3 ms·

We've been living in a world where you couldn't brick the firmware from the OS for a long time, and it's been terrible. I'm perfectly happy to take the risk of

by clinta 11y ago

We've been living in a world where you couldn't brick the firmware from the OS for a long time, and it's been terrible. I'm perfectly happy to take the risk of being able to brick a board from the OS if it means I never again have to try boot to a dos disk and run a proprietary exe to update the BIOS. Some boards do have something of a "factory reset" in the form of dual bios so that if one is bricked, the backup can still be booted. But it's not a bug that not every motherboard has this feature.

Sophira 11y ago
The point isn't that it can be bricked; it's that it's possible to brick it via an "rm". Or heck, doing anything hardware-related via an 'rm'. The UNIX philosophy of "everything is a file" has always been based around the conceptual 'contents' of these 'files'. The kernel doesn't (directly) care if you remove a device node (block or character-based), it doesn't care if you remove a pipe, and it doesn't care if you remove a socket - even though all of these things are interfaces to the kernel in one form or another. Removing these files only removes your ability to access that interface. Simiarly with files in /proc - which, like /sys, is directly exported by the kernel. In many cases the kernel refuses to even allow you to unlink the 'files' in /proc, even when it might make sense. (For example, you can't kill a process by 'rm'ing anything in the relevant /proc directory.) Instead, you update the configuration values that the files in /proc represent by echoing into their contents, where applicable. The case with the efivars 'file' actually causing the kernel to take action when it's removed is what's at issue here. The fact that it happens to brick some computers is particularly unfortunate, but does a good job with showing the problem here. This isn't what the "everything is a file" philosophy is about.
- clinta 11y ago
  I was not defending SystemD, I was defending the hardware manufacturers against the accusation that they're "shipping faulty boards". I think SystemD is in the wrong here. Operating Systems should be protecting users from bricking their hardware. Harware manufacturers should not be shipping hardware that's nearly impossible to brick, because it results in hardware that is nearly impossible to update.

by clinta 11y ago

Sophira 11y ago

The point isn't that it can be bricked; it's that it's possible to brick it via an "rm". Or heck, doing anything hardware-related via an 'rm'. The UNIX philosophy of "everything is a file" has always been based around the conceptual 'contents' of these 'files'. The kernel doesn't (directly) care if you remove a device node (block or character-based), it doesn't care if you remove a pipe, and it doesn't care if you remove a socket - even though all of these things are interfaces to the kernel in one form or another. Removing these files only removes your ability to access that interface. Simiarly with files in /proc - which, like /sys, is directly exported by the kernel. In many cases the kernel refuses to even allow you to unlink the 'files' in /proc, even when it might make sense. (For example, you can't kill a process by 'rm'ing anything in the relevant /proc directory.) Instead, you update the configuration values that the files in /proc represent by echoing into their contents, where applicable. The case with the efivars 'file' actually causing the kernel to take action when it's removed is what's at issue here. The fact that it happens to brick some computers is particularly unfortunate, but does a good job with showing the problem here. This isn't what the "everything is a file" philosophy is about.

clinta 11y ago
I was not defending SystemD, I was defending the hardware manufacturers against the accusation that they're "shipping faulty boards". I think SystemD is in the wrong here. Operating Systems should be protecting users from bricking their hardware. Harware manufacturers should not be shipping hardware that's nearly impossible to brick, because it results in hardware that is nearly impossible to update.