Carsten Pfeiffer to Linux Group via Wall-To-Wall:
Lots of points to agree with...

boycott systemd
systemd 0 is a replacement for the sysvinit daemon used in GNU/Linux and Unix systems, originally authored by Lennart Poettering of Red Hat. It represents a monumental increase in complexity, an abhorrent and violent slap in the face to the Unix philosophy, and its inherent domineering and viral nature turns it into something akin to a "second kernel" that is spreading all across the Linux ecosystem.

@Linux Group
@linux group @debian
50 comments show more
Carsten Pfeiffer
Re logs: at least on SUSE and Debian, output of startup scripts during boot is simply lost. dmesg only gives the kernel messages.

And you probably know that you can still have plain text logs with systemd. I have that here on debian. And you know what: having logs signed so that you know that nobody has tampered with them might actually be a good idea. So do both: binary logs for security and plain text logs for safety.

If distributions have their own custom way of packaging and configuring some software, where is the problem that they ship their own distr-specific unit files for it?

The advantage is mostly for software that is *not* provided by the distributions. They now have the ability to provide distro-agnostic unit files. Locks belong to /var/lock. See

Re environment: if a SysV service is started at boot time, it inherits the environment of the init process at that time. If you later stop and restart the service via /etc/init.d/foo start or service foo start, it inherits the environment of the current shell. Or if a service is launched by udev or dbus, it inherits again other environments. With systemd, it always gets the same environment.

Have you actually asked for some documentation to be improved? It's not like only the core systemd developers can write that. AFAICS contribution is possible for everyone.
David Benfell
Those distributions are doing it wrong, then. And maybe it's not fixable on Linux.

On FreeBSD, I have a preserved copy of dmesg from boot in addition to the dmesg command. I have a dmesg taken yesterday and today. I don't keep logs very long, so I can't check, but I'm sure I've been able to go back to my logs to find boot-up problems.

The problem with having distribution-specific unit files is that it undermines your claim that unit files are distribution-neutral.

Do you have any idea how old the file hierarchy standard is? Seriously, I started hearing about it when I worked at Linuxcare in 1991-2001. Distributions still don't conform to it.

But oh boy, they're sure jumping on the systemd bandwagon.

I see your point about environments. As a matter of practice I seek to diminish any differences between such environments. To me, such differences are bugs.

Finally, as to documentation, there is a threshold beyond which documentation cannot be improved, but only scrapped entirely and started again from scratch. Systemd is so far past that threshold it's ridiculous.