| 1 |
On Mon, 24 Dec 2012 06:58:15 -0600 |
| 2 |
Dale <rdalek1967@×××××.com> wrote: |
| 3 |
|
| 4 |
> So, Nuno, everything was fine until they started moving things to a |
| 5 |
> place where it shouldn't be. |
| 6 |
|
| 7 |
No Dale, that is just flat out wrong. |
| 8 |
|
| 9 |
There is no such thing as "place where stuff should be". There are only |
| 10 |
conventions, and like all conventions, rituals, fashions and traditions |
| 11 |
these are prone to breakage when things move on. Things move on because |
| 12 |
they become way more complex than the designer of the convention thought |
| 13 |
they would (or could). |
| 14 |
|
| 15 |
The truth is simply this (derived from empirical observation): |
| 16 |
|
| 17 |
Long ago we had established conventions about / and /usr; mostly |
| 18 |
because the few sysadmins around agreed on some things. In those days |
| 19 |
there was no concept of a packager or maintainer, there was only a |
| 20 |
sysadmin. This person was a lot like me - he decided and if you didn't |
| 21 |
like it that was tough. So things stayed as they were for a very long |
| 22 |
time. |
| 23 |
|
| 24 |
Thankfully, it is not like that anymore and the distinction between |
| 25 |
/ and /usr is now so blurry there might as well not be a distinction. |
| 26 |
Which is good as the distinction wasn't exactly a good thing from day |
| 27 |
1 either - it was useful for terminal servers (only by convention) and |
| 28 |
let the sysadmin keep his treasured uptime (which only proves he isn't |
| 29 |
doing kernel maintenance...) |
| 30 |
|
| 31 |
I'm sorry you bought into the crap about / and /usr that people of my |
| 32 |
ilk foisted on you, but the time for that is past, and things move on. |
| 33 |
If there is to be a convention, there can be only one that makes any |
| 34 |
sense: |
| 35 |
|
| 36 |
/ and /usr are essentially the same, so put your stuff anywhere you |
| 37 |
want it to be. ironically this no gives you the ultimate in choice, not |
| 38 |
the false one you had for years. So if your /usr is say 8G, then |
| 39 |
enlarge / bu that amount, move /usr over and retain all your mount |
| 40 |
points as the were. Now for the foreseeable future anything you might |
| 41 |
want to hotplug at launch time stands a very good chance of working as |
| 42 |
expected. |
| 43 |
|
| 44 |
You will only need an initrd if you have / on striped RAID or LVM or |
| 45 |
similar, but that is a boot strap problem not a /usr problem (and you |
| 46 |
do not have such a setup). Right now you need an initrd anyway to boot |
| 47 |
such setups. |
| 48 |
|
| 49 |
The design of separate / and /usr on modern machines IS broken by |
| 50 |
design. It is fragile and causes problems in the large case. This |
| 51 |
doesn't mean YOUR system is broken and won't boot, it means it causes |
| 52 |
unnecessary hassle in the whole ecosystem, and the fix is to change |
| 53 |
behaviour and layout to something more appropriate to what we have |
| 54 |
today. |
| 55 |
|
| 56 |
-- |
| 57 |
Alan McKinnon |
| 58 |
alan.mckinnon@×××××.com |
Archives