Re: piece of mind
Hi,
The Wanderer:
> > Can you give an example of people doing that in case of systemd?
> > Because so far, everything I heard was similar to GNOME, where:
> > • systemd provided a feature.
>
> This is the problem. The init system should not be providing "features"
> which other software might, post-boot and pre-shutdown, want to make use
> of.
Define "post-boot". What about socket activation? Or starting up my
database when the iSCSI link to the storage comes up, instead of
*whenever*? Or cleanly restarting my Apache heap-of-processes?
Please explain why it should *not* provide these "features".
Why should every daemon (or its startup script) re-implement the same
code to put itself in the background, change UIDs, resource-limit and
security-enhance (private /tmp) itself, when the same thing can be
implemented once, so that I as a sysadmin (or my puppet script) don't have
to learn ten separate ways of configuring that?
There are a bunch of things systemd can do which sys5rc can't do. Why is it
a "design flaw" to provide these in the way that's easiest to implement,
and therefore (presumably) least buggy?
> The decision to incorporate such features into systemd is IMO the design
> flaw which leads to the problems to which people object. That decision
> was made by the systemd developers
for a couple of reasonably good reasons. You might want to debate the
validity of these reasons and the difficulty of doing it some other way,
assuming that there's a tangible benefit of doing it another way in the
first place. Having ten processes responsible for bits&pieces of what
systemd-as-PID1 does instead of one isn't a benefit -- not if all you gain
by that is nine additional processes.
"It's a big monolithic thing, and big monolithic things are bad and evil
and non-Unix-y, so there!!1!" is not a valid argument.
--
-- Matthias Urlichs
Reply to: