Healthy competition? What healthy competition? It certainly won't be in the form of Micro-Soft's rush-job tablets.

In a nutshell, portability.

Well written gcc/g++ code will compile using gcc/g++ on many, many platforms and operating systems with no changes to the source. The other compilers mentioned, besides being non-free in various ways, won't do that. For me, the portability angle is a whole lot more important than the freedom angle.

that video ... what?

... this is very old news.

Apple is lock-in. Adobe is lock-in. You have a choice of how you'll be locked in. What's the point of developing software?

Me: UGPSJ0722-05.
UGPSJ0722-05: We meet again.
Me: It's been a long time.

The age-old Rules of Optimization:

1. Don't.
2. (For experts only) Don't yet.

A bit off topic, but since I'm seeing posts about OpenCL and portability...

OpenCL will indeed get you portability between processors, however OpenCL does not make any guarantees about how well that portable code will run. In the end, to get optimum performance you still have to code to the particular architecture on which that your code is going to run. For example, performance on Nvidia chips is extremely sensitive to memory access patterns. You could write OpenCL code that runs very well on Nvidia chips, but runs poorly on a different architecture.

Not saying that portability isn't a good thing, but a lot of people seem to be thinking that OpenCL will solve all your portability problems. It won't. It only will let code run on multiple architectures. You'll still have to more or less hand optimize to the architecture.

From my own experience with these kinds of systems, it's very likely that, during telemetering, the stream can become corrupted to a point where the ECC will fail. So then the question becomes, what do you do when the ECC doesn't work (making it impossible to decrypt)? Drop the frame? Retransmit? Neither of these choices are very good. The "easiest" thing to do is just send unencrypted and handle the funkified data payloads as the come in.

More importantly, these video stream are sent over comms links that have a finite bandwidth. Encryption and ECC are essentially "anti-compression" techniques that ultimately require much wider comms bandwidth for the same data payload throughput (e.g. frame rate). It's possible that a trade off was made preferring higher data throughput over a relatively narrow comms pipe -- at the expense of security of the stream.

It's a kind of Sophie's Choice tradeoff, but that's what Engineering is all about.

http://bishophill.squarespace.com/blog/2009/11/20/climate-cuttings-33.html Nice summarized digest of the CRU et.al emails. Doesn't look good for the Hockey Team. Not good at all.

Here's the particular one you're after: http://www.eastangliaemails.com/emails.php?eid=490&filename=1107454306.txt

... And, can we PLEASE have a thread-safe STL? Please, please, please?

Finally, some sanity in language design. syscall will no doubt be used only occasionally, but it's there if you need it and you know what you're doing.

Thing is, though: They're right.

If you haven't read "Good Calories, Bad Calories" by Gary Taubes, you should. This book outlines how 40 years of bad science and personality cults in nutrition research has lead to a serious misunderstanding of the causes of heart disease and obesity.

At the very least you should read his eye-opening NY Times article, which pre-dated the book by a couple of years.

Keeping in mind that all back-lit displays suck, can we please have a reader that doesn't suck?

I mean other than the Kindle.

I think I'd rather hammer #10 nails into my skull than do another VxWorks project.