[Discuss] Debian 12 in the Cloud

[kentborg at borg.org (Kent Borg)]

On 6/4/24 07:07, Rich Pieri wrote:
> Lennart Poettering's take:
> http://0pointer.de/blog/projects/systemd.html
> http://0pointer.de/blog/projects/why.html

Very interesting, thank you. Those point out to me that I should have 
more sympathy for systemd, they tackled a hard problem

Unix's architecture has held up *really* well over the decades. At least 
the from the kernel's perspective. But what we expect of the user land 
part of the OS has changed a lot. The original init system was a simple 
framework for Unix programs to get themselves run at boot. But over time 
user land programs established ad hoc dependencies on each other, 
building up into an incomplete mess.

Upstart's perspective* was that the problem is bigger than the original 
model (true), and so: "Hey y'all, rewrite everything to use our new 
API!", and they would optimize what the init system did, plus mediate 
all of this new dynamic stuff. (Reasonable summary?) Except nothing was 
programmed to this new model, while the old model and the old chaos 
still mostly worked.

* Note Upstart failed: the URL http://upstart.ubuntu.com seems dead.

systemd's approach is to roll their sleeves and start making things work 
better, based on the reality of what was happening with this-bus and 
that-bus and whatnot. And if "progress" means patching OpenSSH, then 
let's patch OpenSSH!

Then this episode comes along and clearly demonstrates (to me at least) 
that if being pragmatic means patching OpenSSH, then it was necessarily 
the wrong approach. There are annoying, pedantic, philosophical 
arguments for why the expedient patching of other packages is a mistake, 
and annoying, pedantic, philosophical arguments are sometimes correct.


So what was right approach?

I don't know. Well, maybe I know a little:

1. Other than embedded boxes, we no longer boot computers that often 
(and even with embedded, only some small footprint devices get booted 
much, and they won't be running systemd), therefore optimizing for boot 
time was a mistake.

2. We now have crazy amounts of RAM (at least until someone launches one 
of those never-designed, bloated, general purpose OSs we misleadingly 
call "web browsers"), therefore optimizing for RAM was a mistake, too.

But trim those two out, and does the problem simplify much? I fear not. 
We still have all those behavioral dependencies as the computer's 
configuration dynamically changes, and to me that seems the hard part.


-kb, the Kent who doesn't know what a good solution would have been.


P.S. Once upon a time when I was working on getting an embedded machine 
to boot faster.

One of my clever ideas: Have our monolithic program, the thing that did 
the embedded work of the box, *be* PID 1, at least at first, so it could 
start running as soon as possible, initializing itself, moving motors, 
etc., but then have it pretty much immediately fork in to two. The 
process that kept PID 1 exec-ed busy box's init white PID 2 continued on 
in parallel. That, plus optimizing kernel boot time, meant we started 
doing our real work with so little delay that the time for the 
hardware's power-on-reset was a major component.