Slashdot Mirror

← Back to Stories (view on slashdot.org)

Devuan's Systemd-Free Linux Hits Beta 2 (theregister.co.uk)

Posted by EditorDavid on from the forking-the-road dept.

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".

39 of 338 comments (clear)

  1. Init alternatives by ArmoredDragon · · Score: 2, Insightful

    Do any of these alternatives offer the same speed benefit of systemd? Serious question as I've never tried to replace the init system on any linux distro.

    1. Re:Init alternatives by drinkypoo · · Score: 5, Funny

      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.'"
    2. Re:Init alternatives by Anonymous Coward · · Score: 5, Insightful

      And your non-systemd boot process will also be comprehensible and easy to troubleshoot.

    3. Re:Init alternatives by Anonymous Coward · · Score: 2, Informative

      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.)

    4. Re:Init alternatives by Sarten-X · · Score: 4, Interesting

      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.
    5. Re:Init alternatives by Sarten-X · · Score: 3, Informative

      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.
    6. Re:Init alternatives by ArmoredDragon · · Score: 2, Interesting

      Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?

      Well, on my home rolled NAS appliance, I really like the ability to reboot all of my VMs very quickly when applying security updates, because I'm not the only one that uses it.

      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.

      I personally don't have a problem with systemd. The thing is, there's so much damn drama over it that I'm curious what its detractors want to use in its place. And why are some people going to go out of their way to say "you don't need a faster boot time" when they don't know my use case? Furthermore, with the way I hack my Android smartphone, I'd love it if it booted faster.

    7. Re:Init alternatives by drinkypoo · · Score: 2, Insightful

      The truth is that the boot speed improvements of systemd are effectively notional. The boot process is so fast now that starting in parallel only saves you time when something goes wrong. If you regularly have a problem during boot, then you should think about fixing that regardless of what your init system is.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    8. Re:Init alternatives by I4ko · · Score: 5, Funny

      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.

    9. Re:Init alternatives by Anonymous Coward · · Score: 3, Informative

      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 ;)

    10. Re:Init alternatives by Sarten-X · · Score: 2, Interesting

      Well, on my home rolled NAS appliance, I really like the ability to reboot all of my VMs very quickly when applying security updates, because I'm not the only one that uses it.

      A fair point.

      The thing is, there's so much damn drama over it that I'm curious what its detractors want to use in its place.

      Typically sysvinit or mostly-compatible equvalents. From my perspective, they don't want to learn something new, and they don't see the existing system as broken.

      And why are some people going to go out of their way to say "you don't need a faster boot time" when they don't know my use case?

      The obligatory XKCD applies. Most boot processes are fast enough now that it's not really worthwhile for an end user to shave a few seconds off the time. On the other hand, doing something as a hobbyist is entirely about wasting time, so I won't hold that against you.

      The biggest improvement over antique boot systems is going to parallel boot chains. Rather than running scripts one at a time, in order, a tree is built to determine what services are dependent on what other services. For example, it doesn't make sense to start the SSH server until the network is live. There are several init systems that do this, differing mostly in how they define dependencies. Some rely on specific services ("openssh-server relies on network") while others work on more generic capabilities ("remote-shell relies on network, and openssh-server is what we'll use for remote-shell").

      After parallelism, it gets tricky and subtle. Maybe we don't need all of a service to start before its dependencies. For example, we don't necessarily need all of our DHCP leases assigned before we know which network interfaces are connected. That requires a more granular service definition, but provides a lot more power, especially for systems with very complicated startup procedures. With that power, we can shave a few more seconds off the boot time, because we aren't required to wait while services settle, improving our overall parallelism. That's useful for me (professionally, I build systems that boot with a strict time limit, and may reboot every few hours), but most folks don't really benefit with the added complexity.

      Furthermore, with the way I hack my Android smartphone, I'd love it if it booted faster.

      I don't know much about Android init, but I think it uses its own system unrelated to systemd, sysvinit, or any of the alternatives listed in TFS.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    11. Re:Init alternatives by Sarten-X · · Score: 4, Insightful

      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.
    12. Re:Init alternatives by Sarten-X · · Score: 2, Insightful

      It sounds like you should be looking into your high-availability architecture, not your init system.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    13. Re:Init alternatives by Sarten-X · · Score: 3, Insightful

      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.
    14. Re:Init alternatives by fnj · · Score: 4, Insightful

      [OpenRC] supports parallel startup processes

      Except for one little problem. Gentoo Bug 391945: "boot can hang when rc_parallel=yes".

      Reported 2009. Current status 5 years later: "CONFIRMED".

    15. Re:Init alternatives by fnj · · Score: 2, Insightful

      In the spirit of "Do one thing and do it well", systemd's goal ...

      BWAHAHA!

    16. Re:Init alternatives by Anonymous Coward · · Score: 3, Informative

      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 ;)

    17. Re:Init alternatives by johannesg · · Score: 2

      How come there is so much noise and heat about a small piece of software that runs maybe 2-3 times per year?

      All of this is anger, just to be angry. It serves no purpose other than giving you that heady rush of Socially Justified Rage. And as the great master said, it only leads to suffering...

    18. Re:Init alternatives by gweihir · · Score: 3, Insightful

      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.
    19. Re:Init alternatives by Threni · · Score: 2

      > In the spirit of "Do one thing and do it well",

      That's generally a good idea but it's wise to consider whether sometimes a better solution is arrived at via integration of multiple pieces of functionality. One of the things I've really enjoyed lately is neovim. It's essentially vim, but amongst the improvements is a built in terminal. Why not use vim (or neovim) and tmux? Because having the terminal built in is just better, that's why. No need to install and configure the apps separately, and when you're using neovim on multiple platforms, that saves me time.

      It has to be said that most major distros are using systemd. If you want to use this one, better hope it's supported for the lifetime of whatever project you're using it for.

    20. Re:Init alternatives by donaldm · · Score: 2

      The major issue people are concerned about is that things will be built on top of systemd (and they have been built on top of systemd), and then you have a huge unrelated dependency on this init system which makes it hard to swap out in the future if you want to use containers.

      I have been running Fedora before systemd (2010) was introduced and have never had an issue with it. I am now running Fedora 25 without any issues. Since my OS is on an SSD I can power up then login in then start my applications within less than one minute.

      Just for you I started up my systemd configuration GUI and you can for "Units" and "User Units" see the following "Load State", "Active State", "Unit State" and "Unit". If I want I can "stat", "stop", "restart" and "reload" a unit as well as being able to "edit" and "isolate" a unit. There are plenty of other options available for you but I would suggest reading up on them.

      Basically screwing up in systemd is pretty much the same as screwing up in an init system and instead of whinging about it, fix it.

      --
      There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
    21. Re:Init alternatives by Anonymous Coward · · Score: 4, Informative

      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.

    22. Re:Init alternatives by Anonymous Coward · · Score: 4, Insightful

      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.

    23. Re:Init alternatives by pz · · Score: 3, Insightful

      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.
    24. Re:Init alternatives by Antique+Geekmeister · · Score: 5, Insightful

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

    25. Re:Init alternatives by flyingfsck · · Score: 2

      "Any program grows until it can send email" - Ancient American Proverb, circa 1980. So systemd clearly still has a ways to grow.

      --
      Excuse me, but please get off my Pennisetum Clandestinum, eh!
    26. Re:Init alternatives by Anonymous Coward · · Score: 2, Insightful

      In the spirit of "Do one thing and do it well", systemd's goal ...

      BWAHAHA!

      You just don't understand the one thing that systemd is aspiring to do: replace.

    27. Re:Init alternatives by dbIII · · Score: 2

      In the spirit of "Do one thing and do it well"

      Doesn't fit, systemD is an octopus that grabs hold of something new before the old bits are stable. Didn't you see the article about how it is going to fuck about with shells and kill background jobs just because the user has closed their shell? That's not doing it's thing and it's definitely not doing it well.

    28. Re:Init alternatives by Pentium100 · · Score: 2

      While I did not have a lot of problems with SysV or Systemd, I wish I could make Systemd boot sequentially. Once I spent quite a bit of time troubleshooting a problem where a zpool would not mount at boot time. It turned out that the controller for the zfs hard drives was initialized too late for the boot process (system drives were on a different controller). This never happened with SysV and I wish I could set Systemd to mimic this as well, even if it adds some seconds to the boot time of a server I reboot once a year.

      Debian jessie does well to hide Systemd. The usual commands work and I usually forget Systemd is even there, unless there is a race condition or I forget to do a "systemd daemon-reload" after editing some files in /etc/default/

    29. Re:Init alternatives by Bing+Tsher+E · · Score: 2

      that's where development stagnated

      More flippant handwaving in usage of words that shows a lot about weakness in your argument.

      Development 'stagnated' only implys development needed to continue. Now, we all know that everybody wants their email address in important headers in the software project, so everything needs to be ripped out and replaced at whim on a regular basis.

      But things aren't 'stagnant' unless there's a reason for something newer to replace them. Has the development of new cinder block designs 'stagnated' because nobody has designed a new cinder block for probably a century? No, the existing design is fine and doesn't need replacement.

      I don't think the argument has ever been that "old means bad".

      In the case of people like the Lentard, the argument is 'I wasn't in charge when it was put in place.' Obviously the dude knows better than anybody else.

    30. Re:Init alternatives by skids · · Score: 3, Informative

      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.
    31. Re:Init alternatives by ausekilis · · Score: 2

      It's probably the most cost-effective way to get back in the game. Back when it took 45 minutes to install and another few hours to configure the OS, it made sense to try to troubleshoot. Now it takes 5 minutes to install the OS, and with package managers (and assorted partition setup), you can be up and running in 10 minutes. Will it take 10 minutes to fix? no? re-install.

    32. Re:Init alternatives by lsatenstein · · Score: 2

      Please unconfuse me, is the "it" in your opening sentence referring to Systemd or the Init system.

      Like all new replacement functionalities, there are teething problems. Already, systemd is stable and easy to use as a system management tool.

      I find systemd just fantastic, considering it's age and the progress made.

      I guess, thats why SUSE' RedHat, Ubuntu and Debian have evaluated systemd against their existing init system and made the switch. Resistance to change reminds me of the expression.

      When the only tool you have is a hammer, everything looks like a nail.

      --
      Leslie Satenstein Montreal Quebec Canada
  2. lol! "entanglement" is right! by tlambert · · Score: 5, Insightful

    lol! "entanglement" is right!

    What did Einstein call quantum entanglement?

    "Spooky action at a distance".

    What better way to talk about systemd...

  3. Re: Libre by RLaager · · Score: 3, Informative

    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.

  4. Re:So almost up to Slackware standards? by Anonymous Coward · · Score: 2, Funny

    > Slackware
    Correct

    > Slackware still
    VERY correct

    > Slackware still works
    MOSTLY correct

    > Slackware still works great
    For certain values of "great"

    > Slackware still works great, and has never had systemd.
    True, but they aren't on record saying that they won't.

  5. Re:Libre by cfalcon · · Score: 2

    The fact that Debian doesn't meet Stallman's standards is a problem with Stallman's standards. Trisquel gives you what you are looking for, but when you can't use your hooble-dooble because the company is a bunch of apes that never made a FOSS driver, you'll be angry at the company, and a little angry that you didn't bend for just that one thing. You can run Debian as a fully free software Linux build, why is that not good enough? Because you could, if you wanted, not do that?

    Their rationale on not including some of these- which dot a bunch of "i"s and cross a bunch of "t"s- is just very rms:
    https://www.gnu.org/distros/co...

    Basically, if there's a clearly labelled option to use nonfree / proprietary dudes, that disqualifies you. I have never met a single soul in person who finds that distinguishment useful, and outside of the FSF I suspect it is a rare opinion indeed, even among folks who jump through the requisite hoops to run only free software.

  6. Re:It's a question of mindsets by Casandro · · Score: 2

    I may be wrong, but isn't it that systemd also depends on things like dbus?

    And again the problem is the mindset. Even though it might be possible to run systemd in a sane way, distributions now package it with all sorts of crap. The opposition against systemd is not about systemd itself, it's about people who constantly try to re-invent the wheel while not having understood the problem or how to solve problems in general. Just look at alsa and pulseaudio which were both attempts at fixing the previous state of the art... and making it somewhat worse. (i.e. Alsa created unfathomable device names which were written differently in every application instead of the simple /dev/dsp OSS provided, or pulseaudio added crap like software mixing so you'll enjoy the fun of quantisation noise while it won't allow you to automatically switch the number of output channels based on the number of channels your software outputs)

  7. Re:It's a question of mindsets by Kiwikwi · · Score: 2, Informative

    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.