Wedson Almeida Filho is a Microsoft engineer who has been prolific in his contributions to the Rust for the Linux kernel code over the past several years. Wedson has worked on many Rust Linux kernel features and even did a experimental EXT2 file-system driver port to Rust. But he’s had enough and is now stepping away from the Rust for Linux efforts.
From Wedon’s post on the kernel mailing list:
I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it’s best to leave it up to those who still have it in them.
…
I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.
Lastly, I’ll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 – and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code."
RUST ppl feel like ARCH ppl. yes it might be better than some other setup yadda yadda, but they are so enervating.i’d rather switch back to windows11 than read another post/blog on how som crustians replaced this or that c library. just shut up already.
Arch people tell you “I use arch BTW”
Rust people make PRs rewriting your code in rust.
Rust people are worse.
The sad thing is, there are other languages better at replacing C/C++ due to closer resemblance, except they’re rarely used due to lack of trendy technology that is being hyped in Rust. D lost a lot of ground due to its maintainers didn’t make it an “immutable by default” language at the time when functional programming paradigm was the next big thing in programming (which D can still do, as long as you’re not too fussy about using
consteverywhere).It was never about replacing C with a new language for the sake of novelty, it was about solving the large majority of security vulnerabilities that are inherent in memory-unsafe languages.
If Rust were to implode tomorrow, some other memory-safe language would come along and become equally annoying to developers who think they’re the first and only person to suggest just checking the code really hard for memory issues before merge.
if you were right they’d replace it with Java.
Rust’s memory safety is at compile-time. Java relies on a virtual machine and garbage collector. Nothing wrong with that approach but there’s a reason Rust is used in kernels and Java is used in userspace apps.
Java was invented 20 years sooner.
Who was the guy that had a lot of pauses with mmmmmm when talking?
omfg, that guy in the video…
The kernel is mostly written in C, by C developers… understandably they’re rather refactor C code to make it better instead of rewritting everything in the current fancy language that’ll save the world this time (especially considering proponents of said language always, at every chance they get, sell it as C is crap, this is better).
Linux is over 30yo and keeps getting better and more stable, that’s the power of open-source.
at every chance they get, sell it as C is crap, this is better
For ‘sendmail’ values of $C, this resembles another argument. Also, of course for $C=sysvinit.
This sounds exactly like the type of nontechnical nonsense they’re complaining about: attacking a strawman (“they’re trying to prevent people from refactoring C code and making them rewrite everything in the current fancy language”) even after explicitly calling out that that was not going to happen (“and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code”).
They said it wasn’t going to happen but their plan will result in it happening, how do you square that?
You tell me how it will result in it happening. Who even has the power to force people to learn Rust?
Linus and GKH, if they merge something that breaks every time C programmers change a kernel API
And where did you find that they will do that?
C is crap for anything where security matters. I’ll happily take that debate with anyone who thinks differently.
No idea what you’re being downvoted. Just take a look at all the critical CVSS scored vulnerabilities in the Linux kernel over the past decade. They’re all overwhelmingly due to pitfalls of the C language - they’re rarely architectural issues but instead because some extra fluff wasn’t added to double check the size of an int or a struct etc resulting in memory corruption. Use after frees, out of bounds reads, etc.
These are pretty much wiped out entirely by Rust and caught at compile time (or at runtime with a panic).
The cognitive load of writing safe C, and the volume of extra code it requires, is the problem of C.
You can write safe C, if you know what you’re doing (but as shown by the volume of vulns, even the world’s best C programmers still make slip ups).
Rust forces safe® code without any of the cognitive load of C and without having to go out of your way to learn it and religiously implement it.
They’re being downvoted because it’s a silly comment that is basically unrelated and also extremely unhelpful. Everyone can agree that C has footguns and isn’t memory safe, but writing a kernel isn’t memory safe. A kernel written in Rust will have tons of unsafe, just look at Redox: https://github.com/search?q=repo%3Aredox-os%2Fkernel unsafe&type=code That doesn’t mean it isn’t safer, even in kernel space, but the issues with introducing Rust into the kernel, which is already written in C and a massive project, are more nuanced than “C bad”. The religious “C bad” and “C good” arguments are kinda exactly the issue on display in the OP.
I say this as someone who writes mostly Rust instead of C and is in favor of Rust in the kernel.
The difference is that now you have a scope of where the memory unsafe code might be(unsafe keyword) and you look there instead of all the C code.
I agree and think that should be helpful, but I hesitate to say how much easier that actually makes writing sound unsafe code. I’d think most experienced C developers also implicitly know when they’re doing unsafe things, with or without an
unsafeblock in the language – although I think the explicitunsafeshould likely help code reviewers and tired developers.It is possible to write highly unsafe code in Rust while each individual
unsafeblock appears sound. As a simple example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6a1428d9cae5b9343b464709573648b4 [1] Run that onDebugandReleasebuilds. Notice the output is different? Don’t take that example as some sort of difficult case, you wouldn’t write this code, but the concepts in it are a bit worrisome. That code is a silly example, but each individualunsafeblock appears sound when trying to reason only within the block. There is unsafe behavior happening outside of theunsafeblocks (thedo_some_thingsfunction should raise eyebrows), and the function we ultimately end up in has no idea something unsafe has happened.Unsafe code in Rust is not easy, and to some extent it breaks abstractions (maybe pointers in general break abstractions to some extent?).
noaliasesin that playground code rightly assumes you can’t have a&refand&mut refto the same thing, that’s undefined behavior in Rust. Yet to understand the cause of that bug you have to look at all function calls on the way, just as you would have to in C, and one of the biggest issues in the code exists outside of anunsafeblock.[1]: If you don’t want to click that link or it breaks, here is the code:
fn uhoh() { let val = 9; let val_ptr: *const usize = &val; do_some_things(val_ptr); println!("{}", val); } fn do_some_things(val: *const usize) { let valref = unsafe { val.as_ref().unwrap() }; let mut_ptr: *mut usize = val as *mut usize; do_some_other_things(mut_ptr, valref); } fn do_some_other_things(val: *mut usize, normalref: &usize) { let mutref = unsafe { val.as_mut().unwrap() }; noaliases(normalref, mutref); } fn noaliases(input: &usize, output: &mut usize) { if *input < 10 { *output = 15; } if *input > 10 { *output = 5; } } fn main() { uhoh(); }
The cognitive load of writing safe C, and the volume of extra code it requires, is the problem of C.
Oh no, i’m having a meltdown with all the cognitive load…
Build all the fancy tools you want. At the end of the day if you put a monkey at the wheel of a Ferrari you’ll still have problems.
Nice that Rust is memory-safe, use it if you want, but why the insistence on selling Rust via C is crap? Doesn’t earn you any points.
How about rustaceans fork the kernel and once it’s fully Rust-only then try and get it to be used instead of the current one… win-win, eh?
At the end of the day if you put a monkey at the wheel of a Ferrari you’ll still have problems.
My eyes are rolling onto the floor and down the stairs.
I honestly like the cognitive load. Just not when I am at the workplace, having to deal with said load, with the office banter in the background and (not so) occasionally, being interrupted for other stuff.
And my cognitive load is not even about the memory allocations, most of the time.Off topic:
I think, if one is seriously learning programming from a young age, it is better to start with C, make a project, big enough to feel the difficulty and understand what the cognitive load is all about and get used to it, hence increasing their mental capability. Then learn the memory safe language of their choice.
I never made a big enough project in C, but you can get to feel the load in C++ too.Yes a monkey. All the vulnerabilities that have happened over the decades are just bad c programmers. So the question is are there any good c programmers?
It’s not just about bad/good C programmers. It’s also about how much of the context, the given C programmer has read to make sure they know enough of what they are doing.
No matter how good one is at Programming, they need to make sure to read and remember what is happening in relevant parts of code, while making their one off contribution.
That’s where the part of “leaving it to the computer” comes in. Hence, the usefulness of code checkers and even better if the compiler itself enforces the stuff. As long as the rules are good enough.
Let’s just hope we are not jumping to another language 20 years down the line.
Someone stubbed a toe here.
I’m not insisting anything; stating C is not a memory-safe language isn’t a subjective opinion.
Note I’m not even a Rust fan; I still prefer C because it’s what I know. But the kernel isn’t written by a bunch of Lewis Hamiltons; so many patches are from one-time contributors and the kernel continues to get inundated with memory safety bugs that no amount of infrastructure, testing, code review, etc is catching. Linux is written by monkeys with a few Hamiltons doing their best to review everything before merging.
Linus has talked about this repeatedly over the past few years at numerous conferences and there’s a reason he’s integrating Rust drivers and subsystems (and not asking them to fork as you are suggesting) to stop the kernel stagnating and to begin to address the issues like one-off patches that aren’t maintained by their original author and to start squashing the volume of memory corruption bugs that are causing 2/3rds of the kernel’s vulnerabilities.
the kernel continues to get inundated with memory safety bugs that no amount of infrastructure, testing, code review, etc is catching.
I’d say this is the issue to fix. It’s not easy but if anything curl has proven it can be done efficiently.
Yeah, let’s see what Bagder has to say about this:
C is unsafe and always will be
The C programming language is not memory-safe. Among the 150 reported curl CVEs, we have determined that 61 of them are “C mistakes”. Problems that most likely would not have happened had we used a memory-safe language. 40.6% of the vulnerabilities in curl reported so far could have been avoided by using another language.
Rust is virtually the only memory-safe language that is starting to become viable.
https://daniel.haxx.se/blog/2023/12/13/making-it-harder-to-do-wrong/
Memory safe language that’s becoming viable … as a proper replacement of C.
There are many other memory safe languages out there. Just not ones most would like to pull in to the kernel…
having to go out of your way to learn it and religiously implement it.
Look! I painted the mona lisa in ketchup.
C isn’t even bad, as long as you use the minimum amount required and do a LOT of security analysis on every line you write.
The problem with C code isn’t necessarily the language, a lot of it is the culture of people who think that unlike everyone else, they can write good, secure, bug-free C code, and they can ignore the warnings. They’re just that good!
These people seem to take the mere concept of a language that enforces memory access or security features as an insult to their intelligence.
Because of this bullshit, Linux is now behind in terms of Rust take up as Windows has begun rewriting components into Rust. I wouldn’t be surprised if the ego-based in-fighting between kernel devs will lead to Windows being significantly more secure in a few years.
Agree. I’m an absolutely awesome software dev myself - and I know C by heart (being my favorite language after assembler). However, with age comes humility and the ability to recognize that I will write buggy code every now and then.
Better the language saves me when I can’t, in security critical situations.
Even if you manage to keep all memory accesses in your memory, while writing the code, there’s a good chance you’ll forget something when reviewing another person’s MR. That’s probably the main problem creator.
Still, a language that you are familiar with, is better than a new language that you haven’t finished reading the specifications of. And considering that adding new maintainers comes with a major effort of verifying trustworthiness, I get how it would be harder to switch.
such a weird dichotomy in Windows – secure kernel space and privacy-nightmare user space … “we’re the only ones allowed to steal your data”
It’s a real shame. I would’ve loved running the Windows 7 or Windows XP userland on the Windows 11 kernel.
I think most people would agree with you, but that isn’t really the issue. Rather the question is where the threshold for rewriting in Rust vs maintaining in C lies. Rewriting in any language is costly and error-prone, so at what point do the benefits outweigh that cost and risk? For a legacy, battle-tested codebase (possibly one of the most widely tested codebases out there), the benefit is probably on the lower side.
Seeing as how 40% of the security issues that have been found over the years wouldn’t exist in a memory-safe language, I would say a re-write is extremely worth it.
Isn’t that exactly the strawman the maintainer got tired of?
Hmm… I admit I didn’t follow the video and who was speaking very well and didn’t notice hostility that others seem to pick up on. I’ve worked with plenty of people who turn childish when a technical discussion doesn’t go their way, and I’ve had the luxury of mostly ignoring them, I guess.
It sounded like he was asking for deeper specification than others were willing or able to provide. That’s a constant stalemate in software development. He’s right to push for better specs, but if there aren’t any then they have to work with what they’ve got.
My first response here was responding to the direct comparison of languages, which is kind of apples and oranges in this context, and I guess the languages involved aren’t even really the issue.
Part of the hostility was the other maintainer misunderstanding the presenter, going on a diatribe about how the kernel Rust maintainers are going to force the C code to become unrefactorable and stagnate, and rudely interrupting the presenter with another tangent whenever he (the presenter) tried to clarify anything.
An unpleasant mix of DM railroading and gish galloping, essentially.
I wouldn’t quite call it a strawman, butthe guy was clearly not engaging in good faith. He made up hypothetical scenarios that nobody asked about, and then denigrated Rust by attacking the scenarios he came up with.Edit: I was thinking of the wrong fallacy. It is a strawman, yes.
He made up hypothetical scenarios that nobody asked about, and then denigrated Rust by attacking the scenarios he came up with.
This seems to be the textbook description of a strawman argument.
Wait, yeah. I was thinking of ad hominem when i wrote that, sorry. Correct, that is a strawman.
If the timeline is long enough then it’s always worth the refactor.
Maybe when you build some little application or whatever. When building the most used kernel in the world, there are probably some considerations that very few people can even try to understand.
C is crap for anything where security matters.
True for people misusing it. If you want to argue the ease of mis-use, it’s a fun talk.
Yea, it’s not C that is crap, but that it has zero guard rails. Like blaming a knife for not having a guard… Is it a bad knife without a guard? Depends on how sharp it is. The guard is orthogonal to the knife’s purpose, but might still be important when the knife is used.
Just because something doesn’t help prevent accidents does not mean it cannot serve its actual purpose well, unless its actual purpose is safety.
What debate? You offered zero arguments and “C bad tho” isn’t one.
Do you believe C isn’t crap when it comes to security? Please explain why and I’ll happily debate you.
/fw hacker, reverse engineer
That’s not how it works. You said:
C is crap for anything where security matters.
Argue for your point.
Link dropping is also not arguing.
Citing scientific research is. Now, please post your gut feeling in response.
Lots of categories which Rust doesn’t prevent, and in the kernel you’ll end up with a lot of
unsafeRust, so it can’t guarantee memory-safety in all cases.The biggest items on the graph are all out of bounds accesses, use-after-free and overflows. It is undeniable that memory safe languages help reducing vulnerabilities, we know for decades that memory corruption vulnerabilities are both the most common and the most severe in programs written in memory-unsafe languages.
Unsafe rust is also not turning off every safety feature, and it’s much better to have clear highlighted and isolated parts of code that are unsafe, which can be more easily reviewed and tested, compared to everything suffering from those problems.
I don’t think there is debate here, rewriting is a huge effort, but the fact that using C is prone to memory corruption vulnerabilities and memory-safe languages are better from that regard is a fact.
From other discussions I’ve seen, the guy stepping down was frustrated by having C code rejected that made lifetime guarantees more explicit. No rust involved. The patch was in service of rust bindings, but there was 0 rust code being reviewed by maintainers.
Most reasonable people say c is good, rust is better
Better in what ways? Rust’s strong points are not to just make a program more stable, but more secure from a memory standpoint and I don’t think Linux keeps improving on that
Some next level deaf going on. That’s not what was being discussed.
The defensiveness proves just how out of touch and unqualified to comment some people are.
Someone linked the thread from Phoronix forum and the comments are so awful. Imagine having to deal with people like this.
One of them reads:
We need Microsoft people like we need fleas. Why can’t they work for projects we don’t like, like GNOME?
It is funny because Ts’o works at Google, lol.
Phoronix comments were always dumb, like, infuriating bad, I don’t even read them anymore, the moderation on that site don’t give a fuck about toxicity in there
Avis/Bridei/Artem has been active as a super troll on that forum for years and absolutely nothing had been done
I’ve asked one question, one time in those comments and it just got buried in people spitting venom at each other about their file system preferences.
Beyond moderation, Phoronix is a case study in why downvotes are a good thing. Those idiots going on dumb tangents would continue, while the rest of us can read the actual worthwhile comments (which does happen, given AMD employees and the like comment there sometimes).
Phoronix comments are a special place on the internet. Don’t go there for a good discussion.
I once started reading the comments on bcachefs. It was a extremely heated for no reason. People were screaming on the nature of btrfs
This is a little off topic and admittedly an oversimplification, but people saying Rust’s memory safety isn’t a big deal remind me of people saying static typing isn’t a big deal.
Totally
Video url:
Ted Ts’o is a prick with a god complex. I understand his experience is hard to match, we all have something in our lives we’re that good at, but that does not need to lead to acting like a fucking religious fanatic.
No intention of validating that behavior, it’s uncalled for and childish, but I think there is another bit of “nontechnical nonsense” on the opposite side of this silly religious war: the RIIR crowd. Longstanding C projects (sometimes even projects written in dynamic languages…?) get people that know very little about the project, or at least have never contributed, asking for it to be rewritten or refactored in Rust, and that’s likely just as tiring as the defensive C people when you want to include Rust in the kernel.
People need to chill out on both sides of this weird religious war. A programming language is just a tool: its merits in a given situation should be discussed logically.
I imagine this mentality is frustrating because of how many times they have to explain that they weren’t forcing people to learn Rust and that the Rust bindings were second class citizens. They never said to rewrite the kernel in Rust.
That’s disengenuous though.
-
We’re not forcing you to learn rust. We’ll just place code in your security critical project in a language you don’t know.
-
Rust is a second class citizen, but we feel rust is the superior language and all code should eventually benefit from it’s memory safety.
-
We’re not suggesting that code needs to be rewritten in rust, but the Linux kernel development must internalise the need for memory safe languages.
No other language community does what the rust community does. Haskellers don’t go to the Emacs project and say “We’d like to write Emacs modules, but we think Haskell is a much nicer and safer functional language than Lisp, so how about we add the capability of using Haskell and Lisp?”. Pythonistas didn’t add Python support to Rails along side Ruby.
Rusties seem to want to convert everyone by Trojan horsing their way into communities. It’s extremely damaging, both to those communities and to rust itself.
It doesn’t help that the Rust community tends to bring extremely divisive politics with it in places and ways that just don’t need to happen, starting battles that aren’t even tangentially related to programming.
-
That is the most sensible look into this so far.
Agreed. His experience might be useful if he were there to engage, but he’s clearly not. It seems like he just wanted to shout down the project and it seems like he was somewhat successful.
I understand his experience is hard to match, we all have something in our lives we’re that good at
At some point, that mix of experience and ego becomes a significant liability. He’s directly hurting the adoption of Rust in the kernel, while the C code he’s responsible for is full of problems that would have been impossible if written in safe Rust.
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 dereferencecrash from undocumented function parameter invariants
My favourite, as that was the exact point the dev was making in his talk, that the stuff is badly documented and that the function signature would document it perfectly.
My favorite, as that is the exact point made by anti-rust people.
What kind of type signature would prove the first block of any directory in an ext4 filesystem image isn’t a hole?
The first directory block is a hole. But type == DIRENT, so no error is reported. After that, we get a directory block without ‘.’ and ‘…’ but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash
The problem isn’t that the block is a hole. It’s that the downstream function expects the directory block to contain
.and.., and it gets given one without because of incorrect error handling.You can encode the invariant of “has dot and dot dot” using a refinement type and smart constructor. The refined type would be a directory block with a guarantee it meets that invariant, and an instance of it could only be created through a function that validates the invariant. If the invariant is met, you get the refined type. If it isn’t, you only get an error.
This doesn’t work in C, but in languages with stricter type systems, refinement types are a huge advantage.
Wouldn’t it still crash when the smart constructor was called?
If it were poorly designed and used exceptions, yes. The correct way to design smart constructors is to not actually use a constructor directly but instead use a static method that forces the caller to handle both cases (or explicitly ignore the failure case). The static method would have a return type that either indicates “success and here’s the refined type” or “error and this is why.”
In Rust terminology, that would be a
Result<T, Error>.For Go, it would be
(*RefinedType, error)(where dereferencing the first value without checking it would be at your own peril).C++ would look similar to Rust, but it doesn’t come as part of the standard library last I checked.
C doesn’t have the language-level features to be able to do this. You can’t make a refined type that’s accessible as a type while also making it impossible to construct arbitrarily.
You can do that in C, too.
Dude, three CVEs were enough. Stop kicking the blood puddle.
Who is Ted Ts’ in this context?
He’s the guy you hear vexing rust in the video posted. While both languages have their pros and cons, he chooses to just blast this other guy by repeating the same crap over and over without letting him reply. Basically the kind of person with a “I win because I’m louder” demeanor.
I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.
Maybe that’s not a bad thing? If you ask me the GNU people are missing a trick. Perhaps if they rewrote Hurd in Rust they could finally shed that “/Linux”.
Maybe a pipe dream, but I would love to see RedoxOS get some traction. A rust based microkernel is a promising concept.
GNU isn’t punchy though; as soon as any punchy word get’s associated with them, people will use that word instead, and we’ll just get GNU/Thermite or GNU/Abson or something.
Easy, GNU->GUN
Gun! Unix? Not!
Are the version numbers going to be mm or caliber?
Gotta be mm to make sense unfortunately, Linux-GUN 7.62.11
They will write kernel in Ada
old white man scared of losing their jobs or their commits going insigificant…who cares. Lets move on.
deleted by creator
Losing their jobs? Uh what?
the guy speaking off camera in the linked 3min 30s of the video is Ted Ts’o, according to this report about the session.
Who the fuck is this little shit? Can’t they even be a little considerate towards rust? Just because they have 15 years worth of inertia for C doesn’t mean they can close their eyes and say “nope, I’m not interested”. I do not see how the kernel can survive without making rust a first class citizen
It’s Ted Ts’o, the maintainer of the ext4 filesystem amongst other things.
little shit
Though you’re still accurate despite his seniority.
There’s really only one valid response to Ted Ts’o:
If you think you can do better with C, prove it.
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 dereferenceYou seem really invested in pointing out those shortcomings. I respect that.
Arrogant hypocrites are a pet peeve of mine. If someone is going to act like progressive technology changes are beneath them and unnecessary, they should be able to put their money where their mouth is.
Somebody needs to send a public email to the kernel mailing lists with this
How many vulnerabilities have the kernel Rust team introduced in the same time period on the same code?
Let me know when you find one?
Memory ownership isn’t the only source of vulnerabilities. It’s a big issue, sure, but don’t think rust code is invulnerable.
Of course. Rust isn’t immune to logic errors, off-by-one mistakes, and other such issues. Nor is it memory safe in
unsafeblocks.Just by virtue of how memory safety issues account for 50%+ of vulnerabilities, it’s worth genuinely considering as long as the bindings don’t cause maintainability issues.
The bindings cause maintainability issues. That’s the problem.
I feel like the time to hide information behind YouTube links is over. Feels like a link to a paywall article at this point.
3min 30s, sample for context
If you keep watching for 10 minutes, it’s an interesting discussion. Too bad they had to cut it short due to time.
Oof, that video… I don’t have enough patience to put up with that sort of thing either. I wonder how plausible a complete Rust fork of the kernel would be.
Why not React?
You should do it. The Linux kernel is a C project. You can’t change a 30-year project on a dime. Make your own project with Rust and hookers.
I wonder how plausible a complete Rust fork of the kernel would be.
It sounds highly impractical, and it would probably introduce more issues than Rust solves, even if there were enough people with enough free time to do it. Any change must be evolutionary if it’s going to be achievable.
There’s certainly a history of Unix and Unix-like forks; which is rather simple compared to the Linux distro forks (go right to the big pic).
It’s always been this way. Except that it was kernel developers arguing with kernel developers over C code. Now it’s relative newcomers arguing with kernel developers over Rust code that the kernel devs don’t necessarily care about. Of course it’s going to be a mess.
A fork is of course possible, but operating systems are huge and very complex, you really don’t want to alienate these folks that have been doing exclusively this for 30 years. It would be hard to keep the OS commercially viable with a smaller group and having to do both the day to day maintenance, plus the rewrite. It’s already difficult as it is currently.
Rust will be a huge success in time, long after the current names have lost their impetus. This is not a “grind for 4 years and it’s done” project.
folks that have been doing this exclusively for 30 years
And yet the number of people I hear “just switch to Linux!” When the other person has been using Windows for 30 years blows my mind.
Inertia is a hell of a drug.
I wouldn’t tell a Windows developer with 30 years experience to just switch to developing for Linux.
Users are different. Most people who have used Windows for 30 years never touch anything outside of the desktop, taskbar and Explorer.It’s insane to find a windows user that doesn’t live in the terminal, it’s just not designed for it
Linux has a gui for everything
I have been using Windows for 30 years and Linux for 25 years (debian since 99’). I really would not bash (pun intended) windows users so much, there is place for both of them.
That person in the audience was really grinding my gears. Just let the folks you’re talking to answer you; no need to keep going on your diatribe when it’s based on a false assumption and waste the whole room’s time.
let’s not lose focus of what’s important here, and that is a room full of people hearing my voice and paying attention to me for as long as I manage to hold it
NOT a fork of Linux, but Redox is aiming for a Unix-like OS based on Rust – but even with “source compatibility” with Linux/BSD and drivers being in userspace, my guess would be hardware drivers are still going to be a big speed bump
Redox also takes some inspiration from Plan9 and https://doc.redox-os.org/book/ch05-00-schemes-resources.html is interesting. Also reading https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html made me a bit more interested in things trying to be more Plan9-like than Unix-like.
All you need nowadays for a decent Unix-like is compatibility with a handful of Linux softwares and a web browser. Hell, if you could get WINE working on your kernel you could maybe support as many Windows apps/games as Linux for free.
The big issue, as I see it, is performant drivers for a wide range of hardware. That doesn’t come easy, but I wonder if that can be addressed in a way I’m too inexperienced to know.
But projects like Redox are a genuine threat to the hegemony of Linux - if memory safety isn’t given the true recognition it deserves, projects like Redox serve to be the same disrupting force as Linux once was for UNIX.
Just fork and port Ext4 to Rust and let the little shit sit in his leaking kiddy pool out back.
That’s pretty well answered here: http://vger.kernel.org/lkml/#s15-3
Site is unreachable
What is so hard to understand, C Is a fucking security issues?
