Leading items

LCA2005: The state of Debian

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 one-year term.

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.

Project 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 be interesting.

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 schedule.

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)

How Tridge reverse engineered BitKeeper

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 than that.

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
    Trying 69.25.196.29...
    Connected to thunk.org.
    Escape character is '^]'.

Once connected, why not type a command at it?

    help
    ? - 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 guidance?

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 era.

Comments (23 posted)

Security in Firefox

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:

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.

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)

The Grumpy Editor's Guide to Image Management Applications

This article is part of the LWN Grumpy Editor series.

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 publication.

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 appropriate.

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 the Gimp.

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.

digiKam

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 image itself.

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 image.

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 means.

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 installed.

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.

f-spot

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, thankfully.

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 place.

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

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 since then.

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 applications.

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 elsewhere.

gthumb

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 removal, however.

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 default.

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

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 jarring.

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. Amusingly, KimDaBa 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.

Conclusion

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 management applications.

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)