Hacker News Reader

Comment by lexicality | Hacker News Reader

You don't think it's unusual that the software is designed to delete crash data from the crashed car?

The question is whether this is code that's special for crashes, or code that runs the exact same way for all data uploads, regardless of whether there's a crash.

You're implying it's special for crashes, but we don't know that.

The crash system uses this code, therefore they chose to do something that would delete the crash data after a crash.

Saying "hey, the upload_and_delete function is used in loads of places!" doesn't free you of the responsibility that you used that function in the crash handler.

Is this a crash handler, or is it their normal telemetry upload loop?

Yes, it's a crash handler that uploads a blackbox "collision snapshot" of the entire car's state leading up to a crash. It's very well documented that Tesla does this, including in the article.

You have it backwards. The fact that after the special condition of a crash it still allows the data to be deleted is an issue. Sure, deleting of normal data is fine, but it clearly detected a crash and did not mark the file in the special crash mode as do not delete is mind boggling. Everyone knows that in a crash detection mode that the data is very important. Not having code to ensure data retention is the laziest at best way of doing things or malevolently designed at worst. Tesla and its leadership do not deserve at best as our default choice.

if its not special for crashes thats criminally bad design in a safety critical system.

u know if for instance u weld a gas pipeline and an xray machine reveal a crack in your work, you can go to jail.... but if you treat car software as an appstore item, totally fine??

stop defending ridiculously bad design and corporate practices.

>> You don't think it's unusual that the software is designed to delete crash data from the crashed car?

After it confirmed upload to the server? What if it was a minor collision? The car may be back on the road the same day, or get repaired and on the road next week. How long should it retain data (that is not legally required to be logged) that has already been archived, and how big does the buffer need to be?

A very simple answer is "until the next time the car crashes", you just replace the previous crash data with the new data.

If the car requires that a certain amount of storage is always available to write crash data to, then it doesn't matter what's in that particular area of storage. That reserved storage is always going to be unavailable for other general use.

> What if it was a minor collision?

Then, I don’t know… Check if it was the case? Seriously, it’s unbelievable. It’s a company with a protocol to delete possibly incriminating evidence in a situation where it can be responsible for multiple deaths.

Keep it until any pending court cases or insurance investigation is complete.

Think of it as the scripts that run on CI/CD actions running unit tests. If a unit test fails, the test artifacts are uploaded to an artifact repository, and then, get this - the test runner instance is destroyed! But we don't think of that as unusual or nefarious.

That's because typically the test runner hasn't just crashed into another test runner at full highway speed

No one dies when your unit test fails. Different stakes, different practices, what are all the Tesla apologists smoking here?

I don't think you can equate CI/CD unit tests and killing humans with 2 tons of metal.

And yet, that's what you get when your software org comes from that kind of devops culture. And here we are

That's a particularly unhelpful analogy. Car telemetry is linked to real world physical objects and real human suffering, whereas CI/CD actions may be linked to the happiness of a project manager etc.

Reply on news.ycombinator.com