Hacker News Reader

Comment by sz4kerto | Hacker News Reader

Why is this interesting or surprising? Of course almost all challengers have hacky tech under the hood because they don't have the resources. Winning from that position is possible not because of generally better tech but by delivering something that the incumbents don't.

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.

View on HN

Cars weigh thousands of pounds and routinely drive upwards of 60 miles per hour.

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.

I think this is a naive perspective. I've heard many similar stories from friends that work in the German automotive industry, and I think you would be surprised how many payment systems are tied together (e.g. (insecure) FTP servers to sync daily payments).

Every organization has these types of things internally. As an engineer, I don't like it, but it's a fact of life.

Banks can reverse transactions if they want to. Tesla's cavalier attitude towards manufacturing has yielded a 14% first pass through rate on the Model 3 line (which is abysmal and may bankrupt the company along with declining M3 demand) vs. the industry standard of ~80% FPT rate.

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.

While I agree that 14% is horrible, that was a point-in-time number that is being compared to an average. One would hope that factories regularly run well above 80%. I'd also bet that some occasionally drop well below it for a day or so.

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.

I don't think the rework rate is a big deal for the customer. Ultimately manufacturing is about increasing the yield rate so that costs are lowered, because rework is expensive. But if you can make money with lots of manual rework on every product, it's no big deal. Something to improve next quarter.

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.

People are waiting 3 or 4 months for replacement parts for their vehicles or Tesla has had possession of the vehicle (and the person is using a loner) for a similar amount of time. That won't fly in the mass market.

"But if you can make money with lots of manual rework on every product, it's no big deal. Something to improve next quarter."

Is Tesla making money?

Rework dramatically slows production.

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.

>>> 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.

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 some cases banks can't reverse transactions.

That link is not a source for declining Model 3 demand. Source? My info shows that

• 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

A key supplier may have gone cash on delivery (no more net 120 terms) because M3 production this week has been at a stand still - https://twitter.com/skabooshka/status/1032409945407250434

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.

>I think you would be surprised how many payment systems are tied together (e.g. (insecure) FTP servers to sync daily payments).

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.

Tesla’s infotainment and IT infrastructure is unrelated to their safety. If this guy worked on motor control or braking system firmware then that would be scary, but he didn’t.

> Tesla’s infotainment and IT infrastructure is unrelated to their safety.

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.

Runtime isolation is distinct from compile/build-time isolation. You're citing the latter, but it's the former that matters. Tesla gets this right, e.g. an interrupt in the MCU does not have any effect on braking, drive-by-wire, or ADAS systems while a car is in operation.

Just to back this up: I have rebooted both my MCU and my instrument panel while driving. Critical systems are not affected.

Fair enough, but if those bits pass through the infotainment center on the way in, controlling one allows you to control the other.

Ignoring the infotainment system for this argument (as they firewall it off from CANBUS and other life critical systems [1]), I argue that their IT infrastructure is safety related, as it governs Tesla's velocity in getting patches and security fixes out to vehicles in a timely manner.

Can you imagine a zero day being found in Windows with Windows Update being down?

[1] https://www.youtube.com/watch?v=KX_0c9R4Fng

There's no guarantee that any given car is connected and receives updates, so the safety-critical systems need to be good enough when the car ships. They might mess up, but then they'd at least be able to patch cars faster, while other manufacturers would have to do a recall.

If the infotainment system caused the MCUs to reboot while someone traveling "130mph on San Mateo Bridge" and that caused the break system to segfault due to unconventional way of loading parts firmware, it might be a life&death situation, easily. Examples in that threads go on, literally hundreds!

I don't understand how that could happen. MCU reboots, ???, brake system segfaults? What goes in the middle?

Probably everything has access to everything on the CAN bus.

IIRC car manufactures are irresponsibly lazy and never properly air-gap infotainment from critical stuff.

There's a firewall between the CAN bus so it cannot be affected at all by the MCU.

Even if this were true (and as another commenter says, it's not) I don't see how that fills in this gap. It would make sense if the first step were "MCU goes crazy," but not with a simple reboot.

Well, you can reboot the system while driving(both console and dash), nothing special happens other than the AC turning off for a brief period of time. Brakes, wheel, throttle all respond normally.

Source: Done this a few times to clear bad map data or occasional glitch.

Doesn't surprise me -- a couple of times my new 3 has had nothing on the display but it's still happy to let me put it in gear and drive away, and the display pops up within a second or two.

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.

AC should be considered mission critical.

Definitely, I'd put it on the mission criticality list right below inflight wifi.

It's not mission critical, but it's important: in cold weather the windshield can fog up to the point of 0% visibility.

In hot weather it can become very uncomfortable or even impossible to drive without AC.

There’s a distinction between safety critical equipment and essential equipment. If the former fails, it could kill you. If the latter fails, you can’t drive anymore but you won’t die if it happens on the road. Brakes are in the former category, while things like HVAC and instruments are in the latter.

Safety equipment must not fail, but essential equipment can fail as much as your customers will tolerate.

You can steal a trick the motorcycle community discovered a long time ago, some water + soap on the windshield prevents condensation.

Our '83 Vanagon doesn't have AC, it can be uncomfortable but sure isn't the end of the world.

Seriously yes, at least ventilation. Anybody who don't believe this, try turn off your AC completely and see how quickly your wind screen is fogged up to the point you can't see out. (depending on which climate you live in)

There’s no concept of “reboot” with MCUs, since there’s usually no OS. Likewise there’s usually no concept of segfault, because segfault requires memory protection which is something most MCUs don’t use.

Tesla’s MCU runs Linux. Older ones use a 2012-era Nvidia mobile SoC, while newer ones use something from Intel.

Nah. No way the mcu responsible for braking would run an OS

Didn't they already do an Over-the-Air update to fix the braking time in response to a bad review?

You don’t need an OS for that.

This must be an acronym mixup. We’re talking about the Media Control Unit, i.e. the giant screen in the center of the dashboard responsible for zero safety-critical systems.

MCU in the case of braking and steering is “micro controller unit”.

Yeah, those definitely aren’t running Linux, and the guy here wasn’t working on them.

Yes, The infotainment stuff, like the screen, internal lights, speakers are connected via a low profile third bus system, certainly not the main CAN bus or profibus or firewire. Some, like in the BMW even via WiFi. These are the systems usually used with Linux or Windows or Android. On top of the important stuff.

s/reboot/reset/, s/segfault/bus-fault/

>Tesla’s infotainment and IT infrastructure is unrelated to their safety

Because drivers can't get distracted and crash because of a failure in the infotainment and IT infrastructure?

If that's the standard, then almost everything becomes safety critical. Drivers can easily get distracted by malfunctioning smartphones or apps. (Or, for that matter, properly functioning smartphones or apps.) Yet the prior discussion was based on the idea that things like iPhones and Facebook aren't safety critical the way this is.

It is my understanding that two major reasons for various ugly UI and unintuitive UX in automotive infotainment systems are patents and safety certifications.

>If that's the standard, then almost everything becomes safety critical.

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.

One time I pulled up at the red light behind a Tesla while I was on a bicycle. Straight through the rear window I could see the driver and front passenger being distracted by the massive flat touch screen. The traffic light turned green, and had I been beside the Tesla, I would have beaten it across the intersection despite all that electric motor tech in the car.

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

I've missed the light turning green while just looking out the window (our car has no screen). As long as people are only distracted while waiting at a light I wouldn't worry too much.

Except they're not only distracted while looking at their screen when stopped. The distraction continues after they start rolling again - one thing directly leads to another here.

1. According to this source, the infotainment system arbitrates flashing other ECUs.

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.

Well, the model 3 lacks a normal speedometer, it's in the screen. For that car, it's related to safety.

There's still the problem with exploding phones and batteries so even if it's just a phone it can go wrong in dangerous ways. (If it happens on a plane for example)

The iPhone has to reliably connect for emergency calls and provide accurate location. That can be life or death. In fact, "Apple isn't ready to engineer phones at a life-or-death standard" was a fairly common critique of the iPhone in the early days. In response, Apple ran a little PR campaign around their radio engineering efforts--they had a web page that showed all the cool-looking rooms for testing radios, which they invited a couple reporters to tour, etc.

> The iPhone has to reliably connect for emergency calls and provide accurate location.

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.

Is a Tesla steer-by-wire? No.

It seems you have to prove that failure of these hack-y systems would lead to the disastrous result you postulate.

Brakes aren’t either. You might lose ABS or boost, but you’ll still have brakes.

That PR tour was in response to "AntennaGate" when Apple failed to engineer a phone to a life-or-death standard (well, if you were "holding it wrong").

Didn't the iPhone use a dual processor set up like the other manufacturers at the time? One ui/app processor and a separate radio processor stack?

There's a lot of EE black magic around antenna design.

Evert smartphone separates the baseband processor from the frontend android/ios/... Arm processor.

Even PC's have now a hidden baseband processor for the mission critical stuff, like backdoors and surveillance.

Are there any interesting papers on formal verification of some of the most modern machine learning algorithms?

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?

lol they'll never bother with that

Read the Barr report on Toyota’s unintended acceleration incident. They didn’t have the right failsafes and watchdogs and only a single bit was responsible for a critical feature. Meaning memory corruption or a cosmic ray flipping the bit can cause disaster. They didn’t follow anywhere near best practices in their firmware development. It’s not just the young upstarts that mess this up by being “reckless”

Indeed, cars currently move fast and break things. Tesla is an improvement on current situation.

As an embedded engineer this was:

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.

"Car infotainment" includes the maps and GPS navigation, doesn't it? Something that many many drivers struggle to multitask with.

Especially considering that the engineer was partially blaming Bosch as a supplier that made these processes necessary.

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.

It sounds more like they didn't follow the specific way bosh requires you to use their HW. I highly double VW or others would use Bosh if hacks are required to get them to work.

Updating the software of node are usually in the automotive industry only allowed by trained technicians. Allowing the updates to be done without turning in the car so a shop is the big difference. Software update in is complex and hard and error prone, for quirks like the bosh stuff here. Many of the big players see it as almost impossible to try to do as Tesla and have it done at the users home.

Not sure if any of those brands try to blast firmware updates over the net with a "push to prod" mentality...

Remember the Toyota uncontrolled acceleration bug and the report that came as a result of the trial. It seems like software is a bit of a second thought for some incumbents too.

It is common knowledge that Toyota uncontrolled acceleration bug was completely imaginary, see for example http://revisionisthistory.com/episodes/08-blame-game

I started listening to that podcast a few weeks ago, that ones one of my favorite episodes. Can highly recommend it.

Check out this, and the linked court transcripts linked therein: http://www.safetyresearch.net/blog/articles/toyota-unintende...

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.

Is it what people call fake news nowadays?

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.

Is it possible that the timing on your contact with them made a difference? It seems that NASA/NHTSA concluded in 2011 that it was a mechanical defect, but research concluding in 2013 showed that it was totally possible to have been caused by the software.

At least according to the summary based on sources used for Wikipedia:

https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...

Hey,

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...

Perhaps have a look at Koopman https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... and Barr http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...

The linked trial testimony says otherwise. The engineer states he found bugs, and theoretically it might be possible he was unable to reproduce. Further, he evaluated the software against his own coding standard which was a variant of another.

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'm rereading, and I think you are right. I misremembered.

Not sure if you're being sarcastic or not, but the Toyota issues were not caused by any software bug. Most cases were caused by people hitting the wrong pedal. The others were caused by floor mats that were a bit too long, causing the gas pedal to stick.

https://www.caranddriver.com/features/its-all-your-fault-the...

Regardless of whether the acceleration were caused by the software or not, the testimonies for the software experts called in to review Toyota's source code for the case were eye-popping:

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.

I mean it's a bit depressing but its only eyepopping if you suffer from murray-gelman amnesia about literally every piece of software even written.

When you're paid to find errors in software, you point out every conceivable bug you can see.

People quote this repeatedly here, but I'm not sure what it's intended to demonstrate.

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.

> 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.

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.

> I once lost proprioception of my foot

That's fascinating. I can say that is something I have never experienced. Does it happen to you with any regularity?

No, I was just using a fancy word I've always liked because it seemed to describe things as best I could.

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.

Koopman has a talk here on his blog that has more details about how ETCS (Electronic Throttle Control System) is safety critical. "If a driver pumps brakes, loses vacuum power assist...WOT requires an average of 175 lbs of force on brake pedal"

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...

"Sorry, this content is not available in your region".

Welp, sadly I am not able to read your source.

I actually experienced this with a rental car in South Africa. I drove for 10+ seconds with the engine revving at full blast with the car in neutral and no mat impacting the pedal. Both feet completely removed from any pedal, using the handbrake to decelerate and pull onto the verge. The floor mat thing is total deflection by Toyota. The only thing that reset the accelerator was turning the ignition off.

In the case, this could possibly have been limp-home mode. I believe this engages if the ECU thinks the throttle pedal is faulty. It disables the throttle and applies a constant throttle setting to allow you to continue driving slowly - it sounds alarming in neutral, but once you put the car in gear, the revs drop as the engine is required to produce torque.

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.

>Why is this interesting or surprising? Of course almost all challengers have hacky tech under the hood because they don't have the resources

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.

That’s what it takes to be a challenger in that space. For example, most biotech series As are $100M, because that’s just what it takes to compete (but/lease equipment etc.).

"Challenger" was used to imply lack of resources for improving software quality.

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.

because about twice a thread some one claims Tesla Has A Software Culture as a reason that GM or Toyota or VW won't ever be able to compete with them.

They didn’t say it was a good software culture.

These are cars first and foremost. They should not be given a hand waive over "break things and move fast".

Indeed. That's the driver's job.

"Or how Microsoft won the desktop starting from a single user, cooperative multitasking system (vs all the sophisticated Unix-based systems)."

All of the what? The only competition on the desktop when Microsoft won was QDOS.

When Windows came out, there were desktop unix(ish) systems, e.g. from Sun or Apollo. Of course they were an order of magnitude more expensive than a PC, so it's hard to argue that they really competed. At that time, if you needed a unix workstation, a Windows PC was not a viable substitute.

well it's interesting because it gives an insight for those of us who aren't there how things actually work.

Musk fan or not, you can't deny this has no interest

there are 2 kinds of startups: those with shitty software, and those with shitty software and customers

Remember Theranos?

For every good success example, there is a good failure example.

Theranos never had a real product or sales and was a fraud from the beginning of institutional investment. Comparing them to Tesla is pointless and has been done to death.

My point certainly wasn't to compare Tesla to Theranos. I didn't mention the two in one sentence.

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.

Everyone knows what you're implying when you bring up Theranos in a thread about Tesla.

Lets pretend that's true. Then why mention it?

In 2004 PHP is the standard. Any MYSQL is still the standard.

what about the iphone demo was hacky ?- just curious

https://gizmodo.com/the-iphones-first-demo-was-buggy-as-hell...

>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.

That's actually pretty interesting to me. I specifically remember seeing those multiple iPhones in the demo and wondering what they were for. Jobs kept putting one down and picking up another one to do a different part of the demo. It never occurred to me that the iPhone wasn't fully cooked and couldn't handle the demo without problems.

Steve was a full on sales person and was really, really good at presentations.

> Of course almost all challengers have hacky tech under the hood because they don't have the resources.

Tesla has a larger market cap than Ford, GM, or Honda.

Market cap isn't a measure of the resources a company has at its disposal.

That's because Tesla has a ridiculous valuation.

Reply on news.ycombinator.com