Ian Murdock’s Weblog

Last week, the Free Standards Group launched the LSB Developer Network, a community resource for developers building portable Linux applications via the LSB (read the press release and the introduction from LDN editor Martin Streicher).

The LSB Developer Network (or LDN for short) aims to provide a well known starting point for developers looking to target the variety of Linux distributions available today without requiring a separate version for each distribution. It is the perfect complement to the LSB, which already provides a “highest common denominator” across the major distributions; and LSB Certification, which allows ISVs to indicate that their products will work with LSB Certified distributions.

The big themes of LDN are “decentralized” and “bottom up”—to paraphrase Darrin Thompson, it’s a developer network that’s actually a network. In other words, we’re not taking the usual path of hiring a bunch of people to construct a centralized “network” from the top down—after all, Linux is a fundamentally decentralized phenomenon so shouldn’t a developer network for Linux be decentralized as well?

Like the LSB, we see LDN as essential to the ultimate success of the Linux platform, an answer to similar programs for the centralized, proprietary platforms Linux competes with but built using the very techniques that make Linux what it is. Our fundamental belief is that “decentralized” doesn’t have to mean “fragmented”, and LSB and LDN are both key steps toward that end goal.

We’re off to a good start too: LDN has the backing of a broad range of Linux platform stakeholders ranging from distribution vendors (Novell, Red Hat, Ubuntu) to OEMs (HP, IBM) and ISVs (MySQL, RealNetworks) to tools and content providers (O’Reilly, SlickEdit). One upcoming feature I’m particularly excited about is the integration of Safari Books Online. Soon, you’ll be able to type, for example, a function name into the LDN search box and get not just results from the link directory but also results from O’Reilly titles and others you know and love.

We’re moving rapidly to add community content as well, including man pages and canonical reference documentation; and we’ll be hooking LDN into the LSB database, so you’ll be able to query the status of interfaces too, including whether or not those interfaces are in the LSB and what their status is in each of the major Linux distributions, to help make your applications as portable as possible.

If you’re a Linux developer, and particularly if you use del.icio.us to bookmark resources on the web related to software development on Linux, I urge you to contribute to the LSB Developer Network. It’s easy: Simply create an account and link your account to your del.icio.us account (you don’t need to provide your del.icio.us password, just your username), and as you bookmark, tag, and annotate pages, your bookmarks, tags, and annotations will be pulled into the LDN directory. Help us build a developer network for Linux, bottom-up style!

Jeff Waugh: “I raised concerns about overselling Portland during the first [OSDL Desktop Architects] meeting, as it could harm long-term credibility with ISVs. Such unclear language has resulted in serious miscommunication, and was not rectified in the 1.0.” (Via Stephen O’Grady.)

I agree completely and have raised similar concerns—Portland helps solve an important problem, but it’s being dangerously oversold, and it’s certainly not a complete solution for ISVs by itself. The LSB has been around for a long time, and we’re just now reaching the breadth of features and distribution support that we’re comfortable positioning it as a practical solution for ISVs. Even now, we’re being extremely careful not to oversell (i.e., we consider our ISV certification program to be in the pilot phase). We (the Linux community) are only going to get one chance at this, namely the opportunity to present Linux as a unified ISV platform rather than a fragmented mess, and we can’t afford to blow our one chance with premature proclamations that the problem is finally solved.

Mike Melanson: “What could possibly be so difficult about porting the Flash Player to Linux? I’m glad you asked…”

It’s been a while since I’ve written about the LSB here, so I figured I was overdue to give an update. In short, it’s been a great year. Highlights include:

» All major distributions, including Asianux, Debian, Mandriva, Red Hat, SUSE, and Ubuntu, are either already certified to LSB 3, in the process of certifying, or planning to certify their next version (see our list of expected distribution coverage for LSB 3).

» A number of ISVs (independent software vendors), including MySQL and RealNetworks, are in the process of certifying applications to LSB 3. For ISVs, LSB certification means fewer distribution specific packages without sacrificing distribution coverage (take a look at the MySQL download page for an example of how crazy it can get). For users, LSB certification means greater application availability with a minimum of hoops to jump through. Expect a lot more announcements about LSB certified applications in the coming months.

» We’ve put together a solid roadmap for the LSB going forward. The LSB aims to provide a “highest common denominator” across the various Linux distributions—in other words, to provide a single target for ISVs writing or porting to the Linux platform, where “the Linux platform” is defined by a short (and potentially different from ISV to ISV) list of distributions on which their applications must run.

To serve as an effective highest common denominator, it needs to be easy to map from LSB versions to distributions and vice versa; and it needs to be possible to target a version of the LSB with assurance that the application will work not only on that version but on future versions as well (i.e., an LSB 3.0 application will run on LSB 3.0, 3.1, 3.2, 4.0, … compliant distributions). We’ve made great strides toward these goals in the past few months.

To satisfy the “easy mapping” requirement, each major version of the LSB now corresponds to a major version, or “generation”, of the enterprise distributions. So, for example, LSB 3.x corresponds to the current generation (Red Hat Enterprise Linux 5, SUSE Linux Enterprise 10, etc.), LSB 4.x corresponds to the next generation (RHEL 6, SLE 11, etc.), etc. To satisfy the application compatibility requirement, LSB versions both major and minor beginning with 3.0 are strictly backward compatible with previous versions.

At a high level, then, the LSB roadmap looks something like this:

» Speaking of the LSB roadmap, we’re hard at work on LSB 3.2, to be released Q2 2007. The short list of new features include the addition of Perl, Python, several freedesktop.org specifications for desktop interoperability, CUPS, HPIJS, ALSA, and more. For LSB 4.0, we’ll be uplifting LSB Core to GCC 4.1 and glibc 2.4 and looking at two longstanding issues, the addition of Java and a packaging facility for ISVs, among many other things. The roadmap will be posted for public comment shortly.

» We’re making it easier than ever to build portable applications using the LSB. We released the LSB SDK (Software Development Kit), which bundles everything a developer needs to write or port to the LSB, with LSB 3.1. We’re building something called the LSB Application Testkit, which aims to be the LSB’s validator.w3.org, an easy to use tool that developers can use to test for application portability. And we quietly launched a beta version of the LSB Developer Network last month.

» In July, we hired Till Kamppeter, making linuxprinting.org, the de facto standard repository of Linux printer drivers, an FSG project. We’re adding both distribution neutral printer drivers (delivered, naturally, as LSB packages) to the linuxprinting.org foomatic database as well as an API that third party printer management tools can use to install and update printer drivers. We also plan to extend the LSB certification program to cover printers in addition to distributions and applications. If all goes well, you’ll be able to look for the LSB Certified mark on a printer at the store and know that it will work on your distribution of choice in the not too distant future.

» Last, but certainly not least, we’re embarking on an exciting new project in partnership with the Institute for Systems Programming at the Russian Academy of Sciences to build the next generation LSB database and test suite infrastructure. The new system will interlink the various moving parts that make up the Linux platform to an unprecedented degree, providing upstream developers and distribution vendors a powerful set of tools for coordinating their work and improving the quality of the platform, as well as giving ISVs a more efficient way to provide feedback to both parties. This is a key tool for enabling the backward compatibility guarantee mentioned earlier, and it will also vastly improve the coverage and quality of the LSB tests, an area where we’ve been criticized in the past (our goal is 75% interface coverage by LSB 4.0). More details here.

I’ll drill down on all of these topics and more in the coming months. In the meantime, you can keep up with the latest at the FSG and LSB by visiting the FSG web site or by signing up for the FSG newsletter (sorry, no RSS feed yet, though I’m told we’re working on it). Finally, if you’re interested in participating in the LSB project, join the lsb-discuss mailing list or the IRC channel #lsb on irc.freestandards.org, where the bulk of LSB development happens.

Mike Melanson: “I would say the hardest part is selecting APIs that have broad coverage across distributions.”

I often quote Marc Andreessen’s 1995 comment that Netscape would reduce Windows to a “poorly debugged set of device drivers” when talking about Linux on the desktop—namely, that with applications increasingly moving to the web, it matters less whether Windows is on your desktop, because all you need to run your apps is a browser. The assumption here is if you no longer need Windows to run your apps, you’d run Linux, either because of the freedom of choice it gives you, or simply because it doesn’t cost $200 (take your pick there).

Of course, there’s a flip side to this: if the operating system is just a set of device drivers, wouldn’t you want the most extensive set? As far as Linux on the desktop has come in the past few years, it still lags Windows significantly in plug-and-play value. For example, during my recent trip to Moscow, my Windows-running colleagues hopped onto wireless networks with impunity, both at the hotel and even sitting in taxis in the infamous Moscow traffic. While they were clicking on nice little balloons saying “wireless network detected”, I was learning more than I ever wanted to know about iwconfig, cursing all the while. And it’s not just wifi. My laptop only successfully suspends about the half the time. For whatever reason, the 3D acceleration on my laptop doesn’t work with the latest eye candy. And so on..

Me, I actually prefer the Linux desktop over Windows. But now, with all the improvements in virtualization over the past few years, I can still use the Linux desktop as my primary UI and have access to the most extensive set of device drivers. For the cheapskates among us, cost really isn’t an issue either—VMware Player and VMware Server are now available for free, and who doesn’t have at least five Windows licenses sitting around that they aren’t using? Besides, who wouldn’t pay a measly $200 to get Linux perfectly working with their laptop hardware?

Food for thought. Let the flames begin..

Tim O’Reilly: “[I]t’s clear to me at least that the open source activist community needs to come to grips with the change in the way a great deal of software is deployed today. And that, after all, was my message: not that open source licenses are unnecessary, but that because their conditions are all triggered by the act of software distribution, they fail to apply to many of the most important types of software today, namely Web 2.0 applications and other forms of software as a service.”

LWN links to Aaron Seigo’s writeup of last week’s LSB Summit. John Palmieri was there too and has posted his notes here and here. My own writeup will be posted here shortly. In the meantime, the LSB Summit wiki page is here.

Technorati Tags: linux, lsb, standards

Stephen O’Grady: “[I]nnovation is reflective of the developer, not the development model.”

ZDNet Asia: “Unified standards in next-generation Linux-Java mobile applications will need to be established, as the cellular and IP (Internet Protocol) worlds collide in the future, says a senior executive from Motorola.”