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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
And your non-systemd boot process will also be comprehensible and easy to troubleshoot.
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.
You do not have a moral or legal right to do absolutely anything you want.
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.
lol! "entanglement" is right!
What did Einstein call quantum entanglement?
"Spooky action at a distance".
What better way to talk about systemd...
Are you seriously asking such a deranged question or just trolling? We don't live in the 90s any more.
There is no reason, even with the price of electricity in Europe to shut your computer down, hence boot time is moot. And considering since 2005 or the whereabouts most people are on laptops, and it is relatively not so hard to find one with a working ACPI, hibernation to disk is what people do. Actual startup should only be performed after kernel patching (and not in all cases necessary) or hardware changes. Which is about 2-3 times a year at most.
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 ;)
With all due respect, that comparison is awful.
In the effort to make an "apples to apples" comparison, it uses only the bare minimum of functionality from each toolset. There's no illustration of dependencies or capability control. It is useful for getting a rough idea of how the init systems' config files look, but not really as the basis for any kind of comparison, especially with regard to advanced features.
You do not have a moral or legal right to do absolutely anything you want.
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.
So let me get this straight... in order to say "Foo depends on some kind of bar, which happens to be baz on this system", I need to write a "bar" definition that actually runs "baz", and go modify a completely separate dependency file to add "foo".
...and you're suggesting this is clean?
You do not have a moral or legal right to do absolutely anything you want.
Except for one little problem. Gentoo Bug 391945: "boot can hang when rc_parallel=yes".
Reported 2009. Current status 5 years later: "CONFIRMED".
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
Ok, that may waste time. Everybody knows that reinstalling is the way to go on boot-problems, right?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
How come there is so much noise and heat about a small piece of software that runs maybe 2-3 times per year?
Point is, it is neither small nor it runs only 2 to 3 times a years. It's starting to be a giant squid of interdependant parts (gnome depends on systemd now) that runs constantly (the init is always running, not just at boot), that is basically a kernel on top of the kernel, trying to control everything in userspace and "be the glu" between everything, and from which most people can't run from.
The biggest improvement over antique boot systems ...
That there is the heart of the problem, an attitude that anything old is necessarily bad. That your otherwise calm and reasoned presentation allowed this pejorative to slip in belies the psychological bias that underlies the wide arguments on the subject.
Lest we forget, Linux as a whole turned 25 recently. That's antique. Are you giving up the entirety because it's old? Your favorite editor is probably (just based on popularity) is either emacs or vi / vim. They are very, very old (heck, I've been using emacs since the early 1980s!). Are you dumping them because they are old? I hope you see why calling something "antique" is ill-conceived.
Now to make sure that my point is being made clear, allow me to be explicit: old does not necessarily mean bad, but it does not necessarily mean good, either. Things that are old now were once shiny and new, and weren't necessarily an improvement when they were introduced. But change merely for the sake of change -- which seems to be what was behind debacles in KDE, Gnome, systemd, and Wayland to name a handful -- is wasted effort. For systemd in particular, the primary argument for using it seems to be parallel init, something that as many others have pointed out really isn't much of an issue these days since (a) Linux is generally stable enough that reboots are rare (although there are specific use-cases that benefit, like demand-based VM creation), and (b) computers have become generally fast enough that reboots are inherently speedy.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
> 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.
Systemd has also taken over network configuration with an unnecessary DHCP service, which it should _not_ have touched, automounting, and is now attempting to manage user processes with misfeatures that kill user processes silently, such as the default enabled "KillUserProcess" command. Please be clear that systemd is not attempting to _manage_ processes. It is attempting to directly manage almost _all_ system services, many of them by direct replacement with dangerously incompatible and modified systems.
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.