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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021143520.gd24...@smurf.noris.de
