From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 181871381F3 for ; Tue, 1 Oct 2013 19:28:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2E1EEE0A00; Tue, 1 Oct 2013 19:28:22 +0000 (UTC) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 27814E0997 for ; Tue, 1 Oct 2013 19:28:20 +0000 (UTC) Received: by mail-vb0-f52.google.com with SMTP id f12so5036435vbg.39 for ; Tue, 01 Oct 2013 12:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+ZG2dzgYZ295cNkX7YivtdfikBPH93dVZ6TJnSd4s08=; b=nwfrXB8RZ1DcWt1lKb56g2iPKMv2SoRQfUAQ2cV2rzdhrzvNFAUbbQ0tB5WqcjoMEI uihNZTYAfil8pzckkMjztuulSpszDXnlAgXuPlCCHbZhb92z+akbPLxq7eW/YKZusxDX qPO3qizAYE6BSbU6DUMh1b4azbTbekkx+AOcFGPVQ95Yvss3zCUoSUGRg3bAlGqOW8dP Fh9bPAwCMAc6TVw+c0bCBL3Km8XuYjigkS8mbIKQDl+zdWGl9JAYyYu2KFJSqr/lZR7X iNqTvxI1knV8M4jOGiGOdT+2ZGGCwSPQK12KnTfHwYYsKJReSwxsxuv/snS/n7L++b0F 0fgg== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.221.32.133 with SMTP id sk5mr1775514vcb.27.1380655700199; Tue, 01 Oct 2013 12:28:20 -0700 (PDT) Received: by 10.52.98.196 with HTTP; Tue, 1 Oct 2013 12:28:20 -0700 (PDT) In-Reply-To: References: <5246079E.7090406@gmail.com> <524761B4.60805@gmail.com> <20130929052937.GA30380@waltdnes.org> <201309290925.06893.michaelkintzios@gmail.com> <5247E4C2.5040502@gmail.com> <52480720.7070704@googlemail.com> <52480902.9040305@gmail.com> <52481602.6020305@googlemail.com> <52484363.7020309@gmail.com> <52484F5F.5090408@googlemail.com> <52485652.4060308@gmail.com> <5248828F.1000802@gmail.com> <52489E78.7020804@gmail.com> <5248A3F6.2020801@gmail.com> <52491ABA.1060003@coolmail.se> Date: Wed, 2 Oct 2013 03:28:20 +0800 Message-ID: Subject: Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim From: Mark David Dumlao To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: cfd94dc6-3572-469f-8754-86aaf4e684f4 X-Archives-Hash: 0741b6855625c3ad97fef986b44eb2b4 On Wed, Oct 2, 2013 at 3:22 AM, Mark David Dumlao wrote: > On Mon, Sep 30, 2013 at 2:31 PM, pk 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