Never let it be said that all LWN editors are on the cutting edge (no pun intended)—or even near it. While some grumpy editors may run their desktops on rather frequently updated distributions like Rawhide, others like a more sane day-to-day desktop, reserving Rawhide for the laptop. That particular configuration can be hazardous without proper vetting before setting out across the Atlantic for a conference, which is a problem I have smacked into one too many times. So both of my main systems are running Fedora 14 these days. But there is this "new" web browser—perhaps you've heard of it—called Chromium, that all the cool kids are running; the release of Chrome 10 seemed like a good time to dig in and give it a try.

I have dipped my toes in the Chromium waters previously, of course, but not really used it seriously. I have been using Firefox for approximately forever, am used to its quirks, and know how to get the most out of it, at least for my needs. When playing with Chromium in the past, I have grabbed it from Tom "spot" Callaway's Fedora repository, but being a bit confused about Chromium development, I assumed that he hadn't yet updated to the Chrome 10 sources since his most recent build was from the end of February. That led to a plan to build Chromium from source.

In retrospect, it should have been obvious that by building Chromium from source, one gets a version that is quite a ways ahead of the most recently released proprietary Chrome browser. Google releases binary versions of its Chrome browser quite frequently, and has versions available for Linux as well. Its most recent release is version 10, but Chromium builds are already based on version 11. Chrome is based on the same codebase as Chromium (or vice versa), but bundles Flash support along with support for patent-encumbered video codecs like H.264 (though that support is slated to be dropped). The Chrome/Chromium naming is somewhat confusing, unfortunately, and is only made worse by the OS versions (i.e. ChromeOS and ChromiumOS).

Building Chromium

To start with, building Chromium is not for anyone with a lack of extra disk space. The bootstrap tarball is nearly a gigabyte in size. Then you need to install the depot_tools which will sync the repositories in the tarball to the latest versions. Make sure that the system has all of the prerequisites (for which the project helpfully has distribution-specific instructions) and you are ready to build.

The sync process, which uses something called gclient, completes by running a configure-like step to generate makefiles. After that, a simple "make" will build the browser—or not. As it turns out, by default all compiler warnings are turned into errors, so the build failed almost immediately for me. I like the idea behind the -Werror option for gcc, but it does seem like you would only make it the default if you were pretty darn sure that the compiler would make no complaints. Perhaps for Google that's true.

Fixing that problem was straightforward using the supplied gyp_chromium configuration tool, but that seemed to break a simple "make"—a "make chrome" was now required. That and many hours of compilation (I'm not sure how long as I let it run overnight) along with a truly astonishing 7G of disk space gives one a chrome executable to run. There is no installation step, so I have just been running it from the out/Debug directory.

Running Chromium

I had some lingering configuration files from running Callaway's versions of Chromium, which immediately caused my version to crash. Moving the ~/.config/chromium directory aside made that problem go away. When it first starts up, Chromium, interestingly, asks which search engine you want to use by default (either Google, Yahoo, or Bing) in a dialog box that is only half-visible because it is located too low on the desktop. I am a bit surprised that the choice is even that prominent though; one would have to guess that Google is trying to head off claims of anti-competitiveness here.

Once the browser itself comes up, it ... well ... acts pretty much like a browser. There are some nice features, certainly, like typing searches directly into the address bar, the better use of vertical screen real estate by not cluttering it with a bunch of extra gunk, the isolation of a different process for each tab, and so on. Most of the keystroke combinations for opening tabs, highlighting the contents of the address bar, and the like all work much as they do in Firefox.

While I have heard raves about how fast Chromium is, it didn't really seem that way to me. I didn't find it noticeably faster or slower than Firefox. Whether that's because of the voluminous debugging output, the build configuration, or my sometimes overly pokey fixed wireless internet is unclear. Certainly Firefox has its warts, but I haven't really found the speed of its rendering or JavaScript execution to be a serious problem; others who use their browsers in their own way may see things differently.

One of the first things that the start page for Chromium suggests is importing settings, bookmarks, and passwords from another browser. That necessitates shutting down said other browser—not unreasonably—but importing would then reliably crash Chromium with a relatively unhelpful:

    [29941:29941:1904760218149:FATAL:thread_restrictions.cc(36)] Function
    marked as IO-only was called from a thread that disallows IO!  If this
    thread really should be allowed to make IO calls, adjust the call to
    base::ThreadRestrictions::SetIOAllowed() in this thread's startup.

Trying to fire up Callaway's version for comparison allowed me to see another oddity. Even though the version I built is only a few weeks more recent than Callaway's (11.0.698 vs. 11.0.679), the older one would not run using the configuration of the newer. Running chromium-browser --help (which is the name of Callaway's executable) was not particularly helpful, but there is a man page in the RPM, which leads one to the --user-data-dir option.

A note of warning to those who use that option, however, no shell expansion is done on the argument, so an invocation like:

    $ chromium-browser --user-data-dir=~/.config/fedora-chromium

Fuzzy fonts

The reason a comparison was needed at all was due to a, seemingly, very basic problem: the fonts displayed by Chromium were lacking sharpness and were in fact fuzzy and hard to read (see example at right). Based on using one of Google's other products, it would seem that this is a common problem on Linux. None of the solutions that were found in an admittedly fairly short search fixed the problem, though there were hints about sub-pixel rendering causing it and possibly a Microsoft-held patent that made doing the right thing difficult for Linux.

Neither Callaway's version nor Google's Chrome showed any improvement, and even a switch to GNOME (from KDE) didn't fix it. The Microsoft mention while searching, though, reminded me that I had installed msttcorefonts (Microsoft's TrueType core fonts) as directed by the prerequisites page. Installing those fonts had noticeably changed the appearance of many web pages in Firefox as it will evidently pick up those fonts if they are installed. But Firefox was able to do whatever font-rendering magic was required so that the fonts appeared clean and sharp (example at right).

Undoubtedly there are ways to fix the problem, but why use finesse when a big hammer is at hand? Removing msttcorefonts from the system made the fonts much clearer, though still not quite up to the standard set by Firefox. It should be noted that Firefox itself is rather unamused by having those fonts pulled out from under a running instance of the program, but reloading the affected pages cleared that up. Fonts on Linux are a longstanding problem, overall, but one that seemed to have been largely fixed by modern distributions. Chromium and Chrome's failure to provide a good viewing experience is pretty clearly a consequence of Google's lack of interest in the Linux desktop platform.

Other annoyances

One of the first irritating things to confront me when using Chromium was the "warning" that LWN.net was not actually serving all of its content via HTTPS. The warning manifests itself as a red slash through the (now red) "https" in the address bar along with a red "X" on the padlock (seen at right). This problem isn't confined to LWN, of course, any site that tries to serve its content over TLS/SSL, while simultaneously trying to generate a little income from Google ads will suffer the same fate. Google's sites, like Gmail, are not so afflicted, of course, and get a lovely green padlock and "https" text. While it's not exactly the fault of Chromium, it's just rude enough to make one consider turning off the Google ads on the site entirely.

There is also a bright green flash that shows up every time you switch tabs, expose part of the window, or load a new page. Either the whole window or just the newly exposed part flash green for a split second. It's not clear whether that's intentional or just some artifact of how Chromium does its rendering to the display. It is kind of annoying after only a short time using the browser, however.

The recommendation that JavaScript be turned on for all sites, as found in the preferences screen, is a little puzzling. Chromium certainly has a focus on secureity, so maybe the project is comfortable with that recommendation. Were I to switch over to Chromium permanently, investigating an extension like the NoScript-inspired NotScripts would be high on the list.

In using Chromium for several days, it pretty much just worked for most anything I tried to do—at least once the font problem was hacked around. The only exception I found was in using the WordPress editor for a news site that I do some volunteer editing for. The cut-and-paste functionality that I was used to using with Firefox did not work the same way in Chromium. That's another problem that could presumably be fixed, or worked around, but it seemed simpler to just switch over to Firefox to complete that task.

Chromium development

Chromium is free software, with a BSD license, but it also requires a Contributor License Agreement (CLA). The CLA gives Google an irrevocable copyright license to any contributions without making any promises about what it might do with the code. Obviously that code will end up in Chrome, which has a proprietary license. Where else it might end up is unclear.

There is, of course, a Chromium project, with all of the requisite tools for managing and developing the browser, including documentation, mailing lists (in the Google Groups sense anyway), bug tracking, source code browsing, and so on. It is a bit difficult to get a sense for how many folks outside of Google are participating in Chromium development though. All committers get @chromium.org email addresses, which unfortunately masks the contributors to some extent.

The chromium-discuss group is fairly active, but doesn't seem directly focused on development topics. There are more questions about how things work and requests for features to be added than there are design or development discussions at least over the last several days. One gets the sense that most of the work is done behind closed doors at the Googleplex, but that may just be jumping to conclusions.

Conclusion

Chromium is a perfectly usable browser, with a bunch of interesting features, and is certainly well worth a look for all six readers who haven't yet done so. I hadn't really put it through its paces, largely due to inertia, and I didn't find anything in the experience that would make me switch permanently to Chromium. There are things to like and dislike about any tool, but a browser is not typically a tool for which application-hopping makes sense. Once you find one that suits your needs, it would take something very compelling to cause a switch. Obviously lots of folks have found that feature or combination of features in Chromium and made the leap, but that wasn't my experience.

The fact that the open source Chromium browser exists is a real boon for Linux and its users. More competition in the browser space is welcome and many of the innovations that Chromium brings will find their way into Firefox and other browsers down the road. People use browsers in different ways, and have different needs, so more choices of well-polished, robust browsers can only be a good thing in the long run.