5 ms·

So what are the arguments actually? A couple of days ago I was reading some POSIX book from 1991 and there the layout of /bin /lib /shared /usr/name/bin /usr/n

by jeena 10y ago

So what are the arguments actually? A couple of days ago I was reading some POSIX book from 1991 and there the layout of /bin /lib /shared /usr/name/bin /usr/name/lib /usr/name/shared and so on was much more logical than what we have now which is just weird as far as I can see because I don't understand it.

digi_owl 10y ago
As best i can tell, thanks to systemd requirements etc initramfs has become bloated to the point that /sbin is largely redundant.
- icebraining 10y ago
  The systemd devs claim it has nothing to do with it, but with a bunch of other software that expects /usr to be mounted at boot time: https://wiki.freedesktop.org/www/Software/systemd/separate-usr-is-broken/ https://wiki.freedesktop.org/www/Software/systemd/separate-u...
  - kbenson 10y ago
    Additionally, I think a good argument could be made that anything that systemd requires to boot should be in sbin, not specifically because systemd requires it, but because it's required or useful for the boot process, as systemd has illustrated, and thus should not be relegated to /usr (depending on where you draw the line between useful and required and whether useful is sufficient to be included in /).
  - groovy2shoes 10y ago
    That's why you mount /usr at boot time... in your initscript...
- deleted 10y ago
  [deleted]
kbenson 10y ago
Originally, disks weren't that big, and / was meant to house what was required to boot and run a minimal system, and additional software was installed in /usr, often on one or more different disks. There's some additional benefit to running a separate /usr partition, which is that you can mount / as read-only for some additional security (but not much, IMO).
- rodgerd 10y ago
  Originally /usr was the user data. Then the disks got full and someone stuck binaries into it. Then people moved to /u, /usr2, /home, or whatever your ix variant (or site) wanted for user data. The ix file system standards are the retcons of a bunch of hacks made by sysadmins trying to stave off users with pitchforks. Philosophy my arse.
  - B1FF_PSUVM 10y ago
    Eh, the seminal BOfH story: "AH! - You haven't got any files" (Here: http://bofh.bjash.com/bofh/genesis2.html http://bofh.bjash.com/bofh/genesis2.html )
pavanky 10y ago
Here is some discussion from ArchLinux[1] and Fedora[2] [1]: https://lists.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html https://lists.archlinux.org/pipermail/arch-dev-public/2012-M... [2]: https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove
- rwmj 10y ago
  That Fedora one is very biased, written by the advocates for UsrMove. A better way would be to search on Google for: site:bugzilla.redhat.com "UsrMove" which produces page after page of bug reports. The reality is it caused lots of breakage throughout the system which required many man-hours to fix over years. The gain from it is pretty minimal. And there are still bugs everywhere, for example these two commands ought to the do the same thing, but in fact the first breaks and the second works: # dnf install /sbin/ifconfig # dnf install /usr/sbin/ifconfig (It's something to do with either RPM or DNF not "knowing" that the two paths point to the same file, even though /sbin is a symlink to /usr/sbin. Various attempts have been made to fix this but obviously we're not there yet). The good thing from Debian's point of view is that Fedora and Arch already fixed many of the bugs, so things will probably be smoother for Debian.
hawski 10y ago
The best explanation goes from Rob Landley: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074... Some fragment: > When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!). > Of course they made rules about "when the system first boots, it has to come up enough to be able to mount the second disk on /usr, so don't put things like the mount command /usr/bin or we'll have a chicken and egg problem bringing the system up." Fairly straightforward. Also fairly specific to v6 unix of 35 years ago. It was discussed here few times: https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=9554134 https://news.ycombinator.com/item?id=9554134
- torrent-of-ions 10y ago
  Considering this, I wonder why the /usr would be kept at all, assuming we keep /home. Why not just have /bin etc. since we can generally fit everything there these days?
  - vbernat 10y ago
    /usr can be made read-only. It is more convenient to have everything in /usr than to have /bin, /sbin, /lib, etc.
    - vbezhenar 10y ago
      I would argue, that it's better to mount / as RO and remount /var, /home as RW.
      - 10y ago
notalaser 10y ago
Rusty Russell summarized this nicely a few years ago: http://rusty.ozlabs.org/?p=236 http://rusty.ozlabs.org/?p=236 (careful, sarcasm follows). The merge does involve some loss of flexibility (for instance, "traditionally", you could use the programs in /bin to recover a failing system), but there are fewer and fewer users relying on it. It also involves departing from the FHS, but Debian already does that (e.g. they use /lib/<GNU triplet> rather than /lib{32,64}). I haven't heard any super convincing arguments from either side; normally, I'd go by the "not broken -- nothing to fix" route, but it's also hard to poke holes in the "this additional complexity isn't needed anymore" line of reasoning. Plus, like most arguments that involve tradition, it's pretty hard to tell robustness from cruft. Whether this change can be done cleanly and without breaking users' systems is an entirely different story and past experience has shown that moderation is a far better friend than optimism. It's particularly difficult to migrate existing installation to this scheme (e.g. Arch failed quite badly, as I remember from those particular two afternoons, thanks a lot Arch!, and it didn't go more smoothly for others, either), but Debian can benefit from the lessons learned by more up-to-da^H^H^H^H fast-moving distributions and do things better.
- marios 10y ago
  Using programs in /bin to recover a failing system is a lost cause on Linux. Pretty much every binary in /bin in Debian (the OS I have at hand to check) links to a library of some sort. Therefore, if my /lib is hosed, I can't use any of the tools in /bin (I've had this happen, and I couldn't even use "ls". This would not have occured if those binaries were statically linked (I believe OpenBSD does that for /bin and /sbin).
  - wyldfire 10y ago
    > Using programs in /bin to recover a failing system is a lost cause on Linux. Agreed. If distros wanted to try and champion the cause for a statically linked subset of critical coreutils, they could still do it in the merged tree. The only thing the separation would facilitate would be separate mount points or physical devices.
    - 10y ago
anexprogrammer 10y ago
Way back when the world was in black and white, DEC PDP 11 RK05 disk packs could only hold 1.5 Meg. /bin and /usr/bin were on different drives. Now all those weird splits and choices make sense. Fuller explanation here: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...
marcosdumay 10y ago
Added to any historical reason, the separation between the / dirs and /usr dirs made Unix networks manageable. You could have a minimal setup on every machine, and just mount /usr (and /var) from a centralized server. With this change, this management format is gone. What is not a big loss nowadays.

by jeena 10y ago

digi_owl 10y ago

As best i can tell, thanks to systemd requirements etc initramfs has become bloated to the point that /sbin is largely redundant.

icebraining 10y ago
The systemd devs claim it has nothing to do with it, but with a bunch of other software that expects /usr to be mounted at boot time: https://wiki.freedesktop.org/www/Software/systemd/separate-usr-is-broken/ https://wiki.freedesktop.org/www/Software/systemd/separate-u...
- kbenson 10y ago
  Additionally, I think a good argument could be made that anything that systemd requires to boot should be in sbin, not specifically because systemd requires it, but because it's required or useful for the boot process, as systemd has illustrated, and thus should not be relegated to /usr (depending on where you draw the line between useful and required and whether useful is sufficient to be included in /).
- groovy2shoes 10y ago
  That's why you mount /usr at boot time... in your initscript...
deleted 10y ago
[deleted]

kbenson 10y ago

Originally, disks weren't that big, and / was meant to house what was required to boot and run a minimal system, and additional software was installed in /usr, often on one or more different disks. There's some additional benefit to running a separate /usr partition, which is that you can mount / as read-only for some additional security (but not much, IMO).

rodgerd 10y ago
Originally /usr was the user data. Then the disks got full and someone stuck binaries into it. Then people moved to /u, /usr2, /home, or whatever your ix variant (or site) wanted for user data. The ix file system standards are the retcons of a bunch of hacks made by sysadmins trying to stave off users with pitchforks. Philosophy my arse.
- B1FF_PSUVM 10y ago
  Eh, the seminal BOfH story: "AH! - You haven't got any files" (Here: http://bofh.bjash.com/bofh/genesis2.html http://bofh.bjash.com/bofh/genesis2.html )

pavanky 10y ago

Here is some discussion from ArchLinux[1] and Fedora[2] [1]: https://lists.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html https://lists.archlinux.org/pipermail/arch-dev-public/2012-M... [2]: https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove

rwmj 10y ago
That Fedora one is very biased, written by the advocates for UsrMove. A better way would be to search on Google for: site:bugzilla.redhat.com "UsrMove" which produces page after page of bug reports. The reality is it caused lots of breakage throughout the system which required many man-hours to fix over years. The gain from it is pretty minimal. And there are still bugs everywhere, for example these two commands ought to the do the same thing, but in fact the first breaks and the second works: # dnf install /sbin/ifconfig # dnf install /usr/sbin/ifconfig (It's something to do with either RPM or DNF not "knowing" that the two paths point to the same file, even though /sbin is a symlink to /usr/sbin. Various attempts have been made to fix this but obviously we're not there yet). The good thing from Debian's point of view is that Fedora and Arch already fixed many of the bugs, so things will probably be smoother for Debian.

hawski 10y ago

The best explanation goes from Rob Landley: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074... Some fragment: > When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!). > Of course they made rules about "when the system first boots, it has to come up enough to be able to mount the second disk on /usr, so don't put things like the mount command /usr/bin or we'll have a chicken and egg problem bringing the system up." Fairly straightforward. Also fairly specific to v6 unix of 35 years ago. It was discussed here few times: https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=9554134 https://news.ycombinator.com/item?id=9554134

torrent-of-ions 10y ago
Considering this, I wonder why the /usr would be kept at all, assuming we keep /home. Why not just have /bin etc. since we can generally fit everything there these days?
- vbernat 10y ago
  /usr can be made read-only. It is more convenient to have everything in /usr than to have /bin, /sbin, /lib, etc.
  - vbezhenar 10y ago
    I would argue, that it's better to mount / as RO and remount /var, /home as RW.
    - 10y ago

notalaser 10y ago

Rusty Russell summarized this nicely a few years ago: http://rusty.ozlabs.org/?p=236 http://rusty.ozlabs.org/?p=236 (careful, sarcasm follows). The merge does involve some loss of flexibility (for instance, "traditionally", you could use the programs in /bin to recover a failing system), but there are fewer and fewer users relying on it. It also involves departing from the FHS, but Debian already does that (e.g. they use /lib/<GNU triplet> rather than /lib{32,64}). I haven't heard any super convincing arguments from either side; normally, I'd go by the "not broken -- nothing to fix" route, but it's also hard to poke holes in the "this additional complexity isn't needed anymore" line of reasoning. Plus, like most arguments that involve tradition, it's pretty hard to tell robustness from cruft. Whether this change can be done cleanly and without breaking users' systems is an entirely different story and past experience has shown that moderation is a far better friend than optimism. It's particularly difficult to migrate existing installation to this scheme (e.g. Arch failed quite badly, as I remember from those particular two afternoons, thanks a lot Arch!, and it didn't go more smoothly for others, either), but Debian can benefit from the lessons learned by more up-to-da^H^H^H^H fast-moving distributions and do things better.

marios 10y ago
Using programs in /bin to recover a failing system is a lost cause on Linux. Pretty much every binary in /bin in Debian (the OS I have at hand to check) links to a library of some sort. Therefore, if my /lib is hosed, I can't use any of the tools in /bin (I've had this happen, and I couldn't even use "ls". This would not have occured if those binaries were statically linked (I believe OpenBSD does that for /bin and /sbin).
- wyldfire 10y ago
  > Using programs in /bin to recover a failing system is a lost cause on Linux. Agreed. If distros wanted to try and champion the cause for a statically linked subset of critical coreutils, they could still do it in the merged tree. The only thing the separation would facilitate would be separate mount points or physical devices.
  - 10y ago

anexprogrammer 10y ago

Way back when the world was in black and white, DEC PDP 11 RK05 disk packs could only hold 1.5 Meg. /bin and /usr/bin were on different drives. Now all those weird splits and choices make sense. Fuller explanation here: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...

marcosdumay 10y ago

Added to any historical reason, the separation between the / dirs and /usr dirs made Unix networks manageable. You could have a minimal setup on every machine, and just mount /usr (and /var) from a centralized server. With this change, this management format is gone. What is not a big loss nowadays.