From Jason Gunthorpe, maintainer of 5 Linux kernel subsystems:
IMHO the current situation of Rust does not look like success. It is basically unusable except for unmerged toy projects and it is still not obvious when that will change.
Today I learned that my Apple AGX GPU driver, which is the kernel side to the world's first and only OpenGL and Vulkan certified conformant driver for Apple Silicon GPUs, and also the FOSS community's first fully reverse engineered driver to achieve OpenGL 4.6 conformance, and which is used by thousands of Asahi Linux users in production, and that literally has never had an oops bug in production systems not caused by shared C code (unlike basically every other Linux GPU driver), is "an unmerged toy project".
(He works for Nvidia, I guarantee he's heard of it, considering we beat nouveau and NVK to GL 4.6 conformance.)
I guess this is what Linux kernel maintainers think of us Rust developers, that we only write "toy projects"...
Jared (MOVED TO DMV.COMMUNITY)
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •karolherbst 🐧 🦀
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •yeah.. we really need to focus more on getting stuff merged and I'd love for nova and asahi to work together on the bindings/abstractions so we can finally get things going here. And there are people more involved and knowledgeable with drm/kms working on nova, so I'm pretty confident that we can make this work.
And if it means we use a new drm_scheduler written in rust so be it.
Sobex
in reply to karolherbst 🐧 🦀 • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Sobex • • •@Sobex @karolherbst Probably not easily if written in idiomatic Rust with stuff like generics. I certainly don't plan to spend time thinking about that right now. It'd just be part of the driver, and if Nova wants to share it we'll move it to common Rust code.
Though you can always make wrappers work some way, so perhaps we could task the C people with writing C abstractions to the Rust scheduler if they really want to use it. Let them suffer the cross-language adaptation pain for once...
karolherbst 🐧 🦀
in reply to Sobex • • •@Sobex in theory yes. With rust you can specify the calling convention and every rust function can be compiled with the C one for compatibility.
And then you have "cbindgen" as a project to generate a C header file you simply include and link against.
The really nice think about rust is, that you don't need any kind of FFI code to call C or vice versa. Rust wrappers are really only about writing good abstractions, not about making it possible to use C code in rust or vice versa.
Asahi Lina (朝日リナ) // nullptr::live
in reply to karolherbst 🐧 🦀 • • •@karolherbst @Sobex You can write Rust that can be called from C, but you have to do that explicitly. The situation doing idiomatic Rust to C abstractions is actually worse than the other way around, because while Rust can support concepts like C struct embedding etc. (just unsafely), there is absolutely no way for C to directly interact with concepts like Rust generics. You'd have to introduce more explicit layers of abstraction in some cases with extra allocations and things like that.
And maybe that's a good thing. If we end up having high quality native Rust code in the kernel and C ends up being a second class citizen if it wants to use it, maybe that'll help convince the C people to learn Rust. We're certainly not going to degrade Rust code to C standards and design just so C people can interact with it in a C way.
karolherbst 🐧 🦀
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •pl
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •popey
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Botahamec
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Botahamec • • •Don Whiteside
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Jérôme Petazzoni
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Jérôme Petazzoni • • •Jérôme Petazzoni
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •lux 🦊ΘΔ
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Firstyear
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •.:\dGh/:.
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Too ingrained into the NVIDIA mentality.
Sometimes people need to be humbled down.
PuercoPop
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •AlgoCompSynth by znmeb 🇺🇦
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •"First they ignore you. Then they ridicule you. And then they attack you and want to burn you. And then they build monuments to you." - Nicholas Klein
quoteinvestigator.com/2017/08/…
Tommy Thorn
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •James Widman
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Code of Amor 💘
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Marsh Ray
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •That video really captures a sad moment.
“I’M NOT GOING TO LEARN [new thing]!”
“WATCH HOW I PASSIVE-AGGRESSIVELY SABOTAGE YOUR [different thing], YOU SECOND-CLASS CITIZEN.”
Jens
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •You do amazing stuff too and there are a lot of us with macs wishing to high five the skin of your palms.
Pierre Bourdon
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Pierre Bourdon
in reply to Pierre Bourdon • • •lol he actually made that argument in his reply. I'm speechless.
> AGX is currently unmerged and serves a tiny and niche user base with no commercial relavance. That is an unmerged toy by my definition.
Asahi Lina (朝日リナ) // nullptr::live
in reply to Pierre Bourdon • • •I love how he keeps on bringing up RHEL but Asahi *is* the reason why Fedora is turning on Rust in distro kernels now. I'm pretty sure that's doing more to push RHEL to do that eventually than anything else.
Also there are literally companies investing in Asahi these days, just not ones who care about RHEL. But I guess he thinks only RHEL matters and anything else is "a toy" even though one such company has roughly ~the same market cap as RH did before the IBM acquisition today.
Peter Brett
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •waffle
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Martijn Faassen has moved
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Felix "tmbinc" Domke
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Shitposting (but only a bit):
Oh, that explains the "merging Rust will risk my NVidia investment!1" thing we saw on reddit.
Matrix Multiplications should be incredibly simple to abstract, yet NVidia's AI hype reduces to "the unmatched software quality" (lol yes but $3T market cap can't lie) that nobody else can deliver.
Now you threaten that ecosystem by creating _toys_ that work better than any commercial driver.
Yes, with that I would be very concerned about any NVidia investments.
penguin42
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Kai
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Jonathan Corbet
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Jonathan Corbet • • •@corbet The problem is that as people in the Rust for Linux project we get to write all the abstractions to make things work, and that means interacting with many/all subsystem maintainers and therefore just one or two hostile maintainers can successfully derail the whole effort.
I'm already making a mental list of people to attempt to design around and avoid interacting with, and sometimes it's not even possible.
Jonathan Corbet
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •If you approach a large city with a plan to install a shiny new utility system, you will quickly find yourself dealing with a whole range of bureaucrats, some of whom will be more helpful than others. The kernel project resembles that large city in a number of ways. I don't say this is a good thing, but it is a thing.
I believe that the Rust for Linux project is succeeding. Yes, it is slow and painful, but the people pushing this work are doing the right things and making progress.
The city council (the maintainers summit) is meeting on September 17. Rust will be on the agenda, and there should be a couple of Rust for Linux developers there. That would be a good time to have a well-thought-out proposal for process changes that you would like to see.
Asahi Lina (朝日リナ) // nullptr::live
in reply to Jonathan Corbet • • •@corbet The difference is that people planning shiny new utility systems are probably on someone's payroll and still being paid regardless of how long the bureaucracy drags on or not, so at least they are getting some benefit (money) out of the painful process.
That doesn't really work like that in FOSS, especially not with non-commercial projects like Linux on M1. What that bureaucracy culture does is heavily benefit and prioritize the people employed to work on Linux and paid to deal with the red tape, and hurts people who are not and are just doing it for fun or to push the community forward, or as a side project and not their main employment.
The endgame is that you end up with a bunch of bitter people employed at big companies who do the work for the money, and have no interest in helping onboard new blood or support those who aren't motivated by a big paycheck to fight the community.
Obviously this doesn't describe the entire kernel community and there are good people working at big companies and still fighting the good fight... but I think it does describe how things are shifting overall, and how we're ending up here.
Chris Friedt
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Jens Axboe
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Jens Axboe • • •@axboe Already replied to @corbet: vt.social/@lina/11305718199671…
The problem is that when the Rust project needs to interact with a wide range of subsystem maintainers to put together usable Rust abstractions, just one or two acting in bad faith (or even simply not up to the task) can successfully derail the whole thing. We need active support from those who do want to see Rust happen... but we're not getting enough.
Asahi Lina (朝日リナ) // nullptr::live
2024-08-31 14:48:12
Jens Axboe
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Bruce Elrick
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •What if adding Rust to the kernel is abandoned and we improved the quality of the internal kernel interfaces for nothing?
gocomics.com/joelpett/2009/12/…
Stormy178
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •MadMike77
in reply to Stormy178 • • •Some people I know are afraid it will affect the complexity to compile Linux and also how much time it takes to compile it.
Asahi Lina (朝日リナ) // nullptr::live
in reply to MadMike77 • • •Dynn
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •penryu
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Chris Friedt
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •here I am reviewing Rust patches for Zephyr thinking Linux already had all of the political stuff sorted out 😂
If it makes a difference, I 💯 support what has been done in Linux with Rust.
There will always be resistance to change. Hopefully the resistance is less aggressive in the future. It sometimes takes thick skin.
I still strongly believe that Rust will reduce many of the common pitfalls hit by C developers (old and new), and that our systems will be more reliable as a result.
Surya Teja K
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •I am so sorry to hear this. Please don’t let this get to you.
We know what your code means to Asahi community.
Stay strong Lina :)