Slashdot Mirror

← Back to Stories (view on slashdot.org)

GSOC Project Works To Emulate Systemd For OpenBSD

Posted by timothy on from the everyone's-idea-of-a-good-time dept.

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.

3 of 314 comments (clear)

  1. New Gnome? no thanks. by DMJC · · Score: 0, Flamebait

    Frankly I don't see much in the new Gnome that makes it worth bringing to any platform. I just wish the same effort being put into making broken UI concepts work on various gnu projects was put into GNUstep and GNU projects.

  2. Er? by lisaparratt · · Score: 1, Flamebait

    I would have expected that BSD would be deliriously happy that the evil gaze of Poettering hadn't alighted upon their operating system. Why would you voluntarily infest your system with his daemon spawn?

    1. Re:Er? by antientropic · · Score: 0, Flamebait

      Your post captures what most anti-systemd posts have in common: it spouts reasonably-sounding slogans ("Unix philosophy!", "dependency hell bad!") - which have nothing to do with how systemd actually works.

      Take the supposed dependency hell. In reality, systemd has a fairly small number of dependencies, almost all of which are already ubiquitous on a modern Linux system (e.g. libacl), and many of which are optional (e.g. PAM). Gnome depending on systemd is hardly systemd's fault - if systemd provides useful functionality that Gnome wants to use, then why does that count against systemd? In any case, it's irrelevant for your "stripped down and hardened server", because surely you're not running Gnome there.

      Or take the Unix philosophy. I'd say systemd (as in the PID 1 program) exemplifies the Unix philosophy: it does one thing, namely managing system services, and it does it really well. Now, systemd the *package* contains lots of other stuff, but most of it is optional. For instance, it does contain an NTP client now, but you don't have to use it. In fact, there even is a configure flag to disable it at build time. Also, the existence of systemd-timesyncd in no way prevents you from running whatever NTP client you want under systemd.

      The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone. It cannot even tell me if a service is currently running.) Systemd can. It cannot imagine going back to a situation where I can't do "systemctl" or "systemd-cgls" to get an overview of what is running on a system, or do "systemctl status " to see the status of a service, including its most recent log messages.