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 1S7H4s-0002Xc-4B for garchives@archives.gentoo.org; Tue, 13 Mar 2012 02:03:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 99292E0BD9; Tue, 13 Mar 2012 02:02:53 +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 549B8E0B9B for ; Tue, 13 Mar 2012 02:01:02 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=FOSZNpUs c=1 sm=0 a=xvUQ5II7JMRnhGkbsebX1A==:17 a=txVIi73YdL4A:10 a=1NhqCOXGNUoA:10 a=6WvLBrxrMboA:10 a=wPDyFdB5xvgA:10 a=LfqMiUf45yUA:10 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=eAfmsCWY3Pfbi7mMFY4A:9 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A: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:39833] helo=basement.kutulu.org) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id F6/E6-21438-D5AAE5F4; Tue, 13 Mar 2012 02:01:01 +0000 Received: from localhost (basement.kutulu.org [127.0.0.1]) by basement.kutulu.org (Postfix) with ESMTP id 258227D8002 for ; Mon, 12 Mar 2012 22:01:01 -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 Hcq75LSE7rAj for ; Mon, 12 Mar 2012 22:00:58 -0400 (EDT) Received: from PORPOISE (PORPOISE.kutulu.org [192.168.69.91]) by basement.kutulu.org (Postfix) with ESMTPSA id A78877D8001 for ; Mon, 12 Mar 2012 22:00:58 -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> In-Reply-To: <4F5E853F.8060404@gmail.com> Subject: RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts. Date: Mon, 12 Mar 2012 21:58:58 -0400 Message-ID: <017301cd00bd$24bce2f0$6e36a8d0$@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+FAH5aa0dAY5DF70CNpOpwQFwPn9mAjUaCP8CzguULgIfRpDcAfOkIbOYCb0f4A== Content-Language: en-us X-Archives-Salt: fe922abc-154f-4692-8052-a8f06ed1358c X-Archives-Hash: e1dbaa8eba822786befd21cbc3b1a2a3 From: Dale [mailto:rdalek1967@gmail.com] Sent: Monday, March 12, 2012 7:23 PM > I like that quote. I may not be dev material but I know this /usr = mess > is not right. The only reason it is happening is because of one or = two > distros that push it to make it easier for themselves. If that's honestly what you think then I suspect you don't understand = the problem as well as you believe. The idea of trying to launch udevd and initialize devices without the = software, installed in /usr, which is required by those devices is a = configuration that causes problems in many real-world, practical = situations. The requirement of having /usr on the same partition as / is also a = configuration that causes problems in many real-world, practical = situations. The requirement to ensure that /usr is *somehow available* before = launching udevd is a configuration that, I am told, causes problems in = some specialized real-world, practical situations. (I am ignoring = "problems" such as "initramd might possibly break maybe" or "that's more = work than I want to do" as being the expected griping that always = happens when you ask a group of geeks to change something.) It is impossible for udev to solve the problem for all users in all = configuration. Given the three readily available options, the one that = makes the most sense from a software engineering standpoint is to choose = option three, thus ensuring that your solution pisses off the smallest = subset of users. Those users are then free to create a solution that = better suits their needs, such as replacing udev with different software = which made a different choice. To call one option a "mess" that is "not right" is both an unrealistic = oversimplification of a complex problem and utterly unfair to the people = trying to solve that problem. --Mike