Hi Steve, hi,

Steve Litt - 18.06.24, 23:35:04 CEST:
> >The Unix Heritage Society mailing list has a long thread this month
> >on the problems of systemd. Visit the archives at
> >
> > https://www.tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/
>
> So now PID1 will read and parse all contents of a .v directory, and run
> a command depending on an algorithm on those contents. What could
> *possibly* go wrong?

Yeah, what can even possibly go wrong with such an approach? Deleting
/home can go wrong – No, this is *no* joke, this is seriously for real:

Systemd 256.1 Fixes "systemd-tmpfiles" Unexpectedly Deleting Your /home
Directory

https://www.phoronix.com/news/systemd-tmpfiles-purge-drama

I am speechless.

At least for a moment.

Let's see what self-serving declarations aka "Nah, that is not a grave
bug, cause… this and this." some of the Systemd developers come up this
time.

Yeah sure, accusing the user:

refuse systemd-tmpfiles --purge invocation without config file specified on
cmdline #33349

https://github.com/systemd/systemd/issues/33349

It is a complete, utter and total failure. A grave bug. A very grave bug
with severe data loss consequences.

And its nothing else than that.

But no use in expecting Systemd developers taking responsibility. Well
they fixed the issue – partly IMHO, cause creating a directory "/home" does
not belong into any tmpfile stuff handling to begin with – but able to admit
having done something wrong? No way at all. This total lack of owning a
mistake is unbelievable. No one even said sorry to the user.

It is even more astonishing how the reporter just asked for clarification
of the documentation. Yeah just write into the documentation: "We delete
your /home and that is fine, cause it is as designed"! That bug reporter
did not even dare to challenge the Systemd dogma anymore or did believe so
much in Systemd that no way it could be wrong.

The amount of brain washing in there is unbelievable.

Best,
--
Martin