LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||
LWN.net Weekly Edition for March 13, 2008Emacs chooses Bazaar 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 eyebrows. 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 history while 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 equals:
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
well enough.
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 choice. 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.
Some topics related to MP3 players 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. [PULL QUOTE: 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. END QUOTE] 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 catch up. 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.
Still waiting for Flash 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 about it.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, proprietary platform. 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 for it. 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 uniformly unsuccessful. 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 worse results). 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.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||