> And I am sure, if you really think about it, you know this yourself.
I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.
Please avoid making bad faith interpretations. I'm reading that comment as this: surely you can acknowledge that sysvinit is not a good solution for many people? And just for the purpose of adding some structure around sysvinit, systemd does an adequate job? And if you have an advanced use case that requires a very specialized init system, I hope you can understand how that is uncommon?
I don't think that is a bad faith reading; when the original statement was (basically) "systemd is bad and overcomplicated", saying "it's not and you know it" is a bad-faith statement. And no, sysvinit was perfectly fine for most people; if anything, I could fairly describe systemd as a very specialized init system for uncommon requirements. Now, I'm happy to agree that systemd is also basically fine for the most common uses (because, honestly, the most common cases are covered by anything), but it also introduced pain points for even non-esoteric cases (I've personally witnessed systemd getting stuck in fascinating nondeterministic ways more than sysv).
That doesn't seem to be what most Linux distributions were thinking around 10 years ago when the upstart/systemd/openrc/etc arguments started happening. The general consensus seemed to be that sysvinit needed to be replaced, or at the very least it needed to have a ton of other scaffolding on top of it in order to make it keep working.
Sysvinit never got stuck in those cases because it never had service dependencies and thus never needed to have a constraint solver for the dependency graph... So could you honestly say that pain point was better?
>Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.
Was bad faith, naive, and frankly... insulting -- so I just chose to ignore it.
My reservations are well grounded, and when ones concerns are echoed by ESR, Linus, and tytso, I don't think they can be dismissed so easily.
Certainly some people wanted features that sysvinit couldn't provide, obviously, because so much effort went into systemd. But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)
I'm still using sysvinit on my main machine, and on all "critical" servers not because I have an advanced use case requiring a specialized init system but because I have a simple use case and a computing philosophy that requires simple init system. I have a strong (I'll admit, borderline fanatic) affinity for the "unix philosophy" of accomplishing things through the composition of simple to understand and debug tools that do one thing, and do it well.
To me, SystemD is about as far as you can get from "do one thing, and do it well" and "simple to understand and debug". It's a monolith (right?) which is why it's not running directly on the hardware. Unfortunately, Debian now builds some packages that I use occasionally with SystemD specified during the configure stage, and I don't want to maintain my own packaging of tools with different compile flags, at least not yet. Presently, I solve this by having a separate VM for "all tasks that need systemd", but I hope to replace that with something lighter weight, perhaps containers instead.
SystemD provides some features I imagine most users want, and that I strongly see the benefit of, but for the vast majority of those features, those reasons I'd want to use systemd, I'd already solved it myself, through the composition of existing and simple tools. A good example is networking. My computer does exactly what I want it to do, every time, in all permutations of wireless, wired ethernet, wireguard, knowing to mount certain NFS shares when I'm at home, randomizing mac address in certain situations, knowing when &c. It's great functionality, and I got there over time by building simple and easy to debug shell scripts, which call out to tools like `ip`, `iw`, `wpa_supplicant` and reading from /sys/class/net.
I also don't use pulseaudio, as audio happens to be one of the subsystems I have strong experience with, and pulse is an unnecessary (and sometimes error prone) layer, considering I get along just fine with ALSA.
The one thing I'm jealous of is faster boot times. But I'll happily boot a few seconds slower in exchange for PID 1 being simple, and my other services being simple and hence easy to debug.
I don't understand why this philosophy discussion seems to get brought up so frequently or why anyone needs to care about philosophy in the context of a computer program. Linux distributions that adopted it are not sitting around pondering the meaning of life or the existential nature of what it means to boot a computer, they were using it to solve a real problem that they had. It was a complex problem, it was not a simple problem that could have been solved with a simple solution. So what you are saying is not really related to the question.
I don't think the opinions of ESR, Linus, and tytso are relevant here either as none of those people work on init systems. If you developed your own solutions with shell scripts, that's great for you, but I hope you can see how that doesn't work at scale in a big distribution. BTW systemd includes a lightweight implementation of containers so I also don't understand what you're talking about when you said you needed to then put it in a VM or container. The exact problem you're having can also be solved... by just using systemd. So it actually seems like you're making things more complex than it needs to be by jumping through hoops to avoid it.
Audio is also my expertise, and using just ALSA is an experience in pain. You need some kind of userspace daemon in order to get a good experience with that.
Booting is simply a complex problem. The complexity simply lives with your shell scripts instead, which is imo a much uglier and less maintainable solution for most use-cases.
Also, does your system do logging before the file systems are mounted?
> But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)
Sure, but systemd has quickly been adopted by the experts, namely the maintainers of every mainstream distribution. The people who maintain all of that infrastructure think it is much better than what we had before. That does say something about its quality.
> It's a monolith (right?)
That‘s a common misconception. You don‘t have to use all of systemd. And I am not talking about all of systemd, just the init system.
That also invalidates your point regarding networking, btw. You could keep using your setup with systemd.
I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.