Making the Case for BeOS on Internet Appliances

Scot Hacker, 4/20/00

Why Not Linux?

In the past, I've used this space to try and explain why BeOS is a superior choice to Linux for the average end-user seeking a way out of the Windows quagmire. I've even set up the Alt.OS Usability Challenge, encouraging journalists to sit Windows and MacOS users down at BeOS and Linux workstations, and report objectively on the ways in which BeOS kicks Linux booty in terms of ease of use, ease of configuration, ease of installation, and the general usability of productivity and media applications. I've received some probing questions from journalists, but no one to date has taken me up on the offer.

This month, I'm going to frame the question from another perspective -- that of the potential Internet appliance vendor about to choose an OS for an upcoming, category-defining device.

Imagine for a moment that you're a hardware vendor with a big idea for an Internet Appliance, and you're trying to decide whether to build it on top of BeOS or Linux. At first blush, it might seem that Linux makes the better choice. After all, Linux is free, right? And with all of those developers out there programming away in their spare time, your product benefits by riding on all those free development cycles. Right?

It's not that simple.

When Free Isn't Free

Certainly, you get the Linux kernel and the architecture for free, not to mention piles of software. But appliances have very different needs from desktop computers and servers. You don't create an Internet Appliance by slapping a generic Linux distribution on a small machine and putting an "Order Pizza" key on the keyboard. Consider these criteria, which any potential appliance vendor must have at or near the top of their game plan:

• Low cost. This usually translates into "Low footprint," which may mean dealing with realities like the absence of a hard drive. Everything must be packed into 16 or 32MBs of flash memory. You've got to chop 90% or more of the "meat" from the standard distribution. Bare bones. In fact, you may have to slim down the OS so far that critical dependencies with other system components are broken, necessitating deeper changes to the architecture.

• High performance. Users have expectations of appliance performance, which stem from decades of using radios, televisions, etc. Waiting is not supposed to be part of the game, and appliances need to distinguish themselves from PCs in this key area. Instant-on and robust performance -- even under load -- will be a big issue for appliance vendors. This becomes especially important for broadband-connected appliances, where multiple streams of simultaneous audio and video will be the norm rather than the exception.

• Custom look and feel. Appliance vendors want to deliver a product that looks like their own creation from top to bottom, not a warmed-over version of a familiar desktop environment. From the desktop to the look and feel of the application windows and widgets, every piece must be easily customizable (emphasis on "easily"). The vendor wants their look and feel in every nook and cranny of the user experience, not that of the OS manufacturer.

While Linux may work well in an "out of the box" configuration, things get messy fast when you try to deeply customize the UI (and I'm not just talking about running a different window manager), or run your system in a tiny memory/storage footprint, or create a user experience based entirely on a custom brand identity. Suddenly you're looking at months of development time, training engineers to create a highly customized Linux distro, dealing with support issues, and so on.

"But wait!" you say. "Doesn't low cost also mean low cost-per-unit? Even if development time, cost, and headaches for a Linux-based device are more expensive than they would be with a BeIA-based device, you can earn that back in volume, since it will be possible to install your customized Linux distribution on appliances for free."

Maybe. In actual practice, you may end up having to pay per-unit royalties for certain technologies included on the device. For example, if want to be able to play back MP3 streams, you'll owe a licensing fee to Fraunhofer and Thomson (Be has already taken care of this for you). Depending on your agreement with the team who creates your customized distribution, you may owe them royalties as well. And of course you'll have support issues to work out. Meanwhile, BeIA in bulk is being priced competitively. Be knows what they're up against with Linux, and is making sure they can compete.

Of course, some will point to the single-floppy Linuxes, noting that slimmed down versions of Linux already exist. For one thing, those distributions are woefully anemic. A consumer appliance needs a full (and fast) GUI, and all of the web goodies customers will expect. In addition to a responsive GUI, BeIA includes Java, JavaScript, Flash, RealPlayer, and support for standards like DHTML, CSS, XML, and more. All in less than 8MBs.

Granted, BeIA and Linux aren't the only players in this game. QNX is a strong contender here as well (witness the Netpliance i-opener, which runs a custom version of QNX). But talk to any developer who's programmed both QNX and BeOS/BeIA implementations, and you'll learn that QNX isn't a pretty picture from the development perspective, and that its API leaves quite a bit to be desired.

WinCE, PocketPC, and PalmOS aren't really contenders here. We're not talking about hand-held devices, but small-yet-robust personal computers dedicated to a subset of computing tasks. None of them have what it takes to deliver the rich user experience on low-cost hardware that BeIA offers.

In the end, it may turn out that time-to-market and resources required are going to be much greater than if your company had gone with an off-the-shelf solution. The bottom line may actually be adversely affected by going open source rather than proprietary. And when all is said and done, your appliance still won't perform as well as a BeIA-based solution.

As it happens, this is exactly the kind of stuff Be is emphasizing and specializing in with their appliance strategy. Be has devoted most of their energies to creating a compact-yet-robust solution custom-tailored for implementation on devices with limited hardware resources. UI customization is accounted for fully in the very concept of the device: most of the interface is created in HTML or DHTML, and OS components are controlled via JavaScript hooks (which cannot be activated from other IP addresses, in case you're wondering about security). The BeIA API is designed expressly for appliance implementations, and is clearly documented for development teams.

Whereas any Linux-based solution will by definition be saddled with the performance quagmire and font mess that is X, BeIA-based appliances get the simplicity, speed and responsiveness of the BeOS windowing system automatically. For devices that intend to evolve into heavy multimedia implementations, the device takes automatic advantage of Be's hallmark multithreading, and therefore remains responsive under heavily multitasked media loads.

Giving Away the Farm

Time to market is only half the battle. From the stance of a commercial vendor creating a commercial product, the open source world holds other barbs. For example, if components of your system link against libraries that fall under the GPL, you may be forced to release your own system -- or parts of it -- back to the community as open source software. In other words, building a proprietary solution on top of Linux may mean being required to expose the company jewels to the competition.

Witness TiVo, who manufacture a time-shifting hardware/software solution for television consumers. Because TiVo is based on Linux, the company's modifications to the kernel are available for anyone to download -- any competitor can emerge at any time, packaging up and selling a variant of Tivo's hard work. That necessity alone is enough to give a CEO pause.

Do you really want to have to think carefully about whether any portion of your code is linking against a GPL'd library? If you develop on top of Linux, you'll have to.. or risk the ire of the open source community.

Working in the open source world also means that programmers have to work in the absence of clearly defined APIs. There is no single application programming interface for open source developers. Rather, there is a cacophony of (often incompatible) choices to make. KDE, Gnome, Motif, QT, and more. All have advantages and disadvantages. And all of them utilize incompatible libraries. If your appliance is constructed such that users are able to download and install software, they're going to come face-to-face with the same kind of incompatibility issues that Linux users encounter on a daily basis -- applications that require one desktop environment or another, or that require system libraries which may be incompatible with already installed libraries. More support headaches.

By forging their solution under a single roof, with a consistent vision of what an appliance could and should be, with a single, consistent API, and with a single, consistent game plan, Be has made things much easier for appliance vendors, offering the opportunity to create devices that A) Boot and run on limited hardware resources without having to hack the system down manually, B) Make total customization of the user experience a comparative walk in the park, and C) Don't risk running afoul of the GPL.

I'm not developing an appliance. But if I were, I can tell you where I'd be putting my development efforts.

One Million and Counting

In the week following the free release of BeOS 5 Personal Edition, half a million potential BeOS users were born. Actually, that number is very conservative, as it tallies only the downloads logged by the official mirrors that actually kept stats. In reality, there was at least one logging snafu that prevented countless downloads from being tallied. And Be's press release didn't account for the tons of unofficial mirrors that sprung up in people's back-yard FTP servers like mushrooms. I wouldn't be surprised if the first week totals weren't closer to a million. And that was only the first week. A recent newsletter article by Be's CEO pegged the most recent count at more than 3/4 million -- who knows where the total stands today? I'm confident there have been more than a million by now.

Of course, not every download automatically results in a new BeOS user. Many people will download the OS and find it's not for them, or find that their hardware is not supported.

Unfortunately, it turns out that the "install BeOS from within Windows" technique, despite the engineering brilliance it represents, does not easily circumvent one ugly fact of life: Windows can be reluctant to let go of memory addresses and IRQ assignments. When you boot BeOS from within Windows, Windows has already assigned addresses to most of your hardware. Because BeOS does a "software reboot" rather than a cold or warm boot, it may suddenly find itself in an environment where it's not able to assign resources at it best sees fit; results can be unpredictable. While the "boot from Windows" technique works fine on most machines, some users have found themselves without a visible mouse pointer, or network cards that won't initialize, or video problems. This is unfortunate, since new users will tend to blame BeOS for what is essentially an artifact of Windows' behavior.

Fortunately, most of these problems can be easily resolved by cold- or warm-booting BeOS. This can be accomplished by using the BeOS boot floppy (create one with the provided Windows tool) or by booting to DOS mode and typing:

c:\beos\loadbeos.com

Will Free BeOS Grow the Scene?

In any case, it's a little early to tell exactly what impact the release of free BeOS will have on the health of the BeOS scene in general, but one thing is certain: BeOS-related online fora have been flooded with new users. IRC, USENET, mailing lists, and discussion boards have been swamped with questions, and the community of veterans has risen to the occassion like champs, making sure new users are able to quickly see and experience the advantages of The Be Way.

The acid test, though, will be in the impact of all this has on software development. If the new users are able to rally their voices, and developers begin to realize they have a real opportunity for profit, then we can expect to see the BeOS software scene burgeon as well. Without that key ingredient, people will be downloading an OS that doesn't provide enough real-world solutions to justify conversion. It's not that BeOS "out of the box" doesn't enable users to do things they can't do in other OSes, but people hold up things like Photoshop or name_your_favorite_game as reference bars. If BeOS solutions can't meet or exceed the standards set by those apps, the userbase will continue to grow steadily... but slowly.

Meanwhile, many existing BeOS developers are pooling resources to build killer open-source apps, in a collaborative project dubbed BeUnited. The question of whether BeOS will benefit by encouraging more open source development, rather than less, is a good one. Many argue that it is precisely the fact that BeOS is mostly closed source that makes it so clean and elegant, and that open source development efforts make it difficult for independent developers to make a living from their efforts. If BeOS developers can't make a living and show the world there's money to be made in the BeOS world, the development pace will languish. On the other hand, many are tired of waiting for tractor apps. Of the thousand+ apps available on BeBits, too many are small utilities. Yes, office suites, graphics apps, and media tools exist. No, most of them are not yet as mature as their Windows or MacOS cousins. Open source efforts may be the best chance we have of bringing large projects to maturity. BeUnited will be an interesting project to watch.

BeView Content Archives