&gt; No. The file system, is the abstraction. Adding &#x2F;proc onto it is a use of that abstraction.<p>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).<p>However, already adding &#x2F;proc challenges that. What does it mean to have &quot;execute&quot; right to a process? It is already running? What does it mean to append to a process? to move it? If processes are &quot;files&quot;, 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 &#x2F;proc as status information being maintained for each process, i.e. they are extracts, owned by the OS.<p>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!<p>&gt; 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>But it actually just sweeping complexity under the rug. I need documentation for <i>what</i> the file contains on each &quot;line&quot; - 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 <i>discovering</i> the correct ressource (the battery) to displaying a progress bar on Windows <i>without</i> consulting documentation:<p><pre><code>			PS C:\&gt; #there&#x27;s probably some class for batteries. let&#x27;s look for it by name
			PS C:\&gt; get-cimclass *battery*

			   NameSpace: ROOT&#x2F;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:\&gt; # the Win32_Battery probably offers the most specific information

			PS C:\&gt; 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:\&gt; # yep - that&#x27;s it. lets save this instance in a variable
			PS C:\&gt; $bat = Get-CimInstance Win32_Battery

			PS C:\&gt; # display a progress bar and update it continually every 10 secs
			PS C:\&gt; for(){ Write-Progress Battery -PercentComplete $bat.EstimatedChargeRemaining -Status &quot;Charge remaining&quot;; sleep 10 }

</code></pre>
&gt; This is, of course, a case where the power is somewhat biting us.<p>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&#x2F;files they operate on.<p>&gt; That doesn&#x27;t make the abstraction wrong<p>It is an abuse of the abstraction.<p>&gt; Any other implementation of UEFI variables is going to have a &quot;delete&quot; call, AFAICT.<p>Indeed. In PowerShell you can discover the commands for manipulating by 
	gcm <i>UEFI</i><p>&gt; 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>No, what bit us is the broken expectation (a surprise) that a higher-level resource was mapped below some file system directory.