> > That's a huge administrative hassle. Not only do you have to figure > > out what programs and libraries /bin/mount depends on so you can make > > sure they're on your real root partition, but the packaging system > > doesn't - and shouldn't - do anything to help you keep the two copies > > of /bin in sync. [Thomas Bushnell BSG] > Um, that "figuring out" is *exactly* the figuring out that you are > *already* doing in maintaining a separate /usr. No. Debian is figuring it out. My whole point is that you've shifted the job of doing so to the site admin. If you are expecting dpkg to take on the responsibility for peeking under people's mounted /bin directories and installing/upgrading things on the root partition that need to be on the root partition - then you're being absurd. > > You would put up with all *that* for a 6-megabyte savings on your > > root filesystem? > > My /usr is rather more than 6 MB. Well, my apologies, I was confusing your proposal slightly. My existing /bin is just over 6 MB, so overlaying *that* with only /bin/mount and its helpers would save me that much. I guess you're talking about moving all of /usr into the root hierarchy, like the hurd does upstream. > > I should mention that I'm still waiting for your benchmark results > > on how a drastic reduction in /usr/lib size speeds up the runtime > > linker. On *any* filesystem, O(n)-lookups or not. > > Your demand to run a benchmark does not translate to an obligation on > my part to run it. Suit yourself. I know you're educated enough to understand the principle of burden-of-proof, and why this falls to the ones proposing change. If you base arguments for change on a speedup which ought to be easily measurable, refusing to measure it degrades your position considerably, and makes you look silly. But that's not my bailiwick.
Description: Digital signature