Leading items

A quick grumpy review of Shotwell

Your editor routinely does a fair amount of photo editing, typically preparing conference pictures for articles or pictures of children for grandparents. In recent years, xv has become less of a tool of choice; it did a number of things right that others still haven't figured out, but it's old, dead, not really free, and unmaintained. Much of this work is now done with gthumb instead. Unfortunately, gthumb has been broken (as in "crashes at start") in Rawhide for quite some time; leaving your editor to look for alternatives. In this context, the relatively new Shotwell application came to your editor's attention. Shotwell is said to be replacing F-Spot as the default photo manager in the Ubuntu 10.10 release, so it seems worth a look.

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

Your editor had the pleasure of giving a keynote talk at the 2010 LinuxTag, immediately prior to Mark Shuttleworth's keynote - a position described by more than one person as being Mark's warmup act. That role must have been successfully carried out; Mark's talk was, indeed, well received from the start. Topics ranged from the familiar (cadence) to issues like quality, with a look at upcoming Ubuntu design features as well.

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
Next page: Security>>