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.

26 of 314 comments (clear)

  1. Oh well ... by Xolotl · · Score: 3, Funny

    ... there goes that refuge then ;)

    1. 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?

    2. Re:Oh well ... by Kvorg · · Score: 4, Insightful

      Exactly, it would seem this will simply emulate the behaviour for applications that expect it, sitting on a DBUS interface. Since it now seems the whole systemd mess will not go away, I would assume this is the "correct" approach to manage it.

      I can only wish non-RH GNU/Linux distrost adopted the same approach.

      --
      -Kvorg
    3. Re:Oh well ... by dpilot · · Score: 4, Insightful

      I see systemd as the product of a culture clash between old and old-school Linux users/developers and new Linux users/developers.

      Linux was really derived from Unix, and in a very important way RMS has always been correct in insisting it be called GNU/Linux. Because "GNU's Not Unix" only in the licensing aspect. Philosophically, GNU really IS Unix.

      A few years back, Linus and Linux started getting a lot of attention in the computing and even general press. Linux started becoming cool and interesting. It started attracting new users, a new wave of early adopters, and since early adopters also tend to be developers, Linux attracted a new wave of developers.

      But these developers has a key difference - they had no Unix background. They largely came from Windows, simply because that's the largest source of developers, by simple demographics. But they weren't "fleeing Windows", they were attracted to Linux. They also brought their background, attitudes and preferences with them, and that includes a heave dose of "The Windows Way" and little to nothing of "The Unix Way."

      The result is systemd - the Windows Way ported on top of the Linux kernel.

      Then there is the demographics issue. The classical Linux market share has been so small and Windows so big that it doesn't take many Windows users/developers to swamp out the old school Linux/Unix camp. We're bing "conquered by demographics." They don't see anything wrong with systemd because it fits their background and world view perfectly - in fact it's a better fit for them than SysV Init is. There's also a bit of the Windows "One Way" attitude at work, attempting to push systemd across the board.

      Fortunately there are a few never-newbie distributions still around, and it seems that the old-school Unix users are congregating there and will keep them alive. Or there are always the BSDs..

      --
      The living have better things to do than to continue hating the dead.
    4. Re:Oh well ... by dpilot · · Score: 3, Insightful

      > the reality is systemd is a bunch of individual modules

      I disagree. Technically you are correct, but the same modularity argument can be made for practically any piece of code bigger than "Hello World". However in practice systemd is shipped as a monolith. I just checked, and even on Genoo with its uber-flexible USE flags and compilation from source, you can't shut off individual features like logging, dhcp, ntp, etc. Most people just install the binaries.

      No, systemd is not the end of the world. But it would be the end of running my machines the way I wish to - at least without spending more time and effort keeping it fenced in as you suggest.

      --
      The living have better things to do than to continue hating the dead.
    5. Re:Oh well ... by weilawei · · Score: 3, Interesting

      Not much chance of successful management when his idea of ignoring log corruption is to IGNORE it. Yes, literally, ignore it. Feature, not bug. In Poettering's own words,

      Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence.

      This guy shouldn't be allowed anywhere NEAR system software!

    6. Re:Oh well ... by BadDreamer · · Score: 3, Insightful

      You have the "linux way" (it is actually the Unix philosophy) completely wrong. It is not "one program for one task". It is:

      "Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable."
      -- Eric S. Raymond

      "Developers should design their programs to be flexible and open. This rule aims to make programs flexible, allowing them to be used in other ways than their developers intended."
      -- Eric S. Raymond

      "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
      -- Doug McIlroy

      What systemd does wrong is abandoning this and using API's internally - API's it does not even lock down. It's a morass.

      "Everything was small... and my heart sinks for Linux when I see the size of it. [...] The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design â" you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option."
      -- Doug McIlroy

      "Developers should design for the future by making their protocols extensible, allowing for easy plugins without modification to the program's architecture by other developers, noting the version of the program, and more. This rule aims to extend the lifespan and enhance the utility of the code the developer writes."
      -- Eric S. Raymond

      Yes, systemd IS the end of the world that many people want you to believe.

    7. Re:Oh well ... by gweihir · · Score: 3, Interesting

      Actually, systemd is all-or-nothing. If you let even a tiny bit in, countless things will break unless you take the whole POS. The developers are very keen on making sure of that.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Oh well ... by Endymion · · Score: 3, Informative

      The thing the inexperienced systemd developers (but I repeat myself) do not understand is that "modular" isn't about some technical detail such as how you compile various features. For example, busybox intentionally compiles everything into one big binary. The features it provides, on the other hand, are still very modular in the UNIX sense. The key difference is that the tools busybox provides ("cat", "wc", "mkdir", "dd", and many others) all implement well defined APIs.

      What is an Application Programming Interface (API)? It's not some function you can call, or the fact that a program understands some option ("--foo"). It is not even the documentation that may or may not be provided that describes how to use some feature. So what is it?

      An API is a PROMISE .

      It is a social feature, not a technical one. The functions, options, and documentation are just the technical implementation of that promise. The key part of an API is that it is a promise by the developer that if you want to interact with some feature, this is the way to do so, because while other internal stuff may change at any time, the promised API will be stable and reliable.

      The problem with systemd is exactly this. Pulling a n00b move and agglutinating various features into one project is annoying and not recommended, but it is not, on its ownn, a reason to avoid systemd. The problem came when Poettering stripped down the barriers betwen features with the specific goal of removing established APIs. His stuff may compile into various separate programs, but Pottering is very careful to keep various key interfaces "unstable", specifically to not make any promise about how those interfaces will work in the future. He likes to call this hididng of interfaces "efficency" or "removing complexity". What he never mentions is that many of us used those promises, and by removing them he has at best forced others to do a lot of work to fix the breakage, or at worse made various features impossible.

      A good example is logind, which was absorbed into systemd just so promises about its behaviuor in the future ("stable APIs") could be removed.

      The reason many of us that have been watching Poettering's cabal for many years now suggest these changes are intentional and malicious are based on this. Occasionally removing features because of a technical need or bug or security requirement is understandable. Purposfully stripping out entire sets of features - that is, the features that allow other groups to develop with confidence that some feature they won't simply vanish - is something entirely different.

      If MS acted like Poettering's cabal and removed a formerly-public API that competetors used - while promoting their own product that happens to use internal, not-publicly-promised APIs, the world would be screaming "monopoly". This happened, and resulted in several high-profile court cases.

      So go ahead an prove that you don't know what you're talking about and assert that systemd is in any way "modular", when non-modularity was an explicit goal behind systemd. The rest of us are choosing to not go along with Poettering's attempt to embrace and extend Linux into a cheap, buggy, feature-free windows clone.

      --
      Ce n'est pas une signature automatique.
  2. Re:Er? by Noryungi · · Score: 4, Insightful

    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?

    Because bloody systemd will be needed if you want to run some brain-dead Linux-only piece of crap software. That's why.

    Emulating systemd allows that software to work on OpenBSD. On the other hand, emulating it means that (a) its working may remain somewhat on the sane side and (b) that emulation will only be installed if the port requires it, therefore limiting the damage.

    And, FYI, OpenBSD could not care less about Poettering and his evil gaze.

    --
    The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
  3. Re:Ye Gods! by Noryungi · · Score: 4, Insightful

    Again, this an emulation of systemd - not the real ugly mess.

    This means that the normal configuration files will probably stay, but will probably be parsed on-the-fly (smartly, one hope) to provide some emulation.

    The reason this is interesting is that it may prove an escape hatch not just for OpenBSD, the other BSDs, but also for some (sane) Linux distributions that refuse to adopt systemd such as Slackware.

    --
    The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
  4. 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.

    3. Re:Huh? by drinkypoo · · Score: 3, 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.

      Right. We have multiple capabilities-based security systems available for use with Linux, and we have a pluggable authentication system, and now we need another system to handle privilege management?

      Fixing that requires an integrated approach.

      That's what Unix gives you. Because the system is made up of small pieces, you can recombine them in different ways to achieve your goals. The pieces are designed to integrate with one another.

      You'll also find that systemd is indeed quite unix-like. It's about a reduction of code duplication.

      We achieve that with shared libraries. There is no need for monolithic daemons which serve many purposes. Process creation is cheap on Unix.

      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.

      But in fact it's one half-arsed implementation that only works sometimes instead of 10 really brilliant implementations that almost always work, and 10 mediocre ones.

      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.

      Yeah, it's called a shared library.

      No one has offered an explanation as to what systemd gives us that we did not have before. There is not one single thing. And what we've lost is simplicity. systemd is the opposite of the Unix way.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  5. /etc/inittab by MrKaos · · Score: 4, Interesting

    and rc.d it's so simple. I'm still struggling to understand why systemd is required - what problem it is actually solving. Am I missing something?

    --
    My ism, it's full of beliefs.
    1. Re:/etc/inittab by Anonymous Coward · · Score: 3, Insightful

      The problem it solves is that currently you don't always need to hire RedHat to manage your large Linux clusters.

      While keeping hold of the top end, they are seeing the bottom end fall out from underneath them. And they have to do something to shore up that attrition of tomorrow's decision makers.

    2. Re:/etc/inittab by antientropic · · Score: 4, Interesting

      It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... for a nice overview of all the limitations of SysV init, the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.

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

  8. 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?

  9. Re:Ye Gods! by Sique · · Score: 3, Interesting

    You know that Gnome is actually a result of The GIMP and not vice versa? Gnome builds on GTK, which stands for GIMP Toolkit (and not Gnome Toolkit). Gnome is basicly a standalone version of GIMPs UI widgets.

    --
    .sig: Sique *sigh*
  10. Re:ntp is the line in the sand by gbjbaanb · · Score: 3, Interesting

    Its actually a very old way to run services. Windows has been doing it this way for years.

    Run process explorer on Windows, click on a svchost.exe process and see what services its running. It made more sense on Windows as a Windows process is more heavy than a Linux one, this is the same reason threads are more common on Windows compared to Linux's spawning processes to provide the same solution.

    Anyway, one issue is reliability - if you want to restart a borked Apache, you can tell it to restart, and if it doesn't you can kill it. Systemd, you'll have to kill the daemonhost that hosts the Apache service, and kill all the other running services too. Assuming the security model allows you to do that.

  11. Why Not? by Anna+Merikin · · Score: 3, Interesting

    Mebbe this will motivate some distro to do a similar; I, for one, would go for a distro without systemd nor Gnome, which I never use. Gnome is expendible. For those who like Gnome, why not do it this way?

  12. Re:Er? by Zocalo · · Score: 4, Insightful

    I have three main issues with SystemD that might help you understand where some of us are coming from:

    1. It effectively works as a monolithic replacement for several daemons, contra to core UNIX design tenets, and even though some of those sub-daemons can be swapped out with an alternative, often that works by running the second daemon in parallel - you can't actually disable the SystemD equivalent, let alone remove it altogether. This makes troubleshooting much more complicated when something goes wrong, especially if you have booted a system from a recovery disk to troubleshoot after a crash, compromise, or whatever and can no longer directly access several of the key sources of information necessary to do that.

    2. Because of the growing number of packages that depend on SystemD, and vice-versa, it's creating a huge mess of package inter-dependencies that mean that it's getting almost impossible to build a stripped down and hardened server. Ballmer might have been right with his "Cancer" comment, he just wasn't specific enough: Gnome requires SystemD, $distro wants to bundle Gnome, therefore $distro adopts SystemD - and forces the default install of all the other package dependencies that go with it, thereby increasing the attack surface of the system. So much for hardening systems by removing all superflous code, huh?

    3. All that cruft seems to be bogging the system down. We are currently migrating a large number (much larger than planned after initial results) of systems from RHEL to BSD - a decision taken due to general unhappiness with RHEL6, but SystemD pushed us towards BSD rather than another Linux distro - and in some cases are seeing throughput gains of greater than 10% on what should be equivalent Linux and BSD server builds. The re-learning curve wasn't as steep as we expected, general system stability seems to be better too, and BSD's security reputation goes without saying.

    That said assuming that it "just works" a SystemD based desktop with everything from a desktop application down to the kernel talking through the same set of core services does sound like a nice idea. The problem is that most of us are not actually running Linux desktops; we're running servers and would just like the OS to mostly get the hell out of the way so we can get on with running whatever server daemons we are using. If SystemD were better architected - say a core PID1 init replacement, then a bunch of optional packages I don't even need to install if I want to use an alternative or not bother with at all, plus a massive clean up of the dependency hell that it has introduced - then I'd be a lot happier with it, but as it stands I just can't see including it on a hardened Internet facing server as being a remotely sane thing to do.

    --
    UNIX? They're not even circumcised! Savages!
  13. 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.