The Linux Core Consortium is an effort by Conectiva, Mandrakesoft, Progeny
and Turbolinux to create a single, Linux Standard Base-compliant core
distribution which each distributor can then use as a base for their
products. The idea is to share some of the distribution engineering work
and, simultaneously, to create a widely distributed, standard platform
which independent software vendors can target for their products. See
this LWN article for more information on the
LCC.
Bruce Perens has recently proposed to the
Debian project that it work with the LCC. There are, according to
Bruce, a few reasons why Debian would want to do that:
The first is that we should be influencing this group to do things
the Debian way, where that is important. The second is that the
group plans to lower the overhead of hardware and application
vendor certification for all of its participants, and we could
really use that sort of support. The third is that the group would
make certification by LSB and other standards bodies easier for all
of the participants.
Ian Murdock, the founder of the Debian project, has his own reasons for encouraging Debian to
join:
How does Debian benefit from LCC? It's a route to the ISV and IHV
certifications that Debian has always lacked, and it is the lack of
these certifications that's preventing Debian from standing
alongside Red Hat and Novell/SuSE in the commercial space despite
comparable (and arguably greater) popularly. The industry simply
doesn't know how to engage us, and LCC provides them with a vehicle
for doing that.
Appealing to vendors of proprietary software has never been high on the
Debian Project's list of priorities. Ian claims that vendor support is
important, however, if Linux is to remain an open, free platform in the
increasingly commercial context in which it operates.
Working with the LCC would, essentially, require Debian to help develop,
and then distribute, a set of standard binaries used by all LCC-based
distributions. All of these distributions would use the same (binary)
kernel, the same libraries, and many of the same configuration mechanisms.
The use of identical binaries goes beyond the requirements of the LSB,
which only requires that the same binary interface (ABI) be available. Ian
claims that the LSB approach has proved to
be insufficient:
...while there are numerous LSB-certified distros, there are
exactly zero LSB-certified applications. The reason for this is
that "substantially the same" isn't good enough--ISVs want *exactly
the same*, and there's a good reason for that, as evidenced by the
fact that while Debian is technically (very nearly) LSB compliant,
there are still a lot of edge cases like file system and package
namespace differences that fall outside the LSB that vastly
complicate the "certify to an ABI, then support all distros that
implement the ABI as defined by whether or not it passes a test
kit" model.
As one might imagine, there is some resistance within the Debian Project to
distributing a set of binaries (including the kernel) provided by an
outside organization. It will be a hard sell; from your editor's reading
of the debate, the early signs are that the Debian developers aren't buying
it. Debian users like to have a great deal of control over their systems,
and the LCC looks like a way of giving up some of that control with no
immediate benefits in sight.
Comments (16 posted)
A recent debate between KDE developers raises an interesting question: Does
it help or hurt to port open source applications to closed platforms, such
as Windows? One
side argues that availability of open source applications on Windows diminishes
the chances that users will choose to migrate to Linux or *BSD. The other side argues
that open source on Windows can bridge the gap between Linux and Windows,
thus making it easier for users to (eventually) migrate.
First, there is the question of goals. While Microsoft has a coherent set
of goals, the open source community does not. Some projects are dedicated
to spreading open source as an end unto itself, others just see open source
as the best model for their specific project. If the goal is simply to
foster adoption of a specific application, like Firefox or OpenOffice.org,
then porting that application to Windows is without question the right
strategy. The vast majority of desktop users are on Windows, and it makes
little sense to ask users to switch operating systems to use one
application.
However, if the goal is to spread open source in general, then one has to
wonder whether users are likely to migrate to a new operating system if the best applications for
that system (or most of them, anyway) are also available on the closed system that
they're familiar with. The vast majority of users are motivated by factors
other than licensing.
This is not the first time the debate has been raised, nor is it likely to
be the last. However, this may be a good time to look at the
situation. Linux is acknowledged as a mainstream server operating system,
but still looked at as a fringe desktop operating system. Desktop
applications on Linux are starting to reach parity in ease-of-use and
feature sets with their Windows counterparts, thus making it a viable
platform for Windows users to migrate to, should they so choose. At the
same time, many of those applications are available on Windows, allowing
Windows users to adopt open source applications without migrating away from
Windows. If this is the final result, then most Linux users would see
porting open source applications to Windows as undesirable. As Aaron Seigo
writes:
The more software we port to Windows the more we reinforce this application
availability imbalance and strengthen the user's inertia to stay on
Windows. If users had to make a choice between Windows or Linux (or BSD)
when it came to getting access to better applications they would find they
had a motivation to switch. And switch they would.
There is, however, the possibility that users will be more likely to adopt
Linux or *BSD if they have a positive experience with some of the open
source applications on Windows. Change is scary for many users, and it may
be better to provide a means to gradually adjust to open source platforms
rather than expecting a user to plunge in headlong and learn to swim right
away. It's also worth considering that many Windows users would never be
exposed to open source applications if they are not available on
Windows. It's one thing to hear wonderful things about OpenOffice.org,
Firefox, The Gimp, Apache or KDE, but another thing entirely to actually
use those applications and become comfortable with them.
For organizations, the gradual approach may be the best way to ensure the
adoption of open source. As "pipitas" argues:
Even at the present stage there is a considerable share of IT desicion
makers in enterprises and government bodies who seriously evaluate options
and costs of a switch over. For most, it now looks like "all or nothing,"
and a big jump. A too big one in many cases. So they refrain. So they sign
another 5 year contract with MS...
To chop the task into smaller pieces, to take the direction, but only a few
steps for now, to smooth the transition out over a period of time is very
difficult. And it costs. Not only do you have to train the users. You also
need to re-train the IT teams. So Microsoft is of course playing on the
card of Total Cost of Ownership (TOC), with a liiiiiittle bit of (every
marketeer's) exageration, but with a tiny bit of valid argument too. They
keep winning, albeit often by a small margin. And they even start losing
some rounds, lately.
Both sides make compelling arguments. There are, no doubt, users and
organizations that will adopt a handful of open source applications and
stop there. Other users and organizations will adopt Firefox,
OpenOffice.org and other open source applications and decide to go
further.
In the end, however, it's hard to argue for spreading open source by
restricting users' choice. Most Linux users resent Microsoft for
restricting their choices when using Windows, so it's somewhat hypocritical
to suggest that Windows users should have to make an "all or nothing"
choice to use Linux or *BSD to benefit from open source. While there's a
risk that users will choose to stay on Windows, it's the ability to choose
that led most of us to Linux in the first place.
Comments (27 posted)
The Ubuntu Conference was already in full swing by the time I arrived, late
last Friday. Canonical employs thirty-seven people, located in twelve
countries, and most of them are here in Mataró. For some this is their
first chance to meet and talk to fellow developers face to face. The
entire conference has been a series of workshops, BOFs and hack sessions
all revolving around Ubuntu, LaunchPad and the various components of
LaunchPad. A few visitors have joined in here and there, but only the
sessions
last Saturday were targeted to
visitors. Presentations have mostly been in English, although Saturday's
sessions were translated into Spanish and Catalan for the benefit of the
many Spanish visitors. People drift in and out, but over all attendance
averages around fifty people, and at least double that on Saturday.
The conference is located at the Hotel NH Ciutat de Mataró, also home for
most of the Canonical staff and your LWN editor. A typical day starts out
with a buffet breakfast in the hotel dining room. All Canonical staff meet
in the main conference room at 9:00 AM before breaking into smaller groups
to talk about and hack on the various projects. The hotel provides a pack
lunch so people can munch and continue working. By around 8 or 9 PM it's
time to head for dinner at one of the many restaurants in Mataró. This is
also done in smaller groups as some continue hacking until late and some go
looking for different types of food. Mataró is on the Mediterranean coast
so the weather is mild. Natives wear coats and scarves and hats, but those
of us from more northerly climes find it pleasant with no more light a
jacket even late at night.
Canonical projects underway here at the conference include Ubuntu and the
upcoming Hoary Hedgehog release, the proposed KDE version called Kubuntu
and the application suite LaunchPad, with many a late night hack session
devoted to one of the LaunchPad applications. For more on LaunchPad and
its applications see Ubuntu Conference: The
LaunchPad workshop. Briefly, the applications so far are the
translation tool Rosetta, package manager Soyuz, version control system
Bazaar, and bug tracker Malone.
I chatted with Canonical founder Mark Shuttleworth briefly on Wednesday
over lunch and asked him how Canonical plans to make money. Ubuntu is free, and
LaunchPad will be free to use, but Canonical does aim to make some money in
support. Additionally, he hopes to get some government grants to build
localized distributions. By using the still incomplete LaunchPad suite it
will be easy to create distributions for a wide variety of the world's
subcultures.
For now he keeps costs low by limiting the number of
developers assigned to any particular project and by not having a
centralized office, and enjoys Python hacking with his staff of talented
developers. He also knows what he's willing to spend to make Canonical
self-sustaining and how long that should take (though he did not share
details with your editor). If it doesn't happen he'll
pull the plug and move on. We're hoping that it does work out and
Canonical will manage to survive, not only because Ubuntu is a nice
distribution and quite stable on this laptop, but also because if LaunchPad
can become the suite that Mark envisions, it could be as revolutionary as
Linux itself. For now LaunchPad remains largely vaporware, with the
exception of Rosetta, so it is too soon to tell if it can really live up to
its potential, but with the team that Mark has put together it stands a
good chance.
This is Rebecca Sobol reporting from Mataró Spain.
Comments (none posted)
Here at the Ubuntu Conference in Mataró Spain, Canonical developers are
meeting with each other and with representatives of the Spanish government
and other guests to talk about Ubuntu and LaunchPad, an application suite
currently in development at Canonical. This article focuses mainly on the
workshops that took place on December 11, wherein government representatives
and other guests were treated to a view of some of the LaunchPad
applications.
The workshops began with an introduction by Mark Shuttleworth (right) and
Carlos González, from the Secretaria de Telecomunicacions i Societat de la
Informació de la Generalitat de Catalunya. Attendees included other
government representatives, members of the Hispalinux community, the local
press, and your roving LWN reporter.
Carlos explained that Mataró is located in Catalunya, where Catalan is the
local language and the local Linux distribution is Càtix. Other regions in Spain
have their own language and culture, and each region wants to preserve
that language and culture, and this is reflected in a variety of local
Linux distributions customized into the various local languages.
Alfonso de Cala, of Guadalinex, was the
next speaker, leading a brainstorming session aimed at identifying the
problems and frustrations of Linux developers throughout Spain. He noted
that this diversity of cultures within Spain has led to the creation of
numerous derived Linux distributions, with little or no collaboration
between developers. Not only are distributions localized for the region,
they are also tailored for use by different types of users. This has led to
much wasted effort as developers from around the country each tackle the
same problems and independently maintain a shared code base. The end
result is more fragmentation, when what is needed is more shared code and
collaboration.
During Alfonso's presentation we learned that the second version of
Guadalinex has been released and that thousands of people use Guadalinex in
schools, at home and at work. Guadalinex offers technical and
non-technical support. Also Guadalinex shares many of the same problems
that are faced by developers around Spain and around the world. Here is a
short list of areas, as identified by the audience, in which small
distributions, particularly those derived from larger distributions, are
having problems.
- Bugs: All software projects have bugs. Many end-users don't
know how to send in a bug report or where to send their bug report.
Bug tracking is not synchronized with upstream. Users of a stable
(old) release want bugs fixed, but developers are more interested in
the newest release. If all bugs are reported to one person, that
person gets swamped, so there needs to be a better way of
determining where bugs should go. Developers want bug reports but
they don't need to wade through many reports for the same bug.
- Translations: Translations can be difficult. A user interface
might be translated many times, some translations will be better
than others, but the best translations may never be incorporated upstream.
- Support and Training: In open source software the components
of a distribution come from many sources. Who does the end user go
to for support and training?
- Hardware: Many types of hardware are supported, but a small
distribution doesn't have access to all hardware. Even a stable
Enterprise distribution needs to be able to support new hardware.
- Code Management - Branding and Configuration: Code needs to be
customized without breakage. Changes need to be compatible with
upstream. Users should be able to tweak the configuration in a way
that remains supportable.
- Standardization and Convergence: All distributions need a
standard base, a standard user interface, and standard configuration
tools. The standard needs to allow for desired diversity. It needs
to be easier for people who don't speak English to be involved and
contribute to projects.
- Certification: Companies need to run a distribution that is
certified for those third party applications (like Oracle) that they
need. Localized distributions can not get certified easily.
- Distribution creation tools: Better tools are needed.
- Release schedules: Coordinating distribution release schedules
with the schedules of including applications.
Once the problems were identified it was time to talk about how LaunchPad
might provide at least some of the solutions. The three LaunchPad
applications closest to release are Rosetta, Malone and Soyuz. We should
note here that while LaunchPad tools are designed to be used with open
source software, they will not themselves be released as open source, at
least not initially.
Rosetta: Due for its first release this week, Rosetta may be out by
the time you read this. This translation tool provides an easy-to-use web
interface for translators, making it easy for a non-technical translator to
provide a translation for an application. How does that work? Take any
application included in your distribution. The user interface is typically
presented in English. To localize the application you could go into the
code and change all the strings to the language of choice. Then you'll
have to recompile, deal with any introduced errors, and have a version of
code that is different from upstream. Worse, the process starts over with
each update to the application, even when the application's interface
remains the same.
Now imagine that you have translators from all over world who use Rosetta's
interface to edit a POTemplate (or POT file) for that application. The
application needs only to be aware that POT files exist to present the end
user with an interface in their chosen language. New translations can be
added and existing translations can be improved without any change to the
code. Rosetta keeps track of translations and can export new or improved
translations back to the original application. Rosetta can also show you
your entire distribution to see what has been translated, and what still
needs to be translated.
Right now Rosetta only works with code, changing the face of the
application for the non-English speaking user. Later releases of Rosetta
will be able to handle man pages, DocBook and OpenOffice
documents, and do spell checking. Those interested in using Rosetta may
join the mailing list at rosetta-users@lists.ubuntu.com .
Malone: Another piece of LaunchPad is Malone, an extraordinary bug
tracking tool. Malone is for developers, not for end users to fill with
their bug reports. It will coordinate with other tools such as Bugzilla,
tracking bugs both upstream and between distributions. A developer using
Malone will be able to see if a bug has been fixed, and where it was fixed
so that the fixes can be incorporated into their own distribution. Expect
to hear more about Malone in early 2005.
Leading up to a brief look at Soyuz, a central tool in LaunchPad's
arsenal, Benjamin "Mako" Hill and Ismael Olea led a discussion on
collaboration and convergence. Various barriers to collaboration and
convergence were identified, some political, some practical. The more
distribution developers can work together the better it gets. When
developers can not or will not collaborate then they will duplicate each
other's work, sometimes fragmenting the code as application A in
distribution Z diverges from the same application in distribution X.
A few of the barriers to collaboration and convergence include government
secrecy, lack of communication/language barriers, geography/time zones,
different deadlines and priorities, lack of resources, infrastructure,
branding, unrealistic requirements, different hardware/architectures, and
so on. The idea of LaunchPad is to provide tools that will eliminate as
many barriers as possible, so that all Linux distributions can share more
and developers can spend less time reinventing the wheel. Soyuz is the
package tracker, helping the developer to track the packages in the
distribution, upload and build source, track bugs, keep information about
the packages and their maintainers and provide a wrapper around the version
control system. LaunchPad's version control system is called Bazaar and
it's forked from Arch. But that's a story for another article.
This is Rebecca Sobol reporting from Mataró Spain.
Comments (12 posted)
As has become our tradition, we will not publish the LWN.net Weekly Edition
the week of December 30. We'll return to the usual schedule with the
January 6, 2005 edition. The daily updates will continue to happen
over the holidays.
For various reasons, the 2004 Linux Timeline will be released a little
later than usual. Rest assured that it is in progress, and that it will be
out by the end of the year.
Comments (4 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Analysis of a kernel vulnerability; New vulnerabilities in file, the kernel, ncpfs, PHProjekt, vim...
- Kernel: Debugfs; Boot-time clock frequency selection; ioctl(), the BKL, and 32-bit compatibility.
- Distributions: Gentoo Linux on AMD64, NetBSD 2.0 released, Fedora Core 3 for PowerPC,
the Ubuntu community work page, Slackware 10 review.
- Development: XPP: The X Printing Panel,
lots of database releases, new versions of dump/restore, Firestarter,
TwistedSNMP, Python Computer Graphics Kit, GNOME, GARNOME, XCircuit,
GnuCash, KolourPaint, Evolution, FreeMED, GnomeMeeting,
Bakery, KTTS, AFPL Ghostscript, DrPython.
- Press: 2005 predictions, Microsoft domination at universities,
apt-get primer, Linux MIDI part 3, Popular Mechanics looks at Linux.
- Announcements: PostgreSQL Hot Backups, Professional Support for Firefox and Thunderbird,
free!music CD, CodeCon CFP, FOSDEM2005 CFP, Red Hat Summit,
The LinuxWorld Conference and Expo/Mexico.
- Letters: GNOME backgrounds
Next page:
Security>>