Poking around inside the NIC

Further investigation revealed some interesting NIC design decisions.

For example, I discovered that the Boa Web server is loaded on bootup — something that at first may seem to make little sense for a restricted small-footprint device like the NIC. However, including a Web server lets the NIC maintain a purely browser-based desktop user interface. A way of launching internal applications (such as games and utilities) was needed, and a reasonable way to accomplish this is to provide a Web page with application choices, then launch the program the user chooses via a CGI script. This can, of course, only be done with a Web server, and Boa is a good choice based on its simplicity and small footprint.

Also interesting, is what you will not find in the NIC's system software.

Few of the standard Linux utilities are included. You won't find “find”, for example; and mkdir is available, but rmdir is not. On the other hand, full versions of bash and vi are provided. Presumably these choices were driven by the needs of the various system scripts, and the NIC apparently includes only those utilities that are required by the scripts.

Such a tradeoff makes sense in an environment in which shell sessions are not expected, but perhaps BusyBox would have been a more appropriate way to save space while still providing facilities for scripts.

General impressions

From examining the NIC's internal software, it's clear that the device was designed strictly for the thin client desktop market, with little or no effort applied to making it adaptable to other purposes. With slightly more I/O flexibility, such as the addition of a serial port or PCMCIA slot, the NIC could be used for a variety of other applications including set-top-boxes, kiosks, point-of-sale systems, and semi-embedded environments such as special-purpose lab devices. On the other hand, this issue may become moot thanks to the rapidly increasing availability of USB-interfaced I/O devices.

The NIC's marginal power supply is frustrating to those wishing to add power-hungry devices like hard drives. Although adding software to the CD-ROM image circumvents that problem to some extent, it's important to realize that CD-ROM based system software needs to be carefully selected and configured to minimize the number of CD-ROM accesses, in order to maintain acceptable interactive performance. The supplied software is somewhat successful in this respect (though it still has annoying waits for disk access), but fails to provide needed functionality such as a mail client. This makes the device usable only for very restricted applications limited to a web interface.

At the risk of seeming a bit like Bill Gates, I think few home users will find the NIC's functionality adequate to serve as a replacement for their more flexible PCs, though the addition of a mail client would help a lot. On the other hand, adding functionality to the CD-ROM is easy, but quickly leads to degraded performance if disk accesses are not carefully considered. Achieving the right balance of cost and functionality is obviously the big challenge!

The CD-ROM based NIC must really be thought of as an embedded device, rather than a general purpose computing platform. As with other embedded devices, the NIC's success depends on carefully choosing only that software needed to meet the predefined application needs, and verifying that the system functions acceptably in its expected modes of use.

• Part 1: Software as a growing percentage of system costs
  
• Part 2: Making the NIC do stuff
  
• Part 3: First hack attempt
  
• Part 4: Poking around inside the NIC
  
• Part 5: The verdict?

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.