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
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
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
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
Comments (105 posted)
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
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.
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
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
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
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
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 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
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.
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)
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.
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>>