> Yes. We also have to find the right boundary between never changing
> (the MSDOS stagnation/windows liability and effective death over
> time, sun 18month bug fix) and excessive changes.
Alan, I agree with this statement completely. This is why I believe
Linux _IS_ a superior OS, because it is possible to make changes to
the kernel. And I also think that the 'right boundary' is the
so-called "stable release."
All I've said is that during stable releases (1.0, 1.2, 2.0, 2.2,
etc.), source-level *AND* binary compatibility should be tantamount.
As I said in my original message, security and stability bugfixes are
ok in a stable release -- your fix so people cannot crash the machine
via the network is _probably_ ok. But those changes should be
minimized and should only be done as a last resort -- and I think we,
as kernel developers, have the obligation to keep source *AND* binary
compatibility unless all else fails!
I'm not complaining about the f00f bug fix, or the teardrop attack.
I'm complaining about _GRATUITOUS_ changes to the kernel, changes like
re-ordering structure members or changing structure member names or
the like. Indeed, I didn't even complain about the 2.0.0->2.0.1
change from Linus to make one of the VFS interfaces POSIX compliant
(although that is getting _close_ to unacceptable). However, I believe
that when changes are made, we have an obligation to preserve binary
interface compatibility -- I mean, it's usually our own fault anyways,
so why should we have the easy way out? ;)
But you're also right that Linux cannot stagnate. I say, during the
development work (1.1, 1.3, 2.1, etc.), let it fly, have fun, go
change things. That's the point of development kernels. I don't
think anyone depends on kernel-level compatibility between major
releases. I don't. I would expect to have to recompile for 1.2, 2.0,
2.2, etc. I just don't want to have to recompile kernel modules for
1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4....2.0.0, 2.0.1, 2.0.2, 2.0.3.....
2.2.0, 2.2.1, 2.2.2.....
> Alan
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
warlord@MIT.EDU PGP key available
-
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/