Choose your side on the Linux divide

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 out InfoWorld’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.

Mike Gancarz sums up the Unix philosophy:

1. Small is beautiful.
2. Make each program do one thing well.
3. Build a prototype as soon as possible.
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use software leverage to your advantage.
7. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter.

We have built the Internet and all modern Internet services on those principles. Systemd’s design and implementation violates nearly all of them.

Should it be a surprise that so many long-term Unix and Linux developers, architects, and administrators recoil at the thought of something like systemd? It might seem that the design of systemd purposefully dispensed with the wisdom of 45 years of Unix development and struck out in a different direction just to spite the old guard. Add to that the overtly narcissistic public attitudes of the project’s lead developers and evangelists, and you have both this cloud over Linux and a schism in the Linux community. It’s not pretty at all.

We’ve seen similar events in the past, where core software was “updated” or “improved,” yet the replacement was overbuilt, poorly designed, or otherwise inferior to its predecessor. Take a look at NIS and NIS+, for instance. NIS is still with us. Its much-ballyhooed replacement, NIS+, withered and died under the weight of a terribly overcomplicated design.

That fate is still an option for systemd. It might come to pass that systemd is widely adopted by distributions built for desktop use, but is not used on servers. Maybe it will be redesigned to be more in line with Unix foundations and finally gain some acceptance — or maybe it will wither and die like NIS+.

One thing to watch for from here on out is the adoption rate of RHEL 7. That will tell much of the tale. RHEL 6 has support for the next six years, and it will be very interesting to see how many heavy Linux users stick with version 6 rather than move to 7 and introduce systemd into their networks.

The old saying, “Those who don’t understand Unix are doomed to re-invent it — poorly,” has been used many times when discussing Windows. It’s disturbing to see it now used to describe Linux.

This story, “Choose your side on the Linux divide,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.