Wanna give me a hand debunking this?

[Les Mikesell]

Jeff Spaleta wrote:

>> On the user side it is - otherwise you can't come close to posix or any
>> other standard that applications are developed to.
> 
> You're arguments are a wasteland of shifting sands.
> POSIX complaince is one thing. A stable ABI that hardware drivers can
> rely on is quite another. If all you cared about was POSIX compliance
> and how "user space" interacted with the kernel the version rev of the
> kernel you ran wouldn't matter at all.

Yes, you are starting to get it.  The kernel version _doesn't_ matter 
once it has working drivers for the hardware in any particular box. 
Hence there is exactly _no_ reason to break either the driver ABI or 
risk breaking other things with irrelevant changes that won't affect the 
standards-conforming interface anyway.  However, every kernel is laced 
with a certain number of bugs and security issues that are not 
discovered until later, and in the fedora scheme of things you can't get 
those fixed without taking other changes likely to break your working 
system.

> I'm still left wondering what your actual complaint is.   It's clearly
> not what the other poster has suggested you meant... you clearly dont
> care about wmware or other binary modules..or if you do you have no
> idea what the fundamental issues associated with such things are as it
> relates to kernel development.  In any event, you are being extremely
> unclear as to why the fedora kernels are a problem for you
> specifically.

I do care about vmware specifically, but even more about the philosophy 
that it doesn't matter what other software breaks during a needed 
security update.  It's just not something I ever want to rely on.


>>>>   It doesn't have to keep changing to do that, particularly on hardware
>>>> that doesn't change, although it does need security/bugfix updates. The
>>>> concepts of open()/read()/write()/ioctl() never change. Applications, on
>>>> the other hand, are always being improved.
>>> Are you calling the development that the upstream kernel developers
>>> do... not improvements? I think you just insulted the upstream kernel
>>> developers.
>> They are improvements to whatever extent they enable new hardware to be
>> used, but that is very much irrelevant on an existing, working box.
> 
> Naive.. very naive.  I would encourage you to pay closer attention to
> upstream work on the kernel. It would be instructive.

But it doesn't matter if it doesn't change the behavior of 
open()/read()/write()/ioctl().  And those were specified a long, long 
time ago so if they do change it will be a bug.

>> Isn't it more of an insult to say that yesterday's kernel isn't
>> usable?
> 
> Just as insulting to say that yesterday's OpenOffice isnt usable.

I think everyone takes that for granted.


> I'm not the one arguing that i need an older kernel with a newer
> application space... you are.
> If you can live with yesterday's kernel you can certainly live with
> yesterday's applications.

Errr, why?  Did posix just add as many new specifications for new OS 
functionality as firefox and openoffice have new features?  I must have 
missed that.

> I am arguing that Fedora as a project attempts to treat ALL the
> components equally and makes an integrated experience that takes the
> latest bits and drive development forward while working as closely
> with the upstream development as possible... from the kernel upward
> into the stack. Suggesting that its perfectly okay to freeze the
> kernel over the usable lifetime of a computer system clearly
> demonstrates that you do not comprehend how active kernel development.

New kernel work needs to be done to support new hardware. 
Posix-conforming operation that works on existing hardware does not need 
to be changed other than fixing bugs as discovered.

> I'm really not sure there's much more I can say constructively on the
> matter.

Tell me what new kernel functionality I'm missing if I run a Centos 
kernel on a box where it runs all the hardware.

-- 
   Les Mikesell
     lesmikesell at gmail.com