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 0AA171381F3 for ; Mon, 19 Nov 2012 16:33:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6244521C065; Mon, 19 Nov 2012 16:32:51 +0000 (UTC) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 44BB121C062 for ; Mon, 19 Nov 2012 16:32:15 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id h8so3514400iaa.40 for ; Mon, 19 Nov 2012 08:32:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=KGusk/doH5uRiSflBhDBIpE2e32XJdIVS6Uw3DtAEO8=; b=C3/ravYiVyY/sboG8e1HALXpn7uhenqBC6Z96y94lCNbEsu0UFFsJNbaEvaQEkGsQ8 UtEgu+Osp0jC5rQvMPkHiS2oLXh8ewBFhwtRN3eYdOmqgsj9YDAkmMGYh3XxCoCdea57 uXAk1QaZUnm4bDFA+KIDOEO+7iobSV5u2v1p/ft2OUZg5UbX9uLpP8EeibrPAa3U7+Um 6+8ndObuQks7XujSfnHEHbZ9/RRGuLkkzm5Iz+XMUr09hvTVgzklKwzMVsEz/0YedmAt sQgJzk0fwH3E2I6pZETwcFBWp6Y5jKh5M0XvHih3GUZ9u0bVAtnHHqnmHRyDUI9bp6/a 4cCg== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.50.152.231 with SMTP id vb7mr7252209igb.1.1353342734369; Mon, 19 Nov 2012 08:32:14 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.64.23.114 with HTTP; Mon, 19 Nov 2012 08:32:14 -0800 (PST) In-Reply-To: <20121119130756.GA4454@rathaus.eclipse.co.uk> References: <20120509183203.GA27545@kroah.com> <4bdd949a377d40eb85590870be440551@HUBCAS1.cs.stonybrook.edu> <50A8943E.7070607@gentoo.org> <20121118080845.GA8628@kroah.com> <50A89A73.3050709@flameeyes.eu> <50A8C257.7060103@mva.name> <50A8F918.2010802@flameeyes.eu> <50A8FBC2.200@gentoo.org> <20121119130756.GA4454@rathaus.eclipse.co.uk> Date: Mon, 19 Nov 2012 08:32:14 -0800 X-Google-Sender-Auth: cuBosrLPfwG92FDjzZVXyjbBqjY Message-ID: Subject: Re: [gentoo-dev] Re: Tightly-coupled core distro From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnZ4mEhlKanDfk/yhxVIudMZGuOSaeBpKW4jEOCVx3au0vreJ4XHCc8e2L3+mysPmEp3rga X-Archives-Salt: 758dc815-5332-4916-898b-872428f05fa1 X-Archives-Hash: 71c5101fcdc943c95c799f8337686a60 On Mon, Nov 19, 2012 at 5:07 AM, Steven J. Long wrote: > On Sun, Nov 18, 2012 at 05:16:18PM +0200, Samuli Suominen wrote: >> I'm still happy enough with building udev out from systemd tree and >> letting sep. /usr consept from 90s to finally die in favour of >> simplifying the system. > > It's from a lot earlier than the 90s. Perhaps we should get rid of pipes, > too- they're /so/ 1970s. > > Torvalds expressed it well[1]: > You made the statement that you want to get away from 30 years of > history, but the fact is, "30 years of history" is a damn good argument > for "that thing worked". > >> The BIOSes have been upgraded last century to support booting from >> larger partitions, the need has long past. >> Nobody has ever provided a valid reason for using sep. /usr in the ML >> either. >> > So at the same time as you have never heard a valid reason, the need (which > you have never understood) is long past? Pfft. > > To reiterate again: many of us are used to keeping /usr on a separate > partition for security and backup purposes (other use-cases for a separate > partition include mounting /usr over NFS, or a common partition for > virtual machines.) I'm sure other people would have more. Irrespective, > it should be about mechanism, not policy, and certainly not about breaking > existing setups. > > Many of the advertised benefits of the "merge /bin and /sbin to /usr" > concept are in fact just benefits of having a separate /usr partition, > though of course they're presented as new and unique to the merge. So, if > you accept those as benefits, you cannot logically deny them as benefits of > a traditional /usr split. > > Further, as one user pointed out[2]: > "I'd be more likely to just stick /usr back on / than create an initramfs > - it was only because the LVM guide recommended that /usr go on its own > partition that I now face this situation." > > We were given a simple requirement ages ago: udev requires /usr and > /var (and going forward may require /opt for 3rd party drivers) mounted > before it starts, not for udev itself but for helper scripts that it may > call. Why get bogged down in anything else? > > The recommended (which became "supported") method to do this was > to use an initramfs, since apparently any chicken-and-egg problems (such > as requiring a udev-initiated device to mount /usr) are easier to handle > there. (Note that no-one has ever provided a description of how they did > that, eg for their bluetooth keyboard, so that the issues, and how they > are addressed, could be made more transparent to everyone.) > > A few us are happily running initramfs-less machines by fulfilling the > requirement with a couple of patches to openrc initscripts[2]. (It's > been working fine here since last August.) This works in the case where > you didn't need an initramfs before, ie have modules for local-disks and > filesystems built-in, root not on LVM or encrypted, but other partitions > might be-- which includes LVM users who followed the Gentoo docs. > > If that's not enough, there is *already* a forked udev version which quite > a few users have been using[3] and reporting success with. I'd hope the > new fork would just collaborate with them, but it's entirely up to them > what they do. > > All of this argues that, irrespective of your views of the layouts admins > prefer to use, they will still use them regardless, and indeed users will > put in the work you yourself told them to.[4] I really don't understand > why people are getting beat up on, just for going ahead and doing what > they've been told to: provide code for an alternative. > > If a Gentoo developer doesn't understand what a Gentoo project means, > that's his problem. Nor should Gentoo projects suddenly change what they > are because "the internet" doesn't understand them. That's a ridiculous > basis for any change. > > The thing none of the proponents of an initramfs, with no other support > for a separate /usr (apart from busybox sep /usr which does NOT fulfil the > requirements presented by Chainsaw, which Council voted to approve before: > for a start it doesn't handle /usr on LVM), have ever answered is: > > How do you deal with the mismatch problem? > > That is, when you have programs or libs upgraded, just as part of normal > system upgrades, and they are now different, potentially incompatible, to > the initramfs. (The potential exists, therefore it must be addressed for > a solution even to be considered as robust.) > > Do you now need another script to run after every emerge to check that > files in your initramfs are in sync? After all, we've been told the > initramfs is "the new root": iow that we should think of it as our rescue > system, so this matters. Debian / Ubuntu have a tool that basically does this. Its update-initramfs. I believe it is called from..the postinst of packages that are supposed to be in the initramfs? honestly I'd have to look up how they implemented it. -A > > At the same time, we've been told "it's only a few hundred kilobytes at > most." That contradiction has never been answered, either. > > [1] http://lwn.net/Articles/492134/ > [2] http://forums.gentoo.org/viewtopic-t-901206.html > [3] http://forums.gentoo.org/viewtopic-t-934678.html > [4] http://forums.gentoo.org/viewtopic-p-6987380.html#6987380 > -- > #friendly-coders -- We're friendly, but we're not /that/ friendly ;-) >