Conspiratorial Thinking in the Linux Community

tty0 login: novatorine
login date: 2024-05-07

"Not unlike Stalin's defense of the need for a vanguard party"

The first example of this sort of conspiratorial, strangely warped mindset is probably going to be my best example, because it's the closest thing to a steel-man of the perspective of a systemd-hater as I can find: the author of "systemd, 10 years later: a historical and technical retrospective" is at least attempting to be objective, thorough, directly use (and link to, and extensively quote) primary sources, and rational. Moreover, it walks you through the whole developing history of systemd in an orderly fashion to give you the full picture of why people hate it, which is rare for such internet controversies. The parts of it that merely document the facts of what happened and quote or link to the relevant primary sources are an invaluable work of lay history.

However, then there's the author's own commentary and analysis.

That's a whole different story.

There are three main flaws with the author's analysis, the entire way through. Every factual recounting of the actual events of the history, and every quote directly from a primary source, is followed by commentary that either:

  1. uses all kinds of unjustified loaded language,
  2. conspiratorially ascribes nefarious motives to people that just really don't make sense when much simpler and more normal motives or explanations are easy to think of, or
  3. analyzes and/or summarizes the events in ways that just directly contradict the events themselves, as recounted by the author, or even contradict themselves, in such a way as to make it clear that the author's impression of events is totally detached from the actual events.

I'm not going to go through the entire gigantic essay line by line pointing out every instance of manipulative rhetoric I find, because this stupidity is simply not worth my time in the first place and still less that much of my time, but I will give a few examples of each. I highly encourage you to go read the essay in full before reading my points though, because many of them will make a lot more sense, and hit far harder, once you have their full context and complete impression of everyting the essay says. Also because, again, despite the terrible analysis tacked on, it's a pretty damn good work of lay history.

Now. Let's begin, shall we?

Examples of unjustified loaded language

Among the damages caused by fragmentation, according to Bernard, are downstream maintainers “adding a permanent dock, icons on the desktop, re-enabling the systray” to the DE. Presumably such irresponsibility may lead to future horrors, like people actually reading source code.

Oh yes, not wanting distro maintainers to basically add really annoying clutterware to your DE that fundamentally misses the entire point of your de's design is the same thing as not wanting users to be empowered to look at the source code and modify your DE how they want.

The most unambiguous statement of the unificationist perspective, however, comes from GNOME developer Emmanuele Bassi:

If desktop environments are the result of a push towards centralisation, and comprehensive, integrated functionality exposed to the people using, but not necessarily contributing to them, splitting off modules into their own repositories, using their own release schedules, their own idiosynchrasies in build systems, options, coding styles, and contribution policies, ought to run counter to that centralising effort. The decentralisation creates strife between projects, and between maintainers; it creates modularisation and API barriers; it generates dependencies, which in turn engender the possiblity of conflict, and barriers to not just contribution, but to distribution and upgrade. [my ellipses here bc the quote is very long] So, if “being about choice” is on the one end of the spectrum, what’s at the other? Maybe a corporate-like structure, with a project driven by the vision of a handful of individuals, and implemented by everyone else who subscribes to that vision—or, at least, that gets paid to implement it.

And if we are to take the “revolution OS” metaphor further, then Bassi’s position is not unlike Stalin’s defense of the need of a vanguard party in The Foundations of Leninism (1924), with those opposed consequently in the role of Trotskyites, Zinovievites and ultra-leftists ... One can no more dissuade a visionary of this kind than one can dissuade a member of the Fabian Society from the virtues of global humanitarian government, but then neither will the vox populi of provincial yokels be of any use in countering it. One can only stoically resign to the pull of inexorable necessity. ...

I simply can't believe we're here this fast. What the author seems to be saying here is that GNOME's idea --- "let's come up with a vision of the Linux desktop as a well-integrated, unified, streamline, well designed thing, and offer it to people as a way of having a unified Linux experience, and everyone who likes it and agrees with us can come join us in using it and working on it" --- with Stalin saying the whole Revolution must be subject to a Vanguard party, as if coming up with a cool vision and asking everyone who likes it to come work with you and use your thing, is the same thing as trying to force out all other options and take over everything. It's absurd, and yet this author simply jumps to the conclusion that GNOME wants to completely eliminate any competitors and completely "take over" the Linux desktop, when that's really not what they mean by "unified" at all, I don't think. They want to unify the Linux desktop by coming up with a Linux desktop environment instead of services that are already unified, not by trying to destroy everything else that exists. You can have an island of unification and stability and stuff inside of the bazaar.

Make note of this absurdity, however. This hyberbole around the very idea of having standardized components on the Linux desktop (nevermind that Linux has standardized on a great many other things before) will lead to a whole string of attempts on the author's part to prove that, get this, any attempt at standardization or making integrated sub-ecosystems within the larger Linux ecosystem is tantamount to colonialist empire building. Yeah, you heard me right.

Examples of conspiratorially assigning motives to people that just don't make sense and aren't necessary

By far the major aspect of systemd’s design which Lennart routinely hyped in the early stages, was that systemd is not a dependency-based init despite being commonly understood as such. (As recently as October 2019, systemd developer Michal Sekletar was presenting it as a “dependency based execution engine.”) Instead, the use of socket activation was meant to obviate explicit dependency information entirely ... This is something that needs to be reiterated throughout, as it reflects a certain vision that systemd had which was never quite fulfilled and subsequently minimized. [...many paragraphs about why this isn't a practical goal and how the systemd people slowly realized that and lowered their ambitions...] The systemd developers largely demoted the primacy of this vision after 2015 or so once they secured their ubiquity, and once the commercial interests behind containerization shifted the focus away to stateless systems, immutable image-based deployments and others.

The author here makes it sound like the initial vision was some kind of disingenuous lie or something that they used to gain power and popularity, and not them just growing more familiar with the problem space and realizing, for all of the reasons that you literally just stated, that it wasn't really feasible or a good idea, and letting the scope of the project shift towards something more immediately useful for the people who needed it. It seems like if they didn't compromise the scope the author would accuse them of being too unrealistic and uncompromising, and if they did compromise it, the author would accuse them, as they just did, of being liars and cheats.

Part of this is that systemd as an upstream still operates as a node in a bazaar acting without direct regard for specific Linux vendor interests, with the inevitable antagonisms that follow from this, no matter how much they may have tried to overcome this and cornered the bazaar into being a vertically integrated megacorp reaping the benefits of scale economies.

Besides that one offhand word that the GNOME person used as an analogy in a previous quote, where is this guy's evidence that the people that want to come up with standard operating system components for Linux wants to do it because they want to somehow turn Linux into a "megacorporation" and not for the million other reasons that is a good idea? How would this even support that, exactly, when it's all still free and open source? Not to mention if this criticism applies to things like system d, then you could Levy it against even something like the gnu core utils or glibc, since they two are basically universal standards in Linux with a few tiny exceptions and people like that because of the compatibility and shared effort it offers.

The same person, in a January 2014 back-and-forth with Upstart developer Steve Langasek, then dropped all pretense of logind being a separable component from systemd

"Dropped all pretense" assigns nefarous motive --- the need to dissemble for some reason --- where none was necessary, because nobody was lying, as the author themselves stated:

At the time, the systemd Interface Portability and Stability Chart listed logind as not independently reimplementable. [And they never say it changed]

Yes, the GNOME developers pointed out that GNOME would work with something other than logind if that thing implemented the features it needs (which OpenRC does) but that's a totally different thing that the author seems to conflate to make this whole issue look more disingenuous.

In the position of Debian or any other community distro, the situation in 2013-4 was major desktop environments depending on logind for power management, which in turn meant depending on systemd due to the single-writer constraint for cgroups, which also hosted the userspace and service activation layer for kdbus (which also encompassed hotplug with udev), over which daemon writers would have registered interfaces. This was the seemingly inexorable direction, and hence the decision was sealed before it was deliberated... Except, of course, this didn’t happen. kdbus became the kdbuswreck after meeting obstacles by kernel maintainers such as Andy Lutomirski and Eric W. Biederman, much to the chagrin of hopeful Desktop Linux buffs all over. Subsequent endeavors like BUS1 did not succeed, either. The cgroupv2 API did gain subtree delegation with systemd exposing it as well, though many other redesigns in anticipation of the single-writer changes were left intact. ... Regardless, these developments served their propaganda value, and by 2015 systemd had decisively secured its place.

The author acts as if software having dependencies on other software when the features of the two overlap and can really enhance each other is some kind of brand-new, unconsciounable occurrence or secret plot. Absurd.

Neither is it necessary to ascribe nefarious motives and secret plots, as "served their propaganda value" implies anyway: maybe this was just a genuine set of perhaps slightly unfortunate technical decisions made in anticipation of a technical thing that didn't work out, which happens all the fucking time on Linux, and not a fucking disingenuous propaganda campaign designed to grab power for some mysterious and unknown reason?

Once the thumotic energy for conquest is spent out, a protracted period of mediocrity ensues. Yet the ideological imperative of “making progress” and “pushing things forward” remains, and with it new directions and justifications must be found to maintain the illusion for the developers and their followers.

And here we get to the fun part. The author is really applying a Marxist analysis of colonialist empire to a fucking init system? Are you kidding me? The through line of this throughout the whole essay is the constant reiteration that the people behind GNOME and systemd want to provide a unified and integrated Linux desktop. This is a point that is reiterated ad nauseum with quote after quote after quote:

In September 2010, he explicitly pledged cross-distro unification as a goal: "Well, it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there’s really no point at all in doing so..."

He expressed ‘cross-distro collaboration’ as an important goal of his: “IMHO, a nice goal would be to increase cross-distro collaboration. How well are the different major distributions represented in your contributor base? I think a strong point of systemd is that they have active contributors from pretty much all major distros (including gentoo and arch, but possibly with the exception of ubuntu, I’m not sure).”)

Josselin Mouette, then a GNOME packager for Debian, wrote his statement in October 2013: "Systemd is becoming a de facto standard in Linux distributions (at least Fedora, SuSE and Arch), and is getting excellent upstream support in many packages. So far, only Gentoo uses OpenRC (and it doesn’t have most of the features I’d like to have), and only Ubuntu uses Upstart. Therefore using OpenRC would mean maintaining many patches on our own, and using Upstart would mean that our upstream would become Ubuntu..."

That cross-distro unification had been a goal since 2010 was documented above. In Poettering’s January 2011 LCA presentation “Beyond init,” systemd is described as a “system and session manager for Linux,” but at the same time already a “basic OS building block” and for “cross-distribution standardization.” The future tasks listed at that time were fairly modest: session management and automatic initrd fallback.

The most unambiguous statement of the unificationist perspective, however, comes from GNOME developer Emmanuele Bassi: [this is the quote from above]

Why do they spend so much time on this? Because it is critical to the author's conspiracy theory that all and only corporate Linux users --- who they think use it for the cloud and service as a software substitute and don't care at all about Linux as a cause for liberating people's desktops and providing a free as in freedom OS, but only care about its use to corporations on servers and profit margins --- are pushing all the changes in Linux that he personally doesn't like. Here's how they introduce this false dichotomy in the introduction:

The complaints over Linux’s fragmented nature as an anarchic bazaar of individual white-box components stitched together into distributions, and various perennial attempts at coming to a “resolution” of this innate issue – are nearly as old as the first distributions themselves. ... he major cultural cleavage in the Linux “community” boils down to two things: its entanglement with the history of GNU and the free software movement, and its image as the “revolution OS” – a product of free culture worked on by hobbyists and volunteers towards the end of emancipation from shrink-wrapped software vendors and pointy-haired bosses, or the snooping cloud service provider as the more modern equivalent would be.

Consequently, the professional Linux plumber and the plebeian hobbyist occupy two different worlds. The people who work at the vanguard of Desktop Linux and DevOps middleware as paid employees have no common ground with the subculture of people who use suckless software, build musl-based distros from scratch and espouse the values of minimalism and self-sufficiency. For many in the latter camp who came to Linux from the message of free software, their eventual realization that real-world Linux development is increasingly dominated by the business interests of large-scale cloud providers as represented in the platinum memberships of the Linux Foundation, is almost analogous to the disillusionment of a communist true believer upon witnessing Comrade Trotsky brutally punish the sailors of the Kronstadt rebellion. The iron law of oligarchy still reigns as usual irrespective of the pretense toward progress and equality.

Despite the age of the homesteading hobbyist making a substantial difference long being over, the image still persists. The communitarian ethos of free software can never be fully wiped from the DNA of GNU/Linux, but it can be increasingly relegated to an irrelevant curiosity. The likes of Richard Stallman, GNU and the FSF are seen more and more as an embarrassment to be overcome in favor of a more “professional” and “inclusive” scene, which will in all likelihood mean professionally showing the user their place as a data entry within the panopticon, not a free and independent yeoman as the admittedly utopian pipe dream envisioned.

And here's how they tie it up in a neat little bow in the finale of that section:

The professionals are doomed in all their vainglory to be perpetually embarking on the Sisyphean task of a unified and integrated Linux ecosystem, even if it means turning the kernel into a runtime for the BPF virtual machine, or making a Rube Goldberg machine of build and deployment pipelines, as appears to be the most recent trend. The hobbyists are doomed to shout in the void with no one to hear them. In this tragedy the only victor is chaos and discord itself, which disguises itself as “progress.” All that is guaranteed is permanent revolution through constant reinvention, where by revolution we mean running around in circles. The suits and ties have forgotten what it was to be Yippies, and for their part the Yippies are fools who are had by ideas, rather than having ideas.

The author acts as if the goal of these attempts at standardization and sharing work between different communities are all really underpinned by a desire to just control everyone so that, as a seen in the earlier quote, Linux can somehow be turned into some kind of profitable thing for them, but I just don't think this is true. There are good motives for wanting to provide something like systemd or GNOME other than that.

Trying to cobble things together out of various separate tiny programs that each solve a tenth or hundredth of the actual problem, none of which are fully compatible or fully give you all the tools you need to solve the problem, or integrate well, is really annoying and leads to a fragile desktop where a lot of really nice features like hot plugging support or session support in your desktop environment and so on can't actually be implemented because you don't have sufficient integration between stuff, and it leads to a ton of complexity and unreliability because you have this rat's nest of random components that you scripted and hacked together with duct tape and bailing wire.

Another good motivation could be that providing software components that an operating system needs, like an init system, that can be a popular standard across multiple Linux distros so everyone can share the effort developing and bug testing it and things can be generally more compatible so less duplicated effort exists, is actually extremely helpful to achieve the goal of becoming a practical alternative to other OSs. It's a massive positive improvement for the people taking part in the bazaar to be able to all pitch their labor into making a common thing that helps all of them, instead of duplicating their effort in competing with each other. I would expect a Marxist to know this concept: it's a commons. Having shared standards that we all pitch in to help each other with is not necessarily an empire, it's a community commons that we all take part in helping improve because it benefits us all, and that we keep unified because being able to share the work of others who also benefit from improving it is great! This is the principle on which a lot of other Linux software is built --- I hate to keep hammering this point home, but the author acts as if systemd is the first time the Linux desktop has standardized on a single "thing" for some component of their operating system, as if before then there were no standards that everyone generally agreed upon (with a few exceptions) and every single distro just did a totally different thing. But that's just ahistorical. There's a very clear double standard here.

And note, none of this requires taking a Stalin-like Vanguard party approach where you literally kill or outlaw competitors or alternatives and stop anyone from ever using them and take actual hierarchical top-down control of everything. That's not how being a popular standard works. All it requires is you working on a really good project, and then selling people on an individually, and alternatives can still exist like OpenRC and Gentoo and Void and Alpine and so on!

Things really jumped the shark when systemd received its own annual conference called systemd.conf in 2015, rebranded to “All Systems Go!” in 2017 with a more general Linux userspace focus. Still, witnessing the project’s own marketing evolution throughout the years is instructive...

That cross-distro unification had been a goal since 2010 was documented above. In Poettering’s January 2011 LCA presentation “Beyond init,” systemd is described as a “system and session manager for Linux,” but at the same time already a “basic OS building block” and for “cross-distribution standardization.” The future tasks listed at that time were fairly modest: session management and automatic initrd fallback.

Yeah, and an init system is a core building block of a operating system? They want to make this out like it's scope-creep or nefarous empire-building goals or something, but that just doesn't track to me. Especially for an init system that actually fully solves the problems in its systems are supposed to solve, like managing the dependencies between things that need to start, and allowing services to respond to new events so that your system can dynamically change what it's running over time depending on what you plug into it and what happens, which any modern operating system needs so that when you plug in a monitor you don't have to fucking run terminal commands in order to make it register the fucking monitor, it would be a crucial base-level component of the operating system.

In Lennart’s 2014 GNOME Asia talk, systemd is a “system and service manager, a platform, the glue between the applications and the kernel.” Universal adoption had been reached. The objectives are much more self-flattering and grandiose: “Turning Linux from a bag of bits into a competitive General Purpose Operating System,” “Building the Internet’s Next Generation OS,” “Unifying pointless differences between distributions,” “Bringing innovation back to the core OS,” “Auto discovery, plug and play is key.” Moreover, it is now emphatically an open-ended project: “Never finished, never complete, but tracking progress of technology.”

I mean, yeah having a good init system that is actually capable of the modern features that systemd enables will really help Linux become an integrated, modern OS instead of a bag of random scripts that don't work well together, so that when you plug in a monitor you have to run terminal commands to make the monitor work. And yes, if you have a program managing all of your running processes, that is kind of a platform that things run on, none of this seems negative to me, but this person seems convinced that they are negative things.

2018 and 2019 alike continue with an underwhelming and haphazard selection of talks. The most notable new addition to systemd is systemd-homed, effectively a new name service with motives similar to those of Sun with NIS/YP in the 90s, but specifically for home directories

Okay, so first having a large and ambitious scope was bad, and now narrowing your scope as you gain more experience and realize you're more ambitious goals were probably not possible is bad too? At this point it seems like nothing system D could ever do will ever satisfy this person that it is good; if it tries to live up to its promises then it's like an empire, and if it narrows its goals and to focus on being a good init system and daemon manager, then it's reneging on its promises and the promises were just propaganda the whole time.

Instances of the analysis not matching up with the historical events

The ultimate reasons for its adoption were as much due to social and network effects as much as technical evaluation. Numerous distro developers were burned out by the nature of distributed bazaar development and welcomed an opportunity to consolidate low-level userspace into a central upstream source tree. Years of piling cruft on initscripts led to increasingly difficult to maintain arcana, with systemd’s ‘clean reset’ of unit files in addition to incursion into major projects finally giving distributors the greenlight to speed up their stagnant on-and-off efforts at init modernization. Upstart was much less effective in part due to it allowing initscripts to be executed verbatim within script stanzas, in addition to its esoteric event model.

Even from this summary you can see that there's a contradiction between this person's overall impression of what happened, and even their own summary of what actually happened. Somehow systemd's success is both because of social and network effects, and because there was nothing else that properly solves the problem of a full init system that actually made things easy and clear and declarative for distribution maintainers at the time, and so we was really the best and cleanest option for them to make a clean break with all of the piling cruft of the past. But seriously, which is it? It can either be the only clean and robust option that fully solves the problem and that had an actual vision about where it was going, or it can be something that was adopted purely for arbitrary social reasons and out of network effects, but it can't be both.

The actual analysis of the state that init systems were in when systemd came about and the Alternatives that existed at the time that this person actually gives in the foregoing section, that they are summarizing here, exacerbates this contradiction even further. It is blindingly obvious even from what this person said that there was no really good alternative that wasn't a massive hack layering it horrible terrible shit on top of the existing horrible terrible shit, or an iterative thing with too much of a focus on backwards compatibility to really make a difference in simplifying distribution maintainers lives and no real Vision to their name. Like, just from reading the evidence they presented, even with all of the biased language that they uses to present it, it was blindingly obvious to me that system D1 simply because it was there at the right place at the right time and nothing else was. Some quotes they quote from people at the time:

On the other hand even when using upstart as an init replacement, we’ll continue to use large chunks of systemd (logind, other dbus services). I personally think “less is more” would only be a convincing argument if we actually would not need the aditional features.

Systemd is becoming a de facto standard in Linux distributions (at least Fedora, SuSE and Arch), and is getting excellent upstream support in many packages. So far, only Gentoo uses OpenRC (and it doesn’t have most of the features I’d like to have), and only Ubuntu uses Upstart. Therefore using OpenRC would mean maintaining many patches on our own, and using Upstart would mean that our upstream would become Ubuntu.

One of the points that I think may have been obscured in the discussion, but which is important to highlight, is that basically all parties have agreed that Debian will adopt large portions of systemd. systemd is an umbrella project that includes multiple components, some more significant than others. Most of those components are clearly superior to anything we have available now on Linux platforms and will be used in the distribution going forward.

Some quotes from the author's own accounts of the competitors that were actually available when systemd came about:

The classic SysVinit boot concept, which uses numbered symlinks (lots of them), has several drawbacks:

-It’s ugly! If you feel that that “K123dostuff” is a pretty name, count yourself lucky, but do me a favor and take advice from your relatives when you name your children ;-)

-Unless you’re a black-belt in Mikado, you soon get lost in a SysVinit setup. Most scripts have at least 3 representations in the filesystem: the script itself, an S symlink and a K symlink. A higher symlink count is not uncommon, though.

-You have to manually specify the order in which boot scripts are to be executed. And you have to do this for all boot scripts, even though it would be more natural to only specify the order for those scripts where it matters. You may be able to fool yourself into believing this is a matter of being in control, but honestly, do you really care if the keymap is loaded before or after the system clock is set ? If you want that control, that’s okay, but the problem is that SysVinit forces it on you.

-It doesn’t have dependency management. Sure, giving service A the number 100 and service B the number 200 will guarantee that A is started before B, but sometimes that’s not enough. What if service B needs service A running ? SysVinit doesn’t help you with this. It starts A before B but if A fails SysVinit will still try to run B. If mounting filesystems fails, it will still attempt every remaining service, even those that need to write to disk. In the end you have a system with nothing running but SysVinit’s runlevel program will happily tell you that you’re on runlevel 5, running the X Window System and full network.

-It’s hard to modify. Why do people write fancy GUI programs to add and remove scripts from/to runlevels ? Because manually creating or deleting half a dozen symlinks, all with different names where even a single mistyped letter can cause the system to break is just madness. Tell me truthfully, wouldn’t you just prefer to do a “mv runlevel.3/telnetd unused/” to deinstall the telnetd service and a “mv unused/telnetd runlevel.3/” to add it back again ?

-It doesn’t scale well. Look at LFS: It uses three digits for the sequence numbers and every service has a number in the hundreds. Makes a lot of sense on a system with only 10 boot scripts, doesn’t it ? The trouble is that whenever you add a boot script you need to fit it into the sequence and should you ever have to start a boot script between a script with number N and a script with number N+1, there is only one solution: Reindexing all your boot scripts. It reminds me of a long forgotten past, when I still wrote programs in a BASIC interpreter with line numbers. From time to time I would need to insert more than 9 lines between line N and line N+10. Fortunately there was the “renum” command that would do it for me. But of course you can write a shell script to do this for your symlinks. No problem. SysVinit admins love exercise.

-It doesn’t work well with automatic installations. If you want to build an installation tool that allows the user to select the packages he wants to install and only installs those, you will inevitably run into trouble with packages that come with a boot script (e.g. an ftp daemon). Your only chance is to assign every script your installation tool supports a unique sequence number, working under the assumption that the user installs all packages. And what if the user installs only part of the packages, adds his own scripts and then wants to install more of your packages which unfortunately use numbers the user’s scripts already occupy ? The worst thing is that this problem exists even for scripts whose order in relation to the other scripts doesn’t matter at all (the usual case).

-No user space testing. To test SysVinit boot scripts and runlevel setup you have to be root and execute potentially dangerous commands. Sometimes you have to reboot multiple times before you get it right. Especially people obsessed with the aesthetics of the boot script output will prefer an easy and safe way to work on the scripts in user space.

-Unsafe shutdown. SysVinit installations rely solely on boot scripts to ensure unmounting of file systems and killing of processes. This is very unsafe and can result in data loss if worst comes to worst. A good shutdown program has a safety net to deal with this.

Look at this as a checklist, and compare that with the features that systemd brought to the table:

So it's clear that at least compared to what came before, systemd solved a real problem. What about the other things created to solve this problem?

In late 2003, a story broke out regarding a proposal by GNOME developer Seth Nickell to write an init replacement. It never progressed beyond conceptual design, and it was unabashedly desktop-driven

Reacting to Seth Nickell’s proposal, Fedora contributor Shahms King wrote in the mailing list about his experiments with revamping initscripts. Content with sysvinit itself and runlevels, he instead wanted to rewrite the /etc/rc script in Python for parallel startup on the basis of a ‘depends’ header in scripts.

What he cited was his own mailing list post from 2004 on boot optimization, which at the end included an off-hand remark on replacing init (but again not initscripts)

Starting from around 2005, Fedora had various on-and-off attempts at updating initscripts under the banner of FCNewInit. It did not envision replacing initscripts, but on the contrary went for full backwards compatibility with incremental improvements to LSB compliance and some vaguely defined hunch for exposing services over D-Bus. ... Nothing ultimately came out of this effort, likely due to it simply adding more cruft in what was already a ball of mud.

Instead by 2007 a more conservative effort again by Harald Hoyer was meant to use LSB dependency headers for parallelizing the scripts, following Mandriva’s work. Notably, Hoyer wrote of init replacements that: "Alternatives to SysVInit (like upstart/initng) can live in Fedora as well, but we are very conservative in changing the startup mechanism that proved to function for a long time now. Unless the “real” killer feature is absolutly needed, we would like to keep backwards compatibility as long as possible."

In 2005, Mandriva implemented a initscript header-based parallelization scheme entitled prcsys. It was described as saving 12 seconds of boot time. At first using Mandriva-specific header directives that began with X-Parallel-, but was updated in 2006 to be fully LSB-compliant. Debian and openSUSE had similar approaches by means of startpar and insserv. A 2008 blog post by a Mandriva developer further confirms that optimization-related grunt work was the primary area of focus, and not any radical redesign of the startup process. This was the same throughout the wider mainstream. [so, and I kid you not, adding comments to init scripts that are parsed by still another separate command. Seriously. That's horrible. Having text files being parsed by two separate commands??]

In 2007, D-Bus system bus activation was implemented with the justification of potentially bypassing any need for a dedicated service manager entirely ... However, as later pointed out by Jonathan de Boyne Pollard, this is an antipattern as the D-Bus daemon “has almost no mechanisms for dæmon management, such as resource limit controls, auto-restart control, log management, privilege/account management, and so forth.” Moreover, the cooperative approach that many D-Bus services exhibit or used to exhibit of directly executing other services effectively led to upstream dictating administrative policy decisions.

Throughout the years, the Debian group brainstormed on a wide variety of schemes, most of which didn’t stick. Some of the more successful things to come out of it were conservative adjustments to startup speed by means of addressing hotspots, described in greater detail in a 2006 position paper. Among the adjustments proposed were replacing bash with dash for initscripts, LSB-compliance, using startpar for parallelization, and backgrounding certain time-consuming operations. Ubuntu implemented similar measures before Upstart.

In September 2009, Petter Reinholdtsen, who had done much of the LSB-compliance and parallelization work on Debian, announced a tentative roadmap regarding the future of Debian’s boot process. It’s an interesting time capsule of the period in its own right, half a year prior to the announcement of systemd. Reinholdtsen appears to have internalized much of the Upstart-related framing around event-driven, hotplug-capable bootup. The sequential nature of Debian’s startup at the time was identified as the root problem. The proposed solution was quite ad hoc: Upstart would have been adopted as /sbin/init, but it would have been modified to understand sysvinit-style inittab(5). The existing rc system and the initscripts were to be left intact in the short-term with Upstart as a fancy initscript launcher until somehow the scripts could be progressively enhanced to emit and react to Upstart events, with insserv being modified to understand Upstart jobs. Not only that, but LSB compliance was still a strong motivation even at this late point, entailing the need for a mix of event-driven job manifests and scripts coexisting. [So tacking on more shit to the ball of mud, instead of cleanly redesigning it.]

A “sprint” between Debian and Ubuntu developers that took place in June 2009 involved an Upstart transition plan for Debian. It’s a very good demonstration of just how convoluted it would have been for Upstart to coexist with sysv-rc, and be integrated in Debian’s packaging infrastructure on top of that. As late as April 2010, Petter Reinholdtsen was writing of his hopes that “for Squeeze+1, /sbin/init in sysvinit will be repaced with upstart while keeping most init.d scripts and insserv in place.” Less than a month later, he was expressing interest in systemd.

Fedora used Upstart from versions 9 to 14 largely as a dumb wrapper for initscripts.

Now, the author never goes into any sort of detail about Upstart itself, which seemed like the only real competitor to systemd in their analysis. According to Wikipedia,

The traditional init process was originally only responsible for bringing the computer into a normal running state after power-on, or gracefully shutting down services prior to shutdown. As a result, the design is strictly synchronous, blocking future tasks until the current one has completed. Its tasks must also be defined in advance, as they are limited to this prep or cleanup function. This leaves it unable to handle various non-startup-tasks on a modern desktop computer elegantly, including:

  • The addition or removal of USB flash drives and other portable storage or network devices while the machine is running
  • The discovery and scanning of new storage devices, especially when a disk may not even power on until it is scanned
  • The loading of firmware for a device, which may need to occur after it is detected but before it is usable

What of OpenRC? Besides missing the crucial feature of actually managing daemons once they're started and being able to handle hotplugging, OpenRC seems like a full-fat competitor to systemd.... just less well designed (not based on declarative configuration, but just fire-and-forgetting random scripts), and just as likely to have become as wide-reaching a family of programs as systemd has, had it become as popular.

Numerous concrete or planned developments, such as GNOME’s increasing number of runtime dependencies on systemd for different components, the seemingly inevitable arrival of kdbus and massive overhaul of the entire D-Bus ecosystem, the planned end for udev support on non-systemd systems and the switch to a kdbus API for libudev, and the single-writer constraint for the redesigned cgroupv2 API – all of these intersected at the same time in a relatively short period of time which created the appearance of an unstoppable current tending towards distributions either assimilating or becoming irrelevant. ... Machiavellianism and coalitional politics do not magically wither away just because the software is free. [emphasis the author's not mine]

Yeah sometimes it happens that we make technical decisions based on what seemed inevitable at the time, and then it turns out that it wasn't inevitable after all and we are left with legacy decisions that are annoying. That doesn't indicate Machiavellianism. And given my discussion above, I think we have ample reason to believe that the decision to go with systemd was anything but "Machiavellianism and coalitional politics", even using the author's own words!

To prove that systemd only got into place because of Machiavellianism and social manipulation, the author would have to do more than show that a couple technical things that were going on at the time helped spur its adoption, or that there might have been one fairly okay alternative that wasn't adopted because it wasn't getting good support, especially when the author's own history did so much to show the technical reasons why it was adopted. And does the author have any evidence that this decision, even if it was in some respect made on the basis of technical choices that don't hold true anymore, he's actually the result of some nefarious plan? No. Does the author have any evidence that is actually a bad decision? No.

systemd was built around a grand vision of its original authors that was usually not spelled out in its entirety, but could be reconstructed by reading earlier source materials from its developers. Its intended way of usage (ubiquitous socket and bus activation) did not coincide with its actual usage, which along with several setbacks involving the kernel maintainers, led to a loss of direction with increasingly ad hoc and reactive development goals for the project as a whole, bordering on stagnation (which could more charitably be called ‘maturity’).

Yeah, again, this demonstrates that the author just wanted systemd to be bad and wrong either way, because no matter what it does it's bad. If it limits its scope and focus because it realizes that it's grander visions didn't make sense or wouldn't work or didn't pan out, it's stagnation and a loss of vision, instead of maturity and just focusing on what you're doing well already, and if it does have a grand vision, then it is evil and an empire. I rest my case.