Uselessd

Yeah, I'm not criticising it, but I expected an actual example .

The name is perfect and I do not see myself changing it. The fact that so many people misunderstand makes it better. The Linux Action Show thought we were calling systemd "useless" and went on a hilarious rant, there's people on LinuxQuestions.org who really insist that it's pronounced "use less dee" (I call it "uselessdee", as in it's of no use, personally).

It might be unprofessional in this context, but it did make me smile. The GNU project's political dedication is vital to the OSS world, but quality of code, documentation and usability often do feel like an afterthought. The minimalism of the BSDs, for example, always is a refreshing contrast.

(Don't get me wrong, I don't want to flame, I use GNU tools on a daily basis. Just when you know what they mean, the rather unexpected link is pretty funny.)

you must be a laugh riot at parties

Because systemd was entirely too consistent across environments, so it needed some inconsistency introduced.

The documentation reminds me a lot of Emacs's "ANTINEWS", listing all the functionality you lose by downgrading to the previous version of Emacs. Except in this case, it's actually a "NEWS" file, showing all the functionality you lose by downgrading from systemd to uselessd.

> Certain superfluous unit types removed, namely devices, timers, swaps, mounts and automounts.

So under uselessd a service or socket file cannot depend on the presence of certain mounts, for instance (RequiresMountsFor=). Nor can a service run maintenance tasks periodically with supervision on the maintenance task, and with all the privilege-dropping, isolation, and security features easily accomplished with a systemd service. (And even if a cron implementation implemented such features, they'd work gratuitously differently from systemd services.) Nor can the availability of a device trigger the reliable, monitored launch of a service with all those same systemd features.

> Setup routines for various MAC/ACL systems, including SMACK, IMA and SELinux, are gone. We want to stick to a more clearly defined purpose, one that is agnostic of such elements. Nonetheless, we have retained SELinux access routines in D-Bus APIs and unit options for SMACK attributes in socket unit files to respect existing configurations.

So anyone who actually wants to use such security systems is screwed, then. Good thing Linux isn't about choice.

> systemd-fsck has been replaced with a service file that starts /sbin/fsck to fsck devices. In essence, this isn’t much different from what systemd-fsck already did, but with the overhead of a middle man executable interfacing with /sbin/fsck cut out. This also means that the systemd-defined sysctl parameters for its fsck are gone, and you should use the old ones (/forcefsck, etc.) instead.

So now, in order to force a check of a filesystem on reboot, you must write to that filesystem, potentially doing further damage to it.