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 A5D5C1381F3 for ; Wed, 19 Dec 2012 09:31:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9F7C21C02C; Wed, 19 Dec 2012 09:31:09 +0000 (UTC) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A4A8921C004 for ; Wed, 19 Dec 2012 09:29:46 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id d4so854744eek.24 for ; Wed, 19 Dec 2012 01:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:message-id:in-reply-to:references :organization:x-mailer:mime-version:content-type :content-transfer-encoding; bh=lN9M0OtjLbjzP3ipiaTjB3EOYobEaQvEy9Olb9cnqtI=; b=k14X49+2NwfZpuW8BCa/hIH3feG3zjm+8rf2q4IbqYx63Y6GRCr+ELThHpDSbCbvzx enudnkpL4Gqapcr3IlX7oR3NBp63H6DlleBXYtwNbvG6AkQEkJlLbJO/HvfKPtv4l0ek EvK4SrR3xQyj+4wFBKbeTi8p+kM9vg5jhps769lOi0628R3xq5U+ZwiCm8XqGe70qxaL nQMgpqnDDzPieBW8x/QuGeqddEc2V1N944iKly5+JoEVB5e2osgKGX4uPwy2WDpmQXK0 imR7itJmbStsSZzZbcwjDtt2A+4HnVh5R1MsH1S2tJcXa2RKiyIJWU/90JN+pmg1xsnU fuyA== X-Received: by 10.14.221.5 with SMTP id q5mr12745333eep.33.1355909385257; Wed, 19 Dec 2012 01:29:45 -0800 (PST) Received: from khamul.example.com (196-215-209-117.dynamic.isadsl.co.za. [196.215.209.117]) by mx.google.com with ESMTPS id b49sm8140323eem.16.2012.12.19.01.29.42 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 01:29:44 -0800 (PST) Date: Wed, 19 Dec 2012 11:26:07 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? Message-ID: <20121219112607.5f1b8f31@khamul.example.com> In-Reply-To: References: <50CB1942.3020900@gmail.com> <50CB4A3C.1030109@gmail.com> <50CB5406.7040404@gmail.com> <8738z7hgsa.fsf@ist.utl.pt> <20121216171043.71084070@khamul.example.com> <20121217104621.735bf43a@khamul.example.com> <20121218163332.7956f31a@khamul.example.com> Organization: Internet Solutions X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.14; x86_64-pc-linux-gnu) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 9ee62da6-c41a-45d2-97e2-af4eb5d5f66d X-Archives-Hash: e1c0e45e7efca439a01f6eb3d7b04669 On Tue, 18 Dec 2012 17:55:16 -0500 Michael Mol wrote: > On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon > wrote: > > On Tue, 18 Dec 2012 09:08:53 -0500 > > Michael Mol wrote: > > > > > > This sentence summarizes my understanding of your post nicely: > > > >> Now, why is /usr special? It's because it contains executable code > >> the system might require while launching. > > > > Now there are only two approaches that could solve that problem: > > > > 1. Avoid it entirely > > 2. Deal with it using any of a variety of bootstrap techniques > > > > #1 is handled by policy, whereby any code the system might require > > while launching is not in /usr. > > This is the solution I favor. Systemic structure which allows > dependency leakage is indicative (to me) of lack of foresight and > proper component role limitation, and ought to be fought. > > > > > #2 already has a solution, it's called an init*. Other solutions > > exist but none are as elegant as a throwaway temporary filesystem > > in RAM. > > I find virtually nothing elegant about a temporary filesystem in RAM. > It duplicates code that already exists on the system, and it > represents and additional maintenance step in system upgrades. It > seems almost a given that if someone is keeping multiple kernel images > on a system, they're not updating the initr* for each when binaries > that would be found in each are upgraded or rebuilt. You could level the same criticism at boot loaders... The also duplicate functionality in the main system they launch (albeit read-only at least in legacy grub) in the fs drivers, are only used briefly at boot-time and have to be maintained. True, the bootloader doesn't contain a *copy* of the main system files which is where the parallel breaks down. init* may well suck, but they suck less than any other possible solution. And they come with one more benefit - the community has agreed on how they work so they form a standard of sorts > > In Debian, Ubuntu and others, this is handled by a post-install hook > where the initr* image is rebuilt. To me, this honestly feels like a > hack. In something like Gentoo, I'd rather see package placement > driven by whether or not it will be needed to get all mount points > mounted. If that means i18n databases under something like /boot/data, > that seems reasonable. To me, the only cases where initr* feels like > the right solution are things like netboot or booting from read-only > media. Let's not forget the prime reason why init* exists - so that binary distros can boot and still have all kernel modules required at launch time compiled as modules. Bootstrap code and operation is ugly, always has been and always will be. It also tends to be inflexible unless you use a slipstreaming technique (my invented description of how init* works). I still think the solution is elegant given the real-world requirements imposed on systems. > > > > > I should be clear that I do not necessarily support Lennart's > > solutions, but I do support his perception of the problem (at least > > partially). We cannot support situations where *launch* code is > > haphazardly scattered in location X and this must always work for > > all values of X. We already have a remarkably parallel situation > > in /boot - in order to boot at all, the code running at that point > > in time needs to be able to find stuff, and it finds it (by policy) > > in what we will later call /boot. I see this /usr debate as the > > same thing on a larger scale. > > -- > :wq > -- Alan McKinnon alan.mckinnon@gmail.com