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@xxxxxxxxx
