[__david__]

True, and I generally like how I can poke around /sys with just ls and cat, but perhaps somewhat sensitive boot configurations should live behind an ioctl interface (or some other syscall) instead of being shoehorned into the filesystem.

[cyphar]

ioctls are definitely the wrong interface (they require an open file, for one). To be honest, there are very good reasons why the "everything is a file" model is very useful. You can use it to do many more cool things with shell scripts (such as changing the fan speed, or backlight brightness or any other dodgy cowboy stuff). And at the end of the day, why is the "everything is a file" model bad?

[wfunction]

> And at the end of the day, why is the "everything is a file" model bad?

Because not everything is a file? And therefore forcing people to treat everything as a "file", which they have certain natural expectations for, leads to problems such as the one here when the objects cannot fulfill the users' expectations?

> You can use it to do many more cool things with shell scripts (such as [...] dodgy cowboy stuff)

I feel this is fairly obvious... if your argument for the everything-is-a-file model is a love for dodgy cowboy hackery, then is it really that surprising that you're sacrificing something (in this case, usability/sensibility/etc.) in the process? I mean, yeah, those who feel like cowboys might find your system intuitive, but do you not see how it might not be very usable by (or useful to) other people?

[cyphar]

> > And at the end of the day, why is the "everything is a file" model bad?

> Because not everything is a file? And therefore forcing people to treat everything as a "file", which they have certain natural expectations for, leads to problems such as the one here when the objects cannot fulfill the users' expectations?

"Everything is file" doesn't mean that everything is associated with a block on disk. Filesystems are a very good (and intuitive) way of describing hierarchies, and benefit from requiring literally only one syscall interface that works will all of your tools and programming languages without needing to update the stdlib. How would you propose to represent hierarchies using syscalls? Would you have a "set_uefi_variable" syscall? How would that not become unweidly? ioctls wouldn't work (not just because they're ioctls but also because you'd need to open a file, and devices aren't files either -- because "everything is a file" is bad, right?). You could try doing it all with kdbus (or something), and that might even be somewhat plausible. Until you realize there's no way of doing anything that doesn't require breaking out a C compiler. Shell scripts couldn't do simple things like change the dimness of your backlight.

> > You can use it to do many more cool things with shell scripts (such as [...] dodgy cowboy stuff)

> I feel this is fairly obvious... if your argument for the everything-is-a-file model is a love for dodgy cowboy hackery, then is it really that surprising that you're sacrificing something (in this case, usability/sensibility/etc.) in the process?

It also doesn't require 500 pages of API docs each time you want to change your backlight with a shell script. The whole point of Unix is to solve problems quickly, not to have to break out your C compiler each time you want to do something less trivial than renaming a file.

> I mean, yeah, those who feel like cowboys might find your system intuitive, but do you not see how it might not be very usable by (or useful to) other people?

Filesystems are intuitive to almost all users. When teaching Unix to my friends, I start by saying "everything is a file" and move on from there. Why? Because it's actually a useful abstraction. Filesystems are already incredibly intuitive. Not to mention that nobody was actually complaining about how intuitive it is to have efivarfs, it's a non-issue.