Steve Litt <slitt@???> writes:
> Rainer Weikusat <rainerweikusat@???> wrote:
>
>> There are really only two options:
>>

>> 1. Don't mount or mount r/o and require user interfaction prior to
>>    working with these variables.

>>

>> 2. Mount r/w and expect people messing around with the fs as superuser
>>    to know what they're doing.

[another misused analogy]

> In a Poettering/UEFI world, railings are all less than 2 feet high,
> high rise picture windows are large and low, mountain roads have no
> guard rails on curves, bridge abutments have no sand barrels in front
> of them, and people who draw blood don't wear rubber gloves. We all
> know what we're doing, and if something goes wrong, we deserve what we
> get.

None of these statements is applicable to the situation. This was about
first intentionally executing a command supposed to delete everything
accessible via any some mounted filesystem and then 'discovering'
that this command deleted some things which should rather have been
kept. Executing such a command without knowing which filesystems are
mounted and how this will affect the state of the machine is not "an
unfortunate accident" but simply gross neglect.

Regarding the different-but-related issue of 'buggy software' causing
the deletion, there should be a prominent "policy choice" to prevent any
modification of 'EFI variables' unless a user specifically oks
that. That's also something where the "systemd responses" of "our
convenience beats your hardware" (as we make the descisions) is clearly
wanting. But that's because users are supposed to be in control of their
hardware/ software and not because random morons "want to watch GNOME
die".