Linux: The Myth and the Reality

Added: 2026-05-19

[00:00:00]The recent Linux kernel security flaws have given me a lot to think about. Not just the bugs themselves, but the ecosystem around them. As I often say, our world is populated by people who on average are more technical and more competent than the general population.

[00:00:16]And yet somehow it manages to produce collective thinking that often falls well below that same average. This is the fruit of a deep mythologization, a politicization, an ideological mass projection that has turned Linux into a legend, an urban myth. Linux is always secure. Linux is always stable. Linux is always better for development and so on with all the lesser mantras. Now, I love this ecosystem. Linux is my life. I have genuinely dedicated my existence to it.

[00:00:47]And I think I can fairly call myself one of its evangelists. And precisely because I love it, I try to look at it with realistic eyes anchored to reality rather than fantasy in a broad scenario, not through a lens that distorts everything into a flattering shape.

[00:01:02]If we want to be serious about this, we shouldn't even be calling it Linux. We should be calling it Ginu Linux. And honestly, we should be talking about it in the plural because what we have is more of an ecosystem of systems than a single system.

[00:01:17]But if we narrow our focus to the kernel itself, the gap between what Linux is perceived to be and what Linux actually is becomes enormous. Linux is a great big stew. Or rather, forgive me, it's a great big fruit salad.

[00:01:32]It's a community project, a kernel of 40 million lines of code conducted by Torvalds like a furious orchestra director trying to coordinate a multitude of contributors.

[00:01:43]a director who on more than one occasion has openly displayed his impatience with badly written code and has paid the price for it to the point of having to take a sbatical to learn how to communicate. I find this absurd. And do you know why? Because all of us always need labels and scapegoats. It's our nature to simplify in order to reach some kind of truth. Because deep down, and forgive me for getting philosophical, our deepest fear, the most intimate one, is admitting doubt, admitting the unknown, Linux really is a great big fruit salad.

[00:02:17]And serving a fruit salad with the same ingredients for breakfast, lunch, and dinner on three different continents is not at all easy. Linux's debts are many, and they are structural. I've always said this, and I'm not jumping on any bandwagon. the PZIX calls, the BSD code grafted here and there, the standardization choices that have produced anything but elegant changes.

[00:02:39]I'm thinking especially of the networking interfaces, but there are countless other examples. So, no, this perfect kernel is not perfect at all.

[00:02:48]And do you know what its real strength is? Exactly this. the fact that the code is open, exposed to public scrutiny, criticizable and examinable by anyone, and that this puts it at the center of constant improvement. And let me repeat one thing. At its core, this is a community project whose magnitude we today do not perceive in its full scope, but I am certain that in the future it will be remembered as one of the great works of humanity of an entire civilization. So yes, Linux at the end of the day does not have a merely technical or technological importance.

[00:03:24]It has cultural, political and philosophical importance too. I believe these are the pyramids, the coliseum, the cyine chapel of our time. But others in the future will be the ones to verify this. Now you might be wondering what all this philosophizing has to do with an episode of source code. Well, it has everything to do with it because in response to the recent serious security flaws, intrinsic, I'd argue, to the monolithic kernel design, and to how Linux structures its permissions, a proposal has been put forward. It was promoted by Sasha Levan, whom we had already met thanks to Autoscell, the AI maintainer of the Linux kernel, and appeared in a recent post on the colonel mailing list. The proposal introduces a kill switch, a short circuit, a big red shutdown button that would immediately mitigate the exposure of certain functions, the ones affected by issues like copy fail or dirty frag by simply disabling them. Now, I am not a highle programmer. I have never touched the Linux kernel source, but allow me to weigh in. At first glance, this whole thing struck me as more of a piece of propaganda than a real solution.

[00:04:34]So, if the solution is broken, I just kill it instantly.

[00:04:39]It looked to me like nothing more than a band-aid, and a costly one at that. And this kind of problem is only going to become more relevant in the months ahead, not in some distant future.

[00:04:50]Linux's structural limits are coming to the surface. And yes, at a certain point in a moment of madness, I asked myself, why doesn't anyone inside the Linux kernel project just sit down and decide to flip the whole barn over from top to bottom? A real Copernican revolution.

[00:05:06]And here I have to stop because if I want to be honest with you and with myself, my first reaction was probably itself a product of the very same mental shortcut I criticize in others. And so was frankly the longing for a Copernican revolution.

[00:05:22]Let me explain. Sasha Leven's proposal is not about killing the solution. Levan is not saying that the kill switch fixes the code or replaces the patch. He's proposing a temporary mitigation mechanism to cover the exposure window that opens between the moment a vulnerability becomes public, perhaps with a proof of concept already in circulation and the moment the patch is actually distributed and deployed across fleets of millions of machines around the world. Between the disclosure of copy fail on April 29th and the full roll out of the patch across all distributions, hours pass, sometimes days. In that window, fleets remain exposed to an exploit with publicly available code. In this sense, the kill switch is an airbag, not an airbag instead of breaks. An airbag in addition to brakes. And the uncomfortable truth is this. Levven's proposal is paradoxically the explicit and honest acknowledgement that the wait for the patch and reboot model is no longer sustainable at modern industrial scale.

[00:06:24]It's an act of realistic lucidity not ideology. The truly ideological patch, the real piece of propaganda, would be denying the problem, repeating the mantra, Linux is secure by design, and continuing to pretend that 20 badly written lines in a cryptographic subsystem are an isolated incident and not a structural symptom.

[00:06:45]That said, the fact that the kill switch makes sense as an operational tool does not mean my underlying unease was wrong.

[00:06:53]It just shifts.

[00:06:55]There are serious critiques of this proposal and they are not the ones I had instinctively formulated. There are others and they're more subtle. First, if a privileged administrator can disable a kernel function at runtime, an attacker who has already escalated privileges can use the same mechanism to disable security functions. We are adding attack surface. Second, a CIS admin under pressure at 3 in the morning during an emergency who disables the wrong function in production can cause damage worse than the vulnerability itself. Third, and this is the most leopard-like of all, we are giving CIS admins the tools to amputate a limb in production. And in doing so, we are shifting the problem from the kernel to the CIS admin instead of addressing it at the root. Here's the truth I find painful to admit. The kill switch makes sense and it's an intelligent move in the short term, but it is also deeply a symptom. It's the symptom of a 40 million line kernel that can no longer afford Copernican revolutions because it now holds up basically the entire technological world and is funded by the very tech companies that want the status quo. The same Linux that declares userland sacred, untouchable, a totem.

[00:08:09]Change everything so that nothing changes. And here a great novel comes knocking again at the door. A small detour between us. For those of you who love reading, The Leopard is a novel that has earned enormous international success. And if you haven't read it yet, please do. I recommend it from the heart. It's one of those books that stays with you for years and that comes back to your mind at the most unexpected moments like in this case while writing about the Linux kernel. change everything so that nothing changes. The Sicilian nobility of the mid-9th century, too aware of itself to actually change and too busy changing to be lucid enough to enact the structural reforms that would let them truly evolve.

[00:08:54]And here I need to walk back my other gut reaction, the more impulsive one.

[00:08:59]Why don't they just flip the whole barn over?

[00:09:02]It's a nice rhetorical question, but then I have to honestly ask myself, who pays the bill? From scratch rewrites have a terrifying failure rate in software history. Netscape 6, Pearl 6, serious alternative kernels exist.

[00:09:17]Fuchia, CL4, Redux, none of them has reached critical mass. New Herd hasn't reached critical mass yet either, nor even a minimal maturity for widespread adoption. But as I've said in previous episodes, the very experience of Linux could help GU herd evolve in a way that doesn't repeat the same mistakes. And that is an enormous advantage. Not because Linux is better in any absolute sense, but because the ecosystem around Linux, the drivers, the tool chains, the AIS, the 30 years of accumulated knowledge is the real asset. And rebuilding that asset costs as much as building it the first time, but without the competitive advantage of having arrived first.

[00:09:57]So perhaps the most honest reading I can offer is this. Linux is not the leopard because it's too conservative to reform itself. Linux is the leopard because it has won. And winners historically do not revolutionize themselves.

[00:10:13]Structural reforms, if they ever come, will come from the outside. Many people, and I am not one of them, see Rust in the Colonel as a small Capernac revolution already in motion, and one that is provoking furious resistance from the historical maintainers.

[00:10:28]I see Rust in the Colonel as yet another patch job, another improvised contraption that will be added to all the others, or to stay with my metaphor, another piece of fruit thrown into the fruit salad served globally.

[00:10:42]The reality I arrive at unfortunately has a logical conclusion. The Linux kernel as it is will tend more and more to standardize itself, to consolidate itself, to sediment itself with all its enormous qualities, but also with all its profound structural weaknesses.

[00:10:59]to expect Torvalds and his maintainers to sit down one random morning and decide to flip the barn over while that barn runs 90% of the internet, AWS, Android, Chrome OS, the Steam Deck, and probably my mother's connected refrigerator. That's asking the Sicilian nobility to abolish itself.

[00:11:17]Historically, it doesn't happen. What we'll witness instead is more patches, more pieces of fruit layered one on top of the other. If I look at it with a strict eye of classical Unix, very little will remain. But on the other hand, we're talking about a mastadon, a miracle of our times that beyond its lack of technical elegance and beyond its structural deficits, remains an open project, more or less independent or at least forkable, on which rest the hopes of digital and technological freedom of humanity. I am not spitting on it, but I look at it for what it is, rather than dressing it up as a lemon of the Amalfi or Sicilian coast to stay with the spirit of the leopard. It's a fruit salad. And fruit, you know, is healthy, rich in vitamins, good for you, much better to eat every day than junk food.

[00:12:07]Better a good fruit salad than a hamburger.

[00:12:10]And so, here we are at the end. This will surely be the year of Linux. We've been saying that for 25 years, and we laugh so we don't cry.

[00:12:19]But the truth, the one our community struggles to accept precisely because of that mythologization I started with is that the year of Linux has already happened many times. We just called it Android. We called it AWS. We called it Chrome OS. We called it Steam Deck. And nobody noticed because we kept waiting for it to land on Grandma's desktop with Gnome. With all the icons in the right place, Linux has won. And precisely for that reason, it can no longer afford to be the revolutionary, uncomfortable, ungovernable thing it once was. It has become infrastructure. It has become a political economic compact between the big companies that fund it. And in a certain sense, it's also a prisoner of its own success. The kill switch, in the end, is nothing more than this, the acknowledgment that the winner must learn to survive the weight of his own victory.

[00:13:12]It's not pretty to admit. It's not romantic. It's not the Capernac revolution we wanted, but it's honest.

[00:13:19]And perhaps in a world that loves myths more than truth, honesty is already in itself a small revolutionary act. Now that you've sat through this long philosophical preamble, and truly thank you if you made it this far without ripping off your headphones, let's move to the actual news of source code. This week, there isn't much, but what there is is significant.

[00:13:41]In fact, I'd say it's significant precisely because the stories seem disconnected from the reflection I just made, and instead, as often happens, they speak exactly the same language.

[00:13:51]They are the leopard, still strolling through the living room, just in a different outfit.

[00:13:56]Let's begin with Fedora and a story that genuinely deserves the word convoluted.

[00:14:02]The Fedora Council, the top level governance body that decides Fedora's strategic direction and approves major initiatives, had on the table a very interesting proposal, the Fedora AI developer desktop initiative. It was submitted by Gordon Mesmer, a longtime project contributor. And the goal was to strengthen Fedora as a platform for AI development by improving developer tools, packaging, Nvidia support, and community engagement. A proposal which by the way had obvious strategic sense.

[00:14:33]Fedora has always been the pioneer distribution, the testing ground of Red Hat, the place where ideas are tried out before they migrate into RE. And in a historical moment when AI AI is devouring every sector of technology, positioning yourself as the DRO for AI development was not a stupid move. On May 6th, the council voted. The recorded result was plus 6 minus 0 with final approval expected after the lazy consensus window closed on May 8th.

[00:15:00]Unanimous approval 6 to0 ball at the center of the field and then no. Because here is where the leopard part of the story begins. In the days following the vote, two council members changed their minds. The first was Justin W. Flory, who switched his vote to Maya 1, citing broader concerns than he had initially anticipated. Colonel strategy, the need to involve Fedora's colonel experts, and crucially unresolved technical and legal questions about Nvidia support. The second was Miro Hanach who also switched to ME1 explicitly citing community feedback received after the initial vote. Feedback which in his own words made him fear that the Fedora community was not in favor of this initiative as it stood. The result the ticket is blocked. The initiative is pulled from the Fedora Linux 44 milestone and pushed to flock 2026. That is delayed by months. translated into plain English, they walked it back. Now, an important clarification.

[00:16:02]The fundamental disagreement isn't whether Fedora should support AI development, but how far Fedora should go in building a dedicated AI focused platform.

[00:16:12]The distinction matters.

[00:16:14]Nobody is saying AI doesn't interest us.

[00:16:16]What they're saying is, do we commit to changing kernel policy, Nvidia enablement, outofree drivers, CUDA components, and the long-term maintenance burden of all that or not?

[00:16:26]And here, watch carefully. The earlier theme returns because what is Fedora doing right now? It's doing exactly what Linux as a whole cannot manage to do.

[00:16:36]It's stopping, listening to the community, and saying, "Wait, before we throw ourselves into a new strategic theme, let's think this through." It's a small act of lucidity in a sector where everyone is chasing AI like children chasing a ball. But, and there's always a butt, it's also again a textbook manifestation of the leopard structure of the open source world. The truth is that there are two possible readings of this story and neither is entirely wrong. The first more reassuring reading, Fedora demonstrates that it has a functioning governance capable of walking back its own decisions when the community pushes back. lovely, romantic, true. The second, more uncomfortable reading. Fedora, faced with the possibility of taking a clear position on one of the most important themes of the decade, got bogged down on policy, Nvidia, proprietary drivers, and long-term maintenance responsibility.

[00:17:31]All legitimate concerns to be clear, but also all concerns that if applied consistently to every decision would mean we'd never have shipped a single binary firmware blob in any kernel ever.

[00:17:43]Never packaged Chrome, never supported Steam. In other words, selective rigor.

[00:17:48]And in the open source world, selective rigor usually means ideology. I confess I am divided. On one hand, I applaud the fact that there is still a place where the community can change a unanimous council's mind. On the other, I wonder if we're not witnessing yet another case where the inability to make a decision gets sold as democratic wisdom. The difference between prudence and paralysis is often just a question of labeling. And while we're on the topic, let me say something about the anti-AI lism that runs through a part of the community. I would tear my clothes off in horror at seeing AI integrated into Void Linux. Honestly, it would be like serving sushi at Grandma's Sunday lunch.

[00:18:31]It just doesn't fit. But if there really must be a Linux distribution with integrated AI, I can't think of a better incubator than Red Hat. After all, they gave us systemd. And forgive my pessimism. Sooner or later, they'll give us integrated AI as default, too.

[00:18:49]And speaking of system D, I have to ask, where were the councils, the communities, the feedback rounds, and all those wonderful mechanisms of democratic prudence when it was decided to integrate that obscene monstrosity into practically every Linux distribution?

[00:19:04]Were they all taking remedial classes from Microsoft?

[00:19:08]Forgive the pmic, but sometimes coherence is a rare commodity in our ecosystem. And now to the second story, which I find even more amusing because it's the perfect demonstration that the leopard doesn't only live in our house, he also takes walks on the other side of the fence in the BSD house. Feronx reports that FreeBSD152 will aim to introduce an option to install the KDE desktop directly from the textbased OS installer. Lovely, right? Simple, convenient, civilized.

[00:19:39]Other Linux distributions have had this for 20 years, but fine, better late than never. Except, and here's the punchline, this thing was supposed to be in FreeBSD 15.0.

[00:19:51]Then it was postponed to FreeBSD 15.1.

[00:19:54]Then it didn't materialize there either.

[00:19:56]Now the KDE desktop install option has been redirected to FreeBSD 15.2, which according to forecasts should be released in December. Official reason for the slip. The script still needs to be updated because new Nvidia drivers have been released and some parts have become obsolete and need to be removed.

[00:20:15]And of course, a testing period will be required before the functionality can be merged into stable. Now, I love FreeBSD.

[00:20:23]I'm saying this sincerely because otherwise the critique would sound mean.

[00:20:28]FreeBSD is a masterpiece of engineering.

[00:20:31]It's probably the only open-source operating system that can claim an architectural coherence. Linux can only dream of. It's living proof that you can make a beautiful system without the GPL.

[00:20:42]But tell me yourselves if it isn't surreal that in 2026 we're still talking about adding a KDE option to the FreeBSD installer as if it were an initiative requiring three release cycles to complete. And here once again the same pattern. FreeBSD wants to relaunch itself on the desktop. It's a noble intention. It's a sacred intention. It's an intention many of us would welcome with enthusiasm. But when you look at the timelines, the obstacles, the reasons for the delays, Nvidia drivers, testing, merging into stable, you realize the problem isn't technical. The problem is that even something apparently trivial like let's add an option to the installer becomes in a deeply conservative BSD ecosystem with long release cycles a coordination effort between the laptop project the driver maintainers the stable team and the release roadmap.

[00:21:35]And so you see same music they want to change. They say they want to change.

[00:21:40]They plan to change. But change when it arrives arrives three releases later with an asterisk and with the promise that if all goes well, we'll have it by December. The difference between Linux and FreeBSD is one of scale, not nature.

[00:21:54]Linux has 40 million lines of code and holds up the world. FreeBSD has a few million less and holds up specific niches, but the pattern is the same.

[00:22:04]Mature open- source institutions don't revolutionize themselves. They adapt slowly, painfully, with approval cycles that would make a Soviet bureaucracy jealous. And with that, I really am closing this long episode.

[00:22:18]Let me just say one last thing, a brief general response to some of the comments I've been getting on my recent invective against systemd. First of all, it's not an invective and it's not hatred. It's awareness and it's reflection. I used system D for over a decade. I don't anymore. I've explained my reasoning in unequivocal terms and I believe that as a communicator it's my job to share with you my ideas, my values and the things I believe in.

[00:22:46]For me, system D is something to be fought and uprooted. It structurally compromises our systems, making them weaker from the standpoint of technological independence and infrastructural quality. That is not a small thing. In short, they're all selling you their subscriptions, their newsletters, their requests for comments, their dodgy VPNs, and their hot air. Let me follow my own line of thought. I have the right to do it on my own channel. If it bothers you, don't follow me. But then again, whoever asked you to. See you in the next episode. And as always, may Linux be with