Live data from Hacker News

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

mjg59.dreamwidth.org

331–340 of 479 posts

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

#331
post #305

Earlier quoted context omitted.

This is a very useful feature the moment you have > 1 development machine. Complex build environments, dependencies, personal preferences all syncing seamlessly between all of them is a godsend.

I already do that in pycharm. Everything else needs to be set once. But you’re actually arguing about multi-machines and I’m arguing about “code from anywhere” even on computers that don’t belong to you. That is an overblown feature that I’d never use. Latency is top priority for me. It shall not be sacrificed for any multi machine inconveniences.

What happens when your machine breaks / stops working / gets stolen?

Is your pycharm config and setup backed up properly? Is your pycharm config versioned?

How do you manage credentials / secrets?

How often do you update pycharm? Does this updating require any refactoring?

How do you build (locally? remotely?)

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

#332
post #242

Who uses a physical workstation anymore? (Besides artists.) OP is suggesting a complete remote desktop for Office applications, like Video Conferencing. Ironically, for all the crap X takes, it could actually pull this off. Moreso for Wayland. I'm surprised there isn't a graphics client/server model out there as good as X after ~40 years. But I think the problem is too much layering: trying to put a VM in the cloud a…

A lot of people use workstations. As described in the article, they are more powerful and many people need that power. You may have a specific, limited set of anecdotal data that you're using to ask that question rhetorically probably?

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

#333
post #311
post #294

Earlier quoted context omitted.

Learning to set up my environment to compile my first MUD back in 1999 was my first introduction to Autotools, ./configure, make, etc. I was motivated to solve the problem because I wanted to tinker. I'm sure someone will say I'm gatekeeping, but seriously these low-level skills have served me my entire career, and I wonder what happens when every dev environment is just a docker pull away. Who learns how to build ne…

>Who learns how to build new environments? Feels like this is happening already. There is no incentive to learn the fundamental concepts. We need more people interested in the why, and not just a quick buck. Folks interested in the why is the only reason we are here to begin with! On the other hand....it's great job security! Less and less people understand networking everyday it seems!

The kinds of things people are talking about - fiddling with autotools or PYTHONPATH - are not “fundamental concepts” or “the why” behind anything. It’s just tedious, boring nonsense. There are plenty of intellectually curious people who would be turned off by this stuff.

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

#334
post #324
post #294

Earlier quoted context omitted.

Learning to set up my environment to compile my first MUD back in 1999 was my first introduction to Autotools, ./configure, make, etc. I was motivated to solve the problem because I wanted to tinker. I'm sure someone will say I'm gatekeeping, but seriously these low-level skills have served me my entire career, and I wonder what happens when every dev environment is just a docker pull away. Who learns how to build ne…

Think of it like a product funnel. If the goal is to get people to learn X, making them learn Y as a barrier first is unnecessary. You risk people abandoning the funnel that way. It's still entirely possible to learn these tools some other way.

Yes, but if learning X beforehand required learning Y, then we might be expecting the value of learning X to be the combined value of learning X + Y.

It should be noted when adopting this approach, that you're lowering the expected value from the people who make it through the funnel. This may be counteracted by more people making it through the funnel, or it may not. The delta in total value is completely unknown.

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

#335
post #294

Earlier quoted context omitted.

There is one more point I would like to add to the "less friction to start." This is the killer feature for education. No more do students have to set up their own envs. Figure out PYTHONPATH. No more do educators need to debug installation issues on 3 different OSes. Teachers distribute a pre setup env which they know works for what they are trying to teach. Students go straight into writing code and building things…

Learning to set up my environment to compile my first MUD back in 1999 was my first introduction to Autotools, ./configure, make, etc. I was motivated to solve the problem because I wanted to tinker. I'm sure someone will say I'm gatekeeping, but seriously these low-level skills have served me my entire career, and I wonder what happens when every dev environment is just a docker pull away. Who learns how to build ne…

> wonder what happens when every dev environment is just a docker pull away

They learn later, when/if they actually need it. And for those who turn out to be unwilling or unable, well, there wasn't much chance they'd have taken the same path as you, anyway.

Speaking of paths, specifically path dependence, autotools and friends really are monstrosities and should rightfully be relegated to history. I hope that simpler, easier environment building really are the future, as you hinted.

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

#336

Earlier quoted context omitted.

This isn’t the intended use case, but one upside of cloud desktops is that if I ever forget to bring my work laptop with me, I can RDP from a friend’s computer, etc. In one particular industry that is rife with cloud desktops you can be trusted to invest or trade $X mln dollars of someone else’s money on a daily basis, or to model out a $Y billion dollar M&A deal, but God forbid you try to install VSCode or MobaXTerm…

I don't understand when and why so much power was delegated to IT w.r.t installing software. The FSF needs to start fighting IT and device management policies before talking about open source software.

It's because people install malware a lot. Usually it comes along for the ride with pirated software, creating a 2x headache. I remember when they introduced similar policies at Google for Windows workstations - the stated rationale was that Windows users would warez literally anything and this was independent of job role or position. Senior engineering managers would be warezing things and it would come bound to malware. So they moved to binary whitelisting, eventually :(

Linux avoids this problem mostly because it doesn't have much commercial software to pirate in the first place.

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

#337
post #311

Earlier quoted context omitted.

>Who learns how to build new environments? Feels like this is happening already. There is no incentive to learn the fundamental concepts. We need more people interested in the why, and not just a quick buck. Folks interested in the why is the only reason we are here to begin with! On the other hand....it's great job security! Less and less people understand networking everyday it seems!

The kinds of things people are talking about - fiddling with autotools or PYTHONPATH - are not “fundamental concepts” or “the why” behind anything. It’s just tedious, boring nonsense. There are plenty of intellectually curious people who would be turned off by this stuff.

I agree.

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

#338
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.

Becsuse the business only provides you with one machine so if you need a portable one one day of 100 then it has to be a laptop.

Buying or maintaining two devices per developer is too costly regardless of whether the pair (a cheap laptop and decent desktop) is cheaper than an expensive laptop.

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

#339
post #278

All these dev-machines-in-a-cloud sound wonderful from a security, compliance, and onboarding perspective. What is often forgotten is that this is now a service you’re operating and a massive SPOF. If it goes down (and it will), productivity drops to exactly zero. It’s like sending your devs home until it’s fixed.

Not that much different than a power failure at the office, or your uplink going down. Both more frequent, in my experience, than cloud zonal outages.

Laptops have batteries that can ride out a power failure of typical duration, especially for non-dev workers. People can get a lot done without the internet.

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

#340

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…

Damn, when you said Google I thought you were gonna talk about Cloudtop, etc. +1 to your recommendation, but they do a pretty good job Cloudtop too(for non-power users it is pretty usable). Also check out https://www.mightyapp.com/

Yeah, to be clear for Google work I am talking about the combination of Cloudtop (VM), Cider (IDE), Blaze/Bazel (Builds).

In addition you also need a version control / file sync system.

It's also nice to have some kind of network proxy especially if you are doing web dev. Tools or web services run on the VM and you just access it directly through the proxy on your local browser.

The integration/combination of these is what allows things to work.

For personal code this is Google Cloud Console. You can actually just jump into it . It has a built in VS Code editor.

But at home it would be GCP VM + VS Code + Git.

GCP also has built in proxy. The only problem I have had so far is it doesn't rewrite URL's which can be an issue for web apps. I think it's solveable I just haven't really tried yet.

Theres some other solutions in the other comments as well.

Post reply on HN