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.
[ Also from InfoWorld's Paul Venezia: systemd, harbinger of the Linux apocalypse? | How-to: Get started with Docker | For the latest practical data center info and news, check outInfoWorld's Data Center newsletter. ]
Fundamentally, I think this exposes a separation of the Linux community: between those who were deep into Unix before Linux came on the scene and those who came later. I can't help but think that a number of younger developers and admins are missing key elements of how Unix-like systems were designed and how they functioned before, say, 1998 -- when Unix was for servers and high-end workstations, not desktop systems or laptops.
As I alluded to last week, we've had many extremely good reasons to use SysVinit all these years. It's extremely adaptable, easily maintained, and very simple to debug. To some, it looks like a ragtag collection of shell scripts that should be condensed into a set of sleek, modern binaries -- now known as systemd. To others, systemd is the answer to a question nobody asked. SysVinit wasn't broken, and it didn't need to be fixed -- certainly not by an option as all-encompassing and dependency-laden as systemd.
I truly don't wish to speculate on how the elders of Unix who have passed on would react to something like systemd. I do, however, find it hard to think that Dennis Richie or Jon Postel would embrace systemd and its 1MB binary running at PID1. We need only look at the pillars of computer software design to see why:
Much of the power of the Unix operating system comes from a style of program design that makes programs easy to use and, more important, easy to combine with other programs. This style has been called the use of software tools, and depends more on how the programs fit into the programming environment and how they can be used with other programs than on how they are designed internally. [...] This style was based on the use of tools: using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs.
-- Rob Pike and Brian Kernighan, Program Design in the Unix Environment, 1984
The design of systemd violates this statement completely. Doug McEllory's statements on the Unix philosophy also clash with systemd's design:
This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface
No comments:
Post a Comment