Ts’o and Linus And The Impotent Rage Against systemd
Bringing some links buried in comments below to the top, I think these critiques of systemd’s integration and maintenance deserve some review.
First, kernel developer Theodore Ts’o, the developer of e2fsprogs and current maintainer of ext4, shares his reservations about systemd’s engineering, and the trouble he has had understanding and using it.
…a lot of the fear and uncertainty over systemd may not be so much about systemd, but the fear and loathing over radical changes that have been coming down the pike over the past few years, many of which have been not well documented, and worse, had some truly catastrophic design flaws that were extremely hard to fix.
He goes on to describe how he previously had to neuter policykit’s security (rendering his system very vulnerable) just to get his system working, and how he has found systemd “very difficult sometimes to figure out”. Should we be concerned that a kernel developer, obviously a very qualified computer user (an MIT graduate in his 40s), has trouble understanding and using policykit and systemd to configure his own system? Where does that leave the average Linux user in handling these atrociously complex and built-to-be-broken technologies?
…Kay Sievers and Lennart Poettering often have the same response style to criticisms as the GNOME developers [read other Red Hat developers] — go away, you’re clueless, we know better than you, and besides, we have commit privs and you don’t, so go away.
Predictably, fanboys rush to systemd’s defense in the comments, telling us how wonderfully documented and supported it is, what a quiet, fascist paradise the systemd mailing list is, and how responsive the developers are to every bug, request and patch submission.
Yet just two days ago, we see Linus Torvalds (the creator of Linux and maintainer of the Linux kernel), launching into a tirade against – yes, you guessed it – systemd developers because of their atrocious response to a bug in systemd that is crashing the kernel and preventing it from being debugged. Linus is so upset with systemd developer Kay Sievers (gee, where I have heard that name before – oh, that’s right, he’s the moron who refused to fix udev problems) that Linus is threatening to refuse any further contributions from this Red Hat developer, not just because of this bug, but because of a pattern of this behavior – a problem for Kay because Red Hat is also foaming at the mouth to have their kernel-based, no doubt bug- and security-flaw-ridden D-Bus implementation included in our kernels. Other developers were so peeved that they suggested simply triggering a kernel panic and halting the system when systemd is so much as detected in use.
So much for systemd developers’ responsiveness, and its great engineering, witless fanboys. (Are we really sure many of these fanboys aren’t part of an Infiltrate, Manipulate, Deceive, and Destroy program?)
While Ts’o’s discussion of systemd wanted to make me wretch for its usual polite, politically-correct crap, he did at least bring up some core problems in that typically watered-down way that mainstream developers express their opinions so as not to offend any fascists in their midst. Yet even Linus’s tirade, and the lengthy user discussion which followed it, completely miss what’s really happening to Linux. It seems these developers and users can’t rise up enough to get a 3D view – all they can do is focus on minute issues in isolation and fail to put the pieces together in any coherent way. Are they just afraid or feeling awkward to discuss it, or are they like other kernel developers I’ve heard from who are completely clueless about what Red Hat developers represent?
I’ll put it together for you once again. For those who missed it in my other articles, Red Hat is a billion-dollar corporation with deep ties to the US military (their largest customer), and thus inevitably the NSA (a military security organization), etc. Adding to the conflict of interest, they have as direct corporate partners Google, Apple, and other too-large-to-imagine corporations with their hands in slime. Red Hat developers dictatorially control the core engineering of Linux, including components such as udev, udisks, xorg, dbus, systemd, etc., used by every major Linux distribution, as well as other common desktop components such as GNOME and GTK. (As Ts’o put it, “we have commit privs and you don’t”.) These are simple facts, though curiously never discussed. In many developers’ views, these Red Hat developers have consistently introduced closed, overly complex, security-breaking technologies to Linux for years, and have a long and tired history of sabotaging kernel development, creating unending bugs and problems for kernel developers, which they often categorically refuse to address. Linus knows them well – or does he?
Yet the myth continues that Linux is somehow not surreptitiously developed as a product of the military-industrial complex, and that its core engineering is based on open and free contributions. Discussions like these ones above revolve around whatever the bugs of the day are, and completely fail to assess what appears to be deliberate and systemic damage done to the Linux ecosystem, primarily through Red Hat developers.
Wake up, morons – and that includes you Linus (who likes to call out morons as such himself). Start telling it like it is, and start addressing the real systemic problems in Linux’s engineering – namely that brown shirts like Kay Sievers and Lennart Poettering are just front men for a much uglier reality. Otherwise you’re just trying to sweep back the ocean with a broom – your actions are useless and doomed to fail. Getting angry won’t help – start getting smart, and start developing a genuinely free and open operating system, taking you-know-who out of the loop. If you can’t or won’t do that, then you may as well just surrender Linux to them entirely, which is pretty much the case already.
- Julian Assange: Debian Is Owned By The NSA
- Biography of a Cypherpunk, and How Cryptography Affects Your Life (second half details Red Hat’s involvement in Linux)