back to article systemd row ends with Debian getting forked

The vivid difference of opinion over Debian's future direction has ended with a new fork of the Linux distribution. The dispute centred on plans to replace the sysvinit init system management toolkit with systemd, a similar but less-Linux-specific set of tools. The “No” camp complainedsystemd is not well-aligned with Unix …

  1. Destroy All Monsters Silver badge
    Facepalm

    Off to a bad start

    > Init freedom.

    Oh my fscking $DEITY

    Seriously why does the choice have to be between init's barely-working duck tape and systemd's skynet-tier complexity? Just get a Prolog interpreter in there for flexibility and bog-simple sequencing based on short scripts and be done with it.

    1. ckm5

      Re: Off to a bad start

      Pretty soon we're going to wind up with Sendmail all over again. I can just see the day when a macro language is needed just to write systemd scripts*.

      * m4 in case you are new to Unix...

      1. Warm Braw Silver badge

        Re: Off to a bad start

        >we're going to wind up with Sendmail

        There was a time when there was a lot of vociferous opposition to the various sendmail alternatives, in particular qmail ("because djb") and postfix ("because IBM").

        I suspect that putting an m4 preprocessor into systemd might be the one thing that makes the "greybeards" look kindly upon it.

        1. Jim 59

          Re: Off to a bad start

          The “Veteran Unix Admin collective” know what they are talking about IMO. They know bad design when they see it, and have spent decades keeping it well away from Unix. If you want to know what happens when bad design permeates an OS, see Windows. If bad design gets into the core of the OS, forget it.

          Systemd is determined to penetrate every part of the OS, for no good reason. If it then wobbles, or the code starts to smell, or it gets too big, or bloats into millions of lines (all of which may already have happened), then any unix containing it will undergo sudden organ failure from which recovery may be impossible. It is therefore reassuring that at least one big distro will not carry that risk.

          Unix does not do things for no reason. Why do Gnome developers want it to? They have poured their lives into rotating icons and bringing mobile-phone ephemera to the desktop, and they haven't listened to anybody for years and years. I respect their coding talent, but I don't want that mind set at the heart of Linux.

          Leave the OS to the guys who are good at writing operating systems, and leave Gnome development to the Gnome guys.

          1. John 156

            Re: Off to a bad start

            I respect the judgment of guys like Jeff Waugh who brought Gnome 3 to an unsuspecting world and who said, "it has to solve a real problem. 'Doesn’t include systemd' is not a real problem.” when he means, ""Does include systemd" is not a real problem".

            1. Lee D

              Re: Off to a bad start

              As with all things computer-wise, what annoys me is not the features that people want, it's the features people don't want.

              Fast bootup is nice. Does that REQUIRE, absolutely REQUIRE binary logs? Can we get an option to have it not do binary logs so we can see how much slower it is? Isn't that nice to the users to have, say, a settings file somewhere where they can override the default to put plain-text logs if that is WHAT THEY WANT?

              What, inherently, about systemd demands binary logs must be a prerequisite?

              And then you start extending down to the other features, with similar problems. And, at the bottom of it, okay say we do want INI file initialisations like that. Why can't we do that with SysVInit style scripts? What, precisely, demands that we have to use systemd's "all or nothing" approach? What parts of systemd would people want to use if there was just a scripted version of the same thing? And then if we compare that against systemd in terms of speed, etc. how much better is it?

              I'm all for progress. But not at the expense of arguments and usability. And, worst of all, when it might be perfectly feasible to do this stuff using "the old way" too, just as well.

              The arguments I see for systemd focus on the "new features", and seem to imply we have to suffer everything it does for those features. Why? That's the bit I don't see explained. Binary logs? Why? Why not text? Performance, you say? Okay, put in normal logs and let's see what the difference is. And how does that tie in with the syslogd shops where everything log-wise is centralised?

              I've yet to see answers like this, and I refuse to do an all-or-nothing upgrade for features that I look at and think "Okay, but to me personally, they are a bit meh."

              1. John Sanders
                Linux

                Re: Off to a bad start

                You do realize that binary logs are there because for some systems they are a requirement?

                And do you realize that they are optional? Nothing stops you from telling the journal daemon to store the logs in disk or RAM and optionally forward them to the console, the kernel log buffer, or to a classic BSD syslog daemon, then all you need to do is to create a service unit like:

                [Unit]

                Description=System Logging Service

                Requires=syslog.socket

                [Service]

                ExecStart=/usr/sbin/syslog-ng -n

                StandardOutput=null

                [Install]

                Alias=syslog.service

                WantedBy=multi-user.target

                There you go.

                And bear in mind that I'm quite critic with some aspects of systemd, but most binary log arguments floating around online are just bollocks.

                1. BitDr

                  Re: Off to a bad start

                  @ John Sanders

                  I think the question being asked is "why". Why are binary logs a requirement? What's the driver? Logs are for people to read and understand so they can work with the data. Binary is not user friendly, text is. If the need is for machine readable logs then use XML (and no sneaking in binary objects while we're not looking!).

                  Just because something CAN be done doesn't mean that it SHOULD be done. My instinct tells me to run in the opposite direction of any distro using systemd, the more I learn about it the more I see it as a single point of failure, and a huge mass of spaghetti. The siren call of BSD is getting stronger by the day.

                  1. Anonymous Coward
                    Anonymous Coward

                    BSD? No need for that yet fella...

                    "The siren call of BSD is getting stronger by the day."

                    Just go Slackware. I don't think Patrick will be switching to systemd anytime this decade.

                  2. rtfazeberdee

                    Re: Off to a bad start

                    Before you run off another distro find out about the logging instead of listening to ignorant crap posted in these forums. ALL LOGS CAN BE CONFIGURED IN SYSTEMD TO BE SENT TO RSYSLOG IN TEXT as per normal.

                    i really can't believe this crap about binary logging is still being propagated

                2. John Hughes

                  Re: Off to a bad start

                  hen all you need to do is to create a service unit like:...

                  And that is the default configuration on Debian.

                3. Anonymous Coward
                  Anonymous Coward

                  Re: Off to a bad start

                  -> You do realize that binary logs are there because for some systems they are a requirement?

                  Ok. Good to know.

                  -> And do you realize that they are optional?

                  Optional?!? You intimated they were a requirement. Now you tell me they are optional?!? HTF can they be a 'requirement' if they are optional?

                  No wonder you Linux/Unix neck-beards are kept locked away from the humans.

                  1. Kiwi

                    Re: Off to a bad start @AC

                    HTF can they be a 'requirement' if they are optional?

                    Reading for Comprehension. A skill I suggest you look up..

                    -> You do realize that binary logs are there because for some systems they are a requirement?

                    "If you are using this system for XZY, you must set your logs to be binary. If you don't require binary logs, you can set them to...."

                    Wearing an appropriate space suit is a requirement for surviving a "space-walk". I assume you're not currently on a space-walk, so probably wearing a space-suit is optional for you right now.

                4. Jim 59

                  Re: Off to a bad start

                  do you realize that they are optional? Nothing stops you from telling the journal daemon to store the logs in disk or RAM...

                  Optional or otherwise. the intention of the systemd project is to replace syslog, otherwise why would they have written the code to enable that ?

                  binary logs are there because for some systems they are a requirement?

                  I have never heard of binary format being a requirement for logs or any other data. That doesn't make sense.

              2. rtfazeberdee

                Re: Off to a bad start

                "Does that REQUIRE, absolutely REQUIRE binary logs?" - no, it doesn't but systemd starts logging so much earlier in the process that rsyslog can and long after rsyslog exits at shutdown. THE logging can be configured to send the logs in text to rsyslog as per normal so binary is a non-issue. Its a stupid argument by people who have not looked into the issue. Systemd makes boot-up faster by allowing parallel startup of services and its faster to do than starting by scripts. Most startup scripts are generic so doing it via systemd is sensible as systemd still allows you to run scripts as per normal - its all down to configuration.

                You are making a lot of decisions/assumptions about something you have not even investigated and relying on misinformed posters

          2. me 1

            Re: Off to a bad start

            > The “Veteran Unix Admin collective” know what they are talking about IMO.

            Presumably they know that Linux is not Unix then, and that it was never intended to be, and has non-Unix-like features ?

            Presumably they also know though, that init and systemd are in user space and not the kernel, so that would be the "GNU" bit of Debian GNU/Linux ? Did they ever read up on what the "N" in GNU stands for ?

            And I guess that they also know about SMF and launchd, which systemd is more or less a clone of, and the Unix systems on which they run ?

            Or, maybe they don't know what they are talking about...

            [PS: worth noting the comment on the actual Unix website about Windows NT, i.e. should it pass the POSIX spec tests it cuold in fact be called Unix... http://www.unix.org/what_is_unix/flavors_of_unix.html ]

            1. sisk

              Re: Off to a bad start

              Presumably they know that Linux is not Unix then, and that it was never intended to be, and has non-Unix-like features ?

              You're half right. Linux is not Unix and was never intended to be. What it is and was always intended to be is a kernel for GNU, which itself was always meant to be a libre clone of Unix.

              Presumably they also know though, that init and systemd are in user space and not the kernel, so that would be the "GNU" bit of Debian GNU/Linux ? Did they ever read up on what the "N" in GNU stands for ?

              Again, "not Unix" only because Unix was, at the time, as proprietary (maybe more so) as Windows is today. Remember the whole thing was the brainchild of Stallman, a man who's convinced that all the evils of the IT world stem from proprietary and closed software.

              And I guess that they also know about SMF and launchd, which systemd is more or less a clone of, and the Unix systems on which they run ?

              Black boxes. Pretty much the thing GNU and Linux were written to avoid because they cause problems that are hard to troubleshoot.

              Or, maybe they don't know what they are talking about...

              I find it more likely that you just don't understand where they're coming from.

          3. RegGuy1 Silver badge

            They know bad design when they see it

            You mean like replacing BIOS with UEFI?

            WTF?

            (Oh I see -- so M$ can fuck off Linux. Nob-eds.)

        2. Uncle Timbo

          Re: Off to a bad start

          And eventually we had exim - which was written by someone with a clue. Almost unlimited flexibility, reliability and a more or less readable config.

      2. John Hughes

        Re: Off to a bad start

        The whole point of systemd is that it doesn't use init scripts.

        Would you need m4 to write:

        [Unit]

        Description=System Logging Service

        Requires=syslog.socket

        Documentation=man:rsyslogd(8)

        Documentation=http://www.rsyslog.com/doc/

        [Service]

        Type=notify

        ExecStart=/usr/sbin/rsyslogd -n

        StandardOutput=null

        Restart=on-failure

        [Install]

        WantedBy=multi-user.target

        Alias=syslog.service

        (Replacing a 137 line shell script that calls wierd shit like "start-stop-daemon")

        1. Tom 38 Silver badge

          Re: Off to a bad start

          The whole point of systemd is that it doesn't use init scripts.

          No it isn't, that is one of the side effects, and that argument is one of the disingenuous arguments for introducing systemd.

          The purpose is to borg desktop services in a way that suits desktops, but only a tiny proportion of linux machines are desktops.

          (Replacing a 137 line shell script that calls wierd shit like "start-stop-daemon")

          I'd prefer the shell script, because then there is less indirection between "I call this script" and what that script does.

          PS: It's only weird if you don't know what it is doing. I find that ini file pretty fucking weird, because I have no clue what "running" that ini file does, or even what program "runs" it. In order to work that out I'd have to read and understand a program that does things based upon the contents of an ini file.

          To work out what a shell script does, you need only to read it, or simply run it with "-x".

          1. rtfazeberdee

            Re: Off to a bad start

            If you don't understand shell scripting syntax, you won't have a clue what its doing. Its the same with systemd, if you don't learn about how it works, you won't know how it works.

            1. Anonymous Coward
              Anonymous Coward

              Re: Off to a bad start

              > If you don't understand shell scripting syntax, you won't have a clue what its doing.

              True enough... however once leaned that knowledge can be re-used in understanding the zillions of scripts outside of init systems, and also applied to BSD, AIX, or even non-Unix OSes that have sh-derived shells.

            2. Doctor Syntax Silver badge

              Re: Off to a bad start

              If you don't understand shell scripting you have no business running a Unix type server.

            3. Anonymous Coward
              Anonymous Coward

              Re: Off to a bad start

              That is a stupid comment - if you can't speak klingon, then you will not understand what a klingon says to you.

              The thing here is ANY *nix admin (or even home user running servers) know b/k/ash scripting - it's common knowledge on part of the UNIX philosophy from years ago - why should you have to learn a new language just because some people force it on you?

              1. watkin5

                Re: Off to a bad start

                That makes no sense what so ever. What have you got against Klingons?

          2. Anonymous Coward
            Anonymous Coward

            Re: Off to a bad start

            The purpose is to borg desktop services in a way that suits desktops, but only a tiny proportion of linux machines are desktops.

            Maybe that is the reason that there are only a tiny number of Linux desktops!

            Regarding your PS. the INI files are the equivalent of the setup instructions of your shell scripts and are run by the programs that own them - at least in OS/2 land, not sure about windows.

          3. John Hughes

            Re: Off to a bad start

            The purpose is to borg desktop services in a way that suits desktops, but only a tiny proportion of linux machines are desktops.

            People keep saying this, not noticing that systemd is mostly written by Red Hat who really want it for servers not desktops.

    2. ElReg!comments!Pierre

      Re: Init freedom

      Hey, steady there. "Init freedom" means "freedom to use whatever init mechanism you want", not "freedom to use sysvinit" (otherwise they would have said "sysvinit freedom", surely).

      The problem with systemd is that it introduce a system where GUI applications force the init system, and a huge bloated one that includes everything but the kitchen sink (yet; kitchensinkd release expected in early 2015).

      For servers it is simply not an option.

      Now add to that the stellar reliability (erm) and exemplary openness of systemd (binary logs... of course, why not!) and I'm entirely behind the greybeards on this one. I tried systemd on a laptop of mine; a desktop-type machine, typical systemd playground. Took me several hours of wading through the system to understand why the trackpad would sometimes work and sometimes not; why the WiFi circuitry would sometimes work and sometimes not; and why external drives would sometimes mount themselves upon insertion (sometimes as root, with the corresponding read/write restrictions), sometimes not, and would sometimes be unmoutable only by root (again, sometimes not) and then of course re-mountable only by root with the corresponding read/write restrictions.

      Uninstalled as much of systemd as I could, back to sysvinit and everything works as expected again.

      I think the "let's see how it works" phase is done and the answer is "not suitably".

      1. Andrew van der Stock

        Re: Init freedom

        I think you might want to spend a bit of time looking at what systemd *does*, and *how it does that* before saying these things.

        For a start, it's a collection of modular things that do their own little thing, but require cooperation in modern systems. For just one example, power management are absolutely critical for servers, particularly virtualized processes.

        Systemd enforces a security model, again critical for servers, that supplements (or outright replaces) the hopelessly complicated SELinux with something that is even simpler to get going than chroot jails on *BSD. As the ultimate parent process, this is the best place to do it, particularly when you take into account its lightweight containerization capabilities.

        Systemd's modular security architecture provides separation of duties, so a compromise of one module doesn't imply a compromise of the entire system. It's early days yet, so I bet there's a few sandbox bugs to work out, but this sort of sandboxing is absolutely critical for Internet facing servers.

        Systemd has lightweight containerization, which is critical to servers, particularly cloud based servers. You can boot a new environment with a single command without a lot of setup. Like any init process, it knows how to start, stop, suspend, or provide services to it.

        Systemd has a completely orthagonal administration model, which eliminates guesswork. This is critical for servers and reduces the chances of admins stuffing it up.

        Systemd boots in a fraction of the time taken by any init. This is critical for servers where taking a 4 minute reboot holiday basically means losing any chance of 99.99% uptime that year.

        Please, please, please, don't let facts get in the way of your emotions. It's just new, which means you should learn about it. It's actually quite good. I was sceptical at first, but now, I can't imagine returning to the old way.

        1. Lee D

          Re: Init freedom

          The containerisation is provided by kernel facilities, not systemd.

          The security is provided by kernel facilities, not systemd. Systemd is merely utilising the kernel services.

          I'm not sure I *want* anything replacing SELinux so quickly, so without question, so without review, so completely and so controversially. This is precisely the problem - to do X, we have to replace your security model. WOOP WOOP!

          And the boot time argument? Anywhere needing 99.99% uptime is not worried about a 4 minute reboot. I guarantee you they have a bank of redundant machines instead and each one does the full server check on bootup that can take minutes in the UEFI/BIOS anyway. That's not an argument. And if it is, it's not one that stands up to scrutiny for why you need to replace the entire system security model.

          Facts are important here. But saying "it does X" does not justify doing any amount of Y or Z you like in order to do so.

          1. Tim Bates

            Re: Init freedom

            "And the boot time argument? Anywhere needing 99.99% uptime is not worried about a 4 minute reboot."

            And most of the reboot time (in my experience) is the BIOS and various controllers doing their random checks and warm-up routines.

        2. ElReg!comments!Pierre

          Re: Init freedom @Andrew van der Stock

          A lot of what you describe is done by the kernel, not systemd at all.

          reduces the chances of admins stuffing it up.

          It also reduces the chances of the admins fixing it when it fails (because it does fails, as does every system -rather more often, too, in my limited experience).

          Systemd's modular security architecture provides separation of duties, so a compromise of one module doesn't imply a compromise of the entire system. It's early days yet, so I bet there's a few sandbox bugs to work out,

          That "sandoboxing", as you call it, often causes more problems than it solves. Process-based permissions (as opposed to user- or group-based like in any san system) might have seemed like a good idea at the time. In the real world it's a nightmare as soon as you get out of the precise sequence of actions that you had planned for the system to be able to perform. In my -again, limited- experience a process creating a resource (i.e. mounting a drive, creating a file, whatever else) becomes the exclusive owner of said resource which is then unavailable to other processes. I understand why you would think this is a good idea for security, but now imagine the "creator" process crashes or otherwise stops at a point in the workflow that you hadn't envisionned. Then you're left with a screw-up that can't be fixed without extensive manual intervention as root -provided you can even identify what went, I was going to type "wrong" but not necessarily, just "unexpected".

          So, what we have is a system that messes up big time in case something happens that the admin had not planned. Sure, what could possibly go wrong with that? Let's put it on every production system we can find!

          Before you answer anything, be informed that the aforementionned scenario happened to me a good dozen times (that's only the ones I could identify with 100% certainty; some of the numerous glitches and fails I encountered may have been caused by such a scenario too). And that's in my limited experience.

          Now I could be very mistaken, that's always a possibility. But I much prefer to be wrong with working systems than right but left with rackfulls of very expensive bricks.

        3. Kiwi

          Re: Init freedom @Andrew van der Stock

          Systemd has a completely orthagonal administration model, which eliminates guesswork. This is critical for servers and reduces the chances of admins stuffing it up.

          When something does get screwed up (or I want to change something or just check or whatever), I often have to log in via SSH because I don't have any other real option. Often I am on connections where speed is not an option either. So I need basic text, as little as possible. Can SystemD be completely managed from a text-only interface, including all logs, all output (for trouble-shooting or otherwise) and all other input/output? if yes, well, it has some bits I might be interested in. If no, then please keep it off my systems. I won't willingly install it, I hope no one decides it should come with an update somewhere down the line.

          Systemd boots in a fraction of the time taken by any init. This is critical for servers where taking a 4 minute reboot holiday basically means losing any chance of 99.99% uptime that year.

          I don't gaurantee uptime, I don't need to. My web server also takes around 2 mintues to re-boot should I need to (last time was a few days ago, big upgrade from Squeeze to Wheezy). Email server (last rebooted a few weeks back) is 5-6 minutes - it's on much older hardware that will soon-ish be replaced. Previous uptime for each server was in excess of 260 days. That's probably pretty close to 99.99% there and then.

          If I did gaurantee up time I'd have a 2nd server (actually the email server carries the same data and config as the web server, so I could just change the DNS entries before rebooting the web server, wait a few hours, reboot, then change back - or run them from the same location in which case things get even easier! :) (don't ask, setup is mildly unusual :) ). Anyway, reboot times would not often affect uptime as most places would run a redundant server and switch from one to the other as needed, right?

          TL;DR : A couple of my servers take a few minutes to boot. Which probably will only happen once per year. If I was really interested in 99.99+% uptime I'd run redundant machines to help.

        4. Jeff Green

          Re: Init freedom

          I would be mortified if anyone suggested 99.99% up time for my systems, that's 5 minutes downtime a year, if I wanted downtime I could run Windows. My linux webservers measure their uptime in years, they only get rebooted after a system is put in place to cover them. I do run (for my other employer) systems that are rebooted as a way to reread configurations, horrible but I do not have access to fix the coding, since they have to be rebooted and since they are required to never have more than 1 minute's gap in uptime we fixed the init to take well under 30 seconds.

          I do not know if systemd is any good, but for my systems it is fixing a problem I haven't got and may well be introducing others that I do not want. All I ever wanted was an option to stick with a system that works, I never use Gnome so I don't care if that requires it, but then on most of my systems I don't use any sort of GUI so that's not surprising. On a unix box, any unix-like box, you only run what you need, forcing a larger system on a server is just plain bad.

  2. Number6

    What is systemd

    I've seen plenty of arguments about whether it's a bad thing or not. Is there a good article on the web that details what it is and how it's supposed to work? (And how I'm supposed to hack it if I want to?)

    1. Anonymous Coward
      Anonymous Coward

      Re: What is systemd

      It's yet another hierarchical daemon that will grow beyond the point of manageable. See ckm5's post above.

      The problem with systemd's camp is that it's not needed. A lot of the Gnome developer community seems to sit around and create solutions to problems that don't exist. Why? Just to become a popular self created hero it seems.

      My argument isn't that it's a bad thing, it is just that it isn't needed.

      http://en.wikipedia.org/wiki/Systemd

      "Poettering complained that the "Open source community is full of assholes, and I probably more than most others am one of their most favourite targets." Poettering went on to blame Linus Torvalds and other kernel developers for the state of the community"

      See, it's all about being the HERO!

      People apparently seem confident that the new fork will die, I'm not confident in that at all. I expect to see the Devuan's name in upcoming enterprise situations, not Debian's. Of course not that it would matter much in the enterprise, systemd has never been there and never will.

      Systemd: The automatic transmission for sport cars.

      1. MacroRodent

        enterprise systemd

        > Of course not that it would matter much in the enterprise, systemd has never been there and never will.

        systemd is in RHEL7, so it will be in widespread enterprise use pretty soon.

        I'm personally still suspending judgement on systemd for lack of experience with, but that is likely to change, as I am seeing more and more of it at work, as Linux systems get upgraded.

        1. Mahou Saru

          Re: enterprise systemd

          Depends on your definition of pretty soon. Even if it was a minor version of 6, it wouldn't go our systems until it was thoroughly tested (especially by bleeding edgers). With such major changes in 7 and with 6 being supported for such a while, I don't see any reason to rush to it, well unless my goal was to make work for myself....

          1. MacroRodent

            Re: enterprise systemd

            >Depends on your definition of pretty soon.

            Well, two or three years... The server guys here are just starting to install RHEL6 instead of RHEL5, and we have just barely got rid of RHEL4...

            1. Matt Bryant Silver badge
              Go

              Re: MacroRodent Re: enterprise systemd

              ".....we have just barely got rid of RHEL4...." Just put our first RHEL7 production systems online last month, no children have been eaten yet! Faster boot - meh, not really a bonus for us. Otherwise it seems pretty rock-solid, just like 6.

              On the matter of the Debian Hurd and BSD kernels, people seem to have missed that Red Hat have zero business interest in either, so why should they hold back development of RHEL to please two fringe groups? If either Debian Hurd or BSD prove of value then maybe RH will reconsider, but (IMHO) that doesn't seem likely.

        2. MustyMusgrave
          Alert

          Re: enterprise systemd

          > systemd is in RHEL7, so it will be in widespread enterprise use pretty soon.

          Yes, because we're all deeply loving what RedHat does.. It's worth noting that RedHat is on it's own path to become something that is not Linux and those SELinux enhancements going everywhere dont exactly give you security out of the box unless you enable it! They're making something simple something complicated, because that's the RHEL way!

          They're not just taking one Daemon, they're trying to include them all, so in a nut-shell when one of those daemons has a problem, then the whole of systemd has a problem!

          1. Vic

            Re: enterprise systemd

            Yes, because we're all deeply loving what RedHat does

            I've long been a RHEL fan - but I suspect RHEL6 might be my last one.

            Vic.

        3. Matt Bryant Silver badge
          Go

          Re: MacroRodent Re: enterprise systemd

          ".....systemd is in RHEL7...." Which begs the question - if systemd is so 'bad', how come Red Hat, the company simply better at making money out of commercialising Linux than anyone else, has chosen to go with it? I have had some interaction with Red Hat's development team, they are not prone to blind faith nor strike me as 'wannabes' pushing a Gnome crusade. They tend to be quite realistic and methodical, and since I am much more likely to use RHEL in business server use than any Debian flavour I would have to say RH's support is tending to sway me more to accepting systemd than falling for the "IT WILL EAT OUR CHILDREN" shrieking of the anti-systemd mob.

      2. hplasm
        FAIL

        Re: What is systemd

        "Poettering complained that the "Open source community is full of assholes, and I probably more than most others am one.""

        There. Fixed.

    2. thames

      Re: What is systemd

      Depending on who you talk to, Systemd is either the spawn of Satan, or it's the salvation of software packagers. More specifically, it's a type of "init system".

      During boot up, an init system (there are several different ones used in various LInux distros) gets called to start up everything else and to shut them back down again. Debian currently uses a System V type init, which is based around shell scripts. It goes way back in Unix history, although the implementation details vary. The name comes from System V Unix, which was an attempted unification of AT&T Unix and BSD. Ubuntu uses something called Upstart (Red Hat used to use it as well, until their latest release), and Gentoo has their own called OpenRC.

      Systemd is basically a copy of the Apple OS/X init system, which in turn is a copy of the Sun init system. I'm using the term "copy" rather loosely, as init systems have to be closely tailored to the actual OS, and Systemd naturally has lots of Linux specific bits to it. However, the basic way of doing things is similar with regards to when and how things are started up in all three.

      Opposition to Systemd tends to revolve around two things, and it should be noted that not everyone who dislikes it, dislikes it for the same reasons.

      Some people dislike it simply because it's not System V. These are the "grey beards" that Systemd proponents like to talk about. Other people dislike it because they think it's a good concept which has been badly implemented by idiots who ignore valid criticism. The latter are the people whom the Systemd proponents don't like to admit exist, and they may in fact form the majority of the opposition.

      With Debian, there is an additional complication. There are, or rather were, two versions of the Debian OS in development which were not based on Linux. One used a BSD kernel, and the other used a Hurd kernel (a micro-kernel). Systemd kills both of these as Debian projects because the Systemd developers insist on inserting their tentacles into nearly everything, and won't accept patches which will make Systemd cross-platform (e.g, make it compatible with a BSD kernel). Systemd is to be Linux only, Gnome and KDE are to be Systemd only, and anything that Systemd touches will no longer work on BSD (or Hurd) without forking them. This is also going to cause major pain for BSD in general in the future by the way.

      The main reason why Debian is changing to Systemd has nothing to do with the relative merits (or demerits) of it versus System V. There is no commercial Debian corporation. Debian developers are generally people who do things with software (e.g. consultants, system administrators, etc.), and cooperate to produce an OS which isn't under the thumb of a particular commercial company. Each Debian developer is responsible for maintaining a specific package or set of packages. They are wildly successful in that Debian is pretty widely used in the server world, and the majority of other Linux distros (e.g. Ubuntu, Mint, as well as many others) are derivatives of it (a derivative being different from a fork in that it keeps going back to the original well for each release).

      As such, Debian developers mainly just repackage, test, and fix minor issues with third party software rather than developing anything new themselves. The Systemd developers (basically, Red Hat) have managed to insert hard dependencies on Systemd into other critical Linux components (e.g. the Gnome GUI desktop, also controlled by Red Hat), meaning that not using Systemd would require effort which the Debian developers are not interested in doing, and don't have the resources for anyway. The discussion which Debian developers have had can basically be summed up as "keeping System V sounds nice, but who's going to do the work for it - because I don't have the time". Canonical (Ubuntu) have already said that they'll just go along with whatever Debian decides to do, so Ubuntu will switch from Upstart to Systemd, although that may not happen for several years.

      The Devuan developers are going to have to address the resource issues as noted above. Good luck to them though if they succeed and give some people what they want. There are already loads of independent Debian derivatives (which I think Devuan is more like, rather than a true "fork"), which focus on things which aren't addressed by the main release, so one more isn't a problem.

      1. ckm5

        Re: What is systemd

        Other people dislike it because they think it's a good concept which has been badly implemented by idiots who ignore valid criticism.

        That is the core of the problem - systemd et. al. is run by a bunch of arrogant pricks who willfully break others code then insult people who call them out on it.

        Open-source is all about playing nice with others. Just because you've created something which is technically superior does not give you the right to piss on others - and leveraging applications where you have a monopoly (aka network-manager) to push your technology stack above all others is just bad karama all around.

        IF the leaders of GNOME & systemd were more community minded, this would have never happened. Unfortunately, it's hard to see how this will resolve itself, it would require adult behavior & conciliation, both of which are sadly lacking.

        1. Eddy Ito

          Re: What is systemd

          It seems to me that another solution is to derive/fork systemd and break down the dependency into smaller pieces that can be worked around more easily.

          1. Not That Andrew

            @ Eddy Ito Re: What is systemd

            >It seems to me that another solution is to derive/fork systemd and break down the dependency into smaller

            >pieces that can be worked around more easily.

            That's already happening with uselessd, which is basically systemd stripped down to an init system and eudev which is udev unborged from systemd (did anyone mention how it had gotten borged).

          2. Mr Spuratic

            Re: What is systemd

            This is under active development: http://uselessd.darknedgy.net/

            There are no doubt other efforts too.

        2. Trevor_Pott Gold badge

          Re: What is systemd

          "IF the leaders of GNOME & systemd were more community minded, this would have never happened. Unfortunately, it's hard to see how this will resolve itself, it would require adult behavior & conciliation, both of which are sadly lacking."

          If the leaders of Gnome and systemd were community minded we would have ended up with a rational compromise: something that was a proper (and badly needed) replacement for SystemVinit, but didn't have binary logs, a registry, tentacle dependencies and wasn't trying to become a userland kernel.

          It would have been a Good Thing, and we could all move forward happy, and in harmony. Unfortunately, Poettering is an ass and he leads a small nation of other asses on their grand quest to "pacify" the fuzzy wuzzies.

          1. John Hughes

            Re: What is systemd

            If the leaders of Gnome and systemd were community minded we would have ended up with a rational compromise: something that was a proper (and badly needed) replacement for SystemVinit, but didn't have binary logs, a registry, tentacle dependencies and wasn't trying to become a userland kernel.

            Where is systemd's registry?

            Answer: it doesn't have one.

            (Gnome does, but that is nothing to do with systemd, and has existed for years).

      2. mathew42

        Re: What is systemd

        > Systemd kills both of these as Debian projects because the Systemd developers insist on inserting their tentacles into nearly everything, and won't accept patches which will make Systemd cross-platform (e.g, make it compatible with a BSD kernel).

        For this reason alone, the pitchforks should be raised in anger. Cross platform software is often of a higher quality because corner cases are found.

      3. John Hughes

        Re: What is systemd

        With Debian, there is an additional complication. There are, or rather were, two versions of the Debian OS in development which were not based on Linux. One used a BSD kernel, and the other used a Hurd kernel (a micro-kernel). Systemd kills both of these as Debian projects because the Systemd developers insist on inserting their tentacles into nearly everything,

        Two minor errors here.

        1. systemd is an optional part of Debian, (it's the default for the linux kernel versions, but they work without it). Debian/kBSD and Debian/Hurd have no problem not using systemd.

        2. The systemd developpers have "inserted their tentacles" into nothing. The Gnome developers have decided to use systemd-logind as well as consolekit, as consolekit developpment is dead, but the Debian (& Ubuntu) developpers have written systemd-shim which allows systemd-logind to be used without systemd as pid 1.

        If the "devuan" people don't want to use systemd, but do want to use Gnome then they should have either worked on systemd-shim or taken up the maintenance of consolekit.

        But since the "devuan" people actually consists of Denis Roio (also known as Jaromil) I doubt anything is actually going to come out of it.

        1. ElReg!comments!Pierre

          Re: What is systemd

          1. systemd is an optional part of Debian, (it's the default for the linux kernel versions, but they work without it). Debian/kBSD and Debian/Hurd have no problem not using systemd.

          For now, and only because sysvinit is still the default init in stable. As soon as systemd becomes the default init (next release), things will start getting interesting depending on the policy on init system, i. e. do maintainers have to support several inits, can a package NOT support the default init, etc...

          No matter what the policy is, it means a huge increase in porting difficulty, which means that packages just won't be ported to hurd or KFeeBSD; that's pretty much the end of the projects.

          2. The systemd developpers have "inserted their tentacles" into nothing.

          I beg your pardon? They're steamrolling essential parts of the system (and even parts of userland) into their monster of a system. See http://www.muylinux.com/wp-content/uploads/2014/08/funny-systemd.gif for a humorous representation of how they "inserted their tentacles into nothing".

          1. Doctor Syntax Silver badge

            Re: What is systemd

            "things will start getting interesting depending on the policy on init system,"

            AIUI after the various votes the policy is now that its up to Debian package maintainers whether they support multiple inits. The likely consequence is that if more upstream package maintainers assume the presence of systemd and friends the Debian packagers are just not going to be able to keep up working round the dependencies. As has been said, there's no DebianCorp to finance such working around. And I fear Devuan and the alternative tack, making the current Debian an LTS release, will have the same problem.

            Red Hat (with one exception, see below) have already captured the .rpm side of Linux. With Debian, Ubuntu & derivatives also captured they had the whole server business condemned to run systemd.

            AFAIK Slackware is the major remaining holdout - Gentoo seems to wish to be agnostic. There is now little incentive for upstream devs to assume systemd etc will not be there. So running a traditional init as an alternative becomes less possible as applications a user might need depend on systemd.

            There is an exception, of course: RHEL releases < 7. If Debian sysadmins want to keep running unbloated systems they may have to buy RHEL 6. What I'm wondering is whether that's just irony or a case of cui bono?

            1. John Hughes

              Re: What is systemd

              If Debian sysadmins want to keep running unbloated systems they may have to buy RHEL 6.

              Why would they do that rather than running Debian Jessie (without systemd) which is considerably more up-to date and will, after it's time as stable is up, probably enter long term support (assuming Debian-lts is a success).

              1. Doctor Syntax Silver badge

                Re: What is systemd

                "Why would they do that rather than running Debian Jessie (without systemd)"

                Good idea. What's needed is a version of Debian Jessie in which without systemd as the default. Why doesn't someone make one? They'd need a name for it. Maybe Devuan.

                1. John Hughes

                  Re: What is systemd

                  "Why would they do that rather than running Debian Jessie (without systemd)"

                  Good idea. What's needed is a version of Debian Jessie in which without systemd as the default.

                  Why do you care whether it's the default?

                  Seriously, why do you care? It stil works with either of the alternatives.

                  Here is the list of packages that depend on systemd in current Jessie:

                  $ apt-cache --no-breaks --no-suggests --no-recommends rdepends systemd

                  systemd

                  Reverse Depends:

                  systemd:i386

                  libsystemd-dev:i386

                  systemd-ui

                  systemd-sysv

                  systemd-sysv

                  systemd-dbg

                  libsystemd-dev

                  libpam-systemd

                  sogo

                  |mate-power-manager

                  lxsession

                  live-config-systemd

                  lighttpd

                  |libguestfs0

                  gummiboot

                  That's an overestimate because apt-cache show doesn't always put the "|" if the package you're looking for is an alternative, for example lighttpd depends on "lsb-base|systemd".

                  If you check each package (ignoring the systemd ones, of course) you'll find that the only package in Debian Jessie (or Sid) that depends on systemd is gummiboot. Some tentacles, eh?

          2. John Hughes

            Re: What is systemd

            The systemd developpers have "inserted their tentacles" into nothing.

            I beg your pardon? They're steamrolling essential parts of the system (and even parts of userland) into their monster of a system

            Please cite one "essential part of the system" that systemd has "steamrollered into their monster".

            A funny gif is not a particularly convincing argument.

            1. Androgynous Cupboard Silver badge

              Re: What is systemd

              Please cite one "essential part of the system" that systemd has "steamrollered into their monster

              Really? There's quite a long list. Or do you not thing logging, DHCP, network interface management, automount etc. are essential system services?

              Of course, if they're not then the bigger question is what they doing in PID 1...

              1. John Hughes

                Re: What is systemd

                Please cite one "essential part of the system" that systemd has "steamrollered into their monster"

                Really? There's quite a long list. Or do you not think logging, DHCP, network interface management, automount etc. are essential system services?

                Of course, if they're not then the bigger question is what they doing in PID 1...

                None of those features has been "steamrollered into systemd". They are all, apart from logging(*) optional features of systemd, which can (and in Debian's case are) still be provided by non-systemd services.

                And, of course, even if you use the systemd features for those services they are not in pid 1.

                (* Yes, systemd logging is not optional. However it is not exclusive either(**), and systemd logs stuff that non-systemd systems don't -- error output from services for example.)

                (** syslog still works, things still get written to text logs).

                1. Jim 59

                  Re: What is systemd

                  They are all, apart from logging(*) optional features of systemd...

                  Be that as it may, there is clearly an intention in the systemd project to Hoover up these subsystems. Whey else would they have written the code.

                  This forum has uniformly delivered a pretty good shoeing to systemd. If the Linux/Unix world in general reflects that attitude, it would seem that support for systemd is largely restricted to the developers and their blood relatives. It is still possible for systemd to be a welcome part of Linux, if the project can listen to the users, respond and change accordingly. Are they capable of that ?

                  1. Trevor_Pott Gold badge

                    Re: What is systemd

                    " It is still possible for systemd to be a welcome part of Linux, if the project can listen to the users, respond and change accordingly. Are they capable of that ?"

                    Emphatically and overwhlemingly no. Which is - above and beyond all other reasons - why so many don't want this shitpile of a viral fuckup on their systems.

                    It might have been different, had the people in charge of systemd/gnome not been in charge of these projects.

                  2. John Hughes

                    Re: What is systemd

                    They are all, apart from logging(*) optional features of systemd...

                    Be that as it may, there is clearly an intention in the systemd project to Hoover up these subsystems. Whey else would they have written the code.

                    They wrote the code because they think their versions are faster.

                    There is no way they can prevent you from running standard NTP, DHCP, inetd, cron or whatever.

                    If some future version of systemd does stop one of the standard services running then you report that as a bug.

                    This forum has uniformly delivered a pretty good shoeing to systemd.

                    Mostly by claiming that systemd is doing things that it isn't doing. And when some of us try to correct the FUD we get told "oh, but they will do that in the future".

                    Me, I don't believe in clairvoyance, time travel or FTL.

                    1. John Sanders
                      Facepalm

                      Re: What is systemd

                      John,

                      I doubt that even 10% of the people here has used systemd for more than a 5 minute casual test.

                      Systemd has become some kind of baby-eating monster on people's collective imagination.

                      Systemd is not perfect, and some things are not as good as they should, but it certainly improves fast and once you get to know it it is pretty decent.

                      It is miles better than SystemV or Upstart

                      1. Adam Inistrator

                        Re: What is systemd

                        I dont even CARE if it is better! It is NOT the Linux way and Linux is DOING FINE - look at Ubuntu breaking into the various EU organisations as a DESKTOP! Getting a desktop userland OS from Redhat and somebody with the personality of Poett will not end well in the years that come. I'm mourning Debian already.

                      2. ElReg!comments!Pierre

                        Re: What is systemd

                        I doubt that even 10% of the people here has used systemd for more than a 5 minute casual test.

                        That may be the case. However some have, including myself. I switched back not for theological reasons but because it made a lot of things work unreliably (and some reliably not work). Only when I looked into what systemd really was and how it worked (which was after banning it) did I understand where my problems stemmed from.

                        but it certainly improves fast and once you get to know it it is pretty decent.

                        For some definition of "pretty decent", perhaps. However, on a production system you can't replace "rock solid" with "pretty decent". Together with the "improves fast" part, it is an argument to NOT make it the default and wait until it becomes really good instead.

                        That's only from a pragmatic, "need-to-work" point of view.

                        From an ideological point of view I do think that systemd is the spawn of some particuliarly dumb and nasty devil. But that's just my opinion, and so obviously entirely discussable.

                        1. rtfazeberdee

                          Re: What is systemd

                          "That may be the case. However some have, including myself. " - i guess you must be smarter than the Red Hat, Suse etc teams then, i'm sure they are going to release a system to their customers that doesn;t work.

                          From what i've read of your posts on systemd, you are being ideological and do not have any real technical problems to point out, just your inability to make it work.

                          1. ElReg!comments!Pierre
                            Mushroom

                            Re: What is systemd @rtfazeberdee

                            From what i've read of your posts on systemd, you are being ideological and do not have any real technical problems to point out

                            Your reading skills need improvement. I made it very clear in my posts -including the very one you're answering to- that the opinion I hold is the result of systemd borking the test system it got installed on; I spent hours tracing the various (and intermittent) startup problems to systemd, everything got back to normal after systemd purge, and only after did I research systemd; then indeed I had an ideological issue as well, as I happen to dislike opaque monolithic blobs. But my ideological opposition is only secondary.

                            Just because I suspect you can't be arsed actually reading my previous posts, I remind you of my technical problems -chich happened even before I knew what ideological abomination systemd is:

                            -trackpad not initialized at boot (roughly 1 boot out of 2)

                            -wifi interface not recognized (~ every boot with very rare exceptio; I had to initialize it from the CLI. No biggie on a test system but still)

                            -inconsistent mount-on-insert for removable media; sometimes not mounted, sometimes mounted as root, sometimes correct.

                            -inconsistent ability to unmount media as a normal user (may be related to the previous issue with a liberal serving of the "process-based" extra-stupid special sauce that systemd insists on).

                            -incorrect read/write/execute rights on removable media (probably linked to the previous two); this issue not fixable even as root i.e. when systemd had decided that the device was off limit, I could access it as root all I wanted but I could not modify its permissions as root. Fun, heh?

                            -fail on boot (rare, but never had happened with sysvinit and never has since I purged systemd).

                            That enough tech issues for you?

                        2. John Hughes

                          Re: What is systemd

                          That may be the case. However some have, including myself. I switched back not for theological reasons but because it made a lot of things work unreliably (and some reliably not work).
                          Bug reports? What actually didn't work?

                          1. ElReg!comments!Pierre

                            Re: What is systemd

                            Bug reports? What actually didn't work?

                            Just to make everything absolutely clear: I only tested systemd on test systems, and even then, "unwillingly" (as in, it got installed as I dist-upgraded test systems).

                            I do run Sid on such systems, because I like to keep abreath of current developpments, and I like to struggle with technical issues before they show up on stable. I also DO like to fix problems, that's my job.

                            I'm thus perfectly fine with systemd in Sid. That's where it belongs.

                            I fancy myself as a pretty practical person; I know of to fix problems, and I know how to to learn how to fix problems. I also know that I can't quickly and efficiently fix intermittent problems. As far as I know, noone can. And these are just the ones systemd created for me on the test systems. Admittedly, I could have devoted hours upon hours learning about the intrinsic workings of systemd (that changes every new moon, more often on a month with an 'e' in the name). Assuming I would have needed a replacement for my perfectly fine and proven system. Assuming I would want to replace a perfectly fine, elegant, lightweight and quite clever system that I know inside-out with a huge, dumb, opaque, malfunctiunning beast of a blob that insists on working differently with each release. I would look into it more seriously should it stay in Sid for a release cycle or two. Pushing it to stable now in Debian of all distros, The Conservative Distro, is just taking the piss.

                            Piss Duly taken. Apt-get dist-upgrade devuan

                            1. Matt Bryant Silver badge
                              Go

                              Re: Pierre Re: What is systemd

                              Whilst I haven't seen the issues Pierre has, at least his opposition to systemd is based on actual testing and not just froth. Bravo, sir, please continue, as actual problems and bug reports are what is needed.

            2. ElReg!comments!Pierre

              Re: What is systemd

              A funny gif is not a particularly convincing argument.

              A funny gif listing the non-init stuff gobbled up by systemd, on the other hand, may just be.

            3. Not That Andrew

              @ John Hughs Re: What is systemd

              > Please cite one "essential part of the system" that systemd has "steamrollered into their monster".

              Well udev was borged into systemd a while back and is no longer maintained separately (unless you count forks like eudev).

              1. John Hughes

                Re: @ John Hughs What is systemd

                Well udev was borged into systemd a while back and is no longer maintained separately (unless you count forks like eudev).

                The udev source code is in a subdirectory of the systemd tree.

                udev does not depend on systemd.

                So you're upset because of the location of the source code directory.

                Seriously?

                1. Not That Andrew

                  Re: @ John Hughs What is systemd

                  >So you're upset because of the location of the source code directory.

                  >Seriously?

                  Well I wouldn't call it upset, rather baffled and slightly concerned, yes. Why is udev now part of the systemd project if the intention is for it to remain standalone?

            4. oldcoder

              Re: What is systemd

              Database startup for one.

              Due to the poor way systemd has of knowing whether a service is available.

              Things like apache may need the database to available when it starts... but unless the database process can tell systemd it is actually ready to start, systemd ASSUMES it is ready as soon as it starts the database process - which causes problems for apache when it really hasn't.

              This is the same problem that NetworkManager has. The systemd developers had to modify NetworkManager to tell it when the network is ready (hence the NetworkManager-wait-online.service). Unfortunately that also requires dhcpclient to be modified if the network uses DHCP, so that dhclient can tell NetworkManager when the network is ready...

              And other network services ALSO have to be modified (named for instance) for the same reason.

              Thus the tentacles spread.

              1. John Hughes

                Re: What is systemd

                Database startup for one.

                Due to the poor way systemd has of knowing whether a service is available.

                Ok, this starts to sound like an interesting criticism.

                So, how is the problem solved in sysvinit?

                1. ElReg!comments!Pierre

                  Re: What is systemd

                  They wrote the code because they think their versions are faster.

                  And you would know that, how? Furthermore, even if that was true (yeah right), why borge the new improved version in the huge do-it-all Frankenstein monster? Why not just release them as standalone tools?

                  The answer is in Poettering's assertion that systemd is set to be an OS, not an init system.

                  If some future version of systemd does stop one of the standard services running then you report that as a bug.

                  A report that will duly be filed together with the few hundred terabugs sitting in systemd devs' garbage bin. Even Torvalds has trouble getting the systemd team to fix the most horrid of their shit.

                  And the problem is not that it would stop alternate utils from working; it's that by forcefully integrating them it may just cause them to disappear, as duplication of utils is not a good use of ressource.

                  So, how is the [database connection] problem solved in sysvinit?

                  That's a problem caused by systemd, sysvinit doesn't need to fix it because it doesn't create it to begin with. If you launch the services in order, no problem. You question is either a bad faith question or a proof of your ignorance of all things computer-y.

              2. Gorbachov

                Re: What is systemd

                > Due to the poor way systemd has of knowing whether a service is available.

                I've had to write sysv, upstart, supervisord* and systemd scripts that handle these situations. SystemD gave me the least trouble and was often the cleanest solution. The scenario you describe is non-deterministic (Apache _may_ need the DB) so there is no way to write a "correct" init sequence.

                When you write about the initialization of network services I don't think:

                "OMG those systemd BASTRDS!"

                but:

                "Well, maybe it was the best possible solution at the time and they plan on doing a better job later."

                I really don't get the hatred pouring out on the developers. I mean, yeah, "do one thing and do it well" is a worthy goal but it's not an unbreakable rule set by the knights who say "Ni!". If it makes more sense to keep it under one name so be it. If a significant section of meatspace decides it's garbage they'll stop using it and we'll have a mass exodus to Slackware. Somehow I doubt it in this case. All this noise looks to me like huffing and puffing of a few passionate individuals while the rest of the world passes them by.

                Good luck with the new distro but I'm sticking with Arch.

                * I know it's not really an init system but it does manage processes so it's relevant in this case

        2. browntomatoes

          Re: What is systemd

          I find it very sad that the Gnome/desktop dependency on systemd is driven, ultimately, by ConsoleKit becoming "unmaintained". The correct answer to "ConsoleKit is unmaintained" was not "replace it with something else that does the same job but depends on systemd" but "remove support for it, it's not needed anyway".

          ConsoleKit/logind's existence is basically motivated by the desire to support "multi-seat" systems - computers with multiple keyboard/mouse/monitor combinations connected to them used to support more than one user. That use-case is incredibly, incredibly niche. And yet it is dictating how basic components work to the detriment of simplicity in the vast, vast majority of common use cases. The same applies to its close cousin PolicyKit - it's simply not needed for the system to work properly unless you're in one of those very niche use-cases which the distros won't support out of the box anyway. The PolicyKit attitude in turn gets generalised into things like hostnamed, the very existence of which almost sounds like some kind of cosmic joke to me.

          The ConsoleKit/PolicyKit mentality has been gradually infecting the (Debian packaging of) other desktop components outside of Gnome like lightdm and this is what has led to the creeping dependencies on systemd via, e.g. libpam-systemd and systemd-logind. What is badly missing is an option to simply go without ConsoleKit features and gracefully fall back to the older way of doing things (sudo and local groups giving access to hardware, with known and defined security trade-offs).

          The worst part is that for all its sophistication, the *Kit software itself is very fragile and breaks in the slightest unusual configuration. For example, I recently set up a new Linux Mint install on a laptop to use my local Kerberos server for user authentication. It won't permit Kerberos-authenticated users logged in locally to suspend/resume or shutdown, despite them having logged in on the "right" terminal. Even more bizarrely, that includes suspending triggered by hardware events like a lid close on a laptop. At worst I would have expected changing the setting of what to do on lid close to be blocked by lack of permissions. But suspending itself? That is just stupid. And not even falling back to "sudo" (which it would have found those users have permission for) is also silly.

        3. Anonymous Coward
          Anonymous Coward

          @John Hughes - Re: What is systemd

          You dislike somebody calling your baby ugly ?

          1. This post has been deleted by its author

      4. Jim 59

        Re: What is systemd

        @thames Depending on who you talk to, Systemd is either the spawn of Satan, or it's the salvation of software packagers. More specifically, it's a type of "init system".

        Systemd is no longer a type of "init" system. As you say, it has forced its tentacles into every part of the OS, and is therefore a putative OS stack. Yes, it was introduced as an "init" system, but calling it that today is not an adequate description, and has misled many.

        I agree with the greybeards that systemd breaks many unix design laws. It has grown from a single tool to take over the OS, in the same way that Windows grew from a windowing library to take over the OS. The code quality is also acknowledged to be poor, the size of the project has spiraled to over half a million lines and the functionality is opaque. What could possible go wrong ?

        It is the manner of the systemd project which is bad, not systemd itself.

        1. Androgynous Cupboard Silver badge

          Re: What is systemd

          > It is the manner of the systemd project which is bad, not systemd itself.

          Exactly. Where's the spec? What are the project goals? In fact, what are the project limits?

          1. ElReg!comments!Pierre

            Re: What is systemd

            Exactly. Where's the spec? What are the project goals? In fact, what are the project limits?

            Well if you believe one interview of it's conceptor, systemd is a set of bricks from which you can build an OS. Which pretty much means "no scope, no limits"; that's in line with the carnivorous behavour of the project right now, incorporating all kinds of non-init utilities and slowly becoming a monolithic and opaque standalone OS.

            1. Anonymous Coward
              Anonymous Coward

              Re: What is systemd

              They're borging everything but the kernel. How long before that goes too?

              1. Vic

                Re: What is systemd

                They're borging everything but the kernel. How long before that goes too?

                There's already been the kernel debug parameter fiasco...

                VIc.

        2. John Sanders
          Facepalm

          Re: What is systemd

          Seriously?

          I'm not too fond of systemd but this is not funny to read to say the least.

          And what I means by this is that you do not know what windows is/was or what systemd is or what it does or why it does what it does.

          1. This post has been deleted by its author

      5. Trevor_Pott Gold badge

        Re: What is systemd

        "The Devuan developers are going to have to address the resource issues as noted above. Good luck to them though if they succeed and give some people what they want. "

        I've donated. Money where my mouth is, etc. I can only hope the rest of the community follows. Those of us who can't code still have our part to play in keeping Linux free/libre.

        1. Alan_Peery

          Re: What is systemd

          > I've donated. Money where my

          alternative fallback options are.

          Yes, I've also donated.

        2. Vic

          Re: What is systemd

          I've donated

          Likewise.

          I don't even use Debian, but I think it's important to keep the choice going. Monocultures tend to inbreed ...

          Vic.

      6. Anonymous Coward
        Anonymous Coward

        Re: What is systemd

        > Other people dislike it because they think it's a good concept which has been badly implemented by idiots who ignore valid criticism.

        You called me? :-)

        > The latter are the people whom the Systemd proponents don't like to admit exist, and they may in fact form the majority of the opposition.

        Yup. And I'll never understand how one bloke who's responsible for an audio server which some seven years after its initial "release" still doesn't work, or another whose "contributions" got banned from the kernel by Torvalds himself, have managed to convince anyone to let them get their hands into such a critical part of the OS. For no particular good reason too. I wish they would all just fuck off and go work for Microsoft¹ or someone like that.

        ¹ Nothing against Microsoft per se. As a big bureaucratic corporation they just seem a better fit for these types.

    3. Decade
      Boffin

      Re: What is systemd

      For the most positively biased introduction to systemd, I suppose there's Lennart Poettering's seminal blog entry, Rethinking PID 1. His entire blog is like a stream of consciousness of the current state and intended future of systemd.

      For a whole lot of tedious technical details, there's the freedesktop.org site, with links to download the source and the documentation. Yes, they do have an entire section about the canonical way to write the name of systemd. A lot of the documentation is just linking back to Lennart's blog, though.

      If you want to hack it, you need to keep in mind the principles of the systemd cabal: POSIX is obsolete and cross-platform is irrelevant, so don't bother with it. Backwards-compatibility is harmful, so don't worry about the past. Use and depend on the features of the newest Linux kernel.

    4. A Non e-mouse Silver badge

      Re: What is systemd

      Others have done a good explanation of what a Unix Init system does. I believe they miss a couple of valuable points.

      Firstly, systemd came about to try to improve boot speed. Because a typical Unix init system is made up of a series of shell scripts, you have to start a shell, parse the script, then run it for each init task. Shells can be relatively expensive to start, so systemd avoids this by not using a shell, and just having a single binary that reads configuration files.

      An objection to systemd, though, is that systemd is more than just an init system and actually does lots of other things that are typically done by separate little programs. (So breaking the Unix tenant of "Do one thing and do it well") By taking on more and more little tasks, it becomes more and more tied to Linux - you can't port systemd easily to the BSDs for example. As other things start to depend on systemd, then they too become impossible to port to other versions of Unix. (There is actually a project trying to create/port a minimalist version of systemd which is more cross-unix friendly.)

      Even on lwn.net (which is usually quite tame compared to other forums) the discussion about the whole Systemd/Debian debate is getting quite heated. The article about the Devuan fork has already attracted over 200 posts in two days - quite a high comment rate for an lwn article.

      1. jake Silver badge

        Re: What is systemd

        "systemd came about to try to improve boot speed"

        How often do you have to reboot your system, A Non e-mouse? This box (Slackware-current on a nine year old HP ZV5105) hasn't been rebooted for close to a month.

        The BSD-based router that it connects to TehIntrawebTubes through hasn't been rebooted in probably 6 months.

        The "improved boot speed" illusion is a side effect of consumers using consumer gear. The existing Debian devs apparantly don't grok this. *nix wasn't built to be booted up two or three times a day. It was (and is!) built to run continuously until a major security issue requires a rebuild & reboot.

        1. sisk

          Re: What is systemd

          How often do you have to reboot your system, A Non e-mouse? This box (Slackware-current on a nine year old HP ZV5105) hasn't been rebooted for close to a month.

          And there's the difference between a server and a desktop. It's why I still run Debian on my servers but run Mint on my desktop and laptops: They have different needs.

          My home desktop gets shut down every night before I go to bed and doesn't get turned back on until I eventually sit back down at it. Total it usually runs about 3-4 hours a day. My work computer usually gets shut down at 5 every Friday (and usually has in-progress projects open overnight the rest of the week) and gets booted back up while I'm getting coffee on Monday. There's no reason to leave a desktop on eating electricity all the time.

          Contrast that to my server at home, which, aside from power outages and a span of about a week a couple months ago while I waited for a new motherboard to come in, hasn't been off since the last time I moved.

          1. BitDr

            Uptime and the false need for a quicker boot...

            My desktop runs 24/7/365, as do my servers. The desktop is a Fedora 14 box which does everything except NetFlix. As of late (the last 6 months or so) I've been using a VM more and more. Eventually, my desktop will be a VM hosted on the more powerful of the two servers. The beast-under-the-desk will get replaced by a SFF thin-client terminal device.

            The laptop gets no use, but the netbook (an Aspire One) runs Fedora 14 and boots from an SSD in under 30 seconds, no need for anything faster. A tablet is the computer-on-the-road, and it's boot time is abysmal compared to everything else in the stable.

            So, for faster boots, use an SSD and keep your home partition on spinning rust (preferably a RAID).

          2. Pookietoo

            Re: There's no reason to leave a desktop on eating electricity

            Absolutely, that's why I hibernate my desktop in the evening and resume in the morning, with all my apps and documents open where I left off.

          3. jake Silver badge

            @ sisk (was: Re: What is systemd)

            "My home desktop gets shut down every night before I go to bed and doesn't get turned back on until I eventually sit back down at it."

            Mine gets suspended. Not totally power-off, but close. Hit a key, grab a swig of coffee, and get back to work where I left off. No muss, no fuss.

        2. rtfazeberdee

          Re: What is systemd

          If you admin a systems and loads and kills a lot of VMs, boot speed is required and that is the reason, a by product is that it benefits the desktop user.

      2. Pookietoo

        Re: systemd came about to try to improve boot speed

        But I reboot so infrequently that boot times are of vanishingly small importance.

    5. Anonymous Coward
      Anonymous Coward

      Binary logs? Ugh.

      I detest binary logs. Almost by definition one needs a log most when there is a problem and, for system start problems, that can be at a rather basic level of the system. One may well be on a text console, with absolutely minimal availability of the xyz_log_reader programme, if you know what it is called and where it is kept. A text log can be followed with tail(1), cut and pasted if one is on a GUI, read with cat(1) if all else fails, posted to a colleague on some (cover your eyes) Windows system, tends to be economical with space and is easily compressed for archiving. I can hardly believe the overheads are signficant compared to writing and reading a binary log. If they are that bad, I suspect the application has got more serious problems.

      1. John Sanders

        Re: Binary logs? Ugh.

        You can disable binary logs, nothing stops you or anyone from shipping rsyslog on the system doing the logs in the same way they have always been done.

        Binary logs are a necessity on systems where integrity of the logs (This is proof that they haven't been tampered with) is a must.

        1. ElReg!comments!Pierre

          Re: Binary logs? Ugh.

          Binary logs are a necessity on systems where integrity of the logs (This is proof that they haven't been tampered with) is a must.

          That's a lie, pure and simple. While there are plenty of ways to protect text logs from being tampered with, all you need to do to "tamper" with the binary logs is to crash journald. There is no way to recover a log corrupted by a crash, and there will not be in the foreseeable future, as the systemd devs do not think of it as a bug:

          https://bugs.freedesktop.org/show_bug.cgi?id=64116

          So much for the added security! That's an added security vuln, plain and simple (and an added pain in the ass when you want to know why the system crashed, for example to prevent it from happening again).

          1. John Hughes

            Re: Binary logs? Ugh.

            There is no way to recover a log corrupted by a crash,

            Wrong.

            The way to read a corrupted log is to just run journalctl.

            There is no way to "fix" a corrupt log because there is no need to do it.

            1. ElReg!comments!Pierre

              Re: Binary logs? Ugh.

              Zbigniew Jedrzejewski-Szmek 2013-08-05 03:08:22 UTC

              The only way to deal with journal corruptions, currently, is to ignore them: when a corruption is detected, journald will rename the file to <something>.journal~, and journalctl will try to do its best reading it. Actually fixing journal corruptions is a hard job, and it seems unlikely that it will be implemented in the near future.

              Lennart Poettering 2014-06-25 09:51:01 UTC

              Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence.

              So in a way you're right to say "The way to read a corrupted log is to just run journalctl", because that's the way to read a log, corrupted or not. But in the case of a corrupted log there's data in there that journalctl won't read and that you can't recover. It's much, much easier to recover data from a corrupt text log.

    6. This post has been deleted by its author

  3. Anonymous Coward
    Anonymous Coward

    This is gold

    > Waugh also feels “it’s very early in the lifetime of systemd, so it would be wiser to see how it goes before throwing toys around..."

    ...or rushing it into production.

    Thanks, good point :)

    1. Anonymous Coward
      Anonymous Coward

      Re: This is gold

      Indeed, if we're going to put it into production, we should also be thinking of an exit strategy in case it doesn't work out.

      1. Anonymous Coward
        Anonymous Coward

        Re: This is gold

        you do have to ask yourself this question

        How frequently do you boot (or change the config) of production Linux servers?

        When uptimes can be measured in years (Especially if you have kernel patching) why all the gnashing of teeth over something that is hardly used. Yes systemd can control restarts etc but most of the time is is mostly irrelevant to the operation of a Linux server.

        The thing I do think is that the SystemV eay of doing things was not granular enough and unless you were really, really careful some services could start before their dependencies were running. If we were to fix that properly then I'd be happy with staying with SystemV.

        Yeah, I'm a heretic and should be burned at the stake.

        1. fixit_f

          Re: This is gold

          "How frequently do you boot (or change the config) of production Linux servers?"

          Fair point, but the assumption here of course IS that you're running it on a server. What about people like me who run linux on home desktops and netbooks which are started and stopped all of the time? Suspend support in LINUX can still be a bit flaky depending on your hardware configuration so many prefer to shut down and restart entirely.

          So improved boot speed into your window manager of choice is a feature that would be very much appreciated by people like me.

          The way this is all being handled sounds pretty churlish though - no wonder so many people have the impression that the open source community is one big "Judean People's front / People's front of Judea" pointless infighting fest.

          1. ElReg!comments!Pierre

            Re: This is gold

            What about people like me who run linux on home desktops and netbooks which are started and stopped all of the time?

            Well, I tried it on a such a machine and it broke all manners of hardware support, so I guess the answer to your question is "they should avoid it as well".

            1. rtfazeberdee

              Re: This is gold

              What "manners of hardware support"? its broken nothing on my machines, maybe you need a training course on systemd.

              1. Kiwi

                Re: This is gold

                What "manners of hardware support"? its broken nothing on my machines, maybe you need a training course on systemd.

                So whereas most systems the hardware just works, now we have this wonderful piece of software that we may have to do a course on if it breaks our hardware?

                Why not stick with the systems where most things just work, out of the box? That's why I use Linux - I'm a fat lazy slob who can't be arsed looking for drivers etc and just want my machines to work. I don't want to fight broken hardware and missing drivers. If I did I'd use Windows.

                I'm already deeply disappointed that I have to use Pulse Audio for Skype (thanks Microsoft - and you wonder why people have a dislike of you!), and may just cut off contact with those few people I do talk to on Skype (or encourage them to use something better) so I can go back to Alsa. (Maybe I should see if I can figure out how to set things so only Skype uses PA and everything else works much better.. See? Now I am having to get off my arse and do something.. Look what that bunch behind Systemd has made me do!!!)

        2. John Hughes

          Re: This is gold

          The init system gets used at moments other than boot (or at least it should). One of the problems with sysvinit is that it is very poor at handling things that happen while the system is running, plugging in drives and so on.

          (And yes, we can and do change the storage configuration of runnning servers, hotplug is not just for desktops).

          1. Doctor Syntax Silver badge

            Re: This is gold

            " One of the problems with sysvinit is that it is very poor at handling things that happen while the system is running, plugging in drives and so on."

            Really? Isn't udev supposed to handle that, not init? Certainly, running current and past Debians on a laptop I haven't noticed a problem in that respect.

            1. John Hughes

              Re: This is gold

              Well, since it was me that fixed the bug that stopped init and friends mounting nfs filesystems when network interfaces came up (which doesn't necessarily happen when the initscripts think it should happen) it'd like to say no, it doesn't work perfectly with sysvinit.

        3. rtfazeberdee

          Re: This is gold

          try looking at the advantages for admins who administer VMs - VMs get created and destroyed a lot of times so boot time is important

          1. Kiwi

            Re: This is gold

            try looking at the advantages for admins who administer VMs - VMs get created and destroyed a lot of times so boot time is important

            I reboot my systems rarely* - so why should I be disadvantaged for others?

            The VM's I run (typically Windows ones ) maybe could stand to boot faster, but then I start them before doing other work anyway. If I was waiting on them often it might be nice to be able to wait a bit less, and I can understand and empathise with that, but as stated - I run servers and don't boot them often enough that even adding a few minutes to the boot time is a problem.

            * Well, the servers anyway - the work desktop gets turned on before I turn the jug and other important things in the office on so it's ready when I am.

        4. Jim 59

          Boot speed

          At home I use Linux Mint, which contains systemd. I am happy to have systemd slice 10 seconds off the boot time. But it is a trivial matter, even if you reboot every day, and certainly not worth dragging in > half a million lines of code.

          1. Tom 7 Silver badge

            Re: Boot speed

            "I am happy to have systemd slice 10 seconds off the boot time."

            But then when you try and do something it takes 11 seconds longer than it used to because the system was only pretending to be ready.

            Boot times are pretty much down to 'shuffle papers on desk and move tea cup into optimal position and its all ready to go" and have been for a long while.

          2. John Sanders
            Holmes

            Re: Boot speed

            Mint does not run full systemd, just a shim, this is if you're using v17 (Ubuntu 14.04) of course.

          3. Kiwi

            Re: Boot speed @Jim 59

            At home I use Linux Mint, which contains systemd. I am happy to have systemd slice 10 seconds off the boot time.

            Just took a look at this machine (thanks to your post), which runs Mint on some fairly decent (for my budget!) hardware - Core I7, 8G RAM, 64bit Mint Mate (16). It has systemD in it. And it does boot slooooowly, like 2-3 mins after post. Compare to my Dell D630 at work, running Mint KDE (17).. That's up in a little over a minute (maybe 1:30) including post - running a barely dual-code CPU with IIRC 2G of RAM, much more ancient hardware. Have an even more ancient machine running Ubuntu 10.04 still that's up in under 45 seconds.

            So the new stuff isn't necessarily faster. If SystemD is making this machine faster, I'd hate to see it with SystemD removed.. Which I just tried.. It's pretty tightly tied into a few items which are tied into a lot more. If I decide I want to remove it, it's not going to be easy.

        5. Vic

          Re: This is gold

          Yes systemd can control restarts etc but most of the time is is mostly irrelevant to the operation of a Linux server.

          I disagree. You might not boot the entire box very often, but services are started and stopped all the time. With SysV, this is both easy *and* it is discoverable - /etc/init.d/ has all the services, so tab completion works to assist the imperfect memory.

          unless you were really, really careful some services could start before their dependencies were running. If we were to fix that properly then I'd be happy with staying with SystemV.

          That would imply a broken init script - SysV scripts are entirely synchronous, so init will not even begin to start a service until all the previous ones are completed. Dependencies are handled trivially by starting dependent services later than their prerequisites.

          SysV has a number of problems, but not that one.

          Vic.

    2. Dr. Mouse

      Re: This is gold

      Exactly my thoughts. If it is so early in the day for deciding against it, it should not be going into Debian, the distro I go to for stability in my servers.

      I don't care that I don't get the newest, flashiest software. I care that it works, every time, and I can say that Debian has always done so.

      1. John Hughes

        Re: This is gold

        So don't use systemd then.

        Before Jessie Debian had the sysvinit package marked "essential", meaning that you had to have it installed.

        As of Jessie there is now a package "init" that is essential, that depends on "systemd | sysvinit | upstart" so you can install whichever init system you want.

    3. SolidSquid

      Re: This is gold

      If it's so early in the lifetime of systemd, why are they making it the default for Debian? Surely they'd wait until after they have a better idea of what issues there are before doing that

      Edit: Looks like I'm not the only one wondering about that

  4. Anonymous Coward
    Anonymous Coward

    Stupid name

    Like most things linuxey

    1. Anonymous Coward
      Anonymous Coward

      Re: Stupid name

      Bing!

      Speaking of stupid, please see why you misspelled Linuxy as Linuxey.

      Time for me to Thunderbolt

    2. jake Silver badge

      Re: Stupid name

      It's the System Daemon. Thus systemd. The trailing "d" denotes a daemon, or background process. Do you have a better name for this simple nomenclature? I thought not.

      Note: I'm not a fan of systemd. Yes, I've fiddled with it.

      1. Havin_it

        Re: Stupid name

        Ehhh... I'm guessing he meant "Devuan"?

  5. btrower

    Evil FlusterCluck

    Both sides of this get me worried. Neither alternative is very good from what I can see. Forking away from Debian seems like a doomed move. However, the people forking say that systemd is creating all sorts of dependencies. You have to worry when the people blithely working on a system which is already a nightmare of dependencies are complaining about a change the brings in 'too many'. OMFG.

    Maybe one of the people who became billionaires off of the ideas and hard work of other people could step in with funds to sort this out.

    1. ckm5

      Re: Evil FlusterCluck

      Well, if you just look around at the Wikipedia page and other writeups on systemd, it's clear that the team designing it want to centralize pretty much all configs in a similar fashion to Windows. It's not necessarily a bad thing, but it's being forced on people and also shutting out alternatives.

      Most of this is driven by the GNOME developers who have managed to create a few critical applications with no competition (e.g. network-manager) and are now using these as leverage to force other GNOME developed technologies (d-bus, systemd et al) as replacements to a whole raft of Linux technologies related to networking, authentication and service management.

      None of this would be bad if the developers behind it weren't arrogant know-it-all pricks that have insulted and dismissed a whole raft of highly skilled developers including Linus himself. The result is that a lot of respected kernel maintainers are not supportive of anything coming out of either GNOME or the systemd team - and probably for good reason.

      1. Flocke Kroes Silver badge

        Where is the off switch?

        When making changes, the first thing to do is make an off switch. Set the default position to off, and check that the off switch works. After that, no matter how badly you screw up, people can always get their kit working again by using the off switch.

        Network manager configures devices by name, which is a problem because the name depends on which device was attached first. Network manager requires devices run a DHCP server, which is not always possible and is certainly not desirable because the device would need to know which network it is connecting to before it can connect to the network. Network manager detects correctly configured interfaces and messes with them. Luckily network manager's documentation includes an off switch. The bad news is it doesn't work.

        I kill network manager, instruct sysvinit to never restart it. I gave each device a unique MAC address, and used /etc/network/interfaces to configure devices based on MAC address. Now devices are correctly configured depending on which computer they are connected to. Fixed and working because of an off-switch... in sysvinit.

        I have seen this problem before with KDE desktop search. I anticipate the problem, and configure nepomuk not to index video files, and not to index the disks full of video files. The system locks up because nepomuk has four maximum priority threads indexing the video files on the video disks. I use its off switch, but it doesn't work - next day nepomuk uses four maximum priority threads to index an SSD. The system is thrashes so badly that I have to use the power switch. I am greatly indebted to Dovydas and his instructions for killing Nepomuk with minimal swearing.

        To be fair to systemd, it ended up on a machine with an old kernel that lacked features it required. I could not ssh in. Luckily the device has a keyboard, but I could not log in either. I had to pull the SDHC card, plug it into a different computer and chroot in to fix it.

        Like KDE, if systemd is still around next decade, I will take another look at it.

        1. Ole Juul

          Re: Where is the off switch?

          Luckily network manager's documentation includes an off switch. The bad news is it doesn't work.

          I'm seriously hoping that Devuan dumps network manager as well. As time has passed, lots of things with Linux have gotten better, and quite a lot has gotten worse. Why can't we just stick with the better bits? I'll be trying the first Devuan version when it comes out. In the meanwhile, I'll stick with FreeBSD which is where I retreated when Linux started getting too irritating.

        2. ABee

          Re: Where is the off switch?

          Network-manager...every Red Hat course I have attended has included the immortal words:

          Red Hat instructor: ...and what do we do with NetworkManager...?

          Class: Turn it off!

          RH Instructor: That's right - chkconfig NetworkManager off.

      2. mathew42
        Linux

        Re: Evil FlusterCluck

        I'm thankful for Mint & Cinnamon.

        1. Dan 55 Silver badge
          Meh

          Re: Evil FlusterCluck

          Mint is based on Ubuntu which is based on Debian. Cinnamon is based on GNOME 3. It's coming to Mint sooner or later whether you like it or not.

      3. Mage

        Re: Evil FlusterCluck

        If it was something other than Gnome ...

        But Gnome 3 makes Win8 look enlightened. Gnome has lost the plot, so their judgement can't be trusted. On Ubuntu I use "Classic" and on Linux Mint and Debian other things. (Not Cinnamon or Gnome 3)

      4. John Sanders

        Re: Evil FlusterCluck

        """Well, if you just look around at the Wikipedia page and other writeups on systemd, it's clear that the team designing it want to centralize pretty much all configs in a similar fashion to Windows. It's not necessarily a bad thing, but it's being forced on people and also shutting out alternatives."""

        What?

        Troll alert.

    2. John Hughes

      Re: Evil FlusterCluck

      However, the people forking say that systemd is creating all sorts of dependencies.

      Yes, they do say that.

      When you ask them what dependancies they say "Gnome". When you point out that Gnome can be made to work without systemd by using systemd-shim, or by fixing consolekit they say "but there will be more in the future". I've never been able to find out where they got the time machine, and when I ask they tend to start frothing at the mouth about SJW's, hot babes, old testament prophets marrying underage children and things like that. (I am not joking).

      1. foo_bar_baz

        @John Hughes

        Who says "Gnome" is ignorant. Systemd is set to take over many parts of Linux, no exaggeration: udev, mount, PAM, syslog, cron, tcpwrappers, xinetd ...

        I run Linux when I want to understand what's happening behind the scenes, or be able to roll up my sleves and get my hands dirty. If I want to run a monolithic, opaque system that requires special tools to read binary logs, I am happy to run Windows Server, no joking.

        The totally rank attitude of the systemd devs is enough to put me off. Personally I'm in mini crisis since RHEL/CentOS has been my distro of choice until now. Devuan looks like a possible alternative.

        1. Doctor Syntax Silver badge

          Re: @John Hughes

          "Who says "Gnome" is ignorant. Systemd is set to take over many parts of Linux, no exaggeration: udev, mount, PAM, syslog, cron, tcpwrappers, xinetd ..."

          Ah yes, udev. A couple of times I've read the statement that although systemd has taken over udev you can still run udevd without systemd, it's just that you can't build it without systemd because of all the shared code.

          WHAT????

          Has it not occurred to these folks that all that needs to be done is separate the shared code out into one or more libraries that udevd and systemd can be individually built against? The fact that they haven't tells me that either the entanglement is deliberate, that the code it too much of a hairball to refactor or that it requires a degree of planning of proper interfaces that they can't be arsed to do.

        2. John Hughes

          Re: @John Hughes

          Systemd is set to take over many parts of Linux, no exaggeration: udev, mount, PAM, syslog, cron, tcpwrappers, xinetd

          Sorry, no.

          The only dependency between any of that stuff is that and systemd is libpam-systemd and that depends on "systemd | systemd-shim".

          systemd does provide alternative implementations of some features of syslog, cron and xinetd, but it also works perfectly well with syslog, cron and tcpd.

          udev is developed by the systemd team, but does not depend on systemd. (It shares some library code).

          I looked through the dependencies for 45758 Debian packages. 73 of them depend on some bit of systemd (not counting the 16 systemd packages), only 17 of them depend on something other than libsystemd (which does nothing if systemd is not init). 8 of them depend on libpam-systemd (which works with systemd-shim)

          So here is the list of packages in Debian Sid that depend on systemd:

          gpsd: netbase | systemd-sysv

          gummiboot: systemd

          init: systemd-sysv | sysvinit-core | upstart

          libguestfs0: systemd | sysvinit

          lighttpd: lsb-base (>= 3.2-14) | systemd (>= 29.1)

          lxsession: consolekit | upower (<< 0.99) | systemd

          mate-power-manager: systemd | consolekit

          sogo: tmpreaper | systemd

          So it comes down to gummiboot.

          I'd worry if you desperately need gummiboot. Or get your finger out and provide a patch.

        3. Anonymous Coward
          Anonymous Coward

          Re: @John Hughes

          Try Gentoo

        4. rtfazeberdee

          Re: @John Hughes

          You need to read up on systemd before you make rash decisions. pssttt, you can configure systemd have text logs too to dismiss just one of your misinformed criticisms

          1. Adam Inistrator

            Re: @John Hughes

            I dont want to configure logs to be text. I want them to be text by default and optionally something extra which I may come to accept in time given practical proof.

            1. Matt Bryant Silver badge
              Boffin

              Re: @John Hughes

              "I dont want to configure logs to be text. I want them to be text by default and optionally something extra which I may come to accept in time given practical proof." Well, yes and no. What you probably want is an immediate error report in text, so you can get an idea of the impact of the issue, but capturing all the actual data relating to an issue in binary does make sense in that it means you don't have to go back, switch on full capture, then recreate the problem to get all the actual data you need. A binary log is a lot more compact and can store a lot more data. Most admins I know turn down a lot of logging because they say it generates too big text log files, which means they get the headlines but have to go back to recreate the issue to capture all the troubleshooting data required to find, deduce and fix the problem.

      2. John Sanders
        Linux

        Re: Evil FlusterCluck

        At last!

        A sane comment!

    3. Bronek Kozicki
      Thumb Up

      Re: Evil FlusterCluck

      I'm not a billionaire, or even a millionaire but my daily work depends on Linux servers working well, so I'll be sending some money towards Devuan promptly and on regular basis. Diversity is one of principles of Linux and it would be a shame if all major distributions switched to one, oversized systemd just to make desktops little "better", for some meanings of the word.

    4. Adam Inistrator

      Re: Evil FlusterCluck

      the motivation for systemd could be money and salaries as much as anything. they are doing something different and betting the farm on it. just so sad that Debian is moving to it before Redhat has proven it.

  6. Stevie

    Bah!

    Fools! Devuan is democracy spelled in ones and zeroes!

    1. Havin_it
      Linux

      Re: Bah!

      Oh, I thought it was a play on "/dev/one", which any true greybeard will tell you is a glaring omission from the Linux kernel (I tried to get it in, but I wasn't the first and I doubt I'll be the last ;) ).

  7. Anonymous Coward
    Anonymous Coward

    Missing article text ?

    "That the “do-ocrats” largely come from the ranks of Gnome developers, rather than

    Negotiations have, of late, considered

    "

  8. thames

    "The dispute centred on plans to replace the sysvinit init system management toolkit with systemd, a similar but less-Linux-specific set of tools."

    You've got that entirely backwards. System V init is not Linux specific (the clue is in the name), and Systemd is strictly Linux-only. System V init is the lowest common denominator which works across many proprietary Unixes, Linux, BSD, and many other unix-like operating systems and long pre-dates Linux. Systemd is relentlessly incompatible with anything other than Linux and the developers have stated they have no intention of changing that.

    1. keithpeter Silver badge
      Windows

      Hurried reporting?

      @thames and all

      Article seems a bit rushed generally and misses some of the action (long time Debian developers resigning from Debian and Debian Technical Committee members resigning from the Committee after over-ruling Debian's systemd packagers over a dependency order issue). Interpretation of the actual developer General Resolution vote is contentious and would provide a good exercise in statistics, but around a quarter of those who voted (in turn just under half of the franchise of 1000+ devs) are not overjoyed with the direction Debian is taking. A minority but hardly a tiny one depending on your definition of tiny.

      A couple of points spring to mind in addition to the one raised by thames...

      1) Debian Jessie provides a choice of init systems, and provides systemd-shim for those who wish to use a rich desktop without systemd running as PID 1.

      2) You can build a systemd-less dbus-less logind-less minimal X system with a window manager quite easily, but you will be using apt-get with the --no-install-recommends switch quite a lot and you will be using pmount to mount your USB sticks and sudo/pm-utils for shutting down. The fork seems to want to try to build a minimalist distro with less rich desktop environments, one hopes with automounting of storage &c.

      3) Red Hat employ most of the systemd project developers. The Gnome project is separate but does receive sponsorship (I recollect) from Red Hat.

      4) The drive towards systemd I gather is mainly containers/automated admin of VMs but I'll not argue that one.

      1. Doctor Syntax Silver badge

        Re: Hurried reporting?

        "Debian Jessie provides a choice of init systems, and provides systemd-shim for those who wish to use a rich desktop without systemd running as PID 1"

        At present Jessie can be installed without systemd but if tasksel is used will put it back in there. Maybe between now & release tasksel will be modified to avoid this, but maybe not.

      2. John Sanders
        Linux

        Re: Hurried reporting?

        (long time Debian developers resigning from Debian and Debian Technical Committee members resigning from the Committee after over-ruling Debian's systemd packagers over a dependency order issue)

        You do realize that the people who resigned did so because they were pro-systemd and their decision to quit had to do with the amount of bullcrap emails and massive bombardment and continuous sabotaging from the people against systemd.

        People who haven't written a single line of code but can not stop trolling the entire internet day and night about how bad systemd is.

        1. John Hughes

          Re: Hurried reporting?

          You do realize that the people who resigned did so because they were pro-systemd

          Almost.

          Ian Jackson resigned because his GR "failed" and he was anti-systemd.

          (It's not often reported, but he was also anti-sysvinit -- he was in favour of upstart).

          1. John Sanders
            Holmes

            Re: Hurried reporting?

            You speak as if Ian Jackson innocently raised a GR and lost it, and then resigned.

            That's not what the history is here, lets say that he tried to subvert/maneuver the decisions made by the Debian's TC with regards to systemd after an entire year debating the matter.

            I can not suggest that you read an entire year of the Debian mailing list, but if you do, you will discover that the real history is not what people think it is.

            The real history is that a majority of developers, (not only in Debian, but across mostly 90% of the distributions out there), have agreed that moving forward the best option is to embrace systemd.

            They took into account the pros and cons of adopting systemd and decided via a democratic vote to go ahead and make systemd "the default in Jessie", with the idea of making it optional in Jessie+1, it is just that for Jessie there was no time to make it optional because of lack of times/resources.

            Those developers are the ones who have been for many years contributing to such distros, who only have the distro's (And FOSS) best interests in mind and that have explained time and time again that systemd its not going to eat your babies and that 99% of systemd's functionality is optional.

            But no, we all have made our minds and have formed myths in our minds about systemd, and all those whining rather than patch/fix or improve SystemV (Which is, lets face it obsolete by any modern definition) want the Debian developers to reverse a technical decision based on the opinion that systemd is going to eat your babies, because.... Reasons Poetering, RedHat and other strange theories.

            This whole systemd debate reminds me of the old Monthy Python's "The holy grail" witch sketch:

            If... systemd.. weighs the same as a duck, systemd's made of wood.

            Hence it floats hence we burn it!

            Systemd is not perfect, heck I would accept that its not great, but it is miles better than SystemV or Upstart, and like it or not there is no alternative available right now.

        2. keithpeter Silver badge
          Windows

          Re: Hurried reporting?

          You do realize that the people who resigned did so because they were pro-systemd and their decision to quit had to do with the amount of bullcrap emails and massive bombardment and continuous sabotaging from the people against systemd.

          Arguably. I was pointing out that the original article had not explained any of the background.

          "People who haven't written a single line of code but can not stop trolling the entire internet day and night about how bad systemd is."

          Perhaps we should be grateful that some(*) of the people concerned are not writing code. Can you imagine what it would look like if they did attempt to?

          It just might be that a good solid non-systemd fork (or 'spoon' in the sense of Refracta) would make things easier for the main distribution. Think about it. No legacy rc.conf stuff, no need to support several init systems, cleaner dependency chains &c.

          (*) I'm obviously excepting kernel developers and Debian packagers and such from this statement

  9. chuckufarley

    IMNSHO...

    ...I think the fork is good thing. While I am by no means a fan of systemd (due to it's lack of transparency) that is not why I think forking Debian is a good idea. No, forking is a good idea because it increases the chances of someone creating code that is not just new and original, but useful as well.

  10. Dr Scrum Master
    Headmaster

    The “No” camp complainedsystemd is not well-aligned with Unix philosophies, reflects the rise of a “do-ocracy” whereby effort trumps quality and steers Debian in the direction of the desktop. That the “do-ocrats” largely come from the ranks of Gnome developers, rather than

    Didn't the author's effort trump quality in this paragraph?

    ...oh, I see what you did there.

  11. Alain

    Hasn't this happened already with Upstart?

    Forgive me if I'm telling nonsense here, but hasn't all of this replacing SysV Init by some supposedly more powerful but immensely more obscure stuff (Upstart) happened already in Ubuntu without much ado being made about it?

    Don't misconstrude me, I'm 100% with the grey beards here (mine is slowing turning into this color anyway). Upstart has given me headaches and has brought the immense frustration of having to re-learn something completely useless.

    Just wondering...

    1. Gene Cash Silver badge

      Re: Hasn't this happened already with Upstart?

      Well the problem is systemd has its tentacles in EVERYTHING, not just boot.

      For example, I use udevd to run short scripts to automount and run fsck when I insert a usb stick, and copy images off when I attach a camera. You're not supposed to run long-running scripts from udevd, so I fork them off so udevd can run. No biggie.

      Well, systemd says fuck you and kills them because it tracks them by process group, and changing process group is really difficult, so I american-engineer it by running things as an "atd" job. Really. It goes to a really complex extra effort to screw things up.

      Also systemd does its own logging. In binary. Not using syslog. You can't cat or edit the logs any more. No. Just no.

      That's the sort of crap you have to put up with when running systemd.

      I uninstalled it and banned it from ever installing again.

      1. Alain

        Re: Hasn't this happened already with Upstart?

        @Gene Cash: thanks for the enlightement. Yep, it seems much more instrusive than the already disliked Upstart.

        > Also systemd does its own logging. In binary. Not using syslog.

        > You can't cat or edit the logs any more. No. Just no.

        Well, this certainly is enough for a red card in my books. Why the hell would they have broken such an immutable rule of Unix? Not using syslog? No way, indeed.

        1. John Hughes

          Re: Hasn't this happened already with Upstart?

          So just use syslog, like the default Debian install of systemd does.

          1. Alan_Peery

            Re: Hasn't this happened already with Upstart?

            The systemd camp would have saved themselves a lot of grief by making this the default for all distributions.

            1. John Sanders

              Re: Hasn't this happened already with Upstart?

              See the majority of the people seriously trolling and stalling systemd were (just like by chance) some prominent Upstart developers.

          2. BitDr

            Re: Hasn't this happened already with Upstart?

            Now John this

            "So just use syslog, like the default Debian install of systemd does."

            is condescending, and ill-deserved. It's like telling a pilot who wants to go to the moon to "just build a rocket and go like NASA did". Sys admins and businesses are looking at spending time and money figuring out how to undo Mr. Pottering's good intentions, why is that? If systemd was truly a drop-in (transparent) replacement it would cause no angst (although I'm sure SOMEONE would complain).

            However, now that the deed is done it's all going to come down to money, the question is whose going to get that money? Will I absorb the cost to change everything and allow systemd to infiltrate my servers going forward, or should I freeze everything where it is and put resources into an alternative distro like Devuan. I have to ask: "Does systemd brings any tangible or financial benefit to my server environment and business operation"? So far the answer is "no".

            Perhaps systemd can improve desktop PC boot-time, but so can using an SSD, which truly IS a drop-in replacement; but even THAT no longer matters as many desktops here are virtual and up 24/7/365 (except the Windows VMs, they seem to need rebooting to remain stable).

            Keeping on track with who gets the money, GNOME 3 is out, as is Windows 8 and the future Windows 10. Our users liked Gnome 2.x and it worked well, so Mate gets our support (yes financially) as does Windows 7 (but far less-so). We don't encourage Windows because with the exception of a certain nameless accounting package (that we're working to replace), it really is irrelevant and just increases costs.

            We were set to start sending funds to CentOS but their implementation of BIOSDEVNAME and subsequent gushing about now being officially aligned with RH caused us to re-evaluate their strategic direction. It's not looking good for CentOS in our shop, although that too is subject to change.

            In real-estate it's all about location, in system administration & business I.T. it's all about stability. We are always looking to improve things, but we need to do it in a sane manner. It's evolution vs revolution. If you change something critical, no matter how well-intentioned the change, you must QA & regression test it before releasing it. It has GOT to be ROCK solid, well documented, and transparent in it's use & maintenance. Miss ANY of these and you had best go back to the drawing-board.

        2. rtfazeberdee

          Re: Hasn't this happened already with Upstart?

          Do some research , don't rely on idiots who don't do any. You can configure systemd to spit out text logs to rsyslog as per normal alongside the more comprehensive binary logs.

          1. Ben Tasker Silver badge

            Re: Hasn't this happened already with Upstart?

            @rtfazeberdee

            So tell me, if I'm going to configure to log in text, what precisely is the point in me having journald running in the first place?

            You're essentially arguing that it's OK for SystemD to use it's own (IMHO crappy) logging system because I can make it also pass onto rsyslog. journald is therefore completely redundant, so why would I want it on my system in the first place?

            That aside though, even if you are planning on using journald's logs, configuring it to also spit out to rsyslog is a good idea. Anything that causes journald to exit uncleanly leads to log corruption, and the SystemD devs appear not to care

            1. John Hughes

              Re: Hasn't this happened already with Upstart?

              You're essentially arguing that it's OK for SystemD to use it's own (IMHO crappy) logging system because I can make it also pass onto rsyslog. journald is therefore completely redundant, so why would I want it on my system in the first place?

              journald logs stuff that systlog can't, the stdout and stderr of things started by systemd for example.

              Also, since it knows exactly which service logged each message it can show you the last messages for every service with the systemctl stautus command, which is pretty cool.

              # systemctl status ssh

              ● ssh.service - OpenBSD Secure Shell server

              Loaded: loaded (/lib/systemd/system/ssh.service; enabled)

              Active: active (running) since Thu 2014-11-27 10:58:31 CET; 4 days ago

              Process: 906 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)

              Main PID: 592 (sshd)

              CGroup: /system.slice/ssh.service

              └─592 /usr/sbin/sshd -D

              Nov 27 10:58:35 celtic sshd[592]: Server listening on 0.0.0.0 port 22.

              Nov 27 10:58:35 celtic sshd[592]: Server listening on :: port 22.

              Nov 27 10:58:53 celtic sshd[592]: Received SIGHUP; restarting.

              Nov 27 10:58:53 celtic sshd[592]: Server listening on 0.0.0.0 port 22.

              Nov 27 10:58:53 celtic sshd[592]: Server listening on :: port 22.

            2. rtfazeberdee

              Re: Hasn't this happened already with Upstart?

              journald starts logging at an earlier stage that it is possible for rsyslog to start logging and long after rsyslog has to stop logging during shutdown and it produces a lot more information. It also has a great viewing tool for the logs, journalctl. If you are really interested in logs, have a look at what you get.

              1. Kiwi

                Re: Hasn't this happened already with Upstart?

                It also has a great viewing tool for the logs,

                Can I do that over ssh or telnet or whatever other method I use on a poor connection (I'm out on the road, 2g only signal at best, some problem with the web or email server needs immediate attention...)

                Honest question. Haven't yet looked at SD, hoping not to have to but seeing it already has a death-grip on Mint on this machine (ie if I remove it the system pretty much dies) I guess I'll be forced to deal with it long before I have the time and other critical resources (eg inclination) to research it properly.

                (Put me in the "I'm not sure it's a bad thing but it sure as hell looks like it, especially with "Kay S"'s (surname escapes me) attitude to what are clearly either quite serious bugs or extremely stupid programming decisions. If their attitude to people having a problem with the way they handle kernel debug commands is any indication on how they code, then their code is not something I would ever want on my machine - the attitude is NOT what I am willing to tolerate even in my small shop!)

            3. John Sanders
              Linux

              Re: Hasn't this happened already with Upstart?

              @ Ben Tasker

              Using binary logs is optional, it just happens to be the default in RHEL 7 and CentOS 7, but you as a distro maker are not forced to make such a default.

              It is easier to think systemd is going to sprout tentacles and its going to eat your server babies than reading the documentation isn't?

              1. Ben Tasker Silver badge

                Re: Hasn't this happened already with Upstart?

                @John

                I'm a bit late seeing this reply, but;

                I've read the documentation, and have been playing around with SystemD a lot, but for a lot of people the _default_ (which is what it'll be if you're using RHEL 7) is supposed to be relatively sane.

                It's far from the only issue I have with systemd, and one of my biggest concerns is what future pain we're going to get from the somewhat cavalier fuck-you-all attitude taken by some of the systemd devs. If we're talking about supporting businesses on this thing, then I need to be sure we're not going to see the infamous pulseaudio approach of criticising the use-case rather than fixing the crappily thought out implementation.

          2. John Sanders
            Linux

            Re: Hasn't this happened already with Upstart?

            Most people criticizing systemd have used it for 5 mins only, they will not let the facts get in the way of thinking that systemd will eat their server babies.

      2. rtfazeberdee

        Re: Hasn't this happened already with Upstart?

        "Also systemd does its own logging. In binary. Not using syslog. You can't cat or edit the logs any more. No. Just no." You need to read up about systemd before you trash it. You can configure systemd to produce text logs to rsyslog in addition to the default of binary logs. systemd requires udev. You just lack the skill of configuring systemd to suit your requirements and blame it for your failures

      3. This post has been deleted by its author

      4. regadpellagru

        Re: Hasn't this happened already with Upstart?

        Is it just me, or I'm starting to see why SysVinit is script-based ?

        This was to avoid ANY dependency ! Dependencies are a complete evil,

        and the only way is likely to have the start sequence be script-based ...

    2. Doctor Syntax Silver badge

      Re: Hasn't this happened already with Upstart?

      Yes it has.

      One of the things sysv is accused of is handling race conditions. The only race condition I've encountered is on my MythTV box. A second disk which goes into the volume group providing /srv sometimes isn't ready when the system tries to mount it. It requires plugging in a keyboard to recover which isn't very useful if the box is starting up for an unattended recording. The init system being used? Upstart.

      1. JEDIDIAH
        Devil

        Re: Hasn't this happened already with Upstart?

        One of my more complicated desktop machine requires manual intervention in order to boot. It has a combination of RAID devices and NFS shares. This box consistently gets confused and thinks it's RAID and NFS filesystems aren't ready at boot time. Startup HALTS as it requests user input of the typical Windows style (ignore-cancel-continue).

        Upstart.

        Oddly enough the box manages to sort itself out despite the panic and the error messages.

        This is a storage server. HALTING during boot is not good.

    3. John Sanders
      Flame

      Re: Hasn't this happened already with Upstart?

      Yes, and the funny thing is that RHEL/CentOS 6 uses upstart, and not SysV

  12. Anonymous Coward
    Anonymous Coward

    If systemd is so bad...

    ...then why are so many distros using it? Is it because the alternatives are even worse?

    1. Sir Alien

      Re: If systemd is so bad...

      Not many distros use it yet because of the massive debacle. I know red hat use it but that's because they made it. There are loads of distros on the fence because of systemd.

      But because gnome would require systemd in future if you wanted to not use systemd you would also have to drop gnome.

      To be honest not so much of a great loss since gnome 3+ has become utter rubbish.

      - SA

      1. rtfazeberdee

        Re: If systemd is so bad...

        @Sir Alien

        Not true, where are you getting your facts? from the bottom of your shoe?. Only Gentoo and Slackware linux do not/will not use systemd, Ubuntu currently uses their own version called upstart but will be upgrading to systemd shortly.

        SO that makes Fedora, opensuse, Arch, CoreOS, Magiea, RHEL, SLES, Tizen, Debian using it now.

    2. Hans 1
      Unhappy

      Re: If systemd is so bad...

      > If systemd is so bad...

      > ...then why are so many distros using it? Is it because the alternatives are even worse?

      Did you read the article ? Not using systemd means you have to adapt gnome et al. TBH, I did not know all this ... now I know why there is so much uproar ...

      Logging in binary ? Seriously ? HERESY ! Linus, please, `kill -11` those b@st@rds.

      Think I will be moving to FreeBSD on my main workstation next ... currently on Debian 7, after ubuntu switched to upstart/Gnome 3 ... among other BS. Note that only Mac OS X, Windows, and Linux are supported on workstations where I work, not that I care.

      Am already miffed by Gnome 3 - yes, I finally switched some weeks ago... had to install a gazillion extensions to switch various things off, move system tray back to where it belongs (hack an XML in the process because the fsck'ing devs are toooo numpty to detect items in the brain dead default tray), disable hot corners, have a "REAL FSCK'ING MENU" ... and even then, I now have to click to expand groups in it ...

      FreeBSD or OpenIndiana for me, next ... OpenIndiana is in serious need of love, not sure it runs on my laptop, though.

      1. Anonymous Coward
        Anonymous Coward

        Re: If systemd is so bad...

        @ Hans 1

        Of course I read the article. But I'm pleased I've helped you vent some of your large supply of anger.

    3. Trevor_Pott Gold badge

      Re: If systemd is so bad...

      "If systemd is so bad... ...then why are so many distros using it?"

      It's called blackmail.

      RedHat are behind the whole thing. They spend the money that makes a lot of critical pieces of your average Linux distribution work. Now those things won't work without systemd and/or getting them to work without systemd is a right bitch/there are roadmaps to make them not work without systemd in short order.

      The short version of this whole thing is that Poettering - and with him, RedHat - are trying to take the kernel away from Linux Torvalds. They are doing so by creating another kernel in userland that everything depends on. Once they have enough stuff jacked into Poettering's matrix, they'll use it to leverage Torvalds out of the picture and finally take the whole cake for themselves.

      Systemd is nothing more than a cynical play for domination and control of the entire Linux ecosystem. To "own the stack" of a modern distro. And since RedHat has managed to co-opt so many core projects, there is precious little to stop them.

      "Linux" as we think of it today is on life support. Android/Linux and systemd/Linux are now looking to be the two dominant entities. Traditional Linux - one that adheres to the Unix philosophy - is all but dead. Hopefully, Devuan can save it.

      1. John Sanders

        Re: If systemd is so bad...

        @Trevor_Pott

        What a disappointment to read this kid of BS from you.

        So that is why systemd is GPL 2.1 isn't? To prevent anyone from forking or modifying it.

        1. Trevor_Pott Gold badge

          Re: If systemd is so bad...

          Who the metric fuck has the resources to fork an app that's a half million lines of code? What about once it's a million? Two? Ten?

          Past a certain point, the fact that it's GPL means nothing.

          You are basically making the argument that the American people have power over their government because the second amendment gives them the ability to carry around AK-47s. Ignoring completely the part where the government has everything from tanks to helicopters to drones, and there isn't a hope in hell of "the people" rising up against the government without being beaten back down as domestic terrorists.

          The same basic principles apply to open source. Past a certain point, the complexity, integration and sheer size of a project make it functionally impossible to fork, unless you can convince the overwhelming majority of the original developers to move to the fork. (LibreOffice, MariaDB, etc.)

          SystemD is a fucking cancer. The goal behind it's ongoing metastasization is nothing more than control of the Linux ecosystem in it's entirety. You can lay down any excuses you want, attempt to dismiss any criticism with a half truth or a technicality, but you can't change the fact that the thing has been rammed up our asses against the express wishes of a huge chunk of the community and with the developers openly and proudly refusing to engage with the community about any aspect of either design or implementation.

          it's the same arrogant egofuckery that the Gnome team displayed and it has no fucking place as a hydra-like unkillable monster at the core of open source upon which everything expected to hang.

          There is room for exactly one Linus Torvalds in the Linux ecosystem, and he's right where he belongs: keeping the kernel sane.

          We don't need a second goddamned kernel running in userland.

          1. Matt Bryant Silver badge
            Facepalm

            Re: Potty Re: If systemd is so bad...

            ".....There is room for exactly one Linus Torvalds in the Linux ecosystem....." In that case it would seem quite reasonable to ridicule your statement by pointing out the dominance of Torvalds and the one kernel. Simply repeat your whole post, just replace the occurrences of "systemd" with "Torvalds' kernel". But then you could argue there is no one kernel due to the existence of BSD - those that don't want Torvalds' kernel can go use BSD, it is just that the Linux kernel is the overwhelmingly more popular choice, regardless of the lack of control the average user has on kernel development. Those that don't want to accept that systemd is probably going to be the more popular choice can now go play with Devuan and stick with init, you have your choice, just please go do it with less bile and volume.

    4. Alan_Peery

      Re: If systemd is so bad...

      Because the earlier scope of systemd seemed to be more reasonable.

  13. Hans 1
    Facepalm

    from http://0pointer.de/blog/projects/systemd.html

    >As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.

    Not sure what they mean by fast, my Linux system loads in 7 seconds flat with SysV, including the 2-3 seconds bios splash screen. Linux is not like windows, where you have to reboot 3 times to install a browser update, so who the fuck cares ?

    1. GrumpyOldBloke

      By fast they were looking at cloud fast whereby virtual servers are stood up and torn down on demand. As you have discovered though the cost of parsing init scripts is not that high and certainly not enough of a problem to justify systemd as a solution. Most of your boot time (apart from the splash screen) will probably reflect the time it takes to detect and init hardware and get a few hundred MBs of stuff off the disk and into RAM.

      1. Vic

        As you have discovered though the cost of parsing init scripts is not that high and certainly not enough of a problem to justify systemd

        That much is certainly true.

        SysV init scripts are pretty much bomb-proof, but being entirely synchronous, they run one-at-a-time, and a delay in one delays all of them. It is an inefficient system.

        The idea of running independent init scripts in parallel is a good one - but systemd seems to have lost sight of that goal, and is heading for the "replace everything in sight" model. And that's why there is resistance to its adoption; the concept is good, but the implementation is worrying.

        Vic.

  14. jake Silver badge

    From this install of slack-current:

    jake$ apropos systemd

    systemd: nothing appropriate

    jake$

    ::heh::

  15. mrwoltman

    Production ready?

    Of course it's ready for production. It's provided by Redhat and is used in RHEL, arguably the only distro that actually matters. Forks like CentOS use it too, and haven't had any problems. This is like the stupid Qt vs GTK argument all over again that led to wasting years of effort on Gnome instead of KDE.

    If the "UNIX" philosophy means "a bunch of bash scripts that kind of work" I guess it's time for the philosophy to die.

    1. Charlie Clark Silver badge
      FAIL

      Re: Production ready?

      RHEL, arguably the only distro that actually matters.

      ROFL

      Or this is evidence of RedHat's long term game plan to own, and I mean this literally, the Linux eco-system?

    2. Uncle Timbo

      Re: Production ready?

      Ah - that'll be why I have 168 Debian servers at our fairly modest university department. Another well known compsci uni department in London runs nothing but Ubuntu (1000 odd installations) and dumped RH years ago when I worked there.

      We're not alone - both Debian and Ubuntu are extremely popular across the board. I have no idea which distro wins by numbers - quite possibly RHEL, but to claim it's "the only distro that actually matters" is not correct.

    3. Ben Tasker Silver badge

      Re: Production ready?

      "Forks like CentOS use it too, and haven't had any problems."

      The major problem is, if and when issues do arise, you need to have faith that one or the other of the following is true

      - The SystemD devs will recognise the issue and resolve it

      - There's an exit strategy so that SystemD can be dumped

      For a lot of people, it's very difficult to have faith in the former, and the latter is likely to become very difficult (hell, the reason Debian went with SystemD was the additional workload involved in not using it)

      There have definitely been some issues in CentOS 7, I've experienced a few myself. I'm happy enough to play around with SystemD so that I get familiar with it, but it's going to be a very long time before I'm happy putting it anywhere near a production server, and option 1 above still needs addressing before that.

      1. foo_bar_baz

        Re: Production ready?

        The first point is what really worries me. If there's one thing I've learned during my years in IT is that Things Go Wrong. There are always unexpected problems related to a specific setup, down to driver issues with a Big Vendor Certified Hardware-OS Stack (tm).

        What the systemd people have amply demonstrated is they don't care about other people's problems and are not willing to keep their own patch clean.

        The second part is the sheer amount of change. Change equals problems, bugs, and security issues. The homogenising effect of systemd on the Linux ecosystem is just one part of it. Watch this space for Linux / systemd related disasters.

        1. Ben Tasker Silver badge

          Re: Production ready?

          "The second part is the sheer amount of change. Change equals problems, bugs, and security issues. The homogenising effect of systemd on the Linux ecosystem is just one part of it."

          Not just that, but (as with any change) you need to be damn sure that your sysadmin (whether that's you or someone else) is familiar enough with the SystemD way of doing things before letting it anywhere near production.

          If something's gone horribly wrong, is the restoration of services going to be slowed by it being a SystemD based system (either because your Sysadmin isn't familiar enough with it, or because it turns out the SystemD guys hadn't considered your use a valid use-case).

          Given the huge amount of change involved in SystemD, there's quite a lot to cover.

      2. John Sanders
        Linux

        Re: Production ready?

        "(hell, the reason Debian went with SystemD was the additional workload involved in not using it)"

        And that somehow is not important isn't? Someone else will do the job for you.

        It floats its a witch, burn!

        1. Ben Tasker Silver badge

          Re: Production ready?

          @John

          Never said it wasn't important, but it's not exactly a resounding fucking endorsement of SystemD is it ;)

  16. Anonymous Coward
    Anonymous Coward

    thowing out the baby with the bathwater

    The problem is that systemd has evolved - or maybe mutated would be more accurate - into a Borg. Something it was never intended to be in the first place. systemd was supposed to replace SVR4-style init scripts, because of all the well-known problems with SVR4-style init scripts.

    It is true that systemd does need to be ripped-out from the places it does not belong to, and it needs to be scaled-back to its initial stated scope.

    Neither side seems to be willing to acknowledge that this is a solvable problem. and their spat is, really, quite childish.

    Why not solve this in the traditional Linux/FOSS way? Meaning: you want a better alternative for component XYZ, because you believe XYZ is broken? Then you write one. Or you fix the existing broken one. Forking because you don't like the init subsystem or its replacement systemd is quite the unnecessary leap. I don't know if it will really lead anywhere.

    This isn't to excuse the bad attitude and crappy implementations coming out of the GNOME/Poettering/Sievers camp. To wit:

    - GNOME itself

    - PulseAudio

    - systemd

    Crap hairball implementations on the one side, temper tantrum followed by "I'm taking all my toys and I'm leaving and I'm forking AND I'M NEVER COMING BACK!" overly dramatic scene on the other side. A time-tested recipe for success. NOT.

    1. Hans 1
      Windows

      Re: thowing out the baby with the bathwater

      >systemd was supposed to replace SVR4-style init scripts, because of all the well-known problems with SVR4-style init scripts.

      <humble>

      Care to elaborate ?

      </humble>

      Note that I did use google to search, the only issues I could find is it is slow and does not integrate with dbus so well. I think that a boot under 30 seconds is acceptable on Linux, my system boots in 7. As for dbus intergration ... not sure I need/understand that.

      1. Ben Tasker Silver badge

        Re: thowing out the baby with the bathwater

        @Hans

        It also allows for dependancy based booting (i.e. don't start x until the network's up) etc.

        1. foo_bar_baz

          @Ben Tasker

          Dependency based booting is only useful to speed things up, eg. let non-dependent services start up in parallel.

          I know the network is up before postfix because the network init script starts first and doesn't exit until it's finished. See contents of /etc/rc3.d or equivalent.

          If this example is so important, why are the systemd devs so lax in their attitude elsewhere: "if we don't know anything, we consider the system online"?

          1. Ben Tasker Silver badge

            Re: @Ben Tasker

            @foo

            Was only replying to Hans' question about what benefits it's supposed to bring.

            I completely agree with you, btw, it's more than possible to set Sysv init scripts up to avoid the sorts of issues that SystemD apparently saves us from. All it takes is a little bit of thought and planning.

            1. Anonymous Coward
              Anonymous Coward

              Re: @Ben Tasker

              Totally agree - if it's timing issues, put a sleep in and run it in the background. Also you can run several scripts in one script so that each follows in order.

              As you say - just a few minutes thought and a bit of planning.

          2. Vic
            Joke

            Re: @Ben Tasker

            If this example is so important, why are the systemd devs so lax in their attitude elsewhere: "if we don't know anything, we consider the system online"?

            They're clearly Star Trek buffs - it's an opportunity to state out of the blue, at the first sign of any trouble, that "$really_necessary_system is offline"...

            Vic.

        2. JEDIDIAH
          Linux

          Re: thowing out the baby with the bathwater

          "dependency based booting" is easy.

          You have an ordered list and the network is higher in that list than X.

          On the off chance you have a fatal failure of some kind, do you really want your system crippled or do you want it to at least boot up so you can figure out what went wrong and how to fix it? The "dependency" based approach sounds nice but it's easy to render your system completely unbootable. (been there, done that)

          Some things sound cool until you actually try them.

        3. Anonymous Coward
          Anonymous Coward

          Re: thowing out the baby with the bathwater

          And that can't be solved using:

          S40network

          ...

          S66somethingthatneedsthenetwork

          ?

      2. Anonymous Coward
        Anonymous Coward

        Re: thowing out the baby with the bathwater

        > Care to elaborate ?

        It's next-to-mpossible to express dependencies between start scripts with SVR4-style init, unless you resort to horrible hacks such as creating a temporary "semaphore" empty file under /tmp and have the dependent script wait for the file to disappear while polling for it, etc. etc. Hack-ish stuff.

    2. Doctor Syntax Silver badge

      Re: thowing out the baby with the bathwater

      "Why not solve this in the traditional Linux/FOSS way? Meaning: you want a better alternative for component XYZ, because you believe XYZ is broken? Then you write one. Or you fix the existing broken one. Forking because you don't like the init subsystem or its replacement systemd is quite the unnecessary leap. I don't know if it will really lead anywhere."

      Firstly, fixing the existing broken one, if the existing maintainers are unwilling to do it themselves, is accomplished by forking. It's the traditional Linus/FOSS way.

      Well, it's not just one component, it's a whole inter-related heap of them. In fact, apart from the kernal & libc, it's the core of the OS. So just replacing a single component won't cut it. The term fork is reasonably well merited although you could also call it a respin or a derivative.

      Of course the twist in the tail here is that in fact the underlying rationale is that the original wasn't broken but it's being fixed anyway. Conventional wisdom has something to say about that,

      1. Anonymous Coward
        Anonymous Coward

        Re: thowing out the baby with the bathwater

        > Firstly, fixing the existing broken one, if the existing maintainers are unwilling to do it themselves, is accomplished by forking. It's the traditional Linus/FOSS way.

        Uhm. no, it's not. The Linux/FOSS way is

        1- you fix it yourself

        2- you post binaries and source of the fixed stuff so that others can try and see for themselves if the new version is indeed better than the old one.

        What you don't do is: issue directives such as "fix XYZ for me because I don't like it and it's broken and the other guys are mean and they don't wanna fix it and they took my Xbox controller".

        1. Doctor Syntax Silver badge

          Re: thowing out the baby with the bathwater

          "> Firstly, fixing the existing broken one, if the existing maintainers are unwilling to do it themselves, is accomplished by forking. It's the traditional Linus/FOSS way.

          Uhm. no, it's not. The Linux/FOSS way is

          1- you fix it yourself

          2- you post binaries and source of the fixed stuff so that others can try and see for themselves if the new version is indeed better than the old one."

          Quite so. It's called a fork.

          1. Anonymous Coward
            Anonymous Coward

            Re: thowing out the baby with the bathwater

            > Quite so. It's called a fork.

            I like your approach.

            Why don't you fork RedHat because you think you want them to write a new 'ls'. You don't like the current one, but you can't be bothered to actually write a new 'ls' yourself.

            Yeah.

    3. AJ MacLeod

      Re: thowing out the baby with the bathwater

      Gnome (3), PulseAudio, systemd... yep, three technologies that have been purged from my own main desktop machine as intolerable, impenetrable rubbish. It works much better without any of them.

    4. JEDIDIAH
      Mushroom

      Re: thowing out the baby with the bathwater

      > Why not solve this in the traditional Linux/FOSS way? Meaning: you want a better alternative for component XYZ, because you believe XYZ is broken?

      Not necessary.

      We already have a suitable component. The problem is that the other camp likes to actively sabotage alternatives. This is apparent with the GNOME3 debacle. There should have been no need to fork GNOME2 into MATE but the GNOME devs made it necessary. They specifically sought to make the obvious conservative option impossible.

      Before you can have compromise you need 2 sides that are willing to do that.

      1. Anonymous Coward
        Anonymous Coward

        Re: thowing out the baby with the bathwater

        > Before you can have compromise you need 2 sides that are willing to do that.

        That is also very true.

  17. Michael Thibault

    Knock yourself out

    The in-fighting is theatre, in the same way watching someone repeatedly punch themselves in the head can be seen as theatre.

    Linux on the desktop^H^H^H^H^H^H^Hdoorstep^H^H^H^H^H^H^H^Hcurb?

    1. itzman
      Headmaster

      Re: Knock yourself out

      s/curb/kerb/g

  18. Dan 55 Silver badge
    Trollface

    This needs to be fixed now

    Obviously what we need is a new startup daemon which is compatible with initd, upstart, and systemd.

  19. Hans 1
    Joke

    New Bug: Linux Should Kernel Panic when Systemd is Detected

  20. h4rm0ny

    Do Not Want

    Some of the fallacious and loaded argument from the systemd camp winds me up. In particular that quote in the article about giving systemd a chance to mature before "throwing toys out". Apart from the patronizing language (very inappropriate - this is a core part of the distro we're discussing and they're trying to make it sound like throwing a tantrum over nothing), there is also the very simple fact that this is NOT a case of giving something a chance to mature before judging it - it's choosing a direction for development. Doing what they suggest is moving you ever further down that road to systemd and making it ever harder to back out.

    Disingenuous and offensive.

    1. Ole Juul

      Re: Do Not Want

      Bang on h4rm0ny. I'm glad to see by the upvotes that others thought so too.

  21. calmeilles
    Alert

    End of the world

    This reeks of One Ring To Rule Them All syndrome.

    It was binary logging that thrust the first icy dagger of despair into my soul but the final, incontrovertible proof of ultimate and unstoppable Evil was visiting the homepage and being assailed with the incantation...

    ..."Follow us on Google+"

    1. tiger99

      Re: End of the world

      "It was binary logging that thrust the first icy dagger of despair into my soul..."

      Yes, it smells very badly of something that originates in Redmond or Cupertino, very bad indeed, and inevitably the cause of much future misery, as well as a proven route to bug-infested code of the type practiced by Gates and his gang.

      The technical success of *NIX since late 1969, 45 years now, is due in large part to the use of PLAIN TEXT for important things. Some time last year, that became a numeric success when the installed base of Linux kernels exceeded that of Windoze or any other OS (due in part to Android, also server farms, supercomputers, routers etc). Still growing....

      '..."Follow us on Google+"'

      I don't care that they use Google+. Some people take exception to it, but, just like the search engine, it is free and provides a useful service to many people. OK, it is not truly "free", it is funded by the cost of advertising on almost everything that you buy, but that is almost as fair as funding it from general taxation for the public good, like other basic services, which will never happen. Governments should fund other essentials like Wikipedia too.... However I have not seen flying pigs recently.

  22. Al fazed Bronze badge
    Thumb Up

    Mnay thanks to everyone posting

    Speaking as a relatively linux n00b of many years, I'd like to acknowledge that the posters here have made clear to me many of the archane things about Linux (and it's deviants) which previously eluded me, where reading man pages presents a massive wealth of complexity and attending forums is often like sticking my head up someone elses arse.

    Bifurcation, branching, forking, fucking hell ! BOLLOX !!!!!

    As far as the Linux desktop is concerned, (IMHO) unless I am prepared to pay for a distro that has human support in English on the phone, it is a none starter for me, as so many things that I want to do and that my clients want to do - on a daily basis, can't be done easily, or simply cannot be done at all. Using the BBC iPlayer being one of 'em.

    While the richness and diversity of the ever evolving application landscape is hearty stuff for developers, It's fucking well driving me insane, as I wade through distro after distro trying to find a working linux desktop that I can reliably recommend to my none computer literate students, who are either old, disabled, strapped for cash, or just really fucked off with the Microsoft and/or Apple softshit efforts available in the shops.

    Fortunately I read this article and the comments, which has convinced me of one thing that I guess I already knew really and that is, if I see that the vested interest is genuinely devoted to capturing punters wallets, then I can easily avoid the pitfall of tripping into a walled secret garden, or worse, sending an unsuspecting n00b in that direction. And conversely, if there's no money init (geddit) then I have to hope the damn thing has been given attention to detail and grown with love and care, rather than being bungled with a time schedule and budget.

    And for now I'll carry on using Debian etc to cover my arse, when I need to get some proper work done.

    Cheers.

    1. John G Imrie

      Re: Mnay thanks to everyone posting

      It's fucking well driving me insane, as I wade through distro after distro trying to find a working linux desktop that I can reliably recommend to my none computer literate students, who are either old, disabled, strapped for cash, or just really fucked off with the Microsoft and/or Apple softshit efforts available in the shops.

      Take a look at http://www.eldy.eu/

      1. Ole Juul

        Re: Mnay thanks to everyone posting

        . . . old, disabled, strapped for cash, or just really fucked off with the Microsoft and/or Apple softshit efforts available in the shops.

        I fit every one of those and FreeBSD works for me in that regard. And, as per your suggestion, I looked at the Eldy link. I grew up using a typewriter, and Eldy is just too far beyond my GUI skill level. As for your "none computer literate students", perhaps it would be a good idea to help them learn, rather than putting effort into dumbing them down. Old, and/or disabled, people may be smarter than you think.

  23. naive

    Just integrate systemd and /etc/init.d

    Having witnessed the demise of /etc/inittab, experienced headaches from the overly complex System VR4 replacement, the linux /etc/init.d is just brilliant, never understood anyway what was missing in /etc/inittab and a shutdown script to justify any change at all.

    There are many software manufacturers which use /etc/init.d scripts to start their apps, it would be optimistic of RedHat and Co if they expect they can change within one year.

    So why not integrate systemd: boot-->/etc/inittab-->systemd-->/etc/init.d, and the user can choose, like it should be with Linux.

    Software manufacturers can then ask the user during installation if they prefer classic /etc/init.d style or systemd startup.

    1. foo_bar_baz

      Re: Just integrate systemd and /etc/init.d

      RHEL 6 is supported until November 30, 2020.

      1. John Sanders
        Linux

        Re: Just integrate systemd and /etc/init.d

        RHEL 6 uses upstart, just saying in case you haven't noticed.

    2. John Hughes

      Re: Just integrate systemd and /etc/init.d

      Well, you don't get /etc/inittab (not that it usually contains much) but systemd is perfectly happy running stuff from /etc/rc?.d

  24. sawatts

    TL;DR

    Gosh what a controversial topic.

    Best sticking with the status quo.

  25. Pete4000uk

    I just use Debian...

    ...on my 10 year old laptop.

    All this goes over my head!

  26. Mage

    Inevitable

    Poor as the sysinit system may be, systemd is terrible. Not a step forward. Given the religious devotion on both sides a fork was inevitable. Eventually systemd will bear no relationship to today's version.

    This won't do anyone any good.

  27. Micha

    Hmm, well, I hadn't really heard of the debate before (despite being a long time Debian user), but this now explains why my desktop and laptop both refused to boot sometime earlier this year after a more or less standard upgrade (one runs SID, the other Jessie). Removing systemd on both got them working again. I just put it down to systemd being something new which was trickling in through unstable and wasn't really going into final production for years.

    I guess unless Debian manages to recover from this gaffe I'll be cross-grading to Devuan. The one great thing about *nix is that it's usually possibly to work out what's going on and fix it. Binary logs and opaque monolithic pieces of software are not conducive to that.

    Oh, and despite systemvinit, my machines boot up (to lightdm's login, yes, I ditched Gnome when the Gnome3 abomination was enforced) quicker than the BIOS POSTs complete, so I'm not sure there's much that can improve on that.. but yes, they both boot from SSD's. Still, so does Windows 7, and that still takes half an age despite all the boot time optimisations which have apparently been put into it.

  28. phil 27
    Stop

    Gentoo is another one fighting against the tide on this.

    I have been using linux and doing it for some household name companies amongst other flavours of unices since the 90's, and systemd represents a lot of thinking I don't want to see in my systems. Just read the rants in here, they have most of them off to a pat, and we've already seen some of them in action (corrupted binary logs etc). Nobodys mentioning the potential vulnerabilty of having a monocultural monolythic binary handling pid0 with absolute privileges and how it will massively increase the attack target having one big spaghetti monster of a daemon hacked together by people in a hurry to dispose of the alternatives, but its lurking at the back of my mind.

    For a good many years I ran gnome because I didn't at all like the way qt was licensed back in the trolltech early days but now I have switched all my boxes to kde/enlightenment wm, installed eudev to stop udev shimming in any badness, and hard masked systemd from my systems.

    I don't want binary logs that require a additional daemon to convert everything into clf or similar format logs to feed into the traditional logging and management system infrastructure set up at every company, I dont want to get a mangled log and find the remnants on the partition after the platters been rebuilt in a clean room into a new chassis but was more borked than we thought and not be able to read even fragments (we have used this in the past), I don't want to be trying to comprehend and dig round in systemd's sourcecode when its suspected of being behind a weird issue because once things disapper into that monolithic blob that is what it may end up being ("Open a ticket", please, the server is dead now and its costing us big time, we have to fix it there and then not palm it off to a vendor), or have issues with a system that wont come up and needs hand fettling to bring it back up enough to rescue and my desktops boot fast without it because they're full of the magic of ssd's. All with the magic of openrc, which solves some of the very same problems systemd was supposed to with dependancies, but somehow manages not to turn the os into windows for unix. I've even wrestled with the odd start up script bug and won.

    So, right in my gentoo use config I have INSTALL_MASK="/usr/lib/systemd/" , its about choosing to have the os the way I want it. Linux has been, and always will be about choice for me.

    Now you may want a "modern" linux with systemd, but some of us greybeards chipped in to make linux what it is today, and out of every one of my skilled collegues, the talk is all of moving to freebsd or similar. Interesting times are ahead.

    Pity about gnome until gnome3, but E17 is pretty nice nowadays.

    1. John Hughes

      So, right in my gentoo use config I have INSTALL_MASK="/usr/lib/systemd/" , its about choosing to have the os the way I want it. Linux has been, and always will be about choice for me.

      So in your Debian config just create a file /etc/apt/preferences.d/no-systemd with the contents:

      Package: systemd-sysv

      Pin: release o=Debian

      Pin-Priority: -1

      Debian and Gentoo are pretty similar when it comes to systemd -- it's one of the possible init systems. On Debian it's the default, but is seems many people have forgotten that if something is the default then by definition there are alternatives.

  29. Chris Evans

    Debian R.I.P. Best alternative?

    If this is the beginning of the end for Debian and Devuan doesn't get enough traction to be a viable alternative what is the consensus on the best alternative?

    1. Trevor_Pott Gold badge

      Re: Debian R.I.P. Best alternative?

      "If this is the beginning of the end for Debian and Devuan doesn't get enough traction to be a viable alternative what is the consensus on the best alternative?"

      Prayer.

      Slack and Gentoo are both probably going to succumb int he next year or two. The BSDs are moving to launchd, which shares many similar issues with systemd.

      If Devuan fails, we're pretty fucked.

      1. MustyMusgrave
        Meh

        Re: Debian R.I.P. Best alternative?

        You know what's happening here dont you trevor?

        This corruption in the source is all coming from one direction....

        The corperate monopoly, RHEL is a monopoly, they're fork Fedora charges you to use a Codec to play an MP3, ie: You have to buy the Codec's to play a bit of Music, kind of why I've never liked Fedora..

        Then when it comes to FreeBSD well there code base went into Apple's products, so DRM?

        Then we're got Mr Shuttleworth and Ubuntu and his desire to see Ubuntu One everywhere, spying on us all for Amazon's benefit! I've tried Ubuntu shortly after I tried Fedora, I wasnt too impressed with Upstart & AppArmor leaving SSH vulnerable by default, because someone didnt set the permission's correctly and I had to edit those by hand!

        Then we've got Debian with System V which has always been a great OS for server & desktop until suddenly for some reason the Debian Multimedia source's got pulled, so again you cant listen to your music or play a DVD because the Debian communities argument is some of it's proprietary?

        Since when has VLC been proprietary?

        Now we get to see the foul corruption spreading it's wings, into everything, suddenly Ubuntu gets SE_Linux, Debian get's SE_Linux, Fedora's always had it... But mark my word's Gentoo will be next!

        You do have to wonder about what happened to the Unix philosophy of "Do one thing & do it well!"

        grSecurity with PAX controls keep cyber-fuckwit's like the NSA out of your Box!

        Clearly they didnt anticipate the power of other peoples Greed, fucking up years of everybody else's life's work for the sake of Money & the chance to make a few quick bucks selling the entire internet into the hands of a few 20 year old soldiers with a raging hard-on to have a cyber-war oh and if you dont believe that's true, I've got photographs of Jared Cohern in a room full of NSA recruits!

    2. ElReg!comments!Pierre

      Re: Debian R.I.P. Best alternative?

      what is the consensus on the best alternative?

      For now it's Devuan. Why are you trying to jump to the "next best thing" when the first best thing is still in the incubation phase? If everyone skip it "because it may not get traction", Devuan will never get the traction it needs. On top of that, switching to Devuan will just be a dist-upgrade-like process, why would anyone actively research a more painful way to avoid systemd?

  30. Doctor Syntax Silver badge

    My take on all this

    Systemd looks set to bring me problems I don't need to solve problems I don't have.

    It intends to replace all manner of things that have been working well for a long time for no more apparent reason that its authors want to. What's more, when I read things such as the claim that the new udevd can be installed without systemd, it just can't be built on its own I realise that, whether by conspiracy or cock-up, the source code is clearly a hairball. That's one black mark. The fact that at least one of their developers have been on the receiving and of a bawling out by Linus on code quality underlines that. (And really Linus's bawlings out don't seem to be all that frequent, just highly publicised.)

    The notion that the standard logging is binary is another black mark. It's akin to shipping binaries without source; I'm amazed the whole FOSS community hasn't descended on them for that. Maybe they've escaped on the basis that they allow additional text logging. I'd have to trust them that if, one day, that should happen to break, they'll fix it but I'd have to check their history of responding to bugs.

    Then there's the position on start-up scripts. I know there seems to be a fashionable aversion for scripting languages invented longer ago than the day before yesterday. Nevertheless anyone who is administering serious Unix-type systems should have some familiarity with shell scripting. It allows arbitrarily complex operations to be performed, .ini style languages not so much. Again, we are allowed, at present, to use scripts in addition to the default .ini approach. For how long? Until there's no going back?

    With Debian falling in line I fear there will be little to inhibit devs for all manner of stuff simply assuming that systemd will be there and including it or one of its relatives as a dependency. It will gradually become more and more work to maintain a non-systemd fork. In short, I think the Devuan fork is built on optimism and will become unsustainable on a voluntary basis within a Linux ecosystem within a few years.

    Red Hat may be able to sustain their pre-systemd distro for a good while on a commercial basis. Alternatively, having seen off the last major non-systemd competitor in the server world, they'll be able to discontinue it any time they like once their contractual obligations expire.

    In the meantime, it looks like many of us will be switching to BSD.

    1. rtfazeberdee

      Re: My take on all this

      Where have you done your reading? Forums like this? Try reading up about systemd at the freedesktop site and check out some presentations online , you'll then find out that you can also have text logging, run scripts as normal etc. You are falling victim to ignorant posters who regurgitate crap from other ignorant posters

  31. Jim 59

    systemd almost appears to be malevolent. It sees other parts of the system not as things to be cleanly interfaced with, or even managed, but as elements to be ignored, replaced, dominated. It even seems to regard systems administrators with contempt. Who is behind systemd ?

    In recent years, the Gnome devs' main achievements have been to take the leading Linux desktop and turn it into an irrelevant basket case, and to take the no.1 distro and make it a distant no. 2, and to antagonise the devs in other projects, including Linus, and to acquire a reputation for bad design and bad programming.. Are these the kind of people you want running around in your core OS ?

  32. Anonymous Coward
    Anonymous Coward

    Why?

    To add to this - from what I read no way is systemd coming on my systems (Slackware).

    I just timed my lowly notebook (1.66 atom) - 20 seconds to login prompt and after logging in, 10 seconds for X to start manually. What is a few seconds saving off of that? My raspberry Pi running Slack* boots even quicker - maybe 15 seconds. My amd64 server takes about 30 seconds. So what advantage there?

    Also the rc.d scripts are so powerful, I can do what I what to a starting system - it is so easy to knock up you own service and run at boot - and everything just *works* forever.

    And there is one question I haven't seen asked. At the moment, if I cock-up a rc.d script (a typo perhaps) that stops the system booting, I can just use a live CD (or the like), bring up the box, mount the /etc partition, correct the typo, and it's *fixed*. What happens with systemd when it fails to boot - is it as easy to fix as that, or do you have to start farting about with mounting partitions and chrooting stuff?

    No thanks to systemd - and if Pat does integrate it into a future Slackware release I will just stick with the last version not to use it - I already update a lot of my stuff from source anyway (including latest stable kernels), so keeping it secure will be no issue.

    *I put Slack on it ( http://rpi.fatdog.eu/ ) as I can't stand Debian derived Distro's anyway.

    1. Charlie Clark Silver badge

      Re: Why?

      just timed my lowly notebook (1.66 atom) - 20 seconds to login prompt and after logging in, 10 seconds for X to start manually. What is a few seconds saving off of that? My raspberry Pi running Slack* boots even quicker - maybe 15 seconds. My amd64 server takes about 30 seconds. So what advantage there?

      Not disagreeing with you, but imagine the potential difference when regularly starting thousands of VM where time literally is money. Certainly an incentive to have things go moar faster there.

      Pretty certain another boot manager isn't the solution in that case which possibly why Docker is getting so much interest.

      1. BitDr

        Re: Why?

        Starting THOUSANDS of VMs? For who? If you're talking computing as a service then forget about it. Why the heck would rely on someone else and get in the blame-throwing game when problems inevitably arise? My servers, my VMs, My Data, My Business. When you work for me your VM it is spun up 24/7/365 with backup servers at the ready should things go south.

        1. Anonymous Coward
          Anonymous Coward

          Re: Why?

          My thought exactly. Who needs to start/restart thousands of VMs often enough that a few seconds added to boot time is going to make that much difference? Who really benefits from systemd?

    2. John Hughes

      Re: Why?

      I put Slack on it ( http://rpi.fatdog.eu/ ) as I can't stand Debian derived Distro's anyway.
      So you are well qualified to comment on Debians default choice of init system.

  33. Gary Bickford

    Trying to make complexity disappear by adding another layer is a classic error ...

    ... and that is what systemd appears to be trying to do, from my very limited reading.

    From my perspective, there was a time, long ago, when a problem with booting or system configuration could be fixed by either editing a couple of conf files or in extreme cases editing or shuffling init scripts. That was the original unix model (mostly BSD?) The SysVInit model actually made things more complicated and difficult to figure out. Since then various attempts have been made to 'simplify' maintenance, but in order to support a GUI or even a Curses program, the configurations had to become more complicated, with configuration-modifying program configurations. It's been 10 or more years since setting up networks, especially dialup and later wifi, become so convoluted that it was impossible to figure out what was going wrong without climbing the learning curve of yet another system containing a dozen or two scripts/programs. Today it's basically impossible to get wifi running unless the fancy GUI NetworkManager magically happens to work. If it doesn't, one has to just resort to suspending, or in severe cases restarting, the laptop and hope that it discovers the wifi by itself.

    As anyone who started out doing simple HTML with a few .SHTML or CGI scripts, then migrated to early PHP, then to CRMs and frameworks written in PHP, these are just layers of complexity that get harder and harder on which to achieve any level of expertise. No sane person could argue that working with Drupal is less difficult than writing native PHP. (Granted you get more built-in tools.)

    Upstart was another attempt to 'simplify and automate' booting, but really just put another layer of crapola (scripts and configurations that interact in mysterious ways) between the system and the user/maintainer, and remove more information from visibility. So without delving into this issue myself, I'm becoming more and more likely to revert to an old-school distribution, and build it myself.

    Bottom line analogy - I don't want to have to relearn how to drive yet again, as every piece of software seems to insist on moving all the knobs and wheels to different places and hook them up differently. Imagine if every two years your car's dashboard and engine controls were moved to random places, and you _had_ to update or else your car couldn't go on the freeway - that's what has been happening in IT for way too long. Funny thing - I could drive a 1946 Ford on the freeway today, and while it might not be as safe or as fast or as comfortable, it would work just fine.

  34. mrscott1337

    It's all about CHOICE

    My problem with systemd lies in the lack of choice available to people regarding it and to me, the whole thing just flies in the face of everything that I've always loved about Linux. If I was happy with simply accepting whatever software gets fed to me, I'd still be using Windows as my primary OS.

    Fair enough systemd might make things faster, but I don't see that as any reason as to why it's practically being forced upon everyone who uses a desktop-centered distribution. Why can't distros just do what Gentoo does and give people the option? Giving people choice won't kill anyone.

    Good on the Devuan people for actually listening to users instead of just shouting down at us that we don't know what's best for us.

    1. John Hughes

      Re: It's all about CHOICE

      My problem with systemd lies in the lack of choice available to people regarding it

      What lack of choice? If you don't want systemd then just install sysvinit (or upstart if you prefer).

      I cannot understand what this shouting is all about.

      Some people will say "but one day every package will depend on systemd". So I guess they've already given up and I don't known why they're still complaining.

      If some package you want depends on systemd then you have two possibilities:

      1. give up using it

      2. fix it to remove the dependency. (or make some kind of "systemd-shim" that resolves the dependency.

      These two choices are the only choices whether systemd is the default Debian init or not.

      1. Anonymous Coward
        Anonymous Coward

        Re: It's all about CHOICE

        You miss the point - if a.n.application is deliberately coded to need systemd, then the battle is lost (you might rely on a.n.application, so now you *have* to use systemd with all the other woes it brings).

        What should be happening is that systemd is a *choice* and people/users can choose what they what to run without buggering up anything else- not have it shoved up their noses.

        1. John Hughes

          Re: It's all about CHOICE

          if a.n.application is deliberately coded to need systemd, then the battle is lost

          1. That application is gummiboot(*). No, I've never heard of it either.

          2. What does that have to do with Debians choice of default boot system?

          Say Debian chose upstart as the default boot system. Would that make gummiboot work without systemd? No.

          systemd is a choice in Debian. It is even a choice in Devuan! But neither of them will be able to use gummiboot without systemd.

          Unless someone patches gummiboot to not depend on systemd.

          For this we needed a fork?

          (* Yes. The only application in Debian Jessie that depends on systemd with no alternative is gummiboot)

        2. rtfazeberdee

          Re: It's all about CHOICE

          so, go to the application author and ask for a non-systemd app.

      2. mrscott1337

        Re: It's all about CHOICE

        >What lack of choice? If you don't want systemd then just install sysvinit (or upstart if you prefer).

        You should know it's not as simple as that. Yes it'll work for the time being but as updates move on, anything but systemd is getting left behind on the distros that choose systemd as default init system.

        >I cannot understand what this shouting is all about.

        It's not shouting, it's just a bunch of people who are rightly annoyed with everything that's surrounding systemd and the way that it's adoption is being forced upon users (or as much as you can force anything in the FOSS world).

        >Some people will say "but one day every package will depend on systemd". So I guess they've already given up and I don't known why they're still complaining.

        That's not giving up, that's recognising the serious problems with systemd attempting to assimilate everything and that alternatives need to be made. Hence we have Devuan.

        Debian's default init isn't simple a choice that a user can make in the long term by uninstalling and installing certain software packages, it's a choice made by the distro maintainers and other developers as to what software is going to be supported in the long run and what's going to get left behind. Using sysvinit and systemd-shim is just a hack that will only work in the short term, we need a long term solution like Devuan that simply doesn't incorporate systemd into it's design so that systemd is unable to incorporate everything else into itself.

        My point still stands; that providing choice to users a la Gentoo, won't hurt anyone and will only please everyone apart from Poettering and his religious following. And honestly, the more people that get needlessly defensive about any criticism of systemd, the more reason I see to get rid of it.

        1. John Hughes

          Re: It's all about CHOICE

          Using sysvinit and systemd-shim is just a hack that will only work in the short term,

          No, it is a choice that will work if the people who feel strongly about it will do the work to make it work.

          If Debian decided to use upstart would that work magicly not need to be done?

          My point still stands; that providing choice to users a la Gentoo, won't hurt anyone and will only please everyone apart from Poettering and his religious following.

          In what sense does Gentoo provide more choice than Debian? They both allow users to run systemd, sysvinit or upstart as the init system(*)

          Hell, even Devuan are promising that systemd will be available.

          (* I think Gentoo also allows OpenRC)

          1. Havin_it
            Boffin

            Re: It's all about CHOICE

            >In what sense does Gentoo provide more choice than Debian? They both allow users to run systemd, sysvinit or upstart as the init system(*)

            >(* I think Gentoo also allows OpenRC)

            Nope. Gentoo uses sysvinit and openrc (lest we forget, init and rc are, historically, complementary but separate components). AFAIK they are both part of the base system. What has now changed is that systemd is supported (via a USE flag), but it is not and is unlikely to become the default, given that openrc is largely a Gentoo project (and regular polls in the forums have swung overwhelmingly against systemd).

            Upstart? Not packaged (although I see it can be installed via the "chromiumos" overlay, lol).

            So Gentoo's actually less "all things to all men" in this regard. More pragmatic though, I think.

            1. John Hughes

              Re: It's all about CHOICE

              Notice also that Gentoo doesn't provide systemd-shim, so if you want to use Gnome 3 you have to use systemd.

              So Gentoo has two packages that depend on systemd (Gnome3 and gummiboot). Debian has only one.

              Starting to feel that Debian offers more choice than Gentoo, :-)

      3. Anonymous Coward
        Anonymous Coward

        @John Hughes - Re: It's all about CHOICE

        "give up using it" - that's exactly what I understant by lack of choice. Don't you?

      4. JEDIDIAH
        Mushroom

        Re: It's all about CHOICE

        The whole "just use the shim" remark only proves his point. If systemd weren't about assimilating the rest of Linux like the borg there would be no need for any "shim". There would just be a sanely designed init system with sanely designed userland services surrounding it.

        However we don't have that. What we have is one big entangled mess being pushed on everyone because someone happens to be the fattest lardbutt in the room.

        GNOME pushing this mess? No big surprise, they already jumped the shark quite badly and demonstrated their lack of trustworthiness.

  35. Anonymous Coward
    Anonymous Coward

    Good discussion/a couple of ways forward

    Maybe the time has come to fork the desktop and server in Linux. The needs of each have been diverging for a long time. Sure, systemd is a key component of both Docker and cloud distros like CoreOS. Its "black box" approach to setting up and running services and interacting with the underlying system is suited to turnkey server platforms. But those of us who have been general purpose server admins for awhile have all experienced the frustration of working around services and software that, while they may be key to a better desktop experience, just get in the way on a server (e.g. NetworkManager). Why put us through that just so Ubuntu can make its play in the handset market, Steam can take over the gaming world, or Gnome subsume Android and OSX on tablets?

    Of course, if no distro comes forward and provides the option of a reasonable server implementation there's always BSD. I doubt the learning curve for Linux server admins to master one of the (extraordinarily well-documented) BSDs would be any steeper than adapting to systemd, so long as the process was approached with humility and open minds.

    1. Anonymous Coward
      Anonymous Coward

      Re: Good discussion/a couple of ways forward

      I experimented with a BSD a few years ago - the only things I sort of had to learn was the different partition names on discs and the scripting firewall syntax - everything else was pretty much the same.

      1. watkin5

        Re: Good discussion/a couple of ways forward

        Systemd has also made me consider trying BDSM

        1. Havin_it
          Gimp

          Re: Good discussion/a couple of ways forward

          >Systemd has also made me consider trying BDSM

          I'm starting to think systemd is BDSM.

    2. ElReg!comments!Pierre

      About switching to BSD

      It's made even easier by the existence of aBSD-based Debian port, which I have dully installed, for 2 reasons: it is (obviously) systemd-free, so running it (with popularity-contest) puts some weight behind the systemd-sceptics; and it helps me getting familiar with BSD, in case everything goes very bad and I need to make the switch.

      1. John Hughes

        Re: About switching to BSD

        The Debian/kBSD port also proves pretty conclusively that systemd is an optional part of Debian.

        It is, however, a pretty poor way to learn BSD. You're not using the BSD init system for example :-)

    3. John Sanders
      Facepalm

      Re: Good discussion/a couple of ways forward

      "Back box", you keep using that term, I think it doesn't mean what you think it means.

      Specially not with GPL v2.1 licensed software.

  36. sisk

    The Debian community has changed pretty significantly in the ten years that I've been a part of it (this wouldn't have even been a debate 10 years ago), but I can't imagine it's changed enough for the people opposed to making systemd part of a stable release a minority. It's not ready for prime time. It's as simple as that. It used to be that the Debian community as a whole would have understood that without even talking about it. It might have made it into the testing branch for a while before coming back out when the problems emerged, but more likely it wouldn't be out of sid, or maybe even experimental, yet. The change from hotplug to udev took quite some time, as it should. There's absolutely no reason for a change to systemd, if it's even necessary, to move any faster.

  37. tekHedd

    Because Gnome depends on it?

    We need this because Gnome's flashy features depend on it? But I don't even care that much for Gnome... what a waste of everyone's time.

    1. MustyMusgrave

      Re: Because Gnome depends on it?

      No, Gnome 3 doesnt depend on it at all, in fact SystemV run's gnome perfectly fine with out SystemD..

      But I could well imagine we would aquiest to SystemD and then later on we find Java in Gnome like Java in Droids!

      I dont even use the Linux or Unix standard UUID's if I run X...

      So that's that little spying gem of an idea out of the windows! eh!

  38. asdf

    Best said by Paul Venezia

    "...systemd is becoming the Svchost of Linux -- which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system -- from authentication to mounting shares to network configuration to syslog to cron."

    1. asdf

      Re: Best said by Paul Venezia

      "It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes. No matter which side of the argument you're on, this monolithic approach is in violation of the rules of Unix, specifically the rule stating it's best to have small tools that do one job perfectly rather than one large tool that is mediocre at performing many jobs. Prior to this, all the functions subsumed by systemd were accomplished by assembling small tools in such a way that they performed the desired function. These same tools could be used within a variety of other scripts to perform myriad tasks -- there was no singular way to do anything, which allowed for extreme freedom to address and fix problems.

  39. asdf

    FYI

    Recently switched to PC-BSD 10.1 on the desktop. If you are a Unix nerd and don't use cinnamon, BSD is now viable for everything but wine games (wow is wine buggy on BSD and so is cinnamon, but long live xfce with the whisker menu). There is a bit of work involved migrating for most use cases but the fact I am immune from the systemd cancer made it worthwhile for me. Discovering the delight that is ZFS has been a very nice bonus (best FS for *nix, Linux, and Mac OS interoperability, and data migration imho). Now hopefully the Red Ass Hats won't succeed in making too much OSS non portable.

  40. Anonymous Coward
    Anonymous Coward

    So familiar - it will come to me any minute now

    systemd - Embrace existing functionality, Extend dependencies, Extinguish other choices ..... hum .... I swear I've heard this somewhere before?

  41. Anonymous Coward
    Anonymous Coward

    Kids! Kids!

    That's a lovely flamewar here, all 4 pages of it, but you're all missing the point.

    Systemd is a GPL circumvention tool.

    Yeah. Really.

    Remember the difference between LGPL and GPL? The one about linking? If you link to GPL code, your code must be GPL. If you link to LGPL (lesser GPL) code, you don't care. Proprietary shops love LGPL because they don't owe you shit if they link to code licensed like that.

    What has systemofad to do with it? -- I hear you ask.

    dbus/kdbus.

    The moment RedHat has its way and plonks dbus in the kernel space the performance difference between linking and dbus RPC will be... academic. Especially on 4GHz server CPUs. Dbus allows binary data _and_ function calls to flow freely. As {,k}dbus will be GPL, your precious little GPL_ONLY_* symbols will be hooked to legally, but every dbus-using shmuck will be able to call those as Remote Procedure Calls which are explicitly exempt from GPL restrictions.

    Here. You didn't see that coming? Were we all foaming at mouth that tiny little bit too much on both sides? Liked your greybeard bash scripts? Loved the 'integration' of hitlerd?

    Well, too effing late. You blinked. You missed it. GPL is done for and our dearly beloved Rev. Stallman can't do anything about it any more. RedHat has won.

    We lost. It's like 400ppm CO2. The crash has already happened. No point deploying the airbags now. Systemd is everywhere and there is no sustainable way around it.

    Go get that MCSE, kids. You'll need it. Grab a RHCSE while you're at it.

    1. asdf

      Re: Kids! Kids!

      Wow nice catch. Friggin Red Ass Hat.

    2. PushF12

      Re: Kids! Kids!

      Good point. Red Hat wants to bundle ZFS on Linux with RHEL -- and then sell all of the enterprise stuff that runs on ZFS -- and this is one way that they can do it.

      1. John Hughes

        Re: Kids! Kids!

        Do you seriously think Redhat is going to release a system where you access the disk via D-Bus?

        What do you think they are, Tandem or something?

    3. MustyMusgrave
      Devil

      Re: Kids! Kids!

      Oh I didnt miss it, some did, some didnt... It's akin to the lot of them going well firefox is still Ok, firefox is not Ok, firefox hasnt been Ok, since Mozilla started intergrating everything to do with Google inside of it..

      Oh look here's Jared!

      https://imgur.com/lZ29XtI

      I think what the System V dev's are driving at which the System D dev's havent figured out yet, is they're saying - No BLOB!

      https://imgur.com/GELB8jZ

      https://imgur.com/Fe5tSPY

    4. John Hughes

      Re: Kids! Kids!

      Yay! Another paranoid fantasy with no substance, just what we need.

      1. MustyMusgrave
        Joke

        Re: Kids! Kids!

        @John Hughes

        Maybe if you follow the Links you'd find the substance!

        The developer community is only to well aware of what Google and it's partners in buisness are trying to do with those ARM and OMAP chips... See SysV can't interact with the binary BLOB so it's darkness with no light, but along comes another binary solution and presto!

        "Maybe if they've got something to hide they shouldnt be doing it in the first place!"

        As they say they're are many eye's in the open source world, its a global community not limited to 5 nations around the world, but spanning the GLOBE... When the harmonious discord is broken by a few money grabbing shy-locks then yes, the Global community rise's up in Wrath!

        Hell hath no fury like a load of old developers scorned.. If a guy with grey hair and a beard say's you shouldnt do that, you'll cause outrage around the world then perhaps people should heed a few perls of wisdom from a senior generation that knows what they're talking about!

        1. John Hughes

          Re: Kids! Kids!

          Hell hath no fury like a load of old developers scorned.. If a guy with grey hair and a beard say's you shouldnt do that, you'll cause outrage around the world then perhaps people should heed a few perls of wisdom from a senior generation that knows what they're talking about!

          Oh for fucks sake.

          I am 55 years old. I have grey hair. I started programming on an ICL 1903T in Fortran and Algol68 using punch cards. I've been a Unix sysadmin since 1991. I've fixed bugs in UnixWare(*), gcc, gdb, bash, linux, sysv init scripts...

          A bunch of wet behind the ears PFY's claiming to be "veteran unix sysadmins" doesn't impress this BOFH.

          (* which involved building a ISA card to force an NMI when I pressed a little button, letting me get a crash dump from a system that would always freeze around 4am, and then disassembling the X.25 drivers to find where there was an off-by-one error in the handling of the user-data field. Amazingly about 20 years later I found almost exactly the same bug in the Linux X.25 drivers.)

          1. John Sanders
            Unhappy

            Re: Kids! Kids!

            John,

            Its no use, systemd its going to eat their server babies and there is no way to convince them otherwise.

            This is beginning to resemble modern politics in which facts do not matter anymore all that counts is people's perceptions.

            It can not be that systemd is trying to accomplish something technically difficult and that always implies a certain conflict and having to learn stuff (some times the hard way)

            Also it can not be that what has been agreed is that systemd is the default choice in Jessie, but it was also agreed that in Jessie+1 it will be optional, it is not optional now on Jessie due to time/resource constrains.

            No, it is none of that, it has to be a Red Hat Conspiracy of some sort!!!! Don't you see!

            I can understand now why some of the Debian developers resigned. :-(

          2. MustyMusgrave

            Re: Kids! Kids!

            Ah, so your like me then a old fart who can no longer find his own shrivelled dick!

            Yeap, I was right BTW I just installed debian and watched it bundle in Java.. From we want to vibrate in your arse Oracle.. You know we're all getting too old for this shi*

            I could care less about Oracle and it's Java scriptin application, but what interest's me is the REALM..

            ie: Plan-B from the Bell-Labs.. or Plan-9.. Why 9 service providers involved in a scheme of steal it all.. ahh

            Jews & Money my friends.. Jews & Money! Bildenburg Group.. sigh.. too old for this shi*

            How long do we have to be subjected to there vision of heaven? When all those chaldee should be rotting in Hell..

            Hey Loookie ---> t3h senior Dev lives @ 666 mountain view california, lets go ask the old cu**

  42. Anonymous Coward
    Anonymous Coward

    I like the good old days of S:startup-sequence or even autoexec.bat those linuxy people make everything so bloody complicated. Too bad BeOS went nowhere...

    It's just starting a bunch of services how difficult can you make it?

    1. asdf

      I'll take the bait

      If systemd kept to only starting services at boot up there wouldn't be 5 pages of comments.

  43. -tim
    Boffin

    Redoing the past the hard way?

    The names and run level fields in the system V inittab are there for a reason. The idea was to allow dependency issues to be resolved. The S## were supposed to be sorted numerically and then each with the same number are supposed to be run in parallel but somehow that code was reduced since rc1 etc were shell scripts.

    Some of these concepts were around on the SysV development platform, the AT&T 3B5 or its phone switch cousin in the early 1980s.

  44. TheOldFellow

    This has more to do with egos, including mine, than technology. I'd prefer not to have anything written by, or influenced by, Poettering because I don't like the way he operates. Same goes if Seivers, and a number of others.

    My love affair with UNIX started back in the 1970s, after reading Kernighan and Plauger: Software Tools. The elegant way the tools fitted together, each doing just one thing really really well, but combining to be tremendously powerful, was entrancing.

    All this died with Linux really, because the Kernel has become one enormous monolith, if Hurd or one of the other micro-kernels had succeeded we could have been in a better state. Yet systemd is a terrible init scheme, and I rebel against binary logging, but it's in the same stable as Linux (and Android, OSX, and NT) - monolithic. I hate monoliths (as Kubrick demonstrated).

    TOF.

  45. Jim 59

    "Devuan"

    Small point, but, from the Devuan web page:

    Devuan is spelled in Italian and it is pronounced just like "DevOne" in English.

    Not in England. Here, it would be pronounced "dev-view-an". They should have chosen a name pronouncable outside of the US. Also, what's with the web page, it has the look of a 1990s gaming forum. I will be contributing anyway, and good look to 'em.

    1. ElReg!comments!Pierre

      Re: "Devuan"

      I think you misread the sentence. It's supposed to be written in Italian (Spanish would work, too), so it's pronounced like dev-one would be pronounced in English, devoine in French, dewoan in German etc.

      Not that it matters much, as long as it's good.

      1. Adam Inistrator

        Re: "Devuan"

        more likely to be a deliberate shift left of the IA to be UV on the keyboard I surmise

  46. g00se
    Linux

    A very tight and scholarly essay

    http://judecnelson.blogspot.co.uk/2014/09/systemd-biggest-fallacies.html

  47. jb99

    Debian is dead

    Like many people, if debian starts to use systemd then it's dead to me.

    We might as well use windows if stuff like this gets forced on us.

    1. John Hughes

      Re: Debian is dead

      Like many people, if debian starts to use systemd then it's dead to me.

      We might as well use windows if stuff like this gets forced on us.

      Debian has had systemd available since Wheezy. I guess you think Debian died May 4th, 2013.

      systemd will be the default init system for Jessie.

      Please ponder the meaning of the word "default". If something is a default that implies there are alternatives.

      In fact the alternatives are sysvinit, the default init system for Wheezy, and upstart, the init system used by Ubuntu and RHEL 6.

      There is exactly one package (out of around 45000 or so) that depends on systemd, It is called gummiboot. If you want to avoid systemd I would recommend not using gummiboot. Personally I'd never heard of gummiboot before people's continuing whining about packages that depend on systemd drove me to see if I could find what they were.

      1. Adam Inistrator

        Re: Debian is dead

        that no packages are dependent on systemd surely tells you something about systemd

        1. Anonymous Coward
          Anonymous Coward

          Re: Debian is dead

          One dependency? Maybe on Debian but on my brand spanking new OpenSUSE 13.2 install, rpm is telling me that there are 86 packages that depend on systemd. And I didn't even perform an "aw hell, just give me everything" installation.

          I foresee the day when, default or not, systemd is the only way to install Linux. On a somewhat related note, it reminds me all to much of the way CUPS insinuated its way into many distributions as THE printing system. Want a word processor? Well, you'll need a way to print, right? So you need CUPS. Not an alternate printing subsystem like the venerable lpd or even LPRng. CUPS and only CUPS. Choosing anything else would force you to deliberately break the dependency leaving you to wonder if you've created the conditions whereby some future printing problem is going to be due to your deciding to use an alternate subsystem.

          There's a difference between "having a choice and actually being able to make a choice" and "having a choice but if you know what's good for ya, you'll select what we want you to". The way things seem to be headed, we're being corralled into the latter.

    2. Anonymous Coward
      Anonymous Coward

      Re: Debian is dead

      I agree and find this disturbing as two of my favourite distros are very light small distros that I would e very surprised have the resources to avoid systemd, (tinfoil hat time) which appears to be a plan to crush the computing freedom that Linux has traditionally provided.

  48. phuzz Silver badge
    Trollface

    /me passes the popcorn round to the other windows admins

    1. John Hughes

      popcorn

      Just you wait, Lennart's next plan is to port systemd to Windows. You'll soon be laughing on the other side of your face.

      1. ElReg!comments!Pierre
        Coat

        Re: popcorn

        The Big War of the Ugly Monolithic Blobs! I can't wait to see what systemd looks like after it has swallowed the whole of Windows "to increase boot speed"! Yo dawg, I heard you like blobs so we put a blob in your blob so it can catastrophically crash while it freezes! And all that sort of things.

  49. Pirate Dave Silver badge
    Pirate

    Problem?

    " 'Doesn’t include systemd' is not a real problem.”

    No, it's a solution to a solution that was looking for a problem.

  50. MustyMusgrave
    Windows

    pfft... re: Kids Kids

    oh look i got thumbs down because I was too out-spoken about OMAP and ARM.. Made in texas kid's made by the same twat that declaired war in the gulf so long as texaco got rich!

    War criminals they come in all guises, some of them are Jewish.. an they hate arabs, some of them are islamic like Malcom X so they put a black man in the white-house...

    Sigh, as time goes by you'll learn all about who the real threat to humanity is.. It's called Man-kind..

    Disease that spreads across the earth looking to take over everything - yeap that's you!

    Then the service providers lie about the final plan because its like Hitlers final solution, if you knew the truth, youd have told them to shove that blue pill up there arse a long time ago!

    LoL

    1. MustyMusgrave

      Re: pfft... re: Kids Kids

      Here's a history lesson for you kids, Unix came out of AT&T the Telephone company...

      Have you ever heard of the Bell-Laboratories picture phone?

      Do you really believe that what you have in front of you, right now, is a personal computing device?

      Interesting!

    2. John Hughes

      Re: pfft... re: Kids Kids

      oh look i got thumbs down because I was too out-spoken about OMAP and ARM..
      No, you got a thumbs down because you're a raving loon.

  51. pyite

    This is a legitimate complaint

    If Ubuntu's totally disastrous experience with "upstart" is anything to go by, the Devuan complaint about systemd is quite reasonable.

    Upstart has ruined Ubuntu Server. Due to inexplicable boot problems it has not been an acceptable server platform starting with the day that 10.04 came out. Some applications (e.g. OpenStack) work better with Ubuntu so sometimes it is acceptable, but without such a compelling reason it is total insanity to use Ubuntu Server.

    I have been extremely wary of systemd due to how terrible upstart is. If they designed it so it's easy to make a guess about the boot order and write out sysvinit compatible S/K boot files, then it may be an acceptable alternative. Otherwise, when the time comes I'll upgrade my Squeeze server to Devuan instead of a newer Debian release.

  52. This post has been deleted by its author

  53. This post has been deleted by its author

  54. Anonymous Coward
    Anonymous Coward

    possibly out of the Devuan developers scope or desire

    but a good way to get users interested in moving to Devuan would be to build a light weight distro similar to #! (CrunchBang, presently a Debian based distro). Possibly use JWM as the windows manager. Build it for both i486 and amd64 based architectures.

    I think that would draw some very positive attention to the Devuan project.

    I use #! on my old laptop and it works beautifully.

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