Live data from Hacker News

Cloud desktops aren't as good as you'd think

mjg59.dreamwidth.org

421–430 of 479 posts

Re: Cloud desktops aren't as good as you'd think

#421
post #103

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.

You could use ssh to connect to the workstation and do all your work there, preserving state.

Re: Cloud desktops aren't as good as you'd think

#422
post #419

Earlier 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.

Can't speak about Apple devices but there's more than enough tinkering available on Android.

Re: Cloud desktops aren't as good as you'd think

#423

I 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…

That's not a cloud desktop. It's a cool setup, but you framed your comment as a disagreement with the post. But you are actually agreeing.

Re: Cloud desktops aren't as good as you'd think

#424

I 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…

IMO you don't really need it to be a full vnc style remote desktop although, or even have the editor run in the browser. You can get equivalent results with bazel[0] remote execution + cache servers and get a similar horizontally scaling build system, without vnc style jank or full network dependence for your actions as a developer.

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

#425
post #160

With 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?

You can't play an fps with them but they are fine for turn based strategy and similar games. I did some beta testing for google stadia with assassins creed oddyssey when it was still being conceived, and while it was mostly playable (single player game though, I would not consider it competitively playable against other humans), even with my wired 1g fiber connection the service would have these huge drops down to almost 144p quality along with framerate issues.

Re: Cloud desktops aren't as good as you'd think

#426
post #36

The 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.

$3000 every 3 years is not alot of money to spend per head, unless you are considering somewhere with developer salaries in the $10,000 range or something like that.

Re: Cloud desktops aren't as good as you'd think

#427

Try 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…

You're a CPU architect and you wait 2 seconds for a keystroke? And you stay in that job? You must be one of the dumbest geniuses I have ever met.

That's absolutely ludicrous that anyone would be expected to work that way.

Re: Cloud desktops aren't as good as you'd think

#428
post #13

Nothing 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.

I guess this is why I ultimately went for a fully spec'd Macbook Pro. It's the price of a car but the value of having workstation class performance anywhere I go makes it easily worth it.

Re: Cloud desktops aren't as good as you'd think

#429

Earlier 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…

Display Postscript was really great, and X11R5 at least was super snappy, predates the Motif and other window managers slightly, I think. But i also would use super fast window managers and usually not be pushing bitmaps all over.

Re: Cloud desktops aren't as good as you'd think

#430
post #298

Earlier 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

Sure, but it's a lot easier just to open a browser in the remote desktop session. It's not like the FPS of the browser matters much when looking at unit test results.
Post reply on HN