Gentoo Archives: gentoo-dev

From: Joshua Kinard <kumba@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
Date: Thu, 15 Mar 2012 13:06:55
Message-Id: 4F61E913.1080800@gentoo.org
In Reply to: Re: [gentoo-dev] Re: Let's redesign the entire filesystem! by Rich Freeman
1 On 03/15/2012 08:30, Rich Freeman wrote:
2
3 >
4 > You know - I had a similar issue, but with a pair of PL2303 USB RS232
5 > interfaces. That makes me wonder if there is a possible way to
6 > enhance udev to better handle situations where devices have no unique
7 > ID and thus tend to be difficult to access consistently across
8 > reboots. In my case I had to hack a rule so that I got a symlink if
9 > the device was in a specific USB slot. Use case is controlling tuners
10 > for mythtv.
11
12
13 I use a ton of the pl2303-based devices, too. Except I'm usually in Windows
14 with them, so I just have to deal with Window's oddball way of renumbering
15 them sometimes when I unplug one and plug it right back into the same USB
16 slot (i.e., I lost COM11, and it's now COM14, which, ironically, is outside
17 the range of TeraTerm)
18
19
20 > No doubt a simpler 80% solution could be created for udev, and likely
21 > it would be easier to cut down on its dependencies as a result.
22 > However, the other 20% of users will still need the more complete
23 > solution. Big distros that want to support lots of hardware with a
24 > one-size-fits-all configuration will just deploy that complete
25 > solution everywhere, which means that the only people maintaining the
26 > simple solution would be people who like to tailor each system.
27
28 That, or udev making more of its functionality optional via its build system
29 (does it use autotools and configure, I never looked, to be honest?). This
30 would allow additional USE flags to be added to enable or disable additional
31 functionality as needed.
32
33
34 > For most of the more enterprise-y OS providers (ie the ones with money
35 > to pay devs), one-size-fits-all is a lot more sustainable. You won't
36 > find an edition of MS Windows that works only on PCs without scanners
37 > and sound but uses 50MB less RAM, for example.
38
39
40 Funny, but as much as I am against Windows on a server, Windows Server is
41 easier to turn off unneeded stuff than RHEL5 is. Windows Server comes with
42 audio and TWAIN/IMAPI components disabled (or out right missing -- you have
43 to add them back in through server manager). But try to remove features
44 like sound, CD burning, various media players, text-to-speech, etc, from a
45 fresh RHEL5 install, and you're in for a fight. It's not necessarily RHEL's
46 fault, but more Gnome's fault because of the massive about of
47 interdependency that you get with Gnome, and the fact RH chose to just not
48 bother with it and build in a ton of stuff by default.
49
50 Ditto for an install of OpenSolaris that I did.
51
52
53 > I don't think that split filesystem installs are going away anytime
54 > soon. In fact, when btrfs is finally mature we might see them
55 > blossum. Using subvolumes you could have more granular snapshotting
56 > and mount options, while still maintaining a shared disk space pool
57 > (with granular quotas). If everything the distro is likely to mangle
58 > is in a few subvolumes you can reverts snapshots on those without
59 > losing changes in other subvolumes if you ran in production before
60 > deciding to revert. That gets you a lot more flexibility than a
61 > single snapshot on root - especially in terms of recovery time (you
62 > can still copy files between snapshots if you only snapshotted root -
63 > in fact with reflinks this is very fast).
64
65
66 ZFS encourages creating volumes and filesystems en masse. Right down to a
67 separate ZFS mount for each user's home directory under /home, and /home
68 itself is a mount point. So yeah, Btrfs, ZFS, etc...get an FS like those
69 two which not only encourage dozens of mount points, but which seamlessly
70 hide all the dirty details from you (and the users), and issues like this
71 will simply vanish into thin air.
72
73 --
74 Joshua Kinard
75 Gentoo/MIPS
76 kumba@g.o
77 4096R/D25D95E3 2011-03-28
78
79 "The past tempts us, the present confuses us, the future frightens us. And
80 our lives slip away, moment by moment, lost in that vast, terrible in-between."
81
82 --Emperor Turhan, Centauri Republic

Attachments

File name MIME type
signature.asc application/pgp-signature