On Fri, 10 Oct 2014 11:05:19 -0500 (CDT)
"Valeri Galtsev" <galtsev@xxxxxxxxxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
