Not only that, but the image in the linked article shows something that looks decidedly like a standard extension cord plugged into the car (possibly, at a stretch, a 440v 3-phase supply). I'm not an EE, but I would imagine that for a cable that thin to be charging the car as quickly as they claim, the voltage would have to be pretty high - high enough to require things like exotic looking connectors and insulation around the charge point.

Also, as other posters have pointed out, a car moving @ 55MPH will consume far more than 2kW of power - it's unlikely that would cover rolling resistance, let alone aerodynamic drag etc. Something has to be powering the accessories too (power steering pump, lights?, dashboard, control circuitry etc).

I get the feeling that someone got punk'd.

It may be true that nothing useful in the real-world changes in 126 microseconds... however...

The way I look at it is that 'the market' is like a big complicated electronic system which contains a lot of complex feedback loops (some of them more stable than others). Imagine tweaking a random knob on such an electronic circuit and watching the effects of that tweak ripple through the circuit until it (hopefully) reaches a steady state again.

Increasing the latency causes changes to ripple through the system in a way that a steady state may take a long time to occur (or may never occur) as market participants end up making decisions based on old data. Sure, it may be easier for a human to observe what's happening but it doesn't necessarily mean things will be any more stable.

Lowering the latency to trade is equivalent to increasing the bandwidth of the components in the system, helping the steady state to be reached sooner. Yes, in the worst case, this might allow the feedback loops to veer outside the stable region within the blink of an eye, but that's why there are things like safety cut-offs.

I agree that at first glance it seems that 126 microseconds should be fast enough for anyone, but when you consider the sheer volume of market participants, the mind-boggling number of trades that are executed, and the complex network of relationships between different stocks, I think that having a market that can reach a steady state as quickly as possible under various "tweaks" of input parameters is probably, on the balance, a good thing.

The simulation argument paper proposes a philosophical argument about this sort of thing. The consequences that they come up with are pretty interesting. Of course, there are arguments against such a configuration of the universe as well...

Bingo! My thoughts exactly. I spent ages a while ago looking for a "server" component to download and install locally, and unfortunately it just didn't seem to exist at the time, so I gave up on it.

There's no way any reasonable company is going to willfully provide another party (even if that party is supposedly "trustworthy" like google) with access to all of their R&D notes and conversations etc.

If it were able to be firewalled off inside a corporate network, and used, like you say, as a sharepoint killer then I think it would have much more of a chance of success, but then I guess google's ability to monetise the service would disappear.

Oh well, if we're lucky we might see others take the ball and run with it - It appears that a few servers might actually be available (PyGoWave, StreamWork, Novell Pulse), so things must have moved on since I first looked, or maybe I didn't look hard enough the first time around.

I think I'd quite like to see it succeed. I think that given a bit more time, and more people who can see where it might really fit in and be useful, it might still have a chance.

It sounds like the job advertised just isn't for you In fact, it seems to me, with all the bitterness in your post, that you're probably not particularly well suited to software development as a profession.

If you want to really succeed as a developer, the best piece of advice I can give you is that you had better be prepared to be continuously learning. Get yourself a subscription to Safari Books, join the ACM or the IEEE, read blogs, download and listen to/watch pod-casts, subscribe to interesting people's twitter accounts, immerse yourself in what's happening in the free software world, try to learn a new language every year if you can.

If you're not prepared to keep up with what's going on, the sad fact is that you're probably not making good decisions for the company that you're working for. Sure you might be able to write basic run-of-the-mill widget-shifting code, but chances are you're not someone who's ever going to be writing really good, clean, maintainable, useful code. Job ads like the one above are trying to find people who are genuinely interested in keeping themselves up-to-date with technology, and who have a real passion for the field.

I'm sorry if I've offended you, but I've met a lot of people in the industry who got into it for the wrong reasons and subsequently struggle, and I'm afraid it sounds like you're one of them.

I know it's bad form replying to your own post, but I just read the article (sorry, I know I'll need to hand in my slashdot license now), and it seems that you were right; the idea is to actually warm the crops using the death ray. Apparently it's able to target the crops without heating the the air around them (as per a normal household microwave oven), hence preventing the frost from damaging them. Weird.

Oh well, I've never been a particularly motivated cook, so being able to buy freshly baked vegetables straight from the crop might be of benefit :)

I'm not sure whether you were joking or not, but I think it's probably more about not letting the frost settle in the first place. ie. disturbing the atmosphere enough that the water doesn't condense out/get a chance to fall on, and freeze on the crop, rather than trying to specifically target frost and melt it after the fact without cooking the crop too.

Ah, but what if they had been sniffing "encrypted" packets too? In the hope that one day their computing power would be sufficient to decrypt them. Or if they had been sniffing DECT packets, knowing that the encryption is weak?

What security measures are "good enough" that they convey an expectation of privacy?

That quote reminds me of something called the Dunning-Kruger effect, whereby people have no idea how ignorant/closed-minded they are, until they are educated. Sadly, ignorant people have a tendency to think they already know everything that they need to know.

The original paper is an interesting read if you've got the time.

It's also usual for cars these days to come equipped with ABS. ABS has the job of preventing the wheels from locking up while stopping, which may be going against the driver's wishes in these cases.

Also, while most cars should have brakes that can overpower the engine, that may not be the case if they are applied progressively and allowed to heat up excessively before they are fully applied. It can take surprisingly little work to trigger a case of brake fade in a road car, and it doesn't seem unreasonable that this could happen in the circumstances described.

I just read a little bit about the CAN protocol and it seems incredibly unlikely that there would be any way to accidentally inject a message onto the bus from a (random) noise source. I'm feeling a bit better about that now, but while digging for info I did read a completely unsubstantiated claim that the drive-by-wire setup in the toyotas at least uses a dual-rail potentiometer to sense the accelerators position.

If that's true, it sounds at least a little bit worrying. I know the dual-rail aspect provides some redundancy, but it probably wouldn't take much (a faulty air-con unit leaking a bit of dirty water onto the pot for example) to trigger a 100% reading.

I'm also wondering if there's a possibility of failure at the other end of the chain (eg. throttle butterfly mechanism sticking). If it happened on the actuator side rather than with the sensor, the ECU would probably have less of a chance of sensing (and correcting) the problem...

Anyway, who knows. It's all speculation without having access to the actual cars involved as well as their hardware and software specifications....

If these cars are drive-by-wire then I'd be suspecting that the potentiometers and/or positional encoders that are used to read the throttle position are failing (or starting to fail) as potentiometers and encoders do.

Can anybody in the know verify what sort of technology is used to actually read the throttle position in cars these-days (not for the TPS sensor so much - but for the drive-by-wire setup)? I'm hoping it's not potentiometers because the resistive layer can wear through on those with age causing unreliable behaviour. Even if they're using rotary or optical encoders, they can have dodgy reliability problems when they age (grease/lubricant starts to age) etc. Who hasn't had a stereo where the volume control has started getting flaky after a few years?

I'm sure that the manufacturers have thought of simple things like this, which makes me think that there's either people are making this stuff up, or there's something screwy with the car's control software or electronics. If it's a software error then, as another poster has already pointed out, no amount of pontificating is going to solve the problem without giving us access to the source code.

Of course, it could be something more sinister. Perhaps the CAN bus command to signal 100% throttle to the ECU happens to be easy to trigger with a particular type of noise? Again, nobody is going to be able to figure that sort of stuff out without some serious insider knowledge..

I hope they do figure this out though as my car happens to be a reasonably recent model and is drive-by-wire. Although I'd like to think I'd have the presence of mind to kill the engine or throw it in neutral if there were any problems, until you're put in that situation it's really hard to know how you'd react.