Comment by znpy
3 months ago
> Can anybody explain to me again why systemd is so bad ?
it isn't, it's great. it is different, though.
and then come in two phenomenon:
1. people resist to change, often out of ignorance.
2. some people tend to look at tradition and consider it just better, without much reason. "unix systems in the 80ies had shell scripts to launch system services, that's what i shall do in the 2020ies".
> Yes, it is maybe monolithic (but so is the Linux kernel).
it really isn't, it's largely a collection of relatively small binaries that do one thing well but they are designed to work with each other. systemd appears to be monolithic from outside, but it really isn't.
> Maybe some of them will get bloated as they achieve feature parity.
they will, most likely. it's easy (as a piece of software) to be lean and clean when you're doing very little (with little error checking and recovery).
> However I can't understand why systemd is the point of so much disagreement.
systemd was essentially pushed down everybody's throat by Red Hat when they realized it was high time to level up the boot process for the whole ecosystem. systemd made a bunch of things not only feasible (concurrency, on-demand service activation, multiple-instances of the same service running, proper log management) but so easy they're trivial.
so 10+ years, it's definitely a net positive.
some people are still complaining but meh, some people will complain anyway, so let them talk, whatever.
>> Yes, it is maybe monolithic (but so is the Linux kernel).
> it really isn't, it's largely a collection of relatively small binaries that do one thing well but they are designed to work with each other.
So where are all small the projects trying to replace the small parts of systemd? AFAIK there are no stable or convenient APIs in all those parts, so even though technically systemd consists if many binaries, it is monolithic.
This is exactly what people call "forces distributions to use it", i. e., you must choose all or nothing.
I don't believe Linux userspace maintainers are lining up en masse, plus if your alternative implementation doesn't significantly improve the status quo, why even bother?
Here in the comments you can find a lot of complaints about non-main parts of systemd, which could be improved easily if it was actually non-monolithic.
> So where are all small the projects trying to replace the small parts of systemd?
you should go ask that to "small projects" developers, not to systemd developers, i guess
There are always people improving small things as a hobby - except for the systemd components. It tell us that it's harder than it seems.
2 replies →
> systemd appears to be monolithic from outside, but it really isn't.
If it looks like a duck, walks like a duck... systemd is modular solely in theory. In practice, I am grateful that I can still remove journald and resolved from current Ubuntu installs and I'm pretty sure that's not going to be possible quite soon.
Systemd itself may be modular, but practically distros are not going to bother.
> 2. some people tend to look at tradition and consider it just better, without much reason. "unix systems in the 80ies had shell scripts to launch system services, that's what i shall do in the 2020ies".
And from that the systemd crowd tend to draw the following conclusion: if something was done a certain way for decades then it is bad and should be replaced.
Seeing how good systems is and remembering how messy it was to work with init scripts, runlevels and other stuff… i guess they were/are right
I have the opposite opinion. Init scripts (upstart!) were reliable, transparent, consistent and manageable.
Systemd is none of those things.
Having said that, I have to additionally admit that init scripts had to go at a certain point. It's hard to imagine a modern scripts-based PID1. Times have changed.
>they will, most likely. it's easy (as a piece of software) to be lean and clean when you're doing very little (with little error checking and recovery).
Why would you even begin to think that openrc would ever want to include a whole virtualization manager. Are you serious?
>but they are designed to work with each other.
And they are not designed to work without one another. See e.g. dbus and how hard it is to get it working on non systemd systems.
Systemd binaries aren't drop in features.