This comment from a systemd develop is what is (the most important thing) wrong with systemd. Its not the first time I have seen comments like this and its not hard to find them.

Found via The Register: https://www.theregister.com/2024/06/20/systemd_2561_data_wip...

Reading the comments by systemd developers on that bug, I am now confused about what the --purge option is actually for.

> Reading the comments by systemd developers on that bug, I am now confused about what the --purge option is actually for.

Its intended for package management (basically the entire sd-tmpfiles is intended primarily for package management), specifically when uninstalling a package it is used to clean up the dirs/files created by that package (while on the other end it is used to create dirs/files when installing).

Should that not be something dealt with by package managers?

They don't parse the tmpfiles.d configs nor are they the ones that create the directories. sd-tmpfiles effectivly is part of the package manager (if they make use of it during uninstall) just like sd-sysusers for creating service users. They indirectly use it by installing files to tmpfiles.d, so it does somewhat follow that they should use it to remove the affected files again.

IIRC idealy services wouldn't even need any tmpfiles.d entries at all and would rely on the service StateDirectory= and RuntimeDirectory= but there are also a decent amount of other cases (mostly programs that require config files in /etc/ which idealy shouldn't be required) where there need to be some other dirs/files present.

i don't know why systemd gets so much hate. been using it for a year or two now for all my services and it seems to work fine.

One reason * may * be that most users didn't want it. It was kind of foisted. I was bitter about it for years until I lost my enthusiasm for Linux. Now, I exclusively use Debian (testing) but, to put it abstractly, it seems without a soul.

And I too find it generally works well. I still would prefer it went away though.

"most" is a really misleading word to describe a tiny loud minority.

so what was the alternative? /etc/init.d scripts??

Systemd's init system used standalone, or one of the many other init systems available and used by some ditros: Upstart, OpenRC, runit....

So basically we don't need a car, just a faster horse.

Looking at systemd just as an init system is shortsighted. Consider it service manager, that manages lifecycle of services, and starting them at init time is just one of many other mechanisms (other being at specified time, dbus activated, socket activated, as-a-dependency activated, etc).

I was replying to a comment that asked what the alternatives were.

Most of the alternatives do provide dependency activation and other features you mention: https://wiki.gentoo.org/wiki/Comparison_of_init_systems

I prefer cron for running things at a specified time.

Is systemd a service manager? It seems to be a lot more than that. It aims to make Linux less unix like: https://www.theregister.com/2024/06/13/version_256_systemd/ . It seems more of an OS built on the Linux kernel - a bit like Android.