One software freedom that Stallman does not mention is the freedom *not* to use the program because you dislike or don't want it for some reason

Free software tends to be flexible, have clear boundaries, split responsibilities, and replaceable components, thanks in part to openly defined protocols and formats

Proprietary software tends to want to lock you in into their freaking ecosystem, and even if they adopt an open standard, it's a part of an E-E-E strategy

@Wolf480pl I'm a fan of systemd actually :) it is free software and it is quite modular, contrary to some beliefs. Different distros ship with different sets of systemd components. Wouldn't hurt for it to be even more modular, such as supporting elogind (being able to use logins without systemd the PID 1) upstream.

Last time I checked, systemd had no open standards (maybe except unit file format). libsystemd's API is the only thing you're supposed to depend on, and the communication methods used for socket activation, startup notification, communication between udev and systemd, communication between systemd and logind, etc. are declared as implementation details and subject to change without notice.

Also, things like systemd-networkd, systemd-resolved, systemd-timesyncd, etc. look to me like a blend of EEE and scope creep.

@Wolf480pl what? systemd (the PID 1) spawns your process using Unix's standard fork() + exec(), and passes you journal fd as standard IO, and socket fds using the standard Unix fd passing. Most public APIs of systemd components are even exported as clearly documented D-Bus interfaces. Honestly some projects could learn from systemd :)

>socket fds using the standard Unix fd passing

But you don't know which fds these are, and how many there are, and you're supposed to use sd_listen_fds and SD_LISTEN_FDS_START from libsystemd to find out.

Of course SD_LISTEN_FDS_START is just 3, and sd_listen_fds just reads an environment variable LISTEN_FDS. But IIRC systemd devs consider this an implementation detail and reserve the right to change it any time.

And then, unless your service is of Type=forking (which is "deprecated"), you're supposed to tell systemd when you're done starting up by means of sd_notify.

Which just writes something to a socked specified by NOTIFY_SOCKET env var, but again, that's implementation detail / subject to change.

Last time I checked, all these env vars were not standardized and subject to change. But that was long time ago. Have they since standardized it, and committed to not breaking it? Because that'd be really nice.

@Wolf480pl exactly, it's just 3 and those env variables. I didn't get the impression that these are the internal implementation details / subject to change without notice. That same blog post actually encourages you to reimplement them yourself if you don't want to use sd_* utilities:




"Eventually we plan to turn this into a proper shared library, however using the drop-in files allows you to compile your project in a way that is compatible with socket activation even without any compile time dependencies on systemd. sd-daemon.c is liberally licensed, should compile fine on the most exotic Unixes and the algorithms are trivial enough to be reimplemented with very little code if the license should nonetheless be a problem for your project."


I've only seen one daemon do that, everyone else just falls for the libsystemd bait.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!