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 …

Page:

  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

        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 Silver badge

              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

          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 Silver badge

          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.

Page:

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