Slashdot Mirror
Linux Beta Kernel 2.5.16 Out
dipfan writes "The latest beta version of the Linux kernel 2.5.16 is out, with some comments by Linus here, who was kept 'personally somewhat busy' by 'the interesting Intel SMP-P4 TLB corruption bug, which ends up being due to some very funky asynchronous speculative TLB fill logic'. Woo hoo. Mirrors, etc." We haven't been keeping up with the 2.5.x series, but a slow Sunday is a good excuse to catch up.
Anyone wanna start betting when the dev kernel will surpass the stable kernel? 3 versions to go....
It's really not that fantastic. 2.5 will probably go pretty high. The 2.3 kernel went to 2.3.51 before it jumped to 2.3.99 (look here).
It will be interesting how much work goes into 2.5 before 2.6.0 is released. Then we'll be able to start comparing what's new to 2.4.x. It is interesting that we're at 2.4.19 when the 2.2. kernel is at 2.2.20, IMHO.
My Karma was at 49, then they switched to words. All that work for nothing!
No, it's a Linux bug not a P4 bug. The kernel was freeing page table memory before invalidating the TLB entries, so another processor was able to modify the entries which the originating processor then picked up. It affects all architectures, but was discovered only on P4, I would guess because the processor does more aggressive speculative page walks than other architectures.
Well, for one thing, there are a lot of IDE updates and fixes going in for 2.4.19, which is why there are so many 19-pre* releases...
And as another poster has said, a backport of the *working* NTFS-NG driver!
The Free desktop that Just Works
Not quite out yet, but watch this space.
~jeff
Not to mentioned gcc 3.1 being released a couple of days ago, and being buried in the Developers section...
As far as I can tell, they haven't been applied in the development series because that series is focusing on other things like the various I/O parts. Making any changes to the VM system while the I/O layer is in flux is sure to cause problems, even if the changes are correct, because they'll change the load on it and hide some bugs and uncover different ones. Better to get I/O done first, and then change the VM. Besides, nobody really cares about the overall performance of a development kernel, except for seeing that their changes improve performance.
I'd like to know "When will Windoze be done?"
See here
--Giving to trolls for the benefit of us all
Specifically, toolkits usually write to an X abstraction library which becomes X the protocol and then a data stream is rendered by an X client. The client can be a window on a framebuffer.
Unless the software ontop of X uses XFree specific code then you can run it on a framebuffer with X ontop.
The main problem is with X extensions but these are usually quite well programmed and most have framebuffer ports. GTK already has a framebuffer port.
I think the main point though is that it won't be much faster. X isn't slow, and there isn't any proof (only rumour) towards that argument.
--Giving to trolls for the benefit of us all