I am the only one who would have a hard time to collaborate on a project where the "collaborators" start their message with > You need to realize that > (a) reality trumps fantasy ?
It used to be way worse than that, but yes you're right.
“Rust is safe” is not some kind of absolute guarantee of code safety
51–60 of 542 posts
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#52I am the only one who would have a hard time to collaborate on a project where the "collaborators" start their message with > You need to realize that > (a) reality trumps fantasy ?
You are free not to collaborate on the Linux kernel. That’s the beauty of free software!
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#53Why is panicing in the kernel on an error not an option? Like kernels can write a core dump and reboot, right?
No need to reboot the machine without warning, and lose data, when the rest of the kernel is probably still functional.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#54Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#55> Not completing the operation at all, is not really any better than getting the wrong answer, it's only more debuggable. Wouldn't be that sure about that. Getting the wrong answer can be a serious security problem. Not completing the operation... well, it is not good, but that's it.
I mean if it is a cosmetic thing sure. If it has substantial meaning I would rather have that 5 ton robotic welding arm not move than have it move through my skill. It is sometimes acceptable to get wrong output. But is nearly always better to know it is wrong.
[deleted]
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#56Earlier quoted context omitted.
While I don’t advocate for kernel panics, journaling filesystems are a thing.
Yes, but even then not all filesystems are journaled. EFI is FAT, FAT is not journaled. You almost certainly have EFI these days.
That’s a good point, but EFI isn’t frequently written I believe, so that I would expect that to be a rare circumstance, and even rarer for user data to be affected as a consequence.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#57Earlier quoted context omitted.
I am probably wrong but I understood that “safety meaning panic” is noeither “safe” not allowed in the Linux kernel because the kernel must not panic when an error arises.
Which is why Rust has been accommodating the kernel by adding non-panic versions of the functions that Linus has been complaining about (namely that memory allocation is infallible, because that isn't an unreasonable thing to assume in applicationc code.). Still doesn't change the fact that "safe" in this context has a technical meaning, and what Linus is describing isn't that.
maybe his point is that the technical meaning should use a more acurate word in his opinion?
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#58I am the only one who would have a hard time to collaborate on a project where the "collaborators" start their message with > You need to realize that > (a) reality trumps fantasy ?
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.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#59I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is. The comment seemed to be making reference to rust's safety guarantees about undefined behaviour like use after free. Linus' seems to have a completely different definition of "safey" that conflates allocation failures, indexing out of bounds, and division by zero with memory safety.…
I am probably wrong but I understood that “safety meaning panic” is noeither “safe” not allowed in the Linux kernel because the kernel must not panic when an error arises.
Safety doesn't mean panic. I don't feel that was the point the person Linus responded to was making.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#60Classic Linus. From the closing paragraph, I feel like he’s under the impression that Rust-advocating contributors are putting Rust’s interests (e.g. “legitimizing it” by getting it in the kernel) above the kernel itself.
Is he wrong?