Linux - now 1000% easier to accidentally destroy your entire computer.
-
This probably isn't fixed from all the arguments of whether it was even their problem or not, but...
At one point running rm -rf / on a linux system with systemd would actually brick the entire motherboard by trashing variables that the BIOS requires for the system to even POST.relevant github issue:
-
Heh:
jmtd commented on Jan 29
via a hasty use of rm -rf /
Is there any other kind? :)
-
Hooray for everything being a file! The good ol' Unix Philosophy™ at work!
-
They're still doing this
This has been a known issue for a while, and IIRC the answer back then was "we want userspace tools to be able to configure efi".
Because why wouldn't you want to be able to screw your computer on accident?
-
@masonwheeler said in Linux - now 1000% easier to accidentally destroy your entire computer.:
Hooray for everything being a file! The good ol' Unix Philosophy™ at work!
Note that this is a bug filed against a project that believes that everything should not be a file and acts accordingly.
Note also that the core problem is manufacturers making crappy UEFI boot systems.
Note also that systemd is a total crap project and codebase and deserves an eternal burnination.
-
@pydsigner I disagree most violently. systemd is one of the most sensible things that happened to computering as of recent times. Totally another thing is that you can botch a motherboard using EFI variables just like that. Bonus points for making the system totally unrecoverable when NVRAM craps out. There must be a super-protected emergency code which at least allows you to restore the stock firmware with default settings.
Then again, Arch users are test lab hamsters so they shouldn't really complain.
-
Fixed in kernel 4.5 which is out for quite a while.
Hardware workarounds are actually a kernel's job; it should not expose dangerous variables and disallow tampering with them.
There are blacklists for hardware with faulty firmware (say, SSDs with buggy TRIM implementation), why not have them here as well. It's BIOS vendors who are the real WTF, but then again, it's not like buggy BIOSes are going anywhere.
-
@wft said in Linux - now 1000% easier to accidentally destroy your entire computer.:
Then again, Arch users are test lab hamsters so they shouldn't really complain.
I like to think of them as canaries.
Filed under: I wasn't making an analogy here. I just like to think of people as canaries.
-
@error Maybe. Expendables.
-
@wft said in Linux - now 1000% easier to accidentally destroy your entire computer.:
Hardware workarounds are actually a kernel's job; it should not ([expose dangerous variables] and [disallow tampering with them]).
Filed under: Not ... Nor ...
-
@djls45 (not(expose dangerous variables)) and (disallow tampering with them)
-
@wft said in Linux - now 1000% easier to accidentally destroy your entire computer.:
@djls45 (not(expose dangerous variables)) and (disallow tampering with them)
(and (not (expose dangerous variables)) (disallow tampering with them))
-
"Deja Vu" moment... I think we have had discussion on this a few months ago already.
-
@masonwheeler And if something can't be fully represented as a file (because what device could possibly need anything more operations than "read" and "write"?) we'll just make a bunch of ad-hoc
ioctl
requests.Wow, such a clean and simple API!!
-
@aliceif Might as well go full LITHTHP at this point…
(let ((them (dangerous variables))) (and (not (expose them)) (disallow-tampering them)))