Open letter to the Linux World

how about going through the points mentioned in Choose your side on the Linux divide and analyzing how systemd violates them:

Quoting:1. Small is beautiful.

systemd is more than 60 individual binaries which all do different things. we'd have to look at each one of them to decide if they are small enough.

Quoting:2. Make each program do one thing well.

which of the more than 60 binaries does more than one thing that could better be done by separate programs. (edit:) or are there cases where multiple binaries depend on each other to do one thing together, which would be better done if it was one combined program?

Quoting:3. Build a prototype as soon as possible.

not sure if this was violated. but since the code is released it is no longer relevant.

Quoting:4. Choose portability over efficiency.

here we have a candidate. systemd is not portable. though i don't know if that relates to efficiency. as far as i understand it is not portable because it depends on other non-ported tools or libraries. making it portable would require to replace their functionality and potentially violate point 2.

Quoting:5. Store data in flat text files.

journaling fits this point. but it can send logs to syslog which produces text files. as mentioned above, the only problem here is that it adds an additional intermediate program, not that it denies us access to flat text logs.

Quoting:6. Use software leverage to your advantage.

i don't know how that should apply.

Quoting:7. Use shell scripts to increase leverage and portability.

the question here is where to draw the line. this point is highly debatable.

Quoting:8. Avoid captive user interfaces.

i don't think this is violated.

Quoting:9. Make every program a filter.

no clue here. but i don't think this really means everything must be a filter, unless you want to restrict all your editing to sed. so the question again is: where to draw the line? what should be a filter, and what shouldn't be?

greetings, eMBee.

Bob_Robertson: depends on what you expect the 60 binaries to do.

if all that systemd was doing is to replace init, then 60 binaries would be ridiculous. but that's not the case, so before we can judge that we need to look at the purpose of each of those binaries.

i do expect that each binary provides in independent function that does something useful, not only for systemd itself. (i remember to have read somewhere that some of the things that come with systemd are useful even without it)

compare that to fish vs bash for example. bash provides a lot of built-in functions. fish instead comes with dozens of separate executables and has only a few functions built in, namely those that wouldn't work if they were running as a separate process, like cd.

now which one is closer to unix philosophy of keeping things small and only doing one thing? fish, i would think.

the next question is whether it makes sense for all these programs to be delivered together with systemd. i can't tell, because i haven't yet looked at what they are.

but as they are developed by the same team, and probably have related functionality, i don't see why not.

a suitable comparison might be the coreutils package. it comes with more than 100 executables.

does that make coreutils violate unix principles? would you rather have each of those 100 programs distributed separately? would you expect each of them to be developed and maintained by a different person or group? i think not.

so just because systemd is aggregating a lot of functionality in separate programs, does not seem a violation of keeping things small.

greetings, eMBee.