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

411–420 of 1001 posts

Re: Resigning as Asahi Linux project lead

#411

Post by kllrnohj »

nindalf wrote: 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.

Re: Resigning as Asahi Linux project lead

#412

Post by anonfordays »

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

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.

Re: Resigning as Asahi Linux project lead

#414

Post by [deleted] »

ThatGuyRaion wrote: post #227
SadTrombone wrote: post #221

Earlier quoted context omitted.

> This idea that conflicts need to be resolved quickly and in the favor of a golden boy is a millennial/zoomer issue. This is a strawman with no support behind it in the actual blog post. Marcan's issue wasn't that he wasn't "getting his way", his issue (from his viewpoint) was with Linus and co. claiming to support Rust on Linux while doing nothing to aid in adoption and in the case of some maintainers, actively sab…

If you actually follow the exchange, he threw temper tantrums until he got suspended off Mastodon. I don't know, but that's not what I would expect from a professional developer.

[deleted]

Re: Resigning as Asahi Linux project lead

#415

Post by uecker »

Ar-Curunir wrote: post #380
uecker wrote: 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.

I don't think it is this simple.

Re: Resigning as Asahi Linux project lead

#416

Post by steveklabnik »

cornstalks wrote: post #257
cratermoon wrote: post #239

Earlier quoted context omitted.

I'm curious now. What are the backwards compatibility guarantees for C?

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.

Re: Resigning as Asahi Linux project lead

#417

Post by SXX »

dagmx wrote: post #59

I really feel for Hector. Open source can be brutal, especially with larger and well established projects. I contribute to several projects as a well recognized person in my field, not at their scale, but everything they say rings true. Established developers often push back extremely hard on anything new, until and unless it aligns with their current goals. I’ve had maintainers shut me down without hearing out the m…

This is not something specific to open source. Unfortunately if you want to be well-known person who works on well-known project you must either ignore all the shit thrown at you altogether or you must be very very resilient. When you react to attacks on internet you will be attacked, often.

And while I appreciate Marcan's work a lot he is also partically responsible because he himself often jumped on bandwagon attacking other people exactly the same way.

Re: Resigning as Asahi Linux project lead

#418

Post by School-Cotton »

knowitnone wrote: post #382
gkbrk wrote: post #259

Earlier quoted context omitted.

The backwards compatibility guarantee for C is "C99 compilers can compile C99 code". If they can't, that's a compiler bug. Same for other C standards. Since Rust doesn't have a standard, the guarantee is "whatever the current version of the compiler can compile". To check if they broke anything they compile everything on crates.io (called a crater run). But if you check results of crater runs, almost every release so…

What do you mean? Rust 1.0 can compile Rust 1.0. Rust 1.1 can compile Rust 1.1.

Right, which is basically the opposite of what backwards incompatibility means. Imagine if GCC 14.2.0 was only guaranteed to be able to compile "C 14.2.0".

Re: Resigning as Asahi Linux project lead

#419

Post by ajross »

nindalf wrote: post #206
diggan wrote: 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…

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.

[flagged]

Re: Resigning as Asahi Linux project lead

#420

Post by yaro330 »

joshkel wrote: post #354
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.

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…

The warning argument is silly. It just means that your code is not up to par with the modern standards. -Wall is a moving goalpost and it's getting new warnings added with every release of a TC because TC developers are trying to make your code more secure.
Post reply on HN