Slashdot Mirror

I personally would prefer it if computers were stong enough to calculate a photon hitting a material, reflecting its non-absorbed light into a "camera" object in game and taking the rendered picture and sending it to the monitor, thus creating a more realistic lighting effect, but we just aren't there yet.

Already been done. It's called ray tracing, and does exactly what you describe (except the other way around -- it traces light rays in reverse from the camera to the light source).

The trouble with ray tracing is that while it looks absolutely beautiful and stunningly realistic it's extremely impractical to do in real time. It can be done, but only with a supercomputer.

I've heard of some game engines being adapted to use ray tracing algorithms (here's a hacked up Quake 3 that apparently does so, but doesn't look any better than the original game). Here's an interesting interview with an Intel dude talking about it. In terms of actual usability though, there's no way you're going to actually play any of those games yet.

Yet.

There is a good overview of the topic on the authors page, at http://ertos.nicta.com.au/publications/papers/Klein_09.pdf. It specifically mentions "the other" big Project in this field, the VeriSoft project ( http://www.verisoft.de/ ). VeriSoft is broader in scope (covering the translation of programs down to machine code level, and also aiming to verify properties of user-space programs), but uses a simpler implementation Language lacking C-pointers, called "C0". C0 is extended with limited support for inline-assembly code for the compilation of the OS ( http://www-wjp.cs.uni-sb.de/publikationen/GHLP05.pdf ).

Textured Quads are used for leaves because of polygon count.

The whole point of realtime ray tracing is that it scales with O(log(n)) instead of O(n) when it comes to polygons. Which means that you can and should model each leaf as fully polygon. That is actually done in quite a few other examples, such as the sunflower scene or that Boeing model, where every last screw is modeled and yes, ray tracing can handle those just fine.

Now there is of course a cavet, this scalability only works for static scenes and things become quite a bit more problematic when stuff is animated, but never the less the whole point of 'going ray tracing' is because presumably polygon counts are slowly get high enough that ray tracing just outruns rasterization.

Also, do not count out some of the other European countries. Saarbrücken in Germany for instance has one of the strongest CS programs:

Besides the university, the two only Max-Planck-Institutes for CS (basic research oriented) are directly next to the CS department, as well as the German Research Center for Artificial Intelligence (DFKI, more application oriented research), as well as one of the five German Centers for BioInformatics.

Together these institutions operate one of the few Excellence Clusters in CS selected in a national scientific competition -- "Multimodal Computing and Interaction". Due to these many research institutes there is an abundance of different research topics available to choose from for a thesis or to work on as a research assistant during your studies.

All research and all teaching from the last year in the Bachelor program onwards has been in English for many years now due to the large number of international students and researchers on campus. Since end of last year, Saarland University together with the above research institutes now also offers a PhD program that you can enter directly with a good Bachelors degree.

Check it out at http://frweb.cs.uni-sb.de/ and http://frweb.cs.uni-sb.de/index.php?id=7

Also, do not count out some of the other European countries. Saarbrücken in Germany for instance has one of the strongest CS programs:

Besides the university, the two only Max-Planck-Institutes for CS (basic research oriented) are directly next to the CS department, as well as the German Research Center for Artificial Intelligence (DFKI, more application oriented research), as well as one of the five German Centers for BioInformatics.

Together these institutions operate one of the few Excellence Clusters in CS selected in a national scientific competition -- "Multimodal Computing and Interaction". Due to these many research institutes there is an abundance of different research topics available to choose from for a thesis or to work on as a research assistant during your studies.

All research and all teaching from the last year in the Bachelor program onwards has been in English for many years now due to the large number of international students and researchers on campus. Since end of last year, Saarland University together with the above research institutes now also offers a PhD program that you can enter directly with a good Bachelors degree.

Check it out at http://frweb.cs.uni-sb.de/ and http://frweb.cs.uni-sb.de/index.php?id=7

You wont be using any space parsing trees other than n-d tree, of course you can adjust the levels of an n-d tree in order to specify the rendering complexity. And yes, there is already hardware acceleration available for n-d tree, it was implemented in the famed ray tracing chip. http://graphics.cs.uni-sb.de/~woop/rpu/rpu.html

Read & Learn, And Legalize Marijuana

Since the article is often pulled from websites, the first article you should read and burn into your mind is this, Google for the title and archive a copy for yourself:

"A break-in to end all break-ins"
"In 1971, stolen FBI files exposed the government's domestic spying program"

It's an amazing story, and in 2008, how much has this expanded into every corner of our lives? The majority of Americans are brainwashed sheep consumers with a limp wet noodle for a brain, thrashing around with their Wii and Paris Hilton media like a fat dinoasaur in a tar pit. Stay informed, we have no privacy, encryption is good but useless with acoustic monitoring, reflections in the eye and objects in your environment, etc.! If it's electronic, there's always a loophole. You shine brighter with each electronic device you use, in many ways. Don't trust Hushmail or any web based mail service to keep anything of yours secure or to provide any reasonable degree of security. Secure your computer room and rig your computer to shut down if you use encryption like Truecrypt or other when your environment is entered by someone other than you or those you permit and trust (you shouldn't trust anyone, everyone has a price)

Compromising Reflections or How to Read LCD Monitors Around the Corner
http://www.infsec.cs.uni-sb.de/~unruh/publications/reflections.pdf [uni-sb.de]

And more:

http://www.eff.org/wp/detecting-packet-injection
http://en.wikipedia.org/wiki/Anonymous_remailer
http://cryptome.org/tempest-law.htm
http://seclab.uiuc.edu/pubs/LeMayT06.pdf
http://www-users.cs.umn.edu/~dfrankow/files/lam-etrics2006-security.pdf
http://cryptome.org/nsa-vaneck.htm
http://www.alobbs.com/macchanger
http://lifehacker.com/software/ssh/geek-to-live--encrypt-your-web-browsing-session-with-an-ssh-socks-proxy-237227.php
http://www.nononsenseselfdefense.com/five_stages.html
http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf
http://csrc.nist.gov/itsec/guidance_WinXP_Home.html
http://csrc.nist.gov/publications/nistpubs/800-84/SP800-84.pdf
http://all.net/books/document/harvard.html
http://www-128.ibm.com/developerworks/library/l-keyc.html
http://www-128.ibm.com/developerworks/library/l-keyc2/
http://www-128.ibm.com/developerworks/library/l-keyc3/
http://www.cl.cam.ac.uk/~mgk25/emsec/optical-faq.html
http://www.cs.washington.edu/education/courses/csep590/06wi/
http://www.wiley.com/legacy/compbooks/mcnamara/links.html
http://lifeha

Since the article is often pulled from websites, the first article you should read and burn into your mind is this, Google for the title and archive a copy for yourself:

"A break-in to end all break-ins"
"In 1971, stolen FBI files exposed the government's domestic spying program"

It's an amazing story, and in 2008, how much has this expanded into every corner of our lives? The majority of Americans are brainwashed sheep consumers with a limp wet noodle for a brain, thrashing around with their Wii and Paris Hilton media like a fat dinoasaur in a tar pit. Stay informed, we have no privacy, encryption is good but useless with acoustic monitoring, reflections in the eye and objects in your environment, etc.! If it's electronic, there's always a loophole. You shine brighter with each electronic device you use, in many ways. Don't trust Hushmail or any web based mail service to keep anything of yours secure or to provide any reasonable degree of security. Secure your computer room and rig your computer to shut down if you use encryption like Truecrypt or other when your environment is entered by someone other than you or those you permit and trust (you shouldn't trust anyone, everyone has a price)

Compromising Reflections or How to Read LCD Monitors Around the Corner
http://www.infsec.cs.uni-sb.de/~unruh/publications/reflections.pdf

And more:

http://www.eff.org/wp/detecting-packet-injection
http://en.wikipedia.org/wiki/Anonymous_remailer
http://cryptome.org/tempest-law.htm
http://seclab.uiuc.edu/pubs/LeMayT06.pdf
http://www-users.cs.umn.edu/~dfrankow/files/lam-etrics2006-security.pdf
http://cryptome.org/nsa-vaneck.htm
http://lifehacker.com/software/ssh/geek-to-live--encrypt-your-web-browsing-session-with-an-ssh-socks-proxy-237227.php
http://www.nononsenseselfdefense.com/five_stages.html
http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf
http://csrc.nist.gov/itsec/guidance_WinXP_Home.html
http://csrc.nist.gov/publications/nistpubs/800-84/SP800-84.pdf
http://all.net/books/document/harvard.html
http://www-128.ibm.com/developerworks/library/l-keyc.html
http://www-128.ibm.com/developerworks/library/l-keyc2/
http://www-128.ibm.com/developerworks/library/l-keyc3/
http://www.cl.cam.ac.uk/~mgk25/emsec/optical-faq.html
http://www.cs.washington.edu/education/courses/csep590/06wi/
http://www.wiley.com/legacy/compbooks/mcnamara/links.html
http://lifehacker.com/software/home-server/geek-to-live--set-up-a-personal-home-ssh-server-205090.php

Instead of a video card you would just need a faster cpu, which if we base off of moore's law won't be much longer.

If the video card makers had picked up on the RPU you could use your video card to get realistic high frame-rate raytraced games today.

Dr Slusallek is working at nVidia now, so who knows?

Here it goes again. Try to rasterize on CPU. It will be similarly slow. On the other hand with good hardware (like raytracing on gpu (PDF), or on cell processor (PDF), or just on PS3 cluster) is ALREADY possible. If you could make custom accelerator for raytracing (PDF) gamers and graphicians would love it.

Here it goes again. Try to rasterize on CPU. It will be similarly slow. On the other hand with good hardware (like raytracing on gpu (PDF), or on cell processor (PDF), or just on PS3 cluster) is ALREADY possible. If you could make custom accelerator for raytracing (PDF) gamers and graphicians would love it.

Here it goes again. Try to rasterize on CPU. It will be similarly slow. On the other hand with good hardware (like raytracing on gpu (PDF), or on cell processor (PDF), or just on PS3 cluster) is ALREADY possible. If you could make custom accelerator for raytracing (PDF) gamers and graphicians would love it.

SaarCOR was getting about 10 FPS for Quake3 with a minimal FPGA-based implementation of a hardware raytracer running at less than 100 MHz with a fraction of the gate budget of a modern GPU... in 2005. Raytracing is highly scalable - it's an "embarrassingly parallelizable" problem - so if nVidia is really working on raytracing hardware they could well be able to beat Intel to the punch.

That's a bit of a catch-22. I wonder what it will take to get nVidia interested in serious raytracing hardware, when it'll take serious raytracing hardware (I'm talking about something like SaarCOR fabbed in silicon in 2008, instead of an FPGA in 2005) to get game developers interested in it?

From: http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/

"runs faster with more computers (about 20 fps@36 GHz in 512x512 with 4xFSAA)"

Sure, it runs easily.

While I'm not going to go through them all to find out which one's the right one, John Carmack, at last year's Quakecon said something along the lines of traditional 3d graphics not being remotely close to dead. So I imagine that most developers are thinking along those lines. The current model is comfortable, well-supported, and there are likely still plenty of tricks to be found. Whether the last part is a good thing (since another post mentioned engine complexity) will have to be seen.

I'm curious as to where the ray-traced proof-of-concept games are. The only one I recall seeing was the Ray-traced Quake 3, and that hasn't exactly made a lot of progress. Of course, I'm neither a developer nor an artist, so I'm not really helping out.

Raytracing scales up far better than rasterization. Adding triangles to a raytraced scene has far less effect on it than to a rasterized scene, because you don't have to render anything that's not actually part of the scene... and you don't have to run what is effectively a separate rendering pass to eliminate parts of the scene to limit the hidden variables, and the processing for each collision is much simpler so you can fit thousands of dedicated raytracing processors in a hardware raytracer where the same transistor budget might support 8 or 12 rendering pipelines.

Look at what they were doing in 2005, with 1% of the gates, 1% of the memory bandwidth, and 15% of the core clock speed of today's GPUs: http://graphics.cs.uni-sb.de/SaarCOR/

Professer Philipp Slusallek of the University of Saarbruecken demonstrated a dedicated raytracer in 2005, using a 66 MHz Xilinx FPGA with about 6 million gates. The latest ATI and nVidia GPUs have 100 times as many transistors and run at 6-8 times the clock with hundreds of times the memory bandwidth. Raytracing is completely parallelizable, and scales up almost linearly with processors, so it's not at all unlikely that if those kinds of resources were applied to raytracing instead of vectorizing you'd be able to add a raytracer capable of rendering 60+ FPS at the level of detail of the very latest games into the transistor budget of the chips they're designing now without even noticing.

Here's a debate between Professer Slusallek and chief scientist David Kirk of nVidia: http://scarydevil.com/~peter/io/raytracing-vs-rasterization.html .

Here's the SIGGRAPH 2005 paper, on a prototype running at 66 MHz: http://www.cs.utah.edu/classes/cs7940-010-rajeev/sum06/papers/siggraph05.pdf

Here's their hardware page: http://graphics.cs.uni-sb.de/SaarCOR/

It really depends what you're trying to teach when. A few years ago I taught a data structures course (second out of a three course lower division sequence) in Java and thought it worked fairly well. About a year before that, I was a teaching assistant for a data structures class taught in C++.

Language choice affected the content of both courses quite a bit. In the Java course, students spent more time understanding how specific data structures worked and working on more interesting programming assignments. Students got to a working knowledge of Java fairly quickly after having only a semester of Scheme under their belt. In the C++ course (which followed a semester taught in ML), the students as a whole spent a lot more time learning about memory management along with the ins and outs of C++. Instruction on data structures was much more limited. Both sets of skills are valuable for practicing engineers, but I think it's fair to say that both the staff (myself and the teaching assistants) and the students enjoyed the class taught in Java more than the class taught in C++, probably because the interesting parts of such a class have to do with efficient data structures more than fighting with pointers and copy constructors.

Following the Java course, those students normally took an introductory hardware class. That course was taught in both assembly language, C and Verilog where learning pointers fit in better with the other material. Following the C++ course, I don't think those students saw much more C or C++ programming for a while (possibly not until upper division topic-specific course work) and instead went off to complete 4 more semesters of more theoretical Computer Science.

WRT games optimized for multiple cores, it is certainly possible, even though it requires a lot of rethinking. This presentation by Tim Sweeney of the Unreal fame touches on the topic.

The kind of hardware needed to run raytracing really fast is well understood, and it doesn't really look like today's GPUs or like intel's CPUs, though even today you can get better results if you take advantage of the GPU as well. If ATI or nVidia doesn't come up with a hardware raytracing GPU someone else will. It's a pity that Intel doesn't seem to be interested in working on that angle.

Here's an article I've dug out of the Wayback machine and cleaned up, Raytracing vs Rasterization. Phillip Slusallek's home page is here, and you can follow that to SaarCOR and OpenRT. They built a prototype RPU (R for raytracing) that at 66 MHz was comparable in performance to a 2.6 GHz P4. The video is pretty impressive, considering how slow the hardware is.

The kind of hardware needed to run raytracing really fast is well understood, and it doesn't really look like today's GPUs or like intel's CPUs, though even today you can get better results if you take advantage of the GPU as well. If ATI or nVidia doesn't come up with a hardware raytracing GPU someone else will. It's a pity that Intel doesn't seem to be interested in working on that angle.

Here's an article I've dug out of the Wayback machine and cleaned up, Raytracing vs Rasterization. Phillip Slusallek's home page is here, and you can follow that to SaarCOR and OpenRT. They built a prototype RPU (R for raytracing) that at 66 MHz was comparable in performance to a 2.6 GHz P4. The video is pretty impressive, considering how slow the hardware is.

Instead of coding open source projects, now we're coding projects to detect license violations.

No, we're not. Those guys are developing a method to detect license violations, and despite Slashdot's implications, I can't personally see any reference they've made in their project to GPL, open source or free software.

It's only a net loss for open source projects if they were otherwise going to be working on something more beneficial for open source, and they probably weren't. Usually people who develop open source software work on whatever the hell they feel like, because they're motivated by a variety of things other than seeing free software conquer closed source software.

Chicken and Egg problem.

If there aren't enough developers comfortable with those concepts, there won't be companies using them. If they aren't used, more jobs won't appear. If more jobs don't appear, nobody will learn them. Repeat loop.

I work with Java, and have worked with C++ in the past. I've been trying to pick up functional programming - mainly Haskell - and LISP on my own off and on for years. I'm not finding it easy, although that probably reflects more upon my intelligence and the programming habits I already possess than the learning curve. But even when I do get a good grasp on this stuff, where can I apply it?

For mainstream acceptance, "advanced" languages (define that how you will) require their killer app - and it isn't here yet. Two things give me some interest and hope, though. Functional languages for parallel programming, like game graphics: http://www.st.cs.uni-sb.de/edu/seminare/2005/advan ced-fp/docs/sweeny.pdf . Or, perhaps a useful Continuation Server could be written in a functional language or LISP.

It is if you are using the wrong tools. Check here to get Tim Sweeney's (unreal engine) thoughts on how he envisions programming his next game engine:

http://www.st.cs.uni-sb.de/edu/seminare/2005/advan ced-fp/docs/sweeny.pdf

(Hint: It involves switching from C++ to a Haskell like language)

Ray Processing Unit

Wait... He hooked up three PS3's to do real-time raytracing, and you _don't_ find it impressive?

Wait... He hooked up three PS3's to do real-time raytracing, and you _don't_ find it impressive?

Raytracing, by definition, is not hardware-accelerated. Of course the RSX isn't being used. Much more impressive is the cluster that, a few years ago, ran raytraced Quake 3.

http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/

Well, speaking of game development, I hope you'll excuse me if I will hold the opinion of that guy Tim Sweeney, you know, the one behind Unreal, higher than yours? 'Cause he seems to disagree with you pretty strongly on many things, threading issues among them. Tools (which languages are) are key to solving this problem, and a lot of it does come from academia, just as all things heavily used in the industry today (like OOP) did.

I find it somewhat troubling that in this article John Backus is remembered primarily for the genie that he tried to put back in the bottle.

FORTRAN was utilitarian and procedural and good at enabling engineers and scientists to get work done. However, the problem with FORTRAN is the imperative pattern of though that it imposed led us to tell the computer a precise sequence of steps to accomplish each task. It doesn't offer information on dependencies, simply a "go here, do that" sequence of instructions. Imperative programs are inherently hard to reason about in terms of global state and effects and as written tend to be subject to off-by-one errors.

Backus saw this in 1978! See http://http//www.stanford.edu/class/cs242/readings /backus.pdf.

His insight spawned a great deal of the interest in functional programming languages. It was been credited by Paul Hudak of Haskell fame http://portal.acm.org/citation.cfm?doid=72551.7255 4 (ACM membership required) (summarized here http://lambda-the-ultimate.org/classic/message4172 .html) and others as really helping to turn the tide and kept functional programming languages from being snuffed out.

A lot of people don't see the point, having never programmed in a functional programming language like Haskell or ML. However even those people see dozens of cores on the horizon and wonder how they are going to deal with the debugging issues associated with all of the threads to keep those processors churning.

Functional programming offers an alternative viewpoint that is arguably much better suited to handle multiple CPUs working on large datasets. A case for this was recently reiterated by Tim Sweeney of Epic Megagames fame who said "in a concurrent world, imperative is the wrong default!" http://www.st.cs.uni-sb.de/edu/seminare/2005/advan ced-fp/docs/sweeny.pdf.

Haskell has brought Software Transactional Memory (STM) into play offering an alternative approach to traditional mutexes and locks that is compositional in nature unlike locking models. This is an approach that isn't readily emulable in an imperative setting because of the lack of guarantees about side effects. http://research.microsoft.com/~simonpj/papers/stm/ index.htm.

These are solutions to real problems that we are experiencing today, not some academic sideshow, and they arise from a school of thought that he helped bring a great deal of attention to.

If you want to do something to remember Backus take the time to learn OCaml or Haskell or even just take the time to learn how to effectively use the map and fold functions in Perl, PHP or Ruby.

It is his willingness to turn his back on what was percieved as his greatest work when confronted with a better idea for which I will remember him and I am a better programmer today for having learned what I could from his ideas.

Can You Imagine a Beowulf Cluster of These?

The RPU is a fully programmable ray tracing hardware architecture, with support for programmable material, geometry and lighting. The RPU combines the efficiency of GPUs with the advantages of ray tracing. The instruction set of the RPU is GPU like, which is optimal for shading purposes. In addition the RPU supports fast ray traversal through an k-D tree using a dedicated hardware unit and recursive function calls, usefull for recursive ray tracing. To increase efficiency always 4 rays are handled in a packet and multi-threading allows for high utilization of the hardware units.
 
A working prototype of this hardware architecture has been developed based on FPGA technology. The ray tracing performance of the FPGA prototype running at 66 MHz is comparable to the OpenRT ray tracing performance of a Pentium 4 clocked at 2.6 GHz, despite the available memory bandwith to our RPU prototype is only about 350 MB/s. These numbers show the efficiency of the design, and one might estimate the performance degrees reachable with todays high end ASIC technology. High end graphics cards from NVIDIA provide 23 times more programmable floating point performance and 100 times more memory bandwidth as our prototype. The prototype can be parallelized to several FPGAs, each holding a copy of the scene. A setup with two FPGAs delivering twice the performance of a single FPGA is running in our lab. Scalability to up to 4 FPGA has been tested.

I would find it cool if AMD/ATI decided to go for the hardware raytracing route.
Some impressive results (http://graphics.cs.uni-sb.de/~woop/rpu/rpu.html) have been achieved with a simple FPGA at 66 MHz. Imagine a dedicated (or several) ASIC(s) at much greater speed.
Sure, you wouldn't expect as high level graphics as todays top-end cards immediately, but I think it is the way to go forward.

Is anyone working on a Ray-Tracing evuivalent of OpenGL?

Actually, yes: OpenRT. Some games which uses it can be found here, although nothing you can try at home unfortunately, only videos available for download.

It's really playable on the hardware they use in the University of Saarbrücken. One of the people involved with this went to school with my sister. I could ask him if there still is work being done on it.
However, what I know is: They made a prototype of a graphics card (SaarCOR) with raytracing hardware instead of a rasterizer (http://graphics.cs.uni-sb.de/SaarCOR/).

The RT-Quake 3 ran on a cluster of several (20 I think) computers, that's why a virtual Intel CPU of 36 GHz is shown.

So, when you have over 20 computers left for a playable Q3 Raytracing you might contact them and you too will be able to play.

Just found that game using raytracing - Quake 3: Raytraced.
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/

Rumors are there's a q4 version on the way.

There are already ray traced games. :O

http://graphics.cs.uni-sb.de/~morfiel/oasen/

They managed to get reasonable frame rates with a FPGA board, which is rather slow compared to modern GPUs. A lot of special effects like diffraction are included and don't kill the framerate. This might be a very interesting alternative to more texels/s and shaders.
It just looks good as well: http://graphics.cs.uni-sb.de/~woop/rpu/rpu.html

Found this link a while ago: http://graphics.cs.uni-sb.de/SaarCOR/

Methinks it would be pretty cool when there's a 'graphics' card that could do standard raster-based graphics, raytracing and physics. Most of the calculations are the same anyway, so a general purpose processor that is very good in floating-point vector calculations would be necessary. The API's would be mostly implemented in the driver (OpenGL, OpenRT, etc.)

Just found that game using raytracing - Quake 3: Raytraced.
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/

Rumors are there's a q4 version on the way.

There are already ray traced games. :O

http://graphics.cs.uni-sb.de/~morfiel/oasen/

You're right - functional programming, especially referential transparency and lazy evaluation (a la Haskell, etc.) allow great things in the way of parallel execution. See Tim Sweeney's presentation "The Next Mainstream Programming Language, a Game Developer's Perspective", http://www.st.cs.uni-sb.de/edu/seminare/2005/advan ced-fp/docs/sweeny.pdf

Fully automatic grading breaks down quite badly if there is a possibility of students making small mistakes that cause large amounts of tests to fail (or, conversely, big mistakes that cause few tests to fail); in this sort of scenario (and concurrent programming is one of them), you really want a human to assign the final grade by identifying the underlying mistake/bug instead of the symptom/failure. However, having automated tests that are designed to expose common problems is a good thing.

Of course, if you like giving out failing grades for messing up input or output formats while letting blatant errors in mutual exclusion pass by with minimal impact, you can do automated grading based directly on test results. Trying to make the computer deduce the actual mistake from the test results, on the other hand, can be quite painful (this is essentially automated debugging, which may be possible to some extent; see Andreas Zeller's work on Delta Debugging).

Not right now, but games are actually a very good candidate for new language adoption.

What other products go through a basically complete rewrite of the code base every few years? Also games compete largely on performance, whereas say word processors do not.
So in the future, let's say the next generation of consoles after Xbox360/PS3, games will need to take advantage of maybe 100 hardware threads simultaneously. I don't think anyone is delusional enough to think that it's possible to do that productively using C++. So to get maximum performance in the future game developers need to use a high level language suited to concurrency and parallellism (this doesn't imply that it shouldn't be nateively compiled - look at Haskell for instance). So ironically a "slow" language will be better for performance because the "fast" languages aren't capable of exposing the available parallelism in a program to the hardware.

See this presentation by Tim Sweeney (founder of Epic) where he explains why C/C++ just isn't very good for games:
http://www.st.cs.uni-sb.de/edu/seminare/2005/advan ced-fp/docs/sweeny.pdf

I guess now I'll start the search for the next beautiful language that can pull itself up above the fray--above the garbage that is the syntax of Ruby, C++, VB and all these other pretenders.

You meant that in jest... but this is the kind of parallelization required to run such things as Ray-traced applications or games in realtime (or at least jerky realtime - which is much better than several seconds watching each frame draw).

Refer to:
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/

and for a screenshot with multiple reflection:
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/ screenshots/mutlipleReflectiveSpheres.JPG

You meant that in jest... but this is the kind of parallelization required to run such things as Ray-traced applications or games in realtime (or at least jerky realtime - which is much better than several seconds watching each frame draw).

Refer to:
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/

and for a screenshot with multiple reflection:
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/ screenshots/mutlipleReflectiveSpheres.JPG

1. take one of the most unsafe, slowest-to-compile, pitfall-ish, unspecified languages in existence (ok, I might be exagerating on the "unspecified" part)
2. add even more #pragmas and other half-specified annotations which are going to change the result of a program near invisibly
3. don't provide a debugger
4. require even more interactions between the programmer and the profiler, just to understand what's going on with his code
5. add unguaranteed and slow static analysis
6. ...
7. lots of money ?

• Lisp, Scheme, Dylan, ... -- maximize code reuse and programmer's ability to customize the language, automatic garbage-collection
• ML, Ocaml, Haskell, ... -- remove all hidden dependencies, give more power to the compiler, make code easier to maintain, check statically for errors
• Java, C#, VB, Objective-C ... -- remove pitfalls, make programming easier to understand, include a little bit of everything
• Python, Ruby, JavaScript -- maximize programming speed, make code readable, make writing prototypes a breeze ...
• Erlang, JoCaml, Mozart, Acute -- write distributed code (almost) automatically, without hidden dependencies, with code migration
• Fortress -- high-performance low-level computing, with distribution
• SQL, K, Q -- restrict the field of application, remove most of the errors in existence
• and probably plenty of others I can't think of at the moment.

• a macro system which was already obsolete when it was invented
• slow compilers
• no modules or any reasonable manner of modularizing code
• neither static guarantees nor dynamic introspection
• no static introspection
• an unsafe language in which very little can be checked automatically
• mostly-untyped programming (not to be confused with dynamically-typed programming)
• about a thousand different incompatible manners of doing just about everything, starting with character strings
• manual garbage-collection (yes, I know about the Boehm garbage-collector -- but I also know about it's limits, such as threads)
• a false sense of safety with respect to portability
• extreme verbosity of programs.

So, now, we hear that IBM is trying to maintain C alive, under perfusion. IBM, please stop. Let granddaddy rest in peace. He had his time of glory, but now, he deserves that rest.

Oh, and just for the record. I program in C/C++ quite often as an open-source developer and my field is distributed computing. But I try to keep these subjects as far away from each other as I can.
(well, venting off feels good)

In contrast to skype (and openwengo?) kphone f.e. uses standard codecs (G711u, GSM, iLBC for audio and H261, H263 for video) for communication. I'm using the provider voiptalk.org (website is currently down) to get connections to/from landline-phones (using GSM-codec) as well.

Here is a document on how to install it.

But maybe the Openwengo developers are planning to do this anyway (I couldn't see this from the project's website though).

Many scientists were talking about and forseeing computers, the media just wasn't paying attention.

As We May Think, Norbert Weiner.

"Soviet Cybernetics" was a vision of a Soviet Internet and the "New Soviet Man" was envisioned to be a Cyborg. It scared the hell out of the Americans, and inspired DARPA.