From: Pandu Poluan [mailto:pa...@poluan.info] Sent: Wednesday, March 14, 2012 12:28 PM
> This email [1] (and the correction email right afterwards) should give some > much-needed perspective on > why we're driving full-speed toward an overturned manure truck (which some of > us, e.g., Walter and me, > are desperately pulling at the handbrakes). >[1] http://lists.busybox.net/pipermail/busybox/2011-September/076713.html Actually, that email lost me in the second sentence (though I kept reading): > It is incredibly biased > towards huge desktop systems and behemoth software Every machine I run Linux on is a huge desktop system running behemoth software (Eclipse, GNOME, Chromium, LibreOffice, etc.). That's why it's called a "free desktop system". The author of this email is clearly baised *against* desktop systems running desktop environments, as well as any other "highly dynamic" system that doesn't fit the model of a simple server running Linux the way it ran 10 years ago. He seems to be producing a rather vitriolic, and IMO uncalled-for, rant against the simple fact that computers do more stuff in 2012 than they did in 1972 and the udev developers are changing with the times. The reality is, the majority of people running Linux desktop systems using big software packages want a desktop system that works out of the box so they can just turn it on and get their work done. That is the audience that udev is targeted for, and it is doing a perfectly good job at meeting the needs of that audience. The fact that the largest major distributions are currently using udev (with an initrd) successfully is all the proof you need that it actually does work. The people who want or need a more specialized solution to this same problem (dynamic device management), are generally also smart enough to avoid using udev if they so choose. Again, the fact that, with merely a few months of effort, a handful of users on this list have produced exactly such a solution is all the proof I need that such a solution is possible. I also know that I have no reason to use their solution because the one I'm using now works just fine for me. As to the email itself, I see two major technical flaws in the argument as presented: First, the fundamental argument being made is that /usr should be allowed to remain a separate partition, and that the "misinformed" and/or "dishonest" and or "[lacking in] good engineering practices" systemd team somehow wants to force everyone to put /usr and / together. Except that's *absolutely not at all what they are proposing*. Their proposal is precisely this: "the /usr partition contains binaries that are needed on many modern desktop systems to properly populate the device tree, and thus, the /usr partition must be available early enough in the boot process for that to happen, and thus, we can move forward with our software (udev) with the assumption that /usr will be available when we need it." Second, the idea that the entire collective Fedora/Debian/etc teams somehow made "a mistake" by "install[ing] critical software into /usr". This argument falls flat when the author fails to identify what he or she considers to be critical vs. non-critical software. Is bluetoothd critical? On my laptop it is not. On my main development workstation it is not. On my wife's desktop it is because she has a Bluetooth keyboard/mouse combination. Should bluetoothd be moved from /usr/sbin to /sbin? Along with libglib and libdbus, which it depends on? How about usbmuxd, or alsactl? You could also argue, as some here have done, that these are not truly "critical" software because those are not "critical" devices; but now, you must teach udev to know the difference between "device that can be added pre-mount" and "device that must wait until post-mount" on a per-device-per-system-per-boot basis, since that designation may change at any time. And recognize the difference between "device that failed because something went horribly wrong and I should drop into rescue mode" vs "device that failed because I tried too early and just need to try again later." And provide a way for udev to create the devices it can, pause while the rest of the filesystems come up, detect that the rest of the filesystems are present, then go back and re-do the devices that failed originally. All the while knowing that the solution of "just make /usr available" is such an easy and reasonable answer 99% of the time. I know which option I'd pick to spend my limited time and resources on. There's no need to get mean-spirited about it. You are not "pulling at the hand-brakes" of an out-of-control "manure truck". You are producing one of many possible /perfectly valid/ alternative solutions to a complex problem, one which meets your needs but does not meet mine, and there is absolutely nothing wrong with that. --Mike
