Sonntag, 4. Februar 2018

Wanted: User friendly, maintainable, secure

Quite a few people have asked the question, why systemd has "won" the "init wars".

Because, even if its proponents might claim otherwise, systemd is not a product of quality software engineering. It has large internal module interdependencies and often uses quite questionable, hard to maintain coding patterns. The solution paths chosen often lean towards complexity rather than maintainability.   The APIs it exports  are often designed with a careless disregard for separation of concerns. This is accompanied by a lack of design documentation and developers using aggressive rhetorics to avoid giving proper rationale for their design decisions.   On top of that add syntactically and semantically poor configuration formats that are built with implicit, often underdocumented automagic. Systemd has too little internal structure and much too much nonchalance with regard to interface semantics.

And, yet, almost nobody cares.

Because systemd makes a lot of features available at our fingertips that you previously needed to hack into init scripts, needed to configure your logging for and/or were not available at all using proper command line tools.

For the casual administrator or devops person, the fact that those feature are often implemented using large spaghetti functions in a largely monolithic code base, that some of systemd's implementation details are clear security regressions from previous SysV behavior does not matter. Basically, given a simple interface that promises ease of use and lies to you about the actual implementation quality, the quite a few members of the community hashave willingly walked towards the lies and even spreads them unverified.

And that may be also one of the reasons, there is no real, clean alternative to systemd, yet. Implementing the feature set that systemd provides in a clean (maybe even portable) manner without taking more than the usual amount of shortcuts is a huge task. It requires a lot of thinking, it requires a lot of interface design, and --in the end-- a lot of code.

And it is not fun competing against systemd, because systemd mostly seems to only pays lip service to proper software engineering. Competing against systemd is essentially competing against a (habitual) cheater.

And you, the community" the do-ocracy, favors the cheat, because it gives you results more quickly. Code counts even if its shitty, as long as it's working.