6 ms·

Hector Martin – [Patch] Maintainers: Remove Myself

12 points by Reventlov 2y ago

deleted 2y ago
[deleted]
talldayo 2y ago
Another for the pile of reverse-engineered devicetrees that started downstream, tried to negotiate with upstream and ended up realizing the futility of it all. Godspeed, may your path to depreciation be slow and painless.
- gigatexal 2y ago
  I hope they keep up the good fight …
  - talldayo 2y ago
    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 understand their exhaustion, but aiming their frustrations at Linus for having an entirely level-headed response shows that they can't read the room. This is the Linux project, you're going to have problems merging enormous codebases that reverse-engineer poorly understood hardware. I support Rust in the Linux kernel, but this is the kind of envoy that will spoil the effort.
    - gigatexal 2y ago
      The Apple hardware is compelling enough that I think they will keep it up. We are funding them — at least I am trying to
      - talldayo 2y ago
        If I poured out a beer for every "compelling" chipset depreciated by the mainline Linux kernel, I'd be going out to buy 6-packs on a weekly basis. It's a neat initiative, but you should have been preparing for this result since the beginning. No official support means no official support.
        gigatexal 2y ago
        What chipsets were deprecated that are still mainstream?
    - steveklabnik 2y ago
      > I understand their exhaustion, but aiming their frustrations at Linus for having an entirely level-headed response shows that they can't read the room. I agree that Linus's response wasn't over the top, but Hector didn't quit because of that one email. Heck, as far as I know he wasn't even involved in writing the patch in question. The Asahi folks have had a number of issues dealing with other maintainers for at least the past couple of years. This is a "the straw that broke the camel's back" situation.
vsgherzi 2y ago
It is what it is... However if you want volunteers to contribute to the kernel and introduce rust as a way to get more people to join this looks pretty bad... I'm sure stuff will figure itself out in the long run it's just sad that the discourse exists at all. I guess the linux kernel will never transition to memory safety via a new language? Idk what else can be done.
- uecker 2y ago
  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.
  - vsgherzi 2y ago
    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 other problems, zig is not 100% safe, and carbon is vapor ware. Could there be something better than rust? Yes. Do I think rust can be annoying at times? Absolutely... But the way I look at it, we don't have another shot.
    - uecker 2y ago
      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.
uecker 2y ago
Some background: https://lore.kernel.org/all/Z6OzgBYZNJPr_ZD1@phenom.ffwll.local/ https://lore.kernel.org/all/Z6OzgBYZNJPr_ZD1@phenom.ffwll.lo... https://lore.kernel.org/all/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ https://lore.kernel.org/all/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWS...
phendrenad2 2y ago
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 consensus-building and healthy debate and just makes people more entrenched and unwilling to compromise). [1] - He was already ousted from the project once, I don't think he wants to try it again.
- steveklabnik 2y ago
  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.
  - uecker 2y ago
    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)
pulsartwin 2y ago
This is a remarkably disappointing end to Hellwig's original NACK, yet entirely expected based on the recent treatment of R4L devs.

12 points by Reventlov 2y ago

deleted 2y ago

[deleted]

Another for the pile of reverse-engineered devicetrees that started downstream, tried to negotiate with upstream and ended up realizing the futility of it all. Godspeed, may your path to depreciation be slow and painless.

gigatexal 2y ago
I hope they keep up the good fight …
- talldayo 2y ago
  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 understand their exhaustion, but aiming their frustrations at Linus for having an entirely level-headed response shows that they can't read the room. This is the Linux project, you're going to have problems merging enormous codebases that reverse-engineer poorly understood hardware. I support Rust in the Linux kernel, but this is the kind of envoy that will spoil the effort.
  - gigatexal 2y ago
    The Apple hardware is compelling enough that I think they will keep it up. We are funding them — at least I am trying to
    - talldayo 2y ago
      If I poured out a beer for every "compelling" chipset depreciated by the mainline Linux kernel, I'd be going out to buy 6-packs on a weekly basis. It's a neat initiative, but you should have been preparing for this result since the beginning. No official support means no official support.
      - gigatexal 2y ago
        What chipsets were deprecated that are still mainstream?
  - steveklabnik 2y ago
    > I understand their exhaustion, but aiming their frustrations at Linus for having an entirely level-headed response shows that they can't read the room. I agree that Linus's response wasn't over the top, but Hector didn't quit because of that one email. Heck, as far as I know he wasn't even involved in writing the patch in question. The Asahi folks have had a number of issues dealing with other maintainers for at least the past couple of years. This is a "the straw that broke the camel's back" situation.

vsgherzi 2y ago

It is what it is... However if you want volunteers to contribute to the kernel and introduce rust as a way to get more people to join this looks pretty bad... I'm sure stuff will figure itself out in the long run it's just sad that the discourse exists at all. I guess the linux kernel will never transition to memory safety via a new language? Idk what else can be done.

uecker 2y ago
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.
- vsgherzi 2y ago
  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 other problems, zig is not 100% safe, and carbon is vapor ware. Could there be something better than rust? Yes. Do I think rust can be annoying at times? Absolutely... But the way I look at it, we don't have another shot.
  - uecker 2y ago
    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.

uecker 2y ago

Some background: https://lore.kernel.org/all/Z6OzgBYZNJPr_ZD1@phenom.ffwll.local/ https://lore.kernel.org/all/Z6OzgBYZNJPr_ZD1@phenom.ffwll.lo... https://lore.kernel.org/all/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ https://lore.kernel.org/all/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWS...

phendrenad2 2y ago

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 consensus-building and healthy debate and just makes people more entrenched and unwilling to compromise). [1] - He was already ousted from the project once, I don't think he wants to try it again.

steveklabnik 2y ago
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.
- uecker 2y ago
  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)

pulsartwin 2y ago

This is a remarkably disappointing end to Hellwig's original NACK, yet entirely expected based on the recent treatment of R4L devs.