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
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
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)
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 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:
Rockbox as an app has been a story we've told the kids around the campfires for a good while by now and yet we haven't actually seen it take off in any significant way. I'm now building up my own interest in working on making this happen. In a chat after my Rockbox talk at Fosdem 2010, two other core Rockbox developers (Zagor and gevaerts) seemed to agree to the general view that a Rockbox future involves it running as an app.
Out of the existing systems mentioned above, I'd prefer to start this work focused on Android. It has the widest company backing combined with open source and it's also the most used open phone OS. I don't think there's anything that will prevent us from working on all those platforms as the back-bone should be able to remain the same and portable code we already have and use. Heck, it could then also become more of a regular app for common desktops too.
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>>