Mark Rousell's commentary is accurate and to the point.  As for "better 
ones" and the lack of competitor systems being "widely adopted" is far 
more a for-profit business decision than a decision based upon the 
abstract software engineering and performance merits of the situation. 
Despite the limitations thereof, IEEE committees and the resulting 
standards, and likewise IETF or W3C, have numerous inputs, compromises, 
and, in the case of IETF or W3C, "adopters" so that an idea can be 
implemented by the community (public funded government laboratories such 
as CERN, non-profit universities, for-profit entities, and public 
interest groups) and tested "in the crucible of experience".

The problems and issues that justify the existence of "new" approaches 
such as SystemD, are very real in terms of scaling, deployability, 
security (this is not the Arpanet of old, but rather a battleground with 
both profit and government edicts -- including "cyberwarfare" -- at 
play), and non-locality (e.g., "cloud" resources and use).  The 
solutions of either the old ATT/Unix or BSD simply were engineered for a 
very different "world" than what we face today.  However, the question 
of whether or not SystemD is a good approach is a separate one, and in 
some measure, tied into the monolithic Linux kernel.

As for competitor systems and the existence thereof, the current Linux 
situation is such than a few students taking the pedagogical Minix 
system cannot in practice develop an operational test bed for a major 
systems internals project, let alone deploy what we now know as Linux. 
Can "small" efforts develop a new programming language or a new end-user 
application?  Probably.  Simply having an "idea", even an engineered 
idea, for a systems internals utility (let alone a "boot" system) does 
not result in a production test bed -- and typically requires more 
experienced person-time than a small effort has available.

The issues mentioned about the continued bloat in SystemD are real  The 
possibility (high probability) of vulnerabilities are also real. These 
vulnerabilities particularly emerge in "cloud" deployment for which 
control of the physical hardware is subject to laws and actions of 
nation-states and entities that may not be in the interests of or 
agreement with those who use such resource (e.g., provisioning a new 
instance of a distributed supervisor set under a type 1 hypervisor using 
hardware resources in some nation).

In practice, does the community really need something "better" than 
SystemD?  Probably.  Will this be achievable in practice?  Even FSF/GNU 
could not in practice achieve wide scale deployment of Hurd -- or this 
discussion would be rather different.  Thus, without some concerted 
resources (read:  equipment, experienced knowledgeable personnel, and 
real world test beds), SystemD will be with us.  Hopefully, it can be 
modified (evolve) to address the issues that have been raised in this 
exchange, but I for one am not holding my breath.

On 1/24/21 8:26 AM, Serguei Mokhov wrote:
> On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell <[log in to unmask]> wrote:
>>
> 
>> BUT... the fact that SysVInit is seen as outdated is NOT a reason in and of itself to support SystemD.
>> There may have been and, in many people's opinion, there were and are better init systems
>> to replace SysVInit than SystemD. "Better" being both a technical and a political/social/industrial construct.
> 
> Mark, please name the better ones. And possibly why have they not been
> widely adopted?
> 
> (PS: Lamar, appreciate as always your PostgreSQL contributions and its
> package management.)
>