It’s probably hard to believe but when I started my career as a programmer in the early 1980s there were no networks, no hard disks and no laptops. Everything was done on standalone personal computers like Apple II and later IBM PCs. The only way to get code in or out was by typing it in, or loading it from a floppy disk. Networking didn’t come along until a decade later.
What about thin clients?
The idea of thin clients has been pushed forward at least on two different occasions, mainly as a way for employers to save money. Instead of developers needing powerful PCs with TBs of storage and 32 GB or more of RAM, the idea is to use a dumb terminal and edit/compile applications on a server. You don’t need to worry about backing up and builds can be automatically triggered and then tested when you commit code. What’s not to like?
Well, I for one wasn’t too keen on the idea. About 10 years ago I was invited to try one but it quickly turned out there were a couple of snags: I was in the United Kingdom and the server was in New York and I logged onto the server; it wasn’t web based. This meant that keys had an 80 ms lag across the Atlantic and that was a bit irritating. That wasn’t the killer though; I was trying to do low-level desktop development using Windows COM and the people managing the server would not let me have local admin access to the server. When you’re registering COM servers, local admin access is vital so that ended the trial.
From an employer’s point-of-view a thin client is great. It also increases security. But most of the developers I know like to keep their own backups. Sadly, even work-from-home laptops have become little islands with USB ports often digitally sealed off. This is fine until it’s time to move to a new laptop and you spend hours or days copying everything up to a server then copying it down again! On my home network I was able to get 130 MB/second copying from my old PC to my new one over Gigabit ethernet. With 2.3 TB to copy that should have taken just a few hours but Windows slows right down to a few KB/second with small files and it took four days to copy everything.
Why I’ve avoided developing for the cloud
As a game server developer, the thought of using cloud services has crossed my mind but having read a few scare stories, it put me off. The last thing anyone wants is to wake up to a bill of tens of thousands of dollars because a process ran amok or a hacker found a secret and ran up a bill.
This isn’t a theoretical worry; it has happened and that’s only the ones that have gone public. I think the worst one was an exposed API key that led to $450,000 charges incurred by people using Google’s translation services. When I set up a server, I‘ll be using a VPS. For more examples of scary bill stories read this reddit thread.
The looming threat – OS Age verification
A considerable number of iPhone/iPad owners in the UK were bitten by the iOS 26.4 update in April 2026 that introduced age verification without a warning, especially for those without a credit card or driving licence. Those people were unable to access some websites or use particular apps, such as banking apps, until they had verified their ages. My wife has put off upgrading hers.
While many places are introducing age verification for access to websites, in the US, some states and other countries (UK, Australia) are now pushing for age restrictions to apply when setting up or using Windows, Mac OS or Linux. If the OS creators don’t add this feature, they can get hit by large fines.
I think this is a very bad policy; we’ve had PCs in homes for almost 40 years and under 16s have used them to learn programming. I think many parents will provide their credentials which renders it kind of pointless.
Of these OS, it’s Linux which has no creators to fine apart from the commercial developers such as Debian or Ubuntu. Several states including California have backtracked on the requirement for Linux.
That said, there are currently 16 distributions that have said they will not implement age verification (by which they mean adding a date field in). You can see this list on developer Bryan Lunduke’s GitHub, which also includes a list of those that said they will implement it or are still discussing it.
One way to head this off is to buy cheap SoC systems like Raspberry Pis, download a non-age-verification distro and burn it to SD cards. So long as the distro’s maintainers never change their minds, you can use it with no worries that an update will sneak it in. Either that, or just don’t update it.
I’ll stick with my computers for as long as I can and if an update comes along for Windows, I’ll wait and see what it adds before installing it. I really struggle to see how this will achieve very much. It’s hard not to see age verification as anything other than a backdoor attempt to bring in universal digital ID
