Ian Murdock’s Weblog

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

Robert Love: “In Google’s calculation, the cost of a native port outweighed the benefit of a native [port] vís-a-vís a WINE-fueled Picasa. Is that really unexpected? Our development platform is no shining star. We have two toolkits, poor binary compatibility, and unclear direction. To be sure, vendors such as Novell are devoting increasing effort toward improving the Linux ISV and platform story. But the community must make it a priority as well, from the kernel up through the highest levels of the graphical desktop.”

That’s part of it (and certainly an accurate assessment of the kind of thinking we need as a community to make Linux a better platform). I think there’s another part of it, though, and that’s that operating systems in general are fundamentally uninteresting to Google as platforms in themselves, as well they should be—after all, the web is Google’s platform, and they dominate there, so why should they promote an alternative where they are much weaker?

In my view, the (fat) client bits merely exist to ease the transition from the current, predominantly desktop centric world to a new web centric world where Google naturally thrives. After all, such paradigm shifts are always gradual. There’s the offline question too—if all your data is in the cloud, how do you get to it when you’re not online?—though I suspect over time the browser will provide offline capabilities of some sort, so this is largely a temporary problem too.

So, using Wine in ports not only minimizes the incremental cost of building out a foothold on the client (which, again, is a necessity for Google, given that Google’s biggest competitor is between them and 90% of their customers), but it raises the fat client platform up a level too. In other words, it builds a fat client platform with a consistent look and feel across desktop environments; and with this, the operating system underneath rapidly becomes irrelevant.

The real question is when Google will hook Picasa into a photo sharing service of its own. I already keep my photos in the cloud, and I’d love to organize and edit them in Picasa (Organizr is nice, but nowhere near as nice as a desktop application, and it doesn’t have some basic functionality, like import from camera and red eye repair). Of course, this is just one example of Google having some platform thinking issues of its own, though that’ll have to be a rant for another day.

Picasa is now available for Linux. This is huge news, if you ask me, if only for what it could portend. Imagine Google Pack for Linux, with Firefox and a bundled Google Toolbar, Google Desktop, Google Talk, Google Earth, etc. By taking this approach, Google could build a client metaplatform across Windows and Linux without getting into the OS business directly. Nice answer to the fact that Google’s biggest competitor is between them and 90% of their customers today, all without the headache of being an OS vendor—simply ride atop what’s already out there.

Related news: Google Reaches Agreement to Have Its Software Installed on New Dell Computers.

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.”

Sun is worried about compatibility in a world where Java is open source. I can’t say I blame them, and I say this as someone who spends a majority of his time thinking about compatibility in the Linux world, where we’ve managed to hold it together but still have a lot of work to do to match the relative consistency of the Microsoft alternatives (Windows and .NET, among others). After all, a platform is useless if there’s not a single, standard way for developers to target it.

Question is: Does open source inherently lead to compatibility problems? Hardly. How many incompatible versions of, say, Apache are there? Or the Ps of the LAMP stack (Perl, PHP, Python)? Or MySQL? GNOME? KDE? BIND? CUPS? The only reason “Linux” and compatibility often come up in the same breath is because the term is used to describe so many different things. Yes, “Linux” has compatibility issues if you’re comparing Red Hat, SUSE, and Debian, but the actual “Linux” used by each of these “Linuxes” (that is, the Linux kernel) have few if any compatibility issues. It’s more the bits around the edges, like slightly different versions of core components with slightly different ABIs or APIs, not to mention the independently developed subsystems for configuration etc., that lead to the compatibility issues. If anything, the fact that the various Linux distributions share so many of the same open source components makes them far more compatible than the various implementations of UNIX ever were.

James Gosling, the father of Java, highlights JavaScript as an example of the situation they’re trying to avoid in a recent podcast with Dan Farber. Today, he explains, there are dozens of AJAX toolkits, and the main reason for this is the need to paper over incompatibilities between the various JavaScript implementations.

He’s absolutely right. If anything, though, the JavaScript situation is a good example of what might have been if we knew as much about the power of open source in setting standards in the 1990s as we know today. There are numerous JavaScript implementations today because there wasn’t a de facto standard implementation developers could just use when they needed one way back when (like there was with Apache etc. and wasn’t with some of the problematic “Linux” technologies like configuration management). What if there had been an open source JavaScript all along that became a de facto standard like Apache did? Would the AJAX world look any different today?

Ironically, then, Java looks a whole lot more fragmented on its current trajectory as the various open source efforts (Apache Harmony, GCJ, GNU Classpath, etc.)—which exist only because the de facto standard implementation isn’t open source—mature and are more tightly integrated into the Linux distributions.

So, what lessons does Linux have to offer Sun as it contemplates the future of Java and, more to the point, how to open source it? First of all, far from being a surefire path to turning Java into a veritable tower of babel, open source could actually help promote compatibility in the Java world. For one thing, if Sun’s Java implementation was open source, history shows there would be no need for another implementation. Case in point: Remember the other Harmony project?

Secondly, what’s in a name? Absolutely everything. It’s entirely possible to open source Java without diluting the Java brand and the compatibility guarantees that brand promises. Most famously, this strategy has worked very well for Red Hat—Red Hat’s platform is open source, so you can fork it, but you can’t call the result “Red Hat”, which preserves the compatibility guarantee a successful platform requires.

It’s not too late, but we’re rapidly approaching a time when it will be. For one thing, the open source implementations are getting better, and once the genie is out of the bottle, it’s damned near impossible to get it back in (see, again, JavaScript). As I said the other day, “open source Java” isn’t so much about licensing as it is about ubiquity, though licensing can get in the way of ubiquity. We’re almost there. Let’s take the final step we need to take to make Linux/Java as well integrated as Windows/.NET.

Jonathan Schwartz: “The question is not whether we will open-source Java, the question is how.”

Simon Phipps: “Yes, you can now apt-get install sun-java5-jre and have it install without fuss on Debian and Ubuntu.”

Great news. We’re one step closer to a Java/Linux combo that’s more than just Java bolted onto the side of Linux (admittedly, there’s still a bit of that here, though at least it’s attached with standard componentry now rather than the old bubble gum and bailing wire).

Why is tighter integration important? Because the alternative, namely Windows and .NET, offers a tightly integrated combo that “just works”. The more a developer has to do (like, say, ship a bundled runtime because that runtime isn’t guaranteed to be available on a key platform), the more attractive the alternative looks.

The real question is: Will this be enough? I’ve long contended that open-source Java is a red herring—the real challenge for Java on Linux is ubiquity, not licensing, and licensing is really only an issue because it gets in the way of ubiquity. Time will tell if this step represents the boost Java needs to become to Linux what .NET is to Windows.

I don’t know though. For that to happen, the major Linux distributions have to not just add Java to the menu of available software, they have to add Java to the default configuration (much as Perl and Python are default components today), and I just don’t see Red Hat, Debian, or Ubuntu doing that till Java is open source. Still, I’m optimistic we’ll get there. Question is, will we get there in time?

P.S. - How about making some of the Java platform components available via APT too? If I’m developing an application that uses, say, JavaMail, I have to go to the web, download it, figure out that it depends on the JavaBeans Activation Framework (JAF), download that, set up my classpath appropriately depending on where I downloaded them, etc. It would be great if I could just apt-get install javamail and have exactly the environment I need without additional effort.

Andreas Barth: “We expect to release Etch as planned in the beginning of December 2006.”

Excellent, excellent news. I cannot overemphasize how important it is that Debian release Etch on time. Between this, Ubuntu’s commitment to LSB certify Dapper (a huge step toward enabling ISVs to target Debian and Ubuntu with a single certification), and recent industry events, this is shaping up to be Debian’s breakout year. Significant delays or even uncertainty in the Etch schedule, though, changes that pretty substantially.

Gordon Haff: “Sometimes the folks over at Groklaw just need to take a deep breath and pop open a cold one. You’d have thought Linspire was making fur coats out of little kittens or something.”

I’ve been rather quiet lately, but that’s because I’ve been busy helping put the finishing touches on LSB 3.1, which was released early last week. New in LSB 3.1 are the integration of the ISO standard LSB Core (ISO/IEC 23360) and the addition of the LSB Desktop platform above the core (which stops at the desktop toolkits in 3.1, i.e., GTK and Qt, but that will move up the stack to encompass more of GNOME and KDE in 3.2 and 4.0). LSB 3.1 also lays a solid foundation on which to build LSB 3.2 and 4.0. Key milestones here include alignment of the LSB roadmap with the roadmaps of the major Linux distros and more direct participation of the key stakeholders in the standard (distro vendors, ISVs, and upstream project maintainers). Much, much more to come on these points as soon as I’m fully recharged.

In the meantime, I’m pleased to report we had a very successful launch last week. The release was supported by a who’s who of the Linux industry: Dell, HP, IBM, Linspire, Novell, RealNetworks, Red Flag, Red Hat, Ubuntu, and others. Importantly, no fewer than ten major Linux distributions have committed to LSB 3.1 certification, including upcoming versions of Asianux, Linspire, Mandriva, Red Hat Enterprise Linux, SUSE Linux Enterprise Server and Enterprise Desktop, Sun Wah Linux, Turbolinux, Ubuntu, and Xandros. In short, if you’re an application developer, and you want to easily target all of the major Linux distributions, LSB 3.1 is a great way to do it.

More details here: BusinessWeek (and dozens of others via the Associated Press, including ABC News, the Boston Herald, Forbes, FOX News, MSNBC, the San Francisco Chronicle, and the San Jose Mercury News), eWEEK, InformationWeek, InfoWorld (and others via the IDG News Service), Slashdot (twice, here and here), and many other places.