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 2C4F81381F3 for ; Sat, 28 Sep 2013 22:41:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7EAC7E0DA4; Sat, 28 Sep 2013 22:41:16 +0000 (UTC) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 38101E0C6F for ; Sat, 28 Sep 2013 22:41:14 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id k14so4024250wgh.1 for ; Sat, 28 Sep 2013 15:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dLscTyNFR3cReDtd2tihvV86cARCREacd4VSM6mJdC8=; b=OkiU2gtqvDeph8cONXbRMqjCwBUknSLZ0RFT2EfIIvtfmc/VTYcZKh9yZ9+lJrvrmS pw4XlFGeQB7qZ13jjqaSTj5V1DRqS786/REBxmTuAF056t8kqX5UmaM7cyl5UEUSES0n +st9ifant78uOxw+neTWKDVoNqEw3ZToNRgOfS2zXHr5LtUmhWpPxlJLGHAD9/3B8smD E1CSM0Qhdl22vU2B3VrqDOujmlrgmPOt/gn70xCCVOTFDcJGBE6KoEzpi1RSYgZtd4Rj gj1lIamMo+8u/2v0WD+kTeXFkj8kfezGORy3WHuPejBIpBkPBWbiCgCsoD+/4sGiw3C7 6Ymw== X-Received: by 10.180.10.136 with SMTP id i8mr7829861wib.46.1380408073819; Sat, 28 Sep 2013 15:41:13 -0700 (PDT) Received: from [172.20.0.41] (196-210-126-33.dynamic.isadsl.co.za. [196.210.126.33]) by mx.google.com with ESMTPSA id e1sm10295961wij.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Sep 2013 15:41:13 -0700 (PDT) Message-ID: <524759FB.2090304@gmail.com> Date: Sun, 29 Sep 2013 00:36:43 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01 References: <20130927222109.GD23408@server> <5246079E.7090406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 65839958-4604-4d7b-ae68-010186e63f47 X-Archives-Hash: e59cc855f1424a18cccb5fc102858266 On 28/09/2013 22:58, Alon Bar-Lev wrote: > As far as I read, the problem is with bluetooth keyboards? and some > other devices and locales, which are minor for this decision of > removing supportability. Especially for servers and for most of > workstations. Most sane configuration can be supported with separate > /. > > And of course there is the hidden systemd agenda, which is what I > suspect had more impact. No, the problem is not bluetooth keyboards per se. That just happens to be a convenient example of the kind of problem anticipated. There is a tendency to use it as the only example, which reinforces the idea that BT keyboards are problem to be solved. The actual problem is better stated something like this: In the early stages of user-land setup (around the time when udev is getting it's act together), arbitrary code can run and that code can be in any arbitrary place, but there is no guarantee that that code is even accessible at the point when it is needed. The actual cause of this mess is the lack of standards on where to put stuff on Linux systems, and it forms a classic bootstrap problem. There has only ever been one way around that problem - define an exact entry point that is guaranteed to be in a specific state. For current userland this effectively means that everything that has traditionally been in bin, sbin and lib in / and /usr must be available as step 1. Technically, you could include /var/lib/ and maybe even /opt in there. but we can safely exclude those at this time as only a brain-dead moron would ever put init-critical code there. It's a fact of history that Linux packager and package devs have never managed to make up their minds where to put stuff. Just have a look at coreutils binaries - why are 60% of them in /usr? It's coreutils! And core isn't in the name because of a whim. So you have two choices: enforce a decent separation so that the problem doesn't happen, or enforce that all binaries are in one place where we can call it "the system". Every major OS out there does the latter, it's only Linux that tolerates this free for all wild wild west approach of stick anything anywhere and still expect it to work. Hint: it doesn't work. Duct-tape and bubblegum don't actually hold stuff together, no matter how much we try convince ourselves it does. This should actually have been done when MAKEDEV was phased out in favour of the now-defunct devfs, but it's never too late to fix design flaws that date back 30 years or more. So this brings us back to the essential technical problem that still needs to be solved on your machines: /usr needs to be available (and not only for BT keyboards) at the earliest possible opportunity - this is a technical constraint. To guarantee that, you need to either merge /usr with /, or use an initramfs to guarantee that /usr is available before anything else happens in userland. It *really* is that simple. If you have a better solution than my last two choices, then I am all ears. -- Alan McKinnon alan.mckinnon@gmail.com