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 1R4CJF-0001Ud-O7 for garchives@archives.gentoo.org; Thu, 15 Sep 2011 13:48:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A292521C17E; Thu, 15 Sep 2011 13:48:43 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 5E9E421C0C0 for ; Thu, 15 Sep 2011 13:47:34 +0000 (UTC) Received: by bkbzt12 with SMTP id zt12so3409329bkb.40 for ; Thu, 15 Sep 2011 06:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=aVUUZOSOGl/cqfrYBbKG7Vf7VgjAxqA1A3wQkNPbkU0=; b=w1SDEsVi3DFnaLuOyER9avSvr1IfUuvXEvDk+lUPp68eOsctQIQydA8eHC5tXdDJzR xKsj5OT40sV9P3NBft2GQSF9IbV+VTzoCbGEZ2DZqA4PpmKBhXrcRzfc51VFZcUuVwVo 8jxGGrszC+ryJXTj0a16Zt0g0ZBqGOtSIlPJs= 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 Received: by 10.204.136.79 with SMTP id q15mr734324bkt.206.1316094454352; Thu, 15 Sep 2011 06:47:34 -0700 (PDT) Received: by 10.204.155.79 with HTTP; Thu, 15 Sep 2011 06:47:34 -0700 (PDT) In-Reply-To: <2056931.seTjzgOPrt@eve> References: <20110912150248.GB3599@acm.acm> <1769799.TszvVHMTQM@eve> <2056931.seTjzgOPrt@eve> Date: Thu, 15 Sep 2011 09:47:34 -0400 Message-ID: Subject: Re: [gentoo-user] udev + /usr From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 179ddfb6184a051f04b335864cd6d683 On Thu, Sep 15, 2011 at 3:01 AM, Joost Roeleveld wrote= : > There are not many people who agree with you here. > The changes will lead to a C:-drive, similar to MS Windows, where everyth= ing > has to be a single partition. Technically, this isn't true. %PROGRAMFILES need not be on %SYSTEMDRIVE%. %PROGRAMFILES(x86)% need not be on the same drive as %PROGRAMFILES%. I believe most of the system key locations are allowed to be in disparate locations. > For various reasons, using seperate partitions are a better solution: > - =C2=A0It allows for the use of filesystems better suited to the type of= files and > usage on each partition. > - It prevents a single part of the filesystem to kill the entire system. = (I > can risk loosing 1 partition and not loose the rest of my data) Fully concur. >> In my humble opinion, what you just said is a little pedantic. You can >> disagree with the proposed changes, you can argue why you think >> another approach could be better. But just saying "the implementation >> of it isn't =C2=A0thought through", is a little insulting to the devs. I >> think they though about the implementation a lot. > > They may have thought about it, but didn't think things through. > I have already stated a better way of doing it in the past few days. I wi= ll > repeat it here. > > The problem-scope that udev is TRYING to solve should NOT be solved in a > single tool. Concur. > The main purpose of udev is to populate the /dev-tree. > The running of scripts based on /dev-tree events should be in a seperate = tool > that starts later in the boot-process. I'm not *entirely* convinced this is the case, because it feels like some situations like network devices (nbd, iSCSI) or loopback would require userland tools to bring up once networking is up. > Merging these 2, without properly handling failures, is bad design. Concur. >> Again, to me is not "breaking it". To me is "improving it". > > Adding another SPOF (Single Point Of Failure) is not an improvement. Concur. --=20 :wq