[Beowulf] Wired article about Go machine

[Lux, James P]

> -----Original Message-----
> From: beowulf-bounces at beowulf.org 
> [mailto:beowulf-bounces at beowulf.org] On Behalf Of Joshua Baker-LePain
> Sent: Thursday, March 26, 2009 8:54 AM
> To: Robert G. Brown
> Cc: Leif Nixon; beowulf at beowulf.org
> Subject: Re: [Beowulf] Wired article about Go machine
> 
> Note that Leif mentioned medical equipment with embedded 
> Windows systems. 
> And he's right -- you're not allowed to touch the software 
> build on those without getting the new build approved by the 
> FDA (at least, not if you want to use said equipment on real 
> live patients).  And those machines are generally networked 
> so that the data (images, e.g.) can be uploaded.  It is very, 
> very scary.  Why anyone ever made the decision to run medical 
> equipment on Windows (over the screams of the engineering 
> team) is utterly beyond me.
> 

Not to be a MS fanboy, but it should also be recognized that Windows Embedded is a different animal than consumer Windows. Or, more properly, Windows Embedded CAN be made a different animal.  It's up to the system integrator/manufacturer to "do the right thing".  After all, it's not the windows kernel that's the problem, it's the "other stuff" and "configuration" that is the problem. It's the person who decides "Hey, let's let the user run PowerPoint on the EKG monitor" that is the real problem, which is exacerbated if your system development team has come from a more traditional non-windows embedded development world, where the idea of network connectivity was a pipe dream (gosh, wouldn't it be neat if we could get the data out by some means other than a 9600 bps serial link! And no more GPIB/IEEE-488!).  Windows *is* a seductive trap.. Hey, we can load windows up and then we can just write to USB thumb drives, or use a browser!.. It creates the illusion that you don't need to invest some serious resources in the OS for your device.

The problem being that those developers (who are very development cost sensitive) AREN'T usually people who have enterprise/networking system experience.  They're "consumers" of desktop services, but their mindset is focussed on running the crosscompiler for the Z80 or x86 that's on the embedded card. There's a whole different mindset when you go from "microcontroller running test equipment" to "networked attached computing device that happens to make measurements". When you're running on a dedicated box with limited interfaces, the very box itself enforces a form of security. You don't even think about viruses, because there's no way to load new software short of sending it back to the factory to burn a new PROM.


Heck, they may not even be aware of the existence of Embedded Windows, so they may think that loading up consumer XP is where it's at.  It solves the immediate need: network and disk accesses without having to actually write any software. Maybe security winds up on some "to-do for the next release" list.


I know lots of embedded developers who basically have devoted all their mindshare to their particular embedded platform (be it VxWorks, eCos, RTEMS, or whatever) and don't really have the time and inclination to become an expert on Windows (which, itself, is probably a >1 year task, PARTICULARLY if you come from a Unix environment.  It's the long time Unix SysAdmin guys who you find writing weird little scripts and stuff to do things that Windows actually already does, but in a non-unix-obvious way)

I think (and it's just speculation, so "flame on" if you will) that those very same developers, if they put Linux on the piece of gear, would make the same boneheaded system configuration issues, etc. that they do with Windows.  The only saving grace is that the "vanilla" installlation of Linux, particularly if they picked a distro targeted at embedded apps, *is* somewhat better configured than the "vanila" installation of XP.


Jim