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

Nitpicking:

If you look at the very early versions of the Unix manuals, before even /lib was invented, there was a notion that /bin was the "system" (section 1) and /usr/bin was "user software" (section 6). This fell by the wayside when they ran out of disk space on / and started putting section 1 commands in /usr/bin. At some point the system/user distinction was abandoned and everything but the games got moved to section 1 of the manual.

(Back in those early days /lib files used to be in /etc. So did /sbin. There's still a meaningful semantic difference between programs any user could run vs programs only useful to root.)

On *BSD there is no initramfs equivalent and the / partition still serves its traditional role of the minimal startup environment. And /home never existed before Linux - it was always something like /usr/home as far as I can tell.

The problem with Gobo is that this progression never works:

New FS Layout -> User Adoption -> Profit

Because at the end of the day the layout of the filesystem is never the selling point on any given distro. It always comes down to the software - either the amount of it, or the newness of it, and that is why people flock to Ubuntu and Arch respectively.

It is much more prudent to argue for filesystem improvements in those distros, and get them implemented there, than to fork it out. Gobo demonstrated both the validity and the utility of the approach, but it is up to distro makers to actually use the evidence given that the traditional Unix layout is garbage.

It's not FUD, and GPLv3 is not clearly a superior license. It may surprise you to learn that different people value different things and have different opinions, and so want different licenses. GPLv3 is really a pretty extreme license that imposes a lot of restrictions that a lot of people simply don't want. If GPLv3 does what you want, by all means use it, but don't denigrate the choices other people make.

> Establish a new, consistent filesystem hierarchy.

systemd is kind of enforcing this already, preferring /usr (where most of the packages go) over naked paths. This is the trend on relatively modern desktop systems, which thankfully preserves standard fs hierarchy while mostly keeping everything in one place. (Unfortunately there are bunches of non-desktop uses for Linux out there.)

See also https://freedesktop.org/wiki/Software/systemd/separate-usr-i....

> It would maybe be even easier if we could redirect writes (I'm not too versed in filesystem capabilities) from the legacy paths to the new ones.

Quite a few distros (and users like Rob Landley) use symlinks from /bin to /usr/bin and the same goes for /lib. sbin is sometimes linked to bin. This does some of the redirection.

(I am not aware of the /usr/tmp and /var/etc stuff mentioned in the message.)

> After even longer, delete the legacy paths.

Nah. Millions of scripts are writing she-bangs like #!/bin/sh and I don't really expect to see this being changed...

Workarounds using `env` is kind of crippled since a.) it introduces an extra level of dependency and indirection and b.) it stops the user from reliability passing options to the interpreter (Linux only cut at the first space, with all sorts of other *nixen doing different things with multiple spaces.)

"Note that Arch follows the systemd FHS convention of symlinking"

The Systemd convention? What the fuck? Does Systemd have to touch everything??