18 Jun
2024
18 Jun
'24
11:55 a.m.
David Arnold <davida(a)pobox.com> writes:
Users reasonably want things to work, and Red Hat
wants to
satisfy
those users, and they’ve chosen this way to do
it. Unfortunately,
there’s been no real competition: this goes well beyond system
startup, and well beyond service management, and citing s6 or
launchd
or whatever misses the war by focusing on the battle.
Good point.
The problem that D-Bus attempts to solve is communication between
components and applications designed for different desktop
environments. i wasn't paying particular attention at the time, so
i don't know what more Unix-y alternatives were proposed, if
any. Laurent Bercot, the developer of s6[a], has created a
bare-bones proof-of-concept alternative:
https://skarnet.org/software/skabus/
but this hasn't been taken further, as his priorities have been
elsewhere.
Wayland is an attempt to solve various issues and limitations of
X. It's not a project by people who don't understand X; as an
example, Matthieu Herbb, an Xorg dev and a primary OpenBSD dev in
this area, did a presentation last year in which he said "X11 is
fading away" and "Wayland is the way to go for graphical desktop":
https://2023.eurobsdcon.org/slides/eurobsdcon2023-matthieu_herrb-wayland-op…
The problem is, people who aren't facing the issues and
limitations faced by others are unlikely to have any motivation to
work on, or support, the development of alternatives. This leaves
the field of proposed solutions open to those with a different
approach and/or a desire for résumé-driven development, regardless
of the quality of the design and/or implementation. But even when
the people working on alternatives are people who understand the
problem space, those for whom the existing solution is perfectly
adequate are unlikely to provide input regarding the development
of those alternatives - so when a particular alternative gains
sufficient momentum that those people are forced to start dealing
with it, they might find it unusable for their use-case(s).
In other words, the war is pretty much lost at the outset, and
people are left fighting battles that, in the medium-to-long term,
are likely to turn out to be quixotic.
Alexis.
[a] i would say s6 is very much in the spirit of "the Unix
philosophy": a suite small focused programs that can be combined
in various ways, "mechanism not policy", and utilising fundamental
Unix features. As Laurent writes at the end of the page about the
s6 approach to 'socket activation', to which i linked upthread:
You don't have to use specific libraries or write
complex unit
files, you just need to understand how a command line
works. This is Unix.
-- https://skarnet.org/software/s6/socket-activation.html
Nevertheless, he's also noted, back in 2020, the real-world issues
that have been an obstacle to s6's uptake:
The fact is that a full-featured init system *is* a
complex
beast, and the s6 stack does nothing more than is strictly
needed, but it exposes all the tools, all the entrails, all the
workings of the system, and that is a lot for non-specialists to
handle. Integrated init systems, such as systemd, are
significantly *more* complex than the s6 stack, but they do a
better job of *hiding* the complexity, and presenting a
relatively simple interface. That is why, despite being
technically inferior (on numerous metrics: bugs, length of code
paths, resource consumption, actual modularity, flexibility,
portability, etc.), they are more easily accepted: they are just
less intimidating.
As a friend told me, and it was an enlightening moment: you are
keeping the individual parts simple, but in doing so, you are
moving the complexity to the *interactions* between the parts,
and are burdening the user with that complexity. You are keeping
the code simple, which has undeniable maintainability benefits,
but you are making the administration more difficult, and the
trade-off is not good enough for a lot of users.
-- https://skarnet.org/lists/supervision/2586.html