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

331–340 of 1001 posts

Re: Resigning as Asahi Linux project lead

#331

Post by macintux »

ThatGuyRaion wrote: post #258
happyhardcore wrote: post #246

Earlier quoted context omitted.

We don't know if he's gone to the cops, but more often than not the police will not be able to help you in these sorts of situations. The way that Kiwifarms target people is incredibly hard to stop and I don't think they particularly need ammo; the way to not "give them ammo" would be to stop standing up for trans rights, and the fact that he hasn't is commendable.

I replied to another commenter about this, but these sorts of things are basically part and parcel of being a public figure. If you can't handle that, you need to sandbag. There's no other way around it. It is unlikely that Marcan will stop being the center of attention wherever he goes. If he wants to stand up for what he believes to be right, he shouldn't have a problem with the consequences of dealing with people…

> If he wants to stand up for what he believes to be right, he shouldn't have a problem with the consequences of dealing with people who disagree with him, sometimes virulently.

This sounds like victim blaming. I suspect very few people who take a stand are truly prepared for years of abuse, even if they think they are. No one has perfect knowledge of the future.

Re: Resigning as Asahi Linux project lead

#332

Post by tgtweak »

The Rust criticism is valid - the hidden "breaking changes" have been a hallmark of rust releases and anyone maintaining a serious codebase in rust needs to really be on top of testing and validating if they want to stay current - moreso than any other language in the same stable as rust.

You can't however claim the right and reason to refuse PRs and code changes under the moniker of maintenance while simultaneously claiming that the rust community is "actively hostile to a second rust compiler implementation" - you can't have it both ways.

The entire narrative is very indicative of the state of open source unfortunately - incredibly adept programmers getting chewed up by the externalities of maintaining code (and by extension an application). Sometimes it's unappreciative users asking for handouts and sometimes it's other developers (or an organization's development resources) causing contention for a project's trajectory.

I think the entirety of it can be summed up as: forking is there for a reason.

Re: Resigning as Asahi Linux project lead

#333

Post by ThatGuyRaion »

Blot2882 wrote: post #319
ThatGuyRaion wrote: post #187

Marcan brings up plenty of good points regarding contributing to kernel.org being stuck in the 1990s. However, he's got no social skills nor does he have what it takes to man up and understand he won't get his way. Additionally I doubt that he really is dealing with stalkers to the degree that he is implying; real people don't talk about their stalkers so much. When I was stalked and harassed I kept the details light…

> real people don't talk about their stalkers so much. When I was stalked and harassed I kept the details light and didn't provide much in the way of actual community details because I went to the FBI and local police to deal with it You actually provided more details here than he did, so I guess that's not true. >> Suffice it to say, I ended up traveling for most of the year, all the while having to handle various a…

[flagged]

Re: Resigning as Asahi Linux project lead

#334

Post by samsartor »

cornstalks wrote: post #229
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…

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

Removing impl Drop is like removing a function from your C API (or removing any other trait impl): something library authors have to worry about to maintain backwards compatibility with older versions of their library. A surprising amount of Rust's complexity exists specifically because the language developers take this concern seriously, and try to make things easier for library devs. For example, people complain a lot about the orphan rules but they ensure adding a trait impl is never a breaking change.

Re: Resigning as Asahi Linux project lead

#335

Post by richardwhiuk »

margana wrote: post #210
Octoth0rpe wrote: post #9

Well that's unfortunate. It seems like there's a balancing act between the benefits of writing drivers in Rust (easier, more maintainable), and getting those drivers mainlined (apparently soul-destroying, morale killing), I wonder if the Asahi team is considering simply abandoning linux in favor of something more rust friendly (redox being an obvious candidate, but maybe one of the BSDs?). Given the narrow set of har…

The goal of Asahi Linux is to create a Linux distribution that is compatible with Apple devices. Using Rust is not a goal of the project, it's just something they decided to use due to personal preference, and is making the process of upstreaming anything much harder. If anything, it works against them in achieving their goal. Abandoning Rust is a possibility, abandoning Linux is not.

The author addressed that in the article.

Re: Resigning as Asahi Linux project lead

#336

Post by Certhas »

jstimpfle wrote: post #224
Certhas wrote: post #171

Earlier quoted context omitted.

It's also not truthful because many of the Rust maintainers are long time C contributors. Marcan also linked to this resignation of a Rust Maintainer: https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@... which references this fantastic exchange: https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s I am not a C person, or a kernel level person, I just watch this from the sideline to learn something every now…

It's practically impossible to document all your assumptions in the type system. Attempting to do so results in code that is harder to read and write. You have a choice between code that statically asserts all assumptions in the type system but doesn't exist, is slow, or a pain to work with, and code that is beautiful, obvious, performant, but does contain the occasional bug. I am not against static safety, but there…

But if the info is info the user of your code needs in order to interface correctly, the point that you can't document everything is moot. You already have to document this in the documentation anyways.

Re: Resigning as Asahi Linux project lead

#337

Post by unclad5968 »

rdtsc wrote: post #209

A person can be in a tough spot personally and then things seem to spiral out of control around them because that just cannot be 100% isolated from professional stuff or other spheres of life. It seems like this might have happened to Hector based on the post. We've all been there and that part is completely understandable. > I get that some people might not have liked my Mastodon posts. Yes, I can be abrasive someti…

> People will look on Rust community after this and say "Remember that time when _they_ where threatening kernel devs with social media drama?". It's not right but that's the perception that will last.

Happened with actix, happened with serde, and now being threatened by kernel contributors. The perception seems at least somewhat based in reality.

Re: Resigning as Asahi Linux project lead

#338

Post by nayuki »

parasense wrote: post #245
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…

> This is par for the course I guess, and what exhausts folks like marcan. I wouldn't want to work with someone like Ted Tso'o, who clearly has a penchant for flame wars and isn't interested in being truthful. I am acquainted with Ted via the open source community, we have each other on multiple social media networks, and I think he's a really great person. That said, I also recognize when he gets into flame wars wit…

> Ted hates the new MiB/KiB system of base-2 units, and for whatever reasons like the previous more ambiguous system of confusingly mixed base-10/base-2 units of MB/Mb/mb/KB/Kb/kb

Here's my best argument for the binary prefixes: Say you have a cryptographic cipher algorithm that processes 1 byte per clock cycle. Your CPU is 4 GHz. At what rate can your algorithm process data? It's 4 GB/s, not 4 GiB/s.

This stuff happens in telecom all the time. You have DSL and coaxial network connections quantified in bits per second per hertz. If you have megahertz of bandwidth at your disposal, then you have megabits per second of data transfer - not mebibits per second.

Another one: You buy a 16 GB (real GB) flash drive. You have 16 GiB of RAM. Oops, you can't dump your RAM to flash to hibernate, because 16 GiB > 16 GB so it won't fit.

Clarity is important. The lack of clarity is how hundreds of years ago, every town had their own definition of a pound and a yard, and trade was filled with deception. Or even look at today with the multiple definitions of a ton, and also a US gallon versus a UK gallon. I stand by the fact that overloading kilo- to mean 1024 is the original sin.

Re: Resigning as Asahi Linux project lead

#339

Post by throwaway2037 » 

    > I ended up burning out, primarily due to the very large fraction of entitled users.
I stopped reading after this sentence. The God complex is simply too much for me to digest. TL;DR: "I am a programming God; they are newbie peons who refused to bow at my altar of greatness." On other posts about this person, I read multiple comments from people that could be summarised as: "This person is an (amazeballs) amazing programmer, but also a total drama queen." I say, with respect, "You will be missed. Thank you for your contributions."

Re: Resigning as Asahi Linux project lead

#340

Post by mardifoufs »

reshlo wrote: post #310
cogman10 wrote: post #297

Earlier quoted context omitted.

Don't know what to tell you. The C developers have the keys of the kingdom. It's up to the rust devs to appease them. When you are a new-comer to an old project a big part of that is working with the current gatekeepers to get your changes through in a way they'll accept. That can sometimes mean doing things sub optimally in your view. In particular, the DMA maintainer didn't want rust code in their DMA subsystem. Th…

> The workplace equivalent is you publishing a whistle blowing article against a team in your company because they'd not accept a pull request you worked very hard on. The workplace equivalent is your CEO making a public statement that your work is to be supported, then not firing people who openly gloat about their intent to sabotage your work.

I mean, I hope that you'd get fired for trying to publicly shame people who you see as trying to "sabotage" you in any normal corporation, regardless of how much your vision aligns with the CEO's lol.

Not that it even makes sense to call it sabotage considering that most people that were involved in the original debate (in the rust for Linux side) didn't see it like that, that the normal kernel development processes were on their way to actually make the change happen anyways, and that Marcan's actions probably did more to sabotage actual support from other maintainers and Linus himself than the original NACK that started all of this ever did.

(Not that Linus ever even gave a blank check for rust on Linux, so I don't think that disagreements and even NACKs are somehow going against what Linus decided)

Post reply on HN