LWN.net Weekly Edition for July 2, 2009

Stallman warns about C# and Mono dependence

Since its inception, Mono has always been controversial, largely because Microsoft—creator of the .NET framework that Mono implements—is not trusted by a large segment of the free software community. The concern is that, at some point, Microsoft will start asserting patent claims against Mono or applications that use it. Richard Stallman recently stirred the pot with a brief warning that reliance on Mono, or applications that are written in C#, is a "serious danger". That, in turn, has led to a number of discussions about how real that danger actually is, and what, if anything, distributions should do about it.

Certainly, the patent non-assertion agreement that Microsoft and Novell signed in 2006 gives the appearance that Mono users—those who are not Novell customers anyway—could be subject to patent harassment—or worse—from Microsoft. So far, nothing like that has materialized, but it is difficult for anyone with even the tiniest bit of cynicism (along with a historical perspective) to be completely unconcerned about the problem As is typical, Stallman is particularly blunt, or alarmist, depending on one's perspective:

It would seem that Debian's recent addition of the Mono-based Tomboy note-taking application to one of its GNOME meta-packages—though only for the Squeeze (testing) release so far—is what prompted Stallman's warning. Some are advocating shipping the Gnote re-implementation of Tomboy in C++, instead of Tomboy, which might be a solution for note-taking. As Debian developer Josselin Mouette points out, though, there are no replacements for other Mono-based applications, such as F-Spot and GNOME Do, so Mono may well be required by other default applications down the road.

Some distributions, such as Fedora for the upcoming Fedora 12, have removed Tomboy in favor of Gnote for default installations. This effectively removes Mono from the default, though the reasons are not necessarily related to any potential patent issues—Gnote has a much smaller footprint. But, there is the recent patent suit against TomTom—and efforts to work around the patent—to remind folks that the patent threat is real, and that Microsoft, which had largely stayed away from pressing patent claims, can and will pursue free software implementations of its patented technologies.

Any patent action against Mono may subject the plaintiff to a countersuit from the Open Invention Network (OIN), which is a patent pool to defend free software. By adding Mono to its list of protected applications, OIN allowed various distributions, Fedora for example, to become comfortable enough to start shipping Mono at all. There are still risks, of course, not least from patent trolls who don't implement anything that could be subject to a countersuit, but the OIN coverage provides enough of a threat to potential patent attackers that Mono is available for nearly all distributions.

Unlike many earlier complaints about Mono and C#, Stallman is not arguing against the existence of Mono, his view is more nuanced than that:

The mention of DotGNU Portable.NET is confusing to some: how can Stallman be warning against C# in the same message where he touts a GNU implementation of the language? But Stallman evidently doesn't see it that way; providing the tool is not the same as encouraging its use. His solution is to discourage new development in C#, find alternative applications written without Mono, and to not include Mono in the default installations of Linux distributions. As more C# applications come along, particularly those without a "Mono-free" alternative, that could pose some serious difficulties.

The most in-depth defense of Mono, in general, as well as arguments for its inclusion in Debian, Ubuntu, and other distributions comes from Jo Shields. In a lengthy blog post, which was a response to a challenge on Linux Today, he also notes that it is the applications that are driving the adoption of Mono, not the technology in and of itself. He has a well-thought-out list of reasons that users should not be worried about the patent threat. He is clearly exasperated—or worse—with the shrill "anti-Mono" contingent:

This issue has been simmering for a long time, but it has really flared up over the last two or three weeks, prompting the Ubuntu Technical Board to issue a position statement saying that it "sees no reason to exclude Mono or applications based upon it from the archive, or from the default installation set". While some distributions may remove Mono from their default installs and Live CDs—for space reasons if nothing else—there are few, if any, mainstream distributions that will completely remove Mono from their repositories, as there are clearly useful applications that depend on it. An interesting exception to that, however, is Red Hat Enterprise Linux (RHEL), which doesn't package Mono at all.

C# is an international standard, as both Ecma International and ISO have adopted C# specifications. Those bodies require patents that are held by their members, and that cover an adopted standard, be licensed under "reasonable and non-discriminatory" (RAND) terms. Depending on what those terms actually are, they may not be "non-discriminatory" towards free software implementations, particularly if they require royalties. But, it may well be that patent enforcement actions by Microsoft against Mono (or DotGNU for that matter) are unlikely. Microsoft might also be leery of the various regulatory bodies that tend to keep an eye on its anti-competitive behavior. All of those things may make the probability of a patent suit vanishingly small, but it doesn't reduce it zero—and that is what Stallman and others are worried about.

Of course, Microsoft could make its intentions clear, and remove the doubt. That it chooses not to, and lets the free software community twist in the wind, speaks volumes about its tactics—whether it truly thinks it might ever use the patent weapon or not. Rather than any active enforcement, a more likely scenario is that Microsoft hopes it can shake down more companies in deals like it made with Novell. From that standpoint, the internal free software community bickering about Mono serves its purposes as well as any "fear, uncertainty, and doubt" campaign it might be able to conjure up.

There are perfectly legitimate reasons to be concerned about Mono: it is resource-hungry, is always playing catch-up with whatever new features Microsoft chooses to add, and could increase the danger from patent suits. At the moment, though, those kinds of arguments are being drowned out by a loud group that doesn't want to see Mono exist at all.

This rabid anti-Microsoft segment of the free software community has not done the rest of the community any favors with its behavior regarding this issue. There are certainly reasons to be wary of Microsoft, but there is no reason to believe that the Mono developers and proponents are interested in anything other than the technology itself. The C# language and .NET libraries have benefits that they see, and wish to use. Disagreeing with that, on a technical—or political—level is all well and good, but calling for people to be fired or somehow expelled from the community for their opinions, as Shields describes, is absurd. Freedom cuts both ways.

The root problem is, of course, software patents, and the uncertainty they bring. This is clearly a growing problem within our community, and one that is not going to go away soon. While a patent attack from Microsoft over Mono may be unlikely, there are certainly other patent trolls out there trying to figure out how to leverage their "valuable intellectual property" against Linux and free software. Where the next attack comes from is unclear, but we can be sure that it's coming.

Comments (70 posted)

RealtimeKit and the audio problem

Skip-free audio and video playback is a fundamental expectation for many - if not most - Linux users. Given the importance of this feature and the increase in hardware performance over the years, one would think that the audio latency problem would have been solved some time ago. The recent posting of (and mixed reception for) the "RealtimeKit" mechanism shows that this issue remains open, though, and that we are still short of a consensus on how it should be solved.

Audio skipping can have a number of causes. If the stream is traveling over the net, those causes may be entirely external to the system involved. The rest of the time, resource contention is usually the problem. And, often, the limiting resource is the CPU. The response time requirements for audio are not especially tight, but, if the processor gets busy with something else for too long, it's still possible that the system will fail to get audio data to the hardware before the stream runs dry. If the sound card runs out of sound to play, it will go silent, thus introducing a skip into the audio stream. Even if the skip improves the material being played (one of the current flood of Michael Jackson retrospectives, say), users still tend to get unhappy.

Efforts to improve audio latency have taken several forms. One is the ongoing effort to identify and fix latency problems throughout the kernel. New scheduling algorithms (the completely fair scheduler, for example) have also helped. But, even after all that work has been done, there seems to be little alternative to running core audio processing code with realtime scheduling priority. And that is where the trouble starts.

More than four years ago, the audio community came forward with its proposed solution to the problem: the realtime security module. This module used the Linux security module (LSM) API to allow the system administrator to grant realtime scheduling privileges to specific users and groups. This solution slightly reduced the security of the system (opening it up to denial of service attacks by the privileged users), but it also solved the latency issues in ways which made audio developers happy.

Kernel developers didn't like this approach, though. The seeming misuse of the LSM API - which is supposed to only limit privileges, never enhance them - was part of the problem. But the realtime module just looked like an ad hoc solution that would not stand the test of time. It was never merged; the kernel developers, instead, opted for an approach based on resource limits. As of 2.6.12, any process is allowed to set a realtime priority up to the value of its RLIMIT_RTPRIO limit. By default, this limit does not allow any realtime scheduling at all, but the system administrator can change the default for specific users or groups by editing the limits.conf file read by the PAM subsystem.

This feature would seem to solve the problem, and, indeed, the media-focused distributions make good use of it. The major distributions tend not to use RLIMIT_RTPRIO, though, because it makes it so easy for a process (malicious or just buggy) to completely freeze the machine. Once a process with realtime priority goes into a tight loop, there is little that the user or administrator can do to stop it short of hitting the reset button. That sort of behavior creates unhappy users and inflammatory bug tracker entries - both things that distributors hate. So those distributors have mostly avoided enabling this feature.

More recent kernels have seen the addition of features which could mitigate this problem somewhat. A new limit (RLIMIT_RTTIME) sets an upper bound on the amount of time a realtime process can monopolize the CPU; after that time, it must make a blocking system call or, eventually, be killed by the kernel. This limit solves the rogue process problem, but it does little against deliberate denial-of-service attacks, which can get around the limit by continually forking new processes. As a result, RLIMIT_RTTIME doesn't make nervous distributors feel much better.

The other feature of note is realtime group scheduling, which allows a group of processes to be given a "realtime bandwidth" value limiting the amount of available CPU time the group can use at realtime priority. That, in turn, limits ability of the group as a whole to completely take over the system. The group scheduling feature looks like it should be a complete solution to the problem; it allows groups of processes to be given access to the realtime scheduler while limiting their ability to affect the overall operation of the system.

When Lennart Poettering set out to solve the audio skipping problem, though, he didn't use any of the above solutions. The security issues associated with resource limits were more than he was willing to deal with, and he describes the group scheduling feature this way:

It is true that a process cannot simultaneously be in a container-related control group and an audio-related control group if both groups want to control scheduling-related parameters.

Lennart's proposal is a new daemon called "RealtimeKit"; it has already found its way into the Fedora Rawhide distribution. The RealtimeKit daemon has a relatively simple job: it grants realtime scheduling priority to processes in response to requests sent via D-Bus. There are, of course, some catches:

• Any process requesting realtime priority must have the RLIMIT_RTTIME limit set to ensure that it cannot completely take over the system.

• There are administrator-set limits on the number of processes which can be running with realtime priority at any given time.

• The requesting process must have the SCHED_RESET_ON_FORK policy flag set in the kernel.

The SCHED_RESET_ON_FORK flag is implemented by a kernel patch written by Lennart and accepted into Ingo Molnar's "tip" tree; this patch has not, as of this writing, been merged for 2.6.31. This flag, when set, prevents any child processes from inheriting any enhanced scheduling priorities from the parent. It thus is effective against fork bombs and other multi-process attacks; it allows RealtimeKit to give realtime priority to a single process in the knowledge that this priority will not be passed on to any others.

As a solution, RealtimeKit looks like it should work, but its reception in the audio development community was chilly at best. As Paul Davis put it:

There are a number of reasons for the objections to RealtimeKit. It adds a dependency on D-Bus regardless of whether audio developers want it. It's far from a POSIX interface. RealtimeKit takes certain decisions (such as whether to use the round-robin or FIFO scheduling classes) out of the developers' hands. It's not sufficient for the needs of pro audio users. And so on. But the real complaints would appear to be these:

• The audio community feels a little burned. They were told four years ago that they needed to drop their preferred solution (the realtime security module) in favor of the rlimit-based solution, which is now, in turn, being pushed aside for RealtimeKit. How long will it be, they wonder, until yet another solution is put forward as the real answer?

• Nobody asked the audio developers how they would like a solution to look; instead, RealtimeKit was simply presented to them as the new way to go.

Lennart's response suggests that he's not likely to go asking the Linux audio development ("lad") community for input in the future:

More seriously, he points out that RealtimeKit does not break the existing rlimit-based system. Instead, it just adds an option for distributors who want to make realtime scheduling available to specific processes in a safe way. So nothing which works now will stop working under RealtimeKit. That is little comfort, though, to developers and users who feel that they will be forced to run RealtimeKit to use their audio applications in the future.

The Linux audio community contains no end of highly talented and highly motivated developers. But audio support under Linux still falls short of what it should really be. Audio development has suffered from a lack of consensus on solutions, a lack of communications between different development communities, and a lack of a maintainer with a view of the full problem. So it is not surprising that our audio applications don't always play well together and don't always work as well as we would like.

Lennart has dedicated a good part of his life toward improving this situation. A certain amount of controversy and pain has accompanied this work; one need not look very far to find no end of PulseAudio horror stories. But PulseAudio seems to be getting better, and Linux may well be getting closer to having basic (non-professional) audio "just work" out of the box. The goals of this work are hard to criticize, and criticism of the results might just be on the wane.

Perhaps RealtimeKit is the missing link which will enable distributors to improve audio responsiveness; Fedora looks to be the laboratory in which this particular experiment will be conducted. If RealtimeKit works as advertised, the audio community will eventually move to make use of it - regardless of whether they were asked ahead of time or not. For better or for worse, that's often how our community works: problems are solved not by talk, but by a determined developer who creates code that works.

(See this README file for more information on RealtimeKit).

Comments (67 posted)

VFAT patent avoidance and patent workarounds

Back in May, the proposed "no long file names" patch got a hostile reception on the linux-kernel mailing list. This patch, presumably aimed at working around Microsoft's VFAT patents, made the kernel unable to create long file names on VFAT filesystems. It was seen by many as a reduction in functionality without any sort of well-explained justification, and it was not merged. Now there is a new patch which takes a different approach on both the technical and political fronts. Its fate remains to be seen, but it demonstrates a method for dealing with patents which is worthy of wider consideration.

The VFAT format is undeniably a hack. It allows the FAT filesystem to be extended beyond its traditional 8.3 upper-case file name limit by creating additional file entries - which look invalid to older filesystem implementations - containing a longer name. Depending on the length of the name, several of these additional entries may need to be placed in the directory ahead of an entry holding a traditional short file name. The first patch simply disabled the ability to create these long name entries; since the relevant patents all make claims about the creation of long file names, a system which does not create them cannot infringe. A Linux kernel with this patch in place (and enabled at configuration time) would be able to read filesystems with long names, but it would be unable to add any more long names to it.

The new patch takes an entirely different approach based on a close reading of the patent. In truth, it's not the creation of long file names which is covered; instead, the patent claims the technique of creating both long and short names. So the current patch takes away that ability; it can create a long name or a short one, but never both for the same file. The result is almost complete interoperability with other systems using long names; the one exception is archaic systems which only have short name capability. Such systems are relatively rare, though.

There is an interesting trick required to make all this work. The FAT format requires that the short-name directory entry be present, so Linux cannot simply leave it out. Instead, that entry is created with a name which is clearly invalid. The "short name" starts with a space and a NUL byte, continues with some random characters, and finishes with an extension containing a slash. The end result cannot be listed as part of the directory, cannot be used to open the file, and may not even be unique within the directory. It is, thus, not a name for the file.

Assuming that reasoning holds up in court, this patch creates a kernel which cannot be said to infringe upon the VFAT patents. Given that the patch has clearly seen some legal review (see the associated FAQ), and given that it comes from a source (IBM) with extensive experience and expertise in patent law, its chances are probably best described as "better than average."

There are still those who will question this whole approach, though. Changing the kernel in a way which reduces interoperability looks like an acknowledgment of the validity of the patents; wouldn't it be better, some ask, to put those resources into fighting the patents instead? For those who do not wish to play this game at all, putting hackish-looking workarounds into the kernel seems like the wrong way to go.

The problem is that invalidating a patent is a long, expensive, and uncertain undertaking. "Long" means years, "expensive" means potentially millions of dollars, and "uncertain" means exactly that. The US patent system (which is of the most relevance in situations like this) is unwilling to invalidate patents in general; even when it does, the patent is merely put back into the review process from which it can arise, zombie-like, to terrorize again. In the mean time, companies subject to attacks under that patent are suffering under extreme legal costs and potential injunctions which keep them from selling their products. For most companies, that's a death sentence. It is unsurprising that most companies lacking a massive patent portfolio of their own quickly settle when subjected to patent attacks.

[PULL QUOTE: If we choose not to make use of patent workarounds, we will clearly increase our chances of losing the larger fight. END QUOTE] Workarounds are a worthwhile alternative to settling and long battles of attrition. A proper workaround effectively invalidates a patent without all of the associated costs. This is especially true if the workaround so clearly avoids the target patent that any attacks can be disposed of quickly via summary judgment. In any long fight, one must choose battles carefully; workarounds can allow us to avoid numerous costly battles and focus our energies on truly disruptive patents. If we choose not to make use of patent workarounds, we will clearly increase our chances of losing the larger fight.

The FAQ makes an important point related to workarounds that the community should hear: publicly questioning the effectiveness of a workaround can have fatal results. The goal of a good workaround is to avoid a patent infringement trial altogether. If a patent holder can point to email from prominent community members suggesting that a given workaround might, in fact, not avoid the patent, said holder may create enough doubt in a judge's mind to defeat a summary judgment motion and force a case to go to trial. Most defendants cannot afford that, and will thus be forced to capitulate. The right way to express concerns of this nature is via private communication.

We have been hearing warnings about software patents for many years, but, for most of those years, the threat seemed distant. During that time, it is said, numerous companies have been quietly shaken down for patent money. The TomTom suit brought that process out into the open, making it clear that powerful companies are willing and able to press patent infringement claims against companies using Linux. The sad fact is that we cannot opt out of playing this game, so we're simply going to have to get good at it. This patch is part of the process of figuring out how this game - so much of which is played via secret maneuvers - can be handled in an open community. It also represents a serious attempt by a large player in the patent game to help the community avoid a couple of threatening patents. Perhaps it's not the patch we want to merge in the end, but it (and its goals) deserve serious consideration.

Comments (47 posted)

Page editor: Jonathan Corbet

Security

Mozilla's Content Security Policy

Cross-site scripting (XSS) is a common web application flaw that can lead to a wide variety of attacks. The problem, and ways to eliminate it, have been known for years, but new instances of XSS crop up regularly in web applications—live sites as well as packages like content management systems. Mozilla has taken the lead on a new security policy, Content Security Policy (CSP), which provides a way for sites to avoid XSS. It does that by fundamentally changing the way JavaScript content is treated by the browser, but does so in a way that allows sites to opt-in to the new policy.

XSS works by injecting JavaScript content into the data returned by a web server. Normally that happens because some kind of user input was not properly filtered before it was echoed back on a web page. If that user input—in the form of a comment on an article, for example—contains unfiltered JavaScript, the users browser will happily execute it as if it originated with the site. At that point, an attacker-controlled code is running with the privileges of the browser user and the origin site.

As described by Mozilla's security program manager Brandon Sterne, on the Mozilla Security Blog, CSP changes that model. Instead of treating all content received in a response as having the same privilege level, CSP allows the site owner to explicitly list what kinds of JavaScript to trust. In order to do that, however, CSP strictly limits where JavaScript can originate, and where it can appear in HTML.

Basically, CSP allows a site operator to list hosts from which JavaScript content will be accepted. If that option is used (via an HTTP X-Content-Security-Policy header or HTML <META> tag), all JavaScript must be loaded from external files from hosts on the list—all other mechanisms for executing JavaScript are disabled for that page. Sterne describes it this way:

This will be an enormous change for sites that want to use CSP, but it is backward-compatible with older browsers (or those that do not support CSP), and there are ways to incrementally approach the implementation. Sterne notes that all sites should be able to make the switch, and Mozilla intends to provide a migration guide to help sites convert to CSP. But, it remains to be seen whether sites will actually use it. Mozilla security lead, Daniel Veditz, commented about that in the bug entry that tracks CSP implementation:

Another interesting feature of CSP is its ability to notify a site when there is an attempt to violate the policy. This will even benefit users of browsers that don't support CSP, as XSS holes can be recognized and fixed more quickly. Sterne is optimistic about the effect of CSP:

The open question is whether site operators are concerned enough about XSS to change the way they handle JavaScript. Over time, automated tools may help with that process, which could lower the bar somewhat, but it is still a daunting task. One would guess that the other browsers will take a "wait and see" attitude before deciding whether to implement it. Though the implementation is progressing, there is no word from Mozilla on when it might release a browser with CSP either.

Perhaps CSP is too heavy-handed of a solution to the XSS problem, but it is good to see Mozilla taking a lead in trying to find something that will alleviate the problem. There are other, similar efforts in the works at Mozilla including the Origin header to mitigate cross-site request forgery and clickjacking.

While these web application vulnerabilities are largely understood and techniques to avoid them are known, they keep cropping up. Finding ways to make users' browsers more resistant to these kinds of attacks can only help improve web security.

Comments (18 posted)

New vulnerabilities

git: denial of service

Package(s):	git	CVE #(s):	CVE-2009-2108
Created:	June 25, 2009	Updated:	February 1, 2010
Description:	git has a denial of service vulnerability From the National Vulnerability Database entry: git-daemon in git 1.4.4.5 through 1.6.3 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a request containing extra unrecognized arguments.
Alerts:	Debian DSA-1841-2 2010-01-31 Mandriva MDVSA-2009:176 2009-07-29 Debian DSA-1841-1 2009-07-25 Mandriva MDVSA-2009:155 2009-07-19 Gentoo 200907-05 2009-07-12 Fedora FEDORA-2009-6936 2009-06-23 Fedora FEDORA-2009-6839 2009-06-23 Fedora FEDORA-2009-6809 2009-06-23

Comments (none posted)

html2text.php: arbitrary code execution

Package(s):	html2text.php	CVE #(s):	CVE-2008-5619
Created:	June 25, 2009	Updated:	July 1, 2009
Description:	html2text.php has a arbitrary code execution vulnerability. From the National Vulnerability Database entry: html2text.php in Chuggnutt HTML to Text Converter, as used in RoundCube Webmail (roundcubemail) 0.2-1.alpha and 0.2-3.beta, Mahara, and AtMail Open 1.03, allows remote attackers to execute arbitrary code via crafted input that is processed by the preg_replace function with the eval switch.
Alerts:	Ubuntu USN-791-1 2009-06-24

Comments (none posted)

kdegraphics: multiple vulnerabilities

Package(s):	kdegraphics	CVE #(s):	CVE-2009-0945 CVE-2009-1709
Created:	June 25, 2009	Updated:	January 25, 2011
Description:	kdegraphics has multiple vulnerabilities. From the Red Hat alert: A use-after-free flaw was found in the KDE KSVG animation element implementation. A remote attacker could create a specially-crafted SVG image, which once opened by an unsuspecting user, could cause a denial of service (Konqueror crash) or, potentially, execute arbitrary code with the privileges of the user running Konqueror. (CVE-2009-1709) A NULL pointer dereference flaw was found in the KDE, KSVG SVGList interface implementation. A remote attacker could create a specially-crafted SVG image, which once opened by an unsuspecting user, would cause memory corruption, leading to a denial of service (Konqueror crash). (CVE-2009-0945)
Alerts:	SUSE SUSE-SR:2011:002 2011-01-25 openSUSE openSUSE-SU-2011:0024-1 2011-01-12 openSUSE openSUSE-SU-2010:1035-1 2010-12-09 Mandriva MDVSA-2010:182 2010-09-14 Debian DSA-1988-1 2010-02-02 Mandriva MDVSA-2010:027 2010-01-27 Debian DSA-1950 2009-12-12 Mandriva MDVSA-2009:331 2009-12-10 Ubuntu USN-836-1 2009-09-23 Ubuntu USN-823-1 2009-08-24 Ubuntu USN-822-1 2009-08-24 Debian DSA-1866-1 2009-08-19 Ubuntu USN-857-1 2009-11-10 Fedora FEDORA-2009-8049 2009-07-27 Fedora FEDORA-2009-8039 2009-07-27 Fedora FEDORA-2009-6166 2009-06-15 CentOS CESA-2009:1130 2009-06-26 Red Hat RHSA-2009:1130-01 2009-06-25

Comments (none posted)

kdelibs: multiple vulnerabilities

Package(s):	kdelibs	CVE #(s):	CVE-2009-1687 CVE-2009-1690 CVE-2009-1698
Created:	June 25, 2009	Updated:	January 25, 2011
Description:	kdelibs has multiple vulnerabilities. From the Red Hat alert: A flaw was found in the way the KDE CSS parser handled content for the CSS "style" attribute. A remote attacker could create a specially-crafted CSS equipped HTML page, which once visited by an unsuspecting user, could cause a denial of service (Konqueror crash) or, potentially, execute arbitrary code with the privileges of the user running Konqueror. (CVE-2009-1698) A flaw was found in the way the KDE HTML parser handled content for the HTML "head" element. A remote attacker could create a specially-crafted HTML page, which once visited by an unsuspecting user, could cause a denial of service (Konqueror crash) or, potentially, execute arbitrary code with the privileges of the user running Konqueror. (CVE-2009-1690) An integer overflow flaw, leading to a heap-based buffer overflow, was found in the way the KDE JavaScript garbage collector handled memory allocation requests. A remote attacker could create a specially-crafted HTML page, which once visited by an unsuspecting user, could cause a denial of service (Konqueror crash) or, potentially, execute arbitrary code with the privileges of the user running Konqueror. (CVE-2009-1687)
Alerts:	openSUSE openSUSE-SU-2011:0024-1 2011-01-12 SUSE SUSE-SR:2011:002 2011-01-25 openSUSE openSUSE-SU-2010:1034-1 2010-12-09 Debian DSA-1988-1 2010-02-02 Mandriva MDVSA-2010:027 2010-01-27 Mandriva MDVSA-2009:346 2009-12-29 Debian DSA-1950 2009-12-12 Mandriva MDVSA-2009:330 2009-12-10 Ubuntu USN-836-1 2009-09-23 Fedora FEDORA-2009-9391 2009-09-09 Fedora FEDORA-2009-9400 2009-09-09 Ubuntu USN-822-1 2009-08-24 Debian DSA-1868-1 2009-08-19 Debian DSA-1867-1 2009-08-19 Fedora FEDORA-2009-8020 2009-07-27 Fedora FEDORA-2009-8046 2009-07-27 Fedora FEDORA-2009-8049 2009-07-27 Fedora FEDORA-2009-8039 2009-07-27 CentOS CESA-2009:1127 2009-06-26 CentOS CESA-2009:1128 2009-06-25 Red Hat RHSA-2009:1128-01 2009-06-25 Red Hat RHSA-2009:1127-01 2009-06-25 Ubuntu USN-857-1 2009-11-10

Comments (none posted)

kernel: buffer overflow

Package(s):	kernel	CVE #(s):	CVE-2009-1389
Created:	June 25, 2009	Updated:	September 23, 2010
Description:	The kernel has a buffer overflow vulnerability. From the National Vulnerability Database entry: Buffer overflow in the RTL8169 NIC driver (drivers/net/r8169.c) in the Linux kernel before 2.6.30 allows remote attackers to cause a denial of service (kernel memory corruption and crash) via a long packet.
Alerts:	openSUSE openSUSE-SU-2010:0664-1 2010-09-23 SUSE SUSE-SA:2010:036 2010-09-01 openSUSE openSUSE-SU-2010:0397-1 2010-07-19 SUSE SUSE-SA:2010:031 2010-07-20 Red Hat RHSA-2009:1469-01 2009-09-30 Red Hat RHSA-2009:1457-01 2009-09-22 SuSE SUSE-SA:2009:045 2009-08-20 Debian DSA-1865-1 2009-08-16 Red Hat RHSA-2009:1211-01 2009-08-13 CentOS CESA-2009:1193 2009-08-05 Red Hat RHSA-2009:1193-01 2009-08-04 Debian DSA-1844-1 2009-07-28 Ubuntu USN-807-1 2009-07-28 rPath rPSA-2009-0111-1 2009-07-24 SuSE SUSE-SA:2009:038 2009-07-23 Red Hat RHSA-2009:1157-01 2009-07-14 Mandriva MDVSA-2009:148 2009-07-07 Fedora FEDORA-2009-6768 2009-06-19 Fedora FEDORA-2009-6883 2009-06-23 Fedora FEDORA-2009-6846 2009-06-23

Comments (none posted)

moodle: arbitrary SQL execution

Package(s):	moodle	CVE #(s):	CVE-2008-6124
Created:	June 25, 2009	Updated:	July 1, 2009
Description:	moodle has an arbitrary SQL execution vulnerability. From the National Vulnerability Database entry: SQL injection vulnerability in the hotpot_delete_selected_attempts function in report.php in the HotPot module in Moodle 1.6 before 1.6.7, 1.7 before 1.7.5, 1.8 before 1.8.6, and 1.9 before 1.9.2 allows remote attackers to execute arbitrary SQL commands via a crafted selected attempt.
Alerts:	Ubuntu USN-791-1 2009-06-24

Comments (none posted)

net-snmp: denial of service

Package(s):	net-snmp	CVE #(s):	CVE-2009-1887
Created:	June 25, 2009	Updated:	July 20, 2009
Description:	net-snmp has a denial of service vulnerability. From the Red Hat alert: A divide-by-zero flaw was discovered in the snmpd daemon. A remote attacker could issue a specially-crafted GETBULK request that could crash the snmpd daemon. (CVE-2009-1887) Note: An attacker must have read access to the SNMP server in order to exploit this flaw.
Alerts:	Mandriva MDVSA-2009:156 2009-07-19 CentOS CESA-2009:1124 2009-06-25 Red Hat RHSA-2009:1124-01 2009-06-25

Comments (none posted)

openssl: multiple vulnerabilities

Package(s):	openssl	CVE #(s):	CVE-2009-1379 CVE-2009-1386 CVE-2009-1387
Created:	June 26, 2009	Updated:	March 2, 2010
Description:	From the Ubuntu advisory: It was discovered that OpenSSL did not properly handle certain server certificates when processing DTLS packets. A remote DTLS server could cause a denial of service by sending a message containing a specially crafted server certificate. (CVE-2009-1379) It was discovered that OpenSSL did not properly handle a DTLS ChangeCipherSpec packet when it occured before ClientHello. A remote attacker could cause a denial of service by sending a specially crafted request. (CVE-2009-1386) It was discovered that OpenSSL did not properly handle out of sequence DTLS handshake messages. A remote attacker could cause a denial of service by sending a specially crafted request. (CVE-2009-1387)
Alerts:	Slackware SSA:2010-060-02 2010-03-02 Mandriva MDVSA-2009:310 2009-12-03 Gentoo 200912-01 2009-12-01 Mandriva MDVSA-2009:239 2009-09-22 Mandriva MDVSA-2009:238 2009-09-21 Mandriva MDVSA-2009:237 2009-09-21 Debian DSA-1888-1 2009-09-15 CentOS CESA-2009:1335 2009-09-15 Red Hat RHSA-2009:1335-02 2009-09-02 SuSE SUSE-SR:2009:012 2009-07-03 Ubuntu USN-792-1 2009-06-25

Comments (none posted)

pam_krb5: information disclosure

Package(s):	pam_krb5	CVE #(s):	CVE-2009-1384
Created:	June 29, 2009	Updated:	March 31, 2010
Description:	From the Red Hat bugzilla entry: A security flaw was found in PAM pam_krb5 module, providing user authentication based on Kerberos principals. A remote attacker could use this flaw to recognize, if some username/login belongs to set of user accounts, existing on the system, and subsequently perform dictionary based password guess attack.
Alerts:	Red Hat RHSA-2010:0258-04 2010-03-30 Mandriva MDVSA-2010:054 2010-03-04 Fedora FEDORA-2009-5983 2009-06-15 Fedora FEDORA-2009-6255 2009-06-15 Fedora FEDORA-2009-6279 2009-06-15

Comments (none posted)

php: crash with corrupted JPEG file

Package(s):	php	CVE #(s):
Created:	June 29, 2009	Updated:	July 1, 2009
Description:	From the PHP bug report: There seems to be a problem in exif_read_data(), where some fields representing offsets(?) are taken directly from the file without being validated, resulting in a segmentation fault.
Alerts:	Mandriva MDVSA-2009:145 2009-06-28

Comments (none posted)

rt3: privilege escalation

Package(s):	rt3	CVE #(s):
Created:	June 25, 2009	Updated:	July 1, 2009
Description:	rt3 has a privilege escalation vulnerability. From the Fedora alert: Bug #506885 - rt3: privilege to edit 'RT at a Glance' unintentionally granted by "ShowConfigTab" right.
Alerts:	Fedora FEDORA-2009-6899 2009-06-23 Fedora FEDORA-2009-6837 2009-06-23

Comments (none posted)

samba: several vulnerabilities

Package(s):	samba	CVE #(s):	CVE-2009-1886 CVE-2009-1888
Created:	June 26, 2009	Updated:	December 7, 2009
Description:	From the Debian advisory: Several vulnerabilities have been discovered in Samba, a SMB/CIFS file, print, and login server. The Common Vulnerabilities and Exposures project identifies the following problems: The smbclient utility contains a formatstring vulnerability where commands dealing with file names treat user input as format strings to asprintf. CVE-2009-1886 In the smbd daemon, if a user is trying to modify an access control list (ACL) and is denied permission, this deny may be overridden if the parameter "dos filemode" is set to "yes" in the smb.conf and the user already has write access to the file. CVE-2009-1888
Alerts:	Mandriva MDVSA-2009:320 2009-12-06 Ubuntu USN-839-1 2009-10-01 Mandriva MDVSA-2009:196 2009-08-07 Red Hat RHSA-2009:1529-01 2009-10-27 Red Hat RHSA-2009:1585-01 2009-11-16 CentOS CESA-2009:1529 2009-10-30 Slackware SSA:2009-177-01 2009-06-29 Debian DSA-1823-1 2009-06-25 CentOS CESA-2009:1529 2009-10-27 rPath rPSA-2009-0145-1 2009-11-12

Comments (none posted)

seamonkey: multiple vulnerabilities

Package(s):	seamonkey	CVE #(s):
Created:	June 25, 2009	Updated:	September 8, 2009
Description:	seamonkey has multiple vulnerabilities. From the Mozilla advisory: MFSA 2009-33 Crash viewing multipart/alternative message with text/enhanced part MFSA 2009-32 JavaScript chrome privilege escalation MFSA 2009-29 Arbitrary code execution using event listeners attached to an element whose owner document is null MFSA 2009-27 SSL tampering via non-200 responses to proxy CONNECT requests MFSA 2009-26 Arbitrary domain cookie access by local file: resources MFSA 2009-24 Crashes with evidence of memory corruption (rv:1.9.0.11) MFSA 2009-21 POST data sent to wrong site when saving web page with embedded frame MFSA 2009-17 Same-origin violations when Adobe Flash loaded via view-source: scheme
Alerts:	Slackware SSA:2009-250-01 2009-09-08 Slackware SSA:2009-176-01 2009-06-25

Comments (none posted)

smarty: PHP code injection

Package(s):	smarty	CVE #(s):	CVE-2008-4810
Created:	June 25, 2009	Updated:	August 18, 2010
Description:	Smarty has a PHP code injection vulnerability. From the National Vulnerability Database entry: The _expand_quoted_text function in libs/Smarty_Compiler.class.php in Smarty 2.6.20 before r2797 allows remote attackers to execute arbitrary PHP code via vectors related to templates and (1) a dollar-sign character, aka "php executed in templates;" and (2) a double quoted literal string, aka a "function injection security hole." NOTE: each vector affects slightly different SVN revisions.
Alerts:	Debian DSA-1919-2 2010-08-17 Gentoo 201006-13 2010-06-02 Debian DSA-1919-1 2009-10-25 Ubuntu USN-791-1 2009-06-24

Comments (none posted)

thunderbird: arbitrary code execution

Package(s):	mozilla-thunderbird	CVE #(s):	CVE-2009-2210
Created:	June 29, 2009	Updated:	July 16, 2009
Description:	From the CVE entry: Mozilla Thunderbird before 2.0.0.22 and SeaMonkey before 1.1.17 allow remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a multipart/alternative e-mail message containing a text/enhanced part that triggers access to an incorrect object type.
Alerts:	Fedora FEDORA-2009-7614 2009-07-15 Fedora FEDORA-2009-7567 2009-07-15 CentOS CESA-2009:1134 2009-07-01 Red Hat RHSA-2009:1134-01 2009-06-30 Slackware SSA:2009-178-01 2009-06-29 Mandriva MDVSA-2009:141 2009-06-17 Gentoo 201301-01 2013-01-07

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current 2.6 development prepatch is 2.6.31-rc1, released on June 24. The 2.6.31 merge window is now closed, and the stabilization phase has begun. As always, see the long-format changelog for the details.

There have been no stable updates over the last week. The 2.6.27.26, 2.6.29.6, and 2.6.30.1 updates are in the review process, though, with an expected release on or after July 3. The 2.6.30.1 update contains over 100 patches.

Comments (none posted)

Kernel development news

Quotes of the week

-- Neil Brown

-- Linus Torvalds

-- Andrew Tridgell

-- Dave Phillips

Comments (6 posted)

In brief

O_NODE. Miklos Szeredi has proposed a new flag (O_NODE) which could be passed to open() calls. This flag, in essence, says that the calling program wants to open the indicated filesystem node, but doesn't want to actually do anything with it. With such opens, the underlying open() file operation will not be called, reads and writes will not be allowed, etc.

One might well wonder what the use for such an operation is. The main motivation would appear to be to allow an application to create a file descriptor which can be passed to other system calls - fstat(), say, or openat(). File descriptors used in this way do not really need access to the underlying file, so it makes sense to provide a way to create file descriptors without that access.

O_PONIES. Rik van Riel has proposed another new open flag (actually called O_REWRITE) which is intended to help applications easily avoid the "zero-length files after a crash" problem. A program could open an existing file with O_REWRITE and get some special semantics. The new file would exist, invisibly, alongside the existing file for as long as it remains open; during that time, any other opens of that file would get the old version. Once the file is closed, the kernel will rename it to the given name in an atomic manner, ensuring that either the old version or the (full) new version will exist should a crash happen in the middle.

This option would make it easy for application developers to rewrite existing files without worrying about robustness. Some might respond that it would be better to just teach those developers to use fsync(), but, as Rik notes, "relying on application developers to get it right seems to not have worked out well." Rik's proposal currently lacks an accompanying patch, so it's not destined for the mainline anytime soon.

VFAT patents. As discussed elsewhere, Andrew Tridgell has posted a new lawyer-approved patch aimed at working around Microsoft's VFAT patents. The discussion on the lists has taken a bit of a different course this time around; there is still some annoyance at making changes like this to deal with the problems of the U.S. patent system, but those voices have been relatively quiet. Not completely quiet, though; Alan Cox said:

Beyond that, what developers worry about is interoperability with other VFAT implementations. Alan Cox is asking that, if this patch goes in, the modified filesystem no longer be called "VFAT," since, as he sees it, it's now something else. Ted Ts'o has responded that "VFAT" is a bit of a slippery concept to begin with. It's not clear how this issue will be resolved.

Voyager's voyage. James Bottomley is a proud owner of an archaic Voyager system; Voyager is an x86-based architecture with a number of quaint features - though, contrary to rumor, steam power is not among them. It is not clear whether any Voyager-based systems are still running outside of James's basement. Nonetheless, James has been maintaining the Voyager architecture for years.

More recently, Voyager got kicked out when the code was broken in the process of an x86 subarchitecture-support rewrite. When James tried to get it put back in, x86 Ingo Molnar objected, saying that the costs of the patch were not justified by the benefits of serving such a small user base in the mainline kernel. In the end, Ingo rejected the patch outright, leading to what appeared to be an unsolvable stalemate between the two developers.

Things changed about the time that Linus jumped into the conversation:

Ingo eventually backed down on a number of his complaints about the Voyager patches. What remains, though, is a long list of technical problems with the Voyager tree and how it has been managed. James has accepted those complaints as valid, and will work toward resolving them. Before too long, Voyager owners (both of them) should once again have full support for their beloved architecture in the mainline kernel.

Comments (26 posted)

Soft updates, hard problems

If a file system discussion goes on long enough, someone will bring up soft updates eventually, usually in the form of, "Duhhh, why are you Linux people so stupid? Just use soft updates, like BSD!" Generally, there will be no direct reply to this comment and the conversation will flow silently around it, like a stream around an inky black boulder. Why is this? Is it pure NIH (Not Invented Here) on the part of Linux developers (and Solaris and OS X and AIX and...) or is there something deeper going on? Why are soft updates so famous and yet so seldom implemented? In this article, I will argue that soft updates are, simply put, too hard to understand, implement, and maintain to be part of the mainstream of file system development - while simultaneously attempting to explain how soft updates work. Oh, the irony!

Soft updates: The view from 50,000 feet

Soft updates is one of a family of techniques for maintaining on-disk file system consistency. The basic problem is that a file system doesn't always get shut down cleanly - think power outage or operating system crash - and if this happens in the middle of an update to the file system (say, deleting a file), the on-disk state of the file system may be inconsistent (corrupt). The original solution to this problem was to run fsck on the entire file system to find and correct inconsistencies; ext2 is an example of a file system that uses this approach. (Note that this use of fsck - to recover from an unclean shutdown - is different from the use of fsck to check and repair a file system that has suffered corruption through some other cause.)

The fsck approach has obvious drawbacks (excessive time, possible lost data), so file system developers have invented new techniques. The most popular and well-known is that of logging or journaling: before we begin writing out the changes to the file system, we write a short description of the changes we are about to make (a journal entry) to a separate area of the disk (the journal). If the system crashes in the middle of writing out the changes, we simply finish up the changes by replaying the journal entry at the next file system mount.

Soft updates, instead, takes a two-step approach to crash recovery. First, we carefully order writes to disk so that, at the time of a crash (or any other time), the only inconsistencies are ones in which a file system structure is marked as allocated when it is actually unused. Second, at the next boot after the crash, fsck is run in the background on a file system snapshot (more on that later) to find and free file system structures that are wrongly marked as allocated. Basically, soft updates orders writes to the disk so that only relatively harmless inconsistencies are possible, and then fixes them in the background by checking and repairing the entire file system. The benchmark results are fairly stunning: in common workloads, performance is often within 5% of that of BSD's memory-only file system. The older version of FFS, which used synchronous writes and foreground fsck to provide similar reliability, often runs 20-30% slower than the in-memory file system.

Step 1: Update dependencies

The first part of implementing soft updates is figuring out how to order the writes to the disk so that after a crash, the only possible errors are inodes and blocks erroneously marked as allocated (when they are actually free). First, the authors lay out some rules to follow when writing changes to disk in order to accomplish this goal. From the paper:

1. Never point to a structure before it has been initialized (e.g., an inode must be initialized before a directory entry references it).
2. Never re-use a resource before nullifying all previous pointers to it (e.g., an inode's pointer to a data block must be nullified before that disk block may be re-allocated for a new inode).
3. Never reset the old pointer to a live resource before the new pointer has been set (e.g., when renaming a file, do not remove the old name for an inode until after the new name has been written).

Pairs of changes in which one change must to be written to disk before the next change can be written, according to the above rules, are called update dependencies. For some more examples of update dependencies, take the case of writing to the first block in a file for the first time. The first update dependency is that the block bitmap, which records which blocks are in-use, must be written to show that the block is in use before the block pointer in the inode is set. If a crash were to occur at this point, the only inconsistency would be one bit in the block bitmap showing a block is allocated when it isn't actually. This is a resource leak, and must be fixed eventually, but the file system can operate correctly with this error as long as it doesn't run out of blocks.

The second update dependency is that the data in the block itself must be written before the block pointer in the inode can be set (along with the increase in the inode size and the associated timestamp updates). If it weren't, a crash at this point would result in garbage appearing in the file - a potential security hole, as well, if that garbage came from a previously written file. Instead, a crash would result in a leaked block (marked as allocated when it isn't) that happens to contain the data from the attempted write. As a result, the write to the bitmap and the write of the data to the block must complete (in any order) before the write that updates the inode's block pointer, size, and timestamps.

These rules about ordering of writes aren't new for soft updates; they were originally created for writes to a "normal" FFS file system. In the original FFS code, ordering of writes is enforced with synchronous writes - that is, the ongoing file system operation (create, unlink, etc.) waits for each ordered write to hit disk before going on to the next step. While the write is in progress, the operating system buffer containing the disk block in question is locked. Any other operation needing to change that buffer has to wait its turn. As a result, many metadata operations progress at disk speed (i.e., murderously slowly).

Step 2: Efficiently satisfying update dependencies

So far, we have determined that synchronous writes on locked buffers are a slow, painful way of enforcing the ordering of writes to the file system. But synchronous writes are overkill for most file system operations; other than fsync(), we generally don't want a guarantee that the result has been written to stable storage before the system call returns, and as we've seen, the file system code itself usually only cares about the order of writes, not when they complete. What we want is a way to record changes to metadata, along with the associated ordering constraints, and then schedule the actual writes at our leisure. No problem, right? We'll just add a couple of pointers to each in-memory buffer containing metadata, linking it to the blocks it has come before and after.

Turns out there is a problem: cyclical dependencies. We have to write to the disk in block-size units, and each block can potentially contain metadata affected by more than one metadata operation. If two different operations affect the same blocks, it can easily result in conflicting requirements: operation A requires that block 1 be written before block 2, and operation B requires that block 2 be written before block 1. Now you can't write out any changes without violating the ordering constraints. What to do?

Most people, at this point, decide to use journaling or copy-on-write to deal with this problem. Both techniques group related changes into transactions - a set of writes that must take effect all at once - and write them out to disk in such a manner that they take effect atomically. But if you are Greg Ganger and Yale Patt, you come up with a scheme to record individual modifications to blocks (such as the update to a single bit in a bitmap block) and their relationships to other individual changes (that change requires this other change to be written out first). Then, when you write out a block, you lock it and iterate through the records of individual changes to this block. For each individual change whose dependencies haven't yet been satisfied, you undo that change to the block, and then write out the resulting block. When the write is done, you re-apply the changes (roll forward), unlock, and continue on your way until the next write. The write you just completed may have satisfied the update dependencies of other blocks, so now you can go through the same process (lock, roll back, write, roll forward, unlock) for those blocks. Eventually, all the dependencies will be satisfied and everything will be written to disk, all without running into any circular dependencies. This, in a nutshell, is what makes soft updates unique.

Recording changes and dependencies

So what does a record of a metadata change, and its corresponding update dependencies, actually look like at the data structure level? First, there are twelve (as of the 1999 paper) distinct structures to record the different types of dependencies:

Structure	Dependency tracked
bmsafemap	block/inode bitmaps
inodedep	inode
allocdirect	blocks referenced by direct block pointers
indirdep	indirect block
allocindir	blocks referenced by indirect block pointers
pagedep	directory entry add/remove
mkdir	new directory creation
dirrem	directory removal
freefrag	fragment to be freed
freeblks	block to be freed
freefile	inode to be freed

Each kind of dependency-tracking structure includes pointers that allow it to be linked into lists attached to the buffers containing the relevant on-disk structures. These lists are what the soft updates code traverses during the roll-back and roll-forward operations on a block being written to disk. Each dependency structure has a set of state flags describing the current status of the dependency. The flags indicate whether the dependency is currently applied to the associated buffer, whether all of the writes it depends on have completed, and whether the update described by the dependency tracking structure itself has been written to disk. When all three of these flags are set (the update is applied to the in-memory buffer, all its dependent writes are completed, and the update is written to disk), the dependency structure can be thrown away.

Page 7 of the 1999 soft updates paper [PDF] begins the descriptions of specific kinds of update dependency structures and their relationships to each other. I've read this paper at least 15 times, and each time I when get to page 7, I'm feeling pretty good and thinking, "Yeah, okay, I must be smarter now than the last time I read this because I'm getting it this time," - and then I turn to page 8 and my head explodes. Here's the first figure on that page:

And that's only the figure from the left-hand column. An only slightly less complex spaghetti-gram occupies the right-hand column. This goes on for six pages, describing each specific kind of update dependency and its progression through various lists associated with buffers and file system structures and, most importantly, other update dependency structures. You find yourself struggling through paragraphs like:

Say that three times fast!

The point is not that the details of soft updates are too complex for mere humans to understand (although I personally I wouldn't bet against Greg Ganger being superhuman). The point is that this complexity reflects a lack of generality and abstraction in the design of soft updates as a whole. In soft updates, every file system operation must be individually analyzed for write dependencies, every on-disk structure must have a custom-designed dependency tracking structure, and every update operation must allocate one of these structures and hook itself into the web of other custom-designed dependency tracking structures. If you add a new file system feature, like extended attributes, or change the on-disk format, you have to start from scratch and reason out the relevant dependencies, design a new structure, and write the roll-forward/roll-back routines. It's fiddly, tedious work, and the difficulty of doing it correctly doesn't make it any better a use of programmer staff-hours.

Contrast the highly operation-specific design of soft updates to the transaction-style interface used by most journaling and copy-on-write file systems. When you begin a logical operation (such as a file create), you create a transaction handle. Then, for each on-disk structure you have to modify, you add that buffer to the list of buffers modified by this transaction. When you are done, you close out the transaction and hand it off to the journaling (or COW) subsystem, which figures out how to merge it with other transactions and write them out to disk properly. The user of the transaction interface only has to know how to open, close, and add blocks to a transaction, while the transaction code only has to know which blocks are part of the same transaction. Adding a new write operation requires no special knowledge or analysis beyond remembering to add changed blocks to the transaction.

The lack of generalization and abstraction shows up again when the combination of update dependency ordering and the underlying disk format poke out and cause strange user-visible behavior. The most prominent example shows up when removing a directory; following the rules governing update dependencies means that a directory's ".." entry can't be removed until the directory itself is recorded as unlinked on the disk. Chains of update dependencies sometimes resulted in up to two minutes of delay between the return of rmdir(), and the corresponding decrement of the parent directory's link count. This can break, among other things, a simple recursive "rm -rf". The fix was to fake up a second link count that is reported to userspace, but the real problem was a too-tight coupling between on-disk structures, the system to maintain on-disk consistency, and the user-visible structures. Long chains of update dependencies cause problems elsewhere, during unmount and fsync() in particular.

Fsck and the snapshot

But wait, there's more! The second stage of recovery for soft updates is to run fsck after the next boot, in the background using a snapshot of the file system metadata. File system snapshots in FFS are implemented by creating a sparse file the same size as the file system - the snapshot file. Whenever a block of metadata is altered, the original data is first copied to the corresponding block in the snapshot file. Reads of unaltered blocks in the snapshot redirect to the originals. Online fsck runs on the snapshot of the file system metadata, finding leaked blocks and inodes. Once it completes, fsck uses a special system call to mark these blocks and inodes as free again.

Online fsck implemented in this manner has severe limitations. First, recovery from a crash still requires reading and processing the metadata for the entire file system - in the background, certainly, but that's still a lot of I/O. (Freeblock scheduling piggybacks low-priority I/O, like that of a background fsck, on high-priority foreground I/O so that it interferes as little as possible with "real" work, but that's cold comfort.) Second, it's not actually a full file system check and repair, it's just a scan for leaked blocks and inodes - expected inconsistencies. The whole concept of running fsck on a snapshot file whose blocks are allocated from the same file system assumes that the file system is not corrupted in a way that leaves blocks marked as free when they are actually allocated.

Conclusion

Conceptually, soft updates can be explained concisely - order writes according to some simple rules, track updates to metadata blocks, roll-back updates with unsatisfied dependencies before writing the block to disk, then roll-forward the updates again. But when it come to implementation, only programmers with deep, encyclopedic knowledge of the file system's on-disk format can derive the correct ordering rules and construct the associated data structures and web of dependencies. The close coupling of on-disk data structures and their updates and the user-visible data structures and their updates results in weird, counter-intuitive behavior that must be covered up with additional code.

Overall, soft updates is a sophisticated, insightful, clever idea - and an evolutionary dead end. Journaling and copy-on-write systems are easier to implement, require less special-purpose code, and demand far less of the programmer writing to the interface.

Comments (39 posted)

Perfcounters added to the mainline

We last looked at the perfcounters patches back in December, shortly after they appeared. Since that time, a great deal of work has been done, culminating in perfcounters being included into the mainline during the recently completed 2.6.31 merge window. Along the way, a tool to use perfcounters, called perf, was added to the mainline as well.

Adding perf to the kernel tools/ directory is one of the more surprising aspects of the perfcounters merge. Kernel hackers have long been leery of adding user-space tools into the kernel source tree, but Linus Torvalds was unconvinced by multiple complaints about that approach. He pointed to oprofile to explain:

Others were not so sure that the oprofile being developed separately from the kernel was the root cause of those failures. Christoph Hellwig had other ideas: "I don't think oprofile has been a [disaster] because of any kind of split, but because the design has been a failure from day 1." But, Torvalds wants to try including the tool to see where it leads: "Let's give a _new_ approach a chance, and see if we can avoid the mistakes of yesteryear this time."

The perf tool itself is a fairly simple command-line tool, which can be built from the tools/perf directory. It also includes some documentation, in the form of man pages that are also available via perf help (as well as in HTML and other formats). At its simplest, it gathers and reports some statistics for a particular command:

    $ perf stat ./hackbench 10
    Time: 4.174

     Performance counter stats for './hackbench 10':

	8134.135358  task-clock-msecs     #      1.859 CPUs
	      23524  context-switches     #      0.003 M/sec
	       1095  CPU-migrations       #      0.000 M/sec
	      16964  page-faults          #      0.002 M/sec
	10734363561  cycles               #   1319.669 M/sec
	12281522014  instructions         #      1.144 IPC
	  121964514  cache-references     #     14.994 M/sec
	   10280836  cache-misses         #      1.264 M/sec

	4.376588249  seconds time elapsed.

This summarizes the performance events that occurred while running the hackbench micro-benchmark program. There are a combination of hardware events (cycles, instructions, cache-references, and cache-misses) as well as software events (task-clock-msecs, context-switches, CPU-migrations, and page-faults) that are derived from the kernel code and not the processor-specific performance monitoring unit (PMU). Currently, support for hardware events is available for Intel, AMD, and PowerPC PMUs, but other architectures still have support for the software events.

There is also a top-like mode for observing which kernel functions are being executed most frequently in a continuously updating display:

    $ perf top -c 1000 -p 3216

    ------------------------------------------------------------------------------
       PerfTop:     360 irqs/sec  kernel:65.0% [1000 cycles],  (target_pid: 3216)
    ------------------------------------------------------------------------------

		 samples    pcnt         RIP          kernel function
      ______     _______   _____   ________________   _______________

		 1214.00 -  5.3% - 00000000c045cb4d : lock_acquire
		 1148.00 -  5.0% - 00000000c045d1d3 : lock_release
		  911.00 -  4.0% - 00000000c045d377 : lock_acquired
		  509.00 -  2.2% - 00000000c05a0cbc : debug_locks_off
		  490.00 -  2.2% - 00000000c05a2f08 : _raw_spin_trylock
		  489.00 -  2.1% - 00000000c041d1d8 : read_hpet
		  488.00 -  2.1% - 00000000c04419b8 : run_timer_softirq
		  483.00 -  2.1% - 00000000c04d5f72 : do_sys_poll
		  477.00 -  2.1% - 00000000c05a34a0 : debug_smp_processor_id
		  462.00 -  2.0% - 00000000c043df85 : __do_softirq
		  404.00 -  1.8% - 00000000c074d93f : sub_preempt_count
		  353.00 -  1.5% - 00000000c074d9d2 : add_preempt_count
		  338.00 -  1.5% - 00000000c0408a76 : native_sched_clock
		  318.00 -  1.4% - 00000000c074b4c3 : _spin_lock_irqsave
		  309.00 -  1.4% - 00000000c044ea10 : enqueue_hrtimer

This is a static version of the output from looking at a largely quiescent firefox process (pid 3216), sampling every 1000 cycles.

There is quite a bit more that perf can do. There is a record sub-function that gathers the performance counter data into a perf.data file which can be used by other commands:

    $ perf record ./hackbench 10
    Time: 4.348
    [ perf record: Captured and wrote 2.528 MB perf.data (~110448 samples) ]

    $ perf report --sort comm,dso,symbol | head -15

    #
    # (110146 samples)
    #
    # Overhead           Command  Shared Object              Symbol
    # ........  ................  .........................  ......
    #
	10.70%         hackbench  [kernel]                   [k] check_bytes_and_report
	 9.07%         hackbench  [kernel]                   [k] slab_pad_check
	 5.67%         hackbench  [kernel]                   [k] on_freelist
	 5.28%         hackbench  [kernel]                   [k] lock_acquire
	 5.03%         hackbench  [kernel]                   [k] lock_release
	 3.19%         hackbench  [kernel]                   [k] init_object
	 3.02%         hackbench  [kernel]                   [k] lock_acquired
	 2.47%         hackbench  [kernel]                   [k] _raw_spin_trylock

This output shows the top eight kernel functions executed while running hackbench. The same data file can also be used by perf annotate (when given a symbol name and the appropriate vmlinux file) to show the disassembled code for a function, along with the number of samples recorded on each instruction. There is clearly a wealth of information that can be derived from the tool.

The original posting of the perfcounters patches came as somewhat of a surprise to Stéphane Eranian, who had long been working on another performance monitoring solution, "perfmon". While he is still a bit skeptical of perfcounters, which were originally proposed by Ingo Molnar and Thomas Gleixner, he has been reviewing the patches, and providing lengthy comments. Molnar, also responded at length, breaking his reply into multiple chunks which can be found in the thread.

Perfmon was targeted at exposing as much of the underlying PMU data as possible to user space, but Molnar explicitly rejects that goal:

His focus, presumably shared with his co-maintainers Peter Zijlstra and Paul Mackerras, is to generalize performance measurement features so that they are not dependent on any particular CPU and that they fit well with developer work flow: "I do claim we had few if any sane performance analysis tools before under Linux, and i think we are still in the stone ages and still have a lot of work to do in this area." From Molnar's perspective, that ease of use for users and developers is one of the main areas where perfmon fell short.

Molnar is not shy about pointing out that perfcounters still needs a lot of work, but the framework is there, so features can be added to that. As yet, there is no documentation in the kernel Documentation/ directory, but one presumes that will be handled sometime soon. Overall, perfcounters and the perf tool look to be a highly useful addition to the kernel, one that should start providing benefits—in the form of better performance—in the near term.

Comments (18 posted)

The fanotify API

One of the features merged for 2.6.31 is the "fsnotify" file event notification framework. Fsnotify serves as a new, common underpinning for the inotify and dnotify APIs, simplifying the code considerably. But this simplification, as welcome as it is, was never the real purpose behind fsnotify. Instead, fsnotify exists to serve as the support structure for fanotify, the "fscking all notification system," which has now been posted for further review.

Fanotify was once known as TALPA; its main purpose is to enable the implementation of malware scanners on Linux systems. When TALPA was first proposed, it ran into criticism on a number of fronts, not the least of which being a general disdain for malware scanning as a security technique. The sad fact of the matter, though, is that a number of customers require this functionality, so a market for such products on Linux exists. Thus far, scanning products for Linux have relied on a number of distasteful techniques, including hooking into the system call table or the loading of binary-only security modules. Fanotify, it is hoped, will help to wean these products off of such hacks and get them out of the kernel altogether.

The user-space API used by fanotify is, to your editor's eye, a little strange. An fanotify application starts by opening a socket with the new PF_FANOTIFY protocol family. This socket must then be bound to an "address" described this way:

    struct fanotify_addr {
	sa_family_t family;
	__u32 priority;
	__u32 group_num;
	__u32 mask;
	__u32 timeout;
	__u32 unused[16];
    };

The family field should be AF_FANOTIFY. The priority field is used to determine which socket gets a specific event if more than one fanotify socket exists; lower priority values win. The group_num is used by the fsnotify layer to identify a group of event listeners. The timeout field currently appears to be unused. Finally, mask describes the events that the application is interested in hearing about:

• FAN_ACCESS: every file access.
• FAN_MODIFY: file modifications.
• FAN_CLOSE: when files are closed.
• FAN_OPEN: open() calls.
• FAN_ACCESS_PERM: like FAN_ACCESS, except that the process trying to access the file is put on hold while the fanotify client decides whether to allow the operation.
• FAN_OPEN_PERM: like FAN_OPEN, but with the permission check.
• FAN_EVENT_ON_CHILD: the caller is interested in events on full directory hierarchies.
• FAN_GLOBAL_LISTENER: notify for events on all files in the system.

Once the socket has been bound, the application can learn about filesystem activity using the well-known event-reading system call getsockopt(). A call to getsockopt() with SOL_FANOTIFY as the level and FANOTIFY_GET_EVENT as the option will return one or more structures like this:

    struct fanotify_event_metadata {
	__u32 event_len;
	__s32 fd;
	__u32 mask;
	__u32 f_flags;
	pid_t pid;
	pid_t tgid;
	__u64 cookie;
    };

Here, fd is an open, read-only file descriptor for the file in question, mask describes the event (using the flags described above), f_flags is a copy of the flags provided by the process trying to access the file, and pid and tgid identify that process (in a namespace-unaware way, currently). If the event is one requiring permission from the application, cookie will contain a value which can be used to grant or deny that permission.

Note that the provided file descriptor should eventually be closed; otherwise these file descriptors are likely to accumulate rather quickly.

When access decisions are being made, the application must notify the kernel with a call to setsockopt() using the FANOTIFY_ACCESS_RESPONSE option and a structure like:

    struct fanotify_so_access {
	__u64 cookie;
	__u32 response;
    };

The cookie value from the event should be provided, and response should be one of FAN_ALLOW or FAN_DENY. If the application does not respond within five seconds, the kernel will allow the action to proceed. Five seconds should be sufficient for file scanning, but it could be a problem with some other possible applications of fanotify, such as hierarchical storage management systems. Fanotify developer Eric Paris notes that a future option allowing the response to be delayed indefinitely will probably be added at some point.

It is possible to adjust the set of files subject to notifications with the FANOTIFY_SET_MARK, FANOTIFY_REMOVE_MARK, and FANOTIFY_CLEAR_MARKS operations. If the FAN_GLOBAL_LISTENER option was provided at bind time, then all files are "marked" at the outset; FANOTIFY_REMOVE_MARK can be used to prune those which are not interesting. Otherwise at least one FANOTIFY_SET_MARK call must be made before events will be returned.

Some details have been left out, but the above discussion covers the core parts of the fanotify API. Comments on this posting have been relatively scarce; opposition to this feature seems to have faded away over the last year or so. What's left is getting the API right; your editor suspects that the use of getsockopt() as an event retrieval interface may raise a few eyebrows sooner or later. But, once that's ironed out, chances are good that Linux will be well on the way toward having a general file access notification and permission interface.

Comments (21 posted)

Patches and updates

Core kernel code

• Paul E. McKenney: expedited "big hammer" RCU grace periods . (June 26, 2009)

Development tools

• Ben Gamari: Infrastructure for tracking driver performance events . (June 26, 2009)

• Subrata Modak: [LTP] [ANNOUNCE] The Linux Test Project has been Released for JUNE 2009 . (July 1, 2009)

Device drivers

• Alan Cox: resource: shared I/O region support . (June 26, 2009)

• Jerome Glisse: TTM page pool allocator . (June 26, 2009)

• Daniel Ribeiro: PCAP regulator driver (for 2.6.32). . (June 26, 2009)

• Daniel Ribeiro: PCAP RTC driver (for 2.6.32). . (June 26, 2009)

• Minkyu Kang: hwmon: add GP2A002 proximity/ambient sensor . (June 26, 2009)

• Rafael J. Wysocki: PM: Introduce core framework for run-time PM of I/O devices (rev. 7) . (June 30, 2009)

• Pavel Machek: Framebuffer support for HTC Dream . (June 30, 2009)

• Pavel Machek: MMC driver for HTC Dream . (June 30, 2009)

Filesystems and block I/O

• Jens Axboe: Per-bdi writeback flusher threads v12 . (June 26, 2009)

• Philipp Reisner: drbd: a block device for HA clusters . (June 26, 2009)

• tridge@samba.org: Added CONFIG_VFAT_FS_DUALNAMES option . (June 27, 2009)

• Eric Paris: fanotify: the fscking all notification system . (June 30, 2009)

• Miklos Szeredi: vfs: new open(2) flag to open filesystem node . (June 30, 2009)

• Christoph Hellwig: XFS status update for June 2009 . (July 1, 2009)

Memory management

• Hugh Dickins: KSM: current madvise rollup . (June 30, 2009)

• Lee Schermerhorn: Balance Freeing of Huge Pages across Nodes . (June 30, 2009)

Architecture-specific

• David Woodhouse: Support DMA-API debugging facility on PowerPC . (July 1, 2009)

Security-related

• Jari Ruusu: Announce loop-AES-v3.2g file/swap crypto package . (June 30, 2009)

• Siarhei Liakh: RO/NX protection for loadable kernel modules . (June 30, 2009)

• Joseph Cihula: [RFC v6][PATCH 0a/4] intel_txt: Intel(R) Trusted Execution Technology support for Linux - Overview . (July 1, 2009)

Benchmarks and bugs

• Arjan van de Ven: kerneloops.org report for the week . (June 30, 2009)

• Rafael J. Wysocki: 2.6.31-rc1-git3: Reported regressions from 2.6.30 . (June 30, 2009)

• Rafael J. Wysocki: 2.6.31-rc1-git3: Reported regressions 2.6.29 -> 2.6.30 . (June 30, 2009)

Miscellaneous

• Greg KH: usbutils 0.84 release . (June 26, 2009)

• Karel Zak: util-linux-ng v2.16-rc1 . (June 30, 2009)

• Ryo Tsuruta: IO controller mini-summit -- Japan, Oct 2009 . (July 1, 2009)

Page editor: Jonathan Corbet

Distributions

News and Editorials

Ubuntu archive reorganization

Ubuntu is over five years old, with ten releases under its belt. Since that time the archive structure, envisioned before the first release, has begun to show its age. Recently the Ubuntu Technical Committee announced that a change was coming. For the most part users should not notice much if any difference, but there will be changes for developers.

The Archive Reorganisation will be done in stages, only a part of the work will be done during the Karmic development cycle. Though the process is still in the very early stages and proposals are subject to change, we will take a look at how things are likely to proceed in the near future.

First we should look at the current organization of the archive, which has been split into four components; main, restricted, universe and multiverse. The main repository contains free software, supported by the core developers. The restricted repository is also supported by core developers and contains non-free software such as drivers. Universe and multiverse contain free and non-free software, respectively and are not officially supported by Canonical, Ubuntu's parent company.

The MOTU (Masters of the Universe) team supports universe, multiverse and various other packages that are otherwise untended. It was initially envisioned that beginning developers would submit patches. After some experience they would be trusted to upload a limited set of packages without prior review. Eventually they would gain enough experience to become a core developer with access to all repositories.

Over time the MOTU team has become increasingly fragmented by the officially supported flavors (Kubuntu, Xubuntu, Ubuntu Studio, etc.). Hundreds of packages have migrated to the main repository as the various flavors became official. Ubuntu Studio alone brought 141 source packages into the 8.04 LTS release that were not part of any other flavor. Meanwhile, many MOTU developers tend to only be interested in a subset of packages and are not interested in becoming core developers. For example many Kubuntu developers only want to work with KDE packages and are not interested in having access to the rest of the archive.

As the number of flavors grows to include MythTV packages, netbooks and mobile devices, cloud computing and other specialties, more and more packages (and all their dependencies are moved into main, but are still maintained by MOTU developers, so there are access control issues. Some packages are "maintained for security updates", while others are "commercially supported by Canonical", further muddying the waters.

The proposal to alleviate these issues has been divided into three parts. The first part deals with exceptions useful in specific cases, the second deals with permission changes and third deals with component changes. The first part is largely implemented already. The second part is targeted to take place during the Karmic development period. The component changes are still being discussed and won't really be addressed until after Karmic (9.10) is released.

To begin with, those MOTU developers who are doing a good job maintaining their packages will be granted permission to upload those packages into main. This has been implemented on a case by case basis as determined by the Ubuntu Technical Board.

Currently packages are grouped by seeds and seed collections. "Xubuntu Jaunty desktop" is a seed that contains all of the source packages and dependencies for a functioning XFCE desktop. "Xubuntu Jaunty" is a seed collection of all the packages on the Xubuntu Jaunty live CD. Seed collections are not exposed to users and are subject to reorganization.

Package sets will likely be based on seeds but will be exposed to users via package management tools. Packages are grouped into package sets such as "core", "Ubuntu desktop", "Ubuntu server" and "Kubuntu". A package may be in more than one package set. Each package set has associated access control for upload permissions and queue administration.

The Technical Board will be able to manage package sets by adding or removing packages from them, and will be able to assign upload privileges at the package set level. Some packages sets will be restricted to a small set of experienced developers, such as the Linux kernel or glib. Most package sets will be unrestricted. Granting upload access to a team implies that the administrators of that team will be able to grant upload access to additional developers, at least for unrestricted package sets.

The core developers and the MOTU developers will be collapsed into a single team of Ubuntu developers. It could be that most developers will be able to upload packages from any unrestricted package set, but this is subject to change. It may make more sense to grant many developers access only to their specific package set. So the average Kubuntu developer would only have upload permission for a set of KDE packages, not to the archive as a whole. The line between core and MOTU developers becomes blurred so does the distinction between the current main and universe repositories. Packages contained in package sets will be considered in main while those few packages that are not part of a set or seed collection will be in universe. Some extensions to Launchpad will be required for this to work as desired. Again, this is still subject to change, but should be mostly implemented by the time Karmic is released.

The third part of the proposal is the reorganization of components. There will be more review and discussion of this after Karmic is released so it is best to deffer any discussion for a while.

Comments (2 posted)

New Releases

openSUSE 11.2 Milestone 3 Available

The openSUSE Project has announced the release of openSUSE 11.2 Milestone 3. "Images are ready for download and testing. This release includes the 2.6.30 Linux kernel, KDE 4.3 beta 2, GNOME 2.27.2, OpenOffice.org 3.1.1 Alpha, and more!"

Full Story (comments: none)

Fixstars Launches YDL v6.2

Fixstars has announced the immediate availability of Yellow Dog Linux version 6.2, delivering several updates and improvements. "This release offers an updated kernel v2.6.29 for 64-bit systems, OpenOffice 3.0, Firefox 3.0.6 and IBM Cell SDK v3.1.0.1, as well as the next generation of ps3vram for fast, temporary file storage or swap using PS3 video RAM. With this release, ps3vram is up to 50% faster than in YDL 6.1 and is automatically enabled as swap."

Comments (none posted)

Distribution News

Debian GNU/Linux

Kernel version 2.6.30 + firmware + ext4 support available for Debian Lenny

Kenshi Muto has released an updated kernel for Debian 5.0.1 "Lenny". Debian installer images with kernel version 2.6.30 including firmware and support for ext4 are available for i386 and AMD64 versions of Lenny.

Comments (2 posted)

Fedora

Fedora news: F12 release name is "Constantine", Josh Boyer appointed to the board

Some miscellaneous Fedora news from over the weekend includes the results of the Fedora 12 release name vote; the winner is "Constantine". Also, Josh Boyer has been appointed to the final seat on the Fedora board by Fedora project leader Paul Frields. "Josh is well known around the Fedora community for his work with release engineering and many other development-oriented groups, as well as his past work with FESCo and as a maintainer of Fedora on PPC architecture. I hope the community will join me in welcoming him to the Board where we hope he can help achieve some of the goals put forward during the town hall meetings earlier this month." The new board will be meeting for the first time on Thursday July 2, in a public IRC meeting.

Comments (18 posted)

Cooperative Bug Isolation for Fedora 11

The Cooperative Bug Isolation Project (CBI) is now available for Fedora 11. "CBI (http://www.cs.wisc.edu/cbi/) is an ongoing research effort to find and fix bugs in the real world. We distribute specially modified versions of popular open source software packages. These special versions monitor their own behavior while they run, and report back how they work (or how they fail to work) in the hands of real users like you. Even if you've never written a line of code in your life, you can help make things better for everyone simply by using our special bug-hunting packages."

Full Story (comments: none)

SUSE Linux and openSUSE

iFolder Packages Available for 11.1

iFolder client packages are available for openSUSE 11.1 from the openSUSE update repositories. "Like openSUSE, iFolder is an open source project sponsored by Novell. iFolder is a simple and secure storage solution that can make syncing and sharing files easy. You can back up, access, and manage your personal files from anywhere, at any time. Once you have installed iFolder, you simply save your files locally and iFolder automatically updates the files on a network server and delivers them to the other machines you use."

Full Story (comments: none)

Distribution Newsletters

DistroWatch Weekly, Issue 309

The DistroWatch Weekly for June 29, 2009 is out. "Everybody knows that LinuxTag is a premier open-source exhibition and conference in Europe. But how does it feel being there? What are the people like? What takes place at the stands, conference halls, informal parties? This week's DistroWatch Weekly gives first-hand answers to these and many other questions. In the news this past week, Debian contributors release an updated kernel for "Lenny", while Fedora settles on a code name for its upcoming release, version 12. If you've ever been tempted to try the oldest surviving Linux distribution, a beginner's install guide for Slackware we link to might be just what you need. Finally, don't miss the story about the BSD Magazine which has released some great articles from its print publication for your reading pleasure. Have a great Monday and the rest of the week!"

Comments (none posted)

Fedora Weekly News 182

The Fedora Weekly News for June 28, 2009 is out. "Here are a few highlights from this week's issue. By request, we've returned to including the contents at the top of the issue. Please let us know what you think! Announcements starts us off with updates on recent Fedora elections. Hot on the heels of the release of Fedora 11, the codename for Fedora 12 has already been chosen -- read inside for details. From the Fedora Planet, lots of great updates from the recent FUDCon in Berlin, as well as many updates from Fedora contributors. In Ambassador news, details from the recent Fedora 11 launch party from the NaLUG (Napoli GNU/Linux Users Group). In Quality Assurance news, many updates on Fedora 12 development, including discussion of improving debugging procedure pages, rawhide acceptance plan, bugzapper updates, and much more. Much interesting discussion in the Design beat this week on thinking around themes for Fedora 12 based on the release name. In Security Advisories, we're brought up to date with this week's software patches for Fedora 9, 10 and 11. This week's issue rounds out with updates from virtualization activities, with detail work on a libguestfs 'Super-minimized Appliance', VMWare ESX driver status, and much more! Enjoy!"

Full Story (comments: none)

The Mint Newsletter - issue 87

This issue of the Mint Newsletter covers the release of Mint 7 x64 and much more.

Comments (none posted)

OpenSUSE Weekly News/78

This issue of the OpenSUSE Weekly News covers: openSUSE Forums hits 30,000 Users, Google Summer of Code Status Reports, Jigish Gohil : Stop ssh brute force attack using SuSEfirewall, metaverse: More Free and Open Source Tools for Writers, openSUSE Forums: How to Read a .docx file in SUSE?, and more.

Comments (none posted)

Ubuntu Weekly Newsletter #148

The Ubuntu Weekly Newsletter for June 28, 2009 is out. "In this issue we cover: MOTU Council, New Ubuntu Members, First Paper Cut milestone reached, Tracking Ubuntu Community Issues, Kubuntu Tutorials Day, Introducing the Ubuntu NGO team, Extra options when filing bugs, Ubuntu Podcast Quickie #7, and much, much more!"

Full Story (comments: none)

Newsletters and articles of interest

Five Reasons I Prefer Slackware Over Ubuntu (fullmetalgerbil)

Dave at the fullmetalgerbil weblog has this post presenting five reasons why he prefers Slackware over Ubuntu. "Really, when I thought about doing this I wondered if I could come up with five reasons but now I'm sure I could go on much longer. Slackware is the oldest existing Linux distribution and it didn't get to being around this long by being sub par. There's a general consensus that the post install configuration of Slackware may be a bit too challenging for beginners, but I think anyone who can read a copy of the Slackbook and use a Slackware forum if need be would be able to do it. Believe me, it's worth the initial effort and like Trent of the Linux Critic says-once you go slack, you never go back."

Comments (1 posted)

Page editor: Rebecca Sobol

Development

VA API slowly -- but surely -- making progress

For years, video acceleration on Linux and Unix-like systems has been possible only through the X Video Motion Compensation (XvMC) API. A new, more modern replacement is in the works: the Video Acceleration API (VA API). XvMC offered a way for applications to partially offload decoding of MPEG-2-encoded video directly to the video card's graphics processing unit (GPU), which provided more speed and a smoother display when compared to processing on the system CPU. VA API will add more video formats to the accelerated decoding pipeline, as well as video encoding and post-processing.

Applications can use XvMC to save CPU cycles and reduce power consumption, but the API is extremely limited: it only supports MPEG-2 video, and only offloads the motion compensation calculations. On the other hand, XvMC is supported by a wide range of video hardware from different manufacturers, current and legacy. X developers talked about extending XvMC to support other formats and to add more steps in the video decoding process — such as the costly inverse discrete cosine transform (iDCT), but eventually decided to write a new API from the ground up.

A new specification

The VA API project was launched in December of 2006, spearheaded by Jonathan Bian from Intel. Initially, the API only attempted to cover video decoding, adding support for the VC-1 codec, and adding iDCT and variable-length decoding (VLD or "slice-level acceleration") to the techniques offloaded to the GPU. The specification subsequently added MPEG-4 ASP/H.263 and MPEG-4 AVC/H.264 to the list of supported codecs, and acceleration hooks for deblocking and inverse zigzag ordering (IZZ). VA API has also been designed to handle color space conversion, gamma correction, scaling, and other video processing techniques traditionally handled by the X video extension (Xv) rather than XvMC itself.

The most recent revision of the specification is 0.30, released in March of 2009, more than a year after the release of 0.29. 0.30 introduces a major new feature to the API: hardware acceleration for video encoding. The encoding support supports multiple codecs; currently H.263, H.264, and generic MPEG-4 are specified.

In addition to the specification, the project produces libVA, an implementation library targeting Linux systems. Using libVA requires supported hardware and a supported video driver, however, which has historically been the sticking point. VA API is maintained by a team at Intel: Bian, Austin Yuan, and Waldo Bastian. Despite calls for input and outside participation, the competing GPU manufacturers have not contributed, each preferring to put effort into its own hardware video acceleration project. NVIDIA has the Video Decode and Presentation API for Unix (VDPAU), and ATI has X-Video Bitstream Acceleration (XvBA). Thus, the only Linux video driver that natively supports VA API is Intel's own (closed source) psb-video, for its Poulsbo chipset, which is aimed at low-power devices like netbooks and features the GMA500 GPU.

Beyond Intel: participation and driver support

The single-vendor problem began to turn around in late 2008, when embedded systems vendor Splitted-Desktop Systems (SDS) decided to adopt VA API for some of its Linux-based low-power boxes. SDS's Gwenole Beauchesne developed bridge code to use VDPAU and XvBA as back-ends for VA API, bringing support for the API to NVIDIA and ATI card owners. Neither VDPAU nor XvBA support the entire product range from either manufacturer, of course, and both vendor APIs are limited in scope — neither supports encoding acceleration, and VDPAU does not support MPEG-4 ASP/H.263.

Taking advantage of this work requires a VDPAU- or XvBA-supported video card, a VDPAU- or XvBA-enabled driver, and a patched version of libVA. Beauchesne's patches to libVA add fields to VA API's control structures to pass parameters down to the VDPAU and XvBA back-ends. He publicly maintains a patch set at SDS in addition to patched libVA packages while the changes await upstream integration.

To use Beauchesne's bridge work for an NVIDA card a user would need to install his patched libVA library, the vdpau-video package that links VA API calls to VDPAU API calls, and a video driver that implements VDPAU. Thus far, only the binary nvidia driver from NVIDIA implements VDPAU, not the free nv driver from X.org. Similarly, an ATI user would need the patched libVA, the xvba-video bridging package, and a Radeon driver that implements XvBA — currently only the closed source fglrx.

In February of 2009, S3 Graphics released its first VA API-compatible driver, for the Chrome 400 and Chrome 500.

Application support

Regardless of the chipset or driver used, it is impossible to see the benefits of VA API if the application does not support it. Fortunately, open source video projects are beginning to take a look. "Official" support is currently limited; RealPlayer for Mobile Devices is designed for Poulsbo-based hardware, and thus to take advantage of VA API through libVA and the psb-video driver. Likewise, closed source codec vendor Fluendo makes specialized builds of its GStreamer codecs for Poulsbo devices that will use VA API. Users with NVIDIA or ATI GPUs would not gain hardware acceleration with either product because neither uses the patched version of libVA compatible with the VDPAU and XvBA back-ends.

Fortunately, Beauchesne provides patched versions of MPlayer and FFmpeg, making this the simplest way to experience hardware acceleration on desktop Linux systems. Build notes are included. The VA API-accelerated MPlayer will work with any back-end: VDPAU for NVIDIA, XvBA for ATI, or native Poulsbo drivers for Intel. Beauchesne has sent his patches upstream, but it is not yet clear when MPlayer or FFmpeg will include VA API in official releases.

VLC has added VA API support in its development branch, and a patch is available through the developers' mailing list that adds support to current releases. MythTV can be patched to support VDPAU, but thus far there has been no work on supporting VA API. It is possible, however, to set up MythTV to use MPlayer as a video playback engine, so it would be possible to leverage Beauchesne's patched version of MPlayer that way.

Benchmarks comparing VA API-accelerated decoding to CPU-based decoding are available from several sources. Beauchesne has run multiple comparisons on different systems: Opteron, Phenom, and Atom processors, and NVIDIA, ATI, and Intel GPUs, all using MPlayer. Jean-Baptiste Kempf has run real-world tests on the VA API-enabled version of VLC. The difference in CPU utilization can be dramatic; the CPU has little to do other than pass the compressed bits to the GPU. Beauchesne's numbers report CPU utilization between 66.3 and 98.4 percent for unaccelerated video playback, and as low as 0.6 percent with VA API acceleration.

Beauchesne said he hopes to see more applications take an interest in VA API, noting that the average desktop user only benefits from it when the players adopt it. He added that he had tried to add VA API support to the open source Flash decoder Gnash, but eventually abandoned the effort because the peculiarities of the Flash format (such as requiring all pixels to be converted to RGB24) sapped away most of the gains of hardware acceleration.

Future work

On the specification side, Bian echoed Beauchesne's sentiment, hoping that more developers would take an interest in contributing to the work. "Many aspects of the API could benefit from video application developer inputs ... as the app developers are ultimately the consumers of the API." Beauchesne's patches are an example of that, he said. Yuan added that moving the libVA code to Freedesktop.org's public Git repository should streamline the process for integrating contributions from outside Intel.

Video encoding is new to the specification, but has not been tested in the wild; that is expected to happen when Intel releases its Moorestown mobile platform late in 2009. Bian indicated that more video post-processing filters may make it into the next revision, and Beauchesne added that he would like VA API to support rendering directly to an OpenGL texture, as this would allow it to work with Clutter.

The bigger news is that Intel plans to launch a VA API-supporting driver for additional graphics chips. According to Bian and Yuan, the G45 chipset is next. G45 is a Core 2 chipset introduced in 2008, and already found in a variety of products, including desktop motherboards.

Still, at the moment the only "native" VA API video drivers are Intel's Poulsbo driver and S3's Chrome driver, neither of which is open source. Although Beauchesne's bridge code for VDPAU and XvBA is open source, both rely on the binaries drivers provided by NVIDIA and ATI to implement VDPAU and XvBA, respectively.

The open source RadeonHD and Nouveau drivers are not pursuing hardware video acceleration, through VDPAU, XvBA, or VA API. Gallium3D is another possibility for purely open source drivers, although developer Younes Manton said that VDPAU was the current focus of his attention.

Searching through the mailing lists, IRC logs, and discussion forums of Linux video applications reveals that a "wait and see" attitude was taken by most projects during the first year or so of VA API development. Some of that is, no doubt, caution that would be taken towards any entirely new API; perhaps some of it is attributable to the perception that VA API was an Intel-only project or at best fated to duke it out against VDPAU and XvBA until one of them becomes dominant. VA API is the only hardware video acceleration standard open to all vendors and with the advent of bridging code for NVIDIA and ATI it is finally possible to see its effects on desktop systems. Hopefully that bodes well for its continued development as a standard.

Comments (10 posted)

System Applications

Database Software

Firebird 2.1.3 RC 1 is available

Version 2.1.3 release candidate 1 of the Firebird DBMS has been announced. "This is the first release candidate of the Firebird version 2.1.3 patch release. It is a BETA whose purpose is for FIELD TESTING. It is recommended that you test it before deploying it into production."

Comments (none posted)

MySQL Community Server 5.1.36 has been released

Version 5.1.36 of MySQL Community Server has been announced. "MySQL 5.1.36 is recommended for use on production systems."

Full Story (comments: none)

MySQL Server 5.4.1-beta released

Version 5.4.1-beta of MySQL Server has been announced. "Bear in mind that this is a beta release, and as with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. For production level systems using 5.1, we would like to direct your attention to the product description of MySQL Enterprise".

Full Story (comments: none)

PostgreSQL 8.4 released

The long-awaited PostgreSQL 8.4 release is available. "This release contains an abundance of enhancements to make administering, querying, and programming of PostgreSQL databases easier than ever before. With 293 new or improved features in version 8.4, there are even more reasons to choose PostgreSQL for your next project." See the announcement (click below) for a list of the most interesting new features.

Full Story (comments: 22)

PostgreSQL Weekly News

The June 28, 2009 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.

Full Story (comments: none)

Web Site Development

Nagare 0.2.0 released

Version 0.2.0 of Nagare, a components and continuation-based web framework, is out. "Nagare is a components based framework: a Nagare application is a composition of interacting components each one with its own state and workflow kept on the server. Each component can have one or several views that are composed to generate the final web page. This enables the developers to reuse or write highly reusable components easily and quickly."

Full Story (comments: none)

Desktop Applications

Audio Applications

Ardour project status

There are a few new project status reports from the Ardour multi-track audio recorder project. First, Goings-on (3.0 and 2.X): "There hasn't been a lot to report around here recently, but thats not because nothing is happening. Instead, a furious slew of changes have been under development for 3.0, including some really fantastic new designs to aid workflow in many different situations. Carl Hetherington has been working at a furious pace and has not only fixed a lot of small bugs in both 3.0 and 2.X, but has radically overhauled the handling of preferences, and changed the basic design of edit/mix groups to provide a much more flexible, simple and convenient system. Meanwhile, I (Paul) have been busy completely altering the design of Ardour's internal signal flow to allow several things that we've wanted to implement for a long time." The project also needs more funding, see the Financial Support Issues note for details.

Comments (none posted)

Desktop Environments

GNOME Software Announcements

The following new GNOME software has been announced this week:

• Cheese 2.26.3 (documentation and translation work)
• GCalctool 5.26.3(documentation and translation work)
• Glade 3.6.7 (new features and bug fixes)
• GLib 2.20.4 (bug fixes and translation work)
• gnome-applets-2.26.3 (bug fix and translation work)
• GNOME Commander 1.2.8 (new features and bug fixes)
• gnome-control-center 2.27.3 (new features, bug fixes and translation work)
• Gnome Games 2.26.3 (bug fixes and translation work)
• gnome-keyring 2.26.3 (bug fixes and translation work)
• gnome-mag 0.15.7 (bug fixes and translation work)
• Gnumeric 1.9.9 (new features)
• GTK+ 2.16.3 (bug fixes and translation work)
• libxklavier 4.0 (API/ABI changes)
• Mistelix 0.21 (bug fixes and translation work)
• mousetweaks 2.26.3 (bug fixes and translation work)
• Orca 2.26.3 (bug fixes and translation work)
• Transmageddon 0.11 (unspecified)
• Vala 0.7.4 (new features and bug fixes)

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

Comments (none posted)

The first KDE 4.3.0 release candidate

The first KDE 4.3.0 release candidate is out. "KDE 4.3 focuses on polishing and completing the user experience by providing a modern and beautiful Free working environment. Compared to the Beta releases, this release candidate now contains the new Air theme, which will be the default for KDE 4.3.0. Air is a theme lighter than Oxygen, which is still available as an option through the 'Desktop Settings' dialog." See the full announcement for a summary of features in KDE 4.3.

Full Story (comments: 20)

KDE Software Announcements

The following new KDE software has been announced this week:

• ATI Overclocking Utility X32 1.0.1 (bug fix)
• ATI Overclocking Utility X64 1.0.1 (bug fix)
• Audex 0.71b5 (bug fix and translation work)
• Bilbo Blogger 0.9.95 (new features)
• cb2Bib 1.3.1 (new feature and bug fixes)
• CuteCom 0.22.0 (new features and documentation work)
• Dikt 1g (unspecified)
• FlashQard 0.12.0 (new features, bug fixes and translation work)
• gambas 2 2.14 (unspecified)
• KBackup 0.6.1 (new feature, KDE 4.2 support)
• Kmenu 0.1 (initial release)
• KMidimon 0.7.0 (new features, documentation and translation work)
• Kwave 0.8.3 (new features and bug fixes)
• MySQLoader 0.2.0 (unspecified)
• PokerTH 0.7.1 (new features and bug fixes)
• QTrans 0.2.1.10 (new features)
• Qwit 0.9 (new features and bug fixes)
• Russian ID3 tags converter 0.1 (initial release)
• Simutrans Starter 2 1.99.4 (new features and bug fixes)
• SixA 0.3 (new features)
• Social Networks Visualizer 0.6.0 (new features and bug fixes)
• TaskbarSwitch 1.0 (unspecified)

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

Comments (none posted)

Xorg Software Announcements

The following new Xorg software has been announced this week:

• pixman 0.15.14 (new features and code cleanup)
• xorg-server 1.6.1.902 (new features, bug fixes and code cleanup)

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

Comments (none posted)

Music Applications

gdigi 0.1.8 released

Version 0.1.8 of gdigi has been announced. "Control your Digitech effect pedal under Linux! gdigi is tool aimed to provide X-Edit functionality to Linux users Supported devices (list misses your DigiTech device? Please get in touch!): * RP250 * RP500 * GNX3000 * GNX4K"

Comments (none posted)

guitarix 0.04.6-1 released

Version 0.04.6-1 of guitarix, a simple Linux Rock Guitar amplifier, has been announced. "Release 0.04.6-1 comes with some major changes: * Build environment and source code changes: - use of the python based waf build system. - use of the boost library for command line options. - various code cleanups and source tree restructuring All this has been done by our new project member James Warden."

Full Story (comments: none)

SuperCollider 3.3.1 released

Version 3.3.1 of SuperCollider has been announced. "SuperCollider is an environment and programming language for real time audio synthesis and algorithmic composition. It provides an interpreted object-oriented language which functions as a network client to a state of the art, realtime sound synthesis server. The new release, 3.3.1, includes various minor updates to 3.3 (the most signficant changes being for mac users)."

Full Story (comments: none)

Office Applications

SyncEvolution project update and 0.9 beta 2 release

Version 0.9 beta 2 of SyncEvolution has been announced. "While I was away on my family vacation, the SyncEvolution branch with the new GTK GUI and various other improvements was published as part of the Moblin 2.0 beta release. Since then we have added some minor fixes and improvements and later released the source as SyncEvolution 0.9 beta 2. Several developers are working on it now, so 0.9 is fairly close to being released. The design for the next big step, direct synchronization with mobile devices via a "personal" SyncML server, is already vailable for discussion."

Full Story (comments: none)

Web Browsers

Firefox 3.5 is now available

Mozilla has announced the release of Firefox 3.5. "Firefox 3.5 has been under development for the past year, contains many new exciting features for users and web developers, and is our fastest Firefox release ever."

Full Story (comments: 10)

Languages and Tools

C++

Phase 1 of gcc-in-cxx now complete

Ian Lance Taylor has announced the completion of the first phase of the gcc-in-cxx project. "I am pleased to report that if you configure gcc with --enable-build-with-cxx, which causes the core compiler to be built using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now completes. I would like to encourage people to try using --enable-build-with-cxx in other configuration--other bootstraps, cross-compilers--to see how well it works. Please let me know if you run into problems that you don't know how, or don't have time, to fix."

Full Story (comments: 5)

Caml

Caml Weekly News

The June 30, 2009 edition of the Caml Weekly News is out with new articles about the Caml language.

Full Story (comments: none)

PHP

PHP 5.3.0 released

Version 5.3.0 of PHP has been announced. "This release is a major improvement in the 5.X series, which includes a large number of new features and bug fixes. Some of the key new features include: namespaces, late static binding, closures, optional garbage collection for cyclic references, new extensions (like ext/phar, ext/intl and ext/fileinfo), over 140 bug fixes and much more."

Comments (1 posted)

Python

Modular toolkit for Data Processing 2.5 released

Version 2.5 of Modular toolkit for Data Processing has been announced. "MDP is a Python library of widely used data processing algorithms that can be combined according to a pipeline analogy to build more complex data processing software. The base of available algorithms includes, to name but the most common, Principal Component Analysis (PCA and NIPALS), several Independent Component Analysis algorithms (CuBICA, FastICA, TDSEP, JADE, and XSFA), Slow Feature Analysis, Restricted Boltzmann Machine, and Locally Linear Embedding."

Full Story (comments: none)

Python 3.1 released

Python 3.1 has been released. "Python 3.1 focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter." For more information on what else is in the release, see "What's New In Python 3.1".

Comments (none posted)

pycairo release 1.8.6 now available

Release 1.8.6 of Pycairo, a set of Python bindings for the multi-platform 2D graphics library cairo, is out with bug fixes and documentation work.

Full Story (comments: none)

timelib 0.2 released

Version 0.2 of timelib has been announced. "timelib is a short wrapper around php's internal timelib module. It currently only provides two functions for parsing textual date descriptions".

Full Story (comments: none)

Python-URL! - weekly Python news and links

The June 29, 2009 edition of the Python-URL! is online with a new collection of Python article links.

Full Story (comments: none)

Version Control

bzr 1.16.1 released

Version 1.16.1 of the bzr distributed version control system has been announced. "We discovered a couple of bugs in the 1.16 release that we simply had to fix now. As such..."

Full Story (comments: none)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

NetworkManager and ConnMan (Dan Williams' Blog)

Dan Williams discusses the advantages of NetworkManager over ofono and ConnMan on his blog. "Lately ofono and ConnMan have been in the news, and that’s sparked some discussion about how these two projects relate to NetworkManager. I’ve mostly just been ignoring that discussion and focusing on making NetworkManager better. But at some point the discussion needs to become informed and the facts need to be straightened out. So what makes NetworkManager great? ..." (Thanks to Paul Wise).

Comments (48 posted)

Digg, Dug, Buried: How Linux news disappears (ComputerWorld)

Steven J. Vaughan-Nichols suggests the possibility of conspiracy in the burial of pro-Linux stories on sites like Digg. "Like it or lump it, the major reason that determines whether any given online story will get read or not is how much play it gets on news link sharing sites and social networks like Digg, reddit, and StumbleUpon. Unlike earlier news sharing sites like Slashdot, these sites have no central editorial control. Instead, the stories that get prominent play on these sites is determined entirely by readers. That sounds like democracy in its most basic form, but in practice what it really means that stories can be buried from sight by abusive users with an ax to grind. I became aware of this because in the last few weeks I've had several stories that were pro-Linux and anti-Microsoft-Linux, it doesn't get any faster and Macs, Windows 7, and Linux--first became popular on Digg, and, an hour later they were buried."

Comments (31 posted)

Trade Shows and Conferences

Group pitches Linux for free netbooks from mobile carriers (NetworkWorld)

NetworkWorld covers a talk by Jim Zemlin. "The move by carriers to sell netbooks at a discount and seek revenue from later application downloads is an opportunity for Linux, Jim Zemlin, executive director of the Linux Foundation, said at a Beijing forum. He urged Chinese and global companies to consider offering devices and download stores based on Linux."

Comments (3 posted)

Companies

Nvidia to Android: We're Just Not That Into You (TechNewsWorld)

TechNewsWorld summarizes a number of blog posts about Nvidia's choice of Windows CE over Android for its smartbook line. "A collective "aargh" resonated throughout the Linux blogosphere in response to Nvidia's dissing of Android in favor of Windows CE for running smartbooks. It really should come as no surprise, suggests blogger Gerhard Mack: "[Nvidia] is a company that got dragged kicking and screaming into the open source world, and they really don't want to be here.""

Comments (4 posted)

Linux Adoption

Berlin art colleges switch to Linux (heise online)

heise online has a brief report that Berlin art colleges are switching to Linux. "Berlin's art colleges are completely switching over to Linux. Most of the productivity software on the workstations has already been swapped for free alternative products as part of a project that started over eighteen months ago. The IT team at ServiceCenter-IT, responsible for the migration at three colleges; the Hanns Eisler music college, the Ernst Busch drama college and the Berlin-Weissensee art college, is hoping for an easy migration, as users will be able to keep on working with their familiar applications. Starting in June, their workstation PCs will switch to Ubuntu Linux and their servers will use Debian."

Comments (5 posted)

Reviews

Book Reviews: A Practical Guide to Ubuntu Linux 2nd ed. (Slashdot)

Slashdot reviews Mark Sobell's book A Practical Guide to Ubuntu Linux, 2nd edition. "Let's kick things off with a rough diff on the two editions. There have been improvements made in content and some added tools to rapidly get at what one needs. With the size of the book and the amount covered, these rapid access improvements are significant. The inside of the cover on the second edition has a utility index, so that a reader searching for help with any specific utility can find it quickly. This is followed up with two tables of contents, one a brief summary and the second much more detailed and taking up twenty-two pages."

Comments (none posted)

Ksplice Boots the Reboot (Linux Journal)

Linux Journal looks at Ksplice. "If you happen to be in Berlin or Porto Alegre, Brazil this week, you can learn about the company's offerings first hand — Ksplice President Jeff Arnold and company COO Waseem Daher will present at both LinuxTag 2009 and Fórum Internacional de Software Livre this week. Coinciding with their presentations is the release of a free "demonstration" version of Ksplice Uptrack for consumers using Linux."

Comments (11 posted)

Computer Logic Design with KTechLab (Linux Journal)

Mike Diehl reviews ktechlab in a Linux Journal article. "A couple of weeks ago, I wrote an article about a digital and analog circuit simulator called ksimus. One of my readers asked what the difference was between ksimus and ktechlab so I thought I'd take a look at ktechlab. Let me just say that both of these programs are a lot of fun to play with. My first impression of ktechlab was that it has a much richer assortment of components from which to build circuits. Unlike ksimus, ktechlab includes an addressable memory as well as DAC's, ADC's and even a PIC micro-controller!"

Comments (none posted)

Shuttle XS29f: Linux Looks Great in Green (LinuxPlanet)

LinuxPlanet reviews the Shuttle XS29f, a low power miniature desktop machine, unfortunately it is not available in the US. "At the heart of the Shuttle XS29f is the Nano, Via's first 64-bit processor in their x86 line. The Nano delivers high-end performance with low power requirements. Two memory slots support up to 4 GB of memory to go along with the Via 1.3 GHz Nano processor. It uses DDR2 memory, which is pretty inexpensive right now. Two internal SATA-II connectors support internal storage."

Comments (45 posted)

Sugar on a Stick brings sweet taste of Linux to classrooms (Ars Technica)

Ryan Paul reviews Sugar on a Stick. "The official release of Sugar on a Stick (SoaS) is a significant milestone for the Sugar project. In this release, the platform exhibits a much higher level of refinement and maturity than the previous versions, which were shipped on OLPC's XO laptops. The user interface is smoother, the individual components seem better integrated, and many impressive new programs that have been added."

Comments (1 posted)

Miscellaneous

Could There Be an AndroidFox? (Linux Journal)

Linux Journal speculates that future Android devices may run Mozilla's mobile Firefox, Fennec. "Android or not, Fennec development is moving forward. Two new builds were released on Friday: a second beta for the Maemo platform, and a second alpha for Windows Mobile. Developers report that the browser's user interface has been heavily improved, and gains have been made in both performance and responsiveness. Changes to the add-on system and download manager have also been incorporated. Windows, Mac, and Linux desktop builds are also available."

Comments (none posted)

LXDE: one of the largest open-source teams in the world

Mario Behling discusses the size of the desktop environment development teams in a blog post, LXDE has 26 developers. "I believe everyone in the LXDE team still considers the project as a rather small project with a small team. There have been many changes and advances, but I would have never guessed that LXDE is one of the big projects. If we see it in regards to Gnome and KDE, the relations become different though. Gnome has 432 developers according to Ohloh and KDE even 482 code contributors. XFCE shows up with 12 coders during the last twelve months."

Comments (1 posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

GNOME Board of Directors Foundation Elections preliminary results

The preliminary results from the spring 2009 GNOME Board of Directors Foundation Elections have been announced. "If the results are not challenged, then the elected directors will be: Behdad Esfahbod Brian Cameron Diego Escalante Urrelo Germán Póo-Caamaño Lucas Rocha Srinivasa Ragavan Vincent Untz".

Full Story (comments: none)

New Books

Complete Web Monitoring - New from O'Reilly

O'Reilly has published the book Complete Web Monitoring by Alistair Croll and Sean Power.

Full Story (comments: none)

Even Faster Web Sites - New from O'Reilly

O'Reilly has published the book Even Faster Web Sites by Steve Souders.

Full Story (comments: none)

The Myths of Security - New from O'Reilly

O'Reilly has published the book The Myths of Security by John Viega.

Full Story (comments: none)

Natural Language Processing with Python - New from O'Reilly

O'Reilly has published the book Natural Language Processing with Python by Steven Bird, Ewan Klein, and Edward Loper.

Full Story (comments: none)

Ruby Best Practices - New from O'Reilly

O'Reilly has published the book Ruby Best Practices by Gregory Brown.

Full Story (comments: none)

Resources

Open Database License v1.0

Version 1.0 of the Open Database License is now official. This is the license that the OpenStreetMap project proposes to move to; the current plan envisions a vote being held almost right away, followed by a 2-3 month transition.

Comments (7 posted)

Calls for Presentations

Linux.conf.au 2010 call for papers is now open

The call for papers for linux.conf.au 2010 is now open. The conference will be held in Wellington, New Zealand, January 18-23, 2010. "linux.conf.au isn't just a Linux conference. It is a technical conference about Free and Open Source Software, held annually in Australasia since 2001 - covering everything from the Linux Kernel and the BSDs to OpenOffice.org, from networking to audio-visual magic, from hardware hacks to Creative Commons."

Comments (1 posted)

PostgreSQL Conference West 2009 Call for Papers

A call for papers has gone out for the PostgreSQL Conference West 2009. "The PostgreSQL Conference U.S. team is pleased to announce the West 2009 venue and call for papers. This year the premiere West Coast PostgreSQL Conference will be leaving its roots at Portland State University and moving north to sunny Seattle, Washington. The event this year is being held at Seattle Central Community College from October 16th through 18th."

Full Story (comments: none)

Upcoming Events

LinuxCon detailed schedule and program announced

The schedule and program for LinuxCon has been announced, the event will take place in Portland, OR on September 21-23, 2009. "LinuxCon is the new annual technical conference that will provide an unmatched collaboration and education space for all matters Linux, bringing together the best technical talent, decision makers and industry experts in the Linux community."

Full Story (comments: none)

Ohio Linux Fest - Back to the Future of Linux! (LXer)

LXer looks forward to the Ohio Linux Fest. "The Ohio Linux community continues its forward march and is gaining momentum every year. Each year brings a new group of speakers and generates more excitement-2009 will be no exception! The seventh annual Ohio LinuxFest will be on September 25-26, 2009 at the Greater Columbus Convention Center, in downtown Columbus, Ohio."

Comments (none posted)

pyArkansas 2009 announced

pyArkansas 2009 has been announced. "pyArkansas 2009 is set for Saturday, November 14 and is once again being hosted by our friends in the Computer Science Department at the University of Central Arkansas. This year we are planning classes GIS, Image Processing using Jython, Introduction to Python and Django. More details will be announced as we continue, but I wanted to get the date announced to the community."

Full Story (comments: none)

Announcing the SciPy 2009 student sponsorship

student sponsorship is available for SciPy 2009. "I am pleased to announce that the Python Software Foundation is sponsoring 10 students' travel, registration, and accommodation for the SciPy 2009 conference (Aug. 18-23). The focus of the conference is both on scientific libraries and tools developed with Python and on scientific or engineering achievements using Python."

Full Story (comments: none)

Events: July 9, 2009 to September 7, 2009

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

Date(s)	Event	Location
July 3 July 11	Gran Canaria Desktop Summit (GUADEC/Akademy)	Gran Canaria, Spain
July 6 July 10	Python African Tour : Sénégal	Dakar, Sénégal
July 7 July 11	Libre Software Meeting	Nantes, France
July 13 July 17	(Montreal) Linux Symposium	Montreal, Canada
July 15 July 16	NIT Agartala FOSS and GNU/Linux fest	Agartala, India
July 15 July 17	Kernel Conference Australia 2009	Brisbane, Queensland, Australia
July 18 July 19	Community Leadership Summit	San Jose, CA, USA
July 19	pgDay San Jose	San Jose, CA, USA
July 19 July 20	Open Video Conference	New York City, USA
July 20 July 24	2009 O'Reilly Open Source Convention	San Jose, CA, USA
July 24 July 30	DebConf 2009	Cáceres, Extremadura, Spain
July 25 July 26	EuroSciPy 2009	Leipzig, Germany
July 25 July 26	PyOhio 2009	Columbus, OH, USA
July 25 July 30	Black Hat Briefings and Training	Las Vegas, NV, USA
July 26 July 27	InsideMobile	San Jose, CA, USA
July 31 August 2	FOSS in Healthcare unconference	Houston, TX, USA
August 3 August 5	YAPC::EU::2009	Lisbon, Portugal
August 7	August Penguin 2009	Weizmann Institute, Israel
August 7 August 9	UKUUG Summer 2009 Conference	Birmingham, UK
August 10 August 14	USENIX Security Symposium	Montreal, Quebec, Canada
August 11	FOSS Dev Camp - Open Source World	San Francisco, CA, USA
August 11 August 13	Flash Memory Summit	Santa Clara, CA, USA
August 12 August 13	OpenSource World Conference and Expo	San Francisco, CA, USA
August 12 August 13	Military Open Source Software	Atlanta, Georgia, USA
August 13 August 16	Hacking At Random 2009	Vierhouten, The Netherlands
August 18 August 23	2009 Python in Science Conference	Pasadena, CA, USA
August 22 August 23	Free and Open Source Conference (FrOSCon)	St. Augustin, Germany
August 22 August 23	OpenSQL Camp	St. Augustin, Germany
August 31 September 4	Ubuntu Developer Week	Internet, Internet
September 1 September 4	JBoss World Chicago	Chicago, IL, USA
September 1 September 4	Red Hat Summit Chicago	Chicago, IL, USA
September 1 September 5	DrupalCon	Paris, France
September 4 September 5	PyCon 2009 Argentina	Buenos Aires, Argentina

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

Audio and Video programs

O'Reilly Webcast: Managing and Growing Open Source in the Enterprise

O'Reilly will hold a webcast on July 7: "Managing & Growing Open Source in the Enterprise: Advice from the Trenches Presented by Carol J. Rizzo and Rod Cope. What are the key elements essential to maintaining effective policies and growing open source usage safely in medium to large enterprises? In this webcast, Carol Rizzo, past CTO of Kaiser Permanente, AIG and CitiGroup, and Rod Cope, the founder and CTO of OpenLogic share their experiences and insights about using open source in the enterprise. This includes creating an effective enterprise open source software governance program that includes strategy, policy, inventory, approvals, and auditing, with plenty of time for q&a."

Full Story (comments: none)

Page editor: Forrest Cook