| Some of his arguments look a little bit botched. For example:
> Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic" Well following Wikipedia (http://en.wikipedia.org/wiki/Monolithic_application) means either a non-modular application, or a self-contained application. In this sense either his counter-argument is simply wrong, or the examples list he gives at the and is wrong. > Fallacy #4.1: "Unit files reduce complexity" Here he compares the ca. 275.000 LoC of systemd with the 10.000 LoC of shell scripts used as initscripts on Debian. Lets ignore that the 275.000 LoC contains much more than the unit management in the systemd daemon. But why are the bugs always in the scripts and never in the shell as he claims? And sorry, I don't take his word that C is always more error prone than the shell. This is true when the shell is used for its intended purpose: to start commands, pipe btw them and having a little bit of flow control. For everything else you surely want to have a general purpose language. > Fallacy #7: "Systemd gives you socket activation!" Well, according to boot charts, socket activation is not only a marketing gimmick. EDIT: Add Fallacy 7 |
The former depends on internal interfaces, where individual modules help separating concerns but can't be swapped out or reused in other contexts, whereas the latter relies on formal interfaces, allow components to be swapped, and promote reusability. (Also, the former can be monolithic or not, but the latter can never be monolithic.)
"Unixy" is sometimes used, but it's not a great term.