4 ms·

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

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.
  - notalaser 10y ago
    The point wasn't (only) that they were statically linked, but also that /bin and /lib were separate partitions (or even separate disks) and could be mounted read-only, could be used from tiny ramdisks etc.. In any case, though, I agree that even without the merge, it wouldn't be doable on any modern Linux system. There are examples for both approaches. OpenBSD keeps /bin minimal and statically-linked, and it works. Solaris merged /bin and /usr/bin a long time ago, and -- unsurprisingly -- that works as well. Frankly, as long as it doesn't bork my Debian machine when I move from Jessie to whatever Debian 9 is going to be called, they can merge all they want. At this point, seeing how many Linux systems are doing the merger, it's probably a good idea to do it, too. Packages whose developers give a flying fsck about portability (fewer and fewer nowadays because lockdown and unportability were bad only when Microsoft were doing it) already deal with both usr-merged and usr-unmerged systems (hardly rocket science in most cases), and the maintainers of packages whose developers don't give a flying fsck about portability and only develop for Linux can hope that four years from now, everyone will have merged, especially now that Debian is doing it too.
JdeBP 10y ago
It's a trifle hard to align the idea of what is supposedly "traditional" with the /usr merger that was done in Solaris 2 in the 1990s and AT&T UNIX System 5 Release 4 in the late 1980s. (-:
- notalaser 10y ago
  Hence the " ;-). Indeed, the heritage isn't nearly as unbroken as its proponents think. I think it's perceived as so traditional because most of the free Unices (and, for a long time, Linux) did it, and some of them still do. FreeBSD started dynamically linking things in /bin much later, around 2004 IIRC, but I think OpenBSD and NetBSD still ship only static binaries there. I think the fact that I can't even remember the last time I cared how things in /bin are linked is good proof of how important this "tradition" is, at least for me...
digi_owl 10y ago
Lovely "con" side representation there...

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.
- notalaser 10y ago
  The point wasn't (only) that they were statically linked, but also that /bin and /lib were separate partitions (or even separate disks) and could be mounted read-only, could be used from tiny ramdisks etc.. In any case, though, I agree that even without the merge, it wouldn't be doable on any modern Linux system. There are examples for both approaches. OpenBSD keeps /bin minimal and statically-linked, and it works. Solaris merged /bin and /usr/bin a long time ago, and -- unsurprisingly -- that works as well. Frankly, as long as it doesn't bork my Debian machine when I move from Jessie to whatever Debian 9 is going to be called, they can merge all they want. At this point, seeing how many Linux systems are doing the merger, it's probably a good idea to do it, too. Packages whose developers give a flying fsck about portability (fewer and fewer nowadays because lockdown and unportability were bad only when Microsoft were doing it) already deal with both usr-merged and usr-unmerged systems (hardly rocket science in most cases), and the maintainers of packages whose developers don't give a flying fsck about portability and only develop for Linux can hope that four years from now, everyone will have merged, especially now that Debian is doing it too.

JdeBP 10y ago

It's a trifle hard to align the idea of what is supposedly "traditional" with the /usr merger that was done in Solaris 2 in the 1990s and AT&T UNIX System 5 Release 4 in the late 1980s. (-:

notalaser 10y ago
Hence the " ;-). Indeed, the heritage isn't nearly as unbroken as its proponents think. I think it's perceived as so traditional because most of the free Unices (and, for a long time, Linux) did it, and some of them still do. FreeBSD started dynamically linking things in /bin much later, around 2004 IIRC, but I think OpenBSD and NetBSD still ship only static binaries there. I think the fact that I can't even remember the last time I cared how things in /bin are linked is good proof of how important this "tradition" is, at least for me...

digi_owl 10y ago

Lovely "con" side representation there...