From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Roiao-0005pY-Hb for garchives@archives.gentoo.org; Sat, 21 Jan 2012 21:35:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 81C95E095D; Sat, 21 Jan 2012 21:35:13 +0000 (UTC) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by pigeon.gentoo.org (Postfix) with ESMTP id F1DBEE06B5 for ; Sat, 21 Jan 2012 21:34:42 +0000 (UTC) Received: by ggnk1 with SMTP id k1so136446ggn.40 for ; Sat, 21 Jan 2012 13:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=MjYKaPk/Kj49jyX0FHr98ca4a9WsF701lTQLhqVM4uk=; b=QtPiuYWcNg3QTdbzQb2xLaMP19jkMC/6WDaqD993SSHkq5pf4mOGpRVA50DL/re/VV JcypdP5rfXRE8Q4JqueItJ5I6R+n7IQZmbXuzSZWDMTM/X/AcKWi1y6hCcOAw0lYE2NF 8lqMaFkjQHrLcWl0bpnYFJnCkYQVtE+KpDZVU= Received: by 10.236.77.72 with SMTP id c48mr4328248yhe.55.1327181682512; Sat, 21 Jan 2012 13:34:42 -0800 (PST) Received: from [192.168.2.5] (adsl-98-95-147-47.jan.bellsouth.net. [98.95.147.47]) by mx.google.com with ESMTPS id r34sm2863960yhe.1.2012.01.21.13.34.40 (version=SSLv3 cipher=OTHER); Sat, 21 Jan 2012 13:34:41 -0800 (PST) Message-ID: <4F1B2F6F.6020301@gmail.com> Date: Sat, 21 Jan 2012 15:34:39 -0600 From: Dale User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20120120 Firefox/9.0.1 SeaMonkey/2.6.1 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: locations of binaries and separate /usr References: <4F0440B3.4090500@gentoo.org> <20120106160719.GB18959@fury> <201201080047.27281.polynomial-c@gentoo.org> <20120108103345.382b8db3@pomiocik.lan> <20120110181452.GA14155@mailgate.onlinehome-server.info> <20120110194640.7696d2c7@pomiocik.lan> <4F163EB2.8050700@gmail.com> <20120118080213.4f533693@pomiocik.lan> <4F1672A3.2040802@gmail.com> <20120118143613.4d9d67a8@pomiocik.lan> <4F1AAF86.1050503@gmail.com> <20120121155744.4f7cf423@pomiocik.lan> In-Reply-To: <20120121155744.4f7cf423@pomiocik.lan> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: fb1708f4-77af-49ce-b56c-6964cb0e63bc X-Archives-Hash: 1ea65d72864071cc88998900e5a9a56f Micha=C5=82 G=C3=B3rny wrote: > On Sat, 21 Jan 2012 06:28:54 -0600 > Dale wrote: >=20 >> Micha=C5=82 G=C3=B3rny wrote: >>> On Wed, 18 Jan 2012 01:20:03 -0600 >>> Dale wrote: >>> >>>> Micha=C5=82 G=C3=B3rny wrote: >>>>> On Tue, 17 Jan 2012 21:38:26 -0600 >>>>> Dale wrote: >>>>> >>>>>> Micha=C5=82 G=C3=B3rny wrote: >>>>>>> On Tue, 10 Jan 2012 19:14:52 +0100 >>>>>>> Enrico Weigelt wrote: >>>>>>> >>>>>>>> * Micha?? G=C3=B3rny schrieb: >>>>>>>> >>>>>>>>> Does working hard involve compiling even more packages >>>>>>>>> statically? >>>>>>>> I guess, he means keeping udev in / ? >>>>>>> Because adding 80 KiB of initramfs hurts so much? We should then >>>>>>> put more work just to ensure that admin doesn't have to waste 15 >>>>>>> minutes to recompile the kernel (if necessary), create an >>>>>>> initramfs and add it to bootloader config? >>>>>>> >>>>>> 80Kbs? You sure about that? I somehow failed to mention this >>>>>> before. I noticed it when I saw another reply to this post. >>>>>> Reality check: >>>>> 80 KiB is enough for mounting plain /usr and booting with it. See >>>>> tiny-initramfs (but I haven't tested it thoroughly). >>>>> >>>> >>>> My plan is to have /usr on lvm. I think it will end up larger and >>>> it still adds one more thing to break. >>>> >>>> I really wish someone would get a better plan. I think I see a >>>> garbage dump ahead with lots of Linux distros headed that way. >>> >>> Better plan how? LVM requires udev for some reason. Letting rootfs >>> grow with data unnecessary for a number of users is no good plan >>> either. Just install that initramfs, be done with it and let us >>> focus on actual work rather than fixing random breakages. >>> >>> We already usually have separate /boot to satisfy the needs of >>> bootloader. Then you want us to chain yet another filesystem to >>> satisfy the needs of another layer. Initramfs reuses /boot for that. >>> >> >> >> The point is, I don't like initramfs. I don't want to use one. >=20 > And I don't like binaries on rootfs. I don't want to have ones. >=20 > So we're talking about taste... Actually, we're talking about how things has worked so well for a VERY long time and there is no need to reinvent the wheel. >=20 >> It's funny how I never needed one before either but now things are >> being broken. It's not LVM that is breaking it either. I wouldn't >> need the initramfs even if It was on a regular partition until the >> recent so called "improvements." >=20 > ...and your main argument is 'long, long ago someone decided that it > should match the same taste as mine, so it should be like it forever'. > Of course, those times there were no such thing as an initramfs... >=20 Then don't break that. Just because someone came up with a initramfs doesn't mean everyone should be forced to use one. Dale :-) :-) --=20 I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=3D"--quiet-build=3Dn"