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:
Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.)
You could use two partition update scheme as ChromeOS. I am working on Linux distribution that have rootfs as a squashfs image and I want to have as painless updates as on ChromeOS.
> Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.)
You can mount RW fs on RO fs. Distributions on Live-CDs do it all the time.
Right, but that's with OverlayFS and such, right? (I.e. not just straight bind mounts.)
Seems awfully complicated to solve what essentially should be a non-problem... (I'm aware OverlayFS has other uses, but in this instance it seems like overkill.)
EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss.
Most probably yes, but there are probably distributions using ro rootfs + specific mounts. I think that in many cases embedded devices would use such a scheme instead of OverlayFS.
EDIT: But you probably have to mount workdir and upperdir somewhere over this ro rootfs for OverlayFS to work.
> EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss.
I was hoping that you could read between the lines also :) I mentioned my WIP distribution. I have mounted:
- squashfs ro on /
- ext4 rw on /mnt/rw
- /mnt/rw/var bind on /var
- /mnt/rw/home bind on /home
Oooh, burn! :) I honestly didn't see any relevant mention of the WIP-distro you're talking about... but now that you mention it I had a look back. "I am working on Linux distribution" (etc.).
> I have mounted:[snip]
So... separate file systems.
Surely there's a lot of horrible software out there that Makes Assumptions.
It doesn't make much sense anymore but before the turn of the century a meg of doc files might cost you a buck per machine, which might add up to a lot of money given a lot of machines and a lot of software... And usually you don't need /usr/doc but when you do need it you REALLY need it and don't mind if its a little slower to access via NFS than on a local drive.
In the same old days, some brave people exported /usr/src. Oh and X window fonts too.
The Linux "community" have a bad habit of turning solutions for special scenarios into generic ones by hook or by crook.
Never mind that this was addressed to the busybox mailing list, a project aimed at reimplmenting the unix coreutils as a single static binary.
You also had people who would build a Linux box out of any old hardware they had left over. That's how I ended up with my first firewall.
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.
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).
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.
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.
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...
[1]: https://lists.archlinux.org/pipermail/arch-dev-public/2012-M...
site:bugzilla.redhat.com "UsrMove"
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
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.
/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/074...
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.
With this change, this management format is gone. What is not a big loss nowadays.
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.