Linked by Thom Holwerda on Mon 30th Jan 2012 20:39 UTC
General Unix Finally something really interesting to talk about. If you've used UNIX or any of its derivatives, you've probably wondered why there's /bin, /sbin, /usr/bin, /usr/sbin in the file system. You may even have a rationalisation for the existence of each and every one of these directories. The thing is, though - all these rationalisations were thought up after these directories were created. As it turns out, the real reasoning is pretty damn straightforward.
Permalink for comment 505538
To read all comments associated with this story, please click here.
RE[3]: We are stuck in the past.
by jabjoe on Wed 1st Feb 2012 20:52 UTC in reply to "RE[2]: We are stuck in the past."
Member since:

How's that any different than code decode a jpeg or other on disc files? Stick it in a userland lib. Less in kernel space the better. Plus often, you don't need much userland code (maybe for ALSA, but not OSS ;-) ). A framebuffer file is just that, you can even memmap it and use it raw!

It is simple. The way I see things, the Turing machine works on addresses, certain address ranges map to certain things. Unix abstracts that so the address system is file paths, and the certain address ranges are files. It then abstracts further by making those certain address ranges map to files via a standard layout (and pushing settings to ioctl), rather than device specific. As everything is done via a file interface, you don't need a million different syscalls, you only need file syscalls and a few others for what isn't files (sleep, fork, etc). It makes everything standard and means you can plug pretty much anything together.

Edited 2012-02-01 20:53 UTC

Reply Parent Score: 2