Arnt Karlsen - 07.11.23, 19:45:28 CET:
> On Tue, 07 Nov 2023 18:33:27 +0100, Martin wrote in message
>
> <113312253.nniJfEyVGO@???>:
> > Hi Roberto.
> >
> > Roberto Scattini - 07.11.23, 17:15:54 CET:
> > > > Lennart working at Microsoft and Systemd 2.55-rc1 brings a blue
> > > > screen of death (BSOD). Even I would not have thought something
> > > > like this would happen.
> > >
> > > That's funny! Can You share more context on this?
> >
> > For example:
> >
> > systemd 255-rc1 Brings "Blue Screen of Death" Support
>
> ..chk out https://github.com/systemd/systemd/issues/26586
>
> ..who defines boot time "if low" "battery level in initrd"?
> Etc.

"detect battery level in initrd and if low refuse continuing to boot,
print message and shut down"

ridiculous. But it is the same pattern as before as in "I decide what is
best for you!" or "Let me do the thinking for you!". It is this arrogance
that was one of the main reasons to go away from systemd for me. No,
Systemd developers you are not more qualified to decide what is best for me
than myself!

It is the same pattern that in many societies caused so much suffering in
the last 3-4 years and even before that. Assisted thinking. I can think
for myself, thanks!

I grew up with computers where I was the boss: Amiga with AmigaOS. AmigaOS
never did something crazy just because it could. What I told the computer
was law. Period. And I even knew what every single files of AmigaOS was
meant for. Something I unfortunately cannot say about modern Linux systems
anymore, especially once a desktop environment is involved.

I know what I am doing, and if not, I am willing to deal with the
consequences.

There are some quite clear-cut cases and I do not object "rm -rf /"
bailing out in GNU coreutils, or Z-Shell asking in case a rm command would
affect more than a few files, however Systemd policies go too far, way too
far. It was one of the reasons for switching to Devuan:

I switched swap mounting to be label based in fstab but forgot to set the
label on swap volume. Systemd refused to boot. And even when booting in
Debian's emergency mode back then, it refused to start ssh daemon, cause
if system does not start 100% correct then of cause ssh daemon cannot be
started. And for refusing to start ssh daemon it even took 90 seconds. You
read that right: Systemd refused to execute on "systemctl start ssh" cause
of failed mounting of swap! Are you even kidding me? Of cause the machine
had more than enough RAM to start the ssh daemon without working swap!

Eventually I started ssh daemon manually in order to get rid of keyboard
issues with VMware console out of band management in combination with my
browser setup.

My preference is: You boot the system, as long as it is even possible! I
can take care of any issues once the system is up. You do not decide
whether to boot or not, you go about booting and I see about whether I can
use the result. Or otherwise written: If I break something I get to keep
the pieces and it is my responsibility to fix it.

Another ridiculous thing is: send Systemd illegal instruction signals =>
boom! Systemd refused to continue working. Cause then Systemd thinks
memory or hardware is broken. Send sysvinit or runit SIGILL signals:
Nothing! It just continues to run. If I like broken memory detection and
some action on broken memory, totally fine, but then I have that as a
separate watchdog kind of service that I install where I need it.

Systemd comes with a ridiculous amount of implied policy. Like for example
using Google DNS servers in case nothing else is specified.

It is the old robustness principle, Postel's law: be generous in what you
accept, but strict in what you send. So my operating system design would
be to take great effort to bring the system up, even in case of errors
during boot up.

> ..the inspiration behind SystemD is very clearly totalitarian
> to anyone who knows a wee bit of German and Austrian history.

Oh, we had and have totalitarian behavior in more countries than that.

> Now, admitting it? ;oD

Indeed.

In corporate there is something similar and it is called endpoint
security. Which often enough equals to installing a rootkit on the client
machines.

I prefer educating staff about security risks instead of installing a
rootkit on every client machine. And of course of doing the best effort to
block malicious content at the network boundary already.

And of cause encrypt clients where needed.

Best,
--
Martin