Pediatricians treat children. Gerontologists work with the aging. Both practice medicine, but their skills are very different.

The mechanic at the Toyota dealership is probably clueless little about GM's cars, while a motorcycle repairman knows every nuance of BMW's bikes, but no doubt can't grok a 745i.

The Verizon FiOS dude can splice fiber, but knows nothing of Comcast's cable distribution system.

It's easy to draw pretty clear lines between the skills and duties of many seemingly close occupations. But it's increasingly hard to narrow what constitutes embedded work from other forms of programming.

Why do you read Embedded Systems Design? Presumably you build, or are interested in, embedded systems. But what characteristic defines this field? How are our skills different from those used by, say, a developer at Microsoft creating the next generation of spreadsheets?

In reading "Building Embedded Linux Systems" (2008, O'Reilly, Sebastopol, CA, by Karim Yaghmour, Jon Masters, Gilad Ben-Yossef and Phillipe Gerum – what a wonderful-sounding mash of international names!) I was struck by how much of the book has nothing to do with embedded systems. It's a nice work, to be sure, but most of the "embedded" content is in the final three chapters on real-time aspects of Linux. And there's little about actual timing one can expect when tossing Linux into a real-time system.

According to "Snapshot of the embedded Linux market -- May, 2006" By LinuxDevices.com, which is 2006 data, 47% of respondents have used Linux in their embedded systems. That number is probably overstated due to the self-selecting nature of those responding to linuxdevices.com, but a survey I conducted the same year showed that 35% of the systems readers built included either Linux or some flavor of Windows. Surely those numbers have increased in the last three years. They do paint a picture that suggests an awful lot of "embedded" applications are running desktop OSes.

Many engineers scoff at the use of a desktop OS in embedded applications. Yet this sort of operating system makes sense in a lot of circumstances. Managers tell me they like the rich APIs these provide, and really appreciate the deep pool of programmers who are familiar with them. The Windows development environment has a much wider following than, say, that of VxWorks. In flush times bosses can hire plenty of Windows people, at more attractive rates, than deeply embedded folks. Processors are cheap; people aren't, so it's common to see systems structured around a hefty 32 bitter running a desktop OS, with one or more smaller CPUs doing the fast stuff and the deep bit twiddling.