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