February 23, 2019

gnotebook: Bugs, Press Releases, and Molasses: The GNOME 1.4 Launch Considered

The Medusa Issue

  • April 6, 2001
  • By Michael Hall

GNOME 1.4 lurched into release first on Monday with an announcement from the GNOME Foundation, then again on Tuesday, when the release team sent out a mail declaring 1.4 well and truly released and ready.

It was a puzzling release to figure out, in part thanks to a last minute bug in Medusa, a package that plays an integral part of Nautilus by providing an file system indexing feature. The development team had discovered leaking file descriptors that eventually hobbled the performance of the indexing daemon, which might have answered a few questions that had popped up on the Nautilus list regarding serious speed hits even well-configured and relatively powerful machines were suffering when the package swung into action via its cron jobs.

Armchair software analysts were in action almost immediately, as is their wont, demanding to know what the point of Medusa was in the first place. There are already tools present on most Linux machines that handle the sort of thing Medusa appears to have been designed for on the most superficial level, such as locate, which the more cynical among us might point out already does a very good job of confusing newbies who are still awake at two or three in the morning when it goes to work thrashing the hard drive to update its database of file locations.

There's a certain lack of charitability present in complaints and interrogations like this, because they almost always imply that the engineers who are building tools like Medusa are still wet around the ears and out to reinvent wheels. The conspiracy-minded usually also take a few seconds to imply there's some sort of covert attempt at a proprietary lock-in present in the whole scheme by introducing a heretofore unknown piece of software into the mix. That's reflective of some effective scare-mongering on the part of many misguided enthusiasts who assume that if a thing's function isn't readily apparent to them, it's probably closed and proprietary. If you're in doubt that this goes on, consider the tired old meme that RPM is a "proprietary format," which always disregards two interesting facts: RPM itself is GPL'd, and RPM's themselves can be cracked open fairly easily with cpio. If Debian's willing to include rpm and librpm in its distro (and it does), I'm inclined to think that settles most of the argument. That doesn't ever seem to stop people, though, whenever Red Hat makes any other mistake and a new pile-on is underway.

Chalk it up, I suppose, to an ongoing bit of schizophrenia in the Linux world where the issue of how to treat people out to make money with Linux is concerned. Most of us are at least reconciled to the idea. A few still struggle with it.

The point of Medusa, though, isn't to reinvent locate in such a way that we all become dependent on a Trojan Horse with a cooler name and end up being forced to bow down before Eazel. It's there because Nautilus depends on a layer of information locate doesn't provide: update times, some file contents, and an additional layer Nautilus itself provides: the rather useful file labels that allow you to flag documents as "important" or "personal" or whatever else you can come up with that might make keeping your work organized. The net result is the ability to create something very similar to Evolution's virtual folders, a grouping of file information by data besides the filename that's been assigned to it. For this kind of thing to work and be useful, it's got to be provided quickly and easily.

I think it's a good idea. My ~/work directory is home to over 1500 files in the form of past articles, notes, and screenshots in about 20 subdirectories. Careful file naming conventions over the past few years give me a handle on some of it if I choose to tackle this information from the console with conventional shell tools, and the rest is usually sorted out by virtue of the fact that I'm an Emacs addict and depend on a remembrance agent to help me figure out what past work is relevant to my current work in progress. People who do that aren't the point of things like Nautilus, which is there to make life easier on people who don't want to deal with that sort of thing.

Regardless of how good an idea it is, though, Medusa had to come out of the 1.4 release thanks to those leaking file descriptors. In a mail to the Medusa list, Rebecca Schulman, Eazel's lead on the project, outlined several courses of action where this particular component is concerned. For the foreseeable future, it looks like Medusa is going to be sidelined, because the bug that caused the initial holdup isn't the only issue. There are also security concerns that come up with a program that does such a thorough job of indexing everything on your machine, especially on multi-user systems.

As with everything in a multi-user operating system with a modicum of care where security is concerned, there are some conflicts between the holy grail of usability and good practice. Most of us who have been around for a while are used to dealing with these conflicts without much of a thought. We set up "normal" user accounts to protect us from the inevitable disaster that will occur once we get too comfortable being the root user all the time. We set up aliases for common root user operations that start with 'su -c' so we can save a few inconvenient keystrokes but remain shielded from anything too hasty, or we impose a discipline on ourselves that involves resolving to always have to log in as root to do anything to the system.

A lot of people disagree that the presence of a superuser in the Linux world is any kind of usability hangup at all, and for the most part there are ways to engineer around this to minimize the difficulty it might impose. It's still a bump in the road, though, and the mail Ms. Schulman sent out expresses fairly directly where this particular bump will need to be addressed in Nautilus. If you have any doubts that the people over at Eazel are thinking hard on a sane resolution to the conflicts ease of use and good security present, read her mail, or any thread on the Nautilus list. Though I try to remain sensitive to the needs of newbies and inexperienced computer users in general, it's pretty clear to me that the Nautilus team is keyed in to usability issues in a way I haven't managed since some time around the quiet strangulation of DR DOS.

Most Popular LinuxPlanet Stories