*everybody* has a cell phone there - preferably from Nokia in the Oulu area

You know, that was what told me that Nokia was doomed. Three years ago, I was staying at the Radisson in Espoo, and I (a non Finn) was the only one there with a Nokia (E71, IIRC), about a couple of km from their world HQ. In the Espoo based company that I was visiting, the standard phone was an iPhone. My Nokia lasted until the end of that year when I went Android!

Apollo 13, the movie had a lot of footage filmed on the so-called "vomit comet", a zero gravity training plane that flies on a special trajectory. I would guess that it was green screened.

A good point. Some appartment buildings have communal garages underneath them and power can be available there.

the "International Linear Collider requires more than 1 TeV beams

Is this because the LHC is wasting a lot of power with synchrotron radiation? The LHC is already running at about 3.5TeV/beam giving 7TeV collisions. With the upgrade, they should be able to manage 7TeV/beam.

it's not the moving parts in the engine that cause most of the maintenance costs, it's all the rest of them, like suspension, steering, brakes, air compressors,

All EVs will require most of the above (but remember, the only air compressor is on the a/c). There is no clutch and no conventional auto-transmission. Braking though is partly friction but is also electric (regenerative), this should lengthen the life considerably.

I know what you are getting at but internal combustion engines certainly do need additional maintenance. The issue is at the moment is that we know very little about the total lifespan. I know someone who bought a Tesla Roadster and is very happy with it. It has received no unplanned maintenance but then it is just a couple of years old. No modern car should have a problem that early. Five or ten years on may be another story.

One of the interesting tendancies is that to balance the weight of the batteries, many manufacturers have chosen much more modern materials, so we see aluminium in the Tesla and carbon fibre in say the BMW i3/8. This costs more, but has long term benefits.

I would agree that the battery is and remains the most critical element and this has to be accounted for in any TCO calculation. Again, we do lack information, particularly on the realistic trade in possibilities for a battery. For example, whether it can be reconditioned rather than completely remanufactured? These questions will be answered over the next few years and lets be honest, not everyone is going to rush out and get an all electric vehicle and for many, it isn't even that practical. For all the indentations being made particularly by Tesla, there are many more ICE vehicles. Over time, though there will be further cost reductions and more people may decide to switch.

As more EVs are on the road, there will be an increasing need for a dealer network to provide the necessary downstream support. At the moment, we are talking niche, so to require dealers when there is such a low volume seems impractical.

Quite simply, a Tesla (or any all electric car) has significantly less moving parts. Faults will occur, but susbstantially less often than with an ICE. Some of those faults though will require very specialist knowledge to fix though.

Yes, two recent British Noble prize winners (Graphene) are actually Russian and spent most of their time there.

In a commercial closed source environment, there are still likely to be far fewer eyes looking at the code. Very few people look deliberately outside their area unless a major problem comes to light (no budget to) and other teams don't like defects being raised against them from outside.

You also can't perform a proper review with a bunch of hobbyist coders, you need highly-trained experts. Every single line of code needs to be checked, double checked, and triple checked against every single other line in the code to make sure that there isn't anything that could possibly compromise the security of the system. These failures are always subtle and usually unintentional.

If you are writing for some critical applications like a flight control computer then it is clear that there will many formal reviews. However, in most systems, commercial users do not have that luxury. Everything tends to be time boxed. With the status of Linux not only as a usable O/S but also as a teaching tool, new people are studying the kernel all the time (and performing exercises like "how random is the RNG"). However "hobbyist" it may seem, and especially with the methods used by the kernel maintainers, there is probably more scrutiny than with commercial systems.

With just a radar linked cruise-control/collision avoidance system you only know about what the guy immediately in front of you is doing. What you need to know is what the guys in front of him are doing. This is why you want the signal passed through immediately from the lead car so all trailing cars start to reduce speed or brake where necessary like a train - so no human reaction time involved.

A first part would be to simply relay the brake signal backwards. This is not a simple problem because the lead vehicle in the offside lane should not affect a vehicle in the nearside lane other than as a FYI. If the lead car is changing lane or turning, they should surrender their role and the next vehicle takes over. However, this could allow, for a small investment to be able to pass the event of the lead car braking backwards so that it could, be indicated on the dash of each trailing vehicle.

A more complex system would actually apply speed control via throttle or braking based on the info from the lead vehicle, all the way through the trailing vehicles.

This is the point. Making big curved mirrors is expensive, so they use lots of straight pieces of glass to make a nice downwards focussing concave effect. So you take a new building with refelctive film on the windows, and you have a pretty good concentrator. Luckily not a very good one because there is a structure in Spain that gets to 4 figure temperatures.

The idea is automatic convoying. It is very unlikely that the car in front of you comes to a dead halt. The issue is that you do not know what is happening in front of that car. People are studying the idea that the leading car will relay information to the trailing cars so that the instant it begins to brake, so do all other cars in the virtual convoy. Such systems can also allow for all kinds of interactions, so a car on the nearside lane on a two lane road can be permitted to pull out to overtake by adjusting the speed of the trailing cars to make a gap and maintain separation.

One of the biggest issues is good intervehicle communications which also means that they cannot send misleading information that could lead to crashes.

Alexander needs to go, yesterday. He's more inept than Ballmer.

No serving general should ever be given so much power over a civilian agency and the population as a whole. Soldiers are very good at military campaigns but they are not so good at managing by consent and they are used to protecting the state and projecting its will. To work effectively, a general has to stop being a general outside the military, especially when turning their agency against civilians. Instead, the better model is that of "policeman", to serve the people over the state.

The method posted requires, access to the car interior to get at the OBD2 port. Hopefully you would have set off the ultrasonic alarm before then.

The device shown is way overpriced, essentially you just need a custom OBD2 device. Just a bit of googling and I managed to find one for a fraction of the price.

I think these guys are able to breakin without access to the OBD2 port, probably by interception of the RFID signals.

For hardware I started with an 11/40, and then went through the range down and up. I got used to pulling and shuffling cards and even removing the wire-wrapped NPR jumper but the software was fun. For the software , we started with a monstrosity called DOS/BATCH, I went on to RSX-11M, RSX-11S (a paired down version of 11M for hard realtime), RT-11 and RSTS/E and ended up on RSX-11M-plus. The latter was a really cool multiprocessing capable O/S. The best thing is that for M and M-plus, they had to give you the kernel source so you could configure it (which was down to conditional assembly and lots of macros).

I was writing drivers and having fun. MACRO-11 was great. I used a heavily modded set of macros to provide a C like structure called SMAC and was using home-brewed structured exception handling by burying stuff in the stack frame, a bit like a VAX does. This gave me the ability to unwind quite gracefully. At one stage I managed to get hold of a copy of Unix, but we were commercial and it was hideously expensive at the time so couldn't use it for anything. The point being that a PDP-11 with EIS/CIS had a really nice instruction set and was easy to hold in the mind so I am fairly certain that a competent assembler programmer could write better code than most of the compilers. The instruction set was truly orthogonal so that all addressing modes worked whether it was real memory or registers.