GSOC Project Works To Emulate Systemd For OpenBSD

An anonymous reader writes Through a Google Summer of Code project this year was work to emulate systemd on OpenBSD. Upstream systemd remains uninterested in supporting non-Linux platforms so a student developer has taken to implementing the APIs of important systemd components so that they translate into native systemd calls. The work achieved this summer was developing replacements for the systemd-hostnamed, systemd-localed, systemd-timedated, and systemd-logind utilities. The hope is to allow for systemd-dependent components like more recent versions of GNOME to now run on OpenBSD.

Comments

Huh?

[Richard_at_work]

Why the hell is a GUI system dependent on a low level system control daemon?

Re:Huh?

[Noryungi]

Thank you, you have just summed up the abomination that is systemd for all of us.

Re:Huh?

[Anonymous Coward]

Because the user of a GUI will want to touch hardware (mount a USB stick, use an audio device, suspend to RAM, configure a wireless network ...) and all of those interactions need some form of permissions broker. The current approach of having a hundred different command line utilities being called from the GUI (and then not working because their command line output has changed yet again) scales very badly and is the reason why linux has a (fairly well deserved) reputation at being hopeless for doing simple things like letting a desktop user use the usb stick they just put in, dealing with audio devices etc...

Fixing that requires an integrated approach. Layers of crappy shell scripts calling yet more layers of crappy shell scripts calling some binary that then calls some shell script that then pokes something into /sys IS the problem.

You'll also find that systemd is indeed quite unix-like. It's about a reduction of code duplication. It's about consolidation of functions into one implementation that *does* work as opposed to 20 half-arsed implementations that do not. It's about providing what amounts to a library for daemons ... and libraries are deduplication are good things while reinventing wheels in every single application is bad, right?

For an application to effectively use these libraries and reduce the amount of code duplication across kde/gnome/xfce/lxde/... it has to actually have access to that code, which means that the thing that provides the code needs to be available. That means that the relevant systemd *component* is there -- and much of this is managed by logind.

How about then backporting from BSD to Linux?

[Anonymous Coward]

If BSD's emulation of those Linux systemd APIs is done in a reasonably portable manner, we could then backport the code over to Linux and gain the benefits without being dependent for those functions on the engineering disaster that Lennart has put into process slot 1.

The BSD folks aren't succumbing to systemd's problematic "kitchen sink in slot 1" approach, so their work could be valuable for those Linux distros that are fighting to keep systemd out of their hair.

Re:Er?

[koinu]

The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).

Locale settings are fine without system-level settings. What is wrong with application-specific LC_xxx settings? And why should I be interested in changing locale in the middle of a desktop session?

The systemd-timedated does almost the same for the date and time.

What?! Who the hell changes time on computers? This is not a $5 digital watch! Every reasonable system has got ntpd installed and is set to UTC. The rest is done by selecting the time zone you are in. And stay away from changing time zones by adjusting time! We are not in Windows world where time handling has been fucked up entirely.

And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.

Why do I need a daemon to log out from a session?