Community commentary: The case for Linux Open Services

Here’s the scenario: I sit down to my desktop computer and plug my Sharp Zaurus Linux-powered handheld into its base station. An applet in my panel starts flashing the word “syncing” and a progress bar starts creeping — 1%, 2%, 10% … Without giving the syncing operation another thought I click on the devices folder in Nautilus.

There, sitting before me, are icons for my printer, scanner, TiVo and my Zaurus. I need to get a hard copy of the Word file I had loaded on my Zaurus at work. I could go searching for it in my sync folder but another glance at the applet tells me it isn’t done yet. Clicking on my Zaurus icon shows me a nice layout of virtual directories making it easy to find my file. I click on documents and then Word files. There it is! Dragging the file to the printer icon automatically opens up a copy of Star Office and prints out the document.

I look at the document and notice that it lists updated contact information for a client of mine. I could open up the god-awful, second thought, cross-platform client for my Zaurus but I rather like the interface of the Zaurus itself. But then again, even with the keyboard, entering any good amount of info into the Zaurus is painful at best. I then remember Sharp saw the light and decided to ship with X enabled. I select my Zaurus icon in Nautilus, open up the side bar and hit the button which is labeled “export
desktop.” In a second, the desktop pops up in a window and I go into the address book app and update the record with the knowledge that it will be backed up on my desktop in a short while.

Now it is time to unwind, but I am too lazy to go downstairs to the TV room. I click on the TiVo icon. In the file view window of Nautilus loads a Mozilla window with a TV guide like listing off all the shows recorded on my TiVo. Oh my! I almost missed tonight’s episode of 24, but that’s why I bought my TiVo in the first place. I fire it up at full screen and, without dropping a frame, watch as it streams seamlessly to my desktop.

The reality

As things stand, we are not quite there yet. At last glance there were many embedded consumer applications running Linux or other Unix-like OSes and many more to come. But I’m not impressed.

While these projects exploit the power, size and cost savings of the Linux kernel, they fail to exploit the openness and its ability to connect via standard protocols. In other words, Linux devices today fail to talk to each other, not because they can’t but because the pieces that would allow them to do so have been excluded from their design. Some of those pieces need to be retrofitted to fit in resource limited environments and some just need a bit more cooperation among the various Linux device manufactures.

Look mom, I can sync

Any mobile device nowadays needs the ability to sync with desktop applications to be useful. This is what made handhelds based on Palm so popular. Whether I am at home or on the road I have the same information at my disposal. It has become an expected feature in handheld computing. If you can’t do it as good as the Palm, then don’t even try to sell me your product. Even if you can do it as well as the Palm, why should I ditch it for something that says Linux inside? I need something more compelling than “just as good as.” It needs to sync better.

Enter the Apple iPod. Here is a device that in all respects should have died the minute it hit the store shelves. It is expensive and could only sync with the newer Macs. What was its saving grace? All you had to do was plug it in, and it would sync with your iTunes software. The Apple iPod is quickly becoming one of the most successful MP3 players on the market and third-party developers have started creating tools to sync it with Windows.

If Linux is to succeed in the consumer embedded market, it needs this type of ease of use. Not only must it sync with little or no user input, I must be able to connect it to my favorite programs such as xmms and Evolution. And it must do all this with the security and reliability we have come to expect from Linux.

The building blocks

Linux has most of this functionality, but those functions must be stuck together in the proper sequence in order to be useful. Down to the kernel all the way up to the desktop, Linux has the ability to do everything I have put forth in this essay. Let us work from the bottom to the top.

I have seen some amazing things from the Linux kernel. I remember a little distribution, now defunct, called Plug and Play Linux, which promised to configure all my cards IRQs for me. Being a DOS-head at the time, I was amazed. Sure Windows 95 had just come out and promised the same thing, but I had to load drivers. The next version of Red Hat came out with limited plug-and-play capabilities — enough so I didn’t have to configure my ethernet card and it was able to detect my sound card and give
me the IRQs. Windows, however annoying, always had better plug-and-play compatibility back then. It was a Microsoft standard.

Now in 2002, something truly amazing is happening. I have Linux on a laptop at work and the dongle on the PCMCIA ethernet card kept falling out. When I plugged it back in within a few seconds, I was back on the network and my telnet session was stilled logged in. After being annoyed at this problem for weeks, I swapped out the PCMCIA ethernet card from a coworker’s laptop. I plugged it in and was back on the network a few seconds later. Talk about plug and play. I have also seen the debug messages run across the screen in an old 2.2 kernel backport of USB whenever I plugged my Visor’s USB cradle in or pulled it out. Hardware detection works in Linux. I am sure it would be simple for Linux hardware manufactures to come up with a standard way of creating detection signatures for their hardware if the USB spec doesn’t already provide for this.

That brings us to the next building block — connection. As far as I have seen, the Linux kernel can run tcp/ip packets over anything. Why mess with a good standard? Using tcp/ip as the transport of choice allows any programmer to simply connect to a port in order to communicate with a device no matter how it is connected (Bluetooth, ethernet, USB, serial). Linux was built around tcp/ip and does it well. Problems with the current IP addressing mechanism running out of ip addresses is solved in Ipv6, which
is part of the kernel, although it still may need some polishing.

Tcp/ip works well as a messenger, but we have to speak the same language in order to
understand each other. This is something Linux vendors, from the embedded device up to the desktop and servers, must get together on. My first big disappointment of the Sharp Zaurus is that it did not come with X Windows installed. It is one of the reasons I won’t be buying it anytime soon. X has been ported to small devices and has been shown to be a viable option in restricted environments. Without the ability to export my desktop and utilize the X clipboard, the Zaurus is just another PDA to me. A cool one at that, but my Visor does what I want and for cheaper.

XML is another ray of hope for device to device communications. Linux has very good support for XML through projects like libxml. There are two very interesting XML protocols that Linux currently supports. They are XML-RPC, and perhaps even more interesting SOAP. Both protocols allow for execution of remote procedures on a server (or any device running these services). What is interesting about the SOAP standard is that it is being pushed by Microsoft (and others such as IBM) as the basis for
their Web services strategies. By including SOAP in a Linux enabled device, it will be able to instantly communicate with any other SOAP-enabled device or Web site. The nice people at Ximian saw the potential of SOAP early on and created the SOUP libraries so that programmers can start SOAP-enabling their applications now. What would be nice is a lightweight SOAP daemon that intercepted incoming SOAP calls and acted as a distributor.

We shouldn’t forget about HTML. HTML is ubiquitous. Every desktop computer can understand and render HTML code. For devices that need to export simple interfaces, like the TiVo in my example, HTML and the newer XML-based browser standards such as Mozilla’s XUL and the W3C’s Xforms provide a great option. Apache, the de facto Open Source web server, has already been ported to embedded devices and can be used to serve up these interfaces. The benefit here is that HTML is simple and many people feel comfortable using a browser as an interface.

The biggest place I see HTML as a boon is in remote configuration. My Linksys broadband router already uses a Web-based configuration tool that is easy and straight forward to use. The best part of this is that it can go both ways. I could be walking around my Bluetooth-enabled office with my Zaurus with the intent of setting up a new employee with email. As I walk to her desk, I connect to the mail server, which is running the GNOME control panel Web service and the mail capplet. I type in the admin password (a secondary form of protection because only my desktop and Zaurus are allowed to access the admin account) and set her up before I even get to her desk. When I get there I ask her to log on, fix a little problem she has accessing
her inbox due to a permission not being set, and then am on my way to the next desk. I don’t think the new GNOME control panel can do this yet, but it should. Imagine that any configuration capplet a programmer writes is automatically Web-enabled by simple turning on the service.

The last building block is desktop integration. In my wishful scenario, I was able
to access all of my devices from the Nautilus file manager and get all the benefits of drag and drop, among other things. One of the goals of Nautilus was the ability to access any data source through the common file system interface. This was accomplished by GNOME’s virtual file system, or VFS for short. If you think about it, everything in Unix is a file. Even devices are files that reside in the /dev directory. So anything can be imported or exported as a file system. While the files may not be arranged in a directory
structure on the actual device, devices would be able to export a virtual directory structure that organized the data in useful ways. The challenge here is to come up with a standard protocol for describing these directories and services and implementing a VFS plug-in so that Nautilus can navigate them. My vote is for XML though LDAP services, which could be used and is already implemented under Linux in the form of the OpenLDAP project.

Security

Security is a huge issue with devices that can communicate and exchange data with each other. Saying any one of these ideas cannot be implemented because of security reasons would be like saying the Internet is not viable because it poses a security threat. The benefits outweigh the risks. Security, however, is Linux’s strong suit and should not be tossed aside for ease of use. A balance must be found, and the ability for the user to tip that balance must also be allowed. Corporate systems need more security and don’t care terribly about ease of use where sensitive data is concerned; however, home users will
quickly become frustrated and move to a less secure product should they have to jump through hoops just to get their handhelds to sync the latest songs from their MP3 collections. Ease of use and good security are not mutually exclusive; I believe that Linux is in the best position to offer this balance in its embedded devices.

Conclusion

We see many Linux enabled devices popping up around us. It is clear that Linux has a bright future in this market niche but it really won’t take off unless these devices offer more than just the same old thing. Linux is in the position, because of its openness, to create a class of devices that truly interact with each other and aren’t just islands of functionality. Sun likes to say, “The network is the computer.” Linux is on
the verge of making that statement a reality. The added benefit is that any platform would be able to join in because the protocols are all open standards, but Linux would have been there first and pioneered what I like to call Linux Open Services. It is this vision that I feel will make Linux stand out as both the de facto embedded, desktop and server OS.

If Linux devices can scale well and communicate with each other
out of the box, then there is no limit to what they can do. In the future computing, power will be judged not only on processor speed and graphics power, but also on how well it keeps you connected. This is an exciting time for Linux.