Simon Hobson <li...@thehobsons.co.uk> writes: > Rainer Weikusat <rainerweiku...@virginmedia.com> wrote: >> Dave Turner <dave_t_tur...@barradas.free-online.co.uk> writes: >>> There seems to be an assumption that everybody is a 'power user' and >>> knows exactly what they are doing. >>> The reality is not like that at all. >>> Leaving nasty surprises for the unwary and inexperienced is at worst >>> malicious and at best incompetent. >> >> How does this apply to someone who executed a command "because he wanted >> to watch GNOME die" after "he unmounted all important filesystem" or - >> more accurately - wrongly believed to have done so? >> >>> I would guess that most of us here have googled for the answer to some >>> programming or scripting conundrum, and how many stackoverflow etc >>> answers did you have to go through to find an answer that was correct? >>> Far too many. >> >> How does this apply to the situation? >> >>> Now imagine the poor sod new to all this... It is most emphatically >>> not gross neglect on the part of the user. >> >> The 'poor sod' wasn't "new to all of this". > > Now I understand your hostility to the idea of trying to provide some > safety
"Provide some safety" is a far to general statement for anyone to have any opinion on it. > - you are assuming we are **ONLY** talking about the person who did > this deliberately. I was only making statements about this situation. > We're talking about the general case, where the "maybe not such a > command line guru" is googling for suggestions and comes across the > "you can do X by X" answer somewhere. The answer was probably written > prior to this UEFI mounted filesystem stuff, the user probably doesn't > understand what half the things returned by mount our, and uses a > command that supposedly achieves what he needs. That's a fictional situation, however, for the real "general case", someone who blindly trusts the advice of strangers despite he doesn't understand it will end up getting himself in trouble sooner or later and probably rather sooner than later. But that's somewhat besides the point here. [...] > Say you read the man pages and release notes for "rm" - will you find > a warning that it can brick your UEFI hardware ? Doubt it ! A nice idea for a comical horror movie scene I had a while ago was someone killing someone else by strapping him to a table and hammering a pair of carrots through the eyes into his brain (don't know if this is really possible with carrots but it should surely work with screwdrivers) with his fists while screaming madly. With the camera moving backwards at the end of the scene from a perpsective where on can see the top of the head of the killed guy, ie, level with the table, with the carrots sticking out. But I never found a warning about that on any carrot I bought. Unlinking all files and directories on a mounted pseudo-filesystem can have a completely arbitrary effect, ie, it's not "rm bricking the UEFI hardware" but a certain kernel driver modifying the UEFI NVRAM as instructed by a user. One could argue that a different interface than the filesystem namespace would be more appropriate here. I have no opinion on that because I know too little about 'EFI variables' but in this case, your (or anyone else's) would be beef with the kernel code implementing the interface and not with systemd using it. [...] > Even if someone runs rm -rf /, while the command takes some time - the > actual window for it to catch the UEFI fs during a "write enable, > modify, write protect" task is still fairly small. Let me put it this way: Were I the author of some software acting in this way, I wouldn't allow you to use it for anything unless you've given me a written declaration that you won't hold me responsible if it destroys your hardware without even giving you a chance to prevent that. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
