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

141–150 of 186 posts

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

#141

Post by pas »

skrtskrt wrote: post #110

A fundamental problem here not yet discussed directly here is how few maintainers there really are for a software project of this magnitude and importance. Further, the fact that so many of those maintainers are purely on volunteer time. Now it is certainly somewhat the fault of the maintainers themselves for turning off thousand if not tens of thousands of eager, well-intentioned wannabe contributors over the decade…

> major technology companies & cloud providers don't each have ...

... they have, and they are selling that as premium. it's the classic "open core" model for the cloud era.

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

#142

Post by pas »

dralley wrote: post #123
exabrial wrote: post #119

Earlier quoted context omitted.

>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.

This seems quite ironic to say when the whole drama started with Christoph not even looking at the patches long enough to see what directory they were in before rejecting them.

Isn't the charitable interpretation that the subsystem he is a maintainer of is downstream from the proposed changes?

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

#143

Post by pas »

TeeMassive wrote: post #69
dralley wrote: post #57

Earlier quoted context omitted.

The reasoning Linus himself gives for greenlighting Rust is, among other things, to avoid stagnation. So OP's description seems more apt than yours. https://www.youtube.com/watch?v=OvuEYtkOH88&t=367s

Linus doesn't write much code anymore. The ones who are responsible and doing the heavy lifting and taking the heat when things break are the often unpaid maintainers. You can't say OP is more apt when he probably never done this work before. I have to work with a "kernel a-hole". Sure it sucks but when there's some mutex bug in a chip driver, he's the one we can call and fix the problem and push the fix upstream eve…

The kernel is full of (a-)holes (both the code and the project), because the a-holes drive away the people who would help fix the holes.

Yes, it works, but there's a very real opportunity cost paid every day, month, release. It works until it doesn't. (Marcan crashed and burned out. But sure it works. And ... after all, since there's no real alternative we just pretend that it works. So as I was saying, it works! It's alive!)

Of course it's not easy to set boundaries, but the whole "patches are welcome" sets up false hope and masks the real incompetence in managing the kernel. (And of course is the focal point of the broader, very human tragedy of the Linux and FOSS ecosystem. insert obiligatory xkcd 2347 link here)

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

#144

Post by dralley »

pas wrote: post #142
dralley wrote: post #123

Earlier quoted context omitted.

This seems quite ironic to say when the whole drama started with Christoph not even looking at the patches long enough to see what directory they were in before rejecting them.

Isn't the charitable interpretation that the subsystem he is a maintainer of is downstream from the proposed changes?

I mean, no, because the straightforwards reading of his first email doesn't match with the facts. He said "no rust code in kernel/DMA" when the patch did not add any rust code to kernel/DMA.

The fact that the patch wraps kernel/DMA is why he was CC'd in the first place, but that doesn't give him authority to unilaterally reject it any more than he would have the authority to reject an Nvidia driver for using DMA.

What would happen in that case (and is likely to also happen in this one) is that CH's objection will be completely ignored, because it's absurd. Maintaining the DMA subsystem doesn't give you veto rights against every driver or subsystem that needs to use it.

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

#145

Post by dralley »

llm_trw wrote: post #129
MyOutfitIsVague wrote: post #126

Earlier quoted context omitted.

The problem is that they might want their drivers to actually work on people's existing Linux systems without having to force them to use a forked kernel. It's like telling people who want JPEGXL in Firefox to "just" fork the browser, ignoring the massive extra effort that you actually have to convince everybody to use your fork instead of the original.

What extra effort? If you match upstream it's a drop in replacement and anyone who cares will use it. If they don't it's because they don't care.

"if you match upstream"

Talk about aggressively missing the point.

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

#146

Post by llm_trw »

dralley wrote: post #145
llm_trw wrote: post #129

Earlier quoted context omitted.

What extra effort? If you match upstream it's a drop in replacement and anyone who cares will use it. If they don't it's because they don't care.

"if you match upstream" Talk about aggressively missing the point.

Explain what the point is.

Rust developers are promising that rust in the kernel should have no impact on c in the kernel.

If rust in the kernel has no impact in c then you should be able to remove the rust from the kernel and move it to it's own project, since it will have no impact on the c either way.

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

#147

Post by [deleted] »

ysofunny wrote: post #55
WhyNotHugo wrote: post #44

Earlier quoted context omitted.

The kernel is continuously changing (which IMHO is also an issue), so keeping a fork requires a lot of work to continuously adapt to those changes. This is why forks made for specific devices are seldom updated for more than a few months (or a couple of years if you're very lucky).

maybe we need something better than git. meh. I feel like this problem should have a technical solution. maybe a VCS good enough that this isn't as big an issue? (along the lines of pijul?) or maybe something from formal verification methods to better enforce or more clearly explain why some drivers cannot be accepted. then again, I don't think the computer science is quite there yet

[deleted]

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

#148

Post by micromacrofoot »

veidr wrote: post #130
skrtskrt wrote: post #85

Earlier quoted context omitted.

it's not that recent that it's a very negative term - the wiki even says the usage with regards to covering up police crimes dates back to the 70s

Yeah, but it wasn't an overt white supremacist slogan until recently. Regardless, I wouldn't have chosen that phrasing, either. I just think it's improbable that the OP (on the Linux list I mean) intended to associate linux maintainers with white nationalists.

the association with police has always been tied to white nationalism, the only change is that the association has become mainstream

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

#149

Post by liveoneggs »

MyOutfitIsVague wrote: post #126
llm_trw wrote: post #115

Earlier quoted context omitted.

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…

The problem is that they might want their drivers to actually work on people's existing Linux systems without having to force them to use a forked kernel. It's like telling people who want JPEGXL in Firefox to "just" fork the browser, ignoring the massive extra effort that you actually have to convince everybody to use your fork instead of the original.

Linux is the most important open source project ever. The barrier to entry is, actually, shockingly low.

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

#150

Post by mustache_kimono »

__d wrote: post #132
mustache_kimono wrote: post #125

Earlier quoted context omitted.

> FOSS evolves past its chokepoints by forking. Unless you've been already invited into the project?

Unless I’m mistaking things, there’s still multiple roadblocks? Just because some people have invited you in doesn’t mean everyone is welcoming.

> Unless I’m mistaking things, there’s still multiple roadblocks?

Where exactly? Yes, Christoph Hellwig did lay down in the street and did say "Over my dead body!", but everyone else just got on with it.

Do you really think a few nasty messages from a few nasty kernel maintainers is what stops Rust in the Linux kernel?

> Just because some people have invited you in doesn’t mean everyone is welcoming.

Exactly, but as much as open source can be a social thing, the Linux kernel is big business. And I think the people who really pay for the kernel really want Rust in the kernel.

Post reply on HN