On Fri, 10 Oct 2014 11:05:19 -0500 (CDT) "Valeri Galtsev" galtsev@kicp.uchicago.edu wrote:
It is about fundamental approach. We always modularize things: split into smaller subunits each of the last doing its smaller task. This allows to make smaller things work reliably, and test these smaller things more comprehensively. As it is much smaller number of combinations of factors you need to repeat your test with in case of subunits. People use this approach for ages. Programs are split into subroutines. Rockets are built from to awful degree independent modules. We had this "modular" system V boot until recently. We lost it.
What makes you think that systemd is not modular? Have you actually looked at its structure (let alone the code)? If you look inside /usr/lib/systemd/ do you see one big monolithic library which represents one big failure point, or do you see a few dozen dedicated small libraries, each doing one particular thing?
I don't really see how systemd violates the "do one thing and do it well" philosophy. A lot of people seem to ignore the fact that systemd is *not* one binary executable which replaces init and tries to take control of everything, but rather a whole swarm of independent binaries, each in charge of one particular function of the OS. If one of them breaks for some reason, others will still keep functioning.
It appears to me that much of bashing of systemd is just FUD. One of the typical misconceptions is the disable vs. mask for services --- despite appearances, the systemd "disable" does *exactly* the same thing that SYSV "disable" did. But people simply refuse to understand it (or never even bother to learn the details), and keep bashing systemd for making the distinction between disabling and masking a service.
I'd suggest to go get familiar with the internals of systemd first, and only after that come back and criticize its shortcomings.
Best, :-) Marko