Dedication

This LWN.net Weekly Edition is dedicated to the people of Japan as they work to recover from the terrible events which have overtaken them. LWN has a lot of friends in Japan; you are all constantly in our thoughts.

Comments (1 posted)

The world of Chromium

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.

Earlier messages in the trace indicate that it may be a problem trying to talk to KWallet, but neither Callaway's version nor Google's Chrome binary had any problems of that sort.

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

will not do what one might expect. Instead of tossing its configuration directory below your home directory, it will create a "~" directory in your current working directory—with all of the amusing chaos that can result.

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 security, 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.

Comments (72 posted)

Turning VistA into a "real" open source project

The US Department of Veterans Affairs (VA) is exploring the creation of a "custodial agent" to govern the development of VistA, its popular open source electronic health record (EHR) platform. VistA exists as open source code because it is in the public domain, and a successful ecosystem of VistA-based projects and companies has grown up around it offering EHR services, but without the governance and infrastructure of a "real" open source project.

High-angle view on VistA

VistA was developed slowly by the VA, beginning around 1977. In its current form, it consists of more than 100 individual applications handling discrete EHR tasks, including prescriptions, medication dispensing, clinical orders, doctors notes, tracking test results, and many more. It is used by the VA's network of more than 1000 hospitals, clinics, and medical facilities, and is regarded as one of the key factors behind the Veterans Health Administration's top ratings on patient satisfaction and quality of care — regularly beating out Medicare, Medicaid, and private health care services.

In addition to its use by the VA, VistA was adopted as the core of the US Department of Defense's Composite Health Care System (CHCS), the Indian Health System's Resource and Patient Management System (RPMS), Finland's MUSTI Consortium, and a number of non-governmental institutions. Several open source projects packaging VistA for deployment have developed over the years as well, most designed as commercial products created by system integrators that offer support services and add-ons, such as OpenVistA by Medsphere and vxVistA by DSS. The WorldVistA non-profit organization was established in 2002, and packages its own version, called WorldVistA EHR, in addition to providing discussion forums, documentation, and resources for adopters.

In spite of its popularity, VistA deployment is not simple. Modules are written in the healthcare-tailored language MUMPS, which offers its own database functionality that is not compatible with general-purpose relational databases. This is not a relic inherited from VistA's age, either: as VistA architect Tom Munnecke explains, relational databases' row-and-column table requirements simply are not compatible with the large structures needed by EHR, starting with the fact that EHR records are extremely sparse (consider, for example, that the non-null entries in a single patient record constitute only a tiny fraction of the set of all possible medical diagnoses).

In addition, the VistA code is in the public domain because it is taxpayer-funded — available courtesy of the Freedom of Information Act (FOIA) — but this is a long way from a truly open source project: APIs and ABIs are not formally specified, the documentation is slim and infrequently updated, and there is no mechanism for downstream VistA users to request enhancements. While the WorldVistA group helps fill in some of these gaps, the VistA community has long lobbied for a more formal solution.

Requesting information

In recent years voices within the VA itself began to voice frustration at the slowing pace of VistA development. VA CIO Roger Baker told the FierceGovernmentIT blog that the EHR marketplace had changed considerably since VistA's early days, and that private sector players are creating features that the VA would like to incorporate into its own system — and producing them far more rapidly than the VA.

Baker's proposed solution was to transform VistA into a publicly-run open source project in the traditional sense, incorporating non-VA VistA users into the design and development process. "One of the things that has slowed down innovation is that about 10 years ago, the VA centralized development of the VistA applications in a software development group", he said. In August of 2010, the VA issued a formal request for information (RFI) to solicit input from the public in "evaluating the viability of including Open Source (OS) software as a component of IT development within the VistA Electronic Health Record (EHR) Architecture".

The initial results of that RFI were released in February, outlining a plan to move forward with VistA as an open source project. This second document is also an RFI, since it solicits feedback from the community on the plan. The primary headline is that the VA would create an open source "Custodial Agent" (CA) to manage the VistA source code repository, certify proprietary applications for compliance, and accept patches and code contributions. The CA would be governed by a board that would set bylaws, define membership and intellectual property guidelines, and determine the appropriate license for the VistA codebase.

Regarding the license selection question, the RFI says it "expects that the CA will use an Open Source Initiative (OSI) Approved license but is open to alternative frameworks that may accomplish its objectives." The objectives listed include royalty-free source code, open access to all code in the repositories, non-discriminatory access, the right to make and distribute derivative works, and the right to package, redistribute, and support without requiring attribution.

The RFI also lays out a plan for modernizing the VistA codebase, refactoring the project, publishing the refactoring design, and committing the work in the open — including all architecture documentation and API specifications. On the other hand, it does not get into many specifics, such as the size, election, and makeup of the CA board, nor does it attempt to spell out any of the technical decisions (which it says will be among the board's first tasks).

The full document is 21 pages long, although the last four or so are devoted to a detailed questionnaire asking for feedback and demographics about personal or organizational experience and background. Each section of the RFI ends with a bullet list of specific feedback questions, such as "What methods of generating, sharing, and maintaining documentation provide the most value to the open source community?" and "How important is a common development environment to the developer community?"

Reaction time

The response from the open source VistA community has been mixed, but generally positive. Open source healthcare "hacktivist" Fred Trotter said the VistA community viewed the RFI "with both hope and a little fear. We have been waiting for something like this for years, but a lot could go wrong here." Postings on WorldVistA's Hardhats mailing list typified that reaction — several emphasized the importance of the API and architecture documentation, while expressing hesitance to embrace the plan outright. In that thread, Gregory Woodhouse said "it's high time we stop complaining and get about the business of developing a set of open standards people can rely upon."

Trotter had called for a VistA "council" similar to the proposed CA as far back as 2008. His proposal hinges on giving stewardship of the VistA code to an organization not controlled by the VA, but also not beholden to the commercial VistA integrators. The latter requirement depended on electing a fixed number of council representatives from VistA-using hospitals, rather than allowing all seats to be selected by the development community.

Some of what Trotter describes dips into the details that the RFI defers to the eventual CA board. What is more interesting in the long run is the closing thought, "anyone should see that the council that I am proposing has parallels with WorldVistA." WorldVistA is currently the closest thing to the proposed CA, because it provides a voice for non-commercial VistA users and developers, but it also lacks a definite governance structure, functioning as a free-form entity instead.

If the VA adopts the CA model described in the RFI, then the need for WorldVistA may eventually fade, or else the group might simply evolve into a different role. For the foreseeable future, however, it serves as the central meeting place and voice for VistA users, so its support for the VA open source strategy is essential. There is clearly trepidation among WorldVistA members about whether the VA will deliver on the principles and promises outlined in the RFI.

I have only an outsider's perspective on VistA, but it appears that this trepidation stems from years of dealing with a VA that threw the code over the FOIA-wall and did little to directly address outside users' needs. In light of that history, trepidation seems normal. But the plan outlined in the RFI sounds solid, and hits the right notes: it does not simply describe an open source foundation, but it details the reasons why it must function independently of the VA to succeed, and addresses the concerns of developers in a way that indicates that the VA understands why open source actually works.

The VA says it will complete its evaluation of submitted responses by March 25, and presumably will issue at least a summary of them several weeks after that. Still it may be many months before the first concrete steps of the plan begin — so far, not even a rough timeline has been discussed. For his part, Trotter is cautiously optimistic because of the slow pace the VA is taking. Putting out an RFI on the plan, he said, shows balance, and will allow the agency to gather input and avoid the big pitfalls. So it may be quite a while before we see VistA complete any transformation into a real, vibrant open source project, but if the success story of the VistA ecosystem is anything to judge by, it will be a huge win for open source — and for health care — when it finally arrives.

Comments (22 posted)

The Grumpy Editor's GNOME 3 experience

There are advantages and disadvantages to running a development distribution like Rawhide. One of those is that users often get to experience new software well ahead of all but the most dedicated developers and testers. Whether this feature qualifies as an "advantage" or not will be left for the reader to determine. While (sometimes unwelcome) bits of GNOME 3 have been slipping onto your editor's desktop for a while, he has, thus far, avoided engaging with the full GNOME 3 experience. Nothing lasts forever, though, especially when it comes to development distributions. As the features slowly drained out of the GNOME "fallback" environment, it seemed to be the right time to jump in with both feet. What follows are some impressions of where GNOME is going.

The early days of GNOME 2 were characterized by a relentless campaign to hunt down and eliminate any configuration options that seemed unnecessary, for a large and inclusive value of "unnecessary." Strangely enough, this move proved to be unpopular with users, with the result that, over time, many of those options were added back. GNOME 3 shows signs of wanting to repeat this history; the end result may well be about the same.

Configuration options

This all came forcibly to your editor's attention when the font used for various desktop elements (application menu and tool bars, for example) suddenly changed and became larger. That created havoc on a carefully laid-out desktop, creating scrollbars and "more bookmarks" menus where none had existed previously. Anybody who follows GNOME releases knows that there are few things this project likes better than forgetting its users' configuration selections; it was logical to assume that this had happened again, sigh heavily, and go off to fix things up. The assumption seemed valid - blinking cursors in text areas made an unwelcome reappearance at about the same time - but things turned out to be different this time.

One of the more visible changes in GNOME 3 is the new "system settings" window. This window now lacks any sort of font selection utility. Some searching turned up others who were asking how to change their fonts in this new world; it turns out that there is an answer: go to the "universal access" section. Sure enough, "universal access" has a menu for "text size" with all of three options: "normal," "large," and "larger." Not much help for somebody who wants his old ten-point fonts back. But it seems that anybody who wants to change his fonts (beyond "larger") will have to delve into the GNOME settings registry; there is no plan to restore font selection to the interface. Why is that? Here's what your editor was told:

Having wandered out of the area of "settings that users *should* want to change," your editor is out of luck. His complaints have led to a suggestion that a "smaller" option might be added, but it has not yet made an appearance as of this writing.

This sort of thinking appears throughout GNOME 3. It will no longer be possible to configure what happens when a laptop's lid is closed. The nice dialog which made it possible to restore the control key to its $DEITY-intended position is long gone; it's a good thing that xmodmap still works. Screen saver configuration seems to have gone entirely by the wayside; it's fade-to-black for everybody now. User-supplied background wallpaper can only come from the "pictures folder," the location of which evidently cannot be queried or changed; in this case it turned out to be the home directory. Evidently nobody wants to enable mouse clicking with touchpad taps anymore. And so on. That is the world GNOME is (once again) aiming for. It is, evidently, seen as an increase in usability that will bring large numbers of new users to the platform. (Update: it turns out that some of these options still exist; see the comments for their new locations.)

gnome-shell

It is in this context that your editor, with some trepidation, enabled gnome-shell on his desktop. Given the changes in the platform, the complaints about gnome-shell seen elsewhere, and some early experiences, he thoroughly expected to hate the whole thing. After two weeks of usage in the doing of real work, things have not turned out quite that way; gnome-shell is not that bad, and there are even some things to like about it. That said, there are a lot of things that could be better, and a return to the "fallback" environment is likely, at least for a while.

The initial gnome-shell experience was harsh indeed; it ran so slowly that the desktop was essentially frozen. Your editor is a fast typist, but, unreasonable person that he is, he still believes that a terminal emulator should be able to keep up with him; that was not the case when running gnome-shell. The problem, as it turns out, is the result of limitations in some Intel graphics chipsets which cannot do 3D rendering if the display width or height exceeds 2048 pixels. The system in question, running with two monitors, had such a display. Disabling the second monitor makes things work, but with an obvious cost; one might describe it as a new form of the classic time/space tradeoff.

One can argue that this particular failure is not gnome-shell's fault, but it is a consequence of the decision to require working 3D support to run gnome-shell at all. It seems likely that, as more users try GNOME 3, the number of people encountering this kind of problem will grow. Systems which work perfectly under GNOME 2 can collapse under GNOME 3. One can only hope that the detection of such systems improves in the near future; gnome-shell should simply refuse to run in such situations. The alternative - a nearly-frozen desktop - is just not the sort of Amazingly Improved Usability experience that users might have been hoping for.

Beyond that, the desktop is not quite as responsive as it was under GNOME 2; there is a perceptible delay when scrolling within windows, for example. Emacs windows get corrupted when compositing is in use; this bug has been reported for a while, but no solutions are in sight. That said, gnome-shell does offer a desktop which is visually pleasing, with nice drop shadows, zooming effects, and such. One can argue about whether it's all worth the cost, but 3D rendering is something that should work well on most Linux systems at this point. The decision to make use of hardware-accelerated 3D rendering in gnome-shell is defensible - as long as the alternatives work properly.

The GNOME 2 panels, which could be configured to appear almost anywhere on the display (your editor's laptop has a single panel running vertically on the left edge) has been replaced by a mostly featureless black bar wired to the top of the screen. Launchers as such are a thing of the past. Instead, one clicks on the "Activities" button (or simply slams the pointer into the upper left corner of the screen); in response, the desktop will zoom back yielding a display of application windows (no longer overlapping), a "dash" on the left side of the display, and a strip representing workspaces down the right side.

The "dash" looks like an application launcher panel, but it is a bit different. Its contents are the union of the applications which are currently running and the user's "favorites." Clicking on an icon will either (1) launch the application if an instance is not already running, or (2) take the user to a running instance if it exists. Getting a second browser window (say) requires right-clicking on the icon and selecting "new window." So, an operation which was previously accomplished with a single click on a panel icon now requires (1) moving to the upper right corner of the display, (2) right-clicking on an icon, and (3) selecting a menu entry - a rather longer and slower sequence of events.

It is not immediately clear this behavior is an increase in usability. The reasoning behind this change is described this way:

Your editor, having been blissfully unaware of the scourge of unnecessary calculators just waiting for their opportunity to overwhelm his desktop, has not yet come to love the new way of doing things.

Happily, gnome-shell has not done away with the concept of workspaces, despite some claims that workspaces confuse inexpert users more than almost any other feature. They have become more dynamic, though, and do not really exist until windows are dragged into them. Anybody who uses workspaces heavily may come to miss the old scheme where workspaces were fixed. In your editor's world, workspace 2 is where LWN writing gets done, workspace 3 is for programming, and email is hidden in workspace 1 where it can be ignored for extended periods. Photo editing tends to happen in workspace 4, and so on. Gnome-shell makes it harder to know where everything is without having to go looking for it; one learns to be careful in the initial population of the workspaces.

Switching between workspaces involves moving the pointer to the upper left corner to zoom back, then going all the way to the right side of the display to select the workspace of interest, then clicking on a window (or hitting escape) to zoom back in - a lengthy ritual. The good news is that it is still possible to designate keystrokes for moving quickly between workspaces, so it's not necessary to do the zoom-back-and-click dance every time.

As has been discussed elsewhere, gnome-shell has done away with the "minimize" and "maximize" buttons on window titlebars. Your editor never found any use for either and, thus, does not miss them at all. On the other hand, the maximization of windows by dragging them to the top of the screen is unintuitive, surprising, and unwelcome. It's easily undone, but it's annoying.

In summary

There are a number of other weirdnesses perpetrated in the name of usability. For example, there's no "power the system off" option in sight. To turn off the system, the user must click on one's own name at the upper right and hold down the "Alt" key while the menu is visible. Clicking on one's name may be more intuitive than stopping the system with the "Start" button, but it seems a little strange and possibly narcissistic as well. Hiding a useful menu item (we all turn off our systems sometimes) behind the "Alt" key, instead, seems intended to confuse.

All of these complaints notwithstanding, it must be said that gnome-shell is not an unpleasant environment to work in most of the time. It looks nice, and most of the needed functionality is not that far away. It is also said to be designed for easy enhancement via extensions written in JavaScript; very few of these extensions exist now, but one can imagine that developers will use this capability to improve the gnome-shell experience considerably in the future.

For now, your editor will be switching back to the fallback environment so he can have his second monitor and Emacs back. But, if a properly functioning gnome-shell were the only alternative available, it would not be that bad a fate. Around GNOME 3.4 or so, when the important configuration options come back, GNOME 3 has a good chance of being a pleasant, flexible, and powerful desktop. But the road between here and there may be a little rough in spots.

(Finally, your editor would like to thank the numerous GNOME developers who have responded to his questions. We did not always agree with each other, but they were always more than willing to answer questions and to help get things working.)

Comments (344 posted)