LWN.net Weekly Edition for November 2, 2006

Pre-testing Emacs 22

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 on 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 without changes. 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 else.

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 combinations.

  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 psychoanalysis programs. 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 use.

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)

Oracle's repackaged RHEL

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:

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 cheaper. 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 happens.

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)

Full disclosure and exploit tools in the wider world

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 check.

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 legal situation.

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)