12 ms·

Debian considers merging /usr

108 points by dengerzone 10y ago

mastazi 10y ago
HN's hug of death. Cached version is here: http://webcache.googleusercontent.com/search?q=cache:s8ApOo1EgtUJ:https://dralnux.com/debian-considers-merging-usr/&num=1&hl=en&gl=au&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:s8ApOo1...
- RKearney 10y ago
  It looks like a server-side misconfiguration. The URL is 301 redirecting to itself. My guess is the admin has a server side redirect to force http to https, but has CloudFlare configured to use http to the origin.
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.
marcoperaza 10y ago
The linked email is pretty sparse on details. More information: https://lwn.net/Articles/670071/ https://lwn.net/Articles/670071/
alexellisuk 10y ago
The argument is not to remove all trace of /bin /sbin /lib - but to move these folders into /usr/ and then sym-link back to the original locations. More of a detailed response here: https://lwn.net/Articles/670071/ https://lwn.net/Articles/670071/
bigbugbag 10y ago
This move has been made a while ago by arch and didn't seem to cause any trouble. On the other hand, it does not change much compared to the revolution of adopting the gobolinux filesystem that has been proposed more than 10 years ago. [1] [1]: http://gobolinux.org/index.php?page=at_a_glance http://gobolinux.org/index.php?page=at_a_glance http://gobolinux.org/index.php?page=doc/articles/clueless http://gobolinux.org/index.php?page=doc/articles/clueless
- asymmetric 10y ago
  Interesting, I didn't know about GoboLinux, but it reminded me of Nix. Here's a comparison: http://sandervanderburg.blogspot.nl/2011/12/evaluation-and-comparison-of-gobolinux.html http://sandervanderburg.blogspot.nl/2011/12/evaluation-and-c...
  - Iv 10y ago
    I did not know about Gobo either. Why isn't everyone using it yet? Directories as packages, multi-versioning made easy... Use it now!
    - digi_owl 10y ago
      Dunno. Maybe because it is largely made out of shell scripts and symlinks, and not laden with buzzwords?
    - nkuttler 10y ago
      The "how can this possibly work" section shows the problem: System libraries are links to app directories. Basically, you end up bundling the same libs over and over again in your applications. Just imagine having several identical copies of gtk, qt, webkit, etc.
      - digi_owl 10y ago
        Not quite. As long as multiple programs use the same lib version, you only install it once just as with RPM or DEB. but if another program needs a older or newer version you can install that version in parallel without it disturbing the rest.
anderskaseorg 10y ago
“Considers” is old news—the Debian installer already merges /usr by default. https://lists.debian.org/debian-devel-announce/2016/11/msg00006.html https://lists.debian.org/debian-devel-announce/2016/11/msg00...
- BuuQu9hu 10y ago
  That got disabled again: https://packages.qa.debian.org/d/debootstrap/news/20161116T074831Z.html https://packages.qa.debian.org/d/debootstrap/news/20161116T0...
SFJulie 10y ago
The initramsf case and the embedded system case are good point. Can Computer Science help us decide if some people are right? The measure of Informational entropy : a state with more compartment as more order, thus more information. By merging /usr you lose information, thus making the one in need losing it, whereas the one without a need for this gain nothing. I laughed at the comment of philosophy by pitchforks of angry users, and I would claim these pitchforks are the one from the Maxwell Daemons telling us to remember that it is easy to lose information and that increasing entropy is messy.
- tobias12345 10y ago
  By splitting / and /usr you create problems for packagers: Where do all the files need to go? Does cryptsetup need to go into /sbin or /use/sbin? Does network code belong into / or /use? Must users will not care, but some might need either of them to set up their file systems. If you pace something into /, then you also need to put all libraries and binaries that needs into /. That will rapidly blue up the size of /. It is also not automatically testable, so distributions will get things wrong (as they repeatedly did before). You could have a script to only put the stuff your system needs into /... Most distributions use such a script for their initrd, which contains everything necessary to check and mount your root file system. So you could just extract that into / and be fine with it:-) Or just use your initrd as that rescue medium.
reacweb 10y ago
I use Linux (ubuntu gnome) on my main computer since many years. IMHO, changing the FHS should be the lowest priority. The priority should be "hardware support" and "education". By education, I think mainly about the different way to use Linux compare to Windows. Imagine you are traveling and need a file that is at home on your desktop PC. With your phone, you can wake up your PC, connect using ssh, convert the document to pdf and copy it to your phone. Imagine you are visiting a friend and want to show something running on your PC, you wake up your PC, launch putty and a VNC client (portable applications) and you are at home. Imagine you want to keep your machine lean and clean. With docker you can switch between images of preinstalled independent development environments. With sshfs, you access your remote website without a local copy. Imagine you want to change the hard drive. I copy very quickly the very few files in my home directory that are not on NFS to a NFS backup directory. I change the disk, reinstall Linux then uses the small installation diary I keep on google drive to configure disk montages and to reinstall non default applications.
- ben0x539 10y ago
  I don't think adding symlinks to / takes away a meaningful amount of time from the people working on drivers. I think you're gonna have a hard time convincing people these days that the answer to all the scenarios you listed shouldn't just be "lol cloud", too. :/
  - reacweb 10y ago
    Of course, the whole point is that my desktop is part of the network like any remote server. You are not a client of servers, you are a member of a network. AFAIK, rdesktop and logmein are far behind (more difficult to setup and to use). https://code.google.com/archive/p/win-sshfs https://code.google.com/archive/p/win-sshfs seems dead. AFAIK, docker does not work on windows home edition. My scenarios are not made up. These are my very usual and simple use cases of linux. I do not know any windows user that do the same. Do you have a backup copy of your 1TB hard drive on the cloud ?
    - ben0x539 10y ago
d33 10y ago
Given that server's under heavy load, here's a copy-paste: "The bootstrap utility for the upcoming release of Debian 9 “Stretch” will feature the ability to merge utilities from the root file system into the /usr file system. This essentially means directories like /bin and /sbin will simply be symbolic links to content stored in /usr/bin and /usr/sbin. Ansgar Burchardt has suggested this file system layout might be made the default behaviour for future versions of Debian: “It has been previously suggested to make this the default for (at least) new installations. I think Russ’ earlier mail explains quite well why the split between / and /usr doesn’t really work out for Debian these days and that trying to maintain it for some configurations (which are not documented) is mostly busy-work. There is also a nice article on LWN summarizing earlier discussions. I found these arguments convincing enough and would like to see the default switched to merged-/usr for Stretch and later. Possibly also switching systems on upgrade to the new scheme (not necessarily already in the Stretch release cycle).” Source: https://lists.debian.org/debian-devel/2016/09/msg00269.html" https://lists.debian.org/debian-devel/2016/09/msg00269.html"
deleted 10y ago
[deleted]
wtbob 10y ago
Wouldn't it make more sense to merge stuff into / than into /usr, i.e., move /usr/bin/* into /bin, /usr/share into /share &c.? The 'usr' portion of the path is weird historical cruft which adds no real information. While we're at it, why don't we add a real Plan-9-style bind and use union mounts?
- fnord123 10y ago
  >While we're at it, why don't we add a real Plan-9-style bind and use union mounts? There have been a few stabs at a union fs. The most recent one, OverlayFS was merged in 2014.
- lima 10y ago
  No, some people want /usr as a separate partition.
  - rleigh 10y ago
    This hasn't had a genuinely useful purpose for many years. On a modern package-managed Linux distribution, both / and /usr are under the control of the package manager, and separating them doesn't make sense since they are modified in lockstep, and used as a coherent whole. And while in the Linux world we're busy "unifying" these locations, other systems can have the whole system on ZFS, where these locations can be in separate datasets if desired, and the whole lot can be snapshotted at will. Since it's all in a single pool, there's no need to even consider splitting it.
- qb45 10y ago
  Some programs may have strings like /usr/share hardcoded in them. I once tried renaming the root user to "boss" and it unearthed few issues of exactly this kind.
  - kasabali 10y ago
    # ln -s / /usr
- JdeBP 10y ago
deadbunny 10y ago
Personally I prefer the suckless[1] approach, but it's a step in the right direction. 1. http://sta.li/filesystem http://sta.li/filesystem
- tobias12345 10y ago
  That would suck hard for me:-) I have a tmpfs on / and mount a ro-snapshot onto /usr. Fresh system in every reboot:-)
- JdeBP 10y ago
  As discussed at https://news.ycombinator.com/item?id=12591737 https://news.ycombinator.com/item?id=12591737
aargh_aargh 10y ago
Page is down. Mirror: http://archive.is/i2Jsu http://archive.is/i2Jsu
pvaldes 10y ago
So if your partition /usr fails and all that you have in /bin is a broken link instead real programs; your entire system fails. Can't see any real advantage in this.
- Latty 10y ago
  And that's a likely scenario? You actually have them on different bits of hardware or something? It's so arbitrary - why not split it further, what goes where? If you want to achieve splitting important stuff off to special storage, I'm sure that'd still be possible. Also, why recover a system like that when I can just boot off a USB stick? This is just a hack that's stuck around from when people had tiny drives and needed multiple partitions for these things, as far as I understand it.
  - pvaldes 10y ago
    Yes, of course. Is the common scenario in all old-school linux users and had saved me a lot of headaches. It simply works. > Why recover a system like that when I can just boot off a USB stick? Because I can. The basic parts of the system are still available and working. I don't need to reboot to fix the problem, I could mount a different and working /usr in seconds. Is not just "a hack", is a design.
- wyldfire 10y ago
  How often do you provision systems where /usr and /bin are on different media? Do you have some reliability-tiering of the media or are they equivalent-but-separate? If it's the latter it seems like you're no better off.
45h34jh53k4j 10y ago
This broke my debian live build! I couldn't work out why the process would fail during build (it couldnt find the elf loader!) I was clobbering the symlink /lib -> /usr/lib with a local included folder. Gah!!

108 points by dengerzone 10y ago

HN's hug of death. Cached version is here: http://webcache.googleusercontent.com/search?q=cache:s8ApOo1EgtUJ:https://dralnux.com/debian-considers-merging-usr/&num=1&hl=en&gl=au&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:s8ApOo1...

RKearney 10y ago
It looks like a server-side misconfiguration. The URL is 301 redirecting to itself. My guess is the admin has a server side redirect to force http to https, but has CloudFlare configured to use http to the origin.

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.

marcoperaza 10y ago

The linked email is pretty sparse on details. More information: https://lwn.net/Articles/670071/ https://lwn.net/Articles/670071/

alexellisuk 10y ago

The argument is not to remove all trace of /bin /sbin /lib - but to move these folders into /usr/ and then sym-link back to the original locations. More of a detailed response here: https://lwn.net/Articles/670071/ https://lwn.net/Articles/670071/

bigbugbag 10y ago

This move has been made a while ago by arch and didn't seem to cause any trouble. On the other hand, it does not change much compared to the revolution of adopting the gobolinux filesystem that has been proposed more than 10 years ago. [1] [1]: http://gobolinux.org/index.php?page=at_a_glance http://gobolinux.org/index.php?page=at_a_glance http://gobolinux.org/index.php?page=doc/articles/clueless http://gobolinux.org/index.php?page=doc/articles/clueless

asymmetric 10y ago
Interesting, I didn't know about GoboLinux, but it reminded me of Nix. Here's a comparison: http://sandervanderburg.blogspot.nl/2011/12/evaluation-and-comparison-of-gobolinux.html http://sandervanderburg.blogspot.nl/2011/12/evaluation-and-c...
- Iv 10y ago
  I did not know about Gobo either. Why isn't everyone using it yet? Directories as packages, multi-versioning made easy... Use it now!
  - digi_owl 10y ago
    Dunno. Maybe because it is largely made out of shell scripts and symlinks, and not laden with buzzwords?
  - nkuttler 10y ago
    The "how can this possibly work" section shows the problem: System libraries are links to app directories. Basically, you end up bundling the same libs over and over again in your applications. Just imagine having several identical copies of gtk, qt, webkit, etc.
    - digi_owl 10y ago
      Not quite. As long as multiple programs use the same lib version, you only install it once just as with RPM or DEB. but if another program needs a older or newer version you can install that version in parallel without it disturbing the rest.

anderskaseorg 10y ago

“Considers” is old news—the Debian installer already merges /usr by default. https://lists.debian.org/debian-devel-announce/2016/11/msg00006.html https://lists.debian.org/debian-devel-announce/2016/11/msg00...

BuuQu9hu 10y ago
That got disabled again: https://packages.qa.debian.org/d/debootstrap/news/20161116T074831Z.html https://packages.qa.debian.org/d/debootstrap/news/20161116T0...

SFJulie 10y ago

The initramsf case and the embedded system case are good point. Can Computer Science help us decide if some people are right? The measure of Informational entropy : a state with more compartment as more order, thus more information. By merging /usr you lose information, thus making the one in need losing it, whereas the one without a need for this gain nothing. I laughed at the comment of philosophy by pitchforks of angry users, and I would claim these pitchforks are the one from the Maxwell Daemons telling us to remember that it is easy to lose information and that increasing entropy is messy.

tobias12345 10y ago
By splitting / and /usr you create problems for packagers: Where do all the files need to go? Does cryptsetup need to go into /sbin or /use/sbin? Does network code belong into / or /use? Must users will not care, but some might need either of them to set up their file systems. If you pace something into /, then you also need to put all libraries and binaries that needs into /. That will rapidly blue up the size of /. It is also not automatically testable, so distributions will get things wrong (as they repeatedly did before). You could have a script to only put the stuff your system needs into /... Most distributions use such a script for their initrd, which contains everything necessary to check and mount your root file system. So you could just extract that into / and be fine with it:-) Or just use your initrd as that rescue medium.

reacweb 10y ago

I use Linux (ubuntu gnome) on my main computer since many years. IMHO, changing the FHS should be the lowest priority. The priority should be "hardware support" and "education". By education, I think mainly about the different way to use Linux compare to Windows. Imagine you are traveling and need a file that is at home on your desktop PC. With your phone, you can wake up your PC, connect using ssh, convert the document to pdf and copy it to your phone. Imagine you are visiting a friend and want to show something running on your PC, you wake up your PC, launch putty and a VNC client (portable applications) and you are at home. Imagine you want to keep your machine lean and clean. With docker you can switch between images of preinstalled independent development environments. With sshfs, you access your remote website without a local copy. Imagine you want to change the hard drive. I copy very quickly the very few files in my home directory that are not on NFS to a NFS backup directory. I change the disk, reinstall Linux then uses the small installation diary I keep on google drive to configure disk montages and to reinstall non default applications.

ben0x539 10y ago
I don't think adding symlinks to / takes away a meaningful amount of time from the people working on drivers. I think you're gonna have a hard time convincing people these days that the answer to all the scenarios you listed shouldn't just be "lol cloud", too. :/
- reacweb 10y ago
  Of course, the whole point is that my desktop is part of the network like any remote server. You are not a client of servers, you are a member of a network. AFAIK, rdesktop and logmein are far behind (more difficult to setup and to use). https://code.google.com/archive/p/win-sshfs https://code.google.com/archive/p/win-sshfs seems dead. AFAIK, docker does not work on windows home edition. My scenarios are not made up. These are my very usual and simple use cases of linux. I do not know any windows user that do the same. Do you have a backup copy of your 1TB hard drive on the cloud ?
  - ben0x539 10y ago

d33 10y ago

Given that server's under heavy load, here's a copy-paste: "The bootstrap utility for the upcoming release of Debian 9 “Stretch” will feature the ability to merge utilities from the root file system into the /usr file system. This essentially means directories like /bin and /sbin will simply be symbolic links to content stored in /usr/bin and /usr/sbin. Ansgar Burchardt has suggested this file system layout might be made the default behaviour for future versions of Debian: “It has been previously suggested to make this the default for (at least) new installations. I think Russ’ earlier mail explains quite well why the split between / and /usr doesn’t really work out for Debian these days and that trying to maintain it for some configurations (which are not documented) is mostly busy-work. There is also a nice article on LWN summarizing earlier discussions. I found these arguments convincing enough and would like to see the default switched to merged-/usr for Stretch and later. Possibly also switching systems on upgrade to the new scheme (not necessarily already in the Stretch release cycle).” Source: https://lists.debian.org/debian-devel/2016/09/msg00269.html" https://lists.debian.org/debian-devel/2016/09/msg00269.html"

deleted 10y ago

[deleted]

wtbob 10y ago

Wouldn't it make more sense to merge stuff into / than into /usr, i.e., move /usr/bin/* into /bin, /usr/share into /share &c.? The 'usr' portion of the path is weird historical cruft which adds no real information. While we're at it, why don't we add a real Plan-9-style bind and use union mounts?

fnord123 10y ago
>While we're at it, why don't we add a real Plan-9-style bind and use union mounts? There have been a few stabs at a union fs. The most recent one, OverlayFS was merged in 2014.
lima 10y ago
No, some people want /usr as a separate partition.
- rleigh 10y ago
  This hasn't had a genuinely useful purpose for many years. On a modern package-managed Linux distribution, both / and /usr are under the control of the package manager, and separating them doesn't make sense since they are modified in lockstep, and used as a coherent whole. And while in the Linux world we're busy "unifying" these locations, other systems can have the whole system on ZFS, where these locations can be in separate datasets if desired, and the whole lot can be snapshotted at will. Since it's all in a single pool, there's no need to even consider splitting it.
qb45 10y ago
Some programs may have strings like /usr/share hardcoded in them. I once tried renaming the root user to "boss" and it unearthed few issues of exactly this kind.
- kasabali 10y ago
  # ln -s / /usr
JdeBP 10y ago

deadbunny 10y ago

Personally I prefer the suckless[1] approach, but it's a step in the right direction. 1. http://sta.li/filesystem http://sta.li/filesystem

tobias12345 10y ago
That would suck hard for me:-) I have a tmpfs on / and mount a ro-snapshot onto /usr. Fresh system in every reboot:-)
JdeBP 10y ago
As discussed at https://news.ycombinator.com/item?id=12591737 https://news.ycombinator.com/item?id=12591737

aargh_aargh 10y ago

Page is down. Mirror: http://archive.is/i2Jsu http://archive.is/i2Jsu

pvaldes 10y ago

So if your partition /usr fails and all that you have in /bin is a broken link instead real programs; your entire system fails. Can't see any real advantage in this.

Latty 10y ago
And that's a likely scenario? You actually have them on different bits of hardware or something? It's so arbitrary - why not split it further, what goes where? If you want to achieve splitting important stuff off to special storage, I'm sure that'd still be possible. Also, why recover a system like that when I can just boot off a USB stick? This is just a hack that's stuck around from when people had tiny drives and needed multiple partitions for these things, as far as I understand it.
- pvaldes 10y ago
  Yes, of course. Is the common scenario in all old-school linux users and had saved me a lot of headaches. It simply works. > Why recover a system like that when I can just boot off a USB stick? Because I can. The basic parts of the system are still available and working. I don't need to reboot to fix the problem, I could mount a different and working /usr in seconds. Is not just "a hack", is a design.
wyldfire 10y ago
How often do you provision systems where /usr and /bin are on different media? Do you have some reliability-tiering of the media or are they equivalent-but-separate? If it's the latter it seems like you're no better off.

45h34jh53k4j 10y ago

This broke my debian live build! I couldn't work out why the process would fail during build (it couldnt find the elf loader!) I was clobbering the symlink /lib -> /usr/lib with a local included folder. Gah!!