Visual Studio Code has a seamless SSH extension for working like this too -

https://code.visualstudio.com/docs/remote/ssh

Any editor can use sshfs.

It's a little more tightly coupled than just a file system; it's essentially a fully headless mode.

Tightly coupled is often not desirable.

the VSCode SSH extension runs the editing process remotely so it doesn't need to transfer the entire file.

It's not really clear that that would be faster... sshfs would load the file once (maybe slow, but it's usually a tiny text file) and then do all editing locally in memory. If the editing process is remote, every edit you make is going to involve round trips over the network? That sounds awful?

If you're doing C++ in VSCode the C++ extension will use ripgrep to index your project. When using sshfs, rg runs on the local machine, causing sshfs to load your entire project which if it's large can really slow you down.

The VSCode remote extension installs extensions onto a VSCode remote client installed on the remote machine. So the C++ extensions spawns rg processes on the remote which is a lot faster.

Maybe but folks have been using vim/ssh since the days of vi/telnet. It’s not a problem under normal conditions.

Its closer to vi over ssh.

That could be helpful, text files are often tiny though.

sshfs (and samba for that matter, even more so) can cause odd kernel behavior and crashes, unfortunately. They're great when network is 100% perfect, if you never suspend laptops, etc. If any of those assumptions go away, you've got a mess.

>odd kernel behavior and crashes

I was under the impression that sshfs is based on FUSE, which works in userspace.

It is. That doesn't prevent bugs in FUSE itself.

Please write a blog post detailing this full setup! I have been trying to do some form of this between macos and a linux host for some time now (to try and move as much compute off my MBP as possible) but it has never really worked well.

over years i started to use vnc instead of X as it works better over WAN. Super simple setup. On linux host one just runs an in-memory Xvnc server. The session and running applications are all stay there no matter whether client connects or not. The client runs on any platform.

Xpra is kinda cool, gives you a more "persistent" experience with X forwarding.

That's pretty much my dream setup (except for the 2060, I have no need for anything more than a low-end GPU).

I think some may discount Ryzen 9 because it's technically not "HEDT", but the market boundaries have changed over time.

HEDT used to include all CPUs more $400 dollars, all of which shared the same socket (for a given generation). Mainstream was on a separate socket and all below $400.

However, Broadwell-E and Skylake-X moved the top end of the HEDT from $1K to $2K, which meant that HEDT spanned a huge segment.

What AMD did with Ryzen 9 and X570 was to take the middle segment of that HEDT market and make it it's own segment.

> What AMD did with Ryzen 9 and X570 was to take the middle segment of that HEDT market and make it it's own segment.

It did carve out a pricing segment there, but the really cool thing is that it's so compatible, backward and forward with other CPUs in the Ryzen family. There is huge upgrade potential.

It would be entirely reasonable to build a system around an R7, with the expectation that its workload will grow, and throw in a discounted 3950X in a year when Zen3 hits.

I've been using VS Code's SSH Extension for the code that is deployed on a laptop running Ubuntu that's older than my 2017 macbook air but sufficiently powerful. Thanks for mentioning the X forwarding.

you may want to try parsec for remoting if you have good connectivity. It's meant for gaming but I've been using it on my LAN as a replacement for VNC and it's fanastic

Yea, X Forwarding works fine for home LAN usage, but when I'm away from the house I probably ought to find something better (more performant). Was thinking of setting up VNC, but will have to check out parsec (hadn't heard of it) as well.

I love your setup. This was my setup at my first software job. I would never actually use the keyboard and mouse of the machine but I would remote into it and forward X to my Windows PC.

This is the way to go. Get something comfortable and with good battery life, these should be your only must haves. Then dump the rest into the server or some monthly bill for some compute nodes for all your heavy lifting. Use the right tools for the job, not a swiss army knife full of compromises.

An XPS 13 isn't a high end laptop? What are you doing that requires that kind of power?

It sounds like an amazing build, but definitely not needed for most tasks. The XPS 13 seems a little wasteful in the setup. You could practically do it with a chromebook.

Any XPS 13 will be running a -U series low-power CPU. I would not consider any laptop high-end with regard to compute, unless it is using a -H series part, at least.

-U series (somehow, magically the same designation between AMD and Intel) will typically run ~15W, though this is configurable by the OEM (sometimes in BIOS?).

-H series (also, magically the same designation) will typically run ~45W, and this is also configurable by the OEM.

The increased power envelope of -H series typically allows higher base clocks. Turbo can sometimes be close between a 15W and a 45W chip, but a -H series will be able to maintain higher frequencies for longer, thanks to a superior thermal solution.

The 3gb of ram that the overnight chrome tabs are gobbling up.

How do you find the battery life on you XPS 13 with Fedora? I have a pretty old ThinkPad X1 running Ubuntu and while it works reasonably well I still find the battery life lacking (I am sure the age of the battery is a contributing factor here).

The XPS 13 I've found is pretty easy on the battery. However, I did opt for the 1080p screen. My understanding is that the 4k screen (which would be unreadable to my 40 year old eyes in any case) uses significantly more power.

You know that higher resolution just means that the text is sharper, not that the font is smaller, right? :-D

This is still unfortunately not true on Linux.

Single-screen 2x scaling (about the easiest possible HiDPI option) seems to work okay, but then you're basically running 1080p, so why bother.