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

421–430 of 1001 posts

Re: Resigning as Asahi Linux project lead

#421

Post by rat87 »

thw8419 wrote: post #97

The Rust situation was handled badly. Two languages (one of which has panics and all sorts of version issues) in one kernel are clearly not viable. Linus should have put his foot down and mandated C instead of stringing people along. That of course was difficult in the corporate environment of 2014-2024. Perhaps he was forced to do it. In many areas, sanity has returned, so perhaps we can get clearer messaging again…

> That of course was difficult in the corporate environment of 2014-2024.

No clue what you could mean by this

>Perhaps he was forced to do it.

By whom? Linus is the one who decides these things.

Re: Resigning as Asahi Linux project lead

#422

Post by dataflow »

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…

> It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining it after that. They have maximum leverage at review time, and 0 leverage after.

I don't follow. The one with zero leverage is the contributor, no? They have to beg and plead with the maintainers to get anything done. Whereas the maintainers can yank code out at any time, at least before when the code makes it into an official stable release. (Which they can control - if they're not sure, they can disable the code to delay the release as long as they want.)

Re: Resigning as Asahi Linux project lead

#423

Post by judofyr »

kibwen wrote: post #349
judofyr wrote: post #263

Earlier quoted context omitted.

> "which is actively hostile to a second Rust compiler implementation" - except that isn't true? Historically the Rust community has been extremely hostile towards gccrs. Many have claimed that the work would be detrimental to Rust as a language since it would split the language in two (despite gccrs constantly claiming they're not trying to do that). I'm not sure if it was an opinion shared by the core team, but if…

The LKML quote is alleging that the upstream language developers (as opposed to random users on Reddit) are opposed to the idea of multiple implementations, which is plainly false, as evidenced by the link to the official blog post celebrating gccrs. Ted T'so is speaking from ignorance here.

(emphasis mine)

> opposed to the idea of multiple implementations, which is plainly false, as evidenced by the link to the official blog post celebrating gccrs. Ted T'so is speaking from ignorance here.

Why use so strong words? Yes, there's clearly a misunderstanding here, but why do we need to use equally negative words towards them? Isn't it more interesting to discuss why they have this impression? Maybe there's something with the communication from the upstream language developers which hasn't been clear enough? It's a blog post which is a few months old so if that's the only signal it's maybe not so strange that they've missed it?

Or maybe they are just actively lying because they have their own agenda. But I don't see how this kind of communication, assuming the worst of the other part, beings us any closer.

Re: Resigning as Asahi Linux project lead

#424

Post by fluoridation »

mustache_kimono wrote: post #121
chongli wrote: post #68

Earlier quoted context omitted.

Brigading has no place in open source communities. There are some members of the Rust community who believe C is obsolete and that C programmers should either switch to Rust or get out of the way. This is an extremely toxic attitude that has no place in the Linux kernel! The fact remains: Rust doesn’t solve all of C’s problems. It trades them off for a whole lot of new problems, many of which are challenging to addre…

> Brigading has no place in open source communities. Agreed. > There are some members of the Rust community who believe C is obsolete and that C programmers should either switch to Rust or get out of the way. This is an extremely toxic attitude that has no place in the Linux kernel! Would you care to share some examples of the Rust for Linux community who have said this? I'm unaware of Hector or anyone else saying an…

>Would you care to share some examples of the Rust for Linux community who have said this? I'm unaware of Hector or anyone else saying anything similar?

In fact, he said that as his very first reply to that thread:

https://lore.kernel.org/lkml/2b9b75d1-eb8e-494a-b05f-59f75c9...

>Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they're going to be on the losing side of history sooner or later. No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages.

Re: Resigning as Asahi Linux project lead

#425

Post by 4bpp »

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

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

> "no one will be forced to use Rust in the Kernel"

Is this true, though? One reason for this altercation seems to be the basic circumstance that in Linux kernel development, if there is a dependency between two pieces of code A and B, the responsibility to keep B consistent with changes to A lies, in order, with anyone proposing patches to A, the subsystem maintainer for A, and finally the subsystem maintainer for B. If B is Rust code, such as a binding, then that's potentially up to 3 people who don't want to use Rust being forced to use Rust.

Re: Resigning as Asahi Linux project lead

#426

Post by afr0ck »

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.

This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.

Re: Resigning as Asahi Linux project lead

#427

Post by ajross »

jrvidal wrote: post #290
cornstalks wrote: post #229

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

Re: Resigning as Asahi Linux project lead

#428

Post by eyelidlessness »

95014_refugee wrote: post #396
jorvi wrote: post #305

Earlier quoted context omitted.

Its quite a well-known wisdom. I think someone in one of Nintendo or Sony's studios has said it too, in the form of: a complaint is worth twice a compliment. Satisfied customers will tell you they think your stuff is great, but dissatisfied customers will be able to hone in on exactly where the problem is. You can even extend this to personal life: if someone tells you your shabby car doesn't fit with the nice suits…

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)

You knew what they meant, which is clear if you’re able to correct the use of language accurately. This isn’t a criticism per se, but an acknowledgment that language evolves and part of the way it does that is acceptance that “incorrect” usage, once common enough, is seldom reversed.

Re: Resigning as Asahi Linux project lead

#429

Post by steveklabnik »

judofyr wrote: post #263
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" - except that isn't true? Historically the Rust community has been extremely hostile towards gccrs. Many have claimed that the work would be detrimental to Rust as a language since it would split the language in two (despite gccrs constantly claiming they're not trying to do that). I'm not sure if it was an opinion shared by the core team, but if…

For whatever it's worth, I did believe that some of the Rust team was very hostile towards gccrs, but that behavior has completely changed, and it seems like they're receiving a lot of support these days.

Reddit... is reddit.

Re: Resigning as Asahi Linux project lead

#430

Post by shortstuffsushi »

citruscomputing wrote: post #355
throwaway2037 wrote: post #266

Earlier quoted context omitted.

Thank you to share the Ted T'so LKM post. Can you explain the culture reference "thin blue line"? I never heard it before.

As important context, it gained popularity in response to the Black Lives Matter movement.

I think you might be mistaking the "thin blue line" concept with the "blue / all lives matter" in this case, thin blue line is neither new nor newly popular with BLM.
Post reply on HN