Linus may view his job as "Saying No" but the way he does it still leaves a little to be desired, because his reasoning is sound here, but it's less "Follow my reasoning" than "You don't want to get yelled at again do you?"
[0]: https://lore.kernel.org/lkml/CAFRnB2VPpLSMqQwFPEjZhde8+-c6LL...
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.
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!)
https://en.wikipedia.org/wiki/Kdump_(Linux)
He also mentions that programs can report problems automatically to the distro devs. For example:
https://retrace.fedoraproject.org/faf/problems/
A kernel dump is not something you always want to upload since it can be large and contain sensitive info. I'm not a kernel dev though.
You should read the email thread, as Linhas explains in clear terms.
Take for instance Linus's insightful followup post:
I mean the post Linus initially responded to did contain[1] a patch removing a kernel define, asking if anyone had any objections over removing that define, just to make the resulting Rust code a little nicer looking.
My intuition says that's the Halting Problem, so not actually possible to implement perfectly? https://en.wikipedia.org/wiki/Halting_problem
https://lkml.org/lkml/2022/9/19/640
Get at least down to here:
https://lkml.org/lkml/2022/9/20/1342
What Linus seems to be getting at is that there are many varying contextual restrictions on what code can do in different parts of the kernel, that Filho etc appear to be attempting to hide that complexity using language features, and that in his opinion it is not workable to fit kernel APIs into Rust's common definition of a single kind of "safe" code. All of this makes sense, in user land you don't normally have to care about things like whether different functional units are turned on or off, how interrupts are set up, etc, but in kernel you do. I'm not sure if Rust's macros and type system will allow solving the problem as Linus frames it but it seems like a worthy target & will be interesting to watch.
Which is safe. It's inconvenient, but it's safe. Failures of this sort do happen, electrical fires are probably the most extreme example. They're annoying, but nobody is at risk if you stop. Since the tube is in civilisation (even at the extreme ends of the London Underground which are outside London, like Chesham, this is hardly wilderness, you can probably see a house from where your train stopped if there aren't trees in the way) we can just walk away.
https://commons.wikimedia.org/wiki/File:Chesham_Tube_Station...
> Linus was saying no, you carry on despite the error until you get to the next station
Depending on the error the consequences of attempting to "carry on" may be fatal and it's appropriate that the decision to attempt this rests with a human, and isn't just the normal function of a machine determined to get there regardless.
I feel like it's a defensive reaction, that people feel like Rust is seeking to obviate arcane skills they've built over the course of their careers. Which I don't think is true, I think there will always be a need for such skills and that Rust has no mission to disrupt other language communities, but I can understand the reaction.
> You can even look in my comment history
Is this the thread you're referring to?
https://news.ycombinator.com/item?id=32878868
Because I genuinely don't see what you're talking about. No one seems to "make it their mission" and no one seems to be arguing for Rust in particular, as much as this category of languages.
I would like to learn otherwise, but even a React JS+HTML page is undecidable... its scope is limited by chrome V8 js engine (like a vm), but within that scope I don't think you can prove anything more. otherwise we could just make static analysis to check if it will leak passwords...
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 differences are they are actually meant to be used for exceptional situations ("assert violated => there's a bug in this program" or "out of memory, catastrophic runtime situation") and they are not typed (rather, the panic holds a type erased payload).
Other than that, it performs unwinding without UB, and is catchable[0]. I'm not seeing the technical difference?
[0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
- use after free
- breaking the aliasing rules
- causing a "data race" (e.g. writing to the same value from multiple threads without a lock)
- producing an invalid value (like a bool that's not 0 or 1)
There's some other technical stuff like "calling a foreign function with the wrong ABI", but those four above capture most of what safe Rust wants to guarantee that you never do. I contrast, the same page provides an interesting list of things that Rust doesn't consider UB and that you can do in safe code, for example:
- deadlocks and other race conditions that aren't data races
- leak memory
- overflow an integer
- abort the whole process
If you need an example of the rust community being toxic, I give you https://github.com/actix/actix-web
Look up the history and realize they bullied an open source project leader into leaving open source for good.
I still don't understand the relevance, this neither appears toxic nor to be a discussion of Rust; this looks like they put forward an out-there idea and you didn't care for it, which just seems like a discussion about consumer protection laws. I also don't see the connection from Actix drama to the idea that people are exaggerating the capabilities of Rust or causing problems for other language communities - I don't know much about it, I'm fully willing to believe toxicity was involved, but a breakdown in communication between a maintainer and their community doesn't seem like the behavior we're discussing and I don't see any evidence this was peculiar to Rust and not a phenomenon in open source at large.
I don't want to relitigate some thread I wasn't even a part of, I just don't understand.
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.
There's a video of passengers doing this for real in this 2016 news article:
I think it's a fair characterization of what was said. Feel free, as everyone is, to read the entire thread again. I'm not a journalist. You have the primary source at your finger tips!
> Can you point out the normative document that provides these guarantees?
You're looking at the Rust reference right? https://doc.rust-lang.org/reference/behavior-considered-unde...
Not normative, as stated here[1], linked from the page you cite.
https://smile.amazon.com/EVanlak-Passthrough-Generrtion-Elim...
After saying everyone was empowered to use their tool, they tried to kick someone off the team for working for Palantir.
Regardless of politics, kinda unfair to make political statements using the rust accounts, then turn around and say other people can’t be part of rust because they work for a company who is political.
Allow me to introduce you to Therac-25: https://en.wikipedia.org/wiki/Therac-25
"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."
https://www.fda.gov/medical-devices/human-factors-and-medica...
Honestly, the FDA regulations go too far vs the EU regs. The company I worked for was based in the EU and the products there were so advanced compared to our versions. Ours were all based on an original design from Europe that was approved and then basically didn’t charge for 30 years. The European device was fucking cool and had so many features, it was also capable of being carried around rather than rolled. The manufacturing was almost all automated, too, but in the USA it was not at all automated, it was humans assembling parts then recording it in a computer terminal.
https://www.acsac.org/2002/papers/classic-multics.pdf
So not even back then.
