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.

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.

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

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.

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

@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

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