> /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.

>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.

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.

> As a sysadmin, I would not want my /bin /sbin exposed to everyone.

Why not? It's not like most of them are suid (right?). Most Unix systems I've used allow any user to peruse /sbin at their leisure and run whatever they want.

Apologies if I'm missing your point, but yikes - any user on your system can run /sbin/shutdown?

Yes of course, just like on more or less any Linux system. But IIRC, shutdown is a suid binary that will do its own permission checks while running. The permissions on the /sbin/ directory should not matter.

Do you realize /bin is a symlink to /usr/bin these days?

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.

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.

> 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.

> 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.

> 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.

The s stands for superuser, not static.