I'm going to talk about systemd. And before you tab away, know this: every Linux computer I've ever owned and practically every server I've ever maintained used systemd. I like systemd, conceptually. It streamlines a lot of the management of a computer into a single suite of tools with a shared API. The behavior is predictable, and the possibilities are great. Systemd makes Linux easy to teach as a professional skill by standardizing the interface somewhat. It solved a lot of the boot issues central to many popular distros, and it is absolutely everywhere.
There are plenty of reasons to be excited about it (if you get excited by this sort of thing, and, I'll be honest, I usually don't). Yet, I'm seriously considering taking a look at another init system, which is proving to be a more arduous journey than I might have initially thought. And I'm not doing it for the reasons you might expect, unless you've been following the Linux community closely for the last few weeks.
Another disclaimer (the first of many): I don't owe any allegiance to the old-school so-called UNIX principles. Although I recognize them as a useful framework for thinking about systems design, it isn't my entire world. Likewise, I'm not terribly bothered by putting trust in monolithic design. If you're worried about that, take a look a the Linux Kernel and then let's talk. And as far as I'm concerned, "bloat" (in the general sense) is a relativistic concern. I have the CPU and the storage space to not worry about it. Most people do.
When you're running a server where a single systemd installation serves 20+ pieces of infrastructure, perhaps much more, bloat becomes more about SQL queries, clock speed, cron jobs, and RAM bottlenecks. Not init software.
However, and perhaps at core of this post, this kind of "bloat" does matter to someone, and it does have impacts on smaller, human-scale applications and personal laptops. Let's face it, systemd is large in comparison to other solutions and covers use-cases for many different types of users and their concerns. That alone isn't a deal breaker for my use-case. It wants to please both enterprise and personal users alike. Is this an issue in and of itself? Perhaps not, but in light of more recent events, I think it might have the potential to be.
Yes, systemd is complex. But so is the internet, and I don't hear similar complaints about the size and scale of the HTML implementation (which was a victim of scope creep early in its lifetime), or of the HTTP implementation (which has headers for every conceivable type of connection), or otherwise.
But complexity, likewise, also isn't the issue.
User Experience is honestly a more important metric to me than the a software implementation's size or scope. Does it work? If so, I can put up with a messy API. Is it useful? If so, I can deal with scope creep. Does it solve more problems than it creates? If yes, then that's great! I'll probably use it.
But, In order to answer these questions, you actually have to care about the end user. You need to think critically about what that person's desires and needs are, and you have to think about how you earn their trust without violating it. You can't pretend that they're an abstract entity merely capable of following instructions and punching arbitrary commands into a computer and that the'll be cool with whatever you do as a maintainer.
Knowing the target audience matters. Caring about the user story matters. Understanding that software has opinions regardless of whether you've bothered to discover them yet matters way more than writing code.
That's why I think the systemd project deserves a second look. It's opinionated, sure. But usually it's opinionated about logging, interacting with D-Bus, and service management.
My issue is the kinds of opinions it seems to be OK with holding. The project appears as though it is starting to think of itself as being open to (optionally[1]) collect personally identifying information and storing it in the systemd database, just in case. I think we can agree that's a whole different ballgame.
If you haven't guessed, this is about the new (optional[1]) birthDate field that recently got added to the systemd database ahead of any formal enforcement activity from the state of California. California, if you're wondering, just approved a law that requires all operating systems to implement vague, far-reaching, and poorly considered age verification tools for every computer and every computer user and all of the software on that computer. It's either pitiful legislation or really good lobbying. Probably both. The birthDate field was added to the systemd database completely unprompted by any actual legal mandate placed upon the project or, I have to imagine, any actual consideration.
My concern also stems from Leonardt Pottering's bizarre refusal to remove the birthDate field from the database in a revert PR he closed and locked without a chance for longer discussion. In that same PR, he provided the justification that systemd "isn't a policy engine", which, in and of itself would be fine if not for the fact that the PR was trying to undo what appeared to be a policy-motivated change.
And it's not just the birthDate field. As one user on Bluesky pointed out, systemd also has (optional[1]) database fields for realName and location. Are those tools useful to system administrators? Maybe the location field could be used to automate selecting the proper software mirrors, but the other two? In what non-dystopian universe would your software care about that information?
All taken together, it isn't impossible to imagine how the systemd of some future time could be used to circumvent identity protection measures implemented by the user. If systemd is just holding onto an API that less-than-scrupulous programs could use to go over your head and ask for personal information, what is the point of trying to protect it in the first place?
And, of course, how did all of these pieces come together in this way? Was there a community discussion we all missed out on? Did the systemd team meet to discuss the technical needs of the project and balance them with the desires of the community before taking action? Or, was this, I saw another commenter pointed out, just another unilateral decision taken by systemd's creator, Leonardt Pottering? Either way, it doesn't give me a ton of confidence that things are all well in systemd land.
These latest developments appear to demonstrate that the decision making processes in the systemd project are operating outside of critical safeguards like community discussion, accountability, and a clear contribution policy. For these technical and leadership-related reasons, and for my own ethical concerns around age verification infrastructure, I'm giving non-systemd distros some real consideration for my personal computer. That, or, because I use nix, I'll have to pick and package a fork for my own uses.
As for work-related uses? I'll probably need to continue using systemd-based tools. And that's simply going to be the way of it for some time because of how ubiquitous systemd is in the modern Linux stack. Again, it's not bad software, its the management I'm worried about.
It's not a hot take to say I don't want my personal computer to have the capability to collect my (or anybody else's) personally identifying information, nor would I want that tool to arrange my information it in a nice-and-tidy little database for certain programs to read. Even if that interface is totally optional[1] I'd still bug out. Even if I had any information worth protecting, I'd still bug out. I don't think this is an outrageous statement and I think a lot of people would agree with me that this just doesn't seem like the role that init software, itself being so central to the software stack, should take.
I've stopped using software for less, and yet, I feel like the mythos around systemd somehow requires greater-than-average proof. So, I'm going to try and hash out my thoughts a little more. But fist, some history.
It might feel like we've been here before as a community. A few years back (and, really to this day) there used to be a huge debate when many main-stream distros started adopting systemd. At the time, the main concerns appeared to be UNIX purity, systems design, and any number of claims that systemd is just too big, too complicated, or operating under some unknown nefarious agenda.
When I started reading about that debate, I could largely just brush off the primary concerns about systemd since they didn't really resonate with me. To me, it felt like the opposition was overly focused on some kind of mythical software purity that simply wasn't achievable in a practical way. At the time I remember reading a distro maintainer for Arch weigh in on how systemd saved his brain from being fried by the endless complexities of the boot process, and I think those arguments, along with others, ultimately won me over.
Systemd was useful to someone and it made using computers easier. That's a story I can get behind!
At the time, I thought there was still a clear feedback loop between those people and the tools they used. It was free software, I thought, if they didn't like the direction things were going in, they could get involved and change the course of the project before it was too late. Now that I've seen just how far reaching systemd is and how fast the main contributor makes poor decisions and then just shrugs it off, I don't think that's possible without a fork or some kind of larger intervention. And, ultimately, I'm still responsible for my own personal choices, so I feel a need to do something for myself.
I think that the moment we're in right now is different than those that have come before. The old debates around systemd largely revolved around design philosophy. This time, I think they're coalescing around discussions of ethics, community engagement, and just plain old power; dirty, blunt, and importantly for me, harder to ignore.
Systemd is suffering from a lack of accountability.
If it was arbitrary and quick for one person to implement age verification infrastructure in systemd, unprompted by any state or federal government, that's a problem.
Likewise, if it is difficult to remove that change afterwards because one person decided it's cool don't worry about it, that's also a problem.
And all of this comes at a bad, but not entirely unexpected time. The entire Linux ecosystem just had a major shock after one person decided to go around and implement age verification infrastructure in several distros without the guidance of anyone else. By all accounts, it seems like he saw a need in the ecosystem and figured he ought to be the guy to fill it. Then, when pushed on why he was doing it, he claimed that his fix would never work right but that the maintainers should adopt it anyway.
Who does that self-defeating narrative serve? Normally, I'd celebrate that kind of do-ocracy. It's what made the Debian project so prolific. But what I think is missing here is a deeper understanding of what groups age verification tools benefit. And, more to the point, I think we're missing the point on why people make software in the first place. It isn't just so we can add more dots on the GitHub heatmap and plop a line on our resume.
Personally, I don't think this kind of tool benefits the person who owns the computer. In fact, it kind of begs the question who really owns the computer in the first place. And maybe, with our ears still ringing about the last systemd debate, that's what we're missing in our current understanding about this moment in Linux.
Systemd was a tool that helped system administrators and distro maintainers. End users like me ultimately didn't really care because it solved my problems and stayed out of my way. I hate to admit it, but we all end up in that disengaged consumer role at some point in our lives. I swore to myself that my transition to using Linux would end that cycle, but I was wrong. It might be worth exploring how I, and other like me, ended up in that position.
Now we're faced with a new kind of debate, and I think we'll do well to adjust our thinking to accommodate the new information, which is this: for whatever reason, we're in a situation where systemd, the default init system in most Linux majo distributions, has decided that a not insignificant part of its future focus as an init program could be to help people who might want to know a lot of personal information about you and who might (optionally[1]) want to use that information to do most-assuredly cool and not-at-all underhanded software things and pretend that that is somehow a valid use-case that should be implemented right away and without a moment's delay without any discussions or takebacksies.
I'm invested in systemd, about as much as anyone else. I don't usually care this much about init software. I don't think I really should.
But I'm not that deeply invested[1] to seriously crave an alternative.
Footnotes
[1]: For now.
Comments