Bdale Garbee led off the linux.conf.au 2005 Debian "miniconf" with a
discussion of the state of the Debian project as he sees it. He covered
several topics of interest to the Debian community - and beyond.
With regard to the recently-concluded project leader election: Bdale was
clearly not entirely comfortable with Branden Robinson as a project leader
candidate. He did say, however, that Branden clearly wants to do the right
thing with Debian, and that the community should work with him to make that
happen. It will, he says, be interesting.
In general, there are difficulties with the whole concept of the Debian
project leader. The Debian community prizes cooperation and working
together to create the best distribution possible, but the project leader
process focuses, instead, on singling out an individual. The job is too
much for one person to handle, and, in any case, that one person can only
do so much to affect the development of Debian. And the election process,
which extends over a nine-week period, takes far too long relative to a
The Debian technical committee is not working as well as it could be
either. Its current composition needs to be reviewed; some of the
committee's members have not been active participants for some time. The
committee could take a more active role in directing Debian's development.
At the same time, the people who complain that the committee is
insufficiently active could also step forward and try to influence things
on their own.
Scud is an initiative to create a sort of advisory committee to help
the Debian project leader in his work. This project was endorsed by
Branden Robinson, so one assumes that it will be implemented in some form.
Bdale noted that not everybody is comfortable with this idea. The
committee's role, as it relates to the project's constitution, is not
particularly clear. The committee is self-selected, and is not necessarily
representative of the entire project. Some people feel left out. Bdale
feels that Scud might improve the situation. But, he says, it's a hack,
and the project can do better.
Bdale's proposal for doing better is to amend the constitution to bring
about a significant change in the project's governance. The Debian project
leader would be replaced with an elected board. A board could divide up
the work, and, hopefully, give more attention to what needs to be done.
Board candidates could emphasize how well they can work with a team.
Running for a board seat is less intimidating than going for a single
position. The result of all this could be that more qualified people run
for (and are elected to) board seats.
Bdale hopes to get some discussion of this idea at Debconf5, to be held in
Helsinki this July. If some sort of consensus emerges, a general
resolution could be proposed to the community as a whole. The idea could
change a lot in the process, but, Bdale says, there is a pressing need to
think creatively about how to evolve Debian, or it will eventually cease to
With regard to the sarge release: Bdale noted (jokingly) that he was the
last Debian project leader to have overseen a Debian stable release. There
comes a point where you have to simply list the remaining hurdles and
summon up the will to deal with them. Debian is, he says, getting to the
point where it is ready to do this and get sarge out the door. After that,
he would like to see Debian go to a more predictable (and shorter) release
A question was asked about shipping XFree86 4.3 in sarge, long after most
other distributions have moved over to the X.Org release. It is, of
course, simply a question of getting the sarge release out the door. Now
is not the time to replace such a large and fundamental component of the
system. It would have been better if sarge had shipped some time ago so
that this sort of issue would not come up, but there is little to be done
about that now.
Meanwhile, Bdale's plots of the number of Debian maintainers and the number
of packages continue to show a linear increase over many years. Debian
continues to grow, and is showing no sign of stopping. The project must,
it seems, be doing something right.
Comments (1 posted)
Andrew Tridgell delivered the first linux.conf.au keynote on Thursday
morning. The bulk of the talk covered software engineering techniques and
how the free software community is taking a leading role in adopting those
techniques. It was a good talk, and your editor will attempt to write it
up later on.
At the end, however, Tridge touched on his role in the separation of the kernel
project and BitKeeper. He couldn't talk about much, and he did not
announce the release of his BitKeeper client. But he noted that there has
been quite a bit of confusion and misinformation regarding what he actually
did. It was not, he says, an act of wizardly reverse engineering. Getting
a handle on the BitKeeper network protocol turned out to be rather easier
He started by noting that a BitKeeper repository has an identifier like
bk://thunk.org:5000/. So, he asked, what happens if you connect
to the BitKeeper server port using telnet? A quick demonstration sufficed:
telnet thunk.org 5000
Connected to thunk.org.
Escape character is '^]'.
Once connected, why not type a command at it?
? - print this help
abort - abort resolve
check - check repository
clone - clone the current repository
help - print this help
httpget - http get command
Tridge noted that this sort of output made the "reverse engineering"
process rather easier. What, he wondered, was the help command there for?
Did the BitKeeper client occasionally get confused and have to ask for
Anyway, given that output, Tridge concluded that perhaps the clone
command could be utilized to obtain a clone of a repository. Sure enough,
it returned a large volume of output. Even better, that output was a
simple series of SCCS files. At that point, the "reverse engineering" task
is essentially complete. There was not a whole lot to it.
Now we know about the work which brought about an end to the BitKeeper
Comments (22 posted)
Perhaps even more than Linux, Firefox is rapidly becoming the poster child for open source. Many users who wouldn't even consider installing Linux on their desktop have happily installed Firefox, looking for features not found in Internet Explorer, and trusting in Firefox's reputation as a more secure alternative than IE.
This reputation has been a bit tattered in recent weeks, though perhaps unfairly. The Mozilla project has released three security updates since February, which has prompted some to call into question the respective security of Firefox in particular, and open source products in general.
Is this proof that Firefox or the Mozilla Suite suffer from as many serious security vulnerabilities as Internet Explorer? Maybe, but the evidence that's in so far suggests otherwise. We spoke to Chris Hofmann, Mozilla's director of engineering, about the recent security fixes and the Mozilla Foundation's security policies.
Hofmann said that Mozilla has built "a larger security community since the Firefox 1.0 release, with "some experts working with us to examine the code and identify potential problems." He also acknowledged that there will be vulnerabilities, but the project is committed to providing a secure browser and repairing problems as quickly as possible.
The latest update closed nine security vulnerabilities three tagged "critical," two rated "high" severity and four rated as "moderate" vulnerabilities. Some of the vulnerabilities have yet to be disclosed, despite the fact that the update is now available. Hofmann said that the project was respecting the wishes of the person reporting the bugs, and that the project tries to use "best judgement" about providing information about exploits. He also noted that it gives users ample time to install updates prior to releasing information that might be used to exploit vulnerabilities.
We also checked on the Mozilla Project's security policies to see what they had to say about disclosure:
The original reporter of a security bug may decide when that bug report will be made public; disclosure is done by clearing the bug's "Security-Sensitive" flag, after which the bug will revert to being an ordinary bug. We believe that investing this power in the bug reporter simply acknowledges reality: Nothing prevents the person reporting a security bug from publicizing information about the bug by posting it to channels outside the context of the Mozilla project. By not doing so, and by instead choosing to report bugs through the standard Bugzilla processes, the bug reporter is doing a positive service to the Mozilla project; thus it makes sense that the bug reporter should be able to decide when the relevant Bugzilla data should be made public.
Interested readers may also want to peruse the rest of the Mozilla project's security policies.
The 1.0.3 release went through several release candidates before it was finally officially released. We asked Hofmann about the length of time required to release a security fix, what was involved and why it took several weeks to push out a patch. Hofmann said that the Mozilla team was capable of putting out a release quickly, and noted the 24-hour turnaround with the shell exploit discovered last fall.
It mostly depends on the vulnerability that's discovered and time that we want to go through and evaluate that there's a comprehensive patch, and adequate testing for the change we're making... this time, changes did require more testing and feedback that the patch was comprehensive and at the right level.
Hofmann also pointed out that the Mozilla team has pushed out security updates in a matter of days or weeks, whereas Microsoft has been known to push out fixes for vulnerabilities that have been known for months rather than just a short time.
He also noted that the team needs to push out documentation updates, and get information out to application developers and authors of extensions. Hofmann said that a couple of the changes in the 1.0.3 release will require some extension authors to make "adjustments to be forward-compatible" and that most extensions that were affected already have new versions available for Firefox 1.0.3.
At any rate, as pointed out on MozillaNews, there have been more vulnerabilities documented by Symantec that affect Mozilla browsers, but that IE has a greater number of high-severity vulnerabilities. It should also be noted that the vulnerabilities listed for Firefox have not been widely exploited, while IE has been widely exploited. Several critical issues in IE remain open. To be fair, a few vulnerabilities are still listed for Firefox as well.
It's certainly true that Firefox and the Mozilla Suite are not perfect, and do not offer a 100 percent guarantee against security problems simply because the projects are open source. The increased attention being paid to Firefox almost assures that further vulnerabilities will be found. However, the project is developing a good track record of fixing security vulnerabilities as they are discovered, and proactively seeking out security problems. To date, Hofmann says that he is not aware of any exploits in the wild that affect Firefox or Mozilla, which means that the vulnerabilities that have been reported have not had any real impact on the Mozilla userbase aside from the inconvenience of upgrading -- which can hardly be said for Internet Explorer.
Those with a careful eye for distinguishing between the severity of vulnerabilities, the length of time required to find fixes and actual exploits, will find that Firefox is still the better choice for security-conscious users.
Comments (5 posted)
Your editor has, on and off, been interested in photography for more than
25 years. In the beginning, the bleeding-edge technology available
included dim red lights, special trays to keep chemicals at the right
temperature, and a disk on a stick for those advanced burning and dodging
techniques. Though your editor thinks that he can take an OK picture, LWN
readers can probably be thankful that this remains a text-oriented
The technology of photography has moved forward in recent years, but
certain issues remain. Your editor's closets contain numerous binders full
of carefully organized negatives, contact sheets, and slides. Said closets
also contain several boxes full of rather less carefully organized
photographic output. There's a lot of great pictures there, but chances
are good that nobody will ever see them. Organizing photographs is hard.
Now your editor's hard drive looks rather like those boxes in the closet;
several years worth of digital photos have accumulated in a messy directory
hierarchy with no easy way to find anything of interest. The move to the
digital format has, if anything, made the mess worse. How can one cope
with all those images? Your editor decided that there must be a
free application out there which might help; here is what he found.
Features to look for
Any graphical file manager can enable mouse-based navigation through a
directory tree full of images. An application tuned to image management,
however, should offer more than that. Anything that can be done to help
find a specific image - searching by date, where the picture was taken, who
is in it, etc. - is more than welcome. One should not have to dig through
a huge box of photos to find that darling shot of one's toddler performing
gravity research with the new laptop. This sort of searching requires the
creation and maintenance of metadata for images; a good application will
make that task easy.
Images from digital cameras include a significant amount of embedded data
in the exchangeable image file format
(EXIF). The EXIF data can contain the date and time of the picture and
a great deal of information on the state of the camera. An image manager
should provide easy access to that data, and make use of it when
Image management also involves various types of image manipulation. At the
simple end of the scale, this means quickly getting rid of the unsuccessful
(or incriminating) shots, and, perhaps, changing the orientation of
portrait-mode shots. Your editor has found that the family does not always
appreciate receiving full-resolution images from his 7 megapixel
camera, so the ability to rescale images is needed. Cropping is another
common task, both to remove uninteresting imagery or to fit a specific
aspect ratio. From there, one can get into color balance tweaking, red-eye
removal, noise removal, in-law removal, and advanced psychedelic effects.
A good image manager should make the simpler tasks quick and easy, and the
harder tasks possible - even if that just involves dumping the user into
An image manager should work well with the rest of the system; it doesn't
necessarily help to fix up an image if you can't find the result
afterward. An image manager which claims ownership over images and makes
them hard to find outside of the application is making life harder.
Similarly, some graphical users may appreciate a "move to trash"
capability, but the more grumpy among us still like files to simply go
away when asked, and have no use for a trash can; an image manager
should be able to make files just go away. A good image manager will make
printing easy, including selecting high-quality modes, printing multiple
images per page, etc. An added bonus for some users might be the ability
to quickly create a web page with a set of images. The ability to write a
set of images to a CD might also be useful for some.
Your editor reviewed five image management applications, and spent a long
day valiantly trying to build a working version of a sixth. Each tool was
used to work with its own copy of a directory hierarchy containing about
3000 photos taken over many years. This has been
a fun project; there is some good work being done in this area. Free image
management tools are still in a relatively primitive form, however; some of
them are maturing quickly, but there is some ground yet to cover.
Your editor reviewed DigiKam once before,
as part of a previous article on
camera interface tools. We'll return to digiKam (and
gthumb, below) to examine its image management capabilities. DigiKam is a
KDE-based application under active development; version 0.7.2 was released
on March 4.
DigiKam wants to organize images into "albums." An album is a simple
directory full of image files, though digiKam goes out of its way to hide
that fact. Files can be "imported" into an album from anywhere; if the
file comes from outside the album's directory, however, a copy will be
made. The importing process for a large tree of images can be slow, but it
only has to be done once.
A binary file (digikam.db) appears to track all of the
albums known to the application.
The digiKam window shows a pane with the album hierarchy, and a large area
with thumbnails from the currently-selected album. By default, the
thumbnails are annotated with the size of the image (only); the
presentation used consumes a relatively large amount of screen space.
Double-clicking on a thumbnail will produce a new window displaying the
The left-hand pane also includes an area called "My Tags." A few
predefined tags ("Events," "People") exist; adding others is easily done
with the menus. Clicking on a tag will bring up all images which currently
have that tag assigned to them. There appears to be no way to get a view
of more than one tag at once. Tags are hierarchical, but there is no
inheritance by default. So, for example, if you create tags for each family member
under "People," and assign those tags to images, clicking on "People" will
not display any of those images. There is a configuration option to change
this behavior, however.
Assignment of tags to images is done by way of a right-button menu attached to the
thumbnail images. There is also a separate "comments and tags" dialog
which, in addition to tag management, allows comments to be associated with
images. Both comments and tags are displayed underneath each thumbnail
Other dialogs available from the thumbnail view include a "file properties"
window and an EXIF information browser. The properties dialog allows the
name and permissions of the file to be changed; it will happily make an
image file setuid if you ask. There is also a histogram display which
gives information on color distribution in the image. The EXIF browser
provides full (read-only) access to the metadata stored within the image
file; it has a help window describing (briefly) what each EXIF field
The image window displays the picture itself, and provides a set of
editing options. Rotation, resizing, and cropping are done here; there
appears to be no way to constrain the aspect ratio of a cropped image.
Rotation of images in digiKam is not optimal: each image must be brought up
separately in the image window, rotated, then saved. When you've just
pulled dozens of images from your camera, you would like a quicker way to
get that job done. Your editor's research indicates that the image window
rotation is not lossless. There is said to be a plugin available
which can do lossless rotation, but your editor was not able to get it
Printing is a big hole in digiKam's capabilities. There appears to be no
option to print multiple images at once (much less N-per-page
capabilities). The image view window can print a single image, but it
requires the user to type in a print command. At this point in the
development of the Linux desktop, we can do better than that.
Like most KDE applications, digiKam is highly configurable; most users will
want to tweak at least a few options. By default, digiKam wants to use a
"trash can" when asked to remove images, but it can be convinced to simply
delete them instead. There
is also a plugin mechanism which can be used to add image editing tools.
In summary, digiKam is a capable and useful tool with a few remaining
shortcomings. Given its pace of development, chances are that those issues
will be ironed out in short order.
Perhaps the newest entry into the image management space is f-spot, currently at
version 0.0.12. It is a Mono application, written in C#.
Despite its youth, f-spot already shows considerable
promise, and is a useful application.
f-spot does not bother with albums, directories, or any such nonsense.
Instead, it implements a single, time-sorted stream of images with the
ability to sort on various types of metadata. Images must be imported into
f-spot before use, and the import process can be quite slow. After the
import process, the user gets a window with a list of tags on the left, an
information area on the bottom left, and a large pane with (possibly
thousands of) thumbnails. The thumbnails are not rendered until needed,
A feature unique to f-spot is a timeline at the top; clicking
on a given month will scroll the thumbnail window to pictures taken on that
date. The timeline is not updated when the thumbnail window is scrolled,
however, so the two can get out of sync. The sorting of images depends on
the date stored in each image's EXIF data; if that data does not exist, the
images are given the current date. There appears to be no way to fix an
image with a missing date, so it will be forever displayed in the wrong
Clicking on a thumbnail causes the lower-left window to be updated with
information on that image - date, resolution, and exposure information.
Once an image has been selected, a number of editing options are available,
including color manipulation, focus adjustment, and rotation. It is
possible to select multiple images (by holding down the control key) and
rotate them in a single operation.
There is a separate window which can be requested (from the "View" menu) to
look at the EXIF information stored in an image.
f-spot allows the user to assign tags to images in a manner very similar to
digiKam's. The application also implements the concept of "categories."
Your editor was not able to figure out what categories are supposed to do,
and how they relate to tags. It was impossible to create new top-level
tags (or categories). In general, the tag mechanism appears to need a
little work. At the basic level, however, it functions just fine: clicking
on a tag will narrow the thumbnail to images with that tag assigned; it is
also possible to narrow further to a specific date range.
It would be nice to be able to automatically attach one or more tags to
images when they are imported.
Double-clicking on a thumbnail replaces the thumbnail pane with the
selected image. It is, thus, not possible to view the thumbnail directory
and a specific image at the same time. At the bottom of the image window
is a line clearly intended for the entry of comments (though the comments
are used nowhere else). There is also a pulldown for the desired aspect
ratio; using the mouse, a box (constrained to the chosen ratio) can be
drawn over the image, and a click on the scissors icon will crop
accordingly. There is a red-eye removal option; the user must first select
an area to be affected. In your editor's experience, the selection must be
done very carefully, or the red-eye removal will leave obvious artifacts.
Given the nature of the task, it would be nice to be able to select
elliptical areas, rather than squares, for red-eye removal. There is also
a color editing dialog available. Nicely, the mouse wheel will quickly
zoom the image in and out.
f-spot handles image editing in an interesting way. The original image is
never overwritten; instead, f-spot creates a new version (called "modified"
by default). Different versions are selectable via a pulldown in the image
information area. Since f-spot seems to assume you'll never do anything
with the files directly, it feels free to give modified versions names
like "dsc00450 (Modified (2)).jpg".
There is a full set of "export" options for getting images out of f-spot.
Images can be exported, for example, to Flickr, to a web gallery, or burned
to a CD. The CD writing process seems to work, though some things are
unclear - does the program write the original form of an image, or the
modified form? The printing support in f-spot is minimal, relative to some
of the other tools reviewed here; there is little control over layout and it is easy
to get it to attempt to print pages which do not fit on the paper.
f-spot shows some clear potential, especially for those who like the
"tagged flat" method of organizing things. Its youth is apparent, but it
would seem to be growing up fast; f-spot is worth watching.
flphoto is a simple
image manager based on the FLTK toolkit. It may be suitable for those
looking for a lightweight application, but it has been left behind by the
competition in a number of ways. Your editor also found this application
relatively easy to crash. Version v1.2 was released in January, 2004;
there does not appear to have been a great deal of development activity
Like digiKam, flphoto works with the concept of "albums," into which photos
must be imported. Unlike digikam, however, flphoto cannot import a whole
directory hierarchy at once; instead, each directory must be fed to the
application separately. An album itself is really just a ".album"
file which contains a list of image file names.
The flphoto window consists primarily of an image viewing area. Thumbnails
are presented in a long, horizontally scrolling window at the bottom; they
show up in the order in which they were imported. Clicking on a thumbnail
brings the image itself into the main part of the window. To your editor's
eye, the quality of the image rendering is poorer than with other
Some image editing options are available, including rotation, scaling,
cropping (with aspect ratio constraints), sharpening, and red-eye
reduction. There is an "edit" option which fires up the GIMP on the
selected image. There is no way to rotate multiple images at once. There
is a "properties" window which shows basic EXIF information and allows the
entry of comments; those comments are not used for anything, however.
flphoto has no concept of tags, or of searching for images in any way.
Printing works well, with a fair amount of flexibility in how images are
printed, and even a simple calendar generator. There is a function for exporting
images to a web page; flphoto is not able to burn images to a CD.
Overall, flphoto is a tool with some capability, but your editor would
recommend that people looking for a new image management utility look
gthumb is a GNOME-based
application; in many ways it is the most fully-featured of the set. Unlike
many other image management applications, gthumb is very much
directory-oriented. It is happy working with any directory tree it is
pointed to; no need to create albums, import pictures, etc. It thus works
well for people who use other applications in their directory hierarchy, or
for those who simply want to get started quickly.
The main gthumb window should look familiar by now; it has the usual
directory pane and area full of thumbnails. The gthumb "folder" pane only
shows one level of the hierarchy, however, which increases the amount of
clicking required to wander around in a directory tree. A number of
operations can be applied to images in the thumbnail view; these include
lossless rotation, series renaming, and series format conversion. There is
also a tool for locating duplicate images.
Double-clicking on a thumbnail brings up the image view; it is not possible
to have thumbnails and a full image on the screen simultaneously. EXIF
information is available in the image view - if you happen to tell gthumb
to show "comments." There are reasonable tools for scaling and cropping
(with aspect ratio constraints), and a number of more advanced (but not
always useful) image manipulation capabilities. There is no red-eye
Tags in gthumb are called "categories"; they are not hierarchical. gthumb
supports comments on images; it also maintains the location of the image
separately. Dates for images are supported; they can be taken from the
EXIF information, the file date, or entered manually. The default,
however, is "no date," even if the image has EXIF metadata; getting gthumb
to actually use that metadata requires bringing up a dialog for each
image. There does not appear to be a way to change that unfortunate
gthumb has the most complete image searching capabilities of any of the
tools tested; if you take the time to enter metadata for your images, quite
a few search options are available. Searches can be done on any subset of the
file name, the image comment (it greps for substrings), the location, the
date (on, before, or after - there is no way to specify a date range
bounded on both ends), and the categories assigned to the image. If you
want to look for all pictures of Aunt Tillie taken at home since the
beginning of the year, gthumb can do it.
While gthumb normally works with the directory hierarchy, it also
implements "catalogs," which are its version of albums.
Images can be added to multiple catalogs at will.
A special catalog contains the results of the most recent search; those images can
be added, in bulk, to another catalog if desired. Thus, the search
mechanism can be used to create catalogs relatively quickly - if you have
your metadata in place. "Libraries" can be used
to create hierarchies of catalogs.
Printing support in gthumb is flexible, with the ability to print up to 16
pictures per page. What gthumb lacks (as do all the others) is the ability
to specify advanced printing options, such as print quality and paper
type. Since that is just the sort of thing one might want to adjust when
printing photographs, this omission is a true shortcoming.
KimDaBa (the KDE Image
Database) is the final tool which your editor was able to make work. It
has some powerful capabilities, but could benefit from some usability
work. KimDaBa 2.0 was released in October, 2004.
The first time a user runs KimDaBa, it asks for an image directory; all
images managed by KimDaBa must be kept underneath that directory. If the
number of images is large, the import process can take a very long time.
When, eventually, the user quits the application, it will ask "do you want
to save the changes?" without specifying what the changes are. If the user
elects not to "save the changes," KimDaBa will not write its special XML
file, and the whole import process must be done again the next time.
As it turns out, if you modify an image, KimDaBa will happily exit without
asking about saving changes, and those changes will be lost.
The initial window is dismayingly textual for an image manager. It gives a
few entries with names like "Folder" and "Locations"; the bulk of the
window, however, consists of lines like "View images (1-100) 100
images." Clicking on one of those lines will bring up a thumbnail view
with exactly 100 images in it. Images are sorted in no clear order; it has
little to do with the date or the underlying directory structure. The
default background is black (that can be changed), which is a little
KimDaBa does provide other ways of sorting images. The "Folder" line will
yield a flattened, directory-oriented view. Users can assign three types
of tags to images: "persons," "locations," and "keywords." There is a
separate view for each type of tag, allowing quick access to all photos of
a specific person, taken in a specific place, or with a given keyword attached to
it. The "search" line pops up a dialog which enables a search for a
combination of tags. There is also the ability to look at all images
within a given date range - but the date filtering does not work in
conjunction with the tags.
Clicking on an image pops up a window with the full image view. The image
window has options for assigning tags to images and for performing
rotation; there is no way to do rotation from the thumbnail view. There is
also a button on the properties window which will delete the image.
offers a "draw on image" option; it allows the user to add arrows, circles,
and squares (in black only) to the picture. It is not clear how this
capability would be useful.
KimDaBa does not provide a way to get at an image's EXIF information,
though it is able to use the date found there. In fact, the application
will not even display an image's resolution; there seems to be no way to
get that information. There is also no option to resize an image.
There is a bizarre "lock images" function which causes the application to
refuse to display them until the password is entered. Said password, as it
turns out, is stored, in plain text, in the "index.xml" file. It
would be better to leave out this sort of option; all it provides is a
false feeling of security.
KimDaBa offers no printing options at all, no web page export, and no CD
burning. There is an export operation; it creates a special file
which can be imported into KimDaBa running on another system.
Work continues on KimDaBa; it appears that version 2.1 will include a
plugin mechanism (presumably for image editing functions) and a date bar
similar to the one provided by f-spot.
One application which your editor was unable to make work is imgSeek. It is a Python
program; its unique feature is the ability to look for images which are
similar to a drawing made by the user. Version 0.8.4 of imgSeek was
released in September, 2004; development seems to be quite slow since
then. The version of imgSeek in Debian sid does not run as of this
writing. Your editor hopes that imgSeek is able to move forward; this
application's developers are trying to do some interesting things.
In general, there is a lot going on in this area. Clearly the time has
come for the free software world to produce some high-quality image
That said, none of the tools reviewed here can truly be said to be
complete, and your editor will resist the temptation to pick a "winner"
from the set. Printing support is, perhaps, the weakest area at the
moment; Linux now has the capability to provide a great deal of control
over printing, but the image managers are not yet using it. Still, the
applications reviewed here have reached the point where they are useful
tools. It will be fun to see where they go from here.
Comments (67 posted)
Page editor: Rebecca Sobol
Inside this week's LWN.net Weekly Edition
- Security: Buffer overflows in XV, Main AGNULA Host attacked, New vulnerabilities in cvs, htdig, logwatch,
monkeyd, Firefox, Mozilla, MySQL, php4, squid, vixie-cron, XV.
- Kernel: Starting quickly with git; Big-endian I/O memory; KProbes.
- Distributions: Checking in on Componentized Linux; SUSE Linux Professional 9.3; Archie
- Development: Debugging free Java with SableVM and Eclipse,
new versions of Glom, Samba, libannodex, mod_annodex, Ghostscript, Catalyst,
phpBB, Ardour, GNOME, GTKWave, Eris, Wine, Amuc, OpenOffice.org, Firefox,
- Press: Getting Flat, Fighting anti-Linux FUD, Lack of OO.o developers,
LWCE coverage, SCO blames Groklaw, Brazil's PC Conectado program,
Munich picks Debian, Hardening the system, Audacity review.
- Announcements: ESP Print Pro 4.5.4, OPERA 8, new CVS for Fedora Extras, injunction against
Fortinet, CUPS Manual, Fibre) Channel State of the Union, Patent Resources,
RPM build guide, LAC streams, Hack.lu, PAKCON II.
- Letters: I don't think pushing readers' buttons is very nice