On Thu, 8 Sep 2011 18:36:56 -0400 Canek Peláez Valdés <can...@gmail.com> wrote:
> On Thu, Sep 8, 2011 at 5:11 PM, Alan McKinnon > <alan.mckin...@gmail.com> wrote: > > On Thu, 8 Sep 2011 16:48:45 -0400 > > Canek Peláez Valdés <can...@gmail.com> wrote: > > > >> On Thu, Sep 8, 2011 at 4:43 PM, Michael Schreckenbauer > >> <grim...@gmx.de> wrote: > >> > Am Donnerstag, 8. September 2011, 16:23:36 schrieb Canek Peláez > >> > Valdés: > >> >> > In what valid way does access to /usr become something that > >> >> > udev may be required to support? > >> >> > >> >> It is a matter of what else do you end having in /bin and /lib. > >> >> Remember that udev rules can execute arbitrary code. Do all that > >> >> code needs to be moved to /bin and /lib also? > >> > > >> > Of course. That's what /bin, /sbin and /lib are for. > >> > > >> >> I keep telling: it is a difficult problem. > >> > > >> > No. Just move or copy the binaries and libs *you* use for *your* > >> > udev-scripts to /bin, /sbin and /lib > >> > >> I *really* don't think bluetoothd belongs to /sbin. But, hey, > >> that's me. > > > > Then do what all sane code does when the scripts it uses fails or > > cannot be found - throw an error and continue. > > This is the problem with people not seeing the big picture: Imagine a > modern system with a bluetooth keyboard. I know, we are geeks, we use > real-men keyboards, not connected with bluetooth. But believe me, > there are people doing that, attaching bluetooth keyboards to their > systems. > > And then, the system does a fsck, and it fails and the user needs to > enter her password to go into maintenance mode. But guess what, if the > bluetoothd daemon is not running, she is going to be a very very very > sad user, because "it will throw an error and continue", leaving her > unable to fix it. > > We are no longer in 1982: we actually have bluetooth keyboards. It is > a very valid and very actual (probably more in the future) use case. > To solve this case the devs had to choose between putting everything > and the kitchen sink into /sbin or /bin (it is not bounded: anything > can be executed from udev), or to ask to put /usr into / or using an > initramfs. You don't need every possible thing that udev could ever run to be avialable on /, just the things that are essential. That is quite a small list subset of the full list of all possible devices: All HID devices All console devices All code to access and read file systems Everything that can be used in place of a physical keyboard (serial, console over ethernet) That looks like it might be a large amount of disk space, but in fact it isn't. This very mail is being typed on a binary distro (Ubuntu): The bluez package is 1.6M. /lib alone is 331M, I use a fraction of it but it is still there. /lib/modules contains two kernel versions of 136M each. Ubuntu has no choice but to ship every imaginable device driver they support, so / is *already* rather large, and that's just device drivers. I say leave it up to the distros what to put where. Ubuntu and Fedora will ship support for bluetooth in the scenario you describe. JoeBlowLinux might not. If Joe's users are left up the creek, that's Joe's problem to deal with, but all the infinite variety of possible Joes still have the same freedom they always had - to fix or break their shipped stuff at will. Incidentally, your bluetooth keyboard example is a tad disingenuous. That fictitious user is going to have an almighty problem at grub time selecting what system to boot. A bluetooth keyboard is the ONLY possible keyboard input device? What kind of general purpose computing hardware were you picturing? -- Alan McKinnnon alan.mckin...@gmail.com
