More shots fired at Linus (justifiably so) https://lore.kernel.org/lkml/6e3e26c7-002a-49c6-a3a8-1cc1b89...
> I'm just a Linux user watching this shitshow unfold
Yet he can't even put up his real name. Pathetic
We are the "thin blue line" that is trying to keep the code high quality
121–130 of 186 posts
Re: We are the "thin blue line" that is trying to keep the code high quality
#122gcc vs. egcs, emacs vs xemacs, bsd vs bsd, bsd vs att, etc, etc, etc.
FOSS evolves past its chokepoints by forking.
So, a credible group of Rustaceans and their backers need to come up with a plan to do it.
It doesn't have to be antagonistic -- it's exploratory. If it works out well, it's a lot easier to adopt once the imagined issues are resolved or evaporated.
Subsystem by subsystem would be my suggestion. And just do it. And sooner or later, it will be (a) good enough that it's pulled into -next, or (b) they'll give up because it's not worth the effort.
I'd be pretty surprised if, for instance, one of Google/Amazon/Meta/Microsoft/Cloudflare/Netflix/etc wasn't interested in an ABI-compatible kernel written in Rust. Get a few biggish backers, and LF would possibly even adopt it.
Re: We are the "thin blue line" that is trying to keep the code high quality
#123The 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.
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.
Re: We are the "thin blue line" that is trying to keep the code high quality
#124Being 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.
This isn't wrong per se, but rather, it lacks concrete recommendations for what should be done differently.
I would love to see Linux thoroughly and meaningfully tested. For some parts it's just... hard. (If anyone wants to get their start writing kernel code, have a crack at writing some self-tests for a component that looks complicated. The relevant maintainer will probably be excited to see literally anyone writing tests.)
For this particular bug, the cheapest spot to catch the issue would have been code review. In a normal code base, the next cheapest would have been unit testing, though, in this situation, that may not have caught it given that the underlying bug required someone to break the contract of a function (one part of Linux broke the contract of another. Why did it not BUG_ON for that...).
Eliminating the class of issue required fairly invasive forms of introspection on VMs running a custom module. Sure, we did that... eventually.
Finding it originally required stumbling on a distro of Linux that accidentally manifested the corruption visibly (about once per 50ish 30 minute integration test runs, which is pretty frequently in the scheme of corruption bugs).
Re: We are the "thin blue line" that is trying to keep the code high quality
#125gcc vs. egcs, emacs vs xemacs, bsd vs bsd, bsd vs att, etc, etc, etc. FOSS evolves past its chokepoints by forking. So, a credible group of Rustaceans and their backers need to come up with a plan to do it. It doesn't have to be antagonistic -- it's exploratory. If it works out well, it's a lot easier to adopt once the imagined issues are resolved or evaporated. Subsystem by subsystem would be my suggestion. And just…
> FOSS evolves past its chokepoints by forking.
Unless you've been already invited into the project?
Re: We are the "thin blue line" that is trying to keep the code high quality
#126Earlier quoted context omitted.
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…
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.
Re: We are the "thin blue line" that is trying to keep the code high quality
#127The 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.
What happened here? Years ago Linus was talking about how he thought positively about Rust in the Kernel in the future if the kinks could be worked out. Now a group of people have built out a set of drivers which are working great, well tested and integrated, and one maintainer has decided they just don't want to merge it so the whole project is indefinitely stalled.
I'd be pretty upset if I was working on Asahi since the Linux project has basically bait and switched them after an enormous amount of work has been invested.
Re: We are the "thin blue line" that is trying to keep the code high quality
#128Earlier 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.
They don't owe me anything, I don't work on it and have no oar in one way or the other. I'm sure they don't give a fuck about any of these conversations. Still, I owe you nothing and I can put forth my opinion, as can you.
Re: We are the "thin blue line" that is trying to keep the code high quality
#129Earlier 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.
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.
Re: We are the "thin blue line" that is trying to keep the code high quality
#130Earlier quoted context omitted.
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
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.