Your editor has finally acted to bring an end to an annual embarrassment.
Each year, at the Kernel Summit, the entire group is brought together for a
photograph. Most digital cameras can do a reasonable job of taking a
portrait, but getting a reasonable image of some 70 people all together is
another story. Your editor, possessing a camera of the "other story"
variety, has been forced to post grainy, second-rate pictures of a
first-rate crowd, only to be upstaged by attendees with far superior
equipment. To be absolutely sure that he will not be shamed this year,
your editor went and picked up a shiny new Sony DSC-V3
camera. If his writing in LWN has seemed distracted recently, blame the
In the classic days of Linux, one would expect to spend a full, painful day
making a new device work with Linux. In this century, however, people have
this irrational expectation that their hardware will "just work." Linux
has gotten good at living up to that expectation in a number of ways; see
the advances in printer configuration, for example. Your editor set out to
determine if support for digital cameras has made the same sort of
It turns out that there are very few free applications which are aimed
specifically at interfacing with digital cameras. And the big ones,
reviewed below, are all based on the libgphoto2 library. So
this review did not take as long as some of the others in this series.
Gtkam is "the official GTK2
GUI" for libgphoto2. On many distributions, it is the default digital
camera interface application. Your editor tried version 0.1.12 on Fedora
and Ubuntu systems.
The initial gtkam window is mostly blank. The "camera" item on the tool
bar leads to the obvious "add camera" dialog, which, in turn, contains a
pulldown menu for
the camera model. In theory, the user need only select the right model
from this list, and all will be well. Unfortunately, this menu contains
over 500 entries, making the camera selection process unwieldy at best.
Even more unfortunately, your editor's camera - on the market since June of
last year - was not on the list. Obviously, your editor should have
checked first and bought a supported camera; somehow, however, the idea of
showing up at the Kernel Summit with a Barbie camera lacks appeal.
There is also a "detect" button next to the model pulldown; it failed to
find your editor's camera, however.
Now, the DSC-v3 has two ways of dealing with the USB bus. In its default
configuration, the camera appears to be a USB mass storage device. The
camera can also be instructed to use the "picture transport protocol" (PTP)
mode, which is an older, specialized way of talking to cameras. When your
editor put the camera into the PTP mode, and after tweaking some
permissions under /proc/bus/usb, gtkam was able to detect it - as
a Sony DSC-F707V. The model was wrong, but everything worked.
When it is talking to a camera it knows about, gtkam presents a simple
browsing interface. The left pane is the directory hierarchy as exported
by the camera, while the right shows thumbnails of any images stored in the
currently-selected directory. Many of the obvious things are not possible;
you cannot ask gtkam to display a full-resolution image, for example, and
it will not let you drag images into file browsers or other applications.
There are, in fact, exactly two things you can do: download images, and
The download window is somewhat awkward to work with, mostly because it
seems to want to provide for several possible actions. It can save the
pictures themselves, or just the thumbnails or metadata. It can feed the
images to an external application. Or it can rename the pictures, adding
an incrementing number to a user-supplied base filename. Once you get the
hang of the window, things work reasonably well, but it can take a couple
of tries at the outset.
The KDE digital camera application is digikam.
Your editor used version 0.7; that version is a bit old (there is a 0.7.2 beta out), but attempts to build
something more recent were a dismal failure. Digikam, it turns out, is not
a straightforward application to build.
The initial digikam window resembles gtkam's, in that there is not much to
be seen. The "Camera" toolbar item has an "add camera" option, which is a
nice enhancement over previous versions of digikam, which required the user
to wander into the "configure digikam" dialogs.
The camera dialog looks very much like gtkam's, and it
behaves in a very similar way. Since the same library is doing the work
underneath it all, this resemblance is not entirely coincidental. There is
one interesting addition to the digikam dialog, however: the user who
remains awake after having scrolled through some 500 possibilities will see
"USB mass storage" as a camera type. The user must provide the directory
where the camera will be mounted - and arrange for it to be actually
mounted there. With that work done, however, digicam was able to talk to
your editor's camera in its native mode. The PTP mode also works, as it
did with gtkam.
Actually, the PTP mode almost works. It will happily detect the camera
(once again calling it a DSC-F707V) and work with it - for one session.
Once the camera has been disconnected and plugged back in, however, digikam
is unable to work with it. Removing the camera from the configuration and
asking digikam to detect it from the beginning worked. It would seem that
the camera pops up with a different address under /proc/bus/usb
each time; gtkam is able to handle that change, but digikam is not.
Digikam provides the same basic operations as gtkam: download images from
the camera, and delete images from the camera. There is much more to
digikam than that, however: while gtkam forgets about images once they have
been extracted from the camera, digikam is a full image management and
manipulation framework. It implements albums, performs simple image
editing, and provides a large set of gimp-style plugins (which seem to be
mostly front ends to tools from the ImageMagick package).
Your editor reviewed gthumb
almost one year ago in this article on image
viewers and editors
. This application is not often presented as being
a tool for working with digital cameras, but the attentive user will notice
an "import images" item on gthumb's "file" menu. Selecting that option
yields the dia digital camera
It is, perhaps, the best of them all. There is no need to tell gthumb to
configure a camera; it simply goes out and talks to whatever it finds.
It found your editor's new camera without trouble (in PTP mode only), but
had to be instructed
on where to look for the old one, which is of the painful serial port
variety. The dialog has a blank marked "film," which would appear to be
the name of a subdirectory to create for the images.
Once that has been
figured out, it is simply a matter of deciding where the images should go,
whether they should be deleted from the camera, and hitting the "import"
So which is the preferred interface for a grumpy editor? Of the three
programs discussed above, gthumb has the most straightforward interface,
with a minimum of bureaucracy required before work can be done. That would
be your editor's pick.
The truth of the matter is this, however: your editor thinks the best
approach is to get a modern camera which implements the USB mass storage
protocol. Then you can simply mount the camera as a disk, move the image
files across, and be done with it. It's fast, easy, and for those who
prefer not to use the mv command, setting up hotplug scripts to
launch a file manager is relatively straightforward. There should be no
need for separate, specialized applications to interface with a digital
On the other hand, the management of images once they have been
pried from a camera's clutches is an interesting problem. Tools like
digikam and gthumb have been written with that task in mind; there are
several others out there as well. And that is likely to be your editor's
next (and rather more ambitious) exercise: a review of image management
tools. Stay tuned.
Comments (44 posted)
The Open Source Development Labs has, just in time for LinuxWorld,
the availability of the "Desktop Linux
Capabilities" specification. This document is available in
One of OSDL's most controversial functions is the creation of
specifications for Linux in particular environments. The Carrier Grade
Linux and Data Center Linux documents might indeed be an accurate
reflection of the features desired by commercial interests in those
sectors. But those documents also appear, to the developers who actually
create Linux, as an attempt to tell them what they should be working on.
In that regard, the introduction from the desktop Linux document is likely
to rub some developers the wrong way:
An important decision taken by the OSDL Desktop Linux Working Group is
that the Linux operating system will be developed independently. We
will not attempt to emulate other existing desktop systems. We feel
that the system should interoperate with existing systems, but we do
not strive for complete compatibility.
The people at OSDL know quite well that any attempt to "decide" that
desktop Linux would not be developed independently would fail. They
do not yet seem to know how to keep that sort of language out of their
The introduction continues:
Variety and choice, two of Linux's greatest strengths, are also its
Achilles heel. ISVs and large corporations do not have the resources
(or ability, in some cases) to ensure all applications work in all
current graphical environments and windowing managers available in
OSDL goes on from there that there should be a single desktop Linux
standard. Furthermore, this standard must be chosen from one of the
existing desktop environments; any attempt to combine them was regarded as
not feasible. The authors are clearly not complete masochists, however:
they stopped short of saying which environment they think should be chosen,
or even naming a subset from which the choice should be made.
The document identifies four types of desktop deployment, ranging from
"fixed function" (locked-down kiosks of one form or another) through to
"technical workstation" and "basic office". The existence of a "general
purpose" usage category is recognized, but not really addressed in the
The bulk of the document follows: it is a tiresome series of tables
describing the capabilities the authors think desktop Linux should have.
Many of them are obvious, and already present: x86 processor support, USB
support, IPv4, and so on. Some will be controversial: DVD playback support
(which "will require licenses") and implementation of digital restrictions
management schemes. Some make sense, and are in the works: persistent
device naming, good IPSec support, etc. And some things are strange in
their absence: instant messaging, Microsoft document format support,
electronic mail, internationalization, and so on.
And a few things are bizarre. It would appear that all desktop users, even
those with "fixed function" systems, have an urgent need for a Linux
installer which uses their preferred desktop environment. Installations
must be checkpointed so that they can be restarted in the middle. Desktop
users should, it is said, be able to do things like update their kernel
without needing root access to the machine. Numerous pages are devoted to
various aspects of the installation process - despite the fact that, in a
world of widespread Linux desktop deployments - most desktop users should
never do their own installations.
If Linux is to achieve desktop World Domination, quite a bit of work will
have to be done. Even the most ardent desktop Linux supporter will not (or
should not) say that all of the necessary pieces are in place now. When
OSDL set out to create its desktop capabilities document, it had an
opportunity to identify the missing pieces, the features which, were they
present, would make Linux more attractive in more desktop situations. That
opportunity was lost in what must have been a series of tiresome meetings
creating checklists of features Linux has had for years. Meanwhile the
development community continues to improve Linux (for all environments) at
a staggering rate - no specification required.
Comments (9 posted)
(Community ENTerprise Operating System)
project has been thrust into the spotlight recently as a result of contact from Red Hat's lawyers
regarding the use of trademarks. In reality, that's something of a non-story, since Red Hat is only asking the project to comply with Red Hat's trademark guidelines
. Red Hat has enforced its trademarks before
without destroying the GPL or stopping the distribution of Red Hat derivatives.
The CentOS team makes it very clear that the trademark issue is not a major obstacle, and is no threat to the future development of CentOS. But the brief flurry of press did bring our attention to the cAos (community assembled operating systems) Foundation and its CentOS and cAos Linux distributions. This writer has run into several admins who've chosen to go with CentOS as an alternative to Red Hat Enterprise Linux.
The CentOS distribution is compiled from source packages from "a Prominent North American Enterprise Linux Vendor." CentOS-3 is built from Red Hat Enterprise Linux (RHEL) 3 sources, and CentOS-2 is built from RHEL 2. The project is working on CentOS 4 as well, but it is still in beta at the moment.
Installing and using CentOS is much (almost exactly) like using RHEL. There are some cosmetic differences, the CentOS logo and name replaces Red Hat's in most places -- though Red Hat is still given due credit in copyrights and so on -- and some changes in non-free packages. For the most part, though, CentOS seems to be an acceptable drop-in replacement for RHEL.
We also tested installing binary packages compiled for RHEL 3 on CentOS 3. We didn't run into any issues with packages compiled for RHEL 3 on CentOS 3 -- so CentOS seems to be suitable for users and organizations that want to use commercial products that support RHEL 3.
Support for CentOS is offered through forums, mailing lists, IRC channels and commercial organizations. We didn't approach any of the commercial organizations, but the CentOS community seems to be very helpful and responsive. The mailing lists, in particular, are fairly active. The February archive for CentOS 3 has 318 messages already, though some of the traffic is directly tied to the trademark issue.
Updates for CentOS are available via Yum repositories, which is a suitable replacement for the Red Hat Network as far as this writer is concerned. We did a little checking to see if the packages available from CentOS were up to date. After running "yum update" on CentOS 3 to get the latest packages, we checked against the Red Hat FTP repository for updates to RHEL 3. In each instance, we found that the CentOS packages were current, or at least as current as the packages on Red Hat's site.
The cAos Foundation is also distributing cAos Linux, not based on Red Hat's sources. The cAos Linux distribution is also RPM-based, but features its own Cinch installer, and a different design philosophy than CentOS. We did not spend much time with this distribution, but it does look like an interesting project for users who are looking for a community-driven RPM distribution with a long shelf-life. (The cAos page promises a 3-5 year life cycle, which is a bit more attractive for many users than the rapid development cycle for Fedora Core.)
Red Hat may have been better off leaving the trademark issue alone, since it seems that the project has garnered some attention it might not have received otherwise. After spending some time with CentOS, this writer sees little difference between Red Hat's official offerings and the CentOS offerings that are community-supported. Official support directly from Red Hat may be necessary for some organizations, but if that's not a requirement, the CentOS distribution may be a better choice.
Comments (11 posted)
Page editor: Jonathan Corbet
Next page: Security>>