:: Re: [DNG] Felker Init: was without-…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Rick Moen
Date:  
À: dng
Nouveaux-sujets: [DNG] Device naming: was Felker Init: was without-systemd.org not working
Sujet: Re: [DNG] Felker Init: was without-systemd.org not working
Quoting Antony Stone (Antony.Stone@???):

> It may have been sold that way in the early days, but it's now
> infiltrated so many parts of the GNU / Linux system that just telling
> people (or showing them) that they can use something else to manage
> their daemons is no longer enough.


Except that robust alternatives exist for all of the other major areas
where systemd is touted as the One True Solution. And, as I've shown in
my own modest writings, it remains a pretty easy task to swap in modular
replacements, each chosen with an appropriate scope of functionality[1]
rather than a figurative brass band (or in other cases, such as daemon
supervision in most cases, electing to omit entirely as not needed).

I mean, c'mon, this isn't the first time the right solution to scope
creep and pathologically excessive integration was to say 'But I don't
actually want that.'

When the 'crowd pushing systemd' (to borrow Rich Felker's phrase), in early
day ballyhooed how great systemd's allegedly innovative daemon
supervision was, I was right then administering many hundreds of CentOS
Internet servers running (selected) critical daemons under Chris
McDonough's Python-based supervisord -- so, my reaction was 'What, you
think you systemd guys invented process supervision? And what else, the
light bulb? Toilet paper?' (To answer Rich Felker's doubt-raising,
yes, supervisord is IMO robust enough, and also the others he cites.)

IMO, pretty nearly the only place the systemd suite has an arguably
compelling advantage is an exotic one: cgroups controller. This makes
systemd irritably difficult to avoid for containerised cloud computing,
and, cgroup controllers have that Highlander quality that 'There can be
only one' (in a running system). The systemd implementation is crammed
like much else into PID1, which has operational advantages over the
better-security alternative of _not_ running it out of PID1 (as does
OpenRC's implementation, https://wiki.gentoo.org/wiki/OpenRC/CGroups ).

[1] E.g., I remain unconvinced I need a half-dozen different ways to
refer to a device node.

-- 
Cheers,
Rick Moen            Diaeresis:  Keeping the cow out of co-worker since 700 AD.
rick@???    
McQ! (4x80)