Phil Wainewright: “The idea, by the way, that users are going to keep their own private backup somewhere else, as Google’s PR rep suggested in an email to TechCrunch, is patently absurd. The whole point of storing email in the cloud, surely, is to avoid having to download hundreds of megabytes to your hard disk every night just in case the service falls over.”
Emre Sokullu is writing about a hypothetical “GoogleOS” again. As a long time OS guy, let me be the first to say that this makes absolutely no sense whatsoever. For one thing, Google already has an “operating system”. It’s the web, and Google dominates the web, so why in the world would they give their main competitor such an obvious advantage by moving into its turf? Furthermore, Google no more needs an operating system in the traditional sense of the word than it needs an office suite in the traditional sense of the word. Releasing yet another Linux distribution isn’t disruptive—redefining what an operating system is is disruptive, and Google’s already doing that. Two predictions for 2007 that I’m fairly sure will hold up: 1. This won’t be the last of the GoogleOS speculation; and 2. there won’t be a GoogleOS.
In part 1, I described the problem of software installation on Linux; in part 2, I’ll describe the solution we came up with at the recent LSB Packaging Summit.
After reading through the comments to part 1, let me first point out that our goal is to create a vibrant third party software ecosystem around Linux—you know, like the one Microsoft has built around Windows. No, it’s not about imitating Microsoft. It’s about being competitive. A platform is only as good as the applications that run on it.
Bottom line: Many third parties have built their businesses around proprietary software, and we can’t just ignore them. And “ecosystem” implies decentralized, which I argued in part 1 was a key tenet of open source development anyway, i.e., this should be playing to one of our core strengths. So, if your “solution” is to tell ISVs (independent software vendors) to give us their source code so the distributions can include it because that’s just how we do things, you can safely skip the rest of the post below. You’re simply not going to agree that any of this is a problem.
Ok. Assuming our goal is to create a vibrant third party software ecosystem (and everyone still reading agrees that’s a good goal, right?), we have the following challenges.
First of all, the distribution vendors are hugely invested in their existing package systems, and for the most part, those package systems work extremely well. As I said in part 1, “if [an application] is in your distro of choice, you’re only an apt-get or a yum install away from running it.” (I’m saying it again here because some of the commenters apparently didn’t see that. The tricky bit is “in your distro of choice”, which by definition is not the case with third party software.)
Furthermore, a variety of highly sophisticated systems management solutions are built above those package systems, such as Red Hat Network and Novell ZENworks. This is a pretty important consideration, because these days, the “software management problem” largely involves managing software across the entire infrastructure, not just a single system.
What problem then? This: ISVs have thus far been reluctant to use the native package systems. Why? THEY’RE hugely invested in “package systems” for other platforms, and every Linux specific thing they have to support costs money. In a world where decisions are ruled by cost vs. benefit, this is a pretty important consideration too.
How do ISVs handle this today? For the most part, they ignore the package systems on Linux and do their own thing. Trouble is, while doing their own thing gives ISVs the flexibility to work cross platform, it ultimately makes their products integrate poorly in the broader systems management context because the package systems know nothing about them.
What is needed is a way to bridge the gap between what the distros provide and what the ISVs want. But how?
First off, we have to understand what ISVs want. The answer is simple: ISVs want to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows. So, if one commenter is right that “[t]he problem is that people (including software distributors) believe there’s such [a] thing as ‘Linux’ as a target platform” and that “[i]f you’re distributing software for ‘Linux’ then it won’t be simple to install it, ever”, well, then Linux is destined to suffer the fate of UNIX. I’m not ready to give up so easily.
Several commenters suggested that what we need is a brand new package system. That’s a non-starter—for one thing, the distros aren’t going to be too keen on replacing something they’re hugely invested in, and if ISVs aren’t going for RPM today, why would they go for something different tomorrow?
No, to find a way forward, we need an evolutionary step from where we are today. From there, perhaps we can do more, but even the first steps can be quite valuable in their own right.
To help find those first steps, we put some of the leading minds in Linux packaging in the same room (including the maintainers of RPM at Red Hat and Novell and the authors/maintainers of APT, yum, alien, and klik) along with ISVs large and small, server and desktop.
The discussion pretty quickly converged on constructing a single API that could be implemented across the various package systems, because APIs make for nice evolutionary steps and can, done right, mask underlying implementation differences.
Question is, what do ISVs need in such an API? Limiting the scope is key here, because providing an API that spans all the functionality of, say, RPM and dpkg is overwhelming to the point of being unworkable, not to mention more work to implement, which in turn makes it less likely to get into the distros so that ISVs can count on it being there, the whole point of this exercise in the first place.
Fortunately, the ISVs don’t really need much. At the most basic level, an installer just needs to be able to query the system to see if it’s LSB compliant, and if it is, what version of the LSB it’s compliant with; and it needs to be able to “register” with the package system, so the package system knows about it, including what files it has installed. And that’s really about it.
Importantly, because we assume an environment that’s LSB compliant, we don’t have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support—components can extend the LSB, and applications can depend on those other components being installed—but we’re talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with.
We only had a day, so we obviously don’t have a complete solution yet. For one thing, we barely touched on the issue of uninstallation (should we allow applications to register GUI uninstallers?), and the issue of how applications go about changing the system configuration still needs discussion (in a lot of cases, the assumption of LSB compliance means the installer is going to be well behaved, but there’s undoubtedly corner cases to be explored). And it’s going to take time for the API to be implemented and put into widespread enough use that ISVs can depend on it.
However, everyone in the room did come to consensus pretty quickly that this was an important problem, and that providing a simple API that provides the minimum necessary functionality was the way to go. Perhaps most exciting, the very people whose support are needed to put the API into widespread use were in that room, and active participants in the discussion too.
Everyone is certainly motivated: The distros get more applications, which makes the shared platform more attractive; and ISVs get lower cost, which tilts the cost vs. benefit equation in their favor, making Linux versions more economically attractive and potentially opening new markets.
Because this is just a start, the FSG is launching a Packaging workgroup to continue the discussion we started at the Packaging Summit. If you’re interested in this topic, I’d encourage you to join the mailing list and get involved. There’s still plenty to be done.
Update: One more thing: In addition to making it easier for ISVs to better support Linux by simply extending their existing installation scripts, the API approach really comes into its own when you imagine it implemented in things like Autopackage and InstallAnywhere. Let the market decide!
Aaron Leventhal of IBM has more details on the relationship between iAccessible2 and the UNIX/Linux accessibility API (ATK/AT-SPI) as well as the motivations behind iAccessible2’s evolutionary approach:
[A]n evolutionary path was needed for applications which already had MSAA (IAccessible) support… [and] an API was needed that did not require separate accessibility implementations for each platform.
[…]
The IAccessible2 interface itself collects important ATK features from other areas, as well some completely new methods and features… For the most part, features were added either to bring Windows capabilities up to the level of ATK/AT-SPI, or in order to support the features of ARIA (previously known of DHTML accessibility).
[…]
[W]hat we’re doing is expanding MSAA while matching ATK/AT-SPI to a very helpful degree. […] [B]ecause IAccessible2 is backwards-compatible with MSAA, the current support of Windows screen readers and other assistive technologies can continue to work on applications that add IAccessible2 support. However, the newer IAccessible2 capabilities will also be exposed, and thus newer assistive technologies will be able to take advantage of them.
Peter Korn of Sun weighs in as well.
(Via Andy Updegrove.)
As anyone who follows my blog knows, I’m fond of linking to other sites with brief little quotes that either get me thinking or reinforce points I’m trying to make elsewhere. (Credit where credit is due: Dave Winer and Doc Searls both do this very effectively, and I’m just shamelessly copying them, down to the quoting style they typically use.)
One of the quotes I’ve had queued up for a long time is this one from Jon Udell:
I have a confession to make. Sometimes, when I’m trying out an unfamiliar open source component, I cheat. Even if the software I’m working on will deploy to Linux, I’ll sometimes develop it on Windows first. Why? Because on Windows, an open source component is likely to come with an installer that just works.
He’s right. Unless an application is included with your Linux distribution of choice, installing that application on Linux is a nightmare compared to Windows.
Here’s an example. To install Sun’s Java Studio Creator on Windows, I just click on the .exe on Sun’s web site, which downloads the file and places it on my desktop. I double click the .exe (after, of course, checking it for viruses) and am up and running in a few minutes.
In contrast, on Linux, I click on the .bin, which downloads the file and.. up pops a text editor showing me a /bin/sh script.
Nice. Fortunately, I know what that is, so I save the script to a file on my desktop. I double click the file, and.. up pops a dialog box telling me the file isn’t executable.
Nice. Fortunately, I know what that means, so I drop into a shell and run chmod +x ./creator-2_1-linux-ml.bin. I double click the file again, and there’s a nice graphical installer now.
Finally, it looks like everything is going my way. Halfway through, though, the installation fails, telling me I need to install the RPMs for compat-libstdc++ and compat-libstdc++-dev.
Nice. Assuming I even know what an “RPM” is, I then realize: I’m running Debian, and Debian doesn’t use RPM. Maybe I know about alien, but even if I do, where do I go about getting the compat-libstdc++ and compat-libstdc++-dev RPMs?
At this point, I’ll probably hit Google—that is, if I haven’t already thrown up my hands in disgust and gone back to Windows. After a bit of Googling, I find this page, which tells me on Debian what I really need is libstdc++2.10-glibc2.2 and libstdc++2.10-dev. Of course! I should have known that. (Note: I’m being sarcastic.)
After installing those two packages, I restart the installer (which, thankfully, knows how to deal with the fact that it’s already half installed, but that won’t always be true). The installation finishes this time, and the installer kindly offers to start the program for me. However, after poking around a bit and exiting back to the desktop, I don’t see a menu entry or a desktop icon, so I’m not sure how I’m going to find it again (and I hope I don’t have to explain why cd’ing to ~/sun/Creator2_1/bin is not an answer).
Anyone who has ever installed software on Linux is familiar with this song and dance. If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms. (And, no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture.)
Oh, well. At least I didn’t have to check for viruses!
Fortunately, some of the problems I experienced are bugs. The above was done on a pre-release Debian etch system over the summer, so it’s likely the problems have been fixed. I repeated the experiment on an Ubuntu edgy system, and it didn’t open the text editor, nor did it complain about an incompatible C++ environment. However, there were still no menu entries or desktop icons, and there was an additional problem too in that when I double clicked the file, it opened it in CrossOver Office, which I also have installed. Regardless, even if it works better on some distros than others, there’s still no usable solution until ISVs and end users alike can depend on things consistently working regardless of the distro being used.
Again, fortunately, we have solutions to parts of the problem already. The LSB abstracts away the differences between the runtime environments of the various distros, so the Java Studio Creator installer could have simply said “you must install the LSB environment” rather than trying to deal with the hundreds of little variations in both the environments and the package namespaces that provide them (e.g., compat-libstdc++ vs. libstdc++2.10-glibc2.2). Better yet, on distros that provide the LSB environment in their default configuration, the installer doesn’t have to do anything. And Project Portland promises to give us a consistent interface for creating menu entries, desktop icons and such things.
However, far too few applications take advantage of the LSB today (though that’s changing), and Project Portland isn’t in any of the distros yet (though we’re looking at bundling its primary deliverable, xdg-utils, with the LSB 3.2 SDK to work around that). Finally, even though the LSB provides ISVs with a consistent way to create an LSB compliant executable, there’s no consistent way to deliver an LSB compliant application that’s easy to install and that integrates well with the distribution’s package system. Yes, the LSB includes RPM today, but for a variety of reasons, ISVs don’t want to use RPM, and as already mentioned, not all distributions support RPM natively.
Fortunately, once again, this isn’t just a rant. The LSB tackled these very issues at the LSB face to face and Packaging Summit last week in Berlin, Germany, and we think we have a way forward that’s acceptable to all involved: Linux distribution vendors who already have well established package systems and systems management tools built around them; ISVs who need to support multiple platforms and so don’t want to support the Linux specific RPM format or who otherwise want more control over the installation experience; and end users who want to use the software management facilities their distributions provide, whether that’s RPM or something higher level like APT and yum. More in part 2…
Max Spevack: “The Fedora Project is leading the creation of a new community around RPM. One in which the leaders can come from Fedora, from Red Hat, from Novell, from Mandriva, or from anywhere.”
Elizabeth Montalbano and Andy Updegrove write about IBM’s donation of iAccessible2 to the Free Standards Group, which is being formally announced today (see the IBM and FSG press releases). In addition to IBM, the project is backed by Sun, Oracle, SAP and other major vendors.
This is a big deal in and of itself, of course, because it will make applications based on ODF, AJAX, and other emerging open standards more accessible to visually impaired users. But it’s also an important milestone for the FSG, so I thought I should say a few words about that here from my own little pulpit.
The first clue is that iAccessible2 is an accessibility API for Windows. Windows? Yes, the FSG is primarily a Linux organization (our main project is, of course, the Linux Standard Base), so why on earth are we now involved in building APIs for Windows?
First of all, we’ll be moving this project forward as an extension to our existing accessibility projects—which, given the way the FSG is structured, flow into the LSB as they are adopted by the Linux distributions (who, as I’ve already mentioned here, are active participants in the LSB project, so we’re not just hoping the distros adopt our work, we’re proactively trying to drive consensus on these key issues). So, this definitely impacts our Linux work by bringing accessibility features to Linux that not only equal those of Windows but exceed them (iAccessible2 itself came about because Microsoft Active Accessibility has notable shortcomings).
But it’s more than that. Another way to look at this is that the LSB APIs will be taking on a distinctly more cross platform flavor, particularly in the “around the edges” cases such as this. Again, that begs the question: Why is cross platform support important for a Linux organization? That one’s simple. APIs are for application developers. Application developers target multiple platforms. The less Linux specific work an application developer has to do to support Linux, the more cost effective a Linux version will be, the more likely it is to get done. It’s all about more Linux apps.
There’s another dimension to it as well. There are a certain class of features that the vast majority of developers don’t think much about because that vast majority doesn’t need them. There’s no itch to scratch, as it were. Accessibility is a great example of such a feature: I have no idea what it’s like to be blind, nor do most people. If we can provide a set of open, cross platform APIs that allow application developers to easily add such features to their products, more standards based products will support them.
As Massachusetts and ODF brings into sharp focus, these “around the edges” cases developers don’t think much about can turn out to be very important indeed.
InfoWorld: “Initially, Liquid VM will work only with VMware’s ESX Server hypervisor, but BEA plans to support other hypervisors in future including those from XenSource and Microsoft.”
Now this is interesting: BEA is coming out with a version of its application server that runs directly atop VMware.
With this move, VMware takes another step toward becoming a full fledged operating system in its own right. VMware is already promoting the distribution of applications as virtual machine images, and operating systems are first and foremost application platforms. If VMware is an application platform, why not cut out the middle man entirely, particularly given that the middle man adds a few hundred megabytes of largely invisible baggage to the application, not to mention an enormous amount of maintenance burden for the ISVs that make or break an application platform?
For me, the real question is: Why BEA and not VMware? A JavaOS makes a lot of sense, since it builds on one of the world’s largest developer communities—it’s a well known environment among developers, and there are a huge stable of applications that could take advantage of the new platform with minimal porting. Furthermore, applications are increasingly server based, with the browser providing the UI, so this matches well with industry trends and nicely addresses the problem that VMware would have a very hard time building any sort of graphical user interface into its platform, just given the nature of what it is.
That said, VMware should really want to provide the JavaOS directly. With Xen and Virtual Server moving aggressively to bundle their products with widely deployed operating systems, the game’s already afoot, and if virtualization becomes just another operating system feature, VMware is at a distinct disadvantage, as it owns no operating system to bundle its product with. Finally, what about standards? New kind of operating system or operating system feature, there are going to be multiple application platforms if history is any indication (and it usually is), so how do applications take advantage of the new platforms without the inevitable fragmentation?
It’s going to be an interesting space to watch, that’s for sure.
It’s now possible to dynamically link web data into Google spreadsheets. For example, stock information can be pulled in via the simple formula GoogleFinance(ticker, attribute), where attribute can be any number of metrics from market capitalization to P/E ratio. Not much to choose from yet—at this point, there’s only GoogleFinance and GoogleLookup, which seems more novelty than useful, and I’d love to see more than just the obvious metrics available for GoogleFinance, things like cash per share, revenue growth over the past m years, number of insider purchases over the past n months, etc. However, it’s a great start, and it’s pretty easy to see where they’re going with this—after all, most spreadsheets are inherently linked to external data sources, though I’d wager a majority of them are “linked” via copy and paste. I look forward to the day when you can pull in all manner of structured information into a spreadsheet via similar formulas.
To me, this is the real value of “Office 2.0″. To compete, the office challengers have to go beyond just copying Microsoft Office on the web—success will come from exploiting the new platform, not cloning the old model. Pretty easy to see something like this grow into a platform all its own too. With a few more financial metrics, a slightly more powerful macro language, and the ability to connect to more arbitrary data sources (say, Google Base or the CSV files my bank makes available to me), I could track my finances on the web in a Google spreadsheet and give Quicken the boot (for what I want to do, Quicken is like driving a nail with a sledgehammer).
