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

We are the "thin blue line" that is trying to keep the code high quality

lore.kernel.org

Post reply on HN
Print view View original

111–120 of 186 posts

Re: We are the "thin blue line" that is trying to keep the code high quality

#111

Post by unethical_ban »

muamoe wrote: post #75
jemmyw wrote: post #62

Earlier quoted context omitted.

Yes but the parent has addressed this and you're just talking past them like they didn't comment. If the maintainers don't want it to happen then they need to come to an agreement that it won't happen. If they do want it to happen then they need to stop blocking it for non-technical reasons. If they can't actually decide then that's "no" or up to the project lead to enforce the decision at the risk of losing maintain…

Wow, the entitlement here is absolutely amazing. You are not entitled to any work, or explanation, or "agreement". Show me where it says maintainers owe you any of this at all.

Basic communication/decisionmaking by the maintainers about a major feature in the kernel is something that I would expect devs to be entitled to.

Re: We are the "thin blue line" that is trying to keep the code high quality

#112

Post by skrtskrt »

strstr wrote: post #33

Being an upstream maintainer is incredibly under-appreciated. It’s an unfathomably hard, and somewhat thankless, job (at least if you do it well). A friend of mine was in a cab with Ted Ts’o at a conference and he was reviewing patches on his phone to keep up with the workload (or maybe he was bored who knows). Despite incredible effort from maintainers, getting necessary changes into Linux can take forever. In the s…

a bug taking a year to track down is a negative indicator of the quality of project maintenance, not the person who contributed the bug, whether it's due the code itself or the tooling and testing environments available to verify such important issues.

Re: We are the "thin blue line" that is trying to keep the code high quality

#113

Post by unethical_ban »

llm_trw wrote: post #37
Diggsey wrote: post #36

Earlier quoted context omitted.

Noone's asking the maintainers to make the project happen. It is the maintainers job to determine whether a project should be pursued at all. If a maintainer says "yes I'd be happy to accept feature X", and then simply rejects all PRs implementing X without giving feedback then they're a bad maintainer! That's essentially what's happening here due to the fact that the kernel maintainers have not come to a coherent de…

>Noone's asking the maintainers to make the project happen. If you're asking them to accept your code then yes, you' are asking them to support your project forever. If you weren't sending them patches then they couldn't block you. Since you are they can. Again, it's not their job to support this great idea you have that means they have to change how they've done everything for the last 30 years.

>Again, it's not their job to support this great idea you have that means they have to change how they've done everything for the last 30 years.

Then say that. A big part of the issue is that there has been mixed signals from the Linux maintainers about R4L. Linus seemed to have supported it, and others are trying to block it.

The maintainers should get on the same page about the inclusion of rustlang code, and communicate that.

Re: We are the "thin blue line" that is trying to keep the code high quality

#114

Post by lmm »

markhahn wrote: post #76
arjie wrote: post #19

The factors at play are all obvious. The old-school guys want to keep things old-school. The new-school guys want to make things better in a new way. Has there been any new rewrite without a BFDL who himself is of the new school? The vim/neovim schism happened and perhaps that's how it ends. I personally like Neovim and I'm glad to be in backers.md and it's a tremendously larger amount of work than to have just chang…

if your lens is old-bad vs new-good, you are blind to merits. didn't the good egcs stuff get merged after all?

> didn't the good egcs stuff get merged after all?

EGCS took over as mainline, and what good stuff there was in the old mainline got merged into it. But it took sustaining the fork for years to make that happen.

Re: We are the "thin blue line" that is trying to keep the code high quality

#115

Post by llm_trw »

liveoneggs wrote: post #87
llm_trw wrote: post #32

Earlier quoted context omitted.

It's not the maintainers job to make your project happen. It's yours. If you need someone to do free work but you can't convince them then you either get their boss to tell them to do it, you take over their job, or - the one thing that no one under 30 ever seems to do - fork and do the work yourself without anyone stopping you.

I agree with you completely. If rust is so great why not make a new kernel with it and compete? or fork and start rewriting subsystems? I do also understand the frustration when an open source project strings you along (me: can I join your club?), ask for this and that (them: sure if you pay your dues), ensuring your cover every "important" person's pet use case (them: and also buy us lunch), then publicly snark abou…

What I don't get is the complaints from the Rust people.

If Rust truly is zero overhead on the C side of things then they should be just able to fork Linux indefinitely without any worry about what upstream does. Just fast forward every change and you're golden.

Then they can write every driver they can imagine to their hearts' content.

The fact they aren't doing this tells me that the promise that this won't impact C people at all isn't much of one.

Re: We are the "thin blue line" that is trying to keep the code high quality

#116

Post by lmm »

llm_trw wrote: post #37
Diggsey wrote: post #36

Earlier quoted context omitted.

Noone's asking the maintainers to make the project happen. It is the maintainers job to determine whether a project should be pursued at all. If a maintainer says "yes I'd be happy to accept feature X", and then simply rejects all PRs implementing X without giving feedback then they're a bad maintainer! That's essentially what's happening here due to the fact that the kernel maintainers have not come to a coherent de…

>Noone's asking the maintainers to make the project happen. If you're asking them to accept your code then yes, you' are asking them to support your project forever. If you weren't sending them patches then they couldn't block you. Since you are they can. Again, it's not their job to support this great idea you have that means they have to change how they've done everything for the last 30 years.

> If you're asking them to accept your code then yes, you' are asking them to support your project forever.

> If you weren't sending them patches then they couldn't block you. Since you are they can.

One of the big turning points of this drama was a maintainer from a different area (who had been CCed on the threads, but was not the person the patch was being submitted to) blocking a patch that they weren't going to have to maintain.

Re: We are the "thin blue line" that is trying to keep the code high quality

#117

Post by geodel »

chris_wot wrote: post #70

I would be more likely to want to listen to T'so if he hadn't done the following: https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s There was a reasonable discussion about Rust, and then T'so drops the bombshell: "I suspect part of the problem here is you're trying to convince everyone to switch over to the religion as promulgated by Rust and the reality is that ain't going to happen because we have 50 plus file sy…

Huh, then don't listen. So far no clear answer why Rust people are suffering daily humiliation at the hand of C coders instead of just writing their own kernel.

Re: We are the "thin blue line" that is trying to keep the code high quality

#119

Post by exabrial »

arjie wrote: post #19

The factors at play are all obvious. The old-school guys want to keep things old-school. The new-school guys want to make things better in a new way. Has there been any new rewrite without a BFDL who himself is of the new school? The vim/neovim schism happened and perhaps that's how it ends. I personally like Neovim and I'm glad to be in backers.md and it's a tremendously larger amount of work than to have just chang…

>The old-school guys want to keep things old-school. The new-school guys want to make things better in a new way

The new school guys greatly underappreciate the wisdom of why and instead try to change things without first understanding.

Re: We are the "thin blue line" that is trying to keep the code high quality

#120

Post by dang »

quartzic wrote: post #6

Related: https://news.ycombinator.com/item?id=43036904

Thanks! Macroexpanded:

Resigning as Asahi Linux project lead - https://news.ycombinator.com/item?id=43036904 - Feb 2025 (826 comments)

Asahi Linux lead developer Hector Martin resigns from Linux kernel - https://news.ycombinator.com/item?id=42972062 - Feb 2025 (1015 comments)

Post reply on HN