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:
Um, because some of them are security bugs that they never got
around to fixing. That's kind of annoying (Fedora security process
definitely seems to be disturbingly low priority -- see the
perl-suid buffer overflow trivial root exploit, for example) but I
don't really care whose responsibility it ought to be, since there
are people who are depending on us to make available patches to
secure their systems.
(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)
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
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
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
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)
Back in September, 1998
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
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
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
Inside this week's LWN.net Weekly Edition
- Security: The OpenOffice.org problem; New vulnerabilities in gld, junkbuster, kernel, phpMyAdmin, ...
- Kernel: The guts of git; More git; Extending netlink; FUSE hits a snag.
- Distributions: Distribution list update; Ubuntu 5.04; Mandriva Limited Edition 2005; ExTiX
- Development: The Xaraya Web Application Framework, new versions of
PostgreSQL, Samba, Oggz, Mod_spambot, Quixote, Xaraya, Ecasound,
matplotlib, Wavy Navy, GIMP, BEAST/BSE, OO.o, Febrl, phpThumb, monotone.
- Press: Legal computer forensics and open source, UK Patent Workshop,
UK Open Source Academy, Andrew Tridgell interview,
online book by Peter Salus, embedded Web interface, Code Obfuscation.
- Announcements: Itanium Community Joins GCC Developers, Mandrakesoft becomes Mandriva,
VIA releases drivers, Audio Musings, FLOSS survey, aKademy 2005,
Italian Perl Workshop, Open Source Training Database.
- Letters: Correcting Laura; VIA's driver release.