The conventional wisdom is that, once Linux reaches a true, user-friendly
paradise state, there will be no need for any command line work at all.
Your editor, however, is a heavy command line user, and has been since,
well, since he was able to get away from punch cards. Some sorts of tasks
are best done in a graphical, pointer-oriented mode. But others are,
truly, best done with the command line. The pure expressive power of a
command-oriented interface has yet to be matched in the graphical world -
at least, for a wide variety of tasks.
Once upon a time, an ADM-3A
terminal looked like a very nice interface. Those days have passed,
for many of the years
since, the definitive terminal emulator has been xterm, which was
packaged with the original X11R1 release. xterm was, for its time, a
marvel of configurability, with a nice set of menus for controlling its
behavior, setting fonts, and providing that all-important access to the
"reset" function for when it gets stuck in the VT100 graphics mode.
There is one other xterm feature which has never been matched anywhere: no
other terminal emulator comes with its own Tektronix 4014 storage tube
emulator mode built in. Your editor who, along with many co-workers, had
sunburned his face working with real storage-tube terminals appreciated this
mode at the time. It has been a while, however, since your editor (or just
about anybody else) has had to run software which expects to talk to such a
terminal; even so, every xterm still has a Tektronix terminal lurking
In general, little has happened with xterm over the years, with the
exception of the addition of color support. For the most part, development
in terminal emulators has happened elsewhere. Your editor has finally
decided that it is time to take a look around, and, perhaps, move beyond
the venerable xterm.
But first: a word on color in terminal emulators; this is a subject on
which your editor can get truly grumpy. Many developers have jumped into
adding color support to terminal-oriented applications with little regard
for basic human factors and usability. A usable terminal should not look
like the Las Vegas strip at night. Color usage, to be effective, must be
subtle and carefully thought out. In particular:
- Users must be given obvious and easy control over color usage.
Different people have very different combinations of monitors, background
colors, limitations in color perception, and general preferences.
There is no single choice of colors that will work for any substantial
portion of the user community.
- The basic nature of the human visual system is that it separates
objects based on intensity differences, not color differences.
If you are designing colors for a white-background display, every
color you use must be, with few exceptions, a low-intensity color.
Hot pink on white may look snazzy, but people will have to work hard
to read it.
- Dark blue should never be used for anything somebody is expected to
read. Short wavelength colors tend to focus just in front of the
retina, and will thus always be a little bit blurry.
Color xterm thus fails on all counts. The colors can be configured via the
X resource database, but it is not straightforward. The default colors are
on the garish side, and they are too bright.
For years, the default replacement for xterm was rxvt. This terminal
emulator is, for all practical purposes, a version of xterm with a lot of
the extra stuff (such as the Tektronix mode) stripped out. It does live up
to its promise of being smaller, taking just over half the virtual memory
required by xterm. rxvt, however, suffers from a lack of maintenance (last
release was November, 2001, with a development version showing a release in
March, 2003), poor default colors, and no
menus for run-time configuration. This terminal emulator has been dropped
from a number of modern distributions.
(As an aside, rxvt, like most other terminal emulators, dropped the
xterm/Xaw scrollbar. This is a big loss; no other scrollbar is as useful
as the old Xaw implementation, which gives very precise control over just how much the
window is scrolled. Wheel mice have made good scrollbars less important,
but your editor wishes that developers interested in usability wouldn't so
casually drop interaction modes which are clearly better).
If you want to know the current state of the art in terminal emulation, of
course, you have to look at what the desktop projects are doing. Your
editor is happy to report that neither GNOME nor KDE has neglected the
lowly terminal emulator.
GNOME's entry is gnome-terminal. This terminal emulator does all of the
stuff that one would expect of an xterm replacement, with a number of
useful new goodies:
- Tabs. A tabbed terminal emulator turns out to be just as useful as
a tabbed web browser. If you tend to have a lot of things going on at
once and limited desk space, tabs make life much easier.
- Nice configurability. It is easy to eliminate gnome-terminal's most
obnoxious features (blinking cursor, space-wasting menu bar), tweak
fonts and colors, etc. The default colors are also relatively
good, at least for people who work in a white-background mode.
- Multiple profiles. Each tabbed session can have its own fonts,
colors, titles, etc. If you tend to keep tabs around for specific
purposes (one could, for example, keep a root shell in one tab), you
can tweak the presentation to make the current task immediately
gnome-terminal also has a nice feature in that it makes the pointer fade
away as soon as the user starts typing. No more moving the mouse around to
get the pointer out of your way. An invisible pointer might seem like a
human factors problem in its own right, but the simple fact is that you
generally have to move the pointer to find it anyway.
Your editor's biggest complaint about gnome-terminal might be that
scrolling with the mouse wheel is a relatively coarse operation; xterm
scrolls in smaller steps unless the shift key is held. The number of lines
to scroll on a mouse wheel event would be a nice addition to the
terminal emulator, has most of the features described above.
In addition, Konsole offers:
- Bookmarks. In the Konsole world, a bookmark is just a saved directory
path; selecting a bookmark causes Konsole to feed a cd
command to the underlying shell.
- History browsing. Konsole can search for a string in the past
history, making it easy to go back and see what happened earlier.
- Notifications. When asked, Konsole will monitor a session for
activity (or, optionally, the lack thereof) and notify the user when
it happens. If you want to know right away when that long
make finishes, Konsole can tell you. It also can notify you
when something rings a bell in one of your sessions; such sessions are
also annotated with a little bell icon in the tab bar.
Konsole, too, will hide the pointer. Unlike gnome-terminal, however, it
does not wait until you start typing, but hides it regardless after a few
Konsole comes with a reasonable set of default colors, and provides user
control as well. The color editor works by way of "schemas," and is rather
awkward to work with. The gnome-terminal profile-based mechanism seems
Both gnome-terminal and Konsole will let you do crazy things, like putting
a background image into the terminal window. Such features make for
screenshot eye candy, but they are not good for usability.
Fortunately, nobody seems to set up either emulator with background images by
Both Konsole and gnome-terminal make it easy to change fonts - if you like
the options provided. Your editor, who long since found a monospace X font
which optimizes both readability and screen space, very much misses the
ability to chose an arbitrary X font. It is probably possible by digging
under the hood somewhere, but the configuration screens are not helpful in
this regard. One should also note that both terminal emulators are memory
hogs, requiring vastly more virtual and physical memory than xterm to run.
That notwithstanding, it is clear that both desktop projects have managed
to improve the state of the art in terminal emulation. Even better, they
have both managed to (1) avoid the temptation to ruin usability with
flashy eye candy, and (2) retain a full set of configuration options
so that this crucial tool can be tweaked to each user's needs.
Congratulations would seem to be in order.
[For completeness: other terminal emulators out there include
9term, the Plan 9
entry; aterm, an rxvt-derived
emulator with background image support; and Eterm, an emulator which prioritizes fancy
backgrounds well above readability or usability (see image at left). There are also several
emulators designed around non-western character sets, which your editor is
in no position to review usefully.]
Comments (151 posted)
Since my last article for LWN
on software patents, a lot has happened. Weeks of speculation and frenzied
lobbying culminated in the EU Council passing a version of the software
patent directive that permits software patents; the FFII has continued to lobby on and discuss
the Council's position, whilst preparing for the EU elections and the new
MEPs; and the Union for the Public
Domain has begun to lobby the BBC to release its archives under a Creative Commons license. And as
usual, there's plenty for European hackers to do!
Software patent news
To begin with software patents, on the 18th May the EU Council of Ministers
voted on the controversial software patent directive, passing with a narrow
majority a version that, according to the FFII, ensures that "software and
business methods ... are ... to be treated as patentable inventions" (source).
This version of the directive removed all of the important amendments made
by Parliament in September 2003 that explicitly stated that software and
business methods cannot be patented. But despite this, many ministers
continued to reassure the public, and those considering rejecting the
directive, that it would not allow these things to be patented, describing
it as a "compromise". The key to understanding this dispute is that without
all of the amendments passed by Parliament in September 2003, the
directive could still allow software patents. But the Council's compromise
scrapped the first four amendments present in the Parliament's version, and
instead made a weak version of the fifth amendment that stated that a
technical contribution must be "new".
One member of the Committee of Permanent Representatives explicitly
described it as a
"compromise between Microsoft and Linux." When I talked to
Dr Caroline Lucas MEP (Green, UK), she commented that:
patenting represents a serious threat to creativity and the right of
computer programmers to make a living practising their art. For the Council
of Ministers to completely disregard the views of the Parliament, the EU's
only directly-elected institution, makes a mockery of the EU's democratic
It is worth noting that the Irish Presidency of the EU, due to expire next
year, is sponsored by none other than Microsoft, amongst other
companies. Furthermore, "almost 35% of Ireland's registered companies
totaling 150,000 are non-resident" (source) due to tax
exemption laws. "Over 40% of all PC package software and 60% of business
applications software sold in Europe is produced in Ireland. US companies
Microsoft, Lotus, Claris, Digital, Oracle, IBM and Novell contribute
significantly to this growth" (source). It is
clear where the interests of the Irish government lie.
So where do we go from here? The Parliament has already voted against
software patents, and the Council has voted for software patents. In June,
the Council must formally adopt their position, which is likely (but not
certain) to happen (it may get delayed, or not happen at all). Assuming it
does, the Parliament must then vote again on the directive, and pass their
version with an absolute majority to overrule the decision of the
Council. So the next step for activists - by which I mean any EU citizen
with a pen, phone and/or e-mail client - is to get back to lobbying MEPs.
It is, or was, the EU elections on June 10th. If you're an EU citizen
reading this in time, make sure you go to the polling booth, and bear in
mind the MEPs' positions on software patents when you cross the boxes. You
can find out how they voted in September with this handy
Once the election results come in, we'll need to start lobbying our new
representatives, and continue with those that held their seats, to ensure
Parliament votes against software patents again. When the directive comes
up for a vote (perhaps by the end of this year), it will need an absolute
majority to pass, whereas in the previous vote it only needed a majority
from those actually voting. This means that we need to persuade more MEPs
to actually vote, and more to vote against software patents. The most
important thing is to send off that first letter, and to then follow it
up. When writing your letter, you might find it useful to look at this guide to the
key arguments, and also this page to find
your MEPs' contact details. If they disagree, try to respond and show
why they are wrong; if they agree with you, ask them to sign the FFII's Call
for Action II.
If you've got a little more spare time (i.e. half an hour), and you'd like
to do more than just write a letter, there's a nice project that you can
get involved in that will introduce you to the world of lobbying proper. It
involves phoning MEPs and asking them some questions, then sending the
results back to the FFII, so they can build up a database both of MEPs'
voting records and their stated positions. To join in this project, first
read this handy
guide, and then find the questionnaire itself here. Though the
project started only as an elections tool, it will still be useful leading
up to the vote, and it gives you a good chance to really make a big
difference with a small amount of your time.
You should also try to contact your national government
representatives. They will often have a lot of influence over the minsters
who sit in the Council, and over their party's MEPs. Again, contact them by
letter, and follow up appropriately. If they're supportive, ask them to
sign the FFII's Call for
We defeated software patents in Parliament last year. If we fail this time,
we will not only see large corporations using patents against free software
projects increasingly aggressively, but we will also miss an opportunity to
affect the outcome of the debate in the US. A vote against software patents
in Europe would send a strong message to legislators in the US, and provide
a huge boon to the EFF's Patent
In other news, there has been some development surrounding the BBC's
promise to give the public full access to its archives online. When originally
announced, then-director general Greg Dyke suggested that they
would open up the full archives, but so far the only concrete plans have
been to make available thousands
of three minute clips from documentaries. After a launch reception in
London, which Lawrence Lessig and the BBC Archive's project leader
attended, the Friends of Creative Archive have launched a campaign
to have the full archives released under a Creative Commons license.
The argument behind this position is a familiar one to anyone who follows
Lessig's work, but at the risk of boring you, I'll run over them
briefly. Innovation, particularly amongst more creative types like
musicians, artists and filmmakers, depends upon being able to draw on
culture and past creations. Culture is not just about passively consuming
and creating entirely new works, but about remixing and building upon past
creations. The more culture there is in the public domain, the more
potential there is for new and interesting work to be made. So, the
activists argue, as the BBC is funded by license payers for the benefit of
the British public, it ought to release its archives for the benefit of the
Having an open archive of this kind would provide two special benefits to
the free software community. First, it would provide a large source of
DRM-free, standards-compliant media so that whatever the rest of the
industry does, we will always have a decent media resource
available. Secondly, it will send out a strong signal throughout the
industry and to governments that the principles of the free culture and
free software movements should be taken seriously. It would be much harder
for the media, hardware and software monopolists to impose proprietary
standards on us if organisations as large as the BBC were publicly doing
the opposite. Combined with the recent work on the Dirac codec, it could be
the start of a healthy alliance between the BBC and the free software
The creation of a free creative archive seems like an obviously good idea,
and one would hope that it would strike the BBC that way, but at the moment
they've not had any input from the public on
this issue. So if you'd like to encourage the BBC to adopt a Creative
Commons license, rather than restricting access through DRM and nasty
licenses, consider signing the Friends' letter here.
Comments (17 posted)
The Mozilla Organization released not one, but two testing releases
on June 9. Mozilla 1.7RC3 and Firefox 0.9 RC were released for widespread
testing. Since Firefox is the future of the Mozilla line, we decided to
take a look at the latest Firefox release to see how it is shaping up on
its way to 1.0. As it turns out, a lot has changed since 0.8 and Firefox
seems to be turning into an excellent browser. Naturally, we were only
interested in testing the Linux version of the 0.9 release, but there are
packages available for Windows and Mac OS X as well.
The first noteworthy change since 0.8, or at least the change that is first
notable, is the addition of an installer for Linux users. Past releases of
Firefox for Linux came as tarballs without any kind of installer. For this
author, the difference between using an installer or simply uncompressing a
tarball of the latest build into a convenient directory is
negligible. Still, many users will probably find the installer much more
At install time, the new release copies over the profile from previous
versions of Firefox from the ~/.phoenix directory that was used to store
user data. If the ~/.phoenix directory does not exist, then Firefox will
import user data from Mozilla. This author tested both methods, and Firefox
imported the data from Firefox 0.8 and Mozilla 1.7 without any
problems. User profiles on Linux are now stored under ~/.mozilla/firefox/.
A few items have shifted around in the new release. Specifically, the
"Options" dialog is now "Preferences" and found under the "Edit" menu,
rather than the "Tools" menu. Themes and Extensions now have their own
managers, rather than being part of the Options/Preferences dialog. The
Extensions manager is a bit slicker now, and apparently will enable the
user to update their installed Extensions through Mozilla Update. At the moment,
however, this feature does not seem to be operational. Presumably, one will
also be able to use Mozilla Update to install and update themes in the
future as well.
One minor quibble with the Download manager: in 0.9, the default download
folder is "Desktop," which hardly seems like a suitable choice even for
Linux users who run a desktop environment that supports saving files to the
desktop. It's fixed easily enough, but one hopes that the Mozilla team will
switch the default to prompt the user for a download location.
Though this author did not conduct any scientific testing, the latest
Firefox release does seem faster than the previous release. The interface,
menus and so forth, seem a bit more responsive than previous releases, and
rendering also seems a bit snappier. Firefox 0.9 RC also seems a bit more
stable, though it has crashed once during testing. The 0.9 RC is certainly
more stable than the 0.9 nightly snapshot releases that this author had
been trying out.
The most obvious change, and one that has generated a great deal of
discussion, is the replacement of the current Firefox "Qute" theme with
a new theme called "Winstripe." For this author, it seems like far too much
fuss over a simple change. The browsing experience itself is not hampered
by the new theme, and one expects that new themes for Firefox will become
available for those who do not enjoy the default. The fact that users are
able to focus so much attention on Firefox's theme may be a good sign,
however. This may indicate that Firefox already meets their needs in terms
of speed, stability and feature completeness -- allowing users to focus
their attention on more superficial areas. If this is the case, the Mozilla
developers should regard the theme complaints as something of a compliment.
In all, the latest Firefox is an impressive browser. It lacks polish in a
few areas, but it is a solid browser with an impressive array of
features. We'll be quite interested to see what the final 1.0 release of
Firefox will look like when all is said and done.
Comments (11 posted)
Page editor: Jonathan Corbet
Next page: Security>>