Comment by adrian_b | Hacker News Reader

Comment by adrian_b | Hacker News Reader

Parent Full thread

I believe that the opposite applies.

I have yet to hear any argument pro systemd that is valid.

As long as the systemd supporters cannot explain its advantages, there is no reason for anybody else to replace their good systems that work fine without systemd, with systems using systemd.

In practice, systemd has been imposed by force. The developers of a few packages, like GNOME, have introduced dependencies upon systemd. Then the maintainers of the major Linux distributions have considered that such packages cannot be removed from their distribution, therefore they must base it on systemd.

Then the users have discovered when upgrading their computers that they must either migrate to systemd or stay with their ancient program versions.

This is how systemd has propagated. In no place there was any analysis about technical advantages and any attempt to find an optimal solution by consensus.

> As long as the systemd supporters cannot explain its advantages, there is no reason for anybody else to replace their good systems that work fine without systemd, with systems using systemd.

Assuming you know what systemd as init system able to do, I'm not sure what extra information you need for getting list of advantages.

If you going with examples is better for you, i'll mention couple of mine - note that I likely forget some other good samples as it's so natural so I'm may be not realizing it's systemd's feature, just "how things work"

* hardening - syscall filtering, privilege limiting, read/write path filtering, per-unit tmp files. As nice example, I have great peace of mind when I put php-fpm into network isolated to localhost only for IP level

* resource management and resource information at all - observing resource usage by multiple units when needed with a quick way saves my time, in addition to being able to collect such metrics into monitoring. Setting the lowest IO priority for backup scripts and even MB/sec per block device - godsend. Limits on CPU usage or RAM usage where needed ensures smooth operations of the fleet without nasty surprises

* things like quick overview with systemctl --failed, user-level units instead of flacky @reboot in crontab (yeah, we still remember it from eggdrop/psybnc days)

* clear and uniform way to work with services across the team, no hacky bash scripts with saving PIDs

so on.

Probably you do system administration for your servers in some other way that all that goodies are not noticeable for you and your team.

Reply on news.ycombinator.com