Re:Changes/Improvements
by
Eslyjah
·
· Score: 5, Informative
More readable version.
final:
- David Miller: sparc/scsi scatterlist fixes
- Martin Mares: PCI ids, email address update
- David Miller: revert TCP hash optimizations that need more checking
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc)
- Peter Anvin: cramfs/zisofs missing pieces
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache
- me: clena up page dirty handling
- Tim Waugh: parport IRQ probing and documentation fixes
- Greg KH: USB updates
- Michael Warfield: computone driver update
- Randy Dunlap: add knowledge about some new io-apics
- Richard Henderson: alpha updates
- Trond Myklebust: make readdir xdr verify the reply packet
- Paul Mackerras: PPC update
- Jens Axboe: make cpqarray and cciss play nice with the request layer
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000
- Richard Gooch: devfs symlink deadlock fix
- Anton Altaparmakov: make NTFS compile on sparc
pre7:
- me: reinstate "delete swap cache on low swap" code
- David Miller: ksoftirqd startup race fix
- Hugh Dickins: make tmpfs free swap cache entries proactively
pre6:
- me: remember to bump the version number;)
- Hugh Dickins: export "free_lru_page()" for modules
- Jeff Garzik: don't change nopage arguments, just make the last a dummy one
- David Miller: sparc and net updates (netfilter, VLAN etc)
- Nikita Danilov: reiserfs cleanups
- Jan Kara: quota initialization race
- Tigran Aivazian: make the x86 microcode update driver happy about
hyperthreaded P4's
- me: shrink dcache/icache more aggressively
- me: fix up oom-killer so that it actually works
pre5:
- Andrew Morton: remove stale UnlockPage
- me: swap cache page locking update
pre4:
- Mikael Pettersson: fix P4 boot with APIC enabled
- me: fix device queuing thinko, clean up VM locking
pre3:
- René Scharfe: random bugfix
- me: block device queuing low-water-marks, VM mapped tweaking.
pre2:
- Alan Cox: more merging
- Alexander Viro: block device module race fixes
- Richard Henderson: mmap for 32-bit alpha personality
- Jeff Garzik: 8139 and natsemi update
pre1:
- Michael Warfield: computone serial driver update
- Alexander Viro: cdrom module race fixes
- David Miller: Acenic driver fix
- Andrew Grover: ACPI update
- Kai Germaschewski: ISDN update
- Tim Waugh: parport update
- David Woodhouse: JFFS garbage collect sleep
That's nice, but its not really news...
by
Nailer
·
· Score: 5, Interesting
There's so many interesting userspace apps slashdot could write about. Unless the kernel has some new feature or fixes a major secutiy hole, I personally don't see how interesting each minor release is. Slashdot isn't freshmeat.
If/. is going to write about apps, why not focus on the new and clever ones - like
* MPlayer allowing us to play WMVs under out OS of choice
* Xine, finally maturing into a solid high quality DVD player
* Partimage providng a useful and open source disk imaging system
* Ximian's setup tools beta making an X config tool that doesn't suck
OI don't have anything against the kernel, but we all know there's always goiung to be a new kernel every couple of weeks. There's so many interesting userspace Open Source projects we could be hearing about.
After all, isn't the point of an OS to run *apps*?
On 31 Oct 2001, Michael Peddemors wrote:
>
> Lets' let this testing cycle go a little longer before making any
> changes.. Let developers catch up..
My not-so-cunning plan is actually to try to figure out the big problems
now, then release a reasonable 2.4.14, and then just stop for a while,
refusing to take new features.
Then, 2.4.15 would be the point where I start 2.5.x, and where Alan gets
to do whatever he wants to do with 2.4.x. Including, of course, just
reverting all my and Andrea's VM changes;)
I'm personally convinced that my tree does the right thing VM-wise, but
Alan _will_ be the maintainer, and I'm not going to butt in on his
decisions. The last thing I want to be is a micromanaging pointy-haired
boss.
(2.5.x will obviously use the new VM regardless, and I actually believe
that the new VM simply is better. I think that Alan will see the light
eventually, but at the same time I clearly admit that Alan was right on a
stability front for the last month or two;)
> My own kernel patches I had to stop because I couldn't keep up.... Can
> we go a full month with you just hitting us over the head with a bat
> yelling 'test, dammit, test', until this is tested fully before
> releasing another production release?
I think we're really close.
[ I'd actually like to thank Gary Sandine from laclinux.com who made the
"Ultimate Linux Box" for an article by Eric Raymond for Linux Journal.
They sent me one too, and the 2GB box made it easier to test some real
highmem loads. This has given me additional load environments to test,
and made me able to see some of the problems people reported.. ]
But I do want to make a real 2.4.14, not just another "final" pre-kernel,
and let that be the base for a reasonably orderly switch-over at 2.4.15
(ie I'd still release 2.4.15, everything from then on is Alan).
Linus
-- w o r l d w i d e w e b e r
Version niceness
by
Anonymous Coward
·
· Score: 5, Funny
The 2.4 kernel will be complete only when it reaches the "Version Niceness" factor, that is version 2.4.24.
Useless point...
by
LSD-OBS
·
· Score: 5, Informative
"from the 14-and-counting dept."
We're actually at 15 (not 14) and counting - kernel version numbers are 0-based, and sequential.
Sorry moderators - I just had to:)
-- Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
Re:why is this news?
by
jfmiller
·
· Score: 5, Insightful
Normally I just lurk but I feel the need to disagree with Mr. Grimes.
I like many who read Slashdot am a linux enthusiast. I appriciate having a place where my OS of choice is reported on with the zeal and timeliness that Microsoft gets in the main stream press. Slashdot is one of the few sights I read on a daily basis, and I for one appriciate hearing about the new kernels. along with the rest of the pertinante Tech news.
My local paper still lists The High School football team's results on the front page every Saturday during the fall, even though most of it's readers dont have kids on the HS football team. It builds a sence of community pride wich is greater than the information that is contained or it's relevance to peoples lives.
Kernel anouncements on slashdot are appriciated by me and I hope a great many other readers. And even if there are only a few of us Linux is one of the things that form Slashdot's Community, and therefore in the interest of Community pride I encourage CT to continue to post all the kernel updates.
JFMILLER
-- Strive to make your client happy, not necessarly give them what they ask for
Re:Changes/Improvements
by
brer_rabbit
·
· Score: 5, Insightful
The ChangeLog definitely needs some verbosity. The word to the wise is "only update if you need to", yet viewing the changelog leaves one wondering if they need the newer software.
What exactly do entries like "shrink dcache/icache more aggressively" or "random bugfix" mean? The former I'd guess has to do with data and instruction caches, but what aggressively shrinking does to them I have no clue without a more context. And the latter, "random bugfix", I hit my coworkers over the head when I see that in our CVS logs.
So is my current kernel effected? Am I missing out by not having my dcache/icache shrunk more aggressively? Or maybe those random bufixes effect me? A little more verbosity in the ChangeLog would go a long way. Having to follow the hacker's mailing list is not an option, this should be included in the release notes.
Re:call it what it is
by
Arandir
·
· Score: 5, Insightful
Linus really, really, REALLY needs to start the 2.5.x branch.
Stable branches need to be stable. Do all of the new feature experimentation in unstable. It's gotten to the point now that "stable" has become a meaningless word in linuxland.
Next time around, let's fork off 2.7.0 at the same time 2.6.2 is released. Or maybe Linux needs to split into three branches: "flimsy" for experimentation and VM wars, "unstable" for up-to-date hardware support but no new features, and "stable" which only gets bug and security fixes.
-- A Government Is a Body of People, Usually Notably Ungoverned
2.4.14 not ready yet either
by
(startx)
·
· Score: 5, Informative
looks like this one isn't ready yet either. loop.c needs some sergery, or else the whole thing won't even compile, dying at
drivers/block/block.o: In function `lo_send':
drivers/block/block.o(.text+0x894f): undefined reference to `deactivate_page'
drivers/block/block.o(.text+0x8999): undefined reference to `deactivate_page'
make: *** [vmlinux] Error 1
it's allready been posted to the lkml, look for a 2.4.15-pre1 or at least a loop.c patch to come around soon.
New ./ feature idea
by
Atilla
·
· Score: 5, Insightful
Ok, how about this -
maybe major kernel release posts should go in their own category, so whiners could set their user prefs to not display them.
-- ---
sig moved for great justice.
I'll throw in my own plug, then!
by
jd
·
· Score: 5, Interesting
For those wanting to try the pre-emptible kernel patch, the HP scheduler-plugin, compressed memory hardware, STP, XFS, JFS, Linux on an old VMS box, any one of a number of VME crates, serial-based network controllers, or the various latency clean-ups, then you could always try the FOLK kernel seris. FOLK 2.3.0 is stable (gasp!) and provides more today than the first fifty 2.5.x kernels are likely to.
(And by the time those come out, FOLK will be comparable to Linux 2.7.0 in terms of features & performance.)
-- It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Slashdot Mirror
More readable version.
;)
final:
- David Miller: sparc/scsi scatterlist fixes
- Martin Mares: PCI ids, email address update
- David Miller: revert TCP hash optimizations that need more checking
- Ivan Kokshaysky/Richard Henderson: alpha update (atomic_dec_and_lock etc)
- Peter Anvin: cramfs/zisofs missing pieces
pre8:
- Andrea: fix races in do_wp_page, free_swap_and_cache
- me: clena up page dirty handling
- Tim Waugh: parport IRQ probing and documentation fixes
- Greg KH: USB updates
- Michael Warfield: computone driver update
- Randy Dunlap: add knowledge about some new io-apics
- Richard Henderson: alpha updates
- Trond Myklebust: make readdir xdr verify the reply packet
- Paul Mackerras: PPC update
- Jens Axboe: make cpqarray and cciss play nice with the request layer
- Massimo Dal Zotto: SMM driver for Dell Inspiron 8000
- Richard Gooch: devfs symlink deadlock fix
- Anton Altaparmakov: make NTFS compile on sparc
pre7:
- me: reinstate "delete swap cache on low swap" code
- David Miller: ksoftirqd startup race fix
- Hugh Dickins: make tmpfs free swap cache entries proactively
pre6:
- me: remember to bump the version number
- Hugh Dickins: export "free_lru_page()" for modules
- Jeff Garzik: don't change nopage arguments, just make the last a dummy one
- David Miller: sparc and net updates (netfilter, VLAN etc)
- Nikita Danilov: reiserfs cleanups
- Jan Kara: quota initialization race
- Tigran Aivazian: make the x86 microcode update driver happy about
hyperthreaded P4's
- me: shrink dcache/icache more aggressively
- me: fix up oom-killer so that it actually works
pre5:
- Andrew Morton: remove stale UnlockPage
- me: swap cache page locking update
pre4:
- Mikael Pettersson: fix P4 boot with APIC enabled
- me: fix device queuing thinko, clean up VM locking
pre3:
- René Scharfe: random bugfix
- me: block device queuing low-water-marks, VM mapped tweaking.
pre2:
- Alan Cox: more merging
- Alexander Viro: block device module race fixes
- Richard Henderson: mmap for 32-bit alpha personality
- Jeff Garzik: 8139 and natsemi update
pre1:
- Michael Warfield: computone serial driver update
- Alexander Viro: cdrom module race fixes
- David Miller: Acenic driver fix
- Andrew Grover: ACPI update
- Kai Germaschewski: ISDN update
- Tim Waugh: parport update
- David Woodhouse: JFFS garbage collect sleep
There's so many interesting userspace apps slashdot could write about. Unless the kernel has some new feature or fixes a major secutiy hole, I personally don't see how interesting each minor release is. Slashdot isn't freshmeat.
/. is going to write about apps, why not focus on the new and clever ones - like
If
* MPlayer allowing us to play WMVs under out OS of choice
* Xine, finally maturing into a solid high quality DVD player
* Partimage providng a useful and open source disk imaging system
* Ximian's setup tools beta making an X config tool that doesn't suck
OI don't have anything against the kernel, but we all know there's always goiung to be a new kernel every couple of weeks. There's so many interesting userspace Open Source projects we could be hearing about.
After all, isn't the point of an OS to run *apps*?
From: Linus Torvalds
;)
;)
.... Can
CC: Kernel Mailing List
On 31 Oct 2001, Michael Peddemors wrote:
>
> Lets' let this testing cycle go a little longer before making any
> changes.. Let developers catch up..
My not-so-cunning plan is actually to try to figure out the big problems
now, then release a reasonable 2.4.14, and then just stop for a while,
refusing to take new features.
Then, 2.4.15 would be the point where I start 2.5.x, and where Alan gets
to do whatever he wants to do with 2.4.x. Including, of course, just
reverting all my and Andrea's VM changes
I'm personally convinced that my tree does the right thing VM-wise, but
Alan _will_ be the maintainer, and I'm not going to butt in on his
decisions. The last thing I want to be is a micromanaging pointy-haired
boss.
(2.5.x will obviously use the new VM regardless, and I actually believe
that the new VM simply is better. I think that Alan will see the light
eventually, but at the same time I clearly admit that Alan was right on a
stability front for the last month or two
> My own kernel patches I had to stop because I couldn't keep up
> we go a full month with you just hitting us over the head with a bat
> yelling 'test, dammit, test', until this is tested fully before
> releasing another production release?
I think we're really close.
[ I'd actually like to thank Gary Sandine from laclinux.com who made the
"Ultimate Linux Box" for an article by Eric Raymond for Linux Journal.
They sent me one too, and the 2GB box made it easier to test some real
highmem loads. This has given me additional load environments to test,
and made me able to see some of the problems people reported.. ]
But I do want to make a real 2.4.14, not just another "final" pre-kernel,
and let that be the base for a reasonably orderly switch-over at 2.4.15
(ie I'd still release 2.4.15, everything from then on is Alan).
Linus
w o r l d w i d e w e b e r
The 2.4 kernel will be complete only when it reaches the "Version Niceness" factor, that is version 2.4.24.
"from the 14-and-counting dept."
:)
We're actually at 15 (not 14) and counting - kernel version numbers are 0-based, and sequential.
Sorry moderators - I just had to
Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
Normally I just lurk but I feel the need to disagree with Mr. Grimes.
I like many who read Slashdot am a linux enthusiast. I appriciate having a place where my OS of choice is reported on with the zeal and timeliness that Microsoft gets in the main stream press. Slashdot is one of the few sights I read on a daily basis, and I for one appriciate hearing about the new kernels. along with the rest of the pertinante Tech news.
My local paper still lists The High School football team's results on the front page every Saturday during the fall, even though most of it's readers dont have kids on the HS football team. It builds a sence of community pride wich is greater than the information that is contained or it's relevance to peoples lives.
Kernel anouncements on slashdot are appriciated by me and I hope a great many other readers. And even if there are only a few of us Linux is one of the things that form Slashdot's Community, and therefore in the interest of Community pride I encourage CT to continue to post all the kernel updates.
JFMILLER
Strive to make your client happy, not necessarly give them what they ask for
The ChangeLog definitely needs some verbosity. The word to the wise is "only update if you need to", yet viewing the changelog leaves one wondering if they need the newer software.
What exactly do entries like "shrink dcache/icache more aggressively" or "random bugfix" mean? The former I'd guess has to do with data and instruction caches, but what aggressively shrinking does to them I have no clue without a more context. And the latter, "random bugfix", I hit my coworkers over the head when I see that in our CVS logs.
So is my current kernel effected? Am I missing out by not having my dcache/icache shrunk more aggressively? Or maybe those random bufixes effect me? A little more verbosity in the ChangeLog would go a long way. Having to follow the hacker's mailing list is not an option, this should be included in the release notes.
Linus really, really, REALLY needs to start the 2.5.x branch.
Stable branches need to be stable. Do all of the new feature experimentation in unstable. It's gotten to the point now that "stable" has become a meaningless word in linuxland.
Next time around, let's fork off 2.7.0 at the same time 2.6.2 is released. Or maybe Linux needs to split into three branches: "flimsy" for experimentation and VM wars, "unstable" for up-to-date hardware support but no new features, and "stable" which only gets bug and security fixes.
A Government Is a Body of People, Usually Notably Ungoverned
looks like this one isn't ready yet either. loop.c needs some sergery, or else the whole thing won't even compile, dying at
drivers/block/block.o: In function `lo_send':
drivers/block/block.o(.text+0x894f): undefined reference to `deactivate_page'
drivers/block/block.o(.text+0x8999): undefined reference to `deactivate_page'
make: *** [vmlinux] Error 1
it's allready been posted to the lkml, look for a 2.4.15-pre1 or at least a loop.c patch to come around soon.
Ok, how about this -
maybe major kernel release posts should go in their own category, so whiners could set their user prefs to not display them.
--- sig moved for great justice.
(And by the time those come out, FOLK will be comparable to Linux 2.7.0 in terms of features & performance.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)