LWN.net Weekly Edition for February 12, 2004

A grumpy user's browser review

An LWN editor's job requires spending vast amounts of time each day operating a web browser. As a result, we have become very sensitive to browser features which make it easier to get things done - or which get in the way. In an effort to find a better tool for the creation of LWN, your editor decided to spend some serious time working with some of the current crop of web browsers. With luck, it was hoped, the least evil browser could be identified and used on into the future.

One note before we get going: Konqueror is not included in this review. Konqueror is a highly capable browser (and file manager) which is worthy of consideration, but it suffers from one fatal flaw (from your editor's point of view): it will not run without the whole KDE infrastructure running behind it. Your editor is not currently a KDE user, so Konqueror is not an available option.

This effort was motivated at this time in particular by the announcement of the Mozilla Firefox 0.8 release. Firefox is the new name for the browser formerly known as "Firebird." Those who are curious about the name change can peruse the "brand name FAQ" and this weblog entry describing the lengthy process involved in changing the browser's name.

We'll start, however, with Galeon, which has been your editor's browser of choice for some time. Galeon has been slowly falling out of favor, however, since the 1.3 branch was begun and all the work that went into making 1.2.x a top-quality power user's browser was thrown away. Galeon 1.3 suffers from the GNOME "don't confuse those poor, helpless users by letting them configure things" disease - though it is possible to have more control if you know the proper secret gconf registry codes. Even so, some nice 1.2 features, such as the ability to configure the toolbar for maximal functionality in minimal space or remembering the preferred zoom level for each site, are still missing.

The real problem with 1.3.x, however, is the seemingly endless series of Weird Bugs. The bookmark editor has not worked well for a long time, and rearranging bookmarks can result in strange little windows with URLs in them floating across the screen long after the user has moved on to other tasks. The "type ahead find death grip" has caused your editor to put his fist through more than one monitor while attempting to fill in web forms. The browser grows without limit; it usually has to be killed and restarted around when it hits 200MB or the entire system slows to a crawl.

Despite all these complaints, Galeon has served well for a long time, and will be a hard browser to beat.

The Mozilla Firefox 0.8 release is easy to download in binary form and install. The initial impression it made was not the greatest, however; Firefox appears to be unable to find or use the beautiful Bitstream Vera antialiased fonts that Galeon uses so happily. The result is an ugly, hard-to-read screen which is reminiscent of the old Netscape 4.x days. Firefox behaves this way on Debian sid and Red Hat Linux 9 systems. Comments from others suggest that this is a problem that can be overcome, but it is clearly not a straightforward thing to do. Update: as noted by a few commenters, the fix is to install the "gtk2+xft" version; it can be found on the FTP site but is not mentioned on the download page.

The browser also makes an immediate impression, however, for its speed. Even when freshly started, current versions of Galeon are not so zippy on your editor's desktop. Firefox seems robust; a day's worth of serious browsing failed to turn up a single site which crashed the browser or which did not render properly. Most of the features one has come to expect in a modern browser (tabbed browsing, search fields, printing, bookmark editing, password management, javascript, history tracking with search, etc.) work well. Firefox gives a relatively high degree of control over things like popup windows and active content; there is a list of actions which can be allowed or denied to Javascript scripts, for example. Firefox has far more theme support than the other browsers reviewed.

The browser's process size appeared to stabilize at "only" 98MB; huge by any rational standards, but Galeon has a hard time putting up its splash screen with that much space. Firefox appears to have a solid base at this point.

That said, some things are missing. At the top of your editor's list is the ability to control image animation. One forgets how annoying the web can be with things bouncing around the screen; Firefox provides no evident way to turn animation off. The download manager is a little strange; it provides no way to place a file in an arbitrary directory at download time. Instead, you have to choose a single download directory via the configuration dialogs and everything will go there. By default, downloaded files go into the home directory. Control-T creates a new tab, as one might expect, but it comes up blank; Galeon's practice of bringing up the home page in new tabs seems preferable.

All of the above items would appear to be fixable with a (relatively) small amount of effort. Firefox may not be ready to displace Galeon from your editor's desktop, but it's not far from that point either.

Once this process was begun, it seemed logical to give Epiphany 1.07 a spin as well. Epiphany makes a first good impression; the toolbars are clean and don't take up a whole lot of space, and antialiased fonts are the rule. It's a nice-looking browser. Epiphany, like the other browsers, also offers the usual set of expected features.

Epiphany's configuration dialog is the most sparse of the three browsers reviewed here. It does provide control over the toolbars, which is nice, but many other things are missing - including that all-important control over image animation. There also does not appear to be any sort of explicit control over popup windows. Another obnoxious little limitation with Epiphany is that it does not allow a URL to be "pasted" into the browser with the middle mouse button - a feature supported by both Galeon and Firefox. Epiphany 1.07 suffers from the "typeahead find death grip." Given that many users probably do not use the typeahead find feature at all, it sure would be nice to have an (obvious) way to turn it off.

Epiphany also manifests some strange behavior when the user types a URL into the location field and there are multiple windows open: completion windows show up on each browser window and must be chased away individually. Epiphany grew to over 100MB during a day of testing, and appeared to be set to continue to inflate. It bloats far more slowly than Galeon, however. Beyond that, however, Epiphany seems stable; your editor could not make it crash.

Epiphany is closer to Galeon than Firefox in rendering speed: generally good enough, but not strikingly fast. To try to get a handle on things, we ran an ultra-scientific test: see how long each browser takes to render a local copy of this page, which consists of a huge table listing vulnerabilities and alerts from 2003. Epiphany and Galeon consistently required about 6.5 seconds to present the page; Firefox can do it in 5.4.

Perhaps the most striking realization from this whole exercise, however, is just how similar these three browsers are. The fact that they all use the Gecko rendering engine will certainly create a degree of uniformity, but the resemblance goes beyond that. Your editor often had to look carefully to see which browser was in use at any given time. To a great extent, they can be substituted for each other; the differences between them come down to little nits and pet peeves.

One might well wonder why three groups of people are working so hard to build complex applications which resemble each other so strongly. If we are going to have multiple Gecko-based browsers, it would make some sense for them to differentiate themselves somehow. Why can't one of them be the power user's browser, providing full control over every aspect of its operation without fear of confusing the user with too many configuration options? Couldn't one of them be an experimental browser, trying out interesting new ways of presenting the web to users? We could dedicate one project to each of those goals, and still have one trying to do the Same Old Stuff in the best way possible. As it is, each of the three browsers reviewed is an advanced and capable application, but it is increasingly hard to find a reason to choose one over another.

Comments (104 posted)

SCO update

SCO and IBM had a new day in court on February 6, when a hearing was held to determine whether SCO had complied with IBM's motion to compel discovery. IBM's position is that SCO has failed to comply. As of this writing, the judge has not made a ruling. The preliminary indications from the transcript of the hearing (available on Groklaw, of course) do not bode well for SCO, however.

IBM noted in court that SCO is no longer alleging any sort of disclosure of trade secrets on IBM's part. SCO did provide a small number of files and line numbers of Linux code which, it says, violates IBM's contract with SCO. These files were in the expected parts of the kernel: the read-copy-update code, the JFS filesystem, etc. In every case, the code in question was indisputably written by IBM, and is owned by IBM. Some of it is even patented by IBM.

In other words, as we have noted in the past, SCO has been pushed back to one of its original claims: that it has the right to control the disclosure of any code which has ever breathed the same air as SYSV Unix. IBM sees this, of course, and isn't making it easy. From the hearing:

The point, of course, is that code independently written by IBM does not derive from SYSV Unix at all. This point has been fairly clear to people who have been paying attention for some time. For the rest (i.e. SCO and the bulk of the news media), IBM has to work to get the idea across.

SCO has also requested permission to amend its complaint against IBM yet again. If this change is allowed, it will modify the case in some interesting ways. Much noise has been made in the wider media about the addition (finally) of a copyright infringement charge. This charge says nothing about IBM's contributions to Linux, however; instead, SCO claims infringement because IBM continues to distribute AIX despite having had its license "terminated" by SCO. Unless SCO can convince a court that IBM has breached its contracts with SCO, this charge will evaporate.

The charges of export violations have been fleshed out. It seems that SCO has concluded that IBM's contracts never gave it the right to distribute Unix code in India. Since Linux is clearly available in India, SCO concludes that its contract has been breached yet again.

Perhaps most amusing is the new claim of "interference with contract." Those who have been following this case will recall that Novell has made some interesting claims, including (1) that it still owns the Unix copyrights, and (2) that it has the right to keep SCO from terminating Unix licenses. SCO, it seems, sees the shadowy hand of IBM behind Novell's actions, and is now charging IBM with causing Novell to act the way it has. Novell's own interest in the success of Linux seemingly does not enter into this picture.

Finally, as noted above, the latest version of the complaint deletes the charge of "misappropriation of trade secrets" which had appeared in earlier versions.

Novell, meanwhile, has sent a new letter to SCO in an (undoubtedly IBM-directed) attempt to clarify its view of the "derived works" argument. Novell has dug up some old communications from AT&T regarding its interpretation of the Unix licenses and some changes the company made to make that interpretation more explicit:

SCO's view of derived works never did seem likely to stand up in Court, but Novell has thrown up yet another obstacle in SCO's path. Novell also pulls out its "override clause" from the asset purchase agreement:

That deadline has passed as of this writing. One assumes that SCO did not comply.

Novell has also filed a motion to dismiss SCO's "slander of title" suit against it, and another motion to move the case (in case it is not dismissed) to federal court.

For those who are curious about the Red Hat (Delaware) case: it remains on hold until the judge gets around to ruling on SCO's motion to dismiss the suit. The wheels of American justice never move particularly quickly, but Delaware seems to be especially slow.

The Open Source Development Labs has published another paper on SCO by Eben Moglen; it is available in PDF format. This one is about the Novell suit:

Finally, Don Marti has noted that the Canopy Group has removed all mention of SCO from its web site and appears to be generally backing away from SCO. Perhaps Canopy, too, sees the end of the game on the horizon.

Comments (7 posted)

OSDL Looks at Linux for the Data Center

The Open Source Development Labs (OSDL) released their second capabilities document for Linux last week, and is asking for input. The Data Center Linux (DCL) Technical Capabilities 1.0 document is about 119 pages long (available in PDF) and defines and rates Linux capabilities needed for Linux in the data center. The DCL Technical Capabilities document is, to say the least, comprehensive.

This document has been quite some time in the making. The DCL working group was announced by OSDL in August, 2002. The document contains evaluations for hundreds of Linux features in eight categories; Scalability, performance, RAS (Reliability, Availability, Serviceability), manageability, clusters, standards, security and usability. The evaluations are ranked by maturity level, ranging from "investigation" for projects in the concept phase, to "completed" for features or projects that are available and fully adequate for customer needs. It provides quite a comprehensive picture of the state of Linux for use in the data center, and a roadmap of where it needs to go.

We spoke with OSDL CEO Stuart Cohen and OSDL strategic marketing manager Lynn de la Torre about the capabilities document, how it was put together, and what OSDL plans to accomplish with the capabilities document. According to de la Torre, the DCL Technical Capabilities document is designed to help OSDL and its members "solidify our priorities," with regards to Linux usage in the data center, and to get feedback on the priorities listed. She noted that OSDL was interested from hearing from the community at large on the priorities as laid out in the document.

We asked de la Torre how OSDL would try to see that the features outlined in the DCL Technical Capabilities document would be implemented, since OSDL doesn't have the resources to do all of the work itself. She said that it would be up to OSDL members and the community to work on the features needed for data center Linux.

De la Torre also acknowledged that the scope of this project was much more broad than the Carrier Grade Linux project:

She noted that OSDL is now looking for public feedback on its priorities for DCL. Anyone interested in participating in the working group can find the details here. She also said that the work done so far by OSDL's members indicates that Linux is ready for the data center, though more mature in some areas than others.

Since the DCL working group is following a similar path to the Carrier Grade Linux working group, we asked Cohen how successful the CGL project has been:

We also asked Cohen how OSDL's legal fund was progressing, and what happens to the money in the event that SCO doesn't sue anyone. Cohen said that OSDL has raised over $3 million so far with a goal of $10 million. If the money isn't used for legal fees, Cohen said that it will probably be kept in place until the board sub-committee in charge of the fund decides the "best use" for the fund.

For those more interested in Linux on the desktop, OSDL has also announced a working group for the Linux desktop. This is in the early stages of development, and Cohen says that anyone is welcome to join, once the project has been officially launched. Cohen said that OSDL would be having the kick-off meeting for the desktop group next week. Like the CGL and DCL working groups, participation should be open to anyone through the mailing lists.

Comments (none posted)