6 ms·

Sbin and bin separation actually causes problems with portability. A certain bluetooth-related utility wants to run iptables command [1] which can usually be fo

Sbin and bin separation actually causes problems with portability. A certain bluetooth-related utility wants to run iptables command [1] which can usually be found in `/sbin`. But `/sbin` is not in the PATH so they have hardcoded `/sbin/iptables` into the source. Now distributions that have iptables in `/usr/sbin` have to patch the program. So it would be better if either there were no `/sbin` or if it was always in the PATH. [1] https://github.com/blueman-project/blueman/blob/fcef83a01c80bec3bbee731a162ce18a0f4c097a/blueman/main/NetConf.py#L365 https://github.com/blueman-project/blueman/blob/fcef83a01c80...

thorawy88 5y ago
This is a ridiculous thought ending argument. Other projects need to sit still so one project doesn’t have to change one line of code? Nonsense. Keep up or get forked (that’s not a euphemism for vulgarity). It’s not esoteric magic like it used to be.
lloydatkinson 5y ago
Why do none of them make a PR to change the original repo instead of maintaining forks?
zaphirplane 5y ago
it is be better for the program to amend path for itself to include both paths. Or probe for its location Rather than hardcore one or the other
- Dylan16807 5y ago
  Hardcoding two locations is only marginally better than hardcoding one. (By probe I assume you mean probing a hardcoded list rather than something even more fragile and confusing.)
  - zaphirplane 5y ago
    Why ? If it’s in the path use that, else if in /sbin use that else in /bin use that Everyone happy
    - usrbinbash 5y ago
      Until it suddenly isn't in either of these paths, maybe because its required to run in some quirky setup. Hrdcoded paths for things a program doesn't bring with itself, should be avoided in general. There is a reason $PATH exists and is easily extended. It is the users/admins responsibility to make sure envvars are set correctly, and it's the programs responsibility to give a useful error message when it cannot locate the programs it expects in $PATH
Gigachad 5y ago
Modern distros just have a single bin directory and symlinks for the rest to resolve this. My favourite one is how people try to come up with reasons for the /usr dir and why /bin and /usr/bin both exist. The original reason was that one of the original Unix devs ran out of space on their hard drive and needed a second bin folder for the new drive.
- vbezhenar 5y ago
  What distros? Fedora is pretty modern and uses separate /usr/bin and /usr/sbin directories.
  - usrbinbash 5y ago
    Manjaro does, not 100% sure about Arch, but I think its symlinked there as well.
- Fnoord 5y ago
  Back in the days, what often happened was /usr was mounted over NFS or a second harddisk like you mentioned (space and maintainability being possible reasons). Because NFS locking was an issue, you'd use lockable files (such as /var and /tmp) on different partitions.

thorawy88 5y ago

This is a ridiculous thought ending argument. Other projects need to sit still so one project doesn’t have to change one line of code? Nonsense. Keep up or get forked (that’s not a euphemism for vulgarity). It’s not esoteric magic like it used to be.

lloydatkinson 5y ago

Why do none of them make a PR to change the original repo instead of maintaining forks?

zaphirplane 5y ago

it is be better for the program to amend path for itself to include both paths. Or probe for its location Rather than hardcore one or the other

Dylan16807 5y ago
Hardcoding two locations is only marginally better than hardcoding one. (By probe I assume you mean probing a hardcoded list rather than something even more fragile and confusing.)
- zaphirplane 5y ago
  Why ? If it’s in the path use that, else if in /sbin use that else in /bin use that Everyone happy
  - usrbinbash 5y ago
    Until it suddenly isn't in either of these paths, maybe because its required to run in some quirky setup. Hrdcoded paths for things a program doesn't bring with itself, should be avoided in general. There is a reason $PATH exists and is easily extended. It is the users/admins responsibility to make sure envvars are set correctly, and it's the programs responsibility to give a useful error message when it cannot locate the programs it expects in $PATH

Gigachad 5y ago

Modern distros just have a single bin directory and symlinks for the rest to resolve this. My favourite one is how people try to come up with reasons for the /usr dir and why /bin and /usr/bin both exist. The original reason was that one of the original Unix devs ran out of space on their hard drive and needed a second bin folder for the new drive.

vbezhenar 5y ago
What distros? Fedora is pretty modern and uses separate /usr/bin and /usr/sbin directories.
- usrbinbash 5y ago
  Manjaro does, not 100% sure about Arch, but I think its symlinked there as well.
Fnoord 5y ago
Back in the days, what often happened was /usr was mounted over NFS or a second harddisk like you mentioned (space and maintainability being possible reasons). Because NFS locking was an issue, you'd use lockable files (such as /var and /tmp) on different partitions.