There 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
highlights its vision of the desktop and what they
think needs to be done to make things happen there.
Serious 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
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
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.
The 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
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
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.
From 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:
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.
Comments (77 posted)
"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.
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.
-- Matthew Paul Thomas
Comments (10 posted)
Buildroot 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.
Full Story (comments: none)
Linux 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.
Full Story (comments: none)
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.
Comments (16 posted)
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
Comments (5 posted)
Version 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
Comments (12 posted)
ROSA has two releases available for testing. ROSA Enterprise Linux Server beta
ROSA Directory Server, ROSA Server Setup and OpenStack 2012.1 Essex. An
alpha version of ROSA Desktop 2012
Comments (none posted)
Tumbleweed 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.
Full Story (comments: none)
The 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.
Full Story (comments: 22)
Newsletters and articles of interest
Comments (none posted)
Matthew Garrett has a progress report
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.
Comments (25 posted)
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.
Comments (none posted)
Page editor: Rebecca Sobol
Next page: Development>>