LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsImproving Ubuntu's application upload processThere has been a surplus of articles recently on how Linux "lost" the desktop. Fingers have been pointed in all directions, from the Windows monopoly to competing desktop projects to Linus Torvalds's management style. Over in the Ubuntu camp, though, there does not appear to be any sense that the desktop has been lost; they are still working hard to win it. Ubuntu's recently-proposed new application upload process highlights its vision of the desktop and what they think needs to be done to make things happen there.
The problemSerious Linux users tend not to think of availability of software as a problem; distribution repositories typically carry tens of thousands of packages, after all, and any of those packages can be installed with a single command. The problem with distribution repositories, from Ubuntu's point of view, is that they can be stale and inaccessible to application developers. The packages in the repository tend to date from before a given distribution release's freeze date; by the time an actual distribution gets onto a user's machine, the applications found there may be well behind the curve. In some cases, applications may have lost their relevance entirely; as Steve Langasek put it:
Why put an upstream through a process optimized for long-term
integration of the distribution when all they care about is getting
an app out to users that gives them information about this month's
beer festival?
Beyond that, getting a package into a distribution's repository is not something just anybody can do; developers must either become a maintainer for a specific distribution or rely on somebody else to create and add a package for their application. And, in most distributions, there is no place in the repository at all for proprietary applications. Ubuntu's owner Canonical sees these problems as significant shortcomings that are holding back the creation of applications for the Linux desktop; that, in turn, impedes the development and adoption of Linux as a whole. So, a few years back, Canonical set out to remedy these problems through the creation of the Ubuntu Software Centre (USC), a repository by which developers could get applications to their users quickly. The USC is not tied to the distribution release cycle; applications added there become available to users immediately. There is a mechanism for the handling of payments, allowing proprietary applications to be sold to users. A glance through the USC shows a long list of applications (some of which are non-free) and other resources like fonts and electronic books. Guides to nearby beer festivals are, alas, still in short supply. Naturally, Canonical does not want to provide an unsupervised means by which arbitrary software can be installed on its users' systems. Experience shows that it would not take long for malware authors, spammers, and others to make their presence felt. So the process for putting an application into the USC involves a review step. For paid applications, for which Canonical takes a 20% share of the price, there appears to be a fully-funded mechanism that can review and place applications quickly. For free applications, instead, review is done by a voluntary board and that group, it seems, has been having a hard time keeping up with the workload. The result is long delays in getting applications into the USC, discouraged developers, and frustration all around.
Automatic reviewThe new upload process proposal aims to improve the situation for free applications; Canonical does not seem to intend to change the process for paid applications. There are a number of changes intended to make life easier for everybody involved, but the key would appear to be this:
We should not rely on manual reviews of software before
inclusion. Manual reviews have been found to cause a significant
bottleneck in the MyApps queue and they won’t scale effectively as
we grow and open up Ubuntu to thousands of apps.
In other words, they want to make the process as automatic as possible, but not so automatic that Bad Things make it into the USC. The first step requires developers to register with the USC, then request access to upload one or more specific packages. Getting that access will require convincing Canonical that they hold the copyrights to the code or are otherwise authorized to do the upload; it will apparently not be possible for third parties to upload software without explicit permission, even if the software is licensed in a way that would allow that to happen. A review board will look at the uploader's application and approve it if that seems warranted. Once a developer has approval, there are a few more steps involved in putting an application into the USC. The first is to package it appropriately with the Quickly tool and submit it for an upload. That is mostly basic packaging work. Uploads through this mechanism will be done in source form; binaries will, it seems, be built within the USC itself. But, before the application can be made available, it must be accompanied by a security policy. The mechanism is superficially similar to the privilege scheme used by Android, but the USC bases its security on the AppArmor mandatory access control mechanism instead. The creation of a full AppArmor profile can be an involved process; Canonical has tried to make things simpler by automating most of the work. The uploader need only declare the specific access privileges needed by the application. These include access to the X server, access to the network, the ability to print, and use of the camera. Interestingly, access to spelling checkers requires an explicit privilege. All (free) USC applications will run within their own sandbox with limited access to the rest of the system. Only files and directories found in a whitelist will be accessible, for example. Applications will be prevented from listening to (or interfering with) any other application's X server or D-Bus communications. There will be a "helper" mechanism by which applications can request access to non-whitelisted files; the process will, inevitably, involve putting up a dialog and requiring the user to allow the access to proceed. That, naturally, will put some constraints on what these applications can usefully do; it is hard to imagine a new compiler working well in this environment, for example. The payoff is that, with these restrictions in place, it should not be possible for any given application to damage the system or expose information that the user does not want disclosed. And, with all that structure in place, Canonical feels that it is safe to allow applications into the USC without the need for a manual review. That should enable applications to get to users more quickly while taking much of the load off the people who are currently reviewing uploads.
Naming issuesFrom the discussion on the mailing lists, it would seem that the biggest concern has to do with the naming of packages and files. If an application in the USC uses a name (of either a package or a file) that is later used by a package in the Ubuntu or Debian repositories, a conflict will result that is unlikely to make the user happy. Addressing this problem could turn out to be one of the bigger challenges that Ubuntu has to face.Current USC practice requires all files to be installed under /opt; this rule complies with the filesystem hierarchy standard and prevents file conflicts with the rest of the distribution. The problem, according to David Planella (one of the authors of the proposal), is that a lot of things just don't work when installed under /opt:
We are assuming that build systems and libraries are flexible
enough to cater for an alternative installation prefix, and that it
will all just work at runtime. Unfortunately, this has proven not
to be the case. And I think the amount of coordination and work
that'd be required to provide solid /opt support in Ubuntu would be
best put in other parts of the spec, such as its central one:
sandboxing.
In other words, the /opt restriction was seen as making life difficult for developers and Ubuntu lacks the resources and will to fix the problems; the restriction has thus been removed in the proposal. With Ubuntu, Debian, and USC packages all installing files into the same directory hierarchy, an eventual conflict seems certain. There has been talk of forcing each USC package to use its own subdirectory under /usr, a solution that, evidently, is easier than /opt, but nothing has been settled as of this writing. Presumably some solution will be found and something resembling this proposal will eventually be put into place. The result should be a leaner, faster USC that makes it possible to get applications to users quickly. Whether that will lead to the fabled Year of the Linux Desktop remains to be seen. The "app store" model has certainly helped to make other platforms more attractive; if its absence has been one of the big problems for Linux, we should find out fairly soon.
Brief items Distribution quotes of the week
"Gentoo" is actually an old Navaho word meaning "some assembly required,
batteries not included". You thought it was a penguin?
-- Ryan Hill
Nearly two decades have passed since operating systems were judged
primarily by their office suites and solitaire games. Photo
retouching, online note syncing, genealogy, kiosk-style UI for the
elderly, music notation, home accounting, calendaring, paying taxes,
making greeting cards, chess, Web design, screencasting, CAD, school
timetabling, wedding planning, screenwriting. For thousands of "long
tail" genres like those, competing OSes have multiple applications to
choose from -- but the published choices in Ubuntu are either
non-existent or, not to put too fine a point on it, terrible.
-- Matthew Paul Thomas
Now, there are many reasons for that: difficulty of publishing is far from the only one. But it would be a subtle error to think that an application not existing for Ubuntu at all means that difficulty of publishing is unimportant. It may be one of the reasons nobody bothered to develop the application in the first place.
Buildroot 2012.08 releasedBuildroot is a tool for creating complete embedded Linux systems. A legal information reporting infrastructure has been added to version 2012.08, along with other significant changes. "Integration of a legal information reporting infrastructure, which allows to generate detailed informations about the licenses and source code of all components of a system generated by Buildroot. License information will progressively be added on packages. As of this release, 77 packages have gained license information." Other changes include the addition of new hardware support, an external toolchain update, and more.
LFS 7.2 is releasedLinux From Scratch 7.2 has been released. This major release includes toolchain updates to glibc-2.16.0 and gcc-4.7.1. "In total, 28 packages were updated from LFS-7.1 and changes to bootscripts and text have been made throughout the book."
openSUSE 12.2 releasedThe openSUSE 12.2 release is now available. "The latest release of the world’s most powerful and flexible Linux Distribution brings you speed-ups across the board with a faster storage layer in Linux 3.4 and accelerated functions in glibc and Qt, giving a more fluid and responsive desktop. The infrastructure below openSUSE has evolved, bringing in mature new technologies like GRUB2 and Plymouth and the first steps in the direction of a revised and simplified UNIX file system hierarchy. Users will also notice the added polish to existing features bringing an improved user experience all over. The novel Btrfs file system comes with improved error handling and recovery tools, GNOME 3.4, developing rapidly, brings smooth scrolling to all applications and features a reworked System Settings and Contacts manager while XFCE has an enhanced application finder."
Open webOS beta releaseThe Open webOS August edition, otherwise known as the beta release, is now available. "Today’s release provides—not one—but two build environments. Our desktop build provides the ideal development environment for enhancing the webOS user experience with new features and integrating state of the art open source technologies. Developers can now use all their desktop tools on powerful development machines. Our OpenEmbedded build provides the ideal development environment for porting webOS to new and exciting devices."
Qubes 1.0 releasedVersion 1.0 of the Qubes security-oriented desktop distribution has been released. "Generally Qubes OS is an advanced tool for implementing Security by Isolation approach on your desktop, using domains implemented as lightweight Xen VMs. It tries to marry two contradictory goals: how to make the isolation between domains as strong as possible, mainly due to clever architecture that minimizes the amount of trusted code, and how to make this isolation as seamless and easy as possible." LWN looked at Qubes in 2010.
ROSA test releasesROSA has two releases available for testing. ROSA Enterprise Linux Server beta includes the ROSA Directory Server, ROSA Server Setup and OpenStack 2012.1 Essex. An alpha version of ROSA Desktop 2012 is also available.
Distribution News openSUSE Tumbleweed is now empty for 12.2Tumbleweed is a rolling repository for openSUSE. As v12.2 has just been released that repository is now empty. "As part of the Tumbleweed lifecycle, with the 12.2 release of openSUSE, the openSUSE:Tumbleweed repo is now empty so that you can start out with a "clean" 12.2 release. It will stay that way for a few weeks for things to settle down with 12.2, and then will start to add packages back to it (new kernel, KDE 4.9, etc.) as time permits."
Ubuntu family Ubuntu's new app developer upload process proposalThe Ubuntu folks have run into an interesting problem with their application upload process: "Despite our best intentions and the Ubuntu App Review Board's epic efforts, we're currently putting a strain on reviewers (who cannot keep up with the incoming stream of apps) and providing an unsatisfactory experience for app authors (who have to endure long delays to be able to upload their apps)." In response, they have come up with a detailed proposal for a new process; comments are sought. "We should not rely on manual reviews of software before inclusion. Manual reviews have been found to cause a significant bottleneck in the MyApps queue and they won’t scale effectively as we grow and open up Ubuntu to thousands of apps."
Newsletters and articles of interest Distribution newsletters
Garrett: UEFI Secure boot in Fedora: status updateMatthew Garrett has a progress report on implementing secure boot in Fedora. "The infrastructure for signing the bootloader binaries is now implemented. pesign is in the archive and being used to sign shim, grub2 and the kernel. At the moment they're all being signed by test keys, and the private key is actually in the pesign package. This is, obviously, not intended for production use - it's just to ensure that we can build correctly signed images. We've proof-of-concepted signing via cryptographic hardware and will shortly be deploying new build systems dedicated to building the signed binaries. These won't be general access systems and will have a lightly modified mock configuration to ensure that the crypto hardware is available to the build chroots, but otherwise there's nothing special about them."
SystemRescueCd 3.0.0 introduces support for modules (The H)The H looks at new features in SystemRescueCd 3.0.0. "Version 3.0.0 of SystemRescueCd introduces support for modularly extending the system and UEFI booting to the Linux distribution for administering and repairing systems. With SRM modules (System Rescue Modules), additional programs with their dependencies, files and data can each be contained in a single squashfs filesystem with a .srm extension. When the system boots, these .srm files are all mounted automatically. Users can add the reusable .srm files to their SystemRescueCD systems as needed to customise their system."
Page editor: Rebecca Sobol |
|||||||||||||