7 ms·

> as a co-founder who is spending less time as a developer, and more time in meetings, writing emails, strategy papers, [...] this is just amazing [...] I’ve be

by desmap 6y ago

> as a co-founder who is spending less time as a developer, and more time in meetings, writing emails, strategy papers, [...] this is just amazing [...] I’ve been spending a lot of time getting Windows Subsystem for Linux working lol, just ssh into a $3 vps as dev machine, real Ubuntu, real tmux/(n)vim, no setup, no hassle Edit: to be fair, Cloud9 was my entry drug into remote development bringing me to my setup above; the idea is awesome and Github Codespaces is too but there are just too many limitations and having a real, ever-running Linux vps everywhere, even on your phone is just magic and even when you write strategy papers...

josephg 6y ago
I respect developers who make that work, but the development experience over SSH (vim, etc) is never as good as local development. You can't use vs code. You have to deal with lag delaying keystrokes. If you download a file and want to copy it into your dev environment you need to SCP it over. If you want to test a network service its nontrivial to point your local browser at the remote machine. If you sleep your laptop and open it again, you need to reconnect your SSH sessions. Etc etc. A lot of these issues can be solved with enough extra work setting everything up - but that completely defeats the point. "no setup, no hassle" is never my experience.
- deleted 6y ago
  [deleted]
- Philip-J-Fry 6y ago
  >You can't use vs code Have I got news for you https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh
  - andybak 6y ago
    That requires installing VS Code locally whereas I thought we were talking about a "no install" dev environment?
- markild 6y ago
  I guess that's where vscode's remote ssh extension comes into play. There's things to be said about it being closed source, but it _definitely_ also removes, IMO, the pain points of remote editing.
- desmap 6y ago
  > vs code check coc.vim, uses vsc's native LSP, 99% of LSP's features > delaying keystrokes I have 16ms latency as my 60hz screen does and def less latency than a local vscode just use a vps close to where you are
  - robotmay 6y ago
    Or use Mosh, which eliminates the keystroke lag.
  - antihero 6y ago
    Some people don't want to use vim, they want to use VSCode.
- jan6 6y ago
  it IS trivial to port forward though, lol
- Aperocky 6y ago
  vim once you get into it is as powerful as vscode, and runs just fine in machine without GUI installed. Funny enough, your description is exactly how I work, except the java part, but then vscode doesn't have an edge with java either.
  - dividedbyzero 6y ago
    > vim once you get into it is as powerful as vscode Maybe, with a lot of effort to set it up like that, and a steep and long learning curve with lots and lots of idiosyncracies, because it's really ancient tech that was made for a completely different kind of computer, and you have to actually like living in a terminal and vim's idiosyncracies in particular.
    - Aperocky 6y ago
      You're probably right, but the advantages of vim in my mind compared to IDE/VSCode/Atom is: 1. Ability to open up any sized file. Anyone who accidentally clicked on a 15mb log file in the directory know what I'm talking about. 2. commands, specifically %s, norm, etc applied over visual mode. norm is particularly powerful when you want to batch edit. 3. macros, the ability to define macros both beforehand, and on the fly is really useful. 4. Availability. Any linux box I ever sshed into has never failed to have vim. ^^ Those are the features that imo are important and won't be available as a vim plugin to other IDEs. People also don't realize how vim has these feature that matches other IDEs. 1. Plugins, the vim plugin world is as rich as other IDEs like vscode. 2. language servers, these can run in the background and provide autocomplete, code smell, e.g. jedi, tsserver-vim.
      - bblough 6y ago
        TIL about norm. Thanks!
- vidarh 6y ago
  All of these frankly just sounds like you're unfamiliar with the typical workflow over ssh and have different tooling preferences. Nothing wrong with that - it's a matter of taste. But personally the reason I often work over ssh connections is that I find the local-only development experience deeply deficient. I package up environments in containers that I can bring up anywhere by dropping in a systemd unit file to pull the images, which means I don't have to worry about whether I have my laptop with me as long as I have ssh access, or about environments changing when I switch laptops. I can also bring those environments up in containers on my laptop, of course. Once I got into the habit of packaging up everything that way it became easy to do, and keep cutting down on the setup effort when I change laptops or make other changes. The flexibility to be able to access the same environment and editor anywhere is an important reason why I insist on using editors that work in a terminal, because that flexibility is far more important to me than any specific editor features. While most of the time I work locally, when I need to ssh in somewhere, not having to deal with a different environment matters. And ssh vs. entering a container is a close enough equivalent that the same workflows apply for the most part. Last couple of years I've used my own client-server based editor that holds all the buffers in a separate process (and traps all exceptions and forwards them to the client, and checkpoints its internal state - I have a couple of years worth of open buffers in RAM, but it just adds to ~24M), because I wanted an editor I could get exactly how I wanted in exactly the language I wanted, and it was worth it. Lag is an issue if on a slow phone connection or something, but you surprisingly quickly get used to working even with ~100ms+ lag, and that's a rare exception. As long as you pick a VPS provider reasonably close 15ms-30ms is not hard. I'm in London, and mostly use Hetzner in Germany, get consistent <20ms to them. It's not noticeable when I log into them. There are few places in the world where you can't find VPS providers close enough. Of course it depends on having decent internet access, so I'm sure there are places that isn't viable. That said, years back I worked over SSH from Beijing to servers in Texas, and even that worked well enough despite the lag. And if you work on things remotely, you quickly get used to download things straight to the remote machine rather than download and copy over whenever possible, and it usually is possible - wget, curl, lynx and links can take a while to get used to, but it's rare I need to resort to downloading anything locally. Not that it is usually a problem if I do, but of course more dependent on upload speeds. Pointing a local browser to a remote machine requires no setup, just knowing the IP. If you want an encrypted tunnel, all it takes is a flag to your ssh client to port-forward. First thing I'll do if I need to do work against a remote server regularly is to set up an alias in .ssh/config to pass the right options. Similarly setting up autossh or similar to automatically re-establish ssh connections (and re-attach to screen or tmux) is a simple one-time affair if you often need to re-attach, but if you run screen or tmux anyway (and I couldn't imagine not doing that on any machines I do actual work on), it's trivial to re-attach to the same state anyway. I run bspwm - a programmable tiling wm, which also means I can easily set up workspaces where it automatically triggers suitable scripts to set up the right windows ssh'd in to the right screen sessions on login, as well. It's true some of this is extra work, but it's extra work once and you have setups you can copy everywhere, and there's extra work to get used to any new tool, but once you get used to these workflows they are extra-ordinarily flexible, not least because they're also scriptable in ways that allows you to add more and more customised shortcuts for the things you do regularly in a lasting way. I've carried my current client-side set of configs and convenience-scripts through half a dozen laptops by now.
simonh 6y ago
>... no setup... Wow, that's a neat trick, how do you manage it?
- desmap 6y ago
  ? click "new vps" at your hoster (60sec), ssh to your new vps, git clone your tmux+nvim config from github (3s), you're ready to go
  - onion2k 6y ago
    So it's "no setup" if you've already done all the work to make a portable setup that enables you to do work over ssh, but actually a ton of setup it you haven't.
    - desmap 6y ago
      shouldn't everyone who touched code on a server have some basic tmux/vim config, at least vim? it's no rocket science and doesn't have to be perfect
      - onion2k 6y ago
        shouldn't everyone who touched code on a server have a basic tmux/vim config, at least vim? No. Obviously not. There are millions of developers who don't work that way.
      - richbradshaw 6y ago
        I’ve been developing for a decade and have never used tmux and have use vim for probably ten hours.
        vidarh 6y ago
        The specific tools are not really the point. The same applies whichever tools you need - sooner or later you'll need to cleanly set up a new machine, at which point committing your configs pays for itself.
coldtea 6y ago
>lol, just ssh into a $3 vps as dev machine, real Ubuntu, real tmux/(n)vim, no setup, no hassle Infamous Dropbox comment: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224
- desmap 6y ago
  Yeah but in contrast the idea isn't new, Cloud9 did this ages ago. Github has the advantage that they own a huge dev focused platform. My point is if you deal a bit with code, even as a founder who writes strategy papers all day long, getting into tmux/vim isn't harder than a vscode-like interface, it pays off in the long run
  - wp381640 6y ago
    XDrive -> Dropbox
- swiley 6y ago
  Meh. The difference is that rsync doesn’t really do what Dropbox does (handle syncing both ways) otherwise they would have been right. Ssh+tmux really does do everything this does and it does it in a way that doesn’t tie you to any single organization. The current company I work for uses the ssh to a VM style setup and I was able to just jump in. Everything was where I expected it to be.
jacquesm 6y ago
> I’ve been spending a lot of time getting Windows Subsystem for Linux working I wouldn't spend a minute on it. Why bother with such an abomination when you can just use Linux the way it is intended to be used with less hassle and corporate superstructure that you most likely will never need.
- jayd16 6y ago
  Well if you're actually asking... I do it so I can use Windows tools like Unity (Editor just runs the best on Windows) and good graphics drivers, as well as having access to bash and linux tooling.
  - jacquesm 6y ago
    I didn't see a question mark in there. If the Unity Editor runs best on Windows then maybe petition the authors to improve it? Otherwise you might end up in a Photoshop/Apple situation and we all know how that ended. Good graphics drivers are available for Linux, and have been for years. Access to bash tooling is the norm on any Linux system.
  - Shared404 6y ago
    > so I can use Windows tools like Unity (Editor just runs the best on Windows) Wasn't Unity a Mac exclusive tool to start out? I know they have support for Windows at this point, and would understand if they've refocused on Windows since then.
    - hurricaneSlider 6y ago
      Unity feels like it runs best on Windows to me. Metal bugs caused quite a few Unity issues for me when I was developing on a Mac. That was a year or so ago, so maybe the situation has improved. Also a lot of useful 3d content creation software is Windows only, or only supports CUDA acceleration, so implicitly rules out Mac from being a first class citizen (e.g. substance painter) Obviously not every game is the same, or needs fancy tooling. But Windows feels like it just works for game dev.
golergka 6y ago
Haven't we been through this discussion before, with "lol just use rsync" comment on the Dropbox original show HN post?...
- bachmeier 6y ago
  "Use SSH rather than WSL" is not the same as the Dropbox comment. Dropbox was dead simple to use, and it did something complicated, keeping files on various machines synced. WSL requires setup and there's friction while you use it. SSH is actually less setup than WSL if you're using a standard Ubuntu Digital Ocean instance.
  - andybak 6y ago
    WSL has one advantage over SSH. I can continue working if my signal drops. (Setup and friction are actually pretty low - but that's another discussion)

by desmap 6y ago

josephg 6y ago

I respect developers who make that work, but the development experience over SSH (vim, etc) is never as good as local development. You can't use vs code. You have to deal with lag delaying keystrokes. If you download a file and want to copy it into your dev environment you need to SCP it over. If you want to test a network service its nontrivial to point your local browser at the remote machine. If you sleep your laptop and open it again, you need to reconnect your SSH sessions. Etc etc. A lot of these issues can be solved with enough extra work setting everything up - but that completely defeats the point. "no setup, no hassle" is never my experience.

deleted 6y ago
[deleted]
Philip-J-Fry 6y ago
>You can't use vs code Have I got news for you https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh
- andybak 6y ago
  That requires installing VS Code locally whereas I thought we were talking about a "no install" dev environment?
markild 6y ago
I guess that's where vscode's remote ssh extension comes into play. There's things to be said about it being closed source, but it _definitely_ also removes, IMO, the pain points of remote editing.
desmap 6y ago
> vs code check coc.vim, uses vsc's native LSP, 99% of LSP's features > delaying keystrokes I have 16ms latency as my 60hz screen does and def less latency than a local vscode just use a vps close to where you are
- robotmay 6y ago
  Or use Mosh, which eliminates the keystroke lag.
- antihero 6y ago
  Some people don't want to use vim, they want to use VSCode.
jan6 6y ago
it IS trivial to port forward though, lol
Aperocky 6y ago
vim once you get into it is as powerful as vscode, and runs just fine in machine without GUI installed. Funny enough, your description is exactly how I work, except the java part, but then vscode doesn't have an edge with java either.
- dividedbyzero 6y ago
  > vim once you get into it is as powerful as vscode Maybe, with a lot of effort to set it up like that, and a steep and long learning curve with lots and lots of idiosyncracies, because it's really ancient tech that was made for a completely different kind of computer, and you have to actually like living in a terminal and vim's idiosyncracies in particular.
  - Aperocky 6y ago
    You're probably right, but the advantages of vim in my mind compared to IDE/VSCode/Atom is: 1. Ability to open up any sized file. Anyone who accidentally clicked on a 15mb log file in the directory know what I'm talking about. 2. commands, specifically %s, norm, etc applied over visual mode. norm is particularly powerful when you want to batch edit. 3. macros, the ability to define macros both beforehand, and on the fly is really useful. 4. Availability. Any linux box I ever sshed into has never failed to have vim. ^^ Those are the features that imo are important and won't be available as a vim plugin to other IDEs. People also don't realize how vim has these feature that matches other IDEs. 1. Plugins, the vim plugin world is as rich as other IDEs like vscode. 2. language servers, these can run in the background and provide autocomplete, code smell, e.g. jedi, tsserver-vim.
    - bblough 6y ago
      TIL about norm. Thanks!
vidarh 6y ago
All of these frankly just sounds like you're unfamiliar with the typical workflow over ssh and have different tooling preferences. Nothing wrong with that - it's a matter of taste. But personally the reason I often work over ssh connections is that I find the local-only development experience deeply deficient. I package up environments in containers that I can bring up anywhere by dropping in a systemd unit file to pull the images, which means I don't have to worry about whether I have my laptop with me as long as I have ssh access, or about environments changing when I switch laptops. I can also bring those environments up in containers on my laptop, of course. Once I got into the habit of packaging up everything that way it became easy to do, and keep cutting down on the setup effort when I change laptops or make other changes. The flexibility to be able to access the same environment and editor anywhere is an important reason why I insist on using editors that work in a terminal, because that flexibility is far more important to me than any specific editor features. While most of the time I work locally, when I need to ssh in somewhere, not having to deal with a different environment matters. And ssh vs. entering a container is a close enough equivalent that the same workflows apply for the most part. Last couple of years I've used my own client-server based editor that holds all the buffers in a separate process (and traps all exceptions and forwards them to the client, and checkpoints its internal state - I have a couple of years worth of open buffers in RAM, but it just adds to ~24M), because I wanted an editor I could get exactly how I wanted in exactly the language I wanted, and it was worth it. Lag is an issue if on a slow phone connection or something, but you surprisingly quickly get used to working even with ~100ms+ lag, and that's a rare exception. As long as you pick a VPS provider reasonably close 15ms-30ms is not hard. I'm in London, and mostly use Hetzner in Germany, get consistent <20ms to them. It's not noticeable when I log into them. There are few places in the world where you can't find VPS providers close enough. Of course it depends on having decent internet access, so I'm sure there are places that isn't viable. That said, years back I worked over SSH from Beijing to servers in Texas, and even that worked well enough despite the lag. And if you work on things remotely, you quickly get used to download things straight to the remote machine rather than download and copy over whenever possible, and it usually is possible - wget, curl, lynx and links can take a while to get used to, but it's rare I need to resort to downloading anything locally. Not that it is usually a problem if I do, but of course more dependent on upload speeds. Pointing a local browser to a remote machine requires no setup, just knowing the IP. If you want an encrypted tunnel, all it takes is a flag to your ssh client to port-forward. First thing I'll do if I need to do work against a remote server regularly is to set up an alias in .ssh/config to pass the right options. Similarly setting up autossh or similar to automatically re-establish ssh connections (and re-attach to screen or tmux) is a simple one-time affair if you often need to re-attach, but if you run screen or tmux anyway (and I couldn't imagine not doing that on any machines I do actual work on), it's trivial to re-attach to the same state anyway. I run bspwm - a programmable tiling wm, which also means I can easily set up workspaces where it automatically triggers suitable scripts to set up the right windows ssh'd in to the right screen sessions on login, as well. It's true some of this is extra work, but it's extra work once and you have setups you can copy everywhere, and there's extra work to get used to any new tool, but once you get used to these workflows they are extra-ordinarily flexible, not least because they're also scriptable in ways that allows you to add more and more customised shortcuts for the things you do regularly in a lasting way. I've carried my current client-side set of configs and convenience-scripts through half a dozen laptops by now.

simonh 6y ago

>... no setup... Wow, that's a neat trick, how do you manage it?

desmap 6y ago
? click "new vps" at your hoster (60sec), ssh to your new vps, git clone your tmux+nvim config from github (3s), you're ready to go
- onion2k 6y ago
  So it's "no setup" if you've already done all the work to make a portable setup that enables you to do work over ssh, but actually a ton of setup it you haven't.
  - desmap 6y ago
    shouldn't everyone who touched code on a server have some basic tmux/vim config, at least vim? it's no rocket science and doesn't have to be perfect
    - onion2k 6y ago
      shouldn't everyone who touched code on a server have a basic tmux/vim config, at least vim? No. Obviously not. There are millions of developers who don't work that way.
    - richbradshaw 6y ago
      I’ve been developing for a decade and have never used tmux and have use vim for probably ten hours.
      - vidarh 6y ago
        The specific tools are not really the point. The same applies whichever tools you need - sooner or later you'll need to cleanly set up a new machine, at which point committing your configs pays for itself.

coldtea 6y ago

>lol, just ssh into a $3 vps as dev machine, real Ubuntu, real tmux/(n)vim, no setup, no hassle Infamous Dropbox comment: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224

desmap 6y ago
Yeah but in contrast the idea isn't new, Cloud9 did this ages ago. Github has the advantage that they own a huge dev focused platform. My point is if you deal a bit with code, even as a founder who writes strategy papers all day long, getting into tmux/vim isn't harder than a vscode-like interface, it pays off in the long run
- wp381640 6y ago
  XDrive -> Dropbox
swiley 6y ago
Meh. The difference is that rsync doesn’t really do what Dropbox does (handle syncing both ways) otherwise they would have been right. Ssh+tmux really does do everything this does and it does it in a way that doesn’t tie you to any single organization. The current company I work for uses the ssh to a VM style setup and I was able to just jump in. Everything was where I expected it to be.

jacquesm 6y ago

> I’ve been spending a lot of time getting Windows Subsystem for Linux working I wouldn't spend a minute on it. Why bother with such an abomination when you can just use Linux the way it is intended to be used with less hassle and corporate superstructure that you most likely will never need.

jayd16 6y ago
Well if you're actually asking... I do it so I can use Windows tools like Unity (Editor just runs the best on Windows) and good graphics drivers, as well as having access to bash and linux tooling.
- jacquesm 6y ago
  I didn't see a question mark in there. If the Unity Editor runs best on Windows then maybe petition the authors to improve it? Otherwise you might end up in a Photoshop/Apple situation and we all know how that ended. Good graphics drivers are available for Linux, and have been for years. Access to bash tooling is the norm on any Linux system.
- Shared404 6y ago
  > so I can use Windows tools like Unity (Editor just runs the best on Windows) Wasn't Unity a Mac exclusive tool to start out? I know they have support for Windows at this point, and would understand if they've refocused on Windows since then.
  - hurricaneSlider 6y ago
    Unity feels like it runs best on Windows to me. Metal bugs caused quite a few Unity issues for me when I was developing on a Mac. That was a year or so ago, so maybe the situation has improved. Also a lot of useful 3d content creation software is Windows only, or only supports CUDA acceleration, so implicitly rules out Mac from being a first class citizen (e.g. substance painter) Obviously not every game is the same, or needs fancy tooling. But Windows feels like it just works for game dev.

golergka 6y ago

Haven't we been through this discussion before, with "lol just use rsync" comment on the Dropbox original show HN post?...

bachmeier 6y ago
"Use SSH rather than WSL" is not the same as the Dropbox comment. Dropbox was dead simple to use, and it did something complicated, keeping files on various machines synced. WSL requires setup and there's friction while you use it. SSH is actually less setup than WSL if you're using a standard Ubuntu Digital Ocean instance.
- andybak 6y ago
  WSL has one advantage over SSH. I can continue working if my signal drops. (Setup and friction are actually pretty low - but that's another discussion)