Understanding the bin, sbin, usr/bin, usr/sbin split (2010)

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

by taubek • 4 years ago

534 227 4 years ago

lists.busybox.net

Its funny how many quirks of UNIX/C/etc go back to the severe limitations of early day computers. Which is why using modern languages like Rust and its compiler really feels like coming up for air.

alecmg• 4 years ago

I think Windows is even more permeated with legacy

Off the top of my head:

Nobody questions why main drive is C:, remnant of [an] early computer having two floppy (not sure) drives on A: and B:

Or more recent - C:/Windows/System32 holds 64 bit executables; 32 bit exectuables live in C:/Windows/SysWOW64

quickthrower2• 4 years ago

Yeah that is a windows gotcha!

fer• 4 years ago

Nobody questions why main drive is C:, remnant of [an] early computer having two floppy (not sure) drives on A: and B:

Recently I was trying to install some obscure driver for a device that doesn't autodetect in my Windows 10 work computer, I had to go through the old school "add device" wizard. When clicking to manually provide the driver, the dialog is exactly (or almost?) the same as the one from Windows 95, and the path defaults to... A:\! There's no floppy on this computer, there even isn't an optical drive!

mlatu2• 4 years ago

so C:/windows/system is a remnant from the 16bit era?

thg• 4 years ago

Windows is a 32 bit shell for a 16 bit extension to an 8 bit Operating System designed for a 4 bit microchip by a 2 bit company which can't stand one bit of competition.

sph7• 4 years ago

And I'd never map a network voume on D:, that's reserved for the CD drive!

indrora2• 4 years ago

Fun fact this is the second time Microsoft have pulled this. The first time was for legacy 16 bit Windows applications running on Windows NT. Since most people have moved to 64bit processors, it has been shuttered.

https://en.wikipedia.org/wiki/Windows_on_Windows

DavidVoid• 4 years ago

As a user, the main one that really annoys me is the "Program Files" vs "Program Files (x86)" split. I can kinda see why they have to be different folders, but why did they have to name it "... (x86)" instead of "... (32bit)"?

You can call the 64 bit architecture x64 all you like, but it's still using the x86 instruction set and it's frequently referred to as x86-64, so naming that 32 bit only folder "... (x86)" will just make things more confusing than they should be.

pmoriarty6• 4 years ago

I'm a big fan of Scheme, which is just about as old as UNIX, and which is based on the even older LISP (which is even older than UNIX, going back to the 50's).

I'd infinitely prefer to use either than Rust.

smartmic• 4 years ago

Embedded guys try to understand and simplify...

It is indeed true that when you have limited resources, simpler - in the sense of better, more beautiful - solutions often emerge.

Waterluvian2• 4 years ago

Speaking of this, is there a good resource that elegantly but succinctly describes the intent of each of linux’s (Unix’s?) root directories?

I’ve spent like eight years with Ubuntu and realize it’s all symbol manipulation to me. I learn what is and goes where but all in practice and never because I understand the semantics.

wkz• 4 years ago

https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf

faho6• 4 years ago

You probably have a "hier" man page on your system. https://man7.org/linux/man-pages/man7/hier.7.html

Also systemd has a "file-hierarchy" man page for its understanding of the hierarchy, which includes e.g. its use of /run and which directory can be read-only - https://man7.org/linux/man-pages/man7/file-hierarchy.7.html

Waterluvian2• 4 years ago

Aha! Thanks so much.

drothlis• 4 years ago

Many distros, including Debian & Ubuntu, have merged /bin and /usr/bin, with symlinks for backwards compatibility: /bin -> /usr/bin (and similarly for /usr/lib etc).

https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...

pabs36• 4 years ago

The Debian/Ubuntu merged-/usr is incomplete, various things are broken by the way this was achieved:

https://wiki.debian.org/Teams/Dpkg/MergedUsr

kajiryoji• 4 years ago

Arch and Gentoo does the same, though I don't think they break their respective package managers

happymellon2• 4 years ago

Did Debian do it? I thought there was internal conflict in the project whether it would happen, and has been for a decade.

mlatu2• 4 years ago

you are looking for the https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

heinrichhartman• 4 years ago

Now that we understand this can we please put all system tools into /bin?

Disk space for binaries has not been a problem for decades now.

pilif2• 4 years ago

having the system mounted in its own sub directory rather than be spread over multiple directories (there's /usr/bin, /usr/share, /usr/lib, etc) has the advantage that a single read-only mount can mount the whole OS.

Having the OS mounted read-only provides some security benefits.

The other option would of course be to have / mounted ro and then have rw mounts in /home, /etc, /var and /tmp, but this is more complicated than a a rw / and a ro /usr

andrewshadura• 4 years ago

While that's true, these days initramfs is what performs this job.

hulitu2• 4 years ago

It depends. Fsck is slow on big hard drives. Also separating data from programs is a good idea.

captainmuon2• 4 years ago

Disk space was not really the issue. Back in the day extra partitions would actually mean you waste space. It's more efficient to put them on one partition.

The issue is organisation. There is already so much junk in the bin folders. I think it would be much neater to further split the bins into various categories: "shell tools" like ls, [, echo; "applications" like firefox, inkscape, "helpers" like gnome-settings-daemon, ... There is no need to show weird daemons when pressing TAB in bash, and there is no need to show `ls` when picking an application via a GUI.

pmoriarty6• 4 years ago

The problem with that suggestion is that some things belong in more than one category.

A much more flexible way of organizing is to use tags. This way a file could have more than one tag.

Having a tag hierarchy would be even better, so you can browse down the hierarchy as you'd traverse the tree structure of a typical file system (with the added advantage of allowing a single file to have multiple categories that it could be in).

mrspuratic• 4 years ago

A long time ago, as a novice sysadmin, I spent some unhappy time fixing a broken Solaris server. The problem was fsck was in /usr/sbin, /usr was a mount point on an external drive array that got its power yanked. Challenge: to boot you need to mount /usr, but first you have to fsck it using the binary in /usr/sbin ...

After that I would make sure to have some working (static) binaries for rescue on every *nix system, tar at least, and on Solaris an extra /usr/sbin/fsck under the /usr mount point). You can fix a lot of things with tar, sed and netcat.

mjevans• 4 years ago

These days a static-linked copy of busybox on the root partition is usually enough; assuming you have the space for that. A 'full' initramfs can also help in case you need to bring over a USB drive of tools from another system or have changed hardware.

j16sdiz• 4 years ago

There's no actual REASON for any of it anymore.

No reason to do it on embedded system. Lots of backward compatibility reason on servers/desktops.

pilif2• 4 years ago

it's my understanding that most distros by now have moved to have their stuff in /usr, though there might still be backwards compatibility symlinks of course.

hulitu2• 4 years ago

Good luck mounting /usr when mount is in /usr/bin. Not everybody uses a ramdisk to boot the system.

usrbinbash4• 4 years ago

Backward compatibility can be ensured with a couple of symlinks.

moffkalast2• 4 years ago

backward compatibility

You're kidding me right? Nobody ever bothers with that for anything else and the company I work at spends like more than half the time resolving stupid install breaking changes that nobody asked for. This would just be one minor extra thing on that pile, but at least it would make sense for once.

EdSchouten4• 4 years ago

I once sent out a proposal on the FreeBSD lists to merge /sbin with /bin, and /usr/sbin with /usr/bin. People were concerned that this would slow down the system, due to PATH lookups taking longer. Even when I demonstrated the opposite was true (it being faster due to fewer directories needing to be scanned), I wasn't able to get consensus. What a shame.

gorgoiler• 4 years ago

What about /usr/games! Insensitive clod!

tremon3• 4 years ago

/usr/games should never have existed in the first place, imnsho. If it's a small game, its binary could just have been put in /usr/bin. If it's a large game, it probably should be in /opt/$game.

Maursault4• 4 years ago

What a shame.

I think this is a pretty dangerous attitude, and it is really the only thing wrong with Linux, and probably leads to replacement of simple structure and functionality with a complex software suite that is merely more convenient, like systemd. "Let's change this thing because we want to, because it will improve performance 0.0024%"

Feature creep is what happens when restraint was not exercised.

IMO, since it really doesn't matter what the filesystem looks like, leave it be for standards and compatibility. Seriously, it takes, idk, maybe, a lack of humility to want to change fundamental characteristics of UNIX when the reasons for doing so are a little capricious.

I'm not really talking about the parent, fwiw. I'm talking about the crowd and ochlocracy.

spijdar• 4 years ago

To be clear, GP's stated intention was to simplify a complex structure into a "simple structure", about which the stated concern was a loss of performance, to which GP's rebuttal was it actually improved performance. The main motivator for flattening the filesystem hierarchy isn't really performance, it's simplifying the organization, and (arguably) bringing it more in like with "pure UNIX", vs the quagmire of commercial SysV derivatives with a few dozen different bin directories in PATH, with esoteric justification.

sph7• 4 years ago

It's also dangerous and tiring the opposite attitude in the Linux world: don't dare change something that has been there for 30 years. Like this very article, there were plenty saying "the /usr split is there for a reason!". No, it's just an historical quirk.

There's plenty greybeards that for them "Linux" is a full screen terminal running emacs on decade-old hardware. "I don't use antialiased fonts, why the hell should I care about decent HiDPI support?" And then protest every time some working group tries to modernise and improve the Linux desktop. You see them every time on this forum.

I'm a greybeard, I've used Linux full time on the desktop for 20 years. I don't get this conservative, "we don't need it" attitude.

Cthulhu_• 4 years ago

Hypothetically speaking, would forking FreeBSD or a *nix to use a simpler folder structure be feasible? I can imagine a lot of package managers and applications make assumptions about the folder structure though, so there would have to be a lot of changes made to make everything work.

I was thinking "just symlink /sbin with /bin", but there would probably be conflicts.

hnlmorg4• 4 years ago

Hypothetically speaking, would forking FreeBSD or a nix to use a simpler folder structure be feasible?*

Not only feasible but it's been implemented a few times over the years. The most notable being GoboLinux[1][2], which is nearly 20 years old.

[1] https://en.wikipedia.org/wiki/GoboLinux

[2] https://gobolinux.org/

I was thinking "just symlink /sbin with /bin", but there would probably be conflicts

Given how long /sbin et al have been around, there would always be some edge cases. However it is still possible to do. GoboLinux uses symlinks to achieve LFH[3] compatibility while still having friendly directory names. ArchLinux also just has one bin directory and uses symlinks for compatibility:

  » ls -l / | grep bin                                                                                                                                                                                   
  lrwxrwxrwx   1 root root              7 2021-12-07 02:41 bin -> usr/bin
  lrwxrwxrwx   1 root root              7 2021-12-07 02:41 sbin -> usr/bin

  » ls -l /usr | grep bin                                                                                                                                                                                
  drwxr-xr-x   5 root root 110,592 2022-05-06 09:23 bin
  lrwxrwxrwx   1 root root       3 2021-12-07 02:41 sbin -> bin

[3] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

em5002• 4 years ago

Why hypothetical, Gobo Linux[1] has already done it. Or if you want to just hide (rather than replace) the traditional Unix hierarchy from the user, you get macOS (inherited from NeXTSTEP).

The problem is that the actual benefits a pretty nebulous, so it's probably not worth the effort (and drawbacks of using different conventions than most others *nix users).

[1] https://www.gobolinux.org/

avidphantasm• 4 years ago

It’s called Darwin.

hpb422• 4 years ago

ArchLinux symlinks /sbin, /bin and /usr/sbin to /usr/bin. And also /lib, /lib64, /usr/lib64 to /usr/lib:

$ ls -la / | grep -e bin -e lib lrwxrwxrwx 1 root root 7 Dec 6 23:41 bin -> usr/bin lrwxrwxrwx 1 root root 7 Dec 6 23:41 lib -> usr/lib lrwxrwxrwx 1 root root 7 Dec 6 23:41 lib64 -> usr/lib lrwxrwxrwx 1 root root 7 Dec 6 23:41 sbin -> usr/bin

jmclnx2• 4 years ago

Also FreeBSD (and other BSDs) usually mount /usr on its own partition. I think that causes issues in Linux these days. So yes, merging in the BSDs may be a big change.

FWIW, Slackware keeps the separate, following the Linux Standard Base.

https://en.wikipedia.org/wiki/Linux_Standard_Base

tremon3• 4 years ago

For me, the value in having a bin vs sbin split is in keeping system binaries (daemons, root-only tools) off the user's path. There's little value in a user starting inetd or apache2 from the command line, so why should those be present in the user's path? Same thing for system management tools that require root access for everything, such as dmsetup, blkdiscard, or shutdown (yes, Linux examples as I don't know FreeBSD).

Having only usable binaries in the path aids discoverability of the system.

usrbinbash4• 4 years ago

so why should those be present in the user's path

And why shouldn't they?

It's not as if a user could do anything damaging with them, if the system is setup properly.

Having only usable binaries in the path aids discoverability of the system.

Except when someone new has to go online to ask "I found this tutorial telling me to use the `xyz` command to do this, but all I get is `bash: xyz: command not found`, please help!"

EdSchouten4• 4 years ago

There are many tools in sbin that should have been in bin instead. For example, there’s no need to run ifconfig as root if you only want to display the current set of addresses. Yet it lives in sbin.

This means that in practice people will just add sbin to PATH to get a somewhat usable system, which makes the division between bin and sbin useless.

Furthermore, on BSD derived systems binaries that should not be invoked by users directly (e.g., daemons) need to be stored in libexec.

mekster5• 4 years ago

Don't you need sbin in PATH anyway when you want to run them with sudo?

cassandratt• 4 years ago

I do on my laptop Dev environments, but I do understand your point, it’s not a use case any but resource constrained devs do.

ivanhoe• 4 years ago

Having only usable binaries in the path aids discoverability of the system.

Downside is it stops the autocomplete, so if you, say, wish to check quickly how binary is called on the system, e.g. if you should sudo apache2 or httpd, it will not work...

cryptonector2• 4 years ago

the value in having a bin vs sbin split is in keeping system binaries (daemons, root-only tools) off the user's path

I think it's nice to be able to keep admin utils out of an admin's PATH when the admin isn't intending to use them.

It's much less interesting to me to keep daemons and such out of anyone's PATH if running them can't do much, though usually those things really belong in a libexec directory and should be exec'ed intentionally only.

pseudostem• 4 years ago

Please correct me if I'm wrong. Aren't binaries in /sbin and /usr/sbin statically linked as opposed to no requirement like this for files living in /bin and /usr/bin?

I always thought the rationale was that if statically linked binaries are on different partition they can be used to recover the system from a failure.

Edit: files in /bin are also statically linked, and I am unsure about what I wrote above but vaguely recall something like that

patrck• 4 years ago

Yeah, this is received unix lore: anything needed to recover a system needs to be statically linked and in /bin or /sbin.

upofadown2• 4 years ago

I just checked and the programs in /bin on OpenBSD are in fact statically linked. The ones in /usr/sbin are not.

pmoriarty6• 4 years ago

It's nice to be able to still run on a crippled system without access to dynamically linked executables, so you can recover. But in practice, wouldn't just about anyone simply boot to a more capable recovery system (via another partition, USB drive, netboot, etc...)?

gjadi2• 4 years ago

It is specified this way on OpenBSD: https://man.openbsd.org/man7/hier.7

/bin/ User utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.
/sbin/ System programs and administration utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.

mekster5• 4 years ago

What ancient system makes a speed difference in command lookup in PATH?

EdSchouten4• 4 years ago

Calls like execvp() do little more than splitting PATH on ':', followed by repeatedly invoking execve() on ${dir}/${filename}. The fewer elements you have in PATH, the fewer execve() calls need to be performed in the worst case.

teknopaul• 4 years ago

What was the reason for wanting to merge? Change is breakage for someone so their ought to be a reason to do it, rather that a reason not to.

We _could_ all decide to drive on the otherside of the road, if the other side is better, but you have to incorporate the cost of the change.

usrbinbash4• 4 years ago

Change is breakage for someone so their ought to be a reason to do it,

Simplicity is reason enough to change something.

When things break because of reasonable change, they can be fixed. And in this case, backwards compatibility can be ensured simply by symlinking things.

cryptonector2• 4 years ago

A merge needs to be done carefully for backwards compatibility.

You could move all the things in /bin and /sbin to /usr/bin and /usr/sbin, then leave behind links (symbolic or hard).

Since everyone ends up having /bin and /usr/bin in PATH, this merge makes a lot of sense from a performance point of view.

Merging bindirs and sbindirs is a touchier topic. Many things in sbindirs should have been in bindirs all along, and many should move to libexecdirs, but some should stay behind so that privileged users can keep sbindirs out of PATH when they're not wearing an admin hat.

bjourne• 4 years ago

Roughly the same reason why dotfiles became a thing on Unix: https://linux-audit.com/linux-history-how-dot-files-became-h... Fortunately more and more software is putting its config in ~/.config/ rather than dumping it all over users' home directories.

sph7• 4 years ago

AFAIK the XDG spec isn't a thing on macOS, so you get those CLI utilities written by devs on their fancy Macbook Pro that pollute your home directory, such as Deno, Doom Emacs, Elixir, Rust/Cargo, Kubernetes, npm, vscode, etc.

oneeyedpigeon• 4 years ago

It's inconsistent, but certainly some programs adhere to XDG on macos. I've got pretty healthy looking ~/.config and ~/.local directories, and it's not all just my own stuff.

indymike2• 4 years ago

On macos its less of a problem because the OS tries to hide your home folder and shows Documents Desktop and downloads in the Finder. Still much prefer .local and .config to a pile of dotfiles.

chmaynard• 4 years ago

I notice that your comments often include trigger words/phrases like "devs on their fancy Macbook Pro". Then I realized that I do the same thing. You spot it, you got it. Maybe I'll start a 12-step group for snark addicts.

faho6• 4 years ago

There is no specific reason for a program that uses the XDG dirs on other unices to not use them on macOS, other than some idea that it's "alien".

You can have ~/.config/. Nothing in macOS prevents you from having it. And so, some programs do. The worst thing that happens is that, instead of having one directoy ~/.foo you now have one directory ~/.config/foo and nothing else in ~/.config. But as soon as you add the second thing that uses ~/.config, you now have two directories in there instead of a second dotdirectory in ~.

It's just that for a bunch of them the XDG path is only used if it exists - e.g. emacs predates the spec, so it uses ~/.emacs.d (and a few others) first.

Cargo doesn't use the XDG paths at all, apparently - https://github.com/rust-lang/cargo/issues/1734. However it also needs a directory for binaries (~/.cargo/bin) and ~/.local/bin isn't actually in the spec at the moment (https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/14).

jeroenhd5• 4 years ago

I can understand devs not using the right circumstances if their platform of choice doesn't come with an easy way to determine the right directory to put stuff in, let alone create it if necessary.

What I really want is an API that does "create/open/delete a file/directory for the relevant configuration/cache/resources store", be it user configured or platform default. What I get is an external package that gives me a list of potential storage locations (of which I'll probably just pick the first) that may or may not be actual directories on the system which I may or may not have access to touch files in.

Some devs are kindly reminded that there's a spec for these things but often it's too late as data is already in specific paths that users may have come to know. That way you end up with paths that get set by environment variables where you have to tell each and every program where to put their crap.

Other programs don't care enough to implement the standards (like Firefox; the bug report about XDG is old enough to vote [1] and it's still not implemented fully). Kubernetes has an open issue for its client that only ever gets bumped.

Even worse are devs that are reminded of standards like XDG and then decide to give everyone the middle finger. Snap is one of them, not only is the data directory hard-coded, it's hard-coded lowercase unlike every other standard directory on Canonical's distribution itself! Snap's biggest competitor, Flatpak, decided not following the standard is not a problem [3]. At least it's special snowflake folder starts with a period so that it's hidden by default, I suppose. Even Bash doesn't support XDG [4] because not everyone uses Linux (and apparently no effort should be made to support OS specific standards?) with the suggestion closed as won't fix.

Many tools that do support XDG only care about their own standards, of course; Windows has had SHGetKnowlFolderPath since Vista, replacing SHGetFolderLocation which dates back to Windows 2000. Still, developers like to push POSIX standards into Windows, creating .dotfiles and not even bothering to at least mark them as hidden.

There's a big list on the Arch wiki[7] listing programs and their compatibilities with XDG.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

[2] https://github.com/kubernetes/kubernetes/issues/56402

[3] https://github.com/flatpak/flatpak/issues/1651

[4] https://savannah.gnu.org/support/?108134

[5] https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...

[6] https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...

[7] https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode...

mmphosis• 4 years ago

https://developer.apple.com/library/archive/documentation/Fi...

soraminazuki• 4 years ago

I haven't seen any software that conditionally disables XDG on macOS. What I do see common is software that hardcode paths. Many of these software use different paths depending on the platform. But those aren't XDG compliant because XDG paths are configurable through environment variables.

Also FYI Doom Emacs is currently XDG compliant.

Taniwha• 4 years ago

I'd forgotten that RK05s only had 1.5Mb which made me think about my disk quota as a student around the same time on a mainframe - 500 180byte blocks - ~90k - but I could back my programs up and take them home - on cards

captainmuon2• 4 years ago

I've read this explanation a couple of times, and if you go all the way back to PDP-11 the split does indeed sound ridiculous. I had my first contact with Linux from some magazine CDs in the late 90s, I think it was Red Hat or SUSE based. The documentation there had a much clearer explaination:

/sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash.

The paths without /usr - /bin and /sbin - are available from the get go. It is the very first partition that is mounted, and what is guaranteed to be available if you do "init 1" or boot in single user mode. You can also do fsck from there (assuming the boot partition is not damaged). I don't know how this integrated with initrd (initramfs wasn't a thing yet). I think there was only one "base system" - either initrd was very basic, or the whole base was in initrd, or something similar.

The paths with /usr were managed by the package manager. Word of mouth was: don't install anything manually there. If you do (via make install), keep around the source so you can do make uninstall. But better install to /usr/local or /opt.

Athas3• 4 years ago

/sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash.

I also got this explanation, but it never made much sense to me. First of all, the binaries there are executable by everyone anyway. Second, it really doesn't matter that they show up during completion. Third, many of them work fine and are quite useful without root! I don't recall the specific examples that bothered me (/sbin and /usr/sbin have been in my PATH forever now), but I think it was something like ifconfig or ping.

digitalsankhara3• 4 years ago

Yes, but you are effectively turning your box into a single user system. And that's fine if you are happy to work that way, but the origins of the directory structure is of course in multiuser UNIX. As a sysadmin, I would not want my /bin /sbin exposed to everyone. In your example I question the security implications of being able to run those binaries outside of root anyway (esp. in a professional environment) if you have your box exposed on a network.

faho6• 4 years ago

Third, many of them work fine and are quite useful without root

It's more complicated than that - many can do a subset of useful things without root.

Often they can read things as a normal user - things like `apt` or `sysctl` can show you information about your current system, but will only be able to change it as root.

And even something like "shutdown" might be usable for a locally logged in normal user on a systemd system - or it might not be, depending on local configuration.

Finding things that actually always "need root" for everything is kind of hard, even discounting "print help" as a useful thing in its own right. And if you only came up with "chcpu" and "switch_root"... would you really want to have a top-level directory just for those? Plus the historical location for some things is in /sbin, so moving them out has a compatibility cost.

Tbh I find the only winning move here is not to play. There are so few binaries that are actually only useful to root that they don't really hurt in tab completion, and they could always grow non-root accessible features.

froh• 4 years ago

Yes. And another benefit of /usr vs / was that is was simpler to read only mount /usr than r/o mount /.

Why do you want to do that? Well, when you have a machine with virtualization you can share the /usr partition across all instances, physically. Which makes a lot of sense if you want to virtualize hundreds of Linux guests on one physical box: you memory map the /usr partition in hypervisor ram, you share that ram across all guests and wham you have snappy fast virtual machines with low physical footprint.

That was actually done, e.g. on IBM mainframes running "your personal web server" for thousands of users in one single mainframe. Fun times.

And only when the root partition could also be mounted r/o, with just an individual /etc, and when large partitions became doable as /, only then it started to make sense to abandon /usr

The split made lots of sense back in the days.

cesarb4• 4 years ago

Why do you want to do that? Well, when you have a machine with virtualization you can share the /usr partition across all instances, physically.

Or you could share the whole /usr over NFS to hundreds of diskless workstations, each having their own separate / (also shared over NFS). Remember that disk space was expensive back then; having hundreds of identical copies of the large /usr tree on the NFS server would be a huge waste.

doctor_eval• 4 years ago

This is exactly what I understood, too. The structure in Linux was familiar to me from SVR4 which I used in a number of implementations, most often Data General’s DG/UX (which was a fantastic system for its time).

It’s probably true that the distinction isn’t really important any more. The things we used to have to worry about in the (g)olden days of Unix (/s) are ridiculous by todays standards. We had one of the first 2.5GB RAID arrays in the country and could run a whole medical laboratory - maybe 100 people running Wyse 60 terminals - on it. We had a dedicated 500MB drive for the OS and a couple of other drives just for database logfiles.

These days the whole OS now fits on a single SSD which takes up a tiny fraction of the device. Large SSDs have made so much complexity obsolete for most people. I believe that one could, quite literally, run that old lab software from a single Raspberry Pi.

The point being, stuff that made sense in that old environment does not necessarily make sense any more. It’s good to have the discussion though.

pmoriarty6• 4 years ago

"/sbin, /usr/sbin is for binaries that need root"

No, they're for statically linked executables.

sph7• 4 years ago

The s stands for superuser, not static.

cesarb4• 4 years ago

I don't know how this integrated with initrd (initramfs wasn't a thing yet).

As far as I recall, early Linux didn't have initrd either; it's a novelty which came later.

But better install to /usr/local or /opt.

I believe /opt is a novelty which appeared on either FSSTD or its successor FHS; I think /usr/local is older (perhaps even older than Linux), being the default --prefix for autoconf.

jjice• 4 years ago

I had my first contact with Linux from some magazine CDs in the late 90s, I think it was Red Hat or SUSE based.

Man that sounds awesome. I know we have it made these days with modern internet and computers, but sometimes I day dream about being 19 in the mid to late 90s and getting to experience that age of computing.

vfinn• 4 years ago

Bad/illogical/outdated directory structure is one of the most annoying things I've encountered while using Linux, because it makes the admin job feel unnecessarily messy (things are all over the place), and it feels as if there's a fundamental imbalance in the system that you can't get rid of.

encryptluks2• 4 years ago

There is really not that many places to look. I agree it could be better but part of the time the issue is with package maintainers. And to some extent, systemd has made things a little more convoluted. Compared to Windows it is far better because at least you don't go having to search thousands of registry keys.

venil• 4 years ago

At least for the PATH, you can also automate the looking. When on a new POSIXy system, I usually try "(IFS=: ; ls $PATH)" at the shell to get a listing of all programs available.

indymike2• 4 years ago

Bad/illogical/outdated directory structure is one of the most annoying things I've encountered while using Linux

Every OS I've ever used has had these kinds of quirks, save simple ones that just dump everything in the root folder or equivalent. Its really hard to move files once you ship software and doubly so do an OS. Users expect files to be where they were last version.

li2uR3ce• 4 years ago

it makes the admin job feel unnecessarily messy

Many admins feel like a Jedi when they memorize all the trivia about a file's path.

There's no shortage of people in a particular profession that feed on unnecessary complexity even when the original reason for said complexity (i.e. tiny drives) doesn't exist any more.

Now if you'll excuse me I have to figure out why sound doesn't work on Linux in 2022 like it's 1997. No seriously, I legit have to do that now. Someone should really develop another system for sound, again.

b65e8bee43c2ed02• 4 years ago

"I use arch btw"

survirtual• 4 years ago

I just got done building an omni-channeling recording system, with a soc running ubuntu-server & alsa handling recording from several usb dacs connected to microphones. I feel your pain. Sound on linux is a nightmare. But now that I have an understanding of it, here are some helpful things I learned.

- Make sure alsa-utils is installed

- Auto-configure hardware devices: alsactl init

- View hardware for playback (use arecord for opposite): aplay -L | grep “^hw:”

^ Use that to make sure your hw is being detected

- Lower level list of sound cards, if having issues: cat /proc/asound/cards

- Base alsa conf: /usr/share/alsa/alsa.conf

^ go there to dive deeper into what alsa is actually doing. It will also show you the priority for config files, so you can go through that and check which ones are in use and modify accordingly. alsactl init should handle most configuration though.

- you will want to mess with this: /etc/modprobe.d/alsa-base.conf …and get it working for your hardware. This is a resource to understand that file better: https://alsa.opensrc.org/MultipleCards

You can google configuration files and find one that works for you. Most issues for normal use will revolve around which card gets set to index 0 / default, so if you know your card you want as default, I’d recommend finding your device id (i think cat /proc/asound/cards will give you vendor/product ids you can use) then making a config using that id to set it as the default card, independent of indexing.

Turned into a lot, stopping here. Sound really shouldn’t be this hard for end users or devs, but it is what it is right now. Anyway, it’s fresh on my mind so at the very least, I might be able to point you in the right direction.

Good luck!

- Someone with no more hair left to pull out

usrbinbash4• 4 years ago

This is by far the best explanation for the mess that is historical file hierarchies I have ever read.

phendrenad2• 4 years ago

On my personal Linux desktop PC I have dumped all binaries into /bin. And /sbin, /usr/bin, and /usr/sbin are symlinks to /bin.

baby3• 4 years ago

Tangent, but that's what made getting into Linux/Unix really hard. You have all these folders and files and no README.md to explain what is what. And there seemed to be no logic at all with how things were organized or named (and names often were shortened to abbreviations that I couldn't comprehend). I'm wondering what a modern system made to be readable and understandable would look like.

The other thing, coming from windows, was not understanding where to install things. In windows there's like a single place where you install all your stuff.

trasz3• 4 years ago

Take a look at "man hier": https://www.freebsd.org/cgi/man.cgi?hier

moffkalast2• 4 years ago

"Link a man to man and you solve his problem for a day, teach a man to man and you've enlightened him for life."

Side note, calling the file system layout "hier" has got to be the stupidest naming choice. Did they want this to be lost forever so that nobody ever finds it?

pmoriarty6• 4 years ago

"that's what made getting into Linux/Unix really hard. You have all these folders and files and no README.md to explain what is what"

In the old days, I read books for that.

cesarb4• 4 years ago

You have all these folders and files and no README.md to explain what is what.

Markdown is a novelty. Back then, it would be just README (with no file extension at all).

In windows there's like a single place where you install all your stuff.

Windows was even worse. Whenever you installed something, parts of it were in a new directory at the root of C:\, and parts of it were dumped in C:\WINDOWS\SYSTEM together with all the rest that's already there, often overwriting files of the same name (and the names were limited to 8 characters plus the extension, so they were quite opaque) used by other software you had installed earlier (that's the original scenario of what is now called "DLL hell"). On later Windows versions, instead of a new directory at the root of C:\ it was a new directory within "C:\Programs Files" (or is it "C:\PROGRA~1"? Or perhaps "C:\Arquivos de programas" aka "C:\ARQUIV~1"? Or something else?), and instead of C:\WINDOWS\SYSTEM it was now C:\Windows\system32, and there's also the "Common files" directory somewhere. And since there's no package manager (actually there is one, but not everything uses it, and it's very complex), you don't know which file came from which software. Oh, and if the program you installed overwrote a "protected" system file, the operating system overwrites the file again with its own copy.

baby3• 4 years ago

As a user everything was in program files/

erik_seaberg• 4 years ago

There is a package manager, what’s missing is a directory tree owned by the package manager and protected from smuggling in unexpected crud without a big red warning for administrators.

1970-01-01• 4 years ago

In windows there's like a single place where you install all your stuff.

Open a cmd box and type

     PATH

How many folders do you see? They all count as places.

But I completely agree with everything you said about Linux!

skocznymroczny2• 4 years ago

Well, you can look at MacOS for a basic inspiration. Hide all the ugly Unix parts and expose sensible directories like Applications, Preferences, Volumes, Users.

behnamoh2• 4 years ago

This. Although I wish Apple would follow MS's suite and remove "spaces" in directories. Right now we have something like

    /Users/behnam/Library/Application Support

which is _nasty_ when working in a terminal.

MS tried to fix this by making directories like:

    C:/Users/AppData/Local/

upofadown2• 4 years ago

Standards bureaucracies like the Linux Foundation ... happily document and add to this sort of complexity without ever trying to understand why it was there in the first place.

That is because that is a standards organization's job. They exist to document what is actually being done, not editorialize about what should be done.

This seems to be a good example of the virtue of this sort of behaviour. The mostly arbitrary changes that have been done here have in themselves caused more problems and wasted effort than just keeping everything the same as it was.

TheCycoONE• 4 years ago

https://fedoraproject.org/wiki/Features/UsrMove (2012) and the linked systems article https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... include some motivation for changing the status quo, and moving all the duplicate root paths into /usr.

codedokode2• 4 years ago

The fact that there are several directories with binaries is not a problem by itself. The problem is that many applications use hardcoded paths instead of searching for these binaries using PATH.

It means that if someone decides to get away from this legacy structure and move OS into something like /system/debian-11.1.2/ all those programs would break.

Examples: [1], [2]. I assume that developers have hardcoded those paths because /sbin is often not included into PATH.

[1] https://github.com/blueman-project/blueman/blob/fcef83a01c80...

[2] https://github.com/blueman-project/blueman/blob/fcef83a01c80...

kuharich• 4 years ago

Past comments: https://news.ycombinator.com/item?id=3519952, https://news.ycombinator.com/item?id=11647304, https://news.ycombinator.com/item?id=22614731

gjadi2• 4 years ago

GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.

That's one way to make new friends :)

szastamasta• 4 years ago

I must say I really like the MacOS idea, that every app has it’s own folder. I think that apps scattered through filesystem are not a good idea at all. Maybe they should symlink executables to /bin and shared libraries to /lib. Also everything that is needed to boot should probably be in a sealed readonly filesystem or binary anyway. I think we have made a mess with unix filesystem stricture and it really needs to be simplified.

cassepipe2• 4 years ago

You should really check out GoboLinux then : https://gobolinux.org/

jmbwell• 4 years ago

macOS also does a more strict but tidier hierarchy, grouped into "domains" … /System/* is "stuff from Apple" (including /System/Library, etc.), / is for "stuff on the local machine" (/Applications, /Library, etc.), and then each user can have their own hierarchy in their user directory (~/Applications, ~/Library, etc.).

Of course, the "stuff from BSD" winds up in /bin and /usr/bin anyway, so it's still a mess.

https://developer.apple.com/library/archive/documentation/Fi...

cassepipe2• 4 years ago

Anyone ever tried to run GoboLinux as a sysadmin ? What was the experience like ?

betagammaxyz• 4 years ago

Path dependence -- just like the default 80x24 character terminal window size that goes back to the VT100 of 1978. A curious historical hangover. GUI defaults are obviously less consequential, though.

ibejoeb• 4 years ago

...cache invalidation, naming things, filesystem hierarchy

Taxonomy, in general, consumes and perplexes us. It only seems to get worse as time goes on. Look at your typical react app...

basemi• 4 years ago

I think modern distros have resolved the issue . For example this is void-linux:

  $ ls -ld /bin /sbin /usr/bin /usr/sbin
  lrwxrwxrwx 1 root root     7 May  3 00:20 /bin -> usr/bin
  lrwxrwxrwx 1 root root     7 May  3 00:20 /sbin -> usr/bin
  drwxr-xr-x 1 root root 39444 May 10 18:41 /usr/bin
  lrwxrwxrwx 1 root root     3 May  3 00:20 /usr/sbin -> bin

Ubuntu, Debian and RHEL, on the contrary still splits up:

  $ ls -ld /bin /sbin /usr/bin /usr/sbin
  lrwxrwxrwx 1 root root     7 set 25  2021 /bin -> usr/bin
  lrwxrwxrwx 1 root root     8 set 25  2021 /sbin -> usr/sbin
  drwxr-xr-x 2 root root 69632 mag 11 14:00 /usr/bin
  drwxr-xr-x 2 root root 20480 mag 11 13:33 /usr/sbin

b65e8bee43c2ed02• 4 years ago

- `/home/username/bin` and for binaries installed under that specific user

- `/bin` for everything except the above, including binaries installed under root

- same pattern for configs, auxiliary and transient stuff

change my mind

deergomoo• 4 years ago

Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt! I'm still waiting for /opt/local to show up...

Heh, MacPorts installs stuff to /opt/local on the Mac.

mc4ndr3• 4 years ago

TL;DR. Storage used to be so expensive per gigabyte that binaries were arbitrarily categorized into distinct file system partitions. Nobody ever bothered to revisit this and merge back to just /bin.

Also, why the heck was $HOME/bin never a thing?

michaelcampbell• 4 years ago

One of my first exposures to *nix in the corporate world was on a Sun Sparc, running at the time SunOS 4.something.

The sysadmin at the time told me the /sbin versions of things where for statically linked binaries that didn't need any other FS' mounted to read any dynamic libs.

I'm not asserting it was right, but just another view into "tribal knowledge" vs "urban legend" vs ???

jlundberg• 4 years ago

For those who liked this text and want to read more from the author, have a look at his busybox replacement toybox:

http://landley.net/toybox/

Understanding the bin, sbin, usr/bin, usr/sbin split (2010)

Related Stories