Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Linux

Choose Your Side On the Linux Divide 826

snydeq writes The battle over systemd exposes a fundamental gap between the old Unix guard and a new guard of Linux developers and admins, writes Deep End's Paul Venezia. "Last week I posted about the schism brewing over systemd and the curiously fast adoption of this massive change to many Linux distributions. If there's one thing that systemd does extremely well, it is to spark heated discussions that devolve into wild, teeth-gnashing rants from both sides. Clearly, systemd is a polarizing subject. If nothing else, that very fact should give one pause. Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition. It indicates that no matter how reasonable a change may seem, if enough established and learned folks disagree with the change, then perhaps it bears further inspection before going to production. Clearly, that hasn't happened with systemd."
This discussion has been archived. No new comments can be posted.

Choose Your Side On the Linux Divide

Comments Filter:
  • by Z00L00K ( 682162 ) on Monday August 25, 2014 @01:57PM (#47750173) Homepage Journal

    Who really needs systemd?

    It may provide some features not previously existing, but it also breaks a lot of stuff that people "knew" were there.

    • by jedidiah ( 1196 ) on Monday August 25, 2014 @02:17PM (#47750409) Homepage

      > Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition.

      Sure it should. At the very least, such sweeping changes should be met with some skepticism based purely on mundane ideas about change control. Why are changes with such a massive impact being considered? What is being done to mitigate risks? How is this going to impact how Linux fits in with other Unixen?

      What's broken exactly?

      • by Anonymous Coward on Monday August 25, 2014 @02:36PM (#47750649)

        What's broken is that some people would rather change Linux into something else fundamentally, rather than wait for the rest of the world to catch up. The result is going to be the same kind of pain that's happening in the browser arena. There, you have reasonable standards bodies who move "too slowly" for a few, who wish to replace the web with a new version that's obviously even more flawed, all in the name of progress. Sometimes the old guard aren't just holding back progress, but don't tell that to inexperienced youths and bitter old men who want to make a name for themselves.

        • by Darinbob ( 1142669 ) on Monday August 25, 2014 @04:44PM (#47751891)

          The new guard in most arenas seem predisposed to think that newer is the same as better. And sometimes that is true. In the case of systemd it's a mix of some new stuff that's good and desirable but inseparable from other parts which are new but not so good. So the conflict seems to be in the push to get the new+good stuff out soon while other people are concerned rightly about all the new+bad stuff being pushed out without any plan or discussion.

          Similarly, there's the ubuntu unity style of stuff: a big push by new guard that want tablet/phone presence, and an old guard wondering what corrupted their desktop (you could probably peek inside Microsoft and see the same divide in the Windows 8 debacle). You can see this in the Mozilla Firefox version deathmarch probably.

          Ultimately it's the push to get new stuff in as soon as possible that leads to the conflict.

      • by gweihir ( 88907 ) on Monday August 25, 2014 @03:06PM (#47750951)

        Nothing is broken with Linux. But by now I believe something very fundamental is broken in a highly dangerous fashion with the systemd developers. They hardly seem to qualify as UNIX folks at all with their mind-set....

      • by Freultwah ( 739055 ) on Monday August 25, 2014 @03:18PM (#47751051) Homepage
        From what I read, I think the point was that if such changes *are* met with such fervent opposition, it is high time to step on the brakes and reevaluate the situation, and perhaps revert the changes.
      • The init system (Score:5, Interesting)

        by jbolden ( 176878 ) on Monday August 25, 2014 @04:00PM (#47751517) Homepage

        What's broken is this. The initt system assumes:

        1) All the subsystems boot quickly
        2) None of them need to communicate back and forth about status in complex ways
        3) The list isn't too long

        There exists lots of users for which one or more of those 3 assumptions are false. If you don't assume those 3 then you would design boot differently.

        What is being done to mitigate risks?

        What's being done is large Unix distributions are heading the effort that deal with thousands of packages. The risk is being handled by going through package by package by package and resolving any small problems.

        How is this going to impact how Linux fits in with other Unixen?

        The 2nd most used Unix is OSX. That uses launchd. That of course handles the problem of integrating in daemon tools and cron like features into the launch system which is different than either init or systemd. If the goal were better compatibility with other Unixes that not init would be the target.

        Anyway the big change is likely to be that more and more linux software is going to assume systemd as hard dependency which means that other Unixes are going to have to switch or at least support systemd if they want to be able to port from Linux.

    • by loony ( 37622 ) on Monday August 25, 2014 @02:17PM (#47750411)

      Who cares if you have to relearn stuff? Its the fact that systemd is less than stable... In many cases, you end up with corrupt binary log file after a crash, have services that don't (run a process that does heavy syslogging to the tune of 25-30K messages per second. Yes, its bad app design but come on - this thing worked for years and now its suddenly broken???) that used to work just fine before and then top it off with really braindead configuration options (go ahead and change the pgsql listen port - and see how long it takes you...)

      I'm all for systemd - once its been stable for a while, but till then it would be nice to have at least a choice...

      Peter.

      • by jedidiah ( 1196 ) on Monday August 25, 2014 @02:23PM (#47750493) Homepage

        > Who cares if you have to relearn stuff?

        Anyone that uses something besides Linux. One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become. The more reason their will be to resist moving from one to another.

        This is something that has benefited Linux greatly in the past: the fact that a Solaris user could feel fairly comfortable with picking up Linux and just dive in.

        The anti-dinosaur sentiment should not be an excuse to blindly and gratuitously change things just because of "new shiny shiny".

        All of your substantive complaints seem to be a direct result of ignoring the principle "don't fix what isn't broken".

        • True,
          However Linux has shone from time to time that it was able to push Traditional Unix systems to switch to their method of doing things.

          However the real question is what is the benefits vs cost of the change.
          How will that affect GNU/Linux primary purpose (Server OS).

        • by Anonymous Coward on Monday August 25, 2014 @02:50PM (#47750805)

          This is something that has benefited Linux greatly in the past: the fact that a Solaris user could feel fairly comfortable with picking up Linux and just dive in.

          http://en.wikipedia.org/wiki/S... [wikipedia.org]

        • by beelsebob ( 529313 ) on Monday August 25, 2014 @02:57PM (#47750871)

          Anyone that uses something besides Linux. One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become. The more reason their will be to resist moving from one to another.

          Except that's actually false. Unixen really don't share common interfaces. Mac OS uses launchd, FreeBSD uses init.d, many Linuxes use systemd.

          On Linux you'll find devices named /dev/hda(n) and sda(n), while on OS X you'll find /dev/disk(n)s(m), and on solaris you'll find /dev/dsk/c(n)t(m)d(l)s(o).

          All unixes differ. Trying to claim that the way it happens to have been done in Linux for a while is the "one true unix way" is frankly bullshit.

        • All of your substantive complaints seem to be a direct result of ignoring the principle "don't fix what isn't broken".

          SysVInit is broken. It doesn't restart services that crash. In an environment with many hundreds of servers, the menial task of restarting services becomes a full-time job.

          • by blue9steel ( 2758287 ) on Monday August 25, 2014 @04:04PM (#47751549)
            Wait, why would I would the system init function to be monitoring and restarting services? That's an unwarranted scope expansion. Yes, I may want that capability, but there is no reason for the init function do be doing it.
          • by DamnOregonian ( 963763 ) on Monday August 25, 2014 @05:39PM (#47752241)
            Entirely false. In an environment with ~400 servers, it's not remotely close to a full-time job. For services that suck or are prone to crashing (very, very few on our deployments) an inittab restart directive does the trick, or for things that are prone to hanging and going full retard, monit does the trick.

            You know what sucks my ass though? Not being able to modify the init scripts as I need. I'm so glad we've made a daemon that will make sure I never need to alter the low-level starting dynamics of a service again. At least I assume it does that, since it *does* deprive me of my ability to.
        • by RR ( 64484 ) on Monday August 25, 2014 @03:53PM (#47751457)

          One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become.

          The init system is a very poor example of Unix common interfaces. As beelsebob [slashdot.org] and oursland [slashdot.org] point out, different Unix systems use different init systems. The Linux alternatives, upstart and systemd, were actually inspired by the clear advantages displayed by MacOS X's launchd.

          And even in Linux, with SysVinit, there are different interfaces. When you want a script to run at boot, do you use update-rc.d, like Debian? Do you use rc-update like Gentoo's OpenRC? Or chkconfig like Red Hat? Or insserv like SuSE? And where do you find important details like the hostname and network configuration?

          I don't find systemd to be a pleasing design, and I especially don't share their love of long command names with lots of consonants, but I think their work is very important.

      • by Anonymous Coward on Monday August 25, 2014 @02:25PM (#47750529)

        Much like pulseaudio, it will probably become quite good when Lennart stops working on it and hands it over to someone else to maintain.

      • by mysidia ( 191772 )

        (go ahead and change the pgsql listen port - and see how long it takes you...)

        vi /var/lib/pgsql/data/9.3/postgresql.conf

        ^] :%s/^#port = 5432/port = 1234/
        :wq
        semanage port -a -t postgresql_port_t -p tcp 1234
        iptables -I INPUT -p tcp --dport 1234 -j ACCEPT
        /usr/libexec/iptables.init save
        systemctl restart postgresql

        Was that so hard?

        So sorry that even with iptables-save installed and the new systemctl firewalld turned off... "service iptables save" command has disabled so suddenly, even though it's

        • by 0123456 ( 636235 ) on Monday August 25, 2014 @02:39PM (#47750683)

          Was that so hard?

          Hey, guess what? I did that, and it didn't work.

          Hint: you missed at least one more place where you have to change the port number.

    • by Anonymous Coward on Monday August 25, 2014 @02:26PM (#47750531)

      Basically we *need* something like systemd, which is why it's gaining ground. It's providing a lot of sorely-needed features, efficiency, and cleanup in a ton of areas. The are a handful primary meta-downsides that cause all the teeth-gnashing can be summarized as follows (all of which are avoidable in theory...):

      1) The developers are often uncooperative assholes - True of many projects in the OSS world, sadly. Generally not a deal-breaker when everything else is fine, but it really exacerbates problems with the other points below.

      2) Emacs Syndrome - systemd has begun to be the kitchen sink of Linux. They're adopting a philosophy that anything anything which touches/interacts with systemd and doesn't work for them (doesn't fit their new radical model) should be re-written into compliance, and since too many of the authors of these non-compliant projects are also systemd grumblers, the project has taken to the habit of rewriting these components themselves and making them a part of systemd. Thus systemd's scope has grown tremendously, and it's bundling a ton of risk into a single meta-package. Even things as far removed as NTP functionality are now rolling into systemd (did you know systemd is trying to replace ntpd?).

      3) Reinventing APIs radically - The big case here is the basic OS interfaces for networked daemons. For a traditional *nix daemon, this means the collection of POSIX-y system calls that deal with things like privilege management, daemonization, logging, socket binding, etc. The systemd model tries to replace all of this with declarative service configuration files which set all of this up from outside the daemon before it's launched, allowing it to focus on merely processing socket traffic. Think of this as a much more advanced variant of the inetd model. The problems with this approach are three-fold (and you'll see examples of these problems in other areas of systemd as well):

      3a) They haven't mirrored every possible legitimate use of the old POSIX-y syscall API in the new declarative configuration. In little ways this means things like not supporting every socket option in the normal socket APIs. In big ways, this means more complex behavior patterns. For example, a traditional *nix daemon might be capable of managing its daemonization in an advanced way with the flexibility of the POSIX APIs (e.g. allowing a controlled 'restart' behavior for reducing downtime that starts a new daemon overlapped with the old one and uses some IPC to coordinate the handoff of live sockets, etc). Systemd's declarative model is far more limited in scope and can't possibly map to all of these creatively-beneficial uses of POSIX behaviors. Also, a full conversion of a system to systemd doesn't work well with just leaving some daemons as traditional sysv-init style, and the long course is to get rid of sysv init compatibility completely. This really screws these cases.

      3b) It introduces a new latency in exposing new APIs. Before if, say, a new socket option appeared that was useful to a daemon, it first appeared in the kernel, then later in glibc, at which point it's at least conditionally available in a reasonable manner to portable (among linux versions/variants) software. Now we must wait for it to hit the kernel, then glibc, then systemd, and only then can the application take advantage of the feature. Who's coordinating this the way that kernel/glibc APIs are coordinated? This stuff isn't even documented.

      3c) In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case. Thus these APIs aren't well-thought-out for the server-like case, and the concerns of authors of that sort of software are not being taken very seriously (see point 1). However, the distros which have all (how the hell?) been convinced it's a good idea to move their whole distro to systemd in the long run will obviously be using the same init system in both cases. I know we all want some year to be the Yea

      • by gweihir ( 88907 )

        Bullshit. There is no "need" for systemd. It does solve a few exotic problems and does to at a huge cost to reliability, security and flexibility.

      • by Peter H.S. ( 38077 ) on Monday August 25, 2014 @04:23PM (#47751725) Homepage

        Re 1: Developers uncooperative?
        Looking at the mailing list this doesn't appear to be the case. +500 developers have contributed to systemd, that points to excellent leadership where even small contributions are welcomed.

        Re 2: Emacs syndrome.
        It is popular but totally wrong meme that systemd just pile on features. Its scope have been quite narrow for years. Yes, it have gained new features, but almost all new systemd features are related to the original scope of stateless booting and light weight containers.
        So people who hasn't bothered following systemd gets totally surprised when a new version of systemd has new features, but that is just because they don't really know systemd.

        Re 5: Total disregard for everything outside of Linux,
        All daemons made when sysvinit was king will work with systemd. It is backward compatible, even with sysvinit scripts (there are some few documented corner cases)

        So daemon authors don't have to change a single line of code if they don't want to. The distribution managers can just add a service file instead of the sysvinit script. (probably remove some bugs that way too)

        No other certified UNIX uses sysvinit scripts, they all have init systems more less like systemd. Does that mean they have a total disregard for anything e.g. not Solaris? (SMF).

        I find the idea that all progress on Linux should be stopped if there is a danger that it progressed faster than other Unix'es (read BSD) a rather silly idea. Especially because those other Unix'es generally hate and despise Linux because it is a successful competitor.

        systemd is the greatest thing happening to Linux for a decade, and probably the biggest shake up ever.

    • by LVSlushdat ( 854194 ) on Monday August 25, 2014 @02:26PM (#47750539)

      Who really needs systemd?

      I've been working with Linux since 1995, where I started with Slackware, moved over to Redhat until it went all "enterprise-y", at which time I moved to Fedora.. Stayed there till a friend turned me on to Ubuntu in 2007, where I stayed pretty much till the recent Unity shitfest over there, where I then moved to Debian.. I cut my teeth on /etc/init.d and a stock standard init() process.. I could do pretty anything I needed to do in troubleshooting/starting/stopping daemons from memory.. Can't remember the last time I consulted a man page regarding anything having to with init() or logging.. Now with this $#@$%%$#@ systemd, I have manpages up ALL the time just to do simple shit that I could do with init() and standard logging in my sleep before systemd. It also seems like this crap is spreading like sewage over pretty much of the standard distros.. Debian/Fedora/CentOS.. The only one I'm somewhat familiar with (haven't used it recently) is Slackware and from what I've heard Patrick and the devs over there feel the same way I do about systemd.... Maybe its time to revisit an old friend.....

      • by CajunArson ( 465943 ) on Monday August 25, 2014 @02:33PM (#47750615) Journal

        TL;DR version: You spend around 20 years getting used to the old way of doing it and now you can't stand change.

        My story: Been using Linux heavily since 2000. Arch adopted Systemd big-time in 2013 or so. I spent a little while learning the new commands, and now it's just as easy/hard/whatever as the old RC system was. Oh, but my boot times are way shorter than they used to be.

    • by psergiu ( 67614 ) on Monday August 25, 2014 @02:34PM (#47750617)

      Systemd's strenghts are:
      - Fast startup & shutdown (compared to sysVinit);
      - Better on-demand loading and stopping services and processes and changing network settings.

      Compared with all the problem it brings:

      - That is useful on a tablet or phone - where you never have to modify the factory configuration;
      - A bit useful on a laptop - if you only use GUI tools that can do a limited ammount of config editing for you;
      - Not very usefullon a desktop - unless you are prepared to get your hands dirty with systemD's smelly and poorly-documented guts;
      - Useless on a server - where you only reboot 4 times a year or so and never have to hot-plug anything or change wireless networks.

      For a server situation, the BSDrc style startup is even better than sysVinit.

      • by evilviper ( 135110 ) on Monday August 25, 2014 @03:21PM (#47751089) Journal

        - Useless on a server - where you only reboot 4 times a year or so and never have to hot-plug anything or change wireless networks.

        Bull. Lots of servers currently run daemontools or similar, or else they use some other hack, because the SysVinit doesn't have any way to restart services (like crond) the one time they exit after running fine for months...

        Alternatively, somebody has to take the time to set-up exhaustive monitoring, including ALL the trivial services running on the servers, and some dummy has to watch it around the clock, and manually perform this extremely simple and menial task. Or else maybe you're the dummy who gets paged at 3AM to do a trivial service restart, due to some simple and transitory event.

        I would have been just as happy with upstart or anything else, but it was a dammed nuisance lacking that 30 year-old feature, and downright embarrassing that Linux still lacked it, while it's been working well in the base of Windows since the first version of NT.

    • by RabidReindeer ( 2625839 ) on Monday August 25, 2014 @02:40PM (#47750699)

      This is the problem with systemd, Gnome 3 and a lot of other recent stuff.

      Unix was originally designed rather like a tinkertoy set. The individual parts might not be very smart, but you could glue them together however you wanted. A "RISC" architecture, if you will.

      Recent "improvements" to Linux have attempted to be all-in-one solutions. By making them one-size-fits-all, you lose useful, important, sometimes critical functionality. Because no one system can be all things to all people. It's a "CISC" solution, and what you are left with is what the designed wanted you to have, not what you wanted to have.

      So that's the Great Divide. Turn into another Apple, where you can have any solution you want as long as it's the one the providers want to give you or retain the original spirt of the system, and allow it to be powerful at the expense of the presumed masses who'd gladly chuck Windows if only Linux was more friendly to the casual user.

  • by NotDrWho ( 3543773 ) on Monday August 25, 2014 @02:00PM (#47750197)

    And THAT pretty much sums up what has always held Linux back (and probably always will).

    • And THAT pretty much sums up what has always held Linux back (and probably always will).

      Except this is not really a problem with the exception of Slackware and Gentoo two obvious holdouts ...and if you use those distributions you know why.(Go on read the wikipedia on systemd it has some great quotes).

      all these distros use systemd - Arch Linux, CoreOS, Debian GNU/Linux(Default for Debian 8 "jessie"),Fedora, Frugalware Linux, Mageia, NixOS, openSUSE,
      Red Hat Enterprise Linux, Sabayon, Ubuntu(Coming). The deal is done.

      Oh FYI Linux overtook windows back in 2013 is quite well know.

  • by jones_supa ( 887896 ) on Monday August 25, 2014 @02:07PM (#47750275)
    I believe X.org versus Wayland would be another pair bridging the old and new Linux world.
    • Re:Display server (Score:5, Insightful)

      by psergiu ( 67614 ) on Monday August 25, 2014 @02:17PM (#47750399)

      As long as xterm & the web browser are running on Wayland, nobody will complain.
      X.org has became such a mess itself (compared to the old XFree86) so anything smaller, simpler, faster and 100% compatible is welcome.

      OTOH systemD is not smaller, simpler and 100% compatible with the systemV init and BSD rc - so it requires everybody relearning a lot of concepts for scratch just to gain 4-5 seconds at boot time - unsually on a server that you reboot only a couple of times a year.

  • by Mr D from 63 ( 3395377 ) on Monday August 25, 2014 @02:09PM (#47750305)
    I don't have a pony in this race. Don't know much about it. But the title says I gotta choose a side, and from the looks of things the new guard is winning, at least with this systemd thingy, so I'll go with them. GO NG GO!
    • Re:Choosing Sides (Score:5, Informative)

      by present_arms ( 848116 ) on Monday August 25, 2014 @02:18PM (#47750425) Homepage
      What system V and systemd do is initialise the OS, let me kinda explain, you turn on your pc, it loads the bootloader which in turn loads the init system, the init's systems job is to hand off certain jobs to certain programs, getty so you have cli, X so you have a nice GUI, and starts or stops services. This is a very simplistic explanation. Now it's my belief that Init should be made with separate components, for instance system V will read the scripts from /etc/rc.d and depending on those scripts depends what's loaded at boot time. Now the problem with systemd is (from what I believe) is that it's a one-stop for all, encompassing all the scripts needed, and gaining bloat (mostly not needed) at the same time. It's starting to be the "registry" of the linux world. and NO-ONE with a hint of intelligence wanted the Windows registry, let alone a clone of one.
      • Re:Choosing Sides (Score:5, Interesting)

        by Zocalo ( 252965 ) on Monday August 25, 2014 @03:22PM (#47751093) Homepage
        Not just the Registry, but it's also rapidly becoming the equivalent of "svchost.exe". I probably wouldn't have a problem with SystemD if it were designed to be *much* more modular, but the design goals for the package seem to be to embrace, extend and extinguish a significant number of other processes essential to the Linux boot process and to bring most of it straight into PID1. That's just asking for major problems if/when anything goes wrong, and makes troubleshooting a nightmare because you have one huge black box instead of a bunch of daemons. If the SystemD team want to manage network startup, system logging, firewalls and whatever else takes their fancy, then fine, go right ahead; just do it in a way that makes it easier for system admins to disable it and plug in a more fully featured and/or stable alternative, and do it as a child of PID1 so if/when it does crash it doesn't bring the whole system down with it.

        If you want an eye opener take a look at the dependency list for SystemD and those packages that depend on SystemD some time, note how entries appear in both lists, then consider the following questions: Bearing in mind that SystemD is the first thing that is loaded after the Kernel; does that look like a good design to you? Does it explain why so many distros have adopted it, given that many of those dependencies either won't work without SystemD underneath or require a considerable amount of customisation to use any alternative?

        Still, there's always BSD.
      • Re:Choosing Sides (Score:5, Insightful)

        by Anaerin ( 905998 ) on Monday August 25, 2014 @03:29PM (#47751173)

        You're posting a lot on the drawbacks of SystemD, but you're not including any of the drawbacks for SystemV.

        • SysV starts every task and service one at a time, waiting for the previous one to finish before it starts the next. This is fine for single-core single-threaded workloads, but most systems these days are multi-core. It also means that startup is slow. SystemD, on the other hand, can (and does) start up services in parallel, making sure that dependencies are resolved before starting the next item. This makes SystemD MUCH faster at booting.
        • SysV only handles the initial bringing up, and the final tearing down, of services. Any service failures are not noticed, any errors are not dealt with. SystemD monitors services even while they're running, and can re-start them if they fail, handle crash reporting and log rotation. This makes SystemD more error resilient and stable.
        • SysV only runs the services, and doesn't care about their configuration, so basic configuration and dependencies have to be handled in a myriad of ways, different for every service. SystemD attempts to be a central repository for ports (and handling the necessary firewall rules for them), configuration files, logging locations, and the rest. While this does make startup a touch more difficult to configure, it makes the system as a whole a lot simpler to deal with.
  • by xxxJonBoyxxx ( 565205 ) on Monday August 25, 2014 @02:11PM (#47750327)

    At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.

    So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)

    • Re: (Score:3, Insightful)

      At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.

      So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)

      Ubuntu is the largest distro I know of and it doesn't support it by default.

      But you're right, all the arguments I've read against it boil down to Linus hating on one of the developers on the project and/or "It's too complicated and unmanageable!" I've yet to read something I'd consider a valid argument against it. A bunch of neck beards yelling "Get off my lawn!" is not and argument I can get any value out of.

      • by blue9steel ( 2758287 ) on Monday August 25, 2014 @03:03PM (#47750927)

        I've yet to read something I'd consider a valid argument against it.

        It violates basic *nix design philosophy, which basically has two pieces: 1) Everything is a text file 2) Lots of small tools that can be chained together to do big things

        Boot time is essentially irrelevant, I don't see why everyone gets so excited about it.

      • by davek ( 18465 ) on Monday August 25, 2014 @03:05PM (#47750939) Homepage Journal

        At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.

        So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)

        Ubuntu is the largest distro I know of and it doesn't support it by default.

        But you're right, all the arguments I've read against it boil down to Linus hating on one of the developers on the project and/or "It's too complicated and unmanageable!" I've yet to read something I'd consider a valid argument against it. A bunch of neck beards yelling "Get off my lawn!" is not and argument I can get any value out of.

        When the neck beards speak, it's often prudent to at least listen.

        I'm reminded of a myth, of when the Ancients were sitting down to design Unix, someone said "Why would we ever need a special file, that never contains any data, and always throws away everything written to it?" The Ancient replied, "Trust me, you'll need it." And thus, /dev/null was born.

  • by MobyDisk ( 75490 ) on Monday August 25, 2014 @02:11PM (#47750331) Homepage

    This article is just a rant, full one one-liner insults and clichés. There are probably good debates on this topic, but this is not one of them.

  • by Eravnrekaree ( 467752 ) on Monday August 25, 2014 @02:12PM (#47750341)

    the general concept behind systemd makes sense, its mainly some additional features on top of the current model, such as the ability to have processes started on certain system events. The fact is, if you want your bootup process to be controlled by bash scripts, all you need to do is configure systemd to start your bash script and youve got a more traditional init system. So, systemd does not take away any functionality, only adds it. Systemd supports the system v init process features so you still have all the old model functionality available to you. So, it does not make much sense that people complain about this when they can easily configure things however they want, including having a BSD style init, by having systemd hand off control to your own scripts, including to work the way things always have. People act like systemd has taken away something when it has not, i think many people just hears some soundbite about systemd introducing a new model and assume that they can no longer use things the way they do currently, which is not the case. it seems like people who don't like systemd don't want people to have the additional functionality that it provides, because it does not take away anything. Its open source software, and its something that you can control and configure to your hearts content. Its much ado about nothing. systemd, while being configurable, also will make things easier to use for many users. I think the ado about systemd is more about Linux people who think that Linux should be hard to use except for a small elite and do not want the OS to be useful to less technically adept users. This is even though making it more useable for less adept users does not in any way harm or take away flexibility from experts, who can still configure everything if they want they want to.

    • Comment removed (Score:4, Interesting)

      by account_deleted ( 4530225 ) on Monday August 25, 2014 @02:57PM (#47750863)
      Comment removed based on user account deletion
  • by Anonymous Coward on Monday August 25, 2014 @02:14PM (#47750373)

    Yes, the old SysV init of hordes of scripts running in series was broken - especially for large-scale systems that have to do a lot of things during startup.

    But systemd is just plain FUCKED UP. Read the dependencies [debian.org].

    Why the fuck does the startup process have to depend on the IPv6 kernel module? The other dependencies are no better.

  • by Artifakt ( 700173 ) on Monday August 25, 2014 @02:20PM (#47750447)

    "Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition."

    The more fundamental a change is, the more it changes everything - that's basically why we call it 'fundamental'. Making fundamental changes says there's a lot broken. If I said we need a program to fast track educating doctors for rural areas, that's a moderate change to the US medical system, and might a good or bad fix for one specific problem. If I say we need to shoot all existing physicians and substitute Qui-Gong practicioners, that's a fundamental change to American medicine. If someone asserts a change is fundamental, they have also implied the existing system is nearly or totally borked, so they have a very strong burden of proof shifted entirely to them for making that assertion. Unless they can meet that burden of proof, the other side should win any debates.
              The smart thing to do is to claim that a change is not alll that fundamental, and changes only a limited subset of things. For example, I could argue that gay marriage is a limited change, in that it is still based on a moral principle many of us respect (that the people choosing it are consenting adults with normal understanding), and not a more fundamental change (such as throwing out any moral base, including the principle of informed consent, so that pedophilia would somehow become legal). Notice how it's been mostly anti gay marriage advocates that are trying to paint the issue like everything under the sun will change if the other side wins - that's because many people have figured out how this burden of proof stuff works.

  • by rubycodez ( 864176 ) on Monday August 25, 2014 @02:34PM (#47750623)

    A complex startup system that logs to a database rather than a text log, is just poor engineering.

    And to answer any systemd apologist who will mention that it can configured to log to syslog, that won't help if there is a problem in the vast complexity of systemd that prevents it from ever getting started to that point.

    Just the requirement for dbus proves systemd far too complex and bloated a thing, it is against the Unix way of doing things. Failures and problems in a needlessly complicated black box may well be too difficult to even troubleshoot

  • by Etcetera ( 14711 ) on Monday August 25, 2014 @02:58PM (#47750885) Homepage

    You can see this in Development vs Operations, Bay Area Startup Hipster Programmers vs System Administrators Who Have To Carry The Pager, Big Data vs Simpler Analysis, and a lot of other places in the industry right now....

    There's an influx of talent that doesn't seem to understand the fundamentals of system architecture, or assumes they have all the answers and can/should hard-code them into the design, preventing "the Unix Philosophy" from being applied by the operator who's trying to deal with the crisis at 3 in the morning. "whatcouldpossiblygowrong", ergo I shall design this in C, and if you need more flexibility than I'm offering then You're Doing It Wrong.

    What they don't understand is that they don't have all the answers... Nobody does. The only solution is to leave as much flexibility available as far down the stack as possible to allow the folks who have to deal with this (eg, system administrators) the ability to do their jobs. Replacing shell scripts with C code and the unix toolkit with monolithic binary blobs does not help the situation.

    systemd does a few things right (cgroup management, for one), and promotes the state of the art in a few areas that probably only could be dealt with at the PID1 level... Also, as the original article admits, there's nothing inherently wrong with working to speed up boot times across the board. All of these things are irrelevant and outweighed by enforcing declarative styles on system configuration, and the sheer philosophical hazard of taking all these disparate functions and putting them into a program.

    It makes absolute sense for Android, and perhaps an embedded system that just needs systemd and busybox. For a regular Linux userland, it takes us in the wrong direction.

  • by MoonlessNights ( 3526789 ) on Monday August 25, 2014 @03:44PM (#47751335) Homepage Journal

    (FYI: I haven't followed the systemd saga but I have noticed this fight in a growing number of places)

    This seems to be a VERY common problem in the modern computing environment: arguments are reduced to ad hominem labels of their supporters where the proponents of "new" are just "kids fascinated by the trendy at the expense of stability" or other "why maintain it when I can write something better?" inexperienced people and the proponents of "old" are just "out of touch old-timers who are afraid of the unknown" or people "only interested in their own job security".

    Of course, the reality is some bits of these straw men, combined with massive doses of reality. The truth is, both sides of the argument make more sense if they are reduced to actual concerns and interests, as opposed to "us versus them" camps.

    The truth is that "change for change sake" is a dangerous position and the reality is that the "legacy" moniker is slowly changing from a negative term into something which means "has worked well for a long time".
    Alternatively, sometimes new ideas are beneficial since they tend to think of current realities, as opposed to sometimes-extinct realities.

    This whole notion of "choosing your side" doesn't help anyone since it isn't actually a division, but a conversation/argument. Sometimes stepping forward is correct while sometimes standing still is correct and neither approach is "always correct". Maybe we would choose our next steps better if we worked together to choose them instead of all lining up in our preassigned trenches.

  • by RDW ( 41497 ) on Monday August 25, 2014 @04:08PM (#47751577)

    Never mind trivial things like systemd - the real watershed moment for Old Unix vs New Linux was back in 2011, when a humourless package maintainer excluded 'ddate' from the default build of util-linux:

    http://en.wikipedia.org/wiki/D... [wikipedia.org]

    https://git.kernel.org/cgit/ut... [kernel.org]

    https://bugzilla.redhat.com/sh... [redhat.com]

Truly simple systems... require infinite testing. -- Norman Augustine

Working...