One does not "hone in" on anything. To hone a thing is to make it sharper or more acute by removing parts of it with an abrasive. The word you are looking for is "home", as in a homing missile, etc. Yes, this is a criticism. Hopefully it's twice as effective as being nice. 8)
Multiple dictionaries recognize the usage of "hone in" to mean "sharpening" your focus on something rather than "home in" which is to move towards something.
Dictionaries also (incorrectly) recognize "literally" to mean "figuratively". They aren't exactly a compelling source these days.
When was the last time you touched a PC, 2003? They most certainly do, when the OEM actually supports it: https://www.kernel.org/doc/html/latest/admin-guide/thunderbo... It's not ever coming to Apple Silicon on Linux since post-Thunderspy, Thunderbolt is dangerous to implement even in the best of circumstances. You'd have to reverse-engineer and update Apple's IOMMU, write software drivers for the port since it doesn…
> when the OEM actually supports it that sentence carries a lot of weight. How many millions of users are left in the dust? Last time I touched a PC, the USB-C port could charge the laptop, unless the battery was empty. Then only the barrel plug could be used. It. was. infuriating.
That's terrible, caveat emptor. My point is that you won't see people porting Thunderbolt to Asahi in a post-Thunderspy era.
Once you're finished astroturfing, you're welcome to rejoin the greater discussion.
I don't really follow what's objectionable about Ted's email, or why it's being singled out. It matches my experience as an open source maintainer pretty accurately. It's also pretty constructive (it goes on to lay out a plan on how to constructively proceed and make everyone happy).
What's objectionable is primarily the phrase "thin blue line" - it's highly politically charged language: https://en.wikipedia.org/wiki/Thin_blue_line One would hope it was just a particularly bad gaffe, but it could also be an insight into how he actually views himself as a maintainer which is not great.
It is most certainly not politically charged language. It's an anodyne statement referring to being a small force keeping bad things from happening. That's all.
The issue is that Linus put the Rust developers in an impossible position: On the one hand he approved Rust in the kernel, but then never ever ever has the balls to enforce that decision. Then, the fanatical C developers openly sabotage and work against all the Rust developers efforts. So, the last option for the Rust developers is to take it to social media. Otherwise, the C developers get away with creating a self…
I agree. Everyone here seems to be criticising Marcan for not being professional, but it’s very difficult to remain professional when the people you’re working with gloat in public that they intend to completely sabotage your work product despite it being given explicit support by the CEO. Why are you the only one criticising the coworkers? I feel like I’m taking crazy pills reading this thread.
Because this thread is about Marcan's behavior, not others'. I think it's perfectly fair to claim that everyone behaved badly in this situation, but the person I replied to was insinuating that Marcan didn't do anything wrong. That is not true, and why I highlighted his behavior.
Yup, I think it went too far. The fact is, you need buy in from other devs and if a dev won't buy in you need to work out a way to avoid them or avoid conflict. It sucks, it slows things down, but frankly making it a "them vs us" is a sure fire way to make them oppose any change you want to make. Public shaming even more disastrous as there's no better way to entrench someone in a position.
But the point is that the Rust developers have tried literally everything else. If the C developers make it a "Them vs Us" thing, there IS NO ALTERNATIVE for the Rust developers. Linus' reaction is quite literally the equivalent of a parent only punishing the loudest child, not the child that's been silently bullying that kid for months.
> If the C developers make it a "Them vs Us" thing, there IS NO ALTERNATIVE for the Rust developers.
There is always an alternative. Exit the project quietly and gracefully if Linus won't show proper leadership. Don't engage in poor behavior back at the C developers, that is just as wrong.
"spreading awareness about a position" isn't a very accurate way to describe what happened. This is the guy who said he wanted to use social media to create a "hall of shame" for kernel developers. Of course Linus told him to knock it off, that's ridiculously unprofessional behavior.
Wow, what an uncharitable read. Are you aware of what that term means? He said it was not about literally shaming people, but showing what contributing to the kernel is like, and even clarified it wouldn't be for public consumption. It's a colloquialism for a resource where peers can learn from each other's mistakes. My high school Spanish class had a hall of shame. It's a magnitude more professional than the extreme…
"hall of shame" inherently means it's about literally shaming people. If that isn't what he meant, then he shouldn't have used those words.
> It's a magnitude more professional than the extremely over the top and public emails that Linus shares
Since when do two wrongs make a right? I think it's perfectly fair to say Linus hasn't shown the best leadership here. But that doesn't excuse Marcan's behavior.
I'm not sure about why they are upset with the issue of upstreaming the changes into the kernal. They want to upstream drivers for a device that the creator of clearly has no interest in allowing others to use outside of their walled garden. The knowledge around it is from a massive , albeit impressive, RE effort. Who is going to support it? Where is the demand for it? It would be different if Apple were to provide p…
This quite literally the story of nouveau. The driver exists because people need it, and the driver is maintained by the people who wrote it. I don't see why the same doesn't apply to Linux on Apple Silicon.
Rust, which is a language I really enjoy, generates more social media outrage and religious wars than any other technical project I have been following for the past 20 years.
> more social media outrage and religious wars than any other technical project I have been following for the past 20 years. It is unfortunately wrapped up in larger-scale outrage culture than just within tech/programming circles. Rust as a community is very gay and very trans: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve... https://blog.rust-lang.org/2025/02/13/2024-State-Of-Rust-Sur... To be clear I…
Please enlighten me why is this even a question on a language survey. I take many languages survey when they show up and Rust is the only one asking this.
> more social media outrage and religious wars than any other technical project I have been following for the past 20 years. It is unfortunately wrapped up in larger-scale outrage culture than just within tech/programming circles. Rust as a community is very gay and very trans: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve... https://blog.rust-lang.org/2025/02/13/2024-State-Of-Rust-Sur... To be clear I…
> The actual percentages are probably somewhat lower, but Rust undoubtedly has the highest concentration of any programming-language community. Zero question. This is complete nonsense. We (LGBT) folk are pretty much equally represented in all programming communities. It's just that Rust presents as a very socially activist community, with all the attendant drama and culture war nonsense, including falsely claiming s…
I don’t understand was to why this even needs to be a question on a language survey.
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.
Not even close to 100%, the reason that it feels like every major C codebase in industry is pinned to some ancient compiler version is because upgrading to a new toolchain is fraught. The fact that most Rust users are successfully tracking relatively recent versions of the toolchain is a testament to how stable Rust actually is in practice (an upgrade might take you a few minutes per million lines of code).
IDK about "industry" but I can't think of any prominent C or C++ open-source codebase that requires a specific version of gcc or clang to compile.