Linus Torvalds announced the release of the 2.6.19 Linux kernel, following the previous stable kernel release by two months [story]. "It's one of those rare 'perfect' kernels," Linus joked, "so if it doesn't happen to compile with your config (or it does compile, but then does unspeakable acts of perversion with your pet dachshund), you can rest easy knowing that it's all your own d*mn fault, and you should just fix your evil ways." He went on to add, "you could send me and the kernel mailing list a note about it anyway, of course. (And perhaps pictures, if your dachshund is involved. Not that we'd be interested, of course. No. Just so that we'd know to avoid it next time)."

The latest kernel source can be downloaded from your nearest Linux Kernel archive mirror [story]. You can browse through all the changes using the gitweb interface. Kernel Newbiews also maintains a useful summary of all the changes that went into this new version of the Linux kernel, including the inclusion of three new filesystems, GFS2, ext4 [story], and eCryptfs.

A recent security advisory announced today by Rapid7 explains, "the NVIDIA Binary Graphics Driver for Linux is vulnerable to a buffer overflow that allows an attacker to run arbitrary code as root. This bug can be exploited both locally or remotely (via a remote X client or an X client which visits a malicious web page). A working proof-of-concept root exploit is attached to this advisory." The advisory goes on to note that the FreeBSD and Solaris binary drivers are also likely vulnerable to the same flaw and cautions, "it is our opinion that NVIDIA's binary driver remains an unacceptable security risk based on the large numbers of reproducible, unfixed crashes that have been reported in public forums and bug databases."

Chad Loder [bio], Rapid7's Manager of Engineering, explained that NVIDIA has known about this bug in their binary driver for some time, "the link in the advisory is the earliest thread in which we could find an NVIDIA employee publicly acknowledging the bug, although it was reported back in 2004 and has probably existed even longer." Regarding the decision to announce the exploit to the public Chad explained, "I expect (or hope) that NVIDIA will fix the defect in their binary drivers quickly. I don't know anything about their development process or where their Linux drivers fit into their priority list. It seems that the majority of Linux users are perfectly willing to accept bugs in binary blob drivers from hardware vendors, so there is little incentive for NVIDIA to change their process."

Linux creator Linus Torvalds posted an email titled, "An Ode to GPLv2" examining why he feels the GPLv2 is such a great license as an alternative way to look at the GPLv3 debate [story]. "This post is kind of another way to look at the whole GPLv3 issues," Linus explains, "not caring so much about why the GPLv3 is worse, but a much more positive 'Why the GPLv2 is _better_'." Following a lengthy preamble to explain his stance, Linus includes a comment originally posted to a Groklaw article titled GPL Upheld in Germany Against D-Link.

His Groklaw comment is in reply to a number of concerns including that the GPLv2 doesn't get specific, doesn't provide patent protection, and ignores DRM. "That's why the GPLv2 is so great," Linus replies, "exactly because it doesn't bother or talk about anything else than the very generic issue of 'tit-for-tat'." Linus explains that when he replaced his original license with the GPLv2 [story], he did it because he was looking for something that was fair. "And that's what the GPLv2 is. It's 'fair'. It asks everybody - regardless of circumstance - for the same thing. It asks for the effort that was put into improving the software to be given back to the common good. You can use the end result any way you want (and if you want to use it for 'bad' things, be my guest), but we ask the same exact thing of everybody - give your modifications back."

James Bottomley posted an article to the lkml titled, "The Dangers and Problems with GPLv3" authored by ten of the most active Linux kernel developers. The paper begins by examining the GPLv2's role in the success of the Linux kernel, then goes on to point out some potential flaws in the upcoming GPLv3. Specific issues are raised with the DRM clauses in the license, "while we find the use of DRM by media companies in their attempts to reach into user owned devices to control content deeply disturbing, our belief in the essential freedoms of section 3 forbids us from ever accepting any licence which contains end use restrictions", the additional restrictions clause, "the additional restrictions section in the current draft makes GPLv3 a pick and choose soup of possible restrictions which is going to be a nightmare for our distributions to sort out legally and get right", and the patents provisions, "as drafted, this currently looks like it would potentially jeopardise the entire patent portfolio of a company simply by the act of placing a GPLv3 licensed programme on their website." The document concludes, "the three key objections noted in section 5 are individually and collectively sufficient reason for us to reject the current licence proposal. However, we also note that the current draft with each of the unacceptable provisions stripped out completely represents at best marginal value over the tested and proven GPLv2."

The resulting discussion included a number of clarifications from Linux creator Linus Torvalds. When it was suggested that he should have specifically retained the right to modify the licensing of the entire kernel he pointed out that things work better as they are with nobody firmly in charge, "remember: the perfect is the enemy of the good. Asking for things that are perfect 'in theory' usually just results in things that are horrible 'in practice'. So not having anybody in charge could _in_theory_ cause problems. But _in_practice_ it's a hell of a lot better than somebody that people need to worry about." He also stressed that the Linux kernel is not a Free Software Foundation project, "I personally have always been very clear about this: Linux is 'Open Source'. It was never a FSF project, and it was always about giving source code back and keeping it open, not about anything else." He further clarified, "the whole 'Open Source' renaming was done largely _exactly_ because people wanted to distance themselves from the FSF. The fact that the FSF and it's followers refused to accept the name 'Open Source', and continued to call Linux 'Free Software' is not _our_ fault."

Andrew Morton [interview] posted an overview of patches in -mm, discussing what is destined for inclusion in the upcoming 2.6.18 Linux kernel. He noted, "there is an unusually large amount of difficult material here." Patch sets that were discussed include a cleanup of kernel headers, klibc, various subsystem cleanups, the ACX1xx wireless driver, swsup cleanups, per-task statistic metrics, a clocksource management infrastructure, smpnice, swap prefetching [story], priority-inheriting futexes, a revamp of /proc/pid, ecryptfs, utsname virtualization [story], readahead, reiser4 improvements, a statistics infrastructure, and lock validation code.

Following up on a couple of features discussed earlier on KernelTrap, both swap-prefetching and utsname virtualization were briefly discussed. In regards to swap-prefetching Andrew noted, "I remain skeptical, but I have a lot of RAM. Multiple people have sung its praises. I guess I'll re-review and tentatively plan on sending them along or 2.6.18. Opinions are sought." As for utsname virtualization, "this doesn't seem very pointful as a standalone thing. That's a general problem with infrastructural work for a very large new feature. So probably I'll continue to babysit these patches, unless someone can identify a decent reason why mainline needs this work. I don't want to carry an ever-growing stream of OS-virtualisation groundwork patches for ever and ever so if we're going to do this thing... faster, please."

Andrey Savochkin leads the development of the kernel portion of OpenVZ, an operating system-level server virtualization solution. In this interview, Andrey offers a thorough explanation of what virtualization is and how it works. He also discusses the differences between hardware-level and operating system-level virtualization, going on to compare OpenVZ to VServer, Xen and User Mode Linux.

Andrey is now working to get OpenVZ merged into the mainline Linux kernel explaining, "virtualization makes the next step in the direction of better utilization of hardware and better management, the step that is comparable with the step between single-user and multi-user systems." The complete OpenVZ patchset weighs in at around 70,000 lines, approximately 2MB, but has been broken into smaller logical pieces to aid in discussion and to help with merging.

With the release of the 2.6.16 Linux kernel, Adrian Bunk reiterated his previously debated intention of maintaining the 2.6.16.y kernel tree well into the future. The first 2.6.x.y release was 2.6.8.1 by Linus Torvalds [story], a quick one line fix for NFS. The idea was revisted a few months later in October of 2004 [story], but didn't actually gain momentum until March of 2005 [story] [story]. Beginning with the 2.6.11 kernel, the process was formalized with Greg KH and Chris Wright officially maintaining 2.6.x.y releases [story] until 2.6.(x+2) is released. For example, stable patches will be applied to the current 2.6.16.y kernel by Greg and Chris until 2.6.18 is released sometime well in the future.

Adrian's plan is to pick up the development of the 2.6.16.y kernel at that point, maintaining it much as the 2.4 kernel tree is is maintained [interview]. His intention is to maintain the tree as long is it is used and people contribute patches. The earlier debate on this idea was met with mixed reactions. At that time Greg KH cautioned, "the time and energy to do this for a long period of time is huge. If I were you, I would listen to the people who have and do maintain these kinds of kernels, it's not a simple job by any means."

A kernel crash dump is a snapshot of system state taken at the time that the kernel crashed, useful for finding and debugging the problem that caused the crash in the first place. There is no standard mechanism for automatiaclly collecting a crash dump on Linux, but there are a number of existing projects working toward efficiently meeting this goal. A "Linux Kernel Dump Summit" was recently mentioned on the lkml, with participants from some of the many crash dump projects looking to standardize the dump process and information collected. A followup email noted, "as memory size grows, the time and space for capturing kernel crash dumps really matter." It went on to examine partial dumps, and full dumps that are compressed. The former risks not collecting information necessary for proper debugging, while the latter risks greatly increasing the amount of time required to collect a dump.

There are a number of existing projects for collecting automatic kernel crash dumps on Linux, including Linux Kernel Crash Dump (LKCD), Mini Kernel Dump (mkdump), kdump, and diskdump (detailed here). Some of these projects also include tools for examining the obtained dumpfiles. Other projects focus just on tools for analyzing kernel crash dumps, including the perl-based Alicia (the Advanced LInux Crash-dump Interactive Analyzer) and Red Hat's crash analysis tool "loosely based on the SVR4 UNIX crash command, but significantly enhanced by completely merging it with the GNU gdb debugger."

In a conversation that began as a request to include the SAS Transport Layer in the mainline Linux kernel, there was an interesting thread regarding specifications. Linux creator Linus Torvalds began the discussion saying, "a 'spec' is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate. And I have seen _lots_ of total crap work that was based on specs. It's _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality."

Linus went on to list two reasons to avoid specifications when writing software. First, "they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW." Second, "specs have an inevitable tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP." As a "classic example" he pointed to the OSI model, "we still talk about the seven layers model, because it's a convenient model for _discussion_, but that has absolutely zero to do with any real-life software engineering. In other words, it's a way to _talk_ about things, not to implement them. And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software."

The git directory content manager used to manage the Linux kernel source tree [story] continues to develop at a rapid pace [story]. Keeping up with the latest changes, Jeff Garzik released an updated version of his Kernel Hacker's Guide To Git. He explains, "several changes in git-core have made working with git a lot easier, so be sure to re-familiarize yourself with the development process."

Jeff's short guide is broken into four major sections, 'getting started' which talks about installing the software and getting a copy of the linux kernel source tree, 'basic tasks' which offers examples of keeping up to date with the latest code and merging in your own changes, 'branches' offering examples of creating, using and merging branches, and 'miscellaneous debris' which mentions applying patches from an mbox file and syncronizing tags. Further documentation on the various git commands can be found in the git man pages.

Following the piratical release of 2.6.14-rc2, a brief discussion looked at the advantages of using git to grab the latest version of the kernel code. A small break in service as the master.kernel.org server was situated in its new home [story] caused the 2.6.14-rc2 patch to not show up right away, and led to people pointing out the advantages of using git. When the ketchup script [story] was proposed as an alternative, it was illustrated how git can keep you up to date with the kernel down to a patch by patch level, or with a specific checkpoint. Linus further explained how git can be used to first track down that a bug was introduced between for example rc1-git3 and rc1-git4, and then to use "git-bisect" to further isolate the problem to a specific change.

As for -rc2, Linus noted, "not a whole lot o' excitement, ye scurvy dogs, but it has t' ALSA, LSM, audit and watchdog merges that be missed from -rc1, and a merge series with Andrew. But on t' whole pretty reasonable - you can see t' details in the shortlog (appended)." Evidently Monday the 19'th of September was International Talk Like A Pirate Day.