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
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
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
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
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.
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.
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 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
, of course) do not bode well for SCO,
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 notion is, Your Honor, that somehow IBM is prohibited from
disclosing that code because in some way it is derived from Unix
System Five. What we asked for in our responses is that they tell
us, if that is the theory, exactly where it is in Unix System Five
that the code derives from.
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
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
AT&T then followed up by adding to section 2.01 a sentence
clarifying that AT&T "claims no ownership interest in any
portion of such a modification or derivative work that is not part
of a SOFTWARE PRODUCT." Even more clearly, the August 1985 edition
of $ echo explained that this "sentence was added to assure
licensees that AT&T will claim no ownership in the software
that they developed -- only the portion of the software developed
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:
Accordingly, pursuant to Section 4.16(b) of the Asset Purchase
Agreement, Novell hereby directs SCO to waive any purported right
SCO may claim to require Sequent (or IBM as its successor) to
treat Sequent Code as subject to the confidentiality obligations
or use restrictions of Sequent's SVRX license.
Novell directs SCO to take these actions by noon, MDT, February 11, 2004,
and to notify Novell that it has done so by that time.
That deadline has passed as of this writing. One assumes that SCO did not
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:
Even if one is unsympathetic to SCO, one can't help but feel sorry
for the quandary its lawyers faced in deciding whether to sue
Novell. Had they not done so, their client's ultimate fate would
have been sealed. But suing Novell destroys SCO's licensing
campaign for the present just as fully.
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
Comments (7 posted)
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,
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.
What we're doing is trying to leverage our membership as much as
possible. Our membership is growing and we are trying to really drive it
from the point of view of the member companies. If we can all get on the
same page, if you will, that's probably the best way we've come up with so
far to do that.
De la Torre also acknowledged that the scope of this project was much more
broad than the Carrier Grade Linux project:
Part of why we have to do a capabilities [document], in the first place and
why we think the first step is prioritization, is exactly for that reason,
which is that the data center is almost what I call 'boiling the ocean,'
it's so broad yet we've gone so deep in our analysis. 350 items is a pretty
large thing to look at, so obviously no technical project can address
something that big so that's why we especially feel that prioritization is
key to go forward.
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
On edge and infrastructure, it's very mature. In database it's emerging and
in some areas it's almost completely there...the overall message is that
it's ready for the data center, especially if you look at 2.6 and some of
the functionality in 2.6.
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:
I think it's been very successful. If you just look at the number of RFCs
around the world that telecommunications equipment manufacturers or
carriers have been issuing related to carrier grade initiatives, it's been
extensive. That work is really an outgrowth of work done by Nokia, Alcatel,
Ericsson, Cisco, MontaVista, so... a number of industry players have been
involved in that definition. That is the biggest reason that NTT joined,
and we have many carriers and other telecommunications equipment
manufacturers interested in participating because they want to take a
leadership position in putting together those requirements and
registrations and specifications going forward.
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
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
Comments (none posted)
Page editor: Jonathan Corbet
Next page: Security>>