First, it's not clear what loss of interface compatibility you're lamenting. systemd supports most of the same traditional CLI utilities, syslog protocol (both in and out of the journal), inetd-style service activation, and SysV-style init scripts (including the LSB metadata). The journal's CLI supports text streams compatible with all the standard shell tools.
That said, needing to replace many tools at once isn't inherently evidence of a monolithic design. It can also be a sign that the boundaries of functionality or interfaces between tools have changed.
For example, we added the journal with a new API and a compact on-disk format. Necessarily, we have to have a new daemon to receive messages (journald), a new tool for browsing the files as text streams (journalctl), and a new C header for doing the structured logging. The journal would be rather useless for a long time if added in program by program over years. Nothing in this design is more monolithic or less Unix-y than what it replaced, but it did require replacing all of those parts at once to get end-user value.
There is nothing in this statement about how many programs you should change at once:
"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."
systemd is not a single "program," nor is splitting an implementation over many version control repositories (a thing many people seem to fixate one) a sign of good, modular design.
> That way the different programs can be written by different people at different times, replaced one by one, etc
Many of the interfaces for systemd are well-defined: the D-Bus API, the native journal field format, discovery of inherited sockets for activation. Those latter two already have multiple implementations talking over the defined interfaces, often for scripting languages that don't want to link to the C functions systemd exports or for projects outside the main systemd repository. We're currently looking at having scripting languages like Python manage services directly over D-Bus as well to enforce stability and completeness for those interfaces.
The Python-based boot graph analysis tool that talks to systemd over D-Bus is about to get replaced with a completely new implementation in C by a different author.
So, systemd has already demonstrated the ability to substitute implementations interfacing over well-defined boundaries.
Therefore, I think it's unnecessary to replace programs one by one rather than as a suite. Nor does the Unix philosophy you quoted say anything about this concern.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds