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
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
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
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
Fedora strongly depends on well-motivated and non-frustrated
maintainers and open source developers. We want to increment number
of responsible maintainers who are able to use common sense. Our
mission is to keep maintainers happy otherwise we will lost them
and then we will lost users and our good position in Linux
Always when I see that someone is trying to introduce a new rule I
have to ask myself ... why so large project like kernel is able to
successfully exist for 20 years without a huge collection of rules?
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
page for the contents of all of the proposals.
contentious FESCO meeting was held on this topic on March 9. The
apparent conclusion was to ponder further
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
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)
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
for several years,
which has resulted in more developers as well as raising the profile of the
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.
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".
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 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.
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)
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.
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
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)
The Mozilla Foundation has launched a
process to update the Mozilla Public License
. The project is described
We've been using
version 1.1 of the Mozilla Public License for about a decade now. Its
spirit has served us well, helping to communicate some of the values that
underpin our large and growing community. However, some of its wording may
be showing its age. Keeping both those things in mind, we're launching this
process to update the license, hoping to modernize and simplify it while
still keeping the things that have made the license and the Mozilla project
such a success.
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
Comments (16 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: SCALE 8x: Ten million and one penguins; New vulnerabilities in apache, cups, curl, samba,...
- Kernel: Deadline scheduler; 2.6.34 part 2; Nouveau and interface compatibility; 4K-sector drives; Zombie quotes.
- Distributions: Rolling with Arch Linux; Fedora 13 Alpha released; Debian Project Leader Elections 2010; Ubuntu changing its look; MeeGo: Toward Day One; Announcing NEOPhysis; interview with Mark Shuttleworth.
- Development: Bluefish 2.0; Releases from Apache, Mercurial, OpenSSH, Renoise, ...
- Announcements: Magnatune sends check to GNOME Foundation thanks to Rhythmbox; European Parliament pushes back on ACTA; Meanwhile, back in Utah...; Elliott Associates and Novell; Schwartz: Good Artists Copy, Great Artists Steal; Simon Phipps: Last Day At Sun.