Steve Litt <[email protected]> writes: > Rainer Weikusat <[email protected]> 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". _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
