2 ms·

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

by 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.

by marios 10y ago

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.