ReidZB

When we migrated away from JIRA, we scripted it such that the JIRA issue numbers were recorded in the newly migrated issues exactly because of things like this.

I find myself doing unit queries like 4 all the time. "80 bytes / second * 1 year" results in ~2.5 GB. Etc etc. It's very convenient for making sure that you're handling units correctly.

It's also really good for random facts. For example, "75 kWh at California electricity price". Or if you know something takes 20W to run continuously and you want to know how much it costs... "20 W * 1 year at california electricity price".

I suppose eBPF could be used to implement real-time index updates, which could be neat. Maybe I'll investigate doing that as a little side project. Though from a quick look, doing it efficiently may require some modification to mlocate's updatedb program (depending on how -U works exactly...).

Yep! I've had two nasty bugs (intermittent audio dropping and HDMI CEC power off being broken) that were fixed by firmware updates.

I don't keep the firmware preemptively updated, though. I just did it as a debugging step in trying to fix some problems, and shockingly it did both times.

I have a couple modern LG 'smart' TVs that I don't connect to the internet, and they work just fine. As you say, they just display whatever is on the HDMI input.

I've updated their firmware a couple times. I connect them with wired cat6 on their own isolated VLAN to update, and then disconnect them afterwards. Maybe I am a little unnecessarily paranoid about it, but I don't really trust TV manufacturers, not with some of the (maybe apocryphal) stories I've read.

That's assuming you're varying only speed and not e.g. following distance. I try to leave at least 3 seconds' distance pretty much always (often more), so I have a pretty consistent amount of time to react regardless if I'm driving 30 mph or 55 mph.

Additionally, most of the metrics are cut-offs. It doesn't matter if you brake very gradually or if you brake very close to the area where it penalizes you. Based on my driving so far, the hard braking threshold is pretty forgiving. Yesterday, I let off the accelerator completely and went full-regen braking and it didn't care.

Anyway, I've driven 99 miles (highway/city mix) with the Safety Score thing turned on, and I'm still at score 100. I haven't slowed down at all.

I don't get it. The article clearly outlines the factors accounted in the safety score, and vehicle speed is not one of them (at least not directly). Yet the author and apparently others are intentionally driving slowly to boost their score? That doesn't make sense.

You can definitely "game" the score (to an extent) by making unnecessary trips, i.e. driving to give it more data, but driving abnormally slowly on those trips doesn't help anything. That is, unless you think driving 55 mph will help in the measures, but I'm skeptical of that.

The forward collision measure is based on number of miles, so if you drive 100 miles with no warnings, that's scored the same way if you were driving at 55 mph or 80 mph.

For the others (hard braking, aggressive turning, and unsafe following), each computes the percentage of time you spend doing the unsafe thing relative to doing it safely. If you want to improve those measures, you need to actually spend more time braking, or turning, or following at >50 mph and less than 3 seconds distance. Just driving a slow constant 55 mph on the highway won't change those measures at all, as I understand it.

The forced disengagement measure is just whether or not the car put you into autopilot jail for not paying attention while autopilot was active. I'd hope no one is getting put in that jail, but especially not if they're trying to be on their best behavior.

Anyway, from the Tesla FAQ, I find the 'predicted collisions in 1 million miles' formula fascinating:

    Predicted Collision Frequency (PCF) = 0.682854
      x 1.014495^{Forward Collision Warning per 1,000 Miles}
      x 1.127294^{Hard Braking}
      x 1.019630^{Aggressive Turning}
      x 1.001444^{Unsafe Following Time}
      x 1.317958^{Forced Autopilot Disengagement}

Hard braking and forced autopilot disengagement are, in their model, big predictors of a collision. I'm surprised to see unsafe following at such a low weight.

> Being able to effectively reason about what the automation is doing is such an important part of why these technologies have been so successful in flight, and examples like this illustrate how far off we are to something like that in cars.

Is that actually the case, though?

I would hope, although perhaps I'm mistaken, that the developers of the actual self-driving systems would be able to effectively reason about what's happening. For example, would a senior dev on Tesla's FSD team look at the video from the article and have an immediate intuitive guess for why the car did what it did? Or better yet, know of an existing issue that triggered the wacky behavior?

Even if not, I'd hope that vehicle logs and metrics would be enough to shed light on the issue.

I don't think I've ever seen a true expert, with access to the full suite of analytic tools and log data, publish a full post-mortem of an issue like this. I'm certain these happen internally at companies, but given how competitive and hyper-secretive the industry is, the public at large never sees them.

For superchargers, where you'd want it most, no. Superchargers use a specific protocol to communicate with the car for purposes of billing -- tied to the Tesla account associated with the car. I don't think the plug itself is different than a normal Tesla plug (other than being beefier, perhaps?) but I could be wrong.

For normal Tesla wall chargers, like one that might be installed at someone's house, I think there are adapters that might work for the Leaf, but I have no experience with them.

That said, other than Tesla, I think there is standardization. Especially with Electrify America. But, Tesla's network is so convenient and widespread that it is currently a big selling point for the brand, in my opinion.

Definitely. Enmity between elves and dwarves is a deep theme in Tolkien's world. The Silmarillion presents several in-universe historical events responsible for that enmity. It's also foreshadowed by "God" (Eru) when he grants life to the dwarves.

Friendships between the elves and dwarves are as a result considered very special, which is why Gimli and Legolas's friendship in The Lord of the Rings is such a big deal.