Systemd, ten years later: a historical and technical retrospective

The logind developers went against the established wisdom of experience (that big rewrites are generally a bad idea) with the predictable result: high costs (both in migration and in handling outright bugs) for nebulous benefits, with the result that desktop linux is flakier and (understandably) less popular than ten years ago.

> This is the kind of toxic behavior that makes communities non-inclusive and leads to impostor syndrome.

Is that supposed to be a bad thing? We should be less "inclusive" of people who want to rewrite everything. They should feel like impostors. You can't produce good quality if you're not willing to call out bad quality; Linux succeeded (for a time) because Torvalds had high standards and was willing to maintain them.

How should anyone know what the user really intends. When I start a tmux in a graphical session and click log out I want the system to stop my things completely, (almost) like I haven't even logged in. After all, my session never was set up to be an always-on server session thingie. The distro never advertised this, etc.

Of course users who grew up on UNIX/POSIX/nohup and on distros that worked in a specific way (ie. without cleaning up processes after log out) expected this to continue.

Debian made systemd default in Jessie, which was released in 2015, and it took 2 years for this subsection to appear there: https://wiki.debian.org/systemd#Orphaned_processes

It either did not bother that many people or no one really did anything to document/address it.

Distros did not care apparently. systemd maintainers were aware that it breaks all and every double-forking self-backgrounding resident stuff, but they accepted the trade off, and even documented it: https://github.com/systemd/systemd/commit/65eb37f8fcf0c82db0...

Compatibility is the only way it becomes possible to make those changes. E.g. in the pre-systemd days there were at least four different syslog systems and at least three different cron systems. But because they conformed to standard interfaces and were loosely coupled to the rest of the system, users were free to choose any of them, or to make their own. Same with desktop environments: you can run KDE or Gnome or Xmonad or whatever, but since they all follow common standards, any program works with any environment.

If the systemd people want to make a shiny new init with cool features, great. It's when they break compatibility with alternatives that I have a problem with it.

> 1. GNOME is an open source project not in control of any one company or organization, and anyone can contribute or fork the project if they so desire.

> 2. Nothing was "forced through" as the decision was agreed upon by the current and previous maintainers. If you disagree, you can revert to an old version as previously stated. This may be unpalatable to you but it is not realistically possible for anyone besides you to write code that you will agree with 100% of the time. It's up to you to make the tradeoffs you want on your system.

The fact is that most contributions are made by RedHat employees on RedHat time, so anything that can be decided by 51% of maintainers is under RedHat's control (and I can't do anything to change that since I can't outspend RedHat). There was a decision to adopt systemd but it was very much not a consensus; there was bitter disagreement at the time (and still is).

Forking by a minority is only practical if the system is made up of small components with standardised interfaces between them. Good open-source citizens follow those standards for the sake of allowing their users to do that (e.g. KDE migrated from DCOP to the technically inferior DBUS for the sake of being able to have common standards and compatibility with GNOME). If the whole system is a big ball of mud with no way to replace or decouple individual pieces, then you can't ever change or fix one part of it without forking the whole thing, and you don't have the Four Freedoms in any practical sense.