6 ms·

sbin split (2010)

199 points by csmantle 10mo ago

jagged-chisel 10mo ago
Reason: because it’s always been that way. Additional info: many rules from many places are now in force that maintain the historical structure.
miggol 10mo ago
I've only used modern immutable Linux (Alpine, MicroOS) and wondered why of all places `/var/` was chosen as the location for rw stuff. It's fun to be reminded that there was of course a time when an immutable OS was the default, and you ran it off of floppies. So there's a lot of history to using `/var/` for that. Guess we've come full circle!
- rendaw 10mo ago
  Was it immutable? I thought it was just different storage types, like you'd have a smaller disk for the root stuff and then make var on a larger disk. I'm surprised that, having something immutable, you'd choose to go the other direction.
  - miggol 10mo ago
    Good point, considering the nature of floppies I suppose it technically mustn't have been immutable. But I feel like it would have been wise to mount your OS root read-only to prevent yourself from accidentally ruining your (possibly only) copy of your OS. At least before you had a reasonably sized hard drive. > I'm surprised that, having something immutable, you'd choose to go the other direction. I can somewhat imagine that having been limited by space and having to swap out disks all the time one would jump on the train of mutability without fully appreciating the benefits of immutability.
cowlby 10mo ago
Obligatory XKCD Standards https://xkcd.com/927/ https://xkcd.com/927/
- esparanto 10mo ago
  When I hear people complaining about this sort of thing, I want to say, “Just go and invent your own, then.” But then you get things like Esperanto. Esperanto takes about 1/4 of the time to learn compared to other languages. It’s taught in China and used as primary language in some settings. But, aside from a large number of people learning some Esperanto from Duolingo several years ago, it’s just another language now to have to learn.
roger_ 10mo ago
Is there a mainstream distro that disregards all the legacy cruft? Gobo, but that’s not really mainstream. Mac OS?
- deleted 10mo ago
  [deleted]
- wasting_time 10mo ago
  NixOS and Guix are fairly established in this regard. macOS is certified Unix, and necessarily implements the "legacy" cruft.
  - behnamoh 10mo ago
    at some point we gotta let go of legacy stuff tho, and Apple has shown in the past that they're not afraid of doing that.
  - Imustaskforhelp 10mo ago
    I had written a similar comment here asking for people's opinion but I would like to add something that I know about which I didn't see in your list Tinycorelinux I know that it doesn't follow the best user practices etc. but I did find its tcz package format fascinating because they kind of work similar to mountable drives and I am not exactly sure but I am fairly certain that a modern package management system where two or more packages with conflicts etc. can run on the same system. I really enjoyed the idea of gobolinux as well. I haven't played with that but it would be good if some more mainstream os could also implement it. Nix and Guix are more mainstream but they also require to learn a new language and I think that we might need something in the middle like gobo but perhaps more mainstream or adding more ideas / additions perhaps? I would love it if someone can tell me about some projects we are missing to talk about and what they add on the table etc. I haven't tried Gobo though so I am not sure but I really wish more distros could add features like gobo, perhaps even having a gobofied debian/fedora eh?
    - yjftsjthsd-h 10mo ago
JodieBenitez 10mo ago
> I'm still waiting for /opt/local to show up... Well... battlestation : ls /opt/ homebrew local :'-)
- JodieBenitez 10mo ago
  And funnily enough, only one file there. battlestation : tree /opt/local /opt/local └── lib └── libgeos_c.dylib -> /opt/homebrew/lib/libgeos_c.dylib 2 directories, 1 file Why ? I don't know. But I do need libgeos.
ck2 10mo ago
and /local/ to top off the confusion
behnamoh 10mo ago
This is what happens when a system is designed by multiple people and companies over a long period of time. An amalgam of ideas which are there just because. There's no reason Linux should be like this. e.g., see https://gobolinux.org/ https://gobolinux.org/ which has more sane dirs.
- jmclnx 10mo ago
  Not really, back then disks were very expensive and you had no choice but to split. And disk sizes were very small. But, I in a way int kind of makes sense. /bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime. 's' for items regular users do not need to run, remember, UN*X is a multi-user system, not a one person system like macs, windows and in most cases Linux.
  - eviks 10mo ago
    How does splitting help save space?
    - yjftsjthsd-h 10mo ago
      I think it's less about saving space and more that / and /usr can be two separate disks
  - kokada 10mo ago
    > /bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime. Nowadays most Linux systems boot with initramfs, that is a compressed image that includes everything the system needs to boot, so you're basically saying /bin and /sbin is useless.
    - schmuckonwheels 10mo ago
      > initramfs, that is a compressed image that includes everything the system needs to boot Not always (raise your hand if you've had an unbootable system due to a broken or insufficient initrd). In retrospect, the whole concept of the initrd seems like an enormous kludge that was thrown together temporarily and became the permanent solution.
chrisweekly 10mo ago
Ha! TIL. Funny and informative post. Speaking of things which are needlessly complex, I'm reminded of this classic post on the tortured history of the browser User-Agent header: https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/ Highly recommended!
paulddraper 10mo ago
1. The title says “understanding sbin” but the content gives zero understanding of that. If someone has a historical explanation, please provide it. 2. “Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt” Not exactly. /usr/local exists so you don’t accidentally mess up your distro/package manager by changing its files. It’s “local” to your installation. But it is still structured — /usr/local/bin, /usr/local/lib, etcetera — divided into binaries, shared libraries, manpages. Whereas /opt has no structure. It’s “the wild west”…application binaries, libraries, configuration, data files, etcetera with no distinction. Apps with “universal” packaging, or sometimes secondary package managers. For example /usr/local/bin is normally part of PATH, but /opt is not (unless eg homebrew adds it to your bashrc).
- vntok 10mo ago
  What do you mean?
  - paulddraper 10mo ago
    I mean the article doesn’t explain sbin. The author symlinks it to bin but doesn’t explain why it exists.
    - em500 10mo ago
      I'm believe /sbin was introduced/standardized in System V Release 4. It's present in SVR4 (1988) but not in SVR3 (1987). Another candidate is would be some old BSD (check 4.2 or 4.3 (1986) if anyone has a running system). I'm guessing it was introduced to finally move out all the (mostly system) binaries from /etc, which in ancient Unix from Bell Labs in the 1970s really meant "etc", as in stuff that didn't fit elsewhere rather than system config files, so it contained binaries like init, mount, umount.
glhaynes 10mo ago
On a similar note: just the other day I was thinking about how the Unixy systems I used 20+ years ago used to nudge/push you toward creating several actual partitions during installation. Maybe /, /usr, swap… maybe one or two more? IIRC, I think some of the BSDs, at least, maybe still do? Always seemed weird and suboptimal to me for most installations, but I remember being told by graybeards at the time that it was the Right Way.
- calvinmorrison 10mo ago
  still makes sense to prevent overruns right? IE /home/ cant drop the whole system just cause you torrented too many debian ISOs and blew out your disk. same for /var/ or wherever you store your DB tables like MySQL.
  - glhaynes 10mo ago
    Ah, yeah, that makes sense, thanks. My experience as "sysadmin" has largely been from the standpoint of personal systems for which that has mostly not been a big concern for me.
  - bpfrh 10mo ago
    Ironically using "modern" filesystems like zfs or btrfs you can do that if they are on the same disk
    - 1718627440 10mo ago
      Partitions are still on the same disk?
  - smallstepforman 10mo ago
    The inverse is also true - cannot download an 60Gb game due to partition size being too small even if there is cumulative free space available.
  - homebrewer 10mo ago
    This is much better solved by quotas which can be adjusted on the fly without rewriting your partition tables.
IgorPartola 10mo 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 :)
- deleted 10mo ago
  [deleted]
- p_ing 10mo ago
  > /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.
  - holowoodman 10mo ago
    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.
- theandrewbailey 10mo ago
schmuckonwheels 10mo ago
This post gets some of the details wrong. /usr/local is for site-local software - e.g. things you compile yourself, i.e in the case of the BSDs the ports collection - things outside the base system. (They may be compiled for you). Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux. /opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software. You're putting your $500k EDA software under /opt.
- yjftsjthsd-h 10mo ago
  > Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux. The Linux base system is managed by the package manager, leaving local for the sysadmin to `make install` into
  - schmuckonwheels 10mo ago
    > The Linux base system There is no such thing as a Linux base system. Separate components, separate people. Hence the term Ganoo plus Leenox...
    - yjftsjthsd-h 10mo ago
      Well, no, my exact argument is that there is a base system, even if it is composed of assorted components. If you install Debian (or whatever) on a machine, the software installed by the package manager ships as a unified release that has been adapted to work together. I think it's reasonable to call that the base OS. And then, separate from that base system that is managed by the package manager, the local admin my install things into /usr/local.
      - schmuckonwheels 10mo ago
        If you can remove GNU coreutils and replace them with something else (like that Rust garbage) then you don't have a base system. You have a loose collection of packages around a kernel.
vxxzy 10mo ago
I am going to use this story in place of the "Pot Roast Principle" [0] [0]: https://www.psychologytoday.com/us/blog/thinking-makes-it-so/201402/the-pot-roast-principle https://www.psychologytoday.com/us/blog/thinking-makes-it-so...
age123456gpg 10mo ago
Here [1] is a related trick in the old Unix to run either `foo`, `/bin/foo` or `/usr/bin/foo` (apparently before `PATH` convention existed): char string[10000]; strp = string; for (i=0; i<9; i++) *strp++ = "/usr/bin/"[i]; p = *argv++; while(*strp++ = *p++); // string == "/usr/bin/foo" execv(string+9, args); // foo (execv returns only in case of error, i.e. when foo does not exist) execv(string+4, args); // /bin/foo execv(string, args); // /usr/bin/foo [1] https://github.com/dspinellis/unix-history-repo/blob/Research-V4-Snapshot-Development/usr/source/s2/nohup.c https://github.com/dspinellis/unix-history-repo/blob/Researc...
drtgh 10mo ago
Nowadays I think packages should turn to portable applications isolated within their own directories. Those directories would have an standard libraries directory that the application would use. Latter, if desired, the system, could override those libraries with another ones (newer compatible or patched), more thinking is needed about this. The key, from the process point of view, would to limit the access of such process to their own directories and some very limited system only local services by default, And to extend this permissions, each binary in such directory would need to be in companion of a permissions request file that would require the approbation from the user or the system defaults patterns (each distro would have a point of view I guess), in the aim of improve process isolation and system, drivers, services access permissions. This would need also restructure the console philosophy, how can manage the processes, and so on, that would need a big restructuration. I mean, anyway people is duplicating space with containers trying to isolate process, remark in trying. I know this is unrealistic due the deep change it would suppose, so consider I'm just thinking out loud. PS: If you answer it already exists with AppArmor, SELinux, etc, then you did not understood the root of the issue with such modules.
- Krutonium 10mo ago
  Honestly the first half of that is just describing NixOS
  - chuckadams 10mo ago
    The second half is more or less Android. iOS isn't terribly different in that respect either.
    - drtgh 10mo ago
      Some basic permissions like Android, but the rest would need to be lower level, more like the configuration file of a firewall with intrusion detection system, let say, to use io_uring needing explicit permissions, the access to some memory regions, and so on.
M95D 10mo ago
Sometime around 2000 someone decided that /bin and /sbin isn't enough to boot and mount the rest of the system, so they added further complexity: an initrd/initramfs that does the basic job of /bin and /sbin. They had to complicate the kernel build process, the kernel update, the bootloader, the kernel command line and for what? Just because they didn't want the kernel to have the storage drivers built-in? So the /bin /sbin became redundant. Sometime around 2020 someone observed that no current Linux can boot without /usr anyway. So what did they do? Move everything from /usr to / and drop the whole /usr legacy? Noooo, that would be too simple. Move / to /usr. And because that is still too simple, also move /bin, /sbin and /usr/sbin to /usr/bin, and then keep symlinks at the old locations because who's gonna fix hardcoded paths in 99% of all Linux apps anyway?? Oh, how I wish I was born in the '60s, when the world was still sane.
- dstroot 10mo ago
  > Oh, how I wish I was born in the '60s, when the world was still sane. As one who was, I find it makes the current world even harder to accept. Be careful what you wish for.
- amelius 10mo ago
  And you haven't even touched upon paths used by Snap and Flatpak.
- Starlevel004 10mo ago
  > So what did they do? Move everything from /usr to / and drop the whole /usr legacy? Noooo, that would be too simple. It's a lot simpler to merge them in a directory that can be mounted across multiple machines than have four separate mountpoints.
  - kees99 10mo ago
    Mount-points were key to early history of the split. Nowadays it's more about not breaking shebangs. Nearly every shell script starts with "#!/bin/sh", so you can't drop /bin. Similarly, nearly every python script starts with "#!/usr/bin/env python", so you can't drop /usr/bin. Hence symlink.
shevy-java 10mo ago
Rob Landley is right. Others realised this too - see GoboLinux. But some regular distributions too. Slapping it down as "FHS is now a standard" does not change anything. People will ask why it is suddenly a standard when it hasn't made any sense at all whatsover. bin versus sbin is also pointless. Inertia is one primary reason why nobody fixes things usually.
codazoda 10mo ago
I wrote an article to remind myself which bin directory I prefer and why. https://joeldare.com/where-i-put-personal-binaries-in-macos https://joeldare.com/where-i-put-personal-binaries-in-macos
aap_ 10mo ago
This is low-effort fantasy history. It may be directionally correct, but why bother when you don't care about the details? From analyzing the UNIX manuals and other old files we get the following (not fully complete) picture: We'll skip PDP-7 UNIX, no hierarchical file system yet. UNIX v1 on the PDP-11 had an RF11 fixed head disk (1mb) for / and swap, and an RK05 moving head disk (2.5mb) for /usr (the user directories) By v2 they had added a second RK05 at /sys for things like the kernel, manual pages, and system language stuff like the c compiler and m6. By v3 they added yet another RK05 at /crp for, well, all sorts of crap (literally), including yacc apparently. /usr/bin is mentioned here for the first time. I don't feel like looking up when sbin was first introduced but it is not a Bell Labs thing. possibly BSD or AT&T UNIX? Binaries that one would normally not want to run were kept in /etc, which includes thing like init, mount, umount, getty, but also the second pass of the assembler (as2), or helpers like glob. Also i don't know when /home became canonical but at Bell Labs it was never a thing (plan 9 has user directories in /usr where they had always belonged logically). The lib situation is more difficult. Looks like it started with /usr/lib. By v3 we find the equivalent directory as /lib, where it contains the two passes of the C compiler (no optimization pass back then), C runtime and lib[abc].a (assembler, B, C libraries respectively). /usr/lib had been repurposed for non-object type libraries, think text-preparation and typesetting. By v4 the system had escaped the labs (see the recent news) and at that point everyone modified the system to their taste anyway. Perhaps it should be noted that the v7 distribution (which is the first that is very clearly the ancestor of every modern UNIX) has no /usr/bin, only /bin. /lib and /usr/lib are split however. These are just some rough notes and due to a lack of early material they're still not as accurate as i would like. Also UNIX ran on more than one machine even in the early days (the manuals mention the number of installations) so there must have been some variation anyway. Something I'd like to know in particular is when and where RP03 disk drives were used. These are pretty huge in comparison to the cute RK05s.
- chuckadams 10mo ago
  I've always heard /sbin contained only static binaries, so it seems likely the distinction would have grown out of BSD. I am also totally adding a /crp directory to my next system.
foresto 10mo ago
Does anyone know why, when Lennart and friends wrote their XDG Base Directory Specification, they decided that each user should replicate /usr/local/ subdirectories under $HOME/.local/? Doesn't being under $HOME make .local redundant? I guess one could argue for binaries going in an architecture-specific subdirectory if $HOME was on a shared filesystem, but that's not what's being done here. To me, $HOME/.local/share and its siblings are just a needless level of indirection, forcing me to jump through an extra hoop every time I want to access what's in there. (I know it's sometimes possible to override it with an environment variable, but the predictably spotty support for those overrides means I would then have to look for things in two places. I think sensible defaults would be nicer.)
- dataflow 10mo ago
  Dunno the historical reason but I sure as heck find it nice to know without ambiguity that the folder called "share" corresponds to that special directory and isn't a random folder in my home directory for files that were intended to be e.g. shared with someone.
  - foresto 10mo ago
    Sure, but I think the better choice for $HOME/.local/share would be $HOME/.share, not $HOME/share This would match the more recent $HOME/.var that's in widespread use via Flatpak.
- hulitu 10mo ago
  > Does anyone know why, when Lennart and friends wrote their XDG Base Directory Specification, It is Microsoft thing. You must pollute the user's /home as much as you can. Can i say that i have 3 daemons on my computer respobsible for ... credentials. This is the way to go.
- 1718627440 10mo ago
  The ~/.local prefix is so that you don't pollute the home directory too much.
  - 10mo ago
olowe 10mo ago
Plan 9 (a Bell Labs successor to Unix) did away with the whole bin, sbin, usr/sbin thing and its shell only looked in /bin. How things got into /bin is a different story. For me this was an eye-opener. I kept trying to wrap my head around all these different paths and "standards" because I thought it was correct and deliberately designed. Looking back through the history this doesn't seem to be the case; I feel much better for being confused by all the different PATH conventions and strict hierarchies.
mannyv 10mo ago
The reason you didn't just drop stuff in /usr/local? Space. One of our devs was also a gimp contributor, and he dropped gimp into /usr/local and filled up the filesystem. And back then package managers didn't exist, so you had to read the makefile and hope you didn't remove anything that was shared /opt/gimp or /usr/local/gimp. Local because in some places they mounted an nfs share, and local was local to you.
grymoire1 10mo ago
Some people think today's file hierarchy is complicated. .That's amusing. I worked at an R&D center where we had hundreds of UNIX systems orf all types(i.e. Sun, Ultrix, HP, Symbolics, etc.) We also had Sun 2's , 3's and 4's - each with different CPU's/architectures and incompatible binaries. Some Suns had no disks at all. And with hundreds of systems, we literally had a hundred different servers across the entire site. I would compile a program for a Sun 3, and needed a way to install the program once, for use on hundreds of computers. Also teams of people on dozens of different computers needed to share files with each other. This was before SSH. We had to use NFS. It was fairly seamless and .... interesting.
- burnt-resistor 10mo ago
  I did consulting work for a place with Sun 2's and 4's, AIX, HP-UX, Xenix, and SCO. There was NFS, Netware, and UUCP all cheerfully coexisting on an IPv4 network that used a public Class C for NATed internal use. (It's now a zombie IP range that doesn't do anything useful.) Later, I wrote code a university that had even more heterogeneous clusters. The problem today is the siloification and bias against system diversity that doesn't account for proper software configuration management and support of multiple platforms. Portability is a dying art.
grymoire1 10mo ago
One complication caused by shared libraries was the security threat. An executable using a shared library allowed the user to execute with a different (updated) library without recompilation. This is a security threat, especially with SETUID programs. If you could change the library, you could install new code and gain privileged access. This was why /usr/sbin was created - all of the programs there were compiled with static libraries.
1970-01-01 10mo ago
This is also around the same time Vista started enforcing the AppData and ProgramData folder redirect. It was a messy time for all developers. IMHO they made the right decision by enforcing that redirect as we now know where every file should be in a Windows program.

199 points by csmantle 10mo ago

Reason: because it’s always been that way. Additional info: many rules from many places are now in force that maintain the historical structure.

miggol 10mo ago

I've only used modern immutable Linux (Alpine, MicroOS) and wondered why of all places `/var/` was chosen as the location for rw stuff. It's fun to be reminded that there was of course a time when an immutable OS was the default, and you ran it off of floppies. So there's a lot of history to using `/var/` for that. Guess we've come full circle!

rendaw 10mo ago
Was it immutable? I thought it was just different storage types, like you'd have a smaller disk for the root stuff and then make var on a larger disk. I'm surprised that, having something immutable, you'd choose to go the other direction.
- miggol 10mo ago
  Good point, considering the nature of floppies I suppose it technically mustn't have been immutable. But I feel like it would have been wise to mount your OS root read-only to prevent yourself from accidentally ruining your (possibly only) copy of your OS. At least before you had a reasonably sized hard drive. > I'm surprised that, having something immutable, you'd choose to go the other direction. I can somewhat imagine that having been limited by space and having to swap out disks all the time one would jump on the train of mutability without fully appreciating the benefits of immutability.

cowlby 10mo ago

Obligatory XKCD Standards https://xkcd.com/927/ https://xkcd.com/927/

esparanto 10mo ago
When I hear people complaining about this sort of thing, I want to say, “Just go and invent your own, then.” But then you get things like Esperanto. Esperanto takes about 1/4 of the time to learn compared to other languages. It’s taught in China and used as primary language in some settings. But, aside from a large number of people learning some Esperanto from Duolingo several years ago, it’s just another language now to have to learn.

roger_ 10mo ago

Is there a mainstream distro that disregards all the legacy cruft? Gobo, but that’s not really mainstream. Mac OS?

deleted 10mo ago
[deleted]
wasting_time 10mo ago
NixOS and Guix are fairly established in this regard. macOS is certified Unix, and necessarily implements the "legacy" cruft.
- behnamoh 10mo ago
  at some point we gotta let go of legacy stuff tho, and Apple has shown in the past that they're not afraid of doing that.
- Imustaskforhelp 10mo ago
  I had written a similar comment here asking for people's opinion but I would like to add something that I know about which I didn't see in your list Tinycorelinux I know that it doesn't follow the best user practices etc. but I did find its tcz package format fascinating because they kind of work similar to mountable drives and I am not exactly sure but I am fairly certain that a modern package management system where two or more packages with conflicts etc. can run on the same system. I really enjoyed the idea of gobolinux as well. I haven't played with that but it would be good if some more mainstream os could also implement it. Nix and Guix are more mainstream but they also require to learn a new language and I think that we might need something in the middle like gobo but perhaps more mainstream or adding more ideas / additions perhaps? I would love it if someone can tell me about some projects we are missing to talk about and what they add on the table etc. I haven't tried Gobo though so I am not sure but I really wish more distros could add features like gobo, perhaps even having a gobofied debian/fedora eh?
  - yjftsjthsd-h 10mo ago

JodieBenitez 10mo ago

> I'm still waiting for /opt/local to show up... Well... battlestation : ls /opt/ homebrew local :'-)

JodieBenitez 10mo ago
And funnily enough, only one file there. battlestation : tree /opt/local /opt/local └── lib └── libgeos_c.dylib -> /opt/homebrew/lib/libgeos_c.dylib 2 directories, 1 file Why ? I don't know. But I do need libgeos.

ck2 10mo ago

and /local/ to top off the confusion

behnamoh 10mo ago

This is what happens when a system is designed by multiple people and companies over a long period of time. An amalgam of ideas which are there just because. There's no reason Linux should be like this. e.g., see https://gobolinux.org/ https://gobolinux.org/ which has more sane dirs.

jmclnx 10mo ago
Not really, back then disks were very expensive and you had no choice but to split. And disk sizes were very small. But, I in a way int kind of makes sense. /bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime. 's' for items regular users do not need to run, remember, UN*X is a multi-user system, not a one person system like macs, windows and in most cases Linux.
- eviks 10mo ago
  How does splitting help save space?
  - yjftsjthsd-h 10mo ago
    I think it's less about saving space and more that / and /usr can be two separate disks
- kokada 10mo ago
  > /bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime. Nowadays most Linux systems boot with initramfs, that is a compressed image that includes everything the system needs to boot, so you're basically saying /bin and /sbin is useless.
  - schmuckonwheels 10mo ago
    > initramfs, that is a compressed image that includes everything the system needs to boot Not always (raise your hand if you've had an unbootable system due to a broken or insufficient initrd). In retrospect, the whole concept of the initrd seems like an enormous kludge that was thrown together temporarily and became the permanent solution.

chrisweekly 10mo ago

Ha! TIL. Funny and informative post. Speaking of things which are needlessly complex, I'm reminded of this classic post on the tortured history of the browser User-Agent header: https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/ Highly recommended!

paulddraper 10mo ago

1. The title says “understanding sbin” but the content gives zero understanding of that. If someone has a historical explanation, please provide it. 2. “Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt” Not exactly. /usr/local exists so you don’t accidentally mess up your distro/package manager by changing its files. It’s “local” to your installation. But it is still structured — /usr/local/bin, /usr/local/lib, etcetera — divided into binaries, shared libraries, manpages. Whereas /opt has no structure. It’s “the wild west”…application binaries, libraries, configuration, data files, etcetera with no distinction. Apps with “universal” packaging, or sometimes secondary package managers. For example /usr/local/bin is normally part of PATH, but /opt is not (unless eg homebrew adds it to your bashrc).

vntok 10mo ago
What do you mean?
- paulddraper 10mo ago
  I mean the article doesn’t explain sbin. The author symlinks it to bin but doesn’t explain why it exists.
  - em500 10mo ago
    I'm believe /sbin was introduced/standardized in System V Release 4. It's present in SVR4 (1988) but not in SVR3 (1987). Another candidate is would be some old BSD (check 4.2 or 4.3 (1986) if anyone has a running system). I'm guessing it was introduced to finally move out all the (mostly system) binaries from /etc, which in ancient Unix from Bell Labs in the 1970s really meant "etc", as in stuff that didn't fit elsewhere rather than system config files, so it contained binaries like init, mount, umount.

glhaynes 10mo ago

On a similar note: just the other day I was thinking about how the Unixy systems I used 20+ years ago used to nudge/push you toward creating several actual partitions during installation. Maybe /, /usr, swap… maybe one or two more? IIRC, I think some of the BSDs, at least, maybe still do? Always seemed weird and suboptimal to me for most installations, but I remember being told by graybeards at the time that it was the Right Way.

calvinmorrison 10mo ago
still makes sense to prevent overruns right? IE /home/ cant drop the whole system just cause you torrented too many debian ISOs and blew out your disk. same for /var/ or wherever you store your DB tables like MySQL.
- glhaynes 10mo ago
  Ah, yeah, that makes sense, thanks. My experience as "sysadmin" has largely been from the standpoint of personal systems for which that has mostly not been a big concern for me.
- bpfrh 10mo ago
  Ironically using "modern" filesystems like zfs or btrfs you can do that if they are on the same disk
  - 1718627440 10mo ago
    Partitions are still on the same disk?
- smallstepforman 10mo ago
  The inverse is also true - cannot download an 60Gb game due to partition size being too small even if there is cumulative free space available.
- homebrewer 10mo ago
  This is much better solved by quotas which can be adjusted on the fly without rewriting your partition tables.

IgorPartola 10mo 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 :)

deleted 10mo ago
[deleted]
p_ing 10mo ago
> /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.
- holowoodman 10mo ago
  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.
theandrewbailey 10mo ago

schmuckonwheels 10mo ago

This post gets some of the details wrong. /usr/local is for site-local software - e.g. things you compile yourself, i.e in the case of the BSDs the ports collection - things outside the base system. (They may be compiled for you). Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux. /opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software. You're putting your $500k EDA software under /opt.

yjftsjthsd-h 10mo ago
> Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux. The Linux base system is managed by the package manager, leaving local for the sysadmin to `make install` into
- schmuckonwheels 10mo ago
  > The Linux base system There is no such thing as a Linux base system. Separate components, separate people. Hence the term Ganoo plus Leenox...
  - yjftsjthsd-h 10mo ago
    Well, no, my exact argument is that there is a base system, even if it is composed of assorted components. If you install Debian (or whatever) on a machine, the software installed by the package manager ships as a unified release that has been adapted to work together. I think it's reasonable to call that the base OS. And then, separate from that base system that is managed by the package manager, the local admin my install things into /usr/local.
    - schmuckonwheels 10mo ago
      If you can remove GNU coreutils and replace them with something else (like that Rust garbage) then you don't have a base system. You have a loose collection of packages around a kernel.

vxxzy 10mo ago

I am going to use this story in place of the "Pot Roast Principle" [0] [0]: https://www.psychologytoday.com/us/blog/thinking-makes-it-so/201402/the-pot-roast-principle https://www.psychologytoday.com/us/blog/thinking-makes-it-so...

age123456gpg 10mo ago

Here [1] is a related trick in the old Unix to run either `foo`, `/bin/foo` or `/usr/bin/foo` (apparently before `PATH` convention existed): char string[10000]; strp = string; for (i=0; i<9; i++) *strp++ = "/usr/bin/"[i]; p = *argv++; while(*strp++ = *p++); // string == "/usr/bin/foo" execv(string+9, args); // foo (execv returns only in case of error, i.e. when foo does not exist) execv(string+4, args); // /bin/foo execv(string, args); // /usr/bin/foo [1] https://github.com/dspinellis/unix-history-repo/blob/Research-V4-Snapshot-Development/usr/source/s2/nohup.c https://github.com/dspinellis/unix-history-repo/blob/Researc...

drtgh 10mo ago

Nowadays I think packages should turn to portable applications isolated within their own directories. Those directories would have an standard libraries directory that the application would use. Latter, if desired, the system, could override those libraries with another ones (newer compatible or patched), more thinking is needed about this. The key, from the process point of view, would to limit the access of such process to their own directories and some very limited system only local services by default, And to extend this permissions, each binary in such directory would need to be in companion of a permissions request file that would require the approbation from the user or the system defaults patterns (each distro would have a point of view I guess), in the aim of improve process isolation and system, drivers, services access permissions. This would need also restructure the console philosophy, how can manage the processes, and so on, that would need a big restructuration. I mean, anyway people is duplicating space with containers trying to isolate process, remark in trying. I know this is unrealistic due the deep change it would suppose, so consider I'm just thinking out loud. PS: If you answer it already exists with AppArmor, SELinux, etc, then you did not understood the root of the issue with such modules.

Krutonium 10mo ago
Honestly the first half of that is just describing NixOS
- chuckadams 10mo ago
  The second half is more or less Android. iOS isn't terribly different in that respect either.
  - drtgh 10mo ago
    Some basic permissions like Android, but the rest would need to be lower level, more like the configuration file of a firewall with intrusion detection system, let say, to use io_uring needing explicit permissions, the access to some memory regions, and so on.

M95D 10mo ago

Sometime around 2000 someone decided that /bin and /sbin isn't enough to boot and mount the rest of the system, so they added further complexity: an initrd/initramfs that does the basic job of /bin and /sbin. They had to complicate the kernel build process, the kernel update, the bootloader, the kernel command line and for what? Just because they didn't want the kernel to have the storage drivers built-in? So the /bin /sbin became redundant. Sometime around 2020 someone observed that no current Linux can boot without /usr anyway. So what did they do? Move everything from /usr to / and drop the whole /usr legacy? Noooo, that would be too simple. Move / to /usr. And because that is still too simple, also move /bin, /sbin and /usr/sbin to /usr/bin, and then keep symlinks at the old locations because who's gonna fix hardcoded paths in 99% of all Linux apps anyway?? Oh, how I wish I was born in the '60s, when the world was still sane.

dstroot 10mo ago
> Oh, how I wish I was born in the '60s, when the world was still sane. As one who was, I find it makes the current world even harder to accept. Be careful what you wish for.
amelius 10mo ago
And you haven't even touched upon paths used by Snap and Flatpak.
Starlevel004 10mo ago
> So what did they do? Move everything from /usr to / and drop the whole /usr legacy? Noooo, that would be too simple. It's a lot simpler to merge them in a directory that can be mounted across multiple machines than have four separate mountpoints.
- kees99 10mo ago
  Mount-points were key to early history of the split. Nowadays it's more about not breaking shebangs. Nearly every shell script starts with "#!/bin/sh", so you can't drop /bin. Similarly, nearly every python script starts with "#!/usr/bin/env python", so you can't drop /usr/bin. Hence symlink.

shevy-java 10mo ago

Rob Landley is right. Others realised this too - see GoboLinux. But some regular distributions too. Slapping it down as "FHS is now a standard" does not change anything. People will ask why it is suddenly a standard when it hasn't made any sense at all whatsover. bin versus sbin is also pointless. Inertia is one primary reason why nobody fixes things usually.

codazoda 10mo ago

I wrote an article to remind myself which bin directory I prefer and why. https://joeldare.com/where-i-put-personal-binaries-in-macos https://joeldare.com/where-i-put-personal-binaries-in-macos

aap_ 10mo ago

This is low-effort fantasy history. It may be directionally correct, but why bother when you don't care about the details? From analyzing the UNIX manuals and other old files we get the following (not fully complete) picture: We'll skip PDP-7 UNIX, no hierarchical file system yet. UNIX v1 on the PDP-11 had an RF11 fixed head disk (1mb) for / and swap, and an RK05 moving head disk (2.5mb) for /usr (the user directories) By v2 they had added a second RK05 at /sys for things like the kernel, manual pages, and system language stuff like the c compiler and m6. By v3 they added yet another RK05 at /crp for, well, all sorts of crap (literally), including yacc apparently. /usr/bin is mentioned here for the first time. I don't feel like looking up when sbin was first introduced but it is not a Bell Labs thing. possibly BSD or AT&T UNIX? Binaries that one would normally not want to run were kept in /etc, which includes thing like init, mount, umount, getty, but also the second pass of the assembler (as2), or helpers like glob. Also i don't know when /home became canonical but at Bell Labs it was never a thing (plan 9 has user directories in /usr where they had always belonged logically). The lib situation is more difficult. Looks like it started with /usr/lib. By v3 we find the equivalent directory as /lib, where it contains the two passes of the C compiler (no optimization pass back then), C runtime and lib[abc].a (assembler, B, C libraries respectively). /usr/lib had been repurposed for non-object type libraries, think text-preparation and typesetting. By v4 the system had escaped the labs (see the recent news) and at that point everyone modified the system to their taste anyway. Perhaps it should be noted that the v7 distribution (which is the first that is very clearly the ancestor of every modern UNIX) has no /usr/bin, only /bin. /lib and /usr/lib are split however. These are just some rough notes and due to a lack of early material they're still not as accurate as i would like. Also UNIX ran on more than one machine even in the early days (the manuals mention the number of installations) so there must have been some variation anyway. Something I'd like to know in particular is when and where RP03 disk drives were used. These are pretty huge in comparison to the cute RK05s.

chuckadams 10mo ago
I've always heard /sbin contained only static binaries, so it seems likely the distinction would have grown out of BSD. I am also totally adding a /crp directory to my next system.

foresto 10mo ago

Does anyone know why, when Lennart and friends wrote their XDG Base Directory Specification, they decided that each user should replicate /usr/local/ subdirectories under $HOME/.local/? Doesn't being under $HOME make .local redundant? I guess one could argue for binaries going in an architecture-specific subdirectory if $HOME was on a shared filesystem, but that's not what's being done here. To me, $HOME/.local/share and its siblings are just a needless level of indirection, forcing me to jump through an extra hoop every time I want to access what's in there. (I know it's sometimes possible to override it with an environment variable, but the predictably spotty support for those overrides means I would then have to look for things in two places. I think sensible defaults would be nicer.)

dataflow 10mo ago
Dunno the historical reason but I sure as heck find it nice to know without ambiguity that the folder called "share" corresponds to that special directory and isn't a random folder in my home directory for files that were intended to be e.g. shared with someone.
- foresto 10mo ago
  Sure, but I think the better choice for $HOME/.local/share would be $HOME/.share, not $HOME/share This would match the more recent $HOME/.var that's in widespread use via Flatpak.
hulitu 10mo ago
> Does anyone know why, when Lennart and friends wrote their XDG Base Directory Specification, It is Microsoft thing. You must pollute the user's /home as much as you can. Can i say that i have 3 daemons on my computer respobsible for ... credentials. This is the way to go.
1718627440 10mo ago
The ~/.local prefix is so that you don't pollute the home directory too much.
- 10mo ago

olowe 10mo ago

Plan 9 (a Bell Labs successor to Unix) did away with the whole bin, sbin, usr/sbin thing and its shell only looked in /bin. How things got into /bin is a different story. For me this was an eye-opener. I kept trying to wrap my head around all these different paths and "standards" because I thought it was correct and deliberately designed. Looking back through the history this doesn't seem to be the case; I feel much better for being confused by all the different PATH conventions and strict hierarchies.

mannyv 10mo ago

The reason you didn't just drop stuff in /usr/local? Space. One of our devs was also a gimp contributor, and he dropped gimp into /usr/local and filled up the filesystem. And back then package managers didn't exist, so you had to read the makefile and hope you didn't remove anything that was shared /opt/gimp or /usr/local/gimp. Local because in some places they mounted an nfs share, and local was local to you.

grymoire1 10mo ago

Some people think today's file hierarchy is complicated. .That's amusing. I worked at an R&D center where we had hundreds of UNIX systems orf all types(i.e. Sun, Ultrix, HP, Symbolics, etc.) We also had Sun 2's , 3's and 4's - each with different CPU's/architectures and incompatible binaries. Some Suns had no disks at all. And with hundreds of systems, we literally had a hundred different servers across the entire site. I would compile a program for a Sun 3, and needed a way to install the program once, for use on hundreds of computers. Also teams of people on dozens of different computers needed to share files with each other. This was before SSH. We had to use NFS. It was fairly seamless and .... interesting.

burnt-resistor 10mo ago
I did consulting work for a place with Sun 2's and 4's, AIX, HP-UX, Xenix, and SCO. There was NFS, Netware, and UUCP all cheerfully coexisting on an IPv4 network that used a public Class C for NATed internal use. (It's now a zombie IP range that doesn't do anything useful.) Later, I wrote code a university that had even more heterogeneous clusters. The problem today is the siloification and bias against system diversity that doesn't account for proper software configuration management and support of multiple platforms. Portability is a dying art.

grymoire1 10mo ago

One complication caused by shared libraries was the security threat. An executable using a shared library allowed the user to execute with a different (updated) library without recompilation. This is a security threat, especially with SETUID programs. If you could change the library, you could install new code and gain privileged access. This was why /usr/sbin was created - all of the programs there were compiled with static libraries.

1970-01-01 10mo ago

This is also around the same time Vista started enforcing the AppData and ProgramData folder redirect. It was a messy time for all developers. IMHO they made the right decision by enforcing that redirect as we now know where every file should be in a Windows program.