Comment by IgorPartola
4 days ago
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 :)
> 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.
My understanding is that sbin for system binaries, not necessarily statically linked. Normally /sbin is only in root's PATH, not normal user's. They are likely world executable, but in many cases you cannot actually run them as non-root since they usually touch things only root can access without special access (e.g. raw devices, privileged syscalls, /etc/shadow etc.). Not always though, like you can run /sbin/ifconfig as normal user in read-only mode.
The s in sbin stood for static initially. Of course nowadays this is not enforced.
What is the source for that? Some of the oldest references to sbin I can find are 4.3BSD Net/2 man pages (https://man.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sek...) and Filesystem Standard v1.0 (https://www.ibiblio.org/pub/Linux/docs/fsstnd/old/fsstnd-1.0...). Former doesn't mention anything about static binaries, latter only mentions that static ln (and even mentions sln being static version of ln) and sync can be useful.
1 reply →
> /var for variable data. This is where you would put things like your Postgres data files.
This one never sat well with me. I think of /var as temporary data, something I can lose without much consequence. But never data files. I know it's the default, but still.
/srv I like because it seems like a proper place to separate server-related data, i.e. /srv/wwwroot or similar. But if you like /var, that of course would be the place for this type of data.
No. Temporary data is /var/tmp or /tmp. The difference: /var/tmp should survive a reboot. /tmp might be lost on reboot.
/var is data that needs to be writable (/usr/*, /bin and /lib may be readonly), and that might be important. Like databases, long-term caches, mail and printer queues, etc.
> 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.
I think that became the rationale for /[s]bin vs. /usr/[s]bin (although based on the linked article, that may have been retconned a bit).
You were supposed to keep your root/boot filesystem very small and mostly read-only outside major updates. That meant that you could boot to a small amount of utilities (e.g. fsck) that would let you repair /usr or any other volume if it became corrupted.
I think the other poster is correct that stuff like fsck is supposed to go into /sbin because it is a "system" binary (but also statically linked since /usr/lib isn't mounted yet) and doesn't make sense to have in user $PATHs since nobody other than root should really be running that one.
Regardless, this is all deeply meaningless these days, particularly if you are running "ephemeral" infrastructure where if anything goes that wrong you just repave it all and start over.
> Ditch /opt and /srv
If a system is intended to serve data on a network (file shares, databases, websites, remote backups, etc), /srv is where the requisite data for those things should live. I think that's a good idea.
What is the difference from /var for databases, websites, etc. and /media for backups?
/media has nothing to do with backups (though one could backup stuff there):
> This directory contains subdirectories which are used as mount points for removable media such as floppy disks, cdroms and zip disks. https://specifications.freedesktop.org/fhs/latest/media.html
/var is used for websites and databases, but defaults for most packages don't use /srv by default. (I have the feeling that /srv is relatively new.)
1 reply →
Basically: https://sta.li/filesystem/. Arguably /usr shouldn't exist because rather polluting system with unmanaged installations should be making a package and installing with package manager.
I used to package a lot of my stuff as Debian packages and it is a process that takes an hour or three for most packages. I really liked it and would have loved to be able to do that as just a normal way to distribute everything but it just is a little too much overhead. A shame, really, since once you get it working it is way nicer than any Docker setup you can think of.
If I was starting a new system layout, I wouldn't have every package smush its files together with everyone else's into a single shared directory hierarchy. /opt would reign supreme, and we already have pkg-config to deal with that sort of layout.
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
/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.
what you suggest to replace /usr/share , /usr/man , /usr/lib ... ?
Good point. It isn’t variable data as in it only changes on package updates. But it isn’t user data either, so it doesn’t belong in /usr. I guess that one should have been in /lib/share and /lib/man. Or it could be a brand new directory called /doc which contains the documentation type content.
/usr/lib contents belongs in /lib if the contents is installed by the package manager. That way /usr/lib is what the user installed.