back to article Linux greybeards release beta of systemd-free Debian fork

The effort to create a systemd-free Debian fork has borne fruit, with a beta of “Devuan Jessie” appearing in the wild. Devuan came into being after a rebellion by a self-described “Veteran Unix Admin collective” argued that Debian had betrayed its roots and was becoming too desktop-oriented. The item to which they objected …

        1. Sam Liddicott

          Re: Init freedom

          I also regularly give a pittance to Devuan. It all adds up to the cost of a Windows DVD, so I'm glad they are succeeding.

    1. Doctor Syntax Silver badge

      Re: Init freedom

      "In short, some people didn't like a new feature so they used the free software to make a version they were comfortable with. This is perfect, however much you do or don't give a shite about systemd, you have to love that people have the tools to do what they want."

      My concern is that although they've been able to achieve this now there'll be a time when so much of the GNU/Linux userland assumes systemd is there that it becomes impracticable to build a distro without it.

      My other concern is that the whole approach of the systemd/opendesktop people is to gradually convert what was a Unix-like OS into one which won't be. So those of us who used Linux because of what it was will be looking elsewhere.

      1. Bronek Kozicki Silver badge

        Re: Init freedom

        @Doctor Syntax - exactly.

    2. Mike Moyle Silver badge

      Re: Init freedom

      ...Well, innit?

    3. John Hughes

      Re: Init freedom

      Devuan claim that their system, which does not allow you to install systemd, gives more freedom than Debian, which allows you to install systemd, upstart or sysvinit.

      1. ElReg!comments!Pierre Silver badge

        Re: Init freedom

        > Devuan claim that their system, which does not allow you to install systemd

        Blatant lie. Nothing in Devuan prevents you from installing systemd. It just allows you to install a system _without_ systemd if you so wish, which (second blatant lie) Debian doesn't allow you to do anymore. udisk2 without systemd in Debian, for example?

        Oh, you CAN install sysvinit or anything else in Debian. You just can't NOT install systemd. Anyone pretending otherwise is either a chill, or without any tech gorm.

        1. ElReg!comments!Pierre Silver badge

          Re: Init freedom

          Disclaimer: my beard is much greyer than I'd wish, thank you for asking.

  1. Tom 7 Silver badge


    you've got to love it. OK!

    Will be trying this out on my new laptop - systemd would have been nice 10 years ago but I cant see much need for a system that is ready and waiting while the wlan is still trying to work out a little number.

  2. Tom Chiverton 1

    systemd is many things, but a bootloader ain't one

    1. NB

      O rly?

    2. Anonymous Coward
      Anonymous Coward

      @Tom Chiverton 1

      Well, it does contain systemd-boot now... Seriously though, no it is not. Also, technically speaking systemd-boot is a boot manager, not a bootloader.

      1. Steve Graham

        Re: @Tom Chiverton 1

        I wouldn't call systemd a "boot manager". A boot manager should piss off once the system is booted, not carry on running, pretending to be a substitute operating system.

        1. Michael Wojcik Silver badge

          Re: @Tom Chiverton 1

          I wouldn't call systemd a "boot manager". A boot manager should piss off once the system is booted, not carry on running, pretending to be a substitute operating system.

          Agreed. The proper term for such a thing is "MS-DOS".

    3. Doctor Syntax Silver badge

      "systemd is many things"

      Too many.

    4. hplasm Silver badge


      is another thing that systemd is not..

  3. jake Silver badge

    As a long-term (just under 23 years) Slackware user ...

    ... I am evaluating Devuan out of curiosity. So far, it looks like a good option :-)

  4. Anonymous Coward

    "Versions for the Raspberry Pi, Banana Pi and AMD64 are on offer, making it something of a niche offering."


    Doesn't someone know what AMD64 is?

    1. Anonymous Coward
      Anonymous Coward

      Given that some of the distros have dropped the 32 bit version of AMD64, (Because who'd want that?) it's quite amusing.

      1. Anonymous Coward
        Anonymous Coward

        Maybe Vulture South runs on i486s or those TV-tube-in-a-plastic-bubble iMacs? None of this newfangled 64bitness down under?

    2. nagyeger

      It must be niche

      it doesn't run on my old 286.

      1. Tom 7 Silver badge

        Re: It must be niche

        ELKS may be updated soon:

    3. Fibbles

      The more articles from Simon Sharwood that I read, the more I realise he knows very little about technology.

  5. nematoad Silver badge


    I'm getting a 502 Bad Gateway error when I go and try to get the torrent from the site.

    Could this be a result of too much traffic?

    Still, I'll try again later, it might be back then.

    Popular, eh?

  6. Flocke Kroes Silver badge

    systemd is not a boot loader

    The sequence is firmware loads (part of) the boot loader, which is usually grub for x86 or U-Boot for everything else. The boot loader - using nothing but itself and some probably broken firmware - loads the rest of itself, then the kernel (and possibly a small disk image). The kernel mounts the root file system, and then runs something as process 1. That was usually sysvinit, or - if you are recovering a badly confused machine - bash. Systemd is a replacement for sysvinit.

    When process 1 starts, it has the complete kernel and any modules the kernel requires, the root file system, and probably a few pseudo file systems like /dev. Sys[vt][ei][nm][di]t? starts almost everything else: all the permanently attached file systems, any strange configuration, various demons, login for each terminal and one of the gui login programs. When a process dies, its parent gets sent a signal. If the parent is dead, that signal goes to process 1. While running, systemd/sysvinit restarts any dead demons. During shutdown, sysvinit/systemd kills all the processes and unmounts all the file systems.

    This makes sys{vinit,temd} very different from a boot loader - which self destructed when it handed control to the kernel within a few seconds of power on.

    BTW: Debian architecture names make sense to techies, but not to computer illiterates. AMD64 is almost certainly what your Intel processor is pretending to be when it is not pretending to be an ancient pentium for 32-bit Windows users. It is the most common architecture on the planet. Raspberry pi is odd. The earliest ones are not quite armhf. The newest ones are ARM64, and the ones in the middle are armhf. Supporting raspberry pi means armhf with restrictive compiler flags. Banana pi is full armhf, and anything armhf should be able to use the same repository.

    If we go through popcon in order of architecture, fist is AMD64. Second is i386 (probably AMD64 compatible machines, although some will be ancient / odd). Raspberry pi is not included in popcon, but is probably next in real life, then comes armel (arm older than the oldest pi), powerpc (old converted macs?), armhf (banana pi, and a pile of other arm based small cheap computers). All the remaining architectures supported by debian together are not as common as armhf. Devuan have chosen about three and a half of the most popular architectures. The most of the others are too old to run Debian Jessie anyway, have bigger problems than hatred of systemd if the maintainers want to upgrade.

  7. EvadingGrid

    One Man Distro !

    If you are like me, and cook your own tiny micro distro - and by that I mean actually compile your own base system, not just re-brand some body else’s work . . . take a wild guess at how enthused people like me are about the pointless extra work load of dealing with system-d . . .

  8. Steve Graham


    This is news to me, in that I migrated my repository settings to Devuan months ago, with no ill effects.

    (On this machine, I seem to have 90 Devuan packages out of 2795 installed, but obviously that ratio will increase as I update them.)

  9. fortran

    bsd and systemd

    Concensus I've seen, has it that BSD cannot run systemd. Lately on Debian/stable, I've noticed that bsdutils is not being upgraded. The reason? On Debian/stable, bsdutils now depends on systemd! I've downloaded the source package, and you can compile it with no inclusion of systemd.

    I will be moving to Devuan. Including my failed attempt at understanding Gentoo.

    1. Justin Pasher

      Re: bsd and systemd

      I have bsdutils installed on a Debian Jessie system running sysvinit. The package depends on libsystemd0, not the full systemd init system. In fact, running sysvinit is officially support in Debian Jessie. You just have to do some work yourself.

      Whether this will still be the case when Debian Stretch becomes stable next year is anybody's guess.

  10. disgustedoftunbridgewells Silver badge


    SystemD has its own bootloader now? Or is that a mistake in the article.

    1. John Hughes

      Re: Bootloader?

      Both, it's a mistake in the article -- systemd isn't a bootloader, and yes, systemd has it's own EFI bootloader, the package formerly known as gummiboot.

  11. td0s

    SystemD was imposed on the linux community by redhat and the same "engineer" who gave us the joy of pulse audio. I am a slackware user and I remember using pulse audio in the early days just after it was renamed from polyp audio and it was a mess - the response to my mailing list request for support was "thats a problem with alsa drivers take it up with them". We recently got pulse audio (7 years later) and it seems reasonably stable, I use centos at work and I have yet to see anything about systemD which is an improvement from my point of view as an administrator - an opaque log, "extras" needed for common pieces of software all to fix something which is not broken.

    You can keep your systemD tyvm

    1. Chris King Silver badge


      Yes, some people will be opiniated. We invited the Devil into our house and stuff. Well, PulseAudio is not maintained by Lennart anymore, and saner people took the helm. We expect no big mess as a result, just a learning curve to understand the new sound configuration. And truthfully, we were left no choice. The alternative would have been to say bye-bye to bluetooth in Slackware because already, major pieces of software are dropping or preparing to drop support the old and incompatible BlueZ 4.x API.

      Note: Slackware is NOT going to add systemd. It’s too controversial and there is no need. Your sleep will be sound now.

      1. Doctor Syntax Silver badge

        "The alternative would have been to say bye-bye to bluetooth in Slackware"

        Pulseaudio incorporated Bluetooth?

        1. Chris King Silver badge

          "Pulseaudio incorporated Bluetooth?"

          No, BlueZ 5 dropped ALSA support.

          1. John Brown (no body) Silver badge

            "Pulseaudio incorporated Bluetooth?"

            No, BlueZ 5 dropped ALSA support.

            And we have the same scenario to look "forward" to with systemd as it gets it's claws into ever more of the system.

  12. TJ1

    Problems with Systemd and Pulseaudio

    I find the technical design, configuration flexibility, single syntax, and tooling for analysing configuration and actions to be far superior to the alternatives especially on more complex systems.

    I say that as someone who was originally set against accepting systemd at all and resisted it for a long time.

    I've come to discover that in the main the problems attributed to systemd are more due to distributions adopting it before it is ready to take over the duties of other daemons, in that it hadn't reached feature-equivalence with the disparate services it extinguished.

    Pulseaudio suffered the same way - it was introduced by maintainers before its features were complete for many mainstream use-cases, even though it was doing more sophisticated things without user intervention (I recall one such being automatic up/down sampling to match bit-rates for sources and sinks). In the case of Pulseaudio many people tend to forget that before it arrived the ALSA tooling it replaced didn't support multiple applications using the sound output at the same time, and that issue was a very big cause of desktop user bug reports and complaints.

    With systemd one example is not supporting key-files for encrypted file-systems but it replaces the working cryptsetup scripts. That's something the distro maintainers could avoid by not including the systemd-cryptsetup service.

    The reasoning behind the missing feature is technical perfection. There have been several pushes to add functionality but Lennart has held out against band-aid solutions and wants a once-and-for-all design which utilizes the kernel key-ring for handling the encryption keys.

    So part of the problem is systemd-cryptsetup not implementing the full set of what I'd call 'standard' features but the distro maintainers enabling it, therefore causing regressions in user experience.

    It is possible for distro maintainers to build only selected modules of systemd so that where features are not yet comparable the original service could remain, but mostly they don't do that.

    1. td0s

      Re: Problems with Systemd and Pulseaudio

      Yes, to be fair Lennart is a good engineer, I just don't think his approach (on systemD) is what people in the (my) community want. ASLA isn't great at all tasks, but there are other sound systems available for Linux which can provide the missing functionality - notably JACK which seems to have been treated as an afterthough by pulse audio.

      I guess that systemD will improve over time and eventually we will have no choice but to use it as the software will start to depend on it - which is what bothers me - exactly the same as pulse audio which we now have because of broken bluez we will end up having to use systemD (unless we use BSD)

      1. Anonymous Coward
        Anonymous Coward

        Re: Problems with Systemd and Pulseaudio

        PulseAudio never fails to fuck things up. Currently it's giving me STATIC - loud, obnoxious clipping noise - intermittently of course. On a brand new Mint 17.3 install, I spent an hour troubleshooting HDMI audio, only to discover Pulse actually wasn't starting automatically... what a total frickin' curveball after 5+ years of struggling to STOP the damn thing, lol. On the upside, now it cooperates with JACK just fine, at least with the help of KXStudio and Cadence, for now. I'm sure that's already broken in newer distros, though.

        For all the effort sunk into the PulseAudio layer-upon-layer architecture, it would've been better to start over and build what ALSA was meant to be, a unified sound architecture with software mixing and optional JACK-style synchronous low-latency I/O.

  13. Jason Bloomberg Silver badge

    Raspberry Pi

    If they can churn out a 64-bit Devuan version for the Pi 3B, that could put the proverbial cat amongst the pigeons.

    Though there might be a danger that a Pi 3B will burst into flames running a 64-bit OS.

    1. oldcoder

      Re: Raspberry Pi

      I understand the P3 is a 64 bit system.

      Shouldn't be any flames... unless you overclock it.

      1. Tom 7 Silver badge

        Re: Raspberry Pi

        The P3 is a 64 bit system but the raspbian for it is currently 32bit. Not sure how much faster/more power it may take running a 64 bit version but I'd guess its could be a bit more than the 32bit and may run a bit warmer simply because the code will be a lot more optimised for the machine. I can get mine up to 70C (assuming I'm looking at the right thing) by doing some very silly maths so a heatsink could be required.

  14. Anonymous Coward
    Anonymous Coward

    Nice to see progress

    It's nice to see progress on Devuan... but I never had high hopes. There are so many things wrong with Debian, and with the Linux ecosystem in general. Package systems, goofy packaging practices, the audio clusterfuck, X windows (man, I hated that shit in the 90s, and it has not improved much)... systemd is merely the latest trainwreck.

    Still, if Devuan keeps Linux competitive with FreeBSD, and possibly serves as a new base for overlay distros like Mint, I guess it's a good thing.

  15. jerky_rs

    personally i think SystemD is overally complicated for what it achieves, sure it boots faster but on a server all i care about is that it comes up and things are simple. With Systemd there is no clear detail of how and what starts unless you reverse targets out of the systemd directory which is ridiculous as compared to "chkconfig --list | grep 3:on" . If we really needed something to start up different processes and manage(and dependencies) them in a simple way they should have just used SupervisorD and include files. Sadly SystemD is much more then what it needs to be.

    This is another great example of why systemd is not very good

    tcp6 0 0 :::9090 :::* LISTEN 1/systemd

    Err so something with PID 1 is listening on 9090, wonder what that is? Start fgrep your systemd directory and hopefully it returns something with 9090 (happens to be cockpit socket..)

    As an RHCE for over 10 years i think this is the biggest mistake Redhat has ever made, but i guess we must learn to love systemd. Its in my opinion as bad or worse then firewalld or networmanager both of which have no business being on a server. (desktop sure why not).

    1. Anonymous Coward
      Anonymous Coward

      Boots faster. Uh huh

      Nope, it doesn't boot faster on my system. It's noticeably slower than Upstart.

      Also restarting services is really slow. nginx used to restart instantly; with systemd it takes about 8 seconds.

    2. TJ1

      @jerky_rs read the documentation

      systemctl status --state active

      systemctl list-sockets

      systemctl list-dependencies ssh.service {--before | --after}

      journalctl -u ssh.service

      systemd-analyze {critical-chain | blame}

      systemd-analyze dump

      As an employer of admins for over 30 years if those admins can't be bothered to read the documentation, in man-pages or other forms, then I consider them remiss in the *most* important skill any admin should be using constantly.

      When something isn't familiar you read the documentation, explore the commands themselves, do some lab-work, and become familiar with the tools.

      systemd in particular has provided some excellent consistent tooling for gaining insights into service state, configuration, dependencies, resources and more.

      1. Tom 7 Silver badge

        Re: @jerky_rs read the documentation

        Read the documentation? Love to have time to do that. That also works really well when you stick to the original Unix ideology but having to read 30 odd documents to try and get a clue to why something is failing is too much for most. In fact I can safely say I've spent more time trying to sort out a systemd problem than it has saved me in boot time by a several orders of magnitude.

      2. Bronek Kozicki Silver badge

        Re: @jerky_rs read the documentation

        Right, systemd init takes the role of inetd. As "an employer of admins for over 30 years", now please explain why do you think this is actually good idea

      3. Aaron Kulkis

        Re: @jerky_rs read the documentation

        Oh, B. S.

        All of the necessary documentation for SysVInit contained in a 2-page document, which is clear, concise, and easy to understand in all of its nuances, because SysVInit is the epitome of elegance. The systemd documentation runs into the hundreds of pages, and is anything but clear and concise.

        I've been using Unix since 1983, WROTE a unix-like operating system in a matter of weeks in a senior-class assignment, and have been administrating Unix and Linux machines since the early 1990's. When I say systemd is an over-complicated pile of rubbish, it's NOT due to an inability to comprehend, it's due to the fact that Poettering is not nearly as talented as he believes himself to be, and thinks that "more lines of code" == "better code" when, in fact, the exact opposite is generally true.

        1. rnturn

          Re: @jerky_rs read the documentation

          I cannot recall ever having a sysvinit-based system toss me into single user mode because a filesystem mount took "too long" due to a forced fsck. Sure, I might have had a filesystem be unavailable for a time while a mount-time fsck completed but I never had the "entire system" be unavailable while I was running that fsck by hand. (In a pinch, I've commented out the filesystem entry in /etc/fstab, rebooted the system, and hoped systemd get confused by another big filesystem needing an fsck.) I'm sure there's a means of extending the time-out that systemctl imposes on mounts but I'll undoubtedly get burned again unless I make it ten times longer. (And will even /that/ be long enough? I haven't sat there with a stopwatch timing an fsck of a multi-terabyte filesystem.)

    3. Tom 64

      "tcp6 0 0 :::9090 :::* LISTEN 1/systemd"

      That is pretty horrible. I've done a bit of network programming and one of the things I've learned is that you should never use your master process to talk to the network.

      I'm not sure what will happen if process 1 blows up on Linux, but I AM sure its not what you want happening.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019