With all due respect to the effort.. Projects built around unsupported ways to use someone else's products, aren't they doomed from the very start? This race that you can't win isn't it a recipe for imminent burnout? I don't even mean that Apple has no interest in this project in the best case, but why Linux maintainers would want to accept changes that are necessary to support such a marginal use case?
Resigning as Asahi Linux project lead
401–410 of 1001 posts
Re: Resigning as Asahi Linux project lead
#402This might be crazy, but why does Ashai and its drivers need to be upstreamed to the Linux kernel at all? Why not fork Linux and call it something new, with the hardware support that is exclusively for M1/2/3/4 Mac’s?
They would have to play catch up for a few years rebasing off the latest and then eventually lose interest and it will all stop working. Same thing that happens with most arm devices that aren't upstreamed.
Re: Resigning as Asahi Linux project lead
#403Earlier quoted context omitted.
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 und…
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?
Just curious, when you’re done removing all the UB, how will you know you’ve been successful? UB is hard to find isn’t it?
Re: Resigning as Asahi Linux project lead
#404Earlier quoted context omitted.
"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.
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…
> So, the last option for the Rust developers is to take it to social media.
Social media is an amplifier of interpersonal problems, not a place to seek for a resolution for them - unless your intended "resolution" is to beat down the other side, the people you have to work alongside by necessity, via potshots from random strangers who hardly ever bother to inform themselves fully of the situation. That is never going to be a true resolution, and I think Linus, for all his faults, recognizes that and that's why he draws the line there.
Re: Resigning as Asahi Linux project lead
#405Earlier quoted context omitted.
> But then marcan told his supportes to fuck off unless they commit to supporting his political ideas, which I was not willing to do. Is this about Marcan’s outspoken support for transgender people? If so, why not simply say that in your comment, rather than framing it in such vague terms?
Because I think it's not important in the context of this discussion. Whatever their views are, I am not willing to be forced to think about them.
…So it is about the fact that you object to his support for transgender people?
Surely you see why this is, actually, directly relevant and important context for your statement. It’s not some general political leaning you’re talking about - lumping this (prejudice against a minority group) into the same category as something like banal disagreements over taxation policy amounts to deliberately obscuring what you’re saying behind innuendo.
If you’ve got something to say about his political views in a public forum like this, at least do the people around you the courtesy of being upfront about what you’re actually saying.
Re: Resigning as Asahi Linux project lead
#406It’s absurd that the C/C++ community is so hard-headed about Rust. Is the Linux kernel in fifty years still going to be written in the same language it is now?
The people in the thread were complaining about having mixed languages in a core kernel module, not about the language being Rust. Replace Rust with any other language and their complaint would have remained. The Rust people complain about not getting technical arguments against their proposals, but how is "a module that's coded in two languages is more difficult to maintain than one coded in a single language" not a technical argument?
Re: Resigning as Asahi Linux project lead
#407Earlier quoted context omitted.
> 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 ch…
I was hit by a similar thing. Rust once caused regression failures in 5000+ packages due to incompatibility with older "time" packages [1]. It was considered okay. At that point, I don't care what they say about semver. [1]: https://github.com/rust-lang/rust/issues/127343#issuecomment...
The comment you linked to explicitly shows that a maintainer does not consider this "okay" at all. T-libs-api made a mistake, the community got enraged, T-libs-api hasn't made such a mistake since. The fact that it happened sucks, but you can't argue that they didn't admit the failure.
Re: Resigning as Asahi Linux project lead
#408Earlier quoted context omitted.
> 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 ) whe…
We have used that video as an exercise in how not to achieve change. Assuming everyone is acting in good faith, the presenter missed the opportunity to build consensus before the talk, Tsu unwilling to budge a bit, but most of all the moderator unable to prevent the situation from exploding. This could have been handled much better by each of them. In contrast to the parent: yes, the presenter says „you don’t have to…
> Assuming everyone is acting in good faith
Why would we assume that Ted repeatedly using strawman fallacies, bleating appeals to emotion and acting like a victim...all the while shouting people down...evidence of "acting in good faith"?
When you shout over someone like that you're nothing but a bully.
> he fails to address the concern that a change they introduce would error downstream and someone else had to clean up afterwards.
Because that "concern" was a strawman. It demonstrated that Ted either did not understand what the presenters were asking for, or simply didn't like others asking him to do something, because he's very important and nobody tells him what to do.
As has been exhaustively explained by others in previous HN threads and elsewhere: the Rust developers were asking to be informed of changes so that Rust developers could update their code to accommodate the change.
Ted loses his shit and starts shouting nonsense about others forcing people to learn Rust, and so on.
> but most of all the moderator unable to prevent the situation from exploding
When someone is being abusive to others, the issue is never "the people on the receiving end are not handling it as best they can."
Further: did it occur to you that Ted's infamous short temper, and his "status" as a senior kernel developer, might be why the moderator was hesitating to respond?
Imagine how Ted would have reacted if he was told to speak respectfully, lower his voice, and stop talking over others. Imagine how the army of nerds who think Ted's behavior was acceptable or understandable.
Re: Resigning as Asahi Linux project lead
#409Earlier quoted context omitted.
It seems obvious that that’s not what Ted intended it to mean, since it wouldn’t even make sense in this context (the debate doesn’t really seem to be about whether maintainers should be loyal to other maintainers). A more charitable interpretation would be “we’re the only line of defense protecting something good and valuable from the outside world, so people should give significant weight to our opinions and decisi…
There are many ways to state that without invoking corruption. I think Ted is telling the truth of who he is by choosing that phrase intentionally - we aren't talking about an idiot who just says stuff, he's a smart guy.
Given that "invoking corruption" is neither the plain meaning of those words, nor does it even make sense in this context, I don't think it's reasonable to claim Ted did so.
Re: Resigning as Asahi Linux project lead
#410Earlier quoted context omitted.
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?
Just curious, when you’re done removing all the UB, how will you know you’ve been successful? UB is hard to find isn’t it?
To be clear: I mean UB in the C standard. The cases where there is UB are mostly spelled out explicitly, so we can go through all the cases and define behavior. There might be cases where there is implicit UB, i.e. something is accidentally not specified, but this has always been fixed when noticed. It is not possible to remove all cases of UB though, but the plan is to add a memory safe mode where there is no UB similar to Rust.