Linus Torvalds Would Reportedly Merge Rust Kernel Code Over Maintainer Objections (phoronix.com) 120
Christoph Hellwig continues to voice strong opposition to Rust in the Linux kernel, arguing that its introduction creates fragmentation, unclear language guidelines, and additional burdens on maintainers. He also says Linus Torvalds has privately stated he will override objections to Rust code, effectively making its adoption inevitable. Phoronix's Michael Larabel has the latest: The latest on Hellwig's perspective of Rust code within the Linux kernel is below. Some interesting insight from a dissenting view. The thread in full can be found on the Rust for Linux mailing list.
[Here's an excerpt from the thread:] "I don't think having a web page in any form is useful. If you want it to be valid it has to be in the kernel tree and widely agreed on. It also states factually incorrect information. E.g. 'Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected.' while Linus in private said that he absolutely is going to merge Rust code over a maintainers objection. (He did so in private in case you are looking for a reference). So as of now, as a Linux developer or maintainer you must deal with Rust if you want to or not. [...] Right now the rules is Linus can force you whatever he wants (it's his project obviously) and I think he needs to spell that out including the expectations for contributors very clearly."
[Here's an excerpt from the thread:] "I don't think having a web page in any form is useful. If you want it to be valid it has to be in the kernel tree and widely agreed on. It also states factually incorrect information. E.g. 'Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected.' while Linus in private said that he absolutely is going to merge Rust code over a maintainers objection. (He did so in private in case you are looking for a reference). So as of now, as a Linux developer or maintainer you must deal with Rust if you want to or not. [...] Right now the rules is Linus can force you whatever he wants (it's his project obviously) and I think he needs to spell that out including the expectations for contributors very clearly."
It's free software (Score:5, Insightful)
Anyone who is that opposed to Rust code in Linux is free to maintain their own Rust-free fork.
Re:It's free software (Score:5, Insightful)
And anyone that doesn't want to work on it at all anymore is free to do that too.
I foresee maintainers quitting if *forced* to integrate rust over their objections.
Re: (Score:1, Troll)
Re:It's free software (Score:5, Interesting)
I don't. Well, maybe one or two so technically correct (there are a lot of maintainers), but in practice I really don't think that many maintainers (1) care in the first place, and of the remainder (2) I doubt most side will Hellwig on this.
The Rust people have been careful to keep their code separate, to avoid requiring any action by maintainers of C code to keep their's working (to the extent a maintainer of C code can make a change that breaks a Rust interface, and the Rust people have to fix their own code), and they're providing a long needed upgrade to the over all maintainability of the kernel.
Re:It's free software (Score:4, Insightful)
I believe most kernel developers would recognize how many kernel bugs have been introduced because of their choice of language - C. These are the best C programmers in the world probably and yet their code still suffers from buffer overflows, double frees, ownership issues etc.
So that is basically why Rust is generating interest - it is a compiled language and it links with C quite easily. It's also a more modern language than C, the compiler is very strict but helpful, the language is terse, it doesn't require code be split into headers / sources, it has inline markdown documentation, inline tests, and it is safe by default. Safe by default means that any nasty, volatile code can be encapsulated in helper functions where the unsafe portion is called and the surrounding code which is safe by default benefits from additional compile time checks. In addition since its a modern language, better patterns can be supported, e.g. streaming IO through lambdas rather than exposing buffers to functions and so on.
I do think some of the objections are valid. Rust is self describing for example. It would be good to separate the language from the implementation. I also expect that many kernel devs just find it intimidating as a thing because they're so used to C, particularly GNU C with a bunch of extensions. But I think the fundamentals of Rust aren't that far removed from C - it's a C like syntax and compiles into .o files but I imagine a lot of the concepts of the language / std library on top and the strictness of the compiler are things that some people would need to adjust to.
Re:It's free software (Score:5, Funny)
And anyone that doesn't want to work on it at all anymore is free to do that too.
I foresee maintainers quitting if *forced* to integrate rust over their objections.
*FreeBSD watches from the shadows*
"There's been an awakening. Have you felt it?"
Re:It's free software (Score:5, Interesting)
If you've followed the story, they person opposing this was not *forced* to integrate anything, as the code was not going inside his subtree.
Nevertheless, he was opposing in principle the existence of shared Rust DMA interfacing code. Instead, each Rust driver should use their own interfacing.
The maintainers can quit for whichever reason (or no reason at all), but if they do, in this case it's not probably a good reason.
Re: (Score:2)
However, as stated in the article, Linus has stated he *would* do so.
Re: It's free software (Score:1)
Re: (Score:2)
What if my architecture does not have the resources to build the rust toolchain?
Re: It's free software (Score:2)
What about cross-compiling the kernel, in that case?
I reckon that there are many platforms with insufficient resources to compile the kernel, and this has apparently not been an issue.
Re:It's free software (Score:5, Informative)
Then don't include it.
Rust is strictly optional. The kernel repo contains a "rust" directory, and the kernel is required to build without that code being included.
Re:It's free software (Score:4, Interesting)
Re: (Score:2)
I've never programmed rust, but, almost certainly.
I have programmed a lot of C over the years, and also a lot C++. C is an exercise in doing an awful lot of stuff by hand which can be done automatically by the compiler, be it C++ (deeply unfashionable for decades for some reason) or Rust (now fashionable).
Re: It's free software (Score:2)
Re: (Score:2)
Does he? Do you have a link?
Alternatively, maybe Linus is playing the good cop to calm down some immature people.
Re: (Score:1)
Re: It's free software (Score:4, Interesting)
Have you actually read the article
Yes. How about answering my question?
, and have you ever 'met' Linus?
No. Have you? I have 'met' him "virtually", through his writings.
if someone is immature, it's Linus.
This is so stupid that it doesn't even deserve a proper rebuttal. He is a d1ck, sorta, indeed. But immature? LMAO.
Re: (Score:2)
Rust will be merged into the kernel tree as a build option. Config that option off and the kernel is supposed to build exactly as before.
Re: (Score:2)
Rust is basically a front end on top of LLVM so it supports as many environment / architectures as LLVM does. If you're unsupported by LLVM then you have an issue, but Rust so far is used in driver modules that aren't relevant to non-mainstream architectures. I could see how scope creep could make it a problem though. But conversely it might motivate LLVM to support more architectures and eventually for the whole kernel to shift from gcc to clang. At that point clang and rustc are using the same backend so
Re: (Score:3)
My guess is that the GCC backend for Rust will be stable sooner than the kernel will shift to clang. Either route works.
Greg Kroah-Hartman (Score:5, Informative)
As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic.
The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)
I'm all for moving our C codebase toward making these types of problems impossible to hit, the work that Kees and Gustavo and others are doing here is wonderful and totally needed, we have 30 million lines of C code that isn't going anywhere any year soon. That's a worthy effort and is not going to stop and should not stop no matter what.
But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time.
Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to "ensure that you got this right" that is a combination of both how our apis have evolved over the years (how many different ways can you use a 'struct cdev' in a safe way?) and how C doesn't allow us to express apis in a way that makes them easier/safer to use. Forcing us maintainers of these apis to rethink them is a GOOD thing, as it is causing us to clean them up for EVERYONE, C users included already, making Linux better overall.
And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I'm willing to learn and work with the developers who have stepped up to help out here. To not want to learn and change based on new evidence (see my point about reading every kernel bug we have.)
Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that?
Linux is a tool that everyone else uses to solve their problems, and here we have developers that are saying "hey, our problem is that we want to write code for our hardware that just can't have all of these types of bugs automatically".
Why would we ignore that?
Re: (Score:2)
My very deep respect to Linus. (Score:1, Troll)
RIP Linux (Score:3, Funny)
The tone of your post sounds a bit like an obituary.
Re: (Score:1)
It's because the parent is incorrectly using the past-tense verb. Since Linus is still alive and still working on the kernel today, the correct phrasing is "He seems to have created an open source C operating system..."
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Disagree. "Seemed" implies it is a past achievement, while Linux is still a work in progress.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I am an asshole.
Not necessarily, but your English is a bit funny.
Re: My very deep respect to Linus. (Score:1)
He didn't invent version control software, but he surely contributed to it significantly with developing git.
Before git, there were RCS, CSV, subversion, and probably many other software that I don't recall. All of them were very centralized.
As none of them fully met the needs of a project like the Linux kernel which drove Linus to developing git.
Re: My very deep respect to Linus. (Score:4)
As I recall, git is influenced strongly by bitkeeper [wikipedia.org] which Linus admired greatly, and used initially.
However, bitkeeper was proprietary software. Linus wanted something that was free software to support the kernel development, so he created git.
Re: My very deep respect to Linus. (Score:5, Informative)
However, bitkeeper was proprietary software. Linus wanted something that was free software to support the kernel development, so he created git.
No, he created git because the creator of bitkeeper threw a tantrum and refused to let Linux devs use his product anymore (without paying).
Re: (Score:2)
Thanks for the improvement. Yes, that's all in the Wikipedia article I linked, so I have no excuse.
Re: (Score:2)
There were any number of fully distributed VCSs before git.
The kernel used bitkeeper, which originally had an "almost free" licence. I don't recall exactly what changed but the licence became untenable for Linus to accept.
DARCS and Monotone are the two in particular I recall from pre-git days. DARCS is still going, Monotone is dead.
I use git exclusively now but I do still wish that Linus had had a few more thoughts for use cases outside of his own when he wrote git. Things like etckeeper ought to be support
Re: (Score:2)
Linus cobbled together git to offer the same desirable attributes as bitkeeper (after a long running issue with the owner & repo) without the commercial aspects or being shut out of the history. It wasn't the first DVCS or even the first open source DVCS (e.g. monotone preceded it), but it was definitely the one that really caught on. I think it caught on because it was fast and lightweight and really leaned into fast branching & merging which were issues that plagued other source control systems.
Re: (Score:2)
none of them fully met the needs of a project like the Linux kernel
BitKeeper apparently did, though.
Re: My very deep respect to Linus. (Score:4, Insightful)
You forgot Visual Sourcesafe which was once the top tool for multi-user collaboration, and the envy of any and all coders.
I think you forgot the /sarcasm tag.
Visual Source Safe (VSS) is a horror that Microsoft bought from some other company, distributed as a product, and finally replaced with TFS which is marginally better. Even Microsoft didn't use VSS internally, although they sold it.
Other revision-control systems pre-date VSS that allowed multi-use collaboration. Not well, but they did support it. SCCS was one of the first. defago mentioned others.
Re: (Score:2)
Visual Sourcesafe was the solution to the question "how can I fuck with my work buddies?". And the answer was "lock some files in VSS and go on a long holiday".
Re: (Score:2)
He created a kernel, not an operating system.
Re: (Score:1)
Re: (Score:2)
Generally, the kernel is the very important part of the operating system that talks to hardware and manages memory and other resources. The operating system is a collection of tools and programs to actually do useful things on a computer, like run other programs. You can't use an operating system without a kernel and you can't use a kernel without an operating system.
Re: (Score:1)
Re: (Score:2)
> You can't use an operating system without a kernel and you can't use a kernel without an operating system.
Technically a kernel is considered part of an operating system. The term was practically invented by the designers of Unix who wanted to distinguish between the scheduler/filesystem/device driver component, and the shell and various utilities that ran over it.
Re: (Score:2)
You kind of can have a full operating system there is merely a kernel, a trivial loader, and one application (probably busybox). Even today you can buy an RTOS that is only a kernel.
I think definitions changed a lot over time. Early on one could have said that the kernel is the operating system and people would have accepted that. Say in 1975. Fast forward and Windows has DLL hell, and that hell is considered to be the "operating system" and people forget there's a kernel (or more precisely there wasn't
Re: (Score:2)
Nice summary. I'd add that you need a kernel to run other programs, but the kernel itself doesn't need other programs to function, at least in a running state.
Re: (Score:2)
Hello, RMS. We already know that.
Project success requirements (Score:3, Insightful)
Hey Linus, large successful projects need emotionally stable people at every level but especially in high level / key roles.
Have we seen that recently from the Rust community? Hasn't been a good look lately.
Maybe it was just those 2 guys and the rest of them are mature adults who don't write book length rant resignation letters or demand other devs be ejected from the project for using normal phrases that are now fotw triggers or ... maybe it wasn't just those 2. Time will tell but the recent noise and past activity from that community doesn't bode well for future likelihood of them behaving themselves and focusing on what counts: the kernel.
Re:Project success requirements (Score:5, Insightful)
large successful projects need emotionally stable people
Linux itself is a counterexample to this claim. Linux has had all manner of emotional basket cases and mental defectives involved, including a cold blooded murderer. At least one, anyhow.
Re: (Score:1)
Keep empowering the Rust folks. Time will tell.
My bet is this is not the last crazy outburst. Not by a long shot.
Re: (Score:1)
Dude. Get over Reisier. That was nearly 20 years ago. He was one of over 20,000 contributors.
So 1 in 20,000 which roughly matches the wider population. (about 1 in 22,000 people have done a murder)
Just because the drama sometimes rises to the top, as it does everywhere else , doesnt mean Linux development is top heavy with crazy.
Re: (Score:2)
Reiserfs was the first journaling filesystem included in Linux release versions. So while they guy turned out a nutcase in his social/family life, there's no question that he was a solid contributor to the kernel.
While the murder case is pretty extreme, there are plenty of cases where a person has been canceled from technical work due to social issues. I think it's a real shame and a waste of talent.
Re: (Score:2)
I'd argue it depends upon one's definition of success
if success is cheating and stealing from poor people than, yes, there are a lot of 'successful' people
large is not a measure of success, nor is profit when ethical considerations are taken into account
we have a lot of pseudo-success built upon economic exploitation and corruption
Re: (Score:1)
Re: (Score:3)
Did you read that first guy's novel length resignation letter? I actually did. I read every word even though it was super cringe.
Then the next guy -demands- that another developer be ejected from working on Linux because in some random discussion he used the phrase "thin blue line" and this guy lost his shit over that and went off at length about his personal emotional damage.
If you're ok with either of those things then there's nothing for us to discuss; we live in different universes.
Re: (Score:2)
Probably because he's a typical Internet German(TM). Remember, I just had to respond to a guy yesterday who was complaining about my post failing to be German Centric:
https://slashdot.org/comments.... [slashdot.org]
Similar to another Internet German(TM) named Angle Of Sphere who hates rust primarily because he doesn't understand anything that isn't sufficiently object oriented or made out of linked lists. Shit, just look at his website, he's still trapped in 1997.
Re: (Score:2)
Lol, ok, you're clearly closer to this than me, maybe I am wrong about it being a Rust problem. Maybe Linus should keep a closer eye on the Germans. :-)
I defer to your knowledge on this one. Either way, Germans or Rust :-) time will tell.
Re: (Score:2)
Maybe Linus should keep a closer eye on the Germans. :-)
I'd bet he already does, after having to deal with Mr. Lennart Poettering and especially Mr. Kay Sievers...
Re: (Score:1)
we live in different universes.
You live in the Trump Universe where illegal Haitians immigrants are eating all the cats and dogs. 99.99999% of the rest of us live in the other one.
Re: (Score:2)
Apparently you live in the la-la land where using the idiom "thin blue line" equals being a Trump-voting minority-oppressing swastika-wearing Nazi. Don't worry though, big pharma will probably create a pill for your disorder sooner or later, if Prozac won't help.
Re: (Score:2)
Did you read that first guy's novel length resignation letter?
Which guy and which letter? I thought Wedson was the first Rust maintainer to resign, but his resignation was anything but long.
Re:Project success requirements (Score:4, Interesting)
Maybe it was just those 2 guys and the rest of them are mature adults who don't write book length rant resignation letters or demand other devs be ejected from the project for using normal phrases that are now fotw triggers or
Those two in particular value politics more than code. Rust has nothing to do with that. Keep in mind as well, these two both had nothing to do with the the PR being reviewed, they were just adding their two cents unrelated to code at all.
However, I will say, Rust developers are used to dealing with people who only care about whether a bit of code is:
1) Sound
2) Practical
3) Solves a real problem
Hellwig doesn't care about any of that. The only thing that matters to him is NIMBY. That's it. Nothing else. He has literally made no argument other than just NIMBY.
Compare him to Linus Torvalds: Not even a Rust developer. Only cares about technical matters. A while back, he brushed off concerns that there weren't enough women contributing to the kernel. (Srsly, this is the kind of political shit that the media brings up.) In his view, technical superiority is far more important than NIMBY concerns. THAT is probably what's on his mind on this.
Re: (Score:3)
All fair. I'm not insisting the future will be how I predict. It is only a prediction but based on past performance there are good odds it goes that way.
As I said, we'll see. Linus should keep a serious eye on this. This sort of emotional nonsense is the kind of thing which kills projects. That's my only point here.
Re: (Score:3)
This sort of emotional nonsense is the kind of thing which kills projects.
Thankfully, damage from emotional instability is usually self-limiting. Affected people often rage quit, the rest continues ahead.
Re: (Score:2)
I think this is unfair. He has some reasonable points to make.
https://lore.kernel.org/rust-f... [kernel.org]
In the end, though, his language is intemperate and his argument boils down to that supporting two languages is more complicated than supporting one, and this is not worth the effort.
He might be right, but in the end, the project needs to make this decision as a whole.
Re: (Score:2)
Apparently it's OK and totally not a sign of instability when Hellwig spews this
Hellwig didn't rage quit. He is stable enough to do kernel development.
Linus himself had been spewing outright profanity in the past. Yet he was stable enough too.
it's not OK when someone points out it's crackpot quasi-fascistic nonsense.
If it was merely a pointing out, it would be okay, and nobody would make a big deal out of it. However, it was an angry demand for cancellation. For something that is not even universally understood as "quasi-fascistic nonsense".
Another dev, Dave Airlie, if I'm not mistaken, did the "pointing out" in a direct answer to Ted in the mailing list. And
Re: (Score:1, Insightful)
People that like Rust tend to be young. The young are usually early adopters and very often proponents of very bad ideas because they lack experience. Rust is one example.
Obviously the young are also in to the whole whatever you want to call it of social bad ideas. They're always like that until they gain more real world experience.
Java is a good example of something adopted by the young. It was and is stupid but gained too much momentum to be shut down so here we all are, eating shit.
I urge everyone to sea
Re: (Score:2)
We are here because Java fulfilled a niche that people really needed. It wasn't the one that Java was invented for, nor the one that they used to advertise it in the first place. Who would have thought that a technology for set-top boxes (which don't exist any more really) and the web would have ended up where it is.
Java has it's problems. But it is very widely used, the JVM is amazing piece of software. It is hard to support the argument that it is stupid.
Rust, well, it will take time to know. It does "run
Re: (Score:2)
Ugh why is this post modded up?
Dismissing languages as "stupid" is not a sign of maturity. Java is fine. Not personally my favourite language, especially as I last did it around Java 6 or so, but it's a solid, work-a-day language which gets stuff done just fine. It's unfashionable and used for stuff that won't win prizes for looks but works well, on any computer and just keeps working.
I urge everyone to search the CVE databases for Rust projects and look at how many security issues they have
So?
Rust doesn't
Re:Project success requirements (Score:5, Funny)
Hey Linus, large successful projects need emotionally stable people at every level but especially in high level / key roles.
If so, the USA is doomed.
Re: (Score:1)
Maybe so. The last time we elected an adult was 1980.
1980-1988 (Score:5, Informative)
Arguably it was 1976. Or have we already forgotten the October Surprise [wikipedia.org], recurring refrains of "I do not recall" in response to questions about Iran-Contra, Nancy relying on an astrologist [pbs.org] for advice that affected governmental decision-making, etc. etc.
Re: (Score:2)
I haven't forgotten any of it. You prefer Carter? The father of modern terrorism?
Explain. This ought to be good. [*grabs popcorn*]
Re: (Score:2)
2 things, 1 I'm sure you're unaware of.
1) Showed incredible weakness during Iran Hostage Crisis. Something that could have probably been avoided entirely if he didn't take the Shah in and sent him to some Caribbean island with the rest of the world's retired dictators.
2) Was close buddies with Arafat and taught him how to work the media to rebrand the PLO, a vicious terrorist group, into innocent "victims".
There's more but that's enough. Hopefully you learned something today.
Re: (Score:2)
2 things, 1 I'm sure you're unaware of.
We'll see.
1) Showed incredible weakness during Iran Hostage Crisis. Something that could have probably been avoided entirely if he didn't take the Shah in and sent him to some Caribbean island with the rest of the world's retired dictators.
Yes, we all know Jimmy Carter waffled on the hostages, and it likely was the main reason he was not re-elected. His successor is hardly unstained though. [wikipedia.org]
2) Was close buddies with Arafat and taught him how to work the media to rebrand the PLO, a vicious terrorist group, into innocent "victims".
I assume you have proof. Actually, no I don't. But you know who else was close buddies with Yasser Arafat? Yitzakh Rabin, Prime Minister of Israel, and co-signer of the Oslo Accords with Arafat, during the Clinton administration.
None of these justify labeling Carter as "the father of modern terrorism" -- not even close.
There's more but that's enough. Hopefully you learned something today.
Nope. Just more of the same
Re: (Score:2)
Reagan would get excommunicated from today's party. He enacted gun control legislation while governor of California and called for amnesty for people in the country illegally.
Re: (Score:2)
And there are good reasons to have Rust in the kernel. You know why it affects Asahi Linux? It turns out a lot of the more complex Apple Silicon Mx drivers are written in Rust. Like the GPU driver. The maintainer claims doing it in Rust cleans up their driver significantly. And the goal is to move more of the drivers from C to Rust to improve maintainability.
So if you want to know why Linus has a strong pro-Rust belief, it's because it's one of his pet projects and they're benefiting from Rust.
Re: (Score:2)
The evidence is against you there. The current argument hows that even for drivers shows that people do have an objection.
What is wrong with trying to write a new scheduler? I mean, if you are that sort of person, it seems a fun thing to try.
Re: (Score:2)
As far as I personally am concerned, writing a new scheduler in C is okay, even if Rust folks do it. Writing a new scheduler in Rust is NOT okay. The reason? All core kernel devs should be able to understand the code. OTOH, not all of them are experts in Rust, and most would agree that Rust is harder and more complex than C.
When expert Rust devs start being more ubiquitous than expert C devs, then I'll change my opinion. I don't hold my breath, though.
Re: (Score:2)
Someone wrote a new scheduler in Rust because they wanted to try it. It is not part of the kernel tree nor is there any expectation that it will be.
As you say, that may change in the future as there is more Rust expertize around. Obviously the Rust for Linux is not working on the basis that they will do drivers and then stop. The hope is that it will be able to do schedulers or other subsystems of the kernel when and if that becomes a good thing for Linux over all. Hard to see why anyone would worry about p
Re: (Score:2)
Not a part of the kernel tree? Everything is okay if it's not a part of the kernel tree.
Re: (Score:2)
Maybe you have just read the most "news worthy" posts in that thread which means that most extreme ones.
Worth reading through the entire thread. I would point out this post in particular from Miguel Ojeda which is extremely reasonable, patient and thoughtful.
https://lore.kernel.org/rust-f... [kernel.org]
When can I merge my PHP code into the kernel? (Score:1)
If Rust is allowed, why discriminate against the PHPPythonPerlRubyC#+ community?
Re: (Score:2)
If you can make that case to Linus and the other Linux project maintainers, then they'll accept your (whatever) code into the kernel.
But first you'll have to successfully convince them that it's a good idea; you can't just coast through on Rust's coattails and some misbegotten sense of "fairness".
Re: (Score:2)
I'd nominate my favorite userland language, Go. Sadly, its performance problems make it unsuitable for anywhere near the kernel.
Any of the languages you listed yield better performance than Go?
Re: (Score:2)
Say no the discrimination against queer languages!
Labview Go Basic Tcl(Tk) QtScript Inform Algol + , unite for an all-inclusive kernel :-)
dang that's whiny (Score:4, Interesting)
"Right now the rules is Linus can force you whatever he wants (it's his project obviously) and I think he needs to spell that out including the expectations for contributors very clearly"
Phrases like that make me think this guy is a dick to have to work with.
Re: (Score:2)
Linus is a public figure, and everyone who has been paying attention and/or cares and can work a search engine knows he is capable of being abrasive, and that Linux is his baby. Whatever else he might be, he's oblivious.
Re: (Score:2)
I wasn't referring to Torvalds. Hellwig is the dick.
Re: (Score:2)
I don't think the GP was talking about Torvalds, given the description of the comment as "Whiny".
And yeah, Torvalds can do what he wants. I lean towards wanting better technologies to be used to build the kernel than C, but if Torvalds disagrees with me, it's his baby, and I'm pretty sure he'd have damned good reasons either way. I think, so far though, he's been in favour of moving the project forward, and I'm glad for that.
Re: (Score:3)
Yes, he is. A quality absolutely necessary to lead the project to the place it is now. If he was a nice guy, Linux wouldn't exist today.
Right now, pandering to two antagonistic groups of people at the same time.
Summary, Please? (Score:4, Interesting)
Is Rust a corporate trojan horse into the kernel? (Score:2)
I've been thinking about this. Maybe I'm completely wrong, but hey this is the internet, so here I go.
I'm not sure in 2025 how much of the kernel is maintained by small developers / hobbyists and how much is already under the control of corporate, but I know that learning a new programming language takes some effort and resources and I'm not sure small devs / hobbyists would be willing to do that. If I were to maintain a driver that I had already written years ago, making small changes here and there to kee
Re: (Score:3)
I'm not sure in 2025 how much of the kernel is maintained by small developers / hobbyists and how much is already under the control of corporate
Effectively all kernel development is done by people who do it as part of their (corporate) job, and that's been the case for at least 20 years.
If I were to maintain a driver that I had already written years ago, making small changes here and there to keep it up to date with the rest of the kernel code, I'm not sure I would be enthusiastic about rewriting the whole thing in a new language that I would need to learn and study and practice enough to become proficient at it.
No one is calling for existing driver maintainers to rewrite their drivers in Rust.
Also, what's up with the reluctance to learn? Software engineering is a profession which requires constant ongoing education. Most of us really enjoy learning.
Re: (Score:3)
Linus is the BDFL (Score:4, Interesting)
The D in BDFL is "dictator", it means that what Linus decides is how it will go, full stop.
So if Linus wants Rust in his kernel, complain all you want but there will be Rust in his kernel. I am not particularly pleased by this decision but for now, I am a bit concerned by tooling and slow compile times, though I didn't give much thought to it. But saying that Linux has done well under Linus rule is an understatement. So I trust him. And if Linux loses its way because of that, which I think is unlikely, then it is an open source project, it can be forked.
Some have raised concerned about the Rust community, and I guess the anti-Rust community too, often on subjects tangential to software development, but for me, Linus does a good job at keeping things technical and focus on what's important for the project. Again I trust him on this part.
Memory safety (Score:2)