Linux is a dumpster fire — somebody call the fire department.
I was a somewhat early adopter of Linux. In my teens, when Microsoft abandoned DOS for Windows 95, I ordered some Slackware CD-ROMs, and didn’t look back. For about a decade, until Gnomification — a form of enshittification without an obvious financial incentive — made Linux unbearable; made it lose its unix roots. Until it became practically impossible to install almost any software without a middle man, the precursors of app stores: the Linux distributions. I learned their wickedness both as a user and as a developer.
And yet, despite everything, moving to open systems is no longer optional.
The dungheap
Fifteen years after I gave up on Linux, I tried again.
And I found the same dungheap I had left behind.
In all that time, Linux has not improved. Not at all. If anything, it seems flakier than ever. It makes me sad and angry.
On Linux, in 2026, whether closing your laptop lid suspends reliably still depends on a roulette of firmware, drivers, kernel versions, power-management daemons, and desktop environments.
Same with Bluetooth, where the problem is exacerbated by a complete lack of documentation and an over-eager configuration that steals all audio from my phone, when I just want to use the Bluetouch app as an emergency mouse.
I learned this last year, when I got an Orange Pi with Armbian as a media station, and when my — bought when the times were still good — Retina iMac at the campus died, and I tried to use the provided Thinkpad with Ubuntu. I gave up, and dumpster-dived for my old 2014 MacBook Pro that still works with an old Thunderbolt display that only comes with a proprietary connector. But neither Apple nor Homebrew provide updates for that machine.
I am no fan of Apple, and would much prefer using open source software, only. To have the right to fix. Windows 95 was awful, but the state of current operating systems makes Windows 95 pale in comparison. Even macOS is so bug-ridden these days that core subsystems like AirDrop frequently hang and demand a reboot. And yet, corporations are too big to care.
I consider myself adept with computers, but I cannot fix Linux. Many subsystems are completely undocumented — unless you consider source code and GitHub bug reports documentation. Every architecture seems to be changed every six months. But it also doesn’t “just work”. After almost 40 years, it is not yet “ready for the desktop”, as common complaints go.
But worse: it also forgot about the capable — if deprived of time — hobbyist.
I do not have the time to figure out the complexities. I am sure the unpaid among the authors (many do now get paid by corporations) do not have time to fix bugs and document. But that is why, exactly, the aim should be
SIMPLICITY.
If you want to give users the control; if you want to enable self-help; if you want to create an operating system that is hackable in practise and not just in theory; if you want to realise the right to fix; if you want to be better than Apple and Microsoft, you cannot have OSS → ALSA → PulseAudio → PipeWire chains, or — a much more appropriate word — dungheaps. You cannot have a complicated Bluetooth stack (a euphemism word for a dungheap), where it is unclear what is responsible for what.
Is simplicity incompatible with the distributed model of development? I do not think so. Rust gets many things right. Nix tries to fix some things. The good old unix approach of “everything is a file” was a beautifully simple abstraction that — one hopes — everyone could have agreed upon. The gnomifiers did not.
The gatekeeper
Another reason I left Linux was the abuse by distributions — by the predecessors of app stores. Not only as a user do you get years-old buggy versions of software, due to the very static nature of the distributions, but the distributions abuse developers. They modify the software, do not indicate it, and leave the upstream developers to deal with user complaints.
Users think they are reporting bugs in version X. In reality, they are often running a heavily patched hybrid of old code, new fixes, and downstream behavior that exists nowhere upstream.
After years of dealing with downstream bug reports caused by distribution-specific patches, I changed my software license. My position was simple: if you provide a “convenient installation method” for my software, you must either
(a) distribute the software unmodified, in its latest released version; or
(b) if you distribute a modified or obsolete version, rename it, remove any visible association with the original author, and explicitly assume responsibility for maintenance, bug reports, and user support.
A very simple ask — trivial to implement in the age of modern distributed version control systems like Mercurial, and one that any reasonable person should agree with. But, predictably, parts of the ideological open-source crowd treated this not as a question of accountability, but as heresy.
It made me lose any faith I had in the movement. Not in the principle — of which I remain a staunch supporter — but in the crowd.
Linux distributions may have begun as an engineering workaround to the way software is constructed from several pieces: a way to manage dependencies, and make installation tractable in a chaotic ecosystem. But over time they became something else: a layer of institutional control between authors and users. They freeze releases, patch behaviour, redefine support boundaries, and blur responsibility. Users think they are running the author’s latest version of the software, because they just upgraded their distribution. Often, they are not. In other words, they became parasites on the open source movement, just as app stores are parasites on society.
And they don’t even do the dependency management well. Innovative exceptions like Nix aside, their architecture is obsolete, monolithic. They do not allow installing a newer version of a specific piece of software, together with its required dependencies, while keeping the underlying system stable. Instead, users are forced into a false choice: either run years-old software, missing features and bug fixes, or upgrade the entire operating system to the latest release, with all the instability that often entails. Ubuntu tries to provide a middle-ground between Debian stable and unstable, but, in practice, unpopular packages are often old.
Recently, I tried to build my scientific codes that depended on FeniCS. The version in Ubuntu had such massive memory leaks, that it crashed my poor OrangePi in just a few minutes of computation. Now, FeniCS does provide its own up-to-date repository for Debian and Ubuntu, but such a repository is not available on other distributions, whose users are pointed to Conda — another disaster of an add-on packaging system that often conflicts with system packages despite its isolation attempts.
Because of fragmentation, because of the absence of real standards, it is practically impossible for authors to support every distribution. And every failure of standardisation gives more power to the abusive distributions — the app stores of open source.
Nix tries to fix the dependency mess through proper isolation, reproducibility, and explicit versioned references to dependencies. You can have one program depend on a different version of a library than another one. You do not have to upgrade the whole operating system to upgrade a single program — easily. But Nix has not really taken hold. Within the Rust ecosystem, I can also easily install author-provided software with its correctly versioned dependencies using Cargo — admittedly only for Rust software, and often as one large self-contained binary, but at least without a middleman.
Most other attempts to “fix” packaging — by shipping self-contained applications with all their dependencies — have remained niche. Why? Is it technical conservatism? Or is it power? Do the distributions simply not want to make themselves optional — to allow authors to distribute software directly, without gatekeepers?
It reminds me of the bus drivers in Quito: they appear to be the fiercest opponents of a functioning public transport system, each guarding their little fiefdoms, even opposing exclusive lanes for rapid-transit buses.
The barbecue
Open source is often described as collaborative. I fail to see where the collaboration is. Judging from the layer-cake of architectures, from the lack of standardisation, it feels more like a thousand lonely barbecues. Everyone grilling their own sausages in their own backyard, each convinced that their special artisanal recipe, their firewood, their homemade chimney, their custom tongs, are the future of cooking. And perhaps, locally, they are.
Globally, however, the result smells no different from a dumpster fire.
There is no shortage of talent in the Linux world. There is no shortage of effort, passion, or cleverness. What there is a shortage of is restraint. A shortage of standardisation. A shortage of developers willing to say: this already works well enough; let us maintain it, document it, simplify it, agree on it, and build on it. Let us remove the cruft. Let us empower the authors and users, and reduce the role of distributions to a minimum.
Instead, subsystems are rewritten, APIs are broken, abstractions pile on top of abstractions, and each new project arrives promising to finally fix the mess created by the previous one.
The tragedy is not that Linux lacks developers. The tragedy is that they do not see the forest from the firewood.
The right to fix
And yet, despite everything I have written, despite the dungheaps, the gatekeepers, and the lonely barbecues, moving to open systems is becoming more important than ever.
Only then can our information systems become resilient against the whims of authoritarian regimes and the increasing rent-seeking and spying of our techno-feudalist overlords.
Because computing is no longer just about convenience. It is about sovereignty.
When your operating system is controlled by Apple, Microsoft, Google, or whatever corporation; when that corporation — even if it had your best interests in mind — is subject to the laws and orders of an authoritarian regime, your machine is no longer fully yours. Features disappear. APIs are revoked. Hardware becomes obsolete by decree. Software stops receiving updates not because it cannot run, but because someone decided it should not. Telemetry becomes mandatory. Features become cloud-dependent. Remote attestation and kill-switch mechanisms creep in, always in the name of security, compliance, or convenience.
In an age of new borders being erected everywhere, in the age of increasing censorship, sanctions, platform control, surveillance, and political volatility, the right to inspect, modify, repair, and run your own software is no longer a hobbyist concern.
It is a civil liberty.
And that is exactly why the failures of Linux matter so much. Not because it is irrelevant — but because it is our best chance, and it is wasting it.
