I think "/usr/bin" is simple and efficient, and Fedora/CentOS have converged on that a couple of years ago (/bin is a symlink to /usr/bin on those distros). /sbin is the same (linked to /usr/sbin).
I find macOS paths atrocious (too long, too inconsistent, and derived completely outside of UNIX traditions and norms) and I certainly wouldn't want them on my Linux system.
I'm not the one suggesting a new-fangled scheme for the filesystem hierarchy. I think whoever is suggesting something hugely disruptive would need to be the ones to defend it. I'm saying, "Hey, we got this thing that's worked for a few decades. Changing it is fine, if there's a real problem with it, and solving it can't be done without disruption."
The person I responded to said the current Linux pattern of "/bin", and "/usr/bin", and "/usr/local/bin", etc. is inefficient (whatever that means). I said I disagreed (as much as one can without really understanding what is efficient about the new scheme or inefficient about the old) and pointed to a change that Fedora has made in recent years that simplifies it somewhat and recognizes that systems have changed (and the way we boot them has changed).
I'm not saying it is more efficient, I'm saying it's not less efficient (again, whatever that means in this context, you'd have to ask the person above me that I was responding to). But, I do find "one application per directory" very messy. My package manager knows where everything is so I don't have to.
This may not be awful. I'm not saying it is bad. I'm saying, "if we're going to change everything about the way we install, manage, update, and use software on Linux", there'd better be a damned good reason for it. It must be a clear improvement. This does not strike me as a clear improvement. It's clever for the sake of clever, without any significant value.
So, tell me why I'd want this. (And, "it's like macOS" sure as heck aint sellin' it.)
Have you ever had to work with a piece of software, where, since you were not using Gentoo or something, your package manager had a very old package and had to install a new version from source?
I remember around 1999 some sysadmins would say, create your own packages from source stuff that you need. Given the current filesystem, permissions, etc. creating your own stuff is not for the faint of heart. So what you did was search the web in hopes somebody had done it for you.
Fast forward to recent times, if you had to do devops where PHP was involved in some way, you would have felt remi was a guy that should be receiving free beer. Explain why we have arrived to that sort of situations.
Luckily nowadays, the world seems to have centered around Ubuntu, from Docker to whatnot, which makes everybody target Ubuntu at least. But to this day, I'm still a very fond user of Gentoo, even if the compile everything from source approach is a bit crazy, and its latest reincarnation, Funtoo, precisely because it gives me a machine that has everything I need when the time comes to deal with "the package not in my package manager" TM.
Sure, I remember 1999 (and I've built my own packages thousands of times since then, and still do a couple times a week, though mostly for my own software for distribution).
I understand the pain that older packages sometimes cause, but I think the notion that we should throw away good package management in exchange for...I'm not sure what exactly you're suggesting this new scheme provides, is a good trade. Gentoo is not a realistic option for most situations where you need stability over some length of time.
I looked over GoboLinux, and I see they offer multiple versions of packages, and that's cool and all. There are repos that do the same for CentOS/RHEL; Software Collections Library is a very good one that is sponsored by Red Hat. And, there's stuff like Flatpak coming down the pike which allows packages to be bundled up in a container with everything it needs.
One could argue that GoboLinux foresaw these needs (it's been around since 2002, apparently) and came up with a partial solution to the problem. I can't argue with that. But, it was, IMHO, so partial that it wasn't worth the trade. I'm not sure containers-as-packages are worth the trade in some cases, either, but it seems inevitable. So, I'm embracing it in my own work. It's definitely got some advantages.
Yeah, uhm, no. /bin and /sbin contain tools fundamental for booting the OS. /usr
can be mounted from NFS resource, and as such, can be missing at boot time.
/usr/local is for things installed locally by sysadmin.
This split comes from the times when it was not uncommon for workstations to
share installed programs using network filesystems.
This way certain directories could be mounted read only (i.e. reside on a read-only partition/disk). Some directories were supposed to be governed by the core distribution, some were for user-installed software etc. It makes sense given the original intentions & restrictions. It may look weird on a one-person working station.
That's not the whole thing about LFS. The split by kind rather than application is also a "feature" (or a bug, depending on your opinion). I used to like the fact that documentation was in one place, binaries in another, configuration etc etc
You do know it’s a hack because the original Unix computer was running out of space and they hadn’t invented Union mounts yet... right?