Jump to content
  • entries
  • comments
  • views

Everything is a file is maby not always the best




sometimes the "everything is a file"  approach on *nix systems is great sometimes its not really

especially when programming its not.

the filesystem structure of certain  " special/magic" directories and there files is maybe unlikely to change in the near future. but

filepaths tend to be just strings most of the time. even when they arent at first glance if you follow the trail down to where they are actually constructed they usually end up being just a collection of hardcoded strings mashed together

and me not likes hardcoding stuff verry much

to get the number of cores in python (on linux) you are either dependant on running a subprocess to get the output of nproc:


import subprocess
#------------ OUTPUT------------#

wich isnt ideal :

  • -its an unnessecary subproc that needs to start
  • its a non system native program and creates a depency on that
  • you have no clue  unless you go look at the sourcecode how that actually gets the number of cores

or yo get the number of cores from the /sys filesystem tree:

p = '/sys/devices/system/cpu/'
rx = re.compile('^cpu(\d+)$')
cores = [rx.search(node).group() for node in os.listdir(p) if rx.search(node)]
print('total:\t', len(cores), '\ndirs:\t',sorted(cores))
#------------ OUTPUT------------#
total:	 8 
dirs:	 ['cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6', 'cpu7']

wich will depending on where you decide to use it leave you with a hardcoded path burried somewhere in the code, for someone trying to adapt a piece of code to lets say osx or windows , they may start by correcting all system dependant calls in the program buth how would they know that some piece of the code just for getting the number of cores somewhare has 3 lines that have a hardcoded system dependant path to look for ?

the third option is bad in the same way the first one  but with extra abstraction :

  • no idea if a subproc is being used or not unless you investigate
  • creates a python depency with possibly more depencies it depends on.
  • possibly a pretty large piece of code for just core numbers or whatever info
import psutil
#------------ OUTPUT------------#

 also when using the first or third possibillity you are deferring the responsability for keeping everything working and up to date to a 3rd party in case of  a change + ofc erverything that comes allong with 3rd party software like(compatible) licencing , do we include or do we depend on the user installing the depency ? ..

if psutils is distributed under GPL you can  not include it and ship your program under (my favorite)  the unlicence


and this isnt a specific thing for getting just the corecount, but a more general argument , on filesystem based hardware access

tink of finding one specific usb device or one specific partition, or check for a hid device

if your left with using the kernel interface the code suddenly becomes more of a challenge and even more cumbersome



Windows works the same way, it's just hidden better.

Everything is always a file, whether it's presented that way or not.

Exposing the "everything is a file" interface to the user can have several benefits. It's significantly easier to write an application that pretends to be a mouse: All you have to do is secure a file for a mouse and write instructions to it. And that's just one example.


This is derived from how things work on silicon: All you can really do is write to an address and read from an address, sometimes with side effects (operations). And that's it. That applies whether you are writing to a register, memory, or storage. All you can ever do is write to and read from an address.

Your argument against hardcoding things like filepaths is really a different argument altogether, one which basically everyone agrees with, with one caveat: They agree with it for application development.

Link to comment
Link to post

no not really actually...

and windows defenetly doesent  🙂

and also imho its not how things work on silicon , on silicon there isnt even such a thing as a file. let allong a folderstructure . on 'disk'  theres chunks of data and metadata and depending on the fs , in linux, its mapped differently to the inode table, where each piece of metadata, discribes a 'file'


I actually had a really detailed description in mind to post here , but as one can see above , if it isnt code , but natural language , complicated things i try to convey in writing tend to end up as a bit of a mess.

Think , how in linux processes are actually  (/proc) wich isnt the case in windows , or how actually reading from a device in windows actually comes with  a Callback if the device is ready, wich is not really possible with a file , since aa file cant do anything eg ....


then i actually remembered i dont need to , thanks to Benno Rice.  😄

i would recommend watching the entire thiing if you  havent  seen it but 

First what its about and what the goal is :  1:30min - > 2:40min

The answer that in MS Windows Verry little But files Are files ,...  2:45 - > 4:35

Why the posix -everything is a file - approach isnt always:

  • true actually
  • the best/most logical/intuitive/most powerfull...

5:50min -> watch untiill your convinced or have enough material to counter 🙂




Link to comment
Link to post