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

Asahi Linux lead developer Hector Martin resigns from Linux kernel

lkml.org

Post reply on HN
Print view View original

131–140 of 1001 posts

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#131

Post by naasking »

mid-kid wrote: post #129
naasking wrote: post #22

Earlier quoted context omitted.

> 5 years later, it's still not there. It was just a one-liner, and I'm not really sure why it never got added. I think they expect people who want things to advocate harder than just mentioning it once. If no one brings it up again, then they assume that no one cares.

why bother infering such intent when the obvious answer - that they simply forgot about it with no ill intentions - is right there?

Requiring people to advocate for their changes is not ill-intent. It handles all cases such as forgetting/missing a patch, and disagreement whether something is needed. The point is there's no system in place to track which patches "should ideally be included but weren't for some reason", it's up for the people who need them to push for them.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#132

Post by dralley »

zoogeny wrote: post #120
bjord wrote: post #20

Earlier quoted context omitted.

is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?

I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings. This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up. For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believ…

No, the point is nonsense. Rust is a consumer of the APIs just like every other driver / subsystem is. Any change to the C APIs would likely require collaboration with those other maintainers no different than Rust. And CH would be immediately shut down if he tried to roadblock some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#133

Post by zoogeny »

ziddoap wrote: post #66
bakugo wrote: post #50

Earlier quoted context omitted.

[flagged]

> Starting to think it's not just a coincidence. Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?

I would argue the second.

I think it is a human trait to like to win arguments. In some card games, there is a thing called a trump card [1]. The trump card has this special ability to beat all other cards.

Rust has a kind of trump card: memory safety. If you get in an argument about code it is often possible to maneuver the argument in the direction of memory safety at which point the Rust advocate gets to default win the discussion.

I think this "trump card" aspect attracts a particular kind of person to advocate for Rust simply because they like to feel technically superior to others. Whenever they are in an argument, no matter what the context, they simply have to play the game: how can I make this technical argument about memory safety so that I can win by default.

1. https://en.wikipedia.org/wiki/Trump_(card_games)

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#134

Post by gpm »

markus_zhang wrote: post #81

I have a question. Instead of fighting an uphill war in the Linux kernel community, why don't Rush developers just make a new kernel or fork their own? Sure it's going to take years, but at least they don't have to suffer the mental outrages from time to time and can do whatever they want? I mean I'd do it if that's what I want. P.S I don't have skin and skill for the kernel game. I'm just a curious bystander.

Linux is a cooperation between numerous companies to develop a shared artifact that works with all of their hardware, solves all of their use cases, etc. No one company involved can just go make their own replacement, because they need the cooperation of the other companies involved to get it to work on the hardware manufactured by the other companies.

Even ignoring the driver problem, it's not really an economically viable amount of work. Right now everyone benefits from everyone else's bug fixes, from everyone else's security improvements (like introducing rust!), etc. Going it on your own means you have to redo everything everyone else has done (unless you just fork linux), and that you don't get the benefit of everyone else working on the shared codebase (I suppose unless you fork linux and keep merging in upstream... which is actually what projects like Android do).

A complete rewrite also means a huge time lag before you start seeing payback in terms of faster development speed and a more reliable/secure operating system. Unlike introducing rust in new work to the existing kernel which sees relatively immediate payback.

I suppose I wouldn't be too surprised to see a project like Android just maintaining a whole series of rust changes in their own branch if the RFL project continues to be impeded by the maintainers. That's what Asahi linux (Linux on apple computers) is already doing (and poking at the android-mainline branch it looks like there are some rust additions that aren't in Linus's tree... but I'm not sure what the extent is).

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#135

Post by ho_schi »

zoogeny wrote: post #120
bjord wrote: post #20

Earlier quoted context omitted.

is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?

I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings. This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up. For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believ…

Thanks.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#136

Post by zoogeny »

dralley wrote: post #132
zoogeny wrote: post #120

Earlier quoted context omitted.

I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings. This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up. For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believ…

No, the point is nonsense. Rust is a consumer of the APIs just like every other driver / subsystem is. Any change to the C APIs would likely require collaboration with those other maintainers no different than Rust. And CH would be immediately shut down if he tried to roadblock some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".

I think you are using inflammatory language by calling the point nonsense.

As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#137

Post by Longhanks »

pyrale wrote: post #102
Longhanks wrote: post #30

Earlier quoted context omitted.

> This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything. Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are…

> The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. Both sides of the argument are kernel developers here, though.

Well, one side just quit.

And that particular side was told by Linus Torvalds himself that his way of Social Media brigading is inappropriate for kernel development, and that the current process works.

I choose to believe Linus. His work on and guidance of the kernel used to and still does work pretty great.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#138

Post by Narishma »

pjmlp wrote: post #91
threatofrain wrote: post #74

Earlier quoted context omitted.

Perhaps C is here to stay and that is the way Linux should live and naturally die. That's what's being proposed here by the guy who opposes multi-language projects.

Most UNIX systems that were not implemented in C, and thus lacked the symbiotic relationship, never survived in the market, sadly. There have been UNIX systems implemented, Pascal, Ada, Modula-2, Modula-3, as the most relevant ones. All gone. Also note that POSIX/UNIX certification requires a C compiler presence.

I don't think you can conclude anything from that since a ton of UNIX systems implemented in C are also dead.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#140

Post by noirscape »

gpm wrote: post #124
noirscape wrote: post #17

Earlier quoted context omitted.

He couldn't veto it anyway; by reading the entire thread, you'll see that the maintainer NACKed the request. After that, Greg KH stepped in (since he was soft asked to help earlier in the thread with an @) to reconfirm that what seems to be the general policy for r4l is followed (aka it'll be a separate file with its own maintainer), with the subtle implication that it would probably just get merged as a separate pat…

Put yourself in the shoes of the person submitting this patch. Is a "subtle implication" (and to be clear, it was a very subtle one if it was one at all) that a senior maintainers NAK on a patch is going to be ignored enough to make the whole situation not incredibly demoralizing? Does it do much of anything to solve the fact they've publicly declared that they are going to do everything they can to stop the project,…

To me the implication isn't subtle; the maintainer NACKs, the response from someone on the contributing team is "maybe we should involve @Linus or @Greg" and from that point on, you see Greg KH get involved to note what the proper procedure is and to ensure that it'll be followed. Hellwig is completely sidelined from that point onwards, minus some grumbling noise on his side.

Hellwig is a jerk, yes (probably crosses a few lines), but there's a procedure that sidelines him and his mention for this patch was a mere courtesy (since r4l maintains the wrappers and they're not even kept in his folder).

Marcan's insertion in the thread is extremely overblown and as someone in the thread notes, comes across more like a several hours late cavalry to appeal to his social feed. I have a slightly "nicer" interpretation of it than that (in that I don't think Marcan is that kind of person) since it reads like it's probably just the sort of rage best reserved for a private message to a friend, but he's making it everyone else's problem by threatening social media brigading (which is plain and simple: harassment and unlike Hellwig's rudeness, extremely easy to identify as something to push back on).

Post reply on HN