On Thu, Sep 8, 2011 at 3:00 PM, Canek Peláez Valdés <can...@gmail.com> wrote:
> On Thu, Sep 8, 2011 at 1:45 PM, Michael Mol <mike...@gmail.com> wrote:
>> This isn't a discussion. This is a bunch of people offering
>> displeasure, ideas and/or thoughts, and one person saying, "hey,
>> nothing I can do. I trust the devs."
>
> I disagree: I'm not saying trust the devs and shut up. I'm trying to
> explain why *I* trust the devs and why *I* think is for the best for
> someone else to do it. Nobody needs to agree with me, of course, I'm
> just trying to explain my POV.
>
>> A discussion is when there's an interchange of ideas, arguments,
>> counterarguments, and the fleshing out of a new framework of thought.
>> That kind of point/counterpoint is *vital* for architectural
>> foresight. All I keep reading from you is, "if you think that will
>> work, go write it." *No* writing for a problem of this scope is
>> warranted without some extensive discussion, noting of edge cases and
>> planning around the same.
>
> Sorry you read that way; I keep trying to explain why I don't find a
> separated /usr a necessity and why I don't think an initramfs is such
> a big problem.
The rhythmic baseline of your explanation is "and you can use an
initramfs for that." I haven't seen much in argument for why initramfs
isn't a problem apart from your expectation that the *kernel* will
eventually require it, and dracut theoretically solve the problem of
updating initrd. (Which sounds nice, but it's yet another moving part
in the system, and another point of failure.)
>> People have been pointing out edge cases, use cases which are being
>> disregarded, etc, and pretty much all they're getting back is "I don't
>> see those as valid."
>
> And I have tried to explain why it's not economically feasible to
> support every architecture and every set of configurations.
Which I think has been firmly explained in at least two different
threads; dev time is not infinite, sure.
> Yeah, the only two solutions I see is either roll up with the change, or
> maintain it yourself.
If those are the only two solutions you see, I suspect you're not
looking hard enough. If udev's problem is that it's running arbitrary
programs, then perhaps a recognizable constraint needs to be made on
what programs udev should run. I thought the primary reason we had
/{,s}bin and /usr/{,s}bin was to differentiate between system-vital
programs and other programs.
> That people don't like the answer doesn't mean is not true.
There's also no solid evidence that it's true, either. I remember when
sysfs came about. Linux Journal's diff -u column described it as a
herculean effort accomplishing something the majority of kernel devs
thought impossible or not worth the time. I rather like sysfs, but at
one time, it was the thing very few people thought was in the possible
set of solutions.
>> Granted, you're kinda painting a target on your
>> back by being the only one defending upstream's decision here
>
> Someone has to. I've been using Gentoo almost eight years now, and I
> usually don't participate in the dicussions, but I have seen in the
> last years a trend to criticize the devs without actually considering
> the alternatives.
People are beginning to consider alternatives, but you've shot them
down without offering improvements, suggesting adjustments or even
pointing out specific flaws. As a result, you come across as something
akin to a fanboy with your mind already made up, which just seems
*bizarre*.
>
> Sometimes the devs do stupid things; but most of the times they really
> think and come to a solution. And the affected users usually just see
> how that solution affects them in the short term, instead of trying to
> see the big picture and how affects the whole distribution, the
> community, and the technological path that Linux is following.
For being irritated that people aren't seeing it, you haven't been
clarifying it much.
>>, but
>> when someone pointed at an already-existing alternative, you simply
>> said, "I doubt that'll be the solution."
>
> And I doubt it. But I also said that they are more than welcome to try
> wathever they want. I think the way I think; that's the whole point of
> me trying to communicate it here.
That much is appreciated, but you didn't say *why* you doubt that'll
be the solution. Downvotes aren't debate, nor are they discussion.
They're expressions of dissatisfaction.
>> As for me, this will be a royal inconvenience, and may require the
>> rebuilding of my primary machine. Still, I can deal. It'll mean
>> learning how to build initramfs*, how to make sure it contains the
>> needed tools, and probably a half-dozen other things I didn't even see
>> coming when I set up this box last fall.
>
> I compile my own kernels (no genkernel for me). I don't use modules
> (except for the stupid scsi_wait_scan), and I didn't used an initramfs
> until I started using systemd. The arguments for using it convinced
> me, and I made the switch in all my machines.
>
> I don't see why it would require to "rebuild" your primary machine,
> but I don't know your configuration. I know that any sane
> configuration would only require to install dracut and modify a line
> in grub. Maybe a kernel rebuild.
My / isn't large enough to hold /usr.
>> * I've avoided it for ten years it was a grossly unnecessary
>> complexity for my systems. Now it sounds like it'll become a
>> necessity.
>
> Apparently. But is not "grossly" unnecessary: udev need it, and udev
> solves a kinda complicated problem. Maybe mdev can solve it in a
> simpler way.
>
> But again, I doubt it.
One question: Why? Are there specific technical reasons to your
doubts, or is it simply confidence that the devs are more likely to
have made a good choice than a bad choice?
--
:wq
