Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Rich Freeman]

On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard <kumba@g.o> 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.  I'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 same
> MAC address and udev doesn't handle this very gracefully (if I had Solaris,
> 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