Small drones don't have much inertia. They can be easily flipped by a small local wind gust. This is a big problem for drones that operate close to buildings, where there are eddies and turbulence as air hits the building. Pass the corner of a building and the wind situation may be completely different.

Very smart and aggressive stability control systems are able to overcome this. See this drone from PSI Tactical, which weighs about 0.5Kg and is supposed to be able to operate in winds up to 30MPH.

Battery storage for bulk power has been talked up for years. Mostly by the wind industry. With solar power, you get peak power and peak air conditioning load around the same time. Wind varies about 4:1 over 24 hours, even when averaged across big areas (California or the eastern seaboard). So the wind guys desperately need to store power generated at 4AM, when it's nearly worthless, so they can resell at 2PM. When the wind farm companies start installing batteries at their own expense, this will be a real technology.

With the US glut of natural gas, this isn't needed right now. Natural gas peaking plants aren't all that expensive to build, and make money even if they only run for maybe 6 hours a day. That covers most peak needs.

There are other ways to store energy. Some of the dams of the California Water Project have reversible turbines, which can run either as pumps or generators. They pump water uphill at night, when power is cheap, and let it down during the afternoon to generate power. Since the dams and pumps are needed for water handling anyway, this adds little cost.

A few years ago, those Google NFC payment terminals were all over Silicon Valley. Nobody used them. Newer credit card terminals show no sign of supporting them, although some apparently have the hardware inside for it.

Another problem is that if the technology just requires the phone's presence, not interaction on the phone, it's insecure. "Near field communication" is only supposed to be up to 20cm, but a 2013 paper at Black Hat demonstrated connectivity at 100cm, which is good enough for crime. If it does require interaction on the phone, the user has to activate the phone, navigate to some app, and deal with the app. This is slower than swiping a credit card.

It's easier to do than card-reader skimmers.

Many ultra-orthodox rabbis who demand their followers not use uncensored smartphones or uncensored internet access. In 2012, a big anti-Internet rally for ultra-orthodox Jews was held in New York. "The siren song of the Internet entices us! It brings out the worst of us!" The event was streamed live and is summarized on YouTube.

There are ultra-orthodox ISPs with filtering. The filtering is very stringent, based on a rabbi-approved whitelist. "That's all you get, and nothing else."

There are kosher cell phones. "Kosher Phone has no camera, no Bluetooth capabilities, no memory card slot and cannot be connected to a computer."

That's in the US. In Israel, kosher cell phones are so locked down that only approved numbers can be called. Even rape crisis centers are blocked.

Right. NASA also still has way too many "centers". Ames (except for the big wind tunnel) and Glenn (except for the test facilities at Sandusky) ought to go.

Quake audio consists mostly of footsteps and bangs. This might be fun for, say, GTA IV/V, where the NPCs have conversations to which you can listen if you're close enough.

Google isn't detecting potholes? Back in 1985, we had that on our DARPA Grand Challenge vehicle. The LIDAR on top of the vehicle was generating a ground profile. This was for off-road driving, where that's essential. I'd assumed Google was doing that; they have a Velodyne laser scanner that provides enough information.

In traffic, sometimes you can't see a pothole because it's obscured by a vehicle ahead, but if the vehicle ahead doesn't change speed, direction, or attitude, it's probably safe to proceed over the ground it just covered. On high speed roads, you can't see distant potholes clearly because the angle is unfavorable, but if the road ahead looks like the near road, and the near road profiles OK with the LIDAR, the far road is probably good. That's what the Stanford team used to out-drive their LIDAR range. (We didn't do that and were limited to 17MPH).

Fixed road components should be handleable. People, bicycles, and animals are tough.

This is my news printer. Each morning I turn it on, and it prints a paper tape with the Reuters news summaries.

This is 1926 technology. The machine talks to a standard serial port at 45 baud, 5 bits, no parity, 1.5 stop bits.

This is fascinating. It's not the classic "people don't have social lives in the real world because they are on line too much" argument. The authors argue that following people who are "different" from you is bad for you. They write:

"Compared to face-to-face interactions, online networks allow users to silently observe the opinions and behaviors of an immensely wider share of their fellow citizens. The psychological literature has shown that most people tend to overestimate the extent to which their beliefs or opinions are typical of those of others. There is a tendency for people to assume that their own opinions, beliefs, preferences, values, and habits are âoenormalâ and that others also think the same way that they do. This cognitive bias leads to the perception of a consensus that does not exist, or a 'false consensus' (Gamba, 2013)."

"The more people used Facebook at one time point, the worse they felt afterwards; the more they used Facebook over two weeks, the more their life satisfaction levels declined over time. The effects found by the authors were not moderated by the size of people's Facebook networks, their perceived supportiveness, motivation for using Facebook, gender, loneliness, self-esteem, or depression, thus suggesting the existence of a direct link between SNSs' use and subjective well-being."

This is a new result, and needs confirmation. Are homogeneous societies happier ones? Should that be replicated on line? Should efforts be made in Facebook to keep people from having "different" friends?

The Mozilla Foundation has sold out. Don't donate to them, either money or code.

Here's a more technical discussion from NHTSA. At page 74-75, the data elements of the Basic Safety Message I and II are listed. The BSM Part I message doesn't contain the vehicle ID, but it does contain latitude and longitude. The BSM Part II message has the vehicle's VIN. So this is explicitly not anonymous.

Back in the 1980s, when Caltrans was working on something similar, they used a random ID which was generated each time the ignition was switched on. That's all that's needed for safety purposes. This system has a totally unnecessary tracking feature.

Most of this stuff only works if all vehicles are equipped. It also relies heavily on very accurate GPS positions. However, there's no new sensing - no vehicle radar or LIDAR. The head of Google's autonomous car program is on record as being against V2V systems, because they don't provide reliable data for automatic driving and have the wrong sensors.

If something is going to be required, it should be "smart cruise" anti-collision radar. That's already on many high-end cars and has a good track record. It's really good at eliminating rear-end collisions, and starts braking earlier in other situations such as a car coming out of a cross street. Mercedes did a study once that showed that about half of all collisions are eliminated if braking starts 500ms earlier.

V2V communications should be an extension of vehicle radar. It's possible to send data from one radar to another. Identify-Friend-Foe systems do that, as does TCAS for aircraft. The useful data would be something like "Vehicle N to vehicle M. I see you at range 120m, closing rate 5m/sec, bearing 110 relative. No collision predicted". A reply would be "Vehicle M to vehicle N. I see you at range 120m, closing rate 5m/sec, bearing 205 relative. No collision predicted". That sort of info doesn't involve tracking; it's just what's needed to know what the other cars are doing. It's also independent of GPS. Useful additional info would be "This vehicle is a bus/delivery truck, is stopped, and will probably be moving in 5 seconds.", telling you that the big vehicle ahead is about to move and you don't need to change lanes to go around it.

Nah. It just takes more crashes before the exploit achieves penetration.

(Address space randomization is a terrible idea. It's a desperation measure and an excuse for not fixing problems. In exchange for making penetration slightly harder, you give up repeatable crash bug behavior.)

The Slashdot article doesn't tell me what MediaGoblin does, or what it's for. Nether does the MediaGoblin site. The documentation, in typical Gnu syle, starts out with "how to participate" and continues with installation instructions.

It's sort of like Wordpress, but with different features and support for streaming media. There's a list of sites that use it. Of the public sites listed, all but one are demos of MediaGoblin. The first site on the list that isn't a a demo and works is this set of baby pictures. There's one site that lets you upload stuff. It's a collection of uploaded pictures with no organization.

This seems to be a publishing system for people with nothing to say.

Back in the 1990s, Microsoft developed something similar. Their idea was to render frames in layers, with the more distant or less active layers rendered less often. if the viewpoint changed, the background layers were scrolled, rotated, or transformed to match, rather than being re-rendered immediately. It never caught on, because graphics hardware became fast enough to re-render everything on for each frame.

This new thing is similar. Mispredicted frames are viewpoint-warped as a temporary measure so the user sees something. The image is wrong, but close enough to look OK until a new rendered frame is sent. It looks OK for Doom, on which it was tested, because Doom is mostly about the shooter and the opponents moving; there's not much general activity in the background. GTA IV/V would probably look much worse than normal.

The whole concept represents a desperate attempt to make something "cloud-based" that shouldn't be.

Except nobody actually does that. The whole JVM thing was done to make browser "applets" work. Nobody uses those any more. Most Java is server-side, running on farms of x86 machines.