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 1RF1EI-0008Gq-Og for garchives@archives.gentoo.org; Sat, 15 Oct 2011 10:12:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2391021C20A; Sat, 15 Oct 2011 10:12:26 +0000 (UTC) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 3923C21C219 for ; Sat, 15 Oct 2011 10:10:37 +0000 (UTC) Received: by wyf19 with SMTP id 19so4562023wyf.40 for ; Sat, 15 Oct 2011 03:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=uAnCShVyG2K4+HwCO8SmwGapSYPr2eo2muuJVyRIsvA=; b=YytGg2y5dV0p5Gp3Ena7vjk3ILcqODOtU0zfHFDQC0CV/uixqNlrbsybw2JdZLn7Ta PcDXjm5FKaeNay6SKw7heGePTZjDBVTIALV1vcSy7DPUSBXBXNU/CPvnEpW47pa8RfQO kyh9ik8A0ASQBygGpfylTe0Pwi2q9uZ5QgOC8= 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 Received: by 10.216.9.201 with SMTP id 51mr3907613wet.94.1318673437381; Sat, 15 Oct 2011 03:10:37 -0700 (PDT) Received: by 10.216.234.130 with HTTP; Sat, 15 Oct 2011 03:10:37 -0700 (PDT) In-Reply-To: <20111015105310.694b2e2c@digimed.co.uk> References: <4E98601C.3030607@gmail.com> <20111014224110.7acaf5b3@digimed.co.uk> <4E98BBE4.6040306@gmail.com> <4E992E82.5010103@gmail.com> <20111015105310.694b2e2c@digimed.co.uk> Date: Sat, 15 Oct 2011 03:10:37 -0700 Message-ID: Subject: Re: [gentoo-user] Apologize to everyone for my nonprofessional From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: dfdb1caba36c8c159d81e355f97b4987 On Sat, Oct 15, 2011 at 2:53 AM, Neil Bothwick wrote: > On Sat, 15 Oct 2011 00:34:10 -0700, Canek Pel=C3=A1ez Vald=C3=A9s wrote: > >> /var !=3D /var/run >> /var !=3D /var/lock >> >> /var/run is going in /run, but /var/run (by definition) only contains >> things like PID files and runtime sockets. In the same vein, /var/lock >> also is going into /run/lock. I have acknowledged this from the very >> beginning, and I have been pointing out that implying that because >> those two (really small and bounded) directories of /var are going >> into /run and /run/lock, > > Putting the contents of /var/run and /var/lock on the root filesystem > makes sense. > >> Nobody has even proposed that /var should go into the same partition >> as /. *Nobody*, and the simplest proof of that is that nobody has >> produced a single proof to the contrary. Not a single email, blog >> post, or wiki entry from any system developer even mentions the >> possibility of requiring /var to be in the same partition as /. > > The stated reason for requiring /usr on / is that udev can run > *arbitrary* scripts and commands. If they are arbitrary, they could > require access to anywhere, including /var or /home. That's the problem > with this approach. Instead of saying "it can run stuff from anywhere, so > anywhere must be mounted before udev is run" the fact that it is trying > to run these arbitrary commands before filesystems are mounted should be > addressed. With an initramfs you can have everything mounted by udev execution time. But forget about that. It's arbitrary (basically) on executables and libraries. If an script needs something more (from /var, lets say), then the rule should be written in such a way that it can be called after that directory is mounted. If you try to put the same restriction with *executables* (not data, like in the ALSA case), then you need to start moving every executable to /, because that's the only way to guarantee that it would be available aearly on boot time (if you don't use an initramfs and have /usr separated). That sucks. /bin and /lib were the original hack, for this very reason: some executables were needed early at boot time, and they put them there so they were available. The initramfs solves this problem; at some point, /bin /lib and /sbin will no longer be necessary. So yeah, the udev rules can execute arbitrary code, but the should not run stupid code. There is a difference. >> Whoever says that /var will be required to be on the same partition as >> / is either wildly speculating, or spreading FUD. > > It's not wild speculation, it is logical extrapolation of the current > approach. You don't have enough data to extrapolate. >> It basically removes the need for a "pesky init* thingy", although for >> the life of me I cannot understand why someone will not see the >> technical advantages of actually using an initramfs. > > We understand its advantages in some circumstances, but =C2=A0I cannot > understand why someone will not see the technical disadvantages of > actually using an initramfs. Care to explain? Regards. --=20 Canek Pel=C3=A1ez Vald=C3=A9s Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n Universidad Nacional Aut=C3=B3noma de M=C3=A9xico