On Thu, Sep 8, 2011 at 3:37 PM, Michael Mol <mike...@gmail.com> wrote:
> 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.)
No, I think you haven't been reading carefully enough. Again:
1. In 2011, we need a dynamic /dev tree. I'm not going to argue why.
2. udev, successor of devfs, which was successor of the classical /dev
tree, after years of design and development iterations, solves the
problem. It's not perfect, but I think that is as close as it could
be, for the problem it tries to solve, and with the feature set it
has.
3. udev needs either an initramfs, because it needs an early user
space, or a /usr inside /.
>From this 3 points, I make my conclusion: keep up with the changes, or
code an alternative (that includes using something like mdev).
>>> 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.
Agree.
>> 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 enters perflectly in my other solution: code an alternative. That
includes changing (or trying to) udev.
>> That people don't like the answer doesn't mean is not true.
>
> There's also no solid evidence that it's true, either.
Prove me wrong, or find the code that proves me wrong. If it's that
important to you, do it. My whole point is that it's easier (and in
the long term more beneficial) to roll with the changes.
> 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.
I don't see the connection. If someone actually goes and writes the
code for an alternative to udev (or /usr inside /, or an initramfs),
then it enters my second alternative.
>>> 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*.
I don't really care if people mind me a fanboi: I know I'm not. I'm
old enoguh to be a fanold, though.
Seriously, maybe I'm not communicating my point clearly. The only
alternative mentioned (I think: please correct me if I'm wrong) is
mdev... which I didn't shoot down, I just mentioned that I don't think
will solve the problem. And if you have followed the development of
Linux as I have, then you know it is a *really* hard problem, and that
udev is the result of many man-hours of thinking, designing and
implementing. That's why I don't give to much hope to a project I have
never heard about.
That doesn't mean I'm not mistaken, of course.
>>
>> 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.
When did I say I was being irritated? I'm only trying to express my POV.
>>>, 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.
Why should I be dissatisfied? The development of Linux goes exactly in
the direction *I* want, I don't complain about any of the required
changes discussed.
Why I doubt it I answered some paragraphs above.
>>> 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 don't understand. You said you were to try building an initramfs,
and if that's the case, then you can keep /usr separated.
If you will put /usr in / (and hence rebuild your system), then why
you said you would learn how to built an initramfs?
>>> * 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?
I answered that already (actually, in that paragraph). But again: udev
is not trivial, and it solves a (far from) trivial problem. If some
developers think they can outsmart the kernel devs, please, lets try
it. Maybe they will.
But I'm not holding my breath.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
