Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

Post reply on HN
Print view View original

511–520 of 1001 posts

Re: Resigning as Asahi Linux project lead

#511

Post by hitekker »

generalizations wrote: post #486
purplesyringa wrote: post #407

Earlier quoted context omitted.

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.

"a maintainer" The way you word that makes it sound like "the maintainers" and "T-libs-api" do not consider this "okay". Reading just above the linked comment, however, puts a very different impression of the situation: > We discussed this regression in today's @rust-lang/libs-api team meeting, and agree there's nothing to change on Rust's end. Those repos that have an old version of time in a lockfile will need to u…

Thanks for clarifying. I took a look as well, and the very first reply confirms your opinion and that of the GP's parent. Plenty of downvotes and comments that come after criticizing the maintainers, "I am not sure how @rust-lang/libs-api can look at 5400 regressions and say "eh, that's fine"."

Not sure why people are trying to cover this up.

Re: Resigning as Asahi Linux project lead

#512

Post by talldayo »

IshKebab wrote: post #114
talldayo wrote: post #45

Earlier quoted context omitted.

> I wonder if it would be in Apple's interests to actively support Linux on Mac Trust me, we would know by now if it was. It's not.

Things don't happen instantly. You could have doubted it was in Microsoft's interest to support Linux within Windows for years... until they released WSL.

Windows machines already support Linux on the hardware level. Getting an Intel or AMD CPU to virtualize a Linux kernel is simple. Worst case scenario is an Nvidia GPU, but since you only need the compute drivers in WSL you avoid Nvidia's graphical issues. There isn't any work required since the OEMs already did it, the only thing required is Hyper-V.

Apple is selling a custom CPU core that has no driver support for anything but XNU with a BSD userland. It doesn't support UEFI, it depends on Devicetree bindings and would demand constant updating and support to render a "first class" Linux experience. Once again, anyone with a protracted interest in staying supported by upstream Linux should not be using a Mac and praying the community cares enough to make it good. Apple knows it's a novelty, and they're not going to take it seriously because that's just what they do. MacOS and the App Store is profitable, Linux is not.

Re: Resigning as Asahi Linux project lead

#513

Post by ajross »

jrvidal wrote: post #492
ajross wrote: post #427

Earlier quoted context omitted.

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

> But "compatibility" needs to be defined precisely.

Compatibility is defined precisely! You're definition requires scare quotes. You want to define it "Precisely" so that you can permit incompatible behavior. No one who cares about compatibility does that, it's just an excuse.

Look, other languages do this differently. Those of use using C99 booleans know we need to include a separate header to avoid colliding with the use of "bool" in pre-existing code, etc... And it sort of sucks, but it's a solved problem. I can build K&R code from 1979 on clang. Rust ignored the issue, steamrollered legacy code, and tried to sweep it under the rug with nonsense like this.

Re: Resigning as Asahi Linux project lead

#514

Post by cornstalks »

steveklabnik wrote: post #416
cornstalks wrote: post #257

Earlier quoted context omitted.

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.

gets() was straight-up removed in C11. Every language has breaking changes. The question is the frequency, not if it happens at all. The C and C++ folks try very hard to minimize breakage, and so do the Rust folks. Rust is far closer to those two than other languages. I'm not willing to say that it's the same, because I do not know how to quantify it.

But you can still use gets() if you're using C89 or C99[1], so backwards compatibility is maintained.

Rust 2015 can still evolve (either by language changes or by std/core changes) and packages can be broken by simply upgrading the compiler version even if they're still targeting Rust 2015. There's a whole RFC[2] on what is and isn't considered a breaking change.

[1]: https://gcc.godbolt.org/z/5jb1hMbrx

[2]: https://rust-lang.github.io/rfcs/1105-api-evolution.html

Re: Resigning as Asahi Linux project lead

#515

Post by kllrnohj »

gsck wrote: 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…

You should click through some of the links to see where the clashes actually happened. It didn't have anything to do with the actual hardware support. Rather, it was over stupid shit like the kernel DMA team throwing a hissy fit over the idea of there being Rust bindings for the DMA interface: https://lore.kernel.org/lkml/20250108122825.136021-3-abdiel....

When the response to such a small contribution is just "No rust code in kernel/dma, please" with a complete shutdown of any attempt to discuss alternatives, it's kinda pointless. Even though Rust is supposed to be an allowed language in the kernel now, with blessing from Linus himself, there's apparently just submaintainers of critical, highly shared infrasture that outright refuse it.

So this has nothing to do with "who will own the Apple drivers?!" but just the rest of the kernel going "your integration layers are an affront to our Holy C, begone religious heretics!"

Re: Resigning as Asahi Linux project lead

#516

Post by tuna74 »

bayindirh wrote: post #460
rowanG077 wrote: post #436

Earlier quoted context omitted.

5%? Sure there is a lot of activity around software. But out of week of 40 hours I most certainly code more than at most 2 hours. If this is your workplace I think it's dysfunctional.

Not by time, but by weight. The code you write is worthless if you can’t communicate it or what you did.

It is not useless if the code is being run and is doing something productive

Re: Resigning as Asahi Linux project lead

#517

Post by [deleted] »

rdtsc wrote: post #378
nrabulinski wrote: post #314

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

#518

Post by sneedle »

caspper69 wrote: post #124
kombine wrote: post #75

Earlier quoted context omitted.

As that kernel maintainer clearly stated this was not because the code was awful, but because the code was written in Rust and it was therefore cancer.

That's not what he said. From the horse's mouth (lkml; Hellwig's headers chopped for brevity): On Thu, Jan 16, 2025 at 02:17:24PM +0100, Danilo Krummrich wrote: > Since there hasn't been a reply so far, I assume that we're good with > maintaining the DMA Rust abstractions separately. No, I'm not. This was an explicit: Nacked-by: Christoph Hellwig And I also do not want another maintainer. If you want to make Linux im…

[dead]

Re: Resigning as Asahi Linux project lead

#519

Post by steveklabnik »

gkbrk wrote: post #472
Ar-Curunir wrote: post #380

Earlier quoted context omitted.

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.

This is not what the "Rust kernel policy" [1] of Rust for Linux says. [1]: https://rust-for-linux.com/rust-kernel-policy > Who is responsible if a C change breaks a build with Rust enabled? > The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust. > Didn't you promise Rust wouldn't be extra work for maintainers? > No, we did not. Since th…

You conveniently left out

> However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.

Re: Resigning as Asahi Linux project lead

#520

Post by stirlo »

adgjlsfhk1 wrote: post #370
surajrmal wrote: post #298

Earlier quoted context omitted.

The thread didn't really have drama before marcan stirred the pot. There was a disagreement, but the individuals pushing for the merge were not attempting to escalate, only try to find a path forward in a way that might make both parties happy with the compromise. The drama and social media outrage arguably did nothing to help, and as far as I can tell, simply makes for good entertainment for onlookers who like to go…

I think this isn't the right take. the "disagreement" was a kernel maintainer saying "Rust in the Linux kernel is a mistake and I will do everything in my power to sabotage Rust adoption" (as feedback on version 8 of a patch). The fact that open undermining of Rust for Linux receives no pushback from Linus or anyone else with power in the Kernel is shocking.

100% this. Yes, Hector went nuclear, but he begged Linus to step in and provide leadership (either merge or reject) and instead Linus ignored the whole technical issue with regards to rust being totally blocked.

Even now with Hector out of the picture, there’s still no suitable path forward for rust in Linux. No wonder why people are giving up (exactly what the blockers want).

Post reply on HN