Is it me (and have I been hiding/asleep under a rock for a long time) or is Linus' tone vastly (and pleasantly) different from what his previous persona is known to be?
I actually loved (I mean really loved) reading the response as it not only was encouraging but also highly respectful and almost glowing with a trained sort of nuance! Just wow!
From what I've seen, Linus has always been mostly quite reasonable and constrictive, even before his 2018 "refection" that some others mentioned. Most of the time it was direct, but helpful, polite, and constructive. This is probably a big contributor to Linux's success.
It's just that on occasion he would rant and rave to people and call them retards or whatnot. People get a bit of a skewed perception because only those messages make the news and are famous, but that's not really representative of all the messages.
And when he did rant and rave, it was pretty much always towards established contributors who had screwed up somehow; people who in his opinion ought to know better, and most of the time he did have a good point. I don't approve of his style, but it's not like he would randomly call people idiots. It's not as if you ever ran the risk of being scolded by Linus if you were a new contributor sending a patch or anything.
tl;dr: Linus has always been like this, and was just occasionally an asshole.
That's the thing. I am very sure perception was tainted by my own laziness and "falling for" populist PR and it took pure coincidence to see the real side! Sigh.
"News" by definition is biased towards both rare and negative events, because common everyday things don't tend to be news. "New contributor gets a very helpful response from Linus" isn't news, and neither is "man spills someone's pint in a pub, they apologize and everything is okay", "woman walks home at night nothing happened", etc.
Quite frankly I consider most of the news to be worse than useless and actively harmful (and news is different from journalism; journalism is great).
(also, I see now I misspelled constructive as "constrictive" in my previous comment do'h facepalm)
I don't read the lkml enough to truly know, but in 2018 he made a public apology and (IIRC) took some time off to go work on his behavior. So maybe that's it!
I agree that I found his messages here to be quite pleasant.
his infamous rants are outliers. caricatures of Linus as some whackjob that always goes on lengthy, profanity-ridden tirades at the slightest minimal provocation are all vastly overstated.
I think he probably makes thousands of comments, yet the controversial ones make it out to the general community and form his reputation.
Also, I think what's really interesting is that with his feedback, could the language be actually be adapted to the kernel?
This would be fascinating because traditionally the code (the kernel in this case) has to adapt to the foibles of C. This could be the reverse, where not only could the language adapt, it might make the kernel technically better, and easier to read and modify.
> Is it me (...) or is Linus' tone vastly (...) different from what his previous persona is known to be?
Indeed, and I hate it. It's actually very scary, a creepy change in personality. Like the last scene in "one flew over the cuckoo's nest", where the main character is lobotomized and loses the spark on his eyes. Deeply, deeply troubling to behold. I wonder if the real Linus still exists behind all this or he's gone forever.
He's really changed. There is a subreddit /r/linusrants that documents his rants. In the last year there have been 9 posts, but most of those are reposts from previous years or not really rants or aimed at technologies, not people. Three years ago there were 27 posts.
And what makes this even more impressive is that he managed to do it despite being - in manys eyes - a very nice and reasonable person to start with, it wasn't like everything was falling apart around him and everyone was leaving their jobs as maintainers AFAIK, he just decided it would be better for the project if he left this part of his personality behind.
RFC 2116 addresses part of the issue. The other part of the problem would be to support disabling the non-fallible APIs at compile time.
Also, RFC 2116 assumes that it's sufficient to provide (for instance) Vec::try_reserve, and require callers to always call that before calling anything that might expand the Vec. That wouldn't eliminate the runtime panics. It might be necessary to go a step further, and actually provide fallible versions of individual Vec methods. (Or there may be other potential solutions.)
Yeah `try_reserve` is ~~racy and~~ (edit, strikethrough) awkward to use. And having a bunch of a panics which "should" be dead code because of the proceeding `try_reserve` at best adds a bunch of noise burdening static analysis.
A bunch of us, anticipating a reaction like Linus' have been arguing that we need `try_` versions of everything and* a way to prevent the other ones from being used. (Cargo features?) I sincerely hope we finally get that.
> A bunch of us, anticipating a reaction like Linus' have been arguing that we need `try_` versions of everything and* a way to prevent the other ones from being used.
This has been anticipated since panic on OOM was introduced.
Adding `try_` version of everything is a horrible solution.
What you want is for the normal APIs to return Result<R,E> where E=! when panic on OOM and some OOM error otherwise.
The largest irony of all time is that, while returning an error on OOM works well on Windows, it makes little sense on Linux because overcommit is often enable by default. Linux and Linux users are directly responsible for the "panic on OOM" that turns out now prevents liballoc from being used in the Linux kernel.
The obvious fix here is for the kernel to use overcommit internally \s
But it's still non-local. one has to manually account for what allocation will be done, and keep the reservation in sync across refactors. This isn't a race but still scares me.
which would be a race. That is not `try_reserved`'s fault, and a rather easy-to-spot example, but I wonder if there are variations on this which are easier to miss.
They probably meant it is a race, not racy. Although, it's not a race I think? The method will attempt to reserve, or return Err, just like malloc would (it's not can_reserve)
let v = vec![0; 42];
v.try_reserve(1);
frob(&mut v); // I expect this not to expand the array
v.push(1); // fails, because frob took the space
Note that this requires passing a mutable reference to frob. Absent an explicit contract in the api documentation I wouldn't expect a function that takes a mutable reference to a vec not to mutate it arbitrarily.
One option for avoiding this would be to pass a mutable reference to a slice, which allows frob to mutate elements of the vec without allowing it to push.
frob(&v[..])
It can't be a race in the traditional sense, as the borrow checker will enforce only one person being able to write at a time.
Even for normal user space code having a way to detect panic at compile time and abort compilation would be great. Ideally together with a way to wrap functions that do panic by catching it and throwing an error instead so the panic infrastructure can still be used. I've sketched that out on HN the other day:
That is still something that happens at runtime, not compile-time. What the kernel would need is not only for the fallible alloc APIs (like Box::try_new) to be expanded to cover all their needs, but also to be able to remove the ability to use the infallible/panicky ones (like Box::new) to ensure, at compile time, that panic will never be called.
The second half doesn't exist either. I want to disallow panic and turn it into an error at compile time. The panic unwinding would be replaced with an error check by the compiler.
> Note that this function may not catch all panics in Rust. A panic in Rust is not always implemented via unwinding, but can be implemented by aborting the process as well. This function only catches unwinding panics, not those that abort the process.
The most notable way this can go wrong in pure Rust code is that panic-while-panicking aborts. So you have to be careful that your destructor can never panic.
It's kind of a funny space; right now Rust handily gives you "no allocations" (this is where I live) or "infallible + fallible allocations" (this is alloc/std by default) but not "only fallible allocations". This sort of thing is basically filling out the quadrant of options.
Yup, it is. If this plan linked above were to be implemented, what would happen is that you would get the same behaviors by default, but with a new setting, you'd get some APIs removed. That's backwards compatible.
I was thinking that when reading the exchanges. This is a really good interaction. Linus and the kernel have strong requirements for good reasons, and the rust teams are trying to address them in useful ways.
Rust in the kernel is not a simple thing, but I think both rust and the kernel will benefit.
Do you think a more ergonomic `#[no_panic]`[0] would require Rust wait for an entire effect system, or be valuable enough to add to the compiler as a one-off?
Yeah!
Even he kind of appreciates one of my favorite Rust features.
> So "Result<T, E>" is basically the way to go, and if the standard Rust
library alloc() model is based on "panic!" then that kind of model
must simply not be used in the kernel.
This is the problem with SW developers: when something starts working they want to "improve" it until it doesn't work. See firefox for a nice example (it is so sloooow). (no i do not have an SSD but earlier it was reasonable. Now the change to rust is making it slower without any visible improvement in security- still have to update every couple of weeks because of CVEs)
It comes from the ASCII C0 [transmission] control code NAK, which means "negative acknowledgment"--something was wrong with the last transmitted data block or command, or the reception of it. As opposed to "ACK", which means a block or command was successfully received and accepted. In the original 1963 standard the mnemonic was "ERR", but changed to "NAK" for the 1965 standard.
In programmer lingo it can means something similar to the original meaning--rejecting a request for faultiness or incompleteness--or it can mean something more like, "no"--answering in the negative.
I am pleased that these are all addressable things. We'll see!