Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Open Source Software Linux

Torvalds: No Opinion On Systemd 385

An anonymous reader writes:Linux creator Linus Torvalds is well-known for his strong opinions on many technical things. But when it comes to systemd, the init system that has caused a fair degree of angst in the Linux world, Torvalds is neutral. "When it comes to systemd, you may expect me to have lots of colorful opinions, and I just don't," Torvalds says. "I don't personally mind systemd, and in fact my main desktop and laptop both run it." Torvalds added, "I think many of the 'original ideals' of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation. There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at some level, but I think it's also clear that it doesn't really describe most of reality."
This discussion has been archived. No new comments can be posted.

Torvalds: No Opinion On Systemd

Comments Filter:
  • well said! (Score:4, Interesting)

    by Brian Beaudoin ( 2848525 ) on Wednesday September 17, 2014 @08:39AM (#47926207)
    I approve of this message.
    • by penguinoid ( 724646 ) on Wednesday September 17, 2014 @09:11AM (#47926535) Homepage Journal

      As usual, the headline is misleading. What's less usual is that they totally undersensationalized the news.

      Torvalds: No Opinion On Systemd
      vs
      Torvalds: UNIX Philosophy is Obsolete

      • by Carewolf ( 581105 ) on Wednesday September 17, 2014 @09:44AM (#47926905) Homepage

        As usual, the headline is misleading. What's less usual is that they totally undersensationalized the news.

        Torvalds: No Opinion On Systemd
        vs
        Torvalds: UNIX Philosophy is Obsolete

        I think you missed the micro-kernel vs macro-kernel debate that happened when Linux was born. That Linus likes things more monolithic and practical is OLD news.

        • ...monolithic and practical...

          Of course, that depends upon one's opinion of "practical".

          .
          Some think that "practical" means a complex, overly interconnected maze of software.

          • by Archangel Michael ( 180766 ) on Wednesday September 17, 2014 @11:24AM (#47928197) Journal

            Practical is how we work. Monolithic or Micro based are independent of whether or not something is practical. What is practical in one situation (small robust control system with high availability) may not be practical (complex system of varying hardware) elsewhere.It is a matter of how close to sigma six you need to be, because each degree closer, is a magnitude more difficult to reach.

            The fact is, you can talk all you want about what is "practical" in a specific case, and I may be arguing that your "practical" isn't practical for me and my specific case. We'd both be right, but not for each other. This is pragmatism at its core. One size doesn't fit all. Never has, never will.But you can build things so that One Size Fits Most, that works in 95% of the cases.

            Systems that are outliers shouldn't be where we decide things for the 95%.

      • by phantomfive ( 622387 ) on Wednesday September 17, 2014 @11:17AM (#47928097) Journal

        Torvalds: UNIX Philosophy is Obsolete

        I'm not sure that's accurate......it seems he's actually saying, "UNIX Philosophy is hard to implement in complex systems." It seems to me the reason he doesn't have much of an opinion is because he hasn't spent the time necessary to think it through deeply. There might be a better solution or not, he doesn't know.

        And I think it makes sense......SystemD is a heap of trash, but System V isn't an example of great design, either.

        • Re: (Score:3, Interesting)

          by Anonymous Coward

          And I think it makes sense......SystemD is a heap of trash, but System V isn't an example of great design, either.

          And that is part of the problem, that it is presented as a init vs init issue.

          It has long since grown past that. Systemd, as a package, now holds udev, journald, its own cron replacement, a network manager, dhcp, ntp, inetd, etc etc etc.

          But the crowning achievement may well be logind, that more and more DEs are getting a dependency on.

          And logind can only function with systemd as the init, full

          • And that is part of the problem, that it is presented as a init vs init issue.

            It has long since grown past that. Systemd, as a package, now holds udev, journald, its own cron replacement, a network manager, dhcp, ntp, inetd, etc etc etc.

            There are several inaccuracies on that list; systemd has timers that may be used as a cron substitute, but really is a different design, so therefore cron can happily co-exist, and nobody forces anybody to use the systemd solution. Systemd doesn't have a replacement for a N

      • by gangien ( 151940 )

        therefore LINUX is obsolete.

        so really Tanenbaum was right all along.

      • by emil ( 695 ) on Wednesday September 17, 2014 @02:31PM (#47930571)
        • - UNIX admins have been able to ply their trade for the last 40-odd years with a stable set of userland utilities, which systemd consigns to the trash heap.
        • - systemd has removed the old userland (init, inetd) without providing good documentation and examples for doing the old things with the new tools (seriously, the top systemd-inetd example uses ssh, which nobody does - how about ftp or pop3?).

        It seems that there are lots of new capabilities with systemd, but it has come to market with lousy documentation. The purveyors are receiving a thorough flogging at the hands of the greybeards, which they richly deserve.

    • I see people all over linking their Facebook to many sites. Never thought I would see it on /.
    • I have no opinion on it.

  • by CajunArson ( 465943 ) on Wednesday September 17, 2014 @08:43AM (#47926247) Journal

    It sounds great in theory but...
    1. If you really buy that principle and want to enforce it religiously, then please never use a web browser again (even Lynx!), not to mention any other complex program that isn't formed from a bunch of small "do one thing well!" utilities that are executed in a pipeline.

    2. Please tear up your Richard Stallman fanclub cards because what little software he's written has mostly been Emacs and Emacs is the anti-UNIX based on the "pure" UNIX philosophy.

    That't the issue: Every single person who hates SystemD because "UNIX PHILOSOPHY!!" has no problem violating that philosophy to actually get things done in a whole bunch of other areas. That's not even bringing up the fact that SystemD is.. wait for it... built from a bunch of individual utilities that can actually be used by non-systemd programs.

    • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday September 17, 2014 @08:50AM (#47926333) Homepage Journal

      If you really buy that principle and want to enforce it religiously,

      It's not a religion, it's a principle. When it makes sense, you put it aside and get work done. The argument against systemd is that it doesn't make sense. systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.

      That't the issue: Every single person who hates SystemD because "UNIX PHILOSOPHY!!" has no problem violating that philosophy to actually get things done in a whole bunch of other areas.

      That's right.

      That's not even bringing up the fact that SystemD is.. wait for it... built from a bunch of individual utilities that can actually be used by non-systemd programs.

      That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.

      • by kthreadd ( 1558445 ) on Wednesday September 17, 2014 @09:04AM (#47926465)

        That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.

        We all stopped using UNIX long ago, it's GNU/Linux now and it's only somewhat inspired by UNIX. What the UNIX people did 30 years ago is interesting from a historical perspective, but is not in any way the only right way to do things. I say did because that's now even how modern unices work. Solaris has for example been running on SMF since 2005 and they are doing just fine.

        • by mark-t ( 151149 )

          It's Linux, not GNU/Linux, no matter what Stallman insists. Linux is released under the GPL, but it is not, itself, part of the GNU project.

          3dldf, a2ps, acct, acm, adns, alive, anubis, apl, archimedes, aris, aspell, auctex, autoconf, autoconf-archive, autogen, automake, avl, ballandpaddle, barcode, bash, bayonne, bazaar, bc, bfd, binutils, bison, bool, bpel2owfn, c-graph, ccaudio, ccd2cue, ccide, ccrtp, ccscript, cflow, cgicc, chess, cim, classpath, classpathx, clisp, cobol, combine, commoncpp, complexi

          • I'm not talking about the kernel, I'm talking about the operating system often referred to as GNU/Linux. Systemd has nothing to do with the kernel, except that it uses its functionality.

            • by mark-t ( 151149 )
              When I was in university,I used an HPUX system that had been heavily retrofitted to use all of the gnu applications and utilities that were available at the time. Nobody ever insisted that it ever should have been called GNU/HPUX. At east one release of Minix extensively used gnu software as well. If that was ever an expectation of Stallman's for operating system installations that heavily depended on GNU, then should have been in v1 of the GPL. Doing otherwise, and pulling this only after Linux had star
              • When I was in university,I used an HPUX system that had been heavily retrofitted to use all of the gnu applications and utilities that were available at the time. Nobody ever insisted that it ever should have been called GNU/HPUX. At east one release of Minix extensively used gnu software as well. If that was ever an expectation of Stallman's for operating system installations that heavily depended on GNU, then should have been in v1 of the GPL. Doing otherwise, and pulling this only after Linux had started to acquire some notoriety of its own makes him look just as bad as people who sit on patents until some really big company start to use it without knowing about the patent, and start enforcing it only then.

                Agreed. Even Solaris uses mostly GNU software now. So are you going to call it GNU/OpenSolaris or GNU/Solaris? Or GNU/MacOSX?
                No. It's just Solaris, OpenSolaris, and MacOS X.

      • by Anonymous Coward on Wednesday September 17, 2014 @09:31AM (#47926749)

        You don't seem to understand how SystemD actually works. The PID 1 is relatively simple -- it uses all sorts of separate (i.e. non-PID 1) helper processes to do all the heavy and complicated lifting.

        systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.

        Given that both C and Shell are Turing Complete (well, disregarding finite memory), then yeah. We could also program an init system in Brainfuck, but that has no bearing on whether it's a better idea to do so. Exactly the same thing here.

        Also, SystemD currently does a fuckton of stuff no other currently usable init system on Linux does. (Reliable process supervision which cannot be evaded, sane handling of process stdout/stderr, proper handling of dependencies at runtime, socket activation, etc. etc.)

        I don't particularly care which init system my system runs, but I want those features and currently only SystemD can deliver them.

        Please stop spreading FUD about things you know next to nothing about.

        • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday September 17, 2014 @11:46AM (#47928579) Homepage Journal

          You don't seem to understand how SystemD actually works. The PID 1 is relatively simple -- it uses all sorts of separate (i.e. non-PID 1) helper processes to do all the heavy and complicated lifting.

          Lifting which should not be done by PID 1. And PID 1 has to be more complex than it should be just to handle those external programs.

          SystemD currently does a fuckton of stuff no other currently usable init system on Linux does.

          It does a lot of stuff the init system shouldn't do.

          (Reliable process supervision which cannot be evaded,

          cgroups existed before systemd.

          sane handling of process stdout/stderr

          Up to the init script.

          proper handling of dependencies at runtime

          Already handled by several init systems.

          socket activation

          We call it inetd.

          I don't particularly care which init system my system runs, but I want those features and currently only SystemD can deliver them.

          That is ignorance at best, or perhaps a lie.

          Please stop spreading FUD about things you know next to nothing about.

          You have no idea about anything, that didn't stop you. I see why you didn't log in.

          • by DrYak ( 748999 ) on Wednesday September 17, 2014 @04:16PM (#47931629) Homepage

            (Reliable process supervision which cannot be evaded,

            cgroups existed before systemd.

            the cgroups functionnality existed in the kernel but wasn't really used that much before.
            systemd, with its tasks in setup/startup of things can handle the creation of jails during lauch when needed.
            whereas current /etc/init.d/apache can't without fumbling of shell scripts.

            sane handling of process stdout/stderr

            Up to the init script.

            And thus each script end up fucking things up in its own original and different way.

            proper handling of dependencies at runtime

            Already handled by several init systems.

            None of which are the original sysvinit.
            Either it's relying on LSB-extended script and a different core which starts the scripts. (Debian had a makefile based one)
            Or it's an entirely new system anyway like upstart.

            socket activation

            We call it inetd.

            Or cron if it's time-based activation. Or udev if it's hardware based activation. Etc.
            Why do we need 83 different way to start some code ?!
            Wasn't the whole point of Unix philosophy having one piece of software which concentrates into doing one thing and doing it well?
            With systemd, setup/startup/stop/teardown responsibilities are concentrated with PID1 and it's helpers.
            Before, you'd have the same concept spread into a dozen of different systems, each only doing part of that functionnality.

            I like systemd, it makes my work easier on desktop, on server, on virtual machines, etc. and although it used to have hiccups when it was introduced before in opensuse, by now it has had the time to mature.
            no need to bash it. if you don't like it, don't use it.
            and perhaps the fact that it's slowly gaining popularity in lots of mainstream distro might be due not because systemd is "a spreading cancer" but because systemd is actually useful and solves real world problem

        • by DrYak ( 748999 ) on Wednesday September 17, 2014 @04:03PM (#47931529) Homepage

          You don't seem to understand how SystemD actually works. The PID 1 is relatively simple -- it uses all sorts of separate (i.e. non-PID 1) helper processes to do all the heavy and complicated lifting.

          And another thing I like about systemd:
          - it groups into 1 single project: 1 single task (starting-up/seting-up things) that was spread accross way too many different project before.

          Before systemd:

          Want to start a service during boot-up ? Put it into sysvinit. Except if it's a file system, then it goes into /etc/fstab. Or if it's not a *service* but like of an interface like your terminal that should go into inittab (Except on distribution which do THE EXACT SAME THING but in init.d anyway).
          The thing which start is related to actual hardware? the you need to put it into hal, no way we replaced that with udev... except that a few distro put them any way in init.d and thus your hardware might not work when plugged after booting... unless you also duplicate some code into modprobe.conf's post-runs.
          And what if conditions for your code to start isn't "boot-up" nor "plug-in" ?
          Then put it into inted/tpcd if it's network triggered. Except for code that doesn't work there, because the service needs to be compiled to use libwrap to work this way. So then you'll have to run the service constantly and fumble around with ip filtering to enable/disable it on demand.
          Or put it into cron if it's time triggered.
          And you need to start a service and the periodically monitor it for failure, and restart and raise alert if it has failed? Well either use an entirely separate custom system like djbdns's daemontools. Or write your own monitoring solution by writing a ton of scripts which tap into all those different ways to start/stop stuff and hope that it works.

          And don't get me started about initialising containers (limited fonctionnality, tons of script), brokering access rights around (not really used. lot of interface must run as root and drop privileges, or lot of interface must be world accessible), handling situation as missing configuration or drivers in a system that hasn't fully booted up to the point where the GUI works and the user can fix things from here (huge tons of scripting to achieve way to detect that Xorg is failing and to propose solution to fix drivers)

          All this written in shell script which can have their own pitfalls, and every single system using a different syntax.

          After systemd:
          PID1 and its herd of helpers take care of setup/start/stop/teardown.
          Want to do *something*? Write a systemd config file, and describe which trigger (boot, after another service has started, on network, by clock, on device plug, etc.) should start it.
          You can even call legacy systems from within systemd (cron can be reimplemented as a systemd service that runs periodically and reads/executes crontab, etc.)

          You can have an LXC that is quickly setup. In fact you can quickly create throw-away container to jail any service separately (systemd is the kind of infrastructure that can boot a dedicated LXC jail to run Skype into, with restriction correctly setup so that no hidden backdoor could spy on you).
          You can have systemd handle brokering the necessary rights (to the point that plugin an USB stick and having the currently active user access to it isn't a nightmare anymore).

          If anything the handling of setup/startup/stop/teardown WAS NOT "unixy" before, it was "have 384 different programme which all do a different part of one single task in subtly different ways".

      • by paskie ( 539112 ) <pasky@nOSpAm.ucw.cz> on Wednesday September 17, 2014 @09:49AM (#47926943) Homepage

        But it's not actually clear why is it critical that PID 1 is simple (and if situation is so much worse with systemd).

        Xorg, which on desktop is as critical as init to keep running, is not really simple.

        kernel, which is also as critical as init to keep running, and it is *much* *much* more complex than systemd. systemd is not at the "bottom layer" of the system, there's the whole of kernel underneath still.

        And one common myth is that systemd has these so many features and systemd is pid 1 therefore pid 1 is this huge bloated monster that does udev, logging and NTP, right? Wrong; actually, just the core bits of systemd run in pid 1 and the rest is compartmentalized in a bunch of separate daemon processes.

        So, this "increased complexity" issue is not really as bad as it sounds, realistically.

        • by jeremyp ( 130771 ) on Wednesday September 17, 2014 @11:38AM (#47928459) Homepage Journal

          The argument is that, if pid 1 dies, everything dies. Also a big pid 1 presents a big attack surface for nasty people.

          Of course the exact same argument applies to a kernel: if something goes wrong in the kernel, everything dies and a big kernel presents a big attack surface to nasty people. However, I observe Linux is not a microkernel but it has a reputation for both reliability and being relatively secure. On the other hand, the quality of the people developing the kernel seems to be higher than those developing systemd, or at least that is the perception I get from reading all the hate on the Internet.

        • Re: (Score:3, Informative)

          by drinkypoo ( 153816 )

          Xorg, which on desktop is as critical as init to keep running, is not really simple.

          Never go full retard. X is not even remotely as important as init. For one thing, if X dies, who will restart it? And do we really want computers that explode when the GUI dies? I, for one, would like network services to terminate gracefully. The whole idea of TCP/IP networks, the dominant network used with Unix, is peer-to-peer. I may well run both services and clients on my machine. If X dies, the clients may die (if they're not text and running in screen) but the servers won't.

          kernel, which is also as critical as init to keep running, and it is *much* *much* more complex than systemd. systemd is not at the "bottom layer" of the system, there's the whole of kernel underneath still.

          So the argument is that sin

        • by putaro ( 235078 )

          Untrue. I've had the X server hang up and I've logged in via the network and killed it and restarted it. I can't restart systemd without restarting the whole system. Furthermore, I don't run the X server on our mission critical machines.

      • by Peter H.S. ( 38077 ) on Wednesday September 17, 2014 @10:25AM (#47927305) Homepage

        It's not a religion, it's a principle. When it makes sense, you put it aside and get work done. The argument against systemd is that it doesn't make sense. systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.

        You can't seriously claim that systemd provides nothing that can't be done by script based init systems, shell scripts and existing daemons, logind is just one example (ConsoleKit is a dead project with no alternative).

        But it would be an interesting project to make a Linux SysVinit distro that tried get feature parity with systemd, so that daemons could utilize the kernel "namespaces" and "capabilities" to massively strengthen security, or have a total supervision chain of all processes, including PID1 etc. There is so much good stuff in systemd that the SysVinit-like init distros could clone.

        That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.

        Isn't that argument just trying to make a virtue out of the fact, that SysVinit and the like, are totally crude and primitive init systems that are unable to anything much of interest?

        All the analyses I have seen shows that moving crucial processes into PID2, just makes everything more fragile and opens up security holes.

        I think that there are actually very good design reasons for why systemd is designed like it is.
        It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages, since it can act as a mediator between kernel features like cgroups and "capabilities" and the processes it controls.

        • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday September 17, 2014 @11:52AM (#47928683) Homepage Journal

          You can't seriously claim that systemd provides nothing that can't be done by script based init systems, shell scripts and existing daemons

          Yes, yes I can. And I did.

          logind is just one example

          Does nothing a script can't do

          But it would be an interesting project to make a Linux SysVinit distro that tried get feature parity with systemd, so that daemons could utilize the kernel "namespaces" and "capabilities"

          Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.

          Isn't that argument just trying to make a virtue out of the fact, that SysVinit and the like, are totally crude and primitive init systems that are unable to anything much of interest?

          No. That is the virtue. They are simple. Simplicity is still a virtue.

          All the analyses I have seen shows that moving crucial processes into PID2, just makes everything more fragile and opens up security holes.

          Making PID1 more complex makes everything more fragile and opens up security holes.

          I think that there are actually very good design reasons for why systemd is designed like it is.

          NIH

          It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages,

          This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.

          • by Peter H.S. ( 38077 ) on Wednesday September 17, 2014 @01:32PM (#47929863) Homepage

            logind is just one example

            Does nothing a script can't do

            Do you really think it is a serious argument is that you could re-implement "logind" as a bash script? We are talking serious hardcore system stuff here, which is why no-one have made an alternative to "logind" or "ConsoleKit" despite upstream projects have pleaded for such a program for several years.

            Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.

            You are seriously misinformed on how systemd works and what it can do:
            It uses kernel namespaces and capabilities to protect the system; this is on top of SELinux etc.

            Here is a general overview:
            http://0pointer.de/blog/projec... [0pointer.de]

            Here are some of the config options for the daemons you can use. See "CapabilityBoundingSet=" for one way of using kernel "capabilities":
            http://0pointer.de/public/syst... [0pointer.de]

            There are so many freaking cool security features in systemd. As time goes by, developers, distro maintainer, and systemd administrators, can add more and more options to the running processes, like "NoNewPrivileges=" to prevent privilege escalation, or "ProtectHome=" to prevent malware and exploited processes from stealing info from /home, even if they otherwise had permission to read in home.

            All this great new stuff can be turned on and used by adding a simple keyword to a structured text file. As time goes by, systemd distros will become ever more hardened.

            It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages,

            This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.

            Well, it does need to be handled somewhere; if you want features, you will get complexity, it is that simple. But as explained, the features and complexity isn't running in PID1; PID1 (systemd) is just a hub for relaying those features to other processes.

            I really think so much of the systemd opponents talk about "Unix way" and "PID1" should be simple, is hand waving to gloss over the fact that the non-systemd distros have no feature parity with systemd to speak of; SysVinit is crude and no one in their right mind would design a init system these days with executable config files. Service configuration files should be non-executable text only.

            General and vague criticism against systemd really doesn't convince anybody. Anyway, the Linux community have spoken with a large majority of Linux distros using systemd in the future.

            If SysVinit systems really have all the features of systemd, just much better because they are simpler, you would expect a "SysVinit" boom in the future with lots of developers and users.

            Personally, I think the systemd opponents are too concerned with negative campaigns against systemd, that they entirely forget to code any alternatives, so I predict ever more distros like Slackware abandoning script based init systems; they simply don't have an alternative.

      • by slack_justyb ( 862874 ) on Wednesday September 17, 2014 @10:34AM (#47927401)

        The complaint is that the process at PID 1 should be simple.

        That's just passing the buck. What you don't do in PID 1, needs to be done by PID 2 or 3 or 4...

        One has to understand that system start up is a complex task. Systemd, sysvinit, launchd, and what-not are just a matter of optics, no matter which one you choose, you are only changing how you look at the problem, you aren't making the problem any easier. That's the important thing to remember, that all of these inits are just different views on how to solve the problem. No matter how many times you break the process up (into PID 4 through 380), it's still a complex task that needs to get done.

        That said, sysvinit comes with the idea that you're going to have a lot of people looking inward at what's been done historically, they're going to make really useful tools, and the expectation is that those that follow will use those tools. That's nice and there is a real benefit for that, but that's not what vendors are going after, that's not what third-parties want, and that's not what end-consumers want. The only people that sysvinit caters to any more is developers and neck-breads. Vendors are going to write their own tools for start up. Third-parties are going to package up the process into something that can be simply delivered to the customer. Standard end-users just don't give a shit so long as the screen comes up. Heck, even server admins won't really care so long as management can still log in. There just isn't clientele for the old way. That's not to say that the old way isn't useful, but honestly you are asking a bunch of Pepsi drinkers to switch over to Coke for just the sake of "it is easier to make."

        SystemD puts all the cards closer together, this allows smaller teams to do useful stuff, and let's face it, the number of people writing kernel, sub-system, and start up code is only going to keep dropping. The hotness is much, much higher up. Vendors like systemd because it works better than script->call program in their deployment cycle. Now they can use systemd reporting to bubble back up into the UI as oppose to writing to some arcane log file. No one can defend the old log files, they seriously were so confusing that there are companies that you can hire and tools that you can buy that can turn your log file into something easier to read. That's just indefensible. I'm not saying that systemd is some magical power that's turned a turd into gold (starting up a system is still a pain in the ass), but it serves a wider group that more than likely (as all the neck-beards die off from old age) will be maintaining this whole thing in the longer term and simplifies something that has gone from, "it was good and easy" to "holy crap! The log file is 23MB!!" Back when we were starting up an FTP server and that's about it, it was great, but now that every sub-system from the kernel feels a need to write to the log on top of everything else that you vendor starts up, it's just a flipping mess.

        It's important to remember the Unix way, but systems have gotten so complex we just don't do it that way in reality anymore.

    • by Arker ( 91948 ) on Wednesday September 17, 2014 @08:58AM (#47926405) Homepage
      I think there is a major difference between having a big possibly over-complicated application program in userspace, and putting something like that in a critical spot in the system itself.

      If your application program has a flaw, it's probably not a huge deal. Maybe it crashes occasionally. You save often, you have autosave, it's not a big deal.

      But a system component that can crash the system, render it unbootable, hand control to a hostile third party, etc - it's much more important in that case to keep things clean and proper to keep the machine itself stable.

      Part of the disconnect between the Sysd cabal and the traditionalists here is about what we mean by the machine. We are often running linux on bare metal as our workstation. From what I have been told, they typically run it in virtual machines on server farms instead, and use Apple workstations. So from their point of view, it is just another application, and it shouldnt be a big deal to restart it occasionally - especially after they put so much work into improving boot times. But from our point of view, we dont care much about fast boot times, we want a stable system that doesnt need to be rebooted all the time.
      • by kthreadd ( 1558445 ) on Wednesday September 17, 2014 @09:00AM (#47926435)

        Are you suggesting that Systemd is prone to crash?

        • by jedidiah ( 1196 )

          It doesn't even need to be "crashing". It could simply be "user error" incurred because the system is more complex, more difficult to deal with, and new and interesting "user driven" failure cases have been added.

          Upstart is a real peach in that regard. I've blown my toe of with it already. If SystemD is anything like that, no thanks..

        • If its doing more than it should be then yes, theres more code that could have bugs, unhandled exceptions, etc.

          Its the same logic thats applied when hardening a system, minimize what it is running so there is less that can be attacked / have a bug / crash.

    • any other complex program that isn't formed from a bunch of small "do one thing well!" utilities

      Pipeline intercommunication aside, most large programs of any quality *are* formed from a bunch of small "do one thing well" utilities. They're commonly called "libraries".

      Please tear up your Richard Stallman fanclub cards because what little software he's written has mostly been Emacs.

      Emacs is *one* thing he's written. Wasn't he responsible for the first versions of pretty much *all* the GNU userspace tools? You

      • Re: (Score:2, Offtopic)

        Pipeline intercommunication aside, most large programs of any quality *are* formed from a bunch of small "do one thing well" utilities. They're commonly called "libraries".

        Hit it dead on.

        People don't want the added work of making things work. It's like building a floor: you need to strip off the old finish, reenforce the subfloor, ensure the floor is level, pour thinset, roll ditra, pour more thinset, lay tile, clean, and grout. Some folks leave old linoleum or hardwood flooring, claiming it's stable, and then pour self-leveling compound or just screw down concrete board, then put tiles on top. Some just cement tile straight to the floor, or pour SLC and cement the til

        • by itzly ( 3699663 )

          It can be a collection of utilities all dependent on each other, running 3 or 5 or 15 services all communicating with each other, all to bring up the system and supply system state management. This is the simplest and easiest way to make a complex system

          Why not make 3-15 modularly written sets of source files, and compile them into a single binary ? It's hardly more complex than 3-15 separate programs, and it makes communication of structured information a lot easier.

          • It can be a collection of utilities all dependent on each other, running 3 or 5 or 15 services all communicating with each other, all to bring up the system and supply system state management. This is the simplest and easiest way to make a complex system

            Why not make 3-15 modularly written sets of source files, and compile them into a single binary ? It's hardly more complex than 3-15 separate programs, and it makes communication of structured information a lot easier.

            And is in fact, how SystemD is put together and intended to be expanded, for better or worse.

    • by mlts ( 1038732 )

      Religious sentiments aside, systemd scratches a number of itches that eventually needed to be addressed. The main one is parallel startup of daemons. On a SSD based machine (and note, these are anecdotal runs), CentOS 6.5 takes about a minute to fully boot to a login prompt. On CentOS 7.0 with systemd starting anything that isn't relying on another process at the same time, well under ten seconds. Similar with a shutdown.

      The second item is being able to place processes in containers and set limits befor

      • by jedidiah ( 1196 ) on Wednesday September 17, 2014 @09:55AM (#47927015) Homepage

        > The main one is parallel startup of daemons.

        This leads to a Windows style boot process where things might not even be ready when they are needed. I see this with one of my more complex Ubuntu boxes. It HALTS the boot process. Now I have to find a way to manually repair that so that box can boot on it's own without human intervention.

        So you have this mindless following of the Windows mentality where it doesn't matter so much if the machine is useful. It just needs to appear to be useful for marketing purposes.

        "Booting fast" is a pretty low priority item to trash a core system process over.

    • by Kludge ( 13653 ) on Wednesday September 17, 2014 @09:11AM (#47926545)

      The logging is a perfect example. Why do I have to learn a new program (journalctl) just to read the system logs? What if I had to learn the syntax of a new program to read the logs of every program that I used? That would suck. If openvpn and mysql and httpd and sshd all had their own little program that I had to use to read their logs, I would give up using Unix.
      I already have a program to read all logs, more or less. And I already have a program that searches all the logs, egrep. Yes, I had to learn egrep syntax, but now that I know it, I can do almost any search imaginable of any program's logs. Except systemd.

      • You don't have to. If you really want your old way then just have journald pass everything along to syslog and it's back to normal.

        • Re: (Score:3, Insightful)

          by Arker ( 91948 )
          "You don't have to. If you really want your old way then just have journald pass everything along to syslog and it's back to normal."

          Unfortunately that's not quite true. You *can* configure systemd to spit out text logs as well as the binaries but that is a delayed process, so in the one case where you MOST want text logs (where a crash has occured with the file open) it's absolutely worthless.

      • by mlts ( 1038732 ) on Wednesday September 17, 2014 @09:20AM (#47926633)

        That is a valid complaint. Adding functionality so startup is parallel is one thing. Having one's own binary log format [1] is a big downside. To boot, rsyslog uses cryptographically signed logs. That means that I lose protection on systemd's logs because in theory an attacker could tamper with those. Should the logs go to rsyslog, the files either will show tampering or be missing.

        This also prevents logging to a remote machine as well.

        I'm not a fan of binary logs. Even AIX will log stuff from the errpt command if you turn on the right syslog settings. Binary logs make a program like Splunk a necessity, and that is not a cheap tool once you start talking about gigs a day hitting your index servers.

        [1]: I don't like the "pro" for it saying that journalctl can give you just the info that you need. For the info I need, I have grep, egrep, and many other tools.

      • by Peter H.S. ( 38077 ) on Wednesday September 17, 2014 @09:49AM (#47926959) Homepage

        The logging is a perfect example. Why do I have to learn a new program (journalctl) just to read the system logs? What if I had to learn the syntax of a new program to read the logs of every program that I used? That would suck. If openvpn and mysql and httpd and sshd all had their own little program that I had to use to read their logs, I would give up using Unix.
        I already have a program to read all logs, more or less. And I already have a program that searches all the logs, egrep. Yes, I had to learn egrep syntax, but now that I know it, I can do almost any search imaginable of any program's logs. Except systemd.

        Sometimes new stuff is actually much better than then old stuff. I was skeptical about binary logs until I actually tried it. The advantages of a indexed journal is overwhelmingly positive. "journalctl" is an extremely powerful logfilter exactly because of the indexed and structured logs.
        Systemd's journal also collects all logs in the same place, so no need to use "last" to read the binary "wtmp" log files, or locate .xsessionerrors and what not; everything goes into the journal.

        Also, all the usual text tools like grep, tee, sed etc. all works with the journal by the standard Unix concept of piping. "journalctl" simply enhances the Unix text tools.

        Give "journalctl" a serious spin someday; you may like it.

        • The problem... (Score:5, Insightful)

          by Junta ( 36770 ) on Wednesday September 17, 2014 @10:14AM (#47927203)

          People have reported corrupt log files. The result is all the data is unrecoverable. The complaints have been answered 'as designed'.

          When things are right, it works as intended. When things are bad, it can go far off the rails. Considering it is the system log used to debug what is wrong when things are off the rails, a full binary log is a dubious proposition.

          There are benefits to binary log, but they could have been done to varying degrees with structured text and/or external binary metadata, rather than a corruptable binary blob.

          • The journal is primarily append based, so it designed to be very robust against corruption, the log is also rotated whenever a corruption is detected. So usually the corruption you see are a single line that was malformed when writing because e.g. the daemon died unexpectedly; this happens all the time with text based logs, but because they have no inbuilt integrity checks like systemd, it doesn't get discovered.

            So in most cases you don't really loose any log info, and the rest of the log remains fully read

      • by Chris Mattern ( 191822 ) on Wednesday September 17, 2014 @09:50AM (#47926965)

        I already have a program to read all logs, more or less.

        In fact, you have *two* programs to read all logs. More and less.

    • If you really buy that principle and want to enforce it religiously, then please never use a web browser again (even Lynx!), not to mention any other complex program that isn't formed from a bunch of small "do one thing well!" utilities that are executed in a pipeline.

      If web browsers and other modern programs do not follow the "many small tools doing 1 thing well" model, that's only due to programmer mediocrity and market pressure.

      It would be a much better world if I could just replace the JavaScript-interp

    • If you really buy that principle and want to enforce it religiously, then please never use a web browser again (even Lynx!), not to mention any other complex program that isn't formed from a bunch of small "do one thing well!" utilities that are executed in a pipeline.

      You seem to think that those hating on systemd like having to use bloated, slow, barely-configurable, GUI-only, privacy-hemorrhaging browsers just to access their {bank/email/news/etc.}.

      The existence of some high-profile non-UNIX projects isn't an excuse to dismiss UNIX practices. In fact, popularity is often correlated with barely-adequate, lowest-common-denominator offerings (eg. pop music).

    • "Do one thing well" is how Unix kernel functions are written, and it's just plain a good idea. Systemd probably follows the first principle internally, many programs do.

      Creating production systems[1] out of single-purpose commands connected by pipelines is a different principle, and only works if you keep them pretty simple. It's not a prionciple, but it is how a lot of Unix scripts are written, NOT including the shell that glues the parts together, and not including all the more complex programs, like ed

  • If you know how systemd works, go to another thread, please only reply if you're ignorant and want to have an angry, ill-informed debate.

    Personally, I think you should be able to start and stop systemd when you want it.

  • systemd (Score:5, Informative)

    by war4peace ( 1628283 ) on Wednesday September 17, 2014 @08:47AM (#47926291)

    Sounds good. What is it again?
    I clicked links. Looked at the article. They all talk about systemd but none really define it, as in "systemd is this and does that, and is different because :reasons:".

    So for any other systemd-impaired readers, click this: http://en.wikipedia.org/wiki/S... [wikipedia.org] - because TFS, TFA and links from them don't tell you much in this regard.

  • An opinion which he expressed.

    "I think many of the 'original ideals' of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation. There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at some level, but I think it's also clear that it doesn't really describe most of reality."

    That sure sounds like an opinion to me. I suspect he stated he didn't have an opinion just so he would start a war among his fanbois.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      I think he just doesn't care about things that don't get in his way.

      A few weeks ago, when systemd would lock up the system if you turned kernel debugging on, he did have rather colorful opinions about systemd and the systemd developers who insisted that systemd was doing the correct thing.

  • Do it well (Score:5, Informative)

    by StripedCow ( 776465 ) on Wednesday September 17, 2014 @09:08AM (#47926501)

    If they're going to change it, I suggest they change it well.

    That is, support *functional* dependencies between processes, and caching of input/output. Automatic starting of processes when configurations change, etc. Right now, my computer has to reboot whenever stuff changes and some script does not handle the changes correctly (or simply does not run).

    Also, whenever I reboot my system, I don't know if I will get back the system that I shut down (some configurations may have been changed and may have broken my system without me knowing it, only to cause a nightmare when I reboot the system, which is usually the worst possible moment). That has to be fixed as well.

    • by Junta ( 36770 )

      That is, support *functional* dependencies between processes,

      Well, explicit stated dependencies are there. If you mean something beyond that, I get very concerned.

      caching of input/output.

      What i/o are you referring to? I/O generally is already cached as intelligently as the filesystem or block subsystem can manage. At filesystem or lower or inside the application are your opportunities to enhance things, not much room in between. If you mean cache data that is piped around or networked around, that is absolutely a horrible idea that is really infeasible unless it

  • by Anonymous Coward on Wednesday September 17, 2014 @09:08AM (#47926509)

    Now, the real question one should ask Linus is whether he trusts systemd upstream's "taste". The answer will be nowhere near as nice.

    The major issue with systemd is actually that we don't trust its upstream. They're known to cut (important!) corners since well before systemd (i.e. pulseaudio), and they have the "we know better" mentality.

    The last time Linus had to trust systemd to do something (udev component), it caused a massive (and deserved) flamewar which ended up with the kernel removing support for udev's firmware loader, and switching to an in-kernel firmware loader to bypass udev.

    • by gweihir ( 88907 )

      Well said. One problem here is that systemd indeed increases complexity significantly and decreases the flexibility and control of the system administrator. That can still result in a good outcome, but not with these people in control and it shows in numerous places already.

  • by DeVilla ( 4563 ) on Wednesday September 17, 2014 @09:12AM (#47926547)
    This may be the best endorsement for systemd yet.
    • by Savage-Rabbit ( 308260 ) on Wednesday September 17, 2014 @10:06AM (#47927131)

      This may be the best endorsement for systemd yet.

      Don't knock it, the "I have no opinion" principle has gotten millions of men through their marriages with a minimum of trouble. Mind you some things you have to have an opinion on, like for example "Does my ass look big in these jeans", your little brain is saying "Yesssss, acres an acres of ass and it's all mine... I love it!", your rational brain prompted by your survival instinct modifies that to "No, dear!"

  • There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at some level, but I think it's also clear that it doesn't really describe most of reality.

    You mean.... gasp! ... PostgresSQL isn't a shell script pipelining a bunch of sed/awk/grep/mv/cp commands? Minecraft isn't some big long awk script that calls perl when it runs out of gas? I never woulda guessed!

    Seriously though, and without belittling the value of the bunch 'o pipelined commands (especially for sysadmins), it's nice to hear someone clearly and concisely articulate this rather obvious reality.

    • by jedidiah ( 1196 )

      > You mean.... gasp! ... PostgresSQL isn't a shell script pipelining a bunch of sed/awk/grep/mv/cp commands?

      In terms of the larger systems that it is integrated with, that is EXACTLY what it is. It is a highly specialized application that does one thing well and leaves the scope creep for other programs that consume it's services.

      It may even be broken down into a lot of highly specialized background processes like Oracle.

  • After reading the comments, I noticed the following fortune at the bottom of /.

    Many people write memos to tell you they have nothing to say.

  • by Endymion ( 12816 ) <slashdot.org@thoughtnoise. n e t> on Wednesday September 17, 2014 @09:34AM (#47926785) Homepage Journal

    (paraphrasing a previous post of mine, becuase more people should see this)

    It breaks existing promises, and makes few new promises in return.

    There has been a lot of talk about the various technical problems with systemd and its developers inexperience-betraying design decisions. As bad as those are, they miss the larger point. There has also been a lot of very important talk about philosophy of design ("the unix way") that again shows how little experience the developers have and their disregard for the work people have already done and will have to do to fix the systemd mess.

    These topics are valid, but miss the larger problem that systemd represents and the threat it is to Free Software in the Linux ecosystem.

    ## The problem with systemd's design: embrace and extend [wikipedia.org] ##

    As an excuse for all the vertical integration Poettering's cabal have been busy aglutenating into what they still sometimes claim is "justs an init system" has been the laughable claim that systemd is in any way "modular". They claim that "modular" is a *compile time* feature, or some property related to the fact that they build several ELF binaries. This is not modular, because it does not represent some form of stable, well-defined API.

    What is an API (Application Programming Interface)? It's not a technical feature. It is not documentation that describes how to use some set of features. It is not a calling convention. So what is it?

    An API is a PROMISE .

    It is a social feature, not a technical one.

    The functions and documentation are just a particular implementation of that promise. The key attribute that makes an API an API is that it is a promise by the developer: "If you want to interact with some feature, this is the way to do so, because while other internal stuff may change at any time, I promise this set of functions will be stable and reliable".

    Binding previously-separate features into one project is bad design, by itself, the problem with systemd. The problem came when Poettering stripped down the barriers betwen features with the specific goal of removing established APIs (and breaking existing promises that developers relied on). His stuff may compile into various separate programs, but Pottering is very careful to keep various key interfaces "unstable" (despite being good enough for RHEL), specifically to not make any promise about how those interfaces will work in the future. He likes to call this hididng of interfaces "efficency" or "removing complexity". What he never mentions is that many of us used those promises, and by removing them he has at best forced others to do a lot of work to fix the breakage, or at worse made various features impossible.

    A good example is logind, which was absorbed into systemd just so promises about its behaviuor in the future ("stable APIs") could be removed.

    The reason many of us that have been watching Poettering's cabal for many years now suggest these changes are intentional and malicious are based on this. Occasionally removing features because of a technical need or bug or security requirement is understandable. Purposfully stripping out entire sets of features - that is, the features that allow other groups to develop with confidence that some feature they won't simply vanish - is something entirely different.

    If MS acted like Poettering's cabal and removed a formerly-public API that competetors used - while promoting their own product that happens to use internal, not-publicly-promised APIs, the world would be screaming "monopoly". This happened, and resulted in several high-profile court cases.

    ## systemd threatens the GPL ##

    It goes without saying that many people would like to distribute various GPL licenced software and not be bound by the terms it requires. The fact that some of these same people use the courts to threaten people who do the same to their software is noted, but off topic for now. The problem is t

    • Binding previously-separate features into one project is bad design, by itself, the problem with systemd.

      Why? Justify that statement without using any reference to the UNIX way or it being the way things have always been designed.

      IMHO a coordinated set of functions that are used in a common way should be combined. Why is it that to parse a log file I need to run grep, and sed, and all these other utilities in a continuous pipe? For that matter why should the tail command be able to open a file, is that against the unix way because everything should be grepped into it?

      I'm getting sick of using 1000 different ut

  • by organgtool ( 966989 ) on Wednesday September 17, 2014 @09:59AM (#47927049)
    Much of the systemd debacle has been a clash of mindsets between the old Unix guard and a newer generation of developers focused on integration. The old Unix philosophy of each module doing one thing and doing it well allows developers to take a bottom-up approach and glue existing modules together to provide solutions rapidly. However, as Linus alludes, this method doesn't scale well, especially as many modules are cobbled together to implement much more complicated tasks. At a certain point, a top-down approach works a lot better for those larger tasks. The top-down approach provides a more user-centric look at how to create a well-integrated solution and may use existing modules just as would be the case in the bottom-up approach. Since it is more focused on the user's perspective (rather than the developer's perspective), it tends to realize shortcomings in existing modules earlier and therefore may lead the developers to make the decision to write some of their own modules rather than mostly relying on extending modules well-beyond their intended purposes.

    Systemd takes a top-down approach, and while some may argue that it's design leaves a lot to be desired, that doesn't mean that a bottom-up approach is automatically better. Based on the dependency tree, this appears to be a project that started out with few requirements and quickly grew after it was deep in the implementation phase, which is a problem regardless of either development approach. And then you have just bone-headed moves on top of that such as using binary logging. In any event, it's being widely adopted, it's here to stay, and I'm sure it will continue to remain controversial.
  • by Lilith's Heart-shape ( 1224784 ) on Wednesday September 17, 2014 @10:41AM (#47927453) Homepage
    It runs in user space, not kernel space, so it isn't really his problem. :)

If money can't buy happiness, I guess you'll just have to rent it.

Working...