Linux Kernel 2.6.21 Released

diegocgteleline.es writes "Linus Torvalds has released Linux 2.6.21 after months of development. This release improves the virtualization with VMI, a paravirtualization interface that will be used by Vmware. KVM does get initial paravirtualization support along with live migration and host suspend/resume support. 2.6.21 also gets a tickless idle loop mechanism called 'Dynticks', built in top of 'clockevents', another feature that unifies the timer handling and brings true high-resolution timers. Other features are: bigger kernel parameter-line, support for the PA SEMI PWRficient CPU and for the Cell-based 'celleb' Toshiba architecture, NFS IPv6 support, IPv4 IPv6 IPSEC tunneling, UFS2 write, kprobes for PPC32, kexec and oprofile for ARM, public key encryption for ecryptfs, Fcrypt and Camilla cipher algorithms, NAT port randomization, audit lockdown mode, some new drivers and many other small improvements."

Published?

[CastrTroy]

What's with the headline? Who publishes OS kernels? I guess it could be grammatically correct and all that, but it sounds a little weird to me.

Bloat?

[ArcherB]

Is it just me, or are all these options that are added with every new release going to result in a bloated kernel? It seems like every release adds new stuff, but I never see anything outdated taken away.

Yes, I know that you can recompile and remove what you don't need, but most "non-uber-geek" users are not going to be able to handle that, and most distros are going to include a kernel with the kitchen sink compiled in.

KVM management?

[drinkypoo]

Speaking of KVM (slightly offtopic, but not totally) are there any worthwhile management utilities for it yet? I actually ended up giving up for a while on KVM entirely because the video device is horribly slow and VDE support is not reliable, and I'm using vmware server, but I did have to give it a try. I'd love to use KVM (since I have supported hardware and it's Free software, and I'd love to minimize my use of the closed stuff) but beyond those problems (which will hopefully both be fixed relatively soon) there is simply no decent management software unless you're on redhate. Either virt-manager or libvirt is badly broken and won't work properly otherwise. UNLESS... has anyone out there gotten it working on debian/Ubuntu yet? I tried for a while, but I'm just not a good enough programmer and the programs ain't done yet.

Re:Bloat?

[qbwiz]

most distros are going to include a kernel with the kitchen sink compiled in.

No, most distros are going to include a kernel with the kitchen sink compiled as modules, taking up a few megabytes on the hard drive, but never loaded.

Re:Bloat?

[Lxy]

I've noticed that each time I compile a new kernel, something has been moved to [deprecated] status that was still live in the last release. All the deprecated stuff is not compiled in by default, keeping the resulting bzImage size manageable.

Most distros compile everything as modules, which generally keeps the overall size of the kernel down. Sure, bzImage grows over time (not just because of new features, but typically new patches == more lines of code), but not significantly from release to release.

Most "non-uber-geek" users don't care what's in their kernel, and if they did, they'd learn to compile it themselves. Compiling kernels has gotten easier over the years. Chances are, if you care enough about how your kernel is compiled, you'll have the skills needed to do it yourself.

Cool, but...

[asninn]

That's cool, but is this really news that's Slashdot-worthy? Sites like LWN and KernelTrap have already reported this, and anyone who's interested in Linux development is pretty much guaranteed to follow the former at least, I think (and most likely the latter as well).

Re:Bloat?

[arth1]

Even if you compile something as modules, it does take up memory and resources. Much less, but still not negligible. There's hooks for the modules, plus tests in other parts on whether a module is loaded or not, in addition to much larger symbol tables.
And, of course, there's many parts that can not be made into modules at all, but have to be part of the kernel. And that makes a HUGE difference.

Is the difference really that big? Well, the machine I'm currently on has a bzipped kernel that's around 1.5 MB in size plus a 820 kB map. The alternative boot to a commercial distro (no name, no shame) has a bzipped kernel that's around 2.1 MB, plus a 2.3 MB initrd, plus a 1.2 MB System map.

The difference might not be staggering, but it's there, and the kernel is growing with each revision. Here's how the System.map has grown for the last few revision on this laptop, with no new options added:


-rw-r--r-- 1 root root 754620 Nov 30 18:32 System.map-2.6.17-gentoo-r8
-rw-r--r-- 1 root root 768275 Dec 28 15:57 System.map-2.6.18-gentoo-r6
-rw-r--r-- 1 root root 809157 Mar 26 04:28 System.map-2.6.19-gentoo-r5
-rw-r--r-- 1 root root 839371 Apr 25 22:45 System.map-2.6.20-gentoo-r6


That's an 11% increase without adding anything. Similar for the kernel itself (although that's harder to compare directly, due to the bzip2 compression). While not alarming, it's a trend towards feeping creaturitis that I think bears watching.

Re:You joke,

[hypnagogue]

A change to the ABI.

Oh, sorry, I didn't realize it was a rhetorical question.

Re:Cool, but...

[npsimons]

That's cool, but is this really news that's Slashdot-worthy? Sites like LWN and KernelTrap have already reported this, and anyone who's interested in Linux development is pretty much guaranteed to follow the former at least, I think (and most likely the latter as well).

Considering that slashdot was (note the past tense) first and foremost a Linux/all things geeky site, I'd say this article is very slashdot-worthy. Not to mention that we get a fawning mac fan boy article every time Steve Jobs so much as farts. At least the Apple section can be turned off. Wish I could do the same with Microsoft and Windows articles.

No, it's just the hardware

[mangu]

people could come in and replace the Linux kernel with BSD, Darwin, or Solaris and I probably wouldn't notice.

This means your CPU is much more powerful than what you really need. I used FreeBSD a bit in the 1990s, but switched to Linux because the kernel allowed me better fine tuning in the 486 CPU I had at the time.

Today the CPU is way over my needs too, but I stick to Linux because, first, I have no need to switch and, second, Linux has better hardware support than the others you mentioned.

Re:Bloat?

[Grishnakh]

I've almost decided that the computer programming age, as an affordable hobby for the non-specialist, is nearing the end of its lifetime. In a few more years you'll have the option of working with entirely standardized/commoditized/completely controlled (corporate DRM style) equipment or, if that doesn't appeal to you, then you'll have to go off a polar deep end and spend absolute bricktons of time and money assembling a system using a soldering iron, a breadboard, and specialty chips ordered from remote clearinghouses in China or Russia.

WTF are you talking about? Programming has become far more accessible to everyone in the last 20 years, and much of this is because of the rise of OSS. You just talked about Linux, KDE, Gnome, Xorg/Xfree86, etc., which are all OSS applications, developed and contributed to by thousands of hobbyists (as well as professionals). There's countless smaller projects developed entirely by hobbyists, focused on very specific niches, such as people who write small applications to support their other hobbies (ham radio, electronics, knitting, or whatever) and put them on sourceforge so other hobbyists will help them out. All this is a phenomenon that did not exist in a meaningful form back in, say, 1990, before OSS software became popular and the internet/WWW become commonplace.

Locked-down corporate-controlled DRM-infected computers are still a real danger, but the way things are currently going, I don't see this becoming a reality unless the US Government mandates it through legislation. We've already seen the beginnings of DRM lock-down with copy-protected CDs and DVDs which don't work worth a damn, and Windows Vista which is having all kinds of problems because of its excessive DRM. While I don't think Windows is going to go away in the next 5 years, I don't think we're all going to be forced into using DRMed Vista-running Dells in 5 years either, with Newegg.com out of business because building your own system is illegal.

Re:Bloat?

[Anonymous Coward]

2.6 and recent kernels in general are aimed at *modern computers*. Modern computers that have a *lot* more features and devices than ever before. There is absolutely no comparison to kernels back in the floppy days. If you're still using floppies you might as well be using an old kernel for whatever weathered machine you're talking about. And a microkernel's not going to reduce the overall amount of code, just push it around.

Not to mention that people who are using Linux for embedded work can still rip out a ton of stuff. You can completely omit module support and all sorts of things that contribute to so-called "bloat." The kernel is still and always has been very flexible about compiling in features, and all the code's there to mess with...

Small, fast, full of features; pick two. I think.

Re:Bloat?

[xenocide2]

Pray tell, how did you eliminate the possibility of existing components growing, in order to conclude modularity itself is the problem?

Re:Bloat?

[shish]

I don't see this becoming a reality unless the US Government mandates it through legislation

The common sense of the US Government is the only thing standing between us and DRM hell? Oh dear :(

Re:Published?

[tomatensaft]

Note, that it's "to release" in English. :)