On Thu, 2013-03-28 at 08:32 -0600, Andy Bradford wrote: > Can you point me to this overwhelming plethora of system administrators > who were clamoring for systemd?
I count myself among the sysadmins who welcomed systemd. I wouldn't say I clamored. Frankly, as I get older I get lazier and the thought of learning something new didn't excite me. But the more I read about systemd the more I realized it was qualitatively better than SysV or Upstart. Here's how I would characterize the history of *nix booting: In the beginning was BSD-style init. I was simple and beautiful. Tragically it didn't meet everyone's needs so SysV was invented. When I was still teaching Linux classes, I preached the gospel of SysV. "It's all just shell scripts! If you ever have a problem, just read the script. Awesome!" But it was a lie. I couldn't admit it to myself at the time, but whenever I dug into a boot script I always came away feeling a little more disgusted. Sometimes it was "I can't believe something so trivial requires so much boilerplate". Other times it was "this app is so stupid, I can't believe how much shell script, duct tape, and chewing gum is required to manage it". (Aside: it is always a mistake for a daemon to require a command line option because there isn't an equivalent config file option.) Don't get me wrong. I love shell scripting. It's an adrenaline sport, like chess with higher stakes. I imagine running with the bulls in Pamplona must feel similar. But let's be honest, shell is a horrible, miserable, no good, error prone language. Reading boot scripts scares me. Invariably I either end of frighten by how fragile the script is, or frightened by how complicated it must be in order to be robust. Admit it, if SysV were so great then why have so many alternatives been created? daemontools, runit, supervisord, etc. Which brings us to Upstart. Like a hot knife through butter it stripped away cruft and proved just how inadequate and complicated SysV was. No more fragile scripts. No more implicit dependencies hiding behind start/stop numbers. No more forking thousands of times just to start a couple daemons. Of course Upstart had it's own problems. It's event-based approach made faster boot possible, but it was thinking about dependency the wrong way. Instead of "networking is configured, now I can start the web server" it should be "I want to start a web server, so I'd better configure networking". Inspired by Upstart, systemd's creators realized the time was right for bolder improvements. Whereas previous solutions had deliberately crippled themselves in the name of portability, systemd takes full advantage of Linux-only features. Let's pick just one example: pid files. They suck. Have you ever been bitten by stale pid files? I have. While some have tried to use ptrace to track children, it's never caught on because it's too fragile. In contrast, systemd's use of cgroups is brilliant. Obvious in retrospect, but brilliant. I still remember the "of course!" feeling the first time I read about it. Buffering log messages? Of course! Integrated container support? Of course! Integrated filesystem management? Of course! I will admit I'm not wild about parts of systemd's interface. I think it's tragic that so many of the technical details are a giant step forward but systemctl feels deliberately obtuse sometimes. Oh well, can't win 'em all I guess. I will also admit that portability to other *nix flavors is important to some people. But I'm not one of them. Instead, I wouldn't point out that systemd is finally helping to increase the unity of Linux. While it does includes allowance for different ditros, it has erased alot of the pointless little differences between distros. Now that's what I call portability! /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
