Earlier quoted context omitted.
Yes, but why would you go to these lengths? The purpose of the whole mechanism is to prevent accidental misdiagnosis based on an incorrectly interpreted X-ray image. This isn't DRM, just a safeguard against incorrect use of equipment.
People are cheap and corrupt. The speed bump this presents is real, but minor, in the face of a couple medical shops looking to save $100/pop on a dozen monitors. I hope it's rare, but I think a persistent nag window ("Your display isn't calibrated and may not be accurate") is probably a better answer than refusing to work altogether, because it will be clear about the source of the problem and less likely to get nai…
“Rust is safe” is not some kind of absolute guarantee of code safety
491–500 of 542 posts
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#492Earlier quoted context omitted.
Sort of how Linus pisses on Rust with a not-actually-good argument?
Linus is not pissing on Rust though, his argument is about panic in Kernel code. Why people feel attacked by Linus words is a mystery to me.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#493Earlier quoted context omitted.
> You calling his point BS, but also strongly agreeing with it. I'm only agreeing with the fact that there are no absolute guarantees. Not that his use of the fact in the point he makes has any relevance... If somebody had said "The earth is round, therefore we should not care about getting lost and GPS, because you always can always keep going and end up where you started on a sphere anyway", then I would have also…
The discussion is about what (if anything) the linux kernel should do to help satisfy the guarantees that rust wants to make. Accepting the idea that rust guarantees aren't necessarily always good is needed to accept the idea that those guarantees might need to be relaxed, or at least don't necessarily justify linux kernel changes.
The idea that rust guarantees aren't necessarily always good is completely orthogonal to a condescending diatribe about how "there are no absolute guarantees", and totally needlessly connected to "go back to kindergarten" and "stop believing in Santa" BS.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#494> And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. I thought that he had apologised and regretted being hostile in comments. Apparently not. Not that I have much of an issue with ranty…
> "WE'RE TRYING to guarantee the absence of undefined behaviour". That's an aim, not a claim they've either achieved it, or they can achieve it 100% How is a "guarantee" not claiming something is 100% ?
"I guarantee I will be there" - but I could always be hit by a bus, or have a very serious family issue to tend to, or an earthquake might happen, or the airports might be closed due to Covid and so on.
"Our bank guarantees your money" - yeah, except if the global economy collapses, or the country is hit by an asteroid, or if there's martial law, and so on.
The trivial such cases are irrelevant to the guarantees they want to offer (and same for Rust), and it's a bad move to point to them and consider them as part of his argument.
Not to mention they're saying "trying to", not guaranteeing in the first place. Which acknowledges things like possible bugs, or some edge case not handled, etc.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#495Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#496I’ve been using Rust for a while, and I’m so, so tired of hearing this argument. Yes, we know. We get it. Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. This is obvious and well-known to anyone actually using Rust. At this point, the argument feels like some sort of ideological debate happening outside the realm of actually getting work done. It feels like any time someone says…
I mean, it's felt like anytime anyone mentions any code base not written in rust, someone pops in and points out that it's not safe , and should be rewritten in rust. I think it's all part of the language maturing process. Give it time, zealots will either move on to something new (and then harass the rust community for not meeting their new standard of excellence) or simmer down and get to work.
There's a clear safety spectrum, with C near the bottom and Rust near the top. It's tedious for people to keep saying "well it's not right at the top so we should just keep using C".
I'm sure pro-seatbelt people were called "zealots" back in the day too.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#497Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#498Earlier quoted context omitted.
> What about a medical procedure that WILL kill the patient if interrupted? What about life support in space? The proper answer to those is redundancy , not continuing in an unknown and quite likely harmful state.
Right. It's clear that many people have not heard of, or considered, Therac-25[1]. [1] https://en.wikipedia.org/wiki/Therac-25
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#499As 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…
"If you want to allocate memory, and you don't want to care about what context you are in, or whether you are holding spinlocks etc, then you damn well shouldn't be doing kernel programming. Not in C, and not in Rust.
It really is that simple. Contexts like this ("I am in a critical region, I must not do memory allocation or use sleeping locks") is fundamental to kernel programming. It has nothing to do with the language, and everything to do with the problem space."
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#500Earlier quoted context omitted.
Memory safety is a well-defined term.
I agree, but that isn’t the term that was used here, and Rust proponents usually mean more than memory safety by “safe” (like e.g. absence of UB).
Rust proponents mean exactly "memory safety" when they say rust is safe because that is the only safety rust guarantees.