Slashdot Mirror
Devuan's Systemd-Free Linux Hits Beta 2 (theregister.co.uk)
Long-time Slashdot reader Billly Gates writes, "For all the systemd haters who want a modern distro feel free to rejoice. The Debian fork called Devuan is almost done, completing a daunting task of stripping systemd dependencies from Debian." From The Register:
Devuan came about after some users felt [Debian] had become too desktop-friendly. The change the greybeards objected to most was the decision to replace sysvinit init with systemd, a move felt to betray core Unix principles of user choice and keeping bloat to a bare minimum.
Supporters of init freedom also dispute assertions that systemd is in all ways superior to sysvinit init, arguing that Debian ignored viable alternatives like sinit, openrc, runit, s6 and shepherd. All are therefore included in Devuan.
Devuan.org now features an "init freedom" logo with the tagline, "watching your first step. Their home page now links to the download site for Devuan Jessie 1.0 Beta2, promising an OS that "avoids entanglement".
Devuan.org now features an "init freedom" logo with the tagline, "watching your first step. Their home page now links to the download site for Devuan Jessie 1.0 Beta2, promising an OS that "avoids entanglement".
Do any of these alternatives offer the same speed benefit of systemd?
No, your system might boot two, or even three seconds slower than with systemd.
Actually, that's not necessarily true. I don't know if Devuan supports it, but OpenRC is an alternative init system that started with Gentoo (pre-systemd), but is now also available in other distros. It is written in C, and supports parallel startup processes, but it is *just* an init system, and sysvinit-style bash startup scripts need only very minimal modification to work with it. (You don't determine a fixed load order; you specify "depends" and "provides", which OpenRC uses to decide on a load order and parallel startup.)
Since my day job involves comprehending and troubleshooting init scripts, I'm going to assume that's sarcasm.
There are some good non-systemd boot processes, with nice clean service definitions... there have to be... please tell me there are...
You do not have a moral or legal right to do absolutely anything you want.
Well, on my systems, runit boots faster than systemd, and does not run into those corner cases systemd encounter that cause it to hang forever ;)
Ubuntu separates non-free stuff into restricted and multiverse (as opposed to main and universe).
Main and restricted are the supported packages. Universe and multiverse are unsupported packages. Here, "support" means paid technical support from Canonical and a security update promise (as opposed to best effort) from the Ubuntu developers.
The correct way is create services foo, baz and a bundle bar, and then
;)
$ echo baz >> bar/dependencies
$ echo bar >> foo/dependencies
You need to read the page more patiently. It's not the never-ending systemd documentation, and does not require much time to read in its entirety
Except that in reality there is no log of early boot messages with sysvinit. So the information to find issues is actually not there.
So with sysvinit, there is a *guarantee* that the diagnostic log messages do *not* exist. On the other hand, systemd logs these as well: this makes debugging boot failures way easier.
I may be wrong, but isn't it that systemd also depends on things like dbus?
Systemd uses the D-Bus protocol for communication (e.g. between the systemctl client and the PID 1 daemon), but a minimal systemd install does not require the D-Bus daemon. That said, you'll be hard pressed to find a Linux desktop systems or server without the D-Bus daemon (no matter what init system is in use), but it'd certainly be possible to build an embedded Linux system with systemd init, and no D-Bus daemon.
Even though it might be possible to run systemd in a sane way, distributions now package it with all sorts of crap.
Really? Ubuntu now ships with systemd service management and the journal (and, yes, udev and the D-Bus daemon, though those have been included for a decade or so). AFAIK, Ubuntu also uses systemd-logind (though it used that even before it switched to systemd init), and doesn't use systemd-networkd (but sticks to NetworkManager), nor does it use systemd's DHCP or NTP services.
There's tons more *useless* information in the systemd journal, and all the useful logging daemons usually do tends to be turned off by whoever wrote the default service file.
I really can't see how a system where a failed service doesn't bother to tell you it failed when started by hand from the command-line got anywhere popularity-wise. Seriously. Doing a "systemctll start blah" when blah enters a failed state doesn't say anything different than when blah starts successfully. What. The. Hell.
Also, I don't appreciate having to learn a bunch of directives only useful inside systemd unit files, named apparently by someone with really bad instincts for naming things. With a shell script, I can see a command being used, and if I do not know it yet, I can read the manpage for it, and here's the trick: I can then use that command for other stuff, not just running daemons.
Granted systemd is better at "structuring" the init scripts... is you need to manipulate them programmatically that's handy. Almost. Everyone. Does. Not. Need. To.
Someone had to do it.