Fatal C error took her life
Вставка
- Опубліковано 14 гру 2023
- In a tragic car accident in 2007 software defects played a key in causing a Toyota Camry to accelerate out of control and crash. Today we dive into the tragic and fascinating story of how memory safety bugs in critical-systems can lead to disaster.
Free Rust cheat sheet: letsgetrusty.com/cheatsheet - Наука та технологія
📝Get your *FREE Rust cheat sheet* :
letsgetrusty.com/cheatsheet
Any code where failure results in death should be formally proven. Car control systems should be held to the same standards as avionics.
All avionics systems are formally proven? Wow. I mean I would expect that to be the case, but analyzing and proving millions of lines of code especially when so many electronics are in play, must be a hard job.
@@tathagataroy5153 laughs in boeng 737 max
@@LeonardoAMsntslaughs in safety standards and statistics in aviation are better
Cars and planes should both follow MISRA C standards, that's how we write code at BAE Systems. Memory leaks or buffer overflows or unguarded pointers etc are all statically analysed. MISRA isn't perfect but it goes a long way to detect defects.
The key is always thorough testing procedures. In aviation and space travel things are generally done extremely well. That's why things go fine most of the time.
However even these have their fair share of problems. Googling for plane crash software failure gives me really interesting results.
I found things about about uncontrolled drops due to sudden AOA changes on a passenger craft and things about a uncontrolled response to turbulence of on a military craft. Not good.
500k lines is absurd for something that can be straightforwardly controlled mechanically.
They need their telemetry, adware and spyware to work.
this shows your lack of knowledge of automobiles lol. there are many advantages with drive by wire.
@@chudchadanstud right cause your accelerator peddle is spying on you. let's loosen the tinfoil hat and touch some grass.
@@Megasteel32 Yes. It actually is. It's called telemetry. The Manufacturer can simply bring out this data to prove you pressed the wrong pedal when you take them to court. They can also use that data to optimise their next design.
@@chudchadanstud I hope you realize cars don't have black boxes like planes do. they aren't recording your every move lmao. I know what telemetry is, this ain't it.
It wasn't just lack of memory safety in C though, the report was scathing. It was probably some of the worst C code ever written, with tens of thousands of global variables etc. The report said it was impossible to test or even reason about the software.
i wonder why NASA couldn't find any bugs in the code..
@@vmachacek I mean they did only get bunch of incorrect parts of it.
Sounds like modern AAA games that released prematurely
Never have I seen such rust Zealotry (and I've seen a lot) than taking the story "Toyota wrote some diabolically shit code" and turning it into "C murdered a tonne of people" lmao absolutely wild
So... in conclusion: C amateurs. The presentation says that many different memory bugs were available in the Toyota's source code
i thought that she wrote a C program, got an error or segfault and took her life
I've been watching this story over the years. I suspected this right away, it was obvious. Glad to get the concise story!
sudden acceleration happened to me too-it occurred in a Honda ---I was in a bumper to bumper situation on a freeway in Los Angeles suddenly my car's engine raced to extreme high rpms all I could think was to slam on the brakes-i pressed very hard as the car was inching closer and closer to the car in front of me-in a moment of panic turning off the ignition did not occur in my mind at the time all I could think of was to keep from hitting the car in front of me--the brake pedal almost hit the floor then the engine went back to normal ---strange experience never happened again
I would like to note that **NASA is able to write safe space-grade mission-critical software with C.**
They do this under a very, VERY strict set of rules. Some of which include "No heap allocations." and "No for loops without a constant upper limit."
It's just not the embedded software memory issue, it was also the issue of using global variables. I always say, don't use globals, half of your problems will be solved right away, and you don't need to use Rust just to follow this principle.
Yes, but the problem is that not everybody is like you, in fact nowadays they like to be different. That's why rules are so important, to protect us from ourselves.
To be honest, if i want to bet my life, i would prefer to bet on a car that were made by technologies that made it harder for the manufacturer to make mistakes, than the technologies that rely on developers' will to do the right thing. I am and have seen enough developers to know that we are not a particularly ethical bunch, and when the pressure is high enough, we would go for the easier route. Sure you can have similar bugs in rust. But you should go out of your way to make those bugs. On the other hand, yes, you can always make a good, robust c code. I just don't think that i would be able to trust more than handful of code bases (Linux, SQLite and probably curl) on delivering it.
@@AmirHosseinHonardust In developers' defense, it's not them wanting to use C rather than companies' lack of interest in rewriting a lot of code, along with issues with software certification. I can suggest to use a certain piece of technology but I cannot take decisions alone. I work in the avionics industry in a mission critical environment btw, I expect safety critical software to have even stricter rules.
-I'm not aware if memory safe languages like Rust can be used in that context even if they could make more sense.-
Edit: I've just finished watching the video, good to know.
This, and many other rules like those in NASA's or MISRA's principles are how the issues were mostly solved in practice. But all these sophisticated rule make things much more complicated and hard to apply IMO. Using something like rust should and will be a modern way to solve it entirely.
@@ishi_nomiJava solved the problem decades ago.
Car manufacturers should be forced by law to open source their software. There should be no secret.
Everyone* should be forced
@@JorgetePanete no, some things need to stay private
@@arson5304 No, only private keys are private, and those don't belong in source code. The users _need_ to be able to inspect their stuff, and "their" becomes the users' when it's on their device.
@@arson5304 i’d say if it is a physical product with embedded code, the source should be available as it is an essential part of device. If it’s a web-based service, the server side can remain private but client should be still open and compilable so that it can be verified against the code on the device
@@JorgetePanete I compare Open Source to the right to self repair. But honestly, I don't know if every software should be forced by law to open source. But for things like cars or medical instruments, where the life of people depend on should be forced.
First thing I learned in my embedded systems course at university was to never use the heap in mission critical embedded applications.
If you ever work with PLCs, which are like big, glorified microcontrollers for industrial applications, heap memory generally doesn't even exist. In fact, on some platforms there isn't even stack memory, it's all statically allocated at compile time.
@@GuyFromJupiter On our planes/vehicles etc (at BAE Systems) we only use the stack if we can mathematically prove that there is no code path that means we exceed a fixed size (e.g. 1MB) stack. We do not have a growing stack, it's fixed. And yeah, no heap. No dynamic memory at all.
500k lines for that???? wtf were they cooking in Toyota software department
Maybe they get paid by the KLOC. ;)
HOW IS THAT EVEN POSSIBLE
Until toyota would start using unsafe 😂
It's not C, but the capabilities/skills of programmers that caused the fatal error.
I think you would've had less backlash on this video while maintaining a majority of the message if you cut it off at 8:30
Uncle Bob has talked about this. Regulate yourselves or you will be regulated.
And yet Bob Martin remains unregulated
@@RoamingAdhocrat Because he is self-disciplined and practices clean code.
Im worried it might become impossible to buy a car without electronics.
I just want lights and steering enhancement.
It is already impossible. Cars have to come with certain electronic assistence systems according to safety standards. Which by itself is not a bad idea but in my opinion such systems can often also be dangerous themselves by making the car behave unpredictably. Both manufacturers (like Tesla) and governments are playing with lives, manufacturers because of profit and governments due to incompetence.
@@SaHaRaSquadI think its naive to call it incompetence. The government is pushing these systems for control over the citizens. They want to be able to control your car remotely. When these systems are not even necessary. I really hope some open source low-electro car manufacturer would hit the market. That could be a good business idea.
Finally a good video, straight to the point without any cheatsheet bullshit.
To be fair towards C: I wonder if something like Frama-C would have prevented the accident.
You're making a solution to the wrong problem. The over digitization and electronification of mechanical systems is the issue. This reaches its peak in "autopilot" cars, electronic gear shifts, and stuff like this. A proper mechanical system can have redundancy and failsafes. It can be isolated from other systems. The issue with electronics is how interdependent and complex they become. I'm fine with sensors and relays and some cpu usage, but the primary functions of a car (and most mechanical systems) should be as simple and stupid as possible.
I don't see anything wrong with it, given that there's emergency mechanical equivalent brakes as well.
Waiting for @ThePrimeTimeagen video on this :D
It could be a great idea to make a dedicated video about the Ferrocene.
Sad for the the loss, yet a very interesting video.
Which models are affected? I have a Toyota from 2011
It pleasure to listen to you. Unlike other programming bloggers whose speech speed fells like 1.75x you talking at very optimal speed by my feel. Thank you for content.
I love C more than anything, and will probably use it for my personal projects, but maybe, just maybe, Rust && Zig can give me some peace of mind for mission critical stuff. Though I do follow NASA guidelines to the T when writing C because it's actually easier on the pea brain I have.
I wonder if we'll start seeing less language/package bloat in the future with Rust. My ideal would be a minimalistic language like GOlang but with the benefits of rust compiler. (don't @ me lmao)
They wrote a firmware for an ECU and didn't follow MISRA C guidelines? Even I know that you must follow this guideline for critical systems, and I don't even write firmware for critical system.
Dude, I love this Kile Hill style video 😂
Rust good
C bad
It’s the Therac-25 problem all over again.
This video raises some pertinent points, but the bigger failure at Toyota was, from the sounds of it, the culture and improper engineering management. You can make dangerous products with any language, and from that PoV this video is a cheap shot.
Also, the rust compilers themselves are massive. Have they been subject to any formal proves?
Daily reminder that the therac's code was actually perfect because it was just designed for an older version of the therac which had hardware interlocks, which the therac 25 did not. I know people doesn't like rockstar programmer stories, but I think it is very important to be aware of the real reason people die when a defect is found in a system. I too thought the therac was entirely on the programmer's fault, but their code ran flawlessly on the version with hardware interlocks, meaning the therac is simply a story about a company cutting one too many corners, leading to the death of people. Doesn't fully justify the code, but let's be clear about the real problem in each scenario... Toyota's case was a software error that happened because there was a bug in the program, the therac's case was a software error that happened because the code had originally been written for a completely different machine which had completely different hardware.
As for ferrocene being approved and whether they have gone through any formal proves... just a few days ago it wasn't considered to be viable for safety critical software, and I haven't been able to find anything about them undergoing any formal proves for any length of time so yeah...
Also, I think this is another worrying problem that is important to discuss: They are acting like the compiler itself is somehow the one that played a hand in killing people when the problem with the C code was that it was simply wrong in the first place. It's good that they are adopting safer languages, but I'm afraid that the main problem is not going to be fixed, that problem being programmers who don't know what they are doing being involved in the creation of safety critical software. If we're moving to languages that allow us to write safer code, we should also move towards hiring programmers who actually know what they are doing when dealing with an embedded system that runs software critical to keeping people alive.
Going back to the therac's example, as much as the code ran flawlessly on the version it was originally designed for, it still had no documentation and the error messages were simply random numbers with no further explanation. Even if the code appears to run properly, it is clear that the incompetency that could get someone killed was already there. Even if the hardware had been kept the same, the margin of error is extremely small and we can't be dealing with shit like that when people's lives are at stake.
Personally, it looks to me like the core problem is not going to be fixed any time soon, and now we're simply going to move to having Rust programs that get people killed, as well as C programs that get people killed. Only that at least Rust can hand hold bad programmers into writing less deathly code, but considering the insane shit some people write even in Rust, it is just a matter of time before someone dies with code written in Rust. Only that this time I'm afraid that it might be harder to make a case for software failure because it will just be assumed that since it was a memory safe language, no software error could have happened...
@@tiranito2834how hard can it be to audit unpopular libraries and unsafe blocks? But you do have a point. It's scary the thought that something outside of the programmer's control can cause UB on critical operations
@@antoniong4380 Yeah, auditing a library for safety may seem simple, but when you're dealing with extremely large codebases written by many different people, auditing the safety of a piece of code becomes harder. Look at how long ferrocene took to be approved for safety critical software, and even then it was done prematurely in my opinion as it didn't go through as many tests as other industry compilers used in safety critical software, this exception being magically given to ferrocene just because it's Rust, and Rust is supposed to be safe... but what if the compiler has a bug? Then no matter how good and perfect your code is, if the generated binary has a mistake, people will get hurt.
We could also argue "how hard can it be to audit X thing", even for C or any language + library combination for that matter... and that still would have a margin of error. Your language and library of choice are not going to magically make your software safe, you really need programmers who know what they are doing and can take the time to test and properly make their code when dealing with systems that are safety critical. That is why it is so important to make sure that not only is your software safe, but the hardware as well. Even if you have the most competent programmers in the world, if something goes wrong, it would be ideal for a hardware lock or mechanism of some sort to exist as a fall back to prevent the system from falling appart.
Again, look at the therac 25... the code was safe because the programmer was just that good. But he never really anticipated for the hardware to be compatible but different from the one it was originally programmed for. And it's not like you can really cover every single case from the software side. Even seemingly perfect code can run into UB if some hardware failure were to happen, or if the code runs in a compatible architecture but with different hardware components. Imagine the case of a hardware interlock not being present and a race condition leading to great injury. Imagine a bit flipping and not being corrected properly, extremely rare but possible, and that is completely outside of the programmer's control and you don't know what could happen.
So while there are elements completely outside of the programmer's control, it is important for the programmer to do as much as they can to ensure that the code they write can at least attempt to handle the greatest amount of edge cases possible to prevent any fatal injuries. It really is scary to know that you can still come across UB in situations completely outside of the programmer's control. But this also shows that safety is not just a code thing. Even the hardware itself has to be safe, otherwise the code is going nowhere, obviously.
Honestly there are also places that should have nothing to do with software, and everything to do only with mechanics. Today it seems people started sticking software into places just because. Like it or not fine electronics is fine electronics. These days fixing a broken tail light on some cars can cost $5400 because instead of a simple circuit - it is connected through computer, which now has greater exposure to external short circuits due to moisture etc in the light itself, which can cause control unit to fry. So WTF is that? Honestly if I was to pick between +20 or 30% reliability and +20 or 30 percent efficiency - I'd pick reliability every time. These car manufacturers need to stop connecting every single sub-system in a car to the computer. It's stupid.
You are discounting the improved safety that can come from connecting these systems to a computer. If done correctly, there are many ways that safety can be improved by connecting sub-systems to a computer. Traction control is a perfect example. The modern traction control systems are capable of doing things that would never be possible from a purely mechanical solution. Its just a compromise. If done correctly it will improve safety. You can't use an example of doing it incorrectly to say we should never do it.
@@Nick-tm2sw There is no improved safety that comes from connecting a blinkers or windshield wiper motor to a computer. Funny how on the web people are trying to decouple things into micro-services, but in car industry engineers are stuffing everything into computer.
@@dmitryrodetsky5573 I can tell you first hand that decoupling everything into microservices is not always the right thing to do. Its the same with car systems. I agree that turn signals should not be tied into a computer. But many things should be. Someone could argue windshield wipers should be because it would turn them on automatically for people that tend to not turn them on soon enough. That could prevent a wreck. Your example of an ECU being fried because of a short in a turn signal circuit is really an issue of poor design since there should be circuit protections in place to prevent that. I agree that not everything should be tied into a computer. But we shouldn't make the mistake of thinking that is always a bad thing either. A lot of safety critical programs are written in low level languages like C, even a lot in assembly. You just need to take a lot of extra precautions when doing that. Many of these systems have functioned for decades with no loss of life.
@@Nick-tm2sw Sorry man. In my opinion - the less automatic crap in a car - the better. Less things to break that cost a fortune to fix. Few years down the road all these gimmicks will put an otherwise perfectly good car in a scrap yard anyway. It will not be fixable by regular mechanic, but only dealerships, which tend to rape people financially. I see how it is beneficial to car manufacturer and dealerships. On top of it many of these gimmicks give a false sense of security to the drivers. They can't feel that the road is slippery for example until it is too late. So bottom line the most important safety device in a car is the driver anyway, so I'd rather be a safe driver and encourage other people to do the same. And no I would not be comfortable letting AI drive me around, and I have good reasons for that.
@@dmitryrodetsky5573 Well everyone is entitled to their opinion. Personally I trust computers more than any driver on the road. A computer is always going to be better at preventing a wreck in slippery conditions than a human. If done correctly the driver never needs to "feel that the road is slippery until its too late". The data shows that this is the case as well. I would rather have a car that protects my family but goes to the scrap yard in 10 years than a car that lasts for 50 but does little to protect them. Cars are cheap, life isn't.
Given ECTS was introduced in 2001, what changed in 2010?
Was Toyota forced to open the source?
This must be the wierdest way to convince someone to move to Rust.
Average C program experience
Not sure you are better than the "average C programer".
@@IBelieveInCode programmer*
In theory rust would help but you still need a specific set of guidelines for writing these types of software because its not difficult for someone to just start working with unsafe code that does still allow for these types of errors.
unsafe does isolated the part of code that can cause such kind of problem with makes it easier to find and test then having to perform memory safety checks over the whole program. Also even in unsafe Rust still does help because you still have access to better slices that do check for length, option instead of null etc.
it's*
@@mateuszschyboll2310 It depends on the type of stuff that you're doing with the code. A few years ago I worked on a key value store for secrets and the system really needed to use unsafe all over the place. For example, I had to use unsafe to implement some of the cryptographic algorithms and I used unsafe to implement non-contiguous memory blocks as well as a memory allocator/garbage collector. With the cryptographic algorithms, you could do exactly as you said because they are isolated from the rest of the code. However the memory allocator is pervasive across the entire application because all of the memory chunks inside of the vault were being allocated using the non-contiguous memory format (and actually, the allocator worked globally across any program that imported the library, there was a pass-through for normal data outside of the vault to use the normal allocator behavior for rust). There were cases where I ran into undefined behavior and it became difficult to debug because of the way that a complex type or an algorithm interacted with the allocator. In other words, the undefined behavior didn't originate from the memory allocator itself, it occured in other parts of the program even if the stack trace pointed to the memory allocator. Something also to keep in mind, as you start to use unsafe in your code, it becomes extremely easy for it to proliferate throughout the codebase if you're not careful. In a lot of cases if you have a dependency that is unsafe, then the function or algorithm needs to also have unsafe flags inside of it. When you start to embed unsafe blocks inside of one another, it becomes a lot harder to pin down where the errors are happening.
There are organizations in the US government that use a language called Ada. Ada has extremely strict safety checks and it's very difficult to bypass them. If rust wants to compete with Ada, then it's very likely that the organizations will set up a style guide that highlights a subset of rust which can be used for these types of systems. I also wouldn't be surprised if they implement their own compilers that remove features like unsafe. Another thing to keep in mind, many of these APIs are already written with Ada or c, which means that they will have to use unsafe to wrap the existing code.
With all that being said, obviously rust can work this way. In one of the last projects I worked on, I used rust with elixir. Elixir is a fault tolerant language that focuses on using processes. What makes it fault tolerant is that each process can crash and another supervising process will bring it back up, sometimes passing the old state into the new process. When you start to add other languages, you have various ways of connecting them to the erlang virtual machine, each of which has a set of pros and cons. The way that I did this was with a mechanism called native interface functions (nifs). One of the major cons of using NIFs with languages like c is that they can bring down the entire program if they run into undefined behavior which means that your elixir code is less full tolerant. Rust solves this problem by way of its result and option monadic types. Because you can return the error from a function rather than throwing an exception, you can let the elixir layer handle the error without crashing the rust layer. Basically, all of the rust code that we used was very pure so as to avoid any undefined side effects. When an error occurred in the rust nif, it would return that error back to the elixir layer and the elixir process could shut down and restart; this worked extremely well.
Anyway, the point of all this is to say that while rust certainly can be used this way but the language doesn't completely prevent the developer from treading on potentially dangerous ground. Having been in the industry for 25 years, I've seen developers take shortcuts even in cases where safety is of the utmost importance. Usually it's not even the developer's fault and instead is a result of higher-ups putting pressure on them to finish faster.
@@mateuszschyboll2310 Yeah, but you can also check for length instead of null in C, but that doesn't magically make all C code safe. The problem that the OP is talking about is the fact that some day, some incompetent programmer will make the mistake of using some insane unsafe piece of code that is wrong and will get someone injured or worse. This can happen in C, Rust or any language for that matter... When you're in embedded, no matter how many safety features you use, if the programmers writing code don't know what they are doing and simply dive into performing unsafe operations, they will most certainly end catastrophically, even if they are using Rust... to fix the problem you don't just rely on a safer language, you also rely on making sure that the developers you're hiring actually know what they are doing or at the very least do not decide to do anything insane. Which is why even in Rust you should have guidelines to prevent deathly code from making it into prod.
dude i have toyota, this is scary
I feel like there's a lot of negative feedback in the comments here! I think its a very good video and I
feel like there would be a lot less nevative attitudes if it were about aircraft software, for some reason. We need to recognise that our software is important and we need to be more accountable to it.
See the original video and slides by Koopman. This video removes all information and adds in Rust advocacy and monetisation. It's fascinating, to me, how this video left in all the problems found in the original code, but left out what the eventual problem was that caused the unintended acceleration.
Maybe because the problem that caused the UA was not something that Rust would have fixed anyway, and because the point of this video is marketing and not information, they left it out.
rust is a good language BUT HOLY HELL you do NOT have to use someones death to tell people to use rust
fr
you guys are idiots fr
I was thinking this the entire time watching this video. But on the other hand, Software developers that programm safety critical systems should strive to do as much as humanly possible to protect users. Doesn't mean you have to use Rust though. Maybe it was his take on why Ferrocene beeing recognized is a big deal?
Sorry you feel that way. The intent was to raise awareness of the dangers of memory corruption using a real world example.
Why not? Some of us work in these industries, this is important to consider.
Are you targeting thePrimeagenReact reddit with this type of content?
I recently wrote a controller for solonodes and safty switch for an engine using Rust. 500,000 lines is fucking crazy for this.
In the context of machinery, 500,000 lines of code in one binary is just about the reddest flag possible.
man I am sold!
Eres muy bueno en lo que haces, sigue asi ❤
500k sloc? That's insane
Simply, just use preditctable mechanical counterparts...thats the lesson
We font know if the actual root cause with a memory management issue... Maybe was just a bug in the algorithm...race condition...bad management of sensor input data...
Maybe not put computers in vehicles?
As i like Rust
As i rember it was stack overflow, not strictly typical memory error but rather some one not fully competent in embedded wrote code, without knowledege on limitations
Well, that's a sales pitch for Rust 😁
Breaks and other critical systems should be mechanical. I like Rust, but I hate this video. The conclusion is wrong. Toyota should be severely punished for designing a critical system this way.
Rust won't fix all the issues in this world no matter how hard you push it.
Exactly this. How can this be the only comment that is sane in this entire comment section? Literally, why do we need to stuff software in every single place? I mean, sure knock yourself out, add as much software as you want in all of the components of your car! But also offer a fully mechanical system that we can fall back to in case of failure. There are so many things that could fail when you rely on a digital system. We can't live in an era where we have far more unsafe vehicles than we used to in the past. Things are meant to get better, not worse.
Exactly. I didn't like the video because it made it look like C was the problem (when it was bad programming, which could have been prevented woth tools) and that Rust was the only solution (languages like Java solved the memory leaks and overflows decades ago). And people act as if programming in Rust is immune to bugs. I respect Rust, but people shouldn't trust it blindly. And the last point about mechanical systems is also spot-on. We shouldn't put software everywhere.
there will be some day where 1 million people have to learn rust here *just like me* 😅
You can have the same in Rust with just some .unwrap() resulting in a crash.
ONLY IN OKLAHOMA
In the end, they would make terrible software using Rust as well...
Yes but it is hard (very hard) to create invalid pointers or buffer overflows in Rust because of the strict static anaysis, type safety and borrowing rules.
Here the problem is not C programming language, first it was company for not forcing strict rules when developing the sofware/hardware, second the developers made the software again without strict guidelines, third all programming languages have bugs, so Rust is not bug free... and again the developers and companies play a important role here for no endorsing more strict rules and guidelines for developing software, it does not matter the programming language because at the end even enforcing strict rules/guidelines if the language has bugs the strict rules become nothing
> Developer Writes Unsafe Code Knowing It Will Cause Undefined Behavior
> **Undefined Behavior Occurs**
> **bad language**
"Developer Writes Unsafe Code Knowing It Will Cause Undefined Behavior"
Except it wasn't so obvious back then.
yes, you are right. even without first 2 items :D
If you're so sure that the developer knew, you've never coded in your life.
Programming languages are kind of adding discipline to programming.
And C comes with the least.
Writing in safe languages is like OSHA compliance but for software.
Would you say:
"a table saw is known to cause injuries by human error
Injury occurs
Bad table saw"
Exactly the same situation here. Unsafe language is easier to avoid than making human errors.
@@shambhav9534exactly
The bug was an important failure, but nothing restricts the driver from applying full brakes, that will always get you stopped, although ofcourse with a bit of delay.
Many fatal flaws have existed through out the years due to memory leaks, many of them without even having the possibility to perform an emergency action. Even in aviation, where extensive testing and validation is required many memory bugs have escaped from the process unnoticed. Same has happen many times to different spacial agencies, with important crashes into the Moon and Mars.
It's almost imposible to scape from all memory bugs and events like data races. If the programming language allows you to create such bugs at the end of the day, somebody is going to program them.
man I was really hoping you wouldn't turn the death of that woman into a rust ad
I mean, that's sad and all but that shows why a language like rust could be needed
I don't think the video is monetized tho. Shows that memory safety is to be taken seriously
Ad? It's a public service announcement if anything. Fatal programming errors are no joke.
@@skellderknowledge3621 rust can't solve anything, there's still a chance for memory corruption, cosmic rays etc. software shd not be controlling acceleration at all
@@haha-hk9txexactly. That's why I removed brakes, seatbelts and air bags in my car. They can't stop ALL problems (what if I get shot by a sniper), ergo they are useless /Nirvana fallacy
Rust code can still contain bugs. The compilation step does not catch all bugs.
This is 100% a mechanical issue. Who designs a system in which task death results in an uncontrolled failure?
Wow
This Rust hype train is getting out of control
Someone will repackage this exact event in a more click bairy manner and better thumbnail and it's gonna get 20m views
Well... I appreciate your work, but my understanding is that if Toyota released a product although they knew it was faulty, then no technology could protect them. Rust may be a better solution, but justification is wrong. Also automotive industry already knows safer programming language (ADA), but decided to use C because it is waaaaay more easy to recruit staff.
i think bro is getting bent by the rust every night. literally this is too much for making people switch to rust. this is just f'ing absurd for a content to make
i will give my 2cent here, this video kinda came in like a tone deaf for me. Although yes, rust can prevent the mem error, but this instance is a violation of swiss cheese model, where there are multiple barrier and safety check, i mean organizational level safety check, to prevent error.
I came from Aviation bg, where icao/faa/nasa would put safety and stability above all. It is becoming pride in itself.
1. Cost cutting before safety?
2. Only limited testing??
Now, i did mentioned aviation industry, you might, how about MCAS? It is doing its very job, just wrong implementation, it is not software issue, it is Stability issue as in control system like PID etc. Mars orbiter? ran as intended, wrong unit. Both of them are using C.
If your car ever does this immediately shift into neutral and then try to decelerate. Using the brakes only in this scenario will just cause them to heat up very quickly and become nearly useless.
I'll keep that in mind while trying not to panic
Awesome video men. Ty
500k lines of c code are 500k lines of c code and it should not ring any bells. The problem is not the language.
The point is that no one can manually prove the safety of projects that complex when it uses global variables and interdependent tasks.
This is a serious issue, but it stuns me still that so many people didn't think to simply turn off their engine and / or shift to neutral. Know your car, and how it works: it could save your life.
every time i see "its crazy how those people didnt act exactly in the way that would work" when talking about a fast-paced, high-stress situation i can immediately tell that the person saying this has never been in such an event. they are normal people driving to work - not pilots or soliders. they dont have the privilege of careful analysis especially since they're panicked and they have not been trained for this type of emergency
If this stuns you then you would pass out behind the steering wheel of a car with this bug.
bro you go bonkers when something like that happens, you forget how to think.
always blame the victim 🤡
So easy to sit on a high horse from the comfort of your couch AND with the benefit of hindsight 😂
Use rust, save lives :D
8:40 I'm sorry, it is not ok to use a story like this to shill for Rust.
Rust is great, but not mentioning Ada as a memory-safe precursor is ignorant or disingenuous.
it's super gross to leverage death to promote your channel/rust
you speak like a 12 year old girl
bringing awareness and giving a better recommendation is gross? lol
It is quite gross how you can only interpret things that way.
He is just using a real world example where memory unsafety could cause life threatening damage and how Rust is a good solution to the problem.
@@arson5304 he does have a "buy my course!!!" deal going on in this channel so yeah... it's not just giving good recommendations, it's about selling his course.
No, you are really just perpetuating an American myth.
Why were there no such problems with Toyotas outside of the US?
First
Rust propaganda!