Rust for Linux Maintainer Steps Down in Frustration With 'Nontechnical Nonsense' (theregister.com) 155
Efforts to add Rust code to the Linux kernel has suffered a setback as one of the maintainers of the Rust for Linux project has stepped down -- citing frustration with "nontechnical nonsense," according to The Register:
Wedson Almeida Filho, a software engineer at Microsoft who has overseen the Rust for Linux project, announced his resignation in a message to the Linux kernel development mailing list. "I am retiring from the project," Filho declared. "After almost four years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them."
[...] Memory safety bugs are regularly cited as the major source of serious software vulnerabilities by organizations overseeing large projects written in C and C++. So in recent years there's been a concerted push from large developers like Microsoft and Google, as well as from government entities like the US Cybersecurity and Infrastructure Security Agency, to use memory-safe programming languages -- among them Rust. Discussions about adding Rust to Linux date back to 2020 and were realized in late 2022 with the release of Linux 6.1. "I truly believe the future of kernels is with memory-safe languages," Filho's note continued. "I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix."
[...] Memory safety bugs are regularly cited as the major source of serious software vulnerabilities by organizations overseeing large projects written in C and C++. So in recent years there's been a concerted push from large developers like Microsoft and Google, as well as from government entities like the US Cybersecurity and Infrastructure Security Agency, to use memory-safe programming languages -- among them Rust. Discussions about adding Rust to Linux date back to 2020 and were realized in late 2022 with the release of Linux 6.1. "I truly believe the future of kernels is with memory-safe languages," Filho's note continued. "I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix."
One good related read (Score:5, Interesting)
https://airlied.blogspot.com/2... [blogspot.com]
Re: (Score:2)
Interesting analogy.
There is more status in being the Wayfinder/Mapmaker. It looks better on resumes and often comes with a bigger budget needed to throw out previous work and hack a new path through the wilderness.
I don't know where the 'nontechnical nonsense' enters into this. The disagreement (described elsewhere) sounds technical. But a matter of two parties having chosen two different paths (or small sections of the path) along the overall route. And defending their choice. Analogy: Sort of like the
Re:One good related read (Score:5, Insightful)
The nontechnical nonsense is basically the whole inter-personal relationships part.
It's the part that developers tend to do badly at - because it's got to deal with other people and soft skills.
You've got here two developers, both technical leads in their areas and both are clashing because of a difference of vision. The technical parts are at odds, and generally speaking you need strong interpersonal skills to realize that this is not going to resolve itself - both parties need to compromise and both need to work it out.
But generally speaking, as developers, that's a soft skill they lack And as such, both will remain at loggerheads and nothing will get accomplished.
Hence "nontechnical nonsense". Both can do the work very well, but both refuse to cave in or compromise and everyone ends up spinning their wheels.
That being said, Linux has traditionally not had a stable interface - they actively refuse a stable API. This is good in some ways as it makes it possible to refactor things for the better when necessary and to add features as necessary without worrying about breaking stuff. The downside is, of course, stuff can break.
Now, Linux is a mature product, so most of the wild changes are not going to happen - first of all it can break a lot of code so you'd better be prepared to fix a lot of code. But some changes can happen.
In the end, it's because the Rust interface demands a stable ABI, but the main developer behind it rightfully does not want to commit to one or to maintain the interface. And if something changes, he doesn't want to be responsible for maintaining the Rust interface code and code it depends on as it likely is going to turn into a nightmare of its own.
It all boils back down to basically Rust. You've got hardcore Linux maintainers who do a very good job at their subsystem, and now you want to impose this on them, and they remain unconvinced (with good reason). As kernel developers, they are very skeptical of things that appear to be fads (and Rust's rapid rise in interest seems to be faddish). Considering even other things that are well established aren't in the kernel (e.g., C++ support - and it's been done many times), the developers remain skeptical it will do any good to the kernel.
So I don't really blame anyone - at this point in time, Rust isn't proven to be better and the people doing the Rust interfaces failed in the interpersonal relationship parts in being able to show why it's a better way to do things.
Rust in the kernel can be a good thing, but there's a lot it needs to show for and simply saying "its better" isn't a convincing argument. The proponents (i.e., the maintainers) need to do a better job of showing and demonstrating rather than believing everyone is going to drink the kool-aid.
And that is a tonne of "nontechnical nonsense" that those Rust developers need to do.
Honestly, old read: Xorg vs Wayland (Score:4)
Personally, I'm thinking about either supporting or forking Xorg.
We will see.
Rust people gave up fast (Score:5, Insightful)
Re:Rust people gave up fast (Score:5, Interesting)
Well, as I read this story - I think it's just another case where a True Believer became shocked and frustrated when the heathens didn't step into the light sufficiently quickly.
Re: (Score:3)
Especially on Linux where Linus has been burnishing his heathen credentials for years and surprisingly the community followed suit ...
Re: (Score:2)
Re: Rust people gave up fast (Score:4, Funny)
Wish they were more open/honest. (Score:2)
I get it this is emotional crap, and they sound very polite and neutral. Just makes it so the next person has no idea what they'd be running into, and the rest of the project's management can't try to fix the problem at the source. Which it sounds like they've already given up on, so... oh well.
Interfaces (Score:5, Insightful)
People suddenly rediscover that in large projects it's not the core logic that is hard, it's the public/internal interfaces that are... nightmare-ish.
Adding interfaces for Rust doubles the nightmares.
P.S. If interfaces, their implementations, were easy, we would had had more (and better) programming languages than we have today. Alas.
Re: Interfaces (Score:2)
Re: (Score:2)
Personally, I find Rust a very distasteful language to use. I understand why they only allow one pointer to a variable, but they consider every use of a variable a pointer-in-that-sense. I think unique pointer and shared pointers are a better approach Using Rust felt like trying to program with one finger. (As you might guess, I rather quickly dropped it, so someone who was used to it might find it less objectionable.)
OTOH, if most of the kernel programmers aren't used to Rust, they may feel the same wa
Re: (Score:3)
Asperger's sufferers, by definition, are exceedingly rational, actually.
Re: Interfaces (Score:4)
Difficulty understanding non-verbal communication and others emotions does not make someone "exceedingly rational" - they may be more *methodical* in communication, by necessity, but they are vulnerable to the same logical fallacies and self-delusions as a neurotypical person.
Challenges expressing emotional reciprocity does not mean lack of personal emotion, nor does it imply a greater self-awareness or ability to self-regulate them.
Neurodiversity acceptance is a wonderful development, but there is a modern tendency to mythologize the spectrum as "Mr Spock / Data" which is dehumanizing in its own way.
"Nontechnical Nonsense" (Score:5, Interesting)
"The video depicts resistance to Filho's request to get information to statically encode file system interface semantics in Rust bindings, as a way to reduce errors.
Ts'o's objection is that C code will continue to evolve, and those changes may break the Rust bindings – and he doesn't want the responsibility of fixing them if that happens."
Sounds like a completely valid technical concern.
Re:"Nontechnical Nonsense" (Score:5, Interesting)
Sounds like a completely valid technical concern.
And how is that a valid technical concern? Filho was adding something in Rust and wanted more information how Linux does things. Ts'o basically retorted he did not want to give any information because does not want to maintain Rust. No one asked him to do so.
Re: (Score:2)
Ts'o basically retorted he did not want to give any information because does not want to maintain Rust. No one asked him to do so.
You're correct; there's no real reason to not share this information. My experience has been that when someone doesn't want to give you information in cases like this, especially like implementation details, it's because (a) their work is poor and/or (b) job security. In either case, they don't want others to know anything about what they do -- or have done, etc...
Re: "Nontechnical Nonsense" (Score:3)
I suspect they didn't want to give more information because they didn't want to be limited by what they would provide and be free to change things whenever they see fit.
Re:"Nontechnical Nonsense" (Score:5, Interesting)
I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves part of the problem.
I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to use its API.
Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?
When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others?
Is a NULL argument allowed and valid usage, or not? What happens to reference counts in the error case? Is a returned ref counted pointer already incremented, or is it an implied borrow from a reference owned by a passed argument?
Is the return value always a valid pointer? Can it be NULL? Or maybe it's an ERR_PTR? Maybe both? What about pointers returned via indirect arguments, are those cleared to NULL on error or left alone? Is it valid to pass a NULL ** if you don't need that return pointer?
...[more very interesting details]...
To be clear, I don't blame Linux developers for the incomplete docs. For better or worse, the Linux kernel is very complex and has to deal with a lot of subtlety. Most userspace APIs have much simpler rules you have to follow to use them safely. Kernels are hard!
Even experienced kernel developers get these things wrong all the time. It's not a skill issue. It's simply not possible for humans to keep all of these complex rules in their head and get them right, every single time. We are not built for that.
We need tooling to help us.
The solution is called Rust. Encode all the rules in the code and type system once, and never have to worry about them again.
Just like the solution to coding style arguments is to encode all the rules in an auto formatter and never have to worry about them again (hint hint! ^^)
And then we can stop worrying about all the low-level safety, ownership, and locking problems, and start worrying about more important things like high-level driver and subsystem design.
(I should note that the Rust for Linux project does in fact also enforce rustfmt for submissions, so you also don't have to worry about code formatting or have a code review complain about that if you write kernel Rust, ever! Just make rustfmt.)
Re: (Score:2)
That's where something like Microsoft's PREfast is handy, it provides semantic annotations for every function and will answer most if not all of the above questions. There's also a static analyser that then runs over the code and tells you whether you've messed something up.
Only downside is that they haven't really updated it since about 2015, it's still maintained but not really updated.
Re: (Score:2)
Nice write up, thanks. I agree that the questions posed should have answers in the API docs/commentary. Other developers shouldn't have to guess and/or do a deep-dive into the code for things like acceptable arguments and return values. I'd also like to add that I've found it useful if documentation/commentary has some sort of timeline attached for things that change so developers can understand how something has evolved and why.
Personally, I always try to write and document my code as though I might
Re:"Nontechnical Nonsense" (Score:5, Insightful)
Ts'o basically retorted he did not want to give any information because does not want to maintain Rust. No one asked him to do so.
Linux is now controlled by corporations. Anyone here who ever worked in Development for a Large Corp. perfectly understands Ts'o concern.
As a kernel maintainer, Ts'o owns a portion of the kernel and will always own it. So if someone makes a change to the those module(s), Ts'o is still the owner until he leaves. That happens in all Large Corporations.
So Ts'o concern is he does not want to maintain Rust code, that is a valid concern for some people. Unless Almeida wants to take full ownership, T'so will not help. Almeida stepping away kind of proves T'so was right in his concerns.
Re: (Score:3)
So Ts'o concern is he does not want to maintain Rust code.
Yes, that's his concern. Thing is it's a false concern. No one asked T'so to maintain Rust code, despite his hysterical claims. Not even by implication. There are all kinds of silos in intellectual work, for good and ill, and there is no reason T'so has to either give up his C silo or work in someone else's Rust silo.
Ts'o feels threatened. His threat response is irrational: false accusations about "religion" and forcing people to do something. The technical parts of his argument are bogus, whining a
Re: (Score:3)
Yes, that's his concern. Thing is it's a false concern. No one asked T'so to maintain Rust code
Yes, but in large projects that is not how things work. Since T'so seems to be responsible for that area of the kernel, in the "real world (tm)", he will end up owning it. Until a rust "expert" steps up and takes full ownership of what T'so owns, he can set the rules.
Re:"Nontechnical Nonsense" (Score:5, Interesting)
Yes, but in large projects that is not how things work. Since T'so seems to be responsible for that area of the kernel, in the "real world (tm)", he will end up owning it. Until a rust "expert" steps up and takes full ownership of what T'so owns, he can set the rules.
What Filho was asking about was "what are the rules?" I suspect T'so does not want to be forced to actually clarify what the rules are because he can change them in the future without any ramifications. It currently works in C and he can make it work in the future in C. However if someone relied on his rules and he changes it to where Rust could break, then he'll have to answer more questions about what the rules are.
Re: (Score:2)
So Ts'o concern is he does not want to maintain Rust code, that is a valid concern for some people.
I perfectly understand the "still the owner until he leaves", this is the story of my work life, shitty responsibility I can't seem to get rid of because I accepted them long ago and nobody steps in to replace me.
However, Ts'o should feel the wind changing direction, and proactively look to either learning the new skill, or have look for someone else who's willing to second him with Rust. It's his responsibility in the interest of the whole project.
Re: "Nontechnical Nonsense" (Score:3)
Re:"Nontechnical Nonsense" (Score:4, Insightful)
Ok, in theory he could say "today the information is like this, but this information cannot be used by you tomorrow because we will change things in subtle ways. Ask again tomorrow and we will give you the information valid tomorrow, but be warned it will not be valid the day after tomorrow because things will be changed experimentally again'.
It is obvious that when Filho is asking for information he actually wants something reliable that will hold true for weeks and months or years, enough time to actually build something in Rust that works properly on top of this information. But guess what, the only way for this to happen is if Ts'o commits to keeping this information valid and stable for weeks and months and years.
In short, Filho by asking for detailed information only is *really* asking for stable code interfaces that can be built on reliably, and that's an imposition on Ts'o, who is being asked to take the extra responsibility of keeping some parts of the code stable for the Rust developers going forward. And if he takes that added responsibility and things break later, he'll be responsible for breaking Rust code too.
If you've never worked in a large (or even medium) organisation, then the above is not obvious. Whenever you let a foreign team inside your organisation use your work, you become responsible for their successes and failures too. That's a thankless and exceedingly bad place to be.
Re: (Score:3)
Ts'o is being asked to make implicit guarantees about the behaviour and API for the future, so that Rust developers can rely on these guarantees.
Please cite where that is stated. Ts'o was not being asked about guarantees. What he was asked about were how things should be done; however, if he states what the behavior is, he has to explain in the future why he changed them. Currently he has to explain to no one if and when he changes things.
That's what giving information in a large project is: making implicit guarantees.
This is Linux. This is not some sort of secret project at a company. For things to work in an open source, there should be standards about how things should work.
It is obvious that when Filho is asking for information he actually wants something reliable that will hold true for weeks and months or years, enough time to actually build something in Rust that works properly on top of this information. But guess what, the only way for this to happen is if Ts'o commits to keeping this information valid and stable for weeks and months and years.
Yes because Linux kernels fundamentally change with
Re: (Score:3)
Sounds like a completely valid technical concern.
It's Not a technical concern. It's called gatekeeping technical information out of fear.
The dev has Information they are witholding bc they fear development of Rust interfaces will Impose more requirements on themself in the future. It's true that Rust development is going to impose more requirements on the whole project, But that is not a technical reason to be hostile and deliberately non-cooperative with other devs.
I believe stating Opposition to the
Re:"Nontechnical Nonsense" (Score:5, Insightful)
Tell me you've never had to maintain anything without telling me you've never had to maintain anything.
Re: (Score:3)
No it's not. He doesn't care about them having the information.
He doesn't want to waste his valuable time explaining it all to them, which is very different.
He doesn't believe in what they're doing and thinks it's a waste of everybody's time and resources, a position with which many others would agree.
Re: "Nontechnical Nonsense" (Score:2)
Re:"Nontechnical Nonsense" (Score:5, Insightful)
>> gatekeeping technical information out of fear
You don't know that.
The report merely says he wanted to "get information to statically encode file system interface semantics in Rust bindings". This is a typical problem with mixing language domains in a complex application. They have to be able to call into each other via a well established interface. If everything is in the same language the compiler/linker will usually enforce compliance with code changes, or at least the test cases will.
The way I read it is that the Rust people want the interfaces to be well defined, and therefore cast in stone to a large extent. There would be a commitment to an API that Rust could depend on. If changes were made to the file system interface they would be communicated clearly between the participants in a timely manner so that things wouldn't break. Not an unreasonable requirement from the perspective of Rust folks.
But the file system people probably aren't doing things that way and they don't want to, it's an extra burden. There's no upside in it for them. More work and less flexibility.
Re: (Score:2)
He could just cooperate and make it clear he's not going to maintain the interfaces and this is a staffing issue.
But the fact is code like ext is prime for conversation to Rust and people are proud of their code.
The linux code that bangs on hardware will remain in C for the longest time but other stuff will get converted.
DoD is one customer that is very committed.
Re: (Score:3)
I didn't get the sense that the filesystem people are concerned that Rust will horn in on their domain. They may simply not want to freeze their API as-is and severely reduce flexibility in later iterations of their code.
Most interesting part ot TFA (Score:5, Interesting)
From the article:
As an alternative, he (Drew DeVault) has proposed starting anew, without trying to wedge Rust into legacy C code. He wrote that "a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML [Linux kernel mailing list] politics. You would be astonished by how quickly you can make meaningful gains in this kind of environment; I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production-ready for some use cases within a few years."
IANAP so I could be totally out to lunch here; but here's why I like that idea. First and foremost, it reduces the likelihood that the Linux kernel will become a flaky, hard-to-maintain bunch of kludges aimed at forcing two very different programming languages together. I can foresee that kernel maintenance might become even more of a nightmare than it already is by introducing another language.
Second, having two functionally equivalent kernels written in different languages may mean that a security exploit against one of them won't work against the other. Also, one might turn out to be faster and/or more efficient than the other.
Third, the Rust enthusiasts can, on their own, either prove their mettle - and that of their chosen language - or sod off.
Re:Most interesting part ot TFA (Score:4, Interesting)
This idea does have a lot of appeal. It's a reasonable concept: they could avoid eating the whole elephant and implement a subset of the kernel. Target, for instance, the "cloud VM" use case where you need VMM, scheduler, processes, network and block devices, and not much else. For the last two you only need virtio implementations. This would have some appeal to cloud operators; fewer defects by virtue of Rust, and shedding a bunch of legacy stuff (BIOS, etc.)
Re: (Score:2)
Re: (Score:2)
Most Linux kernel developers are paid by corporations to write code for the kernel.
Who will pay people to write a new Rust kernel?
Re: (Score:2)
Re: (Score:2)
(the quote by the De Vault makes more sense in the full context of the article. He's not a rah rah Rust guy; He's saying that TO the enthusiastic Rust guys who are already writing Rust stuff and eager to do more. )
Re: Most interesting part ot TFA (Score:2)
Re: (Score:3)
Had the young always won, UNIX-type systems would have been gone long ago. AFAIK most computers in the world run a UNIX-derivative, not a DOS/Windows derivative, not a BeOS derivative, not a OS/2 one, not a MenuetOS one...
And most importantly, there aren't that many complex projects in Rust. Sure, Rust aficionados can rewrite ls or grep all day long, that does not prove a very large Rust project can be maintained over a non-trivial period of time.
Re: (Score:2, Insightful)
"a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML [Linux kernel mailing list] politics."
No they couldn't. It has taken Linux 30 years and hundreds of people to get where it is today. To think that you can do it better and in a small fraction of that time is the number one mistake of the clueless amateur. Also, your new project will have all the same arguing and "mailing list politics". 100% Guaranteed.
Re: (Score:3)
It has taken Linux 30 years and hundreds of people to get where it is today.
We're decades down the line in all respects, the starting point is nothing alike.
The goal isn't stated as a fully featured clone in a year, it's to have something that's ready for _some_ use cases in _several_ years. That's seems quite plausible to me. I'm not saying it's a good idea or that it will happen, but it's not something I'd think out of reach for a group matching the stated description of being motivated and talented at both Rust and OS development.
Personally, I doubt it will happen. Even if it ge
Re: (Score:2)
I agree that they couldn't, but the idea that it could be done a lot more easily now isn't unreasonable. They've got a model to work from. I just don't think Rust is that good a language. It might be interesting if somebody did it in, O, Vala (except that Vala looks like it's never going to get out of beta). Of course, Vala depends on C...but just abot everything does except the stuff that depends on assembler (or microcoding).
Re:Most interesting part ot TFA (Score:4, Insightful)
> you've never used Rust, with Rust, if it compiles it's probably good.
This may be the worst part about fans of Rust. As I started learning Rust, I saw this sentiment virtually everywhere a comment section was attached to the media I was consuming and it's -- to be perfectly blunt -- fucking cultist nonsense. Yes, Rust's core design and tooling will make it very difficult (but not impossible) to write some classes of bugs or errors; but to extrapolate that into "it compiles, it [probably] works" is laughably amateur and omits all the other logic, security, and performance issues and bugs software can have without having a compile-time error. The ideology puts so much qualification into that "probably" that you may as well have said nothing.
Re: (Score:3)
From the article:
As an alternative, he (Drew DeVault) has proposed starting anew, without trying to wedge Rust into legacy C code. He wrote that "a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML [Linux kernel mailing list] politics. You would be astonished by how quickly you can make meaningful gains in this kind of environment; I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production-ready for some use cases within a few years."
IANAP so I could be totally out to lunch here; but here's why I like that idea. First and foremost, it reduces the likelihood that the Linux kernel will become a flaky, hard-to-maintain bunch of kludges aimed at forcing two very different programming languages together. I can foresee that kernel maintenance might become even more of a nightmare than it already is by introducing another language.
Second, having two functionally equivalent kernels written in different languages may mean that a security exploit against one of them won't work against the other. Also, one might turn out to be faster and/or more efficient than the other.
Third, the Rust enthusiasts can, on their own, either prove their mettle - and that of their chosen language - or sod off.
Eh, that actually seems like a terrible idea.
Now, the kludge risk is legit, you'd need to make sure all the kludge went into the interface layer so you didn't end up with long term weirdness, but the rewrite from scratch is worse.
As awesome a language Rust is, it's still possible to write bugs. Some of the existing C kernel weirdness is C-isms and bad architecture, but some came from fixing edge cases and other hard-to-anticipate bugs. If you try a from-scratch rewrite you'll end up with a buggy mess losing
Re:Most interesting part ot TFA (Score:5, Informative)
IANAP so I could be totally out to lunch here; but here's why I like that idea.
Except they already did that. It's called Redox OS [redox-os.org] and it's great or terrible depending on who you ask.
Re: (Score:2)
Redox OS is another microkernel-based toy OS attempt, it's not attempting to replace the monolithic Linux kernel.
Re:Most interesting part ot TFA (Score:4, Interesting)
From the article:
Third, the Rust enthusiasts can, on their own, either prove their mettle - and that of their chosen language - or sod off.
I've been programming in C/C++ for over 30 years and about a year ago I started learning Rust. Now I'm fluent in the language and idioms I feel that programming in C like languages is like watching a black & white TV while a color TV is available. Rust is definitely different enough to require a non-trivial learning curve, but it's an investment that I am happy that I made.
Languages are just tools, and I think Rust is a tool that is often superior to my C tool. No doubt C gets the job done, but the memory management in Rust is superior and is done at compile time so there's no run-time overhead. Depending on what you are coding that could be a non-issue or a huge improvement. But given a language choice, I will reach for my Rust compiler over my C compiler every time. Of course, all my legacy C code is still running and I would never think of rewriting working code just to change the language.
I think I understand why other people are less impressed. Rust offers nothing to an experienced, top notch C programmer who understands memory management well and is certain that he would never, ever access a piece of memory that another thread has already released. But it's nice that you don't have to worry about that and other memory issues. Many people dislike change and I understand that also, but I don't understand why people are so averse to another language to the point where they actively attempt to prevent its adoption.
Re: (Score:2)
I think I understand why other people are less impressed. Rust offers nothing to an experienced, top notch C programmer who understands memory management well and is certain that he would never, ever access a piece of memory that another thread has already released. But it's nice that you don't have to worry about that and other memory issues.
To me that sounds like a good argument in favour of officially migrating the whole kernel to Rust. Develop both kernels simultaneously in order to keep the features and quality up-to-date, then migrate to Rust once they achieve parity and interchangeability.
I can hear people screaming about that prospect right now, and I understand why. But it seems to me that taking the currently-necessary burden of anal-retentive memory management out of day-to-day programming should result in a future with less likelihoo
Re: (Score:2)
The sky's the limit (Score:2)
The sky is the limit. Write Hurd or Plan 9 in Rust.
Re: (Score:2)
The best part of this proposal is that either way they sod off, and nobody else has to deal with them any more.
They either succeed at creating something workable or not. Either way, nobody is forced to interact with them.
switching kernels (Score:2)
Dude should totally do that (Score:2)
He wrote that "a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML [Linux kernel mailing list] politics. You would be astonished by how quickly you can make meaningful gains in this kind of environment; I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production-ready for some use cases within a few years." ®
Completely support that. 100% no reservations. And quite honestly no cynicism from me on this. All of this last paragraph is good stuff. The more the merrier. Give us the moxie that way. I'm due for an astonishment.
Just Follow DeVault Advice (Score:2)
As an alternative, he has proposed starting anew, without trying to wedge Rust into legacy C code. He wrote that "a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML [Linux kernel mailing list] politics. You would be astonished by how quickly you can make meaningful gains in this kind of environment; I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production-ready for some use cases within a few years."
The worst case scenario? Tech companies (Microsoft, Google, NVIDIA, Intel, ...) start writing device drivers and maintain this Rust kernel and then the Linux kernel will be just porting that code into their own. Pretty much like the *BSD developers are porting code from Linux.
Re: (Score:3)
How do you write device drivers in a memory-safe language? Don't they, by definition, poke and peek into raw memory spaces?
Re: (Score:3)
Re: (Score:2)
Eeesh. Smoke and mirrors.
Re: (Score:3)
The drm/asahi driver is currently 18744 lines of pure Rust, and it has 109 unsafe blocks (most of which are one line). So that's less than 1% unsafe code... and a lot of that is described by a few patterns that each repeat a few times.
32 of the unsafe blocks are in object.rs which is where the GPU object model magic happens (which necessarily has to play with raw pointers since it deals with sharing memory between the GPU and driver code). If you remove that and unsafe impl stuff that leaves 65 unsafe blocks. And most of them are boring:
6 are union accesses for channel types
1 is a transmute that only runs in const context
6 are assembly blocks to do TLB invalidation since that happens via special CPU instructions.
20 or so are reading structures from userspace.
9 are in the GPU structure heap allocator in alloc.rs (which again has to play with raw pointers for obvious reasons)
10 are in mmu.rs dealing with the pagetable pointers used by the GPU and related stuff like that
3 are pin projections
A few others are boring miscellanea
And that leaves... one or two "clever" uses of raw pointers that actually require some thought to prove are safe.
In other words, the vast vast majority of unsafe blocks are doing one obvious thing which is trivially correct just by looking at that code and the few surrounding lines. There is practically no "sneaky unsafety" that ends up being hard to prove correct. Other than obvious "I screwed up the pointer math in object.rs when I first wrote that code and it crashed instantly" type stuff, I've never had a random bug related to an unsafe block doing something that was in fact unsafe/broken.
And this is a GPU driver which is pretty much as crazy as drivers get*, memory management wise (it contains an entire object model and memory allocator implementation, as well as having to interact with firmware written in unsafe C). Almost every other driver class will have less unsafe.
[*Emphasis mine]
Well now (Score:3)
"As an alternative, he has proposed starting anew, without trying to wedge Rust into legacy C code. He wrote that "a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML [Linux kernel mailing list] politics."
Okay, just do it. Make your own kernel, with blackjack and hookers. If it's any good, people will adopt it. My guess is the project will just turn into Hurd 2, but put your money/time where your mouth is. No one in the world will try to stop you.
"I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix."
So what? If that actually happens, why would it be a problem?
Path Should Not Have Been Taken In The First Place (Score:2)
When, soon, we will realize that is going nowhere, someone will have to clean the house of the added crud.
Re: (Score:2)
It's like kORBit all over again
Re: (Score:2)
What did it do to Unix? (Score:3, Informative)
Though the code's been updated to the newer standards of the language, BSD kernels remain written in pure — and beautiful — C...
Don't fall for it (Score:5, Insightful)
For Rust supporters (Score:2)
Opposition to Rust, or opposition to change? (Score:2)
What happens when something replaces Rust one day? We'll need the ability to switch to the new language, or maybe to several new languages if it's unclear which one is best, or if there is disagreement.
Re: (Score:2)
Sooner or later, the kernel should be rewritten in a memory safe language. I'm not a big fan of Rust, but eventually we'll have to rewrite it in something. It seems like there needs to be long term support in the kernel not for any one language, but for any potential language or combination of languages.
What people want are assurances of correct operation not merely low level memory safety. It does not follow a rewrite would be necessary or even helpful in providing such assurances.
What happens when something replaces Rust one day? We'll need the ability to switch to the new language, or maybe to several new languages if it's unclear which one is best, or if there is disagreement. As a result, It seems to me that what the kernel really needs is to be designed to support its components being written in potentially many different languages.
If you create a formal specification you can write a kernel that conforms to the specification in nearly any language your heart desires. One first might want to make sure the language they've selected also has a formal specification.
However, at this point, it seems like some kernel devs might be opposed to switching away from C, full stop. That's a problem.
We need to replace it with memory safe languages, maybe we haven't even invented a good one yet, but some day it's going to have to happen. If we have opposition to any change, then that's a major problem.
This presumes language selection is even relevant which I personally doubt. Kernels with form
Re: (Score:2)
> Sooner or later, the kernel should be rewritten in a memory safe language.
Redox [redox-os.org] already did that.
Good luck getting "critical mass". (Linux is here today and works.)
Re: Opposition to Rust, or opposition to change? (Score:2)
Re: (Score:2)
Typically: exploiting vulnerabilities in User programs and common libraries first. THEN afterwards explointing System daemons (SystemD) and the kernel in order to elevate privilege.
Non-technical? (Score:5, Insightful)
Kernel: "no I don't want to have to maintain that too"
Rust: "This is too hard, I'm going home"
Technically it sounds like Linux devs don't want to add compatibility layers all through the code base that they also have to maintain.
Not likely (Score:2)
"I'm afraid some other kernel will do to it what it did to Unix."
Linux succeeded because it was basically a cobbled together hobbyist OS - for free - that you could use to do development in a Unix like operating system. It filled a need.
We don't have a need for memory safe anything. We have a *want* for it, and that's different. Eventually, as memory safety becomes more of a common expectation, it will be introduced into every system. But the systems won't be replaced entirely, because they don't need to be
Re: (Score:3)
We don't have a need for memory safe anything. We have a *want* for it
Eventually we are likely to see Governments adopt a standard that a memory-safe kernel is mandatory for Critical infrastructure devices
Won't matter to them whether it is Linux or something else. It may actually be Microsoft with Windows that becomes the first to do this.
.
Who will fix Rust code when an interface changes? (Score:5, Insightful)
T'so's coment is more legitimate than many here admit. Linus's rules for changes in kernel interfaces require that if T'so changes an interface that he is responsible for patching any other places in the kernel that use that interface. If there are Rust funtions affected, and he doesn't know Rust, then that effectively precludes him from making (or approving) any change to the interfaces he is responsible for. The Rust folk are effectilvely asking for control over changes to the kernel interfaces. It is a pretty big ask, and something Linus needs to address directly.
Re: (Score:2)
Is written in LISP.
Mine is better! It's written in ADA! I just recently upgraded from COBOL. I'm trying to bring the IRS into a new era!
Re: (Score:2)
Mine is better! It's written in ADA!
It's "Ada", not "ADA".
Ada = A programming language named for Ada Lovelace [wikipedia.org], the first programmer
ADA = American Dental Association [wikipedia.org]
Ada is a systems programming language, and implementing operating systems was one of its design objectives.
Re: My kernel (Score:2)
Re: (Score:2)
No, the kernel is based on the Americans With Disabilities Act.
I thought that was the old one-button mouse Apple used to use for the Mac.
Re: My kernel (Score:2)
Re: (Score:3)
Re: My kernel (Score:2)
Re: (Score:2)
Xerox gets that credit. Not Microsoft.
Re: My kernel (Score:2)
Re: My kernel (Score:3)
Xerox invented the mouse, the GUI, the Ethernet, the network protocol stack, the classic paradigm of OOP and more.
Apple plundered some of these things. Microsoft plundered some more.
Re: (Score:3)
Credit where credit is due, most innovations in the computer space are "Done well" by it's originator, and then copied/ripped off. Microsoft Internet Explorer used NSCA Mosaic as it's code base originally and Firefox was a "rewrite from hell" of Netscape. Chromium ripped off Apple's Webkit, which in turn ripped off KHTML.
Apple more or less invented the PDA (the newton), killed it, and then didn't bring it back until the iPhone. Microsoft and Palm ripped off the Newton, with Palm ripping off the look and fee
Re: (Score:2)
It's "Ada", not "ADA".
Ada = A programming language named for Ada Lovelace [wikipedia.org], the first programmer
Linda Lovelace [wikipedia.org] had much more in depth capabilities IMHO!
Re: (Score:2)
Re: (Score:2)
Maybe he was just so excited about Ada that he was SHOUTING.
Actually I was. I should have bolded it or done an emphasis. Besides, none of these languages are safe if someone deliberately poops in the (memory) pool. ;)
Re: (Score:2)
Re: (Score:2)
Xerox Dolphin?
I was a research assistant doing work in LISP on a Xerox 1108 Dandelion way back in '85-87 for a NASA grant Analysis and synthesis of abstract data types through generalization from examples [nasa.gov]. Wonderful machine. Still have the InterLISP-D manual. Also did some Prolog coding for a study in N-version fault tolerance.
Re: My kernel (Score:3)
I have no kernel. My whole OS is a Forth state machine.
Re: (Score:2)
Krispy Kernels are the best! https://krispykernels.com/en [krispykernels.com]
Re: (Score:2)
Re: Hmmm (Score:2)
And he is absolutely right. Also, this is one of the strongest reasons why C++ was never allowed in the kernel. Rust is a hard language, much harder than C, and its wide adoption could potentially decimate the pool of Linux kernel contributors. Rust can be good language for cathedral projects, where you can select your developers; for bazaar projects like Linux, not so much. Some selected parts of it could be declared a Rust zone, maintained by Rust people, but to disseminate Rust throughout the whole kerne