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.
There are some good non-systemd boot processes, with nice clean service definitions...
Agreed. There are plenty of them.
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 ;)
I'm not sure if that's a serious question or an attempt to troll, but regardless...
Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?
In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.
It most certainly is if you manage servers!
Most performance evaluations include an uptime requirement. Most businesses it is 99.97% uptime while some Slashdot readers it might be as high as 99.99% or 99.9999% if they work at Amazon or a Wall Street trading firm where any downtime costs millions a minute.
If servers randomly do things behind your back or you restart one during a standard change and it doesn't come back up and your change window is between 1am - 3am (like my employer) you can be in hot water if you can't get it back up if something weird happens during a patch or other activity. SystemD's benefit is it's downfall which is that is event driven. Let's say theoretically you can have SystemD launch tasks or do something in the event your network is hacked or if one of the NIC teaming cards fail. That sounds cool. Problem is if it fails and does something that crashes it.
I am learning FreeBSD now more after I stopped touching it in awhile. Sometimes boring but predictable non event oriented boot only procedures are bah but predictable and nice. You know what you are going to get. It's in that ugly RC script hack but hey you can debug it!
http://saveie6.com/
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.
There is tons more information in the journal and a lot less work to search it
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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.