LWN.net Weekly Edition for December 16, 2004

The Linux Core Consortium courts Debian

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:

Ian Murdock, the founder of the Debian project, has his own reasons for encouraging Debian to join:

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:

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)

Porting free software to Windows

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:

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:

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)

Ubuntu Conference: The Mataró Sessions

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)

Ubuntu Conference: The LaunchPad workshop

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)

A couple of LWN notes

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)