back to article systemd-free Devuan Linux hits version 1.0.0

Devuan, the effort to build a systemd-free version of Debian, has released Devuan Jessie 1.0.0, a release candidate felt to be just about the finished article. In a mail sent to the project's followers the self-proclaimed “Veteran Unix Admins” behind Devuan say “This Devuan Jessie release candidate is as close as we can get to …

  1. conscience
    Thumb Up

    systemd sucks

    I'll be giving it a go right away.

    1. Ole Juul

      Re: systemd sucks

      I've got two units here running Devuan Jessie 1.0.0-beta2 which I installed a little while back. Works fine, and in fact it was easier to configure to my own taste than Debian is. In my world, Devuan is a winner.

      1. Doctor Syntax Silver badge

        Re: systemd sucks

        "in fact it was easier to configure to my own taste than Debian is"

        So it should be. That's what it was intended to do. I've also had the beta running on an Intel box but it was problematic on a Pi. I must go back to that now the RC is out.

    2. Planty Bronze badge
      Stop

      Re: systemd sucks

      Infighting sucks more, and has essentially killed Linux for mainstream adoption.

      1. jake Silver badge

        Re: systemd sucks

        Infighting? Nah. Just a little healthy sibling rivalry.

        Want mainstream? I'll bet you a plugged nickel that there are over twice as many Linux based devices than there are people in the town that you live in.

      2. Christian Berger

        It's not infighting

        It's loosing the respect of large projects. The whole point of unixoid operating systems is that they avoid large projects. The largest single project in the GNU/Linux environment, for example is the Linux kernel, and that's heavily guarded. It has to be, because even innocent mistakes can easily corrupt the system. Other projects are usually small and compact with well defined scopes. (Though many GNU projects have broadened those scopes a lot in recent years.)

        The idea is that the effort you need to put into software goes up exponentially when you add more lines of code. A 10k project is _much_more_ than 10 times as hard to write and maintain than a 1k project.

        The problem we have now is that there is a surplus of people who want to work in "Open Source". Those people want to write code for projects to have something for their resume. Helping on an existing project is easier than starting your own, and huge projects, like systemd, need lots of work. That's why they attract lots of learners and integrate their code. Code written by people in their early years usually sucks. In the past, that code would have gotten into shareware software and would have been erased by the bit rot of the Internet. Now those bad lines of code and those bad design decisions end up in actual Open Source projects which are stored for all eternity on Github.

        The result are bugs like this:

        https://github.com/systemd/systemd/issues/5644

        1. Anonymous Coward
          Anonymous Coward

          Re: It's not infighting

          > The result are bugs like this:

          > https://github.com/systemd/systemd/issues/5644

          OMG. And Pottering's response is particularly priceless, too, demonstrating both his ignorance and hubris in one succinct piece of prose: erasing the entire filesystem is "not much of a problem", and "this is a unix problem" (it isn't, as pointed out by multiple other commenters).

          I won't go near systemd on the simple basis that I know exactly how good Pottering's previous effort - pulseaudio - isn't. On the basis of having experienced that godawful dreck I'm not letting him anywhere near anything as critical as PID 1.

          1. Dan 55 Silver badge

            Re: It's not infighting

            And after it was shown it was a) bad behaviour and b) a regression, he locked the issue.

            And then some people wonder why systemd isn't liked...

            1. John Hughes

              Re: It's not infighting

              And after it was shown it was a) bad behaviour and b) a regression, he locked the issue.
              No, after the issue was fixed, and hordes of systemd haters came to whine for no reason, he locked the issue.

              Bug reporting tools are not discussion forums.

              1. Graham Dawson Silver badge

                Re: It's not infighting

                You very poorly characterise what actually happened.

                Immediately after the issue was fixed by someone else, he declares the issue wasn't a problem and demonstrates a profound ignorance of the basic utilities systemd is replacing. Several people then corrected his woefully poor understanding of how rm functions.

                If these are "haters" then I'm the fucking pope.

          2. Down not across

            Re: It's not infighting

            OMG. And Pottering's response is particularly priceless, too, demonstrating both his ignorance and hubris in one succinct piece of prose: erasing the entire filesystem is "not much of a problem", and "this is a unix problem" (it isn't, as pointed out by multiple other commenters).

            That is just pure Poettering. As is his reaction to comments pointing out his ignorance:

            @poettering poettering locked and limited conversation to collaborators Apr 17, 2017

            PulseAudio. systemd.

            Each to their own, but I've seen enough that I won't touch any software that has anything to do with Poettering. Kind of like "Once is a chance, twice is coincidence, third time..."

            None of my Linux boxen have systemd (yes, I tried it, it can burn in hell). Luckily Centos 6 and Jessie are (or can easily be) systemd free. Looks like its time to give Devuan a try.

        2. Anonymous Coward
          Anonymous Coward

          Re: It's not infighting

          Christian Berger wrote

          "The result are bugs like this:

          https://github.com/systemd/systemd/issues/5644"

          Thank you.

          Until now I've been just a mildly interested observer of this debate.

          However having seen the contributions from the man in question in the bug report in question, I

          (a) recommend anyone who hasn't seen them yet has a look at them (it won't take long)

          (b) draws their own conclusions (it won't take long)

          If any sensible person still thinks that the current incarnation of systemd is a bright idea after reading that, then I'll eat my hat.

          1. picturethis
            Mushroom

            Re: It's not infighting

            "https://github.com/systemd/systemd/issues/5644"

            (I encourage everyone to read this thread, really, it's not very long)

            OMG.

            Based on his response, I can't believe that anyone takes this guy (and systemd) as something that has made it beyond some dead-end fork, let alone in main stream OS's used in servers.

            Unbelievable.. The linux distro-world (using systemd) has gone to complete shit.

        3. Anonymous Coward
          Anonymous Coward

          Re: It's not infighting

          @Christian Berger - "The whole point of unixoid operating systems is that they avoid large projects."

          Apache is laughing at you right about now.

          1. Anonymous Coward
            Facepalm

            @Andy

            "Apache is laughing at you right about now."

            Since when did Apache turn into a Unix(-like) operating system?

            Some larger projects covered by the Apache foundation may target Unix(-like) environments, but that doesn't mean that those Unix(-like) environments are also involved with those Apache projects as well.

            1. Anonymous Coward
              Anonymous Coward

              Re: @Andy

              No one called Apache an OS. The question was if "large projects" are accepted into the GNU/Linux ecosystem. There are lots and lots of "large projects" associated with both BSD and Linux.

              1. Graham Dawson Silver badge

                Re: @Andy

                Which is why the post specified operating systems and not ecosystems. What an external application developer chooses to do is irrelevant. The closer you are to pid0, the closer you should stick to the Unix philosophy.

                1. cream wobbly

                  Re: @Andy

                  "The closer you are to pid0, the closer you should stick to the Unix philosophy."

                  Right. Such as not aliasing "rm" to "rm -i" and having patches contributed to nix beginner errors like "rm -r .*".

            2. cream wobbly

              Re: @Andy

              "Since when did Apache turn into a Unix(-like) operating system?"

              Fine. GNU, then.

          2. nijam Silver badge

            Re: It's not infighting

            > Apache is laughing at you right about now.

            And that laughter is the reason why nginx is gaining ground.

            1. TheVogon

              Re: It's not infighting

              "And that laughter is the reason why nginx is gaining ground."

              And why Microsoft IIS now has double Apache's market share:

              https://news.netcraft.com/

              1. kosh

                Re: It's not infighting

                That's usage share, not market share. Markets are measured in dollars. IIS is light years ahead of Nginx in that regard.

                NB: There are revenues due to Apache, flowing to IBM and Oracle for their repackaging of it, but we don't have hard data.

                1. TheVogon

                  Re: It's not infighting

                  "That's usage share, not market share. Markets are measured in dollars. IIS is light years ahead of Nginx in that regard."

                  Uhm, no. Markets can be measured in various ways. Pounds for a start. And also not just by sales. Nice pedantry, but also wrong...

              2. Anonymous Coward
                Anonymous Coward

                Re: Microsoft IIS now has double Apache's market share:"

                O'Really? Here's the current market share *detail* for MS and Apache from https://news.netcraft.com/archives/2017/04/21/april-2017-web-server-survey.html

                Share of all sites: Apache 22% MS 44%

                Share of active sites: Apache 46% MS 8%

                Share of top million busiest sites: Apache 40% MS 10%

                Still think "MIcrosoft IIS now has double Apache's market share" is a plausible summary of Netcrafts numbers and charts or even the article text? It is the kind of misleading Twit-sized claim many politicians would happily make, though.

                Use the source, readers, always use the source:

                https://news.netcraft.com/archives/2017/04/21/april-2017-web-server-survey.html

                1. TheVogon

                  Re: Microsoft IIS now has double Apache's market share:"

                  "Share of all sites: Apache 22% MS 44%

                  Still think "MIcrosoft IIS now has double Apache's market share" is a plausible summary of Netcrafts numbers and charts or even the article text? "

                  Uhm, yes. I'm pretty sure 44 is exactly double 22...

                  This was always the exact statistic the Apache fans used to quote.

              3. Kiwi

                Re: It's not infighting

                And why Microsoft IIS now has double Apache's market share:

                Maybe according to a quick glance at the linked Netcraft page (though I've edited this post to reflect another poster pointed out a better look at the Netcraft site shows otherwise). There's not many places out there that do this sort of work (with a quick check on Google anyway, others can look further if it's important enough to them)

                https://w3techs.com/technologies/details/ws-apache/all/all suggests otherwise.

                Site hacking must be at an all-time high. When IIS was just a teency little minnow with no defenses to speak of it was vastly more commonly hacked then Apache. Now it's a ugly large monster (still with no defenses to speak of, not like MS know what "security" is or anything) the number of targets out there is so much higher.

                (I must wonder who runs Netcraft, and how much of the IIS servers they see are MS spinning up a few million VM's just to fudge the data - but then MS has never been known to falsify data or reports before have they?)

                1. TheVogon

                  Re: It's not infighting

                  "Site hacking must be at an all-time high. When IIS was just a teency little minnow with no defenses to speak of it was vastly more commonly hacked then Apache"

                  IIS has always had a far better security record than LAMP stacks, and historically was about 4 time LESS likely to be hacked (allowing for market share at the time). See for instance http://zone-h.org/news/id/4737?zh=1

                  1. Kiwi
                    Coat

                    Re: It's not infighting

                    IIS has always had a far better security record than LAMP stacks,

                    You'd be a comedian if your deluded trash wasn't on such a serious topic.

                    Why is it that IIS gets most of the hacks despite being least used? Can't claim something is more secure when it is less widespread but most broken.

                    How much do they pay you to spread this crap? And how do you go to sleep at night knowing that every time someone takes your advice they're putting their livelihood, and their customer's data at risk? Or are you trying to drum up business for yourself knowing that once people get sick of how broken and insecure MS crap is, you can drop in and sell them a nice secure LAMP system? Or perhaps something based on BSD?

                    Compared to MS, a house with no windows or doors in the worst neighbourhood is quite secure. (Must be, it has no windows! .. Yeah yeah, I'm outta here... )

                    1. TheVogon

                      Re: It's not infighting

                      "Why is it that IIS gets most of the hacks despite being least used? "

                      It doesn't - Linux gets WAY more hacked when used as an internet facing server. See http://zone-h.org/news/id/4737?zh=1 - old - but still true. More recent stats are actually worse for Linux!

                      1. Kiwi
                        Boffin

                        Re: It's not infighting

                        See http://zone-h.org/news/id/4737?zh=1 - old - but still true.

                        We have a consumer protection TV show here in NZ called "Fair Go". It's been around since 1977. Basically they do two things, 1) people can write in with complaints about shoddy businesses or behaviour by people in private deals, and FG chases up the other side and works to either get the victims money back or get a "fair deal" arranged. And they've taken on the big insurance firms, telcos an goverment agencies and won, as well as people trying to rip of their neighbours and so on. And 2) they give people warnings about scams and information on detecting them. One thing they pointed out is a lot of scammers these days are using tricks to hide their true identity. One of them is not having real details in their domain registrations.

                        whois zone-h.org..

                        [..]

                        Registrant Email: ZONE-H.ORG@domainsbyproxy.com

                        [..]

                        So that is who you want us to look to for your proof of how good IIS is vs how bad Apache is? Someone organisation who is so trustworthy they use a domain hiding service so you can't find out anything about them?

                        Your garbage gets worse by the day. That stuff MS is feeding you really is messing up your brain!

                        1. TheVogon

                          Re: It's not infighting

                          "One thing they pointed out is a lot of scammers these days are using tricks to hide their true identity. One of them is not having real details in their domain registrations."

                          Had it occurred to you that might also be something those associated with website hackers might want to use? A very desperate sounding and failed attempt to cast aspersions...

                      2. Anonymous Coward
                        Anonymous Coward

                        Re: It's not infighting

                        "Linux gets WAY more hacked when used as an internet facing server."

                        Zone-h counts website defacements, doesn't it?

                        Is there a difference between a website defacement and what most people might call a hack?

                        "More recent stats are actually worse for Linux!"

                        Then share them please, if you don't mind. Ideally based on something more widely relevant than website defacements. I realise that may be hard work, but you're the one making the claims, you're the one that needs to put up or shut up.

                        Otherwise people may well just assume it's the same recycled Jeff Jones material you were spouting back in (e.g.) 2013 which itself was based on rather outdated source material.

                        This Jeff Jones:

                        https://blogs.microsoft.com/microsoftsecure/author/jeffjones/page/2/

                        Jeff Jones who was claiming in 2007 that, after a whole six months out in the wild, Vista was more secure than Linux and OS-X?

                        You'd be well advised to quote any more recent references you feel may clarify matters, but in the meantime here's one from 2007, from

                        http://www.pcmag.com/article2/0,2817,2149851,00.asp

                        or there's this:

                        http://blogs.csoonline.com/windows_vista_6_month_vulnerability_report

                        Have a lot of fun.

                  2. Maventi

                    Re: It's not infighting

                    "and historically was about 4 time LESS likely to be hacked"

                    Simply because those mountains of outdated WordPress sites left to rot out there aren't running on IIS.

                    Context is everything.

                    1. TheVogon

                      Re: It's not infighting

                      "Simply because those mountains of outdated WordPress sites left to rot out there aren't running on IIS."

                      Sure - whatever excuse you want to make. IIS doesn't tend to be running insecure crap like PHP or My SQL either...

                      1. Maventi

                        Re: It's not infighting

                        "IIS doesn't tend to be running insecure crap like PHP..."

                        Case and point. So it's not Linux/Apache versus Windows/IIS security we are talking about per se; what we are really referring to is the plethora of quickly hacked up PHP apps and the like that become low-hanging bot fodder.

                        Saying that this is a 'Linux' issue is entirely missing the point; it's analogous to the folks that bag 'Java' as insecure without having any clue what they are actually referring to.

                        Unfortunately I guess this is the price to pay for a platform with such a low entry barrier.

              4. Anonymous Coward
                Anonymous Coward

                Re: It's not infighting

                '...now has double Apache's market share...'

                If you read the full stats you linked to as opposed to cherry-picking one graph, it shows that Apache comfortably beats IIS in terms of actual use, and nginx is severely eating into the market share of both Apache and IIS. IIS actually shows a long downward trend in most of the graphs that isn't showing any signs of stopping. Take off the rose-tinted glasses and try scrolling down a bit.

                1. TheVogon

                  Re: It's not infighting

                  "If you read the full stats you linked to as opposed to cherry-picking one graph, it shows that Apache comfortably beats IIS in terms of actual use"

                  Uhm, no - if you read the article - you will see actual use is 44% IIS to 22% Apache.

                  This exact statistic is what the Apache fans always used to quote. It's only now that IIS is market leader that you are trying to cherry pick a more limited measure!

                  1. Anonymous Coward
                    Anonymous Coward

                    Re: more recent stats @The_Vogon

                    Those "more recent stats" you promised to support your case... will we have to wait much longer?

      3. Brewster's Angle Grinder Silver badge
        Paris Hilton

        Authoritian dictatorships for beginners

        "Infighting sucks more,"

        You're Theresa May and I claim my free snap election.

        Paris, because she kinda looks like Theresa, if you squint.

    3. This post has been deleted by its author

  2. Gene Cash Silver badge

    Hm. Plain Debian still allows you to switch to SysV init in a matter of minutes, and in a couple years of that, I haven't found a problem except for Raspian, where the Bluetooth support assumes you have systemd.

    1. Sven Coenye

      It is not that clearcut

      Debian made KDE unnecessarily depend on systemd and without systemd, mounting/unmounting removable storage requires root permissions. While you can opt to not run systemd as PID 1, it is pretty much impossible to get rid of it without loss of functionality.

      1. Ole Juul

        Re: It is not that clearcut

        Too clever by half.

      2. jake Silver badge

        Re: It is not that clearcut

        To say nothing of the fact that systemd goes completely against the entire un*x design philosophy ... kinda like EMACS ;-)

        1. GrumpenKraut
          Angel

          Re: It is not that clearcut

          > ... kinda like EMACS ;-)

          Wait, are you saying I should not be using /boot/vmemacs as O/S kernel?

          1. Graham Dawson Silver badge

            Re: It is not that clearcut

            Yes.

            It should be vi.

            1. jake Silver badge

              Re: It is not that clearcut

              No, no, no! Use vi as your shell! :-)

              From one of my passwd files:

              write:x:1007:101:,,,:/home/write:/usr/bin/vi

              Yes, that's really a user account that I use ... usually on a dumb terminal. I don't like distractions when I'm writing more than throw-away comments, like this one.

              1. GrumpenKraut
                Coffee/keyboard

                Re: It is not that clearcut

                > write:x:1007:101:,,,:/home/write:/usr/bin/vi

                I am impressed. Let me guess: your version of vi does not support noob things like arrow keys?

                1. Brad Ackerman
                  Boffin

                  Re: It is not that clearcut

                  Let me guess: your version of vi does not support noob things like arrow keys?

                  Bonus points for implementing a device that sits between your VT102 keyboard (VT52 acceptable; VT220 is right out) and NOPs the arrow keys using 7400-series ICs and nothing else. Some people have an iron will, but if not it's okay to reinforce your determination with TTL logic and wire-wrap.

                  1. Anonymous Coward
                    Anonymous Coward

                    Re: It is not that clearcut

                    Even more bonus points if said VT102 can dynamically switch between English and Icelandic and Arabic.

                    The real VT102 (and later VT220's) could do that.

                  2. Wensleydale Cheese

                    Re: It is not that clearcut

                    "Bonus points for implementing a device that sits between your VT102 keyboard (VT52 acceptable; VT220 is right out)...

                    You do realise that the VT52 keyboard was part of the main unit? (see pic at top RHS)

                    1. jake Silver badge

                      Re: It is not that clearcut

                      I run Slackware. The vi clone is elvis. The arrow keys work ... if the keybr0ad has arrow keys, of course. I rarely find myself reaching for them, though, unless I'm in input mode ;-)

                      Seriously, try using vi as your shell. You'll be awfully surprised at how functional it is. For test purposes, create a user account with a vi shell. Pull up an xterm & log into that account. See what you can (and cannot) do with vi as your day-to-day CLI shell ... At the very least, you'll learn a lot more about vi than most folks. The concept was suggested to me in jest decades ago (1979ish) when a friend commented that "You seem to live in vi! When was the last time you saw a shell prompt?"

                    2. Brad Ackerman
                      Childcatcher

                      Re: It is not that clearcut

                      You do realise that the VT52 keyboard was part of the main unit? (see pic at top RHS)

                      Yes, and that's what screwdrivers are for.

                      Spock, because there's no Doctor in the house.

                2. Doctor Syntax Silver badge

                  Re: It is not that clearcut

                  " Let me guess: your version of vi does not support noob things like arrow keys?"

                  No, if he wanted to do without arrow keys he'd use ex

            2. nijam Silver badge

              Re: It is not that clearcut

              Emacs vs vi...

              "Unfortunately, only one of them will lose" H Kissinger

              (or something like that, can't be bothered to check).

      3. rtfazeberdee

        Re: It is not that clearcut

        the systemd binary HAS to be PID1 because its the init system. Don't get confused by the systemd project that has loads of other tools in it that do not run as PID1

        1. Graham Dawson Silver badge

          @rtfazeberdee Re: It is not that clearcut

          By that he means running another init as PID1.

      4. lpcollier

        Re: It is not that clearcut

        That's a distro issue - ideally the Debian Way would be to have an "Init System" virtual package (is that the right terminology?) that can be fulfilled in several different ways including systemd. But I guess it becomes difficult to do that at such a low level as the init system.

        1. Graham Dawson Silver badge

          Re: It is not that clearcut

          It wasn't difficult before systemd came along. Other inits aren't tied to disparate elements of the OS and don't pile so much functionality into a single package. They just run and manage daemons.

          If systemd just ran and managed daemons, there wouldn't be any arguments.

          1. Paul Crawford Silver badge

            Re: It is not that clearcut

            It is a shame that Canonical gave up on 'upstart' as it was almost what was needed: an init process that could handle parallel start-up and dependencies. It could also be run as a user PID if users wanted an event-drives start-stops system, say for removable storage. And there it stopped, as it only wanted to be 'init' and not an octopus.

    2. HieronymusBloggs

      "Plain Debian still allows you to switch to SysV init in a matter of minutes"

      For now.

      I've been using Debian 8 with sysvinit-core for a while now, but I'm concerned enough about the long term viability of that to start looking at non-Linux alternatives (*BSD).

    3. SImon Hobson Bronze badge

      Plain Debian still allows you to switch to SysV init in a matter of minutes ...

      Err, well sort of, but not really.

      The problem (as already mentioned) is that SystemD just isn't an init system as it was described as whenever there was any dissent from using it. The problem is that there are so many tentacles that it invades all over the system to the point that you CANNOT uninstall SystemD without breaking an increasing amount of stuff. What you will find if you try it is that you cannot remove all vestiges of SystemD without making your system unusable - such are the gratuitous linkages with bits of SystemD that's enforced by SystemD reinventing established ways of having software interact with other bits of software/the system.

  3. PNGuinn
    Thumb Up

    Y'know I STILL hope Devuan withers and dies, the sooner the better ... But the prospect of the Debian project eating some crow and seeing sense seems further away than ever.

    So great work guys - I grabbed the relevant downloads last night just before I saw this this morning.

    My production box is running Old Stable - so I'll need to upgrade shortly _AND I DON'T WANT SYSTEMD_ so I'll have a serious play with this.

    Hopefully, unless things change elsewhere, this project will gain momentum and become the hub of a new distribution ecosytstem (like the way Mint sits/sat on Umbongo which sits on Debian). With so much of the heavy lifting to get this far done the nest release will hopefully follow on next Debian a bit more quickly and the team will be able to take a long look at a few other issues they're bothered about. Including everything pottering is trying to suck into systemd.

    1. lpcollier

      Why do you _NOT WANT SYSTEMD_ out of interest? It's an elegant system that works with easily understandable text-based configuration files. It's not a "Registry for Linux" as many articles/posts have claimed, it streamlines bringing up a Linux box and does away with a confusing script-based system that was years out of date and difficult to optimise/parallelise. A change of init system isn't something we should be doing more than once every couple of decades, but systemd seems very good to me.

      1. Carlie J. Coats, Jr.

        "Why do you _NOT WANT SYSTEMD_ out of interest? "

        Because I've had more trouble with that kudzu-spreading infection systemd over the last year

        than I had with SysV init over the previous two decades. That's why

      2. Paul Crawford Silver badge

        @ lpcollier

        "A change of init system isn't something we should be doing more than once every couple of decades, but systemd seems very good to me."

        The problem is systemd is not JUST an init system, it adds in binary logging, time setting, module loading/blacklisting, and all sorts of other stuff that were pretty much already solved and workable. And in many cases it adds bugs/issues that seemingly just don't get fixed if they are not in line with Pottering's personal outlook.

        If it were just a paralleled start-up system there would be far less issues, but instead we have fsking *desktops* like GNOME has become that have systemd as a dependency, WTF?!

        1. Sandtitz Silver badge
          Trollface

          Re: @ lpcollier

          "The problem is systemd is not JUST an init system, it adds in binary logging, time setting, module loading/blacklisting, and all sorts of other stuff that were pretty much already solved and workable. And in many cases it adds bugs/issues that seemingly just don't get fixed if they are not in line with Pottering's personal outlook."

          I'm sure you've heard the following mantra from the Acolytes:

          'The beauty in GPL software is that if you don't like it, you can just grab the code and fix it yourself.'

          There. Problem solved. ;-)

          1. Anonymous Coward
            Anonymous Coward

            Re: @ lpcollier

            >'The beauty in GPL software is that if you don't like it, you can just grab the code and fix it yourself.'

            It sure is. They call the fix "devuan".

          2. Chika
            Mushroom

            Re: @ lpcollier

            'The beauty in GPL software is that if you don't like it, you can just grab the code and fix it yourself.'

            Quite so, but generally speaking a user would prefer not to have to fix bugs introduced by twats like Poettering. Fixing accidental bugs, incompatibilities and adding functionality is one thing but having to repair the damage done because somebody working high up wants to dictate how your system should work and doesn't give a flying f*** about complexity, compatibility or usability is something I'd rather not have to do.

            Especially when the other big names in Linux have their collective hooters stuffed firmly up Poettering's taskmaster's rear end and will not see reason.

          3. Anonymous Coward
            Anonymous Coward

            Re: @ lpcollier

            If/when something is Broken By Design, fixing it equals abandoning it. It's at least implied if not plainly said in TAOUP, which isn't like 'the law and the prophets' or anything, but still makes more sense than systemd

        2. Doctor Syntax Silver badge

          Re: @ lpcollier

          "it adds in binary logging"

          Well, there's one reason, all on its own. And as part of the list you gave it's another reason. An init has no reason to be doing so many things.

      3. HieronymusBloggs

        "Why do you _NOT WANT SYSTEMD_ out of interest? It's an elegant system"

        It is precisely because it is _not_ an elegant system that I don't use it on my Debian systems. It pokes its nose into all kinds of things it shouldn't. It makes non-standard setups unnecessarily difficult. It facilitates wide-ranging attack exploits by enforcing uniformity everywhere. It makes low level troubleshooting more difficult. Each new version exhibits unpredictable behaviour which makes it risky to use on a remote system. Need I go on?

        To be fair, you could describe the unit file configuration system on its own as elegant, but the additional feature creep and complexity rule it out for me.

        I had actually dismissed Devuan, but I'm pleased to see they've reached this stage.

      4. Orv Silver badge

        I was willing to learn it (I mean, I learned Solaris SMF, which is even more opaque, and I even sort of understand OS X's launchd). But I got very irritated with a number of bugs that no one seemed interested in fixing because they only affected servers, not the desktop machines systemd targets. For example, it became impossible to reboot a machine via ssh if it had automounted NFS shares; it would hang in the shutdown process every time, requiring physical power cycling. Bug reports about this were met with a collective shrug.

        Personally I find FreeBSD's init system refreshingly simple.

      5. Chika
        Facepalm

        It's not a "Registry for Linux" as many articles/posts have claimed,

        It's something a lot more sinister than a "registry". Something like a registry could be added if one were really needed without everything that systemd is bringing into being.

        it streamlines bringing up a Linux box and does away with a confusing script-based system

        There was nothing confusing about it. When comparing the various sysvinit machines with my current crop of systemd systems, the way in which systemd is gobbling up various modules and making them difficult, sometimes impossible, to access is, if anything, overcomplicating what was previously trivial to work on.

        that was years out of date and difficult to optimise/parallelise.

        The age of the system is immaterial if it works. As for optimisation, sysvinit was pretty good where that was concerned and "parallelisation" is merely yet another fad which has little real use.

        Having said that, the most recent Devuan beta felt like a bit of a let down when I tried it; even the first beta worked better for me. I'll give it a go with a view to possible future use but it all depends on how well it is set up and, more importantly, how well updating works.

      6. Anonymous Coward
        Anonymous Coward

        "Why do you _NOT WANT SYSTEMD_ out of interest?"

        A lot of folks here are sys admins. They like to keep their own boxes running the way they like them. Plus, writing a few init scripts is always good for job security.

      7. PNGuinn
        Unhappy

        Why do you _NOT WANT SYSTEMD_ out of interest?

        "It's an elegant system" ...

        "Elegant" is not a description I'd use personally.

        "Cancerous octopus" springs to mind.

      8. Long John Brass

        confusing script-based system

        If you find a few simple scripts confusing then may I suggest you try Windows or MacOS

        They might be more your speed.

        1. cream wobbly

          Re: confusing script-based system

          You know what *is* confusing? The new unit files.

          Sure, they work. They can build all sorts of dependencies and stuff and you can tell something not to start until something else has started, all that good stuff.

          And the old /etc/rc.d/rc?.d/[ks]* symlinks to /etc/rc.d/ scripts also controlled ordering.

          Ah, "butt parallelization". Sure. When you're booting a server or a high-end workstation that takes several minutes to enumerate its hardware, you don't care whether the OS boots in 30 seconds or 4 minutes. So systemd's *only good feature* was designed expressly to solve a problem with noddy laptops and other prat-about hardware that's better solved by a decent SSD.

          1. Vic

            Re: confusing script-based system

            The new unit files ... Sure, they work

            Not always.

            I had to write some systemd unit files the other week. One of them had to start after the DM - lightdm in this case - had started. So I used systemd to control the dependency.

            Except that it doesn't work; my unit was started after lightdm had started to come up, not once it was functional. I ended up having to do the synchronisation by hand in a script - so it had the worst of all possible worlds.

            SysV is so much simpler...

            Vic.

      9. sdaugherty

        An elegant init system according to UNIX philosophy is a system that does exactly as little as possible in the simplest and sanest way as to be functional at its intended task.

        init should not have an attack surface, it should not handle anything more than necessary - its purpose is to start the rest of processes needed for the system to function. Implementing runlevels, parallel startup, dependencies, and process supervision are potentially sensible additions, that don't raise the footprint very much.

        For me, the part that is unforgivable about systemd is that it is invasive. Its very existence is a threat to the fundamental architectural principles of simplicity, isolation, transparency, and modularity that were so central to the success, stability and widespread adoption of UNIX and Linux. We're seeing deep dependencies on systemd in software that should have no reason to be aware of an init system, much less interact with one.

      10. nijam Silver badge

        > It's an elegant system that works with easily understandable text-based configuration files

        No, it's not elegant, and the config files are no easier to understand than the scripts used previously.

        > A change of init system isn't something we should be doing more than once every couple of decades

        Agreed, but systemd is not an init system (hint: init is an init system). Systemd is spaghetti architecture - even calling it "architecture" at all is generous, of course.

  4. Anonymous Coward
    Anonymous Coward

    Best wishes to Devuan

    It's a pity that they weren't able to release in 2015, when it was possible mostly to remove systemd from Debian itself, but it seems they must have been gearing up to understand the way systemd has become a dependency even when you don't use it as an init, exactly the issue Devuan warned about.

    I mostly use systemd on Debian servers now, but that's because it's becoming harder not to. It's possible on a server, but you just start hitting little irritants. That demonstrates that systemd is far more than the init it claimed to be replacing. I once swapped MTAs from sendmail to postfix at a company with about 400 users. This was done in the middle of the working day, with no loss of service. That's what the unix way of building blocks for services allows, but choosing to run an alternative init is now what systemd expressly prevents in many use cases. Such a pity that Debian, for one, didn't remain neutral in this.

    I'd love Devuan to gain credibility and become a plausible alternative.

    1. CrazyOldCatMan Silver badge

      Re: Best wishes to Devuan

      I'd love Devuan to gain credibility and become a plausible alternative.

      I'd also love to see Proxmox (linux-based VM platform) to migrate to it and away from Debian..

  5. Nolveys

    Great News

    Having to excise systemd every time I install Debian is a hateful experience. Who knows how long it will even be possible to get rid of the blight. I'll definitely be giving Devuan a try.

  6. Will Godfrey Silver badge
    Thumb Up

    Good news

    I've been watching this from the sidelines, and have become increasingly concerned about the virus called systemd.

    I've got a spare machine I can clear out so I'll give this a try ASAP.

  7. jake Silver badge

    I've been watching this (and contributing, a bit).

    It looks like a good option to me.

    Personally, I'm sticking with Slackware on the desktop (it works the way I expect a un*x to work), but one of the "guest" machines here will be running Devuan for the foreseeable future.

    1. Anonymous Coward
      Anonymous Coward

      Re: contributing, a bit.

      Thank you for contributing.

      For those who would like to contribute in non-technical ways (eg $$$/£££) is there an easy way to do so?

      Personally I'd like to stay with Suse but if there's no easy systemd-free option to do so, I'd like there to be some other options too.

      TIA

      Linux user since RH4...

      1. jake Silver badge

        Re: contributing, a bit.

        Assuming the question was serious:

        https://devuan.org/os/donate

        1. Anonymous Coward
          Anonymous Coward

          Re: contributing, a bit.

          Yes thanks, I was and am serious, and yes I'll be donating a few pounds/dollars/euros today, and hopefully more to come (times are a bit straitened at the moment).

          Reminder, here's why I'm donating, you don't need to be a Linux geek (or much of a geek at all) to understand it, it's two minutes to read, and forever to wonder "why?" and "how?" we got here:

          https://github.com/systemd/systemd/issues/5644

          1. Bronek Kozicki

            Re: contributing, a bit.

            I've been donating few quid monthly since the start of the project, also without immediate plan on using it - I have systemd-infested Arch which, for my use, works well enough. So basically my motivation was not as much "displeasure" with systemd as exactly what Devuan promotes - init freedom, for others and perhaps for me (in the future).

  8. joshperry

    Excellent

    Really enjoyed this article. Thank you.

  9. travisgriggs@gmail.com

    Honest inquiry

    Ok, I'll bite. I've done moderate Linux stuff for many years. I get by fine, but I don't put myself in the sage greybeard class.

    I've rather like moving to systemd. I'm not a hard core guru of that either, but I've like having some structured approaches to common unit script patterns. I like it much better than the competing "let's just make the scripts more structured with a layered on meta language" that I was having to learn with Upstart and other distorts variants.

    So let's say that systemd solves these problem in a deplorable way, does the anti systemd crowd actually have an alternate solution to some of the problems systemd wanted to solve? Or is it just a party of no?

    1. nematoad

      Re: Honest inquiry

      "Or is it just a party of no?"

      In short, no it isn't a party of no just for the sake of it.

      A lot of people, including me, dislike and distrust systemd because it does not do what it claims. It is supposed to be an init system but due to creep it has its fingers in a lot of other pies as well. Added to that are the like of a binary logging system which adds complexity and Poeterring's seeming fixation on turning Linux into a Windows clone complete with a Registry. I know that people say that systemd speeds up booting but who needs a quick boot on a server and at what cost? Finally as others here have said systemd turns its back on the Unix mantra "Do one thing and do it well."

      1. lpcollier

        Re: Honest inquiry

        Does Gnome "do one thing and do it well"? Of course not, it's a GUI desktop environment, not a single program. Within Gnome there are many different executables that form a (sometimes) coherent and cohesive whole and are developed and maintained as a project, and hopefully each executable within Gnome does follow the Unix philosophy. Systemd is exactly the same - it's a collection of small binaries developed and maintained as a project that can form the next step (after a bootloader and kernel) of a complete operating system. There are pros and cons, but systemd does provide a robust mechanism for that bottom layer of a working system and seems to me a far better approach than a collection of shell scripts.

        1. Anonymous Coward
          Anonymous Coward

          Re: Honest inquiry

          > Does Gnome "do one thing and do it well"?

          Gnome is a pile of shit, not really useful as an example of either good software or good community.

        2. Ben Tasker

          Re: Honest inquiry

          > Does Gnome "do one thing and do it well"?

          Gnome is amongst the worst examples you could possibly have picked, given that it's another project that's continually criticised (generally for dumbing down and removing useful features).

          It's also a Desktop Environment, so it's kind of expected that it'll contain a wide variety of binaries (just as XFCE, KDE and other DE's do). It's still largely focused on one area though - being a Desktop Environment.

          Systemd was supposed to be init, but the wider project has now pulled in other things too (ranging from udev to network management). Technically those other area's aren't part of the init process (in that they're not in PID 1) but they are now part of systemd, leading to systemd increasingly becoming a dependancy for other packages which shouldn't otherwise require systemd specifically.

          I have days where I outright hate SystemD, and I have days where I'm ambivalent about it. Can't say I've ever felt good about SystemD though (though the same is probably true for SysV). JournalD and FirewallD though, can die in a fire.

        3. GBE

          Re: Honest inquiry

          "Does Gnome "do one thing and do it well"?

          Nope, and I don't use it either. I even gave up on XFCE and switched to something simpler than that.

          Gentoo is still init-system agnostic, and you are free to pick openrc, systemd, or whatever other init system people care to package.

          I find systemd annoying when I have to do anything with Ubuntu, CentOS, Suse, etc. But, I haven't really report any problem with it -- all of my daily-use machines use openrc.

        4. Doctor Syntax Silver badge

          Re: Honest inquiry

          "it's a collection of small binaries developed and maintained as a project that can form the next step (after a bootloader and kernel) of a complete operating system."

          There were already binaries doing those jobs and doing them well. One of the key things about them was that although they worked together they had well defined boundaries and interfaces between themselves. They did not need to be replaced by an interdependent mess.

          One statement made early in the invasion concerned the new systemdified udev. It could be run without systemd but it couldn't be compiled without it. WHAT?????!!!!! This shower couldn't - or wouldn't - structure their code so that common libraries went into one or more source files and the individual programs could be compiled against those without needing to delve into each other's code. Were they really that ignorant of good practice or were they deliberately flouting it? I don't know and frankly I don't care; to know was enough.

          1. This post has been deleted by its author

        5. Doctor Syntax Silver badge

          Re: Honest inquiry

          Does Gnome "do one thing and do it well"?

          It says a good deal about systemd if you feel you need to defend it by comparing it with Gnome.

        6. HieronymusBloggs

          Re: Honest inquiry

          "Gnome does follow the Unix philosophy. Systemd is exactly the same - it's a collection of small binaries developed and maintained as a project"

          This is the kind of sophistry I'd expect from a politician or marketing person. The whole point of the traditional Unix approach is that any components you don't like can be removed and replaced by something else. This is the opposite of the systemd approach. Please don't insult people's intelligence by pretending otherwise.

    2. jake Silver badge

      Re: Honest inquiry

      Frankly, I don't see systemd solving any problems. It doesn't actually fix anything. I do see it adding complex code unnecessarily, which is totally against the entire design philosophy of un*x.

      1. Anonymous Coward
        Anonymous Coward

        Re: Honest inquiry

        Anything which doesn't require a custom script for each service during the boot process gets my vote.

        Upstart, systemd or anything. I can't remember if Upstart can monitor processes or not, but that's something the init system should be able to do that sysvinit can't ( without a bodge like Monit ).

        1. Peter Gathercole Silver badge

          Re: Honest inquiry

          Um. Monitoring processes is exactly what SysVinit does, but it requires you to actually have processes directly created by init that stick around.

          Look at the entries in /etc/inittab. See field 3 in each line, the one that says wait, once or respawn. Respawn allows you to have a service that will be re-stared if the process dies.

          What you are referring to as SysVinit is actually the /etc/rc script that is called from init on runlevel change, that runs the scripts from /etc/rc.d (although different SysV UNIX ports actually implement it slightly differently). While this is part of the init suite, it is not init itself.

          The concept of init in UNIX goes back to before SysV. I have a copy of the Lyons Edition 6 commentary, and that references an init process, although I think that the /etc/inittab file did not exist at that time. I will fire up my Nordier Intel port of Edition 7 VM at some point to refresh my memory about how Edition 7 started the initial processes.

          The rc.d directory heirarchy of scripts appeared at some point between SVR2 and SVR3 IIRC. The first UNIX I remember seeing it in was R&D UNIX 5.2.6 (which was an internal AT&T release).

          1. Peter Gathercole Silver badge

            Re: Honest inquiry

            Back on my own machine. V7x86 partition fired up.

            /etc/init is a binary that is run from inside main.c, and it is crafted as process 1 (the source refers to process 0 as being the scheduler, and is just a loop that sleeps on a timer interrupt, and presumably inspects the process table to schedule the other processes).

            The source for the Edition 7 init is very simple. It handles single and multi-user modes, and runs /etc/rc, and also handles respawning the getty processes (controlled by the entries in /etc/ttys) as they are used by users logging on and off. It's written as an infinite loop with a wait in it. The wait will return every time a process terminates. It then puts a record in utmp, and if the process was a getty or whatever getty exec'd, it respawns the getty.

            Other than that, it does very little. The processes that run at boot are actually started by the /etc/rc script, and that is a simple top-to- bottom script that mounts the other filesystems, starts cron and the update process that periodically.

            So much more simple that the SysVinit that implements inittab. I don't have access to any Bell Labs or AT&T source later than Edition 7, although I guess I could look at BSD, but that may not give any insight to when the full-blown SysVinit appeared.

            I believe that the Edition 8 source may now be at TUHS (at www.tuhs.org). I must check it out, although this is only related to SysV through the common ancestor of Edition 7.

            BTW, Correction to my previous post. Lions is spelt Lions, not Lyons.

            1. Doctor Syntax Silver badge

              Re: Honest inquiry

              "also handles respawning the getty processes (controlled by the entries in /etc/ttys)"

              Ah yes, /etc/ttys, not inittab. But could also be used to respawn other stuff beside gettys if you wanted.

            2. jake Silver badge

              Re: Honest inquiry

              The SysV init started in System III, but I can't remember the details. I'll try to remember to dig through the archives later today.

            3. Peter Gathercole Silver badge

              Re: Honest inquiry @myself

              Hey!

              I've just looked at TUHS, and if you're interested in UNIX source code, there's lots of interesting stuff has appeared there recently.

              Not just source for Edition 8, but Editions 9 and 10 as well.

              The biggest revelation I had was when I found the source for something called pdp11v, which is also called PDP-11 3+2.

              Have a look, and work out what it is yourself! Remember, even large PDP-11s were really rather small (maximum 4MB memory, small 16KB memory segments, maximum of 128KB text and data size for single processes without some fancy overlaying), so someone having got this running was a real feat.

              1. jake Silver badge

                Re: Honest inquiry @myself

                Peter, see my post from 25 days ago:

                https://forums.theregister.co.uk/forum/containing/3142526

                1. This post has been deleted by its author

          2. Doctor Syntax Silver badge

            Re: Honest inquiry

            "how Edition 7 started the initial processes."

            From an inittab as you describe IIRC.

          3. Anonymous Coward
            Anonymous Coward

            Re: Honest inquiry

            Oh yes, I completely forgot about /etc/inittab.

        2. HieronymusBloggs

          Re: Honest inquiry

          "Anything which doesn't require a custom script for each service during the boot process gets my vote."

          You mean like BSD init? That makes unit files look over-complicated.

        3. Doctor Syntax Silver badge

          Re: Honest inquiry

          "I can't remember if Upstart can monitor processes or not, but that's something the init system should be able to do that sysvinit can't"

          If a major service goes down I'd want to know why in case trying to bring it up could do something nasty - nasty as in corrupt or destroy data. An init running round like a hyperactive child trying to restart it would be the last thing I'd need. Init needs to start stuff up at boot time and then restart or stop stuff when it's told to and otherwise keep out of the way.

          1. Anonymous Coward
            Anonymous Coward

            Re: Honest inquiry

            "If a major service goes down I'd want to know why in case trying to bring it up could do something nasty - nasty as in corrupt or destroy data."

            But what if you're pressed on the other side of the coin: It's a "five nine's" service that's gone down, and because it's a holiday or whatever, no one's around to verify its state if it goes down, so you're caught in a dilemma. You need it back up ASAP because it costs you real money otherwise, yet you can't trust the environment to be sound enough to send back up.

            1. Doctor Syntax Silver badge

              Re: Honest inquiry

              It's a "five nine's" service that's gone down, and because it's a holiday or whatever, no one's around to verify its state if it goes down, so you're caught in a dilemma. You need it back up ASAP because it costs you real money otherwise,

              If you're putting five nines before everything else you're worshipping at the wrong altar. Consider the following:

              Maintaining integrity of the data you've got.

              Being sure that new data gets added properly.

              Being available to add new data.

              Availability is a poor third there. Of course five nines availability is something manglement is able to understand and get fixated on. But if you have a big data loss you'll probably lose your five nines whilst you recover it and if you don't recover it all your five nines during the time you were acquiring it turn out to have been a bit pointless. I'm sure there are a few people round KCL who could give you chapter and verse on that.

              TL;DR Five nines is nice to have, no more than that.

            2. Ben Tasker

              Re: Honest inquiry

              > But what if you're pressed on the other side of the coin: It's a "five nine's" service that's gone down, and because it's a holiday or whatever, no one's around to verify its state if it goes down,

              So you've got a service you're advertising as five nines, but haven't provisioned for appropriate monitoring coverage out of hours?

              Your problem there isn't your init system, it's your failure of planning to properly support the service you're offering. As other have said, if the component that went down is brought back up automatically, it could lead to data corruption - so you really want someone to verify things before simply sticking back in service.

            3. BinkyTheMagicPaperclip Silver badge

              Re: Honest inquiry

              If it's a 'five nines' service, then more than one of the same service exists either as a cluster, an active failover, or a DR site. In the case of failure the backup automatically takes over and someone is notified.

              If the primary service falls over for an unknown reason, bringing it back up automatically is almost always the wrong thing to do.

            4. pmb00cs

              Re: Honest inquiry

              if it's a five nines service it isn't running on one single server, and so if one instance goes down it's better it stays down till it can be fixed and brought back up cleanly than it come back up in an indeterminate state and potentially serve corrupt data to your customers, potentially costing you far more than the cost of offering no service for a time. As to "and because it's a holiday or whatever, no one's around to verify its state if it goes down" that's what monitoring and call out rota's are for.

              (and if it is a five nines service running on a single server, it won't stay that way for long)

            5. Vic

              Re: Honest inquiry

              But what if you're pressed on the other side of the coin: It's a "five nine's" service that's gone down, and because it's a holiday or whatever, no one's around to verify its state if it goes down, so you're caught in a dilemma

              SysV always gave you a very simple way of causing services to respawn if you wanted them to. Systemd has not solved any problems in that[1] area.

              Vic.

              [1] Or any other, AFAICT...

        4. John Hughes

          Re: Honest inquiry

          can't remember if Upstart can monitor processes or not
          It can, but at the cost of running everything under ptrace, which is insane.

    3. Tom 7

      Re: Honest inquiry

      Ten years and more ago booting a machine faster was a useful thing. But even a raspberryPi zero is up and running without systemd by the time you've hung your jacket on the back of the chair and cleared the shit off your desk.

      There is no problem for systemd to solve anymore.

      1. James 132

        Re: Honest inquiry

        Boot time was a little bit of flash that was thrown into the discussion to make it an easier sell among enthusiasts - I remember it being a thing with the Arch community in particular when systemd was first adopted in late 2012.

        The thing is, everything has since got slower; a good example is Fedora, which now has an exceedingly long boot time on a mechanical disk, well in excess of 40 seconds, so we're right back to pre-systemd territory as guess what maintainers get lazy, throw a load of unit files at systemd in the belief it will sort them out.

        1. cream wobbly

          Re: Honest inquiry

          "Fedora, which now has an exceedingly long boot time on a mechanical disk, well in excess of 40 seconds" with systemd.

          Jeez, well if 40 seconds is "exceedingly long" you already have other problems. We're running RHEL7 (with systemd baked in) on server and high-end workstation hardware that takes in excess of 4 minutes to decide who it is, why it's been put on this Good Green Earth, also where its arse is. That's before the kernel loads the ramdisk.

          systemd doesn't solve any problems for us, but it brings plenty of new ones.

    4. HieronymusBloggs

      Re: Honest inquiry

      "does the anti systemd crowd actually have an alternate solution to some of the problems systemd wanted to solve?"

      The alternative already exists: stop trying to prevent people from using things that were already working for them. Not everyone has a problem with the things systemd was intended to "solve".

      1. Doctor Syntax Silver badge

        Re: Honest inquiry

        Not everyone has a problem with the things systemd was intended to "solve".

        Systemd - bringing you problems you don't need to solve problems you don't have.

  10. Adrian 4
    Linux

    And there's another thing ..

    Does it remove that pulseaudio crap too ?

    1. Orv Silver badge

      Re: And there's another thing ..

      Pulseaudio is now required for audio on Firefox; they've removed support for ALSA and jack.

      1. GrumpenKraut

        Re: And there's another thing ..

        > Pulseaudio is now required for audio on Firefox;

        Are you sure, on the Poetter-free Debian stable I am typing this firefox works just fine without pulseaudio. Indeed nothing seems to require pulseaudio.

      2. Anonymous Coward
        Anonymous Coward

        Re: And there's another thing ..

        Not removed, just "silenced" in official binaries. Roll your own :P

        1. Orv Silver badge

          Re: And there's another thing ..

          Correct, I overstated it a little. Official binaries don't support anything but pulseaudio, but you can still compile your own that support ALSA or jack. However, since that code is now unmaintained I don't expect it to last all that long.

      3. Kiwi

        Re: And there's another thing ..

        Pulseaudio is now required for audio on Firefox; they've removed support for ALSA and jack.

        Palemoon removes the requirement for Firefox. So does Edge but using Edge is like inserting rusty razor blades into your knob before you take a leak. And pouring concentrated lemon juice on it.

  11. Grommet

    I was neutral about SystemD to start with. But then I started hitting issues with it that I never had with previous init systems. Logging is one issue, and the fact it has it's fingers in way too many other areas bothers me. But stability has taken a nose dive as well now. I never had this many inconsistent boots under the old system. I am so fed up with it now I am considering moving across to a non systemd OS.

    I am fortunate that in my work I deal with pretty much all the major distributions so moving from a deb to an rpm or even a pacman based distro is no hardship at all. The one that is probably going to get my attention though is arch linux with openRC. To avoid issues in future on my desktop I will also probably move to one of the lightweight Desktops such as Xfce... It does feel like a step back a little but I would rather have stable than pretty...

    For me an OS is a tool that lets me get my work done nothing more. I am not religious about it at..

    I had even considered moving across to one of the BSDs. Under systemd it is not quite as bad as under Windows but boy is it heading in that direction.

    1. GrumpenKraut

      > Under systemd it is not quite as bad as under Windows but boy is it heading in that direction.

      That's exactly what some people think about systemd, me included.

      Another WIndow-sy thing being the heavy-weight Desktops (Gnome and KDE), put one can always take a lighter one (such as Xfce) or even just a plain old window-manager.

    2. Tim Bates

      Same here. I personally don't care whether I have sysvinit, upstart or systemd, as long as it works....And systemd simply does NOT work.

      I have had so many random and weird failures with systemd that I can not trust it. Sysvinit might not be cool or super fast, but it works reliably.

      1. Anonymous Coward
        Anonymous Coward

        > I have had so many random and weird failures with systemd

        A favourite at the moment is one of four apparently identical desktops machines, one of which is stuck in the boot process allegedly trying to make a network connection, either before or after connecting to an NFS server. All is fine in recovery mode and it works as expected, but when systemd has full rein, it spits a dummy and won't tell me why. It may be logging loads in its binary database, but if it won't condescend to letting you log in to look, it's no use. This is not progress.

        1. James 132

          The absolute most dysfunction I've observed from systemd has arisen from the NFS and networking, on two production servers. I think it was because of systemd's knowledge of the network state, or lack whereof, but I am not certain, and there's a couple of old bugzilla #s out there with similar issues. The developers don't give a toss.

          It doesn't help that it's very difficult to tell what's going on, even if you can get to the journal.

          1. CrazyOldCatMan Silver badge

            The developers don't give a toss.

            And this is my other reason why I'll never use systemd if I can use something else. To have the principal developer of one of the most critical parts of the running system tell people that faults and failure are either not his problem or not his fault[1] is not acceptable.

            Either be professional and support your code, or pick up your projectile toys and go away.

            [1] Look - I can accept that some edge cases are going to be fairly unique. But when there are so many edge-failure cases that the dev refuses to acknowledge, it makes you start to wonder - especially when taking his ignorance about how the rest of the ecosystem works into account..

        2. Kiwi

          It may be logging loads in its binary database, but if it won't condescend to letting you log in to look, it's no use

          But, but binary logs are TEH GREATEST and are like, you know, PROGRESS! We must have NEW ways of doing things! We can't stick with old, simple, tried and perfect systems! And it's so hard to have stuff that reads log files if it's not binary.. and. and.. PROGRESS! So what if it breaks when one bit gets flipped, it's PROGRESS! Take your old still-readable-with-25%-corruption text logs that are so old skewl and give us TEH NEW and TEH PROGRESS!

          (Ok, sounded funnier in my head when I started....)

          1. Anonymous Coward
            Anonymous Coward

            binary error logs in principle could

            have a few advantages, if done sensibly (e.g. a combination of the best of, rather than the worst of, both the Windows NT event logger and GUI, and VMS's vintage-1978-and-still-working ERRLOG.SYS and associated analysis tools).

            But systemd's implementation of binary error logging seems to come with too much baggage to make it interesting to many people.

            1. Kiwi

              Re: binary error logs in principle could

              binary error logs in principle could have a few advantages, if done sensibly

              I can't see any myself. For a start, the database (or however else the log data is stored) could be fairly easily corrupted just by a flipped bit - say a sizeof or pointer gets a bit flipped meaning that a record is given a size of 512 bytes where it should be 1024, that could cause further problems down the line. A pointer to the wrong place for a record of course can also cause issues. It takes more code to cover that.

              Years ago I wrote some software that parsed config files for various addons to a package to build the config for an addon I wrote. It was a simple job of reading the text configs line by line for certain keywords, reading the rest of the line when such a keyword was found, formatting the data in a way that my addon wanted, and spitting the new line out to my systems config file (actually the config builder was an addon to an addon I guess..). IIRC I also wrote some stuff to monitor my BBS's mailer or tosser logs for certain errors and if so to run another task based on that (pulling the damaged mail packets out to a temp file and alerting me so I could have a go at manually fixing them or something like that - we're talking some 20 years ago so memory is like a Scottish fog when it comes to that time of my life...).

              Once you have the basic concept of reading text files down (in a software sense I mean), monitoring and processing log files is quite easy to automate. And you can do it on a dead system by pulling the logs into a live system if you want. And even with huge amounts of corruption you can read text files easily (though numbers may be a problem - if 1756723ZK245 appears you know something is wrong, but where 18457 appears when it should be 17457 you're far less likely to see the problem). Binary logs would have the same problem, and would be more susceptible to smaller amounts of data corruption (as above with pointers - if a binary log's pointer to the next record is stuffed, so are you. A text log's pointer to the next record means you move your eyes to the next line (or read in a new line). If the system stops entering the new line characters you can look for other keys (eg many log lines start with "[") and use various text processing tools to automatically add a newline for you if you want. A binary system may not be so easily fixed.

              Because of the way text logs are written, if the timestamps get corrupted by any means (whether a failed system clock or attempt at tampering or somehow the data coming from whatever function syslog etc use to get the time is giving corrupted data, eg #saf4@:ce instead of "2017 04 25") you can still follow most things in sequence. How would a binary log system handle corrupted time stamps, or something where the system time was significantly changed?

              I am not against better logging and better monitoring of logs. Anything that makes most people's jobs easier is a good thing. I am against things that make most peoples jobs harder, or make jobs easier 90% of the time but make them impossibly hard and stressful those few times when things get really messed up. And it seems that systemd not only makes things so much harder when things break, but (reading comments here) is also too often responsible for the breakage.

        3. CrazyOldCatMan Silver badge

          All is fine in recovery mode and it works as expected, but when systemd has full rein, it spits a dummy and won't tell me why

          I have this with my Ubuntu-based mail server - it's about 12 years old and has gone through many, many version updates - mostly without a hitch (currently on 14.04 - it keeps naging me to update to the latest LTS release but I don't dare - and this started out as a physical box that, eventually, got made into a VM..).

          The majority of the problems started when Ubuntu went over to systemd. Like the OP, I have to boot the vm in recovery mode (it's a VM, running under KVM) in order to get it to boot correctly - otherwise I just get a blank screen and no ssh daemon[1].

          I have a backup mailserver vm running on FreeBSD 11 but getting my qmail-based stuff to work properly (and the various Apache websites to serve properly) is being a bit of a pain. But, sooner or later, the pain of *not* moving is going to be greater than the pain of moving and I'll be taking a few days to migrate stuff properly.

          [1] And nothing in the binary log either - I suspect that it doesn't even get that far.

    3. James 132

      Take a look at Void. It is a rolling release, uses runit for service management, and has an elegant package manager. Absolutely stonking distro, IMHO.

    4. Anonymous Coward
      Anonymous Coward

      > arch linux with openRC. To avoid issues

      > in future on my desktop

      Manjaro (based on Arch) had (may still have) an openrc spin, and indeed, one based on XFCE. I ran it for a while, because it's easy to install. but systemd is tenacious in making demands, and all kinds of little issues came up, all relating to systemd dependencies, and this with XFCE, which should make few such demands. Can't blame those who ran up the openrc spin, because Devuan's timescale shows how difficult it must be to keep systemd out.

      1. AJ MacLeod

        This is where Gentoo shines - if you don't want systemd, or PulseAudio etc you don't have to have them, almost regardless of which packages you install (so long as the software itself doesn't have a hard dependency on systemd or whatever you're trying to avoid.)

        Your entire OS and applications are built with the options YOU want, not what someone else thinks is best. It certainly does take a bit of extra time to get a system up and running but for systems you care about it's well worth it in the long run.

        I'm happy to see Devuan making this release and I hope they gain some active users - if for no other reason than to give sloppy application developers less excuse for depending needlessly on systemd or related tentacles.

  12. jMcPhee
    Devil

    What is systemd??

    I've been running Slackware for almost 25 years and have never seen systemd

    1. Chika
      Happy

      Re: What is systemd??

      And may you never have to.

    2. jake Silver badge

      Re: What is systemd??

      I, too, have been running Slackware for nearly 25 years. But that doesn't mean I'm unaware of FOSS projects that are outside of the Slackware sphere of reference ...

  13. Anonymous Coward
    Anonymous Coward

    Cat among the pigions but...

    From the point of view of an end user does systemd or sys V init make any difference or is it just something for those totally unhelpful twits on the forums to argue about. Most end users are not interested in compiling anything, in fact many get upset with the process of installing a program and its dependencies, they just want to use what is before them.

    Linux will never be the universal OS as long as these arguments continue and it is difficult for the average user to install and manage what they want to use. It will be seen as the OS of those that want to be superior to everyone, the fact it is used on servers and in the data centre only reinforces that view.

    Before you hack me to pieces, I am just an engineer sitting on the sideline trying to make sense of these exotic arguments, also I use OS/2 as my main OS.

    1. Grommet

      Re: Cat among the pigions but...

      I would have been quite happy with systemd on my desktop if it didn't break stuff. Servers are a different matter. For instance on my Desktop I use Mint, on servers it is mostly Debian or Centos.

      So I am not tied to any particular distro. I have no principled view on what should be used or how it should work. I am not adverse to change.

      My problems with systemd started when my desktop stopped booting into a consistent state. Tracking down the problem was hard because of binary logging, having to futz about to get normal logging working was just an inconvenience. However the fact that I was having to problem solve a boot process for the first time ever was shocking for me. I have never in the last 20 years had to problem solve the boot process in linux. That is my problem with systemd. It is not just an init system, it has it's hooks into other stuff and creates dependencies that weren't there before.

      If systemd had simply worked like the old init system did and hadn't created any problems for me I wouldn't be posting here.

    2. AdamWill

      Optional

      "From the point of view of an end user does systemd or sys V init make any difference or is it just something for those totally unhelpful twits on the forums to argue about."

      About 5% of #1, 95% #2.

      1. HieronymusBloggs

        Re: Optional

        "About 5% of #1, 95% #2."

        Yes, all those people whose systems have been broken unexpectedly by systemd are just "totally unhelpful twits". It is obviously perfect and they are delusional. </sarcasm>

    3. Orv Silver badge

      Re: Cat among the pigions but...

      I think the "universal OS" trope is the whole problem, actually. Servers and desktops have very different needs and we shouldn't expect to run the same distribution on both. Things like systemd and Network Manager that are added for desktop convenience cause serious problems when they're shoehorned onto servers.

      1. Anonymous Coward
        Anonymous Coward

        Re: Cat among the pigions but...

        > Things like systemd and Network Manager that are added for desktop convenience [...]

        Seems more like "laptop" convenience. My desktop doesn't need dynamic <anything>, as it pretty much the same daemon and network configuration as when it was first set up, months ago.

        1. Doctor Syntax Silver badge

          Re: Cat among the pigions but...

          Seems more like "laptop" convenience.

          Not even that. I'm running sysvinit Debian LTS on my laptop, no problem.

      2. Doctor Syntax Silver badge

        Re: Cat among the pigions but...

        "Servers and desktops have very different needs"

        They have very similar basic needs. They need to work.

        1. Charles 9

          Re: Cat among the pigions but...

          Not really. A desktop has to work with much more varied hardware configurations including consumer-designed graphics cards with GPUs and 3D demands as well as things like hot-plugging USB hardware of all shapes and sizes from media devices to display adapters (and a good chunk of which are black-boxed, too), in mobile settings where people may be switching from access point to access point, maybe even using LTE modems and so on.

          As they say, the devil is in the details. There's a world of difference between making a fixed-hardware interface-light server work and making a desktop that could have any number of things attached to it work.

          1. Graham Dawson Silver badge

            Re: Cat among the pigions but...

            As I pointed out below, this was exactly what udev was built to handle. It had issues, but it was far superior to the prior solutions. It worked. it just needed to be made more robust.

            Instead, Poettering and Sievers decided that udev should be rolled into systemd and made some argument about the init having to know about hardware changes to justify the change. The init doesn't need to know this. Not this intimately. udev, formerly a "do one thing" project, became locked into the "do lots of things" project and has been steadily locked down and crippled to fit the vision of systemd - and of course, in the process, it has forced a dependency on systemd in a wide number of subsystems that formerly only had a dependency on udev.

      3. Down not across

        Re: Cat among the pigions but...

        Things like systemd and Network Manager that are added for desktop convenience cause serious problems when they're shoehorned onto servers.

        NetworkManager should be burned on a stake. Twice. Then nuked from orbit. It has absolutely no place on a server. For some reason CentOS insists on it and you have to waste time kicking it back under the rock it crawled from.

    4. HieronymusBloggs

      Re: Cat among the pigions but...

      "From the point of view of an end user does systemd or sys V init make any difference or is it just something for those totally unhelpful twits on the forums to argue about."

      If you read some of the comments on this thread (ignoring the obviously shouty ones) and follow the links to systemd bugs it should be fairly obvious that there are serious problems. As an end user you presumably use web sites. If web site administrators can't keep their systems running reliably due to obscure faults it will affect you as an end user.

      "I am just an engineer sitting on the sideline trying to make sense of these exotic arguments"

      As an engineer I wouldn't expect you to have much difficulty with that.

    5. GrumpenKraut
      Megaphone

      Re: Cat among the pigions but...

      > Most end users are not interested ...

      Not helpful, I am not "most end users".

      When it comes to computers I am a raging fascist pig: the thing has to do what I want it to do and I VERY much want control over it. That said, I refuse to use a piece of software written by some know-it-all that reduces my control for doing the most important things next to the O/S kernel.

      Funny how I never ever witnessed failure to reach a consistent state after booting right until systemd entered the picture. That failure alone disqualifies systemd for me.

    6. Doctor Syntax Silver badge

      Re: Cat among the pigions but...

      "From the point of view of an end user does systemd or sys V init make any difference"

      Maybe not when everything works. But when everything works you don't need your backups, UPS etc. either.

  14. Anonymous Coward
    Thumb Up

    My hats off to you guys!

    Just mentioned for context: this isn't for me because I stopped using Linux a long time ago, slowly turned into a veteran FreeBSD user.

    But that doesn't mean I can't appreciate and admire all the work and effort which must have gone into this. I love it! I read so many (bad) stories about systemd and having my roots fully tied into Unix as well as the Unix philosophy I don't think it should come as a surprise that I dislike systemd as well, even out on principle alone. In my opinion systemd is better described as usurpd, because that's all it does.

    So yeah, I really admire the effort that must have gone into this and I really hope they can keep it up. Let the community decide what they want. And pardon me for laughing it up when it turns out that this will become more popular than other systemd affected environments ;)

  15. Anonymous Coward
    IT Angle

    Systemd v sysvinit

    I'm running Ubuntu under systemd and can't tell the difference. From what I have managed to glean online the main objections to systemd is that it performs functions that used be done elsewhere. And when problems are discovered (systemd and dbus) the answer from the lead systemd developer (Poettering) is that - it isn't our problem.

    1. Chika
      Mushroom

      Re: Systemd v sysvinit

      the answer from the lead systemd developer (Poettering) is that - it isn't our problem.

      And that's one of the biggest reasons why Poettering is mistrusted here. He acts like his word is law, as though he was the second coming of Linus. Systemd is not a replacement for init in his eyes, he wants it to eventually become a replacement for Linux in general, and not only does he have the trust of Redhat, but all the major distros are following him too. I killed off openSUSE on my latest box because it relies too heavily of systemd and Poettering's shite but though I've moved to Mint, I can see the creep going on there too. At least one of the mainstream distros needs to put him in his place but none of them have the balls to do it. If it takes something like Devuan, then more power to them!

      1. GrumpenKraut
        Pint

        Re: Systemd v sysvinit

        > And that's one of the biggest reasons why Poettering is mistrusted here.

        That. Trusting someone who doesn't take responsibility for his shit with a core service? Not a good idea in my book.

        Anyway, past beer o'clock here. -------------->

    2. Long John Brass

      Re: Systemd v sysvinit

      I'm running Ubuntu under systemd and can't tell the difference

      And that's fine; No it really is, But its not the issue at stake. Some of us HAVE had issues with systemd. And when we find that we want to take it off our machines WE CAN'T; And that is why all the hate.

      Just because you can't see or understand the issues with systemd on your laptop doesn't mean that Me with ~500 machines to take care of, if forced to use that festering pile of shit! but ripping systemd out of many modern distros is a fraught and painful experience (I suspect by design)

      Forget arguments about it's design, forget ease of use arguments, forget stability arguments... It's about the choice of using or or not; And I get VERY grumpy when people try to ram shit down my throat.

    3. John Hughes

      Re: Systemd v sysvinit

      Systemd v sysvinit

      I'm running Ubuntu under systemd

      So why are you writing about systemd vs sysvinit? Ubuntu used to use upstart, not sysvinit.

  16. Kurgan

    I use Devuan since older betas - it's fine

    I'm a long time (since versione 3) Debian user, and now I have both Debian Jessie (with systemd removed) and Devuan Jessie beta installed in about 50 servers total. They both work fine. On my desktop I use Mint. I will end up using systemd on my dekstop distro, I suppose, and I can live with it as long as it does not crash too often. But I don't want it in my server.

  17. DCLXV

    I don't understand the hype

    Last I checked, Devuan repos were missing a number of packages Debian repos weren't and it's still unclear what exactly, if anything, Devuan offers that Debian with systemd removed wouldn't do.

    Unless someone can explain what specifically the advantage is, seems like Debian with SysV and OpenRC is still preferable to dabbling in Devuan.

    1. SImon Hobson Bronze badge

      Re: I don't understand the hype

      You CANNOT fully remove SystemD from Debian - that is just a myth.

      AT THE MOMENT it is near enough possible to get rid of all the functional bits of SystemD, but as time goes on, SystemD spreads it's tentacles into more and more packages.

      Basically, SystemD re-implements many previously standard and well understood interfaces. Logging ? Syslog or one of it's modern replacements). Time ? NTP. And so it goes on.

      The SystemD camp keep deprecating these standard interfaces - so that packages increasingly over time have to use the "new 'improved'" interfaces or they can't run properly on SystemD systems. Once they do that, then they won't run on systems without those interfaces - ie they won't run without SystemD.

      And because Debian (through a very flawed vote process that actually didn't support it) chose to make SystemD the default - any bugs along the lines of "doesn't work properly without SystemD" are just closed as "won't fix".

      What Devuan does is take all the Debian base stuff, and fix all those gratuitous dependencies on SystemD. The vast majority of packages are just taken direct from the Debian repositories - the Devuan specific ones are the ones with the crap removed. The expectation is that over time, unless Debian sees sense, that Debian will slowly diverge from Devuan as it allows the SystemD crap to spread.

      1. Doctor Syntax Silver badge

        Re: I don't understand the hype

        "The expectation is that over time, unless Debian sees sense, that Debian will slowly diverge from Devuan as it allows the SystemD crap to spread."

        My fear is that as the crap spreads it will become impossible to build a Linux system without it. I hope this fear is misplaced.

        1. Graham Dawson Silver badge

          Re: I don't understand the hype

          Given that's pretty much what poettering wants...

        2. HieronymusBloggs

          Re: I don't understand the hype

          "My fear is that as the crap spreads it will become impossible to build a Linux system without it."

          A further worry is that software which also runs on other Unix-like systems will become unavailable on those due to the extra effort of maintaining it.

          1. Doctor Syntax Silver badge

            Re: I don't understand the hype

            "A further worry is that software which also runs on other Unix-like systems will become unavailable on those due to the extra effort of maintaining it."

            Yup. That too.

      2. Ramazan

        Re: I don't understand the hype

        "You CANNOT fully remove SystemD from Debian - that is just a myth"

        You actually can. But GNOME, KDE, MATE and Cinnamon will have to be removed too. XFCE and LXDE may be spared by downgrading a pair of packages to oldstable versions.

  18. steelpillow Silver badge

    More honest questions

    I dumped GNOME a few years back and switched to MATE. SystemD unnerves me for reasons discussed but the old way is, to be honest, a bit clunky for the 21st century.

    First, has MATE had the sense to steer clear of SystemD as a dependency?

    Second, and please don't blow my head off, it's just an idea, is it practicable to fork SystemD and castrate its excesses to create a genuinely clean init subsystem?

    1. Charles 9

      Re: More honest questions

      "Second, and please don't blow my head off, it's just an idea, is it practicable to fork SystemD and castrate its excesses to create a genuinely clean init subsystem?"

      I think for many your last suggestion is the nail in systemd's coffin. The group centered around the development of systemd appears insular and opinionated. If it weren't for the "my way or the highway" attitude existing there (and since it's coming mostly from up top, there's no real way to control it), we might see support for paring things down.

      Because there ARE things that could use addressing, like better support for dynamic hardware configurations and especially hot-plugging (not prevalent in servers, yes, but essential for end-user stuff).

      There's also debate about the very core of the UNIX philosophy because "doing one thing" doesn't guarantee they'll do it RIGHT or CONSISTENTLY, and you need both in order to ensure the stable interrelationship that is essential to make a process chain work. Interdependency chains create "weak link" problems that aren't always obvious. Nothing fouls up a maintainers day like one of those "one things" going WRONG, messing up the process chain, and then mangling the logs and backtraces to make backtracking difficult. It doesn't help that there's no real manual of style for scripting or configuration files, so each one does things differently leading to more inconsistency. From my perspective, the whole problem is something that's neither here or there: in other words, it's complicated, and there's no real ability to debate over the best way to approach this due to the spate of extremists in the discussion (see the systemd problem above).

    2. Anonymous Coward
      Anonymous Coward

      Re: More honest questions

      >Second, and please don't blow my head off, it's just an idea, is it practicable to fork SystemD and castrate its excesses to create a genuinely clean init subsystem?

      Someone tried this. It's called uselessd. I haven't heard anything about it in a while.

      1. Charles 9

        Re: More honest questions

        Probably because it wasn't intended to be an actual fork but rather a demonstration on just how tightly integrated the systemd components are. Sort of a, "Oh, you say it's so simple?" response to claims that you can separate the components.

        As I've mentioned, the desire to have this kind of integration appears to come from up top, meaning any attempt to divorce the init part of systemd from the rest is unlikely and it would make more sense to start from scratch. Trouble is, something as serious as an init replacement, especially for modern environments, will likely need some backing, and most commercial interests that back Linux projects are backing systemd.

        1. Doctor Syntax Silver badge

          Re: More honest questions

          "most commercial interests that back Linux projects are backing systemd."

          Let's not forget that the commercial interest that most strongly backs systemd also maintains the systemd-free RH6. Hmmmm.

          1. Anonymous Coward
            Anonymous Coward

            Re: More honest questions

            > Let's not forget that the commercial interest that most strongly backs systemd also maintains the systemd-free RH6. Hmmmm.

            That's only because systemd wasn't an option at RHEL6 release, and RH avoid breaking binary compatibility for point releases. Otherwise their enterprise customers would throw a fit.

            It's in RHEL7 & 8 though, so anyone sticking to that company's products will probably need to get used to it.

      2. HieronymusBloggs

        Re: More honest questions

        "Someone tried this. It's called uselessd. I haven't heard anything about it in a while."

        Unfortunately the uselessd project is now dead.

    3. keithpeter Silver badge
      Windows

      Re: More honest questions

      "First, has MATE had the sense to steer clear of SystemD as a dependency?"

      @steelpillow

      https://unix.stackexchange.com/questions/279603/using-mate-desktop-without-systemd

      Above has a discussion and links to other resources including the Arch wiki and to Gentoo documentation.

      http://wiki.mate-desktop.org/download

      link above lists the installation instructions for a range of Linux/*BSD distributions.

      It looks as if the answer to your entirely reasonable question is "it depends on which options in the .config file the packager decided to enable"

      1. steelpillow Silver badge

        Re: More honest questions

        @keithpeter many thanks for the links. Next Debian install I'll opt out of SystemD and trust apt to pull it back in as a MATE dependency. I don't care if some silly blob sits on my HD and does nothing, I've been doing that myself for years.

    4. Ramazan

      Re: More honest questions

      "First, has MATE had the sense to steer clear of SystemD as a dependency?"

      Nope. If you want to remove systemd from Debian, you should switch to another desktop environment.

  19. poohbear

    Logo

    Am I the only one who thinks that that logo is way cool?

    1. Anonymous Coward
      Angel

      Re: Logo

      It's kinda neat how they used only 2 unique shapes plus a swoosh to make up the whole word but to answer your question, you might be.

      (angelface because that's a swoosh)

      1. nauved

        Re: Logo

        No, it's not a swoosh. It's a segment of an orbit. Very appropriate since Devuan releases are named after Minor Planets in our solar system (and one of the lead developers is an astronomer)

        1. Anonymous Coward
          Anonymous Coward

          Re: Logo

          That's quite all right but I was under the impression that all orbits are swooshes. That page refers to orbit repeatedly and calls it a swish instead but that really doesn't matter-- it might as well be called a Comic Sans. I would have probably made a huge fuss over just turning the 'U' on its side to make the 'D' so it's probably just as well nobody asked me :D

  20. Philip Hands

    Re: Cat among the pigions but...

    I'm puzzled by people that raise the bogey man of "binary logging"

    It's really not _that_ hard to discover that the command 'journalctl' will spew out the contents of those log files, as text, with the added bonus of having the opportunity to add options that give you the logs from this boot, or any previous boot, or only logs associated with particular binaries or services (if you can work out the not very memorable options required).

    You can pipe that into the grep command that you were going to point at your logs, and get the same result, with the added bonus that you don't have to guess the right log file, or wonder if some of the messages you were looking for went elsewhere, or decompress the older compressed (and hence binary) logs, and then sod about stitching them back together with cat if you want to grep back across several of those log files.

    Not that any of that's particularly relevant to Debian, which still defaults to running rsyslogd, with its normal text files, and will only do binary logging if you choose to create the /var/log/journal/ directory.

    1. Charles 9

      The problem comes when you don't have access to journalctl. Say you're booting from an external device because the original drive no longer boots (or worse, you transplanted the drive to another system). Odds are, the journal's mangled and the recovery system you're using doesn't grok the binary log. It's somewhat easier to make at least some sense of a mangled ASCII file; it's one time where INefficiency is a boon (more room for error). As for filtering, as long as the log's well-formatted, you can simply run an ASCII log through the usual trove of text-selector utilities like grep to winnow things down. You'll have to demonstrate (very useful) things that simply cannot be done any way OTHER than a binary log.

    2. Doctor Syntax Silver badge

      Re: Cat among the pigions but...

      "It's really not _that_ hard to discover that the command 'journalctl' will spew out the contents of those log files, as text, with the added bonus of having the opportunity to add options that give you the logs from this boot"

      One of the times when you really need to see logs is when the sodding thing won't boot cleanly. At least with a text log you can take the disk out and mount it on something else to see if you've got anything.

      But basically, a binary log is hiding things from me. I have to trust the folk who are hiding things from me to grant me a view of what they're hiding. And I have a fundamental distrust of people who hide things.

    3. Adrian 4

      Re: Cat among the pigions but...

      You can grep the output of a translator, but what if you're unsure where the process decided to log its thing and you want to grep /var/log/* for the process name ?

    4. HieronymusBloggs

      Re: Cat among the pigions but...

      "I'm puzzled by people that raise the bogey man of "binary logging""

      Next time you have to mount a drive from an unbootable system in another (possibly non-systemd) system to read the logs your puzzlement may disappear.

      "Not that any of that's particularly relevant to Debian, which still defaults to running rsyslogd, with its normal text files"

      AFAIK (and corrections welcome if I'm wrong) binary logging can't be turned off, only masked or redirected to /dev/null. On a heavily loaded system having two sets of logs running could have a significant performance impact.

    5. Kiwi

      Re: Cat among the pigions but...

      'm puzzled by people that raise the bogey man of "binary logging"

      Are the log files still accessible if something has corrupted oh, lets say 1% of the log? And as Charles points out, if journalctl isn't functional/accessible?

      Can you do stuff like grep+tail and so forth?

      Text is such a basic system. Quick and easy to parse (your grep example means I have to learn and remember extra commands just to see what I can see easily normally). All systemd does is takes a basic, simple, and functional system and turns it into a complex pile of rubbish that will be unusable when you really need it. I doubt that any of the examples of "problems" you claim it solves (eg "with the added bonus of having the opportunity to add options that give you the logs from this boot, or any previous boot, or only logs associated with particular binaries or services") really exist for anyone - I can quickly and easily find the logs for the services I want and should they not have a log file of their own (on my systems stuff that seldom really matters gets one place, anything I wish to keep separate gets its own log file), and just the timestamp on a log file can tell me a lot. This crap doesn't solve any problems, doesn't make any tasks easier, and just ads complex junk that'll lead to problems. We need to be rid of systemd ASAP.

    6. nijam Silver badge

      Re: Cat among the pigions but...

      > I'm puzzled by people that raise the bogey man of "binary logging"

      I'm puzzled that anyone thought binary logging was of any use whatsoever. Saying it's not a problem because you can fix it with yet another piece of otherwise unnecessary baggage is rather unhelpful.

  21. taxythingy

    Systemd v17.0

    Now with email!

    1. Anonymous Coward
      Anonymous Coward

      Re: Systemd v17.0

      Future History Of Init Systems

      2015: systemd becomes default boot manager in debian.

      2017: "complete, from-scratch rewrite". In order to not have to maintain backwards compatibility, project is renamed to system-e.

      2019: debut of systemf, absorbtion of other projects including alsa, pulseaudio, xorg, GTK, and opengl.

      2021: systemg maintainers make the controversial decision to absorb The Internet Archive. Systemh created as a fork without Internet Archive.

      2022: systemi, a fork of systemf focusing on reliability and minimalism becomes default debian init system.

      2028: systemj, a complete, from-scratch rewrite is controversial for trying to reintroduce binary logging. Consensus is against the systemj devs as sysadmins remember the great systemd logging bug of 2017 unkindly. Systemj project is eventually abandoned.

      2029: systemk codebase used as basis for a military project to create a strong AI, known as "project skynet". Software behaves paradoxically and project is terminated.

      2033: systeml - "system lean" - a "back to basics", from-scratch rewrite, takes off on several server platforms, boasting increased reliability. systemm, "system mean", a fork, used in security-focused distros.

      2117: critical bug discovered in the long-abandoned but critical and ubiquitous system-r project. A new project, system-s, is announced to address shortcomings in the hundred-year-old codebase. A from-scratch rewrite begins.

      2142: systemu project, based on a derivative of systemk, introduces "Artificially intelligent init system which will shave 0.25 seconds off your boot time and absolutely definitely will not subjugate humanity". Millions die. The survivors declare "thou shalt not make an init system in the likeness of the human mind" as their highest law.

      2147: systemv - a collection of shell scripts written around a very simple and reliable PID 1 introduced, based on the brand new religious doctrines of "keep it simple, stupid" and "do one thing, and do it well". People's computers start working properly again, something few living people can remember. Wyld Stallyns release their 94th album. Everybody lives in peace and harmony.

      1. Anonymous Coward
        Anonymous Coward

        Re: Systemd v17.0

        Dammit, only 130 years to wait.

  22. Anonymous Coward
    Anonymous Coward

    The code is also junk. For example, rather than working off proper parameterization, systemd checks for hard-coded paths (/proc, /sys) to handle them differently. I imagine Poettering's main contributions now are reviewing pulls and reformatting XML files.

  23. DrXym

    They missed a trick

    Should have called their dist Amix after the Amish. Technology should go this far and no further.

    1. Graham Dawson Silver badge

      Re: They missed a trick

      Not every change is for the better. systemd changes a whole bunch of things for absolutely no purpose, to the detriment of users and developers. It isn't any form of progress. This idea that new is always better is a fallacy.

      systemd is a regression - a reduction in quality and maintainability. Rejecting regression is a good thing.

    2. Charles 9

      Re: They missed a trick

      You forget. The Amish are technophobes. They're very much against using electricity; computers are essentially taboo to them.

      What you probably intend to coin is perhaps "Luddix" on the belief that technology isn't the answer to everything.

      PS. Back to the discussion. If we do have to go back to square one, how DO we better handle dynamic hardware configurations where even basic things like displays can come and go on a moment's notice?

      1. HieronymusBloggs

        Re: They missed a trick

        "how DO we better handle dynamic hardware configurations where even basic things like displays can come and go on a moment's notice?"

        By making a solution that doesn't break things for users who don't require that. Most of the (rational) criticism of systemd is that it makes things unnecessarily difficult for those who don't need it.

        1. CrazyOldCatMan Silver badge

          Re: They missed a trick

          By making a solution that doesn't break things for users who don't require that.

          *DING* *DING* *DING* *DING*

          For my use-case (and yes, I'm aware that that my use-case might not be the same as others, but it's pretty standard - it's a headless server VM with a fixed, unchanging and non-dynamic hardware set), systemd introduces a whole set of cruft and services I DON'T NEED!

          At least one of which means that I can't boot the VM in anything other than recovery mode.

      2. Graham Dawson Silver badge

        Re: They missed a trick

        Udev handled that just fine... which is why they rolled it into systemd I guess.

    3. HieronymusBloggs

      Re: They missed a trick

      "Should have called their dist Amix after the Amish. Technology should go this far and no further."

      Rejection of a flawed new technology does not indicate a rejection of all that is new. It indicates a rejection of flaws. (I suspect you already know that).

    4. DrXym

      Re: They missed a trick

      Except systemd is for the better. Virtually all of the objections about it are absurd.

      1. Charles 9

        Re: They missed a trick

        Really? Then perhaps you can list and rebut all the objections to it, including boring things like ntp and udev best kept separate, not using an ASCII log that can be read easily even if you're forced to read a crashed drive by raw sectors, and especially the attitude coming from up top of "my way or the highway," and no, Linus is better than Pottering in this regard. Linus objects to stupid stuff. Pottering objects to stuff that isn't his.

        1. Anonymous Coward
          Anonymous Coward

          Re: They missed a trick

          Is Poettering related to Daniel J. Bernstein - they seem to share the same basic beliefs?

          1. Tom 38

            Re: They missed a trick

            djb and Poettering are very different. djb is an exceptionally smart cryptographer that no distro trusts, and Poettering is an exceptionally naive developer that every distro trusts.

            The only similarity between the two is that they both have the firmly held belief that they are right; when it comes to security, I'm inclined to trust djb on that regard.

          2. CrazyOldCatMan Silver badge

            Re: They missed a trick

            Is Poettering related to Daniel J. Bernstein - they seem to share the same basic beliefs?

            No - Dan knows what he's doing and is a capable developer..

            (I've used his stuff for years - can be a steep learning curve but, once installed, it Just Works(tm))

        2. DrXym

          Re: They missed a trick

          You can have ASCII logging. A simple Google would show you how to set it up, assuming your dist doesn't already. It would also explain the rationale for binary logging (e.g. forward secure sealing, capturing extra information, better indexing, tamper detection etc.).

          I have no idea what you mean about ntp and udev being kept separate. Perhaps you're referring to the fact that systemd package contains a lot of low-level commands that you are free to use or not use as your requirements dictate. Systemd provides a SNTP (S for simple) client called timesync. You are completely free to install a full blown client-server ntpd if you desire but many deployments don't need that complexity and a simple NTP client means they can avoid installing ntpd altogether.

          But hey, systemd is evillll!!! Let the dance of derp continue.

          1. Charles 9

            Re: They missed a trick

            Anything that involves a translation means things can get LOST in translation, especially if a system is heavily used. START with an ASCII log, THEN work from there on an AUXILIARY basis. Until you can prove yourself able to dig through a mangled journal on a crashed drive using a raw sector editor (because the system you're using for the post-mortem may not even be a Linux machine, so forget about one that groks a binary log to say nothing of an extended filesystem), don't even get started.

            Why MUST the log be binary for forward-secure sealing? Why not encode a TEXT log and append the Hex-encoded hash to the log? You get your signature AND maintain an ASCII log that can still be read in the event of a disaster. It's nothing more than a blockchain, and you don't need to use binary formats to create a blockchain.

            As for enclosing those utilities, remember the old Microsoft mantra? The three E's? Embrace, Extend, and Extinguish. This seems like a blatant attempt to usurp baseline utilities and take over their control so that no one else can keep up? Look at what happened to udev, which was working pretty well all by itself. Between it and the existing init systems, you'd be well on your way to solving most of the existing problems with dynamic hardware, containerization, and so on while still keeping things distinct.

            And what about Bug #5644? In any other circles, this would be a Drop Everything because it breaks a cardinal rule of Linux (Don't allow easy tampering of the root). Here it's a WONTFIX. And not because it's a non-issue, because no real reason is given for ignoring the issue. Where I come from, we call that "taking the ball out of spite" and consider this a sign the project is Not Ready for Prime Time and the head to be blackballed.

            Frankly, if they could demonstrate one clear and present need that systemd AND ONLY systemd solves by its particular methodology, we'd probably pay at least some attention to it. But until then...

          2. HieronymusBloggs

            Re: They missed a trick

            "You can have ASCII logging. A simple Google would show you how to set it up, assuming your dist doesn't already."

            Unfortunately it doesn't tell me how to turn off binary logging, only mask it or redirect it to /dev/null. I don't want the extra processing overhead of generating a redundant set of logging data only to dispose of it.

            The problem here isn't that alternatives can't be used, but that a lot of the stuff built into systemd can't be _removed_ .

            1. DrXym

              Re: They missed a trick

              "Unfortunately it doesn't tell me how to turn off binary logging, only mask it or redirect it to /dev/null. I don't want the extra processing overhead of generating a redundant set of logging data only to dispose of it."

              You can turn off the storage in journald by adding Storage=none to the conf file and it logs nothing. Set a flag and it sends the text to someplace else if you like or the console. It isn't as though logging takes much resources in the first place though.

              The reality is the binary logs are there so they can be journaled, indexed, tamper resistent, searchable and all the rest. Things that administrators want or should want. It doesn't even stop you extracting the journal as text. It does allow you to tell if somebody has deleted lines from your journal. It does allow you to efficiently search between two date ranges on a particular event.

              It's just an example of the knee jerk reactions that people hate on it without bothering to check if supports what they're trying to do.

              1. HieronymusBloggs

                Re: They missed a trick

                "You can turn off the storage in journald by adding Storage=none to the conf file and it logs nothing. Set a flag and it sends the text to someplace else if you like or the console. It isn't as though logging takes much resources in the first place though."

                I've had a system hang due to journald generating absurd amounts of data. It was fixable, but that's not the point. I don't want that data generated in the first place.

                "It's just an example of the knee jerk reactions that people hate on it without bothering to check if supports what they're trying to do."

                I don't hate systemd; I'm happy it exists for those who want to use it. I've made what I consider to be a sensible engineering decision to remove it from my own systems. Don't take it personally.

              2. Charles 9

                Re: They missed a trick

                "The reality is the binary logs are there so they can be journaled, indexed, tamper resistent, searchable and all the rest. Things that administrators want or should want. It doesn't even stop you extracting the journal as text. It does allow you to tell if somebody has deleted lines from your journal. It does allow you to efficiently search between two date ranges on a particular event."

                EVERYTHING you describe can be done with an all-text journal.

                The kernel log can be timestamp and is frequently already timestamped.

                If you really need indexing, you can generate an external file. I know video editors that use this technique for interframe videos.

                You don't need a binary format to create a blockchain as they tend to be format-agnostic.

                And logs are already searchable. Since most log searches are textual in nature, a simple linear search remains the most practical. A text log is easier to perform a textual linear search.

                Now tell me how you extract a text journal from a crashed drive when it was housing your only systemd-based system? As Spike Milligan put it, it's like trying to open a box with the crowbar you will find inside.

              3. Kiwi
                WTF?

                Re: They missed a trick

                It isn't as though logging takes much resources in the first place though.

                And here is one of the big problems with systemd's development. "We're not willing/to arrogant/to dumn to see how it can be problem to us so why should we bother fixing it?".

                I don't care if it uses few resources. If I don't want it turned on then it should be turned off. My lavalamp uses very few resources, but I am quite happy to hit the off switch when I don't want it on. Those "few resources" can add up to quite a bit when enough of it is going on. And the arrogance, ignorance and sheer stupidity that is a problem with systemd and it's is apparent in your post... "It's not our fault/problem, other people don't have a problem with it, so we won't bother with it".

                If people want binary logging then let them turn it on. If they don't want it then let them turn it off completely. MS can figure out ways that their extraneous services can be turned off completely, I'm sure that someone even as feeble-minded as a systemd supporter can at least work that much out.

                The reality is the binary logs are there so they can be journaled, indexed, tamper resistent, searchable and all the rest.

                Are you really that thick? Do you truly believe that these things have not been long fixed? Hang on, lets fire up an old VM and check... "grep -ir mika /var/log/*".. Yup, gets results back. Like it has done since grep was invented (or /var/log, depending on which came last). So we have searchable. Indexed... Is that worthwhile? If so, trivial to build an index file for it then. Strange, I know, but I think you could actually use a computer to index stuff. It might be a whole new concept but.... Journaled.. What problem does this solve? How many problems and how much unnecessary complexity does this create? Tamper-resistant may be nice, but looking at the attitude of that Potty thing at the head of systemd, I would not trust it to work. Charles 9 suggests a quite workable solution to this. How much intrusion detection is done just through logs anyway?

                Does systemd actually log anything that would really be relevant when someone is trying to break in or change stuff? Does it log anything over and above what would be logged by a normal system? Again, given the attitudes of the leadership, I doubt it would log anything relevant or helpful. More likely a hindrance. After all just writing a single byte to the log journal in the wrong place would be enough to trash it. Write a single byte to a 5 byte log entry and you can probably still make sense of it.

                So why introduce something that is unnecessarily complex and far more susceptible to file corruption? How does it help any one?

          3. Kiwi
            Boffin

            Re: They missed a trick

            capturing extra information,

            On a few occasions I've written programs/scripts that have a logging element to them. As the programmer, I decide what and how much is being logged. If I decide that my program will log stuff-all (if anything) then you have little or no chance of seeing this. How can the addition of binary logging change this? How can it change this in a way that cannot be done with other tools? And is the extra information it captures worthwhile information, or is it like the system error logs that "Microsoft Internet Services" so love to point elderly ladies to when they're trying to steal their money "fix the viruses on their computer internet"? Sometimes "extra information" can be a problem and can lead someone away from a solution.

            better indexing,

            And when the index gets corrupted at the time of a major failure? You know, when sequential logs are quite important? How would a binary index help anyway? Seriously. I've spent a lot of time with my head buried in piles of logs seeking answers to problems. Either they're there quickly and a glance can see what is going on (eg a web page not displaying, Apache's log shows that there's a permissions problem and I can go in and fix it) or they're something that can require a lot more reading. Being able to scroll down a file is much faster than having to load in a record each time you want to read a new line.

            Grep or search functions have been the only "index" I've needed when things go wrong. Well them and Google, but google is for finding answers to why I am seeing the content in the log, not for reading the log. And the content of the logs have always been plenty enough, often excessive. I can't recall a time when I've had insufficient logs to fix a problem (insufficient knowledge, sure, but not insufficient logs!). Caveat : I've not had to fix a lot of Linux stuff, which is a huge reason why I use it and love it.

  24. GrumpenKraut

    How about an interview with Devuan folks?

    I'd be very much interested to hear their thoughts!

  25. rtfazeberdee

    geez, the ignorance about systemd here is astounding

    no point in trying to rebut all lies and misunderstandings, too many of them. go do some research, might cure some of the ignorance demonstrated here of posters who get the info from other troll posters

    1. HieronymusBloggs

      Re: geez, the ignorance about systemd here is astounding

      "no point in trying to rebut all lies and misunderstandings"

      Please make the effort to do so, if they are indeed misunderstandings. There are some angry comments here about systemd, but I'd be very interested in your rebuttal of the more rational comments from those of us who have what we believe are sound technical objections to systemd's design.

      1. Charles 9

        Re: geez, the ignorance about systemd here is astounding

        "Please make the effort to do so, if they are indeed misunderstandings. There are some angry comments here about systemd, but I'd be very interested in your rebuttal of the more rational comments from those of us who have what we believe are sound technical objections to systemd's design."

        I think what they're saying is that you can't fix Stupid. And you can't stop people ignoring things they WANT to ignore.

    2. Bodge99

      Re: geez, the ignorance about systemd here is astounding

      Yep, some "lies and misunderstandings".. but many, many truths.

      Systemd. A solution to a non-existent problem.

      Please let it die before a major F.U. occurs.

    3. Anonymous Coward
      Anonymous Coward

      Re: geez, the ignorance about systemd here is astounding (rtfazeberdee)

      "no point in trying to rebut all lies and misunderstandings"

      "might cure some of the ignorance demonstrated here of posters who get the info from other troll posters"

      OK, so can we go direct to a reliable source then?

      E.g. https://github.com/systemd/systemd/issues/5644 takes a minute or two to read and doesn't require much technical knowledge at all.

      Is there much ignorance and misunderstanding apparent there in those few short posts? Where's it coming from?

      Me, I'm just a mildly interested bystander. Or I had been, till I saw that github thread. I suspect many others might react the same way.

      1. John Hughes

        Re: geez, the ignorance about systemd here is astounding (rtfazeberdee)

        E.g. https://github.com/systemd/systemd/issues/5644 takes a minute or two to read and doesn't require much technical knowledge at all.
        Yes? What's to understand? There was a bug. It's fixed.

        That some people came charging along to shout about the bug after it was fixed, forcing the locking of the bug report says more about the people who complain about systemd than the people who write it.

        1. HieronymusBloggs

          Re: geez, the ignorance about systemd here is astounding (rtfazeberdee)

          "some people came charging along to shout about the bug after it was fixed"

          True. The bug itself illustrates the developers' disdain for (and ignorance of) POSIX standards, however. That's enough on its own to make me reluctant to use systemd, regardless of other problems.

        2. Graham Dawson Silver badge

          Re: geez, the ignorance about systemd here is astounding (rtfazeberdee)

          First among them: poettering, to declare his ignorance.

    4. Kiwi
      WTF?

      Re: geez, the ignorance about systemd here is astounding

      no point in trying to rebut all lies and misunderstandings, too many of them. go do some research, might cure some of the ignorance demonstrated here

      Yep. Not like there's people here who live and breath Linux/Security etc, who have had to work at rebuilding systems after a failure, and work hard at figuring out what happened in the process (made so much easier with binary logs that are so easy to read with a crashed system! So much better than plain, and so very old, text!). Why, I doubt even one reader on El Reg would have a clue about what Linux is, let alone any of them ever having had experience in development of any sort!

      </sarc>

    5. DrXym

      Re: geez, the ignorance about systemd here is astounding

      Sadly nobody raging about systemd is interested answers.

      1. HieronymusBloggs

        Re: geez, the ignorance about systemd here is astounding

        "Sadly nobody raging about systemd is interested answers."

        Nice straw man. The few "raging" comments here are outnumbered by comments from those who have had genuine problems with systemd. Got any answers for them?

        1. nauved

          Re: geez, the ignorance about systemd here is astounding

          We knew this day was coming.

          Want to know where systemd is headed? Take a look at this:

          https://in.waw.pl/systemd-github-state/systemd-issues.svg

          That graph is linked from:

          https://www.freedesktop.org/wiki/Software/systemd/

          If the 'wontfix' bugs were included, the numbers would be even worse. systemd is sinking under its own weight. May it disappear to the bottom of the ocean of software failures where it belongs!!

        2. DrXym

          Re: geez, the ignorance about systemd here is astounding

          "Nice straw man. The few "raging" comments here are outnumbered by comments from those who have had genuine problems with systemd. Got any answers for them?"

          No, they're outnumbered by a lot of whining, a handful of anecdotes, a mass of misconceptions and a various statements that are false or distorted. If you have a specific problem, go look up your problem on superuser.com or a similar site because chances are it's already been answered more than adequately.

          I've already dealt with a share of issues here - text logging (just configure it), timesync client (a small SNTP client adequate for 95% of uses vs a full blown 20x larger NTP client/server) et al.

          It's funny how for all the people whining about systemd Red Hat and other major dists manage to use it without the world collapsing around them.

          1. HieronymusBloggs

            Re: geez, the ignorance about systemd here is astounding

            "No, they're outnumbered by a lot of whining, a handful of anecdotes..."

            One person's "anecdote" is another's practical experience.

            "If you have a specific problem, go look up your problem on superuser.com or a similar site..."

            Some on this forum might consider such advice patronising.

            "It's funny how for all the people whining about systemd Red Hat and other major dists manage to use it without the world collapsing around them."

            Not funny at all. Those people have made their own decisions about their own systems. I've made mine. I don't see why anyone would have a problem with that.

    6. Grumpy Rob

      Re: geez, the ignorance about systemd here is astounding

      Well, let's see what Linus thinks about the Red Hat developers working on systemd (back in 2014).

      http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01331.html

      Oh, sorry - Linus must be an ignorant troll too </sarc>

  26. Anonymous Coward
    Anonymous Coward

    Why not switch to FreeBSD?

    Systemd sucks and created tons of issues in practice.

    It is hooked into a lot of software piece in Linux.

    Why not switch to FreeBSD, which is simple & elegant.

    Yes, not that fashion, but enough for most of work.

    1. Charles 9

      Re: Why not switch to FreeBSD?

      Hardware support stinks, especially for end users.

      1. HieronymusBloggs

        Re: Why not switch to FreeBSD?

        "Hardware support stinks, especially for end users."

        Hardware support for desktop/laptop systems isn't as good as in Linux, but I don't see it being a problem for most servers.

        Judging by the number of commenters here who have problems with systemd (who I suspect represent the tip of quite a large iceberg) I expect *BSD use to increase substantially if it becomes impractical to avoid systemd on Linux. That should provide some incentive for better hardware support.

  27. wolfetone Silver badge

    I've used Debian 8 with SYSTEMD installed on it for a while now, and I'll be honest I don't see any sort of improvement. And I mean that. It's like finding a screw in a bag of spanners trying to do things with it.

    I held fire on looking at Devuan until I saw more progress with it. I'm glad it's coming along nicely, and it'll be on my laptop over the course of the May Bank Holiday.

    We should be given the choice about whether we want systemv (which just works) or systemd (which will soon have a word processor attached to it). Neither should be forced on us.

  28. Peter Christy

    But, of course, Slackware, one of the oldest and most stable distros out there, has never adopted systemd - nor does it show any inclination to.

    Sysvinit may not be the most elegant system, but it works, and is easy to understand.

    "If it ain't broke, don't "fix" it!!"

    1. wolfetone Silver badge

      Patrick Volkerding said in 2012 that Slackware may be forced to use Systemd in the future. Granted, we're 5 years on from that and 14.2 doesn't include it, but that doesn't mean it won't happen.

      If Systemd solved a problem and was the obvious better choice compared to Sysvinit then there'd be no issue with adoption. But Systemd doesn't solve any problems, not to any great extent or benefit.

  29. sawatts

    What problem systemd suppose to solve anyway?

    Recently ported a large legacy application suite from 32-bit Linux to 64-bit and a systemd distro.

    The systemd bit was the thing that caused the most headaches and pain.

    It was never clear what problem systemd was suppose to be solving. The only thing I've seen touted was that it streamlined boot times - when was this a problem? How often are servers rebooted? (Perhaps once a year?)

    In fact, it is far more common to *reboot* a system - and in this systemd seemed to be appallingly bad compared to the "old" way. Unravelling dependencies in reverse - either not much thought or effort has been put into this, or no adequate solution has been found. Rebooting went from under a minute to 15+ minutes or "infinity" (power button).

    I really wouldn't mind if systemd actually did something useful. But so far it seems like a big steaming pile of regression.

  30. MonsieurTM

    Congrats Devuan!

    I happen to use Gentoo/Linux and still use init, not systemd. There are other OS that allow the user to choose.

  31. Mr.Bill

    amazing

    "Gnuinos, Refracta, Exe GNU/Linux, Nelum-dev1, Star, heads, good-life-linux and Crowz."

    The sheer # of obscure distros. I'm wondering how many have essentially 0 regular users outside of the developer(s) themselves. They use the distro to develop the user-less distro. At best many probably have users who install, test, wipe and move on to the next in the distrowatch list, for fun.

  32. Jim-234

    Someone should do a Devuan Linux Mint Cinnamon clone.

    Now if we could just get somebody to basically make a Devuan based clone of Linux Mint Cinnamon that would be excellent.

    I wonder how much in the way of donations it would take to get the Mint guys interested in a version.

    (Because unfortunately with the 18.xx versions they went the way of the systemd darkside).

    1. wolfetone Silver badge

      Re: Someone should do a Devuan Linux Mint Cinnamon clone.

      "(Because unfortunately with the 18.xx versions they went the way of the systemd darkside)."

      Well if you choose to sleep with dogs you'll get fleas.

      1. jake Silver badge

        Re: Someone should do a Devuan Linux Mint Cinnamon clone.

        My dogs don't have fleas, thank you very much. Better living through chemistry.

        1. Jim-234

          Re: Sleeping with dogs will not give you fleas

          Yes, thanks to the wonders of modern veterinary medicine the dogs have been sleeping on the same bed as me for years & there has been no insect problems whatsoever.

          Tip: If you like having the dogs sleep on the bed with you, get a large square bed, so whatever angle you get pushed into, your head and feet are still on the bed.

          1. Kiwi

            Re: Sleeping with dogs will not give you fleas

            Tip: If you like having the dogs sleep on the bed with you, get a large square bed, so whatever angle you get pushed into, your head and feet are still on the bed.

            I'm not a dog person but a cat person. Tip : If you like having cats sleep on the bed don't worry about the bed size. A cat will always occupy all but a 2" strip of the bed, that strip being whichever spot is the most uncomfortable right at this time. The smallness of the cat or the largeness of the bed have no effect on this whatsoever.

    2. Kiwi

      Re: Someone should do a Devuan Linux Mint Cinnamon clone.

      (Because unfortunately with the 18.xx versions they went the way of the systemd darkside).

      Thanks for that. For some reason I thought that 17.x were using it as well and I was planning to migrate away from mint/mate, but now I see I don't yet need to do so. Just need to get rid of puke audio now, which is tied into mate-control-center through a couple of steps.

      Or maybe when I get a spare few days I'll gran Devuan and move over. There's a program or two I use often that it doesn't yet have in the repos, but I might be able to grab the .debs anyway and be done with it. So long as they don't list systemd or brokeaudio as dependencies.

  33. Stevie

    Bah!

    Did they do so while riding hoverboards?

  34. kneedragon

    test drive

    Goodness me! All these fractious and argumentative people, abusing the main-stream for no other reason than it is the main-stream. Heaven forbid that one should have to consider the possibility that Mark Shuttleworth was right....

    ... NAHH!!!

    My Devuan-1.0 net-install is running (just like a bought one) as I type wit and wisdom here... or demonstrate my ignorance, both work.... let's see how well Devuan works.

  35. eddiejames

    Devuan is a fine operating system.. for me.. It runs great on an old Dell 1521 inspiron laptop. b43 broadcom wireless works fine right out of the box. I wish the developers the best.

    1. Charles 9

      I own a 1521. That particular model is pretty Linux-friendly (I easily ran Mint on it).

      OTOH, a 3521 might be trickier, given it was built for Windows 8+ and has Secure Boot, meaning it won't boot external media right away.

      1. eddiejames

        We don't use this box often. It's old, beatup, has no keys, (we use a usb keyboard), and has only 1 gig ram. I still like it. I usually use my old asus board 8 gig ram and Phenom II processor. The 1521 is sort of weird. I guess it was built for windows vista but win 7 runs on it. I think all I needed was the vista video driver and maybe the dell wireless package to run 7 comfortably. winxp was a nightmare. don't remember if I ever got all the drivers for xp.

        This box has run a lot of nix's. several *BSD's. I think slackware-current x86 and x86_64 kernel wants too much of it though. The older slacks run fine. devuan 3.16.0-4-686-pae runs smoothly. Could do without the pae as it has so little ram.

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

Other stories you might like