linux — jolek78's blog

Reflections on an (impossible) escape from capitalism

Sun, 05 Apr 2026 15:46:47 +0000

It was an ordinary Friday evening. The parcel had arrived with the courier that morning, but I only opened it after dinner, with that silent ceremony I perform every time new hardware shows up – as if opening a box too quickly were a form of disrespect toward the object. Inside was a HUNSN 4K. Small, almost ridiculously small. A mini PC in a form factor that fit in the palm of a hand. I put it on the table, looked at it. Looked at it again. And then an uncomfortable thought occurred to me. I had ordered it from a Chinese reseller, paid with a credit card, through a completely traceable payment infrastructure, from one of the most centralised and surveilled commercial ecosystems in existence. To build a homelab that would let me escape centralised and surveilled ecosystems.

The funny thing – funny in the sense that it makes you laugh, but badly – is that I'm not alone. Every day, somewhere in the world, someone orders a mini PC, a Raspberry Pi, a managed Mikrotik switch, with the stated goal of taking back control of their digital life. They order it on Alibaba, pay with PayPal, wait for the courier. And they see nothing strange in any of this, because the contradiction is so structural it has become invisible. This article is an attempt to make it visible again. Without easy solutions, because I don't have any. And when have I ever…

The Promise of the Homelab

When, in 2019, I started self-hosting pretty much everything – Nextcloud (always on a Raspberry Pi, first RPi3 then RPi4), Jellyfin, Navidrome, FreshRSS, and about twenty-five other services on Proxmox LXC, each with its own isolated Docker daemon – I did it with a precise motivation: I wanted to know where my data lived, who could read it, and have the ability to switch it off myself if I ever felt like it. Not when a company decides to shut down a service, not when someone else changes the licence terms. Me. This came after a long period of reflection on myself, the work I was doing and still do, and the technological society I live in. It is an ideological choice before it is a technical one. Technology as a tool for autonomy rather than control; infrastructure as something you own instead of something that owns you. I hope no one is alarmed if I say that some of these reflections began with reading Theodore Kaczynski's Manifesto, before eventually landing, of course, on more authoritative sources.

Yes, I'm mad, but not quite that mad…

When you pay a subscription to a cloud service, the transaction does not end the moment you authorise the electronic payment. Shoshana Zuboff, in The Age of Surveillance Capitalism, calls this mechanism behavioral surplus: the behavioural data extracted beyond what is needed to provide the service, then resold as predictive raw material.

Under the regime of surveillance capitalism, however, the first text does not stand alone; it trails a shadow close behind. The first text, full of promise, actually functions as the supply operation for the second text: the shadow text. Everything that we contribute to the first text, no matter how trivial or fleeting, becomes a target for surplus extraction. That surplus fills the pages of the second text. This one is hidden from our view: “read only” for surveillance capitalists. In this text our experience is dragooned as raw material to be accumulated and analyzed as means to others' market ends. The shadow text is a burgeoning accumulation of behavioral surplus and its analyses, and it says more about us than we can know about ourselves. Worse still, it becomes increasingly difficult, and perhaps impossible, to refrain from contributing to the shadow text. It automatically feeds on our experience as we engage in the normal and necessary routines of social participation.

You are not the customer of the system – you are its product. Your habits, your schedules, your preferences, your hesitations before clicking on something: all of this is collected, modelled, sold. The transaction is not monthly: it is continuous, invisible, and never ends as long as you use the service. With hardware, in principle, the transaction is one-time: you buy, you pay, it ends, it is yours. The disk is in your room, not on a server subject to government requests, security breaches, or business decisions that are nothing to do with you but impact your access to those services. This distinction – between a tool you use and a system that uses you – is the real stake of the homelab. It is not about saving money, it is not about performance. It is about who controls what.

The problem is that building this infrastructure requires hardware, time, knowledge, and resources. The hardware comes from somewhere; the time, the knowledge, and the energy resources come from a privilege not granted to everyone.

The Market I Hadn't Seen

Search for “mini PC homelab” on any marketplace. What you find is a productive ecosystem that has exploded over the past five years in a way I honestly did not expect.

MINISFORUM, Beelink, Trigkey, Geekom, GMKtec. Zimaboard, with its single-board aesthetic designed explicitly for those who want home racks. Raspberry Pi and the galaxy of clones – Orange Pi, Rock Pi, Banana Pi. Managed Mikrotik switches at accessible prices. 1U rack cases to mount under the desk. M.2 NVMe SSDs with TBW figures calculated for small-server workloads. Silent power supplies designed to run 24/7. A market built from scratch, that exists precisely because there is a community of people who want to run servers at home. r/homelab and r/selfhosted on Reddit have approximately 2.8 and 1.7 million members respectively – numbers publicly verifiable, and growing. YouTube is full of dedicated channels. There is an entire attention economy built around “escaping” the attention economy.

But it is worth asking: who built this market, and why. MINISFORUM and Beelink do not exist out of ideological sympathy for the homelab movement. They exist because they identified a profitable segment and served it with industrial precision. Kate Crawford, in Atlas of AI, documents how technology supply chains follow niche demand with the same efficiency with which they follow mass demand: factories in Guangdong optimise production lines not for a worldview, but for a margin. The fact that the resulting product also satisfies an ideological need is, from the manufacturer's point of view, irrelevant.

The Victorian environmental disaster at the dawn of the global information society shows how the relations between technology and its materials, environments, and labor practices are interwoven. Just as Victorians precipitated ecological disaster for their early cables, so do contemporary mining and global supply chains further imperil the delicate ecological balance of our era.

The mechanism had been described with theoretical precision back in 1999 by Luc Boltanski and Ève Chiapello in The New Spirit of Capitalism. Their thesis: capitalism is never defeated by criticism – it is incorporated. When a critique becomes widespread enough, the system absorbs it and transforms it into a market segment. The artistic critique of the 1960s – autonomy, authenticity, rejection of standardisation – became the marketing of the creative economy. The critique of digital centralisation – sovereignty, privacy, control – has become an online catalogue to browse through.

Resistance has become a market segment. Every time someone buys a HUNSN to stop paying subscriptions to services they don't control, a factory in Guangdong sells a HUNSN. Capitalism has not been defeated – it has shifted (at least for a small slice of the population: the nerds, the hackers) the extraction point from subscriptions to hardware.

The Accumulation Syndrome

But there is a further level – more ridiculous and more personal – that homelab communities never discuss openly, yet anyone who has a homelab recognises immediately. The Raspberry Pi 4 bought “for a project.” The old ThinkPad kept because “you never know.” The 4TB disk salvaged from a decommissioned NAS – and “it might come in handy.” The second-hand switch picked up on eBay for eighteen euros because it was cheap and might be useful. The cables, the cables, the cables.

r/homelab has a term for this: just in case hardware. It is the hardware of the imaginary future, of projects that only exist in your head, of configurations that one day – one day – you will finally test. In the meantime it occupies a shelf, draws current in standby, and generates a diffuse sense of possibility that is indistinguishable from the most classic consumerism. The underlying psychological mechanism has a precise name: compensatory consumption – consumption as a response to a perceived loss of autonomy or control. You buy hardware because buying hardware gives you the feeling of recovering agency over something. The aesthetic is different from traditional consumerism – no luxury logos, no recognisable status symbols – but the mechanism is identical.

That said, there is a partially honest answer to all of this: the second-hand and refurbished market. The ThinkPad X230 on eBay, the Dell R720 server decommissioned from a datacentre, the disk from someone who upgraded their NAS. My ZFS NAS, to give one example, is a recycled old tower with four 1TB disks in RAIDZ – hardware that would otherwise have ended up in landfill, with a life cycle extended by years, without generating new production demand. It is closer to the ethics of repair than to compulsive buying. But it has its own internal contradiction: it requires even more technical competence than buying new – knowing how to assess wear, diagnose an unknown component, manage ten-year-old drivers. The barrier to entry rises further. And the refurbished market is itself now an organised commercial sector, with its own margins, its own platforms, its own pricing logic. It is not a clean way out. It is a less dirty way out.

And then there is the energy question, which is usually ignored in homelab discussions and is instead the most uncomfortable of all – uncomfortable enough to deserve a more in-depth treatment later on. For now, suffice it to say: every machine on your shelf that “draws current in standby” is a line item in the energy bill that the homelab movement rarely accounts for.

Not for Everyone. And It Should Not Be This Way.

There is a second level of the paradox that is even more uncomfortable than the first. Building a homelab costs money – relatively little, but it costs. It requires physical space. It requires a decent connection. And it requires time. A lot of time. Not installation time – that is measurable, finite. The learning time that precedes everything else. To reach the point where you can build a functional infrastructure with Proxmox, LXC containers, centralised authentication, reverse proxy, automated backups – you need to have already spent years understanding how Linux works, how to reason about networks and permissions, how to read a log. I started with a Red Hat in 1997, and it took me almost thirty years to get where I am. I should know this. Yet it always escapes me. And that time did not fall from the sky. It is time I was able to dedicate because I had a certain kind of job, a certain stability, a certain amount of mental energy left at the end of the day. It is middle-class-with-a-stable-position time, not the time of someone working three warehouse shifts a week. Passion is not enough.

Johan Söderberg documents this in Hacking Capitalism: the FOSS movement was born as resistance to capitalism, but reproduces within itself hierarchies of skill and merit that make it structurally exclusive. Freedom is technically available to anyone, but effective access requires resources distributed in anything but a democratic manner. Söderberg goes further than simply observing the exclusivity: the voluntary open source work produces use value – functioning software, documentation, community support – that capital then extracts as exchange value without remunerating those who produced it. Red Hat builds a billion-dollar company on a kernel written largely by volunteers. It is not just that not everyone can get in: it is that those who get in often work for someone without knowing it. The homelab inherits this problem and amplifies it.

The narrative of orthodox historical materialism corresponds with some very popular ideas in the computer underground. It is widely held that the infinite reproducibility of information made possible by computers (forces of production) has rendered intellectual property (relations of production, superstructure) obsolete. The storyline of post-industrial ideology is endorsed but with a different ending. Rather than culminating in global markets, technocracy and liberalism, as Daniel Bell and the futurists would have it; hackers are looking forward to a digital gift economy and high-tech anarchism. In a second turn of events, hackers have jumped on the distorted remains of Marxism presented in information-age literature, and, while missing out on the vocabulary, ended up promoting an upgraded Karl Kautsky-version of historical materialism.

This is not a quirk of the homelab movement: it is a recurring structure in every technological wave. Langdon Winner, in his influential essay Do Artifacts Have Politics?, argued that technological choices are never neutral – they incorporate power structures, distribute access in non-random ways. Amateur radio in the 1920s, the personal computer in the 1980s, the internet in the 1990s: every time the promise was democratising, every time the actual distribution followed the lines of pre-existing privilege. Not out of malice, but out of structure. The irony is this: those who would most need digital autonomy – those who cannot afford subscriptions, those who live under governments that surveil communications, those most exposed to data collection – are exactly those least likely to be able to build a homelab. Not for lack of interest or intelligence. For lack of time, money, and years of privileged exposure to technology.

Homelab communities do not usually talk about this. They talk about which mini PC to buy, how to optimise energy consumption, which distro to use as a base. The conversation about structural exclusivity exists, but at the margins – in Jacobin, in Logic Magazine, in EFF activism – while the centre of the discourse remains impermeable. It is not that no one speaks about it: it is that the peripheries speak about it, and the peripheries do not set the agenda. This entire conversation takes place in a room to which not everyone has a ticket. And those inside do not seem to find that particularly problematic.

A Technological Cosplay?

So is the whole thing a con? Is the homelab just anti-capitalist cosplay while you continue to fund the same supply chains? In part, yes.

The HUNSN 4K was designed in China, assembled in China, shipped by container on ships burning bunker fuel. Global maritime transport is responsible for approximately 2.5% of global CO₂ emissions – a share that the IMO (International Maritime Organization) has been trying to reduce for years with slow progress and targets continually postponed. Then: distributed through Alibaba, paid with a credit card. Every piece of technology hardware carries an extractive chain that begins in lithium mines in Bolivia and cobalt mines in the Democratic Republic of the Congo, passes through factories in Guangdong, and ends in electronic waste processing centres in Ghana. The hardware travels that supply chain exactly like any other consumer device. Furthermore, hardware has a lifecycle. In five years the HUNSN 4K will be too slow, or it will break, or something will come out with energy efficiency too much better to ignore. And I will buy again. The mini PC market for homelabs depends on the obsolescence of previous purchases – exactly like any other consumer market.

The critique of capitalism, when it is widespread enough, is not suppressed – it is incorporated. The system absorbs the values of resistance and transforms them into a market segment. Autonomy becomes a selling point. Decentralisation becomes a brand. The rebel who wanted to exit the system finds himself funding a new vertical of the same system, convinced he is making an ethical choice.

The Counter-Shot

But there is a structural difference that would be dishonest to ignore.

When you pay a subscription to a cloud service, the cost is not just the monthly fee. It is the continuous cession of data, behaviours, habits. It is the behavioral surplus Zuboff talks about: you are not using a service, you are being used as raw material to train models, build profiles, sell advertising. The transaction never ends, in ways you often cannot see and cannot escape from as long as you use the service.

With hardware, the transaction ends. The data stays on a physical disk in your room, not on a server subject to government requests, breaches, or business decisions that have nothing to do with you but impact your life. The software running on it – Proxmox, Debian, Nextcloud, Jellyfin – is open source; you can modify it. If something changes in a way you cannot accept, you can leave. This resilience has real value – but it is worth noting that it is asymmetric resilience: it works for those who have the skills to exercise it. For those who do not, the theoretical portability of their data from Nextcloud to something else requires exactly the same skills we have already identified as the barrier to entry. The freedom to leave is real. Access to that freedom, much less so.

And then there is the energy question, which I have deferred long enough. The major hyperscalers – AWS, Google, Azure – operate with a PUE (Power Usage Effectiveness) between 1.1 and 1.2. For every watt of useful computation they dissipate barely 0.1–0.2 watts in heat and infrastructure. They have enormous economies of scale, optimised industrial cooling, significant investments in renewable energy, and above all: their servers run at very high utilisation rates. Almost always busy.

A home homelab works in a radically different way. The machine runs 24/7 even when it is doing nothing – and for most of the time it is doing nothing. Navidrome serving three requests a day, FreshRSS fetching every hour, an LDAP container sitting listening without receiving connections. You are paying the energy cost of the infrastructure regardless of usage. The implicit PUE of a homelab, calculated honestly on the ratio between total consumption and actual workload, is much worse than that of a datacentre. IEA data (Data Centres and Data Transmission Networks, updated annually) shows that large cloud providers progressively improve energy efficiency thanks to economies of scale that no individual homelab can replicate. The flip side is that the same growth in demand that makes economies of scale possible negates the efficiency gains: Amazon's absolute emissions increased between 2023 and 2024 despite improved PUE. Efficiency improves. Total consumption grows anyway. This is Jevons' Paradox: energy efficiency, instead of reducing consumption, increases it, because it lowers the marginal cost of use and stimulates demand that grows faster than the efficiency gains.

Note: The comparison is not as linear as the numbers suggest. PUE measures the internal efficiency of a datacentre, not the energy cost of the network traffic that data generates every time it leaves it – traffic that a homelab eliminates almost completely for internal services. Nor does it measure proportion: AWS is efficient at delivering services to millions of users, but that scale says nothing about the real cost of storing fifty gigabytes of personal data on a server designed for loads a thousand times greater. A HUNSN N100 in idle consumes less than 8 watts. The honest energy comparison is not homelab vs hyperscaler in the abstract – it is homelab vs proportional share of hyperscaler for your specific workload, a calculation that nobody can make with publicly available data.

This does not automatically mean that the cloud is the ethically correct choice – the problem does not reduce to PUE, and surveillance has costs that are not measured in kilowatts. It means that anyone with SolarPunk values who chooses the homelab must reckon with a real contradiction: the choice of sovereignty may be, watt for watt, energetically more costly than the system one wants to escape. I have no clean answer, but ignoring the question would be dishonest. Söderberg acknowledges that the FOSS movement has produced concrete and undeniable gains – they simply are not enough, on their own, to subvert the dynamics of informational capitalism.

In short: this is not a critique of the homelab, but it is a critique of the homelab presented as a sufficient revolutionary act.

What Happens at Eleven PM – and Beyond

That night, with the HUNSN 4K on the table, I pressed on. I installed Proxmox. I configured the network. I started bringing up containers one by one. And at some point – three hours had passed, I had three terminals open and was debugging nslcd to centralise LDAP authentication across all the containers – I realised something: I was doing all of this simply because I enjoyed it. Not to resist something. Not to advance an ideological agenda. Because there was a problem to solve and solving it gave me satisfaction. Mihaly Csikszentmihalyi describes this state in Flow as total absorption in a task calibrated to one's own competencies: time expands, attention narrows, awareness of context vanishes. It is not motivation – it is something more immediate. Debugging an authentication problem at eleven at night on a system I could have chosen not to build is, neuropsychologically, indistinguishable from pleasure. Not the satisfaction of having finished: the process itself. Moreover, for an AuDHD person like me, going into hyperfocus allows you to lose your sense of time entirely, and to literally escape from a world you viscerally loathe.

Ah – you had not figured that out yet?

When I had finished and closed everything, the satisfaction was still there. Along with a mildly uncomfortable awareness: I could probably have used a hosted service, lived just as well, and not lost three hours of a weeknight. But in the meantime I had understood how PAM worked, I had read documentation I had never opened before, I had implemented it on my homelab, I had learned something I hadn't known I wanted to know.

And here the circle closes in a somewhat unsettling way. Söderberg speaks of voluntary open source work as the production of pure use value – the intrinsic pleasure of doing, understanding, building something that works. But it is exactly this use value that capital then extracts as exchange value: the competence I accumulate debugging LDAP at eleven at night is the same competence I bring to work the next day, that I put into articles like this one, that I share in communities where others use it to build their own homelabs. Technical pleasure is not neutral. It has a production chain. Not always visible, but real.

This is what the homelab is, at least for me: a way of learning that produces, as a side effect, an infrastructure I control. The ideology is there, but it comes second. First comes the pleasure of understanding how something works. Or rather: ideology and pleasure are interchangeable, and often run in parallel – but this does not resolve any of the contradictions I described above. It leaves them all standing, in fact makes them stranger. Am I resisting capitalism, or am I just cultivating an expensive hobby with a political aesthetic?

The Hacker Ethic

The word “hacker” has had bad press for decades. In 1990s news bulletins it was a synonym for a hooded cybercriminal; in the jargon of security companies it became a marketing term to prepend to anything. Neither has much to do with what the word historically means. Steven Levy, in Hackers: Heroes of the Computer Revolution, reconstructs the culture that formed around the MIT and Stanford labs in the 1960s: a community of programmers for whom code was an aesthetic object, access to information a moral principle, and technical competence the only legitimate hierarchy. The principles Levy identifies as the “hacker ethic” are precise: access to computers – and to anything that can teach you how the world works – should be unlimited and total. All information should be free. Decentralised systems are preferable to centralised ones. Hackers should be judged by what they produce, not by titles, age, race, or position. You can create art and beauty with a computer.

It is not a political manifesto in the traditional sense. It is something more visceral – a disposition toward the world, a way of standing before a system you do not yet understand: the correct response is to take it apart, understand how it works, and put it back together better than before.

Pekka Himanen, in The Hacker Ethic and the Spirit of the Information Age – with a preface by Linus Torvalds and an epilogue by Manuel Castells, which already says something about the project's ambition – performs a more explicit theoretical operation. He builds the hacker ethic in direct opposition to the Protestant work ethic described by Max Weber: where Weber saw work as duty, discipline as virtue, and leisure as absence of production, Himanen identifies in the hacker a figure who works out of passion, considers play an integral part of work, and rejects the sharp separation between productive time and free time. The hacker does not work for money – money is a side effect, when it comes. They work because the problem is interesting. Because the elegant solution has value in itself. Because understanding how something works is, in and of itself, sufficient.

Hacker activity is also joyful. It often has its roots in playful explorations. Torvalds has described, in messages on the Net, how Linux began to expand from small experiments with the computer he had just acquired. In the same messages, he has explained his motivation for developing Linux by simply stating that “it was/is fun working on it.” Tim Berners-Lee, the man behind the Web, also describes how this creation began with experiments in linking what he called “play programs.” Wozniak relates how many characteristics of the Apple computer “came from a game, and the fun features that were built in were only to do one pet project, which was to program … [a game called] Breakout and show it off at the club.”

Recognise something? I do. Those three hours debugging nslcd at eleven at night were not work in the Weberian sense – nobody was paying me, nobody had asked me to do it, there was no corporate objective to reach. They were hacking in the precise sense that Levy and Himanen describe: exploration motivated by curiosity, with the infrastructure as an object of study as much as of utility. The homelab is, culturally, a direct expression of the hacker ethic. It is no coincidence that homelab communities and open source communities overlap almost perfectly, that they use the same language, the same platforms, the same values. But here, as elsewhere in this article, the story gets complicated.

The hacker ethic promises a pure meritocracy: you are judged by what you can do, not by who you are. It is an attractive idea. It is also, in practice, a partial fiction. Technical meritocracy presupposes that everyone starts from the same point – that skills are accessible to anyone who really wants to acquire them, that the time to acquire them is distributed equally, that mentorship networks and learning resources are available regardless of context. The homelab as hacker practice inherits both things: the genuine nature of curiosity as a driver, and structural exclusivity as an undeclared side effect. The pleasure of taking a system apart to understand how it works is real and should not be devalued. But that pleasure is available, in practice, to those who already have the ticket.

Conclusions

The HUNSN 4K runs, alongside the other “little electronic contraptions,” on a rack next to my armchair – the one where, at the end of the day, I indulge my guilty pleasure of reading a book in the company of my cats. Proxmox, the Nextcloud server, the ZFS NAS, a small MINISFORUM box running Ollama with some local open-weight LLM models, a Raspberry Pi 5 running the Tor Relay, and a HUNSN RJ15 with pfSense controlling incoming and outgoing traffic. An infrastructure, in short, that allows me to have something resembling digital sovereignty within the limits of the possible. The contradictions I have described do not resolve. They are held together, with effort, as any intellectually complex position on a complex system must be held together.

The first: the market that made the accessible homelab possible is the same market the homelab is supposed to emancipate us from. If this explosion of affordable, efficient mini PCs had not happened – if capitalism had not decided to build exactly what we wanted – how many of us would have taken the same path? How much of our “ethical choice” depends on the existence of products designed and sold precisely for us?

The second: does incorporated resistance truly lose its force, or does it remain resistance even when someone profits from it? Boltanski and Chiapello describe the incorporation mechanism, but do not argue that critique loses all effectiveness in the process. Perhaps the homelab is simultaneously a product of the system and a real, if partial, form of withdrawal from it. The two things are not mutually exclusive.

The third: if digital autonomy requires decades of accumulated skills, enough free time to use them, and enough money to buy the hardware, are we building a democratic alternative? Or are we building an exclusive club with a rebel aesthetic, reproducing the same hierarchies of privilege it claims to want to fight?

The fourth: the energy question has no clean answer, and Jevons' Paradox makes it even more uncomfortable – because it works in both directions. The cloud improves efficiency and increases total consumption. A homelab consumes proportionally more, but does not fuel the demand that drives that total consumption upwards. Are we building digital sovereignty, or are we simply choosing where to position ourselves within a contradiction that cannot be resolved at the individual level?

I don't know. But at least I know where my data is.

Fun Fact

This article was written in Markdown using a Flatnotes instance running as a CT container on Proxmox, while listening to a symphonic metal playlist served by Navidrome – another CT container – pulling OGG files from a ZFS NAS over an NFS share. The cited books were in EPUB format on Calibre Web. In the background, Nextcloud on a Raspberry Pi 4 was syncing and backing up everything. Spelling mistakes were corrected by Qwen2.5, an LLM model served by Ollama on the MINISFORUM box, accessible locally via oterm and Open WebUI. And all of this, controlled from a laptop running Linux.

Coincidences? I don't think so.

Discuss...

#Homelab #SelfHosted #SurveillanceCapitalism #Privacy #OpenSource #HackerEthic #SolarPunk #DigitalSovereignty #FOSS #Linux

· 🦣 Mastodon · 📸 Pixelfed · 📬 Email · · ☕ Support this work on Liberapay

Legacy systems: problem or resource?

Wed, 28 Jan 2026 16:30:00 +0000

Tuesday morning, 9 AM. After a routine patching session, a long-standing ZFS storage system running Solaris 11 suddenly stops talking to its Windows 10 clients. The culprit is the usual, maddening SMB dialect dance: Windows pushes for SMB 3 on security grounds, while Solaris's native service struggles through the negotiation. Two days of banging my head against the wall – hard – and then the discovery: OpenCSW. A community that maintains updated packages for Solaris where the vendor long since threw in the towel. Updated libraries, sorted dependencies, problem solved. There are volunteers out there patching critical systems better than the official vendor ever did. Worth knowing.

Same film, next scene.

Friday afternoon – because critical migrations always happen out of hours. I'm migrating a system from Red Hat 7 to Red Hat 9. Why? To support the new version of Charon-SSP, the Stromasys emulator that lets SPARC hardware run on x86. All of this to keep alive a virtual machine running Solaris 9, an operating system from 2002 that went end-of-life in 2014. It's a layered structure, each level propping up the one below. One of those classic houses of cards you can't quite understand how it stays balanced.

Welcome to the world of legacy systems. A world where “modernising” often means finding increasingly creative ways to change nothing at all, and where communities and old-school sysadmins are the ones guarding infrastructure that corporations abandoned long ago. Try asking Oracle for Solaris support: they'll laugh in your face.

The numbers

In January 2025, the UK government published a report that should have rattled a few chairs at Westminster. Twenty-eight percent of central government IT systems are classified as legacy – up from 26% in 2023. Estimated productivity losses? Forty-five billion pounds. In 2024, the NHS recorded 123 critical IT system crashes. One hundred and twenty-three.

But wait, because the numbers get even more interesting when you look at the banking sector. COBOL – a programming language dating back to 1959 – still processes 95% of global ATM transactions, 43% of the world's banking systems, and around 3 trillion dollars of commerce every day. Every day. It's estimated there are still 220 billion lines of COBOL code in production.

And Windows XP? The one Microsoft stopped supporting in 2014? Today, 1-2% of internet-connected devices still run it. Sounds small until you realise we're talking about millions of machines. And not your grandad's PC: we're talking about MRI scanners in hospitals, industrial control systems, bank ATMs. Critical devices that can't be updated because the software controlling them only runs on XP, and re-certifying the entire system would cost more than building a new one.

Remember WannaCry in 2017? The ransomware that paralysed 75,000 computers in 99 countries? The NHS was devastated. And do you know how many Windows XP machines the NHS had in 2019 – two years after the attack, five years after end-of-support? 2,300.

At this point in the story one might say “right, the problem is clear: legacy systems are dangerous and need replacing.” And that would be the easy narrative – the one that consultants selling “digital transformation” love, and vendors wanting to sell licences love. What if I told you that a Solaris 11 system, properly isolated in a VLAN, is significantly more stable and secure than a shiny new Ubuntu 24.04 LTS?

Reality, as always, is more complicated.

Problems upon problems

Here's the fundamental issue: we use the word “legacy” as if it meant one thing, when it actually covers at least three completely different situations.

Type 1: Unavoidable legacy Solaris 9 on SPARC hardware controlling industrial machinery. Windows XP on MRI scanners. Systems where hardware and software are inseparable, where an upgrade would require replacing equipment worth millions, where re-certification for medical or industrial use would take years and fortunes. These systems are legacy out of necessity, not negligence. There's no fault here. There's only the reality of a technological ecosystem where certain devices have 20-30 year lifespans and the software controlling them can't be changed without changing everything else.

Type 2: Avoidable legacy CentOS 7, for instance. End of support: 30 June 2024. Available alternatives: AlmaLinux, Rocky Linux, migration to RHEL. Cost of migration? Economically: it depends. In time, resources, learning: enormous. How many CentOS 7 systems are still in production today? Too many. Why? Because nobody wants to pay RHEL licences, because “we'll do it next quarter,” because “there are other important things to deal with,” because “if it ain't broke, don't fix it.” This is legacy by choice – or rather, by inertia. It's an organisational decision, not a technical one.

Type 3: Non-legacy perceived as legacy Take COBOL on modern IBM mainframes. Today's mainframes aren't the ones from the 1970s – they're immensely powerful machines, with dedicated processors, hardware security, 99.999% uptime. The COBOL running on them is the same as ever, but the underlying infrastructure is current. Is the code legacy, or the platform? And if the platform is modern, can we still call it legacy? The distinction is fundamental because it determines the strategy. A Type 1 system needs to be isolated and protected. A Type 2 system needs to be migrated. A Type 3 system needs to be left alone. Try explaining that to a CTO who just finished reading a Gartner report on “legacy modernisation.”

From a thread on TheLayoff:

“FWIW, there's a very good chance that your electronic footprint on any given day has passed through a piece of SPARC equipment running Solaris, and that will continue to happen for a good portion of your lifetime.”

Would you believe me if I told you I've seen original BSD systems with eleven years of uptime?

The real problem isn't the machines

Here we get to the heart of the matter. And the answer will surprise you: the real problem with legacy systems isn't technological. It's human.

Let's talk about the “COBOL Cowboys” – retired programmers called back on consulting contracts when something breaks. They're the last generation that knows how those systems actually work. When they leave, they take decades of undocumented knowledge with them. According to Deloitte, companies have seen a 23% decline in mainframe workforce over the last five years, with 63% of those positions left unfilled. It's not that there's no money to hire – it's that there's nobody to hire. Young developers don't want to learn COBOL. It's “unsexy.” It's “archaic.” It's “boomer stuff.”

From ComputerWeekly:

“The retirement of the generation of experts who possess in-depth knowledge of Cobol systems is leading to a severe knowledge shortage. They have knowledge not only of the Cobol programming language, but also of the specific systems they have worked on and built over the years” – Tijs van der Storm, CWI/University of Groningen

And so we find ourselves in a paradoxical situation: systems processing trillions of dollars a day, managed by people who might die of old age before anyone learns to replace them. Knowledge transfer never happened. Documentation – where it exists – is outdated, incomplete, written in a language nobody understands anymore. And every year that passes, the gap widens.

This is the real legacy problem. Not the systems. The people.

When modernisation fails (spoiler: often)

There's a story that people in the UK know well, but that strangely never comes up when “digital transformation” is being discussed. It's called the National Programme for IT, or NPfIT.

Launched in 2002, it was the largest public sector IT project in British history. The goal? Modernise the entire NHS IT infrastructure. Initial budget: 6 billion pounds. Planned completion: 2010.

In 2011, after nine years of delays, exploding costs, vendors abandoning the project, and a system that simply didn't work, the UK government announced the dismantling of NPfIT. Final estimated cost: over 10 billion pounds. For a system that was never completed.

What went wrong? Practically everything. Top-down decisions made by politicians who didn't understand technology. Rigid contracts with vendors who didn't understand the NHS. Resistance from medical staff who hadn't been consulted. Continuously shifting requirements. Impossible integrations with existing systems.

From TechMonitor:

“A lack of digital and procurement capability within government has led to wasted expenditure and lack of progress on major digital transformation programmes.”

The lesson? “Modernising” is not automatically better than “maintaining.” Sometimes, the legacy system that works is preferable to the modern system that never will. But this lesson, apparently, we haven't learned. Because the dominant narrative remains the same: legacy = bad, modern = good. And consultants keep selling the shiny new thing.

Strategies that actually work

TL;DR: There is no single solution. There's a matrix of options ranging from virtualisation to isolation, from refactoring to API wrapping. The choice depends on the type of legacy, the budget, and the acceptable level of risk.

The Gartner 7Rs (yes, they have a name for everything):

Retire – Switch it off. Only works if nobody's actually using it.
Retain – Keep it as is. Sometimes the best choice.
Relocate – Move it to new infrastructure without changes.
Rehost – “Lift and shift” to cloud. Changes the hardware, not the software.
Replatform – Minimal changes to run on a modern platform.
Refactor – Rewrite parts of the code while maintaining functionality.
Rearchitect – Completely redesign. The riskiest and most expensive.

Virtualisation and emulation For systems on proprietary architectures (SPARC, VAX, Alpha, PA-RISC), solutions like Stromasys Charon emulate the original hardware on x86-64 platforms. The operating system and software don't change – only the iron underneath does. For legacy x86 systems (Windows XP, Server 2003, old Linux), standard virtualisation (Proxmox, VMware, KVM) allows you to “freeze” the environment and keep it running indefinitely. I've seen Proxmox setups running Windows 3.11. I'm not joking.

Network isolation If a system can't be patched, it can at least be isolated. Dedicated VLANs, restrictive firewalls, air-gap where possible. It doesn't fix the problem, but it limits the impact in case of compromise.

API wrapping Put a modern REST layer in front of a legacy system. The mainframe keeps doing what it knows how to do; the outside world talks to the API. This is the strategy many banks use to expose COBOL functionality to mobile applications.

The public sector: a special case

Those who work in the public sector know that the dynamics differ from the private sector in ways that make the legacy problem even more complex.

Multi-year budgets. You can't decide in January to modernise a system and have the money by March. Funding cycles are long, rigid, subject to political priorities that change with every election.

Procurement. Buying software in the public sector is a bureaucratic nightmare. Tenders, compliance requirements, impact assessments, GDPR, accessibility. A purchase that takes a week in the private sector takes months here.

Compliance. Systems handling health, education, or tax data are subject to stringent regulatory requirements. You can't simply “migrate to the cloud” – you have to demonstrate that the cloud complies with an endless list of standards.

Service continuity (which in my view is the core problem). If a private company's system goes down for a day, they lose money. If a system managing national exams, or medical prescriptions, or pension payments goes down, the consequences fall on real people with no alternatives. The risk of downtime during a migration is often simply unacceptable.

And then there's the political dimension. Every government wants to announce its own “digital revolution.” Nobody wants to inherit the previous government's problems. And so projects get started, abandoned, restarted, re-abandoned, in an endless cycle of waste.

NPfIT wasn't an exception. It was the rule.

The uncomfortable question

At this point, the question nobody wants to ask is this: what if some legacy systems were simply… better? Not better in an absolute sense, but better for their specific purpose?

Let me tell you something. I worked for years in environments dealing with large-scale Oracle infrastructure – the company that sells “cloud transformation” and “modern infrastructure” to half the world. And among other things, you know what got managed day to day? Old ZFS storage. Stuff that, on paper, should have been “modernised” years ago. Those machines had been running since before Docker existed, before Kubernetes, before “cloud native” became a term. And they worked. Quietly. Without drama. Nobody was in any hurry to replace them. Why would they be? In pursuit of what advantage, exactly?

The COBOL processing bank transactions has been optimised for sixty years. Every bug has been found and fixed. Every edge case has been handled. Every possible scenario has been tested in production billions of times. It's code that has achieved a kind of perfection through Darwinian evolution. Rewriting it in Python would mean starting from scratch. New bugs. New untested scenarios. Years of instability before reaching the same level of reliability.

And in the meantime? In the meantime, the legacy system keeps working. There's a reason banks aren't in a rush to abandon mainframes. It's not ignorance. It's not laziness. It's that they've done the maths and understood that the risk of the new outweighs the cost of the old. And the old administrators have retired. But this is an uncomfortable truth. It doesn't sell well in PowerPoint presentations. It doesn't generate consulting contracts. It doesn't make tech headlines.

And so we keep talking about “modernisation” as if it were automatically a good thing. As if “new” meant “better.” As if technology had a moral direction.

So what?

Legacy doesn't mean old – it means abandoned. The problem is never technical – it's always organisational. And “modernising” is not automatically better than “maintaining.”

If there's one lesson, it's this: be suspicious of anyone with simple answers to complex problems.

Every time I hear some manager say “we need to automate everything with AI,” I think about the software pachyderms holding up half of critical infrastructure. I think about the time it would take to train a model on COBOL written in 1987 with no documentation. I think about how long it would take to migrate a Java 1.7 system running on Solaris 9. I think about the hours spent reverse-engineering platforms still running Lotus Notes. I think about the costs. I think about the risks. And then I think that those same managers don't have the budget to hire juniors willing – and why should they be, when the IT world is moving in a completely different direction – to learn systems that have been decommissioned for at least thirty years. And I laugh. Bitterly, but I laugh. Then I take a few drops of CBD to calm myself down.

Before talking about artificial intelligence – and those who know me know I'm not against AI at all – perhaps we should make sure that human intelligence doesn't retire, taking years of undocumented knowledge with it. But that, evidently, is a less sexy priority to put on the slides.