10 ms·

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 syste

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.

cryptonector 4y 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.
gorgoiler 4y ago
What about /usr/games! Insensitive clod!
- tremon 4y 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.
  - bityard 4y ago
    It's a historical unix thing. Things in /usr/games (which were not all games) were frivolous and not essential to the OS, and were distributed as a separate tape or archive so that admins could easily choose whether or not to install them.
    - jmclnx 4y ago
      /usr/games existing allows people to find the most important binaries. If in */bin finding all of these could be difficult
      - KerrAvon 4y ago
        We have a hierarchical filesystem. /usr/bin/games could be a thing.
    - shagie 4y ago
      I'll also note /usr/games/dm ( https://github.com/vattam/BSDGames/tree/master/dm https://github.com/vattam/BSDGames/tree/master/dm ) which allowed sysadmins to restrict when programs in /usr/games could be run. Setting up that structure in /usr/bin would be more work to maintain.
Maursault 4y 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 4y 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.
  - Maursault 4y ago
    > To be clear, GP's stated intention was > to merge /sbin with /bin, and /usr/sbin with /usr/bin It's a bit more drastic than you make it out to be. This would give two valid $PATHS to the same commands. It would make tab-completion slow. It would likely break all kinds of compatibility across the SUS. And it is incredibly arbitrary, no better or worse than eliminating system hierarchy entirely and putting everything in /.
- sph 4y 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_ 4y 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.
- hpb42 4y 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
  - red_trumpet 4y ago
    Same on my (X)Ubuntu 20.04.
  - salmo 4y ago
    I think nearly all Linux distros did this when they adopted systemd. That’s where I first read this argument. I know RHEL, Debian, and Arch do. Not a lot outside of those families.
  - stouset 4y ago
    I'm actually a bit surprised about `/bin` there. Maybe it's archaic but I've always considered the point of `/bin` to be a minimal set of tools that could allow an otherwise-hosed system to be booted/debugged. So it (and `/lib` and a few other directories) might be on a small, read-only partition while `/usr` and friends are on a much larger read-write partition. Of course in the last twenty-five years I don't think I've ever really used a system set up like that. But it does seem nice to at least be able to do so.
    - xjrk 4y ago
      I've used to setup my system exactly like that, but that was in 20xx. Since then I've got lazy.
tremon 4y 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.
- mekster 4y ago
  Don't you need sbin in PATH anyway when you want to run them with sudo?
  - smhenderson 4y ago
    There's a "secure path" option in sudoers that you can use to add additional directories to the path that is searched when sudo is invoked. Most examples will include the standard user path plus /sbin and /usr/sbin but you can add any directories you want to the option.
    - mekster 4y ago
      Isn't that for executing than autocompleting?
      - smhenderson 4y ago
        Yes, that's correct, it's only about searching the right directories to find and execute the program you asked for. But autocomplete after sudo doesn't work for me on a stock Debian install anyway, not sure what one needs to do to get around that. I don't really rely on it. If I'm doing enough work that needs root I start the session with "sudo su -" anyway so not having autocomplete after sudo is not a big deal for me.
  - robonerd 4y ago
    What if I want to run fsck on a drive image owned by my user? If I can run /sbin/fsck, I can rightly run that on such a file without using sudo.
pseudostem 4y 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
- gjadi 4y ago
  It is specified this way on OpenBSD: https://man.openbsd.org/man7/hier.7 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.
- patrck 4y ago
  Yeah, this is received unix lore: anything needed to recover a system needs to be statically linked and in /bin or /sbin.
  - adrian_b 4y ago
    That was indeed the tradition, but on Linux the GNU libc wants to be only dynamically linked, which creates a lot of problems for those who want static executables. Because of that, in many Linux distributions there are few, if any, static executables. Due to this, it may happen that a botched glibc upgrade makes the system unusable, because no executable can be started to repair it (nowadays many distributions have a static busybox for such situations). I have seen this a couple of times, and the first time I could not understand what happened, because I was used to older systems, where the commands that I tried to execute (e.g. ls or mv) had been statically linked. Such a thing could never happen in a traditional UNIX or Linux system, before glibc disallowed static linking. The GNU libc should have been split into a libc with most of the functions, which may be linked statically without problems, and into a small library with the name resolving functions, which could be linked dynamically only by the programs which need those functions. Even better, the name resolving functions should have been organized in such a way to be able to use their default configuration with static linking and choose dynamic linking only when you really intend to override the default configuration when using less common services, e.g. NIS.
mekster 4y ago
What ancient system makes a speed difference in command lookup in PATH?
- EdSchouten 4y 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.
  - criddell 4y ago
    Is that ever going to be a hot path?
    - hnlmorg 4y ago
      Theoretically can be. Every command you invoke without a path will need to look up PATH. In practice well behaving shells cache the contents of PATH to speed up operations.
    - naniwaduni 4y ago
      It's probably not exactly going to be hot, but even failing execve is inherently semi-expensive since it needs to be a syscall and incurs context switches. It's just outweighed a couple orders of magnitude by all the overhead that comes with a successfully launching another executable unless you have, like, a thousand junk paths in your PATH.
  - mekster 4y ago
    Sounds like they need fixed for inefficient handling of simple operation.
    - EdSchouten 4y ago
      Enlighten me how you would implement it instead.
    - 4y ago
teknopaul 4y 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.
- usrbinbash 4y 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.

cryptonector 4y 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.

gorgoiler 4y ago

What about /usr/games! Insensitive clod!

tremon 4y 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.
- bityard 4y ago
  It's a historical unix thing. Things in /usr/games (which were not all games) were frivolous and not essential to the OS, and were distributed as a separate tape or archive so that admins could easily choose whether or not to install them.
  - jmclnx 4y ago
    /usr/games existing allows people to find the most important binaries. If in */bin finding all of these could be difficult
    - KerrAvon 4y ago
      We have a hierarchical filesystem. /usr/bin/games could be a thing.
  - shagie 4y ago
    I'll also note /usr/games/dm ( https://github.com/vattam/BSDGames/tree/master/dm https://github.com/vattam/BSDGames/tree/master/dm ) which allowed sysadmins to restrict when programs in /usr/games could be run. Setting up that structure in /usr/bin would be more work to maintain.

Maursault 4y 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 4y 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.
- Maursault 4y ago
  > To be clear, GP's stated intention was > to merge /sbin with /bin, and /usr/sbin with /usr/bin It's a bit more drastic than you make it out to be. This would give two valid $PATHS to the same commands. It would make tab-completion slow. It would likely break all kinds of compatibility across the SUS. And it is incredibly arbitrary, no better or worse than eliminating system hierarchy entirely and putting everything in /.
sph 4y 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_ 4y 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.

hpb42 4y 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
- red_trumpet 4y ago
  Same on my (X)Ubuntu 20.04.
- salmo 4y ago
  I think nearly all Linux distros did this when they adopted systemd. That’s where I first read this argument. I know RHEL, Debian, and Arch do. Not a lot outside of those families.
- stouset 4y ago
  I'm actually a bit surprised about `/bin` there. Maybe it's archaic but I've always considered the point of `/bin` to be a minimal set of tools that could allow an otherwise-hosed system to be booted/debugged. So it (and `/lib` and a few other directories) might be on a small, read-only partition while `/usr` and friends are on a much larger read-write partition. Of course in the last twenty-five years I don't think I've ever really used a system set up like that. But it does seem nice to at least be able to do so.
  - xjrk 4y ago
    I've used to setup my system exactly like that, but that was in 20xx. Since then I've got lazy.

tremon 4y 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.

mekster 4y ago
Don't you need sbin in PATH anyway when you want to run them with sudo?
- smhenderson 4y ago
  There's a "secure path" option in sudoers that you can use to add additional directories to the path that is searched when sudo is invoked. Most examples will include the standard user path plus /sbin and /usr/sbin but you can add any directories you want to the option.
  - mekster 4y ago
    Isn't that for executing than autocompleting?
    - smhenderson 4y ago
      Yes, that's correct, it's only about searching the right directories to find and execute the program you asked for. But autocomplete after sudo doesn't work for me on a stock Debian install anyway, not sure what one needs to do to get around that. I don't really rely on it. If I'm doing enough work that needs root I start the session with "sudo su -" anyway so not having autocomplete after sudo is not a big deal for me.
- robonerd 4y ago
  What if I want to run fsck on a drive image owned by my user? If I can run /sbin/fsck, I can rightly run that on such a file without using sudo.

pseudostem 4y 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

gjadi 4y ago
It is specified this way on OpenBSD: https://man.openbsd.org/man7/hier.7 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.
patrck 4y ago
Yeah, this is received unix lore: anything needed to recover a system needs to be statically linked and in /bin or /sbin.
- adrian_b 4y ago
  That was indeed the tradition, but on Linux the GNU libc wants to be only dynamically linked, which creates a lot of problems for those who want static executables. Because of that, in many Linux distributions there are few, if any, static executables. Due to this, it may happen that a botched glibc upgrade makes the system unusable, because no executable can be started to repair it (nowadays many distributions have a static busybox for such situations). I have seen this a couple of times, and the first time I could not understand what happened, because I was used to older systems, where the commands that I tried to execute (e.g. ls or mv) had been statically linked. Such a thing could never happen in a traditional UNIX or Linux system, before glibc disallowed static linking. The GNU libc should have been split into a libc with most of the functions, which may be linked statically without problems, and into a small library with the name resolving functions, which could be linked dynamically only by the programs which need those functions. Even better, the name resolving functions should have been organized in such a way to be able to use their default configuration with static linking and choose dynamic linking only when you really intend to override the default configuration when using less common services, e.g. NIS.

mekster 4y ago

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

EdSchouten 4y 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.
- criddell 4y ago
  Is that ever going to be a hot path?
  - hnlmorg 4y ago
    Theoretically can be. Every command you invoke without a path will need to look up PATH. In practice well behaving shells cache the contents of PATH to speed up operations.
  - naniwaduni 4y ago
    It's probably not exactly going to be hot, but even failing execve is inherently semi-expensive since it needs to be a syscall and incurs context switches. It's just outweighed a couple orders of magnitude by all the overhead that comes with a successfully launching another executable unless you have, like, a thousand junk paths in your PATH.
- mekster 4y ago
  Sounds like they need fixed for inefficient handling of simple operation.
  - EdSchouten 4y ago
    Enlighten me how you would implement it instead.
  - 4y ago

teknopaul 4y 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.

usrbinbash 4y 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.