[EMAIL PROTECTED] wrote:
*snip*
Although we do intend to write specialized code for the project, I do not
want to write a text-to-speech and speech-to-text suite right now.
You don't need to write it. As with AT&T's famous cross of a Rooster and a
telephone pole, you just need to 'reach out and touch' it.
Networking the audio bothways is the equvalent of the rest of that joke.
*snip*
Most likely candidate right now is a Linux laptop in a shoulder bag or Slackware
installed on a mini PC we have in the lab.
Seems driven by 'familiarity' rather than 'suitability for the purpose'.
But might be better-off with DRDOS and GEM. Seriously.
Or Forth. I've done ISAM DB's, multi-tasking, high-speed terminals, graphical
games, editors, text to speech, and a lot more in it - always in well under 24 KB.
As the language is also a virtual-memory OS, and is *tiny*, it could get into
and STAY in the L1 cache of most modern CPU.
There are others like that.
The trick is to NOT otherwise carry a full-blown 'OS' such as Linux in order to
support the 'applications', but rather to provide the applications with only the
I/O hardware layer interface they will actually use.
*snip*
This is what I want. That's why Linux seems like a decent candidate. The
hardware
we're looking at can handle it just fine. It gives us a VT type interface.
CP/M gives a 'VT like interface' in a couple of KB. Real VT's. ADM-3's SOroc IQ
120's TVi 920's et al did it with gate arrays.
Another 500 bytes and you have serial port and Hayes-compatible modem drivers.
Not a whole lot more was needed for David Clark's IP stack.
Linux is a 'decent candidate' the way delivering pizza in a motorhome compares
to using a Vespa scooter.
> Couple
that with campus wireless and we can connect to whatever "support
infrastructure"
we want.
Familiarity with Linux seems to shut down common-sense somehow.
A friend in Hong Kong spent two years working on a contract for a vending
machine maker. He was trying to develop an embedded Linux variant to automate
vending machine inventory - to be 'polled' from HQ via an embedded GSM device.
Meanwhile. KISS.
Back on Planet Earth, someone else hooked an ignorant Programmed Logic Array to
full/empty slot sensors, simply shifted the current count out as a number when
the phone module in the vending machine was polled. No need for even a TOD
function. No 'OS'. No UPS. No need even for NVRAM - just re-poll the sensors
when called.
HQ knows the time of day and can keep their own copy of inventory.
Same again with the now-prevalent smart-card payment modules. Move the data,
move the work needed to manipulate it to where reseources are cheapest and most
easily maintained.
'When the only tool you have is an Operating System...'
it is hard to remember that you only have a few specific taska to accomplish -
'state machine work' most of them,
..and that 'general purpose' programmability is better served back at the
Mothership or elsewhere on the network - not by over-empowering the
should-have-been-thin client/dumb device.
All that does is make money for the battery makers and chiropractors.
Plan9 took cognizance of that, and it isn't just about whether you *can* get
enough power into a postage-stamp size device, or even how cheaply.
To an extent, it is about where you want to do your backups, maintenance
upgrades, devel, testing, and support for the least cost and hassle *those* entail.
Bill
