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 <gentoo-user+bounces-136202-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1S7Jmg-0004Aa-IJ
for garchives@archives.gentoo.org; Tue, 13 Mar 2012 04:56:30 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id C29FEE0B87;
Tue, 13 Mar 2012 04:56:13 +0000 (UTC)
Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212])
by pigeon.gentoo.org (Postfix) with ESMTP id 7A04CE0ABF
for <gentoo-user@lists.gentoo.org>; Tue, 13 Mar 2012 04:55:05 +0000 (UTC)
Received: from mail-vx0-f181.google.com ([209.85.220.181])
by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128)
(Exim 4.69)
(envelope-from <pandu@poluan.info>)
id 1S7JlI-002wkT-UU
for gentoo-user@lists.gentoo.org; Tue, 13 Mar 2012 11:55:05 +0700
Received: by vcge1 with SMTP id e1so228794vcg.40
for <gentoo-user@lists.gentoo.org>; Mon, 12 Mar 2012 21:54:58 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.52.17.82 with SMTP id m18mr16176935vdd.89.1331614498708; Mon,
12 Mar 2012 21:54:58 -0700 (PDT)
Received: by 10.220.58.200 with HTTP; Mon, 12 Mar 2012 21:54:58 -0700 (PDT)
Received: by 10.220.58.200 with HTTP; Mon, 12 Mar 2012 21:54:58 -0700 (PDT)
In-Reply-To: <017301cd00bd$24bce2f0$6e36a8d0$@kutulu.org>
References: <4F5AC0F6.6000804@gmail.com>
<4F5B33CA.2020705@coolmail.se>
<20120310153540.5194cd7c@digimed.co.uk>
<4F5BBE7A.8040802@coolmail.se>
<CADPrc83RO5rE0j8cZtkFK32TzQc4Fg2=oHMGj+5XbZ-fec-_Wg@mail.gmail.com>
<4F5C724C.1010708@coolmail.se>
<CAMgZwF3aHqhqgJZKV6eBWEfLP83mPKS4nPAuLQGJ-mERyAMn=Q@mail.gmail.com>
<jjj3n3$sen$1@dough.gmane.org>
<CAMgZwF2PUjug-Uxmf0YKGvtJVMCTC9zXm4S3vzudS5NzE1xNZg@mail.gmail.com>
<CA+czFiDxEWmvXjsvi0ViTd3teVYjFC633m4MN1eNDV=5O2DmwQ@mail.gmail.com>
<292166434.606817.1331577566543.JavaMail.open-xchange@email.1and1.com>
<4F5E853F.8060404@gmail.com>
<017301cd00bd$24bce2f0$6e36a8d0$@kutulu.org>
Date: Tue, 13 Mar 2012 11:54:58 +0700
Message-ID: <CAA2qdGVtsZ2m_2tA2F==3r5gpk3XjirB5f_ptH08=p-uB7taBg@mail.gmail.com>
Subject: RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
From: Pandu Poluan <pandu@poluan.info>
To: gentoo-user@lists.gentoo.org
Content-Type: multipart/alternative; boundary=bcaec50405d62c5e5e04bb18a961
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com
X-AntiAbuse: Original Domain - lists.gentoo.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - poluan.info
X-Archives-Salt: 713de6a7-f4f4-4151-acac-536da364d205
X-Archives-Hash: bcf50a9eea0ddb1329da4d9cd4f970f2
--bcaec50405d62c5e5e04bb18a961
Content-Type: text/plain; charset=UTF-8
On Mar 13, 2012 9:05 AM, "Mike Edenfield" <kutulu@kutulu.org> wrote:
>
> 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.
>
I quite often read about this, and after some thinking, I have to ask: why?
> 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.)
>
When one's handling enterprise servers, "might possibly break" is a 95%
certainty of "you do that and I'll make sure to have a pink slip standing
by." :-)
Rgds,
--bcaec50405d62c5e5e04bb18a961
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p><br>
On Mar 13, 2012 9:05 AM, "Mike Edenfield" <<a href=3D"mailto:k=
utulu@kutulu.org">kutulu@kutulu.org</a>> wrote:<br>
><br>
> =C2=A0From: Dale [mailto:<a href=3D"mailto:rdalek1967@gmail.com">rdale=
k1967@gmail.com</a>]<br>
> =C2=A0Sent: Monday, March 12, 2012 7:23 PM<br>
><br>
> > I like that quote. =C2=A0I may not be dev material but I know thi=
s /usr mess<br>
> > is not right. =C2=A0The only reason it is happening is because of=
one or two<br>
> > distros that push it to make it easier for themselves.<br>
><br>
> If that's honestly what you think then I suspect you don't und=
erstand the problem as well as you believe.<br>
><br>
> The idea of trying to launch udevd and initialize devices without the =
software, installed in /usr, which is required by those devices is a config=
uration that causes problems in many real-world, practical situations.<br>
><br>
> The requirement of having /usr on the same partition as / is also a co=
nfiguration that causes problems in many real-world, practical situations.<=
br>
></p>
<p>I quite often read about this, and after some thinking, I have to ask: w=
hy?</p>
<p>> The requirement to ensure that /usr is *somehow available* before l=
aunching 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 "tha=
t's more work than I want to do" as being the expected griping tha=
t always happens when you ask a group of geeks to change something.)<br>
></p>
<p>When one's handling enterprise servers, "might possibly break&q=
uot; is a 95% certainty of "you do that and I'll make sure to have=
a pink slip standing by." :-) </p>
<p>Rgds,<br>
</p>
--bcaec50405d62c5e5e04bb18a961--