1. 9
  1.  

  2. 2

    I SSH around a lot. I can’t most graphical editors, because I don’t want to use one editor on a remote machine and another locally. There are plugins and what not for Sublime/VS/whatever that let it talk to a remote client on another machine that opens a socket on that machine and reads editing requests, but none of them that I’ve seen offer any sort of security. Anybody else on that machine can just send editing requests to localhost:3938 or whatever and control my editor.

    There’s sam, which does away with that problem by doing Unix domain socket forwarding and limiting access to the socket that way, but doesn’t work on older versions of SSH (which are still widely prevalent).

    Then there’s the problem of the whole IDE thing. Say the IDE does 90% of what I want development-wise. Great. The other 10% of the time I have to drop to the shell, where I have decades of experience, let’s me write ad-hoc scripts on the spur of the moment, and has a huge number of standardized tools that work well together. If I have to drop to the shell at all, I’d rather just have a shell window open and do whatever I need to there to avoid the cognitive burden of switching.

    Not only that, but the stuff that the IDE glosses over is stuff that I need to know and don’t want to atrophy. I’d rather be able to use Git wherever I am by just, you know, using Git, then be unable to do something because I don’t have a GUI on top of it.

    So yeah…More power to you if you want to use an IDE/graphical editor, but for me, I just don’t see the advantages outweighing the disadvantages unless you only ever work on exactly one machine (never use a coworker’s machine with a different heavily customized environment, or a remote machine with only vi installed) and never need to do something outside of what the IDE or plugin writers thought of…

    In other words, Unix is my IDE. :)

    1. 2

      Could you elaborate on why do you need to ssh a lot? Is this kind of “ops” work?

      For me development work is 99,5% locally, with most dependencies either mocked out or having real local counterparts (db instances). Most of the time I can work offline. Software is updated with automation or delegated people and direct access via ssh is allowed only during debugging sessions.

      1. 1

        Ops and debugging on virtual machines that are set up for testing my code, mostly. I’ll often get something 90% there, put it on a VM, and then debug there. I know there are better ways to do things but I’m old and stuck in my ways.

        1. 1

          Got it, thanks for the context!

      2. 1

        SSHFS covers a multitude of sins.

        (rip plan 9)

        1. 1

          While I don’t disagree, it breaks my workflow. If I’m in a terminal inside an SSH session on the remote machine, I want to be able to type “${EDITOR} file” and have it open - not switch to another window, navigate to the SSHFS mount, figure out where I am in that terminal window in the remote filesystem, navigate there, and open the file….

          I’m genuinely curious if there’s a better way.

          1. 1

            At ${WORK}, the workflow is:

            • A ‘similar enough’ environment locally for sanity-checking config changes
            • Configuration management to push changes out to a test environment

            This is slower and more hassle than editing in-place, but reduces/eliminates many classes of human error (eg not reloading config, changing the wrong box etc).

      3. 1

        I used sublime for years, I’ve been using VS Code for the past 8 months and I love it, as someone who spends more than 6 hours a day looking at/using an editor, it makes life so easy. Also, it takes less than 2 minutes to setup a clean install how I like (which can’t be said with Sublime), I used atom as a comparison to VS code, but the speed difference was drastically slower compared to VS code.