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

[Mark David Dumlao]

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.
-- 
This email is:    [ ] actionable   [ ] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [ ] none