Re: SuSE Linux 7.0
> % I may be biased, but ...
And indeed you are, as is the comment above about Emacspeak being "in use for years" by blind people. It has, and it has not. It has only in that geeks are people too -- a suitably motivated programmer can figure it out, and a suitably motivated employer can afford the expensive voice sythesis hardware or afford to buy the minimum-order 200-seat ViaVoice license (at $200/seat) to make a stable system, but all the other variations of Emacspeak are highly unstable, requiring frequent reboots, missing warning messages, missing error messages, in short, not very friendly to anyone who doesn't already know what is going on.
The same is true for SpeakUp: if you already know the meaning of every last prompt and message that will routinely spew out of the speakers, and programmers will probably find all that "interesting" anyway, then this system works very well, but as a general consumer-level system for a non-technical user? The only users I have encountered in that category had readily available free technical support on-site. That hardly describes the average.
I am quite disappointed with how this all turned out. When IBM yanked the free Linux TTS runtime, it put a fatal dagger in the heart of Emacspeak. DecTalk hardware works, so I am told, but I was also told that etalk, festival, flite, DTPC2 and Accent and espeak all "work" ... and they do only insofar as they occasionally speak intelligible words, but without multi-voice support, without clear diction, without speaking the warning messages but simply stalling or beeping when any of a thousand things go wrong, are they practical?
You'd have to really, really want to make them work for you, and still have sighted people nearby to explain why the LaTeX failed to compile your letter, or why the printer won't work, or why your email won't load or why you can't delete a spam or ...
Re: Many Features except Robustness
> I'm using Debian, so installing [getmail] is
> trivial. And it was simple to configure
> - I have it running as a cron job under
> the mail user, piping mail to procmail
> for two users (procmail filters to
> maildirs which are handled by Courier
> imap + Squirrelmail for web access).
> Appears to work fine. You should try
We've since learned that procmail is also problematic as it loads entire files into memory to process just the headers (or that's what I've heard, haven't read the code yet). In these days of large attachments, that can seriously impact server performance, so we've been looking at a few alternatives.
Just so you know, though, the problem is not so serious that we're scheduling downtime to fix it ;) ... we've known about the problem for a long long time, and yet we still run procmail. What surprises me is how the Linux distros (Mandrake at least) still ship with these really bad-example programs as the default configuration.