LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for February 12, 2004A grumpy user's browser reviewAn 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.
SCO updateSCO 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 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 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:
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
by AT&T."
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 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:
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 the horizon.
OSDL Looks at Linux for the Data CenterThe 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.
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 others.
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 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.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||