I think there's a parallel from the Unix/Linux systems that we think of
as more Unix-like, to the cars and airplanes and other machines of that
and earlier eras. It used to be that part of the design of a system,
alongside its operation, was the idea of normal, regular maintenance.
The system could be pretty simple, but there was some maintenance and
wearable parts replacement required. It was expected that there was an
administrator or mechanic checking in once in a while to keep things
tuned and in "good repair". This worked well, as long as people accepted
this responsibility as part of the deal.
Now it seems like people want everything done for them automatically,
and not to have to know anything about the systems they are using. They
want the systems to be smarter so they don't have to know as much. It's
sort of like when the private airplane industry tried to engineer any
skill required on the part of the pilot, out of the airplane. The
results were not good. Planes became more complex, with more points of
failure, and pilots did not know how to react to unexpected situations.
I see this happening with our computer systems, and the people using
them now, too. Of course there's a reasonable middle ground, but I think
we've gone a little too far making things "easy", and in fact it's
not
easier at all, we're just fiddling in a different way, often through
random trial and error, it all seems horribly indirect, opaque, and
irrational, to support some programmer's idea somewhere, of some perfect
abstraction.
For example: CMake vs. just learning how to write makefiles properly.
You fiddle with CMake and you never really know why it does what it
does, especially from one version to the next, "but you don't have to
write makefiles".
On 06/16/2024 02:56 PM, David Arnold wrote:
On 15 Jun
2024, at 00:18, Grant Taylor via TUHS <tuhs(a)tuhs.org> wrote:
It's my understanding that systemd as a service lifecycle manager is starting to
take on some aspects of what cluster service managers used to do.
I think it goes
beyond this, and that systemd is just a convenient focus point for folks to push back
against a wider set of changes.
My usual example here is PolKit and polkitd. In this latest systemd release, for example,
it seems the new systemd-run0 command (replacing sudo or su), starts a privileged process
by checking permissions with polkitd over DBus, and then uses systemd to actually fork and
setup the “child”.
This is a fairly distinctive departure from how Unix works: over the last decade, Linux
has increasingly moved away from being Unix, and I think this is why people find systemd
so confronting. And there’s more to come, eg. varlink.
I’m sure systemd, polkitd and their ilk address real needs. But the solution isn’t (in my
view) Unix-like, and those for whom Linux is a convenient Unix are disappointed (to put it
mildly).
The world is no longer a PDP-11 or a Vax or a SPARCstation. USB in particular introduced
a lot more dynamism to the Unix device model, and started us down this path of devfs,
DBus, systemd, etc. 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.
d