Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

491–500 of 1001 posts

Re: Resigning as Asahi Linux project lead

#491
post #175

Earlier 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…

The speaker doesn't understand the audience question and doesn't respond to it. The audience member points out that they shouldn't encode the semantics into the Rust type system because that would mean that refactoring the C code breaks Rust, which is not an acceptable situation. The speaker responds to this by saying essentially "tell me what the semantics are and I'll encode them in the Rust type system." That's ma…

> I have to say that I used to be excited about Rust, but the Rust community seems very toxic to me. I see a lot of anger, aggression, vindictiveness, public drama, etc.

I had the same impression.

Why all this drama is 90% of the time around Rust people?

Re: Resigning as Asahi Linux project lead

#492
post #427

Earlier quoted context omitted.

I think we're mixing 2 things here: language backward-compatibility, vs. standard practices about what semver means for Rust libraries. The former is way stronger than the latter.

> language backward-compatibility, vs. standard practices about what semver means I've read and re-read this several times now and for the life of me I can't understand the hair you're trying to split here. The only reason to do semantic versioning is compatibility...

The Rust compiler/language has no notion of semver. Saying "Rust is unstable b/c semver blah blah" is a tad imprecise. Semver only matters in the context of judging API changes of a certain library (crate).

> The only reason to do semantic versioning is compatibility

Sure. But "compatibility" needs to be defined precisely. The definition used by the Rust crate ecosystem might be slightly looser than others, but I think it's disingenuous to pretend that other ecosystems don't have footnotes on what "breaking change" means.

Re: Resigning as Asahi Linux project lead

#493
post #139

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.

Re: Resigning as Asahi Linux project lead

#494
post #371

Earlier quoted context omitted.

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.

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.

They've said that, but nobody believes them, and can you blame them given we JUST saw another big rust maintainer resign?

I'd be suspicious these guys aren't in it for the long haul if they don't get their way and will leave the Rust they shoved in the kernel to bit rot if things don't go their way w.r.t enough rust adoption fast enough. "If you don't let us add even more rust, we will resign from the project and leave you to maintain the rust that's already there and that we added, and that you said you didn't want to add because you didn't trust us to not resign".

Rust 4 Linux people just proving the points of the maintainers scared of abandonment.

The rust 4 Linux people unfortunarely give the impression of caring more about rust than about the kernel, and it's clear that many are willing to make that perfectly clear by abandoning the larger project.

The whole thing needs to be scrapped and rethought with better and more committed leadership. This past 6 months to a year has been embarrassing and done nothing but confirm the fears of anti rust people.

Re: Resigning as Asahi Linux project lead

#495

Earlier quoted context omitted.

That was a mistake and a breakdown in processes that wasn't identified early enough to mitigate the problem. That situation does not represent the self imposed expectations on acceptable breakage, just that we failed to live up to it and by the time it became clearer that the change was problematic it was too late to revert course because then that would have been a breaking change. Yes: adding a trait to an existing…

TBH that's a level of quality control that probably informs the Linux kernel dev's view of Rust reliability - it's a consideration when evaluating the risk of including that language.

Are you sure you want to start comparing the quality control of C and Rust packaging or reliability?

Re: Resigning as Asahi Linux project lead

#496
post #378

Earlier quoted context omitted.

> That’s not ok. Then entertain his question and tell us what is? Bringing up people’s attention to the matter to finally somehow resolve the situation is his last resort, after spending years trying to upstream even trivial patches. You can eat your cake and have it too - you can’t say you want rust in the kernel and then sabotage any upstreaming efforts

> Then entertain his question and tell us what is? In this particular case, Hector himself with the blog post hints at it, but a lot of damage has been done already: "I am working on personal issues currently, I'd like to step back for a while and will not be contributing. Thank you, all". > Bringing up people’s attention to the matter to finally somehow resolve the situation Not everything has a clear and fast resol…

[deleted]

Re: Resigning as Asahi Linux project lead

#497
post #93

Marcan links to an email by Ted Tso'o ( 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…

> 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.

It happened because the Android people put in the work to make it happen both in Linux and in Clang/LLVM.

Re: Resigning as Asahi Linux project lead

#498
post #480

Earlier quoted context omitted.

But Rust 1.0 can't compile Rust 1.1. And as others have noted, C99 is a standard and Rust lacks one.

But Rust 1.0 can't compile Rust 1.1 That's an impossible standard to hold Rust to, did you mean it the other way around? A C89 compiler can't compile all of C99 either.

But v1 of a C99 compiler can compile all of C99, and v2 of a C99 compiler can still compile all of C99.

Re: Resigning as Asahi Linux project lead

#499

Earlier quoted context omitted.

TBH that's a level of quality control that probably informs the Linux kernel dev's view of Rust reliability - it's a consideration when evaluating the risk of including that language.

Are you sure you want to start comparing the quality control of C and Rust packaging or reliability?

I trust the quality control of the Linux kernel devs a lot more than the semantics of a language.

Re: Resigning as Asahi Linux project lead

#500
post #457
post #393

Earlier quoted context omitted.

Or "change is progressing rapidly in an area I am working 20 years and I have seen this kind of thing failing before"

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 success…

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.

Post reply on HN