Linux 2.6.17 Released
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"
I have this now installed in my dual core AMD and the difference is noticable. X is noticable faster, as is my video editing stuff. Good work guys!
Humor from a Genetically Molested Mind
I'm still pretty new to the Linux scene (So far I've done a FreeBSD, Ubuntu and Fedora Core 4 installation.), but I do have a question.
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?
No you can't, although that fact had slipped my mind. How sad for C. The real question here then is: why isn't there a better language than C for creating OSs in? A real macro system and overloading would probably be nice for kernel dev.s everywhere.
Philosophy.
1, there exists no protocol called h.323 There exists a h.323 standard that references protocols such as h.225 h.245 etc. but there is no h.323 protocol.
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?
I downloaded this kernel earlier in the day, and after having gone through the apparent changes, it seems like I cannot find the driver for my webcam. This webcam uses the ov511 driver - does anyone know if it was moved somewhere? In 2.6.16 (.11 is the last patch I have) it was in Device Drivers -> USB support -> USB OV511 Camera support. I'm reluctant to upgrade if this driver isn't in there - anyone have any idea where it might have gone?
Because C is fast, and there is so much already written in C, that it would be a pain to move over. There are a lot of hacks in the linux kernel (they actually use GOTO statements! *gasp*). I can tell you it was a real eye-opener for me when I started looking at things there. I'm sure the reason nobody has moved over to a better language though is because of the massive amounts of work that would have to be redone.
Don't count your messages before they ACK.
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."
Please help metamoderate.
It seems you can crash the box by hitting a race condition in the quota code. You get a "kernel bug in dquot.c" and the machine goes down - hard. One of the changelog entries seems to address this. The question is: will this get backported into the distro kernels? Red Hat, help!
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.
You listed I/O schedulers. I think the multi-core bit talks about a PROCESS scheduler. Two different things. Linux already has specific support for Intel's HTT bullshit and understands NUMA. Understanding multi-core is a good move up.
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
Someday, I'll have a real sig.
I think they've added the driver to support the IR infrared port on IBM (Lenovo) thinkpads, at last!
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.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Bloody hell!
/ dissectors/packet-per.c )
is way larger than that, and that is just aligned PER decoding (ok with some unaligned PER additions recently) and that one itself is >>20kbyte. Adding 225/245 into the mix. Impossible!
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.
Will ubuntu have it soon ?
:( , so it just doesn't work, people claim it has something
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.
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
Looks a good laptop. The only trouble I have ever had with laptops/Linux are: 1) internal modem doasnt work (M$ modems - who cares anyway) 2) might need to disable apic at boot time (will be obvious - machine just wont boot. Add "noapic" to you kernel boot parameters if this is the case) Nvidia drivers can be downloaded from their web site - not open source though :(
>/dev/null 2>&1
DCCP - a kind of UDPv2
Any applications out there using it yet?
Get your own free personal location tracker
Does somebody know for what purposes the klibc which is now in -mm will be used for? I guess this implementation will only provide a subset of the features found in uclibc, but i am not sure about that. Will it even be possible to link userspace programs against it?
I am a little confused right now, have to read up on it.
My blog & programming projects
Wow, looks like a sweet machine.
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
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 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.
Looking through the ChangeLog, I still see no S-ATA hotplug. I've been waiting more or less since the day S-ATA support was introduced in Linux to be able to add new drives without rebooting, and I just cannot understand how such a thing can take so long. I mean, I'm sure that the kernel developers have priorities and stuff, but I would think that adding S-ATA hotplug ought to be simple and important enough not to take more than a year to even get started...? I don't mean it as a complaint, I just find it really weird. Is it just much harder than I think, or is there no particular reason for it not having been done?