LWN.net Weekly Edition for March 5, 2009

How (not) to run a developer program

The Android developer phone (ADP1) is a nice piece of hardware which allows freedoms that the T-Mobile standard-issue G1 does not allow. As the name might imply, it is targeted at developers so that they can more easily develop applications for the Android Market, but also so that they can hack on the Android platform itself. So far, though, the Android development community has been less-than-satisfied with the development support provided by Google. In fact, the recent decision to disallow access to copy-protected applications in the Android Market has a lot of ADP1 purchasers up in arms. But that isn't the only thing that has annoyed—or worse—Android hackers.

The idea behind a developer program is, or should be, that developers get early access to the code that customers will soon be running, so that they can test their applications—finding and fixing bugs before the general public ever sees them. For whatever reason—manpower is the oft-stated problem—Google has turned this on its head. Customers who purchase the consumer version (i.e. G1), will get the RC33 version (in the US, European version numbering is different) of the firmware. The G1 phones ship with an earlier version, but an over-the-air upgrade will eventually bring them up to that version. For developers who purchased an ADP1, however, there is no equivalent upgrade, at least officially.

There has been a fair amount of complaining about the lack of an ADP1 upgrade on the android-developers mailing list. Jean-Baptiste Queru, who seems to be the Android engineer who was selected or volunteered to answer questions on the list, is unhappy about the delay—and lack of information—as well:

The 1.1 firmware release for the ADP1 is supposed to have more-or-less equivalent functionality to the RC33 release for the G1. But what, exactly, that release will contain is still a closely-held secret. That seems to be one of the biggest complaints about how Google is treating Android developers: lack of information. The problem with copy-protected applications for the ADP1 is just another example.

Android offers application developers two restrictions that they can apply to their programs in the Android Market: for-sale and copy-protection. It is believed that most for-sale applications will also carry the copy-protection restriction, but that is not required. Gratis applications can also be copy-protected if the developer wishes to do so.

The ADP 1.0 code does not allow access to either kind of application in the Market. ADP 1.1 is believed to relax that restriction to only those that specify copy-protection, though that may not be much different in practice. The reasoning, according to Queru, is that "copy-protected apps aren't offered on devices where the copy-protection is known to be ineffective." Because the ADP1 phones are unlocked, there are various ways that the copy protection could be overridden.

The fear seems to be that developers might pay for an application, then squirrel it away and apply for a refund. Developers could restore the deleted application after receiving the refund or copy it to other phones. While that is a possibility, it leaves some feeling like developers are being singled out as pirates. One of the problems is that folks who have gotten root access on their G1 phones can access copy-protected applications. In the end, folks who want to pirate applications—be they developers or consumers—will find a way to do it.

It is a time-honored tradition amongst software developers to check out the competition. Many of the hobbyist developers hoping to strike it rich with Android Market applications purchased the ADP1 in the belief that it would have the same functionality that the consumer version does. Now they have found out that they can't purchase competitor's applications (at least in the likely case that they are copy-protected), on top of the realization that they can't get a blessed version of the latest code. Other ADP1 purchasers were looking to get around the geographic and/or cellular carrier restrictions of the G1, but now have a phone with fewer capabilities.

There are alternative firmware loads for the ADP1, but it doesn't sit well that Google has yet to provide one. A somewhat popular alternative is to use the so-called "holiday" version—the version that shipped on the ADP1s that Google gave its employees as a holiday bonus. Interestingly, that code does not allow accessing copy-protected Market applications either, which makes it likely that the restriction is simply an attempt to be consistent about copy protection, as Queru stated, rather than a real belief that developers are more likely to be pirates.

Google could have avoided much of the outcry by being more transparent—something the company seems to have a general problem with—and by paying more attention to its developer program. The official developers blog does not seem to cover many of the areas that are of concern to the community. One must wander through the mailing list or third-party sites to find information about the restriction on copy-protected applications, for example.

There are alternative mechanisms for handling copy protection, of course. Several were bandied about on the mailing list as the "forward locking" scheme—essentially signing the application in such a way that it won't run on other phones—is seen as suboptimal. The alternatives are other forms of DRM, however, as Queru points out:

Developers just want a phone that can do what they need it to, so some are starting to feel like they made a bad decision by purchasing the ADP1. That has led to suggestions that folks should just sell their ADP1 and use the emulator or a G1 phone to do their development. That may be a bit of an extreme reaction, but there are probably some who have done that or are considering it. A bigger worry for Google might be that they decide to ditch the Android platform entirely for something more developer-friendly.

Some have portrayed Android as the future of the Linux desktop—on phones and netbooks at least—but the problems that are currently being experienced on phones could well spill over. DRM and locking devices to particular vendors are not "features" that people normally associate with Linux and free software, but they are being demanded by some vendors. Those kinds of restrictions are really meant to keep consumers from reaping the benefits of freedom. While folks may be used to that treatment from mobile phones, one hopes they don't have to get used to it from their computers as well.

Comments (22 posted)

Third time is the charm?

The patents which TomTom is alleged to be infringing are:

• 6,175,789 (Vehicle computer system with open platform). This patent, filed in 1999, covers the innovative concept of mounting a computer in a vehicle dashboard. Literally, that is all there is to it.

• 6,202,008 (Vehicle computer system with wireless internet, 1999). This one extends the previous patent by adding an Internet connection to the dashboard-mounted computer.

• 7,054,745 (Method and system for generating driving directions, 2003), appears to cover the basic turn-by-turn instructions provided by just about any navigation unit on the market.

• 6,704,032 (Methods and Arrangements for Interacting with Controllable Objects within a Graphical User Interface Environment Using Various Input Mechanisms, 2000). This patent is relatively impenetrable, but appears to cover a framework for binding responses to user interface events.

• 7,117,286 (Portable computing device-integrated appliance, 2005). The deep concept here appears to be recognizing a docking station and causing the user interface to configure itself accordingly.

• 5,579,517 (Common name space for long and short filenames, 1995) and 5,758,352 (Common name space for long and short filenames, 1996). These are the infamous patents on the long filename hacks embedded in the VFAT filesystem.

• 6,256,642 (Method and System for File System Management Using a Flash-Erasable, Programmable, Read-only Memory, 1992). This one covers a fairly straightforward mechanism for managing flash memory by dividing large erase blocks into filesystem-sized blocks and allocating them independently.

The first two patents in this list appear to be laughable indeed; it is hard to see how they can pass the obviousness test. This is especially true in light of the KSR v. Teleflex ruling, wherein it was decided (also in the automotive setting) that the idea of connecting a floor pedal to an electronic throttle control was too obvious to patent. The navigation patent would appear to be infringed by anybody who sits in the passenger seat and helps the driver find a destination. The docking station and GUI patents seem less clear, but it doesn't seem like it should be all that hard to find suitable prior art.

That leaves the final three patents, all of which are relevant to the Linux platform. Like almost every other system on the planet, Linux supports the VFAT filesystem, and, thus, could be argued to infringe upon the relevant patents. The flash patent looks much like the technique used by any system which manages flash memory in anything but the stupidest of ways. It would appear that Microsoft has finally decided to follow through on its longstanding patent threats against Linux.

Of course, not all agree. The 451 Group posted this fairly impressive apology for Microsoft, claiming:

Your editor wishes to politely dismiss this talk as dangerous nonsense. There is nothing special about TomTom's kernel with regard to these patents. One would think that it would make little sense for TomTom to go into the kernel source and create its own special version of VFAT which infringes on Microsoft's patents. Of course, embedded systems developers have been known to do some very strange things, so one cannot take TomTom's good sense for granted in this situation. So, for the definitive word, we will refer to Harald Welte's take on TomTom's kernel:

If TomTom is infringing Microsoft's patents, then everybody who is running Linux is infringing those patents. This is an attack against Linux; TomTom has just been given the honor of being the first defendant.

Microsoft's motivation would seem to be clear. The company has tried for years to sell versions of Windows into the embedded systems market, with success best described as "modest." Linux is hard to compete against in these systems; it is highly portable, can be customized to an arbitrary degree, offers support from multiple vendors, and can be shipped with no royalty charges. Microsoft would like to take away some of those advantages by imposing a patent tax on embedded Linux deployments. Embedded systems vendors cannot miss this message: they can pay licensing fees, or they can pay legal fees.

The obvious question at this point is: what now? The VFAT patents may appear to fail the obviousness test; they could also run into difficulties stemming from the Bilski decision. These patents are problematic, though: the Public Patent Foundation tried hard to invalidate these patents in 2004, only to have them reinstated by the US patent office in 2006. As a result, there will be a certain presumption of validity which could prove hard to overcome in court. It has often been said that attempts to invalidate patents carry risks; what doesn't kill a patent may well make it stronger.

Your editor would certainly not advise anybody to give up on efforts to defeat these patents, but the possibility that they could stand must be considered. The loss of the VFAT filesystem would be painful. It is a poor filesystem, but it has become a sort of de facto interchange format for storage-oriented devices. Without VFAT, Linux users would encounter difficulties working with their digital cameras, cellular telephones, and music players. Sharing storage devices with Windows systems would become harder. VFAT would become a technology like MP3: unavailable on many Linux systems until installed from some third-party repository on the net.

Avoiding this outcome seems desirable. One way would be to defeat these patents in court. To that end, one can only hope that TomTom will stand up to this attack and defend its rights. The rest of the industry would be well advised to consider helping TomTom in this fight. This case, if fought to its conclusion, will certainly be expensive. But the cost of not fighting it seems certain to be much higher.

Another way to deal with the VFAT patents would be to start a serious look for workarounds - a technique which the free software community does not, yet, make enough use of. Patents tend to be tightly written, meaning that workarounds are often possible with relatively small changes. It may well be possible to make changes to the VFAT filesystem which pass the patent-lawyer test while maintaining interoperability with other systems.

Indeed, a suitably clever lawyer might be able to argue that Linux already operates outside the patent; the claims require that the long filename include "more than the maximum number of characters that is permissible by the operating system," something which is clearly not the case on Linux. Your editor, however, is neither a lawyer nor suitably clever; this kind of determination will need to be made by others.

At the upcoming Linux Foundation Collaboration Summit, your editor will be running a panel on kernel development. Sam Ramji, alas, will be in the other room at that time, sitting on a panel entitled "Why Can't We All Just Get Along: Linux, Microsoft & Sun." One can imagine the course this discussion is going to take; Sun is likely to get off easy. Parts of Microsoft (especially those represented by Mr. Ramji) have been making friendly noises toward open source for some time. But actions speak louder than friendly noises, and this particular action speaks loudly indeed. Parts of Microsoft are almost certainly sincere about wanting to get along with the Linux community, but the stronger forces within the company, it seems, are not.

Comments (62 posted)

Ubuntu debates usability changes

Ever since last July, when Mark Shuttleworth called on Ubuntu to surpass Mac OS X in desktop design within two years, Ubuntu mailing lists and blogs have become one of the main places to go for detailed discussions about GNU/Linux usability. However, the discussions can become convoluted and acrimonious, as developers argue the logic of design principles. A case in point is the discussion of Ubuntu's new notification guidelines on the ubuntu-devel list over the past two weeks, which quickly turned into a discussion of whether notifications should be used at all.

The discussion centers around the new guidelines for notification messages, which typically appear by the notification tray in GNOME. These guidelines were announced in Mark Shuttleworth's blog entry for February 21. Both the blog and the guidelines include screen shots to illustrate what they are describing.

The problem is that the now-standard notification bubbles (so-called for their shape) are easily missed because they disappear after a few seconds, and they often point to icons in the system tray, which users may find hard to click. For these reasons, the guidelines call for a reduction in their use, although acknowledging the possibility that they might still be useful in unspecified circumstances.

Whenever possible, notification bubbles will, in the next Ubuntu release, be replaced with a notification in an existing window; for instance, when a web browser has blocked up a popup, the notification could display in a dialog above the web page, using the browser's built-in notification system. More radically, when a notification needs user input, but doesn't need an immediate response — for instance, when a printer is detected, but the necessary driver is missing — it will be displayed in an alert box that opens beside the system tray without taking the focus away from the user's current window.

In cases such as a low battery reading, when a quick response is needed, the window or alert box will display the basic message, followed by, when the user clicks it, a dialog, possibly with a different color background. The guidelines refer to this arrangement as "morphing," and suggest that it will help prevent the accidental selection of a button when the cursor moves to the dialog. Why accidental selection is perceived as a problem, though, is unspecified.

The advantages of the proposed alert boxes is that, unlike notification bubbles, they remain on the desktop, and provide dialogs that are easier to click than a system tray icon.

Discussion of these new guidelines quickly followed Shuttleworth's blog entry, wandering across several threads in ubuntu-devel in February and March. Some of the discussion called for citations to support a usability assertion, as when Jordan Mantha told Mat Tomaszewski of the Canonical design team, the group responsible for the guidelines, that "'trust us, we have our reasons' is not going to very convincing to many people."

As discussion continued, it soon became apparent that at least some Ubuntu designers outside Canonical distrust those employed by the company. For instance, Scott Kitterman remarked:

Similarly, Martin Owens complained that "It's as if the people at Canonical had taken a politics course and decided to deliberately alienate those people who are not inside of Canonical."

To such comments, Mat Tomaszewski replied several times, with patience and enthusiasm for the tasks at hand, while Matthew Paul Thomas, another Canonical employee, explained in a similar tone that usability efforts were just getting started, and were expensive enough that "much of the time we will have to rely on common sense".

At one point, the language became so heated that Mark Shuttleworth intervened to call one developer's comments "not constructive" — a rare occurrence on Ubuntu lists compared to those of some projects, due to the code of conduct by which developers agree to abide.

However, for the most part, discussion remained civil. Matthew Paul Thomas defended the new guidelines, pointing out that:

Thomas also summarized potential problems with notice bubbles: either they disappear after a few seconds and can disappear before users notice them, or else they persist and distract users. In addition, alerts and windows are easier to use than small, often indistinguishable icons.

By contrast, Lars Wirzenius presented a case against all notifications, saying flatly that:

All Wirzenius wanted was essential notifications, suggesting that "All applications should, in my opinion, strive to interrupt the user as little as possible, especially by default."

Wirzenius' position was soon challenged by other developers in ways that show some of the considerations necessary in usability design. Chow Loong Jin questioned Wirzenius' assertion that default settings should be designed for those who use their computer as a "tool" rather than a "toy," arguing that the tool users would know how to change the defaults while the toy users would not.

Similarly, Ted Gould contended that, since toy users are probably a majority, the defaults should be settings that they want. In the same post, he also suggests that:

However, Tomaszewski indicated that some ability to change levels of notifications would be available via a "Do not disturb" mode that would block at least some standard notifications.

What made this discussion especially interesting was how it brought out both the general and specific issues that arise in usability. For instance, Mathew Paul Thomas responded to the suggestion that using an application at full-screen size should disable notifications by pointing out that:

Thomas also warned that:

In much the same way, Tomaszewski stated:

Yet another post, this time by Bruce Cowan, summarized the problems with any sort of dialog. The sudden appearance of windows and alerts, Cowan suggested, is confusing, and could make users worry that a piece of malware has started an application. In addition, too many dialogs could frustrate users, to the point that some disable them altogether, so that over-use of the system could defeat the entire purpose of providing timely warnings. As for the changes in the new guidelines, Cowan suggested that they may annoy experienced users who see little wrong with notification bubbles.

Whether these discussions will have any effect on the Ubuntu Design or Desktop Experience Team seems uncertain, since the guidelines are already being used in alpha versions of the upcoming Jaunty release. All the same, they are the sort of discussions that Ubuntu developers are likely to be having for the next eighteen months as they try to realize Shuttleworth's goal of increased usability, especially in the absence of hard data to show what designs are most usable. They are likely, too, to have them again, as they attempt to have their changes accepted upstream by projects like GNOME. However, for others, they show the punctilious but necessary considerations that usability generally involve — considerations that many free and open source software projects are only just starting to face.

Comments (42 posted)

Page editor: Jonathan Corbet

Security

Reviving Python restricted mode

A sandbox (or restricted execution) environment for a programming language can be a useful feature to allow untrusted users access to much of the language while restricting the "dangerous" operations. Some languages, notably Java, were designed to support sandboxes from the outset. Others, like Python, have a variety of possible sandbox solutions, but the core language doesn't support that functionality. A movement is afoot to change that for Python by reviving "restricted mode".

Guido van Rossum raised the subject on the python-dev mailing list, which started a conversation about the requirements for such a mode. It turns out that the interested party, who goes by the name "Tav", would like to be able to run untrusted code within applications in Google's App Engine. In particular, he would like to be able to allow untrusted code to access additional functionality by way of closures. But, because of the introspection features of Python, a closure object could be used to circumvent any access restrictions.

The example Tav uses in his App Engine feature request is instructive:

    def _get_blog_posts(db, current_user):
        def get_blog_posts():
            """Return Blog posts by the current user."""
            return db.get('BlogPost').filter('user =', current_user)
        return get_blog_posts

    __builtins__['get_blog_posts'] =  _get_blog_posts(db, 'tav@espians.com')

So, at some level, Tav, van Rossum, and others are trying to create a restricted mode that limits the introspection so that untrusted code cannot access attributes that "leak" information from the trusted code. This is a fairly limited definition of a sandbox, as it relies on App Engine (or other, such as PyPy sandbox) safeguards to prevent things like system call access or problems caused by interpreter segmentation faults. For this exercise, those problems are explicitly defined away.

The real goal, as outlined in Tav's blog, is to be able to provide more expressive templating for users of App Engine applications:

In order to test his ideas about how to approach this problem, Tav issued a challenge to Python developers to break his restricted FileReader object such that one could write a file to the filesystem. It was only a few hours before a simple crack was posted, but, unlike other challenges of this sort, Tav seemed delighted, rather than defeated, by what was found. His environment essentially removed access to certain attributes that are normally associated with an object. In essence, the challenge was to find more attributes which needed to be added to his list.

A second version of the challenge was posted to his blog, along with a running tally of exploits that had been found and fixed. It is an interesting exercise that Python developers seem to be having fun with. The problem with the approach is that it relies on blacklists, as Victor Stinner, who also found the first exploit, points out. A whitelist approach is likely to be better; choosing which attributes are safe to use, rather than removing those that are found to be unsafe.

Tav has posted a patch to the Python core that implements his method into the language proper as suggested by van Rossum. Given that van Rossum, as Python lead and Google employee, is uniquely positioned to effect these changes, his promise to "give it serious consideration, both for inclusion in core Python and for App Engine" would seem to carry a lot of weight.

While it is not a complete solution to the sandboxing problem, Tav's work will help Python applications that already run in somewhat restricted environments. After all, from App Engine's perspective, all of the code that it gets is untrusted, so it must provide the safeguards against exploits of the underlying operating system by way of crashes or system calls. Tav's code would then allow App Engine user applications to run their own untrusted code.

This could be a solution for other programs that want to run untrusted Python code as well. The Battle for Wesnoth has support for AIs written in Python, but there have been some security concerns about users grabbing random, perhaps malicious, AI code. This change to the Python core, perhaps coupled with a PyPy sandbox might be enough to change Eric Raymond's recent pronouncement that Lua is the way forward instead of Python.

Comments (5 posted)

Brief items

Support for Red Hat Enterprise Linux 2.1 ends on May 31

Full Story (comments: 9)

New vulnerabilities

audacity: buffer overflow

Comments (none posted)

curl: information disclosure

Comments (none posted)

dkim-milter: denial of service, possible arbitrary code execution

Comments (none posted)

eID-belgium: improper certificate check

Comments (none posted)

eog: arbitrary code execution

Comments (none posted)

flash-plugin: multiple vulnerabilities

Comments (none posted)

kdepim: execution of arbitrary code

Comments (none posted)

kernel: signal handling vulnerability

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: denial of service

Comments (none posted)

mediawiki: cross-site scripting

Comments (none posted)

mldonkey: information disclosure

Comments (none posted)

NetworkManager: information disclosure

Comments (none posted)

network-manager-applet: privilege escalation

Comments (none posted)

optipng: user-after-free

Comments (none posted)

proftpd-dfsg: SQL injection vulnerability

Comments (none posted)

psi: denial of service

Comments (none posted)

rubygem-actionpack: HTTP response splitting

Comments (none posted)

wireshark: multiple vulnerabilities

Comments (none posted)

xchat: arbitrary code execution

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

There have been no stable 2.6 updates released over the last week.

Comments (none posted)

Kernel development news

Quotes of the week

+	/*
+	 * The pifutex has an owner, make sure it's us, if not complain
+	 * to userspace.
+	 * FIXME_LATER: handle this gracefully
+	 */
+	pid = curval & FUTEX_TID_MASK;
+	if (pid && pid != task_pid_vnr(current))
+		return -EMORON;

Comments (1 posted)

Making NetworkManager work with suspend/resume

Comments (36 posted)

Interrupts, threads, and lockdep

Things started when Andrew Morton questioned the following bit of code, found in the driver's interrupt handler:

    #ifdef CONFIG_LOCKDEP
	/* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
	 * we don't want and can't tolerate.  Although it might be
	 * friendlier not to borrow this thread context...
	 */
	local_irq_enable();
    #endif

Workarounds of this variety do tend to catch the attention of diligent reviewers. Understanding this one requires just a bit of background.

Back in the Good Old Days, the Linux kernel had "fast" and "slow" interrupt handlers; the main difference between the two is that "fast" handlers ran with further interrupts disabled, while "slow" handlers were run with interrupts enabled. Over time, the distinction between the two types has faded; faster, smarter hardware and greater use of software interrupts and tasklets have made the execution time of most well-written interrupt handlers essentially irrelevant. So most driver authors do not even think much about whether they are writing a "fast" or a "slow" handler, even though the distinction still exists. Unless a driver passes the IRQF_DISABLED flag when requesting its interrupt line, its interrupt handler will be called with interrupts enabled.

"Lockdep" is the kernel lock validator, which, when enabled, creates a detailed model of how locks are used in the kernel. This model can be used to find potential deadlocks and other problems. According to Ingo Molnar, lockdep has been quite effective:

It turns out, though, that the lockdep developers made one significant, simplifying assumption: all interrupt handlers were to be invoked with interrupts disabled. When lockdep is enabled, in fact, the generic interrupt handling layer forces this condition, regardless of whether any specific handler was registered with the IRQF_DISABLED flag. Lockdep has worked this way for some time, and complaints have been scarce. But, as can be seen from the patch cited above, "scarce" is not the same as "nonexistent."

Drivers for i2c-connected devices operate under a number of interesting constraints, mostly forced by the fact that the i2c "bus" is, in reality, a slow, two-wire serial interface. So even "fast" operations like reading a device register are, in fact, slow on i2c devices; they are slow enough that the process involved should sleep while waiting for the result. That is a bit of a problem for i2c interrupt handlers, since they need to access device registers, but they cannot sleep.

The result is that a number of i2c drivers have implemented what is, in effect, a threaded interrupt handler mechanism. The "real" interrupt handler simply masks the interrupt and wakes up the thread, which then does the real work of talking to the device. In the case of the twl4030 driver, this threaded implementation has been done in a relatively formal manner in which the device interrupt handlers are invoked - from within a special-purpose kernel thread - by way of the generic IRQ layer itself. These threaded handlers do not expect to run with interrupts disabled - indeed, they cannot run that way - but the generic IRQ code will, when lockdep is enabled, turn off interrupts anyway. That is why this patch takes pains to turn them back on when lockdep is being used.

Peter Zijlstra's response to this discussion was to post a patch forcing IRQF_DISABLED for all drivers. His position is that no interrupt handlers should be run with interrupts enabled. Doing so invites kernel stack overruns if too many nested interrupts come in; it also, he says, encourages the notion that it's OK for interrupt handlers to be slow. Additionally, he says, drivers must already be able to run their handlers with interrupts disabled, since another driver may disable interrupts on a shared interrupt line. So, he says, it makes no sense to "fix" lockdep for handlers which want interrupts to be enabled; instead, the always-disabled assumption built into lockdep should be made part of the system as a whole.

The response to this patch was somewhat sympathetic, at least in a general sense. Making IRQF_DISABLED be the default situation makes sense for most devices. But there really are drivers which need their interrupt handlers to run with interrupts enabled; IDE drivers using programmed I/O are one example. If those interrupt handlers are given exclusive control over the system, other devices will see unacceptable latencies and start to fail operations or drop data. So any change of this nature must be done carefully, and it must remain possible to run some handlers with interrupts enabled.

And, of course, forcing IRQF_DISABLED does nothing to fix the twl4030 problem.

The real solution is to have general support for threaded interrupt handlers. The realtime preemption tree has supported threaded handlers for quite some time; more recently, a variant of the threaded handlers patch was posted for mainline consideration. There are a lot of advantages to threaded handlers beyond their applicability to the problems discussed here; threaded handlers can improve latencies, allow interrupt handlers to be prioritized, and, someday, perhaps allow the removal of software interrupts altogether. So it seems like there would be value in getting this code merged.

To that end, Thomas Gleixner has come back with a new version of the threaded handlers patch. The API looks much like it did in the previous posting, though it could change in response to some review comments made this time around. In essence, this infrastructure allows a driver to register a "quick handler" to acknowledge (and mask) an interrupt; there would also be a regular handler which could be called in either hard interrupt or process context, depending on the quick handler's return value. The API allows drivers to continue to work unmodified, or they can be converted over to threaded handlers.

David Brownell, the leading critic of lockdep's behavior and the idea of disabling interrupts for all handlers, seems to agree that the threaded interrupt handler infrastructure should be able to solve the i2c problem. All threaded handlers will, by necessity, run with interrupts enabled, so the primary difficulty goes away. David would like to see some changes made to better support the chaining of handlers that is typically needed in such situations, but it's not clear how many changes are really needed.

In summary, threaded interrupt handlers seem likely to be the next technology to be merged from the realtime preemption tree. Just when that might happen remains to be seen, though. The request for some API changes may well slow things down a bit; there were also requests for example implementations of threaded handlers with more types of drivers. Satisfying those requests quickly enough to allow the code to be reviewed before the 2.6.30 merge window opens could be a bit of a challenge. So this code might just have to wait for one more development cycle; it would be surprising if it were to take longer than that, though.

Comments (3 posted)

Xen: finishing the job

In the mean time, KVM showed up and grabbed much of the attention. Its path into the mainline was almost blindingly fast, and many kernel developers were less than shy about expressing their preference for the KVM approach. More recently, Red Hat has made things more formal with its announcement of a "virtualization agenda" based on KVM. Meanwhile, lguest showed up as an easy introduction for those who want to play with virtualization code.

The Xen story is a classic example of the reasons behind the "upstream first" policy, which states that code should be merged into the mainline before being shipped to customers. Distributors rushed to ship Xen, then found themselves supporting out-of-tree code which, often, was not well supported by its creators. In particular, published releases of Xen often only supported relatively old kernels, creating lots of work for distributors wanting to ship something more current. Now at least some of those distributors are moving on to other solutions, and high-level kernel developers are questioning whether, at this point, it's worth merging the remaining Xen code at all.

All told, Xen looks to be on its last legs. Or, perhaps, the rumors of Xen's demise have been slightly exaggerated.

The code in the mainline implements the Xen "DomU" concept - an unprivileged domain with no access to the hardware. A full Xen implementation requires more than that, though; there is the user-space hypervisor (which is GPL-licensed) and the kernel-based "Dom0" code. Dom0 is the first domain started by the hypervisor; it is typically run with more privileges than any other Xen guest. The purpose of Dom0 is to carefully hand out privileges to other Xen domains, providing access to hardware, network interfaces, etc. as set by administrative policy. Actual implementations of Xen must include the Dom0 code - currently a large body of out-of-tree kernel code.

Jeremy Fitzhardinge would like to change that situation. So he has posted a core Xen Dom0 patch set with the goal of getting it merged into the 2.6.30 release. Among the review comments was this question from Andrew Morton:

The questions asked by Andrew were, essentially, (1) what code (beyond the current posting) is required to finish the job, and (2) is there really any reason to do that? The answer to the first question was "another 2-3 similarly sized series to get everything so that you can boot dom0 out of the box." Then there are various other bits which may not ever make it into the mainline. But, says Jeremy, getting the core into the mainline would shrink the out-of-tree patches carried by distributors and generally make life easier for everybody. For the second question, Jeremy responds:

Beyond that, Jeremy is arguing that Xen still has a reason to exist. Its design differs significantly from that of KVM in a number of ways; see this message for an excellent description of those differences. As a result, Xen is useful in different situations.

Some of the advantages claimed by Jeremy include:

• Xen's approach to page tables eliminates the need for shadow page tables or page table nesting in the guests; that, in turn, allows for significantly better performance for many workloads.

• The Xen hypervisor is lightweight, and can be run standalone; the KVM hypervisor is, instead, the Linux kernel. It seems that some vendors (HP and Dell are named) are shipping a Xen hypervisor in the firmware of many of their systems; that's the code behind the "instant on" feature, among other things.

• Xen's paravirtualization support allows it to work with hardware which does not support full virtualization. KVM, instead, needs hardware support.

• The separation between the hypervisor, Dom0, and DomU makes security validation easier. The separation between domains also allows for wild configurations with each device being driven by a separate domain; one might think of this kind of thing as a sort of heavyweight microkernel architecture.

KVM's advantages, instead, take the form of relative simplicity, ease of use, full access to contemporary kernel features, etc. By Jeremy's reasoning, there is a place for both systems in Linux.

The relative silence at the end of the discussion suggests that Jeremy has made his case fairly well. Mistakes may have been made in Xen's history, but it is a project which remains alive, and which has clear reasons to exist. Your editor predicts that the Dom0 code will find little opposition at the opening of the 2.6.30 merge window.

Comments (39 posted)

Speeding up ftrace printing

A kernel patch that reduces memory, while providing a performance increase of roughly a factor of three, is generally seen as a good thing. But, when there is another, more-or-less equivalent—but much faster—way to perform that action, it may appear to be an unnecessary optimization. A recent patch to the ftrace_printk() function has those characteristics, but the ability to get such a speed increase, even in something that is just convenient—rather than required—may well trump the concerns about the necessity.

Lai Jiangshan proposed adding a binary version of ftrace_printk() last December; Frederic Weisbecker has picked up the patches and submitted them for inclusion into ftrace. The basic idea is that rather than converting the arguments to strings—as specified in a printk()-style format string—ftrace_bprintk() would defer the actual conversion until the trace output is read by user space. Instead it would put the binary values into the ring buffer, along with a pointer to the format string. When the trace data is read from debugfs, the format string and binary data are used to construct the output.

Ingo Molnar liked the idea, but was unhappy with the implementation that duplicated much of the code in vsnprintf() into two new functions. He suggested that it should be possible to pull out the common code: "We should try _much_ harder at unifying these functions before giving up and duplicating them." Weisbecker agreed, which eventually resulted in a patch that breaks out the format string decoding as a separate function.

Molnar also asked for some performance numbers, which Weisbecker provided as part of his patch. He reported the memory and time difference when adding:

    ftrace_printk("This is the timer interrupt: %llu", jiffies_64);

    ftrace_printk:  duration average: 2044 ns, avg of bytes stored per entry: 39
    ftrace_bprintk: duration average: 1426 ns, avg of bytes stored per entry: 16

    ftrace_printk:  duration average: 8812 ns
    ftrace_bprintk: duration average: 2611 ns

Andrew Morton was a bit puzzled by the intent of the patch: "Trying to make something which is inherently slow run slightly faster seems...odd." But Molnar explained why it makes sense:

Breaking out the format string handling into its own format_decode() function was mostly met with approval, except that the argument list is rather ugly:

    int format_decode(const char *fmt, enum format_type *type, 
                      int *flags, int *field_width, int *base, 
                      int *precision, int *qualifier)

Torvalds also thought that the various helper functions to handle specific formats (i.e. number(), pointer(), string(), etc.) should get passed a struct printf_spec pointer as well. As he points out: "When cleaning up, let's just do it properly." Once again, Weisbecker was quick to agree; he plans to respin the patches addressing these and other comments in the near future.

In addition, because ftrace_bprintk() is a drop-in replacement for ftrace_printk(), Weisbecker proposes eliminating the current code in favor of the faster version. Molnar, at least, advocates that outcome:

While it is a minor upgrade to a relatively minor kernel subsystem, it does provide some impressive performance gains. As a bonus, the review process has resulted in some clean-up that was probably overdue. While there is validity to the argument that it is not really required, it is not very intrusive, nor very large. In the end, that is likely to be enough to see it eventually end up in the mainline.

Comments (none posted)

A summary of 2.6.29 internal API changes

• The massive task credentials patch set has been merged. This code reorganizes the handling of process credentials (user ID, capabilities, etc.). One of the immediate implications of this change is direct references to credential-oriented fields in the task structure need to be changed; for example, current->user->uid becomes current_uid(). See Documentation/credentials.txt for a description of the new API.

• The ftrace code has seen a lot of internal changes. The function tracing feature has seen a number of improvements, and the developers have added mechanisms to profile the behavior of if statements, provide function call graphs, obtain user-space stack traces, and follow CPU power-state transitions.

• Most of the callback functions/methods associated with the net_device structure have been moved out of that structure and into the new struct net_device_ops. In-tree drivers have been converted to the new API.

• The priv field has been removed from struct net_device; drivers should use netdev_priv() instead.

• The generic PHY layer now has power management support. To that end, two new methods - suspend() and resume() - have been added to struct phy_driver.

• The networking layer now supports large receive offload (or "generic receive offload") operation.

• The NAPI API has been cleaned up somewhat; in particular, functions like netif_rx_schedule(), netif_rx_schedule_prep(), and netif_rx_complete() have lost the unneeded struct net_device parameter.

• The poll() file operation is now allowed to sleep; see this article for more information on this change.

• The CPU mask mechanism, used to represent sets of processors in the system, is in the middle of being massively reworked. The problem is that CPU masks were often put on the stack, but, as the number of processors grows, the stack lacks room for the mask. The new API is designed to get these masks off the stack, and to guard against anybody ever trying to put one back. See this posting by Rusty Russell for details on this work.

• An infrastructure for asynchronous function calls has been merged. This code is still a work in progress, though, and, for 2.6.29, it will not be activated in the absence of the fastboot command-line parameter.

• The exclusive I/O memory allocation functions have been merged.

• There is a new synchronous hash interface called "shash." It simplifies the use of synchronous hash operations while allowing the same tfm to be used simultaneously in different threads. All in-tree users have been switched to the new API.

• The hrtimer code has been simplified with the removal of variable modes for callback functions. All processing is now done in hardirq context.

• A new set of LSM hooks has been added; these support pathname-based security operations. With the merging of these hooks, one major obstacle to the inclusion of security modules like AppArmor and TOMOYO has been removed.

• The kernel will now refuse to build with GCC 4.1.0 or 4.1.1; those versions have unfortunate bugs which prevent the building of a working kernel. Versions 3.0 and 3.1 have also been deemed to be too old and will not be supported in 2.6.29.

• Video4Linux drivers now use a separate v4l2_file_operations structure to hold their VFS-like callbacks. The prototypes of a number of these functions have been changed to remove the inode argument.

• Video4Linux2 has also acquired a new "subdevice" concept, meant to reflect the fact that video "devices" tend to be, in reality, a set of cooperating devices. See the new document for a description of how this mechanism works.

• Two new functions - stop_machine_create() and stop_machine_destroy() - allow the independent creation of the threads used by stop_machine(). That, in turn, lets those threads be created before trying to actually stop the machine, making that operation more resistant to failure.

• The exports for a number of SUNRPC functions have been changed to GPL-only.

• The internal MTD (memory technology device) API has seen significant changes aimed at supporting larger devices (those requiring 64-bit sizes).

Developers interested in the history of kernel API changes can look at the LWN 2.6 API changes page. After a period of unfortunate neglect, this page has been made current once again; your editor promises to be a bit more diligent about maintaining this page in the future.

Comments (2 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.29-rc7. (March 4, 2009)

Core kernel code

• Thomas Gleixner: [patch 0/4] genirq: add infrastructure for threaded interrupt handlers V2. (February 26, 2009)

• Thomas Gleixner: add rt_tgsigqueueinfo syscall [RESEND]. (February 27, 2009)

• Darren Hart: requeue pi implemenation. (March 3, 2009)

• Arun R Bharadwaj: timers: framework for migration between CPU. (March 4, 2009)

Development tools

• Tom Zanussi: zedtrace, a general-purpose binary tracer. (March 2, 2009)

• Subrata Modak: [ANNOUNCE] The Linux Test Project has been Released for FEBRUARY 2009. (March 2, 2009)

• Akinobu Mita: generic debug pagealloc. (March 3, 2009)

• Steven Rostedt: [RFC] binary reading of ftrace ring buffers. (March 4, 2009)

• Peter Zijlstra: tracing: lockdep tracepoints. (March 4, 2009)

• Paul Mackerras: perfcounters: provide expansion room in the ABI. (March 4, 2009)

Device drivers

• Maciej Sosnowski: I/OAT update. (February 26, 2009)

• Balaji Rao: spi: Add support for non-blocking synchronous transfers. (March 2, 2009)

• Rafael J. Wysocki: Rework disabling of interrupts during suspend-resume. (March 2, 2009)

• tom.leiming@gmail.com: driver core: implement uevent suppress in kobject(v1). (March 2, 2009)

• Felipe Balbi: input: misc: add twl4030-pwrbutton driver. (March 2, 2009)

• Mark Brown: Input: Accelerated touchscreen support for Marvell Zylonite. (March 2, 2009)

• Peter Zijlstra: irq: remove IRQF_DISABLED. (March 2, 2009)

• Daniel Mack: Added driver for ISL29003 ambient light sensor. (March 2, 2009)

• Abhijeet Joglekar: FCoE HBA Driver (fnic) for 2.6.30 feature window. (March 2, 2009)

• Dimitri Sivanich: [PATCH 0/6 v6] SGI RTC: add clocksource/clockevent driver and generic vector. (March 3, 2009)

• Jouni Malinen: ath9k: Virtual interfaces and radios. (March 3, 2009)

• Sakari Ailus: OMAP3 ISP and camera drivers. (March 3, 2009)

Filesystems and block I/O

• Nick Piggin: fsblock preview. (March 2, 2009)

• Theodore Ts'o: ext4: Track lifetime disk writes. (March 2, 2009)

• Theodore Ts'o: ext4: Add sysfs support. (March 2, 2009)

• Miklos Szeredi: delta filesystem prototype. (March 2, 2009)

• Daniel Phillips: Patch: Introduce ddlink interface to expose extended functionality. (March 2, 2009)

• Akira Fujita: mballoc: Add ioctls for new block allocation policy. (March 4, 2009)

• Christoph Hellwig: XFS status update for February 2009. (March 4, 2009)

Janitorial

• arnd@arndb.de: Use strict kernel types to fix the world. (February 26, 2009)

Memory management

• Nick Piggin: mm: new address space calls. (March 2, 2009)

• Nick Piggin: mm: page_mkwrite change prototype to match fault. (March 3, 2009)

• Nicolas Pitre: atomic highmem kmap page pinning. (March 4, 2009)

Networking

• Luis R. Rodriguez: cfg80211: send regulatory events to userspace. (March 2, 2009)

Security-related

• Serge E. Hallyn: keys: work correctly with user namespaces. (February 27, 2009)

Virtualization and containers

• Avi Kivity: KVM Updates for the 2.6.30 merge window (1/3). (February 27, 2009)

• Avi Kivity: KVM Updates for the 2.6.30 merge window (2/3). (February 27, 2009)

• Avi Kivity: KVM Updates for the 2.6.30 merge window (3/3). (March 2, 2009)

• Jeremy Fitzhardinge: xen: core dom0 support. (March 2, 2009)

• Jeremy Fitzhardinge: xen: dom0 apic programming hooks. (March 2, 2009)

Benchmarks and bugs

• Rafael J. Wysocki: 2.6.29-rc6-git7: Reported regressions from 2.6.28. (March 4, 2009)

• Rafael J. Wysocki: 2.6.29-rc6-git7: Reported regressions 2.6.27 -> 2.6.28. (March 4, 2009)

Miscellaneous

• Mark Lord: hdparm-9.12 released. (February 27, 2009)

• Steven Rostedt: [RFC] copy_strtok_from_user. (February 27, 2009)

• Etienne Lorrain: Gujin bootloader version 2.5. (March 4, 2009)

• Kay Sievers: udev 139 release. (March 2, 2009)

Page editor: Jonathan Corbet

Distributions

News and Editorials

CrunchBang Linux 8.10

CrunchBang Linux (#!) is a lightweight Ubuntu-based distribution featuring the OpenBox window manager and Conky system monitor. The distribution is essentially a minimal Ubuntu install with a custom set of installed packages, and it has been designed to offer a balance between speed and functionality. The light system requirements suggest that CrunchBang Linux is a perfect match for an outdated computer or a netbook. With this in mind, your author tested CrunchBang Linux 8.10.02 on an Acer Aspire One with a 8 GB SSD and 512 MB RAM. Since the RAM is on the low end, this puts to the test how lightweight CrunchBang Linux really is.

Installing CrunchBang Linux

CrunchBang Linux comes in three editions: Standard Desktop Edition, Lite Edition, and CrunchEee Eee PC Edition. Your author opted for the Standard Desktop Edition. CrunchBang Linux, like its parent distribution, is available as a live cd image. Of course, the best performance is achieved when installing the distribution on the SSD or hard disk. Your author used Unetbootin to write the iso image to a USB pen drive and booted the live distribution. The installer (started by right-clicking on the desktop and choosing "Install") looks familiar: it is the well-known seven-step installer of Ubuntu's live cd.

After the installation, the light system requirements immediately shine. CrunchBang Linux boots significantly faster than Ubuntu Intrepid on the Acer Aspire One and it feels much more responsive. The memory requirements are significantly less: while Ubuntu is eating almost all the available RAM right after booting, CrunchBang Linux needs only around 150 MB. Even after opening Firefox and some other applications, the memory usage of 250 MB is rather modest.

Minimalistic desktop

The first thing that one sees is the minimalistic interface. Instead of Ubuntu's brownish colors, CrunchBang Linux presents a stylish black background without icons, and showing some system information like CPU, RAM and disk usage. This is done by the Conky system monitor, which also shows some shortcut keys for opening a web browser, terminal, editor, etc. This is helpful for the novice user not yet acquainted with the shortcut keys. Conky is completely customizable: for example, it is possible to show weather reports on your desktop, email notifications, battery life, and more. The CrunchBang Linux forum hosts plenty of examples of the conkyrc configuration file.

The OpenBox window manager is a program in the same minimalistic style. It has no menu bar, but right-clicking on a random position on the desktop presents a menu with applications, preferences and system settings. One caveat: when your author installed an application, it was not automatically added to the applications menu: he had to edit the OpenBox menu file manually. The bottom panel shows the virtual desktop pager, a window list, system tray, digital clock, wireless network, battery status and clipboard manager. Additional plugins are available if you need more information on your panel.

Member of the Ubuntu family

Although CrunchBang Linux is an unofficial branch of Ubuntu, it stays close to the upstream distribution: it uses the official Ubuntu repositories and the same update manager and package management tools. It even uses the stock Ubuntu kernel. Hence, when you are facing problems, most of the information in Ubuntu wikis and forums still applies. CrunchBang Linux has also its own places for help (a wiki, forum, blog and planet aggregator) and an active and helpful IRC channel (#crunchbang on freenode).

The standard set of installed applications differs a bit from Ubuntu's set. For example, CrunchBang Linux doesn't install OpenOffice.org, but the much lighter Abiword and Gnumeric. CrunchBang Linux is also a good fit for web-centric users: Firefox 3 is installed with out-of-the-box Flash support. Other installed internet applications are Skype and Gwibber (for Twitter users). CrunchBang Linux also has MP3 support and encrypted DVD playback out-of-the-box. If you use the Lite Edition, the difference mainly lies in the number of installed applications: the Lite Edition is even more minimal.

The support for the Acer Aspire One is good: Your author successfully applied all the suggestions and tips from the Ubuntu community documentation for the machine right away in CrunchBang Linux. Using wired internet, he installed the linux-backports-modules-intrepid package for the ath5k wireless driver, and after a reboot wireless networking was fully functional. The tweaks for better SSD performance in the Ubuntu community documentation also work in CrunchBang Linux.

Conclusion

If you are looking for an easy-to-use and lightweight Linux distribution, CrunchBang Linux should definitely be considered. The combination of the OpenBox window manager and Conky system monitor with an Ubuntu base and a carefully chosen set of lightweight applications makes it unique. With CrunchBang Linux, you can revive an updated computer or let your netbook shine. Moreover, the huge set of available Ubuntu documentation also applies for this distribution. This makes it easy for Ubuntu users to migrate to CrunchBang Linux, while still having the advantages of the huge Ubuntu community.

Comments (41 posted)

New Releases

Ubuntu Jaunty Alpha 5 released

Full Story (comments: none)

Distribution News

Debian GNU/Linux

Debian Project Leader Elections 2009: Call for nominations

Full Story (comments: none)

Google Summer of Code 2009 at Debian needs you

Full Story (comments: none)

Fedora

Fedora 10 Stats + FUDCon Berlin

Full Story (comments: none)

Fedora Board Meeting Recap 2009-03-03

Full Story (comments: none)

Unofficial Fedora FAQ Update

Full Story (comments: none)

Gentoo Linux

Gentoo Council Meeting summary for 26 February 2009

Full Story (comments: none)

SUSE Linux and openSUSE

openSUSE Trademark Guidelines Released

Full Story (comments: none)

Addressing the layoffs

Comments (none posted)

OpenSUSE RT Kernel

Full Story (comments: none)

Ubuntu family

Ubuntu now offering mainline kernel builds

Full Story (comments: 39)

Karmic Release Schedule

Full Story (comments: none)

New Distributions

Qimo 4 Kids

Comments (3 posted)

Distribution Newsletters

Miscellaneous Debian developer news (#14)

Full Story (comments: none)

DistroWatch Weekly, Issue 292

Comments (none posted)

Fedora Weekly News #165

Full Story (comments: none)

Fedora's Echo Monthly News Issue 6

Comments (none posted)

The Mint Newsletter - issue 77

Comments (none posted)

openSUSE Weekly News

Comments (none posted)

Ubuntu Weekly Newsletter #131

Full Story (comments: none)

Distribution reviews

Debian 5.0 Continues Strong Linux Tradition (eWeek)

Comments (none posted)

Page editor: Rebecca Sobol

Development

Using Parasite to delve into GTK+ applications

Trying to debug your own GUI applications can be a pain if you are not extremely familiar with the toolkit used to make the user interface. When the code you are working on is also unfamiliar, the whole experience quickly becomes less than desirable. The GTK+ Parasite tool helps you to work out the structure of the widgets that comprise a GUI, inspect and change properties of those widgets, and perform more in-depth analysis using an embedded Python shell.

The GTK+ toolkit provides an object-oriented framework for making user interfaces in C. GTK+ gives you facilities to inspect and change the properties of objects and supports introspection so you don't need to know about classes at compile time in order to make use of them at runtime. The GTK+ Parasite attaches itself to a GTK+ application and takes advantage of these dynamic features to let you inspect and change the interface of an application as it runs.

GTK+ Parasite doesn't have any official releases yet, but the source can easily be pulled from its Git repository, compiled and installed using the standard ./autogen.sh && make autotools dance. You'll want to make sure that you have the development packages for PyGtk installed first in order to get the embedded Python shell functionality.

To use GTK+ Parasite, add its name to the GTK_MODULES environment variable and run your GTK+ application as you normally would. For example:

    GTK_MODULES=gtkparasite gedit

Along with your application, you should see and additional Parasite window with a Widget Tree and Action List tab and a small area in the lower part of the window with a Python prompt.

To find out the hierarchy of widgets in your GTK+ application, click on the Inspect button in the Parasite window and then any part of the GUI of your GTK+ application. Along with each widget in a tree view you should see if that widget is realized, mapped and visible, along with the address of both the X Window of the widget and the GTK+ widget itself. The latter address is very handy because you can right click on it and "Send Widget to Shell" to obtain a reference to the widget from the embedded Python interpreter.

The list in the far right of the Widget Tree tab in the Parasite window lists the properties and their value for the current widget. Holding the left button down over a property pops up a list of possible values for you to change it too. On the other hand, if the range of values for a property is too large, like for an integer property, no menu is presented and you can enter the value directly.

The Action List tab in Parasite shows you all the GTKAction objects in the application. For those unfamiliar with the GTK+ toolkit, a GtkAction object represents a piece of functionality that can be connected to a menu or toolbar, for example, opening a Save as dialog or starting a search within the current document. As an example, running Parasite on the text editor gedit, finding the FileOpen action in the list and selecting "Send Object to Shell" from the menu, you can perform the GtkAction by calling the activate method on the object. You should see the file dialog appear. The embedded Python shell command should look something like:

    >>> parasite.gobj(0xa78980).activate()

where everything up to the .activate() was added automatically by Parasite when I told it to send the object to the shell.

If you are writing a custom GTK widget, the "Show Graphic Updates" button causes any redraws that the application performs to briefly flash red first. This makes it fairly simple to see if you are drawing more than you think in order for your widget to update itself. For example, in gedit, only a rectangle covering the current line is updated when you type text into the active document, but when you hit return the current line and everything below it flashes red.

There are a few rough edges to the GUI of GTK+ Parasite, which is to be expected from such a young application. For example, in the "Action List" tab, one might expect to be able to simply double-click on an action to execute it. In addition, left-clicking on a property lets you either edit the value directly inline in the cell or if there is a limited number of acceptable values a popup menu appears allowing you to select a value. While this provides a consistent user interface for editing though left clicking, it does mean that you have to click on a property row before editing its value. One might at first expect a context menu to be available offering such editing functionality, with the added bonus that you could directly right click on a property to edit it rather than having to select it with a left click first.

For such a young application GTK+ Parasite is already very useful and a great tool for ironing out the kinks in an application's GTK+ interface. If you are a Python fan, the embedded Python interpreter lets you tinker with the GTK+ interface even if the program itself is written in C.

Parasite is developed by Christian Hammond and David Trowbridge. Activity on the mailing list is currently on the slow side, but it should pick up as developers discover this tool.

Comments (none posted)

System Applications

Database Software

buzhug 1.5 released

Full Story (comments: none)

Golconde 0.4 released

Full Story (comments: none)

pgpool-II 2.2 and pgpoolAdmin 2.2 are released

Full Story (comments: none)

phpMyAdmin: 3.1.3 is released (SourceForge)

Comments (none posted)

PostgreSQL Weekly News

Full Story (comments: none)

pysqlite 2.5.2 is out

Full Story (comments: none)

Device Drivers

Tour the Linux generic SCSI driver (IBM devloperWorks)

Comments (none posted)

Networking Tools

Zenoss: 2.3.3 is now available (SourceForge)

Comments (none posted)

Security

announcing ClamAV 0.95rc1

Full Story (comments: none)

Virtualization Software

Open Letter: Leaving TightVNC, Founding TigerVNC

Full Story (comments: none)

Web Site Development

spawn-fcgi 1.6.0 released

Comments (none posted)

Miscellaneous

DeviceKit 003 released

Full Story (comments: none)

Microlog: V1.1.0 released (SourceForge)

Comments (none posted)

Desktop Applications

Audio Applications

Invada Studio Plugins 0.3.0 announced

Full Story (comments: none)

Business Applications

Gnumeric 1.9.4 announced

Full Story (comments: none)

Collaboration Software

Agilefant: 1.5.4 released (SourceForge)

Comments (none posted)

gumnut: 0.2.7 released (SourceForge)

Comments (none posted)

Desktop Environments

GNOME Software Announcements

• Anjuta 2.25.903.0 (bug fixes and documentation work)
• at-spi 1.25.92 (bug fixes and translation work)
• Brasero 2.25.92 (code cleanup, bug fixes and translation work)
• Cheese 2.25.92 (bug fixes and translation work)
• Deskbar-Applet 2.25.92 (bug fixes and translation work)
• Ekiga 3.1.2 (new features, bug fixes and translation work)
• Empathy 2.25.92 (new features, bug fixes and translation work)
• Evince 2.25.92 (bug fixes and translation work)
• Eye of GNOME 2.25.92 (bug fixes, code cleanup and translation work)
• GCalctool 5.25.92 (bug fixes, documentation and translation work)
• Gdl 2.25.92 (bug fixes)
• GLib 2.19.10 (new features, bug fixes and translation work)
• gnome-applets 2.25.92 (bug fixes and translation work)
• GNOME DVB Daemon 0.1.5 (new features and bug fixes)
• gnome-games 2.25.92 (new features, bug fixes and translation work)
• gnome-keyring 2.25.92 (new features, bug fixes and translation work)
• gnome-mud 0.11.2 (bug fixes and translation work)
• GNOME Scan 0.6.2 (new features and bug fixes)
• gnome-settings-daemon 2.25.92 (bug fixes and translation work)
• GTK+ 2.15.5 (new features, bug fixes and translation work)
• gtk-engines 2.17.4 (new features and translation work)
• Libgda 3.99.12 (new features, bug fixes and translation work)
• mousetweaks 2.25.92 (bug fix and translation work)
• Nemiver 0.6.5 (new features, bug fixes and translation work)
• Orca 2.25.92 (bug fixes and translation work)
• seahorse 2.25.92 (new features, bug fixes and translation work)
• seahorse-plugins 2.25.92 (bug fixes, code cleanup and translation work)

Comments (none posted)

KDE Software Announcements

• 2ManDVD 0.5.1 (new features, bug fixes and translation work)
• blackscreen 0.0.1 (initial release)
• blackscreen 0.0.2 (new feature)
• cb2Bib 1.2.0 (new features)
• first4 1.4.0 (bug fixes and translation work)
• Frescobaldi 0.7.7 (new features, bug fixes and translation work)
• fsrunner for KRunner 0.1 (initial release)
• KAlarm 2.1.5 (new features and bug fixes)
• KBlogger 1.0-alpha3 (new features and bug fixes)
• KdeSudo 3.3.2/2.6 (bug fixes and translation work)
• kgbmencoder 0.1.1 (new feature and bug fix)
• K Menu Gnome 0.9.1 (new features and code cleanup)
• KRadio4 for KDE4.x snapshot-r694 (new features, bug fixes and KDE4 support)
• K-Yamo v0.40a4-2 (new features and bug fixes)
• PeaZip 2.5.1 (new features and translation work)
• QNapi 0.1.6-rc2 (unspecified)
• QTrans 0.2.1.5 (new feature)
• Qwit 0.8 (new features and bug fixes)
• Radio Italiane 0.2 (new stations)
• Veusz 1.3 (new features and bug fixes)
• Wally 2.0.1 (bug fixes)
• yape 2.0 (new features)

Comments (none posted)

Xfce 4.6 released

Comments (5 posted)

Xorg Software Announcements

• libXi 1.2.1 (new features and bug fixes)
• xf86-input-evdev 2.1.99.1 (new features, bug fixes and code cleanup)
• xf86-input-hyperpen 1.3.0 (build fixes and code cleanup)
• xf86-input-synaptics 1.0.99.1 (new features and code cleanup)
• xf86-input-synaptics 1.0.99.2 (build fixes)
• xf86-input-synaptics 1.0.99.3 (bug fixes and code cleanup)
• xf86-video-intel 2.6.3 (bug fixes)
• xorg-server 1.6.0 (bug fixes, code cleanup and documentation work)
• xproto 7.0.15 (new features and code cleanup)

Comments (none posted)

Electronics

zParts: 0.93 Released (SourceForge)

Comments (none posted)

Encryption Software

GnuPG 2.0.11 released

Full Story (comments: none)

Games

Doomsday Engine: 1.9.0-beta6 released (SourceForge)

Comments (none posted)

ScummVM: 0.13.0 'More Guests' enter(s) the house (SourceForge)

Comments (none posted)

GUI Packages

Qt 4.5 released

Comments (3 posted)

Interoperability

Wine 1.1.16 announced

Comments (none posted)

Medical Applications

GNUmed 0.4.0 released (LinuxMedNews)

Comments (none posted)

Multimedia

Elisa Media Center 0.5.30 Release

Full Story (comments: none)

Music Applications

mingus 0.4 released

Full Story (comments: none)

Digital Photography

hugin: 0.8.0 beta1 testers release (SourceForge)

Comments (none posted)

Video Applications

Gnash 0.8.5 released

Comments (12 posted)

Web Browsers

Browsing in GNOME

Comments (23 posted)

Languages and Tools

C

LLVM 2.5 released

Full Story (comments: 5)

Caml

Caml Weekly News

Full Story (comments: none)

Java

IcedTea6 1.4.1 released

Full Story (comments: none)

Perl

Rakudo Perl development release #14 (use Perl)

Comments (none posted)

PHP

PHP 5.2.9 released

Comments (none posted)

Python

Python-URL! - weekly Python news and links

Full Story (comments: none)

Python-URL! - weekly Python news and links

Full Story (comments: none)

Tcl/Tk

Tcl-URL! - weekly Tcl news and links

Full Story (comments: none)

Cross Compilers

SDCC 2.9.0 RC1 released

Comments (none posted)

Editors

Emacs 23.0.91 pretest

Comments (none posted)

Profilers

Valgrind 3.4.1 is available

Full Story (comments: none)

Test Suites

The Linux Test Project: February 2009 release (SourceForge)

Comments (none posted)

Version Control

GIT 1.6.2 released

Full Story (comments: none)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

451 Group: Microsoft suing TomTom, not Linux, not open source

Comments (39 posted)

LinuxDNA Supercharges Linux with the Intel C/C++ Compiler (Linux Journal)

Comments (43 posted)

Companies

Novell puts Linux on sale as earnings disappoint (cnet)

Comments (14 posted)

VMware, Novell hatch virtual appliance scheme (the Register)

Comments (none posted)

Linux Adoption

UK government backs open source (BBC)

Comments (9 posted)

Legal

Judge orders defendant to decrypt PGP-protected laptop (CNet)

Comments (20 posted)

Red Hat's JBoss Software Draws Patent Suit (InformationWeek)

Comments (10 posted)

Interviews

Video: Ted Ts'o on Ext4, BtrFS and first steps with Linux (Linux Magazine)

Comments (7 posted)

Resources

Web Content Filtering with OpenDNS (Linux Journal)

Comments (6 posted)

Reviews

Touch Book: Linux based touch screen device announced (The H)

Comments (9 posted)

Miscellaneous

Is Microsoft Targeting Linux Through Tom Tom? Oh Please... (ITBusinessEdge)

Comments (21 posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

FSFE engages in the EU browser case

Full Story (comments: none)

The Linux Foundation acquires Linux.com

Comments (8 posted)

Draft OpenStreetMap license and implementation plan

Full Story (comments: 1)

Commercial announcements

MontaVista introduces Meld embedded Linux community

Full Story (comments: none)

wxDesigner 2.19 is available

Comments (none posted)

New Books

Scott Meyers New C++ eBook Collection

Full Story (comments: 2)

Resources

EFF Releases How-To Guide to Fight Government Spying

Full Story (comments: none)

Linux Gazette #160

Full Story (comments: none)

Contests and Awards

Announcing the first programming competition for Openmoko phones

Full Story (comments: none)

Education and Certification

Linux Foundation announces training program

Comments (none posted)

LPI launches Enterprise-level "Security" exam

Full Story (comments: none)

Event Reports

OSBF demos platform for secure cloud computing at CeBIT

Full Story (comments: none)

Calls for Presentations

FRHACK 2nd Call For Papers

Full Story (comments: none)

Liwoli 2009 - Call for projects

Full Story (comments: none)

OSPERT 2009 call for papers

Full Story (comments: none)

Pycon Tre Italy Call For Presentations

Full Story (comments: none)

Upcoming Events

Registration open for ELC 2009 - Program announced

Full Story (comments: none)

EuroPython 2009 registration opens

Full Story (comments: none)

Announcing the International Techno Security Conference

Full Story (comments: none)

Libre Graphics Meeting 2009 launches community fund raising campaign

Full Story (comments: none)

The OpenOffice.org annual Conference 2009 goes to Italy

Full Story (comments: none)

Announcing php|tek 2009

Comments (none posted)

Events: March 12, 2009 to May 11, 2009

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

Page editor: Forrest Cook