Slashdot Mirror

Photoacoustic transducer (1998).

On the other hand, microwave heating is dipole heating. Many molecules (with water being an especially strong example) have an electric dipole, which they tend to naturally attempt to line up with an electric field, such as that in an EM wave. When this field is oscillating, it then causes the molecule as a whole to oscillate, causing heating while not specifically interacting with any specific molecular bond. If you check out a graph of water's absorption (here, for example), you can clearly see the difference between the resonant heating (lower wavelengths, where there is clear resonant structure) and non-resonant dipole heating (the smooth curve at higher energies).

I do think that if the difference between interactions which involve the bonds (such as the mentioned resonant processes, and the dreaded breaks caused by ionising radiation) and these heating processes it might mitigate some of the terror associated with microwaves. On the other hand, anyone who bothered to take the time to understand these issues probably isn't too worried anyway...

Hemoglobin has a different absorption spectrum when it's oxygenated (oxyhemoglobin) or not (desoxyhemoglobin). An interesting characteristic of this spectrum is observed in the near-infrared part or light (700-850nm): http://omlc.ogi.edu/spectra/hemoglobin/index.html

In the infrared part, oxyhemoglobin absorbs less light than desoxyhemoglobin ; it's the contrary in the red part. So if we shoot these near-infrared wavelengths (and some more, to get a good idea of the absorption spectrum) in the head and detect it somewhere else (around 5-6cm from the source), we can get information on the concentration and oxygen level of the hemoglobin in the middle of the emitter and the detector. If the hemoglobin is more present than somewhere else in the head, and it's less oxygenated than usually, we get a good idea that there's something wrong there.

Other advantages : infrared light is non-ionizing, so it's absolutely no dangerous to use that kind of instrument continuously on a person until we are sure there's no problem.

It's brilliant and I'm glad to see that kind of instrument emerging.

House is an operating system written in Haskell.

There are different means of checking software; the article describes a technique wherein a specification language is used to describe the essential features of an application which is then checked using theorem-proving techniques. The power of Alloy seems to be based in part on its ability to efficiently process the multitude of variations in program execution by establishing the equivalency of many internal states. There are other methods which the article does mention, albeit briefly.

Floyd (whose early papers make for excellent reading of CS, and whose name should be every bit as familiar to the CS crowd as Knuth) and then Hoare explored the idea of using assertions to prove the correctness of functions. This work was adapted by Meyer and is the basis of the Design-By-Contract features of Eiffel. Eiffel allows one to specify pre-, post-, and invariant conditions. Unlike the work cited in the article, this is not fed to a model checker, but is instead monitored during program execution. Constraint failures cause exceptions to be thrown. Some debate the overall utility of this approach, as contract checking can be resource intensive. Still, over the past couple of decades there has been a steady increase in DBC research, including several preprocessor and reflection/library implementations for Java and also Spec#, a strong research effort at Microsoft.

There is research project at OGI that features what seems to be a novel approach.
http://www.cse.ogi.edu/PacSoft/projects/programati ca/ allows the developer to annotate bits of code with assertions regarding its validity. For instance, you can tag a function as having been formally proved correct, or you can tag another as having been inspected by a fellow programmer. This flexibility seems to address many of the concerns regarding the role of formal verification in software design.

Another interesting approach is that taken by Praxis, which uses a syntactically reduced version of Ada called 'Spark'. This version is much more amenable to automated analysis. They do the sort of full program-correctness analysis mentioned in the article. Oh, and they are, according to reports, very, very good with respect to their defect rate. I imagine they don't work for peanuts, either.

Other efforts have attempted static analysis of the code base. Some work appears to be simply performing type-checking or simple analysis of the code, i.e. confirming that all statements are reachable, while others, like Alloy, concentrate on theorem proving techniques, either by use of alternate descriptions, e.g. Z, or by direct analysis on the implementation code base.

A variation on this them will be familiar to readers of the Linux kernel mailing list: researchers at Stanford used a combination approach - a variant of gcc and a proprietary language named Metal - to describe the set of potential faults to examine. That is, rather than prove the correction of a body of code, they established that the code in question didn't exhibit particular defects. This approach is, of course, subject to false positives and is limited by capabilities of the fault description language. Still, it has been effective in uncovering many previously undisclosed errors.

I believe that even Meyer has stated that one of the ultimate goals of SE is theorem-proving of large bodies of software. Perhaps choosing when to use one of these tools will eventually become part of the software development process? The success of these tools may alter the manner in which development is performed not only because of the ultimate ramifications of the establishing correctness, but also because of the discipline or precision necessary to utilize them.

jbgreer

I think the explaination can be found in this court transcript:

Q: Doctor, before you performed the autopsy, did you check for a pulse?
A: No.
Q: Did you check for blood pressure?
A: No.
Q: Did you check for breathing?
A: No.
Q: So, then it is possible that the patient was alive when you began the autopsy?
A: No.
Q: How can you be so sure, Doctor?
A: Because his brain was sitting on my desk in a jar.
Q: But could the patient have still been alive nevertheless?
A: It is possible that he could have been alive and practising law somewhere.

source:
http://www.cse.ogi.edu/~diatchki/jokes/court.html

• Hurd (now with KDE)
• Haiku
• TUNES
• House
• Squeak

People who start projects to write a new OS do so for a reason that's less than compelling for the general public.

Really? Which functional language has macros?

Show me one example where O'Caml beats C++.

ICFP contests:

2004 (ocaml 1st); 2003 (ocaml 1st); 2000 (ocaml 3rd, C++ 5th); >2001 (ocaml tied 3rd place with C);

Others winners: 1998 C derivative, 2002 python (I think C++ actually beat OCaml this year)

Check out Lava at Xilinx, Lava at Chalmers, Hawk, the Hardware Design and Synthesis section of Haskell Application Papers on readscheme.org.
The links above lead to programs that are used by companies like Xilinx and Intel to help designers build better chips with existing technology. There are more interesting hardware approaches being investigated with Haskell. Two that come to mind immediately are quantum computing and dataflow-based simulations more related to the Lustre and Lucid languages. Though I do know of some unfinished research in the dataflow/hardware design area, I can't find any published papers at the moment.

One day I'll get around to buying a PCI card with a FPGA and use Haskell to turn it into a reprogrammable coprocessor. So many cool things to learn, so little time...

• Xen does not support Windows today because it uses a technique called para-virtualization to achieve high performance that involves modifying the operating system kernel, Pratt said. However, the debut of virtualization features in next-generation CPUs from Intel and AMD will make it easier to support unmodified operating systems, Pratt said.

• "At that time we will reconsider Windows support," he said.

• Full virtualization requires no changes to the guest OS. But it is not well suited for x86 architecture as x86 is not virtualizable. x86 has machine instructions that are termed sensitive. Sensitive instructions will fail without trap when executed in the guest OS. This requires dynamic rewrite of guest OS kernel during run time and shadow system structures which results in a performance hit. Para-virtualization solves the above issues but it requires changes to the guest OS kernel although are required for the Application Binary Interface (ABI) and hence applications can run as they are on the guest OS.

When will this buffer enforcement be available for gcc!?!?

As soon as you do a search for StackGuard http://www.cse.ogi.edu/DISC/projects/immunix/Stack Guard/ or ProPolice http://www.trl.ibm.com/projects/security/ssp/.

Yeah, it's a little too dark. (It looks okay on some monitors.) Try this one.

Most of the irtc entrants publish their code. I just uploaded my code here, and there's a better rendering here

-jim

Most of the irtc entrants publish their code. I just uploaded my code here, and there's a better rendering here

-jim

Once you get used to the language, it's not that hard to make good looking, complicated stuff. Povray has dozens of built in geometric primitives, CSG support (you can subtract objects from each other), loops, and macros (which can be invoked recursively to generate things like trees). Some things are easier to make in a gui modeller, but many things are actually easier to code directly.

Here's something I've been working on. It's all code except for one of the textures and the Jolly Roger on the boat.

-jim

The scripting language is really not all that bad (especially compared to VRML, the other graphics scripting language I've used). You can build complex objects by generating them within loops or recursive macro calls - you can make a halfway decent looking tree in less than a page of code. If you're used to pointing and clicking, it can be a pain, but some things that would be near impossible to create in gui modeller are easy to program.

CSG helps the user friendliness quite a bit. With ray tracers, it's algorithmically trivial to subtract one object from another, so they expose those capabilities to the user.

Here's something I did. Except for the jolly roger (which you can't really see anyways) and one of the textures, it's all code, even the lumpy rocks.

-jim

Should be able to accomodate all evolution levels of a programmer!

http://www.cse.ogi.edu/~diatchki/jokes/programmer. html

The killer app will be one that takes in existing singing, works backwards to get a model of the singer, and then can generate songs from MIDI and lyrics as if sung by that singer. Instant cover albums.

Good open source project for music geeks.

As a sidenote I might add that Perl 6 will support the functional paradigm.

Perl5 supports *portions* of it already. closures are already fully supported, as well as list-transformation functions. I suppose you meant that Perl6 will widen its support so that it can handle full-blown FP with continuations and the whole works, which matches what I've heard.

Closures are already supported indeed, but Perl 5 lacks the essential built-in support of lambda calculus. It will change in Perl 6. As Larry Wall has said on perl6-language mailing list on December 2002, "About the only things that have to be truly built-in to Perl 6 are lambda and the regex engine. Everything else is negotiable. (I'm counting method dispatch under 'lambda', of course..." Perl 6 thus will fully support the functional programming paradigm. This is great news for anyone seriously into computer science in general and artificial intelligence in particular.

It is just not the only paradigm it will support.

Heckno. Perl will always support contextual programming and imperative programming; object-oriented programming and functional programming are both getting huge boosts in Perl6, and there's talk of logical/declarative paradigm stuff slipping in e.g. from Prolog. Perl is fundamentally a multiparadigmatic language; you can use whichever paradigm is the best fit for the problem space of your program, and you can freely mix and match the paradigms at will, which I do. It's often convenient, for example, to have an object method accept as one of its arguments a coderef (e.g. to use as a callback), which can be a closure. Going the other way, a closure (or a set of related closures) can retain objects and use them to do stuff. I do this stuff today in Perl5. With Perl, you get the best parts of all paradigms. This will be even more true in Perl6, which is getting both real objects *and* continuations, among other things. The support for contextual programming is also being beefed up; a routine will be able to return an object that knows how to return one value in numeric context, another value in string context, and so on. (My personal favourite four-word quote from the Apocalypse series so far is "interesting values of undef". If you don't know why this is awesome, you do not yet fully grok the contextual programming paradigm.)

I can only agree wholeheartedly.

And yeah, Haskell is more innovative than pragmatic. The innovative things about Perl are three: context, the CPAN, and assimilation. Assimilation in this context means that the Perl dev team actively hunts down other languages and incorporates their nifty features into Perl.

Perl is a truly postmodern language in that regard. It has started as a duct tape of Internet and is inevitably becoming the most powerful Swiss Army chainsaw ever known to man.

There's been a lot of talk about Smalltalk and Haskell on perl6-language, for example. One could argue that another way to say this is, "Perl prefers to let other languages do its innovation for it." But it seems to be a pretty good model. None of the other languages seem to have all of the nifty features that Perl has together in one language.

Very true. For example, the Roles in Perl 6 are inspired by what is called Traits in this research paper presented on the European Conference on Object-Oriented Programming only months ago. It is quite an innovative idea and as far as I know it has been only implemented in Smalltalk as an experiment made for that very paper.

Context IMO is the most innovative thing about Perl. The CPAN also rocks.

It most definitely rocks indeed.

There are better ways. (PDF, sorry.) It's also interesting to see other papers and such that reference this paper.

Won't change the world, see Linux with non executable stack for x86:StackGuard

Until now, Intel-compatible processors have not been able to distinguish between sections of memory that contain data and those that contain program instructions. This has allowed hackers to insert malicious program instructions in sections of memory that are supposed to contain data only, and use buffer overflow to overwrite the "pointer" data that tells the processor which instruction to execute next. Hackers use this to force the computer to start executing their own code (see graphic).

The new AMD chips prevent this. They separate memory into instruction-only and data-only sections. If hackers attempt to execute code from the data section of memory, they will fail. Windows will then detect the attempt and close the application.

I've seen patches to Linux that provide a non-executable stack. There's also the mprotect(2) system call to change memory protection from user programs. And I believe OpenBSD has had a non-executable stack in the mainline for at least a couple releases.

So what they're advertising here seems to have already existed. If not, how are the things above possible?

Readers may be interested in an excellent review
of "New Kind of Science" from the journal Science
by Melanie Mitchell of University of Oregon and the
Santa Fe Institute. The review is both thorough and
balanced.

I chose his OGI Faculty page - you can choose your own

Your argument is no more credible than the curmudgeons who said that an electric piano sounds so unlike a real piano that it's a total waste, and nobody would ever perform a legitimate creative work using one.

Think "new tools at an artist's disposal", and "dawn of a new type of digital instrument" instead.

Yeah, except that as others have already pointed out, this is far from the first vocal synthesizer. It's at best an incremental improvement over the previous successes.

Besides VocalWriter, which has been around since 1997 (and hasn't been updated in that time, unfortunately), I'm not aware of any other easy-to-use singing synthesizers that are aimed at the average user or even average musician. But just about every speech synthesizer out there has been hacked to sing, e.g. Apple's Macintalk or Festival's
Flinger.

Yamaha's Vocaloid might sound better than those, but it's not about to fool anyone paying attention. Nor is it likely to be used as a musical instrument the way other synthesizers are. Why? Because there's no way to dynamically control what it says the way you can dynamically control a keyboard synthesizer or any other musical instrument, whether acoustic or electronic.

Thus the only way it could be used is in a recording studio, where it would have to be programmed carefully to "sing" a particular song.

Sorry about the rant. I love new technology, I just hate it when people claim things are the first ever or revolutionary when they're really just incremental improvements.

havent you heard this one?
it is amazing, look:

song10 Garrett Miller, "Like the stars", Oct 9, 2002, 3.95 MB Download

Old news. Go here: Flinger!!!. Or just go here if you want to hear some sample songs.

Old news. Go here: Flinger!!!. Or just go here if you want to hear some sample songs.

Personally, I think the best examples to download are "The Easy Way" (song 15) and "K'ai - Eyes swim" (song 16).

While no where near perfect, Flinger and the samples really show where things are heading - I have said it before, but this type stuff (perfected, of course), plus tech like machinima (once again, as it becomes better) are truely going to alter what we think of movies, acting, etc - virtual actors, virtual singers, virtual movies...

The paper, having been written in the 1970s, is full of archaic references to irrelevant technologies, such a memory control registers and segmentation hardware that is no longer used. However, the concepts still apply: the authors are discussing models of controlled interaction among users. In the early 1970s, that was with shared memory. In the 1980s, it was time share file systems. In the 21st century, it is networks of interacting computers, but the concepts still apply.

I taught security for several years. Saltzer and Schroeder was always the first topic covered. 28 years later, it is still a seminal work.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, Immunix Inc.

"Timing the Application of Security Patches for Optimal Uptime". Steve Beattie, Seth Arnold, Crispin Cowan, Perry Wagle, Chris Wright, and Adam Shostack. Presented at the USENIX 16th Systems Administration Conference (LISA 2002), Philadelphia, PA, December 2002. Postscript. or ugly PDF.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, Immunix Inc.

"Timing the Application of Security Patches for Optimal Uptime". Steve Beattie, Seth Arnold, Crispin Cowan, Perry Wagle, Chris Wright, and Adam Shostack. Presented at the USENIX 16th Systems Administration Conference (LISA 2002), Philadelphia, PA, December 2002. Postscript. or ugly PDF.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, Immunix Inc.

The computer industry's answer to the music industry should be to write better singing synthesizers. Don't steal their stuff, obsolete it.

Try this country and western MP3s generated with Festival Singer: "The Easy Way" No human performers were involved in the making of this recording. You put MIDI, lyrics, and a singer definition in, and out comes music.

The technology needs improvement. A lot of improvement. But it's clearly possible. This would be a good Open Source project.

The computer industry's answer to the music industry should be to write better singing synthesizers. Don't steal their stuff, obsolete it.

Try this country and western MP3s generated with Festival Singer: "The Easy Way" No human performers were involved in the making of this recording. You put MIDI, lyrics, and a singer definition in, and out comes music.

The technology needs improvement. A lot of improvement. But it's clearly possible. This would be a good Open Source project.

ensured that malicious worms could not be trusted and executed on the machine.

Just sign code with digital signatures and write the OS so it only executes code signed by the proper key(s). The plans to extend this to the processor itself doesn't require DRM either, just a proper signature. Be careful who is allowed to sign your binaries. If it's only one specific vendor and not you, prepare for some massive lock in.

I'm not sure how much extra security this will add to those who execute random binaries in the first place. If they get a box saying "this is M1cr0$0ft C0rp0rat1on's certificate, do you wish to add this into the trusted list?" they will probably click yes, and all those security features will be useless. I suppose if it's configured to only accept code from the "one true software vendor", then they won't have that problem, but they'll be screwing themselves in other ways.

As for buffer overflows, instead of checking signatures embedded into each instruction (or whatever the plan was), I'd put faith into more realistic reasearch anyway.

Or that the consumer could use to ensure that, say, a malicious government could not crack their documents.

Sounds like standard encryption to me.

You don't need DRM to do what you are saying. DRM is a system to control accessing and copying data no mater what the owner of the computer wants to do. With DRM your computer tells you what you should do with your files, instead of the other way around. DRM doesn't really help the end user, that is just FUD put out by the cartel.

Haskell.... oooh. Brings back memories. I did a lot of programming in Gofer (a dialect/implementation) of Haskell for an introductory CS courses.

It is a bit of a surprise that C++ won, because in previous years the winners were usually using Ocaml or Haskell (two "modern" functional languages with an advanced type system).

In previous years, the majority of the entries were not C or C++. See for instance the 2002 entry list. In fact the entry list is interesting in itself to see all the languages people use.

And it's true that there are more C++ programmers, but many of the smart ones probably experiment with other languages. On the other hand no one is programming Haskell now because that's the only thing they learned in school and they want a job somewhere.

the size is part of the issue (smaller particles have more surface area). the more important point is that iron in the evironment is already in an oxidized state, e.g., Fe(OH)2. And it is the oxidation/reduction reaction that is driving the detoxification of the compounds. Specifically, Fe0 goes to Fe2+ or Fe3+, giving up 2 electrons which then are used to reduce the compound. (reduction also has the benefit that it usually makes the compound more amenable for microorganisms to chew up naturally).

This site has some diagrams of chemical pathways. Also try googling "zero valent iron".

If you're seriously considering retraining your typing, I strongly recommend the Dvorak layout. I typed in QWERTY for a long time, but I never really noticed any of its problems until I took the time to learn Dvorak a couple summers ago. It took me about of constant Dvorak to get back to my old speeds, but it was well worth it.

If speed is your only goal, Dvorak will certainly be worthwhile, as you'll probably be able to type faster than you would with QWERTY, but in my experience the most noticable difference is just how much more comfortable Dvorak is. That's important for me, because I've had tendonitis in my hands (from too much fast typing with QWERTY...go figure). As I said before, I never noticed that QWERTY wasn't comfortable until I learned Dvorak. It really is much better. I'd say a regular old flat keyboard with Dvorak is quite a bit better than an 'ergonomic' keyboard using the same old crappy key layout.

It might seem to some of you like this keyboard layout is a solution in search of a problem. That may be so, but only in the same way that Ogg Vorbis is (i.e. it has some definite benefits, but most people don't think it matters, since its competitor already has such a huge user base). But my point is, if you're going to do something, in this case relearning how to type, you may as well do it the best you can.

Btw, some people have said to me "well, I would learn Dvorak, but then I'd get confused by a regular keyboard." JFYI, this is wrong. I can still use a QWERTY keyboard as well as I ever could. However, I don't really enjoy having to do it :-)

For those who have lost both hands, I think we need to look at new technology...

What an annoying assumption. John C. Dvorak didn't come up with this keyboard layout. It was devised by Drs. August Dvorak and William Dealey in the 1930's. You can read more here

...and quit spreading misinformation.

Firstly, a cyano group is simply a carbon atom bonded to a nitrogen atom with a triple bond. In the term cyanide, the ide simply identifies the CN as an ion. Hydrogen cyanide (HCN) is the colorless, poisonous gas that may, or may not smell like almonds. (Go ahead...smell it.)

The blue dye you are thinking about is called cyanine, which is simply the common name for 1,1-diisoamyl-4,4-cyanine iodide.

If you go here, you will see a structure of cyanine. The only nitrogen present in the chemical is firmly rooted in a benzine ring (called pyridine). It's not going anywhere, and there's certainly no cyanide.

Additionally, the other dye used in CDRs is called phthalocyanine. Structure here. As you can see, the molecule is circular and the CN groups are in rings and in bonds between the ring structures. No hydrogen cyanide will be evolved.

While this doesn't answer why CDRs smell like almonds after/while they are being burned (do they? I've never smelled that), it does cast away some of the misperceptions.

...and quit spreading misinformation.

Firstly, a cyano group is simply a carbon atom bonded to a nitrogen atom with a triple bond. In the term cyanide, the ide simply identifies the CN as an ion. Hydrogen cyanide (HCN) is the colorless, poisonous gas that may, or may not smell like almonds. (Go ahead...smell it.)

The blue dye you are thinking about is called cyanine, which is simply the common name for 1,1-diisoamyl-4,4-cyanine iodide.

If you go here, you will see a structure of cyanine. The only nitrogen present in the chemical is firmly rooted in a benzine ring (called pyridine). It's not going anywhere, and there's certainly no cyanide.

Additionally, the other dye used in CDRs is called phthalocyanine. Structure here. As you can see, the molecule is circular and the CN groups are in rings and in bonds between the ring structures. No hydrogen cyanide will be evolved.

While this doesn't answer why CDRs smell like almonds after/while they are being burned (do they? I've never smelled that), it does cast away some of the misperceptions.

And Oregon Graduate Institute's CSLU Toolkit extends Festival with an implementation of Sable: an XML format that lets you mark up text with arbitrary timing, pitch and volume envelopes.

An of course there's Dictionaraoke!

Main Entry: dictionaraoke Pronunciation: 'dik-sh&-"ner-A-O-ke Definition: Audio clips from online dictionaries sing the hits of yesterday and today. The fun of karaoke meets the word power of the dictionary.

-Don

We were hoping AT&T would do a better job than IBM at supporting their voice synthesizer. IBM pulled the Linux version of ViaVoice off the market without so much as a peep to their adoring fans on Slashdot, and wiped all mention of the Linux version from their web server. (Goggle isn't even allowed to cache it.) After IBM milked the slashdot linux fanboy publicity for all it was worth, they appearently didn't see any purpose in actually SUPPORTING the product -- so once their libraries stopped working against the latest Gnu/Linux libraries (happy birthday RMS!), they dropped their Linux voice synthesizer product like a hot potato instead of bothering to recompile it and issue an update.

So we hoped AT&T would show more comittment to the promises they made on their web site about their flagship voice synthesizer product, but...

Has anyone actually tried buying a single user copy of Natural Voices from AT&T? YOU CAN'T ANYMORE! They used to sell the synthesizer for workstations and voices for competitive prices (in the 100s of dollars range). So we bought a few voices to evaluate, and sent some simple technical questions into the email address they provided for support, never receiving a reply.

After several weeks they never answered any of our questions, but we decided to buy some more voices to evaluate anyway. But by then, AT&T had pulled the consumer single user version of Natural Voices off of the market (and it took weeks of phone tag to find that out because they don't give out "technical" information on the phone, and they never answer their email support address).

Now if you want to buy a Natural Voice from AT&T, you have to buy the server edition for tens of thousands of dollars. Had their support not absolutely sucked, it might have been worth us paying such a high price, but no way we'd ever consider going with AT&T, after they demonstrated such horrible unresponsive service.

Actually it's a good thing we didn't go with AT&T's voice synthesizer, because we need support for voice authoring tools, and AT&T is incompetent in that regard, since they refuse to give out technical information over the phone, and never answer their email. No support whatsoever. Zilch. Nada. Forget about it.

Fortunately we found some excellent open source software that works together (and whose authors are MUCH more responsive than IBM or AT&T): the Festival Speech Synthesis System, the FestVox voice authoring tools, the small fast Flite runtime speech engine, the Edinburgh Speech Tools, the CSLU speech tools, the OGI Festival tools, and the MBROLA Multilingual Speech Project. This is state of the art research software, where IBM and AT&T got their ideas.

The quality of the commercial voices comes more from throwing lots of time and money into the production process -- the commercial software is not any more advanced than the open source research projects -- in fact the research projects inspired the commercial products!

-A speech synthesizer user who's been jerked around by AT&T and IBM, and is now happy to have no other choice but to use excellent open source software.

Apple's TTS technology is pretty old... and it shows. I've been waiting for them to release voice upgrades since the original PowerPC macs came out, but after they axed their (basic) research section, the likelyhood of that happening decreased dramatically. The IBM approach is also pretty old, but the voice quality is slightly better, probably because there are more voice samples/higher quality.

No matter how good these phoneme-based techniques are, they're limited to the original timbre of the recorded speaker - you cannot synthesize a brand new voice (with on the fly inflections that were never recorded, etc.) with that TTS method. There has been research into modeled speech synthesis, where a mathematical model of lungs, windpipe, vocal cords, and mouth/tongue/lips, are manipulated in order to generate speech. Given the extreme amount of computing power today, you'd expect more people to use that type of TTS, since it's inherently more flexible. However, the biggest problem so far is nobody really has a good model for how all the various fleshy parts within the human speech apparatus interact together. Any open source people want to tackle this problem and start implementing some of these modeled synthesis speech algorithms?

Festival is great, especially with the OGI patches. I was completely blown away by Festival's quality compared to other opensource TTS engines, and OGI stuff makes stock Festival sound pathetic. Really great stuff, regrettably still not as good as IBM's or AT&T's stuff, but they have got a TTS that I can listen to hours without making my ears bleed.

Regrettably OGI patches are for personal/research use only, so Debian won't ship them...

1) What would you use to convert (english) sentences to speech samples (in real time, if possible perfomance-wise).

Others already mentioned Festival - and I wholeheartedly recommend it. (Under BSDish license.)

I especially recommend it with the OGI CSLU patch, even when it's not really open source (only for non-commercial use). Festival is great, it sounds nice even with the normal voice set... but this patch makes it sound really great.

I've used this program to read me some looong texts. (I don't want to do unnecessary large printouts, want to spare the batteries of my PDA, and I don't want to wreck my eyes completely with the monitor...) Strangely, the first text I fed through the OGIFestival was some H.P. Lovecraft story that featured artificial voice... =)

I wish they'd make the changes available under the same license as Festival so I could just apt-get the thing, now I need to do some patch tricks to get it up and running =/ But it's still fairly easy to build by following the instructions.