[andrewstuart3]

Those are common arguments for systemd, similarly to other batteries-included software. But the opponents of such software (and of systemd in particular) tend to expect the whole system being like that: having all the useful components playing nicely together, and easily swappable in addition to that. Which is harder to achieve, but supposed to be nicer.

[andrewstuart]

https://images.news18.com/ibnlive/uploads/2021/12/spiderman-...

It's like I'm in a hall of mirrors......

It's the integration of systemd, the common approach that yields the giant payoff. I understand the "lots of independent utilities" Unix philosophy but systemd's consistent broad scope yields increasing benefits.

[sph]

Sometimes a monolith is better.

See also vim vs Emacs.

[customkitchen]

You can still do that with systemd though. If you want to swap out some components then just don't use those features in your unit file, instead have your unit file run a shell script that uses your components. The "opposition" to systemd has never made any sense to me on any level.

[andrewstuart3]

Can't speak for the whole systemd "opposition", especially since I'm not really a part of it, but I think it is rather a matter of multiple implementations sharing standardized interfaces, versus a single implementation with its custom interfaces: compare systemd's timers to cron implementations sharing crontab format, or systemd journal to syslog implementations, sharing its standardized protocols. With a single interface and different implementations, you can easily swap those, but with a monolith like systemd you are mostly stuck if the software actually makes use of it.

I think there are other reasons why people dislike systemd (and recalling a few articles with people ranting about it; I think there are many around), and usefulness of standards and alternatives/choice wouldn't necessarily make sense either, but here is at least one of the ways to view it.

As for init scripts, I think it can be even a bit nicer than that, since systemd provides some backward compatibility with sysV-style init scripts [1], but in that systemd acts almost like a swappable implementation.

[1] https://www.freedesktop.org/software/systemd/man/systemd-sys...

[vetinari]

> compare systemd's timers to cron implementations sharing crontab format, or systemd journal to syslog implementations, sharing its standardized protocols.

Well, but then you must be aware that you are leaving lot of effectiveness, unification and deduplication on the table.

See, many people think of systemd as if it was init replacement that grew timer support too. They are looking at the wrong level of abstraction: it is an event machine, that manipulates units when events happen. That event might be boot to certain runlevel, timer, hotlplug, incoming request on socket, dbus activation, whatever.

By cutting and dragging out one of the event handlers outside into special-cased, custom flow component that duplicates existing functionality anyway, you are ending up with a worse system.

[customkitchen]

>compare systemd's timers to cron implementations sharing crontab format, or systemd journal to syslog implementations, sharing its standardized protocols. With a single interface and different implementations, you can easily swap those, but with a monolith like systemd you are mostly stuck if the software actually makes use of it.

But this still makes no sense. You can just develop another thing that converts from the systemd format to something else, or make the other daemon capable of loading the systemd format directly. It isn't even hard to do this, I've seen various things do it. And depending on where you are the systemd formats are arguably more standardized than old crons and sysloggers in the current year.

[eternityforest]

The trouble is that the system as a whole becomes a product that requires testing and bugfixes. When things are swappable, every system is unique and has only been built a few times.

Plus, it creates fragmentation instead of concentrating efforts on one project.

It's easy to get situations like "I need feature F but that's only in B, we use A because C needs it".

Use of any features outside the lowest common denominator quickly makes things nonswappable.