1 |
On Mon, Sep 30, 2013 at 11:37:53PM +0100, Neil Bothwick wrote: |
2 |
> On Mon, 30 Sep 2013 17:05:39 -0400, Walter Dnes wrote: |
3 |
> |
4 |
> > > If *something1* at boot time requires access to *something2* at boot |
5 |
> > > time that isn't available then I would say that *something1* is broken |
6 |
> > > by design not the *something2*. |
7 |
> > |
8 |
> > What about the case where *something2* *USED TO BE AVAILABLE, BUT HAS |
9 |
> > BEEN MOVED TO /USR* ? |
10 |
> |
11 |
> What about the case where something1 wasn't required at boot time but |
12 |
> changed circumstances mean it now is? |
13 |
|
14 |
What about it? Honestly it's like you lot don't know the basics of scripting |
15 |
or something. $PATH ffs. |
16 |
|
17 |
(And don't start on at me about badly-coded apps: fix the apps, or the ebuilds |
18 |
not the OS: it's not broken, and certainly does not need to worked-around.) |
19 |
|
20 |
> > > So I would argue that devs relying on /usr always being there have |
21 |
> > > broken the "system". |
22 |
> > |
23 |
> > So I would argue that unnecessarily moving stuff into /usr is |
24 |
> > deliberate sabotage, designed to break *something1*. |
25 |
> |
26 |
> Define unnecessarily in that context? You can't, not for all use cases. |
27 |
> There are many files that clearly need to be available early on, and many |
28 |
> more that clearly do not. Between them is a huge grey area, files that |
29 |
> some need and some don't, that may be needed now or at some indeterminate |
30 |
> point in the future. If you put everything that may conceivably be needed |
31 |
> at early boot into /, you shift a large chunk of /usr/*bin/ and /usr/lib* |
32 |
> into /, effectively negating the point of a small, lean /. That puts us |
33 |
> right back where we started, try to define a point of separation that |
34 |
> cannot be defined. |
35 |
|
36 |
Funny, sounds a lot like deciding what to put in an initramfs. And frankly |
37 |
it's untrue[2]. Most of the core system utilities have long been intended to |
38 |
run people's systems. All you need to do is stop pretending "nu-skool" rubbish |
39 |
is as good as the stuff that's survived decades of use. By definition the |
40 |
latter is a much smaller pool of much higher-quality than the mountains of |
41 |
new unproven and untested stuff, that keeps falling over in real life. |
42 |
|
43 |
Exactly the same happened back then: we just don't see the admittedly smaller |
44 |
mountains of crap that fell by the wayside after a year or five. |
45 |
|
46 |
> initramfs is the new /, for varying values of new since most distros have |
47 |
> been doing it that way for well over a decade. |
48 |
|
49 |
Only it's not, since you're responsible for keeping it in sync with the main |
50 |
system. And for making sure it has everything you need. And hoping they don't |
51 |
change incompatibly between root and initramfs. |
52 |
|
53 |
The point is the burden has shifted, and made the distribution less of a |
54 |
distribution and more of a "DIY, and tough sh1t if it don't work, you get |
55 |
to pick up the pieces we broke" irrespective of how many scripts you provide |
56 |
to do work that was never needed before, and technically is not needed now[1] |
57 |
|
58 |
It will break. Everything does at some point or another. So I for one don't |
59 |
need the extra hassle from a totally unnecessary extra point of failure. |
60 |
|
61 |
Good luck to you if that's how you roll; just don't tell me what choices I |
62 |
should make, thanks. |
63 |
|
64 |
Regards, |
65 |
steveL. |
66 |
|
67 |
[1] http://forums.gentoo.org/viewtopic-t-901206.html |
68 |
[2] http://forums.gentoo.org/viewtopic-t-901206-start-75.html |
69 |
..shows how few things you actually need to move. Note portage is fine with |
70 |
the directory symlinks from /usr to / (I checked with zmedico before I wrote |
71 |
it up.) Also the bug in lvm initscript got fixed, but I still much prefer my |
72 |
machine to have the few extra MB in rootfs, and be able to chuckle at all |
73 |
the eleventy-eleven FUD about those 2 directories. |
74 |
|
75 |
-- |
76 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |