[TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register

[Alexis]

David Arnold <davida at 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-openbsd.pdf

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