LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for August 26, 2010Systemd and Fedora 14Systemd, 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 context of 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 default in 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.serviceand 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 concerns:
[...] 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 fix." 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 systemd. 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 right:
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 bugs, 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.
Android: the return of the Unix wars?Your editor was recently amused to encounter this ZDNet article 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 themselves. 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 former. 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 speed. 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.
Gnash releases version 0.8.8The 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 experience. Gnash developmentThe 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
with 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 Foundation's high 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. For example:
./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. What's newThe 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. A major new functionality feature for the Gnash browser plugin in this release is support for ExternalInterface in Flash movies. Also referred to as "Scriptable Plugin" support, this is a gateway that allows JavaScript in an HTML page to interact with ActionScript (Adobe's Flash scripting language) inside an SWF file, including methods, variables, and movie controls. 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 futureA 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.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||