This kind of exchange was inevitable. The Rust crowd has this mentality that their code can be perfect (beyond even 'safe'), when in reality as long as your foundational system inputs and capacity aren't perfect, no downstream thing can be either. It's harder to see in user space but in the kernel you can't avoid reality. Hope the Rust crowd in general gets more moderate after this (or maybe not, but then that's only to the loss of Rust's long-term success).
“Rust is safe” is not some kind of absolute guarantee of code safety
481–490 of 542 posts
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#482Earlier quoted context omitted.
The policy of ‘oopsing’ and limping on is, in my opinion, literally one of Linux’s worst features. It has bitten me in various cases: - Remember when Linux had that caused the kernel to partially crash and eat 100% CPU due to some bug in the leap second application code? That caused a >1MW spike in power usage at Hetzner at the time. That must have been >1GW globally. Many people didn’t notice it immediately, so it m…
So instead of a power spike, we'd have had a major internet outage across the world, across the entire industry and beyond, probably, if everyone had panicked on oops. The blame really lies with people not monitoring their systems. As you said, you have the option to reboot on panic, but Linus is absolutely not wrong that this size does not fit all. What about a medical procedure that WILL kill the patient if interru…
> What about a medical procedure that WILL kill the patient if interrupted?
Allow me to introduce you to Therac-25: https://en.wikipedia.org/wiki/Therac-25
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#483Earlier quoted context omitted.
Had the same topic often on MCUs: limp along to hopefully get the error out somehow, otherwise it won't be noticed if not with JTAG debugger attached (default in field). So I can understand where Linus comes from.
Limping along is what the salesman and the business people want as failures look bad. Engineers should want the immediate stop, because that's safer, especially in safety critical situations.
What are you talking about? Should planes stop flying when they encounter an error?
Safety critical systems will try to recover to a working state as much as possible. It is designed with redundancy that if one path fails, it can use path 2 or path 3 towards a safe usable state.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#484Earlier quoted context omitted.
Then it's probably not the place for you, or people with thin skin that don't want to deal with that kind of tone/communication. If they lose out on talent because of it, that's their loss. Not every project has to be perfect and all-inclusive to the entire world of developers, and I'm okay with that.
It’s crazy to think that advocating for reasonable, non-toxic people to work with receives this kind response. Inclusivity and non-hostile work environments should not be considered “perfect” and “all-inclusive”. They should be basic . The default . The lowest bar possible .
Are you calling Linus unreasonable and toxic?
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#485Earlier quoted context omitted.
One has to be careful about words. When Rust (or Linux) is used in (say) a vehicle or in a nuclear power plant, panicking certainly has immediate safety implications.
And a perfect, bug-free ballistic rocket program is unsafe in the sense that it is efficient at causing damage. Rust’s “safety” has always meant what the Rust team meant by that term. There’s no gotcha to be found here except if you can find some way that Rust violates its own definition of the S-word. This submission is not really about safety. It’s a perfectly legitimate concern that Rust likes to panic and that pa…
Linus' point is that safety means something different in kernel programming than in PL theory, and that Rust have to be safe according to kernel rules before it can be used for kernel programming.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#486Earlier quoted context omitted.
That shouldn’t excuse him from being a reasonably decent person to work with. He gets a lot more leeway than being the creator of Linux should afford someone.
Unreasonable people build things. Reasonable people run meetings.
Looks like I've annoyed the "reasonable" people with this comment. Interesting.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#487No post body was provided.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#488Earlier quoted context omitted.
It is not a peripheral device if it runs the UI with all the main controls, is it?
No, do you have a concrete example of this strawman, though? Edit: I should also add (probably earlier too) that all my examples are specific to the USA FDA process. I'm sure some other place might not have the same rules.
I can't see how you can make out a strawman in what I said. There are medical devices where the UI is running on a processor separate from the controller in charge of the core device functions. The two are talking to each other and there is no secondary way of interacting with the controller. This lessens the requirements that are put on the part running the UI, but does not eliminate them.
I'm mostly familiar with EU rules, but as far as I know the FDA regulations follow the same idea of tiered requirements based on potential harm done.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#489Earlier quoted context omitted.
Interesting, how does your software detect an uncalibrated monitor? Did it come with a calibration device which had to be used to scan the display output to check? I don't suppose monitors report calibration data back to display adapters do they?
I didn't work on that specific software team and it has been a long time since I worked there. But the software came with its custom calibration routine and I believe that the calibration result was stored with model and serial number information from the monitor EDID.
Thanks, sounds like I need to do some reading about EDIDs; I knew _of_ them but no real understanding is what they are and what they do.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#490As usual HN comments react to the headline, without reading the content. A lot of modern userspace code, including Rust code in the standard library, thinks that invariant failures (AKA "programmer errors") should cause some sort of assertion failure or crash (Rust or Go `panic`, C/C++ `assert`, etc). In the kernel, claims Linus, failing loudly is worse than trying to keep going because failing would also kill the fa…
I might be missing something here. So I understand panic! will essentially crash the kernel, that makes sense to me as a problem. But wouldn't reading outside an array bounds also possibly do that? It coudl seg fault which is essentially the same thing. Is it that reading out of bounds on an array isn't guaranteed to crash everything while a panic always will?
What segment? You don't have mapped memory to overrun in the kernel, so that array would have to be in a very special spot to cause a bus error in such a situation. Also, even in user space, overrunning an array is far from guaranteed in trying to address an unmapped page...in fact, it often doesn't, since mapping memory with gaps for each array is prohibitively expensive (though, debugging aides like Electric Fence rely on exactly this mechanism)