On Wed, Oct 2, 2013 at 3:22 AM, Mark David Dumlao <madum...@gmail.com> wrote: > On Mon, Sep 30, 2013 at 2:31 PM, pk <pete...@coolmail.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
