Leading items

Fedora leaves a vast legacy

The announcement of the second Fedora Core 4 test release heralded a somewhat less-publicized event: support for Fedora Core 2 has been transferred to the Fedora Legacy Project. This is only the second time such a transition has occurred, so there are still a number of interesting questions being raised about just how this transition is supposed to work.

One such question is: what should be done about unresolved bugs in Fedora Core 2? There are quite a few of those; about 600 for the kernel alone. Is the Fedora Legacy group expected to take on all of those bugs? In most cases, the answer is "no"; Fedora Legacy exists to provide ongoing security support, and not random bug fixes. So most of those bugs could simply be closed. As project member Matthew Miller noted, however, that is not the case for all of them:

(The mentioned Perl vulnerability has been fixed by several distributors, including Red Hat, but not Fedora).

So somebody needs to go through all of the open bugs, figure out which ones are security-related, and close all of the bugs which Fedora Legacy will not even attempt to fix. Not a small job. As it turns out, there does not appear to be consensus even on that approach, however.

Many of the bugs reported for Fedora Core 2 still exist in subsequent Fedora releases. What really needs to be done with those bugs is to redirect them to Fedora Core 3 and hope they get more attention there. Other bugs may have security implications which have not yet become evident. In any case, a wholesale closing of Fedora Core 2 bugs may not be the right thing to do.

When LWN last looked at Fedora Legacy (in January), the project appeared to have stalled. One might well ask how the project will cope with a new distribution and a massive pile of bugs when it has not been able to keep up with the responsibilities it already had. The good news is that, in February, the Fedora Legacy process got moving again, and the flow of updates has resumed. Fedora Legacy is back in the business of providing support for older Fedora Core releases - and Red Hat Linux 7.3 and 9 as well. One should note, however, that no advisories have come out, as of this writing, since March 24.

Fedora Legacy is a small, volunteer-driven project. It remains to be seen whether it can take on another large distribution now - followed by Fedora Core 3 sometime around September. At some point, something will have to give. At the FUDCon meeting in February, Red Hat said that it wanted to beef up the Fedora Project to gain back some of the "early adopters" it had alienated. Perhaps providing longer-term, stable support to the Fedora releases would be a good step in that direction.

Comments (20 posted)

The Monotone version control system

Version Control Systems (VCS) have always been of great interest to the Linux and open source community, but the the topic has gained new life in recent weeks thanks to the BitMover announcement that it's ending development of its free (as in beer) tool. Since Subversion has already been ruled out, that leaves the door open for one of the many other open source VCS. One of the alternatives which has been considered by Linus Torvalds for kernel development is Monotone.

Monotone is a distributed version control system that supports 3-way merges, peer-to-peer synchronization and runs on several platforms -- Linux, Windows, Solaris, Mac OS X and other Unix-like systems. The project is available under the GPL and just a bit over two years old. The first release was created by Graydon Hoare and pushed out on April 6, 2003. The most recent release, 0.18, was announced on April 11.

Monotone has much to recommend it, feature-wise. It supports atomic commits, allows versioned file and directory renames (as opposed to CVS, where moving a file or directory causes loss of the file history) and uses SHA1 checksums to identify files, directories and revisions. Information about a source tree is kept in a SQLite database, which is synchronized against remote databases or the local working copy. The command set is relatively easy to pick up, and the documentation is very clear as well.

Torvalds does have a few gripes about Monotone, for example, he complains that it's "much harder than it should be to have throw-away trees due to the fact that they seem to be working on the assumption of 'one database per developer' rather than 'one database per tree'" though it is not necessary to follow the "one database per developer" model. Torvalds has also complained about the performance of Monotone; this issue, by itself, appears to have been sufficient to make him look elsewhere.

There was a brief discussion on the mailing list about the opportunity to boost awareness of Monotone, and it seems that the team is working on improvements. One user on the Monotone-devel mailing list complained that it took more than two hours to pull the source, using 0.17. According to the release notes for 0.18, the new release improves "most operations sped up by a factor of 2 or better; many sped up by several orders of magnitude." Torvalds also gets a special "thank you" in the notes.

LWN readers interested in examining the various open source VCS might find the Version Control System Comparison useful, as well as this essay on systems. The Monotone webpage also provides a list of other version control systems, should Monotone fail to meet your needs.

In the long run, BitMover's exit from kernel development version control may be a boon for the open source community. While the kernel team will have to deal with some short-term pain in finding a replacement, it may provide a helpful boost to open source VCS to reach parity or even, eventually, move ahead of BitKeeper's feature set.

Comments (9 posted)

On polite Linux advocacy

Back in September, 1998, the LWN front page carried an article asking our readers to take a calm and respectful approach to those who criticize Linux. There were some magazine writers - long since disappeared from the scene - who had great fun with the inflammatory and childish responses they got from a few people when they ran critical articles. LWN pointed out that going on the attack against Linux critics rarely changed their mind, and, more often, just gave them material to use in portraying the Linux community as a group of unruly fanatics.

The better part of seven years later, little has changed. Laura DiDio is now having a field day talking about the Linux "nut jobs" who send her threatening mail and call her at home. This kind of press does not help us.

Since the beginning, Linux has had its opponents in the press and the "analyst" industry. Sometimes their criticisms have been fair and well founded; other times they have been silly or overtly biased. Linux was just a toy, you could lose your job by using it, it is not as secure, its total cost of ownership is higher, it has intellectual property problems, it's too complicated for mere mortals to use, it's going to fragment into a thousand incompatible pieces, etc.

All of these hostile articles and analyst studies have one thing in common: not a single one of them has slowed the development or uptake of Linux in any significant way. Even the more accurate and justified criticisms have served mostly as "to do" lists for near-term development; the rest has simply vanished without a trace.

When a writer or "analyst" comes out with something silly, by all means send in a polite, well-written correction. Then get on with life. These people are not worth getting worked up over, and they certainly are not worth flaming or harassing. The current crop of nay-sayers is unlikely to have any more real effect than its predecessors. But we'll still be here; let's try to behave in a way that we'll be proud of in the future.

Comments (16 posted)

Page editor: Jonathan Corbet
Next page: Security>>