This is a computer I bought for $8 at a garage sale and painted with a $2 spraycan. It's a 386 SX with 4 megs of ram and it is running the current version of Vault OS in spite of the fact it has no hard drive, monochrome screen only and even the CMOS battery is dead for the bios. I plan to implement a feature whereby these machines can be told to ignore their BIOs settings and to get an accurate date-time from a TCP-IP service. The app is running in 32 bit protected mode on a 640x480 256 color SVGA display at about 64 fps. It has two visual pages (for smooth flickerless updates) and two offscreen buffers for the GUI interface display management. The current build has all the TCP-IP libraries compiled in, the Metakit database, the John Miles Sound System, the Fastgraph graphics library and a heavily adapted version of FastGUI. The executable is now 1.2 megs leaving roughly 3 more megs to operate with in RAM alone. Amazing what you can do once you ditch windows.
This machine comes with a functional serial port, parallel port, a single USB socket, a microphone input, soundcard output jack and a PCMCIA slot. I already found a network card with floppy disk software that works on this for $1 at a surplus store. So this would be a typical example of a single server/client terminal in the Vault OS Network. You could plug who knows what kind of real time data sensors into this unit without the hassles of having to build a dedicated ethernet board as described in the first draft of the Vault OS architecture. The exact mechanics of how you will read/interpret the data on a port are still up in the air, but I am writing a scripting language that is going to give you all kind of flexibility to do things like read/write to/from ports and some built in routines for A/D conversions and other features for embedded sensors. I will not hard code any of this stuff on my local setup to make sure that others will be able to adapt their networks to do what they want.
Note that the simple presence of a microphone jack implies the capability to read incoming analog sound signals (like from the audio jack of a CD-715 radiation meter) through the sound card and convert them to digital data signals that can be displayed on a graph or display widget of some kind. This part is a gray area but in the act of getting my own setup running I'll be debugging this through the scripting front end. I thought one way of standardizing this might be to insist on Sound Blaster compatibility, that way I could count on an SB driver that I could call off interrupts from inside the script to process audio information. Fantastic things with A/D sensing have been done through sound cards so this is worth investigating.
Right now the important thing to debug is the sensor input framework, but the ports aren't limited to input - they can also be wired to control the outside world ... turn on lights, run the water or fuel pump, manage the temperature of a greenhouse, etc. ... and that's the tip of the iceberg. One very cool application might be a generic system for management of CCD security cameras and getting the framebuffer off of one to splat into GUI windows for real time capture and motion detection on video frames.