The Emacs development process is undergoing some changes; Richard Stallman
has handed off project
maintenance duties, while a change in the version control system (VCS)
seems to be in the offing. Some of the modernization suggestions made by
Eric Raymond last December are taking root. Stallman has not completely
stepped away from Emacs development—it's doubtful anyone expected him
to—but his approach on how to choose a VCS for Emacs is raising a few
Currently, Emacs is tracked with CVS, but a distributed VCS (DVCS) is definitely
planned down the road—how far is unclear at this point. In
earlier discussions, Stallman was particularly interested in the offline
capabilities of DVCS; being able to do commits, diffs, and see revision
unconnected to the internet is a useful feature for him. Many other Emacs
developers see a DVCS as a major upgrade to the development process, the
question then becomes which DVCS to use.
The main contenders are git, Mercurial (aka hg), or Bazaar (aka bzr); there are other options, of
course, but they were quickly
eliminated due to speed or feature set issues. There was some hope that
a comparative VCS study that Raymond was working on would help lead the project to the proper
choice, but the study has been delayed—a major release of Wesnoth is
underway which has taken Raymond from that task.
There were some discussions of the merits of the various systems but, in
the meantime, Bazaar joined the GNU project which changed the equation
somewhat. Stallman announced:
We should use Bzr because that is becoming a GNU package.
GNU packages should show loyalty to each other when possible,
and in this case it is possible.
As might be expected, short-circuiting a technical discussion for a
political expedient is not met with universal approval. Juanma Barranquero
sums up his (and others') objections:
What I'm trying to say is: I won't discuss which dVCS we choose
(unless it makes Windows development a PITA). But I agree with Jeremy
Maitin-Shepard that the cause of free software is strengthened by us
selecting among the free alternatives the one that best serves our
technical, not political, needs.
There is a certain irony in noting that one of the perceived weaknesses of git was its
poor support for Windows development. It is
certainly understandable, but the idea that one of the flagship GNU
projects would make a decision based on tool availability for a proprietary
operating system gives one pause. That isn't one of
Stallman's requirements of course, he sees the decision as essentially a choice amongst
We already know the most important thing about what we will find from
a careful study of git, mercurial and Bzr. We will find that each has
its advantages and disadvantages -- but none of them conclusive. Each
will be preferred by some people, but any one of them would work out
As Thomas Lord (author of another GNU VCS, arch), points out, there is a cost to
agonizing over a choice like this:
Probably so but any group of smart people could easily spend
a year arguing about it. Not even a year arguing about which system
is best but a year arguing just about what "best" means in this context.
Over-optimizing a choice like that can be a *huge* resource
suck and projects and groups fail all the time because of falling
into such traps.
No technical barriers to using Bazaar have been raised, it is, as Stallman
asserts, a fairly arbitrary choice. Unsurprisingly, Stallman chooses the one
that serves his agenda. The new maintainers, Stefan Monnier and Chong
Yidong, presumably agree with that
agenda, in any case they have not indicated any resistance to the
So it seems that Emacs will be moving to Bazaar. Jason Earl has been
pulling the CVS history into a Bazaar repository that should be available
soon. The import process seems to be taking a fair amount of time—something on the order of a week—which is hopefully not indicative of
the operational speed of Bazaar. Assuming the conversion works and
developers can get their work done using it, this would be a pretty
high-profile project to use it. Other GNU software may follow suit, which
could be a big boost to the visibility of Bazaar; precisely
what Stallman was aiming for.
Comments (45 posted)
In many parts of the world, the U.S. is looked upon as a place with
particularly poor taste in "intellectual property" legislation; the DMCA
and software patents are often held up as examples. DMCA-like laws have
since spread to other parts of the planet, which, for some reason, has not
made people living there any more appreciative of the American legal
regime. But it is often pointed out that software patents remain an almost
entirely American problem; people in other parts of the world (Europe, say)
need not worry about them.
If only it were so. On March 5, German police raided a booth at the CeBit
conference in Hannover. That booth, run by Meizu, contained an
iPhone-clone product, but nobody cared about that. Instead, the contraband
which absolutely had to be suppressed was a music player for which Sisvel
(an Italian company which has done this kind of thing before)
had not been paid royalties on its MP3 patents. The player, as it happens,
did not even have MP3 playback capability, but that didn't seem to matter.
The police duly cleared the booth of all mention of the offending device
and saved another day for free enterprise.
This is a pure software patent action, and the
U.S. has no part in it. Software patents are truly a global problem.
(Police raids raise the stakes in interesting way, though; even in the
U.S., things usually start with a polite letter from a lawyer first).
Anybody who wonders why companies like Red Hat exercise great care around
software patents (and MP3 patents in particular) need only look at episodes
like this. The selling of enterprise Linux products is likely to be
distinctly harder if your prospective customers see your conference booth
being forcibly shut down by the authorities.
Meanwhile, it occurred to your editor, while thinking about music players,
that little has been said about the Rockbox project on LWN in recent times.
Rockbox, remember, is a GPL-licensed firmware which runs on a wide
variety of music players. It offers a wider range of features, has
more codecs, is more customizable, and has better accessibility support
than the stock firmware on any of these devices. And it's free software.
Since LWN last looked at this project, the Rockbox developers have added a
number of new features and new platforms. The abandoned 3.0 release has never
happened; the Rockbox developers appear to have given up on the idea of
formal releases for now. The daily snapshots generally work quite well,
though, and there are lots of satisfied Rockbox users out there.
Despite the fact that Rockbox supports a lot of players,
absolutely none of the supported platforms are currently in production. So
anybody looking to buy a player which can run Rockbox must go digging
around on auction sites.
The only problem is: it's not clear how many more such users may arrive in
the future. Despite the fact that Rockbox supports a lot of players,
absolutely none of the supported platforms are currently in production. So
anybody looking to buy a player which can run Rockbox must go digging
around on auction sites. Many Rockbox users do exactly that, but many more
potential users would rather not get their devices that way.
Rockbox ports to current devices are underway, but the developers are fighting an
uphill battle. Manufacturers tend to be uncooperative when it comes to
releasing hardware information, so a certain amount of reverse engineering
is required. And, by the time that work is done, the manufacturers have
moved on to a new product. Music players are consumer electronics devices,
and, like most such devices, their product lifetime tends to be quite
short. So developers on a project like Rockbox will forever be trying to
Your editor, meanwhile, still lugs around his ancient iRiver H340. People
look at it strangely, as if they expect there to be a hatch on the back
so that the user can occasionally add another shovel full of coal. But it
works beautifully with Rockbox, and a replacement looks hard to find. Your
editor wishes that at least one manufacturer would realize that it could
provide better functionality at a lower cost by designing its players to
run Rockbox from the beginning. Perhaps the project needs better advocacy
within the player industry.
There is another approach which could be considered here. The OpenMoko
project is trying to rearrange the mobile telephone market by offering a
completely open product. Surely a music player, being a much simpler
device, would be amenable to the same treatment? As it turns out, there
are a couple groups of people trying to jump start just this kind of
effort. They have a
prototype design, and a
competing design as well. Both look like they could produce a
respectable player at a reasonable cost - a player designed to run free
software from the outset.
Designing a device which can run Rockbox and produce decent audio (and
video) output is not that hard, given the components which are available.
Turning it into a product which is small and sleek enough that people want
to buy it seems likely to be harder. Getting a full device manufactured at
a reasonable cost may be the hardest of all; that requires significant
up-front money and a distribution channel which can sell enough units to make
the whole thing cost-effective. There's also the little issue of those MP3
patents to take care of.
There is no real sign that the Rockbox player developers are thinking on
this level at this time. One of the prototype designs carries a Creative
Commons noncommercial license in an attempt to prevent others from thinking
that way. So the resulting hardware may end up being little more than a
kit for especially dedicated hobbyists. Unless somebody picks up the ball
and tries to commercialize a product like this, Rockbox may be stuck in its
role as the software of choice for last year's players. The good news in
all this is that Linux-based tablet devices seem likely to become cheaper,
more abundant, and more compact. Since these devices can make fine media
players, we may eventually get our completely open gadget via that path.
Modulo patent problems, of course.
Comments (23 posted)
Those of us who were using Linux full-time around the turn of the century
will remember that the state of web browsing on Linux was a little scary
then. The only real option available was the binary-only Netscape 4
client; it was buggy and old. It really seemed like the web was going to
move forward without Linux, and that there was not a whole lot we could do
Things have improved somewhat on that front; we now have a few top-quality
web browsers to choose between. At the same time, though, one might be
forgiven for thinking that we are heading back into a similar situation,
but involving Flash this time around. For all practical purposes, there is
only one viable option for Flash on Linux: the binary-only plugin provided
by Adobe. But that plugin is not just proprietary software; it also is
somewhat old and buggy, and there is nothing we can do to fix it. For an
increasing part of the web experience, we still have a second-rate,
When one thinks of Flash, naturally, one thinks of video sites like
YouTube. But there is more to the Flash experience than silly videos and
obnoxious advertising. Some parts of Google are heavily into flash, as can
be seen from that company's finance sites or analytics offerings. Your
editor's children will attest that there's no end of game sites which
require Flash, and for which the Linux plugin fails to work properly.
Looking for any way to reduce the total amount of time spent in airplane
seats, your editor recently investigated "around the world" tickets; that
search ended up at this
travel planning site which, of course, requires Flash. And so on.
Like it or not, Flash is the language in which an increasing number of
interactive sites are being coded, and Linux does not have proper support
With this in mind, your editor decided to give the recently-announced Gnash 0.8.2 release a try. This
release was billed as the first beta version of Gnash, so there was reason
to hope that it would be something close to a true solution to the Flash
problem. In reality, Gnash is a step in the right direction, but the Flash
issue will be with us for some time yet.
For now, the acid test for a Flash player would appear to be YouTube, so
that is the first place your editor went. The experience there was mixed.
It is, in fact, possible to watch YouTube videos using the Gnash Firefox
plugin. Hearing them is another matter, though; they all played silently.
It would not be surprising to learn that getting audio is a matter of
filling in a missing codec - but would sure be nice if the software were to
say something to that effect. Pausing and playing the video worked, but
skipping around in it did not. Playing videos from other sites was
The "around the world" calculator appeared to load properly, but then took
off as if somebody were punching all of its buttons at once. Charts on
Google sites are uniformly blank. Some flash games mostly worked, others
showed more input-related confusion. Few of them were truly playable. On
the other hand, Flash "intros" and advertisements mostly work as intended -
just what your editor wanted.
So Gnash is not really there yet. In truth, this software is not in a
condition where the use of the term "beta" makes sense; there is a
lot of work yet to be done. There are few of us clamoring for
support for more obnoxious advertising - especially among the LWN
readership, as your plentiful emails over the last couple of months have
made clear. What we want is working support for the useful Flash
applications out there - and there are a few of those at this point. Gnash
does not, currently, provide that support. (Your editor also tried out Swfdec 0.6.0, with generally
That said, it is clear that a lot of work has been done to get Gnash to
this point. Your editor has no real way to judge how much more is required
to get full support for even Flash version 7; chances are it is not a
small job. Needless to say, support for newer versions of Flash will
require even more work. But there now appears to be a solid platform upon
which that work can be done, and that is an important start. Gnash has the
look of a project which has overcome some of the biggest initial hurdles
and is now setting a pace to finish the job. With luck, it will have
reached the point where the fact that it almost works will inspire
new developers to come in and fill in the remaining pieces.
Adobe has the ability to make this job a lot easier. Your editor has
heard, informally, that the company has taken a less hostile position
toward the Gnash developers than it had in the past, but it certainly is still not
helping them. The Flash specifications are not available to anybody trying
to create a Flash player, and, unsurprisingly, the Flash EULA
forbids any sort of reverse engineering. That EULA, incidentally, also
forbids running Adobe's player on any "non-PC device," including tablets
and phones. That restriction suggests that Adobe sees business
opportunities in the lack of a free Flash player for such systems and
intends to ensure that this scarcity continues. So, despite the
occasionally friendly noises Adobe has been making toward the Linux
community, we should not expect a great deal of help from that direction.
Someday, people will figure out that closed standards (like Flash) are best
avoided. Meanwhile, Flash is a fact of life that we will need to
deal with. It appears that we are getting closer to being able to deal
with it - but we are not there yet.
Comments (49 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Extended Validation certificates and cross-site scripting; New vulnerabilities in java, joomla, lighttpd, phpMyAdmin,...
- Kernel: A better DMA memory allocator; How to use a terabyte of RAM; GCC 4.3.0 exposes a kernel bug.
- Distributions: News from the Debian security team; 64 Studio 2.1rc1; Ubuntu Hardy Alpha 6; Debian armel port; Fedora BugZappers; Eric Sandeen on ext4 implementation
- Development: Monitor disks with the S.M.A.R.T. monitoring tools, the first Gnash beta,
memory usage in Firefox 3, new versions of SE-PostgreSQL, libnfnetlink,
lighttpd, Synfig, FET, XCircuit, Wine, Elisa, Dirac, GCC, MonoDevelop,
CSSBox, GNU Classpath, CodeInvestigator, GIT.
- Press: Top 10 Linux Desktop Hurdles, World Domination for the Wrong Reasons, KDE at CeBIT, Miguel de Icaza on Microsoft patent deal, Red Hat adds IP lawyers, Wal-Mart stops selling Linux machines, Linux forensic live-CD, OLPC to run XP soon, Samba 4 reaches alpha.
- Announcements: BusyBox settles lawsuit, Google Summer of Code 2008, new OO.o license, Microsoft's Document Interoperability Initiative, Clean Room Design Practice, Flash Memory cfp, LinuxWorld BOF cfp, Global Open Source Conf, GoOOoCon - Prague, KVM developer forum, Linux Foundation Collaboration Summit, PTPW 2008, PyCon begins, LCA Gaming videos.