A choice pull quote: "The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only 'about a year away' from disallowing new drivers written in C and requiring the use of Rust."
I always assumed kernel-level decisions weren't really influenced by whatever Debain, or any single distro in particular, were doing.
Does this happen more often, or am i just misunderstanding this?
I think this might be that out of all "common" distros, Debian is the one who ships the oldest Rust version.
So this is not the kernel aligning itself on Debian, but the kernel aligning itself by trying to support all distros, with Debian being the "hardest" to please, with the oldest Rust version.
What about RHEL? It releases every 3-5 years so it would be older than Debian which releases every 2 years, Suse enterprise is even longer.
Do these commercial distributions ship bleeding edge kernels? I was under impression that after initial release they generally ship only patch releases (incl. backports) without major release upgrades, so in theory they wouldn't need the latest version of the toolchain
Commercial vendors don't need help here, if they need it they can maintain it themselves. It's going to be a while before mission critical stuff is entirely dependent on Rust kernel features. Will probably only be in the scope of CentOS SIGs and EPEL SIGs for now.
I think RHEL also has looser rules surrounding updating to newer versions of build tooling and runtimes (they market this as "CodeReady Linux Builder"), but I'm not entirely sure how this applies to Rust compilers.
Of RHEL need they may go and port the newest rust, they have done similar for other programs so is not something New
RHEL already updates rust as part of its minor releases. It won't be the absolute latest version, but it does move forward regularly. RHEL 9.7 and 10.1 both ship rust 1.88, which was released upstream earlier this year. I would describe it as laggy rolling release model, not for the whole distro but just that package and a few others such as golang.
Sounds like a sensible choice. Virtually everyone targets Debian (and Ubuntu) for support.
sorry for not including anything about rust discourse btw please don't ban me
There was no need to beg for validation here tbh
Kernel-level decisions are often influenced by Fedora because that's what Linus personally uses.
Unlike C and C++ Rust doesn't have defined standard like ANSI C, C99, C++11 etc. so kernel developers are using Debian Stable rustc version as "standard" to define what features are allowed in Linux Rust code.
It's not that. The kernel team mostly care about the version of GCC more than the C ISO version and they're more than happy to use GCC only features. Not that they deliberately pick up features that break other compilers.
Linux kernel is still using C11 (or rather GNU11) standard. They don't really care about default standard in GCC.
Waiting for a full rewrite of SystemD in Rust
It’s kinda crazy to think about but C code will one day be the equivalent of today’s PERL or COBOL
It’s cool to see how the Linux kernel is doing a gradual, in place evolution to keep up with changing times and improvements
It won’t be the same because, at this point, C has practically become a protocol different OSes and languages use to talk to each other.
Paradoxically, this is one of the main reasons C does not "get fixed". Think about it as English. The English orthography is really awkward but, because it has become the world’s lingua franca, it would not be worth making a huge change to it now. It is too late.
At least we have /r/JuropijanSpeling.
Except rust can mimick the C ABI, so there's that.
Yes and, apparently, they are even trying to write libc in Rust (which is kind of ironic).
That basically confirms the concept of "C as a protocol" I referred to in my previous comment.
Your username made me think that, maybe, C++ is more threatened by Rust than C is.
I always equate it as Rust being a C++ replacement. And Zig attempting to replace C.
In what way do you think Rust cannot replace C? Why then would the Linux kernel work toward moving all new driver development from C to Rust? The only thing that comes to mind is handling of fallible allocations, which Rust has some support for in things like Vec, but not other types of allocations. So even in extremely constrained embedded environments, there is typically a way you can make heap allocations work, but most of those codebases stick to only using the stack anyway. I guess the other two things that come to mind are binary sizes (which can be mitigated if needed), and very obscure platform support. So I guess I'm not convinced that Zig is a better C replacement. I would choose Rust over C 100% of the time. Zig is a nice evolution over C. But it's a far cry from what Rust brings to the table.
I would say, perhaps, that Zig's comptime is nicer than Rust's equivalents.
Now, about niche/obscure platforms, C is the closest one has of an "universal" language (because it is so simple and for historical reasons) and it will likely remain on top.
My point is, C the language, could die tomorrow and everything could still use the C ABI for FFI. You don't need a C compiler for that.
The C calling convention, which these days usually means 'cdecl' on x86? Every architecture is different so it's not really specific to C, but more of a hardware implementation detail. If all the C headers mysteriously go missing one day, nothing is going to work unless they're ported over to another language first. C headers are packed full of code that requires a C preprocessor implementation, so if you use these headers you are still implementing part of the C language. If in this hypothetical scenario portions of the C language and C files are still required, the language is maybe dying, but not dead.
This may be true when calling into C from another language. But I was specifically talking about calling from a non-C lang to another non-C lang. The ABI is the interesting part in this scenario. Not complex C headers with preprocessor needs.
C has no ABI except "what the C compiler happens to do". This is often documented these days, but it is a property of the specific platform and specific compiler. A different compiler on the same platform may use a different ABI.
who is "they"? There a lot of "they"s in linux/open source with different goals.
Redox, which is an OS written in rust is one of the "they"s, but it's probably different than the "they" you're talking about.
It's also not ironic at all if you care about compatibility with existing code.
I keep thinking of C as essentially Programmer Latin. We all know it well enough to read it, but few of us actually use it regularly anymore. C++ is the vulgar Latin that hasn’t quite abandoned mutual intelligibility yet, but it’s getting harder to read across projects.
There is nothing to "fix" in C. The danger has always been the programmer.
Edit: For the people downvoting me, show me a “broken” feature of C that does not originate from a programmer error.
You can say that about any language that exists and where the compiler doesn't have obvious bugs. Look at the JS situation, what's wrong with JS (the language, not the ecosystem) that does not originate from programmer error? You can write perfectly good bug free JS. The problem with C is that for all that's good about it, it lacks features that make making mistakes harder for the programmer.
Obviously what they meant is that you can't really change C to add those features (like borrow checking for pointers) without breaking existing things. That's why you need a whole new language with complex strong typing, borrow checking, bounds checking etc
I understand their analogy. Programming languages build on each other but Rust or any other language does not offer “fixes” for C - it is completely different philosophy on the language itself. Just like English does not “fix” German.
People sometimes try to do too much with C , emulating OOP for example, or other concepts that naturally fall better in “higher level” languages. It’s great that Rust is being taken off “experimental” status and that new graphics drivers will be forced to use Rust. Maybe one day C will get a deprecated status and all future features of the kernel are in a new language.
Be right back then, just need to learn how to write error-free code. That should take what, seventy two hours?
wait, perl isn't cool and modern anymore?
Please could anyone point me in the right direction to understand why there is so much pushing and effort to use Rust instead of C for the development of Linux?
This is a honest question, I'd like to understand all this talk abot "Rust good, C bad*.
I read the whole article to try and understand the advantages of replacing everything with Rust.. and there was not a single bit of information on that.
I only read words and comments of people praising and celebrating each other that "Rust is taking over" almost like a cult following and not tech article.
So again, honest question, what are the practical benefits? And why is it bad to continue using C?
You might see "Keynote: Rust in the Linux Kernel, Why?" - Greg Kroah-Hartman -- https://www.youtube.com/watch?v=HX0GH-YJbGw&embeds_referring_euri=https%3A%2F%2Fwww.reddit.com%2F&embeds_referring_origin=https%3A%2F%2Fwww.reddit.com&source_ve_path=Mjg2NjY
Rust doesn't suffer from many of the pathologies of C code. First, it guarantees spacial and temporal memory safety in safe code. It's also strongly typed. These types make it easier to build little state machines, which make it easier to reason about program correctness.
Thank you for the short explanation, makes things a bit clearer. Also I'll watch the video.
EDIT: watched it; so all in all roughly speaking, looks like it is almost like using C but with a few tweaks to prevent easy misses on logic flow (I think). Seems interesting.
It doesn't protect from logic errors, but from clumsiness about memory allocation. Therefore it eliminates a total category of bugs / attack surface.
Rust doesn't prevent logic errors but when compared to C it's type system being more powerful means you can encode invariants inside it preventing whole classes of logic errors. And that's what that video being referenced talks about and what they mean when they said "prevent easy misses on logic flow".
Right. But as Greg explains in his talk, Rust also allows to define APIs in a richer way than C at the type level. So, it doesn't prevent logic bugs "out of the box", but it gives library authors the tools they need to prevent their users from making logic bugs. Which is pretty damn valuable too. Especially for kernel subsystem maintainers who have to review drivers using their API. If they know: "This API cannot be abused in ways X, Y and Z, because I designed it that way", then maintainers will have to spend less time checking these drivers for logic bugs that would've been common for the C version of the subsystem's API.
Pretty little locking state-machines that will cause massive problems in synchronization.
Would you care to more fully explain?
He thinks the kernel is going to be using
async.As I understand it the reasons are that due to the way the Rust compiler and language work, it simply does not allow simple errors that can cause bugs and headaches if not caught and that C is allowed to compile with. Hence some of the maintainers have decided that it's better to program in Rust as while the adoption will cause issues, later down the line there shouldn't need to be as much bug squashing over simple one line errors.
Linus himself looks at things from an entirely pragmatic viewpoint, he doesn't even have any issues with AI use as long as the code gets vetted. Rust produced good code, the experiment showed good results, his lieutenants believe they can work with it, so he went ahead. He doesn't use social media, so he doesn't actually follow social media impressions of rust.
"Rust good, C bad*" is defintely too much social media on your part. Don't mistake social media bs as a kernel issue. As with most things, it's just a small vocal minority that are way too loud.
Rust dev here. Rust's compiler and memory model nearly eliminates a large number vulnerabilities that are common in other low level languages. Use after free or off by one errors, for example, are almost impossible in Rust. The language does offer an escape hatch (the much misunderstood `unsafe` keyword) to work in contexts where such grantees are counterproductive, such as in code that interacts with hardware registers; but otherwise it is difficult to write code that contains memory violations with Rust.
The language's type system is also very powerful and allows you to express strong type contracts. Its quite common in Rust to define types that make undefined state impossible, creating strong interfaces that are difficult to use wrong.
The language has almost no undefined behavior in its public API which gives you strong guarantees that if your code compiles its probably "correct". Correct in that it will run and not crash, not in the sense that its free of logic bugs; that's still on the programmer (see the recent Crowdflare kerfuffle).
I thought Rust had no undefined behaviour at all, could you give an example?
There is currently still a compiler bug that allows some very pathological code to compile and trigger undefined behavior. It should be quite unlikely to run into it unless you are doing so deliberately.
A compiler bug cannot be undefined behaviour. Undefined behaviour is when the language spec defines the behaviour of some code to be undefined.
Yes, for example, it is considered UB in Rust to have more than one active mutable reference to the same memory at the same time. This compiler bug allows you to do that in safe rust.
So here you need to distinguish between Safe Rust and Unsafe Rust. Safe Rust, by design has no UB; so no matter what what code you write in Safe Rust, it will never itself be the cause of UB*. Note that this does not mean that a bug in a piece of Safe Rust could not lead to Unsafe code creating UB if that Unsafe code depends on the Safe code not being buggy.
* The compiler does currently have at least one bug that allows you to cause UB from Safe Rust, but that is a bug in the implementation not the language design, and it, and any others, have been and will be fixed.
Unsafe Rust, on the other hand, absolutely has UB. This means that when writing Unsafe Rust, you do have to take extra care to avoid it. Complicating that is the interface with Safe Rust. When writing code that has both Safe and Unsafe Rust, you need to make sure that you don't violate any invariants that Safe Rust depends upon, such as the restrictions that references have.
It's also worth noting that what Rust considers valid is not the same as what C considers valid. There are things you can do in Unsafe Rust that are 100% defined, but doing it in C would be UB, and vice-versa. A simple example would be that, for any arbitrary
TandU, it's perfectly valid in Rust for a*Tand a*Uto alias, while C's TBAA means this is UB.Ok, thanks, but I still want an example of UB in Unsafe Rust.
Well, pointers aren't checked and can have use-after-free and out-of-bounds reads and writes. Reading uninitialised memory is UB.
Ah, yes, of course, that should have been obvious, sorry to bother you.
This would mean that the unsafe code is considered unsound though, i.e. incorrect. Correct/sound unsafe code may not allow (even incorrect) safe code to cause undefined behavior.
No, that is not necessarily true. If a safe function has a bug in its implementation, such that it fails to fulfil it's side of the contract, and the unsafe code is written to assume that the safe function is fulfilling its contract (because what else could it do?), then even if the unsafe code is written perfectly, you'll still get UB. The source of the UB can be traced to the unsafe block, but the ultimate source of the bug is incorrectly written safe code.
I'm actually thinking of a specific example that I can't remember where from. They were implementing something along the lines of an Rc, and had some UB. What ended up being the cause of the problem was that a safe function which was supposed to calculate the offset into a field of a struct was not doing so correctly for over-aligned data. The result was that calculated pointer was pointing into padding bytes instead of the data.
When you are writing unsafe code, you cannot just consider the unsafe block. You have to also consider the safe code that is touching or calculating data which that unsafe block depends upon for correctness.
The issue I had with the statement
was that someone might read it and think "What's the point of safe Rust if I still have to be careful to avoid UB?". I suppose a more precise way to state it would be:
If you are writing unsafe code, you have to make sure the safe code touching it is also correct (and you should minimize the amount of (safe and unsafe) code you need to check by building minimal safe abstractions). If you are using someone else's safe function that contains unsafe code, you cannot cause UB unless their code is unsound.
The reference has this to say:
I guess the way this should be read is exactly what I wrote above, but I think the wording could be improved. For a situation like the one you describe:
It is obvious that the unsafe block relies on the safe calculation of i to be correct and can cause UB if it is not. A really pedantic (arguably incorrect) reading of the reference would suggest that this is unsound, but as you note, there is no other way to write this unsafe block, it cannot do anything but assume that i is in bounds (that is the whole point after all). One might be tempted to move the calculation of i into the unsafe block to satisfy the reference's definition of soundness, but that seems worse.
Ironically, when talking about the kernel, particularly when talking about drivers, there are a lot of cases as I understand it where, because you're interfacing with hardware, you have to bypass/disable some of the protections iirc, but I don't remember the details
True, but this can be reduced to an incredibly shallow wrapper. See for example the Rust Embedded tutorial. Rather than passing around raw pointer which can blow up in your face at any time, you define the smallest interface possible to do raw access, and expose it securely to the rest of your code base.
There are two main benefits.
First, Rust is the only memory-safe systems language without performance cost. That means removing a class of memory bugs. That's a real tangible benefit seen in many projects by many companies.
Second, and IMO more important, reason is that it's a more modern programming language and has adoption from next generation. There is a concern that if new programmers don't learn C, over time the contribution to Linux goes down. Having a more modern language helps bring new blood.
Edit: Added clarity on first point.
The first point is wrong, most languages with a gc that doesn’t let you manipulate pointers directly, like java, is memory safe , the main difference with rust is that it uses rules about how variables can be used in a program, so a gc at runtime is unnecessary (and therefore more performant)
They said “systems language”. No sane programmer would count Java in that category.
I don't think of Java as a systems language. But have added clarification on the first point.
Java running in a JVM absolutely has gigantic performance costs compared to the same code in C
I’m aware, I’m by no means telling you to go write a kernel in java lol
I know, just telling you the first point isn't moot since that's what they said.
I think this is one of the best explanations I've seen, from someone who wrote a bunch of Rust code in the Linux kernel:
https://vt.social/@lina/113056457969145576
It's OK if you don't understand all of the terminology used in this explanation. What you should take away is that there are a bunch of things you would need to know in order to write safe kernel code, which aren't obvious in C. Rust has inherent safety advantages, in which the compiler will guarantee that some types of operations will be safe, but the language also provides more information about the correct way to use APIs.
The biggest reason is simple: The kernel developers want to. The "push" for Rust is coming from long-term and well established kernel developers, including Greg KH and Linus Torvalds himself.
The kernel developers behind it see it as a useful tool to improve the kernel and especially the subsystems they control.
This article doesnt go into the why much because Rust has been in the kernel for years at this point, the "why" has been answered in many articles at LWN, on the mailing list, in talks at conferences, all kinds of places over the years. Its kind of an answered question at this point.
Think of it like this:
C is like doing your spreadsheet by hand. Pen and paper. A skilled enough accountant can do it, but if there is a mistake it's a pain to find where the mistake slipped in, and you might need to redo half the work.
Rust is kind of like doing your spreadsheets in a program like LibreOffice Calc or Microsoft Excel. Lots of stuff happen automatically for you, and you can add more safety to a spreadsheet template in case the user makes a common mistake.
In practical terms, it means that many of the things you can write in C which will happily build and only crash and burn (or worse, cause a security issue) will be rejected by the Rust language at build time.
One way people like to put it is that things that are best practices in C become language enforced in Rust. This makes it harder to accidentally write bad code. The compiler can check that these best practices are followed all over the place, rather than forcing the human to think about them and enforce them.
This is a very poor comparison between C and Rust. Rust is like writing C with a really strict code reviewer and an improved version of code gen.
Your example would be more akin to python, which is basically just doing magic as far as the user is concerned. That is not rust.
Making Rust out to be a simplified tool is disingenuous. And it doesn't fully solve all memory classes of issues, there are plenty of ways Rust code can have major issues just like C. Please direct your attention to the latest global outages.
I have said it a lot, but Rust has a number of other issues as a language that make it difficult for me to see it as a true replacement to C. Performant Rust is harder to write than performant C. Not impossible, and with sufficient
unsafeyou can actually do better in some cases, but at that point the touted benefits of Rust are largely gone.I don't follow. How is doing a spreadsheet in a spreadsheet program using a "simplified tool"? You can do exactly the same thing as you would when doing the spreadsheet by hand.
There's some inconsistency here. Are you talking about "memory classes of issues" or "major issues"? Those are pretty different things!
The Cloudflare outage had nothing to do with the type of memory safety issues Rust aims to protect against.
Performance between the two languages is definitely not reducible to such a blanket statement. It's very much a case-dependent analysis, and even then I think you need to also consider that one of Rust's goals is to make it easier to write correct code that performs well (i.e., is performance correct Rust easier or harder to write than performant correct C?). For example:
iter()topar_iter()and be reasonably sure things will work as expected.There's a huge gap between using enough
unsafefor good performance and using so muchunsafethat you get little to no benefit from the rest of Rust, and if anything I'd imagine most codebases would never reach the latter point. For example, consider that low-level/high-performance codebases that are most likely to needunsafestill manage to keep their usage relatively low (IIRC RedoxOS is <= ~10% unsafe, Oxide Computing's Hubris kernel was ~3% unsafe, Asahi Linux's Rust GPU driver was ~1% unsafe last time I looked, etc.).Of course, that doesn't mean that such codebases can't exist, but I think that such codebases might be rarer than you would expect.
No inconsistency, meaning the same thing there.
Cloudflare issue was an unhanded unwrap of bad data, basically an uncaught null dereference.
Performance, talking about how Rust will push you to deep copy rather than references. It also tends to push for more boilerplate where it is logically not needed. Arguably you could redesign code paths for those, but that becomes burdensome fast. By no means am I making broad claims, I am not being exhaustive here on my gripes so, and talking about performance is never black and white.
And like I say, Rust has good things. Struct data alignment and thread safety are two places that Rust helps a lot, since you seem to need to hear me compliment something specific.
OK, in that case would you mind explaining more about what you mean by "memory classes of issues"? Is that distinct from "memory safety issues"?
I think it's more akin to an assert/guard clause that fired in production, but either way it was not the kind of memory safety issue Rust promises to protect against.
Does it? If anything, I've tended to hear the opposite since Rust's mutable xor shared semantics lets you avoid making defensive copies to ensure stuff doesn't get mutated out from under you.
...Maybe? Depends on what you have in mind, I guess.
I'm not looking for compliments. I'm looking for nuance! For example, chances are I wouldn't have said much (if anything) if you had sad "Performant Rust can be harder to write than performant C", because that is true!
That isn't a Rust issue though. You should never ever use unwrap() in production. unwrap() is used during development to save time. Like when you prototype, you don't want to waste time handling all the errors, so unwrap() is a lazy way to write a happy path.
Once everything is working, you search unwrap() and fix them all up. There is a clippy option to error out on use of unwrap() at compile time, and proper CI should use that option for production.
Cloudflare's real problem was development code making it into production because they didn't add that lint to CI.
Rust itself handles the issue, but using unwrap() is the developer intentionally silencing it. Rust has guard rails, but it also lets you go around those guard rails if you choose to at your own risk.
So....it is full of foot guns, the truth comes out!
Sure, but the footgun has a safety lock, labels and clear instructions.
Compared to C which is like an automatic gun which constantly fires with the trigger jammed on always on.
Rust doesn't stop you from shooting yourself in the foot (otherwise you wouldn't ever be able to program a serious program with it). But it does insure best practices by default and goes a long way to stop you from doing so. But the option is always there if you choose to.
And when you choose to, clear labels are used that anyone can instantly know that there is a foot being shot in keywords such as "unsafe" or "unwrap".
Obvious?;
The type system of rust is based on affine logic , which disallows using a variable more than once (outside of a variable using the copy trait). This disallows several classes of memory management problems statically, rather than with a gc and runtime like other memory safe languages.
Yes currently it is the cult. Second thing now is some kind of errors are prevented in some code. Third thing is new people coming to develop kernel.
It started by Linus in other order actually, new people was at first place and he picked rust just because there was no alternatives at all at that time.
Talking about communities, today more and more people started hating rust community (not language itself) but because they mostly don't need this language, people started cancelling rust as something bad by default. It was a response to rust cult that was jumping around everywhere screaming "you don't understaaaand" at anything. And unfortunately people are spreading this cult because rust adopters abuse rating systems everywhere and normal people having real jobs to do, don't have time to deal with online wars.
you say that while the second in command of the linux kernel did an entire presentation on why rust was good.
Well you can watch Linus talk first mentioning rust in kernel to know about it. It's actually pretty understandable decision.
I don't need to watch linus talk. I've already seen his thoughts on it via LKML posts
Rust has a few major advantages, first most talked about is the improved memory safety, but there are others as well. Things like forced error handling and fearless refactoring.
Rust won't make a bad programmer into a good one, but it will make a bad programmer less bad and a good programmer better. It ensures a minimum quality of the code.
The fearless refactoring also makes it easier for new developers to contribute and developers in general to make major changes.
This not only gives you better quality code but also reduces significant load on the maintainers. Someone can create AI slop and submit it and maintainer would have to waste his time figuring it out because C would compile it but it would result in weird errors here and there. Rust stops most issues at the compiler phase so the maintainer doesn't even have to bother looking at it as it would fail CI
That's fucking insane, actually.
Now it's good time to re-read all kernel discussions about cross-language complexity concerns
Of course there are those concerns, but that is why everything should stick to C. The kernel is never going to be pure Rust, so there will always be cross-language issues as long as Rust is in there. Trying to force everyone to switch to Rust is not going to solve the problem, but most likely just make it worse. There are tons of existing DRM drivers written in C that are not going to get magically ported (and I hope nobody is going to try to rush to replace them with a half-baked port or rewrite with tons of regressions). What we will see if this ban is enforced is lots of out-of-tree C drivers that will not get merged just because one person with too much power does not like C.
Exactly, this is my point
When Rust was blocked and some group was upset because of it(to the point of even trying to apply social pressure on the technical project!), and considered as "unfair", that spawned a lot of discussions and now they are cheering for the exact same thing but situation mirrored. Not like it was surprising though.
It's the obvious next step.
Most bugs are introduced in newly-written code, so by switching to Rust for new code you stop the inflow of new memory safety bugs. Rewriting the old C code has far less benefits: the older the code, the more bugs have already been eliminated, so the more likely it is to be correct.
This is directly visible in Android: the drop in the number of memory safety vulnerabilities goes hand-in-hand with the drop in the number of new memory-unsafe code. Combine that with Rust being significantly faster to code and review, and it becomes incredibly difficult to justify sticking to C for brand-new drivers.
Always the same propaganda google article that from a worker that need conserve the work in google.
Agreed, this really made me go "WTF", too! They have always argued that Rust would only be an option, not mandatory, and now we have a subsystem maintainer who wants to make it mandatory for his subsystem in "only about a year"!
Note that this guy is also one of the Xorg maintainers who have decided to permafreeze Xorg and force all users to switch to Wayland. Now he wants to force all developers to switch to Rust. This totalitarian attitude is really toxic.
As long as a can compile a working kernel without the Rust toolchain present I don’t care
Yes, but the point is that it will be less and less likely that you will be able to compile a working kernel for your hardware without Rust as more and more hardware drivers will be written in Rust.
FreeBSD it is then
According to https://wiki.freebsd.org/Graphics they also ship ports of the Linux kernel DRM/KMS drivers, so will be affected too.
You will likely be stuck with a VESA framebuffer, if modern graphics hardware even keeps supporting that ancient legacy standard.
Simple FB is not that bad tbh
Having significant parts of the kernel written in Rust is going to be the end of Linux.
What is the base of your claim?
Hmm, why?
Because Rust bad. /s
All I see Rust doing in the long term is making kernel development more accessible and maintainable
How so? Rust is much more complex and harder to learn than C!
If you know proper C, you know rust. Rust just formalizes most of the concepts that you just have to keep in your head or (if you’re lucky) in comments, and adds compiler safeguards to enforce them. Those safeguards mean you can, in code, see exactly what the constraints of an interface are without needing to know all the inner workings. See the work on expressing the Linux filesystem code in idiomatic Rust
The borrow checker simply has no equivalent in C, and not all software architectures that work and are perfectly valid and safe in C are accepted by the borrow checker.
Also, the syntax of Rust is completely different from the C syntax, so that alone means you have to learn a whole new language.
So what will be the successor of Linux?
Linux 2 aka Twinux
Better yet, Twinkus ;)
What is the programmer socks pattern that will be required for contributing? Gotta ask Santa for a pair!
Pink / purple zebra pattern.
Do you have anything to back that claim up?
Written by someone who has no impact on the development of the kernel with no supporting evidence.
Why? What important arch isn't supported by Rust?
What do you mean by that? A lot of Linux users need to run modern Linux on 30 years old SPARC hardware. /s
Yeah it's not being handled correctly. It seems they are pushing for new DRM drivers to completely abandon C, so this is a defacto push to force every OS that includes DRM code (FreeBSD, haiku, probably others) to also force adoption of rust, or lose support for graphics on newer hardware.
So they are left with the choice to either rewrite their GPU code or fork DRM, making linux less important outside of the corporate sphere of microsoft/google, or force the addition of an unstable language into their code base pushed by the worst actors (literally monopolies enshittifying their competition) in the tech industry.
They are other OS using Linux DRM code?
Yeah basically any non-windows and non-mac OS that supports GPU/hardware acceleration on modern graphics cards. so FreeBSD https://wiki.freebsd.org/Graphics, OpenBSD, NetBSD, probably other BSD's, Haiku, must be more I'm unaware of.
Interesting, I was not aware. Isn't there any license compatibly issue ?
It depends on the files being used, a good number of them are either dual licensed or permissive licensed (when not being used in the context of a linux kernel), but some are GPL-only. to dig deeper untar linux source, cd drivers/gpu/drm and run
grep -ri 'gpl'Indeed, there is a lot of MIT files in DRM, even more than GPL. Seems it's limited to DRM, there are almost no other MIT licensed files in `drivers/`.
Some BSD in `drivers/acpi` and `drivers/net` also.
To people downvoting, what part of this statement do you think is not relevant? Other OS's depend on the DRM subsystem and they won't be able to continue that without adding rust-subsystem-for-linux that was initiated and perpetuated by google and microsoft to their kernels. I'm reminded this week how this subreddit was always not as informed as they pretend to be.
I didn't down vote but the fact that other OSes depend on the Linux DRM subsystem is not a Linux problem. Linux developers care only about Linux, so they won't care about BSD or Haiku when they are making decisions.
Ok thanks but I don't mind if someone downvotes me or not, I just want to rationalize why there are conflicting vote numbers. There are people here asking "why" with like 50 upvotes, so it seems like they are interested in an explaination of why people might not like this new anti-C posture from the linux kernel developers. At the same time they downvote the only person not afraid or willing to speak up with non-fictional information.
So I'll just tell myself these people are probably fine with linux devs receiving less free testing and bug reports from others downstream of linux-DRM, and don't care if nobody else uses the new drivers outside of google android devices, or one of the (what are we up to now) 3 open source nvidia drivers barely anyone uses. Either they refuse to believe such a C-phobic proclaimation has far reaching impacts on the broader FOSS ecosystem (competition of big linux donors), or they legitimately don't want other projects to use linux code, effectively reducing linux's relevance outside of the rusty bubble.
tl;dr: If anyone reading this is genuinely confused still, Declaring a rule prohibiting new C drivers in the linux kernel is either batfish crazy, or intentionally hostile. Both possibilities will destroy the FOSS allegience that has been mutually beneficial for so long.
There aren't enough BSD and Haiku users to make any difference for Linux DRM subsystem. Linux developers don't need to care about Linux relevance outside their bubble because their bubble has almost all open source operating systems market share. It's like saying that not allowing some game to run on Proton will be bad for Windows players because developers won't get feedback from Linux players - yeah, they won't but that doesn't matter if almost 100% players are using Windows.
It doesn't have to be a lot of users, simply bolting it in to another project exposes it to different usage patterns and helps to expose bugs sooner than later.
The king doesn't want to share his toys anymore, this is bad for the allegience.
Again there is not enough BSD and Haiku users to make any difference for Linux.
License didn't change, BSD and Haiku developers are still free to take it. The fact that Rust makes it more difficult for them is not Linux developers problem.
None of it is relevant. You think you're informed but you're not. It's the same kind of nonsense you see from Phoronix posters who know far less than they think they do.
Rust is a net benefit for OS dev, linux and cs as a whole. Touch grass.
But your comment is no different from the parent. "Me right, you wrong." Just explain your points people, ffs.
All of those things are true, but none of them are relevant to Linux. Linux developers aren't Haiku or BSD devs, nor are they beholden to making their code easy to port to other kernels. The onus is on them to figure it out.
Why should Linux devs be beholden to making code that's easy to port to OS's they don't develop?
Allowing easy reuse of the code is part of what Free Software is supposed to be about.
This is tinfoil hat bullshit! None of this is true. Seems like you don't understand most things. For one, smart TV's run linux....like a lot of other stuff that needs to be able to decode DRM media if we ever want general adoption. You can't just not have it. People will stay on windows if no one is able to maintain it. Rust is good. I don't know why it gets so much hate.
This is about DRM as in Direct Rendering Manager (Linux GPU subsystem), not as in Digital Rights Management.
From his comment, lol