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-136242-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1S7U0r-0004kG-NX
for garchives@archives.gentoo.org; Tue, 13 Mar 2012 15:51:50 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id C4F25E0AA2;
Tue, 13 Mar 2012 15:51:40 +0000 (UTC)
Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212])
by pigeon.gentoo.org (Postfix) with ESMTP id 12493E09F1
for <gentoo-user@lists.gentoo.org>; Tue, 13 Mar 2012 15:50:13 +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 1S7TzM-0030dR-5e
for gentoo-user@lists.gentoo.org; Tue, 13 Mar 2012 22:50:16 +0700
Received: by vcge1 with SMTP id e1so904172vcg.40
for <gentoo-user@lists.gentoo.org>; Tue, 13 Mar 2012 08:50:10 -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.88.103 with SMTP id bf7mr17788060vdb.72.1331653810882; Tue,
13 Mar 2012 08:50:10 -0700 (PDT)
Received: by 10.220.58.200 with HTTP; Tue, 13 Mar 2012 08:50:10 -0700 (PDT)
Received: by 10.220.58.200 with HTTP; Tue, 13 Mar 2012 08:50:10 -0700 (PDT)
In-Reply-To: <20120313173551.773ed013@khamul.example.com>
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>
<CADPrc83F+2x_Jw1WYX15B2ekLW93oi-HuYF2crs2Vj1NJJb_fA@mail.gmail.com>
<20120313173551.773ed013@khamul.example.com>
Date: Tue, 13 Mar 2012 22:50:10 +0700
Message-ID: <CAA2qdGX6Oy49xMYS9sxSWmgq9NFQ51FJXX5=TUZgALrFKrGOLA@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=20cf307f3c045c889104bb21d00c
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: ae52d91a-2397-4766-962b-d9978f15a2c5
X-Archives-Hash: aef94fb3c8080cd714a9e24010cdef54
--20cf307f3c045c889104bb21d00c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mar 13, 2012 10:39 PM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On Mon, 12 Mar 2012 17:53:29 -0600
> Canek Pel=C3=A1ez Vald=C3=A9s <caneko@gmail.com> wrote:
>
> > As Alan said in other thread, it can be "fixed" (if you think is not
> > right) for some very specific cases. Alan mentioned servers, really
> > simple desktops with simple hotplug devices, and embedded systems. For
> > mdev to "fix" the situation in the general case, it would have to
> > cover all the setups udev covers. That means bluetooth devices
> > (including keyboards and mice), USB soundcards, touch screens and the
> > like, all of them being plugged and unplugged at any time in any
> > order.
> >
> > Maybe someday mdev will be able to handle all the cases that udev
> > does. If it does (which I honestly doubt), I'm pretty sure at that
> > point it would have become as complex as udev, if not more, and it
> > will probably need the same requirements that udev has. Including the
> > simple one that for mounting a filesystem, the plumbing needed to
> > mounting it has to be available before, and we cannot keep throwing
> > everything directly on / so it can mount /usr.
>
> I'm slowly coming round to this point of view too.
>
> If you want a full blown desktop machine with all the modern bells and
> whistles that always JustWorks(tm), realise that you have a complex
> system needing complex software. And udev is designed to deal with
> that. To accomplish this task, udev needs to apply some constraints.
>
> For almost everything else, that sophistication is not needed and
> simpler (i.e. less complex) software will suffice. Currently mdev (or
> something else like it) fills that needs.
>
> So 2 different scenarios with different solutions. Horses for courses.
>
Fully agree.
However, currently the 'less complex' mdev solution is not yet a 'first
class citizen' anywhere.
Rgds,
--20cf307f3c045c889104bb21d00c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p><br>
On Mar 13, 2012 10:39 PM, "Alan McKinnon" <<a href=3D"mailto:a=
lan.mckinnon@gmail.com">alan.mckinnon@gmail.com</a>> wrote:<br>
><br>
> On Mon, 12 Mar 2012 17:53:29 -0600<br>
> Canek Pel=C3=A1ez Vald=C3=A9s <<a href=3D"mailto:caneko@gmail.com">=
caneko@gmail.com</a>> wrote:<br>
><br>
> > As Alan said in other thread, it can be "fixed" (if you=
think is not<br>
> > right) for some very specific cases. Alan mentioned servers, real=
ly<br>
> > simple desktops with simple hotplug devices, and embedded systems=
. For<br>
> > mdev to "fix" the situation in the general case, it wou=
ld have to<br>
> > cover all the setups udev covers. That means bluetooth devices<br=
>
> > (including keyboards and mice), USB soundcards, touch screens and=
the<br>
> > like, all of them being plugged and unplugged at any time in any<=
br>
> > order.<br>
> ><br>
> > Maybe someday mdev will be able to handle all the cases that udev=
<br>
> > does. If it does (which I honestly doubt), I'm pretty sure at=
that<br>
> > point it would have become as complex as udev, if not more, and i=
t<br>
> > will probably need the same requirements that udev has. Including=
the<br>
> > simple one that for mounting a filesystem, the plumbing needed to=
<br>
> > mounting it has to be available before, and we cannot keep throwi=
ng<br>
> > everything directly on / so it can mount /usr.<br>
><br>
> I'm slowly coming round to this point of view too.<br>
><br>
> If you want a full blown desktop machine with all the modern bells and=
<br>
> whistles that always JustWorks(tm), realise that you have a complex<br=
>
> system needing complex software. And udev is designed to deal with<br>
> that. To accomplish this task, udev needs to apply some constraints.<b=
r>
><br>
> For almost everything else, that sophistication is not needed and<br>
> simpler (i.e. less complex) software will suffice. Currently mdev (or<=
br>
> something else like it) fills that needs.<br>
><br>
> So 2 different scenarios with different solutions. Horses for courses.=
<br>
></p>
<p>Fully agree.</p>
<p>However, currently the 'less complex' mdev solution is not yet a=
'first class citizen' anywhere.</p>
<p>Rgds,<br>
</p>
--20cf307f3c045c889104bb21d00c--