> 2.0.31 now won't include as many bug fixes and updates as it might have
> since Linus (appropriately) will only fix the fatal problems like the
> buffer cache.
Does this mean that we are looking at 2.2 (3.0?) possibly being not too
far down the road? If there become too many features new 2.1 people who
should be using the 2.0 set will start using 2.1 and we'll start getting
flooded with "2.1.44 ate my HARD DRIVE!! DIE KERNEL SCUM!!".. <Sigh> Maby
the 2.1.x should not be kept on the same servers where people get 2.0
kernels from.. :) Or maby Linus should should think about declaring a
semi-stable kernel once and a while.. So if you feel you must run 2.1.x
you can run one that probably wont eat you hd..
> the 2.1.X tree will fall behind a little now since you've forced Linus
> to spend time on 2.0 (which other people like David were willing to
> handle until the bitchy people ticked him off)
Speaking of trees.. Anyone know if there are plans to intergrate the VMS
(QNX?) style schduling.. I've yet to use it but I've used the evolutionary
schduling, which has some of the same end results and It's nice..).. I'd
like to see it as a /proc/ option.. (maby default on?)
On the same line as the QNX schduler.. Has anyone looked into making
fork() more restistant to bombing (like having fork priorities and
demoting any process that forks like crazy when the process table is
getting full)...
And what happened to ZeroD? It seemed to accomplish the same kinds of
improvements the pentium-memcpy patch did but it was a little more sane
looking?
Or how about those wonderful non-exec-stack patches? They worked real
well.. But no one bothered to read the docs and realize they didn't break
signals, tramps, etc.. Is it still being maintained? Any concideration
for becoming an compile time option?
It would be nice to say that Linux is resistant to fork, while loop
bombing without hard limits.. And as soon as buffer-overflow hacks become
common on NT (There ARE SO MANY overflow problems with 95/NT I expect to
see hacks soon), it would be nice to say that linux is one of the few OSes
that can be made impervious to crummy programming!.. :)
Is there some kinda agreement with the sound driver company that the
kernel sound driver cant be as nice as their noncomercial version.. I'm
not taking about menus and all.. Maby just the ability to have seperate
modules for differnt cards and IRQ/IO as module options..
And ext2 compression (I've used the patches on dummy computers.. Worked
for me).. Various new mount options (i.e. noatime usecompression (to
enable ext2compression) etc..), maby carring along some userspace mods to
mount (i.e. autodetection for loopback device)..
> so in the end 2.2 (3.0?) will farther down the road.
Any word from Linus on if it will be 3.0? 3.0 versions make lotsa people
feel more comfortible.. They dont realize the 3 version to fix bugs rule
doesn't apply to free software..... It looks like the next version will
def have enough new features to warrent a new major number.. Esp if maby
during the 2.1.x seris we added the above patches, and maby 64-bit
major/minor numbers.