Slashdot Mirror

← Back to Stories (view on slashdot.org)

Torvalds: No Opinion On Systemd

Posted by Soulskill on from the linus-not-swearing-at-people dept.

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."

9 of 385 comments (clear)

  1. well said! by BrianBeaudoin · · Score: 4, Interesting

    I approve of this message.

    1. Re:well said! by gbjbaanb · · Score: 3, Interesting

      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 this - complex systems *do* work this way, lots of small pieces interfacing with each other is the way complex systems work. Whether its a GUI app where each control is an independent object, or an internet where each website is independent or a business where labour is divided up into divisions or departments.

      What happens when you try to make a complex system that is a tangled web of interconnections that have too many dependencies with each other is a system that does not work.

      DRY, SOLID principles are all current buzzwords, but the truth behind them is that complexity is managed by standard interface protocols that allow components to be practically self-contained. UNIX got this right.

    2. Re:well said! by keltor · · Score: 3, Interesting

      Which if you take a look at the systemd source code you'll find it's that way as well.

  2. Simple set of pipelined utilties! by CajunArson · · Score: 5, Interesting

    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.

    --
    AntiFA: An abbreviation for Anti First Amendment.
    1. Re:Simple set of pipelined utilties! by kthreadd · · Score: 3, Interesting

      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.

    2. Re:Simple set of pipelined utilties! by slack_justyb · · Score: 4, Interesting

      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.

  3. Re:Yes, pipelined utilities, like the logs by Peter+H.S. · · Score: 4, Interesting

    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.

  4. Re:Misleading slashdot headline by Anonymous Coward · · Score: 3, Interesting

    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 stop.

    This in contrast to how if one want to slot in wayland but still use X, one can install a xwayland driver in Xorg and restart X. That is how you do changes with minimal disruptions. Meaning that you don't have to rebuild the whole house because you want to replace the front door.

    Any other init besides systemd can be slotted in or out by changing the init command and making sure the proper daemon configurations are in place, the daemons themselves don't care. With systemd the recommend to rewrite/recompile daemons to use a systemd specific API because the non-api options are all over the place: http://ewontfix.com/15/

    So right now it seems that the people cheering systemd on are daemon developers, and perhaps cloud service "admins" that want to drop in their preferred set of "containers" into a IaaS like Amazon's EC2 and bootstrap their service from there.

    And those making the warning posts are the admins of traditional servers, that want and prefer a deterministic system where they can tell where things broke by what stage things are stuck in.

  5. systemd is objectionable because: by emil · · Score: 3, Interesting
    • - 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.