The problems with systemd are:
* that once it was adopted, every single package started requiring it
* which meant that packages that previously could run everywhere, now could only run on systemd-based systems
* binary logs - a solution that solved nothing but created problems
* which locked out any system that wasn't linux
* which locked out any linux system that didn't want to use it
* which led to abominations like systemd-resolved
* "bUt yOu DoNt hAVe tO uSE it" - tell that to the remote attestation crowd, of which Poettering is a founding member of. see https://news.ycombinator.com/item?id=46784572 - soon you'll have to use systemD because nothing else *can* be used.
The systemD developers don't care about any of this, of course. They've got a long history of breaking user space and poor dev practices because they're systemD. I mean, their attitude was so bad they got one of their principal devs kicked from the kernel because they overloaded the use of the kernel boot parameter "debug", which flooded the console, and refused to modify the debug option to something compatible like "systemd.debug", broke literally every other system, and then told everybody else "hey we're not wrong, the rest of the world is wrong." And this has been their attitude since then.
Look, if people want to use systemD, that's just fine. But it is a fact that the entire development process for systemD is predicated on making Linux incompatible with anything else, which is an entire inversion of how Linux and Free Software works.
I actually like unit files. But if systemD was just an init system, it would stop there.
You're saying that because the person who made systemd now work on hardware attestation, all Linux distributions will eventually require remote hardware attestation, where users don't actually have the keys?
Maybe I'm naive, maybe I trust my distribution too much (Arch btw), but I don't see that happening. Probably Ubuntu and some other more commercial OSes might, but we'll still have choices in what OS/distribution to use, so just "vote with your partitions" or whatever.
But on the other hand, you might be right, you never know how the future looks. But personally I'll wait until there is at least some signal that it's moving in that direction, before I start prepping for it to actually happening.
having to manually deal with daemons was so painful, to the point of being exoteric.
Honestly though, the argument against systemd is that it moves too much stuff into init, but I don't think it does enough of that, it's still extremely conservative, like, SD-DBus should be using binder x-port IMO.
And a lot of those utilities are just straight better then the alternatives, or at least make a decent practicality vs correctness trade off for desktop Linux.
systemd-cryptenroll for example is just straight up much easier to use for most applications of FDE, unless you're really doing network unlocking with something like Clevis.
Most issues regarding systemd I encountered were due to a halfway adoption (Debian). Some things like timers are a bit more cumbersome than "the old way", but I wouldn't want to miss the added robustness. Most things systemd implements lead to _less_ issues. And writing a systemd unit is pretty easy, contrary to the old bash script mess.
So, no. Keep your Poettering-Bashing to yourself. I'd rather invest the time in geokking the systemd choices deeper.
Isn't that a selfish view, though? "Works for me,so I don't care that systemd is creating dependencies everywhere for everyone else".
I appreciate that it simplifies some things, but I can't understand that you can't choose which parts of it to install, or even replace parts of it with alternatives.
Isn't linux about choice? It feels we're going on a downwards spiral where choice is being taken away from us in every domain
If I use and like Firefox, and others depend on Firefox, or Firefox depend on others, then it's Firefox fault for you choosing Firefox?
I really don't understand the argument you're trying to make. You had choices before systemd, and you still have choices even though systemd is widespread, what's the problem? It isn't modular enough? Use something else then that is modular.
Also, it's not just RedHat that's depending on systemd, as if its a conspiracy on their part.
https://www.theregister.com/2026/01/26/plasma_6_6_systemd_lo...
Want to run xterm? Requires Xorg. rootless Xorg requires udev, udev turned into a systemd component. want to run xterm without systemd? good luck, you are now the maintainer of your own LFS.
Yes, but this is hardly a unique systemd/Linux problem. I despise TypeScript for various reasons, always preferred vanilla JavaScript over TypeScript. So if I'm met with "Huh, this library is using TypeScript, am I ready to deal with that", I make the choice to not depend on that, even though half of the ecosystem uses TypeScript.
Going against the grain comes with more work probably, but this is also a choice we make, because we have strong feelings and opinions about something.
You can? The system where I'm writing this uses systemd, yet networking is handled by NetworkManager and not systemd-networkd. Time keeping is handled by chrony and not systemd-timesyncd (or whatever the systemd NTP client was called). Etc. Systemd in fact has many components that are optional. Of course, there are also parts of it that are non-optional, just like many other collections of related software.
> Isn't linux about choice?
Linux is "about choice" to the extent that the source code is freely available, and if you don't like what upstream is doing, you have the choice to fork it and do whatever you want. "Linux is about choice" does not extend to upstream maintainers being obligated to cater to every whim of every end user.
Case in point, Devuan: Not being satisfied with the path Debian was taking, they exercised their choice and are now doing their own thing. Good for them! And to the extent this has reduced the frequency of systemd haters starting yet another anti-systemd flame war on the Debian mailing lists, it seems to me Debian has won too. Hooray!
There is point to complain about distros turning it on by default but you could have systemd where systemd just does unit management and not much more.
The hardest part to get rid of would probably be journald as this parasite's log format is just... not good in any metric but it isn't easy to replace either if you want to keep systemd functionality
systemd solved a ton of headaches but also added few more, like inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS.
> And writing a systemd unit is pretty easy, contrary to the old bash script mess.
We had thousands of lines of "simple" sysv init scripts fixes because apparently even seasoned maintainers or developers of the app can't figure it out. It's huge improvement.
One example: A java app that writes its own pid. The status subcommand relies on the pid existing.
so calling start then status will return that the service haven't started yet. And that is what stuff like for example Pacemaker does so it could just randomly fail under sysv. Under systemd it's all so much simpler
I strongly believe that systemd brand is a worst thing that happened to Linux, hindering the spread and innovation in the Linux space, but at the same time I have to admit that systemd-as-pid1 is the best init system out there.
What "innovations" have been prevented or hindered by systemd? I guess you could argue "well, we can't know" but then what is the argument here really? I'm guessing there is something concrete your thinking about here, that systemd made impossible, but I'm not understanding what you're referencing, I can't recall anything like that.
Devuan lets you choose an init system so you do not have to use sys V init: https://www.devuan.org/os/init-freedom
A number of other distros also use init systems other than sysv init or systemd: Void, Alphine, etc.
Just through some random mess of unintegrated incomplete long abandoned half baked subsystems?
I really want to know, what do you use instead?
https://www.devuan.org/os/init-freedom
It lists other options. It also lists other operating systems that don't use systemd.
I think what I hate most about systemd is that it has seemingly indoctrinated so many into believing that there are no viable alternatives, only some random mess of unintegrated incomplete long abandoned half-baked subsystems.
Even the defunct Upstart is better than what's in Devuan.
I think systemd also took a relatively non-unixy approach, where it's a big stack to adopt, rather than individual programs that work together well. Typically, we prefer the latter instead of the former, so some pushback is because of that too.
Today i hate systemd for its bad debugability (edit unit & daemon-reload loops), the lockups that happen whenever there is a fifo in the wrong place, and the processes that systemd spawns with no apparent related unit and without means to mask them. And the difficult to disable suspends on machines that never had any business suspending.
Then along came Linux with its sysvinit-style init scripts, which were a pain in the arse.
Now here's systemd with yet another form of init scripts, which are a pain in the arse.
Each time there's been an evolutionary shift in how we do things, and systemd works pretty well for the way we use desktop systems now. They're also not terrible for servers once you get used to them. I still find them pretty annoying.
Anyway the TL;DR is that computers suck and operating systems suck and init scripts suck and the whole thing sucks, and everything else we've tried is somehow worse than what we have.
It makes me want to just go back to fixing tractors. People are really grateful when you show up in the middle of a muddy field at 10pm and fix their tractor.
It's.... fine, mostly. It solved no problems I had and introduced some minor ones I didn't, and offers significantly less visibility, but it's no longer the worst offender in those regards (hello, Wayland!) so I just write it off as another of the many ways the Linux experience has gotten worse over time.
A lot of people like the do one thing well philosophy and systemd is intended to be an entire additional OS layer. People like systemd if they want more uniformity between distros.
The systemd developers are not exactly open to suggestions and criticism. Have a look through their issues!
>If the old h4xx0rs make it easy and convenient so that there is no effort working with the system, their ass will fall off.
However, the systemd journal raw format is binary data and would much rather a plain text log. All things being equal I'd rather deal with human readable files.
Yeah, I also wish that at least was an option, would make some things easier.
Also wished the remote log sending was easier, not sure if it's just me but was a huge hassle to setup properly, and really hard to properly validate it works as expected in all cases. Finally got it working, but it isn't as easy as the other parts of systemd/journald.
It is like the cult of "The UNIX Philosophy" hardly found in any commercial UNIX that spun out of AT&T UNIX System V.
Systemd pushed forward proper usage of capabilities, better watchdogs (in a broader sense, as systemd supports all kinds of them), isolation, policies, and so on and so forth. You need it all to efficiently control the daemons, and it's great when it's all available in a single suite.
t43562•3h ago
I think you can even get my favorite init system on Devuan now - dinit. It has a simple and useful service file format that's trivial to use and it can monitor and restart processes and users can use it for starting up their daemons etc - BUT it doesn't take over the world and the log file formats are all text.