Slashdot Mirror
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.
Why in God's name would you want to infect well designed OSs with Systemd ?
That's unbelievably stupid.
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)
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)
Why the hell is a GUI system dependent on a low level system control daemon?
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.
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.
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
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?
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!
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.
> 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.
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.
So you point to the "debunk" written by Lennart? He's hardly a fucking unbiased source. Do you use Fox News for your refernces in other sphere's of life?