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.
... there goes that refuge then ;)
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?
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.
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.
Seriously, please do some editing before posing.
That just has to be a Freudian slip
Read them and weep: http://www.reddit.com/r/linux/...
TL;DR? Essentially, KDE may end up switching to systemd. Because Gnome (and every other Linux fan-boi) does it.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
So the rumors were true that in V2.0 systemd would finally offer integration with ntoskrnl.exe, along with rewrite to take full advantages of the CLR.
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.
Not sure about that, but they are inventing a new way to run services. They will have a new program called daemonhostd which can host multiple services. All you have to do is recompile sendmail and apache as shared object libraries and daemonhostd will dynamically load and run them in the same process to save resources.
As a further refinement, they are also writing kdaemonhostd which is exactly the same but it all runs in kernel space to improve performance.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Ah no, you are bringing facts into this discussion? How dare you! :-)
Thank you, actually.
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?
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.
because Desktop Environments DO interact with the lower systems.
They need access to the DRM and input device, they need access to things like reboot/shutdown/hibernate.
If I understand it correctly one goal of logind is to run the X-server and the Desktop Environment without root, so they cannot do this directly... they use the logind API for it.
OpenBSD truly adheres to "KISS", especially regarding simple configuration files. Exactly of what systemd isn't.
Uh, what isn't simple about configuration in systemd?
The article mentions logind. Here is my logind config:
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RemoveIPC=yes
Just what about that isn't simple? The defaults are basically how most unix-y systems behave anyway, and you can set things like what happens if a user logs out and leaves some processes behind, what happens if somebody pushes the power button, what happens if the console is idle, etc?
And the functionality of this daemon seems like the definition of "do one thing well." If it didn't have systemd in the filename people would be arguing that "systemd should be more like this."
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.
Biggest myths of systemd:
Systemd is a necessary replacement for init.dSystemd is not necessary at least not for the greater majority of Linux users, nor is it a simple replacement for init.d. Systemd does far more than replace your system startup, replacing just about every system daemon it can- including inetd, logind, syslogd, udevd, and it does so in as incompatible way as it possibly can. Binary log files for example break every utility or app which depend on scanning log files (eg. tail -f logfile | grep ...).
Systemd is a result of careful needs analysis and planning by a mature team of developersNope. In Poetterings on words (Apr 2010) initial announcement: "Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia."
In other words, the requirements specification, scope, analysis design, initial implementation all belong to Mr Poettering. Quite impressive for one chap.
Systemd is similar to upstartUpstart did a small fraction of what systemd does, as described a year after the initial announcement. Upstart was restricted to indeed simply replacing init.d, and did so in as unobtrusive a manner as possible. You may as well compare apples to oranges, as compare upstart to systemd.
It seems to me that the referenced article, ostensibly debunking systemd myths, is an exercise in raising red herrings in quick succession, and just as quickly flattening each one. The real problems are brushed under the carpet.
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?
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.
The problem with logind is that you do not communicate with it like you communicate with everything else in a UNIXy system. It has an API, which is not fixed, and logind in turn relies on API's to communicate with other parts of systemd.
None of the chunks in systemd do one thing, do it will and provide a UNIXy way to assemble them together. They're a huge blob of interdependent API's.
And yes, if it wasn't part of this API infested mess people would indeed be arguing that systemd should be more like it. But unfortunately that is not the case.
Wait, who actually needs to do those things?
Desktop applications.
For example, you change time zone or locale in system settings and your organizer app automatically picks up the changes.
And if the services do not depend on systemd, why are they part of the package?
Pottering is maintainer of all of them. So he brought it under the systemd umbrella.
Sounds like a made-up scenario and some bad packaging. Not a real-world need.
Applications "need" the services. They do not care who provides the services. As was said many times, the daemons - with few irrelevant changes to the source code to remove hardcoded systemd depedency - run fine without systemd.
Certainly fits the systemd reputation for taking over already-solved problems without any reason, though.
Yes.
Pottering also enjoys the confusion he has seeded with the organization of the systemd. He claims simultaneously (depending on the context; and to his advantage) that systemd is modular and monolithic. While in fact systemd has monolithic architecture and modular design. Pretty much the worst combination possible - prominently featured in the MSWindows, why comparison with Windows is highly relevant. (Ideally you want modular architecture, while design could be either monolithic (e.g. Linux kernel, optimized for performance) or modular (e.g. GIMP with the tons of the plug-ins, geared toward extensibility). But monolithic architecture is pretty much the worst thing you could ever do to a software project.)
All hope abandon ye who enter here.
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
Anyone who has ever tried running BackupExec Linux agents is well familiar with stopping the service 32 times while the process merrily continues running in a borked state, only fixed with a "killall' command.
Again: I dont really have a horse in this race, but if systemd truly can guarantee that a service stops when it says it does, thats where Im placing my bets. Its absurd that the service system in Linux fails so badly in that regard.
Where, exactly, do I state that I am putting a GUI on a server? Perhaps you got confused when I mentioned Gnome requiring SystemD as an example of how applications making SystemD a dependency was forcing distros into a Hobson's Choice of either adopting SystemD whether they want to or not, or going through a lot of pain to replace it with an alternative when it breaks major dependencies like Gnome? RHEL, like many distros, includes Gnome - but how many of those distros have adopted SystemD mostly as a result of this, not because it is better or worse than the alternatives?
Note also that I point out that the dependencies work in *both* directions; as antientropic points out Gnome requiring SystemD is absolutely an issue with the Gnome team and nothing to do with SystemD, but it does have implications in that it helps build a mess of inter-dependencies that is making it increasingly hard to strip systems down to the minimum. RHEL's insistance on NetworkManager by default, with all the baggage that brings, doesn't inspire confidence either, as this is apparently one of the next daemon in SystemD's sights - maybe SystemD can improve it, but I'm not holding my breath.
Anyway, regardless of that, we've made our choice and moved to BSD; SystemD played a significant part in that, but it definitely wasn't the only factor, as I noted in my OP. ?
UNIX? They're not even circumcised! Savages!
By what strange theory does Slackware support systemd? And how is the conversation being "held back"? At least on LQ, I think it's been discussed to death to the point where there's really nothing new to say about it.
I can say one thing for certain: you do not know that anything concerning systemd in Slackware is likely or not. Hell, *I* don't.
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?
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
Anyone who has ever tried running BackupExec Linux agents is well familiar with stopping the service 32 times while the process merrily continues running in a borked state, only fixed with a "killall' command.
So you're "fixing" a bad application by changing the OS?
Apparently that's the "preferred solution" now... to me it seems to make far more sense to fix the application (BackupExec) to work the way it should, but that type of "logic" apparently doesn't apply to the systemd people who think that the "proper" way to fix that is to write a complex init system replacement and continue to allow people who write shitty service/daemon code to continue writing crappy code.
MATE? Xfce? LXQt?
For small numbers of megabytes, and tens of kilobytes
in text size the systemd executable is about 1Mb and init about 30Kb. (systemd is bigger in reality as it uses more shared libraries.)
Running sizes: init (Debian, amd64)
john@cedric:~$ ps -lyp 1
S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD
S 0 1 0 0 80 0 532 2089 ? ? 00:00:32 init
And systemd:
john@celtic:~$ ps -lyp 1
S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD
S 0 1 0 0 80 0 3816 48691 ? ? 00:00:15 systemd
Systemd's resident size is less than 8 times init's.
(Fucking slashdot - why won't you get the spacing right)
Watch this Heartland Institute video