Live data from Hacker News

Former Tesla Firmware Engineer Discusses the System

twitter.com

441–450 of 589 posts

Re: Former Tesla Firmware Engineer Discusses the System

#441

Earlier quoted context omitted.

It's not a shift. It's the language used by the rest of the industry including manufacturers, not just private owners.

What's being scrutinised here is the difference of being forced to be a part of a fleet as opposed to separately owning and controlling your own fleet. If you buy a Tesla, you will not be able to control access to it without limiting its normal set of features. If you buy a normal bicycle, you always have full direct control of it. No software updates, no data uploading, no tracking. Normally fleet is reserved to mea…

I mean sure, but this isn't some encroachment by Tesla is the point I'm trying to make. At any car company for decades the set of cars for which you're currently responsible for sustaining engineering is known as a fleet.

And I think it's fair for the engineers that have responsibility to have an internal sense of partial ownership.

Re: Former Tesla Firmware Engineer Discusses the System

#442

Earlier quoted context omitted.

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 i…

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

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

Re: Former Tesla Firmware Engineer Discusses the System

#443
post #385

Earlier quoted context omitted.

Ubuntu and Centos come pretty naked; what would you strip and why? Im asking because I run few instances with very heavy traffic and have no issues whatsoever. Just added nano and fail2ban and it runs with no issues for about 2 years now.

Those two, particularly Ubuntu, are the opposite of naked. Try something like Arch.

Arch? Arch ships packages with debug symbols and docs included, and takes over a hundred MB for just a base install! Alpine is way smaller; base image under 10MB, packages broken apart so you only get binaries unless you ask for more, linked with musl to make it even smaller.

EDIT: This is meant to be a bit tongue-in-cheek, but I seriously do prefer Alpine over literally every other Linux distro I've yet seen for minimalism. Also geared towards embedded-type work.

Re: Former Tesla Firmware Engineer Discusses the System

#444
post #8

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 m…

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

Re: Former Tesla Firmware Engineer Discusses the System

#445
post #220

Earlier quoted context omitted.

Probably related to his use of Windows early on at home and at Zip2, PayPal, etc.

I have heard in some youtube video that one of the first post-merger conflicts at paypal was about elon pushing for Windows NT (and presumably MSSQL) instead of Oracle (presumably on Solaris).

In fairness: Competing with Oracle is one of the very few times when choosing Microsoft makes sense.

That felt weird to type.

Re: Former Tesla Firmware Engineer Discusses the System

#446
post #256

Earlier quoted context omitted.

Is that like, you really don't need a fancy RTOS for this stuff 99.999% of the time, although sometimes you do? Or truly, despite the life safety element, there is never any need for RTOS.

In every application I can think of off the top of my head, but mostly in the ones that apply to Tesla, you truly don't, except when the law or a contract says otherwise. I'm sure there are exceptions for things that don't apply to Tesla (or for that matter SpaceX). Here's what's inside of every autonomous vehicle ever made: a message-passing subsystem, sensors, fusers, navigation, dynamic control, actuator device dr…

Do you have a book where you just explain various things in this style? I’d buy it.

Re: Former Tesla Firmware Engineer Discusses the System

#447
post #422

Earlier quoted context omitted.

True, but they also did that while maintaining the lowest launch prices in the industry and presumably they can now decrease that even further if they need to. So while it may not be the most efficient process, the overall process is much better than their competitors since they can launch for so much less money.

At the end of the day that still doesn't really answer the question: "Do companies save money by mistreating employees?" I don't think you can answer that question by just looking at Tesla.

Of course you cannot answer that based on a single companies culture.

I'm refuting the statement that "saving money by paying peanuts, grinding people down to burnout, and then constantly having to rehire/retrain new people as the old ones leave" is unanswerable in the current context based on 1 company especially because this company seems to be destroying their competition.

Re: Former Tesla Firmware Engineer Discusses the System

#448
post #385

Earlier quoted context omitted.

Those two, particularly Ubuntu, are the opposite of naked. Try something like Arch.

Arch? Arch ships packages with debug symbols and docs included, and takes over a hundred MB for just a base install! Alpine is way smaller; base image under 10MB, packages broken apart so you only get binaries unless you ask for more, linked with musl to make it even smaller. EDIT: This is meant to be a bit tongue-in-cheek, but I seriously do prefer Alpine over literally every other Linux distro I've yet seen for min…

Fair enough, and you're quite right about Alpine being geared more for embedded. For general use I find Alpine a bit of a pain due to lack of systemd (bring on the hate ;)), and of course lack of docs hurts usability a bit. With regard to debug symbols, I like what Redhat and Debian are doing with an embedded build id linking binaries to separate debug packages.

Re: Former Tesla Firmware Engineer Discusses the System

#449
post #305
post #207

Earlier quoted context omitted.

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

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.

Re: Former Tesla Firmware Engineer Discusses the System

#450

Earlier quoted context omitted.

I used to work at SpaceX on avionics software, in a role very similar to OP, and my experience was similar in some respects. The tech and products were complex. The turnover rate was high and training new hires was a lengthy process. The new projects coming down the pipeline never ceased (this was during a period where FH/F9-1.1/Dragon/Crew was all under design/development and constant iteration). It was fun for a yo…

I heard the same thing about the burnout and turnover. Do companies really think they are saving money by paying peanuts, grinding people down to burnout, and then constantly having to rehire/retrain new people as the old ones leave? Meanwhile the code is a mess because nobody has been there longer than a year and there is no architecture or design continuity. Just frantic patches over other frantic patches by burnt…

Does paying peanuts here mean—not very top of market? Or?
Post reply on HN