9 ms·
We are the "thin blue line" that is trying to keep the code high quality
- deleted 2y ago[deleted]
- ysofunny 2y agowhy cannot more people learn about git and branching you want your merges in? patch it in your own branch the real crux of the issue is the quality of "the offical version", the real issue, then, is about official branding. I remember back in the day there were multiple kernel versions by different mantainers.... then again I'm probably missing the forest for the trees or something
- percentcer 2y agomarcan addresses this argument in an adjacent thread: > Out of tree doesn't work. People, both in the kernel and out of the kernel, want things in tree. https://lore.kernel.org/lkml/1e8452ab-613a-4c85-adc0-0c4a293dbf50@marcan.st/ https://lore.kernel.org/lkml/1e8452ab-613a-4c85-adc0-0c4a293...
- LorenDB 2y agoThere are still a few custom kernels out there. Liquorix comes to mind. https://liquorix.net/ https://liquorix.net/
- Gigachad 2y agoBecause forked kernels is how we ended up with all those SBCs which could only run some ancient version of linux. If you can't mainline it, you are committing to maintaining a fork forever, and the more changes you require, the more maintenance that fork will be. The Linux kernel quite intentionally makes maintaining a fork a pain in the ass to pressure vendors to mainline their drives. But now mainline maintainers are refusing to accept those drivers. So it's unlikely we will ever see Macbooks properly supported on Linux.
- Mr_Bees69 2y agoUpstreaming to linux-zen might work, not a kernel dev tho.
- account42 2y agoBut the Rust advocates are already telling everyone that they will handle all maintenance of rust code in the kernel and existing maintainers won't have to do a thing. If that was true it wouldn't matter if the rust code is in a separate tree.
- WhyNotHugo 2y agoThe 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).
- ysofunny 2y agomaybe 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
- dikei 2y agoIt'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.
- yuliyp 2y agoThe VCS has nothing to do with it. Code has all sorts of subtle dependencies. When changes are made, other things are liable to break. When they're in someone else's fork, the person making the change is obviously not going to make sure that fork will stay working. Either the change is accepted upstream meaning that everyone else making changes to the mainline needs to keep it working, or it isn't and they don't.
- muamoe 2y agoMaintaining a fork is not difficult because we haven't invented the right VCS.
- deleted 2y ago[deleted]
- foxes 2y agoCalling yourself the “thin blue line” like a reference to police really doesn’t seem like a way to have an enduring community. Police don’t serve the community; I guess they think in the same way then.
- anon-3988 2y agoPolice in your area maybe?
- adastra22 2y agoLook 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.
- quartzic 2y agoRelated: https://news.ycombinator.com/item?id=43036904 https://news.ycombinator.com/item?id=43036904
- dang 2y agoThanks! Macroexpanded: Resigning as Asahi Linux project lead - https://news.ycombinator.com/item?id=43036904 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 https://news.ycombinator.com/item?id=42972062 - Feb 2025 (1015 comments)
- oxnrtr 2y agoNext resignation: Me stepping down as a nouveau kernel maintainer – https://lists.freedesktop.org/archives/nouveau/2025-February/046677.html https://lists.freedesktop.org/archives/nouveau/2025-February...
- micromacrofoot 2y agonot the phrase I'd choose to associate with, even metaphorically
- IncreasePosts 2y ago[flagged]
- micromacrofoot 2y agounfortunately I did read it
- veidr 2y agoThis 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 https://en.wikipedia.org/wiki/Thin_blue_line
- skrtskrt 2y agoit'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
- veidr 2y agoYeah, 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.
- micromacrofoot 2y agothe association with police has always been tied to white nationalism, the only change is that the association has become mainstream
- reactordev 2y agoThe problem is aging code sours like milk. I empathize but we need to have people take over these initiatives and refactor them into something easier the maintain. Not saying introduce a new language or anything but change how we fundamentally look at “The Kernel”. I think reducing scope and making it so hardware providers must maintain their drivers is a good start. If your toolchain doesn’t suffice, create a new tool. If rust is so much better, create a new kernel in rust and force a paradigm shift. I think we can do better than bicker and fight over it and post email chains about it. Bring solutions. Tech debt is just OpEx to everyone else.
- jfbfkdnxbdkdb 2y agoThere is redox os
- beeflet 2y agoIt'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, compared to C/C++ which have more distributed development.
- deleted 2y ago[deleted]
- pabs3 2y agoThe Rust community does seem to be more focused on non-copyleft licenses, do you have any ideas why that is?
- beeflet 2y agonope, but I encounter it a lot. For example, the default cargo template or whatever just gives you a non-copyleft license https://github.com/cargo-generate/cargo-generate https://github.com/cargo-generate/cargo-generate . There are a lot of questionable defaults in this space, like the ecosystem encouraging people to use a centralized repository like crates.io which requires github (now owned by microsoft). I figure it's because the companies and orgs that started working with and investing in the rust ecosystem start by contributing to the compiler, which is non-copyleft and just try to extend that because it works to their advantage. You see this with a lot of languages/ecosystems with corporate sponsors, but also just because it gives you a unique selling point in an area where copyleft software dominates. Like, there will always be some company (like imagine a defense company) that absolutely refuses to publish all of their changes, so that represents a niche that can sustain smaller permissive projects. I think that for an individual corporation, permissive is better and they won't make a decision to go copyleft unless forced. But for the ecosystem as a whole, GPL is better for business (especially when it comes to something like a kernel) because it forces companies to publicly fork over their drivers and collaborate, and reduces the competitive advantage vs companies that would otherwise not publish their changes if it was permissive. That was probably too many words. Anyways, it would be nice to see some of this improved, i think it's a great language and will probably replace C++.
- jeffbee 2y agoPre-supposes existing high quality, a fact not in evidence.
- account42 2y agoWhat are the higher quality alternatives of similar scope you are comparing against?
- makeitdouble 2y ago> the engineers which contribute the code will disappear From the other side, as a very occasional contributor, I'd actually want to deal with fixes or reviews around the code I contribute. But it's usually edge cases on otherwise stable and mature libraries, so hopefully it probably won't happen more than say once in a decade. If I got a mention on a PR I'd reappear, but that doesn't sound like the standard way, I never got involved again on anything submitted. I feel like either the maintainers are doing an incredibly good job at vetting the PRs, or got used to deal with the aftermath another way and just don't need the original code submitter to reappear most of the time ? Am I missing some bigger part of it ?
- arjie 2y agoThe 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 changed vim. But c'est la vie. Egcs vs. gcc was a big deal back in the day and in the end we ended up with gcc by the egcs guys and that was it. When you win, everyone forgets the 'drama' existed. When you lose, everyone remembers you as just the drama guy. RMS had the drama label for decades. Things are not even different. They're the same again. It's like when you'd buy those Chinese NES dupes and they'd have 999 levels of Mario but half the levels would be the same but with different colour bricks. Isomorphic to original but distinct. That's this story.
- patrick451 2y ago> 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.
- dralley 2y agoThere 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.
- Mr_Bees69 2y ago[flagged]
- forgetfreeman 2y agoThe burden of proof isn't on maintainers. Recognizing new, untried code invariably means bugs and instability to work through, often for questionable gains, is a mark of an experienced developer. Work your way through enough industry hype cycles and you'll see, new shit just causes new and usually weirder problems than whatever it was intended to replace.
- thayne 2y ago> But what isn't appreciated, is that it is precisely because people who are long-term members of the community are trusted to stick around and will support code that the have sponsored. Ok. But if you make it too difficult for new developers to contribute, and the experience too stressful, then no one new will stick around to be long time maintainers, and when the old ones retire or die, there won't be anyone to replace them.
- polishdude20 2y agoSame thing happening with ham radio.
- mouse_ 2y agoThe whole community shows symptoms of organizational sabotage. https://files.catbox.moe/u6rold.png https://files.catbox.moe/u6rold.png
- ambicapter 2y agoSabotage or just the inevitable ways that organizations tend to decay (not that they have to, but if they do it tends to look a certain way).
- shae 2y agoI tried to help with the Linux kernel once in 2001 or so. I decided my calm was worth more than dealing with abrasive kernel devs.
- jf 2y ago> One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we know, through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contribute the code will disappear, never to be seen again. This was painful for me to read as someone who has seen how corporations think about “Open Source” - he isn’t wrong at all
- Diggsey 2y agoHe'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 maintainers need to figure out among themselves whether they want to allow Rust to be introduced or not, and if so under what constraints. If they can't come to an agreement, they're wasting everyone's time. Once that happens, either the project is canned, or people can stop arguing over if these changes should be upstreamed, and start arguing over how instead, and that's a lot more productive.
- llm_trw 2y agoIt'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.
- Diggsey 2y agoNoone'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 decision regarding R4L.
- strstr 2y agoBeing 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 subsystem I depend on (and occasionally contribute to directly) it’s kinda assumed it will take at least a year (probably two) for any substantial project to get merged. This continuously disappoints PMs and Leadership. A lot of people, understandably, chafe against this lack of agility. OTOH, I’ve been on the other side of kernel bugs. Most recently, a memory arithmetic bug was causing corruption, and took my team at least an engineer year to track down. This makes me quite sympathetic to maintainers demands for quality. I’ve also been on the other side of the calibration discussions where Open Source work goes under appreciated. The irony never stops (“They won’t merge our patches!” “Are you having your engineers review theirs?”). That and the raw pipeline issues for maintainers (it takes a lot of experience to be a maintainer, which implies spending a lot of a bright engineer’s time on reviewing and contributing upstream to things unrelated to immediate priorities).
- skrtskrt 2y agoa 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.
- strstr 2y agoThis 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).
- mschoch 2y ago[flagged]
- bigolkevin 2y agoFor real. I have a great deal of support for maintainers but that comparison is the quickest way for you to lose it.
- markhahn 2y ago[flagged]
- muamoe 2y ago[flagged]
- ecshafer 2y ago[flagged]
- harimau777 2y agoI think that there's potentially a couple of things at play here: Taken literally, the idea of a "thin blue line" protecting society from chaos has some authoritarian overtones. It's a slogan that tends to be used to simply dismiss problems like police brutality. That is to say, it comes across less like a difference in policy position and more like indifference to the suffering of others. The political faction that it's associated with, i.e. MAGA, is currently in the process of attempting to purge anyone with a worldview that they dislike from public society. All of those factors creates a situation where it is difficult for those who use signifiers like "thin blue line" to practically operate simply as "people who happen to be conservative" as opposed to "people who represent an irreconcilable threat to people they disagree with".
- NewJazz 2y agoDo you bring politics into the workplace when it is not relevant?
- chris_wot 2y agoI 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 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.
- muamoe 2y agoMaybe they're tired of the Rust Evangelism Strike Force.
- chris_wot 2y agoWhich means they can't explain interface semantics?
- skrtskrt 2y agoyeah he managed to try to sound reasonable and measured for most of that, then: > including an upstream language community which refuses to make any kind of backwards compatibility guarantees, and which is actively hostile to a second Rust compiler implementation (I suspect because it might limit their ability to make arbitrary backwards-incompatble language changes). with the full context of all of this it is quite obvious this is just a classic case of a software engineer being an antisocial jerk with strange vendettas in their head and who thinks the strange personal opinions they came up with in their basement are unassailable facts
- mustache_kimono 2y ago>> including an upstream language community which refuses to make any kind of backwards compatibility guarantees, and which is actively hostile to a second Rust compiler implementation (I suspect because it might limit their ability to make arbitrary backwards-incompatble language changes). The guy is a poster who just can't help himself! Both points are demonstrably false.
- greenavocado 2y agoMore shots fired at Linus (justifiably so) https://lore.kernel.org/lkml/6e3e26c7-002a-49c6-a3a8-1cc1b8941f57@kkx.one/ https://lore.kernel.org/lkml/6e3e26c7-002a-49c6-a3a8-1cc1b89...
- oguz-ismail 2y ago> I'm just a Linux user watching this shitshow unfold Yet he can't even put up his real name. Pathetic
- account42 2y ago"Shots fired" from a random anonymous person? Everyone can send their rant to LKML, that doesnt mean anything.
- anonymousiam 2y agoTed's a great guy. I haven't interacted with him for over 20 years, but IMHO, he's a rock star.
- skrtskrt 2y agoA 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 decades, if not through their attitudes and lack of interpersonal skills, then through impenetrable build systems and hostility towards ergonomic changes. But forget the eager amateurs - it is unconscionable that major technology companies & cloud providers don't each have damn near an army helping out with Linux and similar technologies - even the parts that do not directly benefit them! - instead of just shoving it into servers so they can target ads for cheap plastic crap 0.000000001% better than they did last week.
- shkkmo 2y ago> Further, the fact that so many of those maintainers are purely on volunteer time. Greg pointed out in that email thread that: > over 80% of the contributions come from company-funded developers. [1] [1] https://lore.kernel.org/lkml/2025020738-observant-rocklike-75cc@gregkh/ https://lore.kernel.org/lkml/2025020738-observant-rocklike-7...
- cle 2y agoIs that really the right statistic? Seems like the relevant one would be the number of maintainers whose maintenance work is company-funded. (Ex, I'd imagine it would be quite bad if most contributions were from company-funded developers but had to be upstreamed by non-company-funded volunteers.)
- shkkmo 2y agoFrom other discussion in that thread, it does appear that most maintainers are employed by companies to work on Linux. That doesn't mean that all the work these maintainers do is paid, as there are also comments indicating that many of these paid contributors do work on their own time when it doesn't align with their company priorities. I posted that statistic to demonstrate that the kernal project isn't a typical underfunded, almost purely volunteer open source project as implied by many of the kneejerk comments here.
- __d 2y agogcc 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.
- mustache_kimono 2y ago> FOSS evolves past its chokepoints by forking. Unless you've been already invited into the project?
- __d 2y agoUnless I’m mistaking things, there’s still multiple roadblocks? Just because some people have invited you in doesn’t mean everyone is welcoming.
- mustache_kimono 2y ago> 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.
- fabiofzero 2y agoThey couldn't have used a worst name if they tried.
- drewcoo 2y agoThat seems like a fundamental misunderstanding of policing. Maintainers seem more like HOA boards than police.
- boatrocker 2y ago[flagged]
- awalsh128 2y agoI like to think of us at the thin blinking cursor.
- anonfordays 2y agoIf comments as benign as "thin blue line" causes fragile entryist/activists to flee, I say Ted and the kernel team are doing the right thing. Projects as critical as the Linux kernel shouldn't be battlegrounds for the grievance of the week, nor should they be platforms for proselytizing. Others like him leave long paths of destruction in their wake. Lots of projects have been turned upsidedown by the drama they seem to bring with them everywhere. The salient point is contributors need to be more than "drive by" submitters for their pet projects. This isn't specific to Rust in the kernel, look at how much of an uphill battle bcachefs was/is.