&gt; <i>Already exposing processes as files is an abstraction.</i><p>No. The <i>file system</i>, is the abstraction. Adding &#x2F;proc onto it is a use of that abstraction.<p>There&#x27;s two basic extreme positions, and you&#x27;re adopting one, your parent is adopting something closer to the other.<p>a. The filesystem only exposes filesystems actually on disk, mapped to some hierarchy. As you say, &quot;<i>On the disks the OS manages file systems.</i>&quot;<p>b. The filesystem is (roughly) a hierarchical container of named binary blobs (called &quot;files&quot;) with some defined associated metadata, such as permissions.<p>While you can adopt (a), and that&#x27;s fine, some of us (myself included) see a lot of value in (b). The biggest problem with only exposing &quot;real&quot; 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&#x27;re only going to expose &quot;real&quot; files in the file hierarchy leaves us with several classes of objects that aren&#x27;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&#x27;ll probably also need to be able to associate permissions with those objects¹, as so now you&#x27;ve got a named, ACL&#x27;d list or hierarchy of objects, and it&#x27;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.<p>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&#x27;s really just the &quot;CRUD&quot; 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.<p>This is, of course, a case where the power is somewhat biting us. That doesn&#x27;t make the abstraction wrong, nor does it mean the abstraction isn&#x27;t leaky. (In fact, in this case, the abstraction works really well, I&#x27;d say. Any other implementation of UEFI variables is going to have a &quot;delete&quot; call, AFAICT. What bit us here is that all the objects are in one bucket together, and thus rm -rf &#x2F; removes more than just files.)<p>&gt; <i>It breaks one of the most fundamental principles that should be followed in man-machine interaction: The principle of least surprise.</i><p>While I agree, that doesn&#x27;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 &#x2F;` actually does. There&#x27;s certainly more than one way to solve this, some of which don&#x27;t involve limiting what can be done with the FS. (As some examples: perhaps rm shouldn&#x27;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 &quot;user acknowledgement&quot; of their removal; perhaps it really does get mounted read-only.)<p>¹While you might be able to get away with &quot;only root accesses UEFI vars&quot; in the scenario that they&#x27;re not in the file hierarchy, if you remove all non-real-files then you&#x27;ve got a lot of other things to deal with: unix sockets, block devices, terminals, all the various I&#x2F;O ports, temp sensors, battery data… the list is extensive.