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.

@bugaevc
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.

@bugaevc at the end of the day, systemd does pretty bad on the "freedom not to use it" front, IMO.

@Wolf480pl well, hello there from a Linux-based system that doesn't use systemd :)

@Wolf480pl also, hello from a GNU system that doesn't use systemd (or Linux)

@bugaevc
I didn't say it fails completely, but I suspect it places a lot of burden on distro maintainers who want to support non-systemd inits, comparable to that of using non-gnu libc.

@Wolf480pl distro maintainers should just chose which one init system their distro uses and support that. I know Debian and Gentoo want to support all the different configurations, but that's up to them.

(1/)

@Wolf480pl My point here, as far as "freedom not to use" goes, systemd doesn't require individual services to be written in some systemd-specific way (e.g. as dynamically loaded plugins with some entry points, against systemd-specific API/ABI). No, they're just plain Unix executables launched as any other executable. They don't have to care if they're started (and watcher over) by systemd, another init system, from an interactive shell or whatever.

(2/)

@Wolf480pl (That, and systemd also provides sysvinit's config format compatibility.)

This is why you can run pretty much anything that wasn't explicitly written against systemd (and often predates systemd) with systemd. This is why you can pretty much just swap out init systems and have all the services work the same. I imagine the situation on Windows is much different (though I don't know too much about Windows internals).

(3/4)

Follow

@Wolf480pl If a service wants to make use of systemd features such as socket activation, than indeed it needs a small systemd-specific codepath that checks if it's even running "on systemd" and does the appropriate setup. But again, this works without systemd (as a no-op) and you don't need this with systemd (but you won't get some niceties).

(4/4)

@bugaevc
> not a dynamically loaded shared library with systemd-specific entrypoint

> not as bad as Windows

Let's not have such low standards. Just because something isn't mind-boggingly horrible, doesn't mean it's good.

>systemd doesn't require individual services to be written in some systemd-specific way

But encourages them to do so.

That, and

>That, and systemd also provides sysvinit's config format compatibility.

is exactly how embrace-extende-extinguish works.

Everything written without systemd in mind will work with systemd.

Anything written with systemd in mind, linking to libsystemd (and, in case of desktop environments, probably also using some systemd's d-bus APIs) will not work without systemd.

@Wolf480pl no. Services aren't written, and aren't encouraged to be written in systemd-specific ways, they're just plain old Unix executables, and any plain old Unix executable can be run as a systemd service.

(1/2)

@Wolf480pl systemd integration (sd_listen_fds and such) should of course be hidden behind an ifdef & a build time option that controls that ifdef and adds or removes libsystemd to the list of dependencies. And again, even if a service is built against libsystemd, it's a no-op at runtime unless systemd (or another service manager using a compatible API) is in use.

(2/2)

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!