Live data from Hacker News

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

lore.kernel.org

61–70 of 186 posts

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

#61
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 new-school guys want to make things better in a new way. The new guys definitely want to make things different, but it seems there is a lot of debate over whether it will actually be better. Really, they should just write their own their kernel. If rust is really that much better, they'll will.

There are already kernels written in Rust. Telling them to go write new kernels in Rust is like telling people working on a new audio workstation that they should write a package manager instead. A new kernel that they cannot practically use does not suit their needs. The point is to use Rust where it can suit their needs.

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

#62
post #37
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.

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

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

#63

Earlier quoted context omitted.

Look into the history and meaning of “thin blue line.” It’s an endorsement of the us vs. them mindset prevalent in American policing that is the source of many (most? all?) police scandals.

It doesn't even originate in the US, mate.

It did though? First attested reference was to the US army, then to various police departments including the (infamously corrupt) LAPD.

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

#64

not the phrase I'd choose to associate with, even metaphorically

This phrase has been largely co-opted by US white nationalist/fascist groups (similar to how Pepe the Frog was) but that is a relatively recent development; the phrase has been in use for a long time before that.

https://en.wikipedia.org/wiki/Thin_blue_line

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

#65
post #16

Earlier quoted context omitted.

There is redox os

It's a cool idea but it's licensed MIT instead of GPL or something copyleft so I won't contribute to it. Rust-only ecosystem would be pretty cool though. It may be worth just forking linux for the sake of compatibility, and keeping the license going. I don't see a future otherwise. I'd also like to see better compiler diversity. Maybe once gccrs rolls around we will see different attitudes around rust emerge, compare…

The Rust community does seem to be more focused on non-copyleft licenses, do you have any ideas why that is?

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

#66

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

It's not about the VCS, it's about API compatibility being broken.

If your code is out-of-tree, every time someone changes an API that break your build, it's your responsibility to update your for and fix it.

If your code is mainline, the people who change API and break the compilation are on the hook to fix it.

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

#67
post #32
post #30

Earlier quoted context omitted.

He's not wrong, but he hasn't addressed the problem: Some maintainers are rejecting changes as a way to block a project they disagree with - ie. there is no path forward for the contributor. I wouldn't assume this normally, but they're not hiding this fact, it's self proclaimed. On the other hand, Linus has been largely in favour of the R4L project, and gave the green light for it to go ahead. The Linux kernel mainta…

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.

Reducing this to age is overly simplistic. When Linux was younger and simpler, it may've been easier to fork, but today it's a massive system with huge inertia behind it. Even if you are right in principle regarding your changes, it's extremely hard to overcome that inertia.

In the related submission on this topic [1], the author makes this argument in a lot more detail, that it's essentially impossible to make a Linux fork sustainable without massive investment that no one can realistically obtain.

[1] https://news.ycombinator.com/item?id=43036904

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

#68

Earlier quoted context omitted.

Law review articles are largely written by students. They are not authoritative. Do you think that Rowan Atkinson was dogwhistling about undemocratic, racist, bigoted police violence when he named his police sitcom "The Thin Blue Line" or do you think perhaps your dislike of the police has led to you associating negative attributes with anyone that happens to use any phrase related to the police? Where I am from, the…

I'm not a left winger, and I generally respect the police, but everybody I've met with a "thin blue line" American flag decal or sticker has been a total asshole. It's not just hatred of the police. Connotations change over time, and the general connotation of "the thin blue line" in the US at the moment is unabashed support of far-right authoritarianism.

[flagged]

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

#69
post #57

Earlier quoted context omitted.

> The old-school guys want to keep things old-school. You are missing the whole point here. The kernel is a survival epic amongst millions of other failed projects. You don't get to tell the old captain and its lieutenants how to nail the planks and helm the ship when you just went pass the Titanic and Britannic wrecks because metal is so cool. They're "old-school" because they have to be. Engineers will excrete thei…

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 even though he's already overworked. He's an a-hole but I respect his rules because he's the one suffering and pulling in the work and I don't.

Yes the kernel is stagnating (patches and email mailing list, line length limited to be compatible with old tty terminal, etc.) but when you're at the helm of a ship you don't just steer it near the nice looking island just because it looks pretty and there doesn't seem to have rocks.

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

#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 systems in Linux they will not all be instantaneously converted over to rust" [26:05]

He pretty much shouts at the Rust developers, denigrates their efforts and when they explain what they are trying to do which is to understand the semantic changes.

And then T'so then starts yelling at him even more. He wonders why people are not happy with his attitude - then perhaps he should consider how he communicates. The Rust guy is trying to be constructive and T'so was not.

Post reply on HN