LWN.net Weekly Edition for November 6, 2008

The end of the road for Firefox 2

By some accounts, the Firefox browser is now responsible for a full 20% of web traffic. As the number of Firefox users grows, so does the need for top-quality support; 20% makes for a large number of potential attack points. So it is interesting to note that Mozilla is now planning to end Firefox 2 support in the near future, perhaps before the end of the year. This change could leave a lot of users - and not just Firefox users - in a difficult position.

One obvious question to ask would be: have most Firefox users moved on to Firefox 3? Apparently, about two out of three users have made the change, but millions of users have yet to move away from the older browser. The Mozilla project would like to get as many of those users to switch before ending support; that, in turn, requires looking at why they haven't yet upgraded. There seem to be a few prominent reasons beyond sheer inertia:

• Some users have systems which are not supported by Firefox 3. Many of these, it seems, are running old versions of Windows - 9x or NT4. In these cases, the operating system itself has long since ceased to receive support, so it's not entirely clear that continuing to support the browser does a whole lot of good.

• Others are dependent on extensions which have not been ported to Firefox 3. While most actively-developed extensions were ported some time ago, it appears that there are quite a few extensions which, while still having significant numbers of users, have been abandoned by their developers. Zack Weinberg has suggested that the project could make an active effort to find new maintainers for those extensions, or even fix a few of them itself.

• The Firefox 3 experience is not problem-free for all users; there have been some complaints about printing on some systems, for example. Finding - and fixing - the remaining blockers is clearly an important thing for the Firefox developers to do.

Somehow, ways will probably be found to coax most of these users into moving forward to a newer browser. Beyond doubt, though, some will be left behind, and some of those may learn the hard way what "unsupported" really means. But that will be true no matter how long Firefox 2 is supported; there's never a way to get all users to upgrade. Firefox is not different from any other application in this regard, with the sole exception that its user base is larger than most.

There is another important aspect to this story, though: this decision will affect users well beyond those who use Firefox. The end of Firefox 2 support will also bring an end to support for the Gecko 1.8.1 platform. And this version of Gecko is used by several applications beyond Firefox, including Camino, SeaMonkey, Sunbird, Miro, Instantbird, and Thunderbird. All of these platforms currently use Gecko - the soon-to-be-discontinued version of Gecko - for HTML rendering.

There is a fair amount of concern about Thunderbird in particular. This mail client was recently kicked out of the Mozilla nest to fend for itself. Thunderbird developers are working toward a Thunderbird 3 release (the third alpha release came out in mid-October) which will use a newer version of Gecko. But the 3.0 release is still several months away - some months after the end of Gecko 1.8.1 support. Naturally enough, the Thunderbird developers worry that their current users will be running in an unsupported mode; that does not strike them as the best start for their newly-independent project.

The word from the Mozilla Foundation seems to be that the Gecko platform will continue to be supported, in some minimal fashion, for a while yet. According to Samuel Sidler:

So it seems that Thunderbird should be covered - as long as the people who decide whether bugs are "browser-specific" do their job properly. But experience has shown many times that it can be hard to understand the full implications of a given bug. It would not be all that surprising for one or more "browser-specific" bugs to turn out to be fully exploitable in Thunderbird.

Beyond that, though, applications like SeaMonkey and Camino are browsers. Developers from those projects are, needless to say, concerned that their needs are not being taken into account. They are not attracted by the idea of shipping a browser based on a platform where browser-specific bugs are being ignored. Mozilla developers have tried to reassure these groups that the situation is not as bad as it seems, but how things will work for them is far from clear. The real answer was, perhaps, suggested by Samuel:

In other words, Mozilla would like to outsource the maintenance of this code to the community, and to distributors in particular. The good news is that this is free software, so this kind of extended maintenance is possible as long as the interest is there to do it. Gecko is a non-trivial body of software to maintain, but it should be possible for the various interested projects, along with distributors still shipping this code, to pool their effort and get the job done. In their spare time, perhaps, they can give some thought to how they might avoid getting caught in the same situation when Firefox 3 reaches the end of its supported life.

Comments (19 posted)

GFDL 1.3: Wikipedia's exit permit

Wikipedia is one of the preeminent examples of what can be done in an open setting; it has, over the years, accumulated millions of articles - many of them excellent - in a large number of languages. Wikipedia also has a bit of a licensing problem, but it would appear that recent events, including the release of a new license by the Free Software Foundation, offers a way out.

Wikipedia is licensed under the GNU Free Documentation License (GFDL). The GFDL has been covered here a number of times; it is, to put it mildly, a controversial document. Its anti-DRM provisions are sufficiently broad that, by some peoples' interpretation, a simple "chmod -r" on a GFDL-licensed file is a violation. But the biggest complaint has to do with the GFDL's notion of "invariant sections." These sections must be propagated unchanged with any copy (or derived work) of the original document. The GFDL itself must also be included with any copies. So a one-page excerpt from the GNU Emacs manual, for example, must be accompanied by several dozen pages of material, including the original GNU Manifesto.

So the GFDL has come to be seen by many as more of a tool for the propagation of FSF propaganda than a license for truly free documentation. Much of the community avoids this license; some groups, such as the Debian Project, see it as non-free. Many projects which still do use the GFDL make a clear point of avoiding (or disallowing outright) the use of cover texts, invariant sections, and other GFDL features. Some projects have dropped the GFDL; in many cases, they have moved to the Creative Commons attribution-sharealike license which retains the copyleft provisions of the GFDL without most of the unwanted baggage.

Members of the Wikipedia project have wanted to move away from the GFDL for some time. They have a problem, though: like the Linux kernel, Wikipedia does not require copyright assignments from its contributors. So any relicensing of Wikipedia content would require the permission of all the contributors. For a project on the scale of Wikipedia, the chances of simply finding all of the contributors - much less getting them to agree on a license change - are about zero. So Wikipedia, it seems, is stuck with its current license.

There is one exception, though. The Wikipedia copyright policy, under which contributions are accepted, reads like this:

The presence of the "or any later version" language allows Wikipedia content to be distributed under the terms of later versions of the GFDL with no need to seek permission from individual contributors. Surprisingly, the Wikimedia Foundation has managed to get the Free Software Foundation to cooperate in the use of the "or any later version" permission to carry out an interesting legal hack.

On November 3, the FSF and the Wikimedia Foundation jointly announced the release of version 1.3 of the GFDL. This announcement came as a surprise to many, who had no idea that a new GFDL 1.x release was in the works. This update does not address any of the well-known complaints against the GFDL. Instead, it added a new section:

In other words, GFDL-licensed sites like Wikipedia have a special, nine-month window in which they can relicense their content to the Creative Commons attribution-sharealike license. This works because (1) moving to version 1.3 of the license is allowed under the "or any later version" terms, and (2) relicensing to CC-BY-SA is allowed by GFDL 1.3.

Legal codes, like other kinds of code, have a certain tendency to pick up cruft as they are patched over time. In this case, the FSF has added a special, time-limited hack which lets Wikipedia make a graceful exit from the GFDL license regime. This move is surprising to many, who would not have guessed that the FSF would go for it. Lawrence Lessig, who calls the change "enormously important," expresses it this way:

For whatever reason, Stallman and the FSF chose to go along with this change, though not before adding some safeguards. The November 1 cutoff date (which precedes the GFDL 1.3 announcement) is there to prevent troublemakers from posting FSF manuals to Wikipedia in their entirety, and, thus, relicensing them.

Now that Wikipedia has its escape clause, it needs to decide how to respond. The plan would appear to be this:

This proposal will be followed by a "community-wide referendum," with a majority vote deciding whether the new policy will be adopted or not. Expect some interesting discussions over the next month.

This series of events highlights a couple of important points to keep in mind when considering copyright and licensing for a project. There is a certain simplicity and egalitarianism inherent in allowing contributors to retain their copyrights. But it does also limit a project's ability to recover from a suboptimal license choice later on. Licensing inflexibility can be a good thing or a bad thing, depending on your point of view, but it is certainly something which could be kept in mind.

The other thing to be aware of is just how much power the "or any later version" text puts into the hands of the FSF. The license promises that later versions will be "similar in spirit," but the GPLv3 debate made it clear that similarity of spirit is in the eye of the beholder. It is not immediately obvious that allowing text to be relicensed (to a license controlled by a completely different organization) is in the "spirit" of the original GFDL. Your editor suspects that most contributors will be willing to accept this change, but there may be some who feel that their trust was abused.

Finally, it's worth noting that "any later version" includes GFDL 2.0. The discussion draft of this major license upgrade has been available for comments for a full two years now. The FSF has not said anything about when it plans to move forward with the new license, but it seems clear that anybody wanting to comment on this draft would be well advised to do so soon.

Comments (40 posted)

Testing Fedora on the OLPC

In preparation for this year's version of the Give One, Get One (G1G1) promotion of the One Laptop Per Child (OLPC) XO, the Fedora OLPC special interest group (SIG) has undertaken a rather large testing effort. With the assistance of 80 mostly-free XOs, the group has been running Fedora 10 on the hardware, trying to shake out Fedora and OLPC bugs. The idea is to help lift some of the burden from the OLPC developers, while also providing some distribution testing focused on areas specific to the OLPC hardware.

G1G1 participants can optionally purchase an SD card pre-loaded with a Fedora 10 live distribution, so that they can run a full Fedora desktop on the XO. Normally, it runs a stripped-down version of Fedora 9 with the Sugar interface as the only desktop available. Part of the Fedora OLPC effort is to help reduce the operating system burden for the OLPC folks. Fedora OLPC liaison (and Red Hat Senior Community Architect) Greg DeKoenigsberg describes where the project is headed:

Back in September, DeKoenigsberg put out a call for folks interested in testing, with the incentive of a "mostly" free XO. Participants needed to be willing to buy an SD card to put Fedora on and to spend 20 hours testing Fedora on the XO. There were more volunteers than laptops, as would be expected, but 80 XOs—most refurbished returns from the original G1G1 last year—got into the hands of many "experienced Fedora community members." The XOs were provided by the OLPC project through its developer program.

The testing has already "found and resolved a number of potential release blockers," according to DeKoenigsberg. There is an extensive test plan that outlines the different testing areas as well as the methodology of testing and reporting bugs found. In many ways, this is just a test of Fedora on a new hardware platform, with the focus on things that set the XO apart: power management, networking, the built-in camera, display, performance, etc.

But there is more to the SIG than just testing the XO. The task list has a number of different activities that are currently underway. Getting a developer key to each person who chooses the Fedora 10 option in G1G1 is an important piece of the puzzle—the XO security policy will not allow it to boot from SD without it. Various Sugar tasks are high on the list as well.

One of those is the Fedora Sugar spin, a Live CD that allows running the Sugar environment on any computer. So far, there are just a few Sugar "activities"—roughly equivalent to applications for things like web browsing or word processing—available for the spin, but that is another of the tasks that Fedora OLPC will be working on. There is currently a bit of an awkward debate on the fedora-advisory-board mailing list about how "official" the Sugar spin really is—as it missed the deadline for the Fedora 10 freeze—but it would seem that many are in favor of granting it a waiver.

The Fedora OLPC SIG's mission statement—To provide the OLPC project with a strong, sustainable, scalable, community-driven base platform for innovation—makes it clear it sees a big role in assisting OLPC going forward. The testing effort is just one facet of that, as DeKoenigsberg notes:

The OLPC project is one with great promise. It has suffered at times from the mixed message that it gives regarding free vs. proprietary software, but it could, clearly, be a marvelous example of free software in action. In order for that to happen, though, there will need to be a concerted effort by the free software community to assist. The Fedora OLPC SIG looks to be an excellent step in that direction.

Comments (3 posted)

Page editor: Jonathan Corbet

Security

Android's first vulnerability

A company's response to security vulnerabilities is always interesting to watch. Google has the reputation of being fairly cavalier regarding flaws reported in its code; the first security vulnerability reported for the Android mobile phone software appears to follow that pattern. Unfortunately for users of Android phones, though, Google's attitude and relatively slow response might some day lead to an "in the wild" exploit targeting the phones.

The flaw was first reported to Google on October 20 by Independent Security Evaluators (ISE), but was not patched for the G1 phone—the only shipping Android phone—until November 3. Details on the vulnerability are thin, but it affects the web browser and is caused by Google shipping an out-of-date component. Presumably a library or content handler was shipped with a known security flaw that could lead to code execution as the user id which runs the browser.

It should be noted that compromising the browser does not affect the rest of the phone due to Android's security architecture. Unlike the iPhone, separate applications are run as different users, so that phone functionality is isolated from the browser, instant messaging, and other tools. An iPhone compromise in any application can lead to the attacker being able to make phone calls and get access to private data associated with any application; clearly Google made a better choice than Apple.

One interesting recent development, though, is the availability of an application that provides a root-owned telnet daemon. With that running, a simple telnet gets full access to the phone's filesystem. From there, jailbreaking—circumventing the restrictions placed by a carrier on applications—as well as unlocking the phone from a specific carrier are possible. While it is easy to see how that might be useful for the owner of Android, though it opens the phone to rather intrusive attacks, it probably is not what T-Mobile (and other carriers down the road) had in mind.

Google's first response to the vulnerability report was to whine that Charlie Miller, who discovered the flaw, was not being "responsible" by talking about it before a fix was ready. Miller did not disclose details, but did report the existence of—along with some general information about—the flaw. Google's previous reputation regarding vulnerability reporting, as well as how it treated Miller, undoubtedly played a role in his decision.

Perhaps the most galling thing is that the flaw was in a free software component that had been updated prior to the Android release to, at least in part, close that hole. It would seem that the Android team was not paying attention to security flaws reported in the free software components that make up the phone software stack. Hopefully, this particular occurrence will serve as a wake-up call on that front.

Given that the fix was already known, it is a bit puzzling that it would take two weeks for updates to become available. It was the first update made for Android phones in the field, but one hopes the bugs in that process were worked out long ago. Overall, Google's response leaves rather a lot to be desired.

If Google wants security researchers to be more "responsible" in their disclosure, it would be well served by looking at its own behavior. Taking too much time to patch a vulnerability—especially one with a known and presumably already tested fix—is not the way to show the security community that it takes such bugs seriously. Whining about disclosure rarely, if ever, goes anywhere; working in a partnership with folks who find security flaws is much more likely to bear fruit.

Comments (11 posted)

New vulnerabilities

apache tomcat: restriction bypass

Package(s):	tomcat5, apache-jakarta-tomcat-connectors	CVE #(s):	CVE-2008-3271
Created:	October 31, 2008	Updated:	November 5, 2008
Description:	From the CVE entry: Apache Tomcat 5.5.0 and 4.1.0 through 4.1.31 allows remote attackers to bypass an IP address restriction and obtain sensitive information via a request that is processed concurrently with another request but in a different thread, leading to an instance-variable overwrite associated with a "synchronization problem" and lack of thread safety, and related to RemoteFilterValve, RemoteAddrValve, and RemoteHostValve.
Alerts:	SuSE SUSE-SR:2008:023 2008-10-31

Comments (none posted)

dovecot: negative rights in ACL plugin

Package(s):	dovecot	CVE #(s):	CVE-2008-4577
Created:	October 30, 2008	Updated:	September 28, 2009
Description:	dovecot has a restriction bypass vulnerability. From the vulnerability database entry: The ACL plugin in Dovecot before 1.1.4 treats negative access rights as if they are positive access rights, which allows attackers to bypass intended access restrictions.
Alerts:	Ubuntu USN-838-1 2009-09-28 SuSE SUSE-SR:2009:004 2009-02-17 rPath rPSA-2008-0341-1 2008-12-22 Red Hat RHSA-2009:0205-02 2009-01-20 Gentoo 200812-16 2008-12-14 Mandriva MDVSA-2008:232 2008-11-19 Fedora FEDORA-2008-9202 2008-10-30 Fedora FEDORA-2008-9232 2008-10-30

Comments (none posted)

enscript: stack overflows

Package(s):	enscript	CVE #(s):	CVE-2008-3863 CVE-2008-4306
Created:	November 4, 2008	Updated:	December 16, 2008
Description:	From the Ubuntu alert: Ulf Härnhammar discovered multiple stack overflows in enscript's handling of special escape arguments. If a user or automated system were tricked into processing a malicious file with the "-e" option enabled, a remote attacker could execute arbitrary code or cause enscript to crash, possibly leading to a denial of service.
Alerts:	Mandriva MDVSA-2008:243 2008-12-15 CentOS CESA-2008:1016 2008-12-16 CentOS CESA-2008:1021 2008-12-15 Red Hat RHSA-2008:1016-01 2008-12-15 Red Hat RHSA-2008:1021-02 2008-12-15 Gentoo 200812-02 2008-12-02 Debian DSA-1670-1 2008-11-24 rPath rPSA-2008-0321-1 2008-11-17 SuSE SUSE-SR:2008:024 2008-11-07 Fedora FEDORA-2008-9372 2008-11-06 Fedora FEDORA-2008-9351 2008-11-06 Ubuntu USN-660-1 2008-11-03

Comments (none posted)

graphviz: stack-based buffer overflow

Package(s):	graphviz	CVE #(s):	CVE-2008-4555
Created:	October 31, 2008	Updated:	December 7, 2009
Description:	From the CVE entry: Stack-based buffer overflow in the push_subg function in parser.y (lib/graph/parser.c) in Graphviz 2.20.2, and possibly earlier versions, allows user-assisted remote attackers to cause a denial of service (memory corruption) or execute arbitrary code via a DOT file with a large number of Agraph_t elements.
Alerts:	Mandriva MDVSA-2009:254-1 2009-12-05 Mandriva MDVSA-2009:254 2009-10-01 Gentoo 200811-04 2008-11-09 SuSE SUSE-SR:2008:023 2008-10-31

Comments (none posted)

kernel: buffer overflow

Package(s):	kernel	CVE #(s):	CVE-2008-3496
Created:	November 3, 2008	Updated:	November 5, 2008
Description:	From the Mandriva advisory: Buffer overflow in format descriptor parsing in the uvc_parse_format function in drivers/media/video/uvc/uvc_driver.c in uvcvideo in the video4linux (V4L) implementation in the Linux kernel before 2.6.26.1 has unknown impact and attack vectors. (CVE-2008-3496)
Alerts:	Mandriva MDVSA-2008:223 2008-10-31

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2006-5755
Created:	November 4, 2008	Updated:	November 5, 2008
Description:	From the Red Hat alert: a flaw was found in the Linux kernel when running on AMD64 systems. During a context switch, EFLAGS were being neither saved nor restored. This could allow a local unprivileged user to cause a denial of service.
Alerts:	CentOS CESA-2008:0957 2008-11-05 Red Hat RHSA-2008:0957-02 2008-11-04

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2008-3527
Created:	November 4, 2008	Updated:	December 16, 2008
Description:	From the Red Hat alert: Tavis Ormandy reported missing boundary checks in the Virtual Dynamic Shared Objects (vDSO) implementation. This could allow a local unprivileged user to cause a denial of service or escalate privileges.
Alerts:	Debian DSA-1687-1 2008-12-15 SuSE SUSE-SR:2008:025 2008-11-14 CentOS CESA-2008:0957 2008-11-05 Red Hat RHSA-2008:0957-02 2008-11-04

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2007-5907
Created:	November 4, 2008	Updated:	November 5, 2008
Description:	From the Red Hat alert: the Xen implementation did not prevent applications running in a para-virtualized guest from modifying CR4 TSC. This could cause a local denial of service.
Alerts:	CentOS CESA-2008:0957 2008-11-05 Red Hat RHSA-2008:0957-02 2008-11-04

Comments (none posted)

libgadu: denial of service

Package(s):	libgadu	CVE #(s):	CVE-2008-4776
Created:	October 31, 2008	Updated:	December 21, 2010
Description:	From the CVE entry: libgadu before 1.8.2 allows remote servers to cause a denial of service (crash) via a contact description with a large length, which triggers a buffer over-read.
Alerts:	openSUSE openSUSE-SU-2010:1085-1 2010-12-21 openSUSE openSUSE-SU-2010:1077-1 2010-12-17 openSUSE openSUSE-SU-2010:1076-1 2010-12-17 Mandriva MDVSA-2009:208-1 2009-12-04 Mandriva MDVSA-2009:208 2009-08-20 Ubuntu USN-692-1 2008-12-17 Debian DSA-1664-1 2008-11-10 Fedora FEDORA-2008-9293 2008-10-30 SuSE SUSE-SR:2008:023 2008-10-31

Comments (none posted)

libtirpc: denial of service

Package(s):	libtirpc	CVE #(s):	CVE-2008-4619
Created:	October 30, 2008	Updated:	November 5, 2008
Description:	libtirpc performs incorrect handling of negative rights in the ACL plugin. From the Red Hat Bug description: The ACL plugin in Dovecot before 1.1.4 treats negative access rights as if they are positive access rights, which allows attackers to bypass intended access restrictions.
Alerts:	Fedora FEDORA-2008-9204 2008-10-30

Comments (none posted)

ndiswrapper: buffer overflow

Package(s):	ndiswrapper	CVE #(s):	CVE-2008-4395
Created:	November 5, 2008	Updated:	March 3, 2009
Description:	The out-of-tree ndiswrapper kernel module does not properly handle long ESSIDs, enabling remote code-execution attacks.
Alerts:	Debian DSA-1731-1 2009-03-02 Gentoo 200901-01 2009-01-11 SuSE SUSE-SA:2008:057 2008-12-04 Ubuntu USN-662-2 2008-11-06 Ubuntu USN-662-1 2008-11-05

Comments (none posted)

net-snmp: denial of service

Package(s):	net-snmp	CVE #(s):	CVE-2008-4309
Created:	November 3, 2008	Updated:	July 20, 2009
Description:	From the Red Hat advisory: A denial-of-service flaw was found in the way Net-SNMP processes SNMP GETBULK requests. A remote attacker who issued a specially-crafted request could cause the snmpd server to crash. (CVE-2008-4309)
Alerts:	Mandriva MDVSA-2009:156 2009-07-19 Fedora FEDORA-2009-1769 2009-02-17 Gentoo 200901-15 2009-01-21 Ubuntu USN-685-1 2008-12-03 Fedora FEDORA-2008-10451 2008-11-27 Slackware SSA:2008-320-02 2008-11-17 rPath rPSA-2008-0315-1 2008-11-12 Debian DSA-1663-1 2008-11-09 Fedora FEDORA-2008-9367 2008-11-06 Fedora FEDORA-2008-9362 2008-11-06 Mandriva MDVSA-2008:225 2008-11-05 CentOS CESA-2008:0971 2008-11-03 Red Hat RHSA-2008:0971-01 2008-11-03 SuSE SUSE-SR:2009:003 2009-02-02

Comments (none posted)

nfs-client: access restriction bypass

Package(s):	nfs-client	CVE #(s):	CVE-2008-4552
Created:	October 30, 2008	Updated:	September 16, 2009
Description:	nfs-client has an access restriction bypass vulnerability. From the rPath alert: Previous versions of the nfs-utils package contain a bug that causes NIS netgroup restrictions to be ignored by TCP Wrappers, which may allow remote attackers to bypass intended access restrictions.
Alerts:	CentOS CESA-2009:1321 2009-09-15 Red Hat RHSA-2009:1321-02 2009-09-02 Mandriva MDVSA-2009:060-1 2009-03-19 Gentoo 200903-06 2009-03-07 Mandriva MDVSA-2009:060 2009-02-27 Ubuntu USN-687-1 2008-12-04 SuSE SUSE-SR:2009:001 2009-01-12 rPath rPSA-2008-0307-1 2008-10-30

Comments (none posted)

openoffice.org: multiple vulnerabilities

Package(s):	openoffice.org	CVE #(s):	CVE-2008-2237 CVE-2008-2238
Created:	October 30, 2008	Updated:	January 13, 2009
Description:	openoffice.org has two file parser vulnerabilities. From the Debian alert: CVE-2008-2237 The SureRun Security team discovered a bug in the WMF file parser that can be triggered by manipulated WMF files and can lead to heap overflows and arbitrary code execution. CVE-2008-2238 An anonymous researcher working with the iDefense discovered a bug in the EMF file parser that can be triggered by manipulated EMF files and can lead to heap overflows and arbitrary code execution.
Alerts:	Ubuntu USN-677-2 2008-12-23 Gentoo 200812-13 2008-12-12 Ubuntu USN-677-1 2008-11-24 SuSE SUSE-SR:2008:026 2008-11-24 CentOS CESA-2008:0939 2008-11-05 Red Hat RHSA-2008:0939-00 2008-11-05 Fedora FEDORA-2008-9333 2008-10-31 Fedora FEDORA-2008-9313 2008-10-31 Debian DSA-1661-1 2008-10-29 Mandriva MDVSA-2009:006 2008-01-13

Comments (none posted)

opera: multiple vulnerabilities

Package(s):	opera	CVE #(s):	CVE-2008-4195 CVE-2008-4196 CVE-2008-4197 CVE-2008-4198 CVE-2008-4199 CVE-2008-4200 CVE-2008-4292 CVE-2008-4694 CVE-2008-4695 CVE-2008-4696 CVE-2008-4697 CVE-2008-4698 CVE-2008-4794 CVE-2008-4795
Created:	November 4, 2008	Updated:	November 5, 2008
Description:	The Opera browser has multiple vulnerabilities. From the Gentoo alert: Opera does not restrict the ability of a framed web page to change the address associated with a different frame (CVE-2008-4195). Chris Weber (Casaba Security) discovered a Cross-site scripting vulnerability (CVE-2008-4196). Michael A. Puls II discovered that Opera can produce argument strings that contain uninitialized memory, when processing custom shortcut and menu commands (CVE-2008-4197). Lars Kleinschmidt discovered that Opera, when rendering an HTTP page that has loaded an HTTPS page into a frame, displays a padlock icon and offers a security information dialog reporting a secure connection (CVE-2008-4198). Opera does not prevent use of links from web pages to feed source files on the local disk (CVE-2008-4199). Opera does not ensure that the address field of a news feed represents the feed's actual URL (CVE-2008-4200). Opera does not check the CRL override upon encountering a certificate that lacks a CRL (CVE-2008-4292). Chris (Matasano Security) reported that Opera may crash if it is redirected by a malicious page to a specially crafted address (CVE-2008-4694). Nate McFeters reported that Opera runs Java applets in the context of the local machine, if that applet has been cached and a page can predict the cache path for that applet and load it from the cache (CVE-2008-4695). Roberto Suggi Liverani (Security-Assessment.com) reported that Opera's History Search results does not escape certain constructs correctly, allowing for the injection of scripts into the page (CVE-2008-4696). David Bloom reported that Opera's Fast Forward feature incorrectly executes scripts from a page held in a frame in the outermost page instead of the page the JavaScript URL was located (CVE-2008-4697). David Bloom reported that Opera does not block some scripts when previewing a news feed (CVE-2008-4698). Opera does not correctly sanitize content when certain parameters are passed to Opera's History Search, allowing scripts to be injected into the History Search results page (CVE-2008-4794). Opera's links panel incorrectly causes scripts from a page held in a frame to be executed in the outermost page instead of the page where the URL was located (CVE-2008-4795).
Alerts:	Gentoo 200811-01 2008-11-03

Comments (none posted)

phpMyAdmin: cross-site scripting

Package(s):	phpMyAdmin	CVE #(s):	CVE-2008-4775
Created:	October 31, 2008	Updated:	March 19, 2009
Description:	From the CVE entry: Cross-site scripting (XSS) vulnerability in pmd_pdf.php in phpMyAdmin 3.0.0, and possibly other versions including 2.11.9.2 and 3.0.1, when register_globals is enabled, allows remote attackers to inject arbitrary web script or HTML via the db parameter, a different vector than CVE-2006-6942 and CVE-2007-5977.
Alerts:	Gentoo 200903-32 2009-03-18 Mandriva MDVSA-2009:026-1 2009-02-26 Mandriva MDVSA-2009:026 2009-01-23 Fedora FEDORA-2008-9336 2008-10-31 Fedora FEDORA-2008-9316 2008-10-31

Comments (none posted)

samba: denial of service

Package(s):	samba	CVE #(s):
Created:	November 5, 2008	Updated:	November 5, 2008
Description:	From the rPath advisory: Previous versions of the samba package contain a race condition which may lead to a crash of the winbindd daemon (Denial of Service).
Alerts:	rPath rPSA-2008-0308-1 2008-10-30

Comments (none posted)

Page editor: Jonathan Corbet

Kernel development

Brief items

Kernel release status

The current 2.6 development kernel is 2.6.28-rc3, released on November 2. It contains the usual pile of fixes, along with the removal of the (now unused) prepare_write() and commit_write() VFS methods and new drivers for Elantech (EeePC) touchpads, and Intel X38 memory controllers.

Also merged was a driver API change; drivers which support FASYNC no longer need to make a final call to fasync_helper() at release time.

As of this writing, a few dozen post-rc3 patches have been merged into the mainline repository. Along with the fixes is a new I/O memory mapping API for graphics drivers; see the separate article below for details.

Comments (none posted)

Kernel development news

Quotes of the week

-- Andrew Morton

-- Linus Torvalds

Comments (none posted)

Linux and object storage devices

The btrfs filesystem is widely regarded as being the long-term future choice for Linux. But what if btrfs is taking the wrong direction, fighting an old war? If the nature of our storage devices changes significantly, our filesystems will have to change as well. A lot of attention has been paid to the increasing prevalence of flash-based devices, but there is another upcoming technology which should be planned for: object storage devices (OSDs). The recent posting of a new filesystem called osdfs provides a good opportunity to look at OSDs and how they might be supported under Linux.

The developers of OSDs were driven by the idea that traditional, block-based disk drives offer an overly low-level interface. With contemporary hardware, it should be possible to push more intelligence into storage devices, offloading work from the host while maintaining (or improving) performance and security. So the interface offered by an OSD does not deal in blocks; instead, the OSD provides "objects" to the host system. Most objects will simply be files, but a few other types of objects (partitions, for example) are supported as well. The host manipulates these objects, but need not (and cannot) concern itself with how those objects are implemented within the device.

A file object is identified by two 64-bit numbers. It contains whatever data the creator chooses to put in there; an OSD does not interpret the data in any way. Files also have a collection of attributes and metadata; this includes much of the information stored in an on-disk inode in a traditional filesystem - but without the block layout information, which the OSD hides from the rest of the world. All of the usual operations can be performed on files - reading, writing, appending, truncating, etc. - but, again, the implementation of those operations is handled by the OSD.

One thing that is not handled by the OSD, though, is the creation of a directory hierarchy or the naming of files. It is expected that the host filesystem will use file objects to store its directory structure, providing a suitable interface to the filesystem's users. One could, presumably, also use an OSD as a sort of hardware-implemented object database without a whole lot of high-level code, but that is not where the focus of work with OSDs is now.

[PULL QUOTE: The OSD designers decided to offload another task from the host systems: security. END QUOTE] The OSD protocol [PDF] is a T10-sanctioned extension to the SCSI protocol. It is thus expected that OSD devices will be directly attached to host systems; the protocol has been designed to perform well in that mode. It is also expected, though, that OSDs will be used in network-attached storage environments. For such deployments, the OSD designers decided to offload another task from the host systems: security. To that end, the OSD protocol includes an extensive set of security-related commands. Every operation on an object must be accompanied by a "capability," a cryptographically-signed ticket which names the object and the access rights possessed by the owner of the capability. In the absence of a suitable capability, the drive will deny access.

It is expected that capabilities will be handed out by a security policy daemon running somewhere on the network. That daemon may be in possession of the drive's root key, which allows unrestricted access to the drive, or it may have a separate, partition-level key instead. Either way, it can use that key to sign capabilities given out to processes elsewhere in the system. (Drives also have a "master" key, used primarily to change the root key. Loss of the master key is probably a restore-from-backup sort of event.)

Capabilities last for a while (they include an expiration time) and describe all of the allowed operations. So the act of actually obtaining a capability should be relatively rare; most OSD operations will be performed using a capability which the system already has in hand. That is an important design feature; adding "ask a daemon for a capability" to the filesystem I/O path would not be a performance-enhancing move.

In theory, it should be relatively easy to make a standard Linux filesystem support an OSD. It's mostly a matter of hacking out much of the low-level block layout and inode management code, replacing it with the appropriate object operations. The osdfs filesystem was created in this way; the developers started with ext2. After taking out all the code they no longer needed, the osdfs developers simply added code translating VFS-level requests into operations understood by the OSD. Those requests are then executed by way of the low-level osd-initiator code (which was also recently submitted for consideration). Directories are implemented as simple files containing names and associated object IDs. There is no separate on-disk inode; all of that information is stored as attributes to the file itself. The end result is that the osdfs code is relatively small; it is mostly concerned with remapping VFS operations into OSD operations.

Anybody wanting to test this code may run into one small problem: there are few OSDs to be found in the neighborhood computer store. It would appear that most of the development work so far has been done using OSD simulators. The OSC software OSD is, like osdfs, part of the open-osd project; it implements the OSD protocol over an SQLite database. There is also an OSD simulator hosted at IBM, but it would not appear to be under current development. Simulator-based development and testing may not be as rewarding as having a shiny new device implementing OSD in hardware, but it will help to insure that both the software and the protocol are in good shape by the time such hardware is available.

It should be noted that the success of OSDs is not entirely assured. An OSD takes much of the work normally done in an operating system kernel and shoves it into a hardware firmware blob where it cannot be inspected or fixed. A poor implementation will, at best, not perform well; at worst, the chances of losing data could increase considerably. It may yet prove best to insist that storage devices just concentrate on placing bits where the operating system tells them to and leave the higher-level decisions to higher-level code. Or it may turn out that OSDs are the next step forward in smarter, more capable hardware. Either way, it is an interesting experiment.

See this article at Sun for more information on how OSD works.

Comments (22 posted)

Large I/O memory in small address spaces

In the good old days, video graphics drivers ran in user space and the kernel had little to do with video memory. More recently, graphics developers have decisively voted for change and, in the process, moved video memory management into the kernel. So now the kernel must often manipulate video memory directly. And that, as it turns out, is harder than one might expect - at least, on 32-bit machines if the user actually cares about reasonable performance.

The problem is that 32-bit machines have a mere 4GB of virtual address space. Linux (usually) splits that space in two; the bottom 3GB are given to user space, while the kernel itself occupies the top 1GB. Splitting the space in this way yields an important advantage: there is no need to adjust the memory management configuration on transitions between kernel and user space, which speeds things up considerably. The down side is that the kernel has to fit in the remaining gigabyte of memory. That would not seem like much of a problem, even with contemporary kernels, but remember one thing: the kernel needs to map physical memory into its address space before it can do anything with it. So the amount of virtual address space given to the kernel limits the amount of physical memory it can manipulate directly.

One other thing that must fit into the kernel's address space is the vmalloc() area - a range of addresses which can be assigned on the fly to create needed mappings in the kernel. When a virtually-contiguous range of memory is allocated with vmalloc(), it is mapped in this range. Another user of this address space is ioremap(), which makes a range of I/O memory available to the kernel.

Device drivers typically need access to I/O memory, so they use ioremap() to map it into the kernel's address space. Graphics adapters are a little different, though, in that they have large I/O memory regions: the entirety of video memory. Contemporary graphics adapters can carry a lot of video memory, to the point that mapping it with ioremap() would require far too much address space, if, indeed, it fits in there at all. So a straight ioremap() is not feasible; life was much easier in the old days when this I/O memory was mapped into user space instead.

The Intel i915 developers, who are the farthest ahead when it comes to kernel-based GPU memory management, ran into this problem first. Their initial solution was to map individual pages as needed with ioremap() (or, strictly, ioremap_wc(), which turns on write combining - see this article for more details), and unmapping them afterward. This solution works, but it's slow. Among other things, an ioremap() operation requires a cross-processor interrupt to be sure that all CPUs know about the address space change. It is a function which was designed to be called infrequently, outside of performance-critical code. Making ioremap() calls a part of most graphical operations is not the way to obtain a satisfactory first-person shooter experience.

The real solution comes in the form of a new mapping API developed by Keith Packard (and subsequently tweaked by Ingo Molnar). It draws heavily on the fact that Linux has had to solve this kind of problem before. Remember that the kernel (on 32-bit systems) only has 1GB of address space to work with; that is the maximum amount of physical memory it can ever have directly mapped at any given time. Any physical memory above that amount is called "high memory"; it is normally not mapped into the kernel's address space. Access to that memory requires an explicit mapping - using kmap() or kmap_atomic() - first. High memory is thus trickier to use, but this trick has enabled 32-bit systems to support far more memory than was once thought possible.

The new mapping API draws more than inspiration from the treatment of high memory - it uses much of the same mechanism as well. A driver which needs to map a large I/O area sets up the mapping with a call to:

    struct io_mapping *io_mapping_create_wc(unsigned long base,
					    unsigned long size);

This function returns the struct io_mapping pointer, but it does not actually map any of the I/O memory into the kernel's address space. That must be done a page at a time with a call to one of:

    void *io_mapping_map_atomic_wc(struct io_mapping *mapping,
				   unsigned long offset);
    void *io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset);

Either function will return a kernel-space pointer which is mapped to the page at the given offset. The atomic form is essentially a kmap_atomic() call - it uses the KM_USER0 slot, which is a good thing for developers to know about. It is, by far, the faster of the two, but it requires that the mapping be held by atomic code, and only one page at a time can be mapped in this way. Code which might sleep must use io_mapping_map_wc(), which currently falls back to the old ioremap_wc() implementation.

Mapped pages should be unmapped when no longer needed, of course:

    void io_mapping_unmap_atomic(void *vaddr);
    void io_mapping_unmap(void *vaddr);

There are some interesting aspects to this implementation. One is that struct io_mapping is never actually defined anywhere. The code need not remember anything except the base address, so the return value from io_mapping_create_wc() is just the base pointer which was passed in. The other is that all of this structure is really only needed on 32-bit systems; a 64-bit processor has no trouble finding enough address space to map video memory. So, on 64-bit systems, io_mapping_create_wc() just maps the entire region with ioremap_wc(); the individual page operations are no-ops.

Keith reports that, with this change, Quake 3 (used for testing purposes only, of course) runs 18 times faster. The far more serious Dave Airlie tested with glxgears and got an increase from 85 frames/second to 380. This is a big enough improvement that they would like to see this code go into 2.6.28, which will contain the GEM memory manager code. Linus responds:

As a result, this code has been merged into the mainline and will appear in 2.6.28-rc4.

Comments (7 posted)

Hierarchical RCU

Introduction

Read-copy update (RCU) is a synchronization mechanism that was added to the Linux kernel in October of 2002. RCU improves scalability by allowing readers to execute concurrently with writers. In contrast, conventional locking primitives require that readers wait for ongoing writers and vice versa. RCU ensures coherence for read accesses by maintaining multiple versions of data structures and ensuring that they are not freed until all pre-existing read-side critical sections complete. RCU relies on efficient and scalable mechanisms for publishing and reading new versions of an object, and also for deferring the collection of old versions. These mechanisms distribute the work among read and update paths in such a way as to make read paths extremely fast. In some cases (non-preemptable kernels), RCU's read-side primitives have zero overhead.

Although Classic RCU's read-side primitives enjoy excellent performance and scalability, the update-side primitives which determine when pre-existing read-side critical sections have finished, were designed with only a few tens of CPUs in mind. Their scalability is limited by a global lock that must be acquired by each CPU at least once during each grace period. Although Classic RCU actually scales to a couple of hundred CPUs, and can be tweaked to scale to roughly a thousand CPUs (but at the expense of extending grace periods), emerging multicore systems will require it to scale better.

In addition, Classic RCU has a sub-optimal dynticks interface, with the result that Classic RCU will wake up every CPU at least once per grace period. To see the problem with this, consider a 16-CPU system that is sufficiently lightly loaded that it is keeping only four CPUs busy. In a perfect world, the remaining twelve CPUs could be put into deep sleep mode in order to conserve energy. Unfortunately, if the four busy CPUs are frequently performing RCU updates, those twelve idle CPUs will be awakened frequently, wasting significant energy. Thus, any major change to Classic RCU should also leave sleeping CPUs lie.

Both the existing and the proposed implementation have have Classic RCU semantics and identical APIs, however, the old implementation will be called “classic RCU” and the new implementation will be called “tree RCU”.

1. Review of RCU Fundamentals
2. Brief Overview of Classic RCU Implementation
3. RCU Desiderata
4. Towards a More Scalable RCU Implementation
5. Towards a Greener RCU Implementation
6. State Machine
7. Use Cases
8. Testing

These sections are followed by concluding remarks and the answers to the Quick Quizzes.

Review of RCU Fundamentals

In its most basic form, RCU is a way of waiting for things to finish. Of course, there are a great many other ways of waiting for things to finish, including reference counts, reader-writer locks, events, and so on. The great advantage of RCU is that it can wait for each of (say) 20,000 different things without having to explicitly track each and every one of them, and without having to worry about the performance degradation, scalability limitations, complex deadlock scenarios, and memory-leak hazards that are inherent in schemes using explicit tracking.

In RCU's case, the things waited on are called "RCU read-side critical sections". An RCU read-side critical section starts with an rcu_read_lock() primitive, and ends with a corresponding rcu_read_unlock() primitive. RCU read-side critical sections can be nested, and may contain pretty much any code, as long as that code does not explicitly block or sleep (although a special form of RCU called "SRCU" does permit general sleeping in SRCU read-side critical sections). If you abide by these conventions, you can use RCU to wait for any desired piece of code to complete.

RCU accomplishes this feat by indirectly determining when these other things have finished, as has been described elsewhere for Classic RCU and realtime RCU.

In particular, as shown in the following figure, RCU is a way of waiting for pre-existing RCU read-side critical sections to completely finish, including memory operations executed by those critical sections.

However, note that RCU read-side critical sections that begin after the beginning of a given grace period can and will extend beyond the end of that grace period.

The following section gives a very high-level view of how the Classic RCU implementation operates.

Brief Overview of Classic RCU Implementation

The key concept behind the Classic RCU implementation is that Classic RCU read-side critical sections are confined to kernel code and are not permitted to block. This means that any time a given CPU is seen either blocking, in the idle loop, or exiting the kernel, we know that all RCU read-side critical sections that were previously running on that CPU must have completed. Such states are called “quiescent states”, and after each CPU has passed through at least one quiescent state, the RCU grace period ends.

Classic RCU's most important data structure is the rcu_ctrlblk structure, which contains the ->cpumask field, which contains one bit per CPU. Each CPU's bit is set to one at the beginning of each grace period, and each CPU must clear its bit after it passes through a quiescent state. Because multiple CPUs might want to clear their bits concurrently, which would corrupt the ->cpumask field, a ->lock spinlock is used to protect ->cpumask, preventing any such corruption. Unfortunately, this spinlock can also suffer extreme contention if there are more than a few hundred CPUs, which might soon become quite common if multicore trends continue. Worse yet, the fact that all CPUs must clear their own bit means that CPUs are not permitted to sleep through a grace period, which limits Linux's ability to conserve power.

The next section lays out what we need from a new non-real-time RCU implementation.

RCU Desiderata

The list of RCU desiderata called out at LCA2005 for real-time RCU is a very good start:

1. Deferred destruction, so that an RCU grace period cannot end until all pre-existing RCU read-side critical sections have completed.
2. Reliable, so that RCU supports 24x7 operation for years at a time.
3. Callable from irq handlers.
4. Contained memory footprint, so that mechanisms exist to expedite grace periods if there are too many callbacks. (This is weakened from the LCA2005 list.)
5. Independent of memory blocks, so that RCU can work with any conceivable memory allocator.
6. Synchronization-free read side, so that only normal non-atomic instructions operating on CPU- or task-local memory are permitted. (This is strengthened from the LCA2005 list.)
7. Unconditional read-to-write upgrade, which is used in several places in the Linux kernel where the update-side lock is acquired within the RCU read-side critical section.
8. Compatible API.

Because this is not to be a real-time RCU, the requirement for preemptable RCU read-side critical sections can be dropped. However, we need to add a few more requirements to account for changes over the past few years:

1. Scalability with extremely low internal-to-RCU lock contention. RCU must support at least 1,024 CPUs gracefully, and preferably at least 4,096.
2. Energy conservation: RCU must be able to avoid awakening low-power-state dynticks-idle CPUs, but still determine when the current grace period ends. This has been implemented in real-time RCU, but needs serious simplification.
3. RCU read-side critical sections must be permitted in NMI handlers as well as irq handlers. Note that preemptable RCU was able to avoid this requirement due to a separately implemented synchronize_sched().
4. RCU must operate gracefully in face of repeated CPU-hotplug operations. This is simply carrying forward a requirement met by both classic and real-time.
5. It must be possible to wait for all previously registered RCU callbacks to complete, though this is already provided in the form of rcu_barrier().
6. Detecting CPUs that are failing to respond is desirable, to assist diagnosis both of RCU and of various infinite loop bugs and hardware failures that can prevent RCU grace periods from ending.
7. Extreme expediting of RCU grace periods is desirable, so that an RCU grace period can be forced to complete within a few hundred microseconds of the last relevant RCU read-side critical second completing. However, such an operation would be expected to incur severe CPU overhead, and would be primarily useful when carrying out a long sequence of operations that each needed to wait for an RCU grace period.

The most pressing of the new requirements is the first one, scalability. The next section therefore describes how to make order-of-magnitude reductions in contention on RCU's internal locks.

Towards a More Scalable RCU Implementation

One effective way to reduce lock contention is to create a hierarchy, as shown in the following figure. Here, each of the four rcu_node structures has its own lock, so that only CPUs 0 and 1 will acquire the lower left rcu_node's lock, only CPUs 2 and 3 will acquire the lower middle rcu_node's lock, and only CPUs 4 and 5 will acquire the lower right rcu_node's lock. During any given grace period, only one of the CPUs accessing each of the lower rcu_node structures will access the upper rcu_node, namely, the last of each pair of CPUs to record a quiescent state for the corresponding grace period.

This results in a significant reduction in lock contention: instead of six CPUs contending for a single lock each grace period, we have only three for the upper rcu_node's lock (a reduction of 50%) and only two for each of the lower rcu_nodes' locks (a reduction of 67%).

The tree of rcu_node structures is embedded into a linear array in the rcu_state structure, with the root of the tree in element zero, as shown below for an eight-CPU system with a three-level hierarchy. The arrows link a given rcu_node structure to its parent. Each rcu_node indicates the range of CPUs covered, so that the root node covers all of the CPUs, each node in the second level covers half of the CPUs, and each node in the leaf level covering a pair of CPUs. This array is allocated statically at compile time based on the value of NR_CPUS.

The following sequence of six figures shows how grace periods are detected. In the first figure, no CPU has yet passed through a quiescent state, as indicated by the red rectangles. Suppose that all six CPUs simultaneously try to tell RCU that they have passed through a quiescent state. Only one of each pair will be able to acquire the lock on the corresponding lower rcu_node, and so the second figure shows the result if the lucky CPUs are numbers 0, 3, and 5, as indicated by the green rectangles. Once these lucky CPUs have finished, then the other CPUs will acquire the lock, as shown in the third figure. Each of these CPUs will see that they are the last in their group, and therefore all three will attempt to move to the upper rcu_node. Only one at a time can acquire the upper rcu_node structure's lock, and the fourth, fifth, and sixth figures show the sequence of states assuming that CPU 1, CPU 2, and CPU 4 acquire the lock in that order. The sixth and final figure in the group shows that all CPUs have passed through a quiescent state, so that the grace period has ended.

In the above sequence, there were never more than three CPUs contending for any one lock, in happy contrast to Classic RCU, where all six CPUs might contend. However, even more dramatic reductions in lock contention are possible with larger numbers of CPUs. Consider a hierarchy of rcu_node structures, with 64 lower structures and 64*64=4,096 CPUs, as shown in the following figure.

Here each of the lower rcu_node structures' locks are acquired by 64 CPUs, a 64-times reduction from the 4,096 CPUs that would acquire Classic RCU's single global lock. Similarly, during a given grace period, only one CPU from each of the lower rcu_node structures will acquire the upper rcu_node structure's lock, which is again a 64x reduction from the contention level that would be experienced by Classic RCU running on a 4,096-CPU system.

Quick Quiz 1: Wait a minute! With all those new locks, how do you avoid deadlock?

Quick Quiz 2: Why stop at a 64-times reduction? Why not go for a few orders of magnitude instead?

Quick Quiz 3: But I don't care about McKenney's lame excuses in the answer to Quick Quiz 2!!! I want to get the number of CPUs contending on a single lock down to something reasonable, like sixteen or so!!!

The implementation maintains some per-CPU data, such as lists of RCU callbacks, organized into rcu_data structures. In addition, rcu (as in call_rcu()) and rcu_bh (as in call_rcu_bh()) each maintain their own hierarchy, as shown in the following figure.

Quick Quiz 4: OK, so what is the story with the colors?

The next section discusses energy conservation.

Towards a Greener RCU Implementation

As noted earlier, an important goal of this effort is to leave sleeping CPUs lie in order to promote energy conservation. In contrast, classic RCU will happily awaken each and every sleeping CPU at least once per grace period in some cases, which is suboptimal in the case where a small number of CPUs are busy doing RCU updates and the majority of the CPUs are mostly idle. This situation occurs frequently in systems sized for peak loads, and we need to be able to accommodate it gracefully. Furthermore, we need to fix a long-standing bug in Classic RCU where a dynticks-idle CPU servicing an interrupt containing a long-running RCU read-side critical section will fail to prevent an RCU grace period from ending.

Quick Quiz 5: Given such an egregious bug, why does Linux run at all?

This is accomplished by requiring that all CPUs manipulate counters located in a per-CPU rcu_dynticks structure. Loosely speaking, these counters have even-numbered values when the corresponding CPU is in dynticks idle mode, and have odd-numbered values otherwise. RCU thus needs to wait for quiescent states only for those CPUs whose rcu_dynticks counters are odd, and need not wake up sleeping CPUs, whose counters will be even. As shown in the following diagram, each per-CPU rcu_dynticks is shared by the “rcu” and “rcu_bh” implementations.

The following section presents a high-level view of the RCU state machine.

State Machine

At a sufficiently high level, Linux-kernel RCU implementations can be thought of as high-level state machines as shown in the following schematic:

The common-case path through this state machine on a busy system goes through the two uppermost loops, initializing at the beginning of each grace period (GP), waiting for quiescent states (QS), and noting when each CPU passes through its first quiescent state for a given grace period. On such a system, quiescent states will occur on each context switch, or, for CPUs that are either idle or executing user-mode code, each scheduling-clock interrupt. CPU-hotplug events will take the state machine through the “CPU Offline” box, while the presence of “holdout” CPUs that fail to pass through quiescent states quickly enough will exercise the path through the “Send resched IPIs to Holdout CPUs” box. RCU implementations that avoid unnecessarily awakening dyntick-idle CPUs will mark those CPUs as being in an extended quiescent state, taking the “Y” branch out of the “CPUs in dyntick-idle Mode?” decision diamond (but note that CPUs in dyntick-idle mode will not be sent resched IPIs). Finally, if CONFIG_RCU_CPU_STALL_DETECTOR is enabled, truly excessive delays in reaching quiescent states will exercise the “Complain About Holdout CPUs” path.

The events in the above state schematic interact with different data structures, as shown below:

However, the state schematic does not directly translate into C code for any of the RCU implementations. Instead, these implementations are coded as an event-driven system within the kernel. Therefore, the following section describes some “use cases”, or ways in which the RCU algorithm traverses the above state schematic as well as the relevant data structures.

Use Cases

This section gives an overview of several “use cases” within the RCU implementation, listing the data structures touched and the functions invoked. The use cases are as follows:

1. Start a new grace period.
2. Pass through a quiescent state.
3. Announce a quiescent state to RCU.
4. Enter and leave dynticks idle mode.
5. Interrupt from dynticks idle mode.
6. NMI from dynticks idle mode.
7. Note that a CPU is in dynticks idle mode.
8. Offline a CPU.
9. Online a CPU.
10. Detect a too-long grace period.

Each of these use cases is described in the following sections.

Start a New Grace Period

The rcu_start_gp() function starts a new grace period. This function is invoked when a CPU having callbacks waiting for a grace period notices that no grace period is in progress.

The rcu_start_gp() function updates state in the rcu_state and rcu_data structures to note the newly started grace period, acquires the ->onoff lock (and disables irqs) to exclude any concurrent CPU-hotplug operations, sets the bits in all of the rcu_node structures to indicate that all CPUs (including this one) must pass through a quiescent state, and finally releases the ->onoff lock.

The bit-setting operation is carried out in two phases. First, the non-leaf rcu_node structures' bits are set without holding any additional locks, and then finally each leaf rcu_node structure's bits are set in turn while holding that structure's ->lock.

Quick Quiz 6: But what happens if a CPU tries to report going through a quiescent state (by clearing its bit) before the bit-setting CPU has finished?

Quick Quiz 7: And what happens if all CPUs try to report going through a quiescent state before the bit-setting CPU has finished, thus ending the new grace period before it starts?

Pass Through a Quiescent State

The rcu and rcu_bh flavors of RCU have different sets of quiescent states. Quiescent states for rcu are context switch, idle (either dynticks or the idle loop), and user-mode execution, while quiescent states for rcu_bh are any code outside of softirq with interrupts enabled. Note that an quiescent state for rcu is also a quiescent state for rcu_bh. Quiescent states for rcu are recorded by invoking rcu_qsctr_inc(), while quiescent states for rcu_bh are recorded by invoking rcu_bh_qsctr_inc(). These two functions record their state in the current CPU's rcu_data structure.

These functions are invoked from the scheduler, from __do_softirq(), and from rcu_check_callbacks(). This latter function is invoked from the scheduling-clock interrupt, and analyzes state to determine whether this interrupt occurred within a quiescent state, invoking rcu_qsctr_inc() and/or rcu_bh_qsctr_inc(), as appropriate. It also raises RCU_SOFTIRQ, which results in rcu_process_callbacks() being invoked on the current CPU at some later time from softirq context.

Announce a Quiescent State to RCU

The afore-mentioned rcu_process_callbacks() function has several duties:

1. Determining when to take measures to end an over-long grace period (via force_quiescent_state()).
2. Taking appropriate action when some other CPU detected the end of a grace period (via rcu_process_gp_end()). “Appropriate action“ includes advancing this CPU's callbacks and recording the new grace period. This same function updates state in response to some other CPU starting a new grace period.
3. Reporting the current CPU's quiescent states to the core RCU mechanism (via rcu_check_quiescent_state(), which in turn invokes cpu_quiet()). This of course might mark the end of the current grace period.
4. Starting a new grace period if there is no grace period in progress and this CPU has RCU callbacks still waiting for a grace period (via cpu_needs_another_gp() and rcu_start_gp()).
5. Invoking any of this CPU's callbacks whose grace period has ended (via rcu_do_batch()).

These interactions are carefully orchestrated in order to avoid buggy behavior such as reporting a quiescent state from the previous grace period against the current grace period.

Enter and Leave Dynticks Idle Mode

The scheduler invokes rcu_enter_nohz() to enter dynticks-idle mode, and invokes rcu_exit_nohz() to exit it. The rcu_enter_nohz() function increments a per-CPU dynticks_nesting variable and also a per-CPU dynticks counter, the latter of which which must then have an even-numbered value. The rcu_exit_nohz() function decrements this same per-CPU dynticks_nesting variable, and again increments the per-CPU dynticks counter, the latter of which must then have an odd-numbered value.

The dynticks counter can be sampled by other CPUs. If the value is even, the first CPU is in an extended quiescent state. Similarly, if the counter value changes during a given grace period, the first CPU must have been in an extended quiescent state at some point during the grace period. However, there is another dynticks_nmi per-CPU variable that must also be sampled, as will be discussed below.

Interrupt from Dynticks Idle Mode

Interrupts from dynticks idle mode are handled by rcu_irq_enter() and rcu_irq_exit(). The rcu_irq_enter() function increments the per-CPU dynticks_nesting variable, and, if the prior value was zero, also increments the dynticks per-CPU variable (which must then have an odd-numbered value).

The rcu_irq_exit() function decrements the per-CPU dynticks_nesting variable, and, if the new value is zero, also increments the dynticks per-CPU variable (which must then have an even-numbered value).

Note that entering an irq handler exits dynticks idle mode and vice versa. This enter/exit anti-correspondence can cause much confusion. You have been warned.

NMI from Dynticks Idle Mode

NMIs from dynticks idle mode are handled by rcu_nmi_enter() and rcu_nmi_exit(). These functions both increment the dynticks_nmi counter, but only if the aforementioned dynticks counter is even. In other words, NMI's refrain from manipulating the dynticks_nmi counter if the NMI occurred in non-dynticks-idle mode or within an interrupt handler.

The only difference between these two functions is the error checks, as rcu_nmi_enter() must leave the dynticks_nmi counter with an odd value, and rcu_nmi_exit() must leave this counter with an even value.

Note That a CPU is in Dynticks Idle Mode

The force_quiescent_state() function implements a two-phase state machine. In the first phase (RCU_SAVE_DYNTICK), the dyntick_save_progress_counter() function scans the CPUs that have not yet reported a quiescent state, recording their per-CPU dynticks and dynticks_nmi counters. If these counters both have even-numbered values, then the corresponding CPU is in dynticks-idle state, which is therefore noted as an extended quiescent state (reported via cpu_quiet_msk()). In the second phase (RCU_FORCE_QS), the rcu_implicit_dynticks_qs() function again scans the CPUs that have not yet reported a quiescent state (either explicitly or implicitly during the RCU_SAVE_DYNTICK phase), again checking the per-CPU dynticks and dynticks_nmi counters. If each of these has either changed in value or is now even, then the corresponding CPU has either passed through or is now in dynticks idle, which as before is noted as an extended quiescent state.

If rcu_implicit_dynticks_qs() finds that a given CPU has neither been in dynticks idle mode nor reported a quiescent state, it invokes rcu_implicit_offline_qs(), which checks to see if that CPU is offline, which is also reported as an extended quiescent state. If the CPU is online, then rcu_implicit_offline_qs() sends it a reschedule IPI in an attempt to remind it of its duty to report a quiescent state to RCU.

Note that force_quiescent_state() does not directly invoke either dyntick_save_progress_counter() or rcu_implicit_dynticks_qs(), instead passing these functions to an intervening rcu_process_dyntick() function that abstracts out the common code involved in scanning the CPUs and reporting extended quiescent states.

Quick Quiz 8: And what happens if one CPU comes out of dyntick-idle mode and then passed through a quiescent state just as another CPU notices that the first CPU was in dyntick-idle mode? Couldn't they both attempt to report a quiescent state at the same time, resulting in confusion?

Quick Quiz 9: But what if all the CPUs end up in dyntick-idle mode? Wouldn't that prevent the current RCU grace period from ever ending?

Quick Quiz 10: Given that force_quiescent_state() is a two-phase state machine, don't we have double the scheduling latency due to scanning all the CPUs?

Offline a CPU

CPU-offline events cause rcu_cpu_notify() to invoke rcu_offline_cpu(), which in turn invokes __rcu_offline_cpu() on both the rcu and the rcu_bh instances of the data structures. This function clears the outgoing CPU's bits so that future grace periods will not expect this CPU to announce quiescent states, and further invokes cpu_quiet() in order to announce the offline-induced extended quiescent state. This work is performed with the global ->onofflock held in order to prevent interference with concurrent grace-period initialization.

Quick Quiz 11: But the other reason to hold ->onofflock is to prevent multiple concurrent online/offline operations, right?

Online a CPU

CPU-online events cause rcu_cpu_notify() to invoke rcu_online_cpu(), which initializes the incoming CPU's dynticks state, and then invokes rcu_init_percpu_data() to initialize the incoming CPU's rcu_data structure, and also to set this CPU's bits (again protected by the global ->onofflock) so that future grace periods will wait for a quiescent state from this CPU. Finally, rcu_online_cpu() sets up the RCU softirq vector for this CPU.

Quick Quiz 12: Given all these acquisitions of the global ->onofflock, won't there be horrible lock contention when running with thousands of CPUs?

Detect a Too-Long Grace Period

When the CONFIG_RCU_CPU_STALL_DETECTOR kernel parameter is specified, the record_gp_stall_check_time() function records the time and also a timestamp set three seconds into the future. If the current grace period still has not ended by that time, the check_cpu_stall() function will check for the culprit, invoking print_cpu_stall() if the current CPU is the holdout, or print_other_cpu_stall() if it is some other CPU. A two-jiffies offset helps ensure that CPUs report on themselves when possible, taking advantage of the fact that a CPU can normally do a better job of tracing its own stack than it can tracing some other CPU's stack.

Testing

RCU is fundamental synchronization code, so any failure of RCU results in random, difficult-to-debug memory corruption. It is therefore extremely important that RCU be highly reliable. Some of this reliability stems from careful design, but at the end of the day we must also rely on heavy stress testing, otherwise known as torture.

Fortunately, although there has been some debate as to exactly what populations are covered by the provisions of the Geneva Convention, it is still the case that it does not apply to software. Therefore, it is still legal to torture your software. In fact, it is strongly encouraged, because if you don't torture your software, it will end up torturing you by crashing at the most inconvenient times imaginable.

Therefore, we torture RCU quite vigorously using the rcutorture module.

However, it is not sufficient to torture the common-case uses of RCU. It is also necessary to torture it in unusual situations, for example, when concurrently onlining and offlining CPUs and when CPUs are concurrently entering and exiting dynticks idle mode. I use a script to online and offline CPUs, and use the test_no_idle_hz module parameter to rcutorture to stress-test dynticks idle mode. Just to be fully paranoid, I sometimes run a kernbench workload in parallel as well. Ten hours of this sort of torture on a 128-way machine seems sufficient to shake out most bugs.

Even this is not the complete story. As Alexey Dobriyan and Nick Piggin demonstrated in early 2008, it is also necessary to torture RCU with all relevant combinations of kernel parameters. The relevant kernel parameters may be identified using yet another script, and are as follows:

1. CONFIG_CLASSIC_RCU: Classic RCU.
2. CONFIG_PREEMPT_RCU: Preemptable (real-time) RCU.
3. CONFIG_TREE_RCU: Classic RCU for huge SMP systems.
4. CONFIG_RCU_FANOUT: Number of children for each rcu_node.
5. CONFIG_RCU_FANOUT_EXACT: Balance the rcu_node tree.
6. CONFIG_HOTPLUG_CPU: Allow CPUs to be offlined and onlined.
7. CONFIG_NO_HZ: Enable dyntick-idle mode.
8. CONFIG_SMP: Enable multi-CPU operation.
9. CONFIG_RCU_CPU_STALL_DETECTOR: Enable RCU to detect when CPUs go on extended quiescent-state vacations.
10. CONFIG_RCU_TRACE: Generate RCU trace files in debugfs.

We ignore the CONFIG_DEBUG_LOCK_ALLOC configuration variable under the perhaps-naive assumption that hierarchical RCU could not have broken lockdep. There are still 10 configuration variables, which would result in 1,024 combinations if they were independent boolean variables. Fortunately the first three are mutually exclusive, which reduces the number of combinations down to 384, but CONFIG_RCU_FANOUT can take on values from 2 to 64, increasing the number of combinations to 12,096. This is an infeasible number of combinations.

One key observation is that only CONFIG_NO_HZ and CONFIG_PREEMPT can be expected to have changed behavior if either CONFIG_CLASSIC_RCU or CONFIG_PREEMPT_RCU are in effect, as only these portions of the two pre-existing RCU implementations were changed during this effort. This cuts out almost two thirds of the possible combinations.

Furthermore, not all of the possible values of CONFIG_RCU_FANOUT produce significantly different results, in fact only a few cases really need to be tested separately:

1. Single-node “tree”.
2. Two-level balanced tree.
3. Three-level balanced tree.
4. Autobalanced tree, where CONFIG_RCU_FANOUT specifies an unbalanced tree, but such that it is auto-balanced in absence of CONFIG_RCU_FANOUT_EXACT.
5. Unbalanced tree.

Looking further, CONFIG_HOTPLUG_CPU makes sense only given CONFIG_SMP, and CONFIG_RCU_CPU_STALL_DETECTOR is independent, and really only needs to be tested once (though someone even more paranoid than am I might decide to test it both with and without CONFIG_SMP). Similarly, CONFIG_RCU_TRACE need only be tested once, but the truly paranoid (such as myself) will choose to run it both with and without CONFIG_NO_HZ. This allows us to obtain excellent coverage of RCU with only 15 test cases. All test cases specify the following configuration parameters in order to run rcutorture and so that CONFIG_HOTPLUG_CPU=n actually takes effect:

CONFIG_RCU_TORTURE_TEST=m
CONFIG_MODULE_UNLOAD=y
CONFIG_SUSPEND=n
CONFIG_HIBERNATION=n

The 15 test cases are as follows:

1. Force single-node “tree” for small systems:

   	CONFIG_NR_CPUS=8
   	CONFIG_RCU_FANOUT=8
   	CONFIG_RCU_FANOUT_EXACT=n
   	CONFIG_RCU_TRACE=y
   	

2. Force two-level tree for large systems:

   	CONFIG_NR_CPUS=8
   	CONFIG_RCU_FANOUT=4
   	CONFIG_RCU_FANOUT_EXACT=n
   	CONFIG_RCU_TRACE=n
   	

3. Force three-level tree for huge systems:

   	CONFIG_NR_CPUS=8
   	CONFIG_RCU_FANOUT=2
   	CONFIG_RCU_FANOUT_EXACT=n
   	CONFIG_RCU_TRACE=y
   	

4. Test autobalancing to a balanced tree:

   	CONFIG_NR_CPUS=8
   	CONFIG_RCU_FANOUT=6
   	CONFIG_RCU_FANOUT_EXACT=n
   	CONFIG_RCU_TRACE=y
   	

5. Test unbalanced tree:

   	CONFIG_NR_CPUS=8
   	CONFIG_RCU_FANOUT=6
   	CONFIG_RCU_FANOUT_EXACT=y
   	CONFIG_RCU_CPU_STALL_DETECTOR=y
   	CONFIG_RCU_TRACE=y
   	

6. Disable CPU-stall detection:

   	CONFIG_SMP=y
   	CONFIG_NO_HZ=y
   	CONFIG_RCU_CPU_STALL_DETECTOR=n
   	CONFIG_HOTPLUG_CPU=y
   	CONFIG_RCU_TRACE=y
   	

7. Disable CPU-stall detection and dyntick idle mode:

   	CONFIG_SMP=y
   	CONFIG_NO_HZ=n
   	CONFIG_RCU_CPU_STALL_DETECTOR=n
   	CONFIG_HOTPLUG_CPU=y
   	CONFIG_RCU_TRACE=y
   	

8. Disable CPU-stall detection and CPU hotplug:

   	CONFIG_SMP=y
   	CONFIG_NO_HZ=y
   	CONFIG_RCU_CPU_STALL_DETECTOR=n
   	CONFIG_HOTPLUG_CPU=n
   	CONFIG_RCU_TRACE=y
   	

9. Disable CPU-stall detection, dyntick idle mode, and CPU hotplug:

   	CONFIG_SMP=y
   	CONFIG_NO_HZ=n
   	CONFIG_RCU_CPU_STALL_DETECTOR=n
   	CONFIG_HOTPLUG_CPU=n
   	CONFIG_RCU_TRACE=y
   	

10. Disable SMP, CPU-stall detection, dyntick idle mode, and CPU hotplug:

    	CONFIG_SMP=n
    	CONFIG_NO_HZ=n
    	CONFIG_RCU_CPU_STALL_DETECTOR=n
    	CONFIG_HOTPLUG_CPU=n
    	CONFIG_RCU_TRACE=y
    	

    This combination located a number of compiler warnings.

11. Disable SMP and CPU hotplug:

    	CONFIG_SMP=n
    	CONFIG_NO_HZ=n
    	CONFIG_RCU_CPU_STALL_DETECTOR=n
    	CONFIG_HOTPLUG_CPU=n
    	CONFIG_RCU_TRACE=y
    	

12. Test Classic RCU with dynticks idle but without preemption:

    	CONFIG_NO_HZ=y
    	CONFIG_PREEMPT=n
    	CONFIG_RCU_TRACE=y
    	

13. Test Classic RCU with preemption but without dynticks idle:

    	CONFIG_NO_HZ=n
    	CONFIG_PREEMPT=y
    	CONFIG_RCU_TRACE=y
    	

14. Test Preemptable RCU with dynticks idle:

    	CONFIG_NO_HZ=y
    	CONFIG_PREEMPT=y
    	CONFIG_RCU_TRACE=y
    	

15. Test Preemptable RCU without dynticks idle:

    	CONFIG_NO_HZ=n
    	CONFIG_PREEMPT=y
    	CONFIG_RCU_TRACE=y
    	

For a large change that affects RCU core code, one should run rcutorture for each of the above combinations, and concurrently with CPU offlining and onlining for cases with CONFIG_HOTPLUG_CPU. For small changes, it may suffice to run kernbench in each case. Of course, if the change is confined to a particular subset of the configuration parameters, it may be possible to reduce the number of test cases.

Torturing software: the Geneva Convention does not (yet) prohibit it, and I strongly recommend it!!!

Conclusion

This hierarchical implementation of RCU reduces lock contention, avoids unnecessarily awakening dyntick-idle sleeping CPUs, while helping to debug Linux's hotplug-CPU code paths. This implementation is designed to handle single systems with thousands of CPUs, and on 64-bit systems has an architectural limitation of a quarter million CPUs, a limit I expect to be sufficient for at least the next few years.

This RCU implementation of course has some limitations:

1. The force_quiescent_state() can scan the full set of CPUs with irqs disabled. This would be fatal in a real-time implementation of RCU, so if hierarchy ever needs to be introduced to preemptable RCU, some other approach will be required. It is possible that it will be problematic on 4,096-CPU systems, but actual testing on such systems is required to prove this one way or the other.

   On busy systems, the force_quiescent_state() scan would not be expected to happen, as CPUs should pass through quiescent states within three jiffies of the start of a quiescent state. On semi-busy systems, only the CPUs in dynticks-idle mode throughout would need to be scanned. In some cases, for example when a dynticks-idle CPU is handling an interrupt during a scan, subsequent scans are required. However, each such scan is performed separately, so scheduling latency is degraded by the overhead of only one such scan.

   If this scan proves problematic, one straightforward solution would be to do the scan incrementally. This would increase code complexity slightly and would also increase the time required to end a grace period, but would nonetheless be a likely solution.

2. The rcu_node hierarchy is created at compile time, and is therefore sized for the worst-case NR_CPUS number of CPUs. However, even for 4,096 CPUs, the rcu_node hierarchy consumes only 65 cache lines on a 64-bit machine (and just you try accommodating 4,096 CPUs on a 32-bit machine!). Of course, a kernel built with NR_CPUS=4096 running on a 16-CPU machine would use a two-level tree when a single-node tree would work just fine. Although this configuration would incur added locking overhead, this does not affect hot-path read-side code, so should not be a problem in practice.

3. This patch does increase kernel text and data somewhat: the old Classic RCU implementation consumes 1,757 bytes of kernel text and 456 bytes of kernel data for a total of 2,213 bytes, while the new hierarchical RCU implementation consumes 4,006 bytes of kernel text and 624 bytes of kernel data for a total of 4,630 bytes on a NR_CPUS=4 system. This is a non-problem even for most embedded systems, which often come with hundreds of megabytes of main memory. However, if this is a problem for tiny embedded systems, it may be necessary to provide both “scale up” and “scale down” implementations of RCU.

This hierarchical RCU implementation should nevertheless be a vast improvement over Classic RCU for machines with hundreds of CPUs. After all, Classic RCU was designed for systems with only 16-32 CPUs.

At some point, it may be necessary to also apply hierarchy to the preemptable RCU implementation. This will be challenging due to the modular arithmetic used on the per-CPU counter pairs, but should be doable.

Acknowledgements

I am indebted to Manfred Spraul for ideas, review comments, bugs spotted, as well as some good healthy competition, to Josh Triplett, Ingo Molnar, Peter Zijlstra, Mathieu Desnoyers, Lai Jiangshan, Andi Kleen, Andy Whitcroft, Gautham Shenoy, and Andrew Morton for review comments, and to Thomas Gleixner for much help with timer issues. I am thankful to Jon M. Tollefson, Tim Pepper, Andrew Theurer, Jose R. Santos, Andy Whitcroft, Darrick Wong, Nishanth Aravamudan, Anton Blanchard, and Nathan Lynch for keeping machines alive despite my (ab)use for this project. We all owe thanks to Peter Zijlstra, Gautham Shenoy, Lai Jiangshan, and Manfred Spraul for helping (in some cases unwittingly) render this document at least partially human readable. Finally, I am grateful to Kathy Bennett for her support of this effort.

This work represents the view of the authors and does not necessarily represent the view of IBM.

Linux is a registered trademark of Linus Torvalds.

Other company, product, and service names may be trademarks or service marks of others.

Answers to Quick Quizzes

Quick Quiz 1: Wait a minute! With all those new locks, how do you avoid deadlock?

Answer: Deadlock is avoided by never holding more than one of the rcu_node structures' locks at a given time. This algorithm uses two more locks, one to prevent CPU hotplug operations from running concurrently with grace-period advancement (onofflock) and another to permit only one CPU at a time from forcing a quiescent state to end quickly (fqslock). These are subject to a locking hierarchy, so that fqslock must be acquired before onofflock, which in turn must be acquired before any of the rcu_node structures' locks.

Also, as a practical matter, refusing to ever hold more than one of the rcu_node locks means that it is unnecessary to track which ones are held. Such tracking would be painful as well as unnecessary.

Back to Quick Quiz 1.

Quick Quiz 2: Why stop at a 64-times reduction? Why not go for a few orders of magnitude instead?

Answer: RCU works with no problems on systems with a few hundred CPUs, so allowing 64 CPUs to contend on a single lock leaves plenty of headroom. Keep in mind that these locks are acquired quite rarely, as each CPU will check in about one time per grace period, and grace periods extend for milliseconds.

Back to Quick Quiz 2.

Quick Quiz 3: But I don't care about McKenney's lame excuses in the answer to Quick Quiz 2!!! I want to get the number of CPUs contending on a single lock down to something reasonable, like sixteen or so!!!

Answer: OK, have it your way, then!!! Set CONFIG_RCU_FANOUT=16 and (for NR_CPUS=4096) you will get a three-level hierarchy with with 256 rcu_node structures at the lowest level, 16 rcu_node structures as intermediate nodes, and a single root-level rcu_node. The penalty you will pay is that more rcu_node structures will need to be scanned when checking to see which CPUs need help completing their quiescent states (256 instead of only 64).

Back to Quick Quiz 3.

Quick Quiz 4: OK, so what is the story with the colors?

Answer: Data structures analogous to rcu_state (including rcu_ctrlblk) are yellow, those containing the bitmaps used to determine when CPUs have checked in are pink, and the per-CPU rcu_data structures are blue. Later on, we will see that data structures used to conserve energy (such as rcu_dynticks) will be green.

Back to Quick Quiz 4.

Quick Quiz 5: Given such an egregious bug, why does Linux run at all?

Answer: Because the Linux kernel contains device drivers that are (relatively) well behaved. Few if any of them spin in RCU read-side critical sections for the many milliseconds that would be required to provoke this bug. The bug nevertheless does need to be fixed, and this variant of RCU does fix it.

Back to Quick Quiz 5.

Quick Quiz 6: But what happens if a CPU tries to report going through a quiescent state (by clearing its bit) before the bit-setting CPU has finished?

Answer: There are three cases to consider here:

1. A CPU corresponding to a non-yet-initialized leaf rcu_node structure tries to report a quiescent state. This CPU will see its bit already cleared, so will give up on reporting its quiescent state. Some later quiescent state will serve for the new grace period.
2. A CPU corresponding to a leaf rcu_node structure that is currently being initialized tries to report a quiescent state. This CPU will see that the rcu_node structure's ->lock is held, so will spin until it is released. But once the lock is released, the rcu_node structure will have been initialized, reducing to the following case.
3. A CPU corresponding to a leaf rcu_node that has already been initialized tries to report a quiescent state. This CPU will find its bit set, and will therefore clear it. If it is the last CPU for that leaf node, it will move up to the next level of the hierarchy. However, this CPU cannot possibly be the last CPU in the system to report a quiescent state, given that the CPU doing the initialization cannot yet have checked in.

So, in all three cases, the potential race is resolved correctly.

Back to Quick Quiz 6.

Quick Quiz 7: And what happens if all CPUs try to report going through a quiescent state before the bit-setting CPU has finished, thus ending the new grace period before it starts?

Answer: The bit-setting CPU cannot pass through a quiescent state during initialization, as it has irqs disabled. Its bits therefore remain non-zero, preventing the grace period from ending until the data structure has been fully initialized.

Back to Quick Quiz 7.

Quick Quiz 8: And what happens if one CPU comes out of dyntick-idle mode and then passed through a quiescent state just as another CPU notices that the first CPU was in dyntick-idle mode? Couldn't they both attempt to report a quiescent state at the same time, resulting in confusion?

Answer: They will both attempt to acquire the lock on the same leaf rcu_node structure. The first one to acquire the lock will report the quiescent state and clear the appropriate bit, and the second one to acquire the lock will see that this bit has already been cleared.

Back to Quick Quiz 8.

Quick Quiz 9: But what if all the CPUs end up in dyntick-idle mode? Wouldn't that prevent the current RCU grace period from ever ending?

Answer: Indeed it will! However, CPUs that have RCU callbacks are not permitted to enter dyntick-idle mode, so the only way that all the CPUs could possibly end up in dyntick-idle mode would be if there were absolutely no RCU callbacks in the system. And if there are no RCU callbacks in the system, then there is no need for the RCU grace period to end. In fact, there is no need for the RCU grace period to even start.

RCU will restart if some irq handler does a call_rcu(), which will cause an RCU callback to appear on the corresponding CPU, which will force that CPU out of dyntick-idle mode, which will in turn permit the current RCU grace period to come to an end.

Back to Quick Quiz 9.

Quick Quiz 10: Given that force_quiescent_state() is a two-phase state machine, don't we have double the scheduling latency due to scanning all the CPUs?

Answer: Ah, but the two phases will not execute back-to-back on the same CPU. Therefore, the scheduling-latency hit of the two-phase algorithm is no different than that of a single-phase algorithm. If the scheduling latency becomes a problem, one approach would be to recode the state machine to scan the CPUs incrementally. But first show me a problem in the real world, then I will consider fixing it!

Back to Quick Quiz 10.

Quick Quiz 11: But the other reason to hold ->onofflock is to prevent multiple concurrent online/offline operations, right?

Answer: Actually, no! The CPU-hotplug code's synchronization design prevents multiple concurrent CPU online/offline operations, so only one CPU online/offline operation can be executing at any given time. Therefore, the only purpose of ->onofflock is to prevent a CPU online or offline operation from running concurrently with grace-period initialization.

Back to Quick Quiz 11.

Quick Quiz 12: Given all these acquisitions of the global ->onofflock, won't there be horrible lock contention when running with thousands of CPUs?

Answer: Actually, there can be only three acquisitions of this lock per grace period, and each grace period lasts many milliseconds. One of the acquisitions is by the CPU initializing for the current grace period, and the other two onlining and offlining some CPU. These latter two cannot run concurrently due to the CPU-hotplug locking, so at most two CPUs can be contending for this lock at any given time.

Lock contention on ->onofflock should therefore be no problem, even on systems with thousands of CPUs.

Back to Quick Quiz 12.

Comments (10 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.28-rc3. (November 2, 2008)

Core kernel code

• Oren Laadan: Kernel based checkpoint/restart. (October 30, 2008)

Development tools

• Steven Rostedt: trace: profile likely and unlikely annotations. (October 30, 2008)

• Peter Zijlstra: ftrace: sysrq-z to dump the buffers. (November 2, 2008)

• Arjan van de Ven: ftrace: add an fsync tracer. (November 5, 2008)

• Subrata Modak: [ANNOUNCE] The Linux Test Project has been Released for OCTOBER 2008. (November 3, 2008)

Device drivers

• Eric Anholt: [PATCH] Add io-mapping functions to dynamically map large device apertures. (November 2, 2008)

• Keith Packard: [x86_32] Add io_map_atomic using fixmaps. (November 4, 2008)

• Matthew Garrett: Add option to passively listen for PCIE hotplug events. (November 3, 2008)

• Jesse Barnes: DRM based modesetting for drm-next. (November 3, 2008)

• Constantin Baranov: led: ALIX.2 LEDs driver. (November 4, 2008)

• Jon Smirl: In-kernel IR remote control support. (November 5, 2008)

Documentation

• Michael Kerrisk: man-pages-3.12 is released. (October 30, 2008)

Filesystems and block I/O

• Boaz Harrosh: osdfs. (November 3, 2008)

• Boaz Harrosh: open-osd: OSD Initiator library for Linux. (November 4, 2008)

• Frank Mayhar: Allow ext4 to run without a journal.. (November 3, 2008)

• Chris Mason: New btrfs disk format in -unstable (compression!). (November 3, 2008)

• Michael Halcrow: eCryptfs: Filename Encryption. (November 4, 2008)

Memory management

• David Rientjes: cpuset writeback throttling. (November 2, 2008)

• Christoph Lameter: Git next: Second stage of cpu_alloc patches. (November 5, 2008)

Networking

• Injong Rhee: CUBIC v2.3 with new improved slow start. (November 3, 2008)

• Luis R. Rodriguez: wireless: Add 802.11d support. (November 4, 2008)

• Julius Volz: IPVS: Add IPv6 support to LBLC/LBLCR schedulers. (November 4, 2008)

Architecture-specific

• holt@sgi.com: Enable irqs when waiting for rwlocks. (November 4, 2008)

Security-related

• Jeff Garzik: crypto: Add Skein hash algorithm variants. (November 2, 2008)

• Kentaro Takeda: TOMOYO Linux. (November 4, 2008)

Virtualization and containers

• Balbir Singh: Memory cgroup hierarchy introduction. (November 2, 2008)

• Ying Han: Per-cgroup OOM handler. (November 4, 2008)

Benchmarks and bugs

• Rafael J. Wysocki: 2.6.28-rc2-git7: Reported regressions from 2.6.27. (November 2, 2008)

• Rafael J. Wysocki: 2.6.28-rc2-git7: Reported regressions 2.6.26 -> 2.6.27. (November 2, 2008)

• Arjan van de Ven: Oops/warning report for the week of November 4th, 2008. (November 4, 2008)

Miscellaneous

• Jonas Bonn: API for system clocks (oscillators). (October 30, 2008)

• Joern Engel: B+Tree library V2. (November 2, 2008)

• Ian Kent: autofs 5.0.4 release. (November 4, 2008)

Page editor: Jonathan Corbet

Distributions

News and Editorials

Interview with the openSUSE board

The openSUSE project recently welcomed the first community elected board. The previous board was appointed by Novell. The new board consists of both Novell employees and non-Novell members of the community. From the Non-Novell side of the community Pascal Bleser and Bryen Yunashko were elected, and from the Novell side Henne Vogelsang and Federico Mena-Quintero were elected. Novell appointed Michael Löffler as chairman of the board. We asked the new board a few questions and are pleased to present their responses.

LWN: There was some discussion in the mailing lists prior to the election about the definition of a member. The current definition says: "openSUSE Members" are specifically distinguished contributors who have brought a continued and substantial contribution to the openSUSE project."

Do you agree with this definition? What is your definition of "continued and substantial"?

LWN: Does Novell adequately support openSUSE? Should Novell do more to support the project?

LWN: Does Novell exert too much control over the project? Where are the areas where Novell could allow more community control?

LWN: Is the current board, with 5 members (2 Novell + 3 non), a good size and does it achieve the right balance of corporate vs. community?

LWN: In the openSUSE election members were able to name another contributor (non-member) to be a voter. Would you like to see this continue in future elections? Do you know if there were many non-members who voted in this election?

LWN: How do regular users get more involved? How can they contribute to both the technical work and the decision making?

LWN: Do you see areas of collaboration with other distributions either currently or in the future?

Editor's note: We would like to thank the openSUSE Board for taking the time to answer our questions. Readers may notice that not all board members have answered every question. This was their choice and not due to any censorship on our part.

Comments (none posted)

New Releases

Fedora 10 preview release

The Fedora 10 preview release is now available. "Doesn't it smell yummy? We know you can't resist, and we don't want you to. We want everyone in the Fedora community to take an early sample and tell us what you find. The recipe is pretty good, but now is the time to make it perfect." This is the last testing release for this cycle. See the release notes for an overview of what Fedora 10 brings.

Full Story (comments: 10)

Announcing Fedora Sugar Spin!

Fedora has a Sugar Spin available, which incorporates the Sugar Desktop Environment on a Fedora Live CD. "So, what is this in specific? With this spin, you'll be able to run Sugar, which is developed by Sugarlabs and the desktop environment used on the OLPC, directly from a Live CD!"

Full Story (comments: none)

OpenBSD 4.4 released, Nov 1. Enjoy!

The OpenBSD project has announced the official release of OpenBSD 4.4. Click below for a list of new features, new platform support and more.

Full Story (comments: 3)

openSUSE 11.1 Beta 4 Now Available

The openSUSE Project has announced the availability of openSUSE 11.1 beta 4. "This release includes a number of important bugfixes since the last beta, as well as a few new bugs that need to be squashed before the final release. Read on for details about this release and how to get involved with testing."

With the release of openSUSE 11.1 Beta4 comes a call for feature testing.

Full Story (comments: none)

Red Hat Delivers Red Hat Enterprise Linux 5.3 Beta

Red Hat has released the Beta of Red Hat Enterprise Linux 5.3. This version has kernel-2.6.18-120.el5 and includes versions for x86, x86/64, Itanium, IBM POWER and System z. The Beta runs until January 6, 2009.

The CentOS community has issued a call for testing of this release. "So if we can improve the testing during the RHEL Beta program, everyone in the CentOS community directly benefits from that as well. Therefore it makes a lot of sense to encourage the large CentOS community to take part in the RHEL Beta program and help with improving the next CentOS releases."

Comments (none posted)

Tin Hat Linux 20081025 released

A new release of Tin Hat Linux is out, with bugs/security fixes.

Full Story (comments: none)

Ubuntu 8.10 has been released

Ubuntu 8.10 "Intrepid Ibex" has been released. "The Ubuntu team is pleased to announce Ubuntu 8.10 Desktop and Server, continuing Ubuntu's tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution."

Full Story (comments: 21)

Distribution News

Fedora

RPM Fusion is now Available

The RPM Fusion project has announced the availability of its repositories of Fedora and Red Hat compatible software. "RPM Fusion is a project started by the Dribble, Freshrpms and Livna teams. It aims to bring together many packagers from various 3rd party repositories and build a single add-on repository for Fedora and Red Hat Enterprise Linux. We hope to attract new Fedora packagers and hope that other 3rd party repositories will join us." Click below for the full announcement.

Full Story (comments: 2)

Announcing Fedora IRC Classroom Sessions

The #fedora-classroom irc channel (on irc.freenode.net) will be open soon for some classroom sessions. "These sessions are intended to be short (30min to an hour) sessions on the IRC network where you can learn about a specific Fedora related topic." Check the schedule to see what topics will be offered.

Full Story (comments: none)

Fedora Board Recap

Click below for a brief recap of the October 28, 2008 meeting of the Fedora Board. Topics include Trademark guidelines, Fedora Sugar Spin, Upcoming Elections, and FUDCon Fedora 11.

Full Story (comments: none)

FESCo Meeting Summary for 2008-10-29

Click below for a summary of the Fedora Engineering Steering Committee meeting for October 29, 2008. Topics include features, elections and comps.

Full Story (comments: none)

SUSE Linux and openSUSE

Advance discontinuation notice of Service Pack 1 of SUSE Linux Enterprise 10

SUSE Security has announced that the maintenance, security and L3 support for Service Pack 1 of the SUSE Linux Enterprise 10 line of products will end November 30, 2008. "We recommend strongly that customers upgrade now to Service Pack 2 of SUSE Linux Enterprise 10."

Full Story (comments: none)

Ubuntu family

The Ubuntu "Jaunty Jackalope" cycle begins

The Ubuntu Project has started the development cycle leading up to the 9.04 release, currently planned for April 23. "We do not recommend that users upgrade to Jaunty at this time; it is likely to be in very considerable flux until the initial round of merges is complete. As ever, any developers wishing to take the plunge at this early stage should ensure that they are comfortable with recovering from anything up to complete system failure."

Full Story (comments: none)

Distribution Newsletters

DistroWatch Weekly, Issue 277

The DistroWatch Weekly for November 3, 2008 is out. "It was the Ubuntu week, with much of the Linux-related coverage on many web sites dominated by the brand new "Intrepid Ibex", the project's latest. A plethora of reviews followed almost instantly, but some subtle hardware issues and lack of real breakthrough features have left some of the users and reviewers unimpressed. In other news, Fedora has unveiled Plymouth, a new flicker-free boot process, Sabayon has hinted at a large number of never-seen-before features for the upcoming 4.0 release, Yellow Dog Linux has launched a beta testing period for its forthcoming version 6.1, and NetBSD is about to branch version 5.0 with some unexpected improvements. Also in this week's issue - Ubuntu has published a draft release schedule for "Jaunty Jackalope" or Ubuntu 9.04. Finally, we are pleased to announce that the recipient of the October 2008 DistroWatch.com donation is GoblinX, a slick Slackware-based live CD made in Brazil."

Comments (none posted)

Echo Monthly News - Issue 3

The Echo Monthly News for October 2008 is out, covering the news about Fedora's Echo Theme. Topics include new icons, new templates, Echo Won't Be F10's Default Icon Theme, Icon Check Script and Echo Future.

Comments (none posted)

Fedora Weekly News #150

The Fedora Weekly News for November 2, 2008 is out. "In this week's issue, featured content includes announcements on a new Fedora Sugar Spin, and development freeze for Fedora 10. The Translation beat this week features an interview with Fedora Translation project member Diego Zacarao (Rasther). In Developments, details on resume from suspend problems with Intel i945s, details on "[a] gigantic multi-thread flamewar consum[ing] many list participants" over moving X from VT7 to VT1 and POSIX file capabilities for Fedora 11. The Artwork beat features discussion of new wallpaper extras, and final fixes for the Fedora 10 Solar backgrounds. The Security Advisory beat rounds out this issue and updates us with fixes released in the last week for Fedora 8 and 9."

Full Story (comments: none)

OpenSUSE Weekly News/44

This issue of the OpenSUSE Weekly News looks at Less then 50 days to openSUSE 11.1, Results of the 1st openSUSE Board Election, Ben Kevan: fslint - Take control about your Filesystem, OpenOffice.org 3.0 final, counter.opensuse.org updated, and more.

Comments (none posted)

Ubuntu Weekly Newsletter #115

The Ubuntu Weekly Newsletter for November 1, 2008 covers: Ubuntu 8.10 released, Ubuntu 8.10: significant new features, UDSJaunty, Ubuntu Open Week, New Contributing Developer, Dustin Kirkland interview #2, Ubuntu Brainstorm 8.10 report, SFD in Tunisia, Launchpad EPIC, Over 6 million Forum posts and counting, Ubuntu Sighting, Full Circle Magazine #18, New TurnKey Linux release, Release week for Ubuntu and CohesiveFT, and much more.

Full Story (comments: none)

Distribution meetings

Ubuntu Open Week!

Ubuntu Open Week starts next Monday, November 3. "Ubuntu Open Week is a week of IRC tuition and Q+A sessions all about getting involved in the rock-and-roll world that is the Ubuntu community. We organise this week for the beginning of a new release cycle to help new contributors get involved. Thanks to Jorge for helping to get the week together and for everyone who is helping to run sessions. Its going to be a fun week!" Tune into #ubuntu-classroom on Freenode to join in the fun.

Full Story (comments: none)

Newsletters and articles of interest

A Closer Look At Red Hat's Plymouth (Phoronix)

Phoronix takes a look at Plymouth, a flicker-free boot process previewing in Fedora 10. "Plymouth has an extensive API that allows artists and programmers to develop graphically rich Plymouth plug-ins. Plymouth is, however, compiled into the system's initial RAM disk (initrd) so there are some limitations. Plug-ins though can rely on loading PNG images as libpng is linked to Plymouth. The plug-ins currently available through the project's git repository currently include details, fade-in, pulser, solar, spinfinity, and text. These plug-ins are also packaged in RPM form on Fedora 10. The Fedora 10 RPMs include plymouth (the main graphical boot package), plymouth-devel (the libraries and headers), plymouth-gdm-hooks (provides integrated with GDM), plymouth-libs (the Plymouth libraries), plymouth-plugin-fade-in, plymouth-plugin-label, plymouth-plugin-pulser, plymouth-plugin-solar, plymouth-plugin-spinfinity, plymouth-scripts (scripts to assist in configuring Plymouth), plymouth-text-and-details-only (intended for those not interested in a rich boot experience), and plymouth-utils (utilities related to Plymouth)."

Comments (none posted)

GSoC Mentor Summit wrap-up

Joe "Zonker" Brockmeir reports on the Google Summer of Code Mentor's Summit. "Overall, I think the FOSS community in general, and distros in particular, are pretty good at being willing to communicate and work together -- the fall-down comes in when a contributor from Project A doesn't know who to contact with Project B. (Hint: Start with the project leader or community manager if you don't know who to start with_) One of the larger discussions was -- how do projects get picked for GSoC and how do projects get passed over."

Comments (none posted)

Distribution reviews

Ubuntu 8.10 Charges Up the Mountain (Linux Journal)

Linux Journal takes a look at the final release of Ubuntu 8.10 "Intrepid Ibex". "Among Intrepid's shiny new packages are upgrades to core portions of the operating system including the kernel itself, which has been updated to the 2.6.27 release. The latest version of X.Org, 7.4, which appeared in September after months of repeated delays, is included, and boasts improved hot-plugging for keyboards, mice, and other input peripherals, a failsafe mechanism to provide better troubleshooting for startup glitches, and for many users, the end of the xorg.conf configuration file."

Comments (none posted)

Kubuntu 8.10 Brings KDE 4 to the Masses (KDE.News)

KDE.News takes a quick look at Kubuntu 8.10 with KDE 4.1. "The Kubuntu developers have been hard at work, integrating this major new version into a completed desktop. The settings and artwork have been kept close to KDE's defaults to ensure the best face of our favourite desktop shines through."

Comments (3 posted)

Page editor: Rebecca Sobol

Development

Linux Connectivity for the Wii Remote

Linux has had support for numerous hand-held infrared remote control devices for many years through the Linux Infra Red Controller (LIRC) drivers. There has been recent work to include LIRC in the kernel. The Nintendo Wii Remote is a more sophisticated remote control that was developed for the Wii game platform, it is accessible through a collection of Linux tools called CWiid. Wikipedia describes the Wii Remote:

The Wiimote hardware capabilities (photo) include:

• Two-way wireless Bluetooth connectivity to the host.
• A screen-mounted Sensor Bar with multiple IR light sources and a 5 meter range.
• A built-in IR camera with distance and rotation sensing capabilities.
• A three axis accelerometer for detecting hand motions.
• Six general purpose remote control pushbuttons labeled A, -, Home, +, 1 and 2.
• An up-down-left-right four-way pushbutton.
• A power switch.
• Four remote controlled LEDs.
• A built-in speaker for providing audio effects.
• A "rumble" device for producing vibrations.
• Built-in non volatile memory with space for user data.
• A hardware expansion port.
• Powered by two AA cells, can use rechargeable types.

CWiid was written by L. Donnie Smith and has been released under the GPLv2. The project has been around since March, 2007 and is currently at version 0.6.00. The libcwiid API document explains the CWiid software interface.

There are currently at least twelve programs using CWiid. Some of the highlights include control of DMX lighting systems with Wiimote Control, 3D display of chemical structures using the Avogadro molecular editor, the WiiOSC control device for music programs and a newly released prototype Wiimote Control for the Ardour multi-track audio editor. Although the Wiimote control is ideal for use in games, there don't appear to be any such developments under Linux at this point.

One of the more interesting uses of the Wiimote includes Head Tracking for an immersive 3D experience, based on the work of Johnny Chung Lee. This approach to 3D visualization produces full-color displays, unlike the the old-fashioned 3D movie technology that uses glasses with red and green lenses. Other 3D technologies require expensive LCD shutters that tend to produce a lot of flicker. The head tracking 3D technology would be well suited for use by the physically disabled.

New Wiimote devices can be purchased for $40 or less. Many of them exist on the used markets, thanks to the popularity of the Wii platform. If your favorite application could benefit from a two-way wireless remote control device with a wide variety of features, the Wiimote looks like a good choice.

Comments (3 posted)

System Applications

Clusters and Grids

JPPF: version 1.6 released (SourceForge)

Version 1.6 of JPPF, the Java Parallel Processing Framework, has been announced. "JPPF is an open source Grid Computing platform written in Java that makes it easy to run applications in parallel, and speed up their execution by orders of magnitude. Write once, deploy once, execute everywhere! The JPPF Team brings new features and bug fixes in this version."

Comments (none posted)

Version 6.1.3 of the UNICORE server and UCC is available (SourceForge)

Version 6.1.3 of the UNICORE server and UCC have been announced. "UNICORE is a modern, Web services and WS-RF based, OGSA-compliant, standards-conform, ready-to-run Grid technology implemented in Java. UNICORE makes distributed computing, data, network, and software resources available in a seamless and secure way."

Comments (none posted)

Database Software

cx_Oracle 4.4.1 released

Version 4.4.1 of cx_Oracle has been announced, a number of new features have been added. "cx_Oracle is a Python extension module that allows access to Oracle and conforms to the Python database API 2.0 specifications with a few exceptions."

Full Story (comments: none)

IMDbPY 3.8 released

Version 3.8 of IMDbPY has been announced. "IMDbPY is a Python package useful to retrieve and manage the data of the IMDb movie database about movies, people, characters and companies. With this release, it's possible to access the data in the sql database using both the SQLObject and SQLAlchemy ORMs. Many bugs were also fixed."

Full Story (comments: none)

phpMyAdmin: Security fix: 3.0.1.1 and 2.11.9.3 (SourceForge)

Versions 3.0.1.1 and 2.11.9.3 of phpMyAdmin have been announced. "phpMyAdmin is a tool written in PHP intended to handle the administration of MySQL over the Web. Currently it can create and drop databases, create/drop/alter tables, delete/edit/add fields, execute any SQL statement, manage keys on fields. Welcome to phpMyAdmin versions 2.11.9.3 and 3.0.1.1 which fix a security problem."

Comments (none posted)

PostgreSQL Weekly News

The November 2, 2008 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.

Full Story (comments: none)

Networking Tools

ZABBIX: 1.6.1 released (SourceForge)

Version 1.6.1 of ZABBIX has been announced, some new capabilities have been added. "ZABBIX is an enterprise-class open source distributed monitoring solution designed to monitor and track performance and availability of network servers, devices and other IT resources. It supports distributed and WEB monitoring, auto-discovery, and more."

Comments (1 posted)

Security

Announcing ClamAV 0.94.1

Version 0.94.1 of ClamAV, a virus scanner, has been announced. "ClamAV 0.94.1 fixes some issues that were found in previous releases and includes one new feature, "Malware Statistics Gathering." This is an optional feature that allows ClamAV users optionally to submit statistics to us about what they detect in the field. We will then use these data to determine what types of malware are the most detected in the field and in what geographic area they are. It will also allow us to publish summary data on www.clamav.net where our users will be able to monitor the latest threats. You can help us by enabling SubmitDetectionStats in freshclam.conf."

Full Story (comments: none)

sqlmap 0.6.2 has been released

Version 0.6.2 of sqlmap has been announced, it includes major bug fixes. "sqlmap is an automatic SQL injection tool developed in Python. Its goal is to detect and take advantage of SQL injection vulnerabilities on web applications."

Full Story (comments: none)

Web Site Development

Apache 2.2.10 released

Version 2.2.10 of the Apache web server has been announced. "This version of Apache is principally a bug and security fix release. The following potential security flaws are addressed: * CVE-2008-2939 (cve.mitre.org) mod_proxy_ftp: Prevent XSS attacks when using wildcards in the path of the FTP URL. Discovered by Marc Bevand of Rapid7. We consider this release to be the best version of Apache available, and encourage users of all prior versions to upgrade."

Full Story (comments: none)

Django 1.0.1 beta is available

Version 1.0.1 beta of the Django web platform has been announced. "Following the previously-announced schedule, today the Django team has released Django 1.0.1 beta 1; this is a preview of the upcoming Django 1.0.1 release, which consists solely of bugfixes and other improvements to the Django 1.0 codebase. This package also follows our policy of maintaining compatibility in the 1.0 release series."

Comments (none posted)

dotCMS: 1.6.5 Released (SourceForge)

Version 1.6.5 of dotCMS has been announced. "dotCMS bridges the gap between php CMSes and J2ee solutions. Included: clustering support, structured content, granular permissions, WYSIWYG editing, events management, e-communications tools. Please visit http://dotcms.org. dotCMS, Inc. is pleased to announce that dotCMS 1.6.5 is available for download. We’ve worked hard to make dotCMS 1.6.5 faster, more robust, more feature rich and easier to use. The new 1.6.5 version includes almost 300 improvements and fixes."

Comments (none posted)

Midgard 8.09.2 released

Version 8.09.2 of the Midgard web development platform has been announced. "The Midgard Project has released the second maintenance release of Midgard 8.09 Ragnaroek LTS. Ragnaroek LTS is a Long Term Support version of the free software content management framework. The 8.09.2 release focuses on major performance improvements and ease of upgrade from earlier Midgard 1.8 installations. It is the first maintenance release in the Ragnaroek series that combines both Midgard and MidCOM."

Full Story (comments: none)

Desktop Applications

Audio Applications

Amarok 2.0 beta 3 released

Version 2.0 beta 3 of the Amarok music player has been announced. "This release is yet another significant step towards the final version. Beta 3 fixes a number of serious bugs and enhances many parts of the application. Some parts underwent significant rewrites in order to fix some deeply rooted problems. All in all, Amarok 2 is now a much more polished application."

Full Story (comments: none)

Ataksak - Beta 3 of Amarok 2.0 released (KDE.News)

KDE.News briefly looks at Amarok 2.0 beta 3. "The Amarok team announces the third beta release of Amarok 2.0, codename Ataksak. It includes a database importer for users of Amarok 1.4, who want to keep their statistics and ratings, as well as a lot of bugfixes and improvements. The playlist, statusbar and Last.fm integration got a major overhaul and are a lot more stable and polished now."

Comments (none posted)

New features come to Ardour

The Ardour multi-track audio editor recently acquired some new capabilities. Prototype Wiimote Control software has been added: "After languishing for months in the horror of hardware construction and the herding of cats, long-time Ardour developer Sampo Savolainen jumped back in to working on his favorite DAW and added support for the Wiimote as a remote control this past weekend. You just need working bluetooth support on your computer, the right library, and of course a Wiimote."

Also, MIDI Clock Sync Comes To Ardour 3.0: "Although Ardour 3.0 is not yet ready for serious testing, it is the subject of some cool development work. Hans Baier just added support for MIDI Clock sync, which means that Ardour's transport can now slave to you MIDI sequencing hardware/software without relying on more sophisticated (and better, but less widely used) protocols like MIDI Machine Control or MIDI Time Code."

Comments (none posted)

Desktop Environments

GNOME Software Announcements

The following new GNOME software has been announced this week:

• at-spi 1.25.1 (bug fixes)
• bug-buddy 2.25.1 (new features and bug fixes)
• Cheese 2.25.1 (bug fixes and translation work)
• Deskbar-Applet 2.25.1 (bug fixes and translation work)
• Eye of GNOME 2.25.1 (bug fixes, code cleanup and translation work)
• GCalctool 5.25.1 (bug fixes and translation work)
• gnome-applets 2.25.1 (new features, bug fixes and code cleanup)
• The Gnome Chemistry Utils 0.10.0 (new features)
• GNOME DVB daemon 0.1.0 (initial release)
• gnome-games 2.24.1.1 (bug fixes and translation work)
• Gnome Games 2.25.1 (bug fixes, code cleanup and translation work)
• gnome-keyring 2.25.1 (code cleanup and translation work)
• gnome-settings-daemon 2.25.1 (new features, bug fixes and code cleanup)
• GObject-Introspection 0.6.0 (new features and bug fixes)
• GOK 2.25.1 (bug fixes and translation work)
• Gtk2-Perl 2.25.1 (new features and bug fixes)
• gtk-engines 2.17.0 (new features and bug fixes)
• libgee 0.1.4 (Update for Vala 0.3.3)
• mousetweaks 2.25.1 (new features, bug fixes and translation work)
• Orca 2.25.1 (bug fixes and translation work)
• Papywizard 1.2. (new features and translation work)
• PyPoppler 0.10.0 (new features)
• RSS-GLib - 0.2.0 (initial release)
• Seahorse 2.25.1 (code cleanup and translation work)
• seahorse-plugins 2.25.1 (code cleanup)
• Vala 0.5.1 (new features and bug fixes)

You can find more new GNOME software releases at gnomefiles.org.

Comments (none posted)

KDE 4.1.3 released

Version 4.1.3 of KDE has been announced. "KDE Community Improves Desktop with KDE 4.1.3 Codenamed "Change". KDE Community Ships Third Translation and Service Release of the 4.1 Free Desktop, Containing Numerous Bugfixes, Performance Improvements and Translation Updates."

Full Story (comments: none)

KDE Software Announcements

The following new KDE software has been announced this week:

• digiKam 0.10.0-beta5 (new features and bug fixes)
• Gimper 1.2 (new features and bug fixes)
• kipi-plugins 0.2.0-beta3 (new features and bug fixes)
• PySMSsend 1.39 (new features and bug fixes)
• QTGZManager Beta4 (new features and bug fixes)
• skrooge 0.1.0 (initial release)
• TreeLine 1.2.1 (bug fixes)
• Xt7-Player 0.7.9 (new features and bug fixes)

You can find more new KDE software releases at kde-apps.org.

Comments (none posted)

Xfce 4.4.3 released

Version 4.4.3 of Xfce, a light weight desktop environment, has been announced. "Just because we're gearing up to release 4.6.0, it doesn't mean we've forgotten the 4.4 branch. A bunch of bug fixes had accumulated since 4.4.2, so we have a new release for you."

Comments (none posted)

Announcing xpra 0.0.5 - 'screen for X'

Version 0.0.5 of xpra has been announced, it includes bug fixes. "Xpra is 'screen for X' -- it allows you to run X programs, usually on a remote host, direct their display to your local machine, and then to disconnect from these programs and reconnect from the same or another machine, without losing any state. It is licensed under the GPLv2+."

Full Story (comments: 4)

Xorg Software Announcements

The following new Xorg software has been announced this week:

• libdrm 2.4.1 (bug fixes)
• libpciaccess 0.10.5 (bug fixes)
• xf86-input-evdev 2.0.99.3 (new features and bug fixes)
• xserver 1.5.3 (new features and bug fixes)

More information can be found on the X.Org Foundation wiki.

Comments (none posted)

Desktop Publishing

StorYBook: Version 2.1.6 released (SourceForge)

Version 2.1.6 of StorYBook has been announced, it adds some new capabilities and a Finnish translation. "Are you novelist, writer or author? StorYBook is a scene-based software for all creative writers that helps to organize your story. StorYBook assists you in structuring your book."

Comments (none posted)

Financial Applications

SQL-Ledger 2.8.18 announced

Version 2.8.18 of SQL-Ledger, a web-based accounting system, has been announced. The What's New document summarized the changes: "workaround for Bizarre copy error caused by perl 5.10, lock order if it has been converted to an invoice, added user name and email for statements, fixed parts history order and added payment method variable for invoices."

Comments (none posted)

Fonts and Images

Linux Libertine 4.1.8 released

Version 4.1.8 of the Linux Libertine font set has been announced, numerous improvements have been added.

Full Story (comments: none)

Games

Cyphesis 0.5.17 released (WorldForge)

The WorldForge virtual world project has announced the release of Cyphesis 0.5.17, a server for WorldForge games. "Major changes in this version: Terrain modifiers are now fully supported. A new persistence backend has been written and is in testing. Properties have been re-written to be way more efficient. Internal metrics and monitors are now exposed using http. Registration with the metaserver is now much more reliable. Simulation is now jittered to make CPU load much smoother. Lots of bugs have been fixed."

Comments (none posted)

libwfut 0.2.1 released (WorldForge)

The WorldForge virtual world project has announced the release of libwfut 0.2.1. "WFUT is a content distribution system initially intended to provide media updates for WorldForge clients. libwfut is a C++ implementation of the client side functionality. This release allows downloads to be aborted, contains some sample python front-ends and fixes a few small bugs. This version will also use a systemwide installation of tinyxml if available."

Comments (none posted)

Sprite2d: New Release 0.8.0 (SourceForge)

Version 0.8.0 of Sprite2d has been announced. Sprite2d is: "A Java framework for writing sprite based games (turn-based, card, and arcade games.) Provides: Sprite management, rendering (Java2d or OpenGL), Collision Detection, Sprite widgets (buttons etc...), visual editor for layout of game widgets. We have released a new version of Sprite2d. This is another large change that includes: Event Containers, Font Creator, and new Demo called Slide Puzzle."

Comments (none posted)

WOMBAT 0.4.0 and 0.4.1 released (WorldForge)

The WorldForge virtual world project has announced the release of WOMBAT 0.4.0 and 0.4.1, the WorldForge Open Media Browser/Artist Tool. "New features in these versions include: * Completely revamped look and feel * Support for users and roles * Actions that change the server’s data * Custom icons that reflect the content of the media, if possible * New stock icons from the Tango project * Display total number of files under a directory to simplify browsing"

Comments (none posted)

Graphics

Cairo release 1.8.2 now available

Version 1.8.2 of the Cairo graphics library has been announced. "This is the first update to cairo's stable 1.8 series and contains a large number of bug fixes. It is being released just over one month since cairo 1.8.0. This release consists primarily of bug fixes, but there is one notable new feature, (the ability to build cairo without an external font backend), and there are a few optimizations as well."

Full Story (comments: none)

GUI Packages

New Qt Creator IDE from Qt Software (KDE.News)

KDE.News takes a look at a new IDE for Qt. "News emerged recently that Qt Software (formerly Trolltech) were working on their first IDE for Qt, code named Project Greenhouse. Today saw the release of the first technical preview under the name Qt Creator. The initial release is binary only, and under the terms of the Qt preview license, but the final release will be released with source code under a GPL compatible license. The initial release is available for Linux, Mac OS X and MS Windows."

Comments (3 posted)

Multimedia

Elisa Media Center 0.5.17 released

Version 0.5.17 of Elisa Media Center has been announced. "This release brings its usual lot of bug fixes and important performance improvements. A complete list of the new features and bugs fixed by this release is available at: https://bugs.launchpad.net/elisa/+milestone/0.5.17"

Full Story (comments: none)

Office Suites

Announcing OpenOffice.org 2.4.2

Version 2.4.2 of OpenOffice.org has been announced. "The OpenOffice.org Community is pleased to announce the release of OpenOffice.org 2.4.2, a minor update of OpenOffice.org 2.4.1 released in June 2008."

Full Story (comments: none)

OpenOffice.org Newsletter

The October, 2008 edition of the OpenOffice.org Newsletter is out with the latest OO.o office suite articles and events.

Full Story (comments: none)

Video Applications

Theora 1.0 released

The 1.0 release of the Theora video codec is finally available. "A number of leading multimedia web groups already support Theora. Upcoming releases of Mozilla Firefox, the world's most popular open source browser, will support Theora natively, as will releases of the multi-platform Opera browser. Top-10 website Wikipedia uses Theora for all of its video."

Full Story (comments: 5)

Languages and Tools

C

Get to know GCC 4 (IBM developerWorks)

M. Tim Jones explores GCC 4 in an IBM developerWorks article. "In the last few years, the GNU Compiler Collection (GCC) has undergone a major transition from GCC version 3 to version 4. With GCC 4 comes a new optimization framework (and new intermediate code representation), new target and language support, and a variety of new attributes and options. Get to know the major new features and their benefits."

Comments (none posted)

GCC 4.3.3 Status Report

The November 3, 2008 edition of the GCC 4.3.3 Status Report has been published. "The GCC 4.3 branch is open for regression and documentation fixes. The number of P1s grew a little bit, so the 4.3.3 release will need to be delayed by a few days until they are resolved or downgraded. Out of the 5 P1s, 2 were already fixed on the trunk and I'll just need to retest them in 4.3, one had a patch posted but no progress after patch review, one needs reghunt and analysis, one is currently assigned. Once all the P1s are resolved, 4.3.3 rc will be prepared."

Full Story (comments: none)

GCC 4.4.0 Status Report

The November 1, 2008 edition of the GCC 4.4.0 Status Report has been published. "The two months of Stage 3 have ended and the trunk is now in regression and documentation fixes only mode. At this point bugfixing should concentrate on getting the list of serious regressions down to a level that makes GCC 4.4 ready to release. As an exception to this we will still have the old register allocator removed before we branch for the GCC 4.4.0 release."

Full Story (comments: none)

Python

Jython 2.5 Beta 0 released

Version 2.5 Beta0 of Jython, an implementation of Python in Java, has been announced. "Jython 2.5 Beta0 is the beginning of a code cooling period where the number of new features should significantly slow as we concentrate on solidifying Jython 2.5 for an eventual release. There are still a number of features that we will squeeze in (like jythonc). This is a beta release so be careful."

Full Story (comments: none)

Tcl/Tk

Tcl-URL! - weekly Tcl news and links

The October 31, 2008 edition of the Tcl-URL! is online with new Tcl/Tk articles and resources.

Full Story (comments: none)

Build Tools

64 Studio Platform Development Kit 0.9.7 released

Version 0.9.7 of the 64 Studio Platform Development Kit has been announced, it includes a bug fix and a new inst-timeout option. "The 64 Studio Platform Development Kit (PDK) is a Free Software tool that we use to automate the production and maintenance of several different projects. PDK is a kind of version control system for distributions, allowing us to create and manage many different custom products based on Debian and Ubuntu sources."

Full Story (comments: none)

Editors

PHP mode for Emacs: 1.5.0 released (SourceForge)

Version 1.5.0 of PHP mode for Emacs has been announced. The software is: "An Emacs major mode for editing PHP code. Features: Syntax coloring and indenting; Documentation browse and search functions; Support for Imenu and SpeedBar; Customization options A new version of PHP mode for Emacs is released. Version 1.5.0 is the follow-up to the major improvements unveiled for PHP mode in January. There are no major new features in this release, but many bug fixes."

Comments (none posted)

Version Control

Gitbuilder 0.2.0 is released

Gitbuilder 0.2.0 has been announced. "I'd like to announce the new v0.2.0 release of gitbuilder, an auto-bisecting autobuilder tool for git-based projects. The new version incorporates several suggestions from end users..."

Full Story (comments: none)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

Gettys: Time to lead on the desktop

Jim Gettys, one of the original X Window System programmers (among many other things) has put up a lengthy call to the community to take the lead in the design of desktop software. "Our fundamental advantage we have is the ability to experiment and modify all areas of the stack; from hardware, to the window system, though toolkits to applications. Just as compositing has allowed a thousand flowers to bloom (most of which stink, but we've picked some that smell pretty sweet) in eye candy, accessibility and in other areas, compositing and other modern free software technologies can be used in new an unexpected ways. We are able to perform experiments, and have a large audience to test the experiments radically faster than commercial software."

Comments (28 posted)

Ibex design: user switching, presence and session termination (Here Be Dragons)

Mark Shuttleworth discusses recent work done on Ubuntu 8.10. "With Intrepid on track to hit the wires today I thought I’d blog a little on the process we followed in designing the new user switcher, presence manager and session management experience, and lessons learned along the way. Ted has been blogging about the work he did, and it’s been mentioned in a couple of different forums (briefly earning the memorable title “the new hotness”), but since it’s one of the first pieces of work to go through the user experience design process within Canonical I thought it would be interesting to write it up."

Comments (31 posted)

Linux Adoption

Linux: The Joe Sixpack Strategy (ZDNet)

Jason Perlow suggests some Linux adoption strategies in a ZDNet blog. "To get Joe Sixpack to switch to Linux, he’s going to need an easy way to move from his existing XP OS to his end-state, with all of his important data — his Office files, his emails, his contacts, MP3 files, digital photos and what have you, so a foolproof migration process is going to have to be designed. According to my fantasy scenario, Ubuntu and Google join forces and Google provides a freely downloadable program that installs on the client Windows PC, sets the user up with an online Google account, and sucks out all the office files, email and other critical data, backing it up to the cloud, which would be automatically restored to the target Linux install."

Comments (9 posted)

Legal

Diebold faces GPL infringement lawsuit over voting machines (ars technica)

Ars technica covers the GPL infringement suit against Diebold for its use of Ghostscript in its voting machines. "Evidence of Diebold's Ghostscript use first emerged last year when electronic voting machine critic Jim March was conducting analysis of Pima County voting irregularities. He brought a technical question to the Ghostscript mailing list relating to his investigation and mentioned in passing that Diebold's use of Ghostscript could potentially fall afoul of the GPL. This view was shared by Ghostscript developer Ralph Giles, who referred the matter to the Artifex business staff so that it could evaluate the legal implications."

Comments (5 posted)

EU patent board to decide whether to allow software patents (ars technica)

Ars technica reports on an upcoming decision affecting the patentability of software in the European Union. "Although EU patent law expressly excludes patenting software as such, it does allow patents to be granted for computer-implemented inventions. There are, however, many unanswered questions about the distinction between software methods and computer-implemented inventions. In practice, the EPO has historically granted patent applications in some cases for software methods that are viewed as legitimate technical innovations rather than business innovations. The EPO illustrates the difference by saying that a patent on a software method for improving signal strength between mobile phones is likely to be valid, but a patent on Internet auction systems is probably not."

Comments (3 posted)

Status of FSFE's legal dept: FTF (Fellowship of FSFE)

Ciarán O'Riordan takes a look inside the legal department of the Free Software Foundation Europe. "Inside FSFE, we talk a lot about our legal department, the FTF. I was in the Zurich office a while ago with the FTF's coordinator, Shane Coughlan, and took the opportunity to gather some info for anyone interested."

Comments (none posted)

Bilski: What It Means, Part 1 (Groklaw)

Groklaw analyzes the Bilski decision with an eye toward its effects on free software. "As you no doubt recall, Red Hat argued in its amicus brief that abstract ideas are not patentable. That argument won out. But Red Hat also argued that abstract ideas are not patentable *just because there is a computer involved*. The court didn't go that far. In a way, it found the opposite, that a machine has to be involved. But what it said was that as far as software is concerned, future cases will have to decide exactly where the line is."

Comments (none posted)

Court Greatly Limits Software And Business Method Patents (Techdirt)

Techdirt reports on a new US Federal Appeals Court ruling regarding software patents. "The summary is that the court has said that there's a two-pronged test to determine whether a software of business method process patent is valid: (1) it is tied to a particular machine or apparatus, or (2) it transforms a particular article into a different state or thing. In other words, pure software or business method patents that are neither tied to a specific machine nor change something into a different state are not patentable. That means a significant number of software and business method patents are about to disappear, freeing up many industries to be much more innovative -- at a time when that's desperately needed."

Comments (9 posted)

Interviews

How Linux Supports More Devices Than Any Other OS, Ever (O'Reilly)

O'Reilly has an interview with kernel hacker Greg Kroah-Hartman. In it, they cover topics like Linux device support, the kernel development process, and the ever (un)popular binary-only device drivers. "The ease of writing drivers; Linux drivers are at normally one-third smaller than Windows drivers or other operating system drivers. We have all the examples there, so it's trivial to write a new one if you have new hardware, usually because you can copy the code and go. We maintain them for forever, so the old ones don't disappear and we run on every single processor out there. I mean Linux is 80% of the world's top 500 super computers right now and we're also the number one embedded operating system today."

Comments (42 posted)

Resources

AlgoScore - Music By The Numbers (Linux Journal)

Dave Phillips discovers AlgoScore, a Csound-based program for sound and music composition. "AlgoScore is not a "graphical composition" environment, i.e., the sound is not created by the graphics per se. AlgoScore supplies graphic objects, but their ultimate content and shapes result from Csound and/or Nasal code (a Nasal interpreter is included with the package). Thus, unlike other programs that simplify Csound, AlgoScore requires some knowledge of computer programming. Fortunately Csound and Nasal are relatively simple languages to learn, and even a little familiarity will take you a long way into the possibilities of AlgoScore."

Comments (none posted)

Reduce your PC's power consumption through smart activity monitors (IBM developerWorks)

Nathan Harrington discusses power saving with smart activity monitors on IBM developerWorks. "Advanced Configuration and Power Interface (ACPI) and the power configuration systems built into modern computers provide a wide range of options for reducing overall power consumption. Linux and its associated user space programs have many of the tools necessary to master your PC power consumption in a variety of contexts. Much of the current documentation focuses on modifying your kernel parameters and hdparm settings to reduce unnecessary disk activity. In addition, extensive documentation is available for changing your processor settings to maximize the benefits of dynamic frequency scaling based on your current power source. This article provides tools and code to build on these power-saving measures by monitoring your application-usage patterns. Use the techniques presented here to change your power settings based on the application in focus, user activity, and general system performance."

Comments (none posted)

Miscellaneous

Intel, Taiwan teaming up on mobile Linux development lab (Ars Technica)

Ryan Paul covers Taiwan's participation in Moblin. "Intel's open source Linux-based mobile platform initiative got a big boost this month from Linux distributors and new contributors that are joining to participate in the effort. The project, which is called Moblin, aims to assemble a Linux stack that is optimized for mobile Internet devices, subnotebooks, and integrated car computing systems that are designed to use Intel's Atom processor. The latest organization to join the ranks of Moblin supporters is Taiwan's Ministry of Economic Affairs (MOEA), which will be working with Intel to establish a Moblin development facility. Intel is also investing in VMAX, a mobile carrier in Taiwan that plans to roll out a WiMAX network."

Comments (none posted)

Hostile takeover of Open Source Project TWiki

In a blog posting, Michale Daum covers a hostile takeover of the TWiki project. "Yesterday, 2008-10-27: 21:00 GMT, just a minute before the regular TWiki release meeting, the company TWIKI.NET announced unilaterally that the best for the TWiki.org project would be for them to take over governance. With it comes a complete lock down of the community site. From that minute on, all long-time contributors have lost access to their code. Counter-reaction: the community has left the building, leaving TWIKI.NET without a contributing community. Question: is it a sensible move for a venture capital firm that depends on a healthy Open Source community to lock it out?" (Thanks to Francesco Lovergine and Rahul Sundaram).

Comments (8 posted)

What's up with the GNOME Linux Desktop? (InternetNews.com)

InternetNews.com reports on the development and funding of GNOME 3, which should come out in 2009 or 2010. "It takes money and it takes new ideas to build a better desktop, both of which are being raised by the open source GNOME Foundation. GNOME is one of the most popular Linux desktop GUIs and is included in nearly every Linux distribution. The GNOME Foundation is now getting the official support of both Motorola and Google as sponsors and members of the GNOME Board of Advisors. The new advisors come as GNOME continues to expand the mobile Linux footprint as well as gear up for the next big thing – GNOME 3.0."

Comments (none posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

Free Documentation License 1.3

The Free Software Foundation has announced the release of version 1.3 of the GNU Free Documentation License. The big change would appear to be a clause allowing FDL-licensed text to be relicensed to the Creative Commons attribution-sharealike license. "This new permission has been added at the request of the Wikimedia Foundation, which oversees the Wikipedia project. The same terms are available to any public wiki that uses materials available under the new license. The Wikimedia Foundation will now initiate a process of community discussion and voting to determine whether or not to use CC-BY-SA 3.0 as the license for Wikipedia."

Comments (20 posted)

Motorola and Google join the GNOME Foundation Advisory Board

Motorola and Google have joined the GNOME Foundation Advisory Board. "We excited to announce today that Motorola and Google are joining the GNOME Foundation as sponsors and advisory board members. With these new additions to its advisory board, the GNOME Foundation continues to strengthen its industry support and shows that the support for free and open source software is growing - especially in the mobile space with technologies like GNOME Mobile."

Full Story (comments: none)

Knuth: no more checks for bug reports

Donald Knuth pioneered the idea of bounties for bug reports many years ago. He has now announced, in classic Knuthian style, that he can no longer write checks for these reports because he's tired of being ripped off. "It turns out that only 9 of the first 275 checks that I've sent out since the beginning of 2006 have actually been cashed. The others have apparently been cached. So this change in policy will probably not affect too many people. On the other hand, I don't like to renege on promises, so I shall do my best to find a suitable way to send money to anyone who really prefers legal tender."

Comments (80 posted)

Commercial announcements

OXID eSales goes Open Source

OXID eSales has announced the release of its eSales product OXID eShop PE4 under the GPLv3 license. "The new Community Edition, OXID eShop CE, will offer the identical software to the latest release of OXID's proprietary professional edition, OXID PE 4.0, providing a fully functional out-of-the-box software solution for companies looking to build an online shop. The Community Edition is available for free download immediately under the GNU Public License version three (GPLv3)."

Full Story (comments: none)

Zenoss to demonstrate open-source network monitoring solutions at LISA '08

Zenoss has announced plans to demonstrate their latest offerings at the LISA Conference in San Diego, CA on November 12-13, 2008. "Zenoss will be releasing their latest enterprise management and monitoring solutions featuring new capabilities for monitoring J2EE applications, Windows server, and native VMware instances. This latest version was developed in conjunction with the Zenoss open source community who provided product input, beta testing, and over 30 Zenoss extensions. In addition to showcasing its solutions during the show, Zenoss will also conduct its third annual Open Source Systems Management Survey."

Comments (none posted)

New Books

Enterprise Rails - New from O'Reilly

O'Reilly has published the book Enterprise Rails by Dan Chak.

Full Story (comments: none)

Web Security Testing Cookbook--New from O'Reilly

O'Reilly has published the book Web Security Testing Cookbook by Paco Hope and Ben Walther.

Full Story (comments: none)

Resources

Linux Gazette #156 is out!

Issue #156 of Linux Gazette has been published. Topics this time include: A (not so) short overview of the Geographic Information System GRASS, Writing Network Device Drivers for Linux, Installing and configuring root-access sandboxes in a running Linux system, The Red Hat Linux Boot Process, and lots more. Click below for the full announcement.

Full Story (comments: none)

White Paper: rPath Puts Adoption Model in the Cloud

rPath has published a white paper entitled The Pragmatist's Guide to Cloud Computing (registration required). ""Virtualization and cloud computing have a transformative impact on the cost and efficiency of software delivery and consumption, which makes investments in these areas of even greater importance during a down economy," said Jake Sorofman, VP of marketing for rPath. "But despite its importance, the path to cloud remains elusive for many organizations. rPath developed the Cloud Computing Adoption Model to propose what we believe is a useful incremental approach to cloud adoption, while also stimulating a public conversation about patterns and practices that can help us all become smarter about virtualization and cloud initiatives.""

Full Story (comments: none)

Contests and Awards

2008 OpenVAS contest winners announced

Three winners have been selected for the OpenVAS Contest. "The 2008 OpenVAS Contest took place from August 23rd to October 15th, 2008. With 5 nominees who contributed a large number of improvements to the OpenVAS framework and extended the Open Source Network Vulnerability Testing, it was a great success. During the contest duration the number of OpenVAS Network Vulnerability Tests (NVTs) increased dramatically: from 3750 NVTs up to 5736 NVTs (an overall increase of over 50%). The most significant number of NVTs, which deliver full support for Gentoo and FreeBSD local security checks, were contributed by Thomas Reinke who deserves special thanks for his continuing support of OpenVAS."

Full Story (comments: none)

The first official Python coin has been released in the Netherlands

Stani, author of Stani's Python Editor, has won a competition for a commemorative coin design. "I am pleased to announce that I won the competition for the next 5 euro commemorative coin with the theme 'Netherlands and Architecture'. The design of the coin was totally developed with python. I used PIL for raster image manipulation and pyCairo for generating vector graphics." See: How to make money with free software... for photos and more information on the effort.

Full Story (comments: 2)

Education and Certification

Free Web Seminars from MontaVista and Freescale (MarketWatch)

MarketWatch notes that MontaVista and Freescale will hold free web seminars on November 18. "MontaVista(R) Software, Inc., the leader in embedded Linux(R) commercialization, announces registration for two free web seminars on improving embedded Linux Startup time, presented with Freescale(TM) Semiconductor, OpenSystems Media and Christopher Hallinan, author of Embedded Linux Primer, the number one-selling book on embedded Linux. The web seminars will provide strategies for improving embedded Linux startup time and present techniques that help design engineers to reduce boot time while preserving the base functionality required of most embedded Linux systems."

Comments (none posted)

Meeting Minutes

Perl 6 Design Minutes (use Perl)

The minutes from the October 29, 2008 Perl 6 Design Meeting have been published. "The Perl 6 design team met by phone on 29 October 2008. Larry, Allison, Patrick, Jerry, Will, Jesse, Nicholas, and chromatic attended."

Comments (none posted)

Calls for Presentations

DC BSDCon 2009 Call for Papers

A call for papers has gone out for DC BSDCon 2009. The event takes place in Washington, D.C. on February 4-5, 2009, papers are due by December 1.

Full Story (comments: none)

Call for papers for GCC Research Opportunities Workshop GROW'09

A Call for papers has gone out for the GCC Research Opportunities Workshop, GROW'09. The event takes place on January 25-28, 2009 in Paphos, Cyprus, the deadline has been extended to November 21.

Full Story (comments: none)

Camp KDE 2009: Call For Presentations Deadline (KDE.News)

KDE.News has announced The Call For Presentations deadline for Camp KDE 2009. "The Call For Presentations deadline for Camp KDE 2009 will be Friday, November 21. Due to the compressed planning of this event, deliberation will be held over the weekend and selected presentations will be announced on Monday, November 24 so that travel decisions can be made." Camp KDE takes place on January 17-23, 2009 in Negril, Jamaica.

Comments (none posted)

Upcoming Events

O'Reilly Money:Tech conference opens registration

Registration is open for the 2009 O'Reilly Money:Tech conference. "Registration has opened for Money:Tech 2009, February 4-6, 2009, in New York City, and program chairs Paul Kedrosky and Rob Passarella have announced the program. Money:Tech 2009 is the preeminent conference for investment professionals examining the impact technology has on trading, finance, and investing. Money:Tech 2009 will showcase tools, techniques, and technologies; provide a forum for leading-edge viewpoints; and deliver a first look at industry trends that will have merged into the mainstream by next year."

Full Story (comments: none)

O'Reilly Tools of Change for Publishing Conference opens registration

Registration is open for the 2009 O'Reilly Tools of Change for Publishing Conference. "Registration has opened for the O'Reilly Tools of Change for Publishing Conference, taking place February 9-11, 2009, at the Marriot Marquis Times Square in New York City. Program Chair Andrew Savikas and co-Chair Mac Slocum have announced the program, which investigates the emerging trends in digital publishing through keynotes, sessions, tutorials, panels, and other events designed to surpass the high expectations inspired by the sold-out TOC 2008."

Full Story (comments: none)

POC2008 conference, South Korea

POC2008 has been announced. "The 3rd international hacking and security conference "POC2008" by hackers will be held in Seoul, Korea on November 13 ~ 14."

Full Story (comments: none)

Events: November 13, 2008 to January 12, 2009

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
November 10 November 14	Python Bootcamp with Dave Beazley	Atlanta, GA, USA
November 11 November 14	DeepSec IDSC 2008	Vienna, Austria
November 12 November 14	php|works 2008	Atlanta, GA, USA
November 12 November 13	PacSec Applied Security Conference	Tokyo, Japan
November 13 November 14	International Hacking and Security Conference	Seoul, Korea
November 14 November 16	OpenSQL Camp 2008	Charlottesville, VA, USA
November 16 November 20	Middle East IT Security Conference	Dubai, UAE
November 19 November 20	Linux Foundation Japan Symposium	Tokyo, Japan
November 20 November 21	FreedomHEC Taipei 2008	Taipei, Taiwan
November 22	The phpnw08 conference	Manchester, UK
November 22	PGDay Rio de la Plata	Buenos Aires, Argentina
November 22	Mandriva 2009 Installfest	Everywhere, World
November 25 November 29	FOSS.IN 2008	Bangalore, India
November 25 November 30	make art 2008	Poitiers, France
November 28	Informazione geografica aperta e libera	Pontedera (PI), Italy
November 28 November 29	WhyFLOSS La Plata - Argentina	La Plata, Argentina
November 29	LinuxDay in Vorarlberg (Deutschland, Schweiz, Liechtenstein und Österreich)	Dornbirn, Austria
December 1	First Nuxeo Developer Day	Paris, France
December 1 December 2	Open World Forum	Paris, France
December 2 December 5	Open Source Developers' Conference 2008	Sydney, NSW, Australia
December 4 December 7	PIKSEL08 - code dreams	Bergen, Norway
December 5 December 6	FOSSCamp	Mountain View, CA, USA
December 5 December 13	International Joint Conferences on Computer, Information, and Systems Sciences, and Engineering	Online,
December 7 December 12	Computer Measurement Group Conference 2008	Las Vegas, NV, USA
December 8 December 12	Ubuntu Developer Summit	Mountain View, CA, USA
December 8	Forum PHP Paris 2008	Paris, France
December 10 December 11	First Workshop on I/O Virtualization	San Diego, CA, USA
December 13	NLLGG meeting/BSD Community Day	Utrecht, The Netherlands
December 27 December 30	Chaos Communication Congress	Berlin, Germany
January 8 January 11	Consumer Electronics Show	Las Vegas, NV, USA
January 9 January 11	Fedora User and Developer Conference	Boston, USA

If your event does not appear here, please tell us about it.

Page editor: Forrest Cook