Allow me to state my opinion more clearly. Rust can be useful in the kernel. If you want more Rust in the kernel, you should try to get more maintainers to know Rust, and the best way to do that is to get most NEW maintainers to know the language. You can also try to get existing maintainers to learn the language, but this is unlikely. (PLS don't go and think this statement is malicious, if a maintainer says no, it's no). The way I explained it in my video wasn't clear, and it sounds ageist, and it's generally inaccurate, age doesn't change whether you know Rust or not (; Now you can all debate whether Rust should exist at all XD
Experience has a huge enough effect on quality for everything that nothing can compensate for it with a young replacement. If it was up to me, I'd favor the old way with old devs over the new "safe" way with young devs until the old naturally retire. Phase in the new in step with that and only as it becomes more stable and maintainable than the old because that's where most of your person experience is.
One issue is that new maintainers can get burned out if the code they are submitting is seeing a lot of pushback not on technical grounds but just general resistance to rust being near their area of the kernel. You can see this happening with the asahi linux project where the maintainers for it need to keep work out of tree much longer than needed because of non-technical hold ups and debates. Things like this just result in people being more frustrated and creates more work for these maintainers as more of their work stays out of tree for longer. I understand some maintainers being frustrated about a new language in the kernel but that bridge is already crossed, now we should all just be focused on finding the most painless path forward.
I tried to like Rust many times, but whenever I did, I ended up being frustrated because Rust is completely counter intuitive for me. It (language and library) uses strange naming, strange syntax and overall seems to be unnecessarily complex. As far as I understand, memory safety is one of the biggest selling points of Rust. I can see how that is extremely valuable in all those areas where garbage collection is a problem. But in my 30 years of hacking, garbage collection was never really a problem. It is in the kernel. But here is the thing. When you're hacking a kernel, you really need to understand what you're doing. You just don't have a nice abstraction like living in a sane process or thread, you live on hardware. In this context, the qualification to correctly manage memory is still an issue, but compared to all the other skills you need to live in kernel space, it's just trivial. I don't know what exactly requires Rust to get some special support from the kernel to live side-by-side with C code. But to me it is a very bad sign that there is a barrier that is intrinsic to Rust. That makes Rust look like a bad choice for an alternative language in a kernel that is mostly C. The more I hear about issues with Rust in Linux, both technically and socially, the more I am surprised that Linus accepted it.
I think party of the rust problem is a cultural one. In Rust, you put as much as possible about the semantics into the type system, so that the compiler is responsible for enforcing the semantics. Some traditional c developers have the approach that it is primarily the developer's responsibility to know how to do and use things. The rust facades for kernel c apis trigger everybody because that's where the cultures meet.
If you are familiar with duck typing you may have a clear notion of what I mean when I say "C transparently allows duck semantics and Rust is vigorously incompatible with duck semantics." Should the kernel rely on duck semantics? Maybe not, but as long as the semantics documentation is always out of date, or only exists implicitly in the source, keeping code that relies on duck semantics to work cannot play well with Rust.
@@htpc002Weirdhouse Rust is fine with duck-typing. It's just implemented as function pointers, possibly collected into a struct, right? Rust has those. It even has the dyn keyword that marshals between vtables and traits. Rust makes broken or out of date semantics a lot more obvious because you are encouraged to tell the compiler the semantics rather than store them in the lead (possibly sole) developer's head. If the actual semantics are borked, then they are borked. Rust just holds a mirror to this.
I love your videos. This is such a great digest for Kernel Updates. I learned about so many things about the kernel that I probably would have never heard of. This is truly a hidden gem that more people in the community need to see.
You are doing a great job with this summary. It's very instructive, nicely explained, not boring. This must be quite a lot of work. Very nice. Thank you!
@@Maple-Circuit I think we get the better end of the deal here. Big thanks! You seem to have an in depth understanding of the kernel. Have you been working on the kernel? That would be a rare combination of skills, tech & didactics. I wish I had the talent to present stuff as well as you do.
@@michaelutech4786 I've been using Linux for over 10 years, but my area of expertise is Windows, as I was a computer technician for >5 years... To be honest, in the last few months I've just decided that I need to use my general knowledge and communication skills and learn as much as possible about the kernel. It is getting better and better! I'm trying to get to 1 video a week, we'll see!
This is a great review of the kernel changes. Love this style way more than the ones I've seen on bigger channels. Subscribed for more kernel update summaries :D
the rust section neglected to mention examples like maintainers rejecting C code bug fixes that would just so happen to help a rust gpu driver. there are maintainers unjustifiably attempting to halt rust adoption in the kernel
"unjustifiably"? How many drivers relay on this "bug" unintentionally? Or how many new bugs surface after you fix this one? Do you maintain code that have more than 10 years? I had many times in my career cases like this, simple "fix" break lot of things. If we have two people one who recent in code base and fix some bugs and another that had decades in this code base and reject this changes, I would bet on veteran that he make correct call in this case. If veteran is wrong, you can always fork Kernel and fix all fallout cased by your changes yourself.
The IBM Power/s390/z mainframe big-iron systems do have physical CPU & memory hot-plugging capability while the machine is still running - not just VM cpu hotplug. They have hot-spare cores & cpus that process in a form of raid & compare results at runtime. This is why they have such a high 9's uptime because of the on-line repair/maintenance RAS
You said "old developers should quit" because you want more Rust in the kernel... I'm using Rust, but I'm trying to avoid any contact with a community because of statements like this one. Please refrain yourself from a private opinion that someone might interpret as an insult ("Are you an old kernel developer who uses C and doesn't like the idea of implementing more stuff in Rust? then just quit."). I would be thankful if Rust developers working on the kernel wouldn't think about Rust as some type of cult.
I wonder, when Linus passes away if there will be more big changes to the kernel. I think Greg Hartman will add native support for a standardized configuration system across distributions to specify automount behavior, replacing /etc/fstab. He's fucking crazy man!
Zig should've been a better choice for Linux because the old maintainer could've easily get used to writting zig, because zig is just a convenient C (a better version of C with less footguns).
Ntfs using the ntfs3 driver from paragon that was merged into the kernel ALWAYS makes errors in the filesystem that have to be fixed from windows while the fuse ntfs-3g extremely rarely does that. Literally ntfs3 mounted drive i have to check consistency every week and every time windows finds problems. With ntfs-3g it's super rare. I wonder if anyone else experienced this. Both on latest kernel 6.10.x or the 6.6 LTS kernel it doesn't make a difference
On my dual boot system I've had more problems with win10 leaving a drive in such a state, after booting into Linux I'd have to run ntfsfix. Can't recall any problems with nfts-3g.
Maybe this is the wrong place to ask but I'm asking anyway. lol For those who like having Rust in the Linux kernel, how well do you think the Rust Linux kernel developers know 'C'? If they know Rust much better than C, I can understand hesitation by the C developers to incorporating more Rust into the kernel. If the Rust Linux developer is as proficient in C as they are in Rust, I think they should be able to make a more convincing argument to adopt Rust since they can advocate in 'C-like' terms/perspective vs using "because it's safer" kinds of arguments.
Rust is there because C is like Fortran to young developers. Rejecting it at this point is contributing in maliciously killing it just because you don't like it. Part of futureproofing a project is to adopt features that will be maintained by the people who use it. I don't really expect people in 100 years from now to be using C, by then it will be "too old" and younger generations prefer to do things efficiently with things that are already written rather than re-inventing the wheel for the nth time.
@@MilesPrower15 Thanks for the reply! Your point is interesting because I get the analogy of C being "ancient" to the "new crop" of developers, but given how much low-level code, like a kernel, is written in C, that changes it's scope a bit. I don't know Rust. However, I believe parts of the Rust compiler or build-chain are written in C or C++. I think JavaScript engines are written in C or C++, as are some if not all of the major browsers. I think the Windows NT kernel is also written in C and/or C++. To me, that's more 'incentive' to learn C vs something like a FORTRAN. Still, your point is well taken.
What I don't like about Rust is that in contrast to C, which is very simple language, standardized by ISO, has at least 2 big compilers (and really lots of small), Rust is young, quite complex, has huge corporation behind, and only has 1 mature compiler. It more similar to C++ than C, which is hated by Torvalds and not in the kernel. I totally understand why people like Rust, but I wouldn't write significant software that is supposed to exist in long term in this language. tldr: In my opinion, for (probably) the most important software in the world, Rust looks as big and unstable dependency
I feel that rust isn't a good addition to the Linux kernel because it is a relatively new language and if for whatever reason people get tired of it some pieces of code will be left hanging, C is really mature and widespread, I'd still choose it over Rust even in a new kernel
Changes shouldn't be pushed faster than the natural rate of your senior incumbents naturally adopting it. If you want to, let it develop independently of them. Every system of every type crashed hard, often destroying everything good that was already there with no path to become good again but within a false perception bubble, forcing change faster than natural adoption and adaptation.
Rust in the kernel started with a weird twitter campaign foreshadowing personality clashes. I think it was Linus' first big fumble. I also disagree with the mentality about programming that Rust represents which make people think it's superior.
I don't agree with the point of having the old devs quit. I agree that having 2 languages for the kernel is annoing for some people but it should not mater in the long run. The kernel used to have, and still does I think, a lot of assembly. it was a hassle to mantain but people did it. I think we see a lot of growing pain and thinks will smooth out in a few years as the older dev get used to rust and the newer ones get used to C.
Dingus it has assembly because that is REQUIRED for low level bootstrapping. You can not use compiler intrinsics at that low a level. It's not like some people decided to develop a network driver in ASM for fun one time and Linus said "LGTM" and merged it.
I don't get why anything unstable or projected to not be maintained in a continuous stable working state for at least several years ahead would be in the mainline. Let people who want it inline merge it into their custom kernel.
Writing a kernel from scratch would look like a much sounder approach, there's already one in Rust, why don't they focus on this instead of trying to "invade" Linux (I know why: money)? As to languages, Rust is certainly not what I would have picked for a new kernel, if I wanted to try something else than C.
Let's use only Rust in Security and Crypto. Let's use only new, fresh maintainers for it. I understand there is a great training program for them in Quantico.
Ah, yes, "old people don't know Rust". A lot of people do open source development for free, they don't get paid to do it. It's already pretty complex and requires a lot of time to do. Maintaining Rust binding adds even more complexity to it, it's not a mature language (now that it has been added -- more stuff breaks more frequently because of it). But a few Rust fan boys show up and start demanding things, because their language is "superior". And look at all those evil "old developers" who "get triggered" by it! And when things don't go their way they throw their hands in the air and quit because of "non-technical issues". C developers are not the problem here.
Rust is a mature language by any reasonable metric; it's more than a decade old, sees large scale production use. The stuff breaking was always broken, Rust is just more strict and makes problems that were always there more visible.
@@Deveyus in actual real world (as opposed to your fantasies) it is less than a decade old. And even a decade isn't very much compared to pretty much any other language out there (with Golang being the only exception, which is pretty new language, but still older than Rust). It doesn't make any problems in existing C code any more visible.
@@RustIsWinning it doesn't at all actually, only runtime matters. Also you have not finished writing drivers. Whatever you currently have is not a usable system.
@@Asdayasman It is usable. I just made it unsafe but it is doing fine for the most part. Now I'm trying to introduce safety at the driver level before I make the rest more secure. Do you think this will work?
Im gonna have to dislike for the rust propaganda, the classic use of ageism. it's not just "OLD" devs that dislike rust. Rust is just a ugly language compared to C.
I can agree that my characterization of a C-only programmer as old isn't accurate and a little ageist. I should have stuck to the main point: more maintainers that are Rust coders, more Rust in the kernel. I could have worded that wayyy better... (EDIT) and i now do in the pinned comment (;
@@denodoko I could, but I didn't really want to go down that rabbit hole. Ill just say Rust is extremely verbose, it looks like somebody took the worst parts of JavaScript and C++'s syntax and slapped them together.
Rust is the future of the kernel, that's clear. C would work perfectly if everyone was a perfect developer, but they aren't and we're seeing the quality of developers drop with younger generations, especially Gen Z that aren't as technically competent as Gen X and Millennials. Rust essentially provides the safety wheels by being more verbose and having an aggressive compiler that checks everything. It's necessary to make Rust the core of the kernel because we simply are losing all the good developers to age and we can't expect the new young developers to be as good so we have to rely on Rust to essentially force them to write good code (against their will).
Language is just a tool, if new developers are bad at it, you still have a huge problem, worse than the choice of language ... Besides that, Rust doesn't enforce good code, you can do really shitty on it also ...
replacing the old, efficient language because people are getting worse at the job would imply that the way we do things currently is broken. beyond the above, dear virtue signalers: climate change.
Allow me to state my opinion more clearly.
Rust can be useful in the kernel.
If you want more Rust in the kernel, you should try to get more maintainers to know Rust, and the best way to do that is to get most NEW maintainers to know the language.
You can also try to get existing maintainers to learn the language, but this is unlikely. (PLS don't go and think this statement is malicious, if a maintainer says no, it's no).
The way I explained it in my video wasn't clear, and it sounds ageist, and it's generally inaccurate, age doesn't change whether you know Rust or not (;
Now you can all debate whether Rust should exist at all XD
just re-write it in assembly
@@Dimkar3000 of course it should be jquery
Experience has a huge enough effect on quality for everything that nothing can compensate for it with a young replacement. If it was up to me, I'd favor the old way with old devs over the new "safe" way with young devs until the old naturally retire. Phase in the new in step with that and only as it becomes more stable and maintainable than the old because that's where most of your person experience is.
One issue is that new maintainers can get burned out if the code they are submitting is seeing a lot of pushback not on technical grounds but just general resistance to rust being near their area of the kernel. You can see this happening with the asahi linux project where the maintainers for it need to keep work out of tree much longer than needed because of non-technical hold ups and debates. Things like this just result in people being more frustrated and creates more work for these maintainers as more of their work stays out of tree for longer.
I understand some maintainers being frustrated about a new language in the kernel but that bridge is already crossed, now we should all just be focused on finding the most painless path forward.
I tried to like Rust many times, but whenever I did, I ended up being frustrated because Rust is completely counter intuitive for me. It (language and library) uses strange naming, strange syntax and overall seems to be unnecessarily complex.
As far as I understand, memory safety is one of the biggest selling points of Rust. I can see how that is extremely valuable in all those areas where garbage collection is a problem. But in my 30 years of hacking, garbage collection was never really a problem. It is in the kernel.
But here is the thing. When you're hacking a kernel, you really need to understand what you're doing. You just don't have a nice abstraction like living in a sane process or thread, you live on hardware. In this context, the qualification to correctly manage memory is still an issue, but compared to all the other skills you need to live in kernel space, it's just trivial.
I don't know what exactly requires Rust to get some special support from the kernel to live side-by-side with C code. But to me it is a very bad sign that there is a barrier that is intrinsic to Rust. That makes Rust look like a bad choice for an alternative language in a kernel that is mostly C.
The more I hear about issues with Rust in Linux, both technically and socially, the more I am surprised that Linus accepted it.
Drama, the grease that moves the gears of kernel development.
the rust community is a perfect fit then!
Sitting here waiting for the future Zig kernel drama.
The total anarchy that would ensue XD
Can't wait! (Not for the drama...)
It won't be a drama if there won't be zig in the kernel any time soon/ever
@@RomanAvdeevX Dingus that's the joke.
@@Asdayasman Ok
You want old programmers to step aside, but there will be tears when they go away...
indeed, there is drawbacks to everything!
I think party of the rust problem is a cultural one. In Rust, you put as much as possible about the semantics into the type system, so that the compiler is responsible for enforcing the semantics. Some traditional c developers have the approach that it is primarily the developer's responsibility to know how to do and use things. The rust facades for kernel c apis trigger everybody because that's where the cultures meet.
True!
If you are familiar with duck typing you may have a clear notion of what I mean when I say "C transparently allows duck semantics and Rust is vigorously incompatible with duck semantics." Should the kernel rely on duck semantics? Maybe not, but as long as the semantics documentation is always out of date, or only exists implicitly in the source, keeping code that relies on duck semantics to work cannot play well with Rust.
@@htpc002Weirdhouse duck typing is fine. Not documenting or validating the ducked contract is asking for trouble.
@@htpc002Weirdhouse Rust is fine with duck-typing. It's just implemented as function pointers, possibly collected into a struct, right? Rust has those. It even has the dyn keyword that marshals between vtables and traits. Rust makes broken or out of date semantics a lot more obvious because you are encouraged to tell the compiler the semantics rather than store them in the lead (possibly sole) developer's head. If the actual semantics are borked, then they are borked. Rust just holds a mirror to this.
I love your videos. This is such a great digest for Kernel Updates. I learned about so many things about the kernel that I probably would have never heard of. This is truly a hidden gem that more people in the community need to see.
Thanks!
You are doing a great job with this summary. It's very instructive, nicely explained, not boring. This must be quite a lot of work. Very nice. Thank you!
It is! But the nice comments are rewarding (;
@@Maple-Circuit I think we get the better end of the deal here. Big thanks!
You seem to have an in depth understanding of the kernel. Have you been working on the kernel? That would be a rare combination of skills, tech & didactics. I wish I had the talent to present stuff as well as you do.
@@michaelutech4786 I've been using Linux for over 10 years, but my area of expertise is Windows, as I was a computer technician for >5 years...
To be honest, in the last few months I've just decided that I need to use my general knowledge and communication skills and learn as much as possible about the kernel.
It is getting better and better!
I'm trying to get to 1 video a week, we'll see!
This is a great review of the kernel changes. Love this style way more than the ones I've seen on bigger channels. Subscribed for more kernel update summaries :D
in 6.11 intel provided a ssl/tls patch. up to 40% better perfomance. this is good
I really appreciate these filesystem update sections!!
Love learning about filesystems
the rust section neglected to mention examples like maintainers rejecting C code bug fixes that would just so happen to help a rust gpu driver. there are maintainers unjustifiably attempting to halt rust adoption in the kernel
"unjustifiably"? How many drivers relay on this "bug" unintentionally? Or how many new bugs surface after you fix this one? Do you maintain code that have more than 10 years? I had many times in my career cases like this, simple "fix" break lot of things.
If we have two people one who recent in code base and fix some bugs and another that had decades in this code base and reject this changes, I would bet on veteran that he make correct call in this case.
If veteran is wrong, you can always fork Kernel and fix all fallout cased by your changes yourself.
Based.
@@von_nobody well it was an unnoticable side effect caused by a function, how would you even exploit that as a bug-feature?
Why can't the rust developers send a pull request with those bug fixes?
@@RicardoSilvaTripcall but they did
Very nice commentary format to get a quick dump of what's happening in the kernel!
as always, thank you! love the sections on top, makes things clearer
Finally 6.11 is released, i can now use my laptop's keyboard without using an rc kernel!
The IBM Power/s390/z mainframe big-iron systems do have physical CPU & memory hot-plugging capability while the machine is still running - not just VM cpu hotplug.
They have hot-spare cores & cpus that process in a form of raid & compare results at runtime. This is why they have such a high 9's uptime because of the on-line repair/maintenance RAS
Wow thats insane! Thanks for sharing!
Huge fan of your takes in this vid. Super agree.
RISK-V is so cool !
You said "old developers should quit" because you want more Rust in the kernel... I'm using Rust, but I'm trying to avoid any contact with a community because of statements like this one. Please refrain yourself from a private opinion that someone might interpret as an insult ("Are you an old kernel developer who uses C and doesn't like the idea of implementing more stuff in Rust? then just quit."). I would be thankful if Rust developers working on the kernel wouldn't think about Rust as some type of cult.
Pls read pinned comment, where i make things a bit more clear.
And then you can demolish me (;
More and more I feel Zig would be a better choice for a new language in the Kernel.
Not even close 😂
I wonder, when Linus passes away if there will be more big changes to the kernel. I think Greg Hartman will add native support for a standardized configuration system across distributions to specify automount behavior, replacing /etc/fstab. He's fucking crazy man!
Zig should've been a better choice for Linux because the old maintainer could've easily get used to writting zig, because zig is just a convenient C (a better version of C with less footguns).
I just got an update to 6.11 on nobara and immediately my Lenovo laptop has problems waking from sleep. I reverted to the previous .10 version
as an f2fs user i see this as a huge W
Ntfs using the ntfs3 driver from paragon that was merged into the kernel ALWAYS makes errors in the filesystem that have to be fixed from windows while the fuse ntfs-3g extremely rarely does that. Literally ntfs3 mounted drive i have to check consistency every week and every time windows finds problems. With ntfs-3g it's super rare. I wonder if anyone else experienced this. Both on latest kernel 6.10.x or the 6.6 LTS kernel it doesn't make a difference
On my dual boot system I've had more problems with win10 leaving a drive in such a state, after booting into Linux I'd have to run ntfsfix. Can't recall any problems with nfts-3g.
Thanks for your Videos :3
u should start yr podcast , really good content btw
Maybe this is the wrong place to ask but I'm asking anyway. lol For those who like having Rust in the Linux kernel, how well do you think the Rust Linux kernel developers know 'C'? If they know Rust much better than C, I can understand hesitation by the C developers to incorporating more Rust into the kernel. If the Rust Linux developer is as proficient in C as they are in Rust, I think they should be able to make a more convincing argument to adopt Rust since they can advocate in 'C-like' terms/perspective vs using "because it's safer" kinds of arguments.
Rust is there because C is like Fortran to young developers. Rejecting it at this point is contributing in maliciously killing it just because you don't like it. Part of futureproofing a project is to adopt features that will be maintained by the people who use it. I don't really expect people in 100 years from now to be using C, by then it will be "too old" and younger generations prefer to do things efficiently with things that are already written rather than re-inventing the wheel for the nth time.
@@MilesPrower15 Thanks for the reply! Your point is interesting because I get the analogy of C being "ancient" to the "new crop" of developers, but given how much low-level code, like a kernel, is written in C, that changes it's scope a bit. I don't know Rust. However, I believe parts of the Rust compiler or build-chain are written in C or C++. I think JavaScript engines are written in C or C++, as are some if not all of the major browsers. I think the Windows NT kernel is also written in C and/or C++. To me, that's more 'incentive' to learn C vs something like a FORTRAN. Still, your point is well taken.
Rust and C devs blaming the other side, need to look in the mirror. They are both the problem. Tribalism is real. I say this as a C dev.
Wtf is this comment section and why are C devs so salty?
Also, old man yells at cloud.
Lol
thanks for da vid! make more of them, please
18:00 you don't need to know Rust to write proper documentation and commit message to your C code.
What happened to NTSYNC?
as far as i know... nothing! we are still waiting for a fix for the broken version they put up.
we don't need rust in the kernel
Why do you pronounce Linus' name like [lainus]? It's [li:nus], just like [li:nux], (as in leenus/leenux).
I'm french canadian, even if it's right, saying linus in this way breaks my brain because it sound/feels like France french... but yes you're right (;
Why do you care? Why can't you hear why? It's obvious why he talks the way he does......
You want to tell me that when I update to 6.11 that I get 20% faster read and write times?
No, what I'm saying is that journal transactions are 20% faster, not 20% overall (;
No solution to rust drama?
Write code in C.
Write documetation.
Ask rust devs for help to fix broken part using documentation.
Asking for help is OK!
What I don't like about Rust is that in contrast to C, which is very simple language, standardized by ISO, has at least 2 big compilers (and really lots of small), Rust is young, quite complex, has huge corporation behind, and only has 1 mature compiler. It more similar to C++ than C, which is hated by Torvalds and not in the kernel. I totally understand why people like Rust, but I wouldn't write significant software that is supposed to exist in long term in this language.
tldr: In my opinion, for (probably) the most important software in the world, Rust looks as big and unstable dependency
@@kala-telo +1, rust is kinda overrated
@@sakurako-omuroo from someone who doesnt write rust and being a C dick rider hahahaha.
I feel that rust isn't a good addition to the Linux kernel because it is a relatively new language and if for whatever reason people get tired of it some pieces of code will be left hanging, C is really mature and widespread, I'd still choose it over Rust even in a new kernel
I think zig would be better than rust imo
Ah yes because Zig is sooo "memory safe" lmao 😂
@@RustIsWinning it's way better than c at least it has bounds checking... And would work well with legacy c code.
I want a filesystem with native encryption except zfs for the love of God!
Rust is needed
Needs to make it's own kernel
@@skinlab4239I just made one. What now?
... why not make another OS completely in RUST?
seems like you are doing some Frankenstein stuff with all these combinations.... not really elegant.
Bcachefs is a toy in devel
Changes shouldn't be pushed faster than the natural rate of your senior incumbents naturally adopting it. If you want to, let it develop independently of them. Every system of every type crashed hard, often destroying everything good that was already there with no path to become good again but within a false perception bubble, forcing change faster than natural adoption and adaptation.
Rust in the kernel started with a weird twitter campaign foreshadowing personality clashes. I think it was Linus' first big fumble. I also disagree with the mentality about programming that Rust represents which make people think it's superior.
Classic twitter user. Clueless deluxe as always 😂
I don't agree with the point of having the old devs quit. I agree that having 2 languages for the kernel is annoing for some people but it should not mater in the long run. The kernel used to have, and still does I think, a lot of assembly. it was a hassle to mantain but people did it. I think we see a lot of growing pain and thinks will smooth out in a few years as the older dev get used to rust and the newer ones get used to C.
Dingus it has assembly because that is REQUIRED for low level bootstrapping. You can not use compiler intrinsics at that low a level. It's not like some people decided to develop a network driver in ASM for fun one time and Linus said "LGTM" and merged it.
Pls read pinned comment, where i make things a bit more clear.
When the “old developers” retire, one has to hope that Rust is still alive. Religions come and go.
Very funny boomer joke about "religion" 🧓♿️
Where's your old videos?
The quality wasn't up to my new standard, I do a crazy amount of research now and I want all my videos to have that perfect factual backing.
@@Maple-Circuit This is admirable, thank you.
should people search for the part that they wanna change as if they were in v8 (js engine) or cpp stl, rust is a dumb move.
I don't get why anything unstable or projected to not be maintained in a continuous stable working state for at least several years ahead would be in the mainline. Let people who want it inline merge it into their custom kernel.
Unless there's some way to ensure it's never touched by anyone who doesn't choose to use it so those who do can experiment more easily.
real programmers can write multiple languages. people complaining about it is hella cope.... git gud.
Writing a kernel from scratch would look like a much sounder approach, there's already one in Rust, why don't they focus on this instead of trying to "invade" Linux (I know why: money)?
As to languages, Rust is certainly not what I would have picked for a new kernel, if I wanted to try something else than C.
there is no invasion, Linus Torvalds included it of his own volition. get your head out of the dirt
Let's use only Rust in Security and Crypto. Let's use only new, fresh maintainers for it. I understand there is a great training program for them in Quantico.
So the people finally got fed up with the influencer language bs. Good riddance.
promote one tool over another while almost does the same thing is just, politics
Ah, yes, "old people don't know Rust". A lot of people do open source development for free, they don't get paid to do it. It's already pretty complex and requires a lot of time to do. Maintaining Rust binding adds even more complexity to it, it's not a mature language (now that it has been added -- more stuff breaks more frequently because of it). But a few Rust fan boys show up and start demanding things, because their language is "superior". And look at all those evil "old developers" who "get triggered" by it! And when things don't go their way they throw their hands in the air and quit because of "non-technical issues". C developers are not the problem here.
Rust is a mature language by any reasonable metric; it's more than a decade old, sees large scale production use. The stuff breaking was always broken, Rust is just more strict and makes problems that were always there more visible.
@@Deveyus in actual real world (as opposed to your fantasies) it is less than a decade old. And even a decade isn't very much compared to pretty much any other language out there (with Golang being the only exception, which is pretty new language, but still older than Rust). It doesn't make any problems in existing C code any more visible.
Rust devs: just wanting to see a more precise documentation for C code to implement rust bindings
C devs:
@@RomanAvdeevX and I want a pony. And? Rust developers are welcome to contribute to documenting C code, then.
@@ivan_prime Why should they document the code they don't write? Wouldn't it be better and easier if everyone documented their own code?
Heck Rust. Go write your own kernel, stop Star Warsing the best open source project there is.
I just wrote my own kernel. What now?
@@RustIsWinning drivers.
@@Asdayasman That's part of the kernel. Actually I started writing safe abstractions for the drivers. Does that matter?
@@RustIsWinning it doesn't at all actually, only runtime matters.
Also you have not finished writing drivers. Whatever you currently have is not a usable system.
@@Asdayasman It is usable. I just made it unsafe but it is doing fine for the most part. Now I'm trying to introduce safety at the driver level before I make the rest more secure. Do you think this will work?
BSD
Im gonna have to dislike for the rust propaganda, the classic use of ageism. it's not just "OLD" devs that dislike rust. Rust is just a ugly language compared to C.
I can agree that my characterization of a C-only programmer as old isn't accurate and a little ageist. I should have stuck to the main point: more maintainers that are Rust coders, more Rust in the kernel.
I could have worded that wayyy better... (EDIT) and i now do in the pinned comment (;
wdym with "ugly language"?
I feel you could've used many better descriptors, than "ugly" to make your point.
@@denodoko I could, but I didn't really want to go down that rabbit hole. Ill just say Rust is extremely verbose, it looks like somebody took the worst parts of JavaScript and C++'s syntax and slapped them together.
@@purpasmart_4831 oh, i agree
I don't like rust, it's ugly and verbose. Next to C it looks like drugs. Unmaintainable. I'll be disliking the video advocating for it.
Sad!
rust needs to go
Rust complicates things a lot... I'd stick to C only until Rust matures.
@@ehtrude I would not mix languages at all. Rust freaks have their own kernel they can tinker with.
Yep, it's a cancer.
Then why won't you write your own kernel in C? 😂
Making fun of people making this argument for removing rust. Rust is here to stay.
@@RomanAvdeevX rust devs already have a kernel, redox, they should contribute to that instead of planting tumors in linux.
Rust is the future of the kernel, that's clear. C would work perfectly if everyone was a perfect developer, but they aren't and we're seeing the quality of developers drop with younger generations, especially Gen Z that aren't as technically competent as Gen X and Millennials. Rust essentially provides the safety wheels by being more verbose and having an aggressive compiler that checks everything.
It's necessary to make Rust the core of the kernel because we simply are losing all the good developers to age and we can't expect the new young developers to be as good so we have to rely on Rust to essentially force them to write good code (against their will).
Language is just a tool, if new developers are bad at it, you still have a huge problem, worse than the choice of language ... Besides that, Rust doesn't enforce good code, you can do really shitty on it also ...
replacing the old, efficient language because people are getting worse at the job would imply that the way we do things currently is broken.
beyond the above, dear virtue signalers: climate change.
So let's use Rust so bad developers can contribute to the kernel. Your reasoning sounds like a threat.