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.

8 of 314 comments (clear)

  1. Huh? by Richard_at_work · · Score: 5, Insightful

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

    1. Re:Huh? by Noryungi · · Score: 5, Insightful

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

      --
      The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
    2. Re:Huh? by Anonymous Coward · · Score: 5, Insightful

      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.

  2. Re:Oh well ... by Anonymous Coward · · Score: 5, Informative

    Not really.

      * This software is not going to end up in the base system but in ports. It will not have a big effect on the base system.
      * The goal of the project is not to import the systemd programs like the NTP daemon or the cron daemon. Instead, it implements some of the APIs so it will be easier to port software that depends on some systemd features.

    When the software is ready and ends up in OpenBSD ports, it will probably only be installed if you install a piece of software that depends on systemd (future gnome, for instance). So if you don't install these kinds of software, you don't even end up having "systembsd" on your computer.

    In what way is the refuge gone now?

  3. Re:Er? by ThePhilips · · Score: 5, Informative

    The three services are actually needed.

    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).

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

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

    The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.

    In no way the services itself depend on the systemd - they are simply part of the systemd package. Nothing more.

    --
    All hope abandon ye who enter here.
  4. How about then backporting from BSD to Linux? by Anonymous Coward · · Score: 5, Insightful

    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.

  5. Re:Er? by koinu · · Score: 5, Insightful

    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?

  6. Re:Er? by Anonymous Coward · · Score: 5, Informative

    The three services are actually needed.

    For what? If you say "to bring more windowsisms to linux" then I can believe it. Otherwise, not so much.

    The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.

    Unix (not so much linux) has for a really long time been a multi-user system, where multiple users can use different locales and different time zones. The system itself always ran on UTC. UTC is not supposed to change. Users changing their locale need to log out and back in again. That works well enough for the expected frequency of such changes occurring and doesn't need lots of code to notify every running process AND lots of code in every running process to deal with the change.

    As an engineering tradeoff, the Unix way makes sense to me. The poetterix way, not so much. So I don't really buy your "long overdue", no.