> 2.2 is supposed to _be_ stable, not gradually stabilize. That's what 2.1/2.3 are
> for.
Unfortunatelly it's not possible. Joe average will not even try "development"
kernel and some errors could not be found without A LOT OF users.
>>
>> > Besides, binaries are still the best way to get up and running as fast as
>> > possible. Waiting to bring up a replacement server because it's still
>>
>> Really? And what about waiting until the binary only patches get shipped by
>> the vendor. For those of use with experience on binary only systems, this
>> complaint is completely mysterious.
> tell that to redhat/debian whoever.
Huh. And why redhat/debian so struggle for "reproducible builds" (unlike
Slackware :-) ? This is way it's trivial to recreate new binary package when
needed with just `rpm --rebuild` (or whatever in Debian?). Of course it's not
only goal but `rpm --rebuild` is there for purpose !
>>
>> Here's my suggestion. If you want to work with the development kernel
>> in production mode with binary sources,
> binary sources? heh. See above, anyway: the original complaint was not
> about 2.1 kernels pulling the rug from under ur feet, but about 2.0 kernels
> doing that.
Looks like few overlooked problems in 2.0.x kernels started all this fuzz :-((
Even NT where binary compatibility is fetish doing it (after NT 4.0 and
NT 4.0 SP3 are not 100% binary-compatible!) why you thing Linux is exception ?
>> pay for it. That is, get someone or some organization to agree to
>> maintain a binary compatible version of the system and to provide you
>> with updates. There are many people who will do this.
> what do u think MIT is doing? u seriously expect the best university in
> the world to outsource stuff like this?
Or they will outsource "stuff like this" or stuff will be thrown out in dust
and OSS replacement will be done eventually (even if this will not happens
this year or next year :-) We here have simple rule: "no software in kernel
mode or under user root on servers without available sources" and I think that
this trend will be expanding in the future. [VERY] Slowly but inevitable...
>>
>> The argument: "we are using the open source kernel developed by other
>> peoples work to make money and therefore the developers that we don't
>> pay need to follow our requirements", is not a persuasive one.
> true. the point however, is that if the developers don't follow _some_
> requirements, pretty soon they might be the only ones running the system.
> That is not something anybody here _wants_ to see happen.
Why you think so ? IMO "no drivers" or "no AFS support" or "no USB support"
is WAY better then "binary-only drivers", "AFS support via binary-module"
and "USB with precompiled kernel blob".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/