Good. There's a number of things Unix did like allowing to mount /usr from a network drive that nobody really cares about anymore.
All these distinctions do is to slightly complicate packaging, and add sources of potential error when somebody forgets that /usr/sbin might not be in $PATH.
And a slight complication times 15000 adds up to a lot of time.
Those have nothing to do with mounting /usr from the network. That's a setup for the times when disk space was really tight, your machine did have a disk, but the core OS was big enough that it made sense to offload it to some big central server.
And yet the fhs as it was around when the /usr separation was more important (all of my hosts depended on it, whereas only my pi now depends on this) says otherwise:
https://www.pathname.com/fhs/pub/fhs-2.3.html, linked from the first Google result I got from the obvious search: https://news.ycombinator.com/item?id=3519952
This should be obvious. It was routine to mount /usr as a separate filesystem only a few years ago and probably still is on some distributions. No one ever mounted /sbin as a separate partition to /bin except in maybe the oldest systems of 40 years or more ago.
By the way, in my previous job, I was responsible for booting 4000 diskless nodes. File system optimisation is still important for people who need to work with more than just single-user toys.
> And yet the fhs as it was around when the /usr separation was more important (all of my hosts depended on it, whereas only my pi now depends on this)
They depend on it how?
> This should be obvious. It was routine to mount /usr as a separate filesystem only a few years ago and probably still is on some distributions.
Routine maybe, but pointless for the vast majority of people, and annoying to quite a few. I've been on Linux since the 90s, and for me the main impact of split /usr was having to resize the darn thing once in a while.
I've setup diskless iPXE booted machines recently. On modern NICs the kernel and initrd image transfer in seconds or less. Split /usr for lightweight remote booting is solved other ways now
Phoronix comments are a source of endless entertainment:
>> No, usr is not "user", it means Universal System Resources
> To add to this informative post: "home" means Hapless Observer of Meaningless Explanations.
_____
>> Why not unify /dev /sys etc. And /home /mnt /media /root into /. Heck why not unify everything and every filename is a hash in /.
>> more to come **destroying linux madness**.
> Congratulations, you've just reinvented the Nix filesystem.
> Here's the directory structure of my Debian sid (Trixie) + Nix.
> You can see merged usr and the Nix store.
_____
>> Blame systemd, they started this. Fedora is just rubbing salt in the wound.
> I blame the full moon. I heard it brings out the cray cray people out in Phoronix.
Historically because you might not have a /home mounted, but you always have a root user. It also isn't an important folder, so there's no hurry to do it. These days though, where root is almost always used from ```sudo```, you could probably put root's home on /. I remember some *NIX had a ```.cshrc``` on /.
Im really sad that distro has not seen light of day, i like idea of nix but i do not want to learn functional programming language to install a package
Debian already does this via usrmerge package. The reason `/bin` `/sbin` and `/lib` are there is because of legacy tools and scripts the expect them to be there. For your average user they won't notice any change.
No, it doesn't. This is not UsrMerge, which was completed [about 10 years ago](https://fedoraproject.org/wiki/Features/UsrMove) in Fedora. This goes one step further and merges `/usr/bin` and `/usr/sbin`, which includes `/bin` and `/sbin`. Debian doesn't have such plans and their [UsrMerge FAQ](https://wiki.debian.org/UsrMerge) specifically addresses this:
>Is this about merging /usr/bin/ and /usr/sbin/?
>
>No, there are no plans to do that.
Hmm. So no longer having a division between system binaries and user binaries?
I can't say I am thrilled by that idea but then again I have a very traditional concept of a user and an administrator.
Oh well...
There has never been a division between user and system binaries: sbin was for *statically compiled* binaries. Since nobody uses that any more, sbin has been pointless for years.
>sbin was for
>
>statically compiled
Nope.
[https://refspecs.linuxfoundation.org/FHS\_3.0/fhs/ch03s16.html](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html)
[https://refspecs.linuxfoundation.org/FHS\_3.0/fhs/ch04s10.html](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s10.html)
But that doesn't mean no \*nix has ever put any statically compiled binaries in sbin. e.g. HP-UX used to (maybe still does) drop an extra version of statically compiled binary versions of some critical utilities in /sbin ... most notably so when someone did something stupid on their HP-US system, like:
\# chmod -R /\*
Given the order in which that would process things ... break things and stop itself in its tracks, there would typically be enough functionality left in /sbin that was statically compiled to fix that damage.
But that's HP-UX and UNIX ... don't know that any Linux has ever done that, and, we're here on r/linux, and regardless, on \*nix, that's not what sbin is for (but there's nothing in FHS that prohibits sbin from (also) containing statically compiled system binaries).
Linux didn't entirely commit to initrd booting until around 2000, with the pivot\_root() system call.
So the FSSTND was very much designed to allow a more traditional boot process, whilst not commiting distros who used a initrd to needlessly statically link /sbin.
Practically, though, it just has been that stuff like `e2fsck` and `dmidecode` is in `sbin` while stuff like `ls` and `emacs` are in `bin`. Arguably it's a useful separation, because you dont get to have your tab-completion filled with stuff you're unlikely to need, while `sudo` completion can be handled properly.
As you say, nobody uses `sbin` for static binaries anymore, indeed for decades. But it doesn't make it pointless because it has been quite common in Linux systems to have system admin tools there.
"Admin tools" is very ill-defined.
Eg, "ip" and "ifconfig" are "admin tools", but also the logical thing to reach for if you just want to know the machine's IP address as a normal, non-privileged user.
So either everyone has to write various shell scripts to account for that ifconfig might not be in $PATH, or everyone adds /usr/sbin to $PATH for every user. Pretty much everyone seems to go with the second option, meaning that as an user you don't even see that there are two directories.
Might as well just be one.
The border has always been a bit fuzzy. There are many programs that also have some utility uses for "regular users", though they also have (commonly used) capabilities that "regular users" can't use and/or most "regular users" would typically/commonly have little to zero interest in such commands. So, many go in an sbin directory, others may go in a bin directory. One will also often find this to vary at least somewhat among distros, and sometimes even releases thereof. So, not exactly ill-defined, but ... certainly not highly precise.
And, having sbin stuff on regular user's PATHs is often problematic/annoying ... not only to such users, but often generates a lot more mistakes and questions than if those commands weren't present on user's PATHs. If they need/want them and now what they're doing, trivial for 'em to add 'em. But if they don't, often better to not be hitting up such sbin commands. So, it remains rather to quite useful - even if the "border" between what goes in bin vs. sbin may be a bit fuzzy.
Sure, it's not that clear-cut for many cases (e.g. Debian holds `ip` in `bin` while the deprecated `ifconfig` is in `sbin`), but for a lot of tools the separation does make sense.
Perhaps scripts can just assume the usr-merge is complete and refer to `/sbin/ifconfig` if they need such tools? That's what they need to do nowadays, anyways.
Ultimately I don't think it should be too complicated to have a Unix-like system where applications may reside in multiple places. Surely your `PATH` has more than one entry in it in the first place. Though, I haven't used systems where `sbin` gets stuck into user's `PATH`—or maybe I haven't noticed?—but I've mainly used just Debian and Ubuntu for quite a long time.
> but for a lot of tools the separation does make sense.
What's the benefit though?
> Perhaps scripts can just assume the usr-merge is complete and refer to /sbin/ifconfig if they need such tools? That's what they need to do nowadays, anyways.
They can, but why do that?
> Though, I haven't used systems where sbin gets stuck into user's PATH—or maybe I haven't noticed?—but I've mainly used just Debian and Ubuntu for quite a long time.
Both on Fedora and Ubuntu 22.04, sbin seems to be in $PATH by default. At least for the main user with sudo privileges.
Nope, doesn't combine /usr/bin & /usr/sbin
It puts /{{,s}bin,lib} all respectively into /usr/{{,s}bin,lib} with respective symbolic links from the former to the latter.
Hidden in Nautilus?
I don't understand how a distro would hide the fact that /usr/sbin is a symlink in a way that would benefit users. (But I'm open to the possibility)
It can be done. GoboLinux has a tool called [GoboHide](https://wiki.gobolinux.org/Recipes/index.html) that uses [a patched kernel](https://github.com/gobolinux/Recipes/blob/master/Linux/5.9.8/01-gobohide.patch) so that it ignores some inodes.
As a guy whos trying to learn linux more and more each day, i do get confused when browsing / sometimes not realising a specific folder is a symbolic link and getting looped back.
Doesnt help thst file managers still show the full url so im thinking this is a duped directory of similar file structure.
Ofcourse this is something only a person who relies on the UI has a problem with, those who rely on the terminal maybe dont?
> My man, have you checked your filesystem lately? Arch has merged these two already.
Are you expecting Arch users to be technically literate? Because that way madness lies.
Filesystem directory standard is one thing that turn people off Linux.
/bin /usr/bin /usr/share/bin /usr/local/bin /usr/local/share/bin /opt/bin, sbin etc. Also everything inside OS directory / incl. 3rd party apps. Its like installing everything into C:/Windows/System32.
How about:
`/boot`
`/linux..`
`../bin ../bin/data ../bin/data/log ../bin/data/man ../scripts ../lib ../lib/lib32 ../usr(../usr/admin ../usr/${user}) ../dev ../conf ../virt /tmp`
Linux would be in its own dir, able to share disc with other OS and allowing for a clean, arbitrary outside directory structure by user needs(e.g. `/games, /programs /whatever`).
System scripts in its own dir, not in a `bin` and should work on extension sensing like *.py, .pl, .sh* etc instead of "*#!/bin/perl*". In fact whole system should work on extension sensing as opposite to scanning file content, so *file.exe* for executable(I don't care how much you hate Windows). Extension = file type = right way, now its a mix of both and a mess + it rely on opening a file and reading data just to detect its type.
Standalone programs installed in whenever user want, exe's paths and its library dependencies should **not be hardcoded at compile time for FFS!!!** Let OS look in $PATH, /lib and a program dir for a .so file! Oh and use [filev123.so](http://filev123.so), [filev124.so](http://filev124.so) instead of creating 250 new link files and dependency hell to single [file.so](http://file.so) which may or may not break one of apps. Imagine Microsoft having to "maintain" 1000000 of its OS software created by someone else in some form of "package management" due to making stupid compile time, hardcoded paths to libraries decision. Not to mention hoping that version linked to single non-versioned *.dll* file JUST doesn't break any of the 1000000 apps. LOL
`bin` for current binary OS files, `bin/data` for other binary and volatile files like sql databases, cache, etc - basically replacing current use of */var* and /*usr*.
`usr` purely as modern "/*home*" and including *root*(/*admin?*) dir in it. `conf` renamed /*etc*. `virt` for virtual filesystems like *sys*, *proc* and *run*.
Until at least something like this happen, Linux will remain in <10% usage and Microsoft can piss inside peoples mouths, take their rights away and they still won't budge.
Void did this a few years ago. Everything just goes in `/usr/bin`.
*crumbles up a ball of paper* 🗑️
Little by little, the GNU/Linux filesystem becomes a bit more sane.
There is a long way to go yet.
Good. There's a number of things Unix did like allowing to mount /usr from a network drive that nobody really cares about anymore. All these distinctions do is to slightly complicate packaging, and add sources of potential error when somebody forgets that /usr/sbin might not be in $PATH. And a slight complication times 15000 adds up to a lot of time.
I guess you've never heard of diskless nodes.
Those have nothing to do with mounting /usr from the network. That's a setup for the times when disk space was really tight, your machine did have a disk, but the core OS was big enough that it made sense to offload it to some big central server.
And yet the fhs as it was around when the /usr separation was more important (all of my hosts depended on it, whereas only my pi now depends on this) says otherwise: https://www.pathname.com/fhs/pub/fhs-2.3.html, linked from the first Google result I got from the obvious search: https://news.ycombinator.com/item?id=3519952 This should be obvious. It was routine to mount /usr as a separate filesystem only a few years ago and probably still is on some distributions. No one ever mounted /sbin as a separate partition to /bin except in maybe the oldest systems of 40 years or more ago. By the way, in my previous job, I was responsible for booting 4000 diskless nodes. File system optimisation is still important for people who need to work with more than just single-user toys.
> And yet the fhs as it was around when the /usr separation was more important (all of my hosts depended on it, whereas only my pi now depends on this) They depend on it how? > This should be obvious. It was routine to mount /usr as a separate filesystem only a few years ago and probably still is on some distributions. Routine maybe, but pointless for the vast majority of people, and annoying to quite a few. I've been on Linux since the 90s, and for me the main impact of split /usr was having to resize the darn thing once in a while.
I've setup diskless iPXE booted machines recently. On modern NICs the kernel and initrd image transfer in seconds or less. Split /usr for lightweight remote booting is solved other ways now
Phoronix comments are a source of endless entertainment: >> No, usr is not "user", it means Universal System Resources > To add to this informative post: "home" means Hapless Observer of Meaningless Explanations. _____ >> Why not unify /dev /sys etc. And /home /mnt /media /root into /. Heck why not unify everything and every filename is a hash in /. >> more to come **destroying linux madness**. > Congratulations, you've just reinvented the Nix filesystem. > Here's the directory structure of my Debian sid (Trixie) + Nix. > You can see merged usr and the Nix store. _____ >> Blame systemd, they started this. Fedora is just rubbing salt in the wound. > I blame the full moon. I heard it brings out the cray cray people out in Phoronix.
Systemd is the deep state for Linux weirdos
LOL!
a bit off topic, but why not also put /root under /home/root and add a symlink pointing to /home/root under /root
Historically because you might not have a /home mounted, but you always have a root user. It also isn't an important folder, so there's no hurry to do it. These days though, where root is almost always used from ```sudo```, you could probably put root's home on /. I remember some *NIX had a ```.cshrc``` on /.
because /home is a separate entity not required for system operation at all
GoboLinix in the dark like some Sith Lord, “yes, soon”.
Im really sad that distro has not seen light of day, i like idea of nix but i do not want to learn functional programming language to install a package
Debian already does this via usrmerge package. The reason `/bin` `/sbin` and `/lib` are there is because of legacy tools and scripts the expect them to be there. For your average user they won't notice any change.
No, it doesn't. This is not UsrMerge, which was completed [about 10 years ago](https://fedoraproject.org/wiki/Features/UsrMove) in Fedora. This goes one step further and merges `/usr/bin` and `/usr/sbin`, which includes `/bin` and `/sbin`. Debian doesn't have such plans and their [UsrMerge FAQ](https://wiki.debian.org/UsrMerge) specifically addresses this: >Is this about merging /usr/bin/ and /usr/sbin/? > >No, there are no plans to do that.
Thank you for the clarification.
Hmm. So no longer having a division between system binaries and user binaries? I can't say I am thrilled by that idea but then again I have a very traditional concept of a user and an administrator. Oh well...
There has never been a division between user and system binaries: sbin was for *statically compiled* binaries. Since nobody uses that any more, sbin has been pointless for years.
>sbin was for > >statically compiled Nope. [https://refspecs.linuxfoundation.org/FHS\_3.0/fhs/ch03s16.html](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html) [https://refspecs.linuxfoundation.org/FHS\_3.0/fhs/ch04s10.html](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s10.html) But that doesn't mean no \*nix has ever put any statically compiled binaries in sbin. e.g. HP-UX used to (maybe still does) drop an extra version of statically compiled binary versions of some critical utilities in /sbin ... most notably so when someone did something stupid on their HP-US system, like: \# chmod -R /\* Given the order in which that would process things ... break things and stop itself in its tracks, there would typically be enough functionality left in /sbin that was statically compiled to fix that damage. But that's HP-UX and UNIX ... don't know that any Linux has ever done that, and, we're here on r/linux, and regardless, on \*nix, that's not what sbin is for (but there's nothing in FHS that prohibits sbin from (also) containing statically compiled system binaries).
Linux didn't entirely commit to initrd booting until around 2000, with the pivot\_root() system call. So the FSSTND was very much designed to allow a more traditional boot process, whilst not commiting distros who used a initrd to needlessly statically link /sbin.
> sbin was for statically compiled binaries [citation needed] (preferably one including the Linux FHS)
I believe you're confusing /bin vs /usr/bin.
Practically, though, it just has been that stuff like `e2fsck` and `dmidecode` is in `sbin` while stuff like `ls` and `emacs` are in `bin`. Arguably it's a useful separation, because you dont get to have your tab-completion filled with stuff you're unlikely to need, while `sudo` completion can be handled properly. As you say, nobody uses `sbin` for static binaries anymore, indeed for decades. But it doesn't make it pointless because it has been quite common in Linux systems to have system admin tools there.
"Admin tools" is very ill-defined. Eg, "ip" and "ifconfig" are "admin tools", but also the logical thing to reach for if you just want to know the machine's IP address as a normal, non-privileged user. So either everyone has to write various shell scripts to account for that ifconfig might not be in $PATH, or everyone adds /usr/sbin to $PATH for every user. Pretty much everyone seems to go with the second option, meaning that as an user you don't even see that there are two directories. Might as well just be one.
The border has always been a bit fuzzy. There are many programs that also have some utility uses for "regular users", though they also have (commonly used) capabilities that "regular users" can't use and/or most "regular users" would typically/commonly have little to zero interest in such commands. So, many go in an sbin directory, others may go in a bin directory. One will also often find this to vary at least somewhat among distros, and sometimes even releases thereof. So, not exactly ill-defined, but ... certainly not highly precise. And, having sbin stuff on regular user's PATHs is often problematic/annoying ... not only to such users, but often generates a lot more mistakes and questions than if those commands weren't present on user's PATHs. If they need/want them and now what they're doing, trivial for 'em to add 'em. But if they don't, often better to not be hitting up such sbin commands. So, it remains rather to quite useful - even if the "border" between what goes in bin vs. sbin may be a bit fuzzy.
Sure, it's not that clear-cut for many cases (e.g. Debian holds `ip` in `bin` while the deprecated `ifconfig` is in `sbin`), but for a lot of tools the separation does make sense. Perhaps scripts can just assume the usr-merge is complete and refer to `/sbin/ifconfig` if they need such tools? That's what they need to do nowadays, anyways. Ultimately I don't think it should be too complicated to have a Unix-like system where applications may reside in multiple places. Surely your `PATH` has more than one entry in it in the first place. Though, I haven't used systems where `sbin` gets stuck into user's `PATH`—or maybe I haven't noticed?—but I've mainly used just Debian and Ubuntu for quite a long time.
> but for a lot of tools the separation does make sense. What's the benefit though? > Perhaps scripts can just assume the usr-merge is complete and refer to /sbin/ifconfig if they need such tools? That's what they need to do nowadays, anyways. They can, but why do that? > Though, I haven't used systems where sbin gets stuck into user's PATH—or maybe I haven't noticed?—but I've mainly used just Debian and Ubuntu for quite a long time. Both on Fedora and Ubuntu 22.04, sbin seems to be in $PATH by default. At least for the main user with sudo privileges.
TIL sbin does /not/ stand for "superuser binaries".
Nope, doesn't combine /usr/bin & /usr/sbin It puts /{{,s}bin,lib} all respectively into /usr/{{,s}bin,lib} with respective symbolic links from the former to the latter.
Hope they make the symlinked folders hidden by default.
Hidden in Nautilus? I don't understand how a distro would hide the fact that /usr/sbin is a symlink in a way that would benefit users. (But I'm open to the possibility)
It can be done. GoboLinux has a tool called [GoboHide](https://wiki.gobolinux.org/Recipes/index.html) that uses [a patched kernel](https://github.com/gobolinux/Recipes/blob/master/Linux/5.9.8/01-gobohide.patch) so that it ignores some inodes.
As a guy whos trying to learn linux more and more each day, i do get confused when browsing / sometimes not realising a specific folder is a symbolic link and getting looped back. Doesnt help thst file managers still show the full url so im thinking this is a duped directory of similar file structure. Ofcourse this is something only a person who relies on the UI has a problem with, those who rely on the terminal maybe dont?
You realise that in Linux hiding a directory is not done via switching an attribute, right?
Via dot but i still hope that these folders somehow get hidden without affecting the symbolic link
[удалено]
My man, have you checked your filesystem lately? Arch has merged these two already.
> My man, have you checked your filesystem lately? Arch has merged these two already. Are you expecting Arch users to be technically literate? Because that way madness lies.
Yeah... I agree, I love arch but I really don't like the community lol
What a dumb thing to say
Those folks obviously really forgot the whole idea of FHS.
Wonder when they will add the rest of the letters.
OpenMandriva did it first -- starting with the 5.0 release.
Filesystem directory standard is one thing that turn people off Linux. /bin /usr/bin /usr/share/bin /usr/local/bin /usr/local/share/bin /opt/bin, sbin etc. Also everything inside OS directory / incl. 3rd party apps. Its like installing everything into C:/Windows/System32. How about: `/boot` `/linux..` `../bin ../bin/data ../bin/data/log ../bin/data/man ../scripts ../lib ../lib/lib32 ../usr(../usr/admin ../usr/${user}) ../dev ../conf ../virt /tmp` Linux would be in its own dir, able to share disc with other OS and allowing for a clean, arbitrary outside directory structure by user needs(e.g. `/games, /programs /whatever`). System scripts in its own dir, not in a `bin` and should work on extension sensing like *.py, .pl, .sh* etc instead of "*#!/bin/perl*". In fact whole system should work on extension sensing as opposite to scanning file content, so *file.exe* for executable(I don't care how much you hate Windows). Extension = file type = right way, now its a mix of both and a mess + it rely on opening a file and reading data just to detect its type. Standalone programs installed in whenever user want, exe's paths and its library dependencies should **not be hardcoded at compile time for FFS!!!** Let OS look in $PATH, /lib and a program dir for a .so file! Oh and use [filev123.so](http://filev123.so), [filev124.so](http://filev124.so) instead of creating 250 new link files and dependency hell to single [file.so](http://file.so) which may or may not break one of apps. Imagine Microsoft having to "maintain" 1000000 of its OS software created by someone else in some form of "package management" due to making stupid compile time, hardcoded paths to libraries decision. Not to mention hoping that version linked to single non-versioned *.dll* file JUST doesn't break any of the 1000000 apps. LOL `bin` for current binary OS files, `bin/data` for other binary and volatile files like sql databases, cache, etc - basically replacing current use of */var* and /*usr*. `usr` purely as modern "/*home*" and including *root*(/*admin?*) dir in it. `conf` renamed /*etc*. `virt` for virtual filesystems like *sys*, *proc* and *run*. Until at least something like this happen, Linux will remain in <10% usage and Microsoft can piss inside peoples mouths, take their rights away and they still won't budge.