On Mon, Sep 30, 2002 at 12:22:28PM +0200, Tomas Szepe wrote:
> > Technically correct. Major version jump should be made when there is
> > a binary incompatibility. It can be made without, but it is usually
> > done for marketing reasons. I hope we'll never have marketing reasons
> > for lk. :-) We can be actually _proud_ to have 2.$BIGNUM instead of
> > 3.0
>
> ... and go Solaris, as in 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 7, 8, 9. :D
I've no problem per-se with 2.6, 2.7, 2.8, 2.9, 2.10...
And i see no reason to compare it with Solaris where numbers
are mostly marketing although their major number refereed to
the codebase (bsd vs SVr4).
I can see a number of real reasons to advance to 3.x:
Finishing the block layer and VM rewrite, maybe;
making FS blocksize independent of pagesize, probably;
flexibility with regard to pagesize for archs that support
variable pagesize (if market share and performance gains add
up the CPU designers will give it to us), probably;
initramfs, perhaps;
new module interface, possibly;
hotplug everything (and i mean everything), maybe;
elimination of the 32 bit versions of system-calls
and other deprecated interfaces, absolutely;
new filesystems and device drivers, nope;
incremental performance improvements, you've got to be kidding;
It is just that right now, from what little i can see, 2.5
is part way through the process of a block layer redesign
and the VM is in a similar state. Evidently LVM is in limbo
but that has to be at least operational before code freeze.
Driverfs looks promising but the API isn't even set and
documented yet. BTW what happened to moving away from
major/minor numbers?
The developers are doing a great job and things are moving
along but 2.6 looks more than anything else like a stabilized
snapshot so the improvements become available (trustworthy)
for production. That is consistent with "release early,
release often".
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.wsRemember Cernan and Schmitt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 30 2002 - 22:00:44 EST