As a software dev, I like using whatever as a local env but SSH'ing into something more powerful to perform any heavy lifting. There's also tools like VSCode Remote that make it almost like developing locally. That said, the most taxing tools that I use regularly are things like video conferencing and "collaboration" tools like Miro. These things are hell.
> 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" - an approach that only offers SSH access is much more manageable, but also significantly more restricted in certain ways. With those details mentioned, let's begin.
It is good that these "water is wet" statements get written down so we can point humidity-skeptical people to them from time to time.
The deeper problem is the sad state of affairs of distributed computing for the end user:
* Application instances expect to be the only ones modifying the files that underlie the document being edited. Most of them simply bail out when the files get modified by another application.
* The default is "one device = one (local) filesystem" which is the exact opposite to what everyone needs: "one person = one (distributed) filesystem."
* The case for local-only filesystems only addresses corner cases, or deficient distributed file systems that fail to uphold basic security constraints (such as "my data is only in my devices" or "no SPOF" for my data).
* Whatever gets pushed to the cloud becomes strongly dependent on devices and vendors. Users end up handcuffed to a specific hardware (iCloud) or software (Android) if they want to have any chance of interacting with their own documents from their own devices.
* 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.
> * 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.
While I agree, this by itself doesn't solve the problem when you depend on such a FS for your work in a way that when you lose network connectivity, you can no longer work.
But then you have to deal with conflicts in a sensible way that won't lose users files and make it simple enough for people to choose which files to synchronise.
I mean, isn't that a potential usecase for Syncthing? If I go offline on one of my devices, my files are still locally on the system. When it comes back online, it re-syncs the other devices to use my latest files.
This is a very simple use case when you are working alone. Think about a team of people and hundreds of potentially conflicting changes to review manually.* Sometimes a tangible divide between online and offline is extremely useful.
*) Unless you believe this can be resolved by software - I'm afraid we're very far from that point yet.
You can't just synchronise things without knowing the file formats. You can't do a seamless distributed FS which allows offline changes.
Or more precisely, you can, but by choosing the most fresh file and people have lost work that way. There's a few "dropbox ate my files" stories out there.
It would have to be magical not just decent. This is not solvable on the level of the file system. You can't add a blue line to an image on one system and a red line on another system and expect the filesystem to somehow figure out how to handle that on its own. The best you can count on is the conflict being flagged with both versions exposed.
CRDT is extremely format-specific. File systems don't operate at that level. And that's before we even decide if the merged edits is what you actually want.
It’s incredible how many systems are basically two silos that sometimes somehow sync in a totally custom manner, when we have so many ways of keeping distributed systems in sync.
> Previously I used OVH online drive service, but it was EOL and pCloud is the replacement.
So a vendor has the power to disrupt you whenever they feel like EOLing the service you depend on. I understand that's as good as it gets today, but it's not good enough.
For me, the only acceptable level of impact is as follows:
* vendor X sunsets their service by date D
* before date D, I sign-up for a new account with vendor Z and configure it in my filesystem settings
* I set vendor X as "deprecated,EOL-date=D" in my filesystem settings.
Then my filesystem takes care of everything else for me transparently, with zero downtime and zero effort. Date D comes and goes and I haven't noticed a thing.
>What we need is not [...] cloud storage. We need [...] a decent distributed filesystem,
Distributed files to where exactly? You need to be more concrete about the remote location of non-local data that normal people can use. Ok, so you want "distributed filesystem" to not mean "cloud storage" ... So is it p2p? Something else?
In other words, we want Windows, macOS, Linux, iPhone, Android, etc operating systems... to have a file system that all points to the same "distributed filesystem" and see the same files -- and for other collaborators to see those files.
But we don't want those os configurations to point to DropBox / MS OneDrive / Google Drive / Backblaze, etc. So, we need to be concrete on the alternative common remote location that those file system APIs would point to. What would the topology of that solution look like?
This is the problem that needs to be solved. Cloud storage and p2p are solutions looking for a problem, but it would be nice to let them distract us too much.
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 editing.
First we need to specify a distributed fs. THEN we can decide the “to where” bit.
I use syncthing. It's awesome for computers. Coming from Dropbox, then Nextcloud, I find it solves all my needs much, much better, at least on well-supported platforms.
I love how I can decide what to sync where, and even create my own topology of sync-devices if I like. That may sound like crazy complex stuff and over-engineering and what not, but it was a solution I landed on organically, just through normal use.
That said, it's not entirely smooth on iOS and you sometimes needs to manually launch the (third party) app to force a sync after changing some files.
If you want to keep your filesystem in sync across many devices Syncthing fully enables this.
It is a use case where you would expect a payed service would be easier or more reliable but with Syncthing it is the exact opposite. Just install it on your devices and select the folders you want to keep in sync ... done.
I had never had any problems with it something I cannot say about Dropbox which can be terribly slow, hogs my PC and resulted in lost files on some occasion.
My filesystem consists of [checks du -h . | tail -1] 189 GB.
I don't think Syncthing (which I love) can cram 189 GB on my 64 GB phone.
Yet I expect to have access to my filesystem from my phone.
Synthing is a nice "pump-hose system" between reservoirs of data. What I was arguing above is to stop having separate reservoirs of data to begin with.
The issue is not so much "can I browse a virtual file system" but more "why should I depend on one local file system sitting on a remote server, probably owned by a third party, as being the single source of truth for my own files."
I just wish Syncthing would allow for deferred sync, i.e. you see the file, but it only gets fetched once you access it.
That's, imo, the only way to sync large folders. I don't need all my Documents/Photos/Movies/Whatever on my phone at all times, but I do wish I could access them when I need them.
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.
The "to where" bit is really important when specifying the fs. If it includes at least one high-bandwidth high-storage high-uptime device (like a server), the requirements and capabilities change drastically compared to if it's composed of a bunch of battery-powered portable devices on limited data plans.
Funny you use a spreadsheet as an example. That's been the default for Excel for years. Save to SharePoint/Teams/OneDrive (whatever MS is calling it these days, it's all the same backend) is the default option - and multi-user live editing (or one user in multiple sessions) just works.
To where exactly: my devices. And if I don't want to buy my own devices, then to a cloud service that offers opaque storage of binary blobs with an API that my filesystem can abstract for me.
So the topology is a mesh network of my devices, and perhaps optionally a few defined remote endpoints that the opaque blob storage service provides me, and that I enter as part of the config of my filesystem.
With cloud storage, you must have one single fixed central location (often a third party) that contains the real data, many satellite locations with a partial replica of the data, and hit-or-miss mechanisms to notice changes in replicas and propagate them to the central location. If the central location is down there is no more synchronization. If the central location is not yours, they can shut you down anytime.
A distributed filesystem does away with the need for a fixed central storage by storing data across all locations with a configurable level of replication. A strong, consistent cascading of changes (eg a crdt semantic) brings all replicas in sync whenever connectivity allows. No third parties need to be involved, no single device is a point of failure.
> 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 pure volunteer open source can reasonably accomplish.
The problem is economic, not technical. There is no business model for user-empowering software anymore.
Software is extremely costly to produce but we pretend it's free and won't pay for it directly, so instead the industry has deeply wrapped itself around business models in which we are the product or that use lock-in to force payment eventually.
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.
I couldn't agree more. I've been working on CRDTs the last few years, and there's a huge opportunity here if we can reinvent the concept of the filesystem. Ideally, we'd replace files with CRDT-backed objects in the operating system. Then instead of fread / fwrite commands (which wastefully overwrite the entire file), applications could express semantic changes which get saved in a log.
Those changes can be transparently replicated between applications, between devices and between users. We'd get better performance on-device, and automatic, transparent device-to-device replication. And we could trivially enable realtime collaborative editing between users. Better still, if it happened at the OS level, we could make it work in every application on the system.
Right now "linux on the desktop" is slowly and inevitably dying in the face of cloud services. How would OpenOffice even compete with Google Docs? Do opensource application authors need to run their own web servers? (And if so, who pays for that?). If we replaced the filesystem with CRDTs, openoffice (and every other program on the desktop which edits "documents") could have best-in-class collaboration features, right there out of the box.
There's an opportunity here to build a really amazing computing system.
A combination of AWS Workspaces and Appstream solutions worked fine for us, with a few hundred developers and data scientists, spread all over the world, as FTEs (for the first category of products) and contractors on various continents (for the latter), including some M&As we conducted and continue to undergo, which require(d) very short time to bringing new teams up to speed.
I've done this for a long while, and I always come back to the only two viable competitors in the space (that don't require enterprise licensing).
Nomachine and ThinLinc.
Everything else is fine for the occasional remote desktop administration, but they all have a combination of bad video quality, no audio, no keyboard shortcut capture or bad scaling options.
You should really try xorgxrdp. It is now part of most modern distros, has good audio support, and excellent video quality (I can watch YouTube on a Pi running Remmina, using nothing but stock OS packages on both client and server).
One catch is that some distros (like Fedora), for some reason use the Xvnc backend to xrdp by default, which is idiotic. Just go into xrdp.ini and enable the Xorg section (get rid of the Xvnc one) to get things to work properly.
I personally cannot abide NoMachine (it was a spectacular fiddly failure for me many times, especially on Mac and Windows clients) and never found ThinLinc to beat the simplicity of RDP, especially considering the client software (I have very configurable RDP clients like Jump Desktop for iOS and Android that work perfectly with Bluetooth mice and keyboards, so I seldom pack a laptop these days).
Yep. Once you edit the xrdp.ini file to enable the Xorg backend (which I've done recently on Fedora 36 and Ubuntu LTS), you're good.
Multiple screen support depends on your client, I've had no issues with Windows and Mac clients. Audio depends a lot on your server distro (clients have it all sorted). Fedora uses pipewire, so YMMV.
When using mobile connections I trim it down to 16-bit color and it is perfectly usable, although if you're doing that all the time I'd also remove wallpaper and shadows (I prefer using something like XFCE when doing that - https://taoofmac.com/space/blog/2022/04/12/2330).
I happen to agree with NoMachine, specially because it actually supports transporting X rendering commands, which is still miles better than transferring video (and you can have e.g. 8K resolutions without requiring a server farm for encoding).
I also like that they allow rootless mode (i.e. without the desktop), which can of solves the problem of "local browser, remote desktop" that TFA is complaining about. Local windows are practically indistinguishable from remote ones.
Many of this also applies to X2Go/FreeNX, albeit it seems to be a bit more regression-prone.
Yep. Having worked in these environments, this solution is almost always sold to companies that are working around shitty hard to reproduce software stacks, staff trust issues, scale up difficulties and checkbox security cargo cults. The resulting outcome is usually increased staff turnover, increased cost and decreased productivity. Most of this they are having trouble rationalising or acknowledging still.
You don't want to work for those companies.
It's notably different if you have a cloud VM running linux and you're connecting to it with VScode or something over SSH. That's borderline acceptable. The reality is usually some horrible AWS, Azure or Citrix portalised solution however.
RDP works fine for Windows honestly, but in Linux the only decent solution is nomachine and sometimes not even that.
Anyway, in my company they decided to hand us out a company laptop and connect through VPN to the corporate network, with shared drives, and it's the best solution IMO.
I worked over RDP for a couple of years. It's not terrible but it's not too good either. You pretty much have to have a wired Internet connection and there are still problems with Alt+Tab and high DPI displays.
That's a reasonable compromise from your org. Good on them. I was suffering with corporate OneDrive. Fortunately everything I do ends up in git anyway so I just turned it off and don't use it.
OneDrive and SharePoint have been mostly ok for me… but there are real limits. They’re fine for a large number of medium sized files that you collaborate on with a handful of people. But then when you have a 100MB PowerPoint with a dozen contributors it falls over and can’t get up. I’m so annoyed they killed Slide Library…
I work almost daily with RDP when I'm working from home, and I have to say that most of the time I almost can't tell if I'm on the remote machine (I'm working full screen) or on the local one. Unless I'm playing a video or use a graphically-heavy application. But it is very true what a good wired connection is needed (at least 100 Mbps, with low latency ~15 ms). Tried this on a LTE connection (a few Mbps and quite some latency >150ms), and it's a pain.
It’s a miserable experience from top to bottom. Onboarding a new developer takes much longer and is far more tedious than one might expect. There are multiple layers of security employees must navigate. And when something breaks, anywhere, it’s a huge pain to sort out the source of the problem, find the right person responsible, and get something fixed.
If you find yourself in an organization that thinks this remote desktop environment is a great idea, do yourself a favor, if you can, and leave. You’ll give other devs more incentive to push back and make this a thing of the past, like “thin clients”.
Absolutely same experience here. The pay is often nice because they also have difficulties to attract developers. Absolutely not worth it in my opinion.
> issues, scale up difficulties and checkbox security cargo cults.
> You don't want to work for those companies
I can’t defend the likes of Citrix but I’ve been the guy who has to tell an intern on their last day to hand over the flash drive with code we know they copied over the day before. Sometimes avoiding those issues is easier.
Also weird tech stacks are a real issue (but there are lots of developer-native tools for the job).
> It's notably different if you have a cloud VM running linux and you're connecting to it with VScode or something over SSH. That's borderline acceptable. The reality is usually some horrible AWS, Azure or Citrix portalised solution however.
100% agree. VSCode and VM is my only accepted solution now.
> It's notably different if you have a cloud VM running linux and you're connecting to it with VScode or something over SSH. That's borderline acceptable.
Layer 4 beats layer 3 in my experience.
I also find that remote workspaces have advantages that offset the latency and performance issues.
Being able to quickly spin up or clone new workspaces and isolate software dependencies is a huge advantage. It can help a lot when dealing with multiple Python environments or JavaScript dependency trees.
Funny that I should be reading this on such a "cloud" desktop.
I have a Raspberry Pi[1] running Remmina and accessing a number of different machines via RDP - A personal Fedora 36 desktop running in an LXC container[2], a Windows VM on Azure, and various other similar environments. I am typing this on that Pi, through that Fedora session, pushed to a 2560x1080 display. Typing and typical browsing is almost indistinguishable from "being there". Coding too. It is only noticeable (on the Pi) when large parts of the screen update and the little thing has to chug along, but I'd rather have this completely silent setup than an Intel NUC.
For work, I do have spanking new a work-issue laptop, but it is fairly recent and the fans spin up whenever I launch anything of consequence, so I am still logging in to a virtual desktop environment for everything up to (and including) audio calls (RDP has pretty decent audio support these days). Video and display sharing I still do locally, mostly because it's usual to switch environments during a call, but I have full multiple display support, and the connection can handle my 5K2K and 4K displays just fine.
I've been doing this for a decade or so, ever since I could use Citrix over GPRS. The user experience is fantastic - even at that time I could literally close my session in the evening, take a morning flight to Milan, pop open my laptop and continue where I had left off, over a piddling sub-64Kbps link.
With the right setup (and experience), latency issues mostly vanish. These days you can push a full 3D rendered desktop over DSL with either optimized RDP or game streaming, so the real constraints typically come from IT restrictions and people wanting to micromanage their environments.
That said, I also use VS Code Remote, and it works great for me as well over SSH. But it's just easier to spin up a VM/container and do that from my iPad :)
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 nothing in comparison.
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've asked for a workstation from corporate IT, because I'm nearly always working from the same spot, and would be okay with a Chromebook on the rare situations I'm working remote.
The cost of a beefy (but properly cooled) workstation + cheap Chromebook isn't much different than a corporate laptop. It's just not an option being considered anymore.
I bring my laptop with me to other teams for questions. I also bring my laptop for presentations, demo’s and sometimes for refinements. I work at home 2 out of 4 days.
And I am no exception. The whole company I work for does this. I cannot imagine working with a workstation.
A big part of my team has crappy laptops and work just fine with a citrix client. I am a developer and do not understand how they deal with it, but the ba’s are ok with it!
I have a work laptop, but do 99% of my work on an identical VM that sets on my homelab proxmox cluster. Working this way allows me to work from any device, even my phone or iPad from anywhere. It's encrypted, has all the standard security tools required for work, etc. Our VPN suite checks for all of that on connection. I have the added benefit of being able to provision with massive amount of resources that it'll only use when needed due to ballooning and quick backup and rollbacks due to LVM thin provisioning.
I do have everything sync back to the work laptop so in the rare case I lose internet or have a hardware issue with the cluster I can continue working. But that's only happened once in the last two years when a completing fiber provider cut a fiber line on my property laying their own fiber. (Not their fault, my current provider had the markings off by 50', and even then the foreman gave me a gift certificates for the trouble)
This is also my experience. Large Rust/C/C++ code bases will easily compile 3-4x as quickly with a fast workstation as with a top end laptop. I blame thermal design and power limits
Android development, a clean build of our project on an M1 Pro is 15 minutes, a clean build from our build server (which is ultimately just a thick 11700K or something along those lines, so still relatively old) is 3 minutes.
At my job, our main software is a multi-million line c++ codebase. It takes most devs 45 minutes to an hour to compile without a fresh ccache, and this is a workstation with 8 physical cores. On my laptop, a fresh compile takes over 2 hours. This can be brought down to under 10 minutes with enough cores. Partly due to poor internal dependency management, it's pretty common that every git pull or rebase requires recompiling ~1/3 of the codebase and waiting multiple minutes to compile in an edit/compile/test cycle is common.
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.
My main professionnal OS in a Linux booting up from an nvme drive with an usb3 case adapter. The pro laptop I have been given only has a screen resolution of 1366x768 and 16GB of ram. I don't mind too much when using it as a desktop because I have 2 fullhd 24" screens but if I plan to be more mobile and work on one screen, or if I need lots of memory to boot containers and VMS I boot it on my personnal Lenovo. I also boot it sometimes on a desktop in my office while I boot the original windows installation of the pro laptop updating itself and not be forgotten.
I use adhesive velcros so that the drive is secured on the backside of the screen and don't hang from the laptop.
If you do your work in VSCode you can setup the following pretty easily and it works really well (I use it to connect to my workstation in my home office when I work in a coffee shop on my laptop or the rare occasions I go into the office):
Tailscale saves time in this. It does things like busting through NATs for you to get the VPN established, useful when on varying networks with the laptop, but yeah it is a wireguard VPN after that.
Not OP, but I think the purpose of tailscale w/ magicdns is to create a VPN connection directly between the laptop and desktop, regardless of the underlying network locations of either. I believe tailscale uses connection brokering so all connections can be outbound (no firewall policy / port forwarding). MagicDNS is probably just a quality of life improvement here.
It just makes sshing between the machines by name very easy. You can do the same thing by assigning permanent IPs to all machines in the mesh and then updating all your host files across all the machines in the mesh. Life is too short for that.
Having set up OpenVPN a few times, and troubleshooting Cisco VPN, the new thing unique to Tailscale is that it just works.
It takes a few seconds to connect each new machine. It took me way more just to find out how I should configure Cisco's VPN client, and I do not ever want to even think about OpenVPN again.
I've also maintained a WireGuard mesh where I distributed keys and set up /etc/hosts via ansible: add a host to the inventory file, run the playbook - simple.
Yet Tailscale is even simpler than that. And (for my purposes at least) it's free.
I have recently started doing this and it's excellent. I can just wander away from my desktop, take my laptop and go work somewhere else in the house, and I used something very similar going away abroad.
Yeah, already Tailscale / WireGuard user and SSHing all around.
Didn't know VSCode had a headless mode that can be driven over the net (which is what your description sounds like), will definitely check it out, thanks.
> (Before someone suggest "use docker": then I'd need a more powerful workstation and laptop :-)
Why do you believe that to be the case? Docker performance overhead is so minimal I highly doubt you'd be able to tell any difference compared to native processes.
I currently work on a project that involves 28 docker containers (edit: on Linux, so no extra VM overhead like on a Mac), and I definitely can tell the difference compared to native processes.
> Even M1 macs (I have one and love it), while powerful, just can’t hold a candle to a workstation class machine
Not really true. My M1 Pro is performance-wise very close to my previous desktop based Ryzen 5900X, but:
1. It doesn't take space on or below my desk
2. Auxiliary screen it provides is useful
3. I can unplug it any time and continue working from anywhere with the same performance, without having to sync up the development environment.
Before M1 Macs I would concur, but right now the major reason to pick desktop is Linux availability (which is a subject to change with Asahi), not performance.
I have M1 (the original) MBP and Ryzen TR2920X desktop (with oddles of RAM, multiple NVMe drives and 10 Gbps networking). The Mac, while significantly better than any Intel laptop I had before, still cannot hold a candle to the desktop, sorry.
It depends on your workload and codebase. I have a Ryzen 5600X in my desktop and for C++ work, my M1 Pro is quite a bit faster for clean or incremental builds. The desktop is still useful/required for some of my work (using x86_64 windows with an nvidia gpu) but I default to the Mac for anything that could be done in either place. It also helps that I prefer the Mac tools so it’s not just about the CPU speed.
That said, I’d rather find a new job than trade either system for a cloud desktop. I count myself fortunate that I’ve always been in a position to choose my computer and tools.
My System76 laptop with Nvidia graphics is faster than the M1 Pro I have for work, has more cores, and 64G of ram means I can run all my communications stuff and an ide and a compiler and a local k3s and the machine won't break a sweat. However, the battery will drain in an hour and a half doing all that. Performance is definitely not an issue on non-arm machines. Battery life is.
> Yes portability is great, but most of us park our behinds at the same desk everyday.
Got to take exception to that. I'm a developer developer an I'm still required to get up from my desk to attend meetings etc, and I need my laptop in them. Or pair programming. It is usually a different kind of work so there's probably a world where I could have a desktop and a laptop but inevitably I'd end up needing to do something the iPad can't do and get frustrated.
> 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 cost them a lot of money when they hobble developers with them.
If people are slacking off more when working remotely, then measures that make doing the job less frustrating seem likely to have outsized positive effects, by reducing that slacking-off.
(Maybe I'm assuming I'm more typical than I really am. I know that when the work I'm supposed to be doing is frustrating and annoying I feel much more temptation to do other things instead.)
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.
Don't make the problem be about people or process, just show the exact problem and how you could get more done if you had a way to continue working during a build. Put the problem on trial, and not people (don't call anyone in IT stupid, don't blame anyone for sucky processes, and do not under any circumstance indict the choice of tooling).
Take your slow laptop to lunch with your manager. Explain that you are starting a task you have to do three-four times a day that prevents you from working because your computer is maxed, compiling. At the end of lunch, let the manager know when the build stopped, and then discuss getting a faster or a second machine so you can work while building.
You nailed it. Portability. Also if you're working professionally it's far easier to collect your property as a company when you don't have to pay oversized shipping costs for a desktop.
Though rarely is a laptop in clamshell mode as good as a desktop. For certain things, I don't think they'll ever be. For example, graphics work and a lot of scientific work just isn't sufficient unless it's done on a desktop.
It depends what you're doing. For a normal web dev workflow, I have yet to see my M1 MBP be anything but flawlessly responsive. I'm sure there are other workloads where it's different
Even in the bad old days when I did work in an office, we worked some days in the office and some at home.
Even now that I work remotely, I still go home to see my parents for a week at the time and work from there. I definitely wouldn’t want to be dependent on the internet.
Not to mention in less than a month, my wife and I will be doing the digital nomad thing working while flying across the country for a few years.
My set up includes a portable USB C powered external monitor as a second display and my iPad as a third display. Of course I have a Roost laptop stand.
If I need to spin up resources, I use my own (company provisioned) dev AWS account and it’s just there.
Even the last 60 person startup I worked at would let us set up dev AWS accounts with the appropriate guardrails for development.
We had CloudFormation templates to spin up environments as needed and we could just tear them down.
"Most of us" absolutely don't do that. My company has 3000+ people, and I can say with certainty that every single person works away from their desk at some point in the day. I would quit my job in an instant if I had to be tied to a desktop at a particular spot all my life.
> Even M1 macs (I have one and love it), while powerful, just can’t hold a candle to a workstation class machine.
My M1 Pro is faster in some workloads than a small Dell tower sold as a "workstation". Of course I could buy a huge workstation with a 250W CPU or some kind of insanity like that, but then I suspect its power efficiency will be 4 times worse than the M1 Pro. The Dell tower already makes quite a good amount of noise under load while being beaten by a mostly silent M1 Pro.
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.
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.
I have the 2019 16-inch i9 MBP for work, and even that has served me pretty well for almost 2.5 years. I'm fairly conscious about what I have running at any given time, I force-quit out of apps that I only open occasionally to free up resources. Sometimes the fans will get going quick if I'm doing a lot (running Java services, in a Teams call, etc - on top of whatever the hell processes are being used by jamf, VPN, and zscaler) but I can't recall it ever "slowing to a crawl." It mainly just gets hot until I'm done with one of the big tasks the laptop is currently doing.
So the issue is the corporate mandated malware. I usually lay the blame of performance issues on corporate malware for any modern Mac or Windows PC.
But all video conferencing software sucks. I have to use them all on occasion depending on the client and usually the only one I actually keep installed instead of using the web version is Chime (yeah I know how do you say where you work without saying where you work).
Oh I just notice you said you had an x86 Mac, yeah they all suck when it comes to fan noise and throttling
I don't get the use case. Why would you even consider using a cloud desktop?
Even a very low-spec laptop is going to run a simple graphical desktop environment like Xfce just fine. Watching a youtube video, browsing the web and even video conferencing can be handled with any new-ish laptop.
And in reality, you still want a reliable laptop with decent keyboard, long battery life, good display and so on. So you won't end up on a low spec machine to begin with.
For computation heavy dev stuff a simple SSH access is good enough. It can be a very smooth experience with a locally running VS Code or something.
Corollary: your company might force to use you a cloud VM desktop _even when your laptop is significantly more performant than the entire server holding these VMs_.
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 on your own.
IT presumably got tired of being bombarded with application install requests, so one solution is to use vendorized cloud desktops that come with pretty easy tools (for them) to install applications.
> 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 on your own.
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.
> Why would you even consider using a cloud desktop?
I've travelled to and through countries (e.g. in the Gulf, France, India) with my work laptop where I was deeply uncomfortable having those data on hand. Taking a clean machine and remoting into that one when needed removes a lot of paranoia points.
Please don't say something like you don't trust encryption. We have known cases where even state actors could not crack encrypted devices. Not to mention the remote communication you have would be easier to monitor and possibly decrypt anyway.
Sure, in theory you would need a kill switch in case some special forces come through your window while you are working on you laptop and force you to remove your hands from it but but I doubt you live such an interesting life for that to be a realistic treat model.
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 data, they also need to get physical access to it. You could for example decide to not take your laptop to a potential dangerous meeting and store it somewhere safe.
Plus, cloud provider have way more attack surface area. They get regularly hacked. Some state actors already have back doors or can otherwise compel the provider to hand out your data.
The more I think about the more I think storing sensitive data in the cloud is not a good idea for privacy and security.
What is stopping them to force you to give access to your cloud providers though?
Here's my thinking: If you're travelling to a country with nosy officials and you needed access to a lot of sensitive data, if it were on your regular (but encrypted) hard drive then it would be more visible if they asked to see the machine. With that data online, it could be in a system you only access by a URL you remember which they can't see. You can show them a normal desktop.
Still feel that clouds providers are a bigger attack surface than encrypted local data.
If you are actively being targeted, I agree. I was thinking more the "curious official" folks seem to run into when travelling. Since the mere possession of certain plain text documents is a criminal offence in my country, this has the potential to catch people unawares.
I think there are solutions to make hidden partitions. You would have have to create a clean, plausible system to show potential attackers.
This is a good tradeoff and would probably be fine unless they're really out for you - a whole other ballgame.
> 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.
PIA to manage multiple systems / os that don't have functional parity. My steamlink, tablet and occasionally phone remote desktops strait onto my desktop with all the customizations I'm used to for daily tasks. It's just nice not having to adjust. Only problem (relatively new) is DRM preventing many streaming service from displaying video.
In my opinion, developing is not a really good use case. Some of our team develops using VSCode + SSH against a remote VM.
One of the best use cases we've found is education and, specifically, trade schools. There are some trade school courses that require really specific software (image and sound, designing electronics, interacting with proprietary robots, etc.), and it's a painful experience to manage all of that, add new programs, etc. (some trade schools have 60+ courses, each one having different subjects and different software through the year!) By having cloud desktops, the teacher can create a template with their requirements and share that template with the students, and if the requirements change, it's as simple as modifying the template and sharing it again.
Also, most of the public schools here are underfunded, so they end up with really old machines, and the cost of renewing a whole classroom gets really high: let's say a new machine costs between 600€ and 1000€ (depending on the trade course requirements). If you have 30 machines for each classroom, it's something around 24k. (Then there are lots of classrooms, you get the idea)
By having "cloud" desktops, there's no need for renewing old hardware, since you can have something like xfce + the viewer, and all the systems can easily manage that load (we even have classrooms with RPIs), and this can be a huge money saving
In the end, cloud desktops aren't the best option for all the use cases, as the author puts it:
> Overall, the most important thing to take into account here is that your users almost certainly have more use cases than you expect, and this sort of change is going to have direct impact on the workflow of every single one of your users. Make sure you know how much that's going to be, and take that into consideration when suggesting it'll save you money.
Contractors, no way to take code out premises (assuming proper security settings on the VMs), and easy to get new instances instead of waiting for crap Dell and HP dual core laptops, with 8GB and 256GB HDD.
If your definition of zero trust includes the endpoint devices because they are in an area that the general public can access.
If you want access to your desktop from multiple locations. Ex, at my local hospital the staff can tap their badge to any computer and instantly reconnect to their desktop exactly where they left off.
If you are in a multi-site scenario but your big LOB app hates the internet so you need all your clients to be in the same building as the server. This is actually the reason I deploy vmware horizon... im not sure what jack henry and Fiserv are doing to make their overblown CRUD apps so network heavy and inefficient to operate, but I'm happy they are finally rolling out their own cloud-first apps so they can deal with their own garbage instead of outsourcing their support to their customeres IT guys.
If you literally just can't acquire hardware because of a pandemic and need more compute than you have on hand.
You definition of zero trust can never include the endpoint devices. Those get to see everything you type on them, and have the same level of access to your services that its user has.
Instead, with a remote desktop you are only adding a bit more of vulnerabilities. It can never remove any.
(About those others, there exist some nice works about program portability, that culminated on fully distributed OSes, but those have no adoption. Instead, people prefer to hack distribution over the piles of hacks that are modern OSes. Obviously, it doesn't work well.)
When your game developer has and needs a $4k workstation, and they work from home half the week. No reason to buy them another machine and have them maintain two seperate workspaces, we just give them parsec.
All our staff seem happy and we don't get complaints. Author hasn't tried modern tools it seems.
Another use case: mobile people with laptops, who sometimes want to hop in to a play test or show a game off to a vendor. No need for them to have a gaming laptop 99% of the time, when an X1 carbon + parsec to a beefy box work fine.
> Modern IDEs tend to support SSHing out to remote hosts to perform builds there, so as long as you're ok with source code being visible on laptops you can at least shift the "I need a workstation with a bunch of CPU" problem out to the cloud.
I'd mention SSH port forwarding in this section. For webdev you'll want to run your server on the remote host and use the local web browser. SSH port forwarding works great for this. I recently used this setup to get some extra RAM for a short project that could only be run as a collection of memory hungry microservices. This way I could get the whole thing running on one box; I spun down the server once the project was done.
I can confirm that using JetBrains Gateway to run IntelliJ is more pleasant than using Chrome Remote Desktop, X11 forwarding, JetBrains projector, or Xpra.
Is there a way in JB Gateway to re-use an existing project?
I am in the office 50% of the time, working on my desktop with CLion.
The other 50% I'm remote. The one time I tried Gateway, it asked me to create a new project, which meant building another index of a giant codebase, and not having any of my per-project settings. The time and disk space of another index turned me off right away. I couldn't find a way to just re-use the existing project.
So for now I just suffer through using NoMachine to remote in, and then operate CLion.
IMHO remote desktops (cloud or DaaS) is a terrible idea with even more terrible executions.
I never tried one that could measure up to a local environment.
I know this sounds gross, but I wonder if Chromebooks could benefit from being able to trigger local browser actions in the remote browser. So you can click "open in new tab" in your remote and it opens in your local browser. Bonus points if the remote session is also in a tab, so it just switches you away and you can come back easily.
Well thought out Citrix and RDP setups have something like this, where certain apps are able to break through and use the local GPU (usually video conferencing apps, like Teams and WebEx).
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.
It almost doesn't. Computers are now cheap enough and developers mobile enough that it holds through all of the developing world, and most of the underdeveloped 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.
In my whole career i only had one company that provided windows machines and as expected it was a horrible place to work at. Current client wants to do the same. Coincidentally the place is becoming less desirable to work with.
But the problem isn't Windows or MacOS. It's all the corporate spyware, antivirus, network interception and whatever else they come up with making the machines work like its 1995.
It's not one big pile of money. Business expenditures are treated differently depending on what you spend it on.
My loose understanding is that capex (e.g. hardware) and opex (e.g. salary) are treated differently in a lot of ways. Some of it is taxes, there are deductions available for opex that don't apply to capex, at least in the US. Also, you can cut your expenses on opex to balance your budget (e.g. layoffs), but it's harder to recoup the sunk cost on capex.
Cloud desktops turn some capex into opex. Depending on how many employees you have, it can be a sizeable chunk of change.
I still think it's only worth it in specific edge cases, though.
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.
I quit a job because of citrix. Exactly like you said, very noticeable latency. It ate into my productivity as a part of my mental energy was going into waiting for feedback to my actions to appear on screen.
> part of my mental energy was going into waiting for feedback to my actions to appear on screen
This should not be underestimated. I was in a situation like this and I though my short term memory stopped working. I forget what steps I already did because some actions took 10-15 seconds. I often switched to another task in the meantime and could not recollect the last step I did 10 seconds ago. Such delays are poison for for intellectual task where you would need concentration for.
There is no excuse for any modern device to make such pauses. It is also far too expensive for any company. The price for hardware is too low to let any user wait.
That's exactly it. Instead of tasks going "1, 2, 3" in my head, it was more like "1,...,1,...,1". I had to keep reloading every task into my working memory, with lots of brief pauses to think "did that click register", or "when I typed those words, was the context on that text box?". It's a truly torturous level of friction.
I didn’t deal with citrix but I did have to frequently SSH into cruise ships at a job some years ago. Goodness was the latency frustrating beyond belief. I didn’t last more than 6 months at that job.
Every single command input/key stroke could take 2-5+ seconds to display on my screen. Imagine trying to troubleshoot something critical in that type of environment. Luckily, I didn’t encounter anything truly critical, it was mostly maintenance tasks and such.
For me what worked is a setup where I used an Arch linux laptop, ran f5vpn in docker and used the citrix client with some tweaks through that vpn connection.
It was a lot faster than my colleagues' Mac / Win client, and even better, it was automatable to start up and run everything.
My employer blocks Linux clients for whatever reason. Even if you pass through the initial checks there is some kind of system on the Remote Desktop that detects your local setup and kicks you out.
So I use a KVM Windows machine with Virtio drivers. QXL seems to be the best video solution.
I am at a law firm that uses a remote system like that. Have definitely gone two Citrix’s deep for some things, so I feel this.
Honestly, though, it’s better than the laptop the other firms have given me. One took over 10 minutes to boot, iirc. It wasn’t just the hardware, there was just so much … stuff, multiple layers of antivirus seemingly hooking all of the system calls and fighting with each other, and a document management system with blocking I/O everywhere that was somehow so embedded in Windows that it could seem to freeze the whole system.
The thin client setup may have latency, but at least it is convenient and it gets there eventually. Though I would swear it’s getting slower, or maybe my patience is waning.
I was a "Citrix consultant" for about two decades.
I'd walk into customer sites for the first time, meet people, and within minutes they would start ranting about how bad Citrix is.
I suspect only dentists get this kind of feedback from customers before a procedure.
Having said that, 99% of the time the problem boils down to this:
The guy (and it is a guy) signing the cheques either doesn't use Citrix OR uses it from the head office with the 10 Gbps link.
The poor schmuck in the backwater rural branch office on a 512 Kbps link shared by two dozen staff gets no say in anything, especially not the WAN link capacity.
I've seen large distributed orgs that were 100% Citrix "ugprade" from 2 Mbps WAN links to 4 Mbps to "alleviate network congestion" in an era where 100 Mbps fibre-to-the-home is standard. With 2 Mbps you can watch PDF documents slooooowly draw across the screen, top-to-bottom, line by line. Reminds me of the 2400 baud days in the early 90s downloading the first digital porn, eagerly watching the pixels filling the screen.
Don't blame Citrix. Blame the bastard in the head office that doesn't give a f%@$ about anyone not him.
It seems to me that the reason why so many bad enterprise solutions are bought is because the buyer is not the user. It’s such a funny thing to me that people would spend tons of money without firsthand experience or at least someone they trust using it.
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 configure it to have latency twice that of a modem.
...for Massive Multiplayer Online Gaming (MMOG), real-time is a requirement.
As online gaming matures, players flock to games with more immersive and lifelike experiences. To satisfy this demand, developers now need to produce games with very realistic environments that have very strict data stream latency requirements:
300ms < game is unplayable
150ms < game play degraded
100ms < player performance affected
50ms > target performance
13ms > lower detectable limit
"
But this is real-time gaming. Typing should be less demanding, I'd think.
Not really, unless you're the kind of guy working in Cobol and who is used to typing with latency.
I've seen Cobol developers just ignoring the latency, keeping typing because they know what they've typed and it doesn't matter that it's slow to show up on screen.
Working with latency like that also requires the system to be predictable. If you're expecting auto complete but not confident in what it'll show, you've got to wait, if you're not sure if the input will be dropped if you type ahead too much, you've got to wait. If you need to click on things, especially if the targets change, lots of waiting.
If the system works well, yeah, you can type all the stuff, then wait for it to show up and confirm. 'BBS mode' as someone mentioned.
> I've seen Cobol developers just ignoring the latency, keeping typing because they know what they've typed and it doesn't matter that it's slow to show up on screen.
I used to do that (not in COBOL), typing into a text editor in a terminal over a 2400-baud modem. Like the other commenter said, you get used to it, but it requires a certain predictability in your environment that you don't get in modern GUIs.
Generally I think of it in terms of number of frames @ 60 fps.
Anything below one frame (16.66ms) and whether or not any sort of real feedback is even received (let alone interpreted by the brain) becomes a probability density function. With each additional frame after that providing more and more kinesthetic friction until you become completely divorced from the feedback around 15-20 frames.
That’s off by about an order of magnitude – highly skilled humans can see and react in less than 120ms. One thing which can complicate discussion on this is that there are different closely related things: how quickly you can see, understand, and react is slower than just seeing which is slower than seeing a change in an ongoing trend (that’s why you notice stutter more than isolated motion), and there are differences based on the type of change (we see motion, contrast, orientation, and color at different latencies due to how signals are processed starting in the cortex and progressing through V1, V2, V3, V4, etc.) how focused you are on the action (e.g. watching to see a bird move is different than seeing the effect of something you’re directly controlling). Audio is generally lower latency than visual, too.
All of this means that the old figures are not useful as a rule of thumb unless your task is exactly what they studied. This paper notes how unhelpful that is with ranges from 2-100ms! They found thresholds around 25ms for some tasks but as low as 6ms for some tasks.
Keyboard latency is one of the harder ends of this spectrum: the users are focused, expecting a strong (high contrast, new signal) change in direct response to their action, and everything is highly trained to the point of being reflex.
When I’m typing text, I’m not waiting for the change to hit a key outside of games but rather expecting things like text to appear as expected or a cursor to move. Awhile back I tested this and the latency difference between VSC’s ~15ms key-to-character was noticeably smoother compared to 80+ms (Atom, Sublime) and the Citrix system I tested at 120-150ms (Notepad is like 15ms normally) was enough slower that it forced a different way of thinking about it (for me, that was “like a BBS” because I grew up in the 80s).
n.b. I’m not an expert in this but worked in a neuroscience lab for years supporting researchers who studied the visual system (including this specific issue) so I’m very confident that the overall message is “it’s complicated” even if I’m misremembering some of the details.
This is just flat out wrong. Any seasoned gamer can feel the difference between a few tens of milliseconds.
300ms would render most video games unplayable.
I see this claim a lot and it's making me want to build a website that gives you some common interactions (moving a mouse cursor, pressing a button) with adjustable latency so people can see just how big of an impact seemingly small amounts of lag have on how responsive something feels.
Then have an estimation challenge mode, where it picks a random latency and you have to guess within 50ms what it is. Seriously though, that sounds both fun and useful.
After using xterm for years, I don't like gnome-terminal anymore because its lag while typing has become noticeable. It's right around 30ms on this site, and xterm around 10-20ms.
If you had 300ms latency, back when I played League of Legends "your ISP is having problems today and you cannot play".
Anything above 70 is considered very bad
Divide those figures by 10 might be closer to being accurate. 120ms is quite noticable. I know as I need to adjust latency out of Bluetooth headphones for recording. Recording with those latencies sounds like a disaster and is very very much noticable even with sounds let alone vision
While my post was wrong, in fairness the context was specifically about keyboards. Nothing to do with audio. I suppose I should have been explicit but the context was keyboard entry.
In my experience visual and feeling type things like typing have even stricter tolerances for timings is what I meant to say. If audio has a delay, visually noticing a delay will at least be as equal if not more noticable at a specific ms
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.
We aren't talking about website loading speeds. This is about how quickly your mouse cursor moves in response to mouse movements and that latency needs to be 16ms or less.
Personally I can get latency down to 200ms over the internet into a remote datacenter with WebRTC. The challenge however in practice is that running a CPU without a GPU will eventually starve the CPU because it has to do intensive things like run a 1080p video at 60fps which aren't feasible on a CPU only machine. This CPU load will then slow down the video encoder and overall responsiveness (no, responsiveness doesn't mean a mobile layout here) of the remote desktop.
I recently had a bit of a rant about security people and how 70% of the truly dumb decisions in our industry can be attributed to them.
Your description is exactly why. Security people wedge themselves into the halls of power and then start making decisions that don't actually negatively affect them all that much.
I've literally seen a CISO that insisted everyone worked in a way they themselves did not.
sadly, the job of a CISO typically isn't "make the most pragmatic decisions possible to keep our infrastructure secure and running smoothly". In many industries, it's more lke "join as many compliance programs as possible to expand the ability to capture revenue from regulated markets".
The CISO didn't make the decision to enforce password rotation- the compliance programs your sales team asked for did
I'm the IT guy for a new non-profit. We aren't separated yet from the company that created us, but we're in the process of separating. I get to decide all this fun stuff.
I had a very brief talk with the IT team for the larger parent company when I started and explained this stupid password rotation thing, as I came from a security background, they wanted nothing of it. Set in their ways.
For the new non-profit that I'm helping spearhead, I'm not sure I'll get away from the password rotation entirely, but I can certainly set it to something more reasonable, like every 365 days, rather than every 60 days or whatever travesty most are dealing with. I'm pretty pleased about this.
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
This is a really useful thing to keep in mind because even if you aren't directly bound by a requirement to follow the NIST standards, being able to point your policy people at that is handy if you can shift the conversation to “bring our policy in line with NIST” where there's a question about whether they'll later look bad for _not_ having done so. Typically these conversations are driven by risk aversion and things like federal standards help balance that perspective.
Aside from password rotation being a very questionable practice, it actually can cause productivity loss. In a big organisation like mine it can take up to 48 hours for a password change to synchronise across all the internal services. There's also the issue where some endpoint software still uses the old password behind the scenes and fails to log in too many times - causing your account to be locked. I guess you can see my frustration coming through.
I had the joy of dealing with some endpoint software like this in an organization that had mandated password changes every 30 days. Very predictably, people set recurring "change your password" reminders for the 1st of the month and the organization lost an entire day of productivity each month as they locked themselves out of their accounts en masse. So the beginning of the month was always a panicked, all-hands-on-deck day for the help desk as people were waiting on hold for hours to get their account unlocked.
Our penetration testers suggested we add password rotation, and I had to quote them the latest NIST guidelines which state "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."
If they don't know better, it's not surprising other companies don't either.
> causes people to append 1, 2, 3, etc to the same password
It’s either that or they write them down. Because people are going to forget a password that changes every month, especially a password that has to comply with the complexity rules.
> To your point, password rotation is considered an insecure practice because it causes people to append 1, 2, 3, etc to the same password.
A good solution to discourage this would be to have heuristics that'd make sure that the new password isn't too similar to the old one, but doing that without having plaintext in there somewhere is pretty difficult.
Another solution would be mandating that all of the passwords should be randomly generated, but enforcing that would be difficult, because everyone who isn't used to having 99% of their new account information being in KeePass databases with randomly generated passwords, probably would find that too cumbersome to remain productive.
This seems like a people problem that makes being secure essentially impossible, due to how people use passwords (e.g. "I just use one password across X sites because remembering multiple ones is too difficult" or "I just add a number at the end of my current password").
And others also mentioned the productivity loss, for when people are slowed down by the need to change their passwords. You might easily rotate Let's Encrypt certificates thanks to automation but when it comes to people, things aren't so easy.
At that point, you might just stick with whatever passwords you have, do some dictionary checks in the future, maybe have infrequent password rotation and otherwise stack on more mechanisms, like TOTP through whatever application the user has available, or another means of 2FA, because relying just on passwords isn't feasible.
Isn't that just a characteristic of how they're evaluated? Any security error is the CISO's fault, "heads must roll", etc
Given that, they're likely to give you what you are asking from them: a brick with no functionality which will do nothing. You can't do anything with Brick, but Brick has zero outstanding CVEs
The last time I saw a place migrate the remote offices from a less than 10Mb/s network was around 2015. That same place replaced its mainframe at 2011 because of an enormous price hike.
This _very_ much depended on where you are. I had symmetric 10Mbps at home in 1998 but when we moved to New Haven in 2008 Verizon couldn't deliver more than ISDN / T1 to large chunks the city (we literally could have used a WiFi antenna to hit their regional headquarters, too). There's so much deferred maintenance around the world.
I've never used Citrix but I remember when I had a T-1 (1.54Mbits for the younglings) and I left a Remote Desktop session open on a laptop. Some days later I went back to the laptop and used it for an hour before I realized I was in a RDP session to a machine in another state. I wonder what Citrix screwed up to make their UX so different. Of course a decent T-1 back then probably had better latency than today's consumer HFC connection.
Yeah the T1 easily had enough bandwidth to smoothly send the 800x600 16 bit color desktop you were probably running at the time (guessing the timeframe based on usage of a T1). Frame to frame diff was probably much easier as well with less shadows and graphical effects that modern Windows or Linux DEs have.
I don’t doubt Citrix has gotten worse as well but the job it had to do back then was much easier.
> Don't blame Citrix. Blame the bastard in the head office that doesn't give a f%@$ about anyone not him.
> The guy (and it is a guy) signing the cheques either doesn't use Citrix OR uses it from the head office with the 10 Gbps link.
If you were sure about this you could have as the consultant told this sentence or made this entire comment as your 'first page' of powerpoint/PDF (to make sure other hn-ers are happy!)
This is me right now, but only for a short time (I hope). I'm at an agency and currently on my first ever banking client. I'm on a Mac but I use Citrix Viewer to access a Windows 10 machine. The part I dislike the most is the context switching between Mac and Windows. First off, windows doesn't natively let you customize the keys (I can't install anything obviously, it's a bank client). Also, for some reason, the alt key doesn't work in the Citrix Viewer so I have to change a lot of my usual VSCode shortcuts to sone custom ones. I've googled the issue and some people on Mac use a program called Karabiner[1] but I didn't want to install yet another program, I'm just dealing with it for now.
Our agency has another banking client that I hear sends you a laptop, I much rather have that.
Hah now imagine using Teams through Citrix workspace.
One thing I've learned about Citrix is that its a startup company with limited resources to handle all the bugs and crusty corpocrapware layers. The client craps on my HDR setup. It install a ton of crap you don't need and it relies on crap like HDX software running on your machine that last time I've checked it didn't had ARM binaries but this tech is also unavailable for the iOS clients. Meanwhile RDP can do semi-decent multimedia stuff without any of this crap.
Maybe I'm immune to it, or just lucky, but two hops (Logging it at home to a Citrix Network Desktop to Remote Desktop to the PC in my office) has been shockingly fine. I live very close to the servers in question though, so speed of light isn't a limiting factor, and I have solid and reasonably fast home internet. It can work fine.
I work in banking. Everything company-hosted I access via a split tunnel VPN. Everything else goes through the normal internet connection, with a company root CA inserted to sniff HTTPS traffic.
This has been my experience with Citrix also, although I have heard it can be set up to work better. Has anyone had experience with HP Anywhere/Teradaci? I am curious how it would compare.
[ Disclaimer - I am responsible for a Citrix environment, but I'm reasonably proud of how well it works for our company ]
The technology behind remote desktops is fundamentally limited but I'm amazed at how good the user experience can be on a modern well-configured Citrix environment.
- The protocol responds well even on low bandwidth as long as latency is OK. On the office LAN it feels like a local computer.
- There is offloading for Teams[1], media streams[2] and even entire web browsers[3].
The tech behind this is impressive and it works pretty well (mostly!)
- For most staff it's easier to use a thin client or a minimal laptop.
- I can keep the Citrix environment patched and managed much more easily than a proliferation of laptops and home devices.
It can be a struggle at times and it's definitely not the right fit for developers. But it's got a lot of advantages and most of the time it works amazingly well.
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 comfortable).
You really just adapt your way of interacting, and start planning more carefully every one of your actions instead of simply clickety-clacketing everywhere like if you were trying to win a game of Starcraft. It's practically subconscious and it really changes you.
I always think it must be much, much worse for blind people.
It also reminds me of people who complain that 5-minute build times "impair their productivity". How do you even work on _any_ mid-sized commercial codebase then ? It's not that uncommon for a build to take hours (e.g. games), and in engineering it is also not that uncommon for builds to take _days_ even on powerful server farms.
Worked with Citrix for years at different customers. Think it is more about setup. Server capacity, bandwidth and so on. Often Citrix was used for connecting to a bastion or a jump host. Then an extra hop to the target machine. Some setups were laggy. Some worked just fine.
Don't worry, I'm sure that will all be folded into microsoft teams soon :)
More seriously, I'm reminded of something a friend always said.
You need to have a response time of 1/10 of a second or less for something to be interactive. I remember that but I wonder if the brain fixes it like it ignores your blind spot.
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.
Citrix performance can depend a lot on the apps - older win32 apps work really well as the object caching masked the latency on windows and buttons. Newer apps seem to somehow make the caching not very effective.
Give me a powerful workstation at work. Keep the laptop, I'm not doing extra work from home. Of course I have an even more tricked out system at home, but that's for playing games and working on my side-hustle.
> But even a fast laptop is slower than a decent workstation, and if your developers want a local build environment they're probably going to want a decent workstation. They'll want a fast (and expensive) laptop as well, though, because they're not going to carry their workstation home with them and obviously you expect them to be able to work from home.
What kind of builds require more than one of the new MacBook Pro’s?
And what about using cloud development environments instead of a fully remote desktop? I haven’t properly tested GitHub Codespaces, but it seems to me that a lightweight laptop (ie cheapest MB Air, if Apple) with MDM plus codespaces can work really well.
Sure, not everyone is using these tools, but to state that devs in general need both a beefy workstation and a laptop sounds a bit outlandish to me.
I work at the company the gives a chromebook and a cloud desktop. Works great for me.
VS Code for the development, SSH for the remote desktop, most of operations can be done via VSCode anyways. Chrome RDP is slow, I agree. I never use it anyways.
nobody thinks that. not in their sane mind. except for the "you vill ovn nothing, und we vill be happy" technocrats, but their reasons for that are their own.
- workstation model means working on a good (physical) desktop setup, large main monitor, eventual other(s) monitor(s), good keyboard, perhaps a thumb trackball instead of a mouse etc, oh, sure potentially the same can happen with a docked laptop but...
- ...laptop model means being able to move. If we WFH there aren't much reasons to move, well except when moving means relocate elsewhere. In practice MOST laptop users do not use their computers to be operational on the go but as a desktop replacer in suboptimal improvised setups, while those who need a good laptop can hardly find one.
The real issue came out in lack of knowledge from most about how remote works should be done. We have seen a big PR campaigns for more than a decades about nomadic workers who works on unstable and limited mobile network with PCMCIA/3G modems cards, then USB stick/HSPA stuff, portable hotspot, mobile tethering etc in a bar (so with potentially hostile and distracting surroundings) or on a beach (added to a potentially hostile climate/environment for mobile devices) and this model who push from "big notebook" to netbook to ultrabooks etc obviously fails miserably since it can't really work. We can work in such setup for a limited period of time for limited tasks but nothing more.
Now many start to admit that the solution is going back to the classic desk BUT this means every home need a room with a proper setup and so is an effort on both the worker and the company. A thing most reject.
Substantially: it's about time to tell things clear. The modern web is CRAP made to sell services instead of empower users through IT plus an admission that classic commercial desktop model is also CRAP. We damn need real desktops with document-based UIs, working locally and syncing just data that need to be synced. As we do as humans, anyone who do a certain job with a significant degree of independence in a single company.
To do so from remote we need a damn room per worker, well equipped, rented to the employer for a fair rate and establish clear contracts on that work paradigm.
Try to keep up the crappy surveillance capitalism business who can be translated in "rent someone else services, own nothing", in the trace of WEF/2030 https://youtu.be/Hx3DhoLFO4s famous video it's a very expensive absurdity. Try to keep up hybrid craps to avoid real capex is another absurdity.
Those who are eligible to work from home and want such paradigm should offer a proper room for that, companies should be clear "you are hired for remote works AND REMOTE ONLY, eventual travel to meed in persons must not happen more than once in a while" where the timeframe vary depending on the company and workers geographical distance.
Let's do that and we all benefit, companies and workers together in a win-win move those only loser will be GAFAM and friends (from Citrix to Bomgar). Avoid doing so and we will keep an inconsistent liquid situation that can be trivially called like the famous Full Metal Jacket Sg. Hartman definition on the most common amphibious thing so called ...
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 lost productiviry is in millions
Shadow offers remote desktop environment with GPU acceleration where you can run games and it feels responsive and decent.
From a former Stadia user; latency was never an issue or noticeable with a 4K stream. And I've played quite a bit of fast paced shooters in the platform.
The experience is extremely dependent on location, bandwidth, local setup and availability of close services (in my case, the closest DC was <15ms away according to Stadia telemetry).
Not the OP, but i know for something like PlayStation Now, it was acceptable for most games. It was a pleasure to just decide to play a game and well yeah, I was playing the game. The latency wasn't a concern.
I couldn't see myself playing an FPS on it, but then I prefer kb/m anyways. But for the games I play on console? It was fine.
There can still be issues, of course, but the latency overall wasn't a deterrent.
You can try it for yourself with Nvidia’s GeForce Now free tier. Just connect with Ethernet if possible.
My experience is that it’s definitely playable and beats a low power laptop with an underpowered video card. Latency in the 40ms range, and barely perceptible.
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.
I have 100Mb/s internet and I cannot notice it on Ethernet on my M1 MacBook Air or on Wi-Fi on my iPhone or iPad.
Wi-Fi on the M1 Air is garbage so it's very noticable there.
I would also like to know this. I'm interested in doing fintech development... but there's no amount of money someone could pay me to use a consistently laggy environment. This thread is making it sound like it's commonplace.
Application streaming was and perhaps is still a thing. I remember the softricity days... (Not fondly as the process to prepare application bundles was cumbersome).
It’d be nice if the author mentioned what cloud desktops and how good people think they are. Don’t tell me it’s worse than I think without specifying what you think I think!
I know numerous gaming companies that swear by Parsec. Except the author doesn’t appear to be talking about Parsec tier cloud desktops. But then again it’s not clear what the author is talking about
I've had this in the last few jobs. One reason for it is that to move desks in NYC requires a union employee to move the computer which ends up costing a few thousand dollars. With terminals and a cloud PC you avoid this.
Back when I worked for $MEGACORP, we wanted to mount some monitors to the wall in the infosec space for Big Cool Dashboards. The quoted price from the union contractors that had a lock on all HQ building modifications was frightfully high (five figures to just mount some TVs). They spec'd asbestos inspectors for a space that had been certified asbestos-free, had safety observers that had to stand around and be sure the 'job site' was safe, etc.
We went and just bought rolling stands instead. We thought about sneaking the Best Buy techs in but decided we liked our jobs too much to do that. When they found out we just bought stands instead of having the screens mounted they tried to throw a hissy fit but were unsuccessful (we didn't actually break any rules).
This same job required me to get an exemption from two unions because the devices I worked with communicated with RF energy (radio union) and I needed a screwdriver to get inside of them (IBEW). Sigh. It didn't matter than the wire techs down the hall from me didn't know JTAG from JPEG — I couldn't risk getting a grievance because someone thought I, a mere unrepresented member of "management" (as everyone who wasn't union-represented was called), was takin' their jerbs.
Not sure if this is the Cloud not Thin clients but in a school licensing killed any Thin Client attempts.
It was just too hard.
I never got to the stage they hint at, if a tiny amount of things won't work, does it means the whole idea fails?
If you only have Word/Excel/internet etc in one lab inevitably someone will ask for X,Y,Z. Is the money saved on computer and maintenance and benefits of instant installs/upgrades worth more or less than the property & teacher/student time costs of that lab running at 90% useability.
478 comments
[ 9.4 ms ] story [ 331 ms ] threadDo you mean computationally taxing or mentally taxing?
And combine computationally heavy result of running stuff like Miro adding to any inherent complexity of collaboration task... Ehhh
> 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" - an approach that only offers SSH access is much more manageable, but also significantly more restricted in certain ways. With those details mentioned, let's begin.
The deeper problem is the sad state of affairs of distributed computing for the end user:
* Application instances expect to be the only ones modifying the files that underlie the document being edited. Most of them simply bail out when the files get modified by another application.
* The default is "one device = one (local) filesystem" which is the exact opposite to what everyone needs: "one person = one (distributed) filesystem."
* The case for local-only filesystems only addresses corner cases, or deficient distributed file systems that fail to uphold basic security constraints (such as "my data is only in my devices" or "no SPOF" for my data).
* Whatever gets pushed to the cloud becomes strongly dependent on devices and vendors. Users end up handcuffed to a specific hardware (iCloud) or software (Android) if they want to have any chance of interacting with their own documents from their own devices.
* 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.
While I agree, this by itself doesn't solve the problem when you depend on such a FS for your work in a way that when you lose network connectivity, you can no longer work.
Instead we got OneDrive, Dropbox and iCloud. Ugh.
*) Unless you believe this can be resolved by software - I'm afraid we're very far from that point yet.
Or more precisely, you can, but by choosing the most fresh file and people have lost work that way. There's a few "dropbox ate my files" stories out there.
Perhaps the idea of plain text/binary files is a little outdated too.
And yes, default into choosing some one, with an extended interface for displaying and managing conflicts.
* CRDTs
* "Intelligent Edge Platforms" as Ditto [1] calls them
[1] https://www.ditto.live/
Especially true for mobile.
I am very happy with pCloud. One of the reasons I got it is: it works very well on Linux. It works on Android. It works on Windows.
And it works in the browser, for things like video and photos.
Also: no risk of trigger-happy account deletion like with Google, if pCloud dies my email still works.
Previously I used OVH online drive service, but it was EOL and pCloud is the replacement.
One payment and so far no complaints at all.
So a vendor has the power to disrupt you whenever they feel like EOLing the service you depend on. I understand that's as good as it gets today, but it's not good enough.
For me, the only acceptable level of impact is as follows:
* vendor X sunsets their service by date D
* before date D, I sign-up for a new account with vendor Z and configure it in my filesystem settings
* I set vendor X as "deprecated,EOL-date=D" in my filesystem settings.
Then my filesystem takes care of everything else for me transparently, with zero downtime and zero effort. Date D comes and goes and I haven't noticed a thing.
pCloud is a replacement I choose, nothing to do with old OVH service.
In all devices.
Apart from that, yes.
Distributed files to where exactly? You need to be more concrete about the remote location of non-local data that normal people can use. Ok, so you want "distributed filesystem" to not mean "cloud storage" ... So is it p2p? Something else?
In other words, we want Windows, macOS, Linux, iPhone, Android, etc operating systems... to have a file system that all points to the same "distributed filesystem" and see the same files -- and for other collaborators to see those files.
But we don't want those os configurations to point to DropBox / MS OneDrive / Google Drive / Backblaze, etc. So, we need to be concrete on the alternative common remote location that those file system APIs would point to. What would the topology of that solution look like?
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 editing.
First we need to specify a distributed fs. THEN we can decide the “to where” bit.
I love how I can decide what to sync where, and even create my own topology of sync-devices if I like. That may sound like crazy complex stuff and over-engineering and what not, but it was a solution I landed on organically, just through normal use.
That said, it's not entirely smooth on iOS and you sometimes needs to manually launch the (third party) app to force a sync after changing some files.
If you want to keep your filesystem in sync across many devices Syncthing fully enables this.
It is a use case where you would expect a payed service would be easier or more reliable but with Syncthing it is the exact opposite. Just install it on your devices and select the folders you want to keep in sync ... done.
I had never had any problems with it something I cannot say about Dropbox which can be terribly slow, hogs my PC and resulted in lost files on some occasion.
I don't think Syncthing (which I love) can cram 189 GB on my 64 GB phone.
Yet I expect to have access to my filesystem from my phone.
Synthing is a nice "pump-hose system" between reservoirs of data. What I was arguing above is to stop having separate reservoirs of data to begin with.
That's, imo, the only way to sync large folders. I don't need all my Documents/Photos/Movies/Whatever on my phone at all times, but I do wish I could access them when I need them.
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
I think the only way around that limitation is to have a node that's always on - make sure it's always known what order the changes were made in.
https://news.ycombinator.com/item?id=5661920
https://www.joelonsoftware.com/2008/05/01/architecture-astro...
Come back to us, Microsoft Briefcase!
So the topology is a mesh network of my devices, and perhaps optionally a few defined remote endpoints that the opaque blob storage service provides me, and that I enter as part of the config of my filesystem.
With cloud storage, you must have one single fixed central location (often a third party) that contains the real data, many satellite locations with a partial replica of the data, and hit-or-miss mechanisms to notice changes in replicas and propagate them to the central location. If the central location is down there is no more synchronization. If the central location is not yours, they can shut you down anytime.
A distributed filesystem does away with the need for a fixed central storage by storing data across all locations with a configurable level of replication. A strong, consistent cascading of changes (eg a crdt semantic) brings all replicas in sync whenever connectivity allows. No third parties need to be involved, no single device is a point of failure.
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 pure volunteer open source can reasonably accomplish.
The problem is economic, not technical. There is no business model for user-empowering software anymore.
Software is extremely costly to produce but we pretend it's free and won't pay for it directly, so instead the industry has deeply wrapped itself around business models in which we are the product or that use lock-in to force payment eventually.
How much we can expect that to continue is a whole other matter though.
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.
Those changes can be transparently replicated between applications, between devices and between users. We'd get better performance on-device, and automatic, transparent device-to-device replication. And we could trivially enable realtime collaborative editing between users. Better still, if it happened at the OS level, we could make it work in every application on the system.
Right now "linux on the desktop" is slowly and inevitably dying in the face of cloud services. How would OpenOffice even compete with Google Docs? Do opensource application authors need to run their own web servers? (And if so, who pays for that?). If we replaced the filesystem with CRDTs, openoffice (and every other program on the desktop which edits "documents") could have best-in-class collaboration features, right there out of the box.
There's an opportunity here to build a really amazing computing system.
https://personalfilesystem.org/
Nomachine and ThinLinc.
Everything else is fine for the occasional remote desktop administration, but they all have a combination of bad video quality, no audio, no keyboard shortcut capture or bad scaling options.
One catch is that some distros (like Fedora), for some reason use the Xvnc backend to xrdp by default, which is idiotic. Just go into xrdp.ini and enable the Xorg section (get rid of the Xvnc one) to get things to work properly.
I personally cannot abide NoMachine (it was a spectacular fiddly failure for me many times, especially on Mac and Windows clients) and never found ThinLinc to beat the simplicity of RDP, especially considering the client software (I have very configurable RDP clients like Jump Desktop for iOS and Android that work perfectly with Bluetooth mice and keyboards, so I seldom pack a laptop these days).
Currentry using Linux Mint, I guess I could try.
Multiple screen support depends on your client, I've had no issues with Windows and Mac clients. Audio depends a lot on your server distro (clients have it all sorted). Fedora uses pipewire, so YMMV.
When using mobile connections I trim it down to 16-bit color and it is perfectly usable, although if you're doing that all the time I'd also remove wallpaper and shadows (I prefer using something like XFCE when doing that - https://taoofmac.com/space/blog/2022/04/12/2330).
I also like that they allow rootless mode (i.e. without the desktop), which can of solves the problem of "local browser, remote desktop" that TFA is complaining about. Local windows are practically indistinguishable from remote ones.
Many of this also applies to X2Go/FreeNX, albeit it seems to be a bit more regression-prone.
You don't want to work for those companies.
It's notably different if you have a cloud VM running linux and you're connecting to it with VScode or something over SSH. That's borderline acceptable. The reality is usually some horrible AWS, Azure or Citrix portalised solution however.
Anyway, in my company they decided to hand us out a company laptop and connect through VPN to the corporate network, with shared drives, and it's the best solution IMO.
That's a reasonable compromise from your org. Good on them. I was suffering with corporate OneDrive. Fortunately everything I do ends up in git anyway so I just turned it off and don't use it.
If you find yourself in an organization that thinks this remote desktop environment is a great idea, do yourself a favor, if you can, and leave. You’ll give other devs more incentive to push back and make this a thing of the past, like “thin clients”.
> You don't want to work for those companies
I can’t defend the likes of Citrix but I’ve been the guy who has to tell an intern on their last day to hand over the flash drive with code we know they copied over the day before. Sometimes avoiding those issues is easier.
Also weird tech stacks are a real issue (but there are lots of developer-native tools for the job).
> It's notably different if you have a cloud VM running linux and you're connecting to it with VScode or something over SSH. That's borderline acceptable. The reality is usually some horrible AWS, Azure or Citrix portalised solution however.
100% agree. VSCode and VM is my only accepted solution now.
Layer 4 beats layer 3 in my experience.
I also find that remote workspaces have advantages that offset the latency and performance issues.
Being able to quickly spin up or clone new workspaces and isolate software dependencies is a huge advantage. It can help a lot when dealing with multiple Python environments or JavaScript dependency trees.
I have a Raspberry Pi[1] running Remmina and accessing a number of different machines via RDP - A personal Fedora 36 desktop running in an LXC container[2], a Windows VM on Azure, and various other similar environments. I am typing this on that Pi, through that Fedora session, pushed to a 2560x1080 display. Typing and typical browsing is almost indistinguishable from "being there". Coding too. It is only noticeable (on the Pi) when large parts of the screen update and the little thing has to chug along, but I'd rather have this completely silent setup than an Intel NUC.
For work, I do have spanking new a work-issue laptop, but it is fairly recent and the fans spin up whenever I launch anything of consequence, so I am still logging in to a virtual desktop environment for everything up to (and including) audio calls (RDP has pretty decent audio support these days). Video and display sharing I still do locally, mostly because it's usual to switch environments during a call, but I have full multiple display support, and the connection can handle my 5K2K and 4K displays just fine.
I've been doing this for a decade or so, ever since I could use Citrix over GPRS. The user experience is fantastic - even at that time I could literally close my session in the evening, take a morning flight to Milan, pop open my laptop and continue where I had left off, over a piddling sub-64Kbps link.
With the right setup (and experience), latency issues mostly vanish. These days you can push a full 3D rendered desktop over DSL with either optimized RDP or game streaming, so the real constraints typically come from IT restrictions and people wanting to micromanage their environments.
That said, I also use VS Code Remote, and it works great for me as well over SSH. But it's just easier to spin up a VM/container and do that from my iPad :)
[1] - https://taoofmac.com/space/blog/2022/08/14/2030 [2] - https://taoofmac.com/space/blog/2022/04/02/2130
Edit: Remembered I shot this video of it running over Wi-Fi, unoptimized: https://twitter.com/rcarmo/status/1561397639215665153?s=20&t...
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 nothing in comparison.
The cost of a beefy (but properly cooled) workstation + cheap Chromebook isn't much different than a corporate laptop. It's just not an option being considered anymore.
And I am no exception. The whole company I work for does this. I cannot imagine working with a workstation.
A big part of my team has crappy laptops and work just fine with a citrix client. I am a developer and do not understand how they deal with it, but the ba’s are ok with it!
I do have everything sync back to the work laptop so in the rare case I lose internet or have a hardware issue with the cluster I can continue working. But that's only happened once in the last two years when a completing fiber provider cut a fiber line on my property laying their own fiber. (Not their fault, my current provider had the markings off by 50', and even then the foreman gave me a gift certificates for the trouble)
Is it just running a bunch of VMs? I don't doubt the tasks exist but it's got to be a list that's been dwindling for the last few years.
Building Firefox on a macbook air or pro M1: half an hour. Fastest M1 max is around 15 minutes.
Building Firefox on my Threadripper workstation: 5 minutes.
Thermal throttling is a bitch.
(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.
I use adhesive velcros so that the drive is secured on the backside of the screen and don't hang from the laptop.
1. Install Tailscale (https://tailscale.com/) on your laptop and workstation and enable the "MagicDNS" (https://tailscale.com/kb/1081/magicdns/) feature. This sets up a VPN mesh between your machines (and any other you add).
2. Setup you SSH keys so you can login via the "MagicDNS" domain name from your laptop to your workstation.
3. Install the VSCode Remote Development extension (https://code.visualstudio.com/docs/remote/remote-overview) on your laptop and then open a workspace on your workstation via its SSH feature using the "MagicDNS" domain.
It is surprisingly fast - you are just sending keystrokes/commands over the VPN and not rasterizing the host screen like you would with VNC.
Is this faster than a traditional VPN? Is the VSCode remote development extension not able to function with a traditional VPN?
(Not op, just butting in)
It takes a few seconds to connect each new machine. It took me way more just to find out how I should configure Cisco's VPN client, and I do not ever want to even think about OpenVPN again.
I've also maintained a WireGuard mesh where I distributed keys and set up /etc/hosts via ansible: add a host to the inventory file, run the playbook - simple.
Yet Tailscale is even simpler than that. And (for my purposes at least) it's free.
Didn't know VSCode had a headless mode that can be driven over the net (which is what your description sounds like), will definitely check it out, thanks.
Why do you believe that to be the case? Docker performance overhead is so minimal I highly doubt you'd be able to tell any difference compared to native processes.
5% of the time I need to travel with my laptop. I’d rather not maintain two machines.
My daily dev is an 8cpu MacBook Pro. It’s not as fast as a proper workstation but I can take it anywhere with about 5 seconds prep time.
Not really true. My M1 Pro is performance-wise very close to my previous desktop based Ryzen 5900X, but: 1. It doesn't take space on or below my desk 2. Auxiliary screen it provides is useful 3. I can unplug it any time and continue working from anywhere with the same performance, without having to sync up the development environment.
Before M1 Macs I would concur, but right now the major reason to pick desktop is Linux availability (which is a subject to change with Asahi), not performance.
The desktop is much more power hungry, though.
That said, I’d rather find a new job than trade either system for a cloud desktop. I count myself fortunate that I’ve always been in a position to choose my computer and tools.
Got to take exception to that. I'm a developer developer an I'm still required to get up from my desk to attend meetings etc, and I need my laptop in them. Or pair programming. It is usually a different kind of work so there's probably a world where I could have a desktop and a laptop but inevitably I'd end up needing to do something the iPad can't do and get frustrated.
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 cost them a lot of money when they hobble developers with them.
Sadly, that's not going to fly these days with those same employers thinking people slack off more often remotely vs. in the office.
(Maybe I'm assuming I'm more typical than I really am. I know that when the work I'm supposed to be doing is frustrating and annoying I feel much more temptation to do other things instead.)
It's almost like the just assume the costs or pretend like it doesn't exist.
Take your slow laptop to lunch with your manager. Explain that you are starting a task you have to do three-four times a day that prevents you from working because your computer is maxed, compiling. At the end of lunch, let the manager know when the build stopped, and then discuss getting a faster or a second machine so you can work while building.
Though rarely is a laptop in clamshell mode as good as a desktop. For certain things, I don't think they'll ever be. For example, graphics work and a lot of scientific work just isn't sufficient unless it's done on a desktop.
I was under the impression they were not.
I couldn't tell you if I was on a laptop or desktop when I'm docked ...
Even now that I work remotely, I still go home to see my parents for a week at the time and work from there. I definitely wouldn’t want to be dependent on the internet.
Not to mention in less than a month, my wife and I will be doing the digital nomad thing working while flying across the country for a few years.
My set up includes a portable USB C powered external monitor as a second display and my iPad as a third display. Of course I have a Roost laptop stand.
If I need to spin up resources, I use my own (company provisioned) dev AWS account and it’s just there.
Even the last 60 person startup I worked at would let us set up dev AWS accounts with the appropriate guardrails for development.
We had CloudFormation templates to spin up environments as needed and we could just tear them down.
My M1 Pro is faster in some workloads than a small Dell tower sold as a "workstation". Of course I could buy a huge workstation with a 250W CPU or some kind of insanity like that, but then I suspect its power efficiency will be 4 times worse than the M1 Pro. The Dell tower already makes quite a good amount of noise under load while being beaten by a mostly silent M1 Pro.
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.
I have never heard the fan on my current MacBook. Now my older x86 one is a different story.
But all video conferencing software sucks. I have to use them all on occasion depending on the client and usually the only one I actually keep installed instead of using the web version is Chime (yeah I know how do you say where you work without saying where you work).
Oh I just notice you said you had an x86 Mac, yeah they all suck when it comes to fan noise and throttling
Even a very low-spec laptop is going to run a simple graphical desktop environment like Xfce just fine. Watching a youtube video, browsing the web and even video conferencing can be handled with any new-ish laptop.
And in reality, you still want a reliable laptop with decent keyboard, long battery life, good display and so on. So you won't end up on a low spec machine to begin with.
For computation heavy dev stuff a simple SSH access is good enough. It can be a very smooth experience with a locally running VS Code or something.
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 on your own.
IT presumably got tired of being bombarded with application install requests, so one solution is to use vendorized cloud desktops that come with pretty easy tools (for them) to install applications.
I feel this so much.
Linux avoids this problem mostly because it doesn't have much commercial software to pirate in the first place.
I've travelled to and through countries (e.g. in the Gulf, France, India) with my work laptop where I was deeply uncomfortable having those data on hand. Taking a clean machine and remoting into that one when needed removes a lot of paranoia points.
(which are both viable, but there is a different number of drawbacks to each)
Please don't say something like you don't trust encryption. We have known cases where even state actors could not crack encrypted devices. Not to mention the remote communication you have would be easier to monitor and possibly decrypt anyway.
Sure, in theory you would need a kill switch in case some special forces come through your window while you are working on you laptop and force you to remove your hands from it but but I doubt you live such an interesting life for that to be a realistic treat model.
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.
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 data, they also need to get physical access to it. You could for example decide to not take your laptop to a potential dangerous meeting and store it somewhere safe.
Plus, cloud provider have way more attack surface area. They get regularly hacked. Some state actors already have back doors or can otherwise compel the provider to hand out your data.
The more I think about the more I think storing sensitive data in the cloud is not a good idea for privacy and security.
Here's my thinking: If you're travelling to a country with nosy officials and you needed access to a lot of sensitive data, if it were on your regular (but encrypted) hard drive then it would be more visible if they asked to see the machine. With that data online, it could be in a system you only access by a URL you remember which they can't see. You can show them a normal desktop.
Still feel that clouds providers are a bigger attack surface than encrypted local data.
If you are actively being targeted, I agree. I was thinking more the "curious official" folks seem to run into when travelling. Since the mere possession of certain plain text documents is a criminal offence in my country, this has the potential to catch people unawares.
I think there are solutions to make hidden partitions. You would have have to create a clean, plausible system to show potential attackers.
This is a good tradeoff and would probably be fine unless they're really out for you - a whole other ballgame.
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.
In my opinion, developing is not a really good use case. Some of our team develops using VSCode + SSH against a remote VM.
One of the best use cases we've found is education and, specifically, trade schools. There are some trade school courses that require really specific software (image and sound, designing electronics, interacting with proprietary robots, etc.), and it's a painful experience to manage all of that, add new programs, etc. (some trade schools have 60+ courses, each one having different subjects and different software through the year!) By having cloud desktops, the teacher can create a template with their requirements and share that template with the students, and if the requirements change, it's as simple as modifying the template and sharing it again.
Also, most of the public schools here are underfunded, so they end up with really old machines, and the cost of renewing a whole classroom gets really high: let's say a new machine costs between 600€ and 1000€ (depending on the trade course requirements). If you have 30 machines for each classroom, it's something around 24k. (Then there are lots of classrooms, you get the idea)
By having "cloud" desktops, there's no need for renewing old hardware, since you can have something like xfce + the viewer, and all the systems can easily manage that load (we even have classrooms with RPIs), and this can be a huge money saving
In the end, cloud desktops aren't the best option for all the use cases, as the author puts it:
> Overall, the most important thing to take into account here is that your users almost certainly have more use cases than you expect, and this sort of change is going to have direct impact on the workflow of every single one of your users. Make sure you know how much that's going to be, and take that into consideration when suggesting it'll save you money.
If you want access to your desktop from multiple locations. Ex, at my local hospital the staff can tap their badge to any computer and instantly reconnect to their desktop exactly where they left off.
If you are in a multi-site scenario but your big LOB app hates the internet so you need all your clients to be in the same building as the server. This is actually the reason I deploy vmware horizon... im not sure what jack henry and Fiserv are doing to make their overblown CRUD apps so network heavy and inefficient to operate, but I'm happy they are finally rolling out their own cloud-first apps so they can deal with their own garbage instead of outsourcing their support to their customeres IT guys.
If you literally just can't acquire hardware because of a pandemic and need more compute than you have on hand.
Instead, with a remote desktop you are only adding a bit more of vulnerabilities. It can never remove any.
(About those others, there exist some nice works about program portability, that culminated on fully distributed OSes, but those have no adoption. Instead, people prefer to hack distribution over the piles of hacks that are modern OSes. Obviously, it doesn't work well.)
All our staff seem happy and we don't get complaints. Author hasn't tried modern tools it seems.
Another use case: mobile people with laptops, who sometimes want to hop in to a play test or show a game off to a vendor. No need for them to have a gaming laptop 99% of the time, when an X1 carbon + parsec to a beefy box work fine.
The fact that Microsoft failed at a dozen sync frameworks (as chat is for google, sync was for Microsoft) and in 2020 this is still not really doable.
Also, I still can't find a good guide for spinning up a desktop in AWS.
I'd mention SSH port forwarding in this section. For webdev you'll want to run your server on the remote host and use the local web browser. SSH port forwarding works great for this. I recently used this setup to get some extra RAM for a short project that could only be run as a collection of memory hungry microservices. This way I could get the whole thing running on one box; I spun down the server once the project was done.
https://www.jetbrains.com/remote-development/
I am in the office 50% of the time, working on my desktop with CLion. The other 50% I'm remote. The one time I tried Gateway, it asked me to create a new project, which meant building another index of a giant codebase, and not having any of my per-project settings. The time and disk space of another index turned me off right away. I couldn't find a way to just re-use the existing project. So for now I just suffer through using NoMachine to remote in, and then operate CLion.
That depends highly on where you are in the world.
Being inflexible can certainly be a red flag though.
My loose understanding is that capex (e.g. hardware) and opex (e.g. salary) are treated differently in a lot of ways. Some of it is taxes, there are deductions available for opex that don't apply to capex, at least in the US. Also, you can cut your expenses on opex to balance your budget (e.g. layoffs), but it's harder to recoup the sunk cost on capex.
Cloud desktops turn some capex into opex. Depending on how many employees you have, it can be a sizeable chunk of change.
I still think it's only worth it in specific edge cases, though.
This should not be underestimated. I was in a situation like this and I though my short term memory stopped working. I forget what steps I already did because some actions took 10-15 seconds. I often switched to another task in the meantime and could not recollect the last step I did 10 seconds ago. Such delays are poison for for intellectual task where you would need concentration for.
There is no excuse for any modern device to make such pauses. It is also far too expensive for any company. The price for hardware is too low to let any user wait.
Sounds like my life as a developer too. =D
Every single command input/key stroke could take 2-5+ seconds to display on my screen. Imagine trying to troubleshoot something critical in that type of environment. Luckily, I didn’t encounter anything truly critical, it was mostly maintenance tasks and such.
For me what worked is a setup where I used an Arch linux laptop, ran f5vpn in docker and used the citrix client with some tweaks through that vpn connection.
It was a lot faster than my colleagues' Mac / Win client, and even better, it was automatable to start up and run everything.
Ha! I did document this beautiful setup: https://github.com/kmARC/f5vpn-in-docker
So I use a KVM Windows machine with Virtio drivers. QXL seems to be the best video solution.
Honestly, though, it’s better than the laptop the other firms have given me. One took over 10 minutes to boot, iirc. It wasn’t just the hardware, there was just so much … stuff, multiple layers of antivirus seemingly hooking all of the system calls and fighting with each other, and a document management system with blocking I/O everywhere that was somehow so embedded in Windows that it could seem to freeze the whole system.
The thin client setup may have latency, but at least it is convenient and it gets there eventually. Though I would swear it’s getting slower, or maybe my patience is waning.
I'd walk into customer sites for the first time, meet people, and within minutes they would start ranting about how bad Citrix is.
I suspect only dentists get this kind of feedback from customers before a procedure.
Having said that, 99% of the time the problem boils down to this:
The guy (and it is a guy) signing the cheques either doesn't use Citrix OR uses it from the head office with the 10 Gbps link.
The poor schmuck in the backwater rural branch office on a 512 Kbps link shared by two dozen staff gets no say in anything, especially not the WAN link capacity.
I've seen large distributed orgs that were 100% Citrix "ugprade" from 2 Mbps WAN links to 4 Mbps to "alleviate network congestion" in an era where 100 Mbps fibre-to-the-home is standard. With 2 Mbps you can watch PDF documents slooooowly draw across the screen, top-to-bottom, line by line. Reminds me of the 2400 baud days in the early 90s downloading the first digital porn, eagerly watching the pixels filling the screen.
Don't blame Citrix. Blame the bastard in the head office that doesn't give a f%@$ about anyone not him.
"
...for Massive Multiplayer Online Gaming (MMOG), real-time is a requirement.
As online gaming matures, players flock to games with more immersive and lifelike experiences. To satisfy this demand, developers now need to produce games with very realistic environments that have very strict data stream latency requirements:
"But this is real-time gaming. Typing should be less demanding, I'd think.
Edit: also https://stackoverflow.com/questions/536300/what-is-the-short...
Not really, unless you're the kind of guy working in Cobol and who is used to typing with latency.
I've seen Cobol developers just ignoring the latency, keeping typing because they know what they've typed and it doesn't matter that it's slow to show up on screen.
If the system works well, yeah, you can type all the stuff, then wait for it to show up and confirm. 'BBS mode' as someone mentioned.
I used to do that (not in COBOL), typing into a text editor in a terminal over a 2400-baud modem. Like the other commenter said, you get used to it, but it requires a certain predictability in your environment that you don't get in modern GUIs.
Anything below one frame (16.66ms) and whether or not any sort of real feedback is even received (let alone interpreted by the brain) becomes a probability density function. With each additional frame after that providing more and more kinesthetic friction until you become completely divorced from the feedback around 15-20 frames.
All of this means that the old figures are not useful as a rule of thumb unless your task is exactly what they studied. This paper notes how unhelpful that is with ranges from 2-100ms! They found thresholds around 25ms for some tasks but as low as 6ms for some tasks.
https://www.tactuallabs.com/papers/howMuchFasterIsFastEnough...
Keyboard latency is one of the harder ends of this spectrum: the users are focused, expecting a strong (high contrast, new signal) change in direct response to their action, and everything is highly trained to the point of being reflex.
When I’m typing text, I’m not waiting for the change to hit a key outside of games but rather expecting things like text to appear as expected or a cursor to move. Awhile back I tested this and the latency difference between VSC’s ~15ms key-to-character was noticeably smoother compared to 80+ms (Atom, Sublime) and the Citrix system I tested at 120-150ms (Notepad is like 15ms normally) was enough slower that it forced a different way of thinking about it (for me, that was “like a BBS” because I grew up in the 80s).
n.b. I’m not an expert in this but worked in a neuroscience lab for years supporting researchers who studied the visual system (including this specific issue) so I’m very confident that the overall message is “it’s complicated” even if I’m misremembering some of the details.
https://www.nngroup.com/articles/response-times-3-important-...
300ms would render most video games unplayable.
I see this claim a lot and it's making me want to build a website that gives you some common interactions (moving a mouse cursor, pressing a button) with adjustable latency so people can see just how big of an impact seemingly small amounts of lag have on how responsive something feels.
a) movies are not interactive so latency is not a concern, only fluidity is
b) movies come with pre-applied motion blurring to hide the low framerate (which is different from fake motion blur applied in some games)
c) 30 FPS is atrocious even for movies and I wish higher framerate movies had gotten more common
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.
Personally I can get latency down to 200ms over the internet into a remote datacenter with WebRTC. The challenge however in practice is that running a CPU without a GPU will eventually starve the CPU because it has to do intensive things like run a 1080p video at 60fps which aren't feasible on a CPU only machine. This CPU load will then slow down the video encoder and overall responsiveness (no, responsiveness doesn't mean a mobile layout here) of the remote desktop.
Your description is exactly why. Security people wedge themselves into the halls of power and then start making decisions that don't actually negatively affect them all that much.
I've literally seen a CISO that insisted everyone worked in a way they themselves did not.
The CISO didn't make the decision to enforce password rotation- the compliance programs your sales team asked for did
But I've seen so many companies that still insist on it.
I had a very brief talk with the IT team for the larger parent company when I started and explained this stupid password rotation thing, as I came from a security background, they wanted nothing of it. Set in their ways.
For the new non-profit that I'm helping spearhead, I'm not sure I'll get away from the password rotation entirely, but I can certainly set it to something more reasonable, like every 365 days, rather than every 60 days or whatever travesty most are dealing with. I'm pretty pleased about this.
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret
If they don't know better, it's not surprising other companies don't either.
It’s either that or they write them down. Because people are going to forget a password that changes every month, especially a password that has to comply with the complexity rules.
A good solution to discourage this would be to have heuristics that'd make sure that the new password isn't too similar to the old one, but doing that without having plaintext in there somewhere is pretty difficult.
Another solution would be mandating that all of the passwords should be randomly generated, but enforcing that would be difficult, because everyone who isn't used to having 99% of their new account information being in KeePass databases with randomly generated passwords, probably would find that too cumbersome to remain productive.
This seems like a people problem that makes being secure essentially impossible, due to how people use passwords (e.g. "I just use one password across X sites because remembering multiple ones is too difficult" or "I just add a number at the end of my current password").
And others also mentioned the productivity loss, for when people are slowed down by the need to change their passwords. You might easily rotate Let's Encrypt certificates thanks to automation but when it comes to people, things aren't so easy.
At that point, you might just stick with whatever passwords you have, do some dictionary checks in the future, maybe have infrequent password rotation and otherwise stack on more mechanisms, like TOTP through whatever application the user has available, or another means of 2FA, because relying just on passwords isn't feasible.
And it's the CISO job to resist unnecessary overcompliance which is just for the happiness of the sales team.
Given that, they're likely to give you what you are asking from them: a brick with no functionality which will do nothing. You can't do anything with Brick, but Brick has zero outstanding CVEs
My office at the time had dual T1's... a little over 3 megabits shared with roughly 500 people.
I don’t doubt Citrix has gotten worse as well but the job it had to do back then was much easier.
> The guy (and it is a guy) signing the cheques either doesn't use Citrix OR uses it from the head office with the 10 Gbps link.
If you were sure about this you could have as the consultant told this sentence or made this entire comment as your 'first page' of powerpoint/PDF (to make sure other hn-ers are happy!)
Our agency has another banking client that I hear sends you a laptop, I much rather have that.
[1] https://karabiner-elements.pqrs.org/
One thing I've learned about Citrix is that its a startup company with limited resources to handle all the bugs and crusty corpocrapware layers. The client craps on my HDR setup. It install a ton of crap you don't need and it relies on crap like HDX software running on your machine that last time I've checked it didn't had ARM binaries but this tech is also unavailable for the iOS clients. Meanwhile RDP can do semi-decent multimedia stuff without any of this crap.
https://en.m.wikipedia.org/wiki/Remote_Desktop_Protocol
Founded 1989, 2021 revenue over $3B
One of the lucky few I guess :-)
The technology behind remote desktops is fundamentally limited but I'm amazed at how good the user experience can be on a modern well-configured Citrix environment.
- The protocol responds well even on low bandwidth as long as latency is OK. On the office LAN it feels like a local computer.
- There is offloading for Teams[1], media streams[2] and even entire web browsers[3]. The tech behind this is impressive and it works pretty well (mostly!)
- For most staff it's easier to use a thin client or a minimal laptop.
- I can keep the Citrix environment patched and managed much more easily than a proliferation of laptops and home devices.
It can be a struggle at times and it's definitely not the right fit for developers. But it's got a lot of advantages and most of the time it works amazingly well.
[1] https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/m... [2] https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/m... [3] https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/m...
You really just adapt your way of interacting, and start planning more carefully every one of your actions instead of simply clickety-clacketing everywhere like if you were trying to win a game of Starcraft. It's practically subconscious and it really changes you.
I always think it must be much, much worse for blind people.
It also reminds me of people who complain that 5-minute build times "impair their productivity". How do you even work on _any_ mid-sized commercial codebase then ? It's not that uncommon for a build to take hours (e.g. games), and in engineering it is also not that uncommon for builds to take _days_ even on powerful server farms.
That's absolutely ludicrous that anyone would be expected to work that way.
More seriously, I'm reminded of something a friend always said.
You need to have a response time of 1/10 of a second or less for something to be interactive. I remember that but I wonder if the brain fixes it like it ignores your blind spot.
[1] https://www.youtube.com/watch?v=SNJiWPU4HEU
What kind of builds require more than one of the new MacBook Pro’s?
And what about using cloud development environments instead of a fully remote desktop? I haven’t properly tested GitHub Codespaces, but it seems to me that a lightweight laptop (ie cheapest MB Air, if Apple) with MDM plus codespaces can work really well.
Sure, not everyone is using these tools, but to state that devs in general need both a beefy workstation and a laptop sounds a bit outlandish to me.
VS Code for the development, SSH for the remote desktop, most of operations can be done via VSCode anyways. Chrome RDP is slow, I agree. I never use it anyways.
But I frequently use vscode+ssh+tmux on the desktop when working from home.
Then the powerful laptop just has to run chrome.. which to be fair, it barely does without crashing :)
- workstation model means working on a good (physical) desktop setup, large main monitor, eventual other(s) monitor(s), good keyboard, perhaps a thumb trackball instead of a mouse etc, oh, sure potentially the same can happen with a docked laptop but...
- ...laptop model means being able to move. If we WFH there aren't much reasons to move, well except when moving means relocate elsewhere. In practice MOST laptop users do not use their computers to be operational on the go but as a desktop replacer in suboptimal improvised setups, while those who need a good laptop can hardly find one.
The real issue came out in lack of knowledge from most about how remote works should be done. We have seen a big PR campaigns for more than a decades about nomadic workers who works on unstable and limited mobile network with PCMCIA/3G modems cards, then USB stick/HSPA stuff, portable hotspot, mobile tethering etc in a bar (so with potentially hostile and distracting surroundings) or on a beach (added to a potentially hostile climate/environment for mobile devices) and this model who push from "big notebook" to netbook to ultrabooks etc obviously fails miserably since it can't really work. We can work in such setup for a limited period of time for limited tasks but nothing more.
Now many start to admit that the solution is going back to the classic desk BUT this means every home need a room with a proper setup and so is an effort on both the worker and the company. A thing most reject.
Substantially: it's about time to tell things clear. The modern web is CRAP made to sell services instead of empower users through IT plus an admission that classic commercial desktop model is also CRAP. We damn need real desktops with document-based UIs, working locally and syncing just data that need to be synced. As we do as humans, anyone who do a certain job with a significant degree of independence in a single company.
To do so from remote we need a damn room per worker, well equipped, rented to the employer for a fair rate and establish clear contracts on that work paradigm.
Try to keep up the crappy surveillance capitalism business who can be translated in "rent someone else services, own nothing", in the trace of WEF/2030 https://youtu.be/Hx3DhoLFO4s famous video it's a very expensive absurdity. Try to keep up hybrid craps to avoid real capex is another absurdity.
Those who are eligible to work from home and want such paradigm should offer a proper room for that, companies should be clear "you are hired for remote works AND REMOTE ONLY, eventual travel to meed in persons must not happen more than once in a while" where the timeframe vary depending on the company and workers geographical distance.
Let's do that and we all benefit, companies and workers together in a win-win move those only loser will be GAFAM and friends (from Citrix to Bomgar). Avoid doing so and we will keep an inconsistent liquid situation that can be trivially called like the famous Full Metal Jacket Sg. Hartman definition on the most common amphibious thing so called ...
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 lost productiviry is in millions
Shadow offers remote desktop environment with GPU acceleration where you can run games and it feels responsive and decent.
The experience is extremely dependent on location, bandwidth, local setup and availability of close services (in my case, the closest DC was <15ms away according to Stadia telemetry).
0: https://shadow.tech
I couldn't see myself playing an FPS on it, but then I prefer kb/m anyways. But for the games I play on console? It was fine.
There can still be issues, of course, but the latency overall wasn't a deterrent.
My experience is that it’s definitely playable and beats a low power laptop with an underpowered video card. Latency in the 40ms range, and barely perceptible.
I work with Rust and TypeScript projects - MBP M1 Pro 32Gb RAM is 110% enough.
I know numerous gaming companies that swear by Parsec. Except the author doesn’t appear to be talking about Parsec tier cloud desktops. But then again it’s not clear what the author is talking about
Author seems to be stuck in the tech mindset of 5 years ago.
We went and just bought rolling stands instead. We thought about sneaking the Best Buy techs in but decided we liked our jobs too much to do that. When they found out we just bought stands instead of having the screens mounted they tried to throw a hissy fit but were unsuccessful (we didn't actually break any rules).
This same job required me to get an exemption from two unions because the devices I worked with communicated with RF energy (radio union) and I needed a screwdriver to get inside of them (IBEW). Sigh. It didn't matter than the wire techs down the hall from me didn't know JTAG from JPEG — I couldn't risk getting a grievance because someone thought I, a mere unrepresented member of "management" (as everyone who wasn't union-represented was called), was takin' their jerbs.
It was just too hard.
I never got to the stage they hint at, if a tiny amount of things won't work, does it means the whole idea fails?
If you only have Word/Excel/internet etc in one lab inevitably someone will ask for X,Y,Z. Is the money saved on computer and maintenance and benefits of instant installs/upgrades worth more or less than the property & teacher/student time costs of that lab running at 90% useability.
But licensing stopped the experiment.