Purpose-built Systems

Vol. 4 No. 3 – April 2006

Purpose-built Systems

Interviews

A Conversation with Chuck McManis

When thinking about purpose-built systems, it’s easy to focus on the high-visibility consumer products—the iPods, the TiVos. Lying in the shadows of the corporate data center, however, are a number of less-glamorous devices built primarily to do one specific thing—and do it well and reliably.

A Conversation with Chuck McManis

Developing systems with a purpose—do one thing, and do it well.

When thinking about purpose-built systems, it’s easy to focus on the high-visibility consumer products—the iPods, the TiVos. Lying in the shadows of the corporate data center, however, are a number of less-glamorous devices built primarily to do one specific thing—and do it well and reliably.

Few engineers have more experience building these systems than Chuck McManis of NetApp (Network Appliance Inc.). Prior to joining NetApp, McManis worked at FreeGate, a company he started with two colleagues that built an embedded server appliance for the SMB (small and midsized business) market. McManis joined NetApp in 2001, where he has been driving the scalability agenda as a senior technical director. In that role, he is deeply involved with developing NetApp’s line of NAS (network-attached storage) appliances for both enterprise and SMB customers. “We’re not a server company; we’re an appliance company,” McManis is quick to remind us.

Curmudgeon

Evolution or Revolution?

We work in an industry that prides itself on “changing the world,” one that chants a constant mantra of innovation and where new products could aptly be described as “this year’s breakthrough of the century.” While there are some genuine revolutions in the technology industry, including cellphones, GPS (global positioning system), quantum computing, encryption, and global access to content, the vast majority of new product introductions are evolutionary, not revolutionary. Real technical breakthroughs are few and far between. Most new products are just a recycling of an earlier idea.

Evolution or Revolution?

Mache Creeger, Emergent Technology Associates

Where is the High in High Tech?

We work in an industry that prides itself on “changing the world,” one that chants a constant mantra of innovation and where new products could aptly be described as “this year’s breakthrough of the century.” While there are some genuine revolutions in the technology industry, including cellphones, GPS (global positioning system), quantum computing, encryption, and global access to content, the vast majority of new product introductions are evolutionary, not revolutionary. Real technical breakthroughs are few and far between. Most new products are just a recycling of an earlier idea.

The effort seems to go into refinement, not into changing the core paradigm. When I look back to when I was in graduate school some three decades ago, I believed the world would have changed dramatically by now. Pure research in computer science was introducing new concepts at breathtaking speeds. Looking back on that time, things have not changed all that much. Most of the technologies that I studied in graduate school are still widely used. The way work gets accomplished is relatively unchanged. For the most part, we see the same recycled concepts presented over and over with shiny new paint jobs, touted as new ground-breaking solutions. It seems to me that the pace of innovation has actually slowed. As private investment poured into R&D (research and development), dwarfing government funding, the vast majority of intellectual property became privately held. As a result, we have seen less, not more, genuine innovation. Let me give you some examples.

by Mache Creeger

Articles

Java in a Teacup

Few technology sectors evolve as fast as the wireless industry. As the market and devices mature, the need (and potential) for mobile applications grows. More and more mobile devices are delivered with the Java platform installed, enabling a large base of Java programmers to try their hand at embedded programming. Unfortunately, not all Java mobile devices are created equal, presenting many challenges to the new J2ME (Java 2 Platform, Micro Edition) programmer. Using a sample game application, this article illustrates some of the challenges associated with J2ME and Bluetooth programming.

Java in a teacup

STEPHEN JOHNSON, THALES-RAYTHEON

Programming Bluetooth-enabled devices using J2ME

Few technology sectors evolve as fast as the wireless industry. As the market and devices mature, the need (and potential) for mobile applications grows. More and more mobile devices are delivered with the Java platform installed, enabling a large base of Java programmers to try their hand at embedded programming. Unfortunately, not all Java mobile devices are created equal, presenting many challenges to the new J2ME (Java 2 Platform, Micro Edition) programmer. Using a sample game application, this article illustrates some of the challenges associated with J2ME and Bluetooth programming.

J2ME PRIMER

J2ME is Java for embedded devices and consumer electronics. Figure 1 shows the J2ME component stack: configuration is at the lowest level, followed by profile, with optional packages on top. The features (and APIs) provided by a given device depend on the mix of supported configurations, profiles, and optional packages.

by Stephen Johnson

The (not so) Hidden Computer

Ubiquitous computing may not have arrived yet, but ubiquitous computers certainly have. The sustained improvements wrought by the fulfillment of Moore’s law have led to the use of microprocessors in a vast array of consumer products. A typical car contains 50 to 100 processors. Your microwave has one or maybe more. They’re in your TV, your phone, your refrigerator, your kids’ toys, and in some cases, your toothbrush.

THE (NOT SO) HIDDEN COMPUTER

TERRY COATTA, INDEPENDENT CONSULTANT

The growing complexity of purpose-built systems is making it difficult to conceal the computers within.

Ubiquitous computing may not have arrived yet, but ubiquitous computers certainly have. The sustained improvements wrought by the fulfillment of Moore’s law have led to the use of microprocessors in a vast array of consumer products. A typical car contains 50 to 100 processors. Your microwave has one or maybe more. They’re in your TV, your phone, your refrigerator, your kids’ toys, and in some cases, your toothbrush.

The increasing use of microprocessors in consumer goods is not a new trend, of course. Engineers and developers have been working on embedded systems for decades. In the past, however, the fact that a device contained a processor or two might not be immediately obvious to the outside observer. The box did some job, and the vast majority of us could remain blissfully ignorant of the technology that lay hidden away, silently performing its digital miracles.

by Terry Coatta

TiVo-lution

One of the greatest challenges of designing a computer system is in making sure the system itself is “invisible” to the user. The system should simply be a conduit to the desired result. There are many examples of such purpose-built systems, ranging from modern automobiles to mobile phones.

TiVo-lution

JIM BARTON, TIVO

The challenges of delivering a reliable, easy-to-use DVR service to the masses

One of the greatest challenges of designing a computer system is in making sure the system itself is “invisible” to the user. The system should simply be a conduit to the desired result. There are many examples of such purpose-built systems, ranging from modern automobiles to mobile phones.

As these products are enhanced over time, however, they often stray from invisibility, imposing new burdens on the user. The two burdens that are probably most annoying to the user are a complex and difficult control interface and lack of reliability. Reliability is not just about whether a computer system functions or not. It encompasses expected behavior, lack of ambiguity, and recovery from unusual events, such as loss of power or network connectivity.

by Jim Barton

Kode Vicious

Kode Vicious Bugs Out

Dear KV, I'm on a small team that is building a custom, embedded, consumer device that is due out by Christmas. Of course the schedule is tight and there are make-or-break dates that if we miss basically mean the product will never make it to market. Not the most fun environment in which to have problems. The software was carefully specified and laid out and then simulated while the hardware was being manufactured. Now we have real hardware, and real problems as well. Aside from the timing issues we found when we were no longer running the software in a simulator, several bugs remain that show up only under very special circumstances and that disappear when I use the debugger or turn on the logging code built into the system. When tools fail you like this, what do you do next?

This month Kode Vicious serves up a mixed bag, including tackling the uncertainties of heisenbugs -- a nasty type of bug thats been known to drive coders certifiably insane. He also gives us his list of must-reads. Are any of your favorites on the list? Read on to find out!

by George Neville-Neil