I think drivers of autonomous cars should have licenses. Even if they aren't directly driving, they're still responsible for keeping the vehicle in proper functioning condition.

I do, however, think there should be reasonable exceptions for people who can't get a regular driver's license because of a physical disability such as bad eyesight.

What you have described is called photon mapping. I think there is some support for photon mapping in at least some version of povray (I'm not sure if it ever made it in to an official release), but in any case it's an optional feature. It is more accurate to refer to povray as a ray-tracer. In ray-tracing, you send out rays from the camera position and test them for intersection against objects in the scene. These rays can in turn spawn additional rays (for reflection and refraction), and at each hit location you can cast a ray back to each light source to test whether that light is occluded by an object.

There actually are some pretty good game engines that do ray tracing. I'd recommend looking into Arauna and Brigade. (Last time I tried them they were a bit sluggish and ran at a low resolution, but that was about 5 years ago so things have probably gotten better.)

David Miranda, the partner of the Guardian's Glenn Greenwald, was detained while transporting encrypted data on the Snowden affair from Berlin;

That's quite an allegation. Do we have any reason to believe that Miranda was transporting anything of the kind?

Road powered electric vehicles are awesome, I'm glad to see someone doing it, but I'm a little worried about safety and efficiency with the inductive charging technology. I certainly wouldn't want to be right on top of a 20khz rf transmitter that's pumping out tens of kilowatts. I don't remember the permissible exposure limits off the top of my head, but this sounds like it would be way above what's considered acceptable for HAM radio. Is there some way to keep that RF energy from spilling all over the place? How much of that energy actually makes it to the car, and how much is lost to RF, heat, noise, etc..?

Wrong, this still requires amplifiers every 100km, just like today.

They don't explicitly say that there were no repeaters for this particular test, but that is strongly implied. (Sloppy reporting.) However, they do compare it to a test done recently over 10,000km with no repeaters:

Then in January 2012 a Japanese team working out of NEC successfully transmitted 4Tbps over a single “ultra-long haul” (10,000km) fibre optic cable (no repeaters) by making use of WDM just like Alcatel-Lucent (here). Lest we not forget all the other developments, such as the successful UK test of a new type of hollow fibre optic cable that earlier this year delivered speeds of 73.7 Tbps (here).

Alcatel-Lucent might have just set a new record and one that it is arguably most notable for its distance but such records are clearly made to be broken. GCHQ will probably get a headache if they want to “tap” (spy) on the next generation of transoceanic cables.

I had no idea that those kinds of distances were possible without repeaters. This is, indeed, big news.

What do you think Wikipedia is going to need to do to keep up with content maintenance in the long term? Is editor decline inevitable, and thus the focus should be on making vandalism harder, or do you think current trends can be reversed with the right tools or policy?

There actually is a Haskell FPS. State manipulation is a little awkward in some ways, in part because there isn't a universally agreed-on way to do it, but the tools are getting better. With lenses on top of a State monad, things start to look pretty similar to an imperative language, except that you get the benefits of functional programming as well (for instance, error handling is a lot easier when you don't have to back out a bunch of changes because you still have your original state lying around).

Return a list from a function. Sure, you can legally do it, there's nothing in the language inherently stopping you, but experienced C programmers will avoid returning a list at all costs, because suddenly you have to care about whether the caller frees the list properly, and what if the things in the list are used elsewhere and we need to do reference counting etc.. etc... I've worked on a C codebase that was a couple hundred thousand lines of code, and I can't think of anywhere that we ever returned a list from a function. I can't think of any Haskell program more sophisticated than "hello world" that I didn't use "map" and other list functions all the time.

Ultimately, the cost of manual memory allocation isn't just the extra work you have to do to make sure you aren't leaking or corrupting memory, it's the algorithms you won't allow yourself to even consider because the memory management would just be too hard.

I'm not saying C doesn't have it's place, I'm just saying that there are software engineering costs associated with using C as opposed to a higher-level language.

Given that this thread mentioned using an RTG (a Radioisotope Thermal Generator, which is just an electrical generator that operates off of waste heat produced by a radioactive material decaying), it seems like the solution here is pretty obvious, even if it might be a painfully slow.

That's hard to do without the ethernet port, but it's been done with the model B.

Guitar and piano are usually both equal tempered, though pianos typically have a slightly stretched octave to compensate for the strings having harmonics that aren't exact integer multiples of the fundamental. (In other words, it's done to compensate for the physical limitations of the instrument, rather than to compensate for the mathematical limitations of the tuning system.)

One can, of course, tune a piano to just intonation. (My piano is currently tuned that way, partly because I wanted to hear what it would sound like, and partly because, with an oscilloscope, it's a lot easier to tune to just intonation than 12TET and I'm too stingy to hire a tuner to do it the "right" way.)

It is possible to make a just intonation guitar as well, though it's not usually done. Here is one of mine that I made a couple years ago. I just finished putting together a just intonation walnut through-neck electric bass with a 2-octave fingerboard a couple days ago.

There's something that bothers me about this story. Linus's G+ account is basically a personal blog. It isn't tied directly to Linux or the open source community in any way other than that the author is Linus Torvalds and his posts occasionally mention Linux or open source software. If we were to judge everything Linus says about anything in public based on the criteria of how it "reflects on the open source community", then doesn't that essentially mean that we don't think Linus has a right to express his own opinions in public?

If you don't like those opinions, or find them offensive, that's fine. But let's not always assume that any famous person expressing an opinion must always be representing something bigger than him or her own self.

I second the functional language suggestion. For awhile, the only two languages I used regularly were C and (to a lesser extent) Perl, and felt a general sense of dissatisfaction with programming -- it wasn't clear at the time if it was the tools, or just me. I happened to take a pretty hard class on game tree search, and realized I needed to learn a more expressive language fast if I was going to keep up with the assignments. I picked Ocaml, and within a few weeks I was more productive (for the kinds of problems that were assigned as homework in this class) than I would have been in C or Perl. I stuck with it and eventually used Ocaml for some bigger projects that I did on my own. After a few years of Ocaml, I switched to Haskell because I wanted better parallelism support. By then, I'd become sufficiently accustomed to functional idioms that Haskell didn't scare me, and I've been using Haskell ever since. Not at my current job though, unfortunately... that's still C, but I rest easier knowing that there is a more pleasant way to get stuff done and I don't necessarily have to write C the rest of my life.