The success of the first iPhone or Facebook app didn't depend on using it to navigate through life-and-death situations not only for the users but also for everyone around them.
There are places for 'move fast and break things'. But cars move fast already, and they can really break things.
Every organization has these types of things internally. As an engineer, I don't like it, but it's a fact of life.
Source - https://www.businessinsider.com/tesla-hit-model-3-target-by-...
We're at the point in the Tesla story similar to that of 2008 where Dr. Berry et el were watching the housing market collapse around them and the banks wouldn't re-price the swaps. Tesla is already bankrupt, most people don't know this yet. But they will.
I have so many electronic devices, from cheap to expensive, that have some passive component manually bodged on somewhere. They work fine. It just means that paying someone to rework 1000 boards was cheaper than throwing the boards away and spinning up Revision B immediately. It's not a big deal. Waste is worse than a product that is imperfect immediately off the assembly line.
Tesla cannot get the rest of their booked-sale cash for an undelivered car.
But they must pay all the fixed production costs anyway. In cash, creditors at this point will be getting squirrelly.
Therefore: slowness in production is the fast-track to a possibly fatal cash crunch.
Is Tesla making money?
It's not about money. Correcting and refacturing a board takes time, in the order of months even for a simple one. It's too long.
• In July, over 60,000 test drive requests in the US alone
• 5000 Model 3 new net orders in one week in mid-July
• Total deposits greater than total refunds in the twelve months ending April 2018
• Reports of Cancellations Outpacing Orders proved to be False wording
Meaningless negative indicators include Goldman Sachs analyst David Tamberrino saying Model 3 social media activity had lessened and frequent critic Latrilife said Tesla’s Burbank Airport lot is under 24/7 surveillance
Sources include:
• Seekingalpha.com/article/4189303-tesla-short-thesis-model-3-demand-wrong
• Seekingalpha.com/article/4179986-tesla-model-3-reservations-tip-iceberg
And - https://twitter.com/Paul91701736/status/1033136573615730688
All the first hand Twitter intelligence is gathered by people who are short on TSLA. They see the ground level reality.
The details matter here and given the quality that I see in the field, I'm not convinced that this is such a horrible situation.
It's not like those matter. The bank itself guarantees the integrity of your account and can reverse charges. And of course would be insured for such losses.
Being killed by a car, otoh, is more permanent.
Source: Done this a few times to clear bad map data or occasional glitch.
To be sure, it's a bit unsettling, and I wouldn't be thrilled about it deciding to not work for a day or two, but, in a way, it makes me MORE comfortable that the vehicle control systems function as expected.
In hot weather it can become very uncomfortable or even impossible to drive without AC.
Safety equipment must not fail, but essential equipment can fail as much as your customers will tolerate.
Our '83 Vanagon doesn't have AC, it can be uncomfortable but sure isn't the end of the world.
IIRC car manufactures are irresponsibly lazy and never properly air-gap infotainment from critical stuff.
Can you imagine a zero day being found in Windows with Windows Update being down?
2. Apparently people can ssh into the infotainment system.
1 + 2 => someone hacks into the infotainment system and flashes a safety-critical ECU. I guess/hope there's some protection in place to prevent that.
Only if it's deliberately isolated in the vehicle. It should be. Aaaand, it isn't: the firmware upgrades to all other car computing elements go through it.
Because drivers can't get distracted and crash because of a failure in the infotainment and IT infrastructure?
Almost everything in a cars front panel and dashboard can be. I've read somewhere that people have been killed even because of something as quaint as the wrong placement of car ashtray.
Anyway this little illustrated anecdote of mine aside, driver distraction is a genuine issue - even for drivers at red lights. The number of times I've seen this type of behaviour transcend into moving off while remaining distracted (whether that's heads down visually or just mentally) is too boringly frequent to detail. Sometimes the distracted drivers even creep forward unconsciously while traffic is flowing across them. Emergency vehicles can't get through, drivers end up splitting their attention, pressure mounts once proper movement starts again, and all the while they don't realise they don't have full attention in a changing environment.
It's almost like a hypoxia.
Tom Scott did a pretty good video on this: https://youtu.be/_-aDHxoblr4
An iPhone handling an emergency call is an exceptional use case.
A car driving is not an exceptional use case for a car.
A life and death scenario is occurs every few minutes, or continuously for something like a mountain road, if something like brakes, limited throttle, or steering were to fail.
But, I would, naively, assume that the operation of these critical components were in no way related to timing requirements of some process in Linux.
It seems you have to prove that failure of these hack-y systems would lead to the disastrous result you postulate.
Even PC's have now a hidden baseband processor for the mission critical stuff, like backdoors and surveillance.
Clearly when we "verify" Waymo or Tesla auto-pilot, we're going to want to use that stuff, right? Surely they won't just provide insurers with some data about the billions of miles they've driven without accidents and how humans can only drive like a million miles without an accident and try to get the insurers to give them policies...
Just like when we hand out licenses, we always check to make sure the 16 year old took some formal driving classes from professional driving instructors... I wish things were better but we don't care about this stuff as a society until much later usually. When did the car first appear? When did the first seatbelt law appear?
a) interesting, because it shows how other companies solve (or fail to solve) specific common problems.
b) surprising, because I thought they'd be much better at it.
Car infotainment is generally not categorized as safety-critical and can be quite similar to regular software development. Having remote access changes things: I always thought their security must be top notch if they had the confidence to launch that. Ssh-ing and deleting files sounds like the opposite of that.
Btw, saying that doing things properly increases risk must be the biggest load of nonsense I have ever seen on HN.
Bosch supplies VW (includes Audi, Seat, Skoda, ...) and various other large incumbents, as one of the biggest car manufacturer supplier. Why do people think they are considerably better off? Their practices are often equally ridiculous and dangerous.
As a rat in that cage you do whatever you need to make things work.
https://www.caranddriver.com/features/its-all-your-fault-the...
http://www.safetyresearch.net/blog/articles/toyota-unintende...
> Skid marks notwithstanding, two of the plaintiffs’ software experts, Phillip Koopman, and Michael Barr, provided fascinating insights into the myriad problems with Toyota’s software development process and its source code – possible bit flips, task deaths that would disable the failsafes, memory corruption, single-point failures, inadequate protections against stack overflow and buffer overflow, single-fault containment regions, thousands of global variables. The list of deficiencies in process and product was lengthy.
>There are a large number of functions that are overly complex. By the standard industry metrics some of them are untestable, meaning that it is so complicated a recipe that there is no way to develop a reliable test suite or test methodology to test all the possible things that can happen in it. Some of them are even so complex that they are what is called unmaintainable, which means that if you go in to fix a bug or to make a change, you're likely to create a new bug in the process. Just because your car has the latest version of the firmware -- that is what we call embedded software -- doesn't mean it is safer necessarily than the older one….And that conclusion is that the failsafes are inadequate. The failsafes that they have contain defects or gaps. But on the whole, the safety architecture is a house of cards. It is possible for a large percentage of the failsafes to be disabled at the same time that the throttle control is lost.
etc. etc.
Most code is buggy, and the more closely you look, the buggier it is. Most of that same code operates without noticeable error.
That code analysis turns up "inadequate protections against stack overflow and buffer overflow" does not actually suggest that there was any stack overflow or buffer overflow, and people quote this as if it does.
Meanwhile, it is all-but-certain that the overall findings were correct: people hit the wrong pedal regularly, and if enough press attention is given, all of those wrong-pedal-pushers find each other and try to blame the manufacturer instead.
You started with "Regardless of whether the acceleration were caused by the software or not," but I think that's the important thing, and that software is buggy should surprise nobody.
At risk of beating a dead horse, I do find it interesting how despite the myriad of "driver hit the wrong pedal" news stories out there, only the Prius one starts from the "it had a mind of its own" angle.
I think what most people don't realise is that it's so incredibly easy to be fallible with "automatic" familiar everyday activities (i.e., not maths or remembering facts). I recall in driving school approaching a quiet intersection where I once lost proprioception of my foot and had to call the instructor to use her dual brake because I didn't know where my foot was or could no longer reach the brake pedal (I guess I'd have attempted the hand brake if I were alone).
From this single experience along with running other dark hypotheticals through my head, I am so cautious with many things that it bewilders me that activities such as "carpool karaoke" is not an atypical practice.
But otherwise yep, same thing with software only that the stakes are often lower thanks to the sheer number of non-mission critical projects out there. It's only the mission critical bugs that get the most attention and surprise.
That's fascinating. I can say that is something I have never experienced. Does it happen to you with any regularity?
At one point in my life, I was simply an inexperienced learner driver. It isn't and wasn't a medical condition (for me anyway). I literally couldn't find where the brake pedal was because I couldn't really position my foot in the right place as I had clearly lost track of where it was in the footwell area. I also didn't want to take my eyes off the road and knew I was going slowly enough that nothing bad would happen (because the professional driving instructor had a dual brake, and I had a working handbrake too which I never used - we'll call that risk compensation).
Now all this said, it's incredible how many people are completely unaware of their own inabilities when it comes to mission-critical tasks (the Dunning-Kruger effect). This isn't even always limited to "incomptent" people - experienced professionals also make "simple" blunders. See also Air France 447, or various deceased pro/amateur race car drivers.
Speaking of failures though - another time (also while I was learning), I was reversing out of the car shed with my dad supervising. Before leaving, I complained to my mother (who was just outside the car) that my brake was difficult to press. She replied "just press harder", so I shrugged, obliged and went on with the "supervised" driving practice. Her confidence in me had me convinced that everything was fine so off I went.
Damn, the brake was so difficult to press - I needed both feet as well as some bodyweight on it to get the car to stop at each intersection - it hardly budged each time and felt like a dodgem car brake. I figured at the time that if I just kept things slow and got the handbrake ready, things would be okay? Anyway nothing bad happened; it was only a short session before dinner on quiet streets.
The next morning, my mother went to drive the car out of the shed and was alarmed at how broken the brake was. What was I to know - I was pretty new to driving and thought it was just the car being old and figured it was good enough at the time for my two feet. It was probably bad enough to require towing but I think my dad ended up driving it very slowly/carefully to the mechanic.
That was a bit of a long story, but I'm detailing this to highlight how "stupid" cascading failures are "alarmingly" common - it's not unheard of to exist in both the human side, or the electronic/mechanical side. It doesn't really faze me whether the Prius "acceleration bug" was human or machine induced. Both are often as bad as each other. The only thing we should depend on are multiple layers of redundancy and good systems design.
Edit: When I first started driving, I mulled over whether to go barefoot or not (either is legal here so long as the driver has control). These days, I fortunately can handle either confidently. I'm also much better at sport now (and therefore coordination) than when I was a teenager.
And what was particularly negligent about Toyota's software practices that "more likely than not" caused issues with ETCS.
https://betterembsw.blogspot.com/2014/09/a-case-study-of-toy...
Welp, sadly I am not able to read your source.
Happened to my 2001 Clio several years back, although in my case it was when I started the car, not during driving. My hypothesis was that it triggered due to my bad habit of turning the car off in traffic queues then restarting it with the pedal held down.
The security researchers who were expert witnesses in the Toyota case and that analyzed Toyota's source code testified in court that they managed to reproduce the unintended acceleration with a real car on a dynamometer.
The engineer was questioned:
" Q. Now, you have not reproduced in vehicle testing your 25 theory that there's a software bug that opens the THIS TRANSCRIPT IS NOT PROOFREAD 30 1 throttle and then the task dies, have you? 2 A. No."
From page 245. Further reproduction questions were all answered with a no further.
To get a successfully task death failure (what the engineer wanted to happen) the engineer had to modify the source code.
Further in the limited testing even with modifications, the failsafe triggered 100% of the time.
Your statement is incorrect.
I once had a project with a major lobbying organisation with links throughout the automotive industry. The one that published regular reports on real vs declared emissions discrepancies long before the VW scandal.
They were unanimous when asked about the unintended acceleration bug. It was a case of mass hysteria.
At least according to the summary based on sources used for Wikipedia:
https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...
The page you refer to has a section "NHTSA and NASA Investigation Verdict" and it says nothing about the software bugs.
https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...
First, we're talking about a multi-billion dollar company here (they've raised ~ 15 B), not some small "challenger".
Second, your example is the iPhone and Facebook. Those don't have the potential to kill their owners or run over people.
We can't have them be both challenger in that sense, and accept that challenger in their case means multi-billions.
Challenger or not, $15 B doesn't explain a totally crappy software engineering process and result even if its just for the infotainment system.
All of the what? The only competition on the desktop when Microsoft won was QDOS.
Musk fan or not, you can't deny this has no interest
For every good success example, there is a good failure example.
My point is that for every good example of a success story (about startups in this case), there's a good story of a failure. And the failures are much more than the successes. If you want to discount the failures because they don't fit your narrative, then you should equally oppose the successes when they don't fit your narrative.
TL;DR my post is a reply to a post and should be seen in that context. You've taken my post out of context; please don't do that.
Moreover, I recently read the book Bad Blood and I found it interesting to get an inside look at a startup who present themselves better than they actually are. I don't believe that part of the Theranos debacle is so uncommon. The severity and unique market though, are. And, that's actually underlined by the Twitter thread (the pictures). Another similarity is the massive quitting and burnout of quality personal, the fear of being fired and standing up, low morale. Those are, IMO, interesting similarities.
>The iPhone could play a section of a song or a video, but it couldn’t play an entire clip reliably without crashing. It worked fine if you sent an e-mail and then surfed the Web. If you did those things in reverse, however, it might not. Hours of trial and error had helped the iPhone team develop what engineers called “the golden path,” a specific set of tasks, performed in a specific way and order, that made the phone look as if it worked.
>They had AT&T, the iPhone’s wireless carrier, bring in a portable cell tower, so they knew reception would be strong. Then, with Jobs’s approval, they preprogrammed the phone’s display to always show five bars of signal strength regardless of its true strength.
>None of these kludges fixed the iPhone’s biggest problem: it often ran out of memory and had to be restarted if made to do more than a handful of tasks at a time. Jobs had a number of demo units onstage with him to manage this problem. If memory ran low on one, he would switch to another while the first was restarted. But given how many demos Jobs planned, Grignon worried that there were far too many potential points of failure.
Steve was a full on sales person and was really, really good at presentations.
Tesla has a larger market cap than Ford, GM, or Honda.
Remember the demo of the first iPhone (vs the huge expertise of Nokia). Or how Microsoft won the desktop starting from a single user, cooperative multitasking system (vs all the sophisticated Unix-based systems). Or Facebook running on despised MySQL and PHP.
These hacks are part of the strategy. It's risky but probably doing these 'properly' would increase the risk even more.