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

[Mark David Dumlao]

On Wed, Oct 2, 2013 at 3:22 AM, Mark David Dumlao <madumlao@×××××.com> wrote:
> On Mon, Sep 30, 2013 at 2:31 PM, pk <peterk2@××××××××.se> wrote:
>> On 2013-09-30 00:04, Alan McKinnon wrote:
>>
>>> 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. More and more we are
>>> seeing that this is no longer the case.
>>
>> So basically it wasn't broke before stuff started to use the code in
>> /usr. How isn't that breaking?
>>
>>> So no-one broke it with a specific commit. It has always been broken by
>>> design becuase it's a damn stupid idea that just happened to work by
>>> fluke. IT and computing is rife with this kind of error.
>>
>> If what you are saying is true then *everything* is broken "by design"
>> if something isn't available at boot time (may be /usr, may be /var or
>> whatever).
>
> Let me make an analogy between programs and recipes.
>
> You see, a program is a lot like a recipe. It's a set of instructions
> for a computer to follow. And if you have a recipe where if you follow
> it, and anyone that eats the food says it tastes good, then you have a
> good recipe.
>
> Let me make an analogy between a restaurant franchise and a
> distribution. You see, a franchise is a set of instructions for a
> restaurateur to follow. A lot of those instructions are recipes. They
> tell the restaurateur how to cook foods. But not all of those
> instructions are. Some of them are instructions on the ideal
> conditions to cook. Or some of them are instructions on how to get
> materials, or how to talk to customers, or how to keep employees
> happy. Now if you follow those instructions, and have the right
> resources, you get to create a restaurant. In the same way, a
> distribution can be thought of as a set of instructions. If you follow
> those instructions, and have the right resources, you get to install a
> lot of programs on a computer.
>
> If everybody that follows the instructions on a recipe creates a food
> that a lot of people think tastes great, then you have a great recipe.
> And if everybody that follows the instuctions on a franchise creates a
> restaurant that a lot of customers buy from and think the food is
> great, then you have a great franchise.
>
> Now let's say you have a franchise with very specific instructions to
> buy ingredients from the nearest organic store. Now for many
> restaurants that follow these instructions, they end up with great
> food that makes an okay amount of money. But in some cities the
> organic store doesn't have very good lettuce. Or the carrots are too
> expensive. Or there isn't any organic store at all, so the restaurant
> owner has to go to the next city and waste a lot of time and money to
> get eggs. So those restaurants fail. But for many restaurants the
> instructions work.
>
> Now the restaurant owners get together and complain that their
> restaurant isn't working. Why? they ask. It's because the head
> franchise added pizza to the menu! The menu was working fine without
> the pizza, but when they added pizza it became to expensive or
> impractical to turn a profit. They might say that the franchise was
> broken by the pizza. But many restaurant owners do fine by pizza. In
> fact for many of them it's their hottest and most profitable product.
>
> You see, the problem isn't the inclusion of a specific recipe. The
> addition of pizza didn't break the restaurant. Nor did the addition of
> burgers, or coke, or fries or whatever. The problem was with
> instructions on how to manage the recipe ingredients. In short, while
> they were practical for a lot of restaurant owners, they weren't
> practical _in general_. The instructions could be better improved by
> saying something like "buy ingredients from stores that give you this
> much return," or "buy ingredients from our approved suppliers since
> they give the best return on your money". If those instructions were
> given instead of just vaguely saying to purchase from an organic
> store, they'd have better control over the quality and profitability
> of the restaurants.
>
> And this is something like what is wrong with /usr. The individual
> programs may be good. Many parts of the system taken together may be
> good. But the instructions on how to manage programs going to /usr or
> to / is too vague. There is no definitive quality control behind it.
> Even if you follow the instructions, as best as you can, you will end
> up making stupid decisions for the distribution.
>
> Likewise with the franchise restaurants. The individual foods may be
> good. Many of the instructions on managing people, foods, customers,
> may be good.  But the whole concept of "purchase from some a supplier
> with undefined levels of cost and quality" is NOT a good instruction.
> Maybe that works for a lot of restaurants, but as a general rule it
> doesn't work for all of them. If you follow it to the letter, you will
> end up making stupid decisions for the restaurant.
>
> And here's your problem. The franchise instructions aren't supposed to
> just "work for a lot of restaurants". They're supposed to work for all
> of them. Likewise with the distribution. the distribution packages,
> rules, settings, etc, aren't supposed to be tailored for your own
> personal setup. They're supposed to work for anybody for whom the
> distribution is a target.
>
> You might want to say that maybe udev, or maybe this driver, or maybe
> this service, or that hardware breaks FHS and therefore Gentoo. But
> that's the wrong way of looking at it. when the important parts of
> something being boot critical depends on the system.

Sorry, again I pressed something and sent too early.

In the same way, the important parts of "purchase from the nearest
organic store" depends on the store. Since it's too vague a
requirement, different restaurants will end up with different results.
Because of that, you can't predict when a new recipe with different
ingredients will make the restaurant unprofitable.

Same with /usr. Different systems will end up with different
requirements of stuff in /usr. Because of that, you can't predict when
a new program with different requirements will be placed in an
inappropriate location.

/ and /usr being separated, without appropriate tools to handle
migration between the two, is bound to break stuff.
-- 
This email is:    [ ] actionable   [x] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none