Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Open Source Operating Systems Linux

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

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".
This discussion has been archived. No new comments can be posted.

Devuan's Systemd-Free Linux Hits Beta 2

Comments Filter:
  • Init alternatives (Score:3, Insightful)

    by ArmoredDragon ( 3450605 ) on Sunday December 04, 2016 @12:48AM (#53418161)

    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.

    • by drinkypoo ( 153816 ) <martin.espinoza@gmail.com> on Sunday December 04, 2016 @12:58AM (#53418193) Homepage Journal

      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.

      • by Anonymous Coward on Sunday December 04, 2016 @01:06AM (#53418211)

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

        • Re: (Score:3, Informative)

          by Sarten-X ( 1102295 )

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

          • 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 reboo

        • by gweihir ( 88907 ) on Sunday December 04, 2016 @04:21AM (#53418673)

          Ok, that may waste time. Everybody knows that reinstalling is the way to go on boot-problems, right?

          • 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.
        • Re: (Score:2, Insightful)

          by thegarbz ( 1787294 )

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

          +5 Funny. Now if you'll excuse me I have to go back through hundreds of log files and filter through init scripts with 1000s of lines to find out why something's not working.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        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 an

        • I don't know if Devuan supports it, but OpenRC is an alternative init system...

          ...viable alternatives like sinit, openrc , runit, s6 and shepherd. All are therefore included in Devuan.

          Not to be a dick, but the answer is right there in the description. You could take just a few more seconds before rushing to reply.

        • by fnj ( 64210 ) on Sunday December 04, 2016 @03:27AM (#53418575)

          [OpenRC] supports parallel startup processes

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

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

      • Re: (Score:3, Informative)

        by Anonymous Coward

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

        • Corner cases such as...??

          • by dbIII ( 701233 )
            A wireless USB mouse dongle is plugged in :(
            I'm not joking.
            Something so incredibly trivial hung the thing consistently as it attempted to start a systemD service to handle it, failed and did nothing - on several machines after an "upgrade" to a distro with systemD.
            Where is the parallel init that Lennart promised?
            No second thread doing stuff and no giving up and going onto the next thing like a production quality init system.

            I've seen others but that was the most recent
    • Re:Init alternatives (Score:5, Interesting)

      by Sarten-X ( 1102295 ) on Sunday December 04, 2016 @01:21AM (#53418273) Homepage

      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.

      • Re: (Score:3, 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 sm

        • Re: (Score:3, Insightful)

          by drinkypoo ( 153816 )

          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.

        • Re: (Score:3, Interesting)

          by Sarten-X ( 1102295 )

          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 [xkcd.com] 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 paralle

          • by pz ( 113803 ) on Sunday December 04, 2016 @09:00AM (#53419287) Journal

            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.

            • You're reading far too much into one word. You should try reading the rest of that paragraph.

              The first init systems were damned little more than just a shell. After that, we moved to running a single script at startup, and eventually went to runlevels with some common conventions. That's where development stagnated for a decade or two, and that's where I'm drawing my "antique" line. At the time, systems couldn't handle multitasking very well (mostly in terms of race conditions and programmers' sanity), and

              • 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 desig

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

                  That's a very interesting analogy, since I'm currently in a Japanese hotel overlooking a construction site.

                  Rather than the typical cinder blocks, the bottom two floors are being built from large reinforced concrete slabs, about 1 meter by 3 meters, which interlock and periodically have apparently-plastic pieces. It definitely has increased the speed of construction over laying cinder blocks, and I suspect the slabs and plastic provide some means of safety in an earthquake.

                  Elsewhere on the technological spec

        • by dbIII ( 701233 )

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

          The old stuff still works better than the new thing in rapid development so the question is the other way around. The detractors (I'm halfway to being one despite or maybe because of using it on some systems) either think it isn't ready or think various parts are doing things the wrong way, plus the newbie level bugs are a bit offputting. A binary log unprotected from race conditions - what fun!

      • Re: (Score:2, Informative)

        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 i

        • Re: (Score:3, Insightful)

          by Sarten-X ( 1102295 )

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

        • by afgam28 ( 48611 )

          99.9999% (six nines!) is 31.5 seconds of downtime per year. If you get an outage, it's not reasonable to expect anyone to be able to investigate anything in 31.5 seconds, let alone fix it. So any system with six nines of availability must be architected so that it is a cluster of servers, with automatic failover. If a single server crashing can take out your availability SLA, then the system needs to be rearchitected.

          With 99.99% (52.56 minutes per year) of availability, having a backup server will still hel

      • Re: (Score:3, Insightful)

        by fnj ( 64210 )

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

        BWAHAHA!

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          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.

      • I think if it were just an init system, most people would be ok with it (or gripe a little and then move on, like with other alternative init systems that have existed in the past).

        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.
        • by donaldm ( 919619 )

          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

          • by dbIII ( 701233 )
            I had a lot of issues with systemD not working well with ZFS on Fedora. I've also had issues with things like ntp dying and systemD being convinced that it is still running.
          • Just for you I started up my systemd configuration GUI

            Wow, thanks. Why would you do that for me? How does it at all relate to my post?

        • Let's rephrase that: Linux finally has an init system that does something devleopers find useful enough to make their software use that functionality.

          How dare systemd be useful? It should stay as useless as all the rest, so that we can have more useless init systems and switch back and forth between those.

      • by Threni ( 635302 )

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

        • The FreeSWITCH [freeswitch.org] bunch have a useful saying: "Don't glue the Lego pieces together".

          A modular system is best enjoyed as a modular system. This is one of the most powerful things about unix systems, you can pipe the output of cat to the input of sed and feed that to a text file for editing by vi.

          I don't have a dog in this systemd fight, and I agree with another poster who thinks this is much drama over not much. It is a sea change in how to think about things, but I certainly do not miss hunting down a missing

      • by Antique Geekmeister ( 740220 ) on Sunday December 04, 2016 @09:28AM (#53419351)

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

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

        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.

    • by I4ko ( 695382 ) on Sunday December 04, 2016 @01:48AM (#53418341)

      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.

      • by fnj ( 64210 )

        There is no reason, even with the price of electricity in Europe to shut your computer down

        I'd say security-patching the kernel is a pretty goddam good reason.

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

        • by Anonymous Coward on Sunday December 04, 2016 @07:06AM (#53419045)

          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.

          • Only 3 dependencies. The fact that gnome depends on systemd is the gnome devs fault, its the choice they made. There were other options, including a bypass written by LP for them, but they chose actively maintained systemd-logind over the un-maintained consolekit.
      • Issues of systemd aside, all those computers switched on doing nothing use up a boatload of electricity when you total the amount. Not only that, but leaving a machine on allows plenty of time for potential hackers to have a crack at it - unless you specifically switch off networking when you leave it - plus counter to what people think, computer components do wear out when left on, not just fans and spinning disks but also the electronics. If you only use your machine once or twice a day its actually bette

      • > There is no reason, even with the price of electricity in Europe to shut your computer down, hence boot time is moot

        There is with Virtual Machines. You pay for uptime, a reboot is often necessary to add more storage or memory successfully to an existing VM, and even for local development VM's they take significant server RAM for their active kernels. For many VM's, proper nightly backup snapshotting also requires a short shutdown. Also, after activation of new services, it's often useful to reboot the

    • by gweihir ( 88907 )

      What "speed benefit"?

    • In my experience, Slackware is a lot (very noticeably) faster than Fedora on the same HW. I don't know whether it is due to systemd or SELinux or something else entirely, but if you need raw speed, then you seriously should consider going back to basics.
    • by dbIII ( 701233 )
      Since the parallel thing is a lie (I've had stuff hang which would never happen if it was true, and after looking around, sure enough, not parallel) it's likely that the alternatives are still faster than systemD on the same hardware.
  • My one question is logging....

    what did they replace SystemD with and how does it log ?

    the FAQ and the rest of the site is VERY bare...

    • what did they replace SystemD with and how does it log?

      Unless they tell you so, you should assume they did something sensible like use something syslogd compatible, and if you don't like it, you can switch to another one. From googling I get the idea it's rsyslog.

    • by sjames ( 1099 )

      Basic install uses SysV and rsyslog, at least that's what I got from the first Beta.

  • by tlambert ( 566799 ) on Sunday December 04, 2016 @01:34AM (#53418307)

    lol! "entanglement" is right!

    What did Einstein call quantum entanglement?

    "Spooky action at a distance".

    What better way to talk about systemd...

    • by GuB-42 ( 2483988 )

      We can say that of abstraction layers in general.

      • Apple has the same problem with launchd.

        In Apple's case, the trigger messages are not entirely asynchronous, as with systemd, but they may as well be, since the Mac ports being used most frequently do not have peer information available, and are (effectively) just integers.

        This leads to what I call the "on behalf of" problem.

        Something starts running. And you want to know *why*. Clearly, it;s running because someone requested one or more of the services it provides -- but there's no way to know who it is

  • Is there an option to install it with all non-free repositories disabled by default? As my man RMS says, Debian is better than Ubuntu because it at least segregates packages into free and non-free repositories, but still enables both by default. If the non-free repositories were disabled by default, GNU might finally have a modern distribution it could throw its weight behind.

    https://www.gnu.org/distros/fr... [gnu.org]

    My goal in running a GNU/Linux box is to not run a GNU/Linux box, and Debian and Ubuntu are really n

    • Re: Libre (Score:3, Informative)

      by RLaager ( 200280 )

      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.

    • by cfalcon ( 779563 )

      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 inclu

      • by fnj ( 64210 )

        The fact that Debian doesn't meet Stallman's standards

        Says who?

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

        I guess. I run a headless server, device drivers aren't much of a concern for me. My main concern is minimizing the amount of work I have to do maintaining the server, including security patches and updates to the latest version of source code. I hate was

        • I hate wasting my time.

          Oh, I LOVE it! Why, just now I find myself sitting on my butt reading this whole thread, for example.

  • We need a good vim versus emacs war here!
  • Greybeards?
    We may have been programming for longer than Lennart but there are plenty of people younger than him that don't make the same arrogant newbie mistakes about *nix.
    Somebody should give Lennart "The Cathedral and the Bazaar" to read since he missed it the first time. It's not difficult but for some reason he does not understand or care and wishes to change linux entirely.

Heisengberg might have been here.

Working...