11–20 of 542 posts
To put things in context, Linus is being reasonable and wise and well-mannered once again. Wouldn't mind reading a few juicy expletives, to be honest.
> 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 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 ?
Have you missed the years and years of people criticizing Linus for his communication style?
When people say "safe" there's a pretty precise meaning and it's not this.
Yes, anyone who believes rust is 100% "safe" (by any definition) is wrong. That's not something you learn in Kindergarten though, it's actually about understanding that Rice's Theorem is a generalization of the Halting Problem.
> o this is something that I really need the Rust people to understand. That whole reality of "safe" not being some absolute thing
The irony of Linus lecturing anyone on safety lol anyway "the Rust people" know this already, when they say "safe" they mean "memory safe" - https://en.wikipedia.org/wiki/Memory_safety
Anyway, dumb shit like this is why I've always been quietly dreading Rust in the kernel.
a) The kernel will never be safe software because the mainline developers don't want it to be or even know what safe means
b) It just invites more posts like this and puts Rust closer to one of the most annoying software communities
> Or, you know, if you can't deal with the rules that the kernel requires, then just don't do kernel programming.
Agreed on this point. I was very interested in kernel dev earlier in my career until I actually started to engage with it.
I 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.…
> 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.
It is sometimes acceptable to get wrong output. But is nearly always better to know it is wrong.
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 ?
Not all that familiar with the specifics of Rust, but I assume it’s “safety” is somewhat similar to Swift’s “safety,” so type safety and memory safety, which does not mean no crashes, just that you will e.g. crash on an array OOB error rather than start writing or reading to random bits of memory.
edit:
> Yeah I was just trying to provide a clear definition, I didn't think you were implying it was BS.
(would have replied but I'm rate limited on HN - thanks dang!)
I 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.…
Why is panicing in the kernel on an error not an option? Like kernels can write a core dump and reboot, right?