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