Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hector Martin – [Patch] Maintainers: Remove Myself

lkml.org

Post reply on HN
Print view View original

11–20 of 54 posts

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#11

Post by steveklabnik »

phendrenad2 wrote: post #9

This whole thing is, at it's core, an architectural question. It's quite simple: How much should the C code have to change to allow better Rust support? Despite his position as "Benevolent dictator for life", Linus doesn't really have the chutzpah to stand up and say "we're doing it this way"[1], so these sorts of questions try to get resolved through petty bickering and namecalling instead (which is the opposite of…

That question as already answered when the experiment was greenlit: it doesn’t have to at all.

That question is also not what is at the heart of this conflict. It’s someone that categorically rejects the experiment, even though the project has decided to give it a try. It’s entirely social and not technical.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#12

Post by uecker »

vsgherzi wrote: post #10
uecker wrote: post #8

Earlier quoted context omitted.

Well, I very much hope that the Linux kernel will never transition to Rust. The language is far too complex for my taste. IMHO Rust people should just build their own kernels and if those are better they can replace Linux just like the C++ microkernels did.

The complaints I have with rust are going to be on the async side. We need memory safety in the kernel, it dosen't have to be majority but having vital parts in rust could be a game changer. The kernel must evolve, all players are moving this way. Swift is being introduced into Darwin, Rust into Windows. Memory safety is not a fad and the only tangible options right now is rust. Swift could be interesting but creates…

I think a far better approach to memory safety in C projects is to evolve tools and annotate existing code. It is also not true that everybody moves to Rust and I think the claims about memory safety are overblown (due use of unsafe Rust). In my experience as a observer and contributor of open-source and free software for the last decades, these changes driven by enthusiastic and opinionated small group that try change how existing projects work are very dangerous and often contraproductive both in terms of technical and social risks for the projects. It is far better to start alternative projects that compete on their own merits and if the techniques are truly superior, then those will eventually be competitive. Going into existing projects and changing them according to "opinions" is a really bad idea.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#13

Post by uecker »

steveklabnik wrote: post #11
phendrenad2 wrote: post #9

This whole thing is, at it's core, an architectural question. It's quite simple: How much should the C code have to change to allow better Rust support? Despite his position as "Benevolent dictator for life", Linus doesn't really have the chutzpah to stand up and say "we're doing it this way"[1], so these sorts of questions try to get resolved through petty bickering and namecalling instead (which is the opposite of…

That question as already answered when the experiment was greenlit: it doesn’t have to at all. That question is also not what is at the heart of this conflict. It’s someone that categorically rejects the experiment, even though the project has decided to give it a try. It’s entirely social and not technical.

I don't think this is a fair characterization. I think the accusations from the Rust side that the project is "sabotaged" or "non-technical arguments" etc. are a typical symptom of denial. All the hype and enthusiasm related to Rust is that you can just write something easily in C instead of Rust (or rewrite) and then all problems related to safety are solved. And some of those people really believe this nonsense. The real world complexities unsurprisingly do not go away simply by using Rust. The signs are all over: The project is moving very slowly, the very enthusiastic people who move it along with sheer will power get burned out, there also CVEs in Rust code, etc. But if you bought all the Rust arguments and are now invested, it is difficult to accept that the solution of the safety problems is not as simple "rewrite to Rust". So the more immature part of the Rust communities starts to blame politics. Now, I do not want to say that there are not grains of truth in all these points (I do think memory safety is great, I do think that C ecosystem has issues, I agree that there are many good ideas in Rust, and certainly skepticism from others makes it harder to push something forward in a community, etc.), but overall I think it is mostly delusional ideas from Rust folks encountering the real world, and instead of critical self-reflection on what needs to improved both in terms of social aspects of collaboration and maybe also on the technical side, they blame others for sabotaging the project and organize a social media circus to force their ideas on a community (which of course, is super toxic and evil)

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#15

Post by pulsartwin »

uecker wrote: post #13
steveklabnik wrote: post #11

Earlier quoted context omitted.

That question as already answered when the experiment was greenlit: it doesn’t have to at all. That question is also not what is at the heart of this conflict. It’s someone that categorically rejects the experiment, even though the project has decided to give it a try. It’s entirely social and not technical.

I don't think this is a fair characterization. I think the accusations from the Rust side that the project is "sabotaged" or "non-technical arguments" etc. are a typical symptom of denial. All the hype and enthusiasm related to Rust is that you can just write something easily in C instead of Rust (or rewrite) and then all problems related to safety are solved. And some of those people really believe this nonsense. Th…

I don't entirely disagree with some of your points, however, they are not what the recent discussion has been about. Plainly, a maintainer has unilaterally rejected the addition of rust code to assist with DMA and requested that code be duplicated in every driver (which also ignores the fact that the patch never added rust code to kernel/dma to begin with). It strikes many as strange that the experimental addition of rust-based drivers (greenlit by Linus orignally) has come to a head in this way:

"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux."

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#16

Post by menaerus »

steveklabnik wrote: post #11
phendrenad2 wrote: post #9

This whole thing is, at it's core, an architectural question. It's quite simple: How much should the C code have to change to allow better Rust support? Despite his position as "Benevolent dictator for life", Linus doesn't really have the chutzpah to stand up and say "we're doing it this way"[1], so these sorts of questions try to get resolved through petty bickering and namecalling instead (which is the opposite of…

That question as already answered when the experiment was greenlit: it doesn’t have to at all. That question is also not what is at the heart of this conflict. It’s someone that categorically rejects the experiment, even though the project has decided to give it a try. It’s entirely social and not technical.

The reason is entirely technical and I think it has been formulated clearly - maintaining cross-language codebase, or one of the most important kernel modules FWIW in this case, certainly does not make things simpler but only more complex - communication-wise, time-wise, resource-wise, uncertainty-wise etc. I think this is pretty clear and not really debatable IMO.

The actual question is if that overhead is worth it and it seems that there is no clear answer on that question despite many Rust-force claiming otherwise. I can totally understand the position of kernel maintainers.

What I cannot understand is the following shameful, almost unbelievable, act from Hector Martin

> If shaming on social media does not work, then tell me what does, because I'm out of ideas.

If there's a single most reason why Rust-in-Linux will fail it is going to be because of the immaturity and entitlement of individuals in Rust community.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#17

Post by gigatexal »

talldayo wrote: post #6
gigatexal wrote: post #5

Earlier quoted context omitted.

I hope they keep up the good fight …

The good fight was already lost when Apple didn't lift a finger to help. No documentation, no driver code, just an open-enough iBoot interface to flash some code onto. Valiant programmers can take a hack like that pretty far, but at some point they have to ask what they're fighting for. Is Asahi interested in adapting to the norms of the Linux kernel, or do they insist on bending the Linux kernel to meet them? I unde…

The Apple hardware is compelling enough that I think they will keep it up. We are funding them — at least I am trying to

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#18

Post by vsgherzi »

uecker wrote: post #12
vsgherzi wrote: post #10

Earlier quoted context omitted.

The complaints I have with rust are going to be on the async side. We need memory safety in the kernel, it dosen't have to be majority but having vital parts in rust could be a game changer. The kernel must evolve, all players are moving this way. Swift is being introduced into Darwin, Rust into Windows. Memory safety is not a fad and the only tangible options right now is rust. Swift could be interesting but creates…

I think a far better approach to memory safety in C projects is to evolve tools and annotate existing code. It is also not true that everybody moves to Rust and I think the claims about memory safety are overblown (due use of unsafe Rust). In my experience as a observer and contributor of open-source and free software for the last decades, these changes driven by enthusiastic and opinionated small group that try chan…

I agree that memory safety gets over-hyped and is often treated like a silver bullet solution. However, I do believe the problems of memory unsafely to be real and to be a threat (just less than what the popular opinion is). We've tried using static analyzers and C and AI driven detection to limited success, we cannot guarantee correct C code, this is just a hard problem when a project as big and important as the kernel exists.

Rust was an experiment proposed by Linus so I don't really see this as driven by a small group, it should be the standard as that's what Linus wanted to try. It's an experiment that's having social problems.

I think alternative projects are a good idea and some are already being and have been created, but the Goal of this experiment was to help Linux evolve in a direction to keep the kernel competitive and healthy.

I think Rust is a great idea but it might not be the right fit for the kernel socially, which is unfortunate. Maybe the only option forward here is improving C... but that seems like an impossible task without breaking changes. I do hope for the best with the kernel and with the RFL maintianers.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#19

Post by steveklabnik »

menaerus wrote: post #16
steveklabnik wrote: post #11

Earlier quoted context omitted.

That question as already answered when the experiment was greenlit: it doesn’t have to at all. That question is also not what is at the heart of this conflict. It’s someone that categorically rejects the experiment, even though the project has decided to give it a try. It’s entirely social and not technical.

The reason is entirely technical and I think it has been formulated clearly - maintaining cross-language codebase, or one of the most important kernel modules FWIW in this case, certainly does not make things simpler but only more complex - communication-wise, time-wise, resource-wise, uncertainty-wise etc. I think this is pretty clear and not really debatable IMO. The actual question is if that overhead is worth it…

That technical decision has already been made, by Linus: it is acceptable for the purposes of this experiment, and possibly, for good. So objecting on those grounds is a project management issue.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#20

Post by steveklabnik »

uecker wrote: post #13
steveklabnik wrote: post #11

Earlier quoted context omitted.

That question as already answered when the experiment was greenlit: it doesn’t have to at all. That question is also not what is at the heart of this conflict. It’s someone that categorically rejects the experiment, even though the project has decided to give it a try. It’s entirely social and not technical.

I don't think this is a fair characterization. I think the accusations from the Rust side that the project is "sabotaged" or "non-technical arguments" etc. are a typical symptom of denial. All the hype and enthusiasm related to Rust is that you can just write something easily in C instead of Rust (or rewrite) and then all problems related to safety are solved. And some of those people really believe this nonsense. Th…

> I think the accusations from the Rust side that the project is "sabotaged" or "non-technical arguments" etc. are a typical symptom of denial.

When someone says

> You might not like my answer, but I will do everything I can do to stop this.

Against the decision that the project made, that is very straightforwardly sabotage.

> All the hype and enthusiasm related to Rust is that you can just write something easily in C instead of Rust (or rewrite) and then all problems related to safety are solved.

You cannot accuse others of being hyperbolic and then be so yourself. No serious person claims that it’s easy or that it solves all issues.

I don’t really even want to engage with this rest of this post, honestly it says more about you than about Rust.

Post reply on HN