Part of my life is involved in finding issues with the incorporation of new technology to upgrade or 'improve' things, prior to bringing into service. There are always a bunch of knock-on issues related to through-life operations to the shiny new, some of them so significant that they result in major changes to the solution or in several cases the solution is dropped. I see both sides here, yes Rust 'can' improve certain things and if this was a green-field project, fantastic. Unfortunately there are existing personnel, skill-sets, processes, legacy code-bases etc that the shiny new has to fit into nicely.

It's very common for tech providers to go 'I've solved all of your problems!' and for the stakeholders to go... 'You do know how things work around here, right???'

" It's very common for tech providers to go 'I've solved all of your problems!' and for the stakeholders to go... 'You do know how things work around here, right???' "

This seems to be a nice example, yes. Walks in, learns just adding rust doesn't automatically make linux fart rainbows, complains about "nontechnical nonsense" and "bikeshedding" when confronted with people seeing their maintenance workload increased for no gain to them or the wider community. This is a project for the benefit of the rustaceans. rustfapping, for short.

And here I was hoping it was some rust CoC nonsense that had him step down. The more's the pity. But apparently at least this relentless rust promotor has no staying power when confronted with real-world issues. Thus, if you ever get stuck with a rustifyer, be sure to have a back-out plan.

" "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." "

So he's a true believer but no visionary. As it happens, I share neither his belief nor his lack-of-vision nor his fear. Some other kernel (like whose, you're threatening linux with kernel.dll, what?) going rust should have no bearing whatsoever on linux since we were promised left and right, up and down, that it would forever remain "optional". The problem with Unix isn't lack of memory safe languages either, and linux tries very hard not to be Unix anyway. The future of kernels in general isn't by slapping an optional one trick pony language presented as a silver bullet on it. (But I for one wouldn't mind this guy, or some other microsoftian, trying to port kernel.dll to rust. Let's see how that goes. Seems to be a better-delineated project anyway, with being a dll and all. Oh, doesn't work that way? How interesting.)

The main problem with software projects including operating systems is forever complexity. One way to help reduce complexity is to compartimentalise. It's been long known that Unix' monolithic kernel design was getting a bit long in the tooth back in 1969 already. linux copied it, so it's still stuck with that. (Yes, I'm saying "Tanenbaum was right", even though linus probably wasn't up to that challenge and it would've risked linux going the way of gnu/herd.) But adding a language that requires a giant and complex code generator written in yet another language is not how you reduce complexity. Going on with rust will reduce maintainability and will likely cost platform coverage going forward, at the latest as soon as the pretense of optionality fades. This may well be how that pretense fades, in fact.

So rust does exactly nothing to reduce complexity. If you want to fiddle the language, it would be a much better idea to go after its weaknesses, [1]for example by learning from C++, rather than replacing it wholesale. Or adding a friendly neighbourhood one trick pony that isn't going to replace it wholesale, no siree, honest!

So what this guy's saying is bald-faced lies. But we'll give him the benefit of the doubt, that with being not a visionary and all. Just a misguided true believer. And a microsoftian working on linux. That too. "There are no conflicts of interest there at all either," said Comical Ali.

[1] https://herbsutter.com/2024/03/11/safety-in-context/

Hi Ted :)

You wish, but no.

I have a certain amount of sympathy for both sides in this case.

Adding more lines of code implies more maintenance and it's already hard to find maintainers - needing specific skills from an even smaller set of potential candidates isn't going to help.

Equally, we've probably all been in situations where NIH-syndrome has led to foot-dragging.

However, the real problem is seems to me is that the scope, benefits and timeline of Rust for Linux are ill-defined. Indeed, they don't appear to be mentioned anywhere on the project website. It seems mostly focused at present on providing the infrastructure for writing device-drivers in Rust, but acknowledges that deprecation of duplicate drivers in Linux means there are unlikely to be Rust replacements for current drivers. The highly hardware-dependent nature of drivers makes them a good place to shake down the mechanisms by which you'd run Rust code in the kernel, but so much of the memory management is done by the Linux driver framework that you would imagine the gains from Rust's memory safety might be fairly modest - and in any case have to await hypothetical future drivers for devices for which no driver currently exists. I don't see any roadmap for introducing Rust into other parts of the kernel, or any analysis of where the benefits might most be felt.

Of course, there is also the problem that transformational change in a project like Linux is very hard to achieve - it's mature, its stability is critical and it proceeds mostly by discrete incremental changes to is myriad components. You have to start with what you have - and that includes the people as well as the code - and juggle the various competing requirements.

In open source, the solution to a particular problem also depends on the interests of the people working on it. In this case, the only people working seriously on memory safety in the kernel seem to be Rust developers. I can't help feeling it would be a very different conversation if a group were considering adding Rust-like features to a version of C that could over time be incorporated into the existing code.

Like politics, it's the art of the possible and that means not only having a solution but persuading other people to adopt it.

Never _ever_ tell people that the thing you're doing won't affect them, they won't have to change, they won't have to learn anything new, etc., etc. because it's the biggest fib going.

Project A kicks off as a "technical implementation" - drop new software into an existing ecosystem without disturbing anything. Ahahahahahaha, so much naievity. So much WWI trench warfare to go nowhere for years trying to implement.

Project B looks at the experience of project A, says not doing that again, kicks off as a "transformation" - interactions are similarly old testament biblical in nature but at least it's at the design/talky stages (and talk is cheap) rather than the trying to force a square peg into a round hole implementation.

Will it make a difference in the end - to be decided at some future date but it's a hell of a lot easier to rewrite some words on a page than figure out several eye wateringly expensive widgets that you've bought and paid for don't fit together.

That is part of the argument I just don't get, how can they genuinely say that people won't need to learn rust? If rust is part of the Linux kernel and I want to work on the Linux kernel then logically I need to know rust. If I don't know rust then what happens when I come across a section written in rust that I need to alter? Then I have two options, don't alter it or learn rust.

Sure when rust is just used for device drivers and components then it may not be essential to know just now but they seem to want it to become a major part of the kernel, so how would you be able to get away with not knowing it then?

"Filho's request to get information to statically encode file system interface semantics in Rust bindings"

Well this is FOSS so the actual interface is just there for anyone to read, so presumably the sticking point is some background context that can't be expressed in C. But here's the rub: Anyone writing C code to use that interface has exactly the same problem and the same range of solutions.

You can ask a more experienced dev, but they will have limited time to spare for teaching. You can read the source code for the implementation and figure it out yourself, but that's probably a lot of work. Thirdly, you can hope that someone else has gone down one or other of these paths and bothered to document what they learned.

I don't see how your intended target language affects this.

(Edit: His proposal to produce a Linux compatible kernel would present similar issues, albeit only at the user-space interface, and he doesn't seem to think this would be all that hard. So what's he actually complaining about?)

It's not the same person proposing a Linux-compatible kernel at the end of the article. That's someone else and it seems he's worked out that no true Rustacean will be happy until the whole Linux kernel is completely rewritten in Rust, so they may as well go and rewrite it in the same way as they rewrite user-space software, which is disappear for a while and come back and announce they wrote a replacement for something. It sounds much more easier for everyone than Rustaceans arriving in ships to the fabled lands of the Linux kernel, disembarking, and trying to convert all the non-believers.

Seems like the Rustofarians are facing the classic problem of trying to convert the worshippers from The Church of the Holy C. Yeah sure, the new God promises safety from the sin of memory leaks but the worshippers of the old God are happy with their religion and aren't much interested in learning any new prayers or hymns.

well he seems like a complete self absorbed prick.

if it's so easy to make a rusty kernel then fuck off and do it and stop whining like a baby.

(also as he works for M$, he was probably sabotaging linux (lets make every call X times slower for every kernal call just for fun) like that poettering twat with systemD bullshit)

Imagine if Linux decided to incorporate Node.js to become more accessible to developers who can't comprehend C.

You jest, but... lua is making inroads with the *BSDs. In netbsd for drivers, in freebsd to replace the forth used to boot up the system. (And then there was the time when freebsd sported a scsi driver written in perl for a while.) No, I'm not convinced either is a good idea. But it's popular, a FOSS community buzzword, a gottahavefornootherreason, so it's almost inevitable someone stood up and did it, and core@ up and let them. I don't think of lua as small, but it's positively tiny compared to node.js, nevermind rust and the whole circus that brings to town.

Quote from OA

" I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to [the linux kernel] what [the linux kernel] did to Unix. "

And that actually strikes me as something that would be fine. Quote from De Vault's blog post referenced in OA

"Here’s the pitch: 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 politics."

Bring it on. Show what can be done. A drop-in kernel for specific and limited workloads for (say) servers would probably be of great interest to many people and organisations, some of whom might be in a position to provide some funding.

'Politics', i.e. the processes that humans use to work together and arrive at decisions, will have to evolve. It will be interesting to see how and what the steady-state result looks like.