Systemd, an alternative to Upstart or System V init, has made big
strides since it was announced at the
end of April. It has been packaged for Fedora and openSUSE, and for users
of Fedora Rawhide, it gets installed as the default. There are still bugs
to be shaken out, of course, and that work is proceeding, especially in the
Rawhide. The big question is whether Fedora makes the leap to use
systemd as the init system for Fedora 14.
When last we looked in on
systemd, Lennart Poettering intended to have a package ready for Fedora
14, which has happened, but it was unclear what, exactly, openSUSE's plans
were. Since then, Kay Sievers, who worked with Poettering on
developing systemd, has created an openSUSE Factory—essentially the
equivalent of Fedora's Rawhide—package along with web page of instructions for
interested users. But most of the action seems to be going on in Fedora-land.
The Rawhide package gets installed in parallel with the existing Upstart
daemon, so users can switch back and forth. That's important because of
some glitches in the systemd installation that require users who upgrade
from earlier Rawhides to manually
enable certain services and targets:
# systemctl enable getty@.service prefdm.service getty.target \
rc-local.service remote-fs.target graphical.target
(The last "graphical.target" entry comes from a second message
and will resolve the common
"Failed to load configuration for default.target" problem).
The magic incantation to switch between the two is detailed in a fedora-devel posting announcing that systemd was made the
Rawhide near the end of July. The kernel command line init
parameter can be used to choose either systemd
(init=/bin/systemd) or Upstart (init=/sbin/upstart); as
Poettering points out: "note the /sbin vs. /bin!"
There are various other problems being reported on fedora-devel as well,
from the network not coming up
automatically to shutdown behaving
strangely. The fixes are generally straightforward, for the network it
is a simple matter of doing:
# systemctl enable NetworkManager.service
# systemctl start NetworkManager.service
and the shutdown problem was addressed by Poettering in the systemd git repository
within a few days of the report. While he was congratulated for his quick
response on the shutdown problem, Poettering's responses on other systemd
breakage has caused some consternation among other Fedora developers.
In particular, a dubious interpretation of
the "noauto" mount option in /etc/fstab caused numerous
complaints. Essentially, that option is meant to tell the system that the
filesystem should never be mounted except by an explicit action of the
user. But the systemd developers decided that "noauto" just means
that the boot shouldn't wait for the filesystem to be mounted, but will still
proceed to mount them if present at boot time or plugged in later.
Poettering has changed systemd so that its "noauto" behavior matches
expectations—and the documented semantics—but some of his
responses rubbed folks the wrong way. Worse, though, is the concern that
Fedora will be making a big mistake by adopting systemd now, instead of
making it optional for Fedora 14 and then the default in Fedora 15 if all
is well. Matthew Miller voiced his
[...] When you're replacing a core
component of the OS, and you're faced with a point where a human interface
could be changed, the first thought must be "how can we make this
improvement with minimal disruption?".
So, my question is serious. If we go ahead with systemd for F14, will we be
hit with an onslaught of confusion, trouble, and change? That would be good
for testing systemd, but *not awesome* for the distribution or for its
users. Or, on the other hand, is it a matter of a few kinks which we can get
solved before release?
Poettering is characteristically optimistic
in response: "Quite frankly I'd draw a completely different conclusion of the current
state of affairs: everything is looking pretty great." He goes on
to note that any issues reported have been quickly fixed, and that the
number of bugs has actually been fairly small:
That all said if you have a look on the number and quality of open bugs
of systemd for F14 then it appears to be a lot stabler and more polished
than probably most of the stuff in the current base system. It's
definitely not a good metric, but I do believe if that even if the
number increases to a healthy level comparable with other core packages
we'd still be fine.
So, [breathe] deeply, and let's all be jolly!
He has also started a
series of blog posts to help administrators become familiar with systemd
and to ease their transition.
But his overall approach sometimes come under question. At least partially
because of the way he handled PulseAudio complaints, Poettering has
something of a
reputation for waving away bugs as features, which tends to irk some.
Miller puts it this way: "The
pattern I see is that each time, you respond initially with (paraphrased)
'It's not broken -- we've made it better!' before implementing the
The thread went on for quite a ways, even by fedora-devel standards, but
the crux of the issue seems to be that there are worries that major changes
that break things are chasing Fedora users away and a switch to systemd may
be just that kind of change. There is no hard evidence
of that, but it is clearly a fairly widespread—though not
universal—belief. To try to escape the flames and assist with
moving the decision about using systemd as the default in Fedora 14 to a
technical, rather than emotional, basis, Bill
Nottingham started a thread about
acceptance criteria for systemd: "From [reading] the thread, there
are many things that I think people would like covered with systemd before
they would feel comfortable with it. So, I'm going to attempt to quantify
what would need to be tested and verified."
As might be guessed, the flames didn't completely subside but the focus did
shift to technical considerations, with an emphasis on backward compatibility
to existing Upstart—and earlier System V
init—functionality. There are lots of moving parts that go
into making the transition from Upstart (which is mostly run in
sysvinit compatibility mode in Fedora currently) to systemd,
however, and Poettering is feeling like he is getting saddled with fixing
any and all problems, even those that are legitimately outside of
There is a difference between what the Fedora and systemd projects need to
do, though. As pointed out by several people, Fedora needs to ensure that
the system works well, regardless of where the problem lies. As
Nottingham notes, there is a higher burden
on the person pushing a major change, but the distribution as a whole needs
to get it
It's about the integration into the system. Playing a blame game doesn't
help... if the system doesn't work, we can't ship that way. If there are enough
blockers in other packages that prevent a systemd system from functioning to
these sorts of specifications, we cannot ship systemd. Period.
The onus is on the introducer of a large change to make sure that change
works in the system. Sure, we can fire up requests for help, we can lean on
people to fix their packages, and we've got people who are willing to help.
As he surely recognizes, Poettering's best strategy is to fix any bugs
found in systemd and any other component where he has time and enough
understanding to do so. Enlisting aid for any that he, or other systemd
developers, can't address seems appropriate as well. There is no one in
Fedora that can wave a magic wand and force developers to work on specific
tasks, so some amount of team building may be necessary. There is always a
hump to get over between the
development and deployment of a new feature, and the hump in this case is
larger than many. That said, none of the remaining issues looks so
daunting that they cannot possibly be overcome in the next few weeks.
The Fedora 14
schedule shows a "Beta Change Deadline" on September 14. On or before
that date, there will undoubtedly be a "go or no go" decision made on
systemd for Fedora 14. Between now and then, testing systemd, reporting
and perhaps more importantly, pitching in to fix bugs are all things that
systemd fans can do to push it forward. Otherwise, we may have to wait
until Fedora 15 to really see what systemd can do.
Comments (135 posted)
Your editor was recently amused to encounter this
on "Android's dirty little secret." According to that
article, the openness of Android has led to an increase in the control held
by handset manufacturers and wireless carriers and the fragmentation of the
platform. The Open Handset Alliance is in a "shambles," and Android phones
have undone all the gains won by that great standard bearer for openness
and freedom - the iPhone. One might easily conclude that Android is just
business as usual for the mobile telephony industry, but there are a few
things worth contemplating here.
The authors seem surprised by the fact that the Open Handset Alliance is
not functioning like a free software project, and that manufacturers are
not feeding their changes back into the common software core. That is very
much true; very little code from HTC, Samsung, or Motorola (for example)
can be found in the Android distribution. This outcome is unsurprising,
though, for a number of reasons.
The first of those, quite simply, is that Android is still not run like a
free software project. Work is done behind closed doors at Google, with
the code being "dropped" into the public repository on occasion. It is not
uncommon for the code to show up some time after the software starts
shipping on handsets. Outsiders have little visibility into what is going
on and little say over the direction of Android development; there is no
easy way (or incentive) for them to contribute back.
When manufacturers have contributed back, it has tended to be at the lower
levels - in the kernel, for example. Some of those contributions go
directly upstream, which is where they should go. Others tend to sit in the
Android repository. But, regardless of where these contributions end up,
they tend not to be the sort of high-level, user-visible code that the
article is talking about. The manufacturers prefer to keep that code to
And "keep it to themselves" is exactly what these manufacturers are
entitled to do. At that level of the system, permissive licenses rule, by
Google's choice. If more of the Android system were licensed under the GPL,
manufacturers would have been required to contribute their changes back -
at least, those changes which are demonstrably derived from the
GPL-licensed code. Google's decision to avoid the GPL is arguably
regrettable, but it is motivated by an understandable fear: manufacturers
would simply refuse to use a GPL-licensed Android system. If the choice is
truly between permissive licensing and obscurity - and that's how this
choice is seen by many - it's not surprising that Google opted for the
A related complaint is that the openness of Android allows every
manufacturer - and carriers too - to put their own code onto the handsets
they sell. Such code can be custom user interfaces, "crapware," or
restrictions on what the handset can do. These additions are seen to be
undesirable because they contribute to the fragmentation of the system and
because they are often antifeatures that customers would not choose to
have. The implied subtext is that an Android which disallowed such changes
would be a better platform with fewer "dirty little secrets."
As many have pointed out, Android does not differ from other mobile
platforms in its malleability in the hands of manufacturers and carriers.
Handsets based on Symbian or Windows Mobile can also be customized by
vendors. Those handsets, too, can be locked to carriers, restricted in the
applications which can be installed, or otherwise crippled. The article
presents the iPhone as an independent platform which is immune from this
sort of meddling, but the stories of the Google Voice application and the
control over the App Store in general say otherwise. Android has
not magically fixed this problem (and it is a problem), but neither has it
created the problem.
MeeGo, possibly, is trying to do something about the fragmentation side of
the issue; there are various rules which must be followed to be able to use
the MeeGo name. How useful that will be remains to be
seen; there are a number of Android-based devices on the market now which
do not advertise the provenance of their software. And, despite the fact
that MeeGo is not as afraid of the GPL as Android is, it is still true that
MeeGo does not expect to flourish by restricting the flexibility of
manufacturers and carriers. When we are lucky enough to be able to obtain
MeeGo-based devices, we'll see that they've been messed with in many of the
same ways as all the others.
In summary, there are two separate concerns here: fragmentation and freedom.
Fragmentation, of course, has been a staple of anti-Linux FUD since the
beginning; surely, with the source in the open and with all those
distributions, Linux would have to go in many different directions. But
Linux has not fragmented in the way that Unix did twenty years ago. The
main reason for this, arguably, is the common core (kernel, plumbing layer,
and more) that is used by all distributions. Even if strange things are
done at the higher levels in a specific distribution, it's still Linux
underneath. A convincing case can be made that the use of the GPL at those
levels has done a lot to prevent forks and keep everybody in sync.
Android is still Linux underneath, albeit a somewhat limited and strange
Linux. But one could argue that much of the Android core is no longer
GPL-licensed. So, while Android is based on the Linux kernel, the rest of
the system more closely resembles BSD from a licensing point of view. That
might make Android more susceptible to fragmentation; perhaps Android
heralds the return of the Unix wars. Or it might not; most vendors do
eventually realize that the costs of straying too far are too high.
In any case, it's hard to imagine manufacturers going too far afield as long
as Google continues to put resources into pushing Android forward at high
Freedom seems like a harder problem. The demise of the Nexus One as a
mass-market product was taken by some as a sign that consumers have little
interest in freedom in general. There are a couple of things worth noting,
though, starting with the fact that the Nexus One, in its new role as a
developer phone, has quickly sold out. Clearly there is some
interest in relatively open hardware out there.
Then there is the tremendous level of interest in the jailbreaking of
phones, loading of alternative distributions, etc. Contributions to
CyanogenMod have reached a point where the project has had to set up its
own Gerrit system to manage the review process. Your editor suspects
that very few of the people who are jailbreaking phones or installing new
firmware actually need to do that in order to use their handsets.
Instead, those people want the freedom to mess with
the device and see what comes of it.
In other words, Android has kicked off a small (but growing) community of
developers and users with an interest in freedom and making full use of the
hardware they have bought. With any luck at all, this community will grow,
providing a market for vendors who sell open handsets and resisting
legislative attempts to make handset hacking harder. Interesting things
can only come of all that.
If Android has a "dirty little secret," it's that freedom works both ways.
Of course customer-hostile companies (of which there are many in the mobile
telephone business) can make use of the freedom provided by Android to do
customer-hostile things. But that freedom also appears to be supporting a
whole new generation of hobbyists, enthusiasts, and hackers who want to do
interesting things with current computing platforms. All told, Android has
not made things worse; instead, it looks like it is making things better.
Comments (17 posted)
The GNU Flash player Gnash
released version 0.8.8 on August 22, the first release advertised as
supporting 100% of the Flash videos hosted at YouTube, in addition to GPU
acceleration and a host of new features. It is also the first release
following a public disagreement between the leading contributors about the
project's development process. In addition, although the Gnash project and
the alternative free software Flash player Lightspark continue to cover
different parts of the Flash specification, development is progressing on
ways for users to seamlessly integrate both into the web browsing
The disagreement started in mid-May, between Gnash maintainer Rob Savoye and leading contributor Benjamin Wolsey over development policies. Savoye was in favor of making frequent, experimental commits, while Wolsey argued that commits must be rejected if they broke existing tests — or else the stability of Gnash would suffer.
Eventually the two sides settled
on drafting a set of commit policies for the project, which clarified the
need to prevent test regressions and outlined a multi-step policy for
handling checkins, without the potential for conflict that can arise when
one developer reverts another's changes. Documented on the project wiki,
the policy deems
reversions "a last resort" to be taken only after discussing
the issue on IRC, on the mailing list, and blocking out the offending code
Judging by the mailing list traffic and the progress of the code since
then, the policy and the discussion surrounding it seems to have succeeded,
and development returned to normal. A much bigger hurdle for the project is
lack of funding. Savoye is historically the only developer who works
full-time on Gnash, and donations to the non-profit Open Media Now project he established to
raise funds for paying developers have slowed down to the point where he has
started taking on other coding jobs.
Gnash's lack of sustained funding has been a problem for all of 2010,
even forcing the team to drop plans to develop support for newer Flash 9
features like ActionScript 3.0. The project is one of the Free Software
priority projects, but that status does not bestow any funds to help
development, only publicity done by the FSF. Savoye told the Gnash mailing
list in early August that unless donations or other funding pick up, the
maintenance of the existing code — including the multiple rendering
paths targeting different desktop and embedded platforms — will
consume enough time that integrating new features will take a back seat, and
the release schedule may have to slow down.
As to the code itself, source tarballs are provided on the GNU FTP
mirrors, and the release is available via Git. The GetGnash.org site hosts
experimental packages of
the release, including Debian packages for Debian, gNewSense, and Ubuntu
via an Apt repository, as well as Fedora and OLPC packages via a Yum repository.
At the time of this writing, the "experimental" nature of the GetGnash.org packages is fully in evidence, at least for the Ubuntu package, which does not install due to an unresolvable dependency. Compiling Gnash from source was more successful, however.
Due to the number and variety of media formats that can be encapsulated
by Flash, the list of dependencies is long, however it can be reduced by
specifying only a subset of the rendering, GUI, and multimedia options.
./configure --enable-renderer=cairo --enable-media=GST --enable-gui=gtk
builds support for just the Cairo rendering engine, GStreamer media handler, and the GTK+ stand-alone player GUI. The default settings add OpenGL, Anti-Grain Geometry
(AGG), FFmpeg, SDL, and KDE4 dependencies.
The plugin for Mozilla-based browsers is built by default, but does not require Firefox development packages. Gnash's make install installs the standalone player; make install-plugins installs the browser plugin, by default placing it in $HOME/.firefox/plugins.
The flexibility in playback engines is one of 0.8.8's main new features, though. If built with FFmpeg and GStreamer media handlers, the choice between them can be made at runtime with the -M switch. Likewise, the -R switch allows runtime selection between Cairo, OpenGL, and AGG rendering (the latter being targeted for framebuffer-only devices).
In addition, Gnash supports switching between two hardware GPU acceleration APIs at runtime, XVideo, and the newer VAAPI. XVideo is not recommended, as the current builds may even reduce speed when compared to software video rendering due to video scaling. VAAPI hardware acceleration includes support for NVIDIA cards using VDPAU, ATI cards using using XvBA, and native support for Intel GPUs.
The project also claims that 100% of the content hosted on YouTube will now play in Gnash. There have been many and varied reasons for YouTube breakage in the past (not the least of which is that the SWF player served up by YouTube changes regularly), but passing 100% of the tests is a milestone indeed. The Gnash developers suggest that everyone experiencing problems with YouTube and Gnash 0.8.8 clear out their YouTube cookies and try again before filing a bug report.
Finally, Savoye has been working on ARM support in recent releases, and Gnash 0.8.8 supports Android devices. This support is likely to be slower than Adobe's official Flash player, however, because for the time being it uses software rendering — but the availability of a free Flash player for mobile devices is an important step.
Interoperability and the future
A question that popped up several times during the last development
cycle was whether there was a chance that Gnash might join forces with Lightspark, another free
Flash player replacement that works as a browser plugin. Lightspark
focuses on supporting the current version of ActionScript, version 3.0,
which was introduced with Flash 9. Gnash focuses on supporting older
versions of ActionScript, which run on the AVM1 virtual machine from Flash
8 and before. Lightspark implements AVM2 for its ActionScript 3.0 support,
and maintainer Alessandro Pignotti has indicated that he cannot feasibly
add support for AVM1 in addition to maintaining AVM2. Complicating matters
is the fact that Flash 9 and Flash 10 files can incorporate AVM1
code if the developer so chooses.
Each plugin could test for the presence of AVM1 or AVM2 code in a given SWF file, though, so it is theoretically possible for Gnash and Lightspark to co-exist and allow users to view both generations of Flash content. Marek Aaron Sapota pointed out on the Gnash mailing list that the Chrome and Chromium browsers allow both plugins to be installed simultaneously, but that Firefox becomes "confused" in the same situation — even if one of the plugins is disabled.
Progress on that front came on August 2, when Pignotti released Lightspark
0.4.2.2. This release of the plugin tests for the virtual machine version
in SWF files, and calls the Gnash program if it uses AVM1 (assuming it detects that Gnash is installed). Consequently, a user could install the Lightspark plugin and Gnash standalone player, not install the Gnash plugin, and play Flash content using both AVM1 and AVM2, seamlessly.
There is a drawback to this approach, because Lightspark has not yet implemented ExternalInterface. So, for the time being, it is a toss-up whether Gnash or Lightspark will offer the best support for any arbitrary SWF file encountered in the browser. Savoye, however, encouraged Pignotti to make use of Gnash's ExternalInterface code, since both projects are released under the GPL.
Of course, the current habit of using YouTube as a test case is of dubious value, particularly in the long term. Not only does video playback test just a small portion of Flash's capabilities when compared to interactive education and game content, but HTML 5 is clearly a better platform for video delivery in the future. Already, YouTube itself allows users to opt-in to an HTML 5 version of the site, as do several other video hosting services.
Even if HTML 5 becomes the preferred web delivery method for audio and video, and HTML 5 with CSS 3 implements rich interactivity that obsoletes most of Flash's other major uses, both Gnash and Lightspark will remain valuable simply because of the millions of Flash files already in existence. In addition, mobile and embedded devices will likely remain a pain point for free software supporters for years to come, as device makers routinely include proprietary components like Adobe's Flash player, and do not make alternatives user-selectable.
It continues to be an interesting year for open source Flash playback. The level of interaction and cooperation between the two main projects is a welcome sign, as is the experimentation being done to bring future releases to previously inaccessible platforms. Case in point: there have been numerous threads in recent months documenting individuals' attempts to get Gnash running on iOS devices like Apple's iPad — which is certainly something the proprietary companies have no intention of pursuing.
Comments (2 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Transport-level encryption with Tcpcrypt; New vulnerabilities in acroread, kernel, kvm, php,...
- Kernel: __GFP_NOFAIL; VFS scalability; User-space access to kernel cryptography; Statistics and tracepoints.
- Distributions: LinuxCon: A tale of two bootcharts; Fedora, Lunar, Nexenta, Debian, Ubuntu, ...
- Development: Vim 7.3; Cython, OpenSSH, Python, RabbitMQ, ...
- Announcements: OpenSolaris Governing Board resigns; Apple patents, Eben Moglen on defending FOSS, ...