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)
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
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
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
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
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
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.
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
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
problem; others who use their browsers in their own way may see things
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
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
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.
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.
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
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
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.
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)
the address bar along with a red "X" on the padlock (seen at right). This
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
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
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 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.
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
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)
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.
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?"
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
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)
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.
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
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:
There's two really specific cases where having
yet-another-control-panel-applet is not good: discovery of the
settings that users *should* want to change and, in the support
side of things, users who change the font, don't know what they've
done, and then have to call to $linux_savvy_family_member or
$corporate_IT_help_desk. We added the a11y mechanism to handle
vision-related needs specific to fonts in a way that was
simultaneously safe without requiring an entire applet.
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.)
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
graphics chipsets which cannot do 3D rendering if the display width or
height exceeds 2048 pixels. The system in question, running with two
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
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
of Amazingly Improved Usability experience that users might have been
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:
For many applications, such as XChat IRC, Telepathy, Evolution,
Calculator, or Chess, it makes most sense to only run one instance
of the application, so switching to the existing window of the
application is what the user wants if the application is already
running. However, in GNOME 2, the user had to know whether such
application is already running before making a decision to click on
a launcher to open a new window of the application. Accidentally
opening a duplicate window could mean having an unnecessary extra
Calculator window cluttering the desktop or signing in into IRC
under a second nick. By combining the application launcher and the
application switcher and making switching to the already running
copy of the application the default behavior, we give the user
confidence that if they just go ahead and click on the application
icon, the right thing will happen.
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.
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
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
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
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
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
Comments (344 posted)
Page editor: Jonathan Corbet
Next page: Security>>