> No. The file system, is the abstraction. Adding /proc onto it is a use of that abstraction. Agree that the file system is an abstraction. Makes us think in t

> No. The file system, is the abstraction. Adding /proc onto it is a use of that abstraction. Agree that the file system is an abstraction. Makes us think in terms of directories (containers) and files (items). Everything in the file system is designed around the idea of files and directories. Permissions (rwx), operations (create, move, copy, append, delete). However, already adding /proc challenges that. What does it mean to have "execute" right to a process? It is already running? What does it mean to append to a process? to move it? If processes are "files", why can I not kill the process by deleting the file? Processes are not naturally files. Yes, it makes somewhat sense if you think of /proc as status information being maintained for each process, i.e. they are extracts, owned by the OS. But UEFI vars makes absolutely no sense. It is a true leaky abstraction. If one need to be able to write to UEFI vars, then create an API for it, possibly some utilities. That way I need not risk altering fundamental firmware settings by performing seemingly file system operations whose effect I expect to be limited to the hierarchy! > 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. But it actually just sweeping complexity under the rug. I need documentation for what the file contains on each "line" - what it means to write to it, etc. It is not discoverable at all. If you expose system resources as actual resources and do not try to map them onto files, you can actually make a discoverable system. An example of such a regime is CIM. On Windows, PowerShell (or Python or VBScript or ...) can be used to interact with such fundamental system resources. To use your example of a progress bar of the battery, here is an example of how the entire process from discovering the correct ressource (the battery) to displaying a progress bar on Windows without consulting documentation: PS C:\> #there's probably some class for batteries. let's look for it by name PS C:\> get-cimclass *battery* NameSpace: ROOT/cimv2 CimClassName CimClassMethods CimClassProperties ------------ --------------- ------------------ CIM_Battery {SetPowerState, R... {Caption, Description, InstallDate, Name...} Win32_Battery {SetPowerState, R... {Caption, Description, InstallDate, Name...} Win32_PortableBattery {SetPowerState, R... {Caption, Description, InstallDate, Name...} CIM_AssociatedBattery {} {Antecedent, Dependent} PS C:\> # the Win32_Battery probably offers the most specific information PS C:\> Get-CimInstance Win32_Battery Caption : Internal Battery Description : Internal Battery Name : DELL 1C75X31 Status : OK Availability : 2 CreationClassName : Win32_Battery DeviceID : 647Samsung SDIDELL 1C75X31 PowerManagementCapabilities : {1} PowerManagementSupported : False SystemCreationClassName : Win32_ComputerSystem ... BatteryStatus : 2 Chemistry : 6 DesignCapacity : DesignVoltage : 12992 EstimatedChargeRemaining : 94 EstimatedRunTime : 71582788 ExpectedLife : MaxRechargeTime : ... ExpectedBatteryLife : PS C:\> # yep - that's it. lets save this instance in a variable PS C:\> $bat = Get-CimInstance Win32_Battery PS C:\> # display a progress bar and update it continually every 10 secs PS C:\> for(){ Write-Progress Battery -PercentComplete $bat.EstimatedChargeRemaining -Status "Charge remaining"; sleep 10 } > This is, of course, a case where the power is somewhat biting us. No, what biting us is a leaky abstraction that surprises us: We can accidentally delete firmware variables because file system operations are not constrained to the directories/files they operate on. > That doesn't make the abstraction wrong It is an abuse of the abstraction. > Any other implementation of UEFI variables is going to have a "delete" call, AFAICT. Indeed. In PowerShell you can discover the commands for manipulating by gcm UEFI > What bit us here is that all the objects are in one bucket together, and thus rm -rf / removes more than just files. No, what bit us is the broken expectation (a surprise) that a higher-level resource was mapped below some file system directory.