Earlier quoted context omitted.
For the life of me I don’t understand why folks default to laptops for development. Yes portability is great, but most of us park our behinds at the same desk everyday. If I’m going to be out of the office (away from home) I take a laptop and remote into the desktop! Even M1 macs (I have one and love it), while powerful, just can’t hold a candle to a workstation class machine.
I'd love to do that, but my laptop's and workstation's state inevitably get out of sync leading up to "wait why doesn't this work ... spend a couple of minutes .. ah yes I did X on the other device". (Before someone suggest "use docker": then I'd need a more powerful workstation and laptop :-) And VNCing into my workstation from the laptop has all the drawbacks that Matthew described in the article.
Cloud desktops aren't as good as you'd think
421–430 of 479 posts
Re: Cloud desktops aren't as good as you'd think
#422Earlier quoted context omitted.
Huh? It's not like the children aren't using Google and Microsoft services by the truckload already. Every single one has Android/iOs phone. They use Gmail and YouTube and browse the web. And the schools use it too - MS Windows, Office, Google Classroom, Drive... Practically nothing changes with a cloud desktop.
You mean a fully locked down device that allows no tinkering at all. Then they graduate to college and they're again suggested to use a fully locked down environment with no tinkering at all.
Re: Cloud desktops aren't as good as you'd think
#423I would have agreed until I started working at Google. Also, you should completely avoid having Remote Desktop and instead use ssh + an editor that works with remote files. At Google we have a custom fork of VSCode running in browser and builds can either be distributed or run on my Linux VM to utilize build cache. I liked it so much I started doing a similar setup for small side projects. Just boot up the Cloud Cons…
Re: Cloud desktops aren't as good as you'd think
#424I would have agreed until I started working at Google. Also, you should completely avoid having Remote Desktop and instead use ssh + an editor that works with remote files. At Google we have a custom fork of VSCode running in browser and builds can either be distributed or run on my Linux VM to utilize build cache. I liked it so much I started doing a similar setup for small side projects. Just boot up the Cloud Cons…
Another reason why google likes the remote dev experience is because it doesn't download code to the developers laptop, because they don't trust them.
[0] yes i know bazel / blaze is made by google
Re: Cloud desktops aren't as good as you'd think
#425With cloud gaming you can stream 4K games at 60FPS, with clarity and quality for fast moving objects. Why does remote desktop still shit itself when I move around MS Word with a few pictures? I know a tier 1 financial company that offer 100k / year developers a slow VM and from there you have to log into another VM. The VMs are dual core, 8GB. I watch in horror as each keypress takes more than a second. The amount of…
What’s the input latency like in those cloud games?
Re: Cloud desktops aren't as good as you'd think
#426The cost of a new fullly-spec'd workstation + high performance laptop is tiny compared to the salary of good software developers. Managements have a warped sense of how to save money and as a result grossly hurt morale and productivity where it matters the most.
> The cost of a new fullly-spec'd workstation + high performance laptop is tiny compared to the salary of good software developers. That depends highly on where you are in the world.
Re: Cloud desktops aren't as good as you'd think
#427Try working in banking for 20 years, stuck behind at least 1 layer of citrix living in citrix inception. Latency for every keystroke, your brain starts to add latency to latency that is not there to compensate for a life lived wearing citrix latency goggles.
You simply get used to it. In many industry sectors (think CPU architects), multiple layers of inception is the norm (crossing multiple operating systems), and it is not strange for a keystroke to take 2 seconds, and for a menu to open and finish rendering in 10 seconds. This "experience" is probably the reason why I can still comfortably work over a DSL link with just network X (even though I still find NX much more…
That's absolutely ludicrous that anyone would be expected to work that way.
Re: Cloud desktops aren't as good as you'd think
#428Nothing beats working directly on a fast but quiet workstation sitting next to my table. At least for me, the productivity gains associated with quicker builds, IDE resyncs (CLion, looking at you) or just being able to have email, chat, calendar and an active video conference running without making the system crawl to a halt or long latency spikes are huge. 3-4k for a machine that will likely last 2-3 years is nothin…
For the life of me I don’t understand why folks default to laptops for development. Yes portability is great, but most of us park our behinds at the same desk everyday. If I’m going to be out of the office (away from home) I take a laptop and remote into the desktop! Even M1 macs (I have one and love it), while powerful, just can’t hold a candle to a workstation class machine.
Re: Cloud desktops aren't as good as you'd think
#429Earlier quoted context omitted.
better than X11 did? better than Display Postscript did? (genuinely wondering since i've not had a chance to play with Plan 9, kinda randomly)
X forwarding involves granting the remote system access to your X socket, which is very powerful. I don’t know for sure that Plan 9’s model avoids this (I’ve only had small chances here and there to play with Plan 9), but given its heavy use of namespacing I suspect it’s at least possible. Performance-wise X forwarding was always pretty slow for me in a way that Plan 9 seems to avoid, though I’ve gathered it used to…
Re: Cloud desktops aren't as good as you'd think
#430Earlier quoted context omitted.
> you run/test in a terminal Some of the software has a GUI, and some of the tools (i.e. unit test runners) display their output in a locally (to the remote desktop) running web app viewed via a browser. If I were doing strictly text-based work, I might use tmux, but to be honest i3 scales down so well to the text-only use case that I probably wouldn't bother, since there is no upside to doing so.
For tools with webapp output. You can use a proxy to access it in your local browser. Something like ngrok would work well. The advantage of having tools with APIs