Leading items

Who is Fedora for?

Anybody who has gone near the Fedora mailing lists recently may have noticed that they have been a little...active. The discussions have reached the point where the "hall monitors" have intervened to shut down threads and many participants may have unsubscribed in favor of the relative calm and politeness of lists like linux-kernel. It's easy to dismiss it all as yet another Fedora flame war, but there are some serious issues at stake in the discussion. What it comes down to, it seems, is that the Fedora Project is still not entirely sure of who its users are or how to deliver what those users want.

Fedora is a rapidly-releasing distribution, with a new version coming out twice each year. Support limited to just over one year means that Fedora users must upgrade at least once annually or find themselves in a situation where security updates are no longer available. So one assumes that Fedora users are people who have a relatively high level of interest in running recent software, and who are not averse to updating that software with at least moderate frequency. But, it seems, there are limits.

Back in October, Fedora 11 users were surprised to discover that a routine update brought in a new version of Thunderbird with significantly changed behavior. In January, another Thunderbird update created trouble for a number of users. In March, some KDE users were surprised to discover that a "stable update" moved them to the 4.4.0 release, breaking things for some users. In all of these cases (and more), contentious email threads have ensued.

Fedora does indeed not hold back on the updates; a quick look in the LWN mailbox turns up over 600 package updates for the Fedora 11 release - in just the last month. This is a release which is scheduled for end-of-life in a few months. Many of these updates involve significant changes, and others have been deemed "worthless". Regardless of worth, there can be no doubt that all these updates represent a significant degree of churn in a distribution which is in the latter part of its short life. It is difficult to avoid breaking things when things are changing at that rate.

The parts of the discussion which were focused on constructive solutions were concerned with two overall topics: (1) what kind of stable updates are appropriate for a released Fedora distribution, and (2) how to minimize the number of regressions and other problems caused by whatever updates are considered appropriate.

With regard to the first question, it seems that some Fedora maintainers believe - probably with good reason - that their users want "adventurous updates," so it makes sense to them to push new versions of software into released distributions. Others describe their vision of Fedora as a "rolling update" distribution which is naturally following upstream releases. Others, instead, wonder why Fedora bothers making releases at all if it is devoted to rolling updates; users who want adventure, they say, can find plenty of it in Rawhide.

Several proposals have been put onto the release lifecycle proposals wiki page, and others have been posted to the list. They vary from nearly frozen releases to ideas that make releases look like a moderately-slowed version of Rawhide. This decision is one of fundamental distribution policy; it must be faced, or Fedora will continue to have different maintainers doing very different things. Given that need, it's unfortunate that the project seems to be unable to discuss the topic on its mailing lists; there is no clear means by which a consensus can be reached, currently.

Part (2), above, dodges the issue of what updates should be made and just concerns itself with the quality of those updates. The discussion is partly motivated by the fact that the system which Fedora has in place for the review of proposed updates - Bodhi - is often circumvented by updates which go straight out to users. The testing and voting which is supposed to happen in Bodhi is, in fact, not happening much of the time, and the quality of the distribution is suffering as a result. So some Fedora developers are looking for ways to beef up the system.

Matthew Garrett posted a proposal for a new policy which would eliminate developers' ability to push package updates directly into the update stream. Instead, updates would have to sit in the Bodhi system until they receive a minimal +3 "karma" value there; the only exception would be for security updates. By disabling direct pushes, the policy aims to ensure that every package which gets into the updates stream has actually been tested by some users who were happy with the results.

Suffice to say, this proposal was not received with universal acclaim. Some developers simply resent the imposition of extra bureaucracy into their workflow. Karel Zak's response is instructive:

One might observe that the kernel has, in fact, accumulated a fairly substantial set of rules over the last ten years, often in response to discussions with a striking resemblance to those being held in the Fedora community. The merge window, signoff requirements, review requirements, no-regression policy, etc. are all aimed primarily at improving release quality. The kernel also has layers of developers with something close to veto power over potentially problematic changes - a form of dynamic rule-making that Fedora lacks.

So rules might make sense; that says nothing about any specific proposal, though. Many developers feel that very few users test packages in Bodhi, and that large numbers of updates would languish there indefinitely. As Tom Callaway noted, the obstacles to getting those karma votes are significant. So one alternative which has been suggested is that, after 14 days without negative karma, a package would be allowed to proceed to the update stream. Other proposals have included requirements for regression tests or separate (more stringent) requirements for "critical path" packages; see this page for the contents of all of the proposals.

A rather contentious FESCO meeting was held on this topic on March 9. The apparent conclusion was to ponder further on Bill Nottingham's proposal, which involves regression testing and a requirement for positive Bodhi karma for all "critical path" and "important" components; others could proceed after a week in the updates-testing repository. It looks like another meeting will be held in the near future; whether it will come to concrete conclusions remains to be seen.

The "concrete conclusions" part is probably more important than the specific policy adopted (within reason) at this point. Many large and successful projects go through the occasional period where they try to determine what their goals are and how those goals can best be met. Properly handled, these discussions can lead to a more focused and more successful project, even if much heat is generated in the process. A good outcome, though, requires that there be a way to end the discussion with a clear conclusion. Fedora has governance institutions which should be able to do that; until those institutions act, Fedora risks looking like a contentious organization lacking a clear idea of what it is trying to do.

Comments (53 posted)

SCALE 8x: Gnash, the free Flash player

Rob Savoye of Open Media Now! (OMN) gave an overview of the work OMN has been doing on making free versions of various Adobe products available for use on free platforms. He concentrated mostly on Gnash, the GNU Flash player, but also touched on the Cygnal media server, and the Ming ActionScript compiler. Gnash has been one of the Free Software Foundation's priority projects for several years, which has resulted in more developers as well as raising the profile of the project.

Flash is important because it is used for web site navigation, video web sites, and, perhaps most importantly to Savoye, for educational applications. There are an enormous number of educational programs written in Flash and free software couldn't support running them. Because he is a "fanatic" about freedom, Savoye never installed the Flash plugin, which made him and others like him into "second-class citizens on the internet".

There are a number of reasons to implement a free replacement for the Flash plugin, beyond just being able to view YouTube. The Adobe plugin is full of security problems and doesn't integrate well with Linux. There is no 64-bit support and it is essentially only available for the x86 architecture. In addition, some day archeologists may want to play Flash content and the Adobe plugin may have long faded away.

Though he likes working on Gnash, Savoye is no fan of Flash. In answer to a question at the end of his talk, he said: "I hope Flash falls over dead", and that is something he is starting to see happen. In the meantime, though, he recommends against using Flash for web sites, and to use HTML 5 instead. He also suggested encouraging sites that do use Flash to at least test against Gnash so that the site will work for those on other platforms.

Some history

Gnash was started in 2004 because Savoye wanted a user interface for his stereo system. That was Gnash's first platform and he still runs his stereo that way today. In 2005, John Gilmore asked him to turn it into a browser plugin, and he delivered plugins for Firefox and Konqueror in 2006. YouTube support came in 2007.

The development community that formed after the FSF high-priority rating decided that it "would be really nice to have funding", so they started OMN, which has been funded by Bob Young, Mark Shuttleworth, John Gilmore, and others. They have continued to reverse-engineer the Adobe formats and protocols, while also getting Gnash running on "all sorts of weird hardware".

Weird devices

He put up a slide with a picture of Gnash running on various embedded devices: OLPC, Sharp Zaurus, Pepper Pad, Classmate PC, OpenMoko, Playstation 3, etc. He noted that Adobe Flash didn't run on any of them. The OLPC isn't able to redistribute the Adobe Flash player, so they turned to Gnash. As part of getting better Gnash performance on the OLPC, Savoye wrote some GCC and Glibc optimizations for the Geode processor.

Gnash is a clean-room re-implementation of Flash, which means that none of its developers have ever used Adobe's Flash. The EULA that comes with the Flash plugin restricts users from being able to create a competing Flash implementation. So, all of the development was done using publicly available documentation, which is important because if it wasn't done legally, the distributions won't include it. Though they were worried about legal action in the first few years, Adobe recently announced that Gnash is a "legal re-implementation" of Flash.

Gnash features

Gnash can be run either standalone or as a browser plugin for Firefox and Konqueror, with Safari support coming soon. It got OpenGL support for desktop graphics rendering before Adobe did, and has added Anti-Grain Geometry (AGG) support for embedded framebuffer-only devices.

One of the areas that Gnash has concentrated on is security. Adobe's Flash is "really insecure", Savoye said, and if you use a banking site with a Flash interface, you should "be worried". It also has better privacy protection because, by default, Gnash deletes all Flash cookies whenever it exits.

Gnash allows users to extend ActionScript with their own code, or by writing a wrapper around an existing development library. It also supports patent-free codecs, he said, in addition to the standard proprietary ones.

Compatibility, portability, and performance

Gnash can read SWF ("Shockwave Flash") version 9 and earlier files, but primarily supports SWF version 8. Version 9 is under active development, though. Roughly 80% of the ActionScript v2.0 library has been implemented, and the rest of it he has "never seen in the real world". SWF version 10 support is underway as well, but "it's pretty nasty". The ActionScript v3.0 library can reuse many of the v2.0 classes, but version 10 requires support for all of the previous versions, each running in different virtual machines, so there is a lot of work to be done.

Savoye said that they rarely port Gnash any more as it is just a matter of reconfiguring and recompiling it for new hardware. It will run on any system that is POSIX conforming and has ANSI C++ support. It also supports some non-POSIX environments; he noted that he had never heard of Haiku, which is a BeOS clone, but saw it and Gnash running on it down on the SCALE Expo floor. Gnash supports many different architectures, with big or little-endian processors of 32 or 64-bits. It also supports many different GUIs and desktop environments, as well as several back-end renderers (AGG, OpenGL, and Cairo).

For performance, Gnash can use the X11 Xvideo extension for high-resolution full-screen video. Xvideo also reduces the memory footprint. Support is also being added for hardware video decoding on Intel, ATI, and NVIDIA hardware using libvaapi.

It is written in C++ and uses the Boost libraries. Gnash uses either Gstreamer or FFmpeg for media handling. He noted that most distributions use Gstreamer to avoid the codec issues, but that FFmpeg is much faster and Gstreamer can use that as well. For HTTP and HTTPS, Gnash uses libcurl. It supports either GNOME or KDE desktops, or no desktop at all, he said.

Much like Perl or Python, Gnash can wrap any development library so that they can be used from ActionScript. Currently, there are extensions available for things like direct filesystem access, MySQL, GTK2, D-Bus, and so on. The extensions are added directly into ActionScript and can be accessed just like any other ActionScript class.

Current focus

The Gnash team is currently concentrating on supporting SWF 9 and 10, as well as ActionScript 3. "Chasing Adobe" is what they will be doing "for the rest of our lives, at least in this project", Savoye said. There is also ongoing work on the RTMP protocols for Gnash and Cygnal, getting better performance from low-end hardware, and better support for hardware acceleration. They are also working on Flash-based video conferencing so that there will be free solutions in that area.

There is also a lot of work going into Cygnal because there isn't a good rich media server in the free software world. Various groupware and video conferencing applications are written in Flash, but they need server-side support. By implementing a free media server, they can concentrate on better security and privacy than Adobe or another proprietary company is likely to provide, he said.

How to help

Savoye was not shy about suggesting "free beer" as one of the best aids for helping Gnash development, but there are others as well. "Good bug reports" are crucial. The usual suspects for a free software projects: translations, documentation, web site development and maintenance, build farm help, and so forth, are areas where people could help out. Also, donations are always appreciated, he said.

While it is sometimes galling to think that the "open web" requires some way to play Flash content, it is an unfortunate reality today. In six years or so, Gnash has come a long way towards replacing Adobe's closed plugin on x86 desktops, and is the only solution for many other devices and architectures. When one considers that Savoye and the rest of the Gnash team have never actually installed Flash for themselves, that feat is even more amazing. If the adoption of the newer versions of Flash can be slowed—or stopped—there is even hope that Gnash can catch up and we can get rid of one more non-free blob on our desktops.

Comments (14 posted)

Open source and the Morevna project

Konstatin Dmitriev's Morevna Project is to 2-D animation what the Blender Foundation's Open movie projects have been for 3-D. The goal is to produce a production-quality, full-length animated feature, using only open source software, and license the source content and final product under free, re-use-friendly terms. Along the way, the work provides stress-testing, feedback, and development help to the open source software used, while raising awareness of the quality of the code.

Despite the popularity of 3-D animated features churned out by Pixar and its competitors, 2-D animation is not a has-been style — particularly when you consider the wildly popular world of anime. Dmitriev is an anime fan as well as an animator and open source contributor, and in mid-2008 decided to combine his interests in one project. The first product was a brief short created entirely with the Synfig Studio animation package.

Synfig Studio is an animation suite built for 2-D production. Like Blender, it was originally written in-house at a private animation studio as closed source software, but was later opened. Unlike traditional cell-based animation, in which each frame is individually drawn, Synfig uses vector graphics as its underlying elements. The animator needs only to draw key frames, and the software smoothly interpolates between them to create motion.

Production and workflow

Dmitriev is active in the Synfig Studio project and, since announcing the Morevna Project, has gathered a small team of like-minded contributors and artists. Their process reflects that of a traditional animated movie team: it starts with an idea, followed by a screenplay, storyboard, character designs and other creative work, well before animation itself gets underway. For its story, the project decided on the Russian folk tale "Marya Morevna" — but re-imagined in a futuristic setting befitting the anime style.

The script (in English and in Russian), character and production designs are all publicly available on the project's wiki — so don't look if you wish to avoid spoilers. The first portion of the screenplay has already been storyboarded and broken down into shots, and as the team completes work it has been posting demo videos to YouTube — completed animations and "animatics" — the wireframe, in-progress animations that bridge the gap between static storyboard and finished product.

For the actual production pipeline, Dmitriev and the other artists use a variety of open source tools. Animatics are made in Pencil, a cell-oriented "flipbook"-style animation tool. Rough sketches as well as backgrounds and other static imagery are produced in the raster editors Krita and Gimp. Vector-based character designs are drawn in Inkscape, while 3-D models for buildings, machines, and other non-character entities are produced in Blender. All of the content is stored in a Git repository, to allow the remote team members to coordinate their work.

When ready, the various layers of artwork are combined and converted into key frames in Synfig, which is used to render the animation. Further compositing (such as special effects) is done in Blender for final output. The final movie will be rendered in 16:9 1080p resolution.

Openness

As with Blender's open movies, part of the Morevna Project's goals are to improve Synfig and open source animation in general. The team documents progress on the movie on its blog, and has posted several entries about new Synfig features spawned along the way. For example, using Blender's IPO (interpolation) drivers gives the animator more fine-grained control over timing; the Morevna Project uses the technique to suddenly send a scene into slow-motion — an effect often seen in action movies these days — but which was not available in Synfig Studio until the project implemented the technique. The project also created a widget allowing the animator to manipulate the "camera view" in Synfig Studio, adding easy-to-use pan and zoom functions.

The project is licensing its artwork under Creative Commons' Attribution license, so that it can be freely reused. The plan is to do the same for final product and sounds, although licensing for some of the music may dictate different terms. It has also released a character-animation template called Stickman under the no-copyright CC Zero license. Stickman is used by Morevna Project artists to produce animatics with Synfig Studio.

The members of the Morevna Project are taking the openness of the content itself to a new level. Not only is the entire screenplay available online, but the wiki captures the evolution of character and scene designs, not just the final product — including variants and experiments that will not make it to the final product. If you think 2-D animation is somehow simple, take a look at the Battlefield concept art page to see how much work goes into creating a scene.

Still to come

The Morevna Project is still a long way from its final product, does not have corporate or grant funding, and the team is only six people strong — but it is attracting a great deal of attention. Dmitriev writes on the project blog that the anime and open source communities seems to have a great deal of overlap, and the Ubuntu Massachusetts LoCo is planning to promote Morevna at an upcoming Boston anime convention. Anyone who is interesting in joining the creative team should read the Contributor's Guide on the project wiki.

In fact, anyone with an open source project that could use more contributors would do well to read the Morevna Contributor's Guide, because it is a remarkably complete, thorough, and well-written introduction to the project and how to get started joining it. That bodes well for its future success.

Regardless of whether you are an anime addict or not, Morevna — like Blender's open movies — is a project everyone in the open source community should support. Large-scale creative projects like these do something that many other niches in open source cannot — they bring awareness of open source to the general public. Few people care what operating system runs on their mobile phones. The fact that an enterprise's ERP system and web infrastructure runs Linux, MySQL, and other open source components is nebulous at best to people who work outside the IT industry. A high-quality animated movie, on the other hand, anyone can see and appreciate.

Comments (4 posted)

Mozilla to update the MPL

The Mozilla Foundation has launched a process to update the Mozilla Public License. The project is described this way:

While the update process is inspired by the GPLv3 update, the objectives are far less ambitious: Mozilla would like to smooth various rough edges without making major changes to the license. They hope to have the process complete - after releasing three drafts for comments - by November of this year.

Comments (16 posted)