Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mjg59.dreamwidth.org

Post reply on HN
Print view View original

431–440 of 479 posts

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

#431

Post by lioeters »

symlinkk wrote: post #124

VSCode Remote SSH’d into a cloud desktop is superior to local development. With the hardware being remote you can afford to get something that’s ultra fast and can run 24/7, and it still feels just as snappy and responsive as running it locally. I think this will be the standard for development within 3 years.

I agree - for a few years my primary display has been permanently full-screen VSCode with Remote SSH, either to a remote server or a local virtual machine.

Occasionally I open another window to edit files locally, but that's become rarer. I love having everything in a container that I can always destroy and recreate, or spin up as many as I want for isolated environments. It taught me to write automation scripts and configs for reproducible setups. It's perfect for education and onboarding new team members too.

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

#432

Post by api »

ElFitz wrote: post #397
api wrote: post #82

Earlier quoted context omitted.

> What we need is not cloud desktops, or cloud storage. We need local desktops with a decent distributed filesystem, and vendor agnostic access to that filesystem from all our devices. That's absolutely spot on. The problem is: who is going to pay for it? No vendor will do this because it would break lock-in, and building something like this and making it polished enough for widespread adoption is far beyond what pur…

Quite a few complex solutions (mostly unknowingly) used by vast amounts of people have come from pure volunteer open source work. How much we can expect that to continue is a whole other matter though.

If you dig deeply you’ll see that a large fraction of that is actually employees at big companies, universities, and governments. In other words it’s subsidized. Any on the clock OSS work is a subsidy. It’s not pure volunteer.

This tends to be done when there is a strong common interest, but it’s almost always for deep tech and dev tooling stuff. I have never seen an open source consumer product subsidized in this way because consumer lock in is where the money is.

You will never see an open Uber, Ring, or Alexa unless a way can be found to charge for it. As it stands free means “as in beer” more than freedom and nobody would pay for such a thing.

I have played with stuff like Home Assistant. It’s not bad if you are technical. A non-techie could never deploy it.

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

#433

Post by outworlder »

aleksiy123 wrote: post #259

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…

> Also, you should completely avoid having Remote Desktop and instead use ssh + an editor that works with remote files.

That's kinda stretching the definition of a 'desktop', isn't it? The sort of tasks someone uses Remote Desktop for seldom overlaps with what someone uses SSH for. Also it doesn't seem to be the point of the article:

Article: > I'm also going to restrict this discussion to the case of "We run a full graphical environment on the VM, and stream that to the laptop"

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

#434

Post by lmm »

ctoth wrote: post #294
aleksiy123 wrote: post #290

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…

> 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

What skills? 95% of using autotools etc. is tedious memorization or copy-paste, not something you learn anything useful from.

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

#435

Post by assttoasstmgr »

destroy-2A wrote: post #31

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.

Does everyone here just suffer from exceptionally shitty IT departments? I've used Citrix for years and not experienced any of the chronic issues described here. Remember Citrix was developed in the 1990s... the days of Windows NT 3.5/4.0 [1] & Dial-Up connections and to be able to function well in these low bandwidth environments (we're talking kilobits here people, a 10 Mbps LAN was considered glorious at the time). For years ICA was superior to RDP due to its better compression over such connections. It sounds more like whoever setup your environments didn't know what he was doing and the results are what you would expect.

[1] https://www.youtube.com/watch?v=SNJiWPU4HEU

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

#436

Post by dan-robertson »

zasdffaa wrote: post #261
acdha wrote: post #128

Earlier quoted context omitted.

I agree in general but I do blame Citrix for some foot-guns. The Citrix admins at my employer have never figured out how to configure it to get keyboard latency below ~120ms (on a gigabit LAN), and the silly health meter always reports the connection as excellent. This is mostly on them - in classic enterprise IT thinking, if it’s not down your job is done - but I’m somewhat disappointed that it’s even possible to co…

A 120ms should feel immediate. IIRC anything under 300ms feels instant.

The parent comment may be talking only about the network or Citrix components in the critical path. You also have to wait to get keyboard input (often 10s to many 10s of ms) and for double-buffering or composition (you might get updates and render during frame T, flip buffers to reach the OS compositor for frame T+1, have the compositor take another frame to render that and send it to the screen for frame T+2, though this is a bad case for a compositor, you may be paying the double buffering or flu latency twice). And it can take a while for modern LCD screens to process the inputs (changes towards the bottom of the screen take about a frame longer to display) and to physically switch the pixels.

120ms end-to-end without Citrix would be quite achievable with many modern systems (older systems (and programs written for them) were often not powerful enough to do some of the things that add latency to modern systems). So if Citrix 120ms we already get up to your ‘not immediate’ number.

But I think you’re also wrong in that eg typing latency can be noticeable even if you don’t observe a pause between pressing a key and the character appearing. If I use google docs[1] for example, I feel like I am having to move my fingers through honey to type - the whole experience just feels sluggish.

[1] this is on a desktop. On the iPad app I had multiple-second key press-to-display latency when adding a suggestion in the middle of a medium-sized doc.

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

#437

Post by lmm »

cardanome wrote: post #407
petercooper wrote: post #350

Earlier quoted context omitted.

Why not just encrypt your hard disk? While this is a good idea, note that in some countries it is an offence to not hand over keys or passwords when requested (or can rapidly become one - like in the UK) so not carrying data with you in the first place can defend against that.

What is stopping them to force you to give access to your cloud providers though? I think there are solutions to make hidden partitions. You would have have to create a clean, plausible system to show potential attackers. Still feel that clouds providers are a bigger attack surface than encrypted local data. To get you cloud data an attacker would just need to be able to compel you to give the password. With local da…

> What is stopping them to force you to give access to your cloud providers though?

The fact that a) the cloud provider is in a different jurisdiction b) many countries have very broad "anti-hacking" laws that they'd be breaking. It's not by any means a "naturally safe" way of working, but under the current hodgepodge of laws it has some benefits.

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

#438

Post by ThunderSizzle »

raxxorraxor wrote: post #215
indymike wrote: post #195

Earlier quoted context omitted.

> I don’t understand why folks default to laptops for development. I think there's a lot of cost/benefit that comes down to: depends on what you are building. I had lunch with a VR dev last week. He needed a big machine for huge MS builds. I do a lot of web and network programming, and a $1200 LG Gram (i7/32GB, 17" screen) is way more than adequate. The important thing is that employers understand that slow computers…

True, employment costs out-compete costs for hardware very quickly. If your employee takes 10 minutes per day waiting on tasks because the system is too slow, you can instead buy a pretty decent rig every year.

How do you truly report that in a corporation? I haven't seen a way to disclose that a good amount of my time in a project is waiting on thr crappy system they've constructed.

It's almost like the just assume the costs or pretend like it doesn't exist.

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

#439

Post by 0xCMP »

generalizations wrote: post #63
jagged-chisel wrote: post #60

Earlier quoted context omitted.

> Distributed files to where exactly? My desktop computer, my laptop computer, my tablet computer, my pocket computer. Whether that’s cloud or p2p doesn’t matter to me, the user. I should be able to start working on a spreadsheet or presentation on one and, without the ceremony of “save to a shared location, close the app, switch devices, open the app … now where’s that file again?” switch to another and continue edi…

That sounds like syncthing. Dunno about phones and tablets, but I have that functionality among my computers.

Syncthing doesn't solve the problem OP is talking about. It's amazing software that works as long as you don't have to sync the same file edited on two machines before they have a chance to sync. There is no logic, besides something using CRDTs, that can reliably resolve the conflicts in every situation when you just have two sets of bytes and nothing else.

Even if you maintain "last synced" copies + the current latest version and use those to compare against the server there are still simple situations where the conflict resolution doesn't work and/or requires user input. Anything that requires user-input like that can't properly sync binary files without resorting to making a new "File (Conflicted 1).sqlite" which you now manually need to compare.

It just isn't the same thing

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

#440

Post by throwaway413 »

aleksiy123 wrote: post #259

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…

assuming ssh and not scp, replacing traditional ssh with mosh in this setup could prove for some interesting benefits wrt network dependency. If the connection was less brittle, and directories could be opened and cached and rewritten later on, after the connection was disrupted and re-established…that’d be awesome.
Post reply on HN