Don’t count GNOME out just yet. Sure, GNOME faces stiff competition from the K Desktop Environment. With a two-year start on GNOME, KDE is better developed. KDE offers more applications, and the KDE office suite is slated for release this spring or summer. All the major distributions—Red Hat is the sole exception—install the KDE desktop by default. With KDE so far out in front, is there any hope for GNOME? A Linux Journal editorial actually called on GNOME developers to abandon the project so that the community can rally around KDE.
If Helix Code’s GNOME distribution proves anything, it’s this: GNOME might be the Johnny-come-lately in the desktop environment sweepstakes, but GNOME has the technology edge. Boston-based startup Helix Code, Inc., co-founded by GNOME originator Miguel de Icaza, is a for-profit company devoted to improving GNOME without abandoning the free software ideal. All of Helix Code’s releases will fall under the GNU Project’s General Public License (GPL), and the company hopes to make money by providing service, customized software, and support. At the time of this writing, you can download a pre-release version of Helix Code’s improved version of GNOME.
I’ve taken a close look at the pre-release version, and here’s my take: It’s stable, fast, and very impressive. What’s more, it confirms something I’ve thought for some time: KDE’s in the lead, but it’s running with fairly conventional technology. GNOME’s revving up with an architecture that is so innovative, so brilliant, and so flat-out amazing that, once you understand what it’s all about, you’ll know why GNOME is a winner. In reality, it’s KDE that’s running behind, not GNOME. You’ll understand why when you’ve finished reading this article.
In this Daily Feature, I’ll explain what’s under GNOME’s hood. Even if you’re not a developer, you’ll understand why the brainiest and brightest Linux developers prefer GNOME’s system architecture—and that includes the folks at Eazel, a new Linux startup founded by some of the most brilliant people from the original Macintosh team (including Michael Broich, Andy Hertzfeld, and Bud Tribble). Eazel’s first project, code-named Nautilus, is an easy-to-use file manager for Linux. Eazel developers looked under GNOME’s hood, loved what they saw, and chose the GNOME environment. They’re working closely with the GNOME project—so closely, in fact, that GNOME 2.0 will include Nautilus.
What did they see that they liked so much? As they say, read on, read on.
It’s about leverage
As you know, it’s tough to lift something heavy. With a lever, though, you can lift an object that’s many times heavier than your weight.
The same applies to GNOME’s system architecture. In GNOME, the lever is GNOME’s underlying component-based architecture, called Bonobo. In brief, Bonobo consists of a growing number of application components, called objects, that perform specialized tasks, such as displaying vector graphics onscreen, downloading e-mail, searching databases, or enabling Web access.
Here’s where the leverage comes in. With Bonobo components, application developers can put together an application in short order. By combining the database, vector graphics, and Internet components, for example, you could create an interface for a geographical information system. This means, very simply, that application developers don’t have to reinvent the wheel every time they create new applications.
But the ease of development isn’t the only cool thing about Bonobo’s componentized architecture. Bonobo also makes it much easier to maintain applications and make sure they’re functioning smoothly. Let’s say there are 10 GNOME applications that use Bonobo’s vector graphics component. Sure, each of these applications has its own home page and development team. But they all draw from the single Bonobo component that’s separately maintained by the component’s authors.
GNOME’s flagship application, Gnumeric, points the way to the future of GNOME’s applications. Gnumeric will rely on Bonobo components to provide onscreen equation typesetting, embedded charts and graphics, database searching capabilities, and much more. (As a user, you don’t have to worry about whether a certain feature is a component or not; you just choose what you want from a menu.) When you’re creating a document with Gnumeric, you’re not creating a Gnumeric-only document; you’re creating a compound document, in which various portions of the document are created and maintained by imported components. Another way of putting this is that, when you create a Gnumeric spreadsheet, Gnumeric becomes the container for the components you happen to use. Conversely, Gnumeric can be contained by other applications, to the extent that they need spreadsheeting functions.
Software reusability, component-based architectures, and compound documents—that’s the state of the art in application development, and everyone knows it. Until now, though, the only environment that’s offered anything close to the state of the art is Microsoft Windows. With Visual BASIC, Windows developers can throw applications together in short order. But this convenience comes with a price: You’re chaining yourself to a proprietary architecture (Windows) and to the programming languages this architecture supports (such as Visual Basic). Until now, there hasn’t been anything close to an alternative.
Fasten your seat belt, because you’re about to understand why developers like the folks at Eazel get excited about GNOME. Thanks to Bonobo, GNOME stands the best chance of providing a genuine alternative to the Windows development environment—an alternative that doesn’t lock developers into the use of proprietary operating systems, proprietary programming languages, and all-Windows environments. To understand why, take a closer look at the way Bonobo components communicate.
The CORBA advantage
If you’re familiar with Microsoft Windows, you’ll recognize that Bonobo has something in common with Microsoft’s Object Linking and Embedding (OLE) architecture, now dubbed ActiveX. Both Bonobo and ActiveX are component-based architectures that enable application developers to reuse software components. On another level, though, there’s an enormous difference between the two. ActiveX doesn’t give you the freedom to choose a programming language—but Bonobo does.
Here’s why Bonobo gives programmers the freedom to work in the language they prefer. Unlike ActiveX, which relies on a proprietary communications protocol, Bonobo uses CORBA to handle the communications that go on when one application requests services from another. In brief, CORBA (short for Common Object Request Broker Architecture) is a nonproprietary standard that enables applications to request services from each other. The applications don’t have to be written in a certain language—and what’s more, thanks to the fact that CORBA is network-friendly and platform-independent, they don’t have to be running on the same computer or even the same type of computer.
CORBA’s a great idea, but it’s not very useful unless it’s supported by an integrated system environment. And that’s exactly what GNOME provides, thanks to ORBit, an elegant, fast implementation of CORBA for Linux-based systems. Here’s an example. When an application needs a component, a problem arises: Where the heck is the component? With ORBit, that’s no longer a problem. ORBit takes care of finding the object, assuring the appropriate level of security, dealing with file storage issues, and much more.
So what’s the big deal?
Let me sum this up in plain, simple language:
- Software engineers agree that reusable components and component-based architectures are the way to go. It’s too expensive and difficult to develop large-scale applications if you have to reinvent the wheel for every last feature. That’s especially true in the open source community.
- Components need a system architecture that enables them to communicate. To date, only Microsoft Windows has offered a complete, viable environment for component-based development—which is one of the reasons why there are hundreds of thousands of Visual BASIC programmers out there.
- GNOME offers all the benefits of Windows application development—reusable components, object linking and embedding, and compound documents. But it doesn’t lock you into a specific programming language, a specific hardware environment, or even a specific operating system.
Can you spell F – R – E – E – D – O – M?
What’s coming
If you look at Helix Code’s game plan, you’ll see that these guys are going for the jugular. Right now, the Helix folks are working on Evolution, a Bonobo-based, network-friendly calendar/scheduling/e-mail system that’s going to give Microsoft Outlook a run for its money, and GNOME BASIC, a visual programming environment that will enable Visual BASIC programmers to step into GNOME—and Linux—with minimal transition costs. Down the road is a GNOME word processor that will be able to read and write proprietary programs’ files without so much as a hiccup.
Put it all together, and you can see what’s coming. Thanks to GNOME, Bonobo, and ORBit, you get a state-of-the-art architecture that doesn’t lock you into using a specific vendor’s products. You get a beautiful new interface and powerful file manager that makes the Macintosh look difficult, thanks to Eazel. From the Helix Code folks, you get a powerful e-mail and scheduling utility, a Visual Basic killer, and a suite of incredible office applications. It all runs on Linux, and it’s all released under the GPL—which means, in effect, that it’s free.
Helix Code co-founder Miguel de Icaza doesn’t spend time badmouthing Microsoft. After all, Icaza says, Microsoft may have a monopoly on the desktop right now, but only 4 percent of the world’s population has anything like computer access. It’s the other 96 percent that Helix Code’s shooting for.
Getting GNOME’s ducks in a row
What’s been missing from the GNOME project, admittedly, is the grunt-level debugging needed to get GNOME working smoothly, port the environment to the leading distributions, and ease installation hassles. Helix Code has spent much of its early effort focusing on precisely these issues.
Judging from the Helix Code preview release, the project has already racked up an impressive series of achievements. Helix has done all that mind-numbing debugging that somebody ought to have done—and the result is the first GNOME distribution that doesn’t leave core dumps all over your system.
In addition, Helix has created versions of this smooth-running distribution for a whole series of distributions, including Mandrake 6.1/7.0, SuSE 6.3, Caldera OpenLinux 2.3, and Linux PPC 2000. The final release will support five additional platforms. Most impressive of all, though, is the GNOME installer, a utility that’s so easy to use it puts the Macintosh installer to shame. From the Helix Code site, you can download an installer that will transparently and automatically install all the GNOME software, without your having to do anything more complicated than go get lunch. (Make it a lengthy one if you’re planning to download all 112 megabytes!)
Is GNOME the future?
In this Daily Feature, I’ve made a case for GNOME’s technical advantages, and I’m not the only person who finds them very exciting. But what about KDE? In version 1.1, KDE isn’t much more than a pretty face for underlying text mode utilities; of course, much the same could be said of most GNOME applications. KDE 2 will offer more support for components. Unless I’m misreading the KDE technical documents, though, I don’t see anything like GNOME’s coherent, systemwide implementation of reusable components. I don’t doubt that KDE will move in that direction, but this proves my point: Technologically, GNOME’s got the lead. And with Eazel’s help, they’ve got some formidable brainpower and business experience on their side.
Of course, superior technology doesn’t mean you’ll win in the marketplace. What remains to be seen is whether Helix Code and Eazel can deliver on the killer applications that Linux so desperately needs. If KDE beats them to it, KDE could very well carry the day. From what I’ve seen from Helix Code, I’m ready to put my money on GNOME. These guys can deliver. Try it yourself, and see what you think.
Bryan Pfaffenberger, a UNIX user since 1985, is a University of Virginia professor, an author, and a passionate advocate of Linux and open source software. A Linux Journal columnist, his recent Linux-related books include Linux Clearly Explained (Morgan-Kaufmann) and Mastering Gnome (Sybex; in press). His hobbies include messing around with his home LAN and sailing the southern Chesapeake Bay. He lives in Charlottesville, VA. If you’d like to contact Bryan, send him an e-mail.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.