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 1S89q5-0007fB-2u for garchives@archives.gentoo.org; Thu, 15 Mar 2012 12:31:29 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 76C1FE0C1C; Thu, 15 Mar 2012 12:31:20 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 4F906E0BCE for ; Thu, 15 Mar 2012 12:30:50 +0000 (UTC) Received: by bkwj4 with SMTP id j4so2472816bkw.40 for ; Thu, 15 Mar 2012 05:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cJfT9HcqrhDj1tVFudmgkh6Msrq+eJ1wJKDO7yg9xeg=; b=bcWD8ePSoz/TxB/BmGyC6byV0jqzDD4K/9cELG/xaPIBN9lqMR56Hfj+oEuHL62oaa VHaUeH2mvKG/OBHw4u1K5HbCLl2fcY6dz+TlUlqjFTKFSfChK9IYiodqfbyndPGk5kTR mbIlQIBm4y/Vom7Vyp8Mk76nU2cCgQURGf1qIqyhcREyirjvGyXvih36JQb7vIyCkyjL LjBlKfHdcWB3+WdRBfFF8xiOd4s1YHZSk1rJuqCEaCVKZDSzlrkRD/0qooUMcMxCaFSc DpH0anr1B+85SgFzwI+0OlokxF9jvb0z79DZDmU7kdoXU2CZ4K04HXD/UcR2pHcz0kks vFCQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.152.27 with SMTP id e27mr2353036bkw.55.1331814649426; Thu, 15 Mar 2012 05:30:49 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.205.32.194 with HTTP; Thu, 15 Mar 2012 05:30:49 -0700 (PDT) In-Reply-To: <4F61CCD4.9000002@gentoo.org> References: <4F5C1BE9.3040609@gentoo.org> <20120311173355.GB6599@linux1> <4F5EA152.80604@gentoo.org> <4F5FE34A.4030609@gentoo.org> <4F6091CE.1050009@gentoo.org> <20120314144115.GA30606@kroah.com> <20120314145144.GC3200@ca.inter.net> <20120314150431.GA2033@kroah.com> <4F61CCD4.9000002@gentoo.org> Date: Thu, 15 Mar 2012 08:30:49 -0400 X-Google-Sender-Auth: fwO9URa8cE5PNOP2chO0ChEooRM Message-ID: Subject: Re: [gentoo-dev] Re: Let's redesign the entire filesystem! From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 63493fc2-a948-429f-9703-cf5024c98fbf X-Archives-Hash: 2505b96b018488aeca44e5cd19a96022 On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard wrote: > This does lead me to wonder if a light-weight udev could exist that lacks > half or more of the functionality of the current udev. =A0I'll be honest,= I've > only edited my udev rules file once, and that was only when I installed a > Sun Happy Meal quad ethernet card in which all four ports utilize the sam= e > MAC address and udev doesn't handle this very gracefully (if I had Solari= s, > I could edit the card's firmware and change this setting). You know - I had a similar issue, but with a pair of PL2303 USB RS232 interfaces. That makes me wonder if there is a possible way to enhance udev to better handle situations where devices have no unique ID and thus tend to be difficult to access consistently across reboots. In my case I had to hack a rule so that I got a symlink if the device was in a specific USB slot. Use case is controlling tuners for mythtv. No doubt a simpler 80% solution could be created for udev, and likely it would be easier to cut down on its dependencies as a result. However, the other 20% of users will still need the more complete solution. Big distros that want to support lots of hardware with a one-size-fits-all configuration will just deploy that complete solution everywhere, which means that the only people maintaining the simple solution would be people who like to tailor each system. For most of the more enterprise-y OS providers (ie the ones with money to pay devs), one-size-fits-all is a lot more sustainable. You won't find an edition of MS Windows that works only on PCs without scanners and sound but uses 50MB less RAM, for example. Sure, we don't have the same constraints as the enterprise-y distros, but we do have the constraint that if we want to do things differently we will spend a lot of time patching what we could otherwise simply reuse as-is. I don't think that split filesystem installs are going away anytime soon. In fact, when btrfs is finally mature we might see them blossum. Using subvolumes you could have more granular snapshotting and mount options, while still maintaining a shared disk space pool (with granular quotas). If everything the distro is likely to mangle is in a few subvolumes you can reverts snapshots on those without losing changes in other subvolumes if you ran in production before deciding to revert. That gets you a lot more flexibility than a single snapshot on root - especially in terms of recovery time (you can still copy files between snapshots if you only snapshotted root - in fact with reflinks this is very fast). Rich