I heard that C developers are trained to use memory smartly
Kernel coders are an entirely different breed, and when I worked with a few of them they were just stunning. The smartest man I know on the planet so far coded on the Unix kernel – the one that IBM forced back to Novell who’d already fired their staff after selling it, and thus shelved it and killed Unix. He is and was amazing.
So yes, I can confirm that Kernel devs know how to manage their memory – they use very little, they allocate and free it, and they build very small, tight, optimized kernels by knowing how the optimizer will do things and how to hint it to do what they know needs to happen.
Yeah, it’s a skill. Yeah, it takes skilled people. I’d like to one day find out that really big training wheels will let anyone build code that well, but I’ve seen the goal and I don’t expect we’re there yet.
They are amazing but at the end of the day they are still humans and they can make mistakes. In the YouTube video referenced one of the C devs is heavily against rust.
Decided to go look for CVEs from code the guy manages (Ted Ts’o) I found these
CVE-2024-42304 — crash from undocumented function parameter invariants
CVE-2024-40955 — out of bounds read
CVE-2024-0775 — use-after-free
CVE-2023-2513 — use-after-free
CVE-2023-1252 — use-after-free
CVE-2022-1184 — use-after-free
CVE-2020-14314 — out of bounds read
CVE-2019-19447 — use-after-free
CVE-2018-10879 — use-after-free
CVE-2018-10878 — out of bounds write
CVE-2018-10881 — out of bounds read
CVE-2015-8324 — null pointer dereference
CVE-2014-8086 — race condition
CVE-2011-2493 — call function pointer in uninitialized struct
CVE-2009-0748 — null pointer dereference
Do you see a pattern in the type of error here? It’s pretty much entirely memory related and right in the wheelhouse of something rust would just outright not allow short of just slapping everything into unsafe blocks.
The Old Guard is not perfect, and they are acting as a barrier to new talent coming in. Sometimes change is good and I’m heavily in the camp that rust one of those times. Linus seems to agree as he allowed the code into the kernel which he would never do lightly or just because it’s fomo
But on the other hand you can’t expect some smaller and smaller subset of the population to primarily just learn C and meet the criteria of a kernel dev.
I absolutely agree with all your points, and most rust devs would agree, but the general idea is that over time that energy (which would have been spent tweaking malloc and such) should be spent on the rust compiler and memory management systems, which is already magic as someone who as written a lot of c, c++, and spent the better part of a year learning rust. (I’m no expert of course, but I have a pretty decent grasp on the low level memory management of both the Linux kernel and the rust compiler).
So that over time the effort that would be spent on memory management and kernel functionality can be properly divided. Rust not being efficient somewhere in catching memory faults or managing memory? Fix it. Someone writing unsafe rust code? Fix it.
I think at the end of the day everyone wants the same thing which is a memory safe kernel, and I think that rust Is being shoehorned into kernel projects too early in places where it shouldn’t be, but I also think there is unnatural resistance to it just because it’s different elsewhere to “how it’s always been done.”
I guess the question is, what happens to the kernel when all the people who learned on C are gone? The majority of even the brightest new devs aren’t going to cut their teeth on C, and will feel the same resistance to learning a new language when they think that there are diminishing returns to be had compared to what’s new and modern and, most importantly, familiar.
I honestly get the hostility, the fast pace of technology has left a lot of older devs being seen as undesirable because the don’t know the new stuff, even if their fundamental understanding of low level languages could be a huge asset. Their knowledge of C is vast and valuable, and they’re working on a project that thrives because of it. To have new people come to the project and say “Yeah, we could do this without having to worry about all that stuff” feels like throwing away a lot of the skill they’ve built. I’m not sure what the solution is, I really don’t think there are enough new C developers in the world to keep the project going strong into the future though. Maybe a fork is just the way to go; time will tell which is more sustainable.
Kernel coders are an entirely different breed, and when I worked with a few of them they were just stunning. The smartest man I know on the planet so far coded on the Unix kernel – the one that IBM forced back to Novell who’d already fired their staff after selling it, and thus shelved it and killed Unix. He is and was amazing.
So yes, I can confirm that Kernel devs know how to manage their memory – they use very little, they allocate and free it, and they build very small, tight, optimized kernels by knowing how the optimizer will do things and how to hint it to do what they know needs to happen.
Yeah, it’s a skill. Yeah, it takes skilled people. I’d like to one day find out that really big training wheels will let anyone build code that well, but I’ve seen the goal and I don’t expect we’re there yet.
Let the kernel be built by kernel devs.
They are amazing but at the end of the day they are still humans and they can make mistakes. In the YouTube video referenced one of the C devs is heavily against rust.
Decided to go look for CVEs from code the guy manages (Ted Ts’o) I found these
CVE-2024-42304 — crash from undocumented function parameter invariants
CVE-2024-40955 — out of bounds read
CVE-2024-0775 — use-after-free
CVE-2023-2513 — use-after-free
CVE-2023-1252 — use-after-free
CVE-2022-1184 — use-after-free
CVE-2020-14314 — out of bounds read
CVE-2019-19447 — use-after-free
CVE-2018-10879 — use-after-free
CVE-2018-10878 — out of bounds write
CVE-2018-10881 — out of bounds read
CVE-2015-8324 — null pointer dereference
CVE-2014-8086 — race condition
CVE-2011-2493 — call function pointer in uninitialized struct
CVE-2009-0748 — null pointer dereference
Do you see a pattern in the type of error here? It’s pretty much entirely memory related and right in the wheelhouse of something rust would just outright not allow short of just slapping everything into unsafe blocks.
The Old Guard is not perfect, and they are acting as a barrier to new talent coming in. Sometimes change is good and I’m heavily in the camp that rust one of those times. Linus seems to agree as he allowed the code into the kernel which he would never do lightly or just because it’s fomo
But on the other hand you can’t expect some smaller and smaller subset of the population to primarily just learn C and meet the criteria of a kernel dev.
I absolutely agree with all your points, and most rust devs would agree, but the general idea is that over time that energy (which would have been spent tweaking malloc and such) should be spent on the rust compiler and memory management systems, which is already magic as someone who as written a lot of c, c++, and spent the better part of a year learning rust. (I’m no expert of course, but I have a pretty decent grasp on the low level memory management of both the Linux kernel and the rust compiler).
So that over time the effort that would be spent on memory management and kernel functionality can be properly divided. Rust not being efficient somewhere in catching memory faults or managing memory? Fix it. Someone writing unsafe rust code? Fix it.
I think at the end of the day everyone wants the same thing which is a memory safe kernel, and I think that rust Is being shoehorned into kernel projects too early in places where it shouldn’t be, but I also think there is unnatural resistance to it just because it’s different elsewhere to “how it’s always been done.”
I guess the question is, what happens to the kernel when all the people who learned on C are gone? The majority of even the brightest new devs aren’t going to cut their teeth on C, and will feel the same resistance to learning a new language when they think that there are diminishing returns to be had compared to what’s new and modern and, most importantly, familiar.
I honestly get the hostility, the fast pace of technology has left a lot of older devs being seen as undesirable because the don’t know the new stuff, even if their fundamental understanding of low level languages could be a huge asset. Their knowledge of C is vast and valuable, and they’re working on a project that thrives because of it. To have new people come to the project and say “Yeah, we could do this without having to worry about all that stuff” feels like throwing away a lot of the skill they’ve built. I’m not sure what the solution is, I really don’t think there are enough new C developers in the world to keep the project going strong into the future though. Maybe a fork is just the way to go; time will tell which is more sustainable.