Journal phantomfive's Journal: 9 - systemD: Interfaces last longer than code 2
This entry discusses the benefits of good interfaces, then gives a (overly simple) metric for how to recognize them. Then it ties it back to systemd.
The 'unix way' is built around solid interfaces. The actual code to Unix is mostly gone (unless you use SCO or something), but the interface lives on with multiple (mostly compatible) implementations. The interface long outlasted the code. (NB: Unix hasn't always had good interfaces in every place, Unix isn't perfect.)
Another example of a good interface is the Berkeley networking API. It's not user-friendly, but as a low-level 'plumbing' API, it is extremely flexible and effective. It spread and now every OS has an implementation. (That is, every OS more complex than some stuff at http://wiki.osdev.org ). The original code is gone, but the interface will be around for a long, long time.
There are plenty of examples of interfaces in Unix. It doesn't have to be an API.
If you consider a programming language to be an interface between a computer and a human, then think of the C compiler. The original C compiler is no longer in use, but the interface was designed clearly enough that even intentionally bad IOCC code from 30 years ago still compiles.
Cron is another interface, as are the basic CLI commands like ls, mv, ps, grep, etc (which have now taken over almost everywhere....the interfaces, not the original code). The pipe is a powerful interface that seems obvious now, but wasn't at the time......the pipe makes it possible to take the output from any program and send it as input to any other program. That is impressive.
"Robert Metcalf [the inventor of Ethernet] says that if something comes along to replace Ethernet, it will be called Ethernet', so therefore Ethernet will never die. Unix has already undergone several such transformations." -- Ken Thompson
How do you recognize a good API? It's tough, but one thing is sure, a good interface allows easy swapping of components. If it doesn't allow easy swapping of components, it's not a good interface.
"Linux has always been multiple components that you can chose which one suits you best - whether its vi or emacs, gnome or kde, sendmail or postfix, apache or nginx, etc. This is a good thing, where you can swap out component A for B for any reason, and keeps the project competing with each other to get better and better." -- gbjbaanb.
When your component can be easily replaced, because the interfaces are good, it can only compete on its technical merits. That is how you will recognize the best interfaces, because when they are evaluated and put into use by skilled programmers, the best ones will come to the fore.
Time to wrap this back to systemd.
Systemd has gained traction as a init engine because the "unit file" interface provides benefits that a lot of people like. If the "unit file" interface proves durable, then it will last longer than the code. Interfaces can be immortal, code can not.
Throughout systemd there is a lack of understanding of proper interfaces. Making the GUI depend on a particular init system is a particularly obvious example of poor design, but the code was written from a 'code first' perspective rather than an 'interface first' perspective.
Lennart Poettering is a fine programmer. (His code is readable, and let's be honest, anyone who can hack on the Linux kernel has skill. Furthermore he is passionate about it). I don't think he really understands interfaces, though. When he does, his code will move up to next level.
Nicely written (Score:1)
Re: (Score:2)
My next piece is going to examine how stable systemd interfaces are over time. I would have written it already, but it's not an easy thing to do