Re: [gentoo-user] Re: Re: Flexibility and robustness in the Linux organisim

[Alan McKinnon]

On 11/10/2013 09:54, Steven J. Long wrote:
> 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.

I have no idea what you are trying to communicate or accomplish with this.

All I see in all your responses is that you are railing against why
things are no longer the way they used to be.



-- 
Alan McKinnon
alan.mckinnon@×××××.com