Leading items

Between Fedora 12 and 13

In many minds, the Fedora 12 release is likely to remain forever associated with the project's ill-advised decision to allow any local user to install packages without the root password. That mistake is now in the past and, in any case, there is far more to Fedora 12 than this particular problem. In this article, your editor looks at the quality of the Fedora 12 release and ponders what Fedora 13 may bring.

The Fedora brand has suffered a bit in recent times; the Fedora 10 and Fedora 11 releases have not proved to be the most stable distributions ever. Some users have begun to lament the passing of the days of Red Hat Linux, when quality control seemingly had a higher priority. Said users may well have never lived through the RHL 4.0 and 5.0 transitions, which were not the most rock-solid systems on the planet. Today's Fedora releases are far larger than Red Hat Linux ever was, and they are more stable than many RHL releases were. We have made progress over time.

Still, recent Fedora releases have had some users wondering if it might not be time to move on to some other distribution. For some of those users, Fedora 12 might be the release which forces the decision one way or another. With this thought in the back of his mind, your editor proceeded to upgrade two systems (one from Fedora 10, the other from 11) to the current release.

As an aside, it should be said that the Fedora "preupgrade" feature is a nice addition. It's still not quite a Debian-style online upgrade, but preupgrade does the work of collecting all the needed package files while the system is operating normally, only requiring that the system be taken down for the actual upgrade operation. No need to burn DVDs. It makes the whole process easier, at least when it works; some users are still reporting problems with preupgrade. It worked flawlessly for your editor, in any case.

Fedora 12, once installed, made an immediate impression: a great many little irritations have gone away. Printing works - every time. The laptop suspends and resumes much more quickly, and it has lost its "you have to resume me twice before I'll stay resumed" behavior. NetworkManager no longer comes up with "network disabled" and it responds far more quickly to network changes. The GNOME desktop even remembered most of its pre-upgrade settings - an unexpected bonus. And so on. From your editor's point of view, the Fedora developers have used the F12 development cycle to fix a big pile of problems, and they would appear to have been kind enough to avoid adding a pile of new problems to replace the old ones. In summary: Fedora 12 is the solid release that this project really needed to create. Compared to that, the new features in F12 (and there are many) are of secondary importance.

While your editor has seen similar comments from others, it's worth noting that not all users are 100% pleased. If people are having trouble with F12, chances are it has to do with graphic adapters. One user went so far as to suggest the cancellation of Fedora 13 so that the developers could work on fixing F12 graphics problems. That seems unlikely to happen, but there is an awareness within the development community that the graphics experience is still not quite what it should be.

Dave Airlie explained the priorities used by the development team when addressing problems. Issues which prevent the system from booting normally are at the top of the list, as are those which keep a normal desktop from working. Unfortunately for certain classes of users, the lowest-priority items are non-GNOME desktops and arbitrary 3D applications. So the above-mentioned user, who was running into trouble getting Blender to work, may have to wait a while for a complete fix. There are also known issues with the Nouveau driver. Users having difficulties with proprietary graphics drivers are, of course, entirely on their own.

In the end, Linux graphics is still a work in progress. There have been a lot of advances in this area, but the job will not be done for a little while yet.

So what comes next? Fedora 13 is tentatively scheduled for release on May 11, 2010. The proposed feature list for this release is just beginning to come together, and some possible features (such as Btrfs-based rollbacks) do not yet appear there. Unsurprisingly, improvements to the Nouveau and Radeon graphics drivers are on the list. Better online telephony support is a possibility for F13 as well.

Another important feature which is likely to appear in Fedora 13 is the Python 3 language. The current plan is to package Python 3 in a way that allows it to be installed alongside Python 2.6 without interference between the two - an important point, since a number of crucial Fedora scripts are written in Python 2. It looks like the only place where non-interference is hard to implement is when attempting to run both within the same address space. That may seem like a strange thing to do - and it is, until you try to run both mod_python and mod_python3 within a web server. Most users are unlikely to notice or install the python3 package with Fedora 13, but it will provide a base for the gradual migration of programs written in Python.

Fedora 13 users can also look forward to RPM 4.8.0, with a long list of new features. The RPM developers are looking for especially brave and well-backed-up testers to help find any remaining problems before inflicting it upon the more cowardly folks who merely run Rawhide.

Finally, the Fedora developers would like F13 to be a higher-quality release than F12, even though F12 is looking good. To that end, they have started a quality assurance retrospective page, reviewing how the QA process went for F12 and how it can be improved the next time around.

There has been speculation that Fedora 12 will be the release picked by Red Hat to serve as the base for Red Hat Enterprise Linux 6. Despite its remaining problems, F12 should serve well in that role; it is one of the best of the recent Fedora offerings. The challenge for the project now, of course, is to carry that success forward into subsequent releases while simultaneously incorporating all of the new software that the development community is so busily producing. Whether 13 will prove to be a lucky number for Fedora remains to be seen, but F12 seems like a good starting point and the project seems determined to do even better the next time around.

Comments (105 posted)

UDS from an embedded hacker's perspective

The Ubuntu Developers Summit (UDS), held November 16-20 in Dallas, while kicking off the development cycle for the next Ubuntu release, "Lucid Lynx", had a surprising amount to interest a kernel hacker with embedded tendencies. The Summit covered a wide range of topics from low level kernel details, to best community practices, but the ARM netbook support sessions were particularly interesting. At this UDS, the Ubuntu ARM developers set out to enable support for many ARM machines in a single distribution, a difficult task due to the lack of a standard firmware interface on ARM systems; a familiar problem to embedded developers. This report covers the solutions debated at UDS — including Kexec bootloaders and the flattened device tree — and the choices made for the next Ubuntu release.

Ubuntu has supported the ARM architecture since the 2008 Intrepid Ibex (8.10) release, but the relative lack of consumer hardware has effectively made it interesting only to developers. During the Lucid cycle we can expect that to change as Canonical is working with ARM netbook OEMs to provide full support for the new devices that are widely anticipated to appear on the market in the new year.

However, support for a wide range of ARM devices is complicated by the absence of any form of a firmware interface standard for ARM systems. The vast majority of ARM designs are embedded systems with no expectation that the end user will install their own software. General purpose ARM computers are historical rarities; the notable exceptions being the original Archimedes, and the Corel Netwinder. As such, unlike the x86 architecture where an IBM PC-type BIOS is mostly a given, device manufactures can (and do!) implement whatever firmware interface best meets their needs. Every device has a different method for booting the OS. Additionally, since firmware provides little if any information about the hardware, the kernel must be hard coded with device addresses and configuration information.

The current situation requires a different method for each system to boot an installer and multiple kernel images, each hard coded for a specific machine. For a device vendor who only maintains software loads for a handful of devices this situation is not particularly onerous. For general purpose distributions like Ubuntu it is problematic. The maintenance load of both installer and kernel images for every single hardware platform from every single vendor is completely unmanageable. As such, a number of the sessions in the mobile track at UDS this year were devoted to solving the ARM boot problem.

Bootloaders and Firmware

Getting firmware to behave was the theme behind two sessions on Tuesday. The first covered Oliver Grawert's script for creating a bootable image for a Freescale Babbage i.MX51 board with RedBoot firmware. From a purely pragmatic viewpoint, the script is absolutely necessary to create a usable install image but it certainly is not portable. Every board requires a different script for convincing the firmware to boot from the right place. So while it is a current necessity, it is not a viable solution in the long term.

The ARM Soft Bootloader session led by Michael Casadevall on Tuesday afternoon proposed a more complete solution. Rather than depend on the capabilities of firmware executed by the device at power up, he suggested using a second stage boot loader that is built around the kernel and uses Kexec to boot the real OS image in the manner of Petitboot for the PS3. The idea is that the kernel can be used to sidestep firmware differences and provide a consistent boot interface to the installer. It also eliminates the current need to write device drivers twice; once for the kernel, and a second time for the firmware.

For most developers the firmware is not actually interesting, it is just a necessary hoop to jump through to boot an operating system. By adopting the kernel as the boot loader, it eliminates all the (arguably wasted) effort spent developing drivers for firmware, freeing up time for other development. However, there are concerns about the soft bootloader approach. The most significant of these is how much time booting a second kernel will add to the boot process.

Discussion in the Soft Bootloader session was interesting, and is well summarized in the blueprint. It is worth a read for anyone doing firmware work. At the end of the session it was decided that Soft Bootloader is the preferred approach but it still requires some investigation and engineering. Most likely it will not be ready for the Lucid release but is a Lucid+1 candidate.

Flattened Device Tree

Several sessions discussed the problem of hard coded machine information in the kernel which requires the kernel to be modified for each new device. I was asked to lead two sessions on the Flattened Device Tree (FDT). The first was an overview of the FDT approach — how it is implemented in PowerPC and how it can be used to solve several of Ubuntu's ARM problems. The Flattened Device Tree has been discussed elsewhere with more eloquence, but in brief it is a data structure that is passed to the kernel at boot time which describes the hardware. Instead of relying on hard coded platform device tables, the kernel reads the data structure to determine what devices to register and how they are configured.

While no firm decisions were made in the first session, it was generally agreed that device trees solve the problem at hand and should be pursued. Proof of concept work is proceeding which should demonstrate the device tree on an ARM platform in mid-January.

The overview sparked the scheduling of a second Flattened Device Tree session quite unrelated to ARM platforms. Fixing Hardware Quirks in Device Trees discussed the idea of using the same FDT data structure to capture machine specific quirks that are currently hard coded in the kernel. For example, ALSA codec routing information is wildly different from board to board but changing it (for instance when trying to uncover why sound does not work on a user's brand new machine) requires a kernel recompile. If a binding could be written for the device tree that encodes the codec configuration, then it may be possible to fix non-working audio by dropping a new device tree blob into sysfs somewhere instead of asking the user to replace the kernel. Research is needed to decide if this is a viable approach, but it seems promising. Jeremy Kerr has volunteered to investigate it further during the Lucid cycle.

Other Topics

Other interesting discussions for ARM and kernel developers included Colin Watson's Cross Building Ubuntu session, the decision to drop ARMv6 support to take advantage of the performance gains in ARMv7, and the decision to use the 2.6.32 kernel version with Ext4 remaining as the default filesystem (the exception being the ARM kernels which will be allowed to lag if the vendor supplied trees are not yet at the 2.6.32 baseline).

On the other end of the spectrum, the work going into the Quickly application framework was presented during Monday's plenary session. It is intriguing and appears to be a promising approach to simplify Linux application development.

Summit Organization

Sessions at UDS were limited to small groups and the focus was on discussion and making decisions about the next release. Only a handful of 15 minute time slots per day were devoted to formal presentations during the plenary sessions in the ballroom. Participation was open; and to provide for those who were unable to attend, audio from all the meeting rooms was Icecast to the Internet. One of the two projectors in each room was dedicated to showing an IRC channel, allowing anyone in the world to listen in and participate. The IRC channel worked well for those offsite, but also had advantages for those who were onsite. It was often used as a "back channel" for making comments without interrupting the conversation at hand.

With 12 sessions going at any one time, far more was happening at UDS than any one person could track. This report gives a taste from the embedded Linux perspective, and is not intended to be a complete review. Anyone interested in knowing more about what was discussed at UDS is strongly encouraged to browse through the posted schedule for notes on most sessions' discussion and decisions. In addition video that was taken at the conference has been posted for public access.

Comments (10 posted)

New releases from Tomboy and Gnote

The GNOME note-taking utilities Tomboy and Gnote both made releases recently. Tomboy, the older project, released version 1.0.1 and includes some long-awaited online storage features. Gnote, a port of Tomboy to C++ instead of the original C#/Mono, released version 0.6.3, a bugfix release in its own right, but one that put an end to rumors that the project was without a maintainer.

Tomboy meets Ubuntu One

Tomboy has supported online note synchronization via WebDAV and other back-ends for several releases. An announcement in May of 2009 attracted considerable attention to a new option, "Tomboy Online," a Tomboy-specific network service that would allow users to access their notes through a web interface in addition to the desktop clients, and share notes with other users. The software powering Tomboy Online, Snowy, is AGPL-licensed, and built on top of Django. As of December, however, Tomboy Online still has not debuted, and activity slowed down on the Snowy Git repository.

Consequently, it was seen as welcome news by Tomboy fans when the 1.0.1 release added support for a new online service that permits web-based note editing, Canonical's Ubuntu One. Ubuntu One accounts provide 2GB of storage to Ubuntu users, supplying Tomboy with a large base of potential testers. More importantly, Ubuntu One's implementation of online Tomboy synchronization and editing uses the same REST-based API designed for use with Tomboy Online and implemented in Snowy. Ubuntu One's Tomboy service does use OAuth 1.0 Revision A for authentication, while Snowy uses OAuth 1.0, but the newer revision plugs a security hole in the OAuth token approval process, so the likelihood of an update is high.

Synchronizing with Ubuntu One is indeed simpler than setting up and using WebDAV. Setup requires only entering the Ubuntu One URL into Tomboy's Synchronization preferences tab; clicking "Connect to Server" then hands off authentication to the browser-based OAuth process. Even more interesting is the possibility of setting up a private Snowy server; the Snowy web page links to instructions for installing the software on the popular Dreamhost web hosting provider, and instructions for configuring Apache with mod_python or mod_wsgi.

Sandy Armstrong's blog announcement also highlighted a new Note Statistics plugin that provides the user with access to line counts, word counts, and character counts, and updates to the Android and Maemo ports of the Tomboy client. The Android application Tomdroid can sync with Ubuntu One's note service in the latest Bazaar branch, and the Maemo application Conboy has work underway but has not yet made a release. Both mobile clients should be able to sync with any server that implements the Tomboy Online REST API.

The latest development release of Tomboy, dubbed 1.1.0, was released at the same time as the stable 1.0.1. For both the stable and development releases, users can download tarballs for generic Linux systems and binary installers for Windows and Mac OS X. OpenSUSE users can install both releases through the package management system, and Ubuntu users can install both via stable and development personal package archives (PPAs).

Gnote meets Fedora

Gnote is a port of the Tomboy desktop application that uses C++ instead of C# and plain GTK+ instead of the Mono stack. The project was started in April of 2009 by Hubert Figuiere as a spare-time effort, but gained a significant following. As always seem to be the case when Mono is involved, the project's existence ignited long standing debates about Mono itself, and when Figuiere decided in late October that he could not continue as maintainer, detractors of Gnote declared it a "victory." The Fedora distribution decided to include Gnote as its default note-taking application starting with Fedora 12, though, and Fedora packager Debarshi Ray stepped up to take over as Gnote maintainer.

Gnote 0.6.3 is Ray's first release as maintainer, and he said he plans to continue tracking Tomboy's feature set. The next major release should add support for synchronization and the Directory Watcher add-in, which will bring the younger application closer to supporting the same online services just announced for Tomboy itself. Gnote has always strived to remain compatible with Tomboy, using the same file format, and it can import users' existing Tomboy notes — although the Gnote team makes it clear that there are no warranties as to whether Tomboy can read notes created with Gnote. Support for Tomboy plugins is spottier, but many are reported to work.

Gnote builds are not provided for Windows or Mac OS X. Linux users on many non-Fedora distributions can find packages through their package management system, including Mandriva, Debian and Ubuntu. Moblin users have expressed interest in Gnote, since the distribution does not include a note-taking application and Gnote would not require building Mono and introducing its corresponding runtime dependency, however Moblin-specific packages are not yet available. Plain Moblin is based on Fedora and Canonical's Ubuntu Moblin Remix is based on Ubuntu; both can run Gnote packages rebuilt from their desktop distributions' respective source packages.

Fedora's decision to include Gnote as its default note-taking application still has its critics, who cite the small development community. It is important to note, though, that Gnote is a direct translation from Tomboy's C# code to C++, not a rewrite, and thus requires considerably less coding effort than either Tomdroid or Conboy.

Gnote's new maintainership and new release is unlikely to change any minds about the project; some will continue to see it as a viable alternative and others as an attack on its parent application Tomboy. What is clear, though, is that neither application is going away soon. Tomboy is poised to finally deliver on the online storage and editing service users have been waiting for, and even if the first service to go live was not the one originally planned, it is probably better in the long run to have multiple, compatible services. The same could be said for Tomboy and Gnote itself.

Comments (2 posted)

Page editor: Jonathan Corbet
Next page: Security>>