Everything stated below is "correct", historically as well as for the 
immediate for-profit concerns of the vendors (such as IBM RH or 
Canonical).  The issues with both the (old,"deceased", pre-RBOC) ATT or 
the BSD boot, startup, etc., mechanisms are primarily that these were 
designed for a very different epoch, long before Gage coined "the 
network is the computer" became the reality (not just a slogan) at a 
scale considered science fiction at the time of the original Unix/BSD 
mechanisms, and long before large scale type 1 hypervisor deployment 
resulting in "cloud" computing.  Overwhelmingly, there is agreement that 
new mechanisms, and in some sense, algorithms, were/are needed beyond 
the original Unix or BSD mechanisms.

The question is:  what mechanism?  The reality today for Linux systems 
as deployed at scale mostly is SystemD.  The question -- a question that 
goes well beyond what started as an exchange about EL 8 -- is what goes 
forward?  SystemD as it currently stands is too delicate and too 
vulnerable to compromise, either within itself or in terms of the 
processes/subsystems it "controls", despite the large scale deployment 
of SystemD.  The reason behind this is in part driven by the monolithic 
design (and implementation) of the Linux kernel, and the symptom is 
continued SystemD intrusiveness and bloat throughout much (all?) of the 
Linux distros that have deployment at scale.  This scale is from laptops 
and workstations to large network distributed systems, even if such 
large systems are in fact deployment controlled by a non-Linux type 1 
hypervisor that instantiates Linux systems -- each such Linux system at 
some point uses SystemD.

I asked a question to which I have not seen an answer:  does a SystemD 
configuration (plain text files in the SystemD design) from two similar 
hardware platforms but different Linux distros (say, EL and LTS) 
interoperate, or require significant rewriting to produce the "same 
results"?  In other words, are the valuable concepts of portability and 
re-usability (do not reinvent the wheel, another engineering turn of 
phrase) met in practice with SystemD?



On 1/25/21 6:57 AM, Lamar Owen wrote:
> On 1/24/21 10:59 AM, Mark Rousell wrote:
>>
>> This is undoubtedly the case but of course it doesn't necessarily 
>> follow that SystemD is the correct solution. And that's where the 
>> controversy arises.
> 
> What is 'correct?'  (THAT is where the controversy actually lies.) The 
> old engineering mantra is that 'the better is the enemy of the good 
> enough;' any piece of software can always be made 'better' for various 
> definitions of 'better.'  There comes a time you have to accept the 
> 'good enough' and get on with life; the Linux kernel is not the 
> be-all-end-all but at the moment it IS 'good enough' for what it does; 
> it's not going away no matter how badly kernel purists wish it would. 
> There are many init systems distributions can choose from; the Wikipedia 
> article on init lists them and I won't repeat the list here.
> 
> The definition of 'correct' is fluid and dynamic, changing with the 
> needs of the users of the system on which the init must run, and 
> subsumes far more than technical items, as things like license 
> compatibility must be considered, too.  For a long time root-executable 
> shell scripts were 'good enough' for 'correct' behavior; that time has 
> passed.  Sun scrapped the whole mess in Solaris 10 with SMF; Canonical 
> wrote Upstart for Ubuntu because old-style SysV Init was no longer 
> 'correct' for their use cases; Red Hat paid for the development of 
> systemd because nothing was 'correct' for their desired use cases, and, 
> well, Red Hat wanted their own solution.  Other distributions followed 
> suit because systemd is now 'good enough' for today's 'correct' and got 
> to that place before its competitors.
> 
>>
>>> Difficult? That is the understatement of the decade.  I prefer to 
>>> honestly evaluate new technologies with a bit more pragmatism; do I 
>>> like having to learn a different way of doing things?  Not really; 
>>> but after Debian adopted systemd I took more notice.
>>
>> The thing is, one cannot wisely evaluate something on *purely* 
>> technical grounds because its function in reality may not be entirely 
>> or purely technical. Issues of politics and control of industry and/or 
>> mindshare are relevant too.
> 
> I never evaluate something on purely technical grounds; Debian adopting 
> systemd is not a technical but a political criterion.  I do weigh 
> technical merit highly, but the political fact that systemd is the 
> current init system for all of the top 5 server distributions has to be 
> taken into consideration.
> 
> Are there technically better init systems?  Sure; daemontools is the 
> first that comes to my mind (as Nico correctly pointed out), but there 
> are others.  Had djb made his license more palatable then we might all 
> be griping about daemontools instead of systemd.  But that ship has sailed.
> 
> What you say in your message, especially the parts I didn't quote, is 
> quite true all around; but it's unfortunately irrelevant, since systemd 
> achieved critical mass once Debian adopted it and Ubuntu followed suit. 
> As much as I'm not really fond of it, systemd is the current winner of 
> the init war, unless something far better, with a good license, and with 
> a critical mass to support it, comes along OR systemd becomes so 
> obnoxious that Debian drops it (again, I use Debian as a bellwether 
> simply because it's a fully openly developed system with no single 
> company behind it, so no 'corporate agenda' to interfere with open 
> decision-making).
> 
> One thing can be said that I'm sure everyone will agree on: systemd is 
> definitely the most polarizing component of the typical Linux distribution.