371–380 of 542 posts
Earlier quoted context omitted.
You mean for the hundreds of thousands of people that in the past 31 years willingly decided to contribute to the to the most successful and well maintained open source project ever, because the creator is such a brilliant person?
Anyone who has to interact with him pretty much.
They chose to.
Who's to blame here?
Earlier quoted context omitted.
> Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. In today's news "random angry guy on the Internet tells Linus Torvalds to go back to kindergarten, because reasons"
Actually Linus wrote the above part. It's a quote from his post.
Harsh truths are still truths.
Earlier quoted context omitted.
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…
That’s exactly my point. Rust’s definition of safety is a very specific one, and one has to be careful about what it actually implies in the context where Rust is employed. “Safety” isn’t a well-defined term for PL in general. “Soundness” is.
This is false. "Safety" and "Liveness" are terms used by the PL field to describe precise properties of programs and they have been used this way for like 50 years (https://en.wikipedia.org/wiki/Safety_and_liveness_properties). A "safety" property describes a guarantee that a program will never reach some form of unwanted state. A "liveness" property describes a guarantee that a program will eventually reach some form of wanted state. These terms would be described very early in a PL course.
Earlier quoted context omitted.
You can prove that a machine can't ever write "1" to the tape if you just look at the state machine and see that none of the rules write a 1 to the tape. Since no rules ever write 1, no possible execution could. Working out whether it will write 1 to the tape in general is undecidable, but in certain cases (you've just banned states that write 1) it's trivial. If all of the state transitions are valid (a transition t…
"Print 1" is trivial according to this: https://en.wikipedia.org/wiki/Rice%27s_theorem . But day to day programs are not trivial... as for your example, just switch it with this code: `print(gcd(user_input--,137))`... now it's quite more hard to "just ban some final states"
And that's pretty easy to statically analyze.
Earlier quoted context omitted.
You can prove that a machine can't ever write "1" to the tape if you just look at the state machine and see that none of the rules write a 1 to the tape. Since no rules ever write 1, no possible execution could. Working out whether it will write 1 to the tape in general is undecidable, but in certain cases (you've just banned states that write 1) it's trivial. If all of the state transitions are valid (a transition t…
"Print 1" is trivial according to this: https://en.wikipedia.org/wiki/Rice%27s_theorem . But day to day programs are not trivial... as for your example, just switch it with this code: `print(gcd(user_input--,137))`... now it's quite more hard to "just ban some final states"
The point is that you can produce a perfectly working analysis method that is either sound or complete but not both. "Nowhere in the entire program does the call 'panic()' appear is a perfectly workable analysis - it just has false positives.
The problem is that this definition of safety is very arbitrary. Sometimes crashing a process can be safe (as in not causing serious problems) but sometimes not. Accessing an array out of bounds can be safe sometimes and sometimes not, and so on.
Rust says that here is a list of things that are always safe and here is a list of things that are always unsafe and then people want safety everywhere so they take that definition of safety to other contexts where it doesn't make sense, like the kernel.
Earlier quoted context omitted.
You can prove that a machine can't ever write "1" to the tape if you just look at the state machine and see that none of the rules write a 1 to the tape. Since no rules ever write 1, no possible execution could. Working out whether it will write 1 to the tape in general is undecidable, but in certain cases (you've just banned states that write 1) it's trivial. If all of the state transitions are valid (a transition t…
"Print 1" is trivial according to this: https://en.wikipedia.org/wiki/Rice%27s_theorem . But day to day programs are not trivial... as for your example, just switch it with this code: `print(gcd(user_input--,137))`... now it's quite more hard to "just ban some final states"
(input state, input symbol) --> (output state, output symbol, move left/right)
This is like just not linking panic() into the program: it isn't going to be able to call it, no matter what else is in there.
As 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…
Please correct me if I’m wrong, but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, and thus with regards to Linux kernel requirements isn’t safer in that aspect than C. To the contrary, Rust is arguably less safe in that aspect than C, due to the general Rust practice of panicking upon unexpected conditions.
Earlier quoted context omitted.
>and in particular not a sensitive part like kernel error reporting Things like "kernel error reporting" doesn't exist as discrete element. Sure, you might decide to stop everything and only dump log onto earlycon, but running with serial cable to every system that crashed would be rather annoying. For all kernel knows, the only way to get something to the outside world might be through USB Ethernet adapter and conne…
> Things like "kernel error reporting" doesn't exist as discrete element. I'm not familiar with kernel development in general or Linux in particular. I would have expected there to be an error reporting subsystem, so that if a given subsystem fails the failure is reported to the error reporting subsystem (which hopefully exposes a more modern interface than serial cable), but this might be naive on my part. > For all…
Earlier quoted context omitted.
> They occupy less than 1% of the programming community and act like they single-handedly are the only people who understand correctness. Maybe I’m too young (just past 30) but is it just me or is that some kind of attitude that emerged in the last 10-15 years? And I mean not only in programming, but in general. A small amount of people which is very vocal about something and start pushing everybody else to their thi…
>A small amount of people which is very vocal about something and start pushing everybody else to their thing while simultaneously shaming and/or making fun of those who either disagree or aren’t generally interested. It's called manufacturing consent and it's all around us.
If not, would you care to drop some links?