On Thu, Mar 15, 2012 at 10:09 AM, Mike Edenfield <kut...@kutulu.org> wrote: >> From: Dale [mailto:rdalek1...@gmail.com] > >> This has been one of my points too. I could go out and buy me a bluetooth >> mouse/keyboard but I don't because it to complicates matters. > > I had a long reply to Walt that I (probably wisely) decided not to send, but > the basic point of it is also relevant here. My response to his (IMO > needlessly aggressive) email was basically this: > > Why *shouldn't I* be able to go but a Bluetooth keyboard and mouse if I > wanted to? Those things *work perfectly fine with udev*. And why wouldn't I > want to use the *same* solution for all of my various machines, even if that > solution is "overkill" for half of them? Just because my laptop doesn't need > bluetoothd support in udev doesn't mean using udev there *is bad*. (I don't > need 80% of what's in the Linux kernel but I still install one...)
I wouldn't say you shouldn't be able to. (Outside that I think Bluetooth is a pile of smelly carp, people shouldn't have to bend over backwards to support, but that's a different issue...) > > I am not in any way denigrating the work he's doing. I think it's awesome > and I've tried to help where I can. But I'm pretty fed up with people like > him acting as if the current udev solution is the end of the world. I've > heard it called everything from "design mistake" to "out of control truck > full of manure". "design mistake" is a perfectly reasonable description, and I'd agree with that. It's also not pejorative, but I'd say the two vocal sides of the issue are far too polarized to notice that. "truck full of manure" is probably a bit far, but that description only holds if important things which shouldn't need a dependency on udev gain or keep them. Rather like how installing a console Qt app on a Debian server pulls in X. > > I have three PCs in my home running Gentoo. Two of them would boot correctly > using Walt's new solution (mdev and no /usr mounted at boot) and one would > not. *All three of them* boot correctly using udev. 100% success > 66% > success, so clearly the udev solution is a perfectly legitimate solution to > a real world problem. At work, those numbers are likely different, and > Walt's solution might be a working approach -- if udev didn't already work > fine in 100% of those cases, too. Sure. > > Instead of asking why everyone else should be "forced" to use the udev > solution *that already works*, you should be focusing on explaining to > everyone else the reasons why it is worth the time and effort to configure > *something different* for those same machines. There's little use in explaining to someone why they should use something apart from what they're comfortable with. Moving out of a comfort zone requires personal motivation, not external. If udev works for someone, they should use it. If they discover udev is getting in their way, then they should look for alternatives. I use apache2+squid3 on my server, despite hordes of people telling me I should use nginx. Apache+squid works appropriately well for my circumstance. > There was a reason why people > stopped using static /dev, and devfs; maybe there is a reason why people > should stop using udev, but thus far that reason seems to be "initramfs > makes us cranky." *That* is a matter of systemic complexity and maintenance difficulty; the increased complexity tickles the spider senses of anyone who's had to design, develop or maintain very complex systems with few leave-alone black boxes. It's very difficult to increase the complexity of a system without adding bugs or mistakes anywhere from code to testing procedures to package management to end-user maintenance. So when a system starts becoming more complex, and I'm told that I'm going to have to go along for the ride, I get concerned. Before Walt started pulling mdev from being a busybox-only component, that was exactly the scenario. (Thank you, Walt!) The only cases I've ever conceivably needed to use an initramfs have been where I needed a kernel module available early. Rather than build that as a module and build an initramfs, I simply build it into the kernel. Certainly, there are portions of the kernel (particularly some sound cards) where that doesn't work, and if someone needs those portions available early, then an initramfs is going to be the tool for them. > > There's no need to get mean-spirited just because you choose a different > audience that freedesktop.org as the target for your solution. That's really not the reason for it. I mean, sure, I think the initial reactions were mostly grumpiness and misinformed outrage, but I don't think the contrariness really *baked* in until people got a twofer of "you're going to use udev unless you write the code to get around it" and "oh, you're writing the code? You're wasting your time and you're going to fail." That, I think, is when the real malaise set in. > It just makes > you look petty and childish. Produce an alternative to > "udev/initramfs/single root" that works, provide (accurate) details on the > differences, and let users pick which one they want. I concur. For my part, I expect I'll use mdev in some circumstances, udev in others. Right tool for the right job, and all that. -- :wq
