LWN: Comments on "Whither the Apple AGX graphics driver?"

Rust saga to end?

mathstuf — Wed, 02 Oct 2024 13:17:27 +0000

Well, if you want to be pedantic, no general purpose language has "flush the TLB" or "enter VM" instructions either. Both Rust and C use inline assembly or ABI contracts with full assembly files to access such functionality.

Perhaps that is far enough

Rudd-O — Wed, 25 Sep 2024 10:01:35 +0000

Sure. Have a nice day.

The borrow checker as a significant advance

Rudd-O — Wed, 25 Sep 2024 09:54:37 +0000

Oh, 100% right! Ownership checking and the prevention of pointer aliasing are awesome.

Thoughts and clarifications

Rudd-O — Wed, 25 Sep 2024 09:52:59 +0000

Not sure what you're referring to with "provably correct", that's Knuth's claim, not mine.

Nevertheless, in my professional experience, the C compiler's silence generally tells you near to nothing about whether the program will run as intended (I concede things have improved over the last 30 years. Whereas the Rust compiler's silence generally does mean the program is either going to run as intended or will have substantially fewer problems than the C one (mostly logic errors introduced by the programmer).

You can choose to be dogmatic and insist that all compilers / languages give the same results (a belief I like to call " blank slatism"), or you can choose to test that theory for yourself. I know what I chose and I am quite happy. My sincere recommendation is that you test the theory for yourself.

Perhaps that is far enough

corbet — Wed, 25 Sep 2024 09:48:13 +0000

It is my suspicion that this conversation will go nowhere useful after this point. Perhaps it's best to stop it here?

Thoughts and clarifications

Rudd-O — Wed, 25 Sep 2024 09:44:49 +0000

That's a lot of code.

To get back to the topic (common pitfalls of refactoring and how Rust helps avoid errors):

Can you articulate what a match statement does, and how it behaves when you add a new case somewhere very far away from the match statement? How is it different from, say, a chain of if/else or a select case? If your codebase was (hypothetically) Rust, what would the compiler say to such a change, versus what the C compiler says today?

My intention is to figure out if you have had a chance to compare both C and Rust in order to form an honest, informed opinion.

Thanks in advance.

Rust saga to end?

Rudd-O — Wed, 25 Sep 2024 09:29:02 +0000

> Hold on, are you telling that Rust has no means to talk to hardware and always need a C shim doing that?

I'm curious to find out how you deduced that I had claimed this.

> If it's true, how even it's possible to write an OS in Rust to begin with?!

Redox, Hubris, Rust on Linux,... Eppore sic muove.

Rust saga to end?

daroc — Tue, 24 Sep 2024 20:16:47 +0000

In practical terms, however, the Rust project has made supporting the Rust-for-Linux project one of their main goals for 2024.

Rust saga to end?

farnz — Tue, 24 Sep 2024 20:13:51 +0000

Neither; Rust is sufficiently mature that both groups have similar influence on the future of the language.

Note that Rust is not a particularly new language at this point; stable Rust is 9 years old, whereas the first draft of ANSI C was only 6 years old at the point Linux was first released. There's a lot of groups influencing the future of the language, with the intent that it's a usable language for any domain in which you'd consider C or C++.

Rust saga to end?

andy_shev — Tue, 24 Sep 2024 20:06:26 +0000

Ah, that makes sense! And which of those two groups has most influence in how Rust as a language is being developed?

737 MAX only tested, not proven correct

paulj — Mon, 23 Sep 2024 16:23:43 +0000

Went and had a read, as it seems you and farnz don't quite agree and/or are talking about slightly different things. ICBW, but my read of the FAA summary report is:

FAA "Safety Item #1: USE OF SINGLE ANGLE OF ATTACK (AOA) SENSOR" - this refers to the use of /data/ from a single AoA sensor by MCAS.

FAA "Safety item #5: AOA DISAGREE:" - refers to the "AOA DISAGREE" warning in the cockpit FDU, which somehow was tied to the optional "AoA Indicator gauge" feature for the FDU, which airlines had to purchases.

AFAICT from the FAA summary. I.e., the change was entirely in the logic - because there was no action item to retro-fit another AoA vane to the 737 Max. Excluding training and maintenance requirements, aircraft changes were all logic update to do better filtering of the 2 AoA signals, with better differential error detection, and cease ploughing ahead with MCAS commands based on measurements from just 1 vane - which could be faulty. Other aircraft safety items added limits, damping and margins, to prevent runaway MCAS crashing aircraft.

Stunning issues really.

737 MAX only tested, not proven correct

pizza — Mon, 23 Sep 2024 15:49:30 +0000

> first is that "AoA DISAGREE" was an optional indication,

It's worse than that -- _redundant sensors_ were optional.

..and they were optional because one set of folks had a different set of functional specifications than another, and management was disincentivized to notice.

737 MAX only tested, not proven correct

farnz — Mon, 23 Sep 2024 14:40:52 +0000

There is a requirement underpinning all avionics that the aircraft's behaviour is safe in the event of a data source failing, and that the avionics are able to detect that a data source has become unreliable and enter the failsafe behaviour mode. This is a specification item for MCAS, and Boeing asserted to the FAA that they had tested MCAS and confirmed that, in the event of an AoA sensor fault, MCAS would detect the fault and enter the failsafe behaviours.

Boeing's tests for this, however, were grossly inadequate, and at least 3 different failure conditions have been found which were not covered by the tests: first is that "AoA DISAGREE" was an optional indication, available during the tests, but not in production MCAS unless purchased (20% of the fleet). Second is that they did not test enough bit error cases, and later investigation found a 5 bit error case that was catastrophic. And third was that the procedure for handling MCAS issues assumed that the pilot would have time to follow the checklist; in practice, the training issues meant that pilots didn't even realise there was a checklist.

Thoughts and clarifications

pizza — Mon, 23 Sep 2024 14:06:57 +0000

> Reference for "the software running on the 737MAX's MCAS was "provably correct""?

I'm giving Boeing's software folks the benefit of the doubt, because the MCAS debacle was a failure of specification (on multiple levels), not one of implementation.

After all, one can't test/validate compliance with a requirement that doesn't exist.

> Boeing asserted to the FAA that the testing covered all plausible scenarios.

It did! Unfortunately, many of those "plausible scenarios" required pilots to be trained differently [1], but a different part of Boeing explicitly said that wasn't necessary [2].

[1] ie recognize what was going on, and flip a circuit breaker (!) to disable MCAS
[2] One of the main selling points of the MAX

Thoughts and clarifications

farnz — Mon, 23 Sep 2024 12:01:36 +0000

Reference for "the software running on the 737MAX's MCAS was "provably correct""? I can't find any evidence anywhere that the MCAS was formally verified at all - merely that it was tested correct, and Boeing asserted to the FAA that the testing covered all plausible scenarios.

Thoughts and clarifications

pizza — Mon, 23 Sep 2024 11:56:19 +0000

> It does not prove that what the model does is what reality does! In a properly specified system, maths and science(reality) usually agree, but there's no guarantee ...

This has been my experience.

...The software running on the 737MAX's MCAS was "provably correct" .. for its specifications.

(It turns out that the words "properly specified" are about as common as unicorn-riding sasquatches...)

The borrow checker as a significant advance

intelfx — Mon, 23 Sep 2024 11:24:12 +0000

Another hugely impactful thing is Rust's linear/affine type system. This one has actually changed the way I think about variables, objects and resources in _any_ language.

Thoughts and clarifications

Wol — Mon, 23 Sep 2024 09:26:49 +0000

While it may not be what Knuth was thinking of, I also think of it as pointing out that a formal proof merely proves that the mathematical model is internally consistent.

It does not prove that what the model does is what reality does! In a properly specified system, maths and science(reality) usually agree, but there's no guarantee ...

Cheers,
Wol

Thoughts and clarifications

farnz — Mon, 23 Sep 2024 09:15:27 +0000

Knuth's point was not that it wouldn't work, but rather that his proof would only cover the things he cared to prove correct, and not necessarily cover everything that you, the reader of his code, would expect. He wrote that jibe in an era when formal methods practitioners were merrily proving all sorts of properties about code that, to a large extent, were irrelevant to users of computation systems (including those implemented using humans as the compute element), and not considering important properties (like "is this proven to terminate in finite time") because they're not always provable.

The borrow checker as a significant advance

farnz — Mon, 23 Sep 2024 09:03:07 +0000

Arguably, the biggest advance Rust brings is the borrow checker; it's hugely intrusive, but it allows Rust to formally verify that you're paying attention to whether or not a given pointer (in Rust's case, a class of pointers called "references") points to a valid place at time of use, without runtime assistance (e.g. a garbage collector).

Combine that with "either shared, or mutable, but not both", and you get a powerful tool for making it easier to reason about your code's behaviour.

Rust saga to end?

farnz — Mon, 23 Sep 2024 08:47:43 +0000

Redox OS is not inactive; it's under quite heavy development. The people pushing Rust into the Linux kernel are not people who want a pure Rust OS; they're people who want to work on Linux, but who find that C is a wholly inadequate language for expressing solutions to hard problems compared to languages they've used before, and who think that Rust is appropriate for kernel use.

This is much like asking why people worked on Linux in the early days, when 386BSD was there and in much better state than Linux 0.x; it's a different group of people, with different objectives.

Rust saga to end?

mb — Sun, 22 Sep 2024 20:16:36 +0000

>Rust has no means to talk to hardware and always need a C shim doing that?

No.

https://doc.rust-lang.org/std/ptr/fn.write_volatile.html

Rust saga to end?

andy_shev — Sun, 22 Sep 2024 20:13:49 +0000

Showing the possibility doesn't mean a production-ready solution. So, why Redox is so inactive, if Rust fellow developers trying hard to make it part of Linux kernel instead of investing more into pure Rust OS?

Rust saga to end?

andy_shev — Sun, 22 Sep 2024 20:11:55 +0000

Hold on, are you telling that Rust has no means to talk to hardware and always need a C shim doing that? If it's true, how even it's possible to write an OS in Rust to begin with?!

Doesn't seem that bad..

Rudd-O — Sun, 22 Sep 2024 19:00:13 +0000

All of that, combined with the fact that other people have expressed interest in using the new scheduler that might be written in Rust, seems like a win-win for everybody. I know I have had OOPSes in the DRM layer in my machines across the years. If I could benefit from Asahi's work, hell yeah let's go!

Use of unsafe in Rust

Rudd-O — Sun, 22 Sep 2024 18:58:27 +0000

> Unsafe is not there for cases where reality engages in behaviour the theoreticians have declared "illogical and impossible

I am almost 100% sure that was supposed to be comedy.

Rust saga to end?

Rudd-O — Sun, 22 Sep 2024 18:57:27 +0000

"Unsafe" is funny.

Unsafe is a funny keyword because the meaning of an unsafe block in Rust is actually the opposite of what you think it might be. I have seen it described as a promise to the code that's outside of the unsafe block that what you're doing inside of this block is safe for everybody else. Sort of like, trust me bro.

If the code that is within the unsafe block is correct and it does what it is supposed to do, then anyone calling that code or using that code will not encounter undefined behavior, or unexpected crashes, or other problems.

Aside from that, you are allowed to do certain things within an unsafe block that would not be allowed outside of those blocks. You can't just do whatever the hell you want inside of those blocks, of course. There are still rules. They're just somewhat relaxed. For 99.9% of the things that you write, you absolutely do not need to resort to an unsafe block. You may unwittingly be calling code that has on safe blocks within it, but you yourself are not actually writing on safe code. Precisely because those on safe blocks have promised the outside world, the colors, that everything is safe. Trust me bro!

There are things that are just not possible to do in Rust without those unsafe blocks. For example, your olde C style linked lists, or certain hardware / memory twiddling bits, or (I think) thunking into C libraries. For everything else, you just use plain rust and you get all the guarantees that the language offers you.

Too long didn't read version. Unsafe code writers are putting everything on the line to make sure that everybody else around them is safe.

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 18:32:53 +0000

> but pattern matching and exhaustiveness checking

This was magical to me too. At first it felt super awkward because it felt like an inversion of the order in which things are supposed to read like. But when it clicked... oh my god. Combining that with the question mark or the return inside of the match, it really helped simplifying the structure of the happy path that I could read.

I am so happy I learned Rust. And I've even happier that I'm getting paid to do it.

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 18:30:10 +0000

Addendum:

In case it's interesting for the readers here, the current firm I'm working at started the system that we are developing with Haskell. We had a lot of researchers that were super talented and were able to crank out what I consider pretty high quality code at the very beginning using nothing but Haskell.

The problem is that once you need to grow past 10 engineers, or in this case computer scientists, you can't. Finding 10 Haskell programmers in a Haskell conference is fairly easy. Finding the 11th to join your team when there's no conference going on is almost impossible. Hasklers are wicked smart, and because they're wicked smart, they're wicked rare.

So what did we do after that? We switched our system to Rust. Of course, the system continues to have the same type structure to the extent that it is possible, that it had back in the era when it started as Haskell. And all the Haskell programmers quickly adapted to using Rust because the type system in Rust is less complex than the type system in Haskell, so for them it was a downgrade. But we were able to quickly triple the amount of programmers that we had developing the system.

And the system continues to grow, and it has pretty high code quality for the standards of my career — I've seen code maybe 25 years? I routinely refactor the innards of the system without fearing that I'm going to break something somewhere else, somewhere deep in the system. I don't think I've ever felt so free to actually change the code without having the dread inside of me that it's going to catastrophically explode in production. Two years, and I have yet to put a bug in the system. That is almost completely magical.

Thoughts and clarifications

pizza — Sun, 22 Sep 2024 18:29:13 +0000

> you just have to read a little code and push a button in a webpage and you can see it. And they just refuse. It is so oddly disconcerting.

$ sloccount `find projdir -name *.[ch]`
[...]
Total Physical Source Lines of Code (SLOC) = 2,278,858

Call me naive, but "read a little code and push a button on a web page" isn't going to cut it.

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 18:24:39 +0000

> Rust will have its Eternal September, when relatively average-to-mediocre corporate body farms start cranking it out. At that point, "Rust Culture" goes out the window as the only "culture" that matters is what falls out of coroporate metrics<->reward mappings.

I haven't seen so far, at least in decades of me working in the industry, that eternal September has arrived to Haskell.

And I don't think that's going to happen. At least in Haskell. Maybe in Rust will. Maybe it won't.

There is a set of conceptual difficulties associated with learning any programming language, and it is not the same, depending on the language. Learning ATARI basic is one thing, (by the way that's the first language I learned). Learning Python is another Learning assembly is yet another Learning Haskell is another.

To pull the conversation away from the realm of language and just talk about concepts, pretty much any programmer can program using a stringly typed interface (which we all know leads to shitty code). But not every programmer is capable of learning the Haskell type system (I know I can't but ikcan understand how it leads to improved type safety and thus code quality).

All of this is to say that we're not all made equal. And because we're not all made equal, we are not all able to use the same tools. Just as we are not all able to wield a sledgehammer that weighs 30 pounds and break down a wall, so we are just as unequal to wield a specific programming language with skill and produce the results that one wants. Evolution does not stop at the neck.

But what do i know? Perhaps Haskell will get its eternal September? All i know is i can't learn it. Or at least I'm humble enough to admit that.

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 18:19:21 +0000

> That same argument applies to any statically-typed language, even (*gasp*) C.

No. Not even close.

You can make a change in C struct, such that you're missing a member of the struct, and maybe the compiler will complain that you missed initialization somewhere of that struct member. That is true.

But if you add to an enum somewhere, which represents a new state of the object that you are using the enum on, and that enum is used in an if, case or select statement somewhere else, C will happily ignore that you've done this, and compile just fine. Then your code doesn't work.

In Rust, when you do this, generally a selector case statement equivalent, which is called match, will not compile, because it knows that you've added a different case that your code does not handle. Only after you have fixed every site where this enum is used, will it compile.

This simple thing prevents entire classes of logic errors in your code.

There are quite a few other ergonomic changes that the language has over other languages that existed before rust, which work in a similar way. to give you just one other example:

You change a C struct to have a new member that has a pointer to another type. You painstakingly change every place where that struct needs to be initialized so that your program will compile and run. This program is multi-threaded, like the kernel is. You run, your program, and it crashes. In this particular case, that new member that refers to a pointer to this other structure was used at the wrong time. This is due behavior that wasn't there before when the first structure did not have a pointer to the second one.

This is not possible in Rust. The compiler, in fact, the borrow checker in the compiler, keeps track of where every pointer is going and where every pointer is used. And will not let you compile the program if you use a pointer or a reference when you are not supposed to, when it's supposed to be dead or not initialized, or if the lifetime of the object taking a reference to that thing is a different lifetime, incompatible with the lifetime of the object pointed to by the pointer. It even knows when you are using data that you're not supposed to be using because you will have forgotten to grab a lock. And it will tell you you need to change how this is done. Try this, try this other thing, try this other thing. It gives you options.

This is so far ahead of anything that the C language does, that in fact could be construed as magic by Ken, Dennis, and Donald. You need to see it with your own eyes to believe it, but it is amazing.

On a personal note, this conversation on this particular thread has exposed to me the wide difference of perspective that C developers and Rust developers have. Having developed years of my life with both languages, I have the uncomfortable advantage of having perspective from both sides. But to me, it really does feel like we're arguing versus horses and carriages versus automobiles, or electric cars versus gas cars. I, too, thought Teslas were bullshit until I got on one, as a passenger, and the driver punched the pedal. Oh my god. It's a similar experience going from Python, or Go, or C, to Rust.

And I think that explains why a lot of people see what Rust developers say about the language, and then conclude, this must be a religion, or worse, a cult.

Thoughts and clarifications

pizza — Sun, 22 Sep 2024 18:11:44 +0000

> "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth

..Your blithe dismissal of Knuth as an "assembly and C programmer" doesn't invalidate his point. "Provably correct" doesn't mean that it actually *works*.

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 18:05:31 +0000

I have reason to believe that you are talking to people who have never seen a match statement in their lives. And so they're used to knowing that when they make a change somewhere in the code, somewhere else very, very far away, and if or case select statement no longer matches that condition that you just added to the code, and therefore things break spectacularly at runtime.

That lack of experience is why they continue issuing the truism that refactoring is "very difficult" and you don't really know when you're changing code if something else is going to break. They haven't gotten the compiler to yell at them, "you're missing this case", because they have never experienced it. Reflectoring is super easy when the computer is doing the thinking of myriad otherwise irrelevant trivialities for you!

There really is something magical about it. And to try and explain to people that haven't seen that, quote, magic, is almost impossible. It's like trying to explain electricity to someone from the 1600s. And it is equally frustrating. In fact, it is doubly frustrating because unlike electricity in the 1600s, this is something that is very easy to witness, you just have to read a little code and push a button in a webpage and you can see it. And they just refuse. It is so oddly disconcerting.

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 17:58:45 +0000

> "just change the definition and your job is done when the compiler stops complaining" is laughably naive.

In C. And assembly.

> Donald Knuth

— famous C and assembly developer

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 17:57:49 +0000

> Have you ever seen a moderately complex *RUST* codebase that is easy to refactor?

Yes, I have.

Because the compiler yells at me all the way until I'm done with the refactor, which is awesome. Because I know at the end of the refactor, my refactor is almost certain to work properly. Because Rust forced all of the developers before me to encode the behavior of the APIs and the algorithms in the type system.

And the type system + the borrow checker do not forgive you or give you free passes. You cannot cast to void yourself around it. You cannot pass some sort of shim that could have a bug itself. You cannot hold a pointer for the wrong timespan. You have to fix it correctly.

Sure, you can leave a bunch of functions empty, effectively not doing your job in not finishing the refactor, and obviously the program is going to break after that.

But if you do your job, it is substantially easier than refactoring a C code base, only to discover that the first time you run it corrupts your data, or it crashes, or it works for a good while without any problems, and you discover all those issues much later down the road.

Anecdotally, Python refactorings have the same problem of C refactorings. In fact, it might actually be worse than C refactorings. Python with types is substantially easier to refactor than Python without types. But Rust? Refactoring Python is much harder, with without types, than refactoring Rust.

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 17:46:20 +0000

> Technically Rust culture is releasing new, incompatible, versions of crates very often.

If you are a Rust programmer, you are not forced to upgrade to the latest and greatest crate. You could just keep using the old crate, it's still published, you can still download it, and unless you have security issue, there's no issue for you. You can even use multiple versions of the same crate in the same project, and it just works. This is the opposite of move fast and break things. It is rather move fast, keep old things working the way they were.

Moreover, kernel developers don't gratuitously use crates like your comment would seem to imply. The vast majority of crates are simply unusable in the kernel because they depend on the standard library. And the standard library cannot be linked into the kernel because the standard library has some requirements regarding memory allocation that cannot be fulfilled by the kernel.

I find it absolutely amazing that you can add a few YAML lines to your GitHub project and there's an entire computer network that will automatically upgrade all of your crates in your Rust project that's on GitHub. And then subsequently your CI fires and everything is tested so that you know all the upgrade didn't break anything. I used that all the time. But this is absolutely unrepresentative of how kernel development with Rust code is done. Maybe someday that will be the case. Maybe in 25 years. We're not even close to that. We need to get even a few crates going in the kernel before that's even a concern in anyone's radar.

If anything, Rust in the kernel is actually move slow. And if we are to conclude anything from the rust for Linux developers' contributions to the Linux kernel, it has been move slow and fix other people's things.

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 17:41:32 +0000

> Especially since it seems that the Rust culture (that likes to ‘move fast and break things’)

🤣 where would anyone get that opinion from? Honest question!

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 17:40:23 +0000

Oftentimes yes, and you are completely correct about that.

However, the two controversies that I am seeing clearly here do not (at least to me) seem to be matter of opinion.

The technical controversy arising from that patch that fixed the circularity issue in the ownership of objects under DRM seems quite clear cut to me. Circularity is almost always bad design; and having some object hold a reference to another which holds a reference to the first (for printk()'s sake), which then prevents the first object from freeing the other or the other from freeing the first safely? Bad. Asahi's fix should have gone in without question, rather than invoke curt NAK.

The more social or human controversy about the animosity that Rust developers are getting from some kernel developers that do not want or do not appreciate some strictures that (they perceive) Rust is imposing on them? Well, you could argue it could go either way, but we have video. We have video of a rust developer explaining how the type system prevents certain classes of errors to an audience of C file system kernel developers. And one of the kernel developers interrupts him, doesn't let him finish and accuses him of trying to spread the Rust religion or impose it on the kernel space. This is comically easy to judge.

No one in the Rust for Linux project is trying to rewrite the kernel into Rust or trying to make everybody ditch C and learn Rust. (I would if I had a magic wand, but I don't). What I have seen indicates to me that Rust for Linux developers are discovering deficiencies in existing subsystems, and structures, and algorithms, and drivers, and APIs, and have been trying to fix those deficiencies with the best of intentions, and also have been trying to help the C developers see that there is a way that they can prevent having those deficiencies. And not everybody, not the majority, not many, But sadly a few kernel developers have reacted in a negative and destructive way to this effort.

A computer language that is more rigid than another has its drawbacks. And sometimes these drawbacks are very serious. But one thing that is not a drawback is with that language and its strictures help you find issues that were previously unseen before. Folks who are exposed to these previously unseen issues should be thankful that these issues have been brought to light because now that they can be seen and addressed, they can be fixed. Can you make bad APIs with Rust? Absolutely. Is it easier to make bad APIs with Rust than with C? struct void* struct {}.

Thoughts and clarifications

Rudd-O — Sun, 22 Sep 2024 17:24:50 +0000

> because the code is the doc when it comes to APIs,

Quite ironically, this is exactly what the rust for Linux people are trying to do. And it is not exaggeration to say that exactly that, wanting the code to document the behaviors of the API is what got Wedson interrupted by Ted.

Put the behavior of the API in the types. That is all what the Rust people are asking for. Nothing more. Actually, they're asking for something that's even less than that. They're asking for cooperation from the C part of the kernel so that they can do that work of putting the meaning of the API and the behaviors of the API into the type system so that the system can be safe and sound.

To me this controversy does sound like a few kernel developers, not everybody, not the majority, but a few, are seriously looking at a gift horse in the mouth. Maybe they just don't want the horse? And as a result, nobody else gets the pony we want.

Now I'm not a kernel developer, I'm simply a roast programmer, a fairly new one, but I do know, having used Linux since 1996, that I want superior kernel code quality and stability and fewer security issues. We are never getting there, unless we move on from C, at least for the critical parts of the system. And I frankly do not care if it is in Rust or in another language, But if we are going to jump out of a puddle and not fall into another, it has to be a type safe and sound language that protects against the sort of problems that see causes. There is this precious opportunity right now to take that chance by using Rust. I hope we don't squander the opportunity and have to wait 10 more years until either everybody is using a different operating system, or someone invents a superhuman AI that can type, check, see, and its runtime properties properly, or Linux has finally decided that it's going to incorporate sound and type safe programming tooling beyond C + glorified linters.