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 1S7wVW-00020B-Ll for garchives@archives.gentoo.org; Wed, 14 Mar 2012 22:17:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3D047E0AEE; Wed, 14 Mar 2012 22:16:54 +0000 (UTC) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by pigeon.gentoo.org (Postfix) with ESMTP id 2B50CE08B5 for ; Wed, 14 Mar 2012 22:15:06 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=TvJkdUrh c=1 sm=0 a=xvUQ5II7JMRnhGkbsebX1A==:17 a=txVIi73YdL4A:10 a=1NhqCOXGNUoA:10 a=6WvLBrxrMboA:10 a=wPDyFdB5xvgA:10 a=Uxmo08gEHq4A:10 a=IkcTkHD0fZMA:10 a=QN-jTBhkAAAA:8 a=J0Tn2xNtAAAA:8 a=0tnYw7u1YLycyyQNbTwA:9 a=QEXdDO2ut3YA:10 a=9Pvay1Ymw5sA:10 a=1Ey5B3EzntkA:10 a=xvUQ5II7JMRnhGkbsebX1A==:117 X-Cloudmark-Score: 0 X-Originating-IP: 97.102.250.187 Received: from [97.102.250.187] ([97.102.250.187:42265] helo=basement.kutulu.org) by cdptpa-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id DA/85-17039-968116F4; Wed, 14 Mar 2012 22:15:05 +0000 Received: from localhost (basement.kutulu.org [127.0.0.1]) by basement.kutulu.org (Postfix) with ESMTP id 6D9977D801C for ; Wed, 14 Mar 2012 18:15:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at kutulu.org Received: from basement.kutulu.org ([127.0.0.1]) by localhost (basement.kutulu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 744e_9Ah9QXt for ; Wed, 14 Mar 2012 18:15:04 -0400 (EDT) Received: from MIKEDESKTOP (173.221.47.98.nw.nuvox.net [173.221.47.98]) by basement.kutulu.org (Postfix) with ESMTPSA id 8B8DC7D801B for ; Wed, 14 Mar 2012 18:15:04 -0400 (EDT) From: "Mike Edenfield" To: References: <4F5AC0F6.6000804@gmail.com> <4F5B33CA.2020705@coolmail.se> <20120310153540.5194cd7c@digimed.co.uk> <4F5BBE7A.8040802@coolmail.se> <4F5C724C.1010708@coolmail.se> <292166434.606817.1331577566543.JavaMail.open-xchange@email.1and1.com> <4F5E853F.8060404@gmail.com> <017301cd00bd$24bce2f0$6e36a8d0$@kutulu.org> <20120313091356.5a947032@khamul.example.com> <07ed01cd01fd$ea6c6b60$bf454220$@kutulu.org> In-Reply-To: Subject: RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts. Date: Wed, 14 Mar 2012 18:15:03 -0400 Message-ID: <005701cd022f$e8228fb0$b867af10$@kutulu.org> 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="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCnkx23NGc6DAJaFQnNFtgLhMpKUgHpGpoHAVuFT4wBiR8+FAH5aa0dAY5DF70CNpOpwQFwPn9mAjUaCP8CzguULgIfRpDcAfOkIbMBzcz8rwHKrDNLActl5ucDAYlZHQJRqVLXl7bmfxA= Content-Language: en-us X-Archives-Salt: 77bf9c33-6ee8-4695-bffa-45a819f81b1c X-Archives-Hash: 0215fdcd9eba2a02f942bb95cc6293c1 From: Pandu Poluan [mailto:pandu@poluan.info]=20 Sent: Wednesday, March 14, 2012 12:28 PM > This email [1] (and the correction email right afterwards) should give = some much-needed perspective on=20 > why we're driving full-speed toward an overturned manure truck (which = some of us, e.g., Walter and me, > are desperately pulling at the handbrakes). >[1] = http://lists.busybox.net/pipermail/busybox/2011-September/076713.html Actually, that email lost me in the second sentence (though I kept = reading): > It is incredibly biased > towards huge desktop systems and behemoth software Every machine I run Linux on is a huge desktop system running behemoth = software (Eclipse, GNOME, Chromium, LibreOffice, etc.). That's why it's = called a "free desktop system". The author of this email is clearly = baised *against* desktop systems running desktop environments, as well = as any other "highly dynamic" system that doesn't fit the model of a = simple server running Linux the way it ran 10 years ago. He seems to be = producing a rather vitriolic, and IMO uncalled-for, rant against the = simple fact that computers do more stuff in 2012 than they did in 1972 = and the udev developers are changing with the times. The reality is, the majority of people running Linux desktop systems = using big software packages want a desktop system that works out of the = box so they can just turn it on and get their work done. That is the = audience that udev is targeted for, and it is doing a perfectly good job = at meeting the needs of that audience. The fact that the largest major = distributions are currently using udev (with an initrd) successfully is = all the proof you need that it actually does work. The people who want or need a more specialized solution to this same = problem (dynamic device management), are generally also smart enough to = avoid using udev if they so choose. Again, the fact that, with merely a = few months of effort, a handful of users on this list have produced = exactly such a solution is all the proof I need that such a solution is = possible. I also know that I have no reason to use their solution = because the one I'm using now works just fine for me.=20 As to the email itself, I see two major technical flaws in the argument = as presented: First, the fundamental argument being made is that /usr should be = allowed to remain a separate partition, and that the "misinformed" = and/or "dishonest" and or "[lacking in] good engineering practices" = systemd team somehow wants to force everyone to put /usr and / together. = Except that's *absolutely not at all what they are proposing*. Their = proposal is precisely this: "the /usr partition contains binaries that = are needed on many modern desktop systems to properly populate the = device tree, and thus, the /usr partition must be available early enough = in the boot process for that to happen, and thus, we can move forward = with our software (udev) with the assumption that /usr will be available = when we need it." Second, the idea that the entire collective Fedora/Debian/etc teams = somehow made "a mistake" by "install[ing] critical software into /usr". = This argument falls flat when the author fails to identify what he or = she considers to be critical vs. non-critical software. Is bluetoothd = critical? On my laptop it is not. On my main development workstation it = is not. On my wife's desktop it is because she has a Bluetooth = keyboard/mouse combination. Should bluetoothd be moved from /usr/sbin to = /sbin? Along with libglib and libdbus, which it depends on? How about = usbmuxd, or alsactl? You could also argue, as some here have done, that these are not truly = "critical" software because those are not "critical" devices; but now, = you must teach udev to know the difference between "device that can be = added pre-mount" and "device that must wait until post-mount" on a = per-device-per-system-per-boot basis, since that designation may change = at any time. And recognize the difference between "device that failed = because something went horribly wrong and I should drop into rescue = mode" vs "device that failed because I tried too early and just need to = try again later." And provide a way for udev to create the devices it = can, pause while the rest of the filesystems come up, detect that the = rest of the filesystems are present, then go back and re-do the devices = that failed originally. All the while knowing that the solution of "just = make /usr available" is such an easy and reasonable answer 99% of the = time. I know which option I'd pick to spend my limited time and = resources on. There's no need to get mean-spirited about it. You are not "pulling at = the hand-brakes" of an out-of-control "manure truck". You are producing = one of many possible /perfectly valid/ alternative solutions to a = complex problem, one which meets your needs but does not meet mine, and = there is absolutely nothing wrong with that. --Mike