12 ms·

Marcan links to an email by Ted Tso'o (https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.

Marcan links to an email by Ted Tso'o (https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...) that is interesting to read. Although it starts on a polarising note ("thin blue line"), it does a good job of explaining the difficulties that Linux maintainers face and why they make the choices they do. It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining it after that. They have maximum leverage at review time, and 0 leverage after. It also makes sense to relax that attitude for someone in the old boys' network because you know they'll help maintain it in the future. So far so good. A really good look into his perspective. And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false? - "an upstream language community which refuses to make any kind of backwards compatibility guarantees" -> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. - "which is actively hostile to a second Rust compiler implementation" - except that isn't true? Here's the maintainer on the gccrs project (a second Rust compiler implementation), posting on the official Rust Blog -> "The amount of help we have received from Rust folks is great, and we think gccrs can be an interesting project for a wide range of users." (https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust.html https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-c...) This is par for the course I guess, and what exhausts folks like marcan. I wouldn't want to work with someone like Ted Tso'o, who clearly has a penchant for flame wars and isn't interested in being truthful.

deleted 2y ago
[deleted]
Certhas 2y ago
It's also not truthful because many of the Rust maintainers are long time C contributors. Marcan also linked to this resignation of a Rust Maintainer: https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@gmail.com/ https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@... which references this fantastic exchange: https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s I am not a C person, or a kernel level person, I just watch this from the sideline to learn something every now and then (and for the drama). But this exchange is really stunning to me. It seems so blatantly obvious to me that systematically documenting (in code!) and automatically checking semantic information that is required to correctly use an API is a massive win. But I have encountered this type of resistance (by very smart developers building large systems) in my own much smaller and more trivial context. To some degree, the approach seems to be: "If I never write down what I mean precisely, I won't have to explain why I changed things." A more charitable reading of the resistance is: Adding a new place where the semantics are written down (code, documentation and now type system) gives one more way in which they can be out of sync or subtly inconsistent or overly restrictive. But yeah, my intuitive reaction to the snippet above is just incredulity at the extreme resistance to precisely encoding your assumptions.
- mietek 2y ago
  Your charitable reading is too charitable. One of the benefits of using types to help guarantee properties of programs (e.g. invariants) is that types do not get out of sync with the code, because they are part of the code, unlike documentation. The language implementation (e.g. the compiler) automatically checks that the types continue to match the rest of the code, in order to catch problems as early as possible.
  - diggan 2y ago
    I'm not a kernel developer, and never done anything of the sorts either. But, I think the argument is that if they have two versions of something (the C version + the Rust bindings), the logic/behavior/"semantics" of the C version would need to be encoded into the Rust types, and if a C-only developer changes the C version only, how are they supposed to proceed with updating the Rust bindings if they don't want to write Rust? At least that's my understanding from the outside, someone please do correct me if wrong.
    - bcrosby95 2y ago
      That was a large part of the disagreement. Rust developers were saying it would be their job to do this. But then someone said Linus rejected something because it broke Rust. GKH backed the Rust developers and said that was an exception not a rule, but didn't know Linus' stance for sure. Then Linus chimes in because of one of Hector's replies, but at the time of my reading did not clarify what his actual stance is here.
      - ChocolateGod 2y ago
        > but at the time of my reading did not clarify what his actual stance is here. Whatever he says is guaranteed to piss off at least one side of the argument.
        rekoil 2y ago
        Yeah it's not an easy discussion for sure, but he has to say something. At the rate we're going here the existing kernel devs will alienate any capable new blood, and Linux will eventually become Google Linux(TM) as the old guard goes into retirement and the only possible way forward is through money.
diggan 2y ago
> And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false? Many discussions online (and offline) suffer from a huge-group of people who just can't stop themselves from making their knee-jerk reactions public, and then not thinking about it more. I remember the "Filesystem in Rust" video (https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s) where there are people who misunderstand what the "plan" is, and argue against being forced to use Rust in the Kernel, while the speaker is literally standing in front of them and saying "no one will be forced to use Rust in the Kernel". You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true. I personally don't know how to deal with this either, and tend to just leave/stop responding when it becomes clear people aren't looking to collaborate/learn together, but instead just wanna prove their point somehow and that's the most important part for them.
- nindalf 2y ago
  If you watch that YouTube link, you'll see the same guy Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust". I think he apologised for this flagrant comment, but this email shows he hasn't changed his behaviour in the slightest.
  - uecker 2y ago
    His email seems very reasonable to me (the thin-blue-line comment is a bit weird though). To me the problem are that some Rust people seem to expect that the Linux maintainers (that put in a tremendous amount of work) just have to go out of their way to help them achieve their goals - even if the maintainers are not themselves convinced about it and later have to carry the burden.
    - Ar-Curunir 2y ago
      How many times will this need to be said: the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.
Ntrails 2y ago
That's useful context because as a complete laymen I thought his message was largely reasonable (albeit I am not unsympathetic to the frustration of being on the other side)!
- dapperdrake 2y ago
  Here is what I learned the hard way: the request sounds reasonable. And that doesn’t matter (sucks, I know.) Here is the only thing that matters in the end (I learned this an even harder way. I really worked like the L4R people approach this and was bitten by counter-examples left, right, and center): The Linux Kernel has to work. This is even more important than knowing why it works. There is gray area and you only move forward by rejecting anything that doesn’t have at least ten years of this kind of backwards compatible commitment. All of it. Wholesale. (And yes, this blatantly and callously disregards many gods efforts sounding like the tenuous and entitled claim "not good enough".) But it’s the only thing that has a good chance of working. Saying that gravity is a thing is not the same attitude as liking that everyone is subject to gravity. But hoping that gravity just goes away this once is wishful thinking of the least productive kind. Rust is not "sufficiently committed" to backwards compatibility. Firstly, too young to know for sure and the burden is solely on "the rust community" here. (Yes, that sucks. Been there.) Secondly, there were changes (other posters mentioned "Drop") and how cargo is treated that counter indicate this. Rust can prove all the haters wrong. They will then be even more revered that Linux and Debian. But they have to prove this. That is a time consuming slog. With destructive friction all the way. This is the way.
cornstalks 2y ago
> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. Unfortunately OP has a valid point regarding Rust's lack of commitment to backwards compatibility. Rust has a number of things that can break you that are not considered breaking changes. For example, implementing a trait (like Drop) on a type is a breaking change[1] that Rust does not consider to be breaking. [1]: https://users.rust-lang.org/t/til-removing-an-explicit-drop-impl-and-relying-on-drop-glue-is-a-breaking-change/56763 https://users.rust-lang.org/t/til-removing-an-explicit-drop-...
- cratermoon 2y ago
  I'm curious now. What are the backwards compatibility guarantees for C?
  - cornstalks 2y ago
    As long as you compile with the version specified (e.g., `-std=c11`) I think backwards compatibility should be 100%. I've been able to compile codebases that are decades old with modern compilers with this.
    - joshkel 2y ago
      In practice, C has a couple of significant pitfalls that I've read about. First is if you compile with `-Werror -Wall` or similar; new compiler diagnostics can result in a build failing. That's easy enough to work around. Second, nearly any decent-sized C program has undefined behavior, and new compilers may change their handling of undefined behavior. (E.g., they may add new optimizations that detect and exploit undefined behavior that was previously benign.) See, e.g., this post by cryptologist Daniel J. Bernstein: https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8GGp2K1DAAJ https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8...
      - uecker 2y ago
        Why not entirely wrong, the UB issues are bit exaggerated in my opinion. My C code from 20 years ago still works fine even when using modern compilers. In any case, our plan is to remove most of UB and there is quite good progress. Complaining that your build fails with -Werror seems a bit weird. If you do not want it, why explicitly request this with -Werror?
School-Cotton 2y ago
> Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. This is a very persistent myth, but it’s wrong. Adding any public method to any impl can break BC (because its name might conflict with a user-defined method in a trait), and the Rust project adds methods to standard library impls all the time.
- purplesyringa 2y ago
  This is true, strictly speaking, but rarely causes problems. Inherent methods are prioritized over trait methods, so this only causes problems if two traits suddenly define a single method, and the method is invoked in an ambiguous context. This is a rare situation, and std thrives to prevent it. For example, in [1], a certain trait method was called extend_one instead of push for this reason. Crater runs are also used to make sure the breakage is as rare as T-libs-api has expected. The Linux kernel in particular only uses core and not std, which makes this even more unlikely. [1]: https://github.com/rust-lang/rust/issues/72631 https://github.com/rust-lang/rust/issues/72631
  - School-Cotton 2y ago
    Okay, but “they try to avoid issues” is not the same as “they guarantee never to intentionally break BC except to fix compiler bugs”.
- sophacles 2y ago
  That's just not true. If the user has defined on the struct and a trait also has the method name, the struct's impl is used. Multiple traits can have methods named the same too. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ff49076bd187d56c6980d2d0881906f8 https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - School-Cotton 2y ago
    My comment might have been technically wrong as originally stated; I’ve since edited to try to correct/clarify. What I really meant is the case where a method is added to a standard struct impl that conflicts with a user-defined trait. For example, you might have implemented some trait OptionExt on Option with a method called foo. If now a method called foo is added to the standard option struct, it will conflict.
uhgrippa 2y ago
These are often the same classification of individual who tend to modify their viewpoints towards “change is progressing rapidly in an area that I don’t understand and this scares me.” Anytime an expert in a particular area has their expertise challenged or even threatened by a new technology it is perfectly human to react in a way that is defensive towards the perceived threat. Part of growth as a human is recognizing our perceived biases and attempting to mitigate them, hopefully extending this into other areas of our lives as well. After all, NIMBYS probably started out with reasonable justifications for why they want to keep their communities the way they currently are - it’s comfortable and it works, and they’re a significant contributor to the community. Any external “threat” to this concept becomes elevated to a moral crusade against the invaders who are encroaching upon their land, when really they’re jousting against windmills.
- mcosta 2y ago
  Or "change is progressing rapidly in an area I am working 20 years and I have seen this kind of thing failing before"
  - uecker 2y ago
    I think confronting those volunteers that maintain open-source software with arguments such as "you just do not want to learn new things" , "are scared of change", etc. is very unfair. IMHO new ideas should prove themselves and not pushed through because google wants it or certain enthusiastic groups believe this is the future. If Rust is so much better, people should just build cool stuff and then it will be successful anyway.
    - znpy 2y ago
      This isn't the first time a new language is proposed for the kernel though. At some point there was some brief discussion for C++ in the kernel and that was essentially immediately killed by Linus. And he was essentially right.
    - uecker 2y ago
      Overall, this whole situation seems entirely weird to me. All this stuff such as Unix, Linux, and C ecosystem was build by C programmers and maintained for decades mostly voluntarily, while most of the industry pushed into other directions (with a gigantic influx of money). It is completely amazing that Linux become so successful against all the odds. Certainly it also then had a lot industry support, but I used it already before most of this and witnessed all the development. But somehow, C programmers are now suddenly portrayed as the evil gatekeepers, not stepping aside fast enough, because some want to see change. In the past, the people wanting to see something new in the open-source community would need to convince the community by building better things, not by pushing aggressively into existing projects.
parasense 2y ago
> This is par for the course I guess, and what exhausts folks like marcan. I wouldn't want to work with someone like Ted Tso'o, who clearly has a penchant for flame wars and isn't interested in being truthful. I am acquainted with Ted via the open source community, we have each other on multiple social media networks, and I think he's a really great person. That said, I also recognize when he gets into flame wars with other people in the open source social circles, and sometimes those other people are also friends or acquaintances. I can think of many times Ted was overly hyperbolic, but he was ultimately correct. Here is the part of the Linux project I don't like sometimes, which was recently described well in this recent thread. Being correct, or at least being subjectively correct by having extremely persuasive arguments, yet being toxic... is still toxic and unacceptable. There are a bazillion geniuses out there, and being smart is not good enough anymore in the open source world, one has to overcome those toxic "on the spectrum" tendencies or whatever, and be polite while making reasonable points. This policy extends to conduct as well as words written in email/chat threads. Ted is one of those, along side Linus himself, who has in the past indulged into a bit of shady conduct or remarks, but their arguments are usually compelling. I personally think of these threads in a way related to calculus of infinitesimals, using the "Standard Parts" function to zero away hyperbolic remarks the same way the math function zeros away infinitesimals from real numbers, sorta leaving the real remarks. This is a problem, because it's people like me, arguably the reasonable people, who through our silence enable these kind of behaviours. I personally think Ted is more right than wrong, most of the time. We do disagree sometimes though, for example Ted hates the new MiB/KiB system of base-2 units, and for whatever reasons like the previous more ambiguous system of confusingly mixed base-10/base-2 units of MB/Mb/mb/KB/Kb/kb... and I totally got his arguments that a new standard makes something confusing already even more confusing, or something like that. Meh...
- throwaway2037 2y ago
  > I can think of many times Ted was overly hyperbolic, but he was ultimately correct. Here is the part of the Linux project I don't like sometimes, which was recently described well in this recent thread. Being correct, or at least being subjectively correct by having extremely persuasive arguments, yet being toxic... is still toxic and unacceptable. I want to say that I am thankful in this world that I am a truly anonymous nobody who writes codes for closed-source mega corp CRUD apps. Being a tech "public figure" (Bryan Cantrill calls it "nerd famous") sounds absolutely awful. Every little thing that you wrote on the Internet in the last 30 years is permanently recorded (!!!), then picked apart by every Tom, Dick, Harry, and Internet rando. My ego could never survive such a beating. And, yet, here we are in 2025, where Ted T'so continues to maintain a small mountain of file system code that makes the Linux world go "brrr". Hot take: Do you really think you could have done better over a 30 year period? I can only answer for myself: Absolutely fucking not. I, for one, am deeply thankful for all of Ted's hard work on Linux file systems.
yellowapple 2y ago
> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. The community is more than just the language and compiler vendor(s). It's everyone using the language, with particular emphasis on the developers of essential libraries and tools that those users use and on which they're reliant. In this sense, based on every time I've attempted to use Rust (even after 1.0), Ts'o's remark ain't inaccurate from what I can tell. If I had a nickel for every Rust library I've seen that claims to only support Rust Nightly, I'd have... well, a lot of nickels. Same with Rust libraries not caring much about backward-compatibility; like yeah, I get it during pre-1.0, or while hardly anyone's using it, but at some point people are using it and you are signaling that your library's "released", and compatibility-breaking changes after that point make things painful for downstream users. > Here's the maintainer on the gccrs project (a second Rust compiler implementation), posting on the official Rust Blog Same deal here. The Rust developers might be welcoming of additional implementations, but the broader community might not be. I don't have enough information to assess whether the Rust community is "actively hostile" to a GCC-based Rust implementation, but from what I can tell there's little enthusiasm about it; the mainstream assumption seems to be that "Rust" and its LLVM-based reference compiler are one and the same. Maybe (hopefully) that'll change. ---- The bigger irony here, in any case, is that the Linux community has both of these very same problems: - While the kernel itself has strict backwards-compatibility guarantees for applications, the libraries those applications use (including absolutely critical ones like glibc) very much do not. The ha-ha-only-serious observation in the Linux gaming community is that - thanks to Wine/Proton - the Windows API is the most stable ABI for Linux applications. Yeah, a lot of these issues are addressable with containerization, or by static compilation, but it's annoying that either are necessary for Linux-native applications to work on old and new distros alike. - As marcan alludes to in the article, the Linux community is at least antipathetic (if not "actively hostile") to Linux-compatible kernels that are not Linux, be they forks of Linux (like Android) or independent projects that support running Linux applications (WSL 1/2, FreeBSD, some illumos distros, etc.). The expectation is that things be upstreamed into "the" Linux, and the norms around Linux development make out-of-tree modules less-than-practical. This is of course for good reason (namely: to encourage developers to contribute back to upstream Linux instead of working in silos), but it has its downsides - as marcan experienced firsthand.
judofyr 2y ago
> "which is actively hostile to a second Rust compiler implementation" - except that isn't true? Historically the Rust community has been extremely hostile towards gccrs. Many have claimed that the work would be detrimental to Rust as a language since it would split the language in two (despite gccrs constantly claiming they're not trying to do that). I'm not sure if it was an opinion shared by the core team, but if you just browse Reddit and Twitter you would immediately see a bunch of people being outright hostile towards gccrs. I was very happy to see that blog post where the Rust leadership stepped up to endorse it properly. Just one reference: In one of the monthly updates that got posted on Reddit (https://old.reddit.com/r/rust/comments/1g1343h/an_update_on_gccrs_development_lwnnet/ https://old.reddit.com/r/rust/comments/1g1343h/an_update_on_...) a moderator had to write this: > Hi folks, because threads on gccrs have gotten detailed in the past, a reminder to please adhere to the subreddit rules by keeping criticism constructive and keeping things in perspective.
- kibwen 2y ago
  The LKML quote is alleging that the upstream language developers (as opposed to random users on Reddit) are opposed to the idea of multiple implementations, which is plainly false, as evidenced by the link to the official blog post celebrating gccrs. Ted T'so is speaking from ignorance here.
  - vlovich123 2y ago
    I think it’s more pointed towards people like me who do think that gccrs is harmful (I’m not a Rust compiler/language dev - just a random user of the language). I think multiple compiler backends are fine (eg huge fan of rustc_codegen_gcc) but having multiple frontends I think can only hurt the ecosystem looking at how C/C++ have played out vs other languages like Swift, Typescript etc that have retained a single frontend. In the face of rustc_codegen_gcc, I simply see no substantial value add of gccrs to the Rust ecosystem but I see a huge amount of risk in the long term.
  - judofyr 2y ago
    (emphasis mine) > opposed to the idea of multiple implementations, which is plainly false, as evidenced by the link to the official blog post celebrating gccrs. Ted T'so is speaking from ignorance here. Why use so strong words? Yes, there's clearly a misunderstanding here, but why do we need to use equally negative words towards them? Isn't it more interesting to discuss why they have this impression? Maybe there's something with the communication from the upstream language developers which hasn't been clear enough? It's a blog post which is a few months old so if that's the only signal it's maybe not so strange that they've missed it? Or maybe they are just actively lying because they have their own agenda. But I don't see how this kind of communication, assuming the worst of the other part, beings us any closer.
throwaway2037 2y ago
Thank you to share the Ted T'so LKM post. Can you explain the culture reference "thin blue line"? I never heard it before.
- jsk2600 2y ago
  The "thin blue line" is a term that typically refers to the concept of the police as the line between law-and-order and chaos in society.[1] The "blue" in "thin blue line" refers to the blue color of the uniforms of many police departments. [1] https://en.wikipedia.org/wiki/Thin_blue_line https://en.wikipedia.org/wiki/Thin_blue_line
- Suzuran 2y ago
  It's a motto used by American law enforcement to justify extrajudicial punishment. Since they are the "thin blue line" that separates the public from anarchy, they are justified in acting independently to "protect" us when judges and juries do not "cooperate".
  - patmorgan23 2y ago
    Not just extrajudicial punishment, but overlooking corrupt acts and crimes from fellow officers. That it's more important to maintain the 'brotherhood' than to arrest an officer caught driving home drunk.
  - milesrout 2y ago
    That is a very strange take. The phrase isn't American and has no negative connotation. It has nothing to do with "extrajudicial punishment". It simply refers to the (obvious) fact that what separates societies from anarchy is the "thin blue line" of law enforcement. Rowan Atkinson had a sitcom set in a London police station in the 90s called "The Thin Blue Line". Are you under the impression he was dogwhistling about extrajudicial violence?
    - mijoharas 2y ago
      This is what really confused me about the article. I read the mailing list post and had no idea what was controversial about thin blue line. In fact, I thought most of that post was fairly reasonable. I'd never heard of the extrajudicial punishment aspect of the phrase (though I had heard the phrase itself) and it didn't show up when I googled, but I'm not American, so maybe there's some cultural differences.
scottlamb 2y ago
> - "an upstream language community which refuses to make any kind of backwards compatibility guarantees" -> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. The most charitable interpretation I can imagine is that the Rust-in-Linux project needs specific nightly features, and those don't get stability guarantees. But I think this is still pretty unfair to complain about; my impression is there's a lot of appetite on the Rust side to get those stabilized. I also think... > 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. ...that while there's truth in this, there's also a large extent to which it's a self-fulfilling prophecy. Someone might want to stick it out to get their work into mainstream once, but then take a look at the process once it's in the mirror and say never again. ...and: > Instead of complaining about maintainers for who are unreasonably caring about these things, when they are desparately under-resourced to do as good of a job as they industry demands, how about meeting us half-way and helping us with these sort of long-term code health issues? It's really hard for me to not see "let's actually write down the contract for these functions, ideally via the type system" as doing exactly that. Which seems to me to be the central idea Ted Ts'o was ranting about in that infamous video.
j45 2y ago
Perhaps merge requests should have to go through a process of learning the codebase first, and submitting increasingly more complex fixes before jumping to really complex requests. It can be hard when solving your own acute issue - doing so doesn't mean it is the only fix or the one the project should accept. Even if it's beneath someone's talent to have to do it, it is an exercise of community building.
kllrnohj 2y ago
> which is actively hostile to a second Rust compiler implementation Which is hilarious since Linux itself was actively hostile to the idea of a second C compiler supporting it. Just getting Linux to support Clang instead of only GCC was a monumental task that almost certainly only happened because Android forced it to happen.
- tuna74 2y ago
  It happened because the Android people put in the work to make it happen both in Linux and in Clang/LLVM.
  - kllrnohj 2y ago
    Putting in the work is one thing, which is what the Rust-in-Linux people are also doing, but there's also the political requirement to force maintainers to accept it. Android was big enough, and happy enough to fork seeing as it had already done that before, that it forced a lot of hands with top-down mandates. Rust, despite having Linus' blessing to be in the kernel, is still just getting rejected just because it's Rust, completely unrelated to any technical merits of the code itself.
  - ndesaulniers 2y ago
    hello!
anonfordays 2y ago
If 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. Marcan and 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.
- adamrezich 2y ago
  Quite wild to see this being downvoted, because by downvoting, surely one implies the inverse of your post to be the truth, such that projects such as the Linux kernel should be battlegrounds for the grievance of the week, should be platforms for proselytizing, and so forth. Very strange to see little to no empathy for kernel maintainers in this situation.
  - PoignardAzur 2y ago
    Most people would not interpret downvoting as "I believe that the exact opposite of every single sentence in your post is true".
    - adamrezich 2y ago
      Most people don't compulsively downvote every post that they only mildly disagree with.
      - PoignardAzur 2y ago
        Look, I don't know what to say without just assuming you're approaching this discussion in bad faith. Saying people "compulsively downvote" the stuff above is already a strong claim that you have no way to substantiate. I think more broadly what you're claiming is that the people downvoting you and anonfordays are emotional and doing so out of political zealotry, and... again, that a pretty strong claim. People can downvote a post not because they strongly disagree with its claims, but because they strongly dislike its inflammatory tone ("fragile entryist", "Marcan and others like him leave long paths of destruction in their wake", etc). People who strongly disagree with a post don't necessary believe the exact opposite of its claims. They can disagree with some of the claims and agree with others, or disagree with the very framing of the post. If I say "we should outlaw all guns because gun crimes are awful" and you disagree, that doesn't mean you think gun crimes are great.
dataflow 2y ago
> It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining it after that. They have maximum leverage at review time, and 0 leverage after. I don't follow. The one with zero leverage is the contributor, no? They have to beg and plead with the maintainers to get anything done. Whereas the maintainers can yank code out at any time, at least before when the code makes it into an official stable release. (Which they can control - if they're not sure, they can disable the code to delay the release as long as they want.)
- tuna74 2y ago
  Maintainers can't yank out code if that leads to feature, performance or user space regressions.
  - janice1999 2y ago
    Entire filesystems and classes of drivers have been purged from the kernel over time. Removing stuff is not impossible as some here suggest.
    - tuna74 2y ago
      Yes, but removing stuff takes a lot of time and effort that most maintainers want to spend doing something more productive or fun.
znpy 2y ago
> Marcan links to an email by Ted Tso'o (https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...) that is interesting to read. Although it starts on a polarising note ("thin blue line") Can I say that I was immediately put off by the author conflating the "thin blue line" quote from with a political orientation? The full quote (from the article) being: "Later in that thread, another major maintainer unironically stated “We are the ‘thin blue line’”, and nobody cared, which just further confirmed to me that I don’t want to have anything to do with them." The way I read it, "thin blue line" is being used as a figure of speech. I get what they are referring to and I don't see an endorsement. It doesn't necessarily means a right-wing affiliation or sympathy. To me it seems like the author is projecting a right-wing affiliation and a political connotation where there is none (at least not officially, as far as I can see on https://thunk.org/tytso/ https://thunk.org/tytso/) in order to discredit Theodore Ts'o. Which is a low point, because attacking Ts'o on a personal level means Martin is out of ammunitions to back their arguments. But then again, Hector Martin is the same person that though that brigading and shaming on social media is an acceptable approach to collaboration in the open source space: "If shaming on social media does not work, then tell me what does, because I'm out of ideas." from https://lkml.org/lkml/2025/2/6/404 https://lkml.org/lkml/2025/2/6/404 To me, from outside, Hector Martin looks like a technically talented but otherwise toxic person that is trying to use public shaming on social media and ranting on his blog as tools and tactics to impose their will and force the otherwise democratic process of development the linux kernel. And the on top of everything it's behaving like a victim. It's a good thing they are resigning, in my opinion.
- adamrezich 2y ago
  Thank you for pointing this out—willfully, uncharitably misinterpreting “thin blue line” as used by Ts'o demonstrates a severe lack of empathy for people in his position. Jumping to conclusions about police brutality and so forth (as many here in the comments are doing) is very frustrating to see, because, in context, the intent of his phrasing is very clear to anyone who doesn't needlessly infer Contemporary Political Nonsense in literally everything they read.

deleted 2y ago

[deleted]

Certhas 2y ago

It's also not truthful because many of the Rust maintainers are long time C contributors. Marcan also linked to this resignation of a Rust Maintainer: https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@gmail.com/ https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@... which references this fantastic exchange: https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s I am not a C person, or a kernel level person, I just watch this from the sideline to learn something every now and then (and for the drama). But this exchange is really stunning to me. It seems so blatantly obvious to me that systematically documenting (in code!) and automatically checking semantic information that is required to correctly use an API is a massive win. But I have encountered this type of resistance (by very smart developers building large systems) in my own much smaller and more trivial context. To some degree, the approach seems to be: "If I never write down what I mean precisely, I won't have to explain why I changed things." A more charitable reading of the resistance is: Adding a new place where the semantics are written down (code, documentation and now type system) gives one more way in which they can be out of sync or subtly inconsistent or overly restrictive. But yeah, my intuitive reaction to the snippet above is just incredulity at the extreme resistance to precisely encoding your assumptions.

mietek 2y ago
Your charitable reading is too charitable. One of the benefits of using types to help guarantee properties of programs (e.g. invariants) is that types do not get out of sync with the code, because they are part of the code, unlike documentation. The language implementation (e.g. the compiler) automatically checks that the types continue to match the rest of the code, in order to catch problems as early as possible.
- diggan 2y ago
  I'm not a kernel developer, and never done anything of the sorts either. But, I think the argument is that if they have two versions of something (the C version + the Rust bindings), the logic/behavior/"semantics" of the C version would need to be encoded into the Rust types, and if a C-only developer changes the C version only, how are they supposed to proceed with updating the Rust bindings if they don't want to write Rust? At least that's my understanding from the outside, someone please do correct me if wrong.
  - bcrosby95 2y ago
    That was a large part of the disagreement. Rust developers were saying it would be their job to do this. But then someone said Linus rejected something because it broke Rust. GKH backed the Rust developers and said that was an exception not a rule, but didn't know Linus' stance for sure. Then Linus chimes in because of one of Hector's replies, but at the time of my reading did not clarify what his actual stance is here.
    - ChocolateGod 2y ago
      > but at the time of my reading did not clarify what his actual stance is here. Whatever he says is guaranteed to piss off at least one side of the argument.
      - rekoil 2y ago
        Yeah it's not an easy discussion for sure, but he has to say something. At the rate we're going here the existing kernel devs will alienate any capable new blood, and Linux will eventually become Google Linux(TM) as the old guard goes into retirement and the only possible way forward is through money.

diggan 2y ago

> And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false? Many discussions online (and offline) suffer from a huge-group of people who just can't stop themselves from making their knee-jerk reactions public, and then not thinking about it more. I remember the "Filesystem in Rust" video (https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s) where there are people who misunderstand what the "plan" is, and argue against being forced to use Rust in the Kernel, while the speaker is literally standing in front of them and saying "no one will be forced to use Rust in the Kernel". You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true. I personally don't know how to deal with this either, and tend to just leave/stop responding when it becomes clear people aren't looking to collaborate/learn together, but instead just wanna prove their point somehow and that's the most important part for them.

nindalf 2y ago
If you watch that YouTube link, you'll see the same guy Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust". I think he apologised for this flagrant comment, but this email shows he hasn't changed his behaviour in the slightest.
- uecker 2y ago
  His email seems very reasonable to me (the thin-blue-line comment is a bit weird though). To me the problem are that some Rust people seem to expect that the Linux maintainers (that put in a tremendous amount of work) just have to go out of their way to help them achieve their goals - even if the maintainers are not themselves convinced about it and later have to carry the burden.
  - Ar-Curunir 2y ago
    How many times will this need to be said: the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.

Ntrails 2y ago

That's useful context because as a complete laymen I thought his message was largely reasonable (albeit I am not unsympathetic to the frustration of being on the other side)!

dapperdrake 2y ago
Here is what I learned the hard way: the request sounds reasonable. And that doesn’t matter (sucks, I know.) Here is the only thing that matters in the end (I learned this an even harder way. I really worked like the L4R people approach this and was bitten by counter-examples left, right, and center): The Linux Kernel has to work. This is even more important than knowing why it works. There is gray area and you only move forward by rejecting anything that doesn’t have at least ten years of this kind of backwards compatible commitment. All of it. Wholesale. (And yes, this blatantly and callously disregards many gods efforts sounding like the tenuous and entitled claim "not good enough".) But it’s the only thing that has a good chance of working. Saying that gravity is a thing is not the same attitude as liking that everyone is subject to gravity. But hoping that gravity just goes away this once is wishful thinking of the least productive kind. Rust is not "sufficiently committed" to backwards compatibility. Firstly, too young to know for sure and the burden is solely on "the rust community" here. (Yes, that sucks. Been there.) Secondly, there were changes (other posters mentioned "Drop") and how cargo is treated that counter indicate this. Rust can prove all the haters wrong. They will then be even more revered that Linux and Debian. But they have to prove this. That is a time consuming slog. With destructive friction all the way. This is the way.

cornstalks 2y ago

> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. Unfortunately OP has a valid point regarding Rust's lack of commitment to backwards compatibility. Rust has a number of things that can break you that are not considered breaking changes. For example, implementing a trait (like Drop) on a type is a breaking change[1] that Rust does not consider to be breaking. [1]: https://users.rust-lang.org/t/til-removing-an-explicit-drop-impl-and-relying-on-drop-glue-is-a-breaking-change/56763 https://users.rust-lang.org/t/til-removing-an-explicit-drop-...

cratermoon 2y ago
I'm curious now. What are the backwards compatibility guarantees for C?
- cornstalks 2y ago
  As long as you compile with the version specified (e.g., `-std=c11`) I think backwards compatibility should be 100%. I've been able to compile codebases that are decades old with modern compilers with this.
  - joshkel 2y ago
    In practice, C has a couple of significant pitfalls that I've read about. First is if you compile with `-Werror -Wall` or similar; new compiler diagnostics can result in a build failing. That's easy enough to work around. Second, nearly any decent-sized C program has undefined behavior, and new compilers may change their handling of undefined behavior. (E.g., they may add new optimizations that detect and exploit undefined behavior that was previously benign.) See, e.g., this post by cryptologist Daniel J. Bernstein: https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8GGp2K1DAAJ https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8...
    - uecker 2y ago
      Why not entirely wrong, the UB issues are bit exaggerated in my opinion. My C code from 20 years ago still works fine even when using modern compilers. In any case, our plan is to remove most of UB and there is quite good progress. Complaining that your build fails with -Werror seems a bit weird. If you do not want it, why explicitly request this with -Werror?

School-Cotton 2y ago

> Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. This is a very persistent myth, but it’s wrong. Adding any public method to any impl can break BC (because its name might conflict with a user-defined method in a trait), and the Rust project adds methods to standard library impls all the time.

purplesyringa 2y ago
This is true, strictly speaking, but rarely causes problems. Inherent methods are prioritized over trait methods, so this only causes problems if two traits suddenly define a single method, and the method is invoked in an ambiguous context. This is a rare situation, and std thrives to prevent it. For example, in [1], a certain trait method was called extend_one instead of push for this reason. Crater runs are also used to make sure the breakage is as rare as T-libs-api has expected. The Linux kernel in particular only uses core and not std, which makes this even more unlikely. [1]: https://github.com/rust-lang/rust/issues/72631 https://github.com/rust-lang/rust/issues/72631
- School-Cotton 2y ago
  Okay, but “they try to avoid issues” is not the same as “they guarantee never to intentionally break BC except to fix compiler bugs”.
sophacles 2y ago
That's just not true. If the user has defined on the struct and a trait also has the method name, the struct's impl is used. Multiple traits can have methods named the same too. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ff49076bd187d56c6980d2d0881906f8 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- School-Cotton 2y ago
  My comment might have been technically wrong as originally stated; I’ve since edited to try to correct/clarify. What I really meant is the case where a method is added to a standard struct impl that conflicts with a user-defined trait. For example, you might have implemented some trait OptionExt on Option with a method called foo. If now a method called foo is added to the standard option struct, it will conflict.

uhgrippa 2y ago

These are often the same classification of individual who tend to modify their viewpoints towards “change is progressing rapidly in an area that I don’t understand and this scares me.” Anytime an expert in a particular area has their expertise challenged or even threatened by a new technology it is perfectly human to react in a way that is defensive towards the perceived threat. Part of growth as a human is recognizing our perceived biases and attempting to mitigate them, hopefully extending this into other areas of our lives as well. After all, NIMBYS probably started out with reasonable justifications for why they want to keep their communities the way they currently are - it’s comfortable and it works, and they’re a significant contributor to the community. Any external “threat” to this concept becomes elevated to a moral crusade against the invaders who are encroaching upon their land, when really they’re jousting against windmills.

mcosta 2y ago
Or "change is progressing rapidly in an area I am working 20 years and I have seen this kind of thing failing before"
- uecker 2y ago
  I think confronting those volunteers that maintain open-source software with arguments such as "you just do not want to learn new things" , "are scared of change", etc. is very unfair. IMHO new ideas should prove themselves and not pushed through because google wants it or certain enthusiastic groups believe this is the future. If Rust is so much better, people should just build cool stuff and then it will be successful anyway.
  - znpy 2y ago
    This isn't the first time a new language is proposed for the kernel though. At some point there was some brief discussion for C++ in the kernel and that was essentially immediately killed by Linus. And he was essentially right.
  - uecker 2y ago
    Overall, this whole situation seems entirely weird to me. All this stuff such as Unix, Linux, and C ecosystem was build by C programmers and maintained for decades mostly voluntarily, while most of the industry pushed into other directions (with a gigantic influx of money). It is completely amazing that Linux become so successful against all the odds. Certainly it also then had a lot industry support, but I used it already before most of this and witnessed all the development. But somehow, C programmers are now suddenly portrayed as the evil gatekeepers, not stepping aside fast enough, because some want to see change. In the past, the people wanting to see something new in the open-source community would need to convince the community by building better things, not by pushing aggressively into existing projects.

parasense 2y ago

> This is par for the course I guess, and what exhausts folks like marcan. I wouldn't want to work with someone like Ted Tso'o, who clearly has a penchant for flame wars and isn't interested in being truthful. I am acquainted with Ted via the open source community, we have each other on multiple social media networks, and I think he's a really great person. That said, I also recognize when he gets into flame wars with other people in the open source social circles, and sometimes those other people are also friends or acquaintances. I can think of many times Ted was overly hyperbolic, but he was ultimately correct. Here is the part of the Linux project I don't like sometimes, which was recently described well in this recent thread. Being correct, or at least being subjectively correct by having extremely persuasive arguments, yet being toxic... is still toxic and unacceptable. There are a bazillion geniuses out there, and being smart is not good enough anymore in the open source world, one has to overcome those toxic "on the spectrum" tendencies or whatever, and be polite while making reasonable points. This policy extends to conduct as well as words written in email/chat threads. Ted is one of those, along side Linus himself, who has in the past indulged into a bit of shady conduct or remarks, but their arguments are usually compelling. I personally think of these threads in a way related to calculus of infinitesimals, using the "Standard Parts" function to zero away hyperbolic remarks the same way the math function zeros away infinitesimals from real numbers, sorta leaving the real remarks. This is a problem, because it's people like me, arguably the reasonable people, who through our silence enable these kind of behaviours. I personally think Ted is more right than wrong, most of the time. We do disagree sometimes though, for example Ted hates the new MiB/KiB system of base-2 units, and for whatever reasons like the previous more ambiguous system of confusingly mixed base-10/base-2 units of MB/Mb/mb/KB/Kb/kb... and I totally got his arguments that a new standard makes something confusing already even more confusing, or something like that. Meh...

throwaway2037 2y ago
> I can think of many times Ted was overly hyperbolic, but he was ultimately correct. Here is the part of the Linux project I don't like sometimes, which was recently described well in this recent thread. Being correct, or at least being subjectively correct by having extremely persuasive arguments, yet being toxic... is still toxic and unacceptable. I want to say that I am thankful in this world that I am a truly anonymous nobody who writes codes for closed-source mega corp CRUD apps. Being a tech "public figure" (Bryan Cantrill calls it "nerd famous") sounds absolutely awful. Every little thing that you wrote on the Internet in the last 30 years is permanently recorded (!!!), then picked apart by every Tom, Dick, Harry, and Internet rando. My ego could never survive such a beating. And, yet, here we are in 2025, where Ted T'so continues to maintain a small mountain of file system code that makes the Linux world go "brrr". Hot take: Do you really think you could have done better over a 30 year period? I can only answer for myself: Absolutely fucking not. I, for one, am deeply thankful for all of Ted's hard work on Linux file systems.

yellowapple 2y ago

> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. The community is more than just the language and compiler vendor(s). It's everyone using the language, with particular emphasis on the developers of essential libraries and tools that those users use and on which they're reliant. In this sense, based on every time I've attempted to use Rust (even after 1.0), Ts'o's remark ain't inaccurate from what I can tell. If I had a nickel for every Rust library I've seen that claims to only support Rust Nightly, I'd have... well, a lot of nickels. Same with Rust libraries not caring much about backward-compatibility; like yeah, I get it during pre-1.0, or while hardly anyone's using it, but at some point people are using it and you are signaling that your library's "released", and compatibility-breaking changes after that point make things painful for downstream users. > Here's the maintainer on the gccrs project (a second Rust compiler implementation), posting on the official Rust Blog Same deal here. The Rust developers might be welcoming of additional implementations, but the broader community might not be. I don't have enough information to assess whether the Rust community is "actively hostile" to a GCC-based Rust implementation, but from what I can tell there's little enthusiasm about it; the mainstream assumption seems to be that "Rust" and its LLVM-based reference compiler are one and the same. Maybe (hopefully) that'll change. ---- The bigger irony here, in any case, is that the Linux community has both of these very same problems: - While the kernel itself has strict backwards-compatibility guarantees for applications, the libraries those applications use (including absolutely critical ones like glibc) very much do not. The ha-ha-only-serious observation in the Linux gaming community is that - thanks to Wine/Proton - the Windows API is the most stable ABI for Linux applications. Yeah, a lot of these issues are addressable with containerization, or by static compilation, but it's annoying that either are necessary for Linux-native applications to work on old and new distros alike. - As marcan alludes to in the article, the Linux community is at least antipathetic (if not "actively hostile") to Linux-compatible kernels that are not Linux, be they forks of Linux (like Android) or independent projects that support running Linux applications (WSL 1/2, FreeBSD, some illumos distros, etc.). The expectation is that things be upstreamed into "the" Linux, and the norms around Linux development make out-of-tree modules less-than-practical. This is of course for good reason (namely: to encourage developers to contribute back to upstream Linux instead of working in silos), but it has its downsides - as marcan experienced firsthand.

judofyr 2y ago

> "which is actively hostile to a second Rust compiler implementation" - except that isn't true? Historically the Rust community has been extremely hostile towards gccrs. Many have claimed that the work would be detrimental to Rust as a language since it would split the language in two (despite gccrs constantly claiming they're not trying to do that). I'm not sure if it was an opinion shared by the core team, but if you just browse Reddit and Twitter you would immediately see a bunch of people being outright hostile towards gccrs. I was very happy to see that blog post where the Rust leadership stepped up to endorse it properly. Just one reference: In one of the monthly updates that got posted on Reddit (https://old.reddit.com/r/rust/comments/1g1343h/an_update_on_gccrs_development_lwnnet/ https://old.reddit.com/r/rust/comments/1g1343h/an_update_on_...) a moderator had to write this: > Hi folks, because threads on gccrs have gotten detailed in the past, a reminder to please adhere to the subreddit rules by keeping criticism constructive and keeping things in perspective.

kibwen 2y ago
The LKML quote is alleging that the upstream language developers (as opposed to random users on Reddit) are opposed to the idea of multiple implementations, which is plainly false, as evidenced by the link to the official blog post celebrating gccrs. Ted T'so is speaking from ignorance here.
- vlovich123 2y ago
  I think it’s more pointed towards people like me who do think that gccrs is harmful (I’m not a Rust compiler/language dev - just a random user of the language). I think multiple compiler backends are fine (eg huge fan of rustc_codegen_gcc) but having multiple frontends I think can only hurt the ecosystem looking at how C/C++ have played out vs other languages like Swift, Typescript etc that have retained a single frontend. In the face of rustc_codegen_gcc, I simply see no substantial value add of gccrs to the Rust ecosystem but I see a huge amount of risk in the long term.
- judofyr 2y ago
  (emphasis mine) > opposed to the idea of multiple implementations, which is plainly false, as evidenced by the link to the official blog post celebrating gccrs. Ted T'so is speaking from ignorance here. Why use so strong words? Yes, there's clearly a misunderstanding here, but why do we need to use equally negative words towards them? Isn't it more interesting to discuss why they have this impression? Maybe there's something with the communication from the upstream language developers which hasn't been clear enough? It's a blog post which is a few months old so if that's the only signal it's maybe not so strange that they've missed it? Or maybe they are just actively lying because they have their own agenda. But I don't see how this kind of communication, assuming the worst of the other part, beings us any closer.

throwaway2037 2y ago

Thank you to share the Ted T'so LKM post. Can you explain the culture reference "thin blue line"? I never heard it before.

jsk2600 2y ago
The "thin blue line" is a term that typically refers to the concept of the police as the line between law-and-order and chaos in society.[1] The "blue" in "thin blue line" refers to the blue color of the uniforms of many police departments. [1] https://en.wikipedia.org/wiki/Thin_blue_line https://en.wikipedia.org/wiki/Thin_blue_line
Suzuran 2y ago
It's a motto used by American law enforcement to justify extrajudicial punishment. Since they are the "thin blue line" that separates the public from anarchy, they are justified in acting independently to "protect" us when judges and juries do not "cooperate".
- patmorgan23 2y ago
  Not just extrajudicial punishment, but overlooking corrupt acts and crimes from fellow officers. That it's more important to maintain the 'brotherhood' than to arrest an officer caught driving home drunk.
- milesrout 2y ago
  That is a very strange take. The phrase isn't American and has no negative connotation. It has nothing to do with "extrajudicial punishment". It simply refers to the (obvious) fact that what separates societies from anarchy is the "thin blue line" of law enforcement. Rowan Atkinson had a sitcom set in a London police station in the 90s called "The Thin Blue Line". Are you under the impression he was dogwhistling about extrajudicial violence?
  - mijoharas 2y ago
    This is what really confused me about the article. I read the mailing list post and had no idea what was controversial about thin blue line. In fact, I thought most of that post was fairly reasonable. I'd never heard of the extrajudicial punishment aspect of the phrase (though I had heard the phrase itself) and it didn't show up when I googled, but I'm not American, so maybe there's some cultural differences.

scottlamb 2y ago

> - "an upstream language community which refuses to make any kind of backwards compatibility guarantees" -> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. The most charitable interpretation I can imagine is that the Rust-in-Linux project needs specific nightly features, and those don't get stability guarantees. But I think this is still pretty unfair to complain about; my impression is there's a lot of appetite on the Rust side to get those stabilized. I also think... > 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. ...that while there's truth in this, there's also a large extent to which it's a self-fulfilling prophecy. Someone might want to stick it out to get their work into mainstream once, but then take a look at the process once it's in the mirror and say never again. ...and: > Instead of complaining about maintainers for who are unreasonably caring about these things, when they are desparately under-resourced to do as good of a job as they industry demands, how about meeting us half-way and helping us with these sort of long-term code health issues? It's really hard for me to not see "let's actually write down the contract for these functions, ideally via the type system" as doing exactly that. Which seems to me to be the central idea Ted Ts'o was ranting about in that infamous video.

j45 2y ago

Perhaps merge requests should have to go through a process of learning the codebase first, and submitting increasingly more complex fixes before jumping to really complex requests. It can be hard when solving your own acute issue - doing so doesn't mean it is the only fix or the one the project should accept. Even if it's beneath someone's talent to have to do it, it is an exercise of community building.

kllrnohj 2y ago

> which is actively hostile to a second Rust compiler implementation Which is hilarious since Linux itself was actively hostile to the idea of a second C compiler supporting it. Just getting Linux to support Clang instead of only GCC was a monumental task that almost certainly only happened because Android forced it to happen.

tuna74 2y ago
It happened because the Android people put in the work to make it happen both in Linux and in Clang/LLVM.
- kllrnohj 2y ago
  Putting in the work is one thing, which is what the Rust-in-Linux people are also doing, but there's also the political requirement to force maintainers to accept it. Android was big enough, and happy enough to fork seeing as it had already done that before, that it forced a lot of hands with top-down mandates. Rust, despite having Linus' blessing to be in the kernel, is still just getting rejected just because it's Rust, completely unrelated to any technical merits of the code itself.
- ndesaulniers 2y ago
  hello!

anonfordays 2y ago

If 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. Marcan and 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.

adamrezich 2y ago
Quite wild to see this being downvoted, because by downvoting, surely one implies the inverse of your post to be the truth, such that projects such as the Linux kernel should be battlegrounds for the grievance of the week, should be platforms for proselytizing, and so forth. Very strange to see little to no empathy for kernel maintainers in this situation.
- PoignardAzur 2y ago
  Most people would not interpret downvoting as "I believe that the exact opposite of every single sentence in your post is true".
  - adamrezich 2y ago
    Most people don't compulsively downvote every post that they only mildly disagree with.
    - PoignardAzur 2y ago
      Look, I don't know what to say without just assuming you're approaching this discussion in bad faith. Saying people "compulsively downvote" the stuff above is already a strong claim that you have no way to substantiate. I think more broadly what you're claiming is that the people downvoting you and anonfordays are emotional and doing so out of political zealotry, and... again, that a pretty strong claim. People can downvote a post not because they strongly disagree with its claims, but because they strongly dislike its inflammatory tone ("fragile entryist", "Marcan and others like him leave long paths of destruction in their wake", etc). People who strongly disagree with a post don't necessary believe the exact opposite of its claims. They can disagree with some of the claims and agree with others, or disagree with the very framing of the post. If I say "we should outlaw all guns because gun crimes are awful" and you disagree, that doesn't mean you think gun crimes are great.

dataflow 2y ago

> It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining it after that. They have maximum leverage at review time, and 0 leverage after. I don't follow. The one with zero leverage is the contributor, no? They have to beg and plead with the maintainers to get anything done. Whereas the maintainers can yank code out at any time, at least before when the code makes it into an official stable release. (Which they can control - if they're not sure, they can disable the code to delay the release as long as they want.)

tuna74 2y ago
Maintainers can't yank out code if that leads to feature, performance or user space regressions.
- janice1999 2y ago
  Entire filesystems and classes of drivers have been purged from the kernel over time. Removing stuff is not impossible as some here suggest.
  - tuna74 2y ago
    Yes, but removing stuff takes a lot of time and effort that most maintainers want to spend doing something more productive or fun.

znpy 2y ago

> Marcan links to an email by Ted Tso'o (https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...) that is interesting to read. Although it starts on a polarising note ("thin blue line") Can I say that I was immediately put off by the author conflating the "thin blue line" quote from with a political orientation? The full quote (from the article) being: "Later in that thread, another major maintainer unironically stated “We are the ‘thin blue line’”, and nobody cared, which just further confirmed to me that I don’t want to have anything to do with them." The way I read it, "thin blue line" is being used as a figure of speech. I get what they are referring to and I don't see an endorsement. It doesn't necessarily means a right-wing affiliation or sympathy. To me it seems like the author is projecting a right-wing affiliation and a political connotation where there is none (at least not officially, as far as I can see on https://thunk.org/tytso/ https://thunk.org/tytso/) in order to discredit Theodore Ts'o. Which is a low point, because attacking Ts'o on a personal level means Martin is out of ammunitions to back their arguments. But then again, Hector Martin is the same person that though that brigading and shaming on social media is an acceptable approach to collaboration in the open source space: "If shaming on social media does not work, then tell me what does, because I'm out of ideas." from https://lkml.org/lkml/2025/2/6/404 https://lkml.org/lkml/2025/2/6/404 To me, from outside, Hector Martin looks like a technically talented but otherwise toxic person that is trying to use public shaming on social media and ranting on his blog as tools and tactics to impose their will and force the otherwise democratic process of development the linux kernel. And the on top of everything it's behaving like a victim. It's a good thing they are resigning, in my opinion.

adamrezich 2y ago
Thank you for pointing this out—willfully, uncharitably misinterpreting “thin blue line” as used by Ts'o demonstrates a severe lack of empathy for people in his position. Jumping to conclusions about police brutality and so forth (as many here in the comments are doing) is very frustrating to see, because, in context, the intent of his phrasing is very clear to anyone who doesn't needlessly infer Contemporary Political Nonsense in literally everything they read.