Some projects produce major releases more quickly than others, but, even
when placed at the slow end of the scale, GNU Emacs is exceptional.
Current Emacs users are running version 21, first released
October 22, 2001. Occasional minor releases have happened since, but,
for all practical purposes, Emacs has stood still for the last five years.
At least, the officially-released version of Emacs has stood still.
Meanwhile, the development community has been busy working toward
Emacs 22. Richard Stallman - who still keeps a firm hand on the
direction of Emacs development - has never been inclined to give dates for
upcoming software releases. So, after five years, we still don't know when
Emacs 22 might be released, but we do know that it is getting closer:
the first pre-test release of
GNU Emacs 22 is, at long last, available. The project has reached
the point where the desired features are in place and stabilization is an
increasingly high priority.
Your editor grabbed the pre-test release, and has been working with it for
a couple of days - it is being used to type this article. At first blush,
the new version of Emacs does not look all that much different. The
windows look the same, most of the keystrokes are the same, and your editor
has not yet encountered any elisp code which fails to work properly - even
the brutal elisp hacks which connect Emacs to the LWN article database work
The Emacs developers have seemingly done a good job of maintaining
compatibility over five years of development.
The new GNU Emacs does feel a little faster and more responsive, somehow.
There are also various little things one notices over time. For example, a
command to open a new file generates a prompt like this:
The prompt includes the directory where the file is expected to be found.
Emacs has always allowed the user to simply type a new path, starting with
"/" or "~"; the new version, however, makes the resulting
action (ignoring the previous path in the prompt) clear:
It's little things like this which make an interface more pleasant and easy
to use. On the other hand, the new policy of requiring a keystroke to get
past the "one component of the GNU/Linux operating system" screen is
obnoxious - but this behavior can be disabled.
Of course, there's plenty of bigger things in this new release, once one
goes looking. Support for internationalization and encodings has been
significantly improved. Also improved is window system support: Emacs now
understands mouse wheels without special instructions and will do the right
thing when files are "dropped" into it. One can turn on "focus follows
mouse" behavior even within Emacs frames. The addition of an IRC client
would have been useful, but this is Emacs, so they added two different ones.
There is a new "calc" mode which is truly scary in the things it can do.
"Org mode" is a Tomboy-like notes-taking application, but with an order of
magnitude more features. There is a built-in spreadsheet with all the
usual features and some unusual ones - like the ability to enter cell
formulas in Lisp. Flymake
mode performs on-the-fly syntax checking of source code as it is being
entered. There is a new, fancier printing mechanism built into the editor.
And so on. The current
NEWS file gives a lengthy overview of the changes - though somehow it
omits the important addition of a Tetris game.
When LWN first posted the pre-test announcement, the result was an
immediate mini-flamewar on the merits of Emacs relative to vi. One can
only expect that, as the Emacs 22 release gets closer and draws more
attention, we will see more of this sort of debate. Your editor must
confess that he has never quite understood what motivates these battles;
one person's choice of editor should not really be a problem for somebody
More to the point, though, your editor is one of those rare, strange people
who actually uses both editors over the course of a normal day. They both
have their strengths and weaknesses, and each fits your editor's working
style at different times.
- vi is fast, in a number of ways. It starts quickly, which is nice
when a quick job needs to be done. It is likely to be the most
keystroke-efficient editor around, especially once one gets the hang
of how the movement and editing commands combine. Files can be edited
in vi using relatively straightforward keys and no strange modifier
On the other hand, vi has an inherently modal interface, which is
considered to be bad human factors in general and which trips up every
user sooner or later. It is deeply line-oriented at its core, though
some more recent versions have done a better job of hiding that fact.
And vi simply lacks a number of more advanced features; it was never
meant to contain mail clients, RSS readers, calendars, or
Recent work to add some of these features to vi feel misplaced, like
putting a trailer hitch onto a two-seater sports car.
- Emacs is an interactive user interface development environment which
happens to be very good at editing text. Many years of effort have
gone into using this environment to develop editing tools of great
power. Emacs has long had a high level of integration with tools like
compilers, debuggers, text formatters, etc. which still does not exist
in vi. There can be great joy in having a full editor environment
available when dealing with mail or debugging a program. Emacs, when
well configured and understood, can be a great productivity aid.
But, then, Emacs is a vast monster of a program - though it has been
rapidly out-bloated by current desktop tools. Somebody who has been
an expert Emacs user for many years will still only know a fraction of
its capabilities; it can be frustrating to know that, somewhere in
there, lurks just the feature needed to get a job done - but to not be
able to find it. The wrong key sequence can occasionally lead to
hallucinogenic results, to the point that there is a special command
("view-lossage") to answer those "how the hell did I make it do that?"
questions. Even some relatively trivial customizations require typing
in Lisp code, which, for some strange reason, not everybody wants to
learn how to do.
There is also an entire branch in the physical therapy field dedicated
to the treatment of little-finger injuries caused by excessive Emacs
The end result of all the above is that your editor tends to use Emacs for
most day-to-day work, including the editing of articles and source code.
When working as root and editing system configuration files, however, he
tends to switch to vi. And, seeing advantages in both tools, your editor
sees no real reason for intense discussions about which is better.
Such discussions will certainly come about, however, as the Emacs
development cycle heads toward its conclusion. The new release seems
unlikely to tempt many vi users to make a switch, but Emacs users will have
something to celebrate. After all this time, there will be a significant
update for this venerable tool (the first thing released by the GNU
project). Just don't ask RMS when to expect it.
Comments (56 posted)
For weeks the rumor mill has been full of guesses about what Oracle's big
Linux news, if any, might be. None of them, however, were correct. In the
end, Oracle has announced
a competing support program for Red Hat Linux. It will be most interesting
to see how things will evolve from here. At least nobody is complaining
anymore that you can't get support for Linux.
Oracle's program is easy to understand:
Oracle starts with Red Hat Linux, removes Red Hat trademarks, and
then adds Linux bug fixes... Every time Red Hat distributes a new
version we will resynchronize with their code. All we add are bug
fixes, which are immediately available to Red Hat and the rest of
Essentially, Oracle is offering a version of Red Hat Enterprise Linux
(RHEL) with the serial numbers filed off. To maintain compatibility,
Oracle also promises to file the serial numbers off of future RHEL releases
and distribute them as well. All for rather less money than Red Hat
charges. If that's not enough to entice customers to switch, Oracle also
tosses in a bit of old-fashioned SCO FUD as a bonus.
One cannot help but wonder just what Oracle is thinking here. Rather than
(as some had guessed) offering its own Linux distribution, it is
reaffirming the primacy of a competitor's offering. The added value
claimed by Oracle - the bug fixes that, says Oracle, Red Hat is failing to
provide to its customers - will, by Oracle's own admission, be immediately
available for Red Hat to incorporate back into its offerings as well.
Meanwhile Oracle is openly hitching a free ride on Red Hat's work with the
clear intent of cutting off the revenue stream which supports that work.
If Oracle is successful, it will kill the goose laying the golden eggs that
it is selling.
There are reasons to believe that Oracle might not be as successful as the
stock market evidently fears. Oracle claims Linux expertise, and it has
hired a few developers and made some real contributions. But Oracle's
contributions and expertise are both tiny compared to Red Hat's; customers
who are paying attention will understand that. Oracle will always be a
little behind Red Hat, following Red Hat's lead. The quality of Oracle's
support is not always praised by all of its customers, and the challenge of
dealing with Oracle's lawyers is legendary. It is hard to imagine why
people who are concerned about the quality of the support they are paying
for would not go directly to the source.
So what is Oracle up to? One line of reasoning says that Oracle is simply
trying to lower Red Hat's stock price to make an eventual acquisition
Certainly people seem to have no problem believing that Oracle would be
willing to use this sort of tactic. If Oracle is truly trying to soften
up the competition through a sort of shock and awe campaign, however, it is
hard to see that there would be a whole lot worth acquiring by the end.
Many of the core developers who make Red Hat what it is might find
themselves unwilling to go along with the new Oracle overlords; quite a few
of them may try to find another place to be.
What Oracle might be trying to do, instead, is to begin building up its
Linux expertise and the beginnings of a customer base in preparation for an
eventual fork of RHEL into its own distribution. The "bug fixes" could
grow over time until a point arrives where moving from Oracle's Linux back
to RHEL is no longer an easy thing to do. Perhaps a few proprietary pieces
would help to solidify the lock-in. If this plan went well, customers and
engineers would drift in Oracle's direction with no acquisition effort
required. Rather than jumping into the distribution business from the
beginning, Oracle could be dipping some toes into the water to see what
The arrival of free-riders in the commercial Linux world was always
inevitable, even if few people expected one the size of Oracle. In a way,
we are all free riders; even the heaviest contributor to the free software
community gets far more back than they could ever put in. Companies like
Red Hat and Oracle are not selling the software; they are selling the
quality of the service they provide. As long as customers pay attention to
what they are really buying and do not allow vendors to try to lock them
into a specific distribution, we should all come out ahead.
(See also: Red Hat's
"Unfakeable Linux" response to Oracle's announcement).
Comments (36 posted)
Opinions on how to handle security vulnerabilities vary quite a bit. It is
probably safe, to say, however, that a majority of people who have studied
security issues are in favor of some form of disclosure. Hiding security
problems reduces awareness of the issues and reduces the chance that those
problems will be fixed in a timely manner - without actually making anybody
more secure. There is a rather smaller group that favors the release of
exploit tools, however. Sharing information is one thing, but empowering
groups of script kiddies is seen differently; the majority point of view
here, arguably, is that the release of exploit tools just increases the
damage from security problems without getting things fixed any more quickly.
The recent, short-lived creation of a web site which can print fake
boarding passes would appear to be a classic example of the difference in
how information and tools are seen. In the U.S., and other places as well,
the security gauntlet which must be run to get onto an airliner includes an
identification check: each passenger must produce some sort of
identification which matches the name printed on their boarding pass. The
weakness of this check has been well known for years; boarding passes
printed by passengers on their own printers are accepted as valid with no
verification. So it has always been true that anybody with minimal skills
could print up a boarding pass, under any name, which would pass this
In this case, disclosure of the vulnerability did little to inspire any
sort of fix, however. So Christopher Soghoian put together his web site.
In response, the FBI raided his house and took his computers, and a
U.S. Congressman publicly called for his arrest (though he later
reconsidered that position). The web site got pulled down in a hurry.
Mr. Soghoian has taken a storm of criticism, and is now facing an uncertain
Many of the people who have criticized the creation of the boarding pass
generator are normally in favor of the disclosure of security problems.
The boarding pass site, however, has been deemed to be an exploit tool, and
is thus beyond the pale. Mr. Soghoian, they say, should have found a more
responsible way of making his point about the security of the boarding pass
checks. This despite the fact that people have been "responsibly" making
that point for years. Would the site have had the same impact had it, for
example, printed "VOID" on its output?
The boarding pass generator was not released as free software, so it was
easy to pull off the net. But there will be many readers of this site who
could reproduce this tool in the time it takes to work one's way through
the security lines in some airports. It would not be surprising to see
such a tool show up on the net somewhere before too long. It is simply too
easy to do.
Anybody contemplating such an action may want to take care to post the
result anonymously. Mr. Soghoian may well avoid serious legal problems,
assuming that, as he claims, he never actually used a fake boarding pass to
get through a security line. Had he distributed his code, however, there
is little doubt that rather more effort would be put into finding some
crime to charge him with.
When we talk about software freedom, we often pass over a freedom so
fundamental that we accept it implicitly: the freedom to write programs in
the first place. But there are clearly limits on what we can really
write. Authors of encryption tools, game servers, DVD decoders, electronic
book liberators, and, now, boarding pass generators have found themselves
in legal hot water. This will not be the last such episode, and the next
one may affect the free software community more directly. There are
programs that we are not supposed to write.
Comments (17 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Extended validation certificates; New vulnerabilities in ImageMagick, mutt, ruby, screen, ...
- Kernel: Buried in warnings; struct path; Video4Linux2 part 3: Basic ioctl() handling.
- Distributions: The Edgy Efts swim to a mirror near you; new releases from Gentoo/FreeBSD, OpenBSD, openSUSE, Ramdisk Rescue, rPath Linux and Xfld; FC6 issues and cooperative bug isolation; DebConf7
- Development: Unmaintained free software, The impending arrival of Gnu EMACS version 22, GlobalGCC project launches,
new versions of MySQL Community Server, BusyBox, libassuan, OpenBGPD,
Sussen, Audacity, Jack_capture, Pengupop, PyChess, wxPython, Free Image Manipulator, Wine, GRASS, Vilistextum, JanRain PHP OpenID library,
- Press: ODF in the EU, Bernard Leach from the iPodLinux project, Oracle's
Unbreakable Linux, Linux on an eMac, the origins of LDAP,
list manipulation in OO.o, Ruby implementations, reviews of fnord, Krita,
Python 2.5, SLERT and Zotero, the Geekcorps.
- Announcements: Creative Commons 3.0 draft, Software Quality Observatory,
Motorola Java Micro Edition stack, Nuxeo Core 1.0, Sun 1Q07 results,
online Django book, EFF Bloggers' Guide, php|tek cfp, LCA program,
GNOME.conf.au, LinuxWorld Mexico, Openlab3 London, Linux Action Show.