On Mon, Sep 30, 2013 at 12:04:38AM +0200, Alan McKinnon wrote: > On 29/09/2013 23:41, Dale wrote: > > Alan McKinnon wrote: > >> On 29/09/2013 18:33, Dale wrote: > >>>> that gnome is very hostile when it comes to KDE or choice is not news. > >>>>> And their dependency on systemd is just the usual madness. But they are > >>>>> not to blame for seperate /usr and the breakage it causes. > >>> If not, then what was it? You seem to know what it was that started it > >>> so why not share? > >>> > >> He already said it. Someone added a hard disk to a PDP-9 (or was it an 11?) > >> > >> Literally. It all traces back to that. In those days there was no such > >> thing as volume management or raid. If you added a (seriously expensive) > >> disk the only feasible way to get it's storage in the system was to > >> mount it as a separate volume. > >> > >> >From that one single action this entire mess of separate /usr arose as > >> folks discovered more and more reasons to consider it good and keep it > >> around
Yes you elide over that part, but it's central: there were more and more reasons to consider it good, and to use it. You said it. They haven't gone away just because some prat's had a brainwave and needs a lie-down, not encouragement. In fact most of them are touted as "USPs" in the propaganda we get told is a reasoned argument for ditching all our collective experience. > > > > That wasn't the question tho. My question wasn't about many years ago > > but who made the change that broke support for a seperate /usr with no > > init thingy. The change that happened in the past few years. > > > > I think I got my answer already tho. Seems William Hubbs answered it > > but I plan to read his message again. Different thread tho. > > > > Nobody "broke" it. > > It's the general idea that you can leave /usr unmounted until some > random arb time later in the startup sequence and just expect things to > work out fine that is broken. > > It just happened to work OK for years because nothing happened to use > the code in /usr at that point in the sequence. Actually because people put *thinking* into what things were needed in early boot and what were not. In fact *exactly the same* thinking that goes into sorting out an initramfs. Only you don't need to keep syncing it, and you don't need to worry about missing stuff. Or you never used to, given a reasonably competent distro. Which was half the point in using one. Thankfully software like agetty deliberately has tight linkage, and it's simple enough to move the two or three things that need it to rootfs; it's even officially fine as far as portage is concerned (though I do get an _anticipated_ warning on glibc upgrades.) > More and more we are > seeing that this is no longer the case. > > So no-one broke it with a specific commit. True enough. Cumulative lack of discipline is to blame, although personally I blame gmake's insane rewriting of lib deps before the linker even sees them, that makes $+ a lot less useful than it should be, and imo led to a general desire not to deal with linkage in the early days of Linux, that never went away. > It has always been broken by > design becuase it's a damn stupid idea that just happened to work by > fluke. *cough* bullsh1t. > IT and computing is rife with this kind of error. Indeed: and even more rife with a history of One True Way. So much so that it's a cliche. Somehow it's now seen as "hip" to be crap at your craft, unable to recognise an ABI, and cool to subscribe to "N + 1" True Way, as that's an "innovation" on the old form of garbage. And yet GIGO will still apply, traditional as it may be. Peace and hugs ;) steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
