zlacker

[return to "Understanding the bin, sbin, usr/bin, usr/sbin split (2010)"]
1. IgorPa+Vp[view] [source] 2026-01-04 16:33:32
>>csmant+(OP)
Also /bin vs /sbin believe is that the latter is meant for statically linked binaries such that if your system is corrupted these at least will keep working.

Practically in this century if I was starting a new OS I would set it up like so:

/bin for all system binaries. Any binary from a package installed by the OS package manager lived here.

/lib same but for shared libraries

/var for variable data. This is where you would put things like your Postgres data files.

/tmp for temporary files.

/home as usual.

/dev as usual.

/boot as usual

/etc as usual

/usr would be what /usr/local is on most systems. So /usr/bin is binaries not installed by the OS package manager. /usr/etc is where you put config files for packages not installed by the package manager and so on.

Get rid of /usr/local and /sbin.

/media replaces /mnt entirely (or vice versa).

Ditch /opt and /srv

Add /sub for subsystems: container overlays should live here. This would allow the root user (or a docker group, etc.) to view the container file system, chroot into it, or run a container on it.

Then again, nobody gave me a PDP-11 to decide so my vote doesn’t count :)

◧◩
2. immibi+rv[view] [source] 2026-01-04 17:06:46
>>IgorPa+Vp
Why not call it /local instead of /usr?

Along p_ing's lines I'd rename /var to something else, possibly not /srv because it's not just for servers, but it could be /data

◧◩◪
3. IgorPa+MN[view] [source] 2026-01-04 18:57:52
>>immibi+rv
/srv is for services. Which is weird because so is /var. The choice between /var/lib/postgresql and /srv/postgresql is arbitrary to me. Except in /var you can also have things like /var/cache, /var/tmp, and so on.
[go to top]