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