Slashdot Mirror
Linux 2.6.22 Kernel Released
An anonymous reader writes "Linux creator Linus Torvalds announced the official release of the 2.6.22 kernel: 'It's out there now (or at least in the process of mirroring out — if you don't see everything, give it a bit of time).' The previous stable kernel, 2.6.21, was released a little over two months ago. New features in the 2.6.22 kernel include a SLUB allocator which replaces the slab allocator, a new wireless stack, a new Firewire stack, and support for the Blackfin architecture. Source-level changes can be tracked via the gitweb interface to Linus' kernel tree."
There for you, help yourself.
BTW in short plain english, it adds some voodoo stuff to struct page, removes a lot of metadata cruft from the slab allocator, adds lesser and simple locking after removing most of locks which are not required because of the changes in the cache layer.
So if you are running your kernel on a huge farm of processors of the order of thousand(s), you ll find a remarkable memory saving, which is a big overhead in slab allocation.
HTH
-- "Genius is 1% inspiration and 99% perspiration" - TAE --
Anyways, I was thinking of adding one of these USB wireless accessories.. could anybody here recommend one that has a good track record of working in linux ?
I would recommend using one of the PCMCIA cards instead. Find one that uses the Anthros chipset. I picked up a D-LINK one that was recognised by Dapper Drake. I didn't need to install NDIS Wrapper of Network Manager. I don't remember the model number of the card, but setting it up was as easy as setting it up in Windows except I didn't need to use the setup CD that came with it. Dapper recognised it as an Unknown Wireless. Properties showed it has an Anthros chipset made by D-Link. From there I gave it a static IP on my LAN and plugged in the WEP key after picking my SSID from a list. I added some DNS listings and put in the gateway address of my router and I was online. There have been some difficulty with configuring many of the USB cards. Check the forums and purchase carefully.
The truth shall set you free!
Indeed, you are a double pleonasm, and should take pride in your superfluous redundancy.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Second now there are less threads in the firewire subsystem, which is indeed good because kernel threads are really really a very stupid idea.
Last but not the least i have used TI firewire chipset with Basler IEE1394 cameras under Linux and trust me they knock teeth out of Windows Firewire stack.It was good and performed good even with two cameras working in real time image inspections.
I suspect the current stack is going to work atleast similar if not better, though i ll bet on it being better.This is a good sign also, as there is no point in patching things but point is in writing the whole messy thing again.And here we are.... hey wait TTY layer ...any takers? please :-)
-- "Genius is 1% inspiration and 99% perspiration" - TAE --
"Because Linus said so" is in fact not a particularly valid answer. Yes, Linus has the right to choose the development structure the kernel is now using, but that doesn't mean it is the best way to do it for everybody. dropping the distinction between "stable" and "development" versions was a sloppy, lazy move that simply pushed the responsibility for maintaining stable released off onto the distributors. That has essentially duplicated the work a hundred-fold, because each distribution must do the work themselves. We're told that this is a "better" arrangement, but it is clearly only better for Linus and the kernel developers, because they get to do less work and be lazy when it comes to making changes: "Want to rip out the allocator and replace it with a largely untested one? Sure, why not! Making sure everything works is the distributors problem, not ours!"
Except that the old system didn't work at all. There were just too many changes to stabilize in any reasonable amount of time and while the debugging was happening the 2.4.x kernel was becoming so badly out of date that people (and distros) tried to back port changes from the 2.5.x tree.
The result was TWO unstable kernel trees and the vendor trees had a tendency to be even worse. The old system would have left those people using SATA in a worse situation then they are in now. Keep in mind that SATA came out after 2.6.x so the drivers would right now be somewhere in the 2.7.x series kernel still waiting to be debugged and the stable maintainers would be forced to try and backport the SATA drivers once again resulting in two unstable kernels