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 <markrlon...@hotmail.co.uk> 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.)
