Then you’re still entirely misunderstanding the point.

While I enjoy using Aurora, there were a bunch of issues popping up over the last few months (e.g. display freezes). I guess that’s the danger of a rolling release cycle, but I’m not sure it’s 100% as foolproof as it needs to be right now.

Dude, the places that measured 50x the normal amount of radiation aren’t measuring 50x the amount right now. I’m aware that coal adds radioactive material to the air, but that’s just not relevant to the topic. But I’m tired of explaining that, have a good one.

Yes, lots. After the accident a bunch of places in Germany measured far higher-than-normal radiation levels. There were lots of unclear signals going through the government and media - the different states had different recommendations and there were lots of confusing/opposing signals going through the government and media. Some examples:

• the government recommended taking iodine tablet, which promptly sold out
• people were scared of the rain being sour, so they really tried not going out during/after
• people sprayed down their children after playing outside for fear of residue
• confusing/cautionary signals around fresh dairy and produce meant that many only consumed canned goods for a while

All of this happened during the formative years of a large part of our population. Can you understand how this does give a foundation to the fear?

Nuclear disasters are not happening despite there being hundreds of plants in operation. It’s all just FUD spread by the fossil lobby.

One happened a couple of years ago, and I guarantee you more will happen - as long as humans are involved in the cycle, things can and will go wrong. Modern designs make this far less likely and hopefully reduce the worst outcomes by a lot, but how sure are you that all our reactors are secured against e.g. sabotage? What if an enemy nation invades and gains control of the reactor? What if individual systems get attacked by drones? We’re entering a new age - don’t underestimate what terrible things can happen this time around.

Also, Fukushima happened due to natural disasters. Climate change is changing what magnitude of disaster happens where, so they might hit reactors that aren’t prepared for these disasters. Is every nuclear reactor worldwide safe from a Fukushima-type accident under all possible conditions?

I’m not at a computer with the source on it, so if you get to it before me, how many rust drivers are there? How many that would use the rust dma wrapper?

… of course there aren’t many Rust drivers so far, since the project is still young, and it’s evidently still facing hurdles and not really accepted by everyone. But if there’s already a couple of Rust drivers and Rust has explicitly been accepted into the Kernel, we’re already past your “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future”, so why argue such irrelevant points?

More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.

And that’s what has been blocked here…

I don’t know if you’re trolling. Of course people aren’t afraid of exactly these reactors blowing up again. They are afraid of nuclear accidents in general. There’s always a chance for things to go wrong, otherwise we wouldn’t have had Fukushima a couple of years ago. Some link in the chain can always fuck up.

“Coal puts out more radioactivity into air” is an incredibly stupid point. “More radioactivity” than what? People aren’t going through the same precautions they had to when they lived through the last fallout. That’s not real in this context.

No, fear doesn’t work like that. Just because something is unlikely doesn’t mean it can’t happen, and fear tends to be about just those things.

Again, you can call it irrational, but it is objectively not unfounded. There is a foundation, even if it’s unlikely. You don’t get to change the meaning of the word “unfounded” just because you think something isn’t likely to happen.

Why? I’m happy to support the developer of an application I use (as long as he actually uses the funds to fund further development).

Yes, literally include the wrapper code in every rust driver that needs it then when you push the wrapper on its own you can say “this code is currently duplicated 900 times because there isn’t a rust wrapper” not “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future” and no one will bat an eye!

That is what they are already doing and it’s introducing unnecessary work! There’s nothing about “hypothetical rust drivers”, it’s the case right now.

That’s how you get things added to the kernel!

Weird, how come C drivers don’t have to track these interfaces in their own trees? Why is this the way to get Rust code added to the kernel, but all other code doesn’t have to jump through these hoops?

Linus owes you, nor anybody not signing his paycheck, a goddamed thing.

No, he owes the community to fulfill his role in this community project. He’s not a king or a monarch or whatever you think he is. If he’s not ready to fulfill this role, he should step down as project lead.

but I have enough experience with c, c++ and rust to know that those wrappers don’t need to be in the kernel if the kernel has c bindings.

I think you have a fundamental misunderstanding of the topic.

If I were writing something in rust I could just include the r4l wrapper for the kernels c bindings and everything would work fine. The wrapper doesn’t need to be in the kernel.

We’re talking about device drivers, which are part of the Linux kernel. If you develop these wrappers outside the kernel tree, you’re making the situation even worse, since the kernel suddenly has a new dependency.

This approach was never considered, even by the maintainers that blocked wrappers, because it would be far worse than every other possibility.

Instead the question is: does every driver have to include a copy of the wrapper, or can there be one copy that’s used by all the drivers? And obviously one copy makes far more sense than N different copies.

I’ll skip over the rest of your comment, since it all seems to be built on a broken foundation.

Or I can ask Linus to do his job properly and lead on this issue, whether it’s for or against R4L.

You seem to be under the impression that I’m somehow involved with R4L or Rust, or that I even use Rust. None of these are true. I’m just seeing an example of bad project management, and people like you that keep lying to justify the maintainers decision.

So why can’t rust modules use the c bindings?

They can, if wrappers are written. These wrappers were blocked by a maintainer.

What im building towards is: if r4l isn’t about replacing c code then it doesn’t need to be in the kernel.

Why? It needs to be in the kernel for new code to get written in Rust. Why can it only be in the kernel if the goal is to replace existing code?

r4l people need to have a clear process and understanding of how they expect to accomplish that goal and be open about it.

They do!

There’s no advice to take for working with maintainers who’ll abuse their power to stop a project they don’t like.

Okay so if the point of the rust for Linux project isn’t to replace c code with rust then what is the point?

The purpose is to allow new modules to be written in Rust, not to replace C code. Why are you acting like you don’t know this already?

For the last time, the decision to include Rust has already been made. The “prove him wrong by developing out-of-tree” has already happened.

I’ll give you the benefit of the doubt and explain it, if you’re actually not understanding it.

Sync is a freemium app. You can use it for free, but you will have ads and tracking. Or you can pay a one-time fee to upgrade to premium, which removes ads and trackers. This upgrade costs 20€.

given the situation, what do you think is the answer to replacing a huge c codebase with rust under the specific conditions of Linux development (open source, overwhelmingly maintained by 9-5 lifers employed by disparate organizations, in use everywhere for everything) when maintainers say they’ll oppose it?

Nobody is trying to replace a huge C codebase.

The project lead OK’d the R4L experiment (which, again, is NOT about replacing C). Why should individual maintainers be able to completely block this outside their own subsystems?

Why lie about something so easy to check? Here’s the maintainer himself saying that the issue isn’t “R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with”:

I accept that you don’t want to be involved with Rust in the kernel, which is why we offered to maintain the Rust abstraction layer for the DMA coherent allocator as a separate component (which it would be anyways) ourselves.

Which doesn’t help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.

The maintainer literally says the issue is that there are two languages. There is no way to convince them, there’s nothing anyone can do.

Which doesn’t help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this.

The maintainer didn’t say “I worry about the maintainability, please prove that it works outside the tree” (this concern was already discussed when the R4L experiment was officially OK’d). They are explicitly saying they’ll block Rust in the kernel, no matter what.

I don’t know how to better explain this to you.