Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Michael Mol]

On Thu, Mar 15, 2012 at 10:09 AM, Mike Edenfield <kutulu@××××××.org> wrote:
>> From: Dale [mailto:rdalek1967@×××××.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