Linux 2.6.17 Released 444
diegocgteleline.es writes "After almost three months, Linux 2.6.17 has been released. The changes include support for Sun Niagara CPUs, a new I/O mechanism called 'splice' which can improve the performance greatly for some applications, a scheduler domain optimized for multicore machines, driver for the widely used broadcom 43xx wifi chip (Apple's Airport Extreme and such), iptables support for the H.323 protocol, CCID2 support for DCCP, softmac layer for the wireless stack, block queue IO tracing, and many other changes listed at the changelog"
Really helped (Score:4, Interesting)
Question for the masses. (Score:3, Interesting)
Why are the network drivers part of the kernel? It seems like this would make it more difficult to adopt newer hardware types. Also, since most computers have 1-2 NICs at the most, wouldn't that clog up the kernel with tons of drivers for hardware you'll never use?
Re:Question for the masses. (Score:5, Interesting)
Many have argued that Linus needs to stablize the kernel driver ABI. But on the other hand, by not doing so and encouraging drivers to be open source and in the kernel source tree brings us a large amount of stability that Windows just cannot achieve. Most windows stability problems are not caused by the kernel, which is as stable as Linux, but by third-party device drivers. Anyway it is a trade-off, and one that is hotly contested. Personally, everything I currently use has open source drivers that come with my kernel bundle (Fedora Core). They are loaded on demand, so they don't cause memory bloat. If I was to compile my own kernel, I could choose not to build many of the drivers, reducing the disk bloat too.
One of the biggest things for me in this kernel release is the Broadcom wireless driver. Kudos to the team that clean-room reverse engineered the driver.
Re:Go Linux! (Score:3, Interesting)
support for the h.323 protocol, quite unlikely (Score:1, Interesting)
2, even more unlikely for h.323 support is that since all the important parts of h.323 such as h.225 and h.245 are all ASN.1 PER encoded.
Are they going to add a decoder for aligned-PER inside the kernel? yeah likely.
Whatever thay have added it is not support for h.323. Maybe they have added support for RTP?
Missing driver? (Score:1, Interesting)
Re:Go Linux! (Score:3, Interesting)
module shotguns (Score:1, Interesting)
Many a linux distribution I've used (most noticeably Debian) applies the "shotgun" approach to module-loading because the hardware detection and hotplug methods are so convoluted and undependable. Kind of defeats the purpose of loadable modules if the distribution simply loads everything under the sun to see what sticks.
Worse, many modules aren't smart enough to determine "hey, I'm a driver for [some non-removable component]. If I can't find my hardware, maybe I should print an error to ksyslogd and unload myself."
Quota BUG() fixed? (Score:1, Interesting)
Re:Question for the masses. (Score:5, Interesting)
It's worth pointing out that pretty much every remotely mainstream OS *except* Linux manages to work (and work well) with a stable kernel ABI. Including ones considered at least - if not more - stable than Linux, even by Linux zealots, like FreeBSD and Solaris.
"splice" - because Microsoft did it? (Score:5, Interesting)
The "splice" system call seems to be an answer to one of Microsoft's bad ideas - serving web pages from the kernel. At one point, Microsoft was claiming that an "enterprise operating system" had to be able to do that. So now Linux has a comparable "zero copy" facility.
"Zero copy" tends to be overrated. It makes some benchmarks look good, but it's only useful if your system is mostly doing very dumb I/O bound stuff. In environments where web pages have to be ground through some engine like PHP before they go out, it won't help much.
The usual effect of adding "zero copy" to something is that the performance goes up a little, the complexity goes up a lot, and the number of crashes increases.
Re:Really helped (Score:1, Interesting)
root PCI bridge when you do a 'lspci -t' ?
Re:Question for the masses. (Score:1, Interesting)
A comparison might be, "It doesn't matter if a law is made for the right reasons, it's still made because at the end the laws are made by the House and Senate." Except Congress isn't elected, and anybody can be on it, Linus is the president for life and he also does whatever he wants.
Re:OK, so where are they? (Score:5, Interesting)
If you have a 2P dual-core setup the best performance for two independent tasks would be spread to both chips. Specially in the AMD camp. That means each task gets a full memory bus to themselves. The trick is to pick up when two tasks have shared memory between each other and schedule that for one chip. Specially on the Intel side of things with their massive shared L2 cache.
Tom
infrared for IBM thinkpads (Score:2, Interesting)
Re:Where is 2.7? (Score:5, Interesting)
Or bane. The "old way" meant that the vanilla-kernel (kernel offered by kernel.org) was stable. But new features took a LONG time to appear in the vanilla-kernel. But users and distros still wanted those advanced features that were not part of the kernel (yet). What happened was that distros offered their own vendor-kernels, that were VERY different from vanilla-kernel. Distros then spent their time and energy fixing their own vendor-kernels, instead of vanilla-kernel.
This new system changes things so that new features are added to the vanilla-kernel, which means that the difference between vanilla and vendor-kernels is not that big. The distributors can focus on stabilizing the kernel, instead of adding new features to it. And porting those fixes to vanilla is a lot easier than porting changes in the old system. This means that if you want to use REALLY stable kernel, you should use the vendor-kernel.
In short: this new system means that things progress a lot faster for everyone, with new features appearing in the kernel. And we can still have the stability we want if we use the tested and patched vendor-kernels.
Re:support for the h.323 protocol, quite unlikely (Score:3, Interesting)
They managed to squeeze both PER and also H225/235/245 into just 20kbyte of object code?!
(why implement h235? thats crypto and wouldnt work unless you know the keys?)
That is VERY impressive.
My PER decoder alone ( http://anonsvn.wireshark.org/wireshark/trunk/epan
I am very impressed. Very impressed.
Re:linux (Score:3, Interesting)
They have included much of the stuff into their version of 2.6.15.23,
but ofcourse that doesn't have everything. The broadcom driver that came
with ubuntu(same sources, maybe earlier version) has somesort of issues
with my BCM4318
to do with soft interrupt stuff.
ps. broadcom, next time make interrupts stiff.
Re:suggestions for a laptop (Score:2, Interesting)
DCCP (Score:3, Interesting)
Any applications out there using it yet?
What is the klibc for? (Score:2, Interesting)
I am a little confused right now, have to read up on it.
Re:suggestions for a laptop (Score:2, Interesting)
My advice, if you really want to be sure, take the time to go through the hardware specs and check the kernel source for drivers for each thing you definitely want to have running (be careful of versions)
You could also check out the linux on laptops site [linux-laptop.net]
Finally, I've noticed that the biggest problems for me in the past have always come in with ACPI support. This is where the most noticable improvements(*) in the kernel have come for me lately. You might want to check out the ACPI4Linux [sourceforge.net] site to see if there's anything special that's been discovered about your system yet.
* It's actually not a problem with Linux, it's a problem with the way some OEMs do ACPI using tools from M$ that the kernel guys have been doing a better and better job of working around. Who needs standards when you think you pwn the world.
S-ATA hotplug (Score:3, Interesting)
Re:Question for the masses. (Score:2, Interesting)
This is why OpenBSD is having more success than Linux in getting specs from vendors, right? Because they just let BLOBs run in the kernel? Oh, wait...
The only secure way to run binary drivers is to run them in usermode with ACLs on each hardware port and memory region they use, with safe wrappers around DMA. In fact, it's probably not even safe to trust binary drivers in this case. What if the hardware doesn't respect your computer and decides to snoop the bus on its own? It can leak information back to the driver through side channels, or worse act as a backdoor. Suppose your wireless chipset maker gets a visit from a TLA who wants immediate access to any wireless system. The driver is the place to do that, since it runs in kernel mode. Makes you wonder about all those "closed source wireless drivers are the *only way* to satisfy the FCC!" arguments.