Rust and C Linux Divide? + BCacheFS Tools removed from Debian + HUGE Win for Kernel Panics..
Вставка
- Опубліковано 20 вер 2024
- Linus the creator of Linux doesn't like this file system being in the kernel anymore.. BCacheFS Tools just got removed from Debian, but why? Kernel DRM is receiving a win for BSOD screens and error handling.
My Linux Cheat Sheet and 25 Page Checklist here:
📚 learn.savvynik...
Share this free tool and support Small UA-camrs
editbulk.com
(I made this tool to help creators)
Useful Commands/Links:
Discord: / discord
Zed - zed.dev/blog/z...
Linus BCacheFS - lore.kernel.or...
LinkedIn - / navigating-the-transit...
Linus Torvalds - • Is Linus throwing Bcac...
Wedson - lore.kernel.or...
Asahi Dev - vt.social/@lin...
Archetypes - airlied.blogsp...
BSOD - lore.kernel.or...
#linux #tech #pc
Things like filesystems and the kernel NEED to be stable. These low level things need to work 100% of the time (or as close as possible). I agree with the (ex) Debian maintainer and Linus here.
They need to work in such stability as medical software
When you submit to an open source project, you're being invited into someone's home. You have to respect that this is where they live, not you. After you get your PR merged, you get to screw off and go work on something else while the maintainers will have to fix the issues that come from your code. Requiring code to look and function like existing code helps to ensure that it won't conflict with other code and that maintainers can fix it later if it breaks.
Open source projects survive in the long term because their maintainers are hard-asses.
You act like everyone trying to contribute, that wasn't the first person on the scene, wants to submit a patch and fvck off.
From the message, it sounds like the (i assume) chick in the story is very dedicated to trying to contribute.
I've contributed to the Bazel project and the Diesel (Rust) OSS project this year and, overall, the analogy is valid. You have to respect the house rules, coding style, test convention etc in order to get your PR merged. Luckily, all of my PR's went through after a tough review process.
However, I also encountered these kind of C/C++ programmers that simply want Rust to go away for no obvious reason. I offered to write a Rust client for a very sophisticated commercial database system and its developer team, all C++ guys, were busy to make my life as hard as possible mainly with their C SDK being unable to compile anywhere else other than Linux X86. I understand that writing portable C code that is also fast is an order of magnitude harder than just writing really fast C code that is fully optimized for just one platform, I get it. Because the C bindings were required to build a Rust unsafe wrapper for a Rust SDK supposed to run on all Rust supported tier one platforms, well, to make this all work, a lot of ancient C code would have to be rewritten. Obviously, that never happened and the Rust client was abandoned ...
If you ignore the human element for a moment and accept the reality that nobody likes to re-write poorly designed ancient code, then you realize that a lot of software will be re-written from scratch in Rust with lessons learned from previous blunder.Those orgs who have the ressources to migrate legacy code to Rust, will do so by writing each sub system from scratch and, if you follow the Rust eco system a bit, you already see a lot of projects basically stating it is X, but in Rust.
As much as I would love to see Rust in the Linux Kernel, just give it more time and let it progress because, remember, nobody likes to rewrite poorly designed ancient code especially if the current maintainer isn't even the original author. Given that the entire embedded and Cloud industry is build upon the Linux Kernel, the Kernel project has a real mandate to keep the lights on, but more importantly, as the entire cloud industry pushes hard towards Rust for security reasons, the Kernel will eventually budge and make Rust a first class citizen; just not without a fight over legacy c code and that has to be sorted out over time.
@@marvin_hansen Idunno. The kernel is a huge beast. I've seen estimates of so many billions of dollars equivalent of coding effort having been spent on the kernel that no single company could afford to implement anything comparable. But IT has a history of coming up with technologies that speed up things orders of magnitude, make things orders of magnitude cheaper or allow things to scale out orders of magnitude higher, compared to what was there a decade or even less before that.
Rust is an extremely powerful language when it comes to large codebases - like the kernel. If resistente to change is too high, from the kernel developers, it might very well happen that at some point someone just forks the kernel, integrates all of the existing code into a build mechanism where C is the guest, no longer the host, and slowly but surely starts to rewrite increasingly more of it in Rust. Thirty years from now we'll then have a Rust kernel, with the migration to Rust done at a fraction, and a rather small, even tiny one, of the development cost of the kernel as we have it now.
@@marvin_hansen "no obvious reason"
Obvious reason: having to run rust in unsafe mode when using system libs.
Obvious cpp reason: smart pointers make rust's only claim to fame moot.
@@user-gh4lv2ub2j It's not _quite_ fair to say they eliminate rust's advantage. If someone uses a dumb pointer in a C++ project that's supposed to be all smart pointers, it requires a human in code review to spot it. In Rust, the compiler is supposed to spot it. Were Rust _just_ C++ with compiler enforced smart pointers, it might even be worth using.
For a kernel written in C (or any large legacy C project), Zig is the obvious candidate for compiler-enforced abstractions, as they interoperate without needing a manually maintained binding system.
Linus just had enough with people testing new feature in production and messing around with parts they are not supposed to
Linus is the reason Rust is in the Linux kernel right now. He commented this month at KubeCon his disappointment that kernel maintainers are resistant to it. He further reiterated the importance of Rust by sharing that the kernel still suffers from basic memory management issues constantly, and therefore adoption should be quicker.
@@mmstick Both could be true. Linus was annoyed by basic memory management issues, tried to introduce Rust, and then discovered that exactly the BCacheFS tools were developed with a deficient development model.
@@mmstick mr system76 man i literally see you everywhere.. no like actually everywhere wtf??!
@@mmstick Soon he will end without maintainers
Kent going off on how filesystems are dangerous if there are bugs and could corrupt files as if LInus hasn't dealt with filesystem code for the last couple of decades, linux 0.01 as released to the FUNET FTP servers in 1991 obviously didn't have a filesystem... oh wait, of course it did, the soure code is right there in the same fs directory in the source tree even.
Bcachefs looks to be an interesting and filesystem, but it is marked experimental and people are not and should not be expecting it to be stable and not ever corrupt files. It is not for production use and that is relatively clear. If files end up corrupted from using it at this point, then that is on the user that chose to use explicitely marked experimental kernel code.
Rust is not the issue with bcachefs developer not fitting in with the process at all. Now there are problems with some of the maintainers not understanding rust or how they might need to expose a particular strut or something and that is a problem.
Oh, man… I’m just a user, not coding outside of server scripts. ZFS has done a good job for our needs, ever since I implemented it within *BSD. It’s fine in Linux since a few years back.
Why “modern” at all cost? I sense some widespread tiredness from that notion… 😅
ZFS is great, but it is very memory hungry. I don't know anything about Bcachefs, but if it's more lightweight than ZFS, that could make it interesting for resource-constrained systems.
Because new tech often have benefits for that old may not have. Though maintanence cost may negate it intheend
@@User-hq6rr Yes, that used to be so, indeed… However, numbers & stats don’t tell that story these days, at least they show a certain split. Both demographically and for businesses in the B2C sector.
B2B and finance is fine, but not everyone’s cup of tea - for practical reasons, meaning price hikes, onshoring, de-clouding, ecology policies, user erosion, conflicts and… well… ongoing changes…?
They brought ideologies to coding, that's why it's tiresome.
Bcachefs by reading what it supports, and what limits has, seems to be like an early primitive Btrfs in the early days. Probably it needs another 6-8 years to mature.
And another 10 years for distros to adopt it and eventually make it their default filesystem, so that bcachefs's stability is proved
@@MadalinIgnisca or possibly ReiserFS .. looks good on paper, and it’s written by people with a few “interesting” personality traits
it has had 8 years most of it outside of kernel tree as an independent project (2016 it was started), but it seems the developer has a problem with working within the kernel development process nowit has been merged upstream.
As a Linux admin, I don't want a "modern" over a stable approach to software development in Linux. Linux is infrastructure and not some web app in a ephemeral container.
And you didnt get what this is about 😂. Linus wants Rust to fix the Memory Issues of the C code but is disappointed by devs being to conservative with using unsafe Code.
@@HksjJkdkdThat has literally nothing to do with what the video about? There’s plenty of unsafe code and there’s no aversion to using unsafe where necessary, I don’t understand what you’re talking and I don’t remember Linus ever saying anything like that?
@mc338 Rust is literally 10x more stable than C? Hello? Where have you been the last 20 years? Figures you’re an admin, I don’t even respect ‘programmers’ opinions on languages, much less admin’s.
what makes you think modern != not stable? Rust is set and done with peace in mind since memory issues are less prevalent.
That attitude though @@anonymousalexander6005
I'm not qualified to form a strong opinion whether Rust should be in the Kernel or not.
Probably only the top 1% of the developers actually can.
But when you see Linus with very good arguments and on the other hand you see an unknown person (or an agency behind it?) with fake name, fake visual representation and even a fake voice (yes, it was in a Brodie's podcast 2 yrs ago, hilarious to watch), and some vague talks about woods, roads, trees, it's not on the same level, it doesn't even need to be commented on. It's crap.
One should be able to compile and prep a kernel and its tools using only the resources on one's own machine. The moment you need a network repository (aka "npm") you have made it impossible to have your kernel be clean-room.
you can just do that? Just download the source code beforehand and use it locally? How do you think people get the linux source code?
Dont forget 'npm' and 'node' that you need to compile your kernel are not source-bootstrap-able, ie. Binary black box.
@@will_i_craft5555 If you need an off-machine repo to compile your code, you are no longer "local"
@@arkeynserhayn8370 Yah. When one does Linux From Scratch he/she needs to build the tools for compiling the kernel. That's why all distros ship the kernel tools with the kernel itself. If those tools have required off-machine repositories there's no way a local build -- particularly a bootstrap build -- is possible, because you always need the network stack operational.
@@unclesmrgol where do you think the linux kernel source code lives? It’s in a git, wait for it, repo.
I always thought people who use Rust never could figure out the modern tool chain C uses in 2024.
Seems like they assume C is like 1985 to justify using Rust. Unfortunately, the tool chain in 2024 for C is more than a match for Rust.
Imo there SHOULD be a new OS/Kernel to compete with Linux fully written in Rust or something else. Linux has it's own philosophy and culture. If people want a fully memory safe Kernel written in a completely different language they should make their own. Just like Linux did to Unix. Instead of trying to make Linux do everything at once
Been working on something like that since 2020 myself. Agreed.
Redox OS which is made by the same guy as Cosmic DE and actually runs Cosmic.
"Just like Linux did to Unix". You probably could learn a few things from history.
You are assuming the end goal here is to deliver a working kernel and OS
Religious zealots don’t care about that - they only care about evangelism and conversion
They want to “win” some imaginary game of their own making.
Linus invited the Rust devs. Now the Rust devs are tired by the gatekeeping old geezers on whos expert knowledge everyone has to rely on somehow and with no intend to actually document their wacky interfaces. If you invite someone, just to confront them with a bouncer, you are just a piece of shit, m8.
Nobody wants change forced upon them, even in the name of progress. To sell something to someone you have to show them how it solves their own problems, so that they actually want it. If people only see the pain and don't see the benefits then they will not want it.
Except this isn’t about a financial transaction, it’s all about trust and reliability. As admins & users, we don’t “buy into” open source, maybe leave that language to the corporate sector…?
Just asking…😊 (and kudos to _everyone_ contributing code, reporting bugs, maintaining repositories…!)
@@musiqtee I wasn't talking about financial transactions. You have to sell ideas to people for them to think it's a good idea. You have to put it in terms where they think the benefit to them outweighs the pain to them. If people only see the pain then they will resist change, even if it benefits others. Show them what problem they are having that it solves, and work to minimise the pain that it causes them.
These aren't just pure technology choices, they affect people, and the human aspect is arguably more important than the tech, but it's the part that developers struggle with.
@@georgehelyar Er, still no… You sell something, expecting a return. You _share_ something (like how Rust is indeed a great tool), and gain trust.
The pain you describe comes from how we’re need money for everything, and work harder for less (OECD statistics). The words we use (or not) can alleviate that pain, and actually achieve the progress needed. Just the language (no, not the programming language) used can change attitudes quite profoundly…
Says me, a silly ex-corporate guy for decades… 🙈👍
@@musiqtee"sell" here just means "convince". It is not corporate or financial.
The things I've said have just been about how to interact with people effectively and are nothing to do with money.
Ad hominem doesn't help.
Trust and reliability....and the current situation failed to inspire either. This approach won't last.
The road analogy is fantastic, because wider roads are part and parcel with how car centric and debt strapped a lot of America is today. Sometimes chasing the shiny doesn't lead to sustainable outcomes.
If the graphics crashes, what's wrong with printing what went wrong in the console rather than a qr code that you have to go through extra steps to get info from?
It’s easier to get a picture of a QR code then of a crash log. Like what Nik said it just makes it more accessible.
Besides displaying a QR code is optional, if you don’t like it, have it disabled
Rust helps eliminate entire classes of bugs common in C and C++, but developers still need to be vigilant about logical errors, third-party dependencies, and the proper use of unsafe code. Like all languages, Rust can have vulnerabilities, especially when dealing with complex systems, human error, or external dependencies. Both language have pro's and cons.
I would say Rust has more pros and C more cons
@@RustIsWinning could you elaborate? I've seen a few of your comments but I haven't seen you add to a conversation yet
@@TheCheD3 OP mentioned the most important thing already so that's one of many pros. Here are a few more: type system, DSL, enums and error handling.
Honestly it might not be that fair to compare it to C. The only con I can think about Rust is the lack of inheritance compared to C++ but that could be partially solved with the upcoming reuse syntax. C++ is getting reflection in the next version so we also have to catch up to that. I'm probably missing a few things.
@@RustIsWinning Rust has a lot of awesome features for sure. Many bells, many whistles, many genuinely useful tools too. I just don't believe that bolting it on will do much for Linux as a monolithic system. It will instead lead to more complexity on a higher level. A language designed to integrate seamlessly with C would be more appropriate, but Carbon, Zig and those breeds just aren't ready or useful enough yet. I'm on the conservative side here, Rust will grow more as a tumour than as a supplement.
@@TheCheD3Sure I understand your concerns but the goal of Rust for Linux is to provide safe abstraction for kernel drivers. No other language is even close to the safety guarantees that Rust provides. Sure it sounds as painful as a tumor for you but you are not the one who has to write those bindings.
So, I looked at the repo, and what I saw alarmed me tremendously.
I can summarize the entire fundamental problem with bcachefs with a single question, although it may take time to really understand how astoundingly bad things are, this will lead you to those conclusions:
"What's the current LTS version of bcachefs?"
No file system should have bugs and be 'experimental' and in development still after 10 years. It means you didn't think about it enough when designing it. Delete it all, start again, and do it right this time.
😲😆🤣
agreed
Don't tell Btrfs and ReFS users that. ReFS is *still* basically only for Windows Server users, making a drive use ReFS is painful under regular Windows, and I don't even think it's available as an install option to boot Windows off of anyways.
and you know this how? are you an expert in filesystems? Do you know if every other filesystem adhered to your rules, or did you just make this up?
that goes for wayland and systemd too btw
Debian is right. Unstable.
The existing maintainers need to understand the code they are responsible for. And Rust developers need to comply with the interface requirements for existing code.
I agree, but Lina often brings up issues with the C API. It's not very well documented, there are a lot of hidden pitfalls that you have to consider and people DO fall into. Now, you could just ignore these issues and completely comply to the API, or you could comply with the API as much as possible and suggest changes to the API that prevent bugs. Lina seems to choose the latter.
Seeing how resistant the C maintainers are to these changes, I would rather completely comply with the API and after that work on API improvements. Don't do both at the same time
@@NabekenProG87 from what I understood reading Lina's post the C API simply cannot be complied with because the missing documentation is missing key stuff like intended object lifetimes which is critical for writing safe Rust code.
@@Xankill3rif the rust code needs c language users to adopt non c language features in the c code for the rust developers to use that code, then the rust code obviously is not fit for purpose.
complaining that the non rust programmers don't provide information which is rust specific fundamentally misses that point, and acting out because the overworked c developer will not break lots of other code just to provide language specific features for a language he does not use does not convince anyone that this supposedly better language actually reduces developer workload for the c maintainer.
hardly surprising that there is push back from the maintainers of the existing code.
no other language community i have seen requires the c programmers to perform major rewrites just to get the c api bindings to work, so it points to a major flaw in the core of your language and developers that you do. if you need extra information that the c language does not provide, work on a tool which will look at the code you are trying to bind to, and have it figure out the extra information that you need. if that does not work, then maybe your language has an issue with not being able to play well with others and needs looking at again.
Rust team should make a new kernel instead of patching things in legacy C codes. It'd take way less time and effort.
At this point I don't think they have the skill to do so. If they are actually confident in rust they would have done that approach instead of shoehorning it into a C operating system.
@@CommanderRiker0Redox exists. It's a whole running micro-kernel/os written in rust and it already works on some hardware, has a desktop (cosmic) and surprisingly good software support (for an os not made to be Linux-compatible)
I'm against Rust in the kernel for a couple of reason.
First, to then build the kernel you need ALSO a Rust toolchain. What is the matter? For anyone like me that deals with embedded systems and knows the pain to get a working build toolchain that requires having the exact versions of each tool otherwise everything breaks the idea of having to deal ALSO with Rust, that evolves far more quickly than GCC, it's a recipe for a disaster. Platform also have their quirks, thus finding a toolchain that works it's not always easy, because you maybe need to compile with specific options for that specific CPU because it implements that instructions in their way, not everything is x86 or ARM!
Secondly, Rust build times are too high. Again when working with embedded systems you have to compile the kernel again and again. Sure, you have a fast server, sure you have ccache (by the way, is there an equivalent of ccache for Rust?), sure you have distcc (again, for Rust?) but in the end it's slow. If the build time get even 10 minute higher, while developing and building hundreds of images it reduces your productivity a lot.
Finally, rewriting any piece of code from language A to language B is always a risk. No matter that language A is not memory safe and with many defects, that code is tested on the field and runs on billions of machines every day. If you rewrite it in language B (Rust), even if you have a 0.01% change of introducing a bug, it would mean that in a project as big as the Linux kernel you introduce lots of bugs. This is the reason why banks still run COBOL programs written in the 80s, because it's a risk upgrading them to a more modern language, as it's to converting Linux code to Rust.
And, by the way, Linux doesn't have a test suite that you can run on every update to test regression, because it's a kernel and has to deal with hardware, most of which no kernel developer even has, most of which is some sort of old esoteric device that is not even sold anymore, but that you still need to support because there are thousands of people using it. For that reason I think the best thing is touch as few things that you can.
For the first problem in theory that would help a gcc frontend for Rust (they were developing it, I don't know if the project is still active), for the second one the problem is the language that is slow by design to compile since it has to do a ton of checks that C doesn't, and for the last one, I think there is no solution.
Regardless, I think that Rust is a great language that has a big potential, in fact we are starting considering it in our company for userspace application whenever possibile (i.e. where there is a toolchain that supports the target), but surely not for the kernel.
Easily the best take I've seen here.
I'm a primary Rust engineer for embedded nowadays, but I started off in C land. There are lots of issues with unsupported platforms in rust. So you've hit the problem on the head with calling out the toolchain.
I love how ignorant this is.
> First, to then build the kernel you need ALSO a Rust toolchain. What is the matter?
First, to then build the kernel you need ALSO a C toolchain. What is the matter?
> For anyone like me that deals with embedded systems and knows the pain to get a working build toolchain that requires having the exact versions of each tool otherwise everything breaks the idea of having to deal ALSO with Rust, that evolves far more quickly than GCC, it's a recipe for a disaster.
I've updated my Rust toolchain countless of times and have never had to refactor any code. The syntax has pretty much been solid ever since Rust reached 1.0.
> (by the way, is there an equivalent of ccache for Rust?)
sccache, lol.
> Finally, rewriting any piece of code from language A to language B is always a risk.
If you're rewriting code with memory safety in mind, the only risk is incredibly stupid code, and the only way for someone to do that is if the developer really is that dumb.
I think a linux crash screen should have a Tux with a sad face and Xs for it's eyes, similar to how the old Macs had a Mac sadface iconl BSOD is too Windows-ilke. Also, if they do have a BSOD, at least make it so the colors can be changed like Windows can.
Lol love it
I understand that the Rust community of developers is frustrated, and that C programmers tend to be more defensive of C, but there are aspects that some Rust guys want to ignore:
1. Rust's syntax adds complexity.
2. You need a lot of experience to use Rust effectively.
3. You can't rewrite everything in Rust! It just doesn't work!
I like the take on adds more complexity. If only a low percentage is able to really understand and potentially fix your code, thats a big problem for everything thats developed in a community. We have this issue at a much much smaller scale in our department, where the "tech-bros" introduced nodeJS backends in an environment with 95% java devs used to use spring boot. Take a wild guess which microservices are way more stable in production.
you forgot to add that rust is a centralized language atm with cargo being a trojan horse. you are literally pulling in binaries you have no clue about what they contain. It does not help that rust is being pushed by companies that do not care about your privacy. Honestly Linus is senile for allowing rust but not c++.
It only takes only one month to learn Rust, even if you are a complete beginner. These are experienced kernel developers we are talking about. It is their job to maintain the kernel. It is their job to fix memory safety issues in their code. It is their job to keep their skills sharp, and learn the tools and techniques necessary to do their job. There's no excuse for this at all. At a certain point, if all you're doing is holding everyone back, it's time to step aside so others can do their jobs.
@@mmstick mhh dunno if you can really learn rust in that short timeframe. At least not on a level to feel comfortable to work on smth like the Linux Kernel. But that might be just me.
@@stevenrichman7101There's a good book for Rust called "Learning Rust in a Month of Lunches". Even if you are a complete beginner to programming, you'll have no problem completing it in a few weeks. Start there if you must
The code that a kernel maintainer will write in Rust is not that different from what they already write in C. The main difference is purely syntax and basic language patterns. If they can't do that, it's time to retire.
It's true there are some cultural issues involved, but there are legit technical issues as well with the Rust/C divide that inexperienced onlookers are attributing to the cultural issue. One of the major issues stems from the fact that there is no stable Rust standard library. To built software with Cargo, the Rust package manager, you have to pull in dependencies hosted in the cloud, which they themselves have all sorts of dependencies. This leads to micro-dependency h*ll. This was a decision early on in Rust development that was pushed by some and rejected by others, and now we're seeing the consequences of it. Essentially, Cargo is npm. It adopted its benefits, but also its dependency drawbacks. Until Rust has a standard library, this issue will persist. The Rust community has to take responsibility for this decision, self reflect, and decide if there might be a better way forward that leads to more maintainable software.
also they should fix the syntax of rust. I tried rust and eventually came to conclusion that yes mem safety is nice but syntax is also important
@@LinguisticMirage You're totally right!
The entire premise of your argument is wrong because the Rust Linux project does not use the standard library. Do not confuse onlookers any more than they already are. This was already solved 3 years ago.
@@mmstick That's the reason bcache fs tools was orphaned in Debian.
@@Onyx-it8gkWhich has nothing to do with the Rust Linux project, and quite honestly has more to do with Debian than anything else here. Fedora, Arch, Gentoo, OpenSUSE, and many others have no qualms with packaging Rust applications.
The comments here are a perfect microcosm of the c/rust stuff, and thats incresibly depressing. So many uninformed, reactionary, dismissive, or otherwise hostile comments with almost nobody capable of rational discussion on either side of the issue.
tribalism at its finest
Yea true but Rust is winning tho 🦀
I think it’s more of a general product support problem that you see in a lot of different areas rather than C vs Rust. Linux is where it’s at due to years of hard work and many tough lessons learned. It’s now mature and not a great area for radical innovation. It’s a tool millions of people depend on every day. That’s why the two groups hate each other. One feels the other is too old fashioned and restrictive. The other feels like the new guy is a bull in a china shop. This happens all the time. I normally favor the guys who have actually made it in the real world. They have survived all the real world gauntlets rather than some theory of why they are better. A programming language is not a useable Kernel. The responsibility is on the Rust community to go prove they can do better, not just talk about. Linux has no obligation to change for them.
@@RustIsWinning
People like you are the reason for others hating rust.
People get emotional when they feel that their livelihood is being threatened. I don't think Rust will take away anyone's job, but humans are emotional beings.
The sociopathic nature of the rust "community" makes me want to avoid it entirely.
"Rewrite everything according to our orthodoxy or else"
This. Sociopathic is the word, specifically sociopathic zealots.
That said, they might be right about "memory safe languages" (they mean Rust of course but I suspect it won't actually be Rust) eventually giving rise to a Linux replacement, but that's fine. Linux won't last forever.
> The sociopathic nature of the rust "community" makes me want to avoid it entirely.
Me too. And I have to work in it.
Hmm are you one of those kernel devs that tries to sabotage the Rust for Linux project?
@@RustIsWinning Nobody needs to sabotage Rust. The Rust community does it itself.
@@chrboesch Good one! Wanna hear an actual funny joke? You replying with my name... ironic right? Zig is like C which means they cannot win. It's all about winning.
4:33 wtf are you talking ... labeling people with common sense as "traditionalists" is almost an insult ... do you understand that Linux runs on 99% of the worlds infrastructure and it better be stable
Rust developers are annoying everyone, not only Linux. Instead of improving what is already there, and use rust for new projects, they want to rewrite everything. And this is not traditionalist vs people that want to innovate. This is tech bros vs actually engineers.
On engineering, you do minimal innovation to get the job done. We learn to do that after 3 and half millennia of experience. The bcachefs developers are the best example of this problem. The guy never addresses the fact that for a stable release, you have tho change the minimum to fix the bug or the vulnerability.
If you are making a product, or trying to scam investors, sure, innovate the maximum. But if you want to actually develop technology, follow the rules. Don't reinvent the wheel and don't reinvent engineering.
No, it's the other way around. Spend some time looking at every argument on every forum objectively. You will see a pattern. People who hate Rust and accuse Rust developers as being zealous or part of a cult are doing only one thing: appealing to emotions with very emotionally-driven arguments. Meanwhile, actual Rust developers are having to calmly defuse and bring discussions back to reality by stating technical facts about the situation. Here you are perpetuating emotional arguments and insulting people purely out of spite because you don't know anything about Rust or the Rust Linux project.
Stereotypical Rust guys think they've ascended above all other and have the moral right to write programs unlike those who write using "unsafe" languages. Tech bro == Rustacean is an analogy I now cannot unsee, hope you're ok with me stealing that phrase, lol
@mmstick are you aware of the issue here? bcachefs developers are constantly adding new features to a stable branch. You can't do that on any project. It doesn't matter the programming language. You just don't do that. New features are, by definition and experience, buggy and vulnerable. That's why you only change the absolutely minimum.
Look at python 2 to 3 transition. Or x11 to Wayland transition. Nobody question that those two technologies are better than their predecessors. But big changes equals to big troubles. That's why we have to follow certain rules.
70% of all security vulnerabilities are memory related. Rust is a minimal innovation to fix that. It compiles through the existing LLVM stack, it's not a "tech bro invention". Generalizing all Rust developers as being annoying is also quite an immature take. The way evangelist Rust developers see it is that the loud minority of C/C++ devs are lashing out because they feel threatened. In reality the majority doesn't give a shit and everyone just goes on their merry way writing software in their language of choice, which for an increasing amount of devs is now Rust. Sticking to C/C++ is not a crime, just do what feels right for you ;)
@@mmstick You are delusional,
the rustards should build their own projects instead of trying to slither their way in great products that don't use Rust.
Rust can go fukk itself
I'm with the maintainers it's right they are very conservative with rust code when you understand how complex the kernel is but imo rust shouldn't be in the kernel
Rust needs to mature, kernel doesn't use modern C, it uses C from 2011, an upgrade from C99, and yes, this just doesn't work for rust folks. I did think rust in the kernel was a mistake, wait 5 years, and we do see the effects.
Clueless deluxe 😂
I fail to see how the two issues are linked.
I'm not familiar with the API in question, but bad design is bad design.
If people, using both C and Rust, have ran into issues with the API, its bad.
Simple as.
@@khatdubell 100% this.
@@RustIsWinningI think you're slightly biased
@@MysteriousFoxy87I'm also making meaningless predictions just like the OP 😂
It sounds like the Rust Devs are trying to do AGILE development but the Linux Kernel releases are set up for Waterfall development. Constantly making changes and fiddling around with other people's code during a Waterfall process just creates chaos. Follow the process or go do your own thing. Don't join an existing project and expect everyone to do things your way.
That is a bcachefs problem, not a Rust problem.
What? I think you misunderstood the video
@@p0n-pompf There are 2 issues in the video and they are being lumped together. One is Kent of bcachefs is trying to do agile/tdd (I think it is more tdd as he mentions his great test suite, but tests can have bugs too and the language doesn't prevent that) style development, and he is expanding that out past his filesystem and Linus is putting his foot down, here is the thing, nothing says Kent can't do that style of development but when you get to merge windows, one needs to stop, package it up and expose it in more traditional waterfall form and not continue doing that and doing it across vast swaths of the kernel after freeze.
On the other hand there are actual problems integrting rust with c, like refusal to fix api so it works in both C and with rust lifetimes and doesn't bust the lifetimes at the boundraries, or just exposting the c struct as a stub so rust devs can ingest it, this of course is more subsystem dependent but it can be done in the traditional model of being introduced as a series of small features and reviewed. There are some maintainers though who see the stub code and nothing using it or rust code they don't understand how works and why using it and proceed to deny the merge, this is an entirely separate issue.
Trying to convince a rust person they are wrong is impossible. They are not really programmers so much as cult members.
@@CommanderRiker0 So you're trying to tell a person they are stubborn by being stubborn and being convinced you're the right one, congratz good luck in life
Thoughts on Rust & C Linux being divided?
Rust in the kernel long term is dangerous, mostly because of its toxic community. Zig seems like a better path if any other language is brought into the mix.
@@29238734943 Zig toolchain's ideology is C/Linux compatible, unlike Rust's - that's how I feel. As an example, I built my first 32-bit x86, bootable floppy image/kernel proof of concept just by following C tutorials and osdev wiki, but doing it in just Zig (Almost, needed NASM to write 16-bit bootloader) and there was no friction from the language itself, just like you'd feel no friction from C.
And you can probably finish writing kernel before you even THINK about importing something from a package manager, unlike in Rust world where to do anything remotely useful you buy into NPM-like dependency explosion and pray that none of those have a version conflict or you're about to have an emotional roller coaster trying to fix this issue in a sane way.
Not sure the way Zig code is written in a "typical ziggy style" is compatible with Linux coding style, but adapting the culture and style is the price Zig guys would have to pay, which was apparently too much for Rust guys already.
But before they get that "1.0" tag this Zig/Linux conversation should not even start. Even then, Linus may be, understandably, reluctant to let in yet another batch of uncertainty to the project.
Honestly? There seems to be a small subset of C developers that absolutely hate Rust with a irrational emotional intensity and want turn back time before Rust was included in the Kernel.
@@Wurstbrot03 hey, I can be indifferent to Rust while still feeling revulsion to the public image of Rust fanboys and the counterproductive activities that Rust devs too often engage in. example? claiming Rust can be faster than C is to (willfully?) misunderstand computers and compilers and languages--AND to do precisely NOTHING useful for the community, unless you suppose there is a lack of testosterone somehow? these guys should go back to destroying mom-and-pop business models for scorched-earth venture capitalists and leave us to our work
Remove rust.
Kernel Panics > BSOD > Scan the Penguin QR code > Solution run sudo rm BCacheFS_Tools, 10-4 sudo roger and out. Just for laughs the comment section is too hot lol hahaha 😂. Thanks for the Vid its pretty interesting and informative.
Haha lots going on the in the linux world and yes it's getting spicy
Not sure why people are ragging on the Rust community in the comments here. My team recently adopted Rust and I generally found the community welcoming and extremely helpful. Obviously - not everyone is nice, but I that's true of any community, right?
For me in userland, I don't care for the politics - the prospect of interacting with system calls via Rust's rich type system is much more appealing than C so I'm here for that.
It's a nice language that helps noobs contribute changes that are impossible to have critical memory safety or parallelism bugs. It makes reviewing PRs a dream and expands the pool of people who can make contributions - isn't that a good thing?
You want noob code in the kernel? Memory safety and parallelism bugs aren't the only things to worry about, especially with inexperienced developers writing code. Just because it compiles and "works" doesn't mean the code is good or should be included in the kernel. You can write a disaster of a program in any language. Rust is no different. Sure, it may be harder or impossible to do certain kinds of bugs, but those memory bugs aren't the only ones that bite you in the ass. Logic bugs can be the worst.
@@redemptusrenatus5336 I'm not endorsing the incorporation of bad code into the kernel.
My point was that, in my experience, reviewing Rust code has significantly lower overhead than reviewing code from unsafe languages.
This allows reviewers to be focused on valuable aspects like correctness, logic, efficiency, structures, and teaching/educating.
This doesn't mean bad code will go into the kernel; that is up to the reviewers. It does mean that the accessibility of kernel development improves. In addition, the lower overhead of reviews means that core maintainers have more time to spend on other tasks.
@@redemptusrenatus5336 ah the classic "but Rust does not solve XYZ" 😂
@@RustIsWinning Did I stutter?🤣
@@redemptusrenatus5336 You wrote a whole paragraph on safety just to remind us that we also have to care about the other 30%. That's not what we are focusing on with what we are currently trying to solve. So you making that comment in this context is not relevant. Next time why not mention social engineering and supply chain attacks too lol
I have some bias, so as usual take the comment as seriously you would take any comment on a UA-cam video.
But my point of view is that Rust is a newcomer language into the kernel, and should adapt to the existing environment rather than makes things more difficult for existing code. And maybe some maintainer are viewing rust code through a stricter lens because having a different toolchain to build the kernel is already making things more difficult than they are for a lot of existing developer.
As per my experience as a user on the receiving end of a tool transition to rust, it makes my life more difficult, and because of some of the details of my setup, rust building tools cannot be easily found on my path. And I can rarely download pre built binary.
Also as far as I know some part of the Rust community has been far more vocal into discouraging either wannabe or prominent Rust developer into making further contribution to the community.
This is the correct opinion to hold. Rust zealots say this is uncovering issues with poor C documentation but the truth is that they're trying to make the C developers lock in their private APIs, effectively making them public. Linus wrote something back in the day about how "you think you want a stable kernel ABI, but you don't."
I have been hearing about this from multiple channels. From what I understand rust is the current fad in programming, and the rust devs want everyone else to conform to them. The c devs are just looking at them like a hyperactive child hoped up on sugar wating for them to crash.
Uhm, no. Major corporation are picking up Rust because it does better than C. Amazon and even Windows OS are getting more Rust code. The US government is using Rust too to replace C. You are confusing Rust with Zig.
@@techpriest4787 I don't know. Many programming languages have come and gone, but C is still here. I am willing to bet that in a few years the government will be the only people using rust because the government is slow to change, and C will still be used just as much as it is today everywhere else.
The Rust guys do actually have some valid complaints nested in this whole saga.
Asahi Lina has a dwcent twitter thread going it this. The main issue seems to be that in Rust, the way you use functions contains more explicit information about the behavior of said function. The C kernel API functions sometimes contain different branching paths that do very different things with memory etc and all this is basically undocumented (except in the fun ‚the code is the documentation‘ way).
This can make it very frustrating to actually work with Rust in this environment.
Ultimately the core seems to be more about coding practices and not necessarily about Rust or C itself.
Its just that many of the kernel devs probably don‘t feel like writing documentation and they know their own code well enough to deal with the weirdness.
@@Techsupport243 The government is slow to change so it's the only one to adopt a new language long term? What kind of logic is that?
Nobody denies that C will still be here for a long time, but saying Rust is a temporary trend is just wrong at this point. Maybe it'll backfire, who knows, but it won't just disappear overnight.
@@SaHaRaSquad Of course it won't disappear. maybe the next few years was the wrong words. I'd probably say 10 years then you'll just have the people maintaining legacy code, and government projects.
I may be totally wrong, but I think that if Rust developers instead of contributing to Linux focus on something like "Redox OS" and "do to Linux what Linux has done to UNIX", it will be not a tragedy at all. If they are confident Rust (and other memory-safe languages) is the way to go, let them do it - and let Linux continue developing its traditional way, it is quite good at it so far.
I agree with your opinion and the same thing I say
12:43 I don't believe this is specifically for graphics subsystem crashes. Historically kernel panic messages just didn't work if a DRM driver was in use. They would only show on fbdev drivers and that was about it. There has been a lot of work recently on getting panic messages to show correctly on DRM in general as almost no one uses fbdev drivers at this point outside of early boot.
Zig really feels like it would have been a better fit than Rust. Too bad it's still a little early maybe.
Good one 😂
@@RustIsWinning Good what? This is the truth.
Rust was released a year earlier than Zig.
@@hedgehogform no rust was 1.0 a year earlier than zig was started. Huge difference. Rust was started in 2006.
Yes the fact that zig is basically c but better. Rust is c++ but better. Zig is much better suited for Linux kerny
We should not mix languages in a kernel like Linux; it is the best way to finally have an unusable open-source system.
Mixing - depends on what. If the architecture is well split into layers with perfectly well defined interfaces, and each layer is written in a different language, why not.
But if that's not the case, then, not a practical approach indeed.
This is the correct answer.
Interesting. Linux kernel is GPL, so it can be forked, right?
I've tried Rust and I though is many times more difficult than C. That "festival" of ways to refer to pointers is disgusting! Clearly, is not a language that prioritize productivity.
I have now read all the comments here and they are depressing. It’s like reading “smart” people talking about how dumb electric cars are…
Electric cars don't fix what their proponents advertise them solving. Electric cars just shift the pollution to other places, and introduce other types of it as well.
They are better in terms of emissions/pollution and energy efficiency but in the end sum it's not miraculous, but a modest improvement. The big issue with electric cars is the scaling issue, both infrastructure and materials. Adoption will be severely limited for decades by these factors.
Electric cars are extremely dumb.
Batteries are much less portable and energy dense than fuel and that's a FACT.
No electric car can match a fuel car in mileage.
Charging also takes significantly (and I mean significantly) longer than refuelling.
"Oh but I can charge from my wall socket at night".
Good luck charging it after a thunderstorm cuts off your electricity for 3 days.
If it was a fuel car, you could just pour some gas into it from a simple bottle that you had kept from earlier. Keeping a backup car battery is not comparable to this.
Batteries also degrade over time, reducing their capacities and charging speeds and needs replacing.
Honestly I feel sorry for anyone dumb enough to fall for the scam of buying an electric car. It's just sad.
"Oh it saves the environment!". Not even close to as much as you've been scammed into believing.
@@ScorgRus they are also more efficient, even when using electricity from coal fired power plants… and they can run on better, cleaner electricity when it’s available. Battery pack prices are still failing (and will continue to fall for quite some time) so they will also be cheaper to build than petrol cars.
@@Dipj01 you must be very smart.
I do think that rust in the kernel is good...but also, Linux has been C for a long time and it's not going to be easy to get rust in it, I feel like the rust devs might be moving a bit too quickly.
As a developer, myself personally I want my operating systems to just work. If that means putting the code in c okie dokie if that means putting it in rust so be it. To be honest both are viable systems programming languages personally I know C myself; however, I have no issues with rust there's a lot of people who like to stick with what works. Also there are people who like to just do the new thing. Due to the polarization that's been happening in our society people have trouble agreeing on that to be frank a balance needs to be struck.
still don't know why they went with Rust, sure zig is unstable for now, but can we all agree that it's more readable and easier to write ? and let's not even talk about compilation speed
You answered your own question immediately: zig is unstable. That's not something you can just brush over for kernel development, that's the mother of dealbreakers.
@@SaHaRaSquad all I'm saying, rust was a bad idea. You can see these cultists for yourself in the comments
@@oumardicko5593your idea is better? 😂
@@RustIsWinning which idea? I said zig would have been better but it's not stable yet. 🙃
@@oumardicko5593did zig pay you? Nice ad man 😂😂😂
You need to understand…
They don’t care if any additions to Linux work or not. They only care that it’s written in Rust. Anything not written in Rust must be cancelled.
If you understand this basic motivation, then the rest of it makes perfect sense
So going off any writing their own OS in rust does not achieve these goals. They are not interested in creating a working system.. they just want to wreck anything done differently
"They" = Linus?
Another bait comment haha
Accurate.
Rust is glowing
Take your meds Helen.
Once the whitehouse issued a press statement saying we should all use rust, I had the same thought. Nothing the government recommends is in your best interest.
@@CommanderRiker0 Oh boo hoo! The WH does not like my language. Cry more LOL 🤣
Doesn't affect me, I haven't ever encounter any case where BCacheFS would actually helpful.
To be fair, the C kernel team has a reputation of "patronizing pedantic megalomaniacs" to quote the pop_os team
I quite like Rust, but man, do I not enjoy the community surrounding it. The superiority complex. The need to force Rust down everyone’s throat. Does Rust bring some benefits to the table? Yes it does, but it’s not a silver bullet, and it comes with its costs too. Everything in software engineering is a trade-off and you have to weigh the costs and the benefits. I feel like many Rust evangelists don’t really realize that.
But what if I love Rust?
This. It really does bring some nice concepts to the table. But the amount of times I've seen "This would be a cool project if it was written in Rust. Too bad it's $LANGUAGE" or "Memory safety == no CVE" is very annoying and not helpful at all. Pick the right tool for the job. And if you want a Rust version of something, go ahead and rewrite it yourself, we're not stopping you, but don't expect people who are trying to move forward drop everything and start from scratch, possibly even learning a new language.
@@RustIsWinning you need to get out and find some other obsession that doesn't upset people this much.
@@RustIsWinning Good for you, but your tastes are not universal.
@@ScorgRusI know! This is good because how else would I win? You need to be 2nd, 3rd etc. lol
Once I hear rust comunity is a bunch of narcissists that don't accept their cult language have problems. And from my personal experience, rust is about abstract EVERYTHING as raii paradigm. Under supposition their raii is conflicting with legacy huge amount of C, I suppose it's better for them to create their ideal hevean of abstraction from a clear slate. Let the better system win. I think rust is a very interesting language, and their idea can actually end up winning this natural selection.
not my area, just some old real-time systems guy, where code can't break, ever.
there's enough toxicity in the comments to poison most of NYC... but, it's your playground, even if it poisons everyone, everywhere.
People discover one way to do things, and then they decide to stop learning.
Honestly, Rustaceans need to just fork the kernel and proceed, all the drama is highlander-esque "there can only be one" nonsense
But how would they tap into the big pool of money that the Linux foundation manages if they fork the project? Why do you think they all try to piggyback here? That's where the money is.
For all I know, there is an attempt of a brand new OS written from scratch in Rust. But there's no money in that.
@@joseoncrack well, what you've described is literally how Linux started in relation to MINIX and BSD, if Rust is truly the end-all, be-all language, then whatever the Rustaceans build for their kernel should be superior, but they'll have to prove that overtime and with the same resources most FOSS projects have (which is usually none), Rustaceans demanding it like children mutes any points on stability and memory safety... there's a Tolkien quote about creation that seems applicable, but quoting it further plays into the drama
@@Wolkebuch99 Yeah, good ol 'RedoxOS' where, as per their FAQ, "Redox is alpha/beta quality software, because we implement new features while fixing the bugs." Awesome reasoning there. Oh yes, they've been working at it at least 9 years, and besides saying it's alpha/beta quality software, they also have this to say about their faith in the stability of the system: "Because of this, it’s not ready for daily usage yet. Feel free to test the system until its maturity and don’t store your sensitive data without a proper backup." Beautiful isn't it? I see that and wonder, if they've had 9 years to work on this, using only Rust and having all their whims granted, then how the hell are they going to do any better jamming the code into Linux? It's ludicrous.
@@Wolkebuch99 imagine the dummy spits and temper tantrums, as a whole agile project full of Rust experts go to war with each other over the “correct” way to publish an API, or define lifetime constraints, traits, async behaviour, or which set of 300 crate based micro dependencies are the best.
Could raise millions selling pay per view tickets to their daily standup meeting cage match
@@steveoc64😂😂😂😂 so many 🤡 comments here
Linus' biggest mistake was letting the Rust nutjobs in in the first place.
I can't help thinking that the Rust language has merit, but replacing C is a massive job.
Maybe someone(s) smarter than me would/could fork the kernel, maybe in stages and replace elements in Rust.
They would need a _lot_ of resources to do this.
There would be a lot of growing pains, rather like with Wayland vs Xorg.
Perhaps distros would offer different kernels as a choice.
Another thought is that a new Rust based kernel could simply avoid legacy hardware and focus on the new stuff, reducing the footprint of the code base, maybe even just focus on say ARM, _or_ x86, _or_ RiscV rather than trying to be all things to all people.
I think they'd rather ride on Linux's coattails because it's a large and popular project. You don't see them bashing down FreeBSD's door... though FreeBSD is considering it, they're only talking about it. No, they'd rather hop on a bigger project with more steam behind it so that they can slowly take it over. Linux has guaranteed visibility and popularity right now. Rustaceans and their RedoxOS? It's still alpha and they even tell you not to use it without a backup of all your data. For all this talk about less bugs and better memory management and ease of writing code, you'd think they'd have gotten further in 9 years. At least, enough to say it's stable for what they support but they don't even say that.
Rust is doing what called "legitimacy laundering" . They have to shoehorn into projects, which literally have zero need for it. The rust team even twisted the arm of somebody in the white-house to release a statement saying all coding should be done in rust, LOL. Its all just AstroTurf type marketing nonsense.
@@redemptusrenatus5336exactly what I said, congratulations to you for saying the obvious
Rust Kernel is a complex thing like Port JVM for machines and the kernel with this, it's hard work and for because of memory safe and Any language could be memory safe even C if you know what is doing
Linux and its community, and their intolerant and toxic behaviour. lol
@obinnaokafor6252 calm down darling.
People will say C is bad and then happily use Java Script!
C IS BAD
C is pretty good. Not saying it couldn't be improved, but it's not nearly as bad as some people make it out to be.
There is nothing wrong with C. Its simple and performant. It requires vigilance for memory bugs, but that is a skill thing.
Rust Dev's: We dont want C dev's to lean rust.
Also Rust Dev's: He didnt want to help me so i quit.
Misinformation
@@RustIsWinning I think you need a better obsession than a weird programming language.
@@RustIsWinning where?
@@nempk1817You make it sound like Rust devs are not trying to help. What's your suggestion here? C kernel devs are not forced to learn Rust.
I just don't understand rust devs... if you don't like the C community why don't you just make your own fork and slowly chip away all of the C code? might takes decades to finish but at the end you got what you wanted
You don't understand because you didn't bother to read what this was about in the first place. This isn't about "the C community". The Rust Linux project is endorsed by Linus Torvalds. He was at KubeCon this month, where he commented about his disappointment that kernel maintainers are so resistant to supporting it. That it should be adopted faster because basic memory safety issues are still a big problem in the kernel 33 years later. The point of this project is to fix those problems and enable developers to transition to writing drivers in Rust. Not to create a useless fork and waste all that effort.
@@mmstick so in short... zig???
@@mmstick " basic memory safety issues are still a big problem" Rustafarian religious mantra. Can you give a concrete example? I've been using Linux for decades at home and work and the only kernel crash I had was because of a failed motherboard on a server.
@@joeyjo-jojuniorshabadoo6827 Are you calling Linus Torvalds a liar? Syzbot shows thousands of memory bugs and race conditions, even standing at only ~30% coverage of Kernel code in their tests. Furthermore, both Google and Microsoft released comprehensive reports that 80% of their vulnerabilities were caused by memory safety issues.
C programmers are supposed to stop development to help rust developers catch up, basically. Rust wants them to either stop programming C and start in Rust or to give up their time helping Rust devs.
7:45: Wow! Of course a Rust written replacement driver for another driver written in C must work *_exactly_* the same way. That's nothing to be frustrated from, that is just development sanity. Otherwise there would be a chain reaction where everything that need to interact with any Rust replacement driver needs to be rewritten in a cascade that will affect the viability of the entire operating system. You can improve the drivers in the future, but now it must work exactly as before, and that is a fundamental program development principle in order to not create chaos. I'm anti-impressed by the lack of skill, experience and fundamental knowledge exhibited by Asahi Lina. If this is the culture in the Rust community, I would recommend it to quarantine itself from the real world until it gets well and healthy.
Yeah, I guess asahi linux dev got infected by apple virus or smthn, or does she not care about compatibility?
I held that project in high regards, but this makes me wonder...
Strong arming oneself into ANY project is a very bad practice imho. The linux kernel has accepted the change to move towards rust, but obv has requirements, not completely ignoring functionality is one...
Linus is the king of the hill and linux is NOT a democracy...
Linus is also the one ultimately responsible if something breaks in the kernel, so I totally understand his reaction.
Lina's driver isn't a replacement, it is a new driver for Apple Silicon hardware.
They didn't want to change any existing driver, they are working on a new driver and encountered some issues with how the c scheduler works and wanted to add some improvements, but they were blocked because other drivers are working around those issues, so they should work around them too.
@@calebgindelberger3046 And that shows how deep inside the bubble she and you seem to be.
Linux is not about her or her project, it's about maintaining a stable kernel. And demanding everybody change what THEY have done to fit HER project (or ANY rust implementation) is insane.
She can always make a kernel module instead.
If someone wants to contribute code to the linux kernel, they have to make it compatible and abide by the rules of the maintainer, not demand the project becomes compatible to THEM.
@@marcusjohansson668Did you miss the part where other C drivers need to actively work around the kernels interface as well? That's not a sign of Rust kernel code being bad, just that they're affected by bad design as much as C kernel code, and that Rust developers just happened to be the ones that tripped on it and decided to improve it.
Nice job!
I get the impression that rust devs are the vegans of software development...
If they want to push rust they should build an own unix like kernel, solely in rust and not make the linux kernel even more complex. Bringing rust to a mostly C codebase sounds like enshittification to me.
This is the point of view of everyone that hasn't written any Rust and mainly writes in C. It's a silly territorial argument that has C developers that don't want to learn Rust on one side and Rust developers pushing against a kernel that is consistently in development on the other.
If you think Rust enshittifies C code you obviously don't understand the features of Rust and you're an old head.
@@transcendtient meat eaters don't understand. if you only stop eating meat for one month, you'll see... yada yada... I get it.
@@transcendtient Why the big push to put Rust into Linux? RedoxOS already exists. Why not go there, I'm sure they'd welcome all the Rustaceans. No? Perhaps Rust devs want to piggyback off Linux instead.
@@redemptusrenatus5336 ah yes Redox is exactly like Linux. Wait let me quickly rewrite the C kernel instead because it cant be that hard right?
@@redemptusrenatus5336because improving Linux affects many more people (and corporations) so it is literally thousands of times more valuable. And allowing some drivers to be written in (fairly idiomatic) Rust definitely improves Linux. If it were just a case of some programmers wanting to code in Rust for fun, then a hobby OS in Rust would indeed be fine - but it isn’t.
The problem with the "just make a new kernel" is that if push comes to shove we might just see the death of Linux. A vast, *VAST*, amount of work is being done by corporate backed maintainers and the foundation itself gets most of its money that way. I think Linux will just get obsoleted if that is pushed for.
If Linux is no longer necessary then it SHOULD die or assume the Rust fork as it's main project, that's all fine, but mixing codebases and developers of two very different languages together in the same repo is always going to be a disaster on multiple fronts
If Rust OS (something like currently existing Redox OS, but preferably GPL licensed) becomes better and more popular than Linux, why not? If they can do it - let them do it, nothing bad in the new better OS emerging if that is really the case.
@@comesignotus9888 I would absolutely love it if things actually work out like that. But I am worried about the kind of BS we can expect from big corporations in the interim period. What happens between now and the time a copyleft Rust-based kernel becomes stable? Because I absolutely expect big corpos to use that period of uncertainty to damage the FOSS movement further - via regulatory changes, etc. You know the typical FUD tactics.
Most people don‘t seem to get why Rust is being added to the Linux kernel. ITS NOT PRIMARILY ABOUT STABILITY. Linus himself stated, that there is a shortage of kernel maintainers. By adding another, more modern, language to the kernel, he hopes that more people will be willing to maintain the kernel. He did that, because he doesn‘t want Linux to die.
In that case, use React moving forward instead of Rust
Replace all existing APIs with a HTTP call that returns a massive blob of JSON
unfortunately it appears most rust dev's are web programmers and are bringing that mindset to systems programming.
@@CommanderRiker0 Is Rust used that much for web dev? I thought WebAssembly wasn't there yet to compete with JS (performance wise when it comes to DOM manipulation).
@@tobilinz_ No it appeals to web devs looking to "break in" to systems programming.
@@CommanderRiker0 Oh, ok. I guess we would need a lot more data to test if the adoption of Rust actually combats maintainer fatigue or if it just increases the amount of crappy pull requests maintainers have to review. I hope that Linus or another Linux maintainer will release more information about this at some point in the future.
Let's hope for the best!
Lol some other kernel take place of linux... dude literally the whole world runs on linux😂
Rust getting hated on for simply existing as usual
Hate for no reason 😔
Rust is being hated on because its completely pointless in the context of Linux systems programming. The Linux kernel uses C because its the worlds most stable and simple language with clear understanding of its compiler. We've understood memory safety in C for 30+ years, but yes its up to the programmer to follow the guidelines for memory safety which are often ignored. That's a skill issue, not a language issue.
@@CommanderRiker0 Skill issue of 30+ years to not come up with a better solution LOL. Our solution works at compile time. C is outdated. Get over it.
@@RustIsWinning Languages generally get better and more performant overtime. I am not sure outdated is an insult here, but yet another misunderstanding from a what I presume is a former web developer boot camp guy. No wonder they keep messing this up.
@@CommanderRiker0 Well guess what boomer. We dont want to rely on guidelines anymore. A machine is better at pointing out incorrect code. C devs could never. The Linux kernel will be safer. Rust is winning.
Actually don't care about memory safety in the kernel, kernel devs are wizards anyway, I care more about a fast kernel.
Yea true and this is why you never have to update your kernel because critical CVEs dont exist 😂
@@RustIsWinning I was clearly not speaking of leaving memory issues in the kernel, if you can get any more dishonest. Rust community needs less memory safety and more normal discourse if anything.
@@rrraewrYes but what do you think is better less or more safety? If you dont care it would be less. Good job! Well done! Your logic is flawless!
@@RustIsWinning Been using Linux in production for 30+ years. Never had a kernel CVE issue affect me. Most require elevation to begin with. Non issue.
@@CommanderRiker0 You forgot to like your own comment like you did with the others. 30+ years is big copium. If you are so sure why not turn off security updates LOL 🤣
I wonder which group is the worst: the Wayland bros or the Rust sisters?
I'm pretty sure it's the group that watches vtubers LOL
@@RustIsWinningdude you just watched a vtuber. You are proving the rust programmer stereotype 😂
@@Cloudo55Who did I watch? You okay? OP has public subs on. I could not resist to roast him on that. It was the perfect setup.
@@Cloudo55 I don't think he watches anything. Any video tagged rust he has to come and defend every negative opinion. Its a religion for these people. Sad.
If Rust developers think Linux awaits the same fate as Unix they should prove the point and develop a Rust based OS. Otherwise, it's all talk in the wind.
Redox OS
@@gljames24 yeah, let's wait and see if Redox OS does to Linux what Linux did to Unix then. I wouldn't hold my breath though.
Call me crazy buuuuuut..
What does this have to do with rust as a language???
Nothing. Boomers are mad.
Introducing rust is a big mistake.
Using C was a big mistake.
Rust is a mistake from the beginning.
@@yooyo3dokay boomer 🤣
@@RustIsWinningthe existence of unsafe is a proof of mistake.
@@yooyo3d ah you are probably one of those who start counting the unsafe keyword in Rust code bases and then make a 1 hour long rant about it on YT. Yes, a guy like this actually exist LOL
Mmstick guy shilling for Rust in the replies to every single comment with such extreme force you'd think C personally had his family killed in a mafia style execution
Don't forget, he's got 10 years experience in Rust. Oh, and it only takes a month to go from beginner to full-on Rust Kernel Developer. That and he's had people submit PR's who had never coded before and aren't even sure they did it right, and he didn't even have to change the code, it just worked with no problems! Well, if that's true, it makes me wonder about the quality of the code that gets accepted. 🤨🤪
He is a sophistst.
Paraphrazing:
"Rust is good because linus said so"
Appeal tho authority.
"can you show us a concerete example of a memory issue"
"You are saying Linus Is A liar"!!
Dont know name of this falacy
(Asked to provide concerete example)
"Big companies like this and that are all reporting 70% of vulnerabilities are because of memory issues"!!
1 - yet doesn't provide concerete example
2 - coincidentally, many of those corpos are also heavily invested in rust.
Yikes.
@@arkeynserhayn8370you perfectly described him lol
@@arkeynserhayn8370Clueless deluxe if you need an example 😂
@@arkeynserhayn8370the name of the problem is deflection. instead of replying to the question, you pose a different one which either is more favourable to your position, or which distracts the other side away from the awkward question you don't want to answer.
it is usually a sign that the answer would be a disaster for their position.
I think a Linux in C kernel and Linux in Rust kernel would be interesting, especially as each side could try and prove to the other why the other language is not/no longer needed and maybe come to understand whether there are real deficiencies and where, which'd only help the development of either...but at the end of the day, I'm definitely on the side that Rust is probably the future.
They just need to write kernel in Rust. And presumably avoid assembler, since it defeats to aim being memory safe :)
Letting a bunch of web dev's program the linux kernel is going to work out great.......
@@YouTubdotCub in kernel developers should be solving kernel and real hardware problems, not fighting silly wars for superiority of languages, nor is kernel a place for language development. That is exactly the downside rust culture seems to bring
@@dmitripogosian5084 memory safe kernels are the future regardless of which language one goes with, and Rust is the most developed of them so I don't really see the point of waiting until the language is "fully developed" (whatever that means, arguably C is still being developed lol)
@@YouTubdotCub I don't even understand what memory safe is in kernel context, which can manipulate hardware directly. How can a kernel be "memory safe" ? Some parts, maybe, but "the kernel" ?
Ok, so I gotta know. Is Linus' name pronounced "Lean-us", or "Line-us"?
Always thought it was the latter, and not the former.
He pronounces it both ways, according to him it's Lean-us in Swedish and Line-us in English, he doesn't mind which one you use. But since most of us would address him in English it's "Line-us"
@@liquidsnake6879 I wonder which one his mother uses?
@@CosmicCleric Lean-us maybe
Also, if you search Linus pronounciation, you will find his audio pronouncing his name
Toxic people? I guess there are conflict. Why not build their rust OS Kernel. Just create branch and test their own ways... I feel there will be bully and auth abuse and feedback disallow. It a lot of work to translate c and rust. I guess it more hinder...
Rust will never *Extinguish* the Metal. I will not be cheated by some cultureless Mary Sue and their Nerded tools that produce not armaments. These nameless vainglorious beggars are unknown to maintenance and cannot comprehend redundant failsafes nor debugging. The little angels who only ever get it true deserve to be smited, for Deception is not TRUTH... we test things here because everything breaks its all a matter of when and where but it surely does break. Coddle and Cope what you will, but such negligence is always at someone elses expense. Mobile users are propping up pretenders everywhere in all fields. The Internet is being reborn.
Redox OS is a thing and it's shaping up nicely...
What even is there left to test? Rust is usable already. There are drivers poping out like the apple silicon gpu driver, where the dev said that Rust made it so much more easier to get to a stable state and have a memory save driver. It not some unfinished concept to play around with, it doesnt crash or fail, it works.
If you push it to just some new branch or fork instead of the main kernel, you will lose resources and hinder its development, which I dont think is something good to delay tools for memory safe code.
Even if Rust is new and needs more implementation. At its current state, it does hold its promise of beeing memory save and working as it should.
For me this is a question if we wanr Rust develop as fast as possible or slow its development down.
Language grammar nice is.
@@peterfireflylund For everybody's language, them on it not English why first pick?
It kinda pisses me off that the C maintainers are being so petty. Like they don’t have to like Rust, but going out of there way to make the Rust maintainers lives difficult is just childish.
Whenever I see people be petty and make others lives/jobs difficult it just screams jealousy to me. Like nobody is forcing them to learn Rust, and C has benefits over Rust and vice versa.
They're not being petty, they're losing the ability to maintain the project, that's highly problematic, the Rust devs effectively demand that everyone learn Rust so that it can be integrated into the Kernel at large scale without a loss of maintenability and all this is problematic, especially when major projects like Debian tried Rust and are abandoning it because they failed to get it working reliably without massive efforts.
The solution is as ancient as it is simple, fork it
The dogmatic hubris of rust zealots never ceases to amaze. That blog post.. holy crap. The complete lack of self awareness is awesome.
"You see, we Rust devs aren't just visionaries. That's too pedestrian a title for our greatness. We're _wayfarers_! And you, well you're that construction crew we speed by at 30mph over the construction zone speed limit every morning on our way to work to change the world.
We recognize the importance of construction workers... "road builders", even as we ignore your basic safety as we fly by at 80mph. Our work is just more important. We are the future that you'll soon be tasked with building!
So do get out of our way. We've got a world to change!"
Problem with rust is that is just language filled with "belivers" not with people that understand how the reality works - hence it's not worth touching it in kernel.
Good one 😂😂😂
From what ive seen rust is just another java script hype today gone tomorrow.
Ah yes javascript is gone in the browser 😂😂😂
Leeenus
The do it as others have done it can be a very sensible approach, particularly if your fixes and upgrades are breaking changes for everyone else. Which is the bigger a headache?
It's not just "do it as others have done it", it's the Rust compiler discovering logical errors in the way this design handles memory, that break Rust's memory safety guarantees. Basically they found bugs that need fixing and they were blatantly told "It is as designed, shut up and repeat the same mistakes" which would entirely defeat the point of using Rust in the first place. So of course the Rust developers are distraught.
Only because a new change breaks something, doesnt make that new change bad. Compatibility and reliability is importent, so is adopting new technologies, tools and advancements. Because even if they at start may break some other component, for the future they could mean even bigger reliability. So having some APIs be changes could mean that developers could build easier and better drivers with less bugs.
@@TheFimiTube It would be better to let them do it the C way first, despite the problems, so that it can get incorporated into the kernel first. THEN make your case for how you are discovering the memory problems and while you're at it, present the way to fix it with patches for the current C system. Otherwise, it's going to be a hard sell to anyone.
@@TheFimiTube stability within the linux kernel supersedes any adoptions of new tooling / languages.
"someday this COULD be more stable" is not what ANYONE should want merged into the kernel.
there needs to be a plan and process to contributing to the kernel (processes which already exist).
and, at least some of the rust devs are not abiding by process and having issues with it.
Linus is gatekeeping for stability over sweeping changes that are prone to regression introduction.
He's not wrong.
hmm not sure how connected a specific language is with a disagreement on philosophy on changes/refactoring.
What I see happening is rust advocates trying to get their code into the kernel because they see it as superior, and old C devs pushing back because
1. C is simple, compatible with literally everything (compiler-wise), and faster than anything (even C++ sometimes) which does add up at a kernel level. When linux is used a ton in embedded devices and minimal containers C makes a lot of sense. C is also the most mature at this point, which makes sense for something like a kernel.
2. they know C and C is much more simple/easy to understand than rust.
Imo these devs should simply fork the kernel if they want rust to be a fixture for modern platforms.
though on the other hand, Linus has already allowed Rust in the kernel. At that point the cat's out of the bag
original intent was to allow for device drivers (loadable kernel modules) being written in Rust, and that could be a good thing vis-a-vis stability and safety per said device drivers.
Directly doing parts of the kernel itself in another language than gcc - that's a rather different matter
it's literally a skill issue on C dev side. the C ABIs are dogshit.
C actually doesn't have a true ABI and will act differently depending on architecture. There's a reason Zig reimplemented it in their own language. Rust is designed to be architecture agnostic and does give you meaningful guarantees on memory safety you will never get from C. Honestly, I think i32 is much better syntax than int32_t or whatever long long means. Rust spells everything out nicely and you can compose your code effortlessly. Lifetimes, async, macros, and traits could use a redesign if I'm being honest, but everything else is amazing.
@@gljames24 I don't disagree that 'i32' is much better than 'int'. I'm not even saying C is better in every situation.
But other parts of rust do seem somewhat esoteric and difficult to work with, plus the ecosystem just isn't as stable and mature (or supported on every platform). At the end of the day these safety guarantees do come at a cost whether it's computational or cognitive overhead. (and maybe is partly just being newer). People writing a kernel probably need to use all those things you say need a redesign, so why would they write kernel code using that instead of using something they know well and know is stable, works well, and is supported on every platform?
Actually I think zig makes much more sense to use for inclusion in a kernel than rust as it's C interop is prioritized and it seems easier to reason about, but it's even less stable right now..
Any and everything can adapt to C ABIs - any programming language known to man has some means of dealing with bindings to C APIs.
But there will be a massive, massive, massive rebellion against trying to make the Rust programming language a basis for so-called universal bindings. Just not enough hyperbolic adjectives in the English language to describe how much outrage this would generate (e.g., say govt mandate attempts, etc).
C won that war because it was essentially first
Looks like rust people are trying to convince others with sermons now. Opponents may say that If you need a safe language, maybe kernel dev isn't for you.
Whatever the end result, this drama rivals some Netflix originals.
Looks like you do need to watch some TV series so you actually get informed about what is really happening lmao
I’m with team C. Rust should behave exactly the same and use the exact same APIs as the C drivers. You don’t want different approaches in the same kernel! And you can’t just change roads that needs to be though over properly planned, because updating roads causes traffic jams and problems (always), you don’t want that in critical systems. I’d yiu want the latest and greatest build a new kernel. And soon you’ll be in the same mindset to not change your roads (or at least not too hastily).
IBM never did that in the decades that OS/3XX exists and they too changed technologies. Stability and thus standard of doing things are the utmost importance of a kernel!
And I see in the Rust devs, something I’ve seen with developers below the age of 40-45 and that’s properly designing, testing and implementing robust critical software having the vision and mindset to not break what is there; this is why modern software breaks so often MacOS, Windows but also Adobe and AutoDesk critical applicaties crash like a junky getting of a high. Critical software takes time and is tedious, and it seems to not be a thing anymore. And it irks me in this business, these days.
Rather hard when the language itself mandates enforces memory ownership.
Easier to rewrite everything from scratch like ReduxOS. There's definitely some 30 years of questionable design decisions within the base kernel. Everyone simply forgot about the drama
@@Demopans5990 my points exactly make a new Rust posix compliant micro kernel. That makes far more sense.
Use of the term "modern" is quickly becoming a euphemism for "repeating the mistakes of the past". These aren't modern development methods. They're just bad ones. If your filesystem can't survive a 7 year lifecycle deployment, it's useless in production. I have better things to do than babysit monthly breaking changes.
Also, take a shot for every "Leenus". 😂
Clearly the C language is the oldest language of all the programminglanguages we use for Linux. It was designed in the seventies! Its authors never kept it as a public sercret that there are trade off 's when designing a language. Would you revoke some of the decisions no a days? Of course you would. And the C language started on hardware of 50 years ago that no one uses anymore. THE POINT I WISH TO MAKE HERE: : would it be interesting do desing a better C, applying all the knowledge and experience about conpiler construction for example that there is today? Then one of the criteria is faster programming, and another one the good readability of the code in that new language for debugging and cooperation between the developers.
Tale as old as time:
The new generation thinks they can change everything.
The old generation thinks nothing needs to be changed.
The truth is, as always, somewhere in-between.
really, the bcachefs folks just need to stick to module space until they get it right....
As far as rust is concerned, no reason why you can't fork the kernel and refactor all the code you want.
Rust developers frustrated? Yeah. f-Rust-ration, it's baked into the language. You can't just walk into a project and expect everything to change for you and around you, especially something like Linux. Honestly, Linus is the OG pathfinder. It seems kinda arrogant to come in thinking, you know the way, and everyone else must be wrong.
You're never going to have a "safe" kernel. Rust is "safe" because it delegates unsafe, or just goes unsafe and is no longer safe, and now you have to be a guru in how the compiler optimizes code and the assumptions it makes. You're more unsafe at that point.
Why do I have a feeling that you don't know how the kernel works or Rust's safety lol
@@RustIsWinning I don't care about your feelings
@@toddfulton2280delusion 100. Keep it up 😂🤡
@RustIsWinning
Clown world is thinking a hacky affine type system can solve everything. In fact, there are data structures and algorithms that can't be implemented in safe Rust because of this, which is a major reason for unsafe or delegating to C. If you need to unsafe or delegate to C, don't try to impose the affine types on C/unsafe. Otherwise, you're back where you started, or you're just pushing the issue on and making it someone else's problem.
Don't get me wrong, limiting unsafe is great, but when you get out of that bubble, you have to understand where you are, why you're there, and that eventually you have to be. You can't live in a pure world forever if you actually want to interact with the real world, which is what the kernel is for. Rust can live in its affine bubble because it can delegate to C.
@@toddfulton2280ah ok that's what you meant. Well, thanks for extending your last paragraph because it's hard to decipher the quotes around safe and sometimes without quotes.
I mean you are not wrong. At the lowest level we will eventually find unsafe code. I'm pretty sure everyone knows that already. The only new thing that is going to happen with safe abstraction is that there will be way less critical CVEs. Well, unless somebody finds a new way like cross language attacks. What matters is that the kernel is somehow improving.
as purist programmer, one is allow to only mix 2 languages assembly language and a high lelvel one , c and rust have no business comingling with each other, this elevate the complexity of thing,
if Rust is that great as a programming language the should not have issue creating their 100% Rust kernel, instead they want to complain and blame the the original api for it issues,
even a programming language change over time, software that look like frankensteing are terrible and too complex to understand seriously if they want Linux with rust they should start porting it now, but the language is immature and it was recommended by an overzealous idiot from the gonverment to make all software safe
"They"? It was Linus who wanted to add Rust to the kernel. The Rust people already created their own OS call Redox OS.
@@khai96x linus did not want to look like a duch bag and alienated rust developer, he made clear he will continue to do c even though it will be costly if there not enough people to maintain it, i saw the video , he didn't want to jump in the war between c and rust
My problem with it is precisely that they're mixing languages and it's a giant mess, lots of C maintainers don't know Rust so now there's a bunch of code in the Kernel that only a select subset of coders and even less maintainers can even understand (which is in of itself a massive security risk) and they're splitting the Kernel into two separate factions, the ones that write and maintain Rust code and the ones that write and maintain C code, it's a mess, and the Rust guys from projects like Debian themselves are struggling with managing dependencies it seems so it's not fully battle tested and people already want it to take over massive chunks of the Kernel
Far better IMO if they just hard-fork the Rust version into a separate repo and work on that separately from the mainline Kernel
Those Zealots from Rust just wanna satisfy their ego by destroying Kernel...
Meds 🤡
@@RustIsWinning
you mean RustisClown ?
oh... I got it...
my bad... 🤔😏
@@SkyFly19853 my guy you program in Python and PHP. All your comments are meaningless if you dont understand system programming.
@@RustIsWinning
but...
at least, I understand enough to recognize Rust is useless for Kernel Development and even harmful...
@@SkyFly19853You are not giving any convincing arguments. What makes you think this way? Rust is trying to improve the world. What's your problem with this?
Well if rust leave Linux , rust will fall into the forgotten languages
Clueless deluxe 😂
@@RustIsWinningwe will see.
Just to have more fun we should have the C code written in a way for it to be more difficult and tedius to be converted over to rust. Job security > memory security
Looks like Rust was aptly named.
Here's a thought, maybe the Rustaceans can rebuild TempleOS in Rust instead shoehorning themselves into existing projects
Good one 😂😂😂
I've been saying exactly this. Time for that community to put up or shut up.
Just fork it! Rewrite all in rust!
I'm going to single-handedly do that tomorrow morning and show every boomer how easy it is to rewrite their old code in one day!!
@@RustIsWinning 🤣
They can't. Skill issue. Rust primarily appeals to 20 somethings and web developers who want to "break in" to systems programming. Which is why you are seeing so much pain right now.
@@CommanderRiker0 Interesting point to consider that while Rust is kind of an "elitist" language in itself, most Rust developers seem to focus their skills in Rust itself and have often very little in anything else (apart probably from web dev, as you mentioned). The problem with this programming language "mania" is that it seems to become central to everything, and its proponents seem to feel entitled to get help from everyone because they are the kings who bring Rust to the table.
The logical approach would be a bunch of regular Linux kernel contributors (in C), with extensive enough experience to be trusted contributors, having learnt Rust and introducing it in some parts of Linux as it looks fit from experienced devs' POV.
Instead, it looks like a bunch of Rust afficionados that want to invade Linux without actually knowing it deeply enough and expect to get hand-held by developers who not only do not know Rust, but have, like, already a lot of work to do to maintain Linux.
As I said before, there *is* a project around with a full Rust kernel (not Linux) with some OS around, I don't remember the name, but it should be easy to find. These people seem to know what they're doing. Why don't more Rust devs flock to this project rather than try to piggypack on Linux and then whine?
I think I have an idea: that's where money and fame potentially is. I guess they realize that they won't get that by contributing to a possibly interesting, but obscure OS than nobody knows (I can't even remember its name myself!)
"Leenus"? And Wikepedia is a terrible source for "facts".
Yeah, about the Rust in Linux Kernel, people just too idealistic about C and feel superior (like other language specific programmer do) and gatekeeping the kernel.
I just can't take seriously anyone who uses the term "gatekeeping".
@@stargazer7644 You can't take seriously anyone who rejects modern use of language and ridicules new generations while being left behind. Exactly what's happening to C/C++ purists, lmfao
How about rasturds create their own projects instead of hijacking other great non-rust stuff.
@@EiziEizz It's funny how you edgy people think Linus would let supposed trend chasers hijack his kernel.
@@SaHaRaSquad Already did with the Code of Conduct. That was the first big mistake.