6 ms·

Where does Linux promise that files are bits on a disk? As a user I certainly don't expect that. Perhaps you have a problem with the name "file" but the abstrac

by mjhoy 11y ago

Where does Linux promise that files are bits on a disk? As a user I certainly don't expect that. Perhaps you have a problem with the name "file" but the abstraction itself still seems useful. (And yet I do find it quite odd when I have to do something like `echo "TPAD" > /proc/acpi/wakeup` to disable wake-on-trackpad.) That said I don't disagree with you that UEFI variables should not be delete-able, but there are many files on Linux that you can't delete.

jerf 11y ago
I agree that there's no promise it's a file. After all, fuse will let you mount anything as a filesystem. But I'm trying to think of another file I can "delete" and permanently hose my computer, but I'm coming up blank. Maybe some fuse filesystem somewhere can do it, but none of the ones I've used. I mean, yeah, I've destroyed many a partition table in my day, and I've permanently lost myself some data, I've even dd'ed in the wrong direction with no recourse but to suck it up and deal with it, but I've never fried a computer with a rm command. (Contrary to what some commenters seems to be viciously defending, this does seem to be a legitimately different level of destructive possibility than has conventionally been available. This is the sort of thing that would put me off having ever installed Linux in the first place.)
useerup 11y ago
It is a file system, consisting of file system objects, like files and directories. Already exposing processes as files is an abstraction. It somewhat works because you can imagine the file representation being maintained by the process. But it is an abstraction, because a process is not a file. But what is more important: A file system is a hierarchy. At the root is the most fundamental object. Each level has subordinate objects. That the model you expect. Having UEFI variables mounted as a file is a surprising loop back to something even more fundamental that the OS itself: The firmware of the physical computer. It a breach of the mental model. It breaks one of the most fundamental principles that should be followed in man-machine interaction: The principle of least surprise. I have a machine. I have installed an operating system on it. The OS manages several disks. On the disks the OS manages file systems. I expect the files of that system to be managed by the OS. I do not expect that regular file system actions have effect outside the hierarchy of the directory on which I perform the actions. Specifically I do not expect files on that system to manage the physical computer.
- deathanatos 11y ago
  > Already exposing processes as files is an abstraction. No. The file system, is the abstraction. Adding /proc onto it is a use of that abstraction. There's two basic extreme positions, and you're adopting one, your parent is adopting something closer to the other. a. The filesystem only exposes filesystems actually on disk, mapped to some hierarchy. As you say, "On the disks the OS manages file systems." b. The filesystem is (roughly) a hierarchical container of named binary blobs (called "files") with some defined associated metadata, such as permissions. While you can adopt (a), and that's fine, some of us (myself included) see a lot of value in (b). The biggest problem with only exposing "real" file-storing FSes in the file hierarchy is that it leaves you with a ton of questions about how to expose all the other things. Taking the stance that we're only going to expose "real" files in the file hierarchy leaves us with several classes of objects that aren't files-on-disk, and you need to name them s.t. the user can interact with them. It is certainly possible to expose each different type of thing in a completely separate namespace. You'll probably also need to be able to associate permissions with those objects¹, as so now you've got a named, ACL'd list or hierarchy of objects, and it's starting to look a lot like a filesystem. You now also need another set of tooling to work with each of these classes of objects. You need another set of syscalls for each of these objects. The great thing about having a unified file hierarchy in the (b) abstraction is that tooling works on all of these different classes of objects different. It's really just the "CRUD" idiom, and normally it allows things to interoperate quite smoothly. I can write a bash script that draws a progress bar of my battery, and it requires no knowledge other than where in the file hierarchy the battery is. This is, of course, a case where the power is somewhat biting us. That doesn't make the abstraction wrong, nor does it mean the abstraction isn't leaky. (In fact, in this case, the abstraction works really well, I'd say. Any other implementation of UEFI variables is going to have a "delete" call, AFAICT. What bit us here is that all the objects are in one bucket together, and thus rm -rf / removes more than just files.) > It breaks one of the most fundamental principles that should be followed in man-machine interaction: The principle of least surprise. While I agree, that doesn't mean we need to throw out all the power of having a unified file system, but it might beget some way of ensuring the user understands what `rm -rf /` actually does. There's certainly more than one way to solve this, some of which don't involve limiting what can be done with the FS. (As some examples: perhaps rm shouldn't recurse to a different FS, and objects of similar types are on different FSs, which prevent the very error that got us here; perhaps some files force "user acknowledgement" of their removal; perhaps it really does get mounted read-only.) ¹While you might be able to get away with "only root accesses UEFI vars" in the scenario that they're not in the file hierarchy, if you remove all non-real-files then you've got a lot of other things to deal with: unix sockets, block devices, terminals, all the various I/O ports, temp sensors, battery data… the list is extensive.

by mjhoy 11y ago

jerf 11y ago

I agree that there's no promise it's a file. After all, fuse will let you mount anything as a filesystem. But I'm trying to think of another file I can "delete" and permanently hose my computer, but I'm coming up blank. Maybe some fuse filesystem somewhere can do it, but none of the ones I've used. I mean, yeah, I've destroyed many a partition table in my day, and I've permanently lost myself some data, I've even dd'ed in the wrong direction with no recourse but to suck it up and deal with it, but I've never fried a computer with a rm command. (Contrary to what some commenters seems to be viciously defending, this does seem to be a legitimately different level of destructive possibility than has conventionally been available. This is the sort of thing that would put me off having ever installed Linux in the first place.)

useerup 11y ago

It is a file system, consisting of file system objects, like files and directories. Already exposing processes as files is an abstraction. It somewhat works because you can imagine the file representation being maintained by the process. But it is an abstraction, because a process is not a file. But what is more important: A file system is a hierarchy. At the root is the most fundamental object. Each level has subordinate objects. That the model you expect. Having UEFI variables mounted as a file is a surprising loop back to something even more fundamental that the OS itself: The firmware of the physical computer. It a breach of the mental model. It breaks one of the most fundamental principles that should be followed in man-machine interaction: The principle of least surprise. I have a machine. I have installed an operating system on it. The OS manages several disks. On the disks the OS manages file systems. I expect the files of that system to be managed by the OS. I do not expect that regular file system actions have effect outside the hierarchy of the directory on which I perform the actions. Specifically I do not expect files on that system to manage the physical computer.

deathanatos 11y ago
> Already exposing processes as files is an abstraction. No. The file system, is the abstraction. Adding /proc onto it is a use of that abstraction. There's two basic extreme positions, and you're adopting one, your parent is adopting something closer to the other. a. The filesystem only exposes filesystems actually on disk, mapped to some hierarchy. As you say, "On the disks the OS manages file systems." b. The filesystem is (roughly) a hierarchical container of named binary blobs (called "files") with some defined associated metadata, such as permissions. While you can adopt (a), and that's fine, some of us (myself included) see a lot of value in (b). The biggest problem with only exposing "real" file-storing FSes in the file hierarchy is that it leaves you with a ton of questions about how to expose all the other things. Taking the stance that we're only going to expose "real" files in the file hierarchy leaves us with several classes of objects that aren't files-on-disk, and you need to name them s.t. the user can interact with them. It is certainly possible to expose each different type of thing in a completely separate namespace. You'll probably also need to be able to associate permissions with those objects¹, as so now you've got a named, ACL'd list or hierarchy of objects, and it's starting to look a lot like a filesystem. You now also need another set of tooling to work with each of these classes of objects. You need another set of syscalls for each of these objects. The great thing about having a unified file hierarchy in the (b) abstraction is that tooling works on all of these different classes of objects different. It's really just the "CRUD" idiom, and normally it allows things to interoperate quite smoothly. I can write a bash script that draws a progress bar of my battery, and it requires no knowledge other than where in the file hierarchy the battery is. This is, of course, a case where the power is somewhat biting us. That doesn't make the abstraction wrong, nor does it mean the abstraction isn't leaky. (In fact, in this case, the abstraction works really well, I'd say. Any other implementation of UEFI variables is going to have a "delete" call, AFAICT. What bit us here is that all the objects are in one bucket together, and thus rm -rf / removes more than just files.) > It breaks one of the most fundamental principles that should be followed in man-machine interaction: The principle of least surprise. While I agree, that doesn't mean we need to throw out all the power of having a unified file system, but it might beget some way of ensuring the user understands what `rm -rf /` actually does. There's certainly more than one way to solve this, some of which don't involve limiting what can be done with the FS. (As some examples: perhaps rm shouldn't recurse to a different FS, and objects of similar types are on different FSs, which prevent the very error that got us here; perhaps some files force "user acknowledgement" of their removal; perhaps it really does get mounted read-only.) ¹While you might be able to get away with "only root accesses UEFI vars" in the scenario that they're not in the file hierarchy, if you remove all non-real-files then you've got a lot of other things to deal with: unix sockets, block devices, terminals, all the various I/O ports, temp sensors, battery data… the list is extensive.