Blubber-wrapped Linux kernel 2.6.30 hits the decks
Well-oiled 'Man-Eating Seals of Antiquity' surfaces
Ensure Ease of Recovery with Asigra’s Agentless Software
A new version of the Linux kernel has been unleashed, 2.6.30 — dubbed "Man-Eating Seals of Antiquity" — just three months on from Linus Torvalds’s previous release.
The latest Linux kernel sped through eight release candidates before it landed yesterday.
"I'm sure we've missed something, and I know we have some regressions pending," noted the big daddy of Linux in a newsgroup message penned on Wednesday.
"At the same time, we do need the coverage of a eral [sic] release, and on the whole it looks pretty good. We've fixed a few regressions in the last few days, and there's always 2.6.30.x," said Torvalds.
Changes in the latest version include beefed-up data security of the Ext4 file system.
Version 2.6.30 offers better ways and means of reconfiguring software RAIDS, there's also support built in for two additional file systems.
Memory management code has also been revamped, and there are various changes to the PCI and power management features in the Linux kernel too, in an attempt to improve its system hibernation mode.
The full list of tweaks can be viewed here.
"One thing that doesn't seem to be mentioned there [in the newbie notes] is that we're hopefully now done with the suspend/resume irq re-architecting, and have switched to a new world order. Although I suspect lots of details will still change, of course," said Torvalds.
"And as usual, I'll wait a day or two before really opening the merge window. I want people to actually test this one rather than immediately sending me 'please pull' requests. Deal?" ®
COMMENTS
Kernel versioning
There was quite a good interview with Linus some time ago on versioning. I recall that there just wasn't the need to keep odd number development forks, things are pretty modular and have been really robust. Much of the work that used to happen in the odd series appears to be happening in patch sets, you can build 2.6.30 and decide to pull in the bleeding edge patches from your favourite maintainer for just the bits that you want to be bleeding edge.
Bloat: explanation
Actually the Linux kernel is quite good. What I meant by "bloated" is that it does a lot of things that are not supposed to be the kernel's job. It does a nice job of it, too. But at some point it causes problems. Amongst others, as highlighted by the numerotation silliness, it makes evolution a hard, arcane process. A microkernel that does its kernel job, and only his kernel job (which is basically assigning CPU time to task, or the other way round if you prefer) and let outside "servers" deal with almost everything else, makes more sense. More compat work involved (and, admitedly, a lot of compat problems to be expected when you mix servers and kernel of different ages), but still makes more sense. The module approach is a sort of compromise, but as a result the kernel still ends up doing many things that it shouldn't be doing.
I don't mind rebuilding modules each time I fiddle with the kernel, but as a famous -though fictional- scrivener put it, I'd prefer not to.
And also, as I said, modules are only a compromise, which means that not only do I have to build most of them by hand, but also I have to install a whopping 300 MB package if I want reasonable basic hardware support (OK, not Linus' fault, my distro is to blame here, but it's part of the "kernel does what kernel shouldn't do" problem). Which means keeping two such packages concommitently in the relevant partition -albeit for a short time- upon upgrade. And this is a no-no on most of my machines. I could just increase the size of said partitions, but again, I'd prefer not to. Or I could just use a large virtual machine to compile the bare kernel, build the modules, create my package and deploy that. But I'd prefer not to. And it would still be needlessly large. With a microkernel and suitably backward-compatible servers, I would be able to upgrade the whole system, minute amounts at a time. It allows for faster developpment and easier vuln patching, too. GNU's Hurd seems promising to me. I'll be waiting for it to be ready, reporting problems from time to time... or I could contribute more actively, but of course, as you'll have understood by now, I'd prefer not to! ;-)
While I'm on a rant...
"re-architecting"
Could the person who wrote that be taken out and shot, NOW.
I don't care if it is Linus, I don't care if it was Lucy or Charlie Brown, that is a criminal act against language.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
