Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

451–460 of 1001 posts

Re: Resigning as Asahi Linux project lead

#451

Earlier quoted context omitted.

That's just not true. If the user has defined on the struct and a trait also has the method name, the struct's impl is used. Multiple traits can have methods named the same too. https://play.rust-lang.org/?version=stable&mode=debug&editio...

My comment might have been technically wrong as originally stated; I’ve since edited to try to correct/clarify. What I really meant is the case where a method is added to a standard struct impl that conflicts with a user-defined trait. For example, you might have implemented some trait OptionExt on Option with a method called foo. If now a method called foo is added to the standard option struct, it will conflict.

Look at the linked code - it literally shows what happens in that case. What happens is not what you're saying.

Re: Resigning as Asahi Linux project lead

#452
> I cannot work with those who denounce calling out misbehavior on social media to thousands of followers, while themselves roasting people both on social media and on mailing lists with thousands of subscribers.

That person is someone called `Sima` and their posts on Mastodon are pure gas lighting. These are the worst abusers.

Re: Resigning as Asahi Linux project lead

#453

Drama needs to be worked against, not expanded upon. A lot of what I’m reading seems to make me feel that drama was… not avoided by this person, putting it charitably. And I'm someone who I believe still sponsors them! Asahi Linux is an awesome, and dare I say necessary, project. There is value in learning how to relinquish a constant "defensive posture" mentally. (I have struggled with, and am still working through…

Agreed. There's such a victim mentality throughout this post. While it's clear that marcan faced into headwinds, they're also definitely not somebody that I want to be around me in any kind of leadership position.

Can’t say I’d want you on the team characterizing a situation like this, and communicating about a situation like this, as “victim mentality.”

There’s a lot of toxic behaviors that have wormed their way into certain parts of culture. I’m not as concerned about bright, brash men like Hector.

Re: Resigning as Asahi Linux project lead

#454
post #425

Earlier quoted context omitted.

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

They're not "forced to use Rust". They are maybe forced to work with Rust developers of whichever subsystem needs to be updated, but that would always have been the case with the C developers of whichever subsystem needs to be updated too.

I don't think that is a correct interpretation. As I understand it, Linux does not have a notion of someone being obliged to help facilitate a patch, especially if it's not the narrow case of a maintainer and a patch to the subsystem they are in charge of. What do you do if you are a C developer modifying system A, your change has implications for system B which includes Rust code, and none of the Rust developers involved with B care to volunteer time to draft the necessary changes to Rust code for you?

The same situation of course also arises between C-only subsystems, but then the natural solution is that you have to go and understand system B well enough yourself that you can make the necessary changes to it and submit them as part of your patch. In that situation you are "forced to use C", but that's a free square because you are always forced to use C to contribute to Linux code.

Re: Resigning as Asahi Linux project lead

#455
post #175
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…

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 maximally missing the point.

The proposal would cause large classes of changes to C to break the build, which would dramatically slow down kernel development, even if a small handful of Rust volunteers agree to eventually come in and fix the build.

> You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true.

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. On HN you not infrequently see down voting to indicate disagreement. These clashes with the Linux maintainers look really bad for Rust to me. So bad that I'm pretty convinced Rust as a language is over if they're no longer banging on the technical merits and are instead banging on the table.

I'm sure there are great things about the community. But I would encourage the community to have higher standards of behavior if they want to be taken seriously. The Linux team seem like they're trying to look beyond the childishness because they are optimistic about the technical merits, but they must be so tired of the drama.

Re: Resigning as Asahi Linux project lead

#456
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)

I went down a slight rabbit hole for this: apparently both are correct, although "hone in" doesn't seem to have a ground source and has gotten institutionalized in our lexicon over time.

By the way, I don't mind the nit at all! English is not my first language and I slip up occasionally, so refreshers are welcome :-)

Re: Resigning as Asahi Linux project lead

#457
post #393

Earlier quoted context omitted.

These are often the same classification of individual who tend to modify their viewpoints towards “change is progressing rapidly in an area that I don’t understand and this scares me.” Anytime an expert in a particular area has their expertise challenged or even threatened by a new technology it is perfectly human to react in a way that is defensive towards the perceived threat. Part of growth as a human is recognizi…

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

Re: Resigning as Asahi Linux project lead

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

> Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. This is a very persistent myth, but it’s wrong. Adding any public method to any impl can break BC (because its name might conflict with a user-defined method in a trait), and the Rust project adds methods to standard library impls all the time.

That's true for literally every non static function in C, given the lack of namespaces. So it can't be a blocker.

Re: Resigning as Asahi Linux project lead

#459
post #287
post #225

Earlier quoted context omitted.

I'm not a kernel developer, and never done anything of the sorts either. But, I think the argument is that if they have two versions of something (the C version + the Rust bindings), the logic/behavior/"semantics" of the C version would need to be encoded into the Rust types, and if a C-only developer changes the C version only, how are they supposed to proceed with updating the Rust bindings if they don't want to wr…

Which is a moot point because the agreement right now is that Rust code is allowed to break, so the C developer in question can just ignore Rust, and a Rust person will take care of it for them.

As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes:

https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...

> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.

> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".

> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.

For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?

Re: Resigning as Asahi Linux project lead

#460

Earlier quoted context omitted.

> Not realizing that is a sure road to burnout (and yes, I'm just as guilty of that myself). Humans are shaped by experience. This is both a boon and a curse. I have been also been on the hot end of the stick and burned myself down, sometimes rightly, sometimes wrongly. Understanding that I don't want to go through this anymore was the point I started to change. > Collaborating on software development is a social act…

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.
Post reply on HN