It's a shame to see but inevitable when trying to get open software working on such a proprietary platform with so many hardware cut corners and incomplete/non-standard implementations. Just an insane amount of work of the most frustrating kind. What they did manage to do was incredible... but Apple is Apple.
Sure Apple being not as great to develop drivers, but ~99% of the article is about displeasure working with Linux maintainers.
EDIT: Here is the breakdown by paragraphs.
| Paragraph # | Tone |
| ----------- | -------------------------------------------------------------------------- |
| 1 | History recap |
| 2 | History recap |
| 3 | mentions Apple and M1 in positive light. |
| 4 | Mostly positive, slight negative towards Apple not being having good docs. |
| 5 | Negative Linux kernel development (upstreaming) |
| 6 | Negative user focused |
| 7 | Negative user focused, complaints about M3/M4 support. |
| 8 | Negative user reviews |
| 9 | Money troubles regarding support. |
| 10 | Linux maintainers, mostly negative |
| 11 | Unknown 2024 event |
| 12 | Negative about users (demanding more features and support) |
| 13 | Stress about Kernel development |
| 14 | Negative about Linux kernel development roadblock |
| 15 | Negative about Linux kernel development (Linus leadership failures) |
| 16 | Positive about Rust |
| 17 | Negative about Linux kernel development (Why Rust can't wait) |
| 18 | Negative about Linux kernel development (downstreaming) |
| 19 | Negative about Linux maintainer (thin blue line) |
| 20 | Negative about Linux kernel maintainers (two faced) |
| 21 | Negative about Linux kernel maintainers |
| 22 | Negative about Linux (disapointment in refusing invitation) and Linus |
| 23 | Negative about Linux maintainers (being corporate) |
| 24 | Negative about Asahi, and dreading to turn on Apple |
| 25 | Negative about burnout |
| 26 | Resignation |
| 27 | Positive about Asahi Linux team |
| 28 | Hiring proposition. |
18 negative paragraphs
2 about Apple (11%)
4 about users (22%)
12 about Linux/Linus/Maintainers (67%)
I was wrong about it being 99% about LKM but it's more accurate than saying 50% of issues are Apple.
All those "Negative user focused" are actually "Apple proprietary problems" (problems that exist only on apple because of their weird proprietary stuff with no standards following, ie, getting temp on any other system is dead simple). Not sure if you actually believe in your list or you just used an AI that made the mistake.
I counted paragraphs topics myself: History (3), Proprietary Hardware Problems (8), Kernel/Rust problems (8), Other/Quitting (7). Could be off by one or two because I'm not a machine.
Also, I note that you did not disagree with or object to my initial response (the one made before your edit) that it is indeed halfway down the page before rust/kernel stuff is even mentioned.
I think it is safe to say that both Apple and the kernel/rust issues matter here and trying to derail any discussion of Apple's role into even more rust ragebait threads in a HN topic full of them is counterproductive.
No. Those are issues caused by users. You could have most open hardware platform, and it would still persist. See any OSS maintainer complaining about unrealistic user expectations.
How are you counting those? I made a table, point me which exact paragraphs. Also it's deceptive to pull Rust into this story. marcan had nothing but praise for it, without it, he wouldn't be able to write those drivers.
The main complaint of marcan is the horrible experience you have as a hobbyist Linux contributor. You can't blame Rust or Apple for that. That's on Linus, and Linux maintainers.
My sense from the article was that it seems less of an Apple is Apple issue, and more of a Linux maintainers are Linux maintainers issue. The big problems listed are all interpersonal conflicts and a sense that the maintainers were making his life upstreaming Rust changes hell.
I think if I was indicted by Linus and told I'm a problem over spreading awareness about a position on social media, I too would burn out pretty quickly. That's how you crush motivation. There's a deeper issue in open-source culture where harshness and gatekeeping drive away passionate contributors.
> What does social media have to do with bad code, though?
Nothing. That's why this was said:
>> *There's a deeper issue* in open-source culture where harshness and gatekeeping drive away passionate contributors.
It's separate gatekeeping.
I entertained getting involved in the kernel for about 3 days, in college. The process is so complex, I just went on to do other fun things. The drama will turn off others. Organizational apathy is much worse, imo. I have quit jobs for this reason and that was when I got paid to stay.
I disagree. Provoking up a mob on social media will not endear you to anyone. You're just making the gatekeeper's jobs harder, and since their job is hard enough, they will simply gatekeep you to simplify things.
Regardless of whether you think the project should be maintained differently, that's not your call, that's their call. Fork it if you want different policies.
Isn't that also what Linus is doing but on a professional forum, which is even worse? The issue comes down to de-escalation, and there wasn't enough on both sides. It's also not unreasonable to expect more from a figure head who is a role model in open-source development in general.
A maintainer's job is to keep contributors on track and in line so the project moves in the right direction, and he did so on the forum in which it's supposed to happen. Not sure what the issue is.
The last drama wasn't about the guy not liking drama, he just don't like nor want to maintain a codebase with two languages, but I think they really need to say it directly instead of calling it canser and leaving people to think he was calling rust cancer and not multiple languages codebase cancer
Im pretty sure he specifically said the cancer was trying to inter-op 2 languages in a code base and not Rust. Even went on to say that he thinks Rust is good and recommends people implement new Greenfield projects in it.
Aside from hatred of Rust and Rust developers there is a bigger problem. The Rust guys are twisting the C developers' arms to iron out API semantics because there is so much behavior and API usage that can't be defined in C and it's driving C devs insane. The Rust people are doing the right thing but doing the right thing is extremely annoying for the C devs.
If you want your code merged in the kernel, you have to think about things from Linus' perspective. You cannot in any circumstances try to shame someone into adopting an enormous and unsustainable workload.
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.
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 <hch@lst.de>
And I also do not want another maintainer. If you want to make Linux
impossible to maintain due to a cross-language codebase do that in
your driver so that you have to do it instead of spreading this cancer
to core subsystems. (where this cancer explicitly is a cross-language
codebase and not rust itself, just to escape the flameware brigade).
---
Hellwig was abrasive and unreasonable. But there is no need to perpetuate, repeat, and repost absolutely one-sided, self-serving misrepresentations of the words he used.
You don't need to paraphrase. You don't need to guess. You don't need to distill or simplify.
He wrote English so we could read it; stop paraphrasing. It's unhelpful at best and nefarious at worst.
Edit: I think it's very telling that there is a crowd here that would literally downvote the actual quote. Actually it's more sad than anything.
The linked article doesn't say the submitted driver code was awful. In fact, it says Paragon submitted the driver after Linus suggested they submit it.
What the article quotes Linus complaining about is a process issue. Paragon apparently used GitHub's GUI to merge some of their branches rather than the git CLI. Linus would prefer they use the CLI to merge branches because the GitHub GUI reportedly omits important metadata from merge commits, such as the developer email, and encourages uninformative commit messages.
"spreading awareness about a position" isn't a very accurate way to describe what happened. This is the guy who said he wanted to use social media to create a "hall of shame" for kernel developers. Of course Linus told him to knock it off, that's ridiculously unprofessional behavior.
The fact is, you need buy in from other devs and if a dev won't buy in you need to work out a way to avoid them or avoid conflict. It sucks, it slows things down, but frankly making it a "them vs us" is a sure fire way to make them oppose any change you want to make.
Public shaming even more disastrous as there's no better way to entrench someone in a position.
I'm not entirely convinced they meant to truly make a public hall of shame.
It sounded to me like a list of "friends who want to get more involved, I'll let you know who to avoid". Then, I read the interactions that sparked that post, and I could totally understand the frustration from OP's part.
Linus being unwilling to take a real stand on maintainers blocking Rust just because doesn't really help.
> However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.
> Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics.
To me, it sure sounds like Marcan is making the case that they tried other venues, didn't feel like it worked, so they resolved to using their social media following to shame kernel developers if they didn't stop.
Reminder that he did this on the Linux kernel mailing lists. If I was a Linux maintainer who found out that two of the people I'm talking to, are actually with high likelihood the same person secretly maintaining a charade, I wouldn't be far from banning both.
I also certainly wouldn't take any of his complaints about cliques or brigading with any seriousness or self-reflection afterwards.
Having an alter-ego is one thing, but I strongly suspect that he had at least one sock puppet here during the drama with HN [0]
* a brand new account suddenly appears, defending Marcan's behavior (the only comment/post ever of this account) with a very similar writing style
* Marcan immediately "notices" the new comment while doing "random search" (how ? he claims he doesn't browse HN, and even posted a screenshot of news.ycombinator.com being routed to 0.0.0.0 to block his own access to it the day before)
* Marcan highlights the comment in question on his media account [1], praising them "at least [this commenter] gets it"
Only circumstantial stuff, but sure smells very fishy to me.
But the point is that the Rust developers have tried literally everything else.
If the C developers make it a "Them vs Us" thing, there IS NO ALTERNATIVE for the Rust developers.
Linus' reaction is quite literally the equivalent of a parent only punishing the loudest child, not the child that's been silently bullying that kid for months.
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. That sucks, but it means you need to relocate your dma bridge code out of their subsystem. It does mean your driver will be a second-class citizen in the kernel tree (which was always going to be the case for rust).
Linus' reaction was to someone who started a public campaign against another kernel developer and tried to use that following to pressure the maintainers of the kernel to bend to the will of the newcommer. I'm sorry, but I'd also have a pretty negative reaction to that.
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. You don't do that. You handle things internally and privately and sometimes you tell the boss "sorry, I can't get this done because another team is blocking the change and they are unwilling to work with me".
And do not mistake my post. I'm not siding with the C dev just because I'm critiquing the rust dev. Guy sounds like he's too stuck in his way. The problem is you don't get a big well working and long running project like the kernel without having these sorts of long-term maintainers that make the calls and shots on what to reject.
> 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)
NACKs of bad Rust code, or Rust code that you don’t want in the system that you maintain, would be fine. The specific NACK at issue here was a NACK of code that used a maintainer’s API from a language that he didn’t like, which Linus has confirmed is not allowed.
> Maintainers like Hellwig who do not want to integrate Rust do not have to. But they also cannot dictate the language or manner of code that touches their area of control but does not alter it. The pull request Hellwig objected to "DID NOT TOUCH THE DMA LAYER AT ALL," Torvalds writes (all-caps emphasis his), and was "literally just another user of it, in a completely separate subdirectory."
> "Honestly, what you have been doing is basically saying 'as a DMA maintainer I control what the DMA code is used for.' And that is not how any of this works," Torvalds writes.
> Torvalds writes Hellwig that "I respect you technically, and I like working with you," and that he likes when Hellwig "call[s] me out on my bullshit," as there "needs to be people who just stand up to me and tell me I'm full of shit." But, Torvalds writes, "Now I'm calling you out on YOURS."
> The leader goes on to state that maintainers who want to be involved in Rust can be, and can influence what Rust bindings look like. Those who "are taking the 'I don't want to deal with Rust' option," Torvalds writes, can do so—later describing it as a "wall of protection"—but also have no say on Rust code that builds on their C interfaces.
> "Put another way: the 'nobody is forced to deal with Rust' does not imply 'everybody is allowed to veto any Rust code.'" Maintainers might also find space in the middle, being aware of Rust bindings and working with Rust developers, but not actively involved, Torvalds writes.
>In particular, the DMA maintainer didn't want rust code in their DMA subsystem. That sucks, but it means you need to relocate your dma bridge code out of their subsystem
The code was never in the DMA subsystem. At no point was there ever any Rust code in the DMA subsystem.
CH didn't even look at the patch before throwing the wall up. When it was pointed out that the patch already was the way he claimed he wanted it, he came up with a 2nd excuse, and then when that avenue was shut down he said he would do anything to stop Rust being put in the kernel, period, he wouldn't work with any Rust developers and he wouldn't accept adding a second maintainer for his subsystem that would do that engagement either.
From that point it's pretty clear that all previous engagement was just in bad faith.
> If the C developers make it a "Them vs Us" thing, there IS NO ALTERNATIVE for the Rust developers.
There is always an alternative. Exit the project quietly and gracefully if Linus won't show proper leadership. Don't engage in poor behavior back at the C developers, that is just as wrong.
Wow, what an uncharitable read. Are you aware of what that term means? He said it was not about literally shaming people, but showing what contributing to the kernel is like, and even clarified it wouldn't be for public consumption. It's a colloquialism for a resource where peers can learn from each other's mistakes. My high school Spanish class had a hall of shame.
It's a magnitude more professional than the extremely over the top and public emails that Linus shares, which HN jerks off over. I too would be burnt out if people were picking apart what I said so closely but clapping when Linus says "this code is retarded"
Yes I'm aware of that quote, which doesn't make sense to link with the original quote because his intentions with the "Hall of shame" are different from this quote.
This message brings up a lot of valid complaints about talented developers being stonewalled and you're honing in on one word that is not being used the way you think. Again, there are dozens of emails from Linus that are vastly more unprofessional than this.
My complaint is not that this maintainer would be charitable in their reads or should stay on the project, but that they are unevenly being examined because they are not one of the greybeards.
If you don't want a maintainer, that's fine, but to claim it has anything to do with professionalism is dumb when this is seen as communication to admire.
"hall of shame" inherently means it's about literally shaming people. If that isn't what he meant, then he shouldn't have used those words.
> It's a magnitude more professional than the extremely over the top and public emails that Linus shares
Since when do two wrongs make a right? I think it's perfectly fair to say Linus hasn't shown the best leadership here. But that doesn't excuse Marcan's behavior.
1. I think the the DMA maintainer is correct. Don't intertwine implementation languages, that is bad idea and a maintenance hell.
2. Social media "hall of shame"
3. Torvalds is forced to make a statement because of 2. Not 1.
"Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project (...) Personally, I would consider this grounds for removal of Christoph from the Linux project on Code of Conduct violation grounds, but sadly I doubt much will happen other than draining a lot of people's energy and will to continue the project until Linus says "fuck you" or something. (...)"
"Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect. Every experienced kernel submitter has this in their head, maybe it should be finally written down."
"Okay I literally just started this privately and the first 3 names involved are all people named variants on "Christ". Maybe there's a pattern here... religion secretly trying to sabotage the Linux kernel behind the scenes???
Edit: /s because apparently some people need it."
The issue is that Linus put the Rust developers in an impossible position: On the one hand he approved Rust in the kernel, but then never ever ever has the balls to enforce that decision.
Then, the fanatical C developers openly sabotage and work against all the Rust developers efforts. So, the last option for the Rust developers is to take it to social media. Otherwise, the C developers get away with creating a self fulfilling prophecy: Sabotage all Rust efforts, then claim the Rust experiment failed.
Linus didn't seem to ever have the time to actually take a stance, except of course on the social media issue. Fully ignoring all context. It's the equivalent of a school principal suspending the bullied victim for finally snapping and punching their bully.
I agree. Everyone here seems to be criticising Marcan for not being professional, but it’s very difficult to remain professional when the people you’re working with gloat in public that they intend to completely sabotage your work product despite it being given explicit support by the CEO. Why are you the only one criticising the coworkers? I feel like I’m taking crazy pills reading this thread.
Because this thread is about Marcan's behavior, not others'. I think it's perfectly fair to claim that everyone behaved badly in this situation, but the person I replied to was insinuating that Marcan didn't do anything wrong. That is not true, and why I highlighted his behavior.
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 gossip. While it would be nice to have Linus help out here with a clear resolution after escalation, it's clear to me that the behavior marcan displayed is the higher priority problem to address.
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).
Counterpoint: prior to going nuclear, is there any evidence that Marcan directly tried to get Linus's attention, given the huge quanity of mailing-list mail Linus is sure to get every day?
I only see Danilo doing that in that thread. And admittedly Linus didn't respond (and Greg KH only minimally responded). But even CC probably means a lot of mail for top maintainers, and at that point I don't see anything that would've gotten in the way of "send a PR despite the Nacked-by", which has been done in the past.
He literally says in the post he reached out to Linus directly and to this day haven’t gotten a response. He also himself was (trying to) upstream patches for years, usually ending up similarly getting stonewalled
I don't see the word "reach" or any relevant mention of "Linus" in either the "shaming" post or in the resignation post.
Even if there was, I'm not sure I trust the word of such a drama-seeker directly, so it's reasonable to a evidence of on-mailing-list appeals adding CC (as Danilo did), and if that fails mention of contacting Linus off-list in that specific subthread.
>Even now with Hector out of the picture, there’s still no suitable path forward for rust in Linux
The suitable path forward is to submit the patch series like normal to Linus, where it will be merged regardless of CH's NACK. CH isn't able to actually stop this process, he's just being a jerk.
However, I agree with you that it would have been nice to actually publicly clarify the situation rather than ignore it and deal with the whole thing behind closed doors. It shouldn't need to be explained that letting this sort of thing fester is a great way to kill motivation in a project and ensure it's less likely that new people will get involved.
The reasoning Linus himself gives for greenlighting Rust is, among other things, to avoid stagnation.
In practice, CH is doing everything he can to stonewall and sabotage efforts to subsequently bring Rust to solve problems.
This explosion, now, was plainly a consequence of months and months of failure. And that anyone name-calls to blame that failure on “a drama-seeker” leaves me to wonder about the future of Linux 20 years from now.
The rust project is not stalled. There is pushback from maintainers, but as trust is established, things will hopefully change and it'll get easier. Escalating erodes trust and simply will make the process take longer. Anything that fuels us vs them narratives are simply damaging. Everyone needs to focus on the shared objectives of the overall Linux project. Ignoring the maintainers and pretending their opinions are wrong or don't matter won't help. I'm not sure a top down directive is necessarily the right way to establish a healthy space for rust in linux.
> So, the last option for the Rust developers is to take it to social media.
Social media is an amplifier of interpersonal problems, not a place to seek for a resolution for them - unless your intended "resolution" is to beat down the other side, the people you have to work alongside by necessity, via potshots from random strangers who hardly ever bother to inform themselves fully of the situation. That is never going to be a true resolution, and I think Linus, for all his faults, recognizes that and that's why he draws the line there.
The C maintainer in question had no power to stop the code from being merged, it wasn't in his directory. He was tagged as a courtesy in case he wanted to do a drive-by review since the code was wrapping his subsystem. The Rust code being reviewed wasn't written by marcan, and the other Rust developers called him out for taking the argument to social media when the code was likely going to be merged anyway (see https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen... and https://lore.kernel.org/rust-for-linux/CAPM=9tzPR9wd=3Wbjnp-... ).
You’re right, it’s mostly any open source code projects too. I’ve tried to contribute to projects where they ignore my merge request and take my code and merge it in under their own account. I call this behavior “demonstrating the moat” in which the Maintainers are more concerned with maintaining a moat around their project that they actively go out of their way to prevent contribution under the guise that your contribution did not correctly cross the moat. Even if the moat is mostly decorative and ceremonial.
Then turn off merge requests if you don’t want your project accepting contributions. Remove your CONTRIBUTING.md. Stop being welcoming if all you want to do is show off your source code. Don’t have a document explaining that I need to sign an agreement to contribute.
Not to mention stalkers ? Doesn't matter how much you love a community, one or two psychopaths can maybe it simply not-worth-it.
It's hard enough in physical spaces to remove abusers (usually the abused just stop showing up), I can't imagine there's an answer for preventing this kind of behavior in online spaces
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 address in a kernel development setting (and much less of a problem for userspace software).
This makes the “C is obsolete” position even harder to defend and ignoring the concerns of long-term kernel maintainers is not going to get anywhere! I think these folks ought to learn the lesson of Chesterton’s Fence [1] before continuing on their journey to promote Rust, which does a lot of great things!
> 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 anything similar? Or is this just a fear of yours?
I think we should be very clear -- believing the future of systems programming is mostly memory safe isn't the same thing as saying "C programmers should...get out of the way".
I didn't say Rust for Linux community, I said Rust community. Here's an example [1]. You don't have to search online forums and mailing lists very long to find countless others like this.
The problem with the brigading (which has been done by the Rust for Linux community) is that it invites these zealots into the conversation. It's totally inappropriate and not at all constructive towards a compromise.
Plus the stated goal of Rust for Linux is to enable people to write drivers in Rust, not to rewrite the whole kernel in Rust. Yet there are countless people in the wider Rust community that believe Rust is the future and every line of C code still in use should be rewritten in Rust. It's gotten so prominent that "Rewrite it in Rust" has become a meme at this point [2]. There are now many developers in other languages (C and C++ especially) who reject Rust simply because they don't like the community.
I'm quite familiar with both, and Phoronix is much worse. Imagine the worst of flagged/downvoted HN comments, and even worse than that, but instead of being flagged/downvoted, they're just one more comment, which begets replies and further trolling, and gets treated as a fixture. "Oh, there's X again."
> You don't have to search online forums and mailing lists very long to find countless others like this.
So -- you're bothered by people on the internet, but not specifically the Rust for Linux people or the Rust project people? I guess -- I'm sorry people are saying mean things about a programming language on the internet?
There are also just as many (more!) anti-Rust partisans out there too, who say lots of crazy stuff too. I'm not sure there is much to be done about it.
> Yet there are countless people in the wider Rust community that believe Rust is the future and every line of C code still in use should be rewritten in Rust.
So what? Does your C code still run? I'm struggling to understand what the problem is. People are free to think whatever they want, and, if they what to rewrite things in Rust or Swift or Hylo or Zig or Java, that's how many of them learn!
People are free to think whatever they want, and, if they what to rewrite things in Rust or whatever language, that's how many of us learn!
Yes, they're free to rewrite their own projects in Rust. They aren't free to force others to do the same to their projects. That's what this is all about: a prominent R4L community leader tried to use brigading and shaming to force a Linux kernel maintainer into accepting and maintaining Rust code (along with the entire toolchain to support it). The maintainer refused, Linus got involved, and marcan stormed out of the room.
This isn't a debate about technical merits. It's a debate about maturity and what's appropriate for collaborating with others (and what's not). The Rust community has been going through a lot of growing pains over this issue for a while now.
If you're forking the Linux kernel then it becomes your own project, de facto, since you're taking over maintenance of the fork. You're free to rewrite it in Rust when you do that!
Where is anyone forcing anyone else to do a rewrite in Rust?
When hellwig likened the R4L project to a cancer, he was implying exactly this. He saw this one patch as a Trojan horse (in the original Greek sense, not in the computer virus sense) to get Rust into the main kernel tree. This brings all of the toolchain and language issues into it. By relegating Rust to drivers only, the kernel maintainers avoid the issue of having to maintain a cross-language codebase and toolchain, whether they like it or not.
Being a maintainer of a project that accepts patches from contributors is like operating an orphanage. Allowing anyone to just drop off their unwanted babies results in an unmaintainable nightmare. You can say that the Rust for Linux team have been acting in good faith but the very public actions of one of their (now former) leaders contradicts this. The stated goal of the project was to allow drivers to be written in Rust. Adding Rust bindings to the kernel oversteps that goal. It's a legitimate concern.
> The stated goal of the project was to allow drivers to be written in Rust. Adding Rust bindings to the kernel oversteps that goal. It's a legitimate concern.
You do recognize that all drivers will need to bind to some C interfaces? So -- your argument (or the argument you suppose Hellwig has) is that it is better that each driver author recreate each such interface for themselves? Now, when these interfaces break as a result of a change in the underlying C code, instead of fixing that breakage at possibly a single place, that one true binding, now a maintainer might have to fix that breakage in a dozen such places? And this is preferable? This will cause less work for the overburdened maintainer?
You are aware this patch introduced no code into the main kernel tree?
It doesn't have to. By becoming a single point of failure for all Rust drivers that depend on it, it becomes the responsibility of all maintainers of the kernel to avoid breaking it when they change the C interfaces. It's a foothold into a world where all kernel maintainers need to run and test Rust builds, something Christoph does not want the headache of dealing with.
When your teenager brings home a puppy and promises you he'll never let the puppy leave his room, you know that's not true and it won't be long before you're the one taking care of it.
Ultimately it's about motivations. Long-term kernel maintainers are motivated to protect and promote the kernel as a maintainable and successful project. R4L developers, on the other hand, seem more interested in promoting Rust than promoting Linux.
>> You are aware this patch introduced no code into the main kernel tree?
> It doesn't have to.
Ah, it's one of those other kinds of Trojan horses that don't enter the city walls.
> By becoming a single point of failure for all Rust drivers that depend on it, it becomes the responsibility of all maintainers of the kernel to avoid breaking it when they change the C interfaces.
So -- I'll ask what the Rust for Linux people asked Hellwig -- what is your suggested alternative? Where do we go from here? Is it Rust drivers not be allowed to common interfaces ever? In that case, what are the Rust for Linux team doing?
Or is it that you would like Linus rethink his decision re: adding Rust to the kernel? And if so, why didn't Hellwig make that case directly to Linus? What's with all this performative bellyaching on the LKML?
Ah, it's one of those other kinds of Trojan horses that don't enter the city walls.
The kind that have to be invited in, yes.
So -- I'll ask what the Rust for Linux people asked Hellwig -- what is your suggested alternative? Where do we go from here? Is it Rust drivers not be allowed to common interfaces ever? In that case, what are the Rust for Linux team doing?
That's not the kernel team's problem. They provide a common C interface. The fact that there's an impedance mismatch with binding to them from Rust code is a Rust problem.
Or is it that you would like Linus rethink his decision re: adding Rust to the kernel? And if so, why didn't Hellwig make that case directly to Linus? What's with all this performative bellyaching on the LKML?
I don't know what Linus's goals are, apart from keeping his maintainers happy and keeping the kernel rolling along smoothly. That's not a small thing. From what I can see, Christoph has been a maintainer for over 25 years.
Does Linus want to have his cake and eat it too? Sure. But I think he earned that right by building Linux into what it is today. The R4L team hasn't paid their dues. As someone else mentioned, it took 10 years for Clang to become a supported compiler for the kernel.
>Yes, they're free to rewrite their own projects in Rust. They aren't free to force others to do the same to their projects. That's what this is all about: a prominent R4L community leader tried to use brigading and shaming to force a Linux kernel maintainer into accepting and maintaining Rust code (along with the entire toolchain to support it).
Nobody tried to force Christoph into accepting or maintaining Rust code. This was stated repeatedly.
I don't see how you can possibly have actually read the discussion and come to this conclusion. At this point you're just making false accusations and contributing to the flamewar.
They're offering to maintain it themselves but that's not good enough for long-term maintainers. It's like when a teenager brings home a puppy and promises to take care of it. The parents know that they will be the ones looking after it eventually.
I wish I knew of a less condescending analogy but I think it gets the point across. The list of former kernel maintainers is extremely long. Anyone who leaves the project, as marcan did, leaves all of their code for someone else to maintain. This is not a problem for drivers which can be left orphaned. For all other code it is a problem!
You're imposing your own rationales on top of CH, not expressing his own.
He expressed complete opposition to having Rust anywhere in the kernel at all, including places he doesn't maintain. He was opposed to any other maintainer deal with Rust for him, even though Robin Murphy (who is already a reviewer on the DMA side) expressed willingness to do so. His initial replies were an exercise in goal-post-moving.
The kernel is not CH's project. It's not his call to reject things he doesn't like anywhere in the kernel, including places he doesn't personally maintain.
Since Linus backed him up on this issue I’m left with the impression that Christoph is not a lone maintainer standing in the way of the inevitable march of progress; that his concerns are valid and shared by the founder and leader of the project and represent the views of other maintainers who preferred not to step into the ring on this debate.
Furthermore, the Rust code depends on his C dma code. That automatically makes it Christoph’s problem when something breaks, regardless of how many R4L maintainers come and go from the project.
>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:
>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.
> In fact, he said that as his very first reply to that thread:
I think it's clear from the surrounding context that you are likely over-interpreting some of Hector's comments.
What is the losing side of history here? There is simply too much C code in the Linux project to say "stop this ride, I want to get off and only use Rust" right now. This is a fight about some new code. Rust drivers in kernel and perhaps in the future Rust in other places it makes sense. I believe Hector's arguing Rust drivers are inevitable, because they are already here!
What did I say above:
> I think we should be very clear -- believing the future of systems programming is mostly memory safe isn't the same thing as saying "C programmers should...get out of the way".
As I read it, "the losing side of history" refers to insisting on using C, possibly at all. The last part about the "world moving forward towards memory-safe languages" doesn't suggest a limited scope for the statement.
The thread was not about Rust drivers, it was about adding Rust code to the DMA module. I.e. about mixing two different languages in a single module, thus requiring being knowledgeable about both languages in order to maintain it, thus making the module less maintainable. In fact, a few developers were saying that they didn't mind Rust drivers, if they used the C ABI as-is. Someone wanted to expose new Rust-specific interfaces to support cleaner abstractions from Rust drivers.
> The thread was not about Rust drivers, it was about adding Rust code to the DMA module. I.e. about mixing two different languages in a single module
AFAIK this is false. The patch was CCed to the maintainer as FYI, but all the code was in a Rust a module binding to the C DMA interface. If I'm wrong, show me the code.
>I'm just going by what was mentioned in the thread. If that interpretation is wrong, the thread makes no sense.
You've now discovered why this blew up in the first place. All of the excuses used to reject the code were not just petty but also outright false, and trivially so.
My impression is the average Zig programmer is more interested in making a better Linux than trying to prove Zig can be used in Linux.
There are _already_ dozens of hobby OS projects and embedded groups doing systems work in Zig. Everyone knows Zig is a systems language. It doesn't have a chip on their shoulder.
Linux said no brigading. Hector resigns twice and in the second time, despite saying he wouldn’t elaborate on Rust vs Linux, proceeds to blame Linus and start another social media brigade.
Your comment has nothing to do with someone trying to ironically gatekeep me from commenting on Linus' public behavior in response to my comment about gatekeeping.
Oh, bullpucky. People are hostile towards you because A) you employed ludicrously tendential wording, and B) when this was pointed out to you, you refused to own up to it -- or, more probably, to even realise or acknowledge it to yourself. In stead you went on to whine about "gatekeeping".
This kind of rant is typical of the public behaviour of the (typically young and "woke") modern social-media "developer" crowd, and your behaviour here only illustrates why so many dislike them. If there are any "hive mind effects" here, they're in your mind.
"Although you don't see those threads, search engines do. HN uniquely has a high page rank and low moderation, making it a prime target for bad actors to poison search results with abuse, bigotry, and nastiness. This isn't low-level trolling, but an organized attempt to destroy lives, including of developers in our communities."
Funny how this aged, now. Trying to shame people on Mastodon? Totally valid. Trying to chew someone out on a private forum? Now it's an organized attempt to destroy lives.
Always funny to me to read something like that. HN has high moderation, one of the highest I've seen on modern fora, only a few steps below r/AskHistorians for example. I don't see this "abuse, bigotry, and nastiness" here and even if there are comments like that, they are quickly downvoted and dead.
That's not correct, the point is that while the comment might be flag-killed, the subsequent posts in that thread are not and are visible to search engines. For example: if you go to this post [1] from the prior thread while in private/incognito/whatever mode you can see the posts underneath a flagged comment even though you can't see the comment itself. And there are some comments there by other users that, despite being flagged, are still indexable and visible
That's true, but those comments would be flagged too if they're bad enough. Just because a flagged comment exists does not mean the entire subthread is bad.
Right, but that gets into the exact argument that the team is making. When a thread is flagged, that means fewer users are going to open that thread and flag subsequent content or flamebait. It creates a lower moderation environment where those kinds of comments can thrive, which is evident in the same link I posted where you can see what I'm referring to.
As a general point I agree that it would be better that a flag disables replies to the entire subthread (although it shouldn't [dead] it), just because 99% of the time they're just not good discussions. However, the claim that this is somehow "destroying lives" is rather unserious. Whatever may or may not be going on on Kiwifarms has little to do with HN, and the occasional idiotic comment on HN is ... just the occasional idiotic comment on HN. There are also not really that many of them.
Also, I'll add that whenever I've seen an unflagged hateful comment I've emailed hn@ycombinator.com, and the success rate in getting the comment killed and people told off (or banned) is thus far exactly 100%. This usually happens if someone leaves a comment a few days after the discussion dies down, so few see (and flag) it.
If they are flagged, how would they thrive? Fewer people are seeing them as you mention (and even then, many people do have showdead turned on and flag those comments). None of the non-flagged comments on that thread to me (at first glance on a quick skim, anyway) seem like they are "abusive" or "toxic" or whatever other word wants to be used by Asahi it seems like. Indeed, people are pointing out that you can't censor opinions on a forum that you don't control such as HN.
No, IMO that point is wrong and stupid: I surf HN with Showdead on, so I've seen that the overwhelming majority of responses to dead comments are pushback on whatever got the parent comment flagged in the first place. So if any content here gets "unduly emphasised" this way, it's anti-"evil" content.
HN is pretty low moderation across the axis of personal attacks. If you politely say a ad hominem or racist or *-phobic thing here, it's unlikely you'll be moderated for it, for instance.
I can dig up many such examples, but I suspect the response would be, "of course that's not moderated" because this community has a different set of values than some others.
Moderation is always an editorial action, and as such we tend to view it as strong when it aligns with our own values and weak when it doesn't.
That doesn't match my experience of what we do, so I'd like to see those "many such examples".
IMO, if you're going to make charges like this, which would be serious if they were true, you should include links so readers can make up their own minds.
My methodology:
Search for any of the following terms: woman, biological, Black, Latino, gay, trans, woke, dei, or virtue signal
Set to "Comments" and "30 days". You'll find plenty of people saying things that are pretty awful. Yes, they are not the majority of posts, this place isn't a cesspool, it's just a place that permits "just asking questions" or "it's up for debate" as a defense for behavior
Of the remaining 3 of the 10, I disagree with you about saagarjha's comment: https://news.ycombinator.com/item?id=42907076. That one seems thoughtful and in keeping with the site guidelines. It does use a lot of sort-of trigger words (I counted "trans", "vegan", "left wing", "Democrat", "progressive", "conservatism", "Republican"), but surely we're not going to punish people just for using words like that.
The other two seemed borderline to me, although I confess that one was so long that I couldn't read it before becoming le tired.
> I could find many, MANY more examples.
I'd be interested in seeing them, and I hope it's clear that I mean that. I don't want to argue about this—I want to see what you're seeing.
I think saagarjhas comment is probably a transcription error on my part, copying the wrong link out of a thread that had questionable stuff in it.
I'll dig up some more. They tend to be a bit stochastic, and on various topics. (There was an article that made the front page awhile back written about pg that was written by a trans woman that was an absolute lightning rod for this, iirc.)
I don't think HN has high moderation at all. High moderation would imply stricter and quicker punishment for making rancid remarks.
There were a number of remarks on the prior thread by people making conspiracy claims, harassment, insults etc. Some of them get flag-killed, some just down voted but ultimately the users on the site still remain.
Of course I'm not one to be above such a thing in terms of insulting people occasionally but HN is really quite permissive in terms of what you can post and get away with. It takes consistent and repeated bad behavior to get a warning, and even more to get banned. And if you're an expert in being politely venomous you can get away with even more. That's why the outside perception of HN tends to be a lot worse than the inward one.
> Hi! It looks like you might have come from Hacker News.
> Asahi Linux developers are frequent targets of abuse on Hacker News. Despite our pleas, the moderators have not taken effective action to improve the situation.
> Overtly hateful content is often flagged on HN and not immediately visible. Unfortunately, when a comment is flagged and killed, its child subthread is not. That preserves the 'clean' image of the website, but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do. HN uniquely has a high page rank and low moderation, making it a prime target for bad actors to poison search results with abuse, bigotry, and nastiness. This isn't low-level trolling, but an organized attempt to destroy lives, including of developers in our communities.
> Please demand change within your community.
This is an unfair and gross assessment. I've lost some respect from Asahi for this.
They're calling for extreme moderation of opinions they don't agree with, which is the opposite of open discourse.
Asahi: deal with it. You're Streisand Effecting this. Your inability to handle drama is actually causing more drama. Just turn the other cheek and ignore it.
If the opinions they don't agree with exist on Hacker News, and they do (check the dead comments in just about any thread where Asahi Linux comes up) then it isn't an unfair assessment at all.
What is the "it" that you're insisting they "deal with," here? What is the "drama?"
Also what value does bigotry, homophobia and transphobia have in open discourse that it must be preserved? None of that is on topic for Hacker News, why must it be on topic for the Asahi Linux community?
Turn the other cheek. Ignore it. It's 2025 we're learning lessons from USENET all over again and having to reign in the over-sensitive, disregulated behavior of some people.
I'm gay, on the spectrum, and my wife is trans. What certain people in "my" community do from places of relative comfort makes life for those of us in more moderate / conservative-leaning places worse. The screeching from our community [2] has turned our little demographic into a major culture war topic, and it's all because of the bad attention and friction you manufacture.
Conservatives let LGBT and trans issues slide for over two decades of my adult life. But by being loud and attempting to silence them -- by harassing them -- you've become the nail that sticks out and have now created a tidal wave of opinion against us.
It's easy for some European or SF trans person to call for universal outlawing and censoring of speech, but you have to realize your message is being read all over the world. It's interpreted by an overwhelming number of people as attempting to memory hole conservatives and flush away their culture.
Simultaneous to your harmful messages, folks are also being inundated with social media rage/engagement bait to make them think liberals are literally attempting to destroy and annihilate conservatives [3].
Your message adds weight to this perception, and all you accomplish here is making the majority of voters angry at us. It even turns moderates and would-be supporters sour.
I hate that you represent me by association and think that this is acceptable behavior.
As another anecdote, when I talk to my friends about Rust, the subject of "drama" frequently comes up. Why is that? Suddenly my work becomes harder for an entirely unrelated and unmerited reason. That's just me as an LGBT person - imagine how straight people feel.
We shouldn't have to keep reading about this over and over. It's orthogonal, childish, dysfunctional behavior.
Take one more look at that loud disgusting banner on the top of the Asahi page. That's neener-neenering in front of everyone. Even the moderates you hope to be your allies. Please, for god's sake, put yourself into different shoes. You're asking them to do it for you, but it's your turn.
I think you'll see that your behavior is also harassment.
Please calm down, slow down, and behave like adults. Not everything warrants a response or attention. Chances are, it'll just go away and get totally ignored. When you engage, you shift the conversation and bring yourselves down to their level. You create a firestorm of drama that everyone watches like a burning wreck.
Stand above that.
[1] I only wanted to talk about the very public, inflammatory resignation and the immature handling of this by certain parties.
> Conservatives let LGBT and trans issues slide for over two decades of my adult life. But by being loud and attempting to silence them -- by harassing them -- you've become the nail that sticks out and have now created a tidal wave of opinion against us.
In the US, DADT was repealed in 2011. Obergefell was 2015. The idea that they let LGBT and trans issues slide for over 20 years is fundamentally wrong and not supported by history.
I reject the rest of your post and the defense of those that would take rights away from individuals and myself because they have to be coddled.
I would like to first acknowledge the feelings of what I read to be anger, frustration & pain you expressed in your comment. (If I've misinterpreted what you've written, I am open to reading further clarification if that's something you felt like investing effort into.)
While my life experience has been different to yours, from what you've written about how you've been treated by others in your community, as a consequence of who you are, it seems understandable to me that you might experience those feelings--and, even if they didn't seem understandable to me, it is more important to me that you feel heard and your feelings acknowledged as valid and not dismissed.
I hope I have been able to communicate that intent effectively.
----
At the risk of falling into the stereotype traps of "straight white male thinks every rhetorical invitation is a literal invitation for him to say what he thinks" & "straight-splaining" I did want to provide an answer to the question in the last sentence here:
> "As another anecdote, when I talk to my friends about Rust, the subject of "drama" frequently comes up. Why is that? Suddenly my work becomes harder for an entirely unrelated and unmerited reason. That's just me as an LGBT person - imagine how straight people feel."
(I preface the following with an acknowledgement that it's bullshit that you have had to deal with the impact of this rather than the predominantly straight white males who don't want to be made to feel uncomfortable.)
TL;DR:
FWIW, from my perspective as a straight white male I feel the subject of "Public Interpersonal Conflict" attributed to Rust is directly related to values rightfully espoused/embodied by the Rust project/community/language that are at odds with values held by other groups.
Specifically, groups consisting of predominantly straight white males believe that the comfort of predominantly highly skilled straight white males should be prioritized over the physical well-being of other humans; and, also over the security and stability of the software other humans use.
They are also unlikely to agree with this characterization.
Unlike the above group however, rather than targeting resentment at the people whose physical well-being is at risk I choose to direct my resentment at the predominantly straight white males who choose to dismiss important issues as unimportant "drama" because they resent being "made" to think about issues that impact people other than themselves.
----
For anyone who disagrees with my characterization I would point out that we do not know what other contributions Alan Turing may have contributed beyond "Turing Completeness" & "the Turing Test" to current in-demand fields such as AI if he hadn't been persecuted for not being a straight white male.
I would also remind them the ARM CPU attached to that unified memory on which they're running their latest AGI & LLM models is thanks to another person some people in the present day think should be persecuted for daring to exist.
But equally people shouldn't have to trade advancements in the field of Computer Science for the right to exist without persecution.
----
I will acknowledge that its entirely understandable to want to avoid the associated discomfort because from personal experience it is very uncomfortable to have to re-evaluate one's place & responsibility in the world after a lifetime of being told something different.
----
The other ~2,500 words I wrote on the topic was certainly more nuanced but pretty much said the same thing with more beating around the bush with additional personal context.
For any straight white males who may be confused why someone might think as I do, all I can say is that time spent reading/listening to this (unfortunately, archived) resource is likely to be worthwhile, if temporaril...
seconded. even if it was completely true criticism, which it categorically is not, putting up a half-page banner is extremely gauche and immature.
saying things like "an organized attempt to destroy lives, including of developers in our communities" is patently not true. trolls get flagged. honest nice people who don't agree with you aren't trying to destroy anything and nor do they hate you.
I'm unsure whether the most charitable reading of your comment is to assume you missed that these linked phrases exist on the original site but were not included in the text copied into the comment above, or something else:
While you may be correct that initial "trolls get flagged", the statement on the Asahi site agrees that while the initial comment may be flagged & killed, the other comments in the subthread are still indexed, visible & tend not to get moderated/flag:
"Unfortunately, when a comment is flagged and killed, its child subthread is not. [...] but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do."
Based on other remarks about the content of such subthreads it seems surprising to claim that follow-on comments are made by "honest nice people".
I'm as much of a fan of adverbs as the next person but using words like "categorically", "extremely" & "patently" doesn't seem to leave much room for nuance of interpretation when written by someone who I'd have assumed was a third party observer?
While I could understand someone describing JWZ's HN-tailored "banner" (I wouldn't suggest researching this if anyone is not already familiar) gauche and immature, it feels like somewhat of a stretch in relation to a plain text message who last sentence starts with "Please".
disagree, strongly. kiwi-farms has nothing to do with hn. if kiwi-farms starts brigading and spamming/trolling on hn, it gets flagged.
> the other comments in the subthread are still indexed, visible & tend not to get moderated/flagged
indexed: please complain to google.
visible: not unless you turn on show-dead. so don't do that.
don't get moderated: they are already dead.
> I'm as much of a fan of adverbs
i mean what i said. i'm extremely tired of seeing histrionics and exaggerations, misplaced blame, etc. turned into loud, unfair, criticism toward what is probably the best moderated group i can think of.
JWZ's banner is at least recognizable as satire, and his opinions are well known. i can disagree with him, but still find it a little bit funny (and immature). but if you do the same thing (yes, with a please), then you are just exactly as mature. and if you are serious, less grounded in reality and not nearly as funny.
> I'm unsure whether the most charitable reading of your comment is to assume you missed that these linked phrases exist on the original site but were not included in the text copied into the comment above, or something else:
As has already been pointed out, HN isn't "Kiwi Farms" (whatever that is), so WTF does that have to do with their whining specifically about HN???
> While you may be correct that initial "trolls get flagged", the statement on the Asahi site agrees that while the initial comment may be flagged & killed, the other comments in the subthread are still indexed, visible & tend not to get moderated/flag:
> "Unfortunately, when a comment is flagged and killed, its child subthread is not. [...] but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do."
And what's the problem with, I assume they mean, not all comments in subthreads of dead comments also being automatically killed? I read HN with "Show dead" on, so I get to see those with a simple click of "[... more]", and I usually open them. What I've found is that the absolute majority of these responses are sensible comments pointing out what's wrong with the original inappropriate comment.
So the "problem" they're complaining about is not only not a problem; it's actually the remedy for that exact issue. The banner is not only childishly whiny, but actually self-contradictory. In short, it's stupid.
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 hardware they're aiming to support and that they're writing many of their own drivers _anyway_ (and so are not relying as much on the large # of existing linux drivers), that approach might be more viable. I'd be surprised if the Asahi GPU work wasn't the largest problem by far that their team faces, and as such it would make sense to choose a kernel that lowers the difficulty on that aspect to the greatest degree possible.
> Given the narrow set of hardware they're aiming to support and that they're writing many of their own drivers _anyway_ (and so are not relying as much on the large # of existing linux drivers), that approach might be more viable.
They are relying heavily on mesa. I'd also assume that GNU stuff is also pretty essential.
Perhaps Android would be possible? It has a HAL that might be easier to work with than the raw linux kernel. The android devs have put in a lot of effort to make downstream driver development not painful. With android, they'd also still have GNU stuff available.
The big issue is non-linux will mean every single open source tool may have a compatibility problem. You also end up dumping a huge amount of capabilities (like running docker containers).
Isn't mesa portable? Or are there parts that are OS-specific?
> With android, they'd also still have GNU stuff available.
I don't follow; Android is a non-GNU Linux distro. Or do you mean that being on Linux makes GNU stuff easy? (But then, GNU runs happily on BSDs and other unix-likes)
> Isn't mesa portable? Or are there parts that are OS-specific?
IDK. I'm not familiar with mesa enough to know how portable it is. That said, I do know that it's primarily deployed on linux. An issue with portability is simply that when big projects like mesa are developed, non-linux environments are rarely developed (No clue, for example, if you can build mesa for BSD).
> Or do you mean that being on Linux makes GNU stuff easy?
Mostly this. I don't think, for example, those GNU tools will port over to redox. Building them targeting android is a snap.
> Isn't mesa portable? Or are there parts that are OS-specific?
Even the OS-specific parts are at least permissively-licensed. OpenBSD is about as religious about "all new code must be under an ISC-compatible license" as it gets, and even they pull in Linux DRM/Mesa code for hardware graphics acceleration: https://man.openbsd.org/drm.7
Android would still come with the kernel development caveats which is where Asahi is having the most trouble. Android's HALs help abstract the userspace portion of drivers, but if you need to be in kernel space you're still stuck dealing with Linux. You could stick to just doing forks of the LTS releases, but then you're choosing between less-frequent-but-bigger merge conflicts every couple years vs. small-but-constant merge conflicts continuously.
> I wonder if the Asahi team is considering simply abandoning linux in favor of something more rust friendly
The entire point of Asahi is to run Linux on macOS (edit: on Mac hardware, not macOS). If they did what you’re suggesting it would be a completely different project.
Well, I wonder if this is a good time for people to reconsider what they actually want out of Asahi. Things that I'm sure are on the list are open source, able to run the tools they want (standard gnu userland?), docker, maybe gnome/kde? I am not convinced that the linux kernel specifically is on that list.
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.
I think neither is a possibilty: there is zero appetite for rewrite what they've written in rust in C, I think the most likely result of it not being upstreamed is it becomes a long-lived fork.
Its sad that they chose Apple, instead of like investing time into the upcoming ARM laptops to make the Linux more optimized on them. That talent should not be wasted on tech jewelry.
The MBP is the best laptop hardware that exists on the market, by far. Why wouldn't someone who prefers Linux over macOS want to run Linux on it?
The existence of other ARM laptops is irrelevant; the reason MBPs are so good has little to do with ARM. Yes x86 makes the processor frontend more complicated but this doesn't make a big enough difference to come close to accounting for how much better the MBP is than its competitors. I would guess the biggest factors are Apple's ability to buy the entire run of TSMC's best process node, and the fact that they have a high level of competence at designing CPU cores and other hardware. The instruction set the core uses is just not that important in comparison.
>The MBP is the best laptop hardware that exists on the market, by far.
Really?
What is so great about a locked down hardware, locked down software machine, that phones home to Apple all the time?
The only reason to get Macs is if you have a niche case of needing long battery life (most people don't, even if they say they do), but this is where the other ARM laptops are gonna also be good, without all the proprietary crap.
I expect you are rage-baiting, but just in case you are not...
Even if you consider the hardware "tech jewelry", isn't it strictly better to have a way to run Linux on it instead of sending it to landfill? Seems silly to exclude a particular set of hardware from consideration for arbitrary reasons?
Not rage bating. Im legitimately suprised by how many tech people hype up the MBP for no reason what so ever. If the laptops were half the price, they would be worth it from a tech perspective considering what you get.
>isn't it strictly better to have a way to run Linux on it
In a perfect world, Apple would open source the firmware, which would let people just compile the linux driver for it. While Asahi project is cool in terms of figuring stuff out, ultimately its a lost cause because Apple will never be on board.
> Abandoning Rust is a possibility, abandoning Linux is not.
The Asahi developers have repeatedly and publicly asserted that were it not for Rust they would not have been able to achieve the level of quality required for the project, at the speed they did, with as small of a team as they have. From the article:
> Rust is the entire reason our GPU driver was able to succeed in the time it did.
Rust is just a better and more productive language than C (I guess this is a subjective statement, but obviously they would think so and I would agree with them).
Nobody ever claimed that it's impossible to write these drivers in C -- C is "Rust-complete" in the sense that you could in theory write a compiler that translates any Rust program to C.
They're just claiming that Rust allowed them to write much higher-quality code, much faster, which seems plausible.
Redox would probably be the best option. The BSDs, it would probably be an uphill fight to. I believe it's been floated, but no movement on incorporating Rust in the BSD kernels. So I they would have to start form scratch. The benefit of Linux in this case is, the Asahi team isn't single handily doing all the Rust in the Linux kernel, right. There are other Rust people and Rust for Linux was already getting somewhat bootstrapped before the Asahi project. With the BSDs, you would have to start with bootstrapping Rust in the kernels and build systems.
FreeBSD may be open to it? It's been awhile, and I haven't kept up to date on it for a year or two. But once again, I think you'd have to start from scratch. So everything for R4L that was built before Asahi Linux needs to be done on the FreeBSD side.
NetBSD is probably a no go. NetBSD supports architectures that Rust (due to LLVM) can't support. Which means it is most likely a no go for NetBSD, NetBSD's schtick is that it can run on anything and they will fully do everything in their power to make sure NetBSD can run on any hardware and be maintained. Hardware portability matters for them.
The attitude I've seen from OpenBSD devs is, the answer is to 'git gud' at C and, not replace C code with Rust. Or in other words, they have no interest in Rust in the OpenBSD kernel.
I don't really know where DragonFlyBSD falls in this. Its the BSD I know the least about.
God bless. Asahi introduced me to fedora/gnome, it feels rock solid on my m1 MacBook, and it's now my daily driver on a 2014 Intel Mac mini
Wishing I had donated before, I'll sign up for opencollective now. I can only imagine the anticlimactic nature of releasing the emulation stack for gaming [0] and not seeing any increase in interest financially. One wonders what funding might have made it more worthwhile than simply passing the hat.
OT, Have you had any issues with WiFi setup with this Mac Mini? I tried multiple distributions and most of them have troubles with detecting WiFi chip on 2014 mini.
Oh that could be, I just have it hardwired. This machine was basically a dumpster dive and was sitting in my closet for the last few years til I found out it had USB3 and gigabit ethernet, did a SSD swap and its working great, but indeed I get "No Wi-Fi Adapter Found"
> But then also came the entitled users. This time, it wasn’t about stealing games, it was about features. “When is Thunderbolt coming?” “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS” (nobody ever complained when compared to x86 laptops…) “I can’t even check my CPU temperature” (yes, I seriously got that one).
This sounds so rough. I can't imagine pouring your heart out into this labor of love and continue to have to face something like this. Back in the early days of Quora, when it used to be good, there used to be a be nice be respectful policy (they might still have it), I wonder if something like that would be helpful for open source community engagement.
Regardless, major props to Marcan for doing the great work that he did, our community is lucky to have people like him!
This is every successful product, small, medium, large. I've never ever worked on a big corporate or small personal project and not experienced this.
The secret is to have a healthy system for taking in those requests, queueing them by priority, and saying, "you are 117 in the queue, you can make it faster by contributing or by explaining why its higher priority".
You can't let feature requests get to you, the moment you do your users become your opponent. None of those requests are entitled, the author has clearly already reached a point where they are antagonistic towards requests.
Yes, this is pretty normal; in paid products I even find it's less aggressive than in free things. But I have a hard and frozen shell around my vital organs to just politely and friendly point to the place in queue and where to donate to speed it up. For $10k I will build your cpu temp proc, if that's not an option then it's in pos #17463 of my task list.
Yes. I was developing some open source stuff before venturing to for-profit closed Source Software, and I was surprised that the paying customers were on average much nicer than those who got their stuff for free!
When you pay for something, you’ve already demonstrated that you value whatever it is (a product, a service, etc). Free stuff tends to attract people who don’t value the thing.
There's also a level of professionalism depending on the product. When I'm responsible for an MSP team I'm very polite to them and always try to get them good, detailed, high-quality information when I'm telling them about problems with their work product, because I want them to do good work quickly and that's the best way to do that.
Yea, I'm not sure it's open-source vs other software. It's public vs. professional insiders.
My company's bug tracker is mostly internally-filed bugs, but accepts bugs from the public. The difference in tone and attitude is night and day. The public-filed bugs can be wild, varying across: Rude, entitled, arrogant, demanding, incoherent, insulting, irrelevant, impatient... They are also the worst when it comes to actually including enough information to investigate. Frequently filed without logs, without reproduction steps, sometimes without even saying what the filer thinks is wrong. We get bugs with titles "It doesn't work" and with a text description that reads like a fever dream from someone very unwell.
We do have strong personalities among employees, but bug reports tend to be professionally and competently written, contain enough information to debug, and always, always leave out insults and personal attacks. The general public (at least many of the ones technical enough to file bug reports) does not seem to have the emotional regulation required to communicate professionally and respectfully.
> Frequently filed without logs, without reproduction steps, sometimes without even saying what the filer thinks is wrong.
In projects where this is a problem, I've made an issue template that clearly requests all the stuff I think I'll need. There's a big note at the top of the template that says it's not optional and that if it isn't filled out fully, I'll close the issue without comment.
And then I do that, every time. Sometimes they fill it out and reopen, sometimes they don't. Either way, I don't end up wasting time trying to help people who don't respect my time.
Or the more darwinistic view: anything you pay access for, you can get gated off from.
Its quite difficult to ban someone from a public park, especially when they can just put on a new hat.
Its really easy to ban someone from a private park. Even if they do put on a new hat, when they get belligerent again you just revoke the renewal of their access pass.
I tell my friends all the time: You want your product to be accessible? Sell cheap, but not too cheap.
Fair deals attract people with some money, but the almost-free only attract people who are forever broke, who live their life feeling entitled to everything being handed over to them.
> were on average much nicer than those who got their stuff for free!
this is always true with, at least a great many, people. it's related to choosey-beggar syndrome. it's a bug/glitch/feature in human psychology.
if you ever have the chance to be a property manager, never ever let someone move in a week early or pay a week later for free. never let your rent get drastically below market. when people aren't paying for something, it's incredibly common behavior to stop respecting it. it's like a switch flips and suddenly they are doing you the favor.
that's why in times past, offering or taking "charity" was considered impolite. but making a small excuse might be ok. say someone needs to stay an extra week after their lease was over, but was strapped for cash. instead of saying "sure you can stay one more week", say "well, you'd really be doing me a small favor staying in the place to watch for the extra week since it's empty anyway. how about i discount the rent by 50% for that week and amend the lease to take care of it."
I agree that this is needed. It doesn't stop the person requesting the feature from asking for a meeting to explain why and just whining that they need it the whole time and saying they shouldn't have pay anything to get it addressed right now.
Having in the person taking these meetings for a software vendor, it can get really toxic quickly and I never had more than 1 meeting a quarter with really toxic people and they were at least paying for the product and maintenance so hearing them out was part of the job. It unfortunate to get to the point where you view customer requests as antagonistic, but I can see how it happens. Some people really feel entitled, and some have a job to do and limited resources or control to do it in.
Yep. I've been working on Ardour for 25 years now, and it took me 7-10 years to develop the right kind of skin for dealing with "user feedback". For me, the right kind of skin was basically to shed such stuff like water off a duck's back. Whether someone is saying "I've been using Logic for 10 years and this is so much easier and intuitive" or "You should be ashamed for asking anyone to pay for this steaming pile of shit" (both real quotes), I had to be able to shrug and carry on with whatever my development priorities were anyway.
That said, I sympathize very much with Marcan on this project: getting the basic infrastructure for Linux operational on new hardware inflames passions much more than a niche project like a DAW.
Thank you for Ardour btw, great piece of software although I still use Ableton from time to time, Ardour is taking over more and more parts for me :)
I've read your comments here (and elsewhere) for a long time, and I'm sure you'd have some great ideas or at least opinions about this, which is pretty relevant to what you just wrote: https://news.ycombinator.com/item?id=43037537
I think my experience actually making a living from a FLOSS project changes things enough that it is not that relevant to people doing it "for the love it" or as a side-project.
It's much easier to shrug off strong comments when the people who do support you are making it possible for you (and one other) to lead a pretty comfortable middle class life.
God how I hate these arguments. You have this especially with Gimp. "But my beloved multibillion company worth product can do X sooo much better and easier. Also it has 16bit bla bla bla." You don't say?!?!?!?
Any tips how to get a thicker skin, or it grows on you over the years ?
Also, thanks for Ardour. I am a hobby cellist and record sometimes myself using Ardour and to cut down samples for an app I am working on. I tried doing that with my iPhone which worked like crap. Yup!
I always tell this story about working with sales at a job where I worked in tech support. Sales would call me up and ask why I hadn't talked to their client about their very important ticket.
I would tell them:
"I have 5 P1 tickets, 8 P2 tickets, and dozens of P3 tickets. Your ticket is a P3 ticket."
They would ask that I change it to a P1. I would. Then they would call me an hour later asking me about the ticket and I would tell them:
That's when they understand that they have to start fighting their peers and talking with the big boss to get their P1 ticket moved in front of the other P1 tickets.
Yup, but it gets them out of my hair, and they understand the support guy isn't in a position to wave a magic wand for them. If sales guy wins his fight with the folks in charge and I get time / resources to work on his thing, fine with me.
So? If they succeed (big if), then that ticket is your new priority. Maybe even for good reason, maybe not. But usually you don’t care that much which one you work on first, do you?
At Symbian defects were classified from P1-P4, with the inevitable shit-fights about adding magic runes to the title so everyone knows that your P1 is more important than theirs.
The day came when, after prolonged hand wringing and with stern observations about great power and great responsibility, the priority could be set to P0. But like any bunch of junkies we came off this new high all too quickly and the P-1 classification arrived, the showstopper of showstoppers.
In hindsight what I most regret is that we stuck with an integer field; we were denied the expressive power of fractionally critical issues.
Good for them for at least understanding at that point. The typical response is to say "I get that, I really do—can you move this one to the front of the line for me?" and then maybe a vague threat like "I can talk to your manager if it would help".
In my experience, when it's other people deciding the priority of your tasks (usually your boss), the distribution is 150 P1 tickets, 3 P2 tickets and 1 P3.
This is when the underrated skill of saying NO pays off massive dividends. One long-term client once told me the thing he appreciated the most, compared to most other consultants, was that I wasn't afraid of pushing back on his requests and saying no (within reason). Probably the most valuable feedback I have ever received.
When I worked support, they didn't even have a priority system (it was C2B, so there weren't necessarily enterprise customers. That did come later, with LiveChat and all it's joys). Instead, we had a 24hr expected turnaround and harder tickets would naturally filter to the top. Tickets that had reached near that point had a higher weight, which went towards your metrics/"leaderboard status". To dissuade gaming of the system, ongoing replies were assigned to an agent (you wouldn't give a half-assed reply and then hope for someone else to clean it up) and were exempted from the bonuses (so were one standard ["fresh"] ticket each).
Obviously, there was some oversight from managers, but overall it worked pretty well.
Open source is about liberating computing not about liberating users.
If you're supporting end users you need to be collecting money from them.
The mechanics of this system are entirely upside down. The corporations have bought into open source to regain control of computing and passionate developers are mired in the swamp of dumb user requests.
I had a similar thought. The tone of the messages was a little rough and they definitely could have used some better tact knowing that the project developers would see it, but ultimately those are just factual statements delivered with brutal bluntness.
Right exactly. They're not tactful, but they also weren't in bad faith. Marcan should have taken 5 minutes to realize that he's the boss, he's the one doing the work, nobody is entitled to anything in free software and that if people want a feature sooner they can either fund the project or kick rocks. Anyone who's been in open source for over 2, definitely 3 understands this.
> I miss having free time where I can relax and not worry about the features we haven’t shipped yet. I miss making music. I miss attending jam sessions. I miss going out for dinner with my friends and family and not having to worry about how much we haven’t upstreamed. I miss being able to sit down and play a game or watch a movie without feeling guilty.
This is the big problem really. He should have just turned down his work hours to a regular 40 a week, asked for more donations to pay more people and asked for more volunteer help. And honestly, probably therapy.
This is the same person that resigned as a kernel maintainer (focus on Apple/Arm unsurprisingly) about a week ago.
I don't know this person so this is completely baseless speculation but I assume they are "going through it" in some way and experiencing significant burnout, which based on my own experience in the past has a way of (negatively) amplifying all sorts of interactions that are related to the source of your burnout.
Basically, making linux work on Apple hardware is a pretty hard task, including a shitload of reverse engineering.
When a user decides to try it, and finds a lot of features missing, they are completely unaware of the work required to get it into that state, and just think they should have the readily available features.
Open source attracts some of the very worst users. Often people pretending to be trying to help by "suggesting improvements", but just as often entitled people who want to work for free. I don't think policies will change that. It's just something you have to accept when you provide something useful to lots of people for free. Even if you use moderated environments for user feedback (adding the burden of constantly banning people), people will find your email address and complain to you directly. See also: jwz/xscreensaver/Debian drama. Seeing how people treat open source developers makes me hesitant to upload any code I write to a public repository.
I'd expect the worst part for an Asahi project contributor to be the active sabotage some angry Linux kernel devs are trying to pull because they don't like Rust. Users being unreasonable is one thing, but your fellow maintainers are supposed to be allies at least.
I hope Marcan can find a new project to take on that doesn't involve all of this mess.
That's what I get with my software projects. People tell me that it sucks and I suck at code and other projects have it better, and don't forget to waste months of your time rewriting to Rust, and don't you dare to use unsafe all over your code (see: actix drama)... sigh. But when asked to show their alternative they get silent. So as long as you keep being assertive this is fine. For everyone who comes and behaves like a drama queen you have to prove again and again that talk is cheap and code is how you get the job done. Or you simply ignore them.
> I hope Marcan can find a new project to take on that doesn't involve all of this mess.
The only way to do that is to never collaborate with anyone else. I hope he'll be someday able to process what happened, why and reach appropriate conclusions. Software development is a social activity, especially with relatively high-visibility projects like Asahi, and it comes with just as usual burden of social troubles as any other kind of social activity.
> Software development is a social activity, especially with relatively high-visibility projects like Asahi, and it comes with just as usual burden of social troubles as any other kind of social activity.
Yes.
> The only way to do that is to never collaborate with anyone else.
Not necessarily. You can also treat project politics and social skills like any other technical skills that you need on your team like network engineering or database optimization.
If you can find trusted collaborators with those social and political skills, you can make a lot of things happen without necessarily being very good at it yourself.
Team building has a lot of parallels with building a full stack technology. Or building a sports team.
It's true, but what I was responding to was "a project to take on that doesn't involve all of this mess".
The real answer is to either learn these skills or, as you suggest, delegate them. Hoping to find something that doesn't involve "all this mess" at all will be fruitless.
> Open source attracts some of the very worst users
I don't think it's even just that, it seems to be something about the price.
I work on a piece of closed-source free software, and we consistently get support requests from unbelievably entitled assholes. The worst of them are the ones that have some technical knowledge; they will not only demand things be fixed or implemented, they make completely erroneous statements about how easy it would be to fix/implement with the conviction that they are 100% correct, with a level of arrogance that is impossible to fathom how they could have written their email with a straight face.
The support requests we receive for a paid offering from the same company are 99% of time much more pleasant people (of course there are the, "I PAID FOR THIS YOU MUST FIX IT!!!1!" on occasions, but they're a definite minority).
I think I've said this before, but 'free' seems to attract the worst of humanity.
When I want to give something away, I list it for some nominal fee like $10, then just tell them to keep it. Because when I used to list things for free, I got the dredges of society bothering me. Asking for delivery, asking me to hold it for 3 months til they can find a truck, cussing at me for saying no to both of these, cussing me because I sold it to someone else already, telling me long sob stories to guilt me. I've never had any of that happen when asking for money(except one guy wanted me to deliver it for $20, which was a fair-ish offer).
I wonder if that same 'pay but you'll get it back under the table' model could work for software? At least until the word got out, I guess.
Depends on the project. I have found Pinephone users quite nice overall as a kernel developer.
Anyway, if your project involves convincing hundreds of maintainers to increase their cognitive/work load in order to include your fancy new foreign workflow breaking language into their project, you have to expect pushback.
In the early aughts, I spent a lot of time writing and maintaining Open Source software. I burned out on that because of rude users. I had one guy track me down offline and phone me at all hours to demand that I drop everything and fix a bug for him. When I pointed out that my day job came first because I have to pay bills, he went on an online screed accusing me of holding him hostage unless he paid for fixes and listing my cell number so people could "encourage me to be a better developer."
In those days, I was part of a core development team for a project with a fairly large community. A few bad users and a few bad development team members is all it takes to poison something like that.
Now I barely even contribute to Open Source projects even when I fix them for my own uses.
> Open source attracts some of the very worst users.
This has not been my experience. Perhaps consider that the problem is not the users.
> the active sabotage some angry Linux kernel devs are trying to pull because they don't like Rust
On the other hand, users that demand you rewrite the project in their favorite language or otherwise accomodate their preferences over your own are pretty annoying.
> On the other hand, users that demand you rewrite the project in their favorite language or otherwise accomodate their preferences over your own are pretty annoying.
I work for a company that is open source and has a large community. I blows my mind (and often aggravates me) how rude some people can be.
For some reason people feel that it is appropriate to throw barbs in their issue reports. Please to everyone out there, if you find an issue and want to report it (hurray open source!) please be kind with your words. There are real people on the other side of the issue.
Always remember, you catch more flies with honey than vinegar.
> I blows my mind (and often aggravates me) how rude some people can be.
That seems to be a general characteristic. I strive to be cheerful and helpful whenever I'm asking for something. I feel like (sadly) it sets me apart from the crowd and helps me to get what I'm asking for. And IAC, with so little effort on my part I may brighten someone else' day and that makes me happy.
Just last week I asked housekeeping at a hotel for an old style coffee pot since I had brought my own coffee and filters. I started with "Can I pester you a moment?" and the conversation went up from there. Housekeeping was extremely friendly and helpful. Later I guessed this might have been her way to disarm some of the typical hostile interchanges she's been the brunt of.
I always feel like I'm imposing, and I have to remind myself that there are people who are eager to hear what I have to say. I try to set up my issue reports with appropriate background, and I always volunteer to, for example, submit a PR for a documentation change if the resolution requires it. And I have had some of the most wonderful interactions with complete strangers who had an idea, built a tool for themselves, and found other people had the same need.
There's a broader topic of ... just be nice to people. It doesn't cost anything. It does reassure me that this universe has been struggling with this for decades upon decades--witness the Malvin and Jim scene in WarGames. "Remember when you told me to tell you when you were acting rudely and insensitively?"
I think I kind of get it. By the time someone actually gets to the point of filing an issue report, they are at the end of their rope. They have tried everything they can think of. They have googled and found no one else having the same problem, or fixes that don't work, or people saying "why would anyone need that feature". They feel like they're being gaslit, their time is being wasted, and that the developers are intentionally antagonizing them. And then the form to submit the issue has way too many fields and comes across as very adversarial.
That's certainly how I felt when trying to get my drawing tablet to work properly under Linux Mint, although in my case I skipped filing an issue and just gave up and went back to Windows.
First of all, I wholeheartedly applaud Marcan for carrying the project this far. They, both as individuals and as a team proper, did great things. What I can say is a rest is well deserved at this point, because he really poured his soul into this and worn himself down.
On the other hand, I'll need to say something, however not in bad faith. He needs to stop fighting with the winds he can't control. Users gonna be users, and people gonna be people. Everyone won't be happy, never ever. Even you integrate from applications to silicon level, not everyone is happy what Apple has accomplished technically. Even though Linux is making the world go on, we have seen friction now and then (tipping my hat to another thing he just went through), so he need to improve his soft skills.
Make no mistake, I'm not making this comment from high above. I was extremely bad at it, and I was bullied online and offline for a decade, and it didn't help to be on the right side of the argument, either. So, I understand how it feels and how he's heartbroken and fuming right now, and rightly so. However, humans are not an exact science, and learning to work together with people with strong technical chops is a literal superpower.
I wish Hector a speedy recovery, a good rest and a bright future. I want to finish with the opening page of Joel Spolsky's "Joel on Software":
It's not just that "people are hard" - it was clear that this will end up this way the moment marcan started ranting on social media about having to send kernel patches via e-mails. Collaborating on software development is a social activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code. Not realizing that is a sure road to burnout (and yes, I'm just as guilty of that myself).
> 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 activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code.
Writing the code is at most 5% of software development IME. This is what I always say to people I work with. I absolutely love writing code, but there are so many and more important activities around that, I can't just ignore them and churn out code.
> Writing the code is at most 5% of software development IME.
This really depends on what you work on. And how good the managers are on your team. I talked to a manager at Google once about how he saw his job. He said he saw his entire job as getting all of that stuff out of the way of his team. His job was to handle the BS so his team could spend their time getting work done.
This has been my experience in small projects and in very well run projects. And in immature projects - where bugs are cheap and there’s no code review. In places like that, I’m programming more like 60% of the time. I love that.
But Linux will never be like that ever again. Each line of committed code matters too much, to too many people. Is has to be hard to commit bad code to Linux. And that means you’ve gotta do a lot of talking to justify your code.
I did some work at the IETF a few years ago. It’s just the same there - specs that seem right on day 1 take years to become standards. Look at http2. But then, when that work is done, we have a standard.
As the old saying goes, if you want to go fast, go alone. If you want to go far, go together. Personally I like going fast. But I respect the hell out of people who work on projects like Linux and chrome. They let us go far.
Even in the Google example, it's still in the low percentages when you view it as a system. All the manager did was efficiently allocate resources. It didn't reduce the non-programming work - it simply moved it elsewhere.
Someone who is in a management position, has good political skills and good connections will be way more efficient at doing some of this non-programming work.
This is something that even C-levels forget. Something that takes a CTO 2 minutes to do can take several months for a regular developer to achieve, and I have plenty of experience on and plenty of examples of that.
Yeah. I think the whole drama around rust on Linux is a great example of this. If Linus came forward and clearly supported (or clearly rejected) rust on Linux, it would have saved a lot of people months of stress and heartache.
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.
You are implying that if you can communicate but have nothing backing it up that's worth 95%? If anything code can still be taken as is and understood by someone else. So to me it's always most important to be able to produce anything before being able to communicate.
It's more like writing the code is just the first step on a long road. You won't go anywhere at all if you don't take it, but if that's the only thing you do, all you did is the first step.
I have written plenty of code that's stuck on this first step in my life, including some that went to the very same LKML we're talking about here right now. Some of those things have already been independently written again by other people who actually managed to go further than that.
Think about it the other way around: How much code is written and never used? How much code is written and would be better if it were never used? How much code is used only to then notice, that it doesn't solve the business problem that it was intended to solve? How much code is run and it's never noticed that it doesn't solve any business problem?
All the while: You are correct, being able to produce anything that solves a problem is much more valuable than being able to talk about it. But in order to unlock the value (beyond solving your own problem) absolutely requires communication
Once your proof of concept gains traction more time is spent in meetings with other teams responsible for the systems you'll be interacting with - making sure you do it "right" rather than scrappy. Once your initial release starts getting popular you spend more time looking at metrics and talking to operations folks to make scaling easier and not waste resources. Once your product starts having customers who depend on it, you spend a lot of time working with product to figure out features that make sense, advise on time estimates, mentor new team members, and advise teams who use your product/services as a dependency.
These are all engineering tasks, and the longer you spend on a team/in a company, the more likely it is you provide more value by doing this than by slinging code. You become a repository of institutional knowledge to dispense.
In a sense, yes. I'm contributing to a small but crucial part of a big project, as a coordinator of a four person team. The dynamics of the project form the team as "band of equals", in other words, everybody has approximately the same capabilities, and roles are divided organically, and I ended up as the "project manager" for that group somehow.
Even before we started coding, there was an RFC written by us. We have talked about it, discussed it, ironed it out with the chief architects of the project. When everything made sense we started implementing it. Total coding hours is irrelevant, but it's small when compared all the planning and it's almost finished now.
The code needs to tap and fit into a specific place in the pipeline. Finding and communicating this place was crucial. The code is not. Because you can write the most sophisticated code in the most elegant way, but if you don't design and implement it to fit to the correct place, that code is toast, and the effort is a waste.
So yes, code might be the most enjoyable (and sometimes voluminous) part, but it's 5% of the job, by weight, at most.
Perhaps "useless" was the wrong word the GP used. "valued" may be better.
It's fairly common for very useful/valuable code to be discarded because the engineer (or his management) failed to articulate that value to senior leaders as well as someone else who had inferior code.
It really depends what kind of code and for which usage.
People might also live their hobby dev experience better if they were really coding for themselves without any expectation except pushing the code to a repo. As a hobby dev, you don't have to make package, you don't have to have an issue tracker, you don't have to accept external contributions, you don't have to support your users if you aren't willing to have this on your shoulder. You don't even need a public git repo, you could just put a release tarball when release is ready on your personal website.
This works perfectly fine as long as you're happy with being approximately the only user of your code. With some of my projects I do just that, but it gets very different once you add users to the mix.
> it was clear that this will end up this way the moment marcan started ranting on social media about having to send kernel patches via e-mails. Collaborating on software development is a social activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code.
Yeah but FFS using email for patches when there are so much better ways of doing development with git? The Linux Foundation could selfhost a fucking GitLab instance and even in the event of GitLab going down the route of enshittification or closed-source they could reasonably take over the maintenance of a fork.
I get that the Linux folks want to stay on email to gatekeep themselves from, let's be clear, utter morons who spam on any Github PR/issue they can find. But at the same time it makes finding new people to replace those who will literally die out in the next decade or two so much harder.
I personally don't think GitHub's PR model is superior to e-mail based patch management for two reasons. First, e-mail needs no additional middleware at git level to process (I can get my mails and directly start working on my machine), plus e-mail is at least one of Git's native patch management mechanisms.
This is not about spam, server management or GitLab/Gitea/whatever issue. This is catering to most diverse work methods, and removing bottlenecks and failure points from the pipeline. GitLab is down, everybody is blocked. Your mail provider is failing? It'll be up in 5 minutes tops, or your disk is full probably, go handle it yourself.
So Occam's razor outlaws all the complex explanations for mail based patch management. The answer is concise in my head:
> Mailing list is a great archive, it's infinitely simpler and way more robust than a single server, and keeps things neatly decentralized, and as designed.
This is a wind we can't control, I for one, am not looking and kernel devs and say "What a bunch of laggard luddites. They still use e-mail for patch management". On the contrary, I applaud them for making this run for this many years, this smoothly. Also, is it something different what I'm used to? Great! I'll learn something new. It's always good to learn something new.
Because, at the end of the day, all complex systems evolve from much simpler ones, over time. The opposite is impossible.
> Your mail provider is failing? It'll be up in 5 minutes tops, or your disk is full probably, go handle it yourself.
Well until you deal with email deliverability issues, which are staggeringly widespread and random. Email were great to send quick patches between friends like you'd exchange a USB key for a group project. For a project the size of Linux? It doesn't scale at all. There is a reason why Google, Meta, Red Hat, and [insert any tech company here] doesn't collaborate by sending patches via email.
the problem with mail-based patch management is that it doesn't scale well, management wise... when you have hundreds of patches and multiple reviewers who can review them, Github/Gitlab environments make it easier to prioritize the patches, assign who will do the review, filter the patches based on tags, and keep track of what wasn't reviewed yet...,
mail-based patch management is fine for smaller projects, but Linux kernel is too big by now.. it sure is amazing how they seem to make it work despite their scale, but it's kinda obvious by now, that some patches can go unnoticed, unprioritized, unassigned, ...
and open source is all about getting as many developers as possible to contribute to the development. if I contribute something and wait months to get it reviewed, it will deter me from contributing anything more, and I don't care what's the reason behind it. the same goes for if I contribute something and receive an argument between two or more reviewers whether it's the right direction or not and there's no argumentative answer from a supervisor of the project and this situation goes on for months...
Email is just the protocol. What you're really saying is that http-based protocols make more powerful tools possible.
It's not really enough to state your case. You have to do the work.
On the surface, the kernel developers are productive enough. Feel free to do shadow work for a maintainer and keep your patch stack in Gitlab. It it can be shown the be more effective, lots of maintainers are going to be interested. It's not like they all work the same way!
They just have a least common denominator which is store-and-forward patch transport in standard git email format.
Everyone still has at least the base branch they're working on and their working branch on their machine, that's the beauty of working with Git. Even if someone decides to pull a ragequit and perma-wipe the server, when all the developers push their branches, the work is restored. And issues can be backed up.
> Also, is it something different what I'm used to? Great! I'll learn something new.
The thing is, it's harder and more difficult in a time that better solutions exist. Routinely, kernel developers complain about being overworked and onboarding of new developers to be lacking... one part of the cause certainly is that the Linux kernel is a massive piece of technology, and another one that the social conventions of the Linux kernel are very difficult, but the tooling is also very important - Ballmer had a point with "developers developers developers".
People work with highly modern tools in their day jobs, and then they see the state of Linux kernel tooling, and they say "WTF I'm not putting up with that if I'm not getting paid for it".
Or to use a better comparison... everyone is driving on the highway in the same speed, but one car decides to slow down, so everyone else overtakes it. The perpetual difficulties of many open source projects to accomodate changing times and trends - partially because a lot of small FOSS is written by people for their individual usage! - are IMHO one of the reasons why there is so much chaos in the FOSS world and many private users rather go for the commercial option.
The people in charge decided on their preferred ways of communication. You may believe that there are better ways out there, and I may even agree with you, but ultimately it's completely irrelevant. People responsible decided that this is what works for them and, to be honest, they don't even owe you an explanation. You're being asked to collaborate in this specific way and if you're unable to do it, it's on you. If you want to change it, work your way to become a person who decides on this stuff in the project, or convince the people already responsible. Notice how neither of those are technical tasks and that they don't depend on technical superiority of your proposed methods either.
You are missing the entire point. When you interact with a group of people who already have a culture and a set of practices/traditions, you have to play by their rules, build up credibility with that community... and then maybe, down the road, you can nudge them a little to make changes. But you have to have credibility first, have established that you understand what they do and understand why their preferences are the way they are.
If you approach it from the viewpoint that you have the solution and they are Luddites, you will influence no one and have no effect.
> Yeah but FFS using email for patches when there are so much better ways of doing development with git?
You are missing one point, namely that email is probably the only communication medium that's truly decentralized. I mean, on most email providers you can export your mailboxes and go to someone else. You can have a variety of email clients and ways to back up your mailboxes. No git clone, no specific mailbox or server is in any way special, I think Linus emphasized recently that they made efforts to ensure kernel.org itself is not special in any way.
Yes, I find Github's or Gitlab's UI, even with all enshittification by Microsoft and whatnot, better for doing code reviews than sight-reading patches in emails. And yet I cannot unsee a potential danger that choosing a service — any service! — to host kernel development would make it The Service, and make any migration way harder to do than what you have with email. Knowing life, I'd say pretty confidently that an outcome would be that there would be both mailing lists and The Service, both mandatory, with both sides grumbling about undue burdens.
Have you ever been in a project which had to migrate from, say, Atlassian's stack to Github, or from Github to Gitlab, or vice versa? Heck, from SourceForge + CVS/SVN to Github or similar? Those were usually grand endeavors for projects of medium size and up. Migrate all users, all issues, all PRs, all labels, test it all, and you still have to write code while it all is happening. Lots of back-and-forth about preserving some information which resists migration and deciding whether to just let it burn or spend time massaging it into a way the new system will accept it. Burnout pretty much guaranteed, even if everyone is cooperating and there is necessity.
But you could probably build tools on top of email to make your work more pleasant. The whippersnappers who like newer ways might like to run them.
It's an interesting phenomenon where people keep coming out of the woodwork and criticize the most successful software development project inhistory for doing it wrong.
They're not micro kernel! They're not TDD! They're not C++! They're not CVS! Not SVN! Not SCRUM! Not Gitlab!
Yet the project marches on, with a nebulous vision of doing a really useful kernel for everyone. Had they latched on any of the armchain expert criticism of how they're doing it wrong all these years we wouldn't be here.
> Yet the project marches on, with a nebulous vision of doing a really useful kernel for everyone.
The question is - how long will it march on? The lack of new developers for Linux has been a consistent topic for years now. Linus himself isn't getting younger, and the same goes for Greg KH, Ted Ts'o and other influential leads.
When the status quo scares off too many potential newcomers, eventually the project will either wither or too inexperienced people drive the project against a wall.
For the last few years, I've been saying the following regularly (to friends, family and coworkers): communication is the hardest thing humans will ever do. Period.
Going to the moon, launching rockets, building that amazing app... the hardest thing of all is communicating with other people to get it done.
As a founder (for 40+ years and counting) I manage a lot of different type of people and communication failures are the largest common thread.
Humans have a very, very tough time assuming the point of view of another. That is the root of terrible communication, but assumptions are right up there as a big second.
On the Marcan thing... I just want to say, control what you can and forget the rest (yes, this is direct from stoicism). Users boldly asking for features and not being grateful? Just ignore them. Getting your ego wrapped up in these requests (because that's what it is, even if he doesn't want to admit it), is folly.
I contributed to Marcan for more than a year. I was sad to see the way it ended. I wish him well.
> Humans have a very, very tough time assuming the point of view of another. That is the root of terrible communication, but assumptions are right up there as a big second.
That's very true. I recommend some people to read "The Four Agreements", because that thin book has real potential to improve people's lives through active and passive communication.
Also worth being aware of Robert Kagen's adult development model [0] or something similar; that gives people a framework to go from "humans seem" to some actual percentages and capabilities.
Spoiler, but approximately 66% of the adult population make do without being able to maintain their own perspective independently of what their social circle tells them it is. I imagine that would make it extremely challenging to determine what someone else's perspective is. Especially if that perspective is being formed based on empiricism rather than social signalling.
And if we're making book recommendations, Non-Violent Communication is a gem of an idea.
That's pretty fascinating, thanks for sharing it! It's a pretty compelling explanation as to why some people seem to be completely unable to logically explain their reasoning for certain beliefs and just fall back to "well it should be so because everybody says so."
Ta. I learned about it from my favourite HN comment (https://news.ycombinator.com/item?id=40856578) and have spent the last 6 months wondering why people don't bring it up more. It may just be a model but it has much explanatory power for why there seem to be so many "stupid" people around. I don't really have the word to describe them; people who are technically reasonable but not convinced by arguments or evidence.
If they've written "many many words over thousands of years" for the merits of their philosophy, they are also perfectly capable to write multi-paragraph goodbye letters. That's the bearing it has on the parents claim. And many did.
Why you felt the need to add your comment, is a more apt question.
> If they've written "many many words over thousands of years" for the merits of their philosophy, they are also perfectly capable to write multi-paragraph goodbye letters. That's the bearing it has on the parents claim. And many did.
Eh, not really - "multi-paragraph goodbye letters" here refers to the overly dramatic fad that internet denizens sometimes engage in when they leave communities, and they tend to have a lot of whining.
Those types of goodbye letters are not the types of goodbye letters stoics would write.
> Why you felt the need to add your comment, is a more apt question.
If you were able to pick up so swiftly what the person I replied to was implying, you too should be able to have picked up that I replied because I disagreed with that implication.
I doubt this, but would be curious to see a source.
> You could then just say that you disagree and state your case, without rudely asking why they posted it.
I didn't find it rude at all, and your reply was far less productive than my IMO neutral question. You took offense on behalf of someone else and inserted yourself when it was unnecessary and entirely reliant on your interpretation and perception. Now we're discussing your perceived slight instead of anything of substance.
Marcus Aurelius wrote extensive personal reflections in his "Meditations". Seneca wrote detailed letters to friends and family discussing philosophy, life, and death. Epictetus discussed death extensively in his Discourses, but sure, they were philosophical teachings rather than personal goodbyes.
They focus on acceptance and equanimity rather than formal farewells.
That said, "control what you can and forget the rest" is indeed stoicism, albeit simplified.
Marcan's career as a developer includes lots of development on hostile systems where he's jailbreaking various consoles to allow homebrew.
Asahi Linux is similar, given how hostile and undocumented Apple Silicon is, but it has a great amount of expectations of feature completeness and additional bureaucracy for code changes that really destroys the free-wheeling hacker spirit.
I understand. While I'm not as prolific as him, I've grown with systems which retrocomputing fans meticulously restore and use, so I had to do tons of free-wheeling peeking and poking.
What I found is being able have this "afterburner mode" alongside "advanced communications" capabilities gives the real edge in real life. So, this is why I wish he can build his soft skills.
These skills occupy different slots. You don't have to sacrifice one for the other.
Probably a few reasons. For Darwin, there are a few small projects but I think they are all functionally dead. The benefit with Linux, or even the BSDs here is, sure you gotta port to the hardware, but you should get a good set of user land stuff running for 'free' after that. Lots of programs just need to be compiled to target arm64 and they will at the very minimum function a little bit. Then you can have package maintainers help improve that. I don't think any of the open source Darwin based projects got far enough to build anything in user land. So you'd probably just get the Darwin code from Apple, figure out how to build it and then build everything else on top of it.
The BSDs. You can fork a BSD. Maybe he could try to mainline into the BSD, but would probably face a similar battle with the BSDs. Right, one again, the benefit mainlining into linux, and there is some (maybe limited) support to include Rust, is you can narrow your scope. You don't need to worry as much about some things because they will just sorta work, I am thinking like upper layers of the kernel. You have a CPU scheduler and some subsystems that, may not be as optimized for the hardware, but at least it is something and you can focus on other things before coming around to the CPU scheduler. You can fork a BSD, but most would probably consider it a hard fork. I also don't think any of the BSDs have developers who are that interested in brining in Rust. Some people have mentioned it, but as far as I know, nothing is in the works to mainline any kind of Rust support in the BSD kernels. So he would probably meet similar resistance if he tried to work with FreeBSD. OpenBSD isn't really open to Rust at all.
Why insist on developing in Rust? I mean, I see how it's much cooler and actually better than something like C, but people are hugely underestimating how difficult it is to change the established language of a 3 decade old project.
If Rust is the point you get up from the bed in the morning, why don't you focus on Redox and make it the new Linux? Redox today is much more than Linux was in 1991 so it's not like you would be starting from scratch.
You're probably not as good as Linus in, well, anything related to this field really. The only way to find out whether you actually are is to do the work. Note that also he spent a lot of time whining to people who were perceived as the powerful in the field. But in addition to whining he went and did the work and proved those people wrong.
Mind you, I'm a PHP developer by day, so this Rust-vs-C debate and memory management stuff is not something I've had experience with personally, but the "Rust is magical" section towards the bottom seems like a good summary of why the developer chose to use Rust.
Oh no, I totally agree. I am just saying from the perspective of the Asahi Linux project and wanting to use as much Rust as they can, that is what they are facing and the associated trade offs.
I personally fall a little more on the side of the Linux kernel C devs. Inter-oping languages and such does bring in a lot of complications. And the burden is on the Rust devs to prove it out over the long haul. And yes, that is an uphill battle, and it isn't the first time. Tons of organizations go through these pains. Being someone who works in a .NET shop, transitioning from .NET Framework to .NET core slowly is an uphill battle. And that's technically not even a language change!
But I do agree, Redox would probably less friction and a better route if you want to get into OS dev on an already existing project and be able to go "balls to the walls" with Rust. But you also run into, Redox just has a lot less of everything. That is just because it's a small project.
> Asahi Linux is similar, given how hostile and undocumented Apple Silicon is, […]
«Undocumented» – yes, but «hostile» is an emotionally charged term that elicits a strong negative reaction; more significantly, though, it constitutes a flagrant misrepresentation of the veritable truth as stipulated within the resignation letter itself:
When Apple released the M1, I realized that making it run Linux was my dream project. The technical challenges were the same as my console homebrew projects of the past (in fact, much bigger), but this time, the platform was already open - there was no need for a jailbreak, and no drama and entitled users who want to pirate software to worry about.
Which is consistent with marcan's multiple previous blog posts and comments on here. Porting Linux (as well as NetBSD, OpenBSD) onto Apple Silicon has been no different from porting Linux/*BSD onto SPARC, MIPS, HP-PA and other platforms.
Also, if you had a chance to reverse-engineer a closed source system, you would have known that «hostile» has a very specific meaning in such a context as it refers to a system that has been designed to resist the reverse-engineering attempts. No such resistance has been observed on the Apple Silion computing contraptions.
I also think calling it hostile is a little far. I recall Hector making comments of, "yea, even though is not greatly documented, it does things quiet a few things the way I would expect" and I believe even applauded Apple on a few thing. I wanna recall it was specifically around the booting.
> No such resistance has been observed on the Apple Silion computing contraptions.
I think they even left a "direct boot from image" (or something similar) mode as a small door to allow Asahi Linux development, if not to accelerate a little bit without affecting their own roadmap. Even Hector tweeted about it himself!
> He needs to stop fighting with the winds he can't control. Users gonna be users, and people gonna be people. Everyone won't be happy, never ever.
Right - but it kinda sounds like he's facing headwinds in a lot of different directions.
Headwinds from Apple, who are indifferent to the project, stingy with documentation, and not inclined to reduce their own rate of change.
Headwinds from users, because of the stripped down experience.
Headwinds from the kernel team, who are in the unenviable situation of having to accept and maintain code they can't test for hardware they don't own; and who apparently have some sort of schism over rust support?
Be a heck of a lot easier if at least one of them was on your side.
Another uphill battle that I haven't seen anyone mention is just how good mobile AMD chips got a year or so after the M1 release. I wouldn't buy a Mac to run Linux on it when I can buy a Lenovo with equally soldered parts that'll work well with the OS I wanna run already.
And some of these Lenovos are relatively upgradable too. I'm using a ThinkPad I bought refurbished (with a 2 year warranty) and upgraded myself to 40 GB of RAM and 1TB of SSD (there's another slot too if I need it). It cost me $350 including the part upgrades.
Prices seem to have risen a bit since I bought mine. Here's a similar model with a Ryzen 5 7530U for $355: https://www.ebay.com/itm/156626070024 It is certified refurbished and has a two year warranty. It has a SODIMM slot and supports dual SSDs, although not the full size M.2.
A lot of it is simply AMD getting on newer TSMC nodes. Most of the Apple's efficiency head start is better process (they got exclusive access to 5nm at first).
That's my understanding as well, as soon as the node exclusivity dropped they were ballpark equal.
Many ARM SOC are designed to run on battery only so the wireless packages and low power states are better, my AMD couldn't go below 400mhz.
But yeah the "Apple M hardware is miles and leagues away" hypetrain was just a hypetrain. Impressive and genuinely great but not revolutionary, at best incremental.
I hope to be able to run ARM on an unlocked laptop soon. I run a Chromebook as extra laptop with a MediaTek 520 chip and it's got 2 days battery life, AMD isn't quite there yet.
> But yeah the "Apple M hardware is miles and leagues away" hypetrain was just a hypetrain. Impressive and genuinely great but not revolutionary, at best incremental.
It's more nuanced than that. Apple effectively pulled a "Sony A7-III" move. Released something one generation ahead before everybody else, and disrupted everyone.
Sony called "A7-III" entry level mirrorless, but it had much more features even when compared to the higher-end SLRs of the era, and effectively pulled every other camera on the market one level down.
I don't think even they thought they'd keep that gap forever. I personally didn't think it either, but when it was released, it was leaps and bounds ahead, and forced other manufacturers to do the same to stay relevant.
They pulled everyone upwards, and now they continue their move. If not this, they also showed that computers can be miniaturized much more. Intel N100 and RaspberryPi/OrangePi 5 provides so much performance for daily tasks, so unimaginable things at that size are considered normal now.
I like the Sony story, but I don't think Apple did "pull everyone along" like that, they had an exclusivity deal with TSMC to be first on a good manufacturing node improvement. They took their high-quality, high-performance iPhone SoC, gave it more juice and a bit better thermals.
It's just another "Apple integrating well" story.
Their SoC is huge compared to competitors because Apple doesn't have to make a profit selling a SoC, they profit selling a device + services so they can splurge on the SoC, splurging on the SoC plus being one node ahead is just "being good", the team implementing Rosetta are the real wizards doing "revolutionary cool shit" if anything
> they had an exclusivity deal with TSMC to be first on a good manufacturing node improvement.
...plus, they have a whole CPU/GPU design company as a department inside Apple.
Not dissimilar to Sony:
Sony Imaging (camera division) designed a new sensor with the new capabilities of Sony Semiconductor (fab), and used their exclusivity to launch a new camera built on top of that new sensor. Plus, we shall not forget that Sony is an audiovisual integration powerhouse. They one of the very few companies which can design their DSPs, accompanying algorithms, software on top of it, and integrate to a single product they manufacture themselves. They're on par with Apple's integration chops, if not better (Sony can also horizontally integrate from Venice II to Bravia or Mics to Hi-Fi systems, incl. everything in between).
The gap also didn't survive in Sony's case (and that's good). Nikon and Fuji uses Sony's sensor fabs to use their capabilities and co-design sensors with the fab side.
Canon had to launch R series, upscale their sensor manufacturing chops. Just because Sony "integrated well" when looked from your perspective.
Sony is also not selling you the sensor. It's selling you the integrated package. From sensor to color accuracy to connectivity to reliability and service. A7-III has an integrated WiFi and FTP client to transfer photos. A9 adds an Ethernet jack for faster transfers. Again, integration within and between ecosystems.
>But yeah the "Apple M hardware is miles and leagues away" hypetrain was just a hypetrain. Impressive and genuinely great but not revolutionary, at best incremental.
Compared to the incremental changes we've seen the previous 10 years before it arrived on AMD/Intel space, it was revolutionary.
We must have different definitions of the word "revolutionary". They put a high-end mobile chip in a laptop and it came out good, what's revolutionary? The UMA architecture has advantages but hardly revolutionary.
The jump in performance, efficiency, battery time was not incremental or "evolutionary". Such jumps we call evolutionary.
What they did doesn't matter. Even if they merely took an intel laptop chip and stuck a chewing gum on it, the result was evolutionary.
So much so, that it put a fire under Intel's ass, and mobilized the whole industry to compete. For years after it came out the goal was to copy it and beat it.
What did you expect to call "revolutionary"? Some novel architecture that uses ternary logic? Quantum chips?
Was Intel switching from the Pentium 4 to the Core architecture considered revolutionary at the time? Was AMD's bulldozer architecture? I don't recall.
> Headwinds from Apple, who are indifferent to the project, stingy with documentation, and not inclined to reduce their own rate of change.
That is part of the challenge he chose to take on.
> Headwinds from users, because of the stripped down experience.
Users can be ignored. How much you get users to you is your own choice.
> Headwinds from the kernel team, who are in the unenviable situation of having to accept and maintain code they can't test for hardware they don't own
You don't have to upstream. Again, it's not the kernel team that chose to add support for "hostile" hardware so don't try to make this their problem.
> and who apparently have some sort of schism over rust support?
Resistance when trying to push an entirely different language into an established project is entirely expected. The maintainers in question did not ask for people to add Rust to the kernel. They have no obligation to be welcoming to it.
> Be a heck of a lot easier if at least one of them was on your side.
Except for the users all the conflicts are the direct result from the choice of work. And the users are something you have to choose to listen to as well.
"Their boss" - I'm not sure that boss is best word here.
"did ask for it" - did he? Because from my perspective it looks more like he gave the bone for corporations so they will shut up for rust in kernel. After some time it will end up "Sorry but rust did not have enough support - maintainers left and there were issues with language - well back to C"
I don’t think that’s an accurate way to describe what happened, no. He seems to be enthusiastic about it and to genuinely want it to succeed.
> "A lot of people actually think we're somewhat too risk averse," said Torvalds. "So when it comes to Rust, it's been discussed for multiple years by now. It's getting to the point where real soon now, we will actually have it merged in the kernel. Maybe next release."…
> "Before the Rust people get all excited," the Linux kernel creator and chief said. "Right? You know who you are. To me, it's a trial run, right? We want to have [Rust's] memory safety. So there are real technical reasons why Rust is a good idea in the kernel…”
> “And hopefully, it works out, and people have been working on it a lot, so I really hope it works out…”
Last September he was still insisting he thinks the project will not fail, and he was not exactly subtle in his criticism of maintainers who refuse to engage with it in good faith.
> "Clearly, there are people who just don't like the notion of Rust, and having Rust encroach on their area.
> "People have even been talking about the Rust integration being a failure … We've been doing this for a couple of years now so it's way too early to even say that, but I also think that even if it were to become a failure – and I don't think it will – that's how you learn," he said.
> "So I see the whole Rust thing as positive, even if the arguments are not necessarily always [so]."…
> With impressive diplomacy, considering his outbursts of years past, Torvalds went on, "There's a lot of people who are used to the C model, and they don't necessarily like the differences... and that's ok.
But yeah, I still don't think it's all that inaccurate: He may not have wanted it to fail, and still not think it's a technical failure... But socially? Still seems possible he'd be starting to think that while the Rust language per se is a technical success, all the drama surrounding the integration of it into Linux means that that is turning out to be a social failure.
(Or maybe I'm just projecting because that is what it looks like to me.)
Yeah, I want to give them accolades for the great work they did.
I just wanted to also add that users will be users. Once its out, there will be endless posts about "why X" and "why not Y". No matter what you do, lots of people are going to be displeased. Its just the way things go. I hope he will want to pick it up again after some time.
You gotta have super thick skin to be a maintainer of an opensource project or even be popular on the net these days. Folks are going to come for you for whatever reason, if you read too much into it you're going to have a bad time.
Never ever give away anything for free if you intend to support it is an evergreen advice.
Selling ads? Using it as a gateway to a commercial product? Selling support? Have some genius business plan that allows you to make money in the future? Fine, give it away no strings attached but expecting that users will be grateful is a mistake developers keep repeating. The free users are just as entitled, even more entitled as they don’t have a price tag for your efforts and don’t have a document specifying what are your obligations so they can assume scope of entitlements anyway they wish.
Since you gave it for free, you can’t refund an unhappy customers to make it go away. If it looks like a product, You will be stuck with people who think they did their part by using your products and you failed them. Some may make it a full time job to take a revenge on this injustice.
I’m not even sure that these users are at fault, you actually took something in exchange(like fame, street cred etc) and you are not delivering your part.
Paying users can be incredibly entitled, sometimes even more than people who don’t pay you a dime. The problem is the moment you accept a cent people expect you to do work for them, regardless of whether the money is actually “worth” how much effort needs to go into a feature. The open source projects I’ve worked on get donations but sometimes people will put up like $10 for their pet feature which takes a week to write. Like, thanks for your contribution, but this actually doesn’t affect my priorities at all.
I have been maintaining open source projects, and really: users of open source projects suck. They get your work for free, but it's not enough; they have to be assholes on top of that.
I would say it's more the case that the users who suck are both the loudest and also seem the loudest. If you get 10 people saying thank you and one person cussing you out, it might still ruin your day. And of course a lot of people just quietly use the thing and are happy with it, and you never hear from them at all.
I think entitlement like that is stupid and bad for open source (and everything). However, in the next paragraph the author gets into criticising the opposite position, that asahi linux was not ready for everyday use. The entitled requests came from users that thought of asahi linux as exactly covering an everyday use case, a linux distro they should be able to use to carry on their tasks. This I find contradictory. While some entitled users always exist, you can either admit that asahi is not a daily driver for people who want to use most of basic features of a laptop, or admit that the requests make sense. You cannot both claim that asahi is fine to be used, and complain that users ask for being able to connect an external monitor on a M1 macbook air. I am not sure what is wrong with the claim that asahi linux is an experimental (and no less amazing) project that people lacks certain (widely considered basic when things come to this) functionality, or that the functionality of it is restricted to these use cases that may include using it as a headless server but exclude some common other ones. I am not sure how this would matter, but setting user expectations to a level that matched the state of development may have helped to limit such requests.
I say that also because I have been gotten quite a few responses from people that I should use asahi, while looking at what it supports it definitely would not make sense for me, and you cannot just present it to a macos alternative right now.
Thing is it will never get to be a daily driver if people don't use it and shake out the bugs.
25 years ago (huh, long time), when Windows ME pissed me off for good, linux wasn't exactly known for being a daily driver but I gave it a try and, unsurprisingly, it did become reliable over the years. Other than Gnome's propensity to make stupid changes to default settings I can't remember the last time I had to even think about messing with the underlying system and other than a simple google search on the linux compatibility of hardware before I buy I just don't think about it. Actually, I take that back, when I first got my current laptop I was messing around to get the AMD mesa drivers (or whatever) working because I wanted to mess around with this fancy GPGPU thing.
Personally, if I were to buy a macbook it would be for the OS and not dodgy linux support because I've walked that road before. If the Christmas sales were just a tiny bit better though...
I am talking about lack of pretty standard features, not bugs. Having more users would not help there. And in general, you dont need a huge influx of users, and you definitely you dont get as much help from users who are not going to put at least some effort in the feedback they give. You want users that are conscious enough about what they are using to give useful feedback and/or support with donations. I am pretty sure that some people still are attracted to running an experimental version of linux.
Imo modern linux experience is much better than the situation you describe, at least as long as you use certain type of hardware. In the past it was definitely harder. But wrt asahi, I want the "luxury" of using an external monitor with my 13" macbook air, and sadly, while in the past x86 machines I put linux I would put some effort and get AMD mesa drivers to work, I cannot do that here. I respect the effort put in the asahi project, but calling it suitable for a daily driver is misleading, unless you specify exactly what sort of daily driver you mean. Stuff like using an external monitor is pretty basic in my book of daily usage.
This whole post feels like typical burnout. Imagine porting something as complex as Linux to a platform who's creators actively do not want Linux ported to it. Of course you will burn our eventually. Not to dismiss his experiences, but I wonder if there is some deflection going on here - burnout was happening anyway but blaming others is a good smoke-screen.
> This sounds so rough. I can't imagine pouring your heart out into this labor of love and continue to have to face something like this.
Or: he shouldn't steal people's time with false advertising :shrug:
Also if he wants to create an operating system, then these aren't even requests, but
bug reports. So the users ate his false advertising, spent time to try out his system, then spent some more time to file bug reports, and then he calls them "entitled users".
I can't imagine then what's his problem. I don't get offended by people that can't even read. I don't normally call them people let alone entitled :\ Set up a bot that links them the device support page, and problem solved? I don't get it
> It's comments like these that causes people to wear out.
No it isn't. You - fundamentally - don't get to control what people say to you. You need to filter how to take that. And that's incredibly hard. Especially in open source. You need to both be able to ignore (some version of "idiots, who can't be bothered to read") and be openminded enough to take weird requests, because they could be the starting point of a new major contributor. The second is optional, as long as you are happy just doing your thing, but then the former probably won't become a problem for you.
I'm know it's pretty pointless to argue because we see the world in a different way. But realize the (quoted) requirements are you putting on the open source developer.
I'd argue I'm not putting any requirement on the developer, I'd argue I'm making a statement of fact. Namely
> A developer without these skills will burn out.
And I think that's something that should be said more directly. If you want to do open source (as in become the provider of load bearing infrastructure): Then you really need to realise what you are getting yourself into. Would I like that to be different? Sure. Would I bet on that changing? Absolutely not.
And yes, that absolutely means you can either do open source as a hobby, then nobody should ever be willing to rely on the thing you are building (because you can just say "i've got better things to do than fixing the security bug you got") or you can attempt to get other people to use and rely on it, but then you have to find a way not to burn out.
Apple users today are just Windows users with even more entitlement.
Wasn’t always like this, I think. Personally have seen the same with other projects and dealing with proprietary Apple APIs and their walled in garden is hard enough.
It sounds like he really got invested too much into what people wrote.
> “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS”
These are not even requests. These are objective statements he can either take note of for prioritisation or ignore. I can also say Asahi is useless to me until usb-c monitors support, but that's just my situation - there's no bad faith or request here. Previously that was the same for WiFi support.
I wish there was some good model for maintainers of bigger projects to deal with this on a personal level. The bigger the project, the more people there will be with unmet requirements and that's just life. It literally can't be solved.
People complain about things that they care about. People also don't usually have as much tact as we would like them to.
I think the best way to deal with this is to just confidently say what you are and are not ready to get done. The social dynamic will always be this way, so we may as well take whatever criticism is useful, leave the rest behind, and move on.
>"I can’t even check my CPU temperature” (yes, I seriously got that one"
Actually if this distro is my primary / only one I would like to be able to check CPU, GPU, etc. temperature. It is important to know if cooling is adequate or requires cleaning / repair.
In any case Marcan would be way better off having thick skin. Users will always be assholes (well same is generally true about vendors).
why not tag it as pre-alpha, not suitable for daily use? Saying smoothest linux experience on one side and expecting people to not expect basic features of the hardware working...how does that work?
"Heavily under development and not ready for prime time use" should have been first line in readme and only reply to such feature request.
So it sounds like they bit more than they could chew.
from what I've seen of his grandstanding on the LKML suggesting to bully people on social media, I've lost all respect for the guy. He is a person in power considering all his social media clout, and this is how he uses it. I'm glad he realizes that it's time to sit back and reflect. And I don't mean that in a disrespectful way. He will be of much more use to the community, and more importantly himself after confronting his ego.
There are two types of VIP developers: those that stay in the shadows and do their work (think the Bram Moolenaars and Daniel Stenbergs) and those that seem to spend their entire time picking fights on social media and writing very emotionally charged blog posts that routinely reach the HN front page, because gossip and drama sells.
He likes C, hate c++, allowing rust in the kernel is trying something new, and maybe to attract new maintainers that don't care too much about C, and as he said "maybe it work, maybe don't, if don't we learn"
First of all, yay Asahi — one of the great modern hacking / hacker stories in my opinion.
Second, what’s the drama? I read the blog, and I’m guessing that on top of being burned out, which sucks, Marcan didn’t like a kernel developer using the phrase “we are the thin blue line” implies he’s politically liberal, in the US sense. He then says he may have been toxic on Mastodon, which might have got him secretly canceled?
All that said, I found his assessment of downstream v. upstream economics (if you can’t successfully upstream you’re doomed to rebase off a massive patch list) pretty interesting. I think the way it is now is the only way that’s good for users — if downstream forks could somehow maintain viability longer term, we would be splitting, e.g. security budgets, performance budgets, etc. I get that it sucks for a group working to upstream, and I am in no way shocked to hear personal politics plays some role in success upstreaming — open source is largely a personal / social capital economy - I guess all that said, hopefully the new Asahi maintainers can work well across what seems like ideology bounds. Maybe?
Thank you for pointing out the blue line comment, I didn’t grasp it and continued. If you are right I’m saddened to see this type of politics being played in the kernel development. Especially since the Russian maintainer incident.
My understanding from afar is that a Rust dev wanted to interact with C code in a way that the C maintainer didn't like. This led to the C dev saying that while he likes Rust, he believes multi-language codebases are cancer and would stonewall all Rust code that touches his code.
Marcan watched it unfold on the mailing list wanted Linus to step in and force the C dev to play nice. Since nothing happened, he went to social media and lashed out as a last resort. That's when Linus finally chimed in and pretty much said "you might be right, but this isn't the way to handle things".
> My understanding from afar is that a Rust dev wanted to interact with C code in a way that the C maintainer didn't like.
He didn't want any Rust code at all touching his turf. He outright NACKed without any technical reason and refused any negotiations with the Rust team that any Rust build fails due to C code breaking changes would be their entire responsibility.
> This led to the C dev saying that while he likes Rust, he believes multi-language codebases are cancer and would stonewall all Rust code that touches his code.
I believe that was an attempt of damage control to save face and he actually meant to call Rust "cancer".
Anywhere really, it's just the phrase 'there's a thin [or fine] line between...' modified to say the police are that line, between lawful order & disorder.
Apparently it's political in the US, I have no idea, but as I understand it the maintainer just means 'I am here reviewing the change to keep the kernel in good order'.
The maintainer might mean that, but words have meaning. That particular phrase is overly charged and carries a specific connotation surrounding the idea that police are the sole line keeping society in shape.
It’s a poor choice of words for such (relatively) public communication.
These words have the meaning you're implying to at least some people in the USA, it was new to me.
I don't know his full biography, seems to be Chinese born and went to MIT, but he signs off 'Cheers', I think it's a reasonable possibility that he doesn't mean whatever politically charged US meaning it has by it.
You're, with your US perspective, saying 'hey words have meaning you know, don't downplay murdering homosexuals' while millions^ of people smoke fags in the UK every day.
(^probably? Maybe not any more, a lot of fag-smoking relative to murder at any rate.)
Damn shame, both for the burnout and for the project. I was talking to the team which laptops next to get and kind of everyone wanted something like Arm with battery and performance and there are only MBPs (except damn notch) out there. Except no one wants MacOS. And then there's Asahi. I said it might come down to exactly this, what's happening now.
Buying MacBooks and doing your development work in a full screen Linux VM (with e.g. UTM) is a surprisingly good solution, that’s what I’ve done for the past year with no regrets.
My perspective is it might be a chicken-or-egg problem. I would willingly donate to the Asahi project...if/when I were to buy a Macbook for the purpose of running Asahi Linux on it.
And I've been watching from the sidelines, waiting for Asahi Linux to become "stable" enough to consider buying a Macbook and putting Asahi Linux on it.
I was an early donator to marcan and never expected any delivery from Asahi project, just thought that the idea of having Linux of Apple Silicon was awesome and worthy of my support.
But then marcan told his supportes to fuck off unless they commit to supporting his political ideas, which I was not willing to do.
I guess this comment will be seen as abuse from the HN crowd. Oh well...
There is really not much to elaborate: I was supporting the idea of Linux on Apple Silicon. I would support that idea even today (without even installing it really) but because of marcan's twitter/mastodon (I don't remember which) posts. Btw, those accounts are on longer active, I presume marcan deleted them (go to marcan's About page and see for yourself).
Now, if you want me to explain what political ideas those were: I don't care. Whatever they are, I don't want to support it, even if I have those same ideas. Yes, I do think that open source communities should move away from the politics.
He seems to take a lot of things that are fairly neutral or merely untactful as being bad faith. Like the "thin blue line" comment by Dr Greg. Sure the whole thing blue line thing in reference to the police misrepresents their role in society (police in most western countries are fairly useless at best and actively harmful at worse), but Occam's razor just suggests that Dr Greg was just making a tactless remark rather than being super pro po-po.
It sounds weird and somehow I don’t think it was communicated that way, even if I wasn’t there. You say he said I don’t want your money unless you follow my ideology? Did he then send you the money back after checking your social media?
Out of curiosity what are his political views? It has been mentioned a couple of times here already and it seems to be part of the story.
> But then marcan told his supportes to fuck off unless they commit to supporting his political ideas, which I was not willing to do.
Is this about Marcan’s outspoken support for transgender people? If so, why not simply say that in your comment, rather than framing it in such vague terms?
…So it is about the fact that you object to his support for transgender people?
Surely you see why this is, actually, directly relevant and important context for your statement. It’s not some general political leaning you’re talking about - lumping this (prejudice against a minority group) into the same category as something like banal disagreements over taxation policy amounts to deliberately obscuring what you’re saying behind innuendo.
If you’ve got something to say about his political views in a public forum like this, at least do the people around you the courtesy of being upfront about what you’re actually saying.
And here we go again, there is never a neutral position with some people.
I support the freedom of people chosing their sex or gender. At the same time, I'm not willing to fight their wars. And if they force me to go to war, then I pass.
Comments like this are why people find transactivists so irritating. Whether they happen to agree with them or not. No-one even mentioned transgender issues yet here you are bringing them up to start an argument. Not everything is about trans you know.
Given that this is seemingly the thing for which he’s most known, politically, it doesn’t seem remotely unreasonable to infer that the person I was replying to was talking about it. It’s absurd to take this evasiveness as anything other than bad faith.
If the group in question were gay people, or a racial minority, would you still treat the issue this way?
> primarily due to the very large fraction of entitled users
I think anyone working in serious open source projects just need to learn to ignore those users. I definitely would have the attitude of "I'm perfectly fine if no one uses my product" and have a lot of fun banning entitled users left and right.
To me, unless there is an exchange of money and a signed statement of work, I have absolutely zero entitlement as a user. And the maintainers are well within their rights (by law and social contract) to tell me to go away. I wish this was a more adopted mindset.
It’s why things like CentOS being abandoned, terraform licensing, et. al. never bothered me. I’m not paying them, so :shrug:.
Easier said than done. If you care about users, and then realize most of them are jerks, it’s deflating. Maybe the secret is to not care about users, but the risk is that you end up doing self-gratifying work that leads nowhere.
Yeah, I agree. Maybe that's why I'm not doing great work -- I simply don't care about users. But again, you don't have to care about all users. You only need to care about the ones that have the same mindset. That's why I think working in smaller communities is better. Asahi Linux and Rust in Linux are the worst projects in that perspective because they both try to touch too many users.
But again, maybe they can hire someone like me, whose sole job is to block the very worst entitled users.
Not exactly the same but being a mod made me realize the same, people will 100% treat you like a whole other being in a dehumanizing way, if you're just a passionate person about the topic you get whiplash at first.
I see a lot of FOSS maintainers continue to engage and defend themselves against people who have demonstrated themselves as unwilling to contribute in any way, yet expecting that free work be done for them. I wish more open source devs will keep in mind that FOSS work is a gift they're sending out into the world, and it's a common good that anyone can contribute to. That is not to say ignore all criticism or user requests, just that you hold absolutely no responsibility to placate emotionally draining people - the project is just as much their responsibility as yours.
Yeah, 100%. Large successful FOSS eventually needs someone like Linus who can just brush away arguments that can bog down the project. It's almost like a military operation -- armies need to move forward instead of bogging down. And in the case of Linux that's perhaps even more true, because the world literally runs on it.
I don't agree with Linus all the time (mostly because I don't have the technical knowledge to agree with), but I 100% agree to his attitude. I hope other large FOSS project maintainers have the same mindset.
Well written. I think the accusations of drama-hunting are unfounded. What else are you supposed to do in the face of persistent "non-technical nonsense"? Linus doesn't seem to care.
Definitely a shame. I wonder if it would be in Apple's interests to actively support Linux on Mac. It would make Macs more attractive as developer machines, and I don't see how it would disadvantage them.
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.
That's not really Apple's game anymore. They don't really care about selling Macs, what they want to sell you is their ecosystem. So that way you'll get a Mac and an iWatch and an iPhone and whatever else they push out once they get their hooks and lock you in.
Do the demigods of the Linux kernel - Linus and the core maintainers - personally want the kind of code Asahi is developing to be merged into the kernel? The author writes as if part of his drive was that Linus himself showed enthusiasm for getting Linux on Apple Silicon.
If there is interest in the work Asahi has done, then the Linux team needs to describe what they see as the gap between today's code quality and support model and what they want to see before upstreaming.
It sounds like the Linux team has been wishy-washy and needs to draw a line in the sand on their needs rather than handwaving about being part of the "community".
It would be fair to say "we don't like your attitude or trust you to work with us kindly over the years and don't want to deal with you", if that's the case. Just don't dance around it.
And it sounds like you read just one side of the story, with no background in Linux kernel internals. This is about how C APIs are typically inherently unsafe, Rust people wanting to build safe(r) abstractions on top, and a question of who is responsible for changing what code when it's time to refactor the underlying C API. And yes, marcan is being overly dramatic, though he is not alone in that.
I do not claim a background in Linux kernel internals. I'm a human who has seen teams miscommunicate in the past, and see it now. I'm not sure what I said that drew hostility.
It sounds like you agree with me though. The Linux team needs to clearly define the expectation they have for code maintenance from the team trying to upstream Rust code (edit) and the Asahi team needs to acknowledge how/if they can meet those expectations.
Well, stop accusing people who's work you don't know of being wishy-washy.
The challenge is not dictating from high above some criteria; the challenge is discovering the criteria that will let the Linux project continue development as well as can be arranged. This is why you'll hear Linus say it's a learning experience, and not just make proclamation of how things shall be (at this stage).
I don't think it's reasonable to read my original comment as an "accusation". I said "it sounds like" as part of a casual conversation about the subject. There was no hostility in my comment.
Would you say that the Asahi team wasn't receptive to the pace at which the needed criteria were being developed?
My point is that between these two groups there seems to be a misunderstanding of expectations. And being the upstream org, and not having read every mailing list thread, I would expect the kernel team to have built a framework for accepting this kind of code. Or a framework for building the framework.
The framework is "we will discuss it and a consensus may emerge". Linux is an open source project, not a company trying to remain profitable for the next quarter. If some outsider stumbles in and expects something else, well, they didn't understand what they were getting into.
Having structure to decision-making doesn't have anything to do with having a profit motive. Asahi nor myself as an outsider have brought up money.
It sounds like the implicit answer to "Does Linux want Asahi contributions" is "low priority". Which is fine if that's communicated.
I sense you have been involved in these discussions already and have a strong opinion about the specifics of this topic. I don't mean that in a bad way.
You continue to misunderstand open source. "Linux" in incapable of wanting things. Linus as the quality gatekeeper of the main repository cannot tell anyone what to do; his power is purely saying "I won't merge that". The project is what the project contributors do, and nobody can tell them as a group what to do. It's herding cats, not a business meeting.
I have very little personal interest in Asahi, I am not really part of that "conversation", but I dislike outsiders coming in and expecting to dictate how something that predates them should work. Everyone is entitled to their opinion, but that doesn't mean anyone else has to listen to it. If you want to understand, read linux-kernel the mailing list and watch people like Al Viro work (Minimum realistic time allotment: multiple months).
> The author writes as if part of his drive was that Linus himself showed enthusiasm for getting Linux on Apple Silicon.
Perhaps the author jumped to conclusions after Linus himself started using Asahi Linux on his own laptop for Linux kernel development[0]. Note the praise for the Asahi team in the commit message.
As a 20-year Mac enthusiast who knew a thing or two about Hackintoshing, Marcan got me excited about Linux. The idea that someone could just say, “we can solve this difficult problem and make it work, with little external help”? That is the core of FOSS right there, and he helped so much work happen, so quickly.
Loved following his various social feeds. I was sad when he stepped away from the fediverse. I hope he comes back as just a regular hacker without this massive weight on his back.
Thank you Macan! Asahi is a heroic effort, but way larger than a hobby. To be sustainable, it would require full buy-in from Linus and kernel maintainers indeed.
Hope you enjoy well deserved better hobbies and family time.
Unfortunately it is not the first time a good developer leaves the project for a famous "Linu(s)x shitshow", and it will not be the latest...
I don't believe in the Linux project since a few years now, especially as "the bearded ones" are not interested in moving the project to a certain future, but only jerking on their old own code.
Good luck for the futur Hector, and thanks for what you managed to do until now with your team.
> I don't believe in the Linux project since a few years now, especially as "the bearded ones" are not interested in moving the project to a certain future, but only jerking on their old own code.
I personally lost my confidence in it when they stopped properly triaging security issues and flooded everyone interested with just noise.
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 merits, only to come back a year later when whatever company they work for suddenly sees it as important.
Project leads who will shift goalposts to avoid confronting the clear hostility their deputies show.
I’ve had OSS users call me personal number, or harass me over email for not having their pet interest prioritized over everything else. Often that’s because I’m blocked by the maintainers.
Open source can be extremely brutal and it’s a battle of stamina and politics as much as it’s one of technical merit.
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.
There’s a significant difference between open source and proprietary software.
With proprietary software you usually have a corporate mandate, a goal etc to achieve. Any new tech is achieved as part of that drive. You can get people on board or not based on that, and once you’ve decided, there is someone to answer to if you can’t deliver.
Open source doesn’t have that. A project can go in twenty different directions at once, you can say you all agree to something and then have people sabotage it without being answerable to anyone.
Does that make open source worse? No. It’s the trade off for being open, which is extremely valuable but it is a very different push in terms of a product.
For me it wasn't about open source vs proprietary software. I just wanted to say that in areas like game development, online entertainment or just really anything that require interacting with big communities of people on internet there is no way to avoid attacks on yourself.
So leading well known open source project is politics on a small scale and there will be a lot of people who want to hurt or manipulate you.
If you decide to become a public person and want to have fans and supporters then be ready to have haters as well.
1,059 comments
[ 3.5 ms ] story [ 478 ms ] threadAsahi Linux lead developer Hector Martin resigns from Linux kernel
https://news.ycombinator.com/item?id=42972062
New Apple Silicon Co-Maintainer Steps Up for the Linux Kernel
https://news.ycombinator.com/item?id=42990588
Did you read the rest of it?
Sure Apple being not as great to develop drivers, but ~99% of the article is about displeasure working with Linux maintainers.
EDIT: Here is the breakdown by paragraphs.
18 negative paragraphs 2 about Apple (11%) 4 about users (22%) 12 about Linux/Linus/Maintainers (67%)I was wrong about it being 99% about LKM but it's more accurate than saying 50% of issues are Apple.
I counted paragraphs topics myself: History (3), Proprietary Hardware Problems (8), Kernel/Rust problems (8), Other/Quitting (7). Could be off by one or two because I'm not a machine.
Also, I note that you did not disagree with or object to my initial response (the one made before your edit) that it is indeed halfway down the page before rust/kernel stuff is even mentioned.
I think it is safe to say that both Apple and the kernel/rust issues matter here and trying to derail any discussion of Apple's role into even more rust ragebait threads in a HN topic full of them is counterproductive.
No. Those are issues caused by users. You could have most open hardware platform, and it would still persist. See any OSS maintainer complaining about unrealistic user expectations.
> I counted paragraphs topics myself: Proprietary Hardware Problems (8), Kernel/Rust problems (8)
How are you counting those? I made a table, point me which exact paragraphs. Also it's deceptive to pull Rust into this story. marcan had nothing but praise for it, without it, he wouldn't be able to write those drivers.
The main complaint of marcan is the horrible experience you have as a hobbyist Linux contributor. You can't blame Rust or Apple for that. That's on Linus, and Linux maintainers.
Nothing. That's why this was said:
>> *There's a deeper issue* in open-source culture where harshness and gatekeeping drive away passionate contributors.
It's separate gatekeeping.
I entertained getting involved in the kernel for about 3 days, in college. The process is so complex, I just went on to do other fun things. The drama will turn off others. Organizational apathy is much worse, imo. I have quit jobs for this reason and that was when I got paid to stay.
Regardless of whether you think the project should be maintained differently, that's not your call, that's their call. Fork it if you want different policies.
Isn't that also what Linus is doing but on a professional forum, which is even worse? The issue comes down to de-escalation, and there wasn't enough on both sides. It's also not unreasonable to expect more from a figure head who is a role model in open-source development in general.
If you want your code merged in the kernel, you have to think about things from Linus' perspective. You cannot in any circumstances try to shame someone into adopting an enormous and unsustainable workload.
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 <hch@lst.de>
And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
---
Hellwig was abrasive and unreasonable. But there is no need to perpetuate, repeat, and repost absolutely one-sided, self-serving misrepresentations of the words he used.
You don't need to paraphrase. You don't need to guess. You don't need to distill or simplify.
He wrote English so we could read it; stop paraphrasing. It's unhelpful at best and nefarious at worst.
Edit: I think it's very telling that there is a crowd here that would literally downvote the actual quote. Actually it's more sad than anything.
What the article quotes Linus complaining about is a process issue. Paragon apparently used GitHub's GUI to merge some of their branches rather than the git CLI. Linus would prefer they use the CLI to merge branches because the GitHub GUI reportedly omits important metadata from merge commits, such as the developer email, and encourages uninformative commit messages.
The fact is, you need buy in from other devs and if a dev won't buy in you need to work out a way to avoid them or avoid conflict. It sucks, it slows things down, but frankly making it a "them vs us" is a sure fire way to make them oppose any change you want to make.
Public shaming even more disastrous as there's no better way to entrench someone in a position.
It sounded to me like a list of "friends who want to get more involved, I'll let you know who to avoid". Then, I read the interactions that sparked that post, and I could totally understand the frustration from OP's part.
Linus being unwilling to take a real stand on maintainers blocking Rust just because doesn't really help.
> To back up Sima here, we don't need grandstanding, brigading, playing
> to the crowd, streamer drama creation or any of that in discussions
> around this.
Marcan replied (https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...):
> If shaming on social media does not work, then tell me what does, because I'm out of ideas.
Then Linus replied (https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...):
> However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.
> Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics.
To me, it sure sounds like Marcan is making the case that they tried other venues, didn't feel like it worked, so they resolved to using their social media following to shame kernel developers if they didn't stop.
That is an entirely different situation from facing inner circles in an open source project while contributing to a major port.
Sock puppets aren't taken seriously while the word of the inner circle is taken as gospel.
I also certainly wouldn't take any of his complaints about cliques or brigading with any seriousness or self-reflection afterwards.
I’ve been supporting Hector since week 1 of the Asahi project and I think it’s a shame he’s thrown in the towel but I can understand why.
I don’t know enough about kernel development to have an opinion about about the Kernel policy of “no aliases” for contributions.
I certainly don’t care that some people think it’s weird for a man to have a female alter ego.
Maybe those things matter to you.
I mean, they are welcome to clarify if they want
* a brand new account suddenly appears, defending Marcan's behavior (the only comment/post ever of this account) with a very similar writing style
* Marcan immediately "notices" the new comment while doing "random search" (how ? he claims he doesn't browse HN, and even posted a screenshot of news.ycombinator.com being routed to 0.0.0.0 to block his own access to it the day before)
* Marcan highlights the comment in question on his media account [1], praising them "at least [this commenter] gets it"
Only circumstantial stuff, but sure smells very fishy to me.
[0] https://news.ycombinator.com/item?id=35400352
[1] https://archive.ph/zdVbA
https://vt.social/@lina/112887550181123672
https://docs.google.com/document/d/1W2Vvwg0rwSVb5r4TQ_NmAF8S...
If the C developers make it a "Them vs Us" thing, there IS NO ALTERNATIVE for the Rust developers.
Linus' reaction is quite literally the equivalent of a parent only punishing the loudest child, not the child that's been silently bullying that kid for months.
In particular, the DMA maintainer didn't want rust code in their DMA subsystem. That sucks, but it means you need to relocate your dma bridge code out of their subsystem. It does mean your driver will be a second-class citizen in the kernel tree (which was always going to be the case for rust).
Linus' reaction was to someone who started a public campaign against another kernel developer and tried to use that following to pressure the maintainers of the kernel to bend to the will of the newcommer. I'm sorry, but I'd also have a pretty negative reaction to that.
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. You don't do that. You handle things internally and privately and sometimes you tell the boss "sorry, I can't get this done because another team is blocking the change and they are unwilling to work with me".
And do not mistake my post. I'm not siding with the C dev just because I'm critiquing the rust dev. Guy sounds like he's too stuck in his way. The problem is you don't get a big well working and long running project like the kernel without having these sorts of long-term maintainers that make the calls and shots on what to reject.
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.
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)
> Maintainers like Hellwig who do not want to integrate Rust do not have to. But they also cannot dictate the language or manner of code that touches their area of control but does not alter it. The pull request Hellwig objected to "DID NOT TOUCH THE DMA LAYER AT ALL," Torvalds writes (all-caps emphasis his), and was "literally just another user of it, in a completely separate subdirectory."
> "Honestly, what you have been doing is basically saying 'as a DMA maintainer I control what the DMA code is used for.' And that is not how any of this works," Torvalds writes.
> Torvalds writes Hellwig that "I respect you technically, and I like working with you," and that he likes when Hellwig "call[s] me out on my bullshit," as there "needs to be people who just stand up to me and tell me I'm full of shit." But, Torvalds writes, "Now I'm calling you out on YOURS."
> The leader goes on to state that maintainers who want to be involved in Rust can be, and can influence what Rust bindings look like. Those who "are taking the 'I don't want to deal with Rust' option," Torvalds writes, can do so—later describing it as a "wall of protection"—but also have no say on Rust code that builds on their C interfaces.
> "Put another way: the 'nobody is forced to deal with Rust' does not imply 'everybody is allowed to veto any Rust code.'" Maintainers might also find space in the middle, being aware of Rust bindings and working with Rust developers, but not actively involved, Torvalds writes.
https://arstechnica.com/gadgets/2025/02/linux-leaders-pave-a...
The code was never in the DMA subsystem. At no point was there ever any Rust code in the DMA subsystem.
CH didn't even look at the patch before throwing the wall up. When it was pointed out that the patch already was the way he claimed he wanted it, he came up with a 2nd excuse, and then when that avenue was shut down he said he would do anything to stop Rust being put in the kernel, period, he wouldn't work with any Rust developers and he wouldn't accept adding a second maintainer for his subsystem that would do that engagement either.
From that point it's pretty clear that all previous engagement was just in bad faith.
There is always an alternative. Exit the project quietly and gracefully if Linus won't show proper leadership. Don't engage in poor behavior back at the C developers, that is just as wrong.
It's a magnitude more professional than the extremely over the top and public emails that Linus shares, which HN jerks off over. I too would be burnt out if people were picking apart what I said so closely but clapping when Linus says "this code is retarded"
The original message I read (https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...) they quite explicitly said (verbatim): "If shaming on social media does not work, then tell me what does, because I'm out of ideas."
This message brings up a lot of valid complaints about talented developers being stonewalled and you're honing in on one word that is not being used the way you think. Again, there are dozens of emails from Linus that are vastly more unprofessional than this.
Aha, I thought it was referring to the same "event"/context but it clearly didn't. Thank you for the correction.
If you don't want a maintainer, that's fine, but to claim it has anything to do with professionalism is dumb when this is seen as communication to admire.
https://www.reddit.com/r/linusrants/
> It's a magnitude more professional than the extremely over the top and public emails that Linus shares
Since when do two wrongs make a right? I think it's perfectly fair to say Linus hasn't shown the best leadership here. But that doesn't excuse Marcan's behavior.
https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
https://archive.is/uLiWX https://archive.is/rESxe
"Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project (...) Personally, I would consider this grounds for removal of Christoph from the Linux project on Code of Conduct violation grounds, but sadly I doubt much will happen other than draining a lot of people's energy and will to continue the project until Linus says "fuck you" or something. (...)"
"Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect. Every experienced kernel submitter has this in their head, maybe it should be finally written down."
"Okay I literally just started this privately and the first 3 names involved are all people named variants on "Christ". Maybe there's a pattern here... religion secretly trying to sabotage the Linux kernel behind the scenes??? Edit: /s because apparently some people need it."
Then, the fanatical C developers openly sabotage and work against all the Rust developers efforts. So, the last option for the Rust developers is to take it to social media. Otherwise, the C developers get away with creating a self fulfilling prophecy: Sabotage all Rust efforts, then claim the Rust experiment failed.
Linus didn't seem to ever have the time to actually take a stance, except of course on the social media issue. Fully ignoring all context. It's the equivalent of a school principal suspending the bullied victim for finally snapping and punching their bully.
His fellow R4L partners chewed him out for jumping in and spoiling their work. They even quietly but publicly disaffiliated R4L from him.
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).
I only see Danilo doing that in that thread. And admittedly Linus didn't respond (and Greg KH only minimally responded). But even CC probably means a lot of mail for top maintainers, and at that point I don't see anything that would've gotten in the way of "send a PR despite the Nacked-by", which has been done in the past.
Even if there was, I'm not sure I trust the word of such a drama-seeker directly, so it's reasonable to a evidence of on-mailing-list appeals adding CC (as Danilo did), and if that fails mention of contacting Linus off-list in that specific subthread.
The suitable path forward is to submit the patch series like normal to Linus, where it will be merged regardless of CH's NACK. CH isn't able to actually stop this process, he's just being a jerk.
However, I agree with you that it would have been nice to actually publicly clarify the situation rather than ignore it and deal with the whole thing behind closed doors. It shouldn't need to be explained that letting this sort of thing fester is a great way to kill motivation in a project and ensure it's less likely that new people will get involved.
Social media is an amplifier of interpersonal problems, not a place to seek for a resolution for them - unless your intended "resolution" is to beat down the other side, the people you have to work alongside by necessity, via potshots from random strangers who hardly ever bother to inform themselves fully of the situation. That is never going to be a true resolution, and I think Linus, for all his faults, recognizes that and that's why he draws the line there.
It doesn't also imply something like open contributions.
It's hard enough in physical spaces to remove abusers (usually the abused just stop showing up), I can't imagine there's an answer for preventing this kind of behavior in online spaces
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 address in a kernel development setting (and much less of a problem for userspace software).
This makes the “C is obsolete” position even harder to defend and ignoring the concerns of long-term kernel maintainers is not going to get anywhere! I think these folks ought to learn the lesson of Chesterton’s Fence [1] before continuing on their journey to promote Rust, which does a lot of great things!
[1] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
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 anything similar? Or is this just a fear of yours?
I think we should be very clear -- believing the future of systems programming is mostly memory safe isn't the same thing as saying "C programmers should...get out of the way".
The problem with the brigading (which has been done by the Rust for Linux community) is that it invites these zealots into the conversation. It's totally inappropriate and not at all constructive towards a compromise.
Plus the stated goal of Rust for Linux is to enable people to write drivers in Rust, not to rewrite the whole kernel in Rust. Yet there are countless people in the wider Rust community that believe Rust is the future and every line of C code still in use should be rewritten in Rust. It's gotten so prominent that "Rewrite it in Rust" has become a meme at this point [2]. There are now many developers in other languages (C and C++ especially) who reject Rust simply because they don't like the community.
[1] https://www.phoronix.com/forums/forum/software/general-linux...
[2] https://goto.ucsd.edu/~rjhala/hotos-ffi.pdf
So -- you're bothered by people on the internet, but not specifically the Rust for Linux people or the Rust project people? I guess -- I'm sorry people are saying mean things about a programming language on the internet?
There are also just as many (more!) anti-Rust partisans out there too, who say lots of crazy stuff too. I'm not sure there is much to be done about it.
> Yet there are countless people in the wider Rust community that believe Rust is the future and every line of C code still in use should be rewritten in Rust.
So what? Does your C code still run? I'm struggling to understand what the problem is. People are free to think whatever they want, and, if they what to rewrite things in Rust or Swift or Hylo or Zig or Java, that's how many of them learn!
Yes, they're free to rewrite their own projects in Rust. They aren't free to force others to do the same to their projects. That's what this is all about: a prominent R4L community leader tried to use brigading and shaming to force a Linux kernel maintainer into accepting and maintaining Rust code (along with the entire toolchain to support it). The maintainer refused, Linus got involved, and marcan stormed out of the room.
This isn't a debate about technical merits. It's a debate about maturity and what's appropriate for collaborating with others (and what's not). The Rust community has been going through a lot of growing pains over this issue for a while now.
Um, or any other they so choose?
> Yes, they're free to rewrite their own projects in Rust. They aren't free to force others to do the same to their projects.
Where is anyone forcing anyone else to do a rewrite in Rust?
Where is anyone forcing anyone else to do a rewrite in Rust?
When hellwig likened the R4L project to a cancer, he was implying exactly this. He saw this one patch as a Trojan horse (in the original Greek sense, not in the computer virus sense) to get Rust into the main kernel tree. This brings all of the toolchain and language issues into it. By relegating Rust to drivers only, the kernel maintainers avoid the issue of having to maintain a cross-language codebase and toolchain, whether they like it or not.
Being a maintainer of a project that accepts patches from contributors is like operating an orphanage. Allowing anyone to just drop off their unwanted babies results in an unmaintainable nightmare. You can say that the Rust for Linux team have been acting in good faith but the very public actions of one of their (now former) leaders contradicts this. The stated goal of the project was to allow drivers to be written in Rust. Adding Rust bindings to the kernel oversteps that goal. It's a legitimate concern.
You are aware this patch introduced no code into the main kernel tree?
See: https://lkml.org/lkml/2025/1/8/801> The stated goal of the project was to allow drivers to be written in Rust. Adding Rust bindings to the kernel oversteps that goal. It's a legitimate concern.
You do recognize that all drivers will need to bind to some C interfaces? So -- your argument (or the argument you suppose Hellwig has) is that it is better that each driver author recreate each such interface for themselves? Now, when these interfaces break as a result of a change in the underlying C code, instead of fixing that breakage at possibly a single place, that one true binding, now a maintainer might have to fix that breakage in a dozen such places? And this is preferable? This will cause less work for the overburdened maintainer?
It doesn't have to. By becoming a single point of failure for all Rust drivers that depend on it, it becomes the responsibility of all maintainers of the kernel to avoid breaking it when they change the C interfaces. It's a foothold into a world where all kernel maintainers need to run and test Rust builds, something Christoph does not want the headache of dealing with.
When your teenager brings home a puppy and promises you he'll never let the puppy leave his room, you know that's not true and it won't be long before you're the one taking care of it.
Ultimately it's about motivations. Long-term kernel maintainers are motivated to protect and promote the kernel as a maintainable and successful project. R4L developers, on the other hand, seem more interested in promoting Rust than promoting Linux.
> It doesn't have to.
Ah, it's one of those other kinds of Trojan horses that don't enter the city walls.
> By becoming a single point of failure for all Rust drivers that depend on it, it becomes the responsibility of all maintainers of the kernel to avoid breaking it when they change the C interfaces.
So -- I'll ask what the Rust for Linux people asked Hellwig -- what is your suggested alternative? Where do we go from here? Is it Rust drivers not be allowed to common interfaces ever? In that case, what are the Rust for Linux team doing?
Or is it that you would like Linus rethink his decision re: adding Rust to the kernel? And if so, why didn't Hellwig make that case directly to Linus? What's with all this performative bellyaching on the LKML?
The kind that have to be invited in, yes.
So -- I'll ask what the Rust for Linux people asked Hellwig -- what is your suggested alternative? Where do we go from here? Is it Rust drivers not be allowed to common interfaces ever? In that case, what are the Rust for Linux team doing?
That's not the kernel team's problem. They provide a common C interface. The fact that there's an impedance mismatch with binding to them from Rust code is a Rust problem.
Or is it that you would like Linus rethink his decision re: adding Rust to the kernel? And if so, why didn't Hellwig make that case directly to Linus? What's with all this performative bellyaching on the LKML?
I don't know what Linus's goals are, apart from keeping his maintainers happy and keeping the kernel rolling along smoothly. That's not a small thing. From what I can see, Christoph has been a maintainer for over 25 years.
Does Linus want to have his cake and eat it too? Sure. But I think he earned that right by building Linux into what it is today. The R4L team hasn't paid their dues. As someone else mentioned, it took 10 years for Clang to become a supported compiler for the kernel.
Nobody tried to force Christoph into accepting or maintaining Rust code. This was stated repeatedly.
I don't see how you can possibly have actually read the discussion and come to this conclusion. At this point you're just making false accusations and contributing to the flamewar.
https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0...
I wish I knew of a less condescending analogy but I think it gets the point across. The list of former kernel maintainers is extremely long. Anyone who leaves the project, as marcan did, leaves all of their code for someone else to maintain. This is not a problem for drivers which can be left orphaned. For all other code it is a problem!
He expressed complete opposition to having Rust anywhere in the kernel at all, including places he doesn't maintain. He was opposed to any other maintainer deal with Rust for him, even though Robin Murphy (who is already a reviewer on the DMA side) expressed willingness to do so. His initial replies were an exercise in goal-post-moving.
https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0...
You're making excuses for stuff that does not really need to be excused.
Since Linus backed him up on this issue I’m left with the impression that Christoph is not a lone maintainer standing in the way of the inevitable march of progress; that his concerns are valid and shared by the founder and leader of the project and represent the views of other maintainers who preferred not to step into the ring on this debate.
Furthermore, the Rust code depends on his C dma code. That automatically makes it Christoph’s problem when something breaks, regardless of how many R4L maintainers come and go from the project.
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.
I think it's clear from the surrounding context that you are likely over-interpreting some of Hector's comments.
What is the losing side of history here? There is simply too much C code in the Linux project to say "stop this ride, I want to get off and only use Rust" right now. This is a fight about some new code. Rust drivers in kernel and perhaps in the future Rust in other places it makes sense. I believe Hector's arguing Rust drivers are inevitable, because they are already here!
What did I say above:
> I think we should be very clear -- believing the future of systems programming is mostly memory safe isn't the same thing as saying "C programmers should...get out of the way".
The thread was not about Rust drivers, it was about adding Rust code to the DMA module. I.e. about mixing two different languages in a single module, thus requiring being knowledgeable about both languages in order to maintain it, thus making the module less maintainable. In fact, a few developers were saying that they didn't mind Rust drivers, if they used the C ABI as-is. Someone wanted to expose new Rust-specific interfaces to support cleaner abstractions from Rust drivers.
AFAIK this is false. The patch was CCed to the maintainer as FYI, but all the code was in a Rust a module binding to the C DMA interface. If I'm wrong, show me the code.
See the discussion here: https://lkml.org/lkml/2025/1/9/398
I'm willing to grant that it is possible Christoph Hellwig simply misunderstood the patch and overreacted.
See: https://lkml.org/lkml/2025/1/8/801See: https://lkml.org/lkml/2025/1/9/398
See: https://lkml.org/lkml/2025/1/10/619
See: https://lkml.org/lkml/2025/1/29/999
You've now discovered why this blew up in the first place. All of the excuses used to reject the code were not just petty but also outright false, and trivially so.
There are _already_ dozens of hobby OS projects and embedded groups doing systems work in Zig. Everyone knows Zig is a systems language. It doesn't have a chip on their shoulder.
That's an invitation to self-reflection.
We all should consider that, in every discussion.
The opposite is to think that everyone who disagrees is by definition wrong, which can never be productive.
Linux said no brigading. Hector resigns twice and in the second time, despite saying he wouldn’t elaborate on Rust vs Linux, proceeds to blame Linus and start another social media brigade.
This kind of rant is typical of the public behaviour of the (typically young and "woke") modern social-media "developer" crowd, and your behaviour here only illustrates why so many dislike them. If there are any "hive mind effects" here, they're in your mind.
https://asahilinux.org/2025/02/passing-the-torch/
"Everyone else is a bully, but not me - I'm just trying to raise awareness."
[1] https://news.ycombinator.com/item?id=42972571
Also, I'll add that whenever I've seen an unflagged hateful comment I've emailed hn@ycombinator.com, and the success rate in getting the comment killed and people told off (or banned) is thus far exactly 100%. This usually happens if someone leaves a comment a few days after the discussion dies down, so few see (and flag) it.
I can dig up many such examples, but I suspect the response would be, "of course that's not moderated" because this community has a different set of values than some others.
Moderation is always an editorial action, and as such we tend to view it as strong when it aligns with our own values and weak when it doesn't.
IMO, if you're going to make charges like this, which would be serious if they were true, you should include links so readers can make up their own minds.
https://news.ycombinator.com/item?id=42907076
https://news.ycombinator.com/item?id=42783776
https://news.ycombinator.com/item?id=42780835
https://news.ycombinator.com/item?id=42718838
https://news.ycombinator.com/item?id=42708579
https://news.ycombinator.com/item?id=42700319
https://news.ycombinator.com/item?id=43034231
https://news.ycombinator.com/item?id=43031405
https://news.ycombinator.com/item?id=42959625
My methodology: Search for any of the following terms: woman, biological, Black, Latino, gay, trans, woke, dei, or virtue signal
Set to "Comments" and "30 days". You'll find plenty of people saying things that are pretty awful. Yes, they are not the majority of posts, this place isn't a cesspool, it's just a place that permits "just asking questions" or "it's up for debate" as a defense for behavior
I could find many, MANY more examples.
Of the 10 links you listed, 7 seem to me obviously to break the site guidelines and I've flagkilled them. One, incidentally, was from an account that we banned earlier today (https://news.ycombinator.com/item?id=43042278), and another was from an account that we banned a couple days later (https://news.ycombinator.com/item?id=42483610).
Of the remaining 3 of the 10, I disagree with you about saagarjha's comment: https://news.ycombinator.com/item?id=42907076. That one seems thoughtful and in keeping with the site guidelines. It does use a lot of sort-of trigger words (I counted "trans", "vegan", "left wing", "Democrat", "progressive", "conservatism", "Republican"), but surely we're not going to punish people just for using words like that.
The other two seemed borderline to me, although I confess that one was so long that I couldn't read it before becoming le tired.
> I could find many, MANY more examples.
I'd be interested in seeing them, and I hope it's clear that I mean that. I don't want to argue about this—I want to see what you're seeing.
I'll dig up some more. They tend to be a bit stochastic, and on various topics. (There was an article that made the front page awhile back written about pg that was written by a trans woman that was an absolute lightning rod for this, iirc.)
There were a number of remarks on the prior thread by people making conspiracy claims, harassment, insults etc. Some of them get flag-killed, some just down voted but ultimately the users on the site still remain.
Of course I'm not one to be above such a thing in terms of insulting people occasionally but HN is really quite permissive in terms of what you can post and get away with. It takes consistent and repeated bad behavior to get a warning, and even more to get banned. And if you're an expert in being politely venomous you can get away with even more. That's why the outside perception of HN tends to be a lot worse than the inward one.
> Hi! It looks like you might have come from Hacker News.
> Asahi Linux developers are frequent targets of abuse on Hacker News. Despite our pleas, the moderators have not taken effective action to improve the situation.
> Overtly hateful content is often flagged on HN and not immediately visible. Unfortunately, when a comment is flagged and killed, its child subthread is not. That preserves the 'clean' image of the website, but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do. HN uniquely has a high page rank and low moderation, making it a prime target for bad actors to poison search results with abuse, bigotry, and nastiness. This isn't low-level trolling, but an organized attempt to destroy lives, including of developers in our communities.
> Please demand change within your community.
This is an unfair and gross assessment. I've lost some respect from Asahi for this.
They're calling for extreme moderation of opinions they don't agree with, which is the opposite of open discourse.
Asahi: deal with it. You're Streisand Effecting this. Your inability to handle drama is actually causing more drama. Just turn the other cheek and ignore it.
What is the "it" that you're insisting they "deal with," here? What is the "drama?"
Also what value does bigotry, homophobia and transphobia have in open discourse that it must be preserved? None of that is on topic for Hacker News, why must it be on topic for the Asahi Linux community?
Turn the other cheek. Ignore it. It's 2025 we're learning lessons from USENET all over again and having to reign in the over-sensitive, disregulated behavior of some people.
I'm gay, on the spectrum, and my wife is trans. What certain people in "my" community do from places of relative comfort makes life for those of us in more moderate / conservative-leaning places worse. The screeching from our community [2] has turned our little demographic into a major culture war topic, and it's all because of the bad attention and friction you manufacture.
Conservatives let LGBT and trans issues slide for over two decades of my adult life. But by being loud and attempting to silence them -- by harassing them -- you've become the nail that sticks out and have now created a tidal wave of opinion against us.
It's easy for some European or SF trans person to call for universal outlawing and censoring of speech, but you have to realize your message is being read all over the world. It's interpreted by an overwhelming number of people as attempting to memory hole conservatives and flush away their culture.
Simultaneous to your harmful messages, folks are also being inundated with social media rage/engagement bait to make them think liberals are literally attempting to destroy and annihilate conservatives [3].
Your message adds weight to this perception, and all you accomplish here is making the majority of voters angry at us. It even turns moderates and would-be supporters sour.
I hate that you represent me by association and think that this is acceptable behavior.
As another anecdote, when I talk to my friends about Rust, the subject of "drama" frequently comes up. Why is that? Suddenly my work becomes harder for an entirely unrelated and unmerited reason. That's just me as an LGBT person - imagine how straight people feel.
We shouldn't have to keep reading about this over and over. It's orthogonal, childish, dysfunctional behavior.
Take one more look at that loud disgusting banner on the top of the Asahi page. That's neener-neenering in front of everyone. Even the moderates you hope to be your allies. Please, for god's sake, put yourself into different shoes. You're asking them to do it for you, but it's your turn.
I think you'll see that your behavior is also harassment.
Please calm down, slow down, and behave like adults. Not everything warrants a response or attention. Chances are, it'll just go away and get totally ignored. When you engage, you shift the conversation and bring yourselves down to their level. You create a firestorm of drama that everyone watches like a burning wreck.
Stand above that.
[1] I only wanted to talk about the very public, inflammatory resignation and the immature handling of this by certain parties.
[2] eg, folks whose entire personality is to harass people on social media: https://www.tiktok.com/@lillytino_/video/7295890626539687210
[3] Just look at this image and how religious people take it: https://danolinger.com/2018/11/01/responding-to-persecution-...
In the US, DADT was repealed in 2011. Obergefell was 2015. The idea that they let LGBT and trans issues slide for over 20 years is fundamentally wrong and not supported by history.
I reject the rest of your post and the defense of those that would take rights away from individuals and myself because they have to be coddled.
While my life experience has been different to yours, from what you've written about how you've been treated by others in your community, as a consequence of who you are, it seems understandable to me that you might experience those feelings--and, even if they didn't seem understandable to me, it is more important to me that you feel heard and your feelings acknowledged as valid and not dismissed.
I hope I have been able to communicate that intent effectively.
----
At the risk of falling into the stereotype traps of "straight white male thinks every rhetorical invitation is a literal invitation for him to say what he thinks" & "straight-splaining" I did want to provide an answer to the question in the last sentence here:
> "As another anecdote, when I talk to my friends about Rust, the subject of "drama" frequently comes up. Why is that? Suddenly my work becomes harder for an entirely unrelated and unmerited reason. That's just me as an LGBT person - imagine how straight people feel."
(I preface the following with an acknowledgement that it's bullshit that you have had to deal with the impact of this rather than the predominantly straight white males who don't want to be made to feel uncomfortable.)
TL;DR:
FWIW, from my perspective as a straight white male I feel the subject of "Public Interpersonal Conflict" attributed to Rust is directly related to values rightfully espoused/embodied by the Rust project/community/language that are at odds with values held by other groups.
Specifically, groups consisting of predominantly straight white males believe that the comfort of predominantly highly skilled straight white males should be prioritized over the physical well-being of other humans; and, also over the security and stability of the software other humans use.
They are also unlikely to agree with this characterization.
Unlike the above group however, rather than targeting resentment at the people whose physical well-being is at risk I choose to direct my resentment at the predominantly straight white males who choose to dismiss important issues as unimportant "drama" because they resent being "made" to think about issues that impact people other than themselves.
----
For anyone who disagrees with my characterization I would point out that we do not know what other contributions Alan Turing may have contributed beyond "Turing Completeness" & "the Turing Test" to current in-demand fields such as AI if he hadn't been persecuted for not being a straight white male.
I would also remind them the ARM CPU attached to that unified memory on which they're running their latest AGI & LLM models is thanks to another person some people in the present day think should be persecuted for daring to exist.
But equally people shouldn't have to trade advancements in the field of Computer Science for the right to exist without persecution.
----
I will acknowledge that its entirely understandable to want to avoid the associated discomfort because from personal experience it is very uncomfortable to have to re-evaluate one's place & responsibility in the world after a lifetime of being told something different.
----
The other ~2,500 words I wrote on the topic was certainly more nuanced but pretty much said the same thing with more beating around the bush with additional personal context.
For any straight white males who may be confused why someone might think as I do, all I can say is that time spent reading/listening to this (unfortunately, archived) resource is likely to be worthwhile, if temporaril...
saying things like "an organized attempt to destroy lives, including of developers in our communities" is patently not true. trolls get flagged. honest nice people who don't agree with you aren't trying to destroy anything and nor do they hate you.
* "bad actors" links to https://en.wikipedia.org/wiki/Kiwi_Farms
* "destroy lives" links to https://en.wikipedia.org/wiki/Kiwi_Farms#Suicides_of_harassm...
While you may be correct that initial "trolls get flagged", the statement on the Asahi site agrees that while the initial comment may be flagged & killed, the other comments in the subthread are still indexed, visible & tend not to get moderated/flag:
"Unfortunately, when a comment is flagged and killed, its child subthread is not. [...] but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do."
Based on other remarks about the content of such subthreads it seems surprising to claim that follow-on comments are made by "honest nice people".
I'm as much of a fan of adverbs as the next person but using words like "categorically", "extremely" & "patently" doesn't seem to leave much room for nuance of interpretation when written by someone who I'd have assumed was a third party observer?
While I could understand someone describing JWZ's HN-tailored "banner" (I wouldn't suggest researching this if anyone is not already familiar) gauche and immature, it feels like somewhat of a stretch in relation to a plain text message who last sentence starts with "Please".
> the other comments in the subthread are still indexed, visible & tend not to get moderated/flagged
indexed: please complain to google.
visible: not unless you turn on show-dead. so don't do that.
don't get moderated: they are already dead.
> I'm as much of a fan of adverbs
i mean what i said. i'm extremely tired of seeing histrionics and exaggerations, misplaced blame, etc. turned into loud, unfair, criticism toward what is probably the best moderated group i can think of.
JWZ's banner is at least recognizable as satire, and his opinions are well known. i can disagree with him, but still find it a little bit funny (and immature). but if you do the same thing (yes, with a please), then you are just exactly as mature. and if you are serious, less grounded in reality and not nearly as funny.
> * "bad actors" links to https://en.wikipedia.org/wiki/Kiwi_Farms
> * "destroy lives" links to https://en.wikipedia.org/wiki/Kiwi_Farms#Suicides_of_harassm...
As has already been pointed out, HN isn't "Kiwi Farms" (whatever that is), so WTF does that have to do with their whining specifically about HN???
> While you may be correct that initial "trolls get flagged", the statement on the Asahi site agrees that while the initial comment may be flagged & killed, the other comments in the subthread are still indexed, visible & tend not to get moderated/flag:
> "Unfortunately, when a comment is flagged and killed, its child subthread is not. [...] but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do."
And what's the problem with, I assume they mean, not all comments in subthreads of dead comments also being automatically killed? I read HN with "Show dead" on, so I get to see those with a simple click of "[... more]", and I usually open them. What I've found is that the absolute majority of these responses are sensible comments pointing out what's wrong with the original inappropriate comment.
So the "problem" they're complaining about is not only not a problem; it's actually the remedy for that exact issue. The banner is not only childishly whiny, but actually self-contradictory. In short, it's stupid.
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 hardware they're aiming to support and that they're writing many of their own drivers _anyway_ (and so are not relying as much on the large # of existing linux drivers), that approach might be more viable. I'd be surprised if the Asahi GPU work wasn't the largest problem by far that their team faces, and as such it would make sense to choose a kernel that lowers the difficulty on that aspect to the greatest degree possible.
They are relying heavily on mesa. I'd also assume that GNU stuff is also pretty essential.
Perhaps Android would be possible? It has a HAL that might be easier to work with than the raw linux kernel. The android devs have put in a lot of effort to make downstream driver development not painful. With android, they'd also still have GNU stuff available.
The big issue is non-linux will mean every single open source tool may have a compatibility problem. You also end up dumping a huge amount of capabilities (like running docker containers).
Isn't mesa portable? Or are there parts that are OS-specific?
> With android, they'd also still have GNU stuff available.
I don't follow; Android is a non-GNU Linux distro. Or do you mean that being on Linux makes GNU stuff easy? (But then, GNU runs happily on BSDs and other unix-likes)
IDK. I'm not familiar with mesa enough to know how portable it is. That said, I do know that it's primarily deployed on linux. An issue with portability is simply that when big projects like mesa are developed, non-linux environments are rarely developed (No clue, for example, if you can build mesa for BSD).
> Or do you mean that being on Linux makes GNU stuff easy?
Mostly this. I don't think, for example, those GNU tools will port over to redox. Building them targeting android is a snap.
There are official freebsd packages of mesa: https://ports.freebsd.org/cgi/ports.cgi?query=mesa-&stype=al...
In fact, https://doc.redox-os.org/book/graphics-windowing.html seems to imply that redox is or plans to use mesa.
Android:
Okay, that's fair; termux already proved that GNU on Android is viable.
Even the OS-specific parts are at least permissively-licensed. OpenBSD is about as religious about "all new code must be under an ISC-compatible license" as it gets, and even they pull in Linux DRM/Mesa code for hardware graphics acceleration: https://man.openbsd.org/drm.7
The entire point of Asahi is to run Linux on macOS (edit: on Mac hardware, not macOS). If they did what you’re suggesting it would be a completely different project.
At this point, it’s really about what trade-off you’re willing to make. Do you want a better graphical interface or better docker integration?
Because it runs a Linux VM at a considerable overhead and serious issues if you want anything more detailed in networking than `-p 8080:8080`.
Perhaps you’re confusing it with XNU? (Which is Mach merged with some BSD stuff).
The existence of other ARM laptops is irrelevant; the reason MBPs are so good has little to do with ARM. Yes x86 makes the processor frontend more complicated but this doesn't make a big enough difference to come close to accounting for how much better the MBP is than its competitors. I would guess the biggest factors are Apple's ability to buy the entire run of TSMC's best process node, and the fact that they have a high level of competence at designing CPU cores and other hardware. The instruction set the core uses is just not that important in comparison.
Really?
What is so great about a locked down hardware, locked down software machine, that phones home to Apple all the time?
The only reason to get Macs is if you have a niche case of needing long battery life (most people don't, even if they say they do), but this is where the other ARM laptops are gonna also be good, without all the proprietary crap.
Even if you consider the hardware "tech jewelry", isn't it strictly better to have a way to run Linux on it instead of sending it to landfill? Seems silly to exclude a particular set of hardware from consideration for arbitrary reasons?
>isn't it strictly better to have a way to run Linux on it
In a perfect world, Apple would open source the firmware, which would let people just compile the linux driver for it. While Asahi project is cool in terms of figuring stuff out, ultimately its a lost cause because Apple will never be on board.
The Asahi developers have repeatedly and publicly asserted that were it not for Rust they would not have been able to achieve the level of quality required for the project, at the speed they did, with as small of a team as they have. From the article:
> Rust is the entire reason our GPU driver was able to succeed in the time it did.
Nobody ever claimed that it's impossible to write these drivers in C -- C is "Rust-complete" in the sense that you could in theory write a compiler that translates any Rust program to C.
They're just claiming that Rust allowed them to write much higher-quality code, much faster, which seems plausible.
FreeBSD may be open to it? It's been awhile, and I haven't kept up to date on it for a year or two. But once again, I think you'd have to start from scratch. So everything for R4L that was built before Asahi Linux needs to be done on the FreeBSD side.
NetBSD is probably a no go. NetBSD supports architectures that Rust (due to LLVM) can't support. Which means it is most likely a no go for NetBSD, NetBSD's schtick is that it can run on anything and they will fully do everything in their power to make sure NetBSD can run on any hardware and be maintained. Hardware portability matters for them.
The attitude I've seen from OpenBSD devs is, the answer is to 'git gud' at C and, not replace C code with Rust. Or in other words, they have no interest in Rust in the OpenBSD kernel.
I don't really know where DragonFlyBSD falls in this. Its the BSD I know the least about.
Wishing I had donated before, I'll sign up for opencollective now. I can only imagine the anticlimactic nature of releasing the emulation stack for gaming [0] and not seeing any increase in interest financially. One wonders what funding might have made it more worthwhile than simply passing the hat.
[0] https://asahilinux.org/2024/10/aaa-gaming-on-asahi-linux/
This sounds so rough. I can't imagine pouring your heart out into this labor of love and continue to have to face something like this. Back in the early days of Quora, when it used to be good, there used to be a be nice be respectful policy (they might still have it), I wonder if something like that would be helpful for open source community engagement.
Regardless, major props to Marcan for doing the great work that he did, our community is lucky to have people like him!
The secret is to have a healthy system for taking in those requests, queueing them by priority, and saying, "you are 117 in the queue, you can make it faster by contributing or by explaining why its higher priority".
You can't let feature requests get to you, the moment you do your users become your opponent. None of those requests are entitled, the author has clearly already reached a point where they are antagonistic towards requests.
Great idea about the priority queue.
My company's bug tracker is mostly internally-filed bugs, but accepts bugs from the public. The difference in tone and attitude is night and day. The public-filed bugs can be wild, varying across: Rude, entitled, arrogant, demanding, incoherent, insulting, irrelevant, impatient... They are also the worst when it comes to actually including enough information to investigate. Frequently filed without logs, without reproduction steps, sometimes without even saying what the filer thinks is wrong. We get bugs with titles "It doesn't work" and with a text description that reads like a fever dream from someone very unwell.
We do have strong personalities among employees, but bug reports tend to be professionally and competently written, contain enough information to debug, and always, always leave out insults and personal attacks. The general public (at least many of the ones technical enough to file bug reports) does not seem to have the emotional regulation required to communicate professionally and respectfully.
In projects where this is a problem, I've made an issue template that clearly requests all the stuff I think I'll need. There's a big note at the top of the template that says it's not optional and that if it isn't filled out fully, I'll close the issue without comment.
And then I do that, every time. Sometimes they fill it out and reopen, sometimes they don't. Either way, I don't end up wasting time trying to help people who don't respect my time.
Its quite difficult to ban someone from a public park, especially when they can just put on a new hat.
Its really easy to ban someone from a private park. Even if they do put on a new hat, when they get belligerent again you just revoke the renewal of their access pass.
Fair deals attract people with some money, but the almost-free only attract people who are forever broke, who live their life feeling entitled to everything being handed over to them.
this is always true with, at least a great many, people. it's related to choosey-beggar syndrome. it's a bug/glitch/feature in human psychology.
if you ever have the chance to be a property manager, never ever let someone move in a week early or pay a week later for free. never let your rent get drastically below market. when people aren't paying for something, it's incredibly common behavior to stop respecting it. it's like a switch flips and suddenly they are doing you the favor.
that's why in times past, offering or taking "charity" was considered impolite. but making a small excuse might be ok. say someone needs to stay an extra week after their lease was over, but was strapped for cash. instead of saying "sure you can stay one more week", say "well, you'd really be doing me a small favor staying in the place to watch for the extra week since it's empty anyway. how about i discount the rent by 50% for that week and amend the lease to take care of it."
Having in the person taking these meetings for a software vendor, it can get really toxic quickly and I never had more than 1 meeting a quarter with really toxic people and they were at least paying for the product and maintenance so hearing them out was part of the job. It unfortunate to get to the point where you view customer requests as antagonistic, but I can see how it happens. Some people really feel entitled, and some have a job to do and limited resources or control to do it in.
Does it have to be a meeting? Although it's about sales calls, I'm reminded of https://keygen.sh/blog/no-calls/ (HN discussion: https://news.ycombinator.com/item?id=42725385 )
That said, I sympathize very much with Marcan on this project: getting the basic infrastructure for Linux operational on new hardware inflames passions much more than a niche project like a DAW.
I've read your comments here (and elsewhere) for a long time, and I'm sure you'd have some great ideas or at least opinions about this, which is pretty relevant to what you just wrote: https://news.ycombinator.com/item?id=43037537
It's much easier to shrug off strong comments when the people who do support you are making it possible for you (and one other) to lead a pretty comfortable middle class life.
Simplest ( works in enterprise too) is to say pay for it to be faster or even considered.
I would tell them:
"I have 5 P1 tickets, 8 P2 tickets, and dozens of P3 tickets. Your ticket is a P3 ticket."
They would ask that I change it to a P1. I would. Then they would call me an hour later asking me about the ticket and I would tell them:
"I have 6 P1 tickets."
That's when they'd understand ;)
Otherwise he knows he's 6th in line.
The day came when, after prolonged hand wringing and with stern observations about great power and great responsibility, the priority could be set to P0. But like any bunch of junkies we came off this new high all too quickly and the P-1 classification arrived, the showstopper of showstoppers.
In hindsight what I most regret is that we stuck with an integer field; we were denied the expressive power of fractionally critical issues.
I got along great with the sales guys. They could understand that kind of thing.
Not when all the other P1 tickets are from other sales guys.
But at least now they're all fighting with each other, via your manager, so they're out of your hair.
This is when the underrated skill of saying NO pays off massive dividends. One long-term client once told me the thing he appreciated the most, compared to most other consultants, was that I wasn't afraid of pushing back on his requests and saying no (within reason). Probably the most valuable feedback I have ever received.
Obviously, there was some oversight from managers, but overall it worked pretty well.
If you're supporting end users you need to be collecting money from them.
The mechanics of this system are entirely upside down. The corporations have bought into open source to regain control of computing and passionate developers are mired in the swamp of dumb user requests.
Something went very wrong here.
> I miss having free time where I can relax and not worry about the features we haven’t shipped yet. I miss making music. I miss attending jam sessions. I miss going out for dinner with my friends and family and not having to worry about how much we haven’t upstreamed. I miss being able to sit down and play a game or watch a movie without feeling guilty.
This is the big problem really. He should have just turned down his work hours to a regular 40 a week, asked for more donations to pay more people and asked for more volunteer help. And honestly, probably therapy.
I don't know this person so this is completely baseless speculation but I assume they are "going through it" in some way and experiencing significant burnout, which based on my own experience in the past has a way of (negatively) amplifying all sorts of interactions that are related to the source of your burnout.
Basically, making linux work on Apple hardware is a pretty hard task, including a shitload of reverse engineering.
When a user decides to try it, and finds a lot of features missing, they are completely unaware of the work required to get it into that state, and just think they should have the readily available features.
I'd expect the worst part for an Asahi project contributor to be the active sabotage some angry Linux kernel devs are trying to pull because they don't like Rust. Users being unreasonable is one thing, but your fellow maintainers are supposed to be allies at least.
I hope Marcan can find a new project to take on that doesn't involve all of this mess.
The only way to do that is to never collaborate with anyone else. I hope he'll be someday able to process what happened, why and reach appropriate conclusions. Software development is a social activity, especially with relatively high-visibility projects like Asahi, and it comes with just as usual burden of social troubles as any other kind of social activity.
Yes.
> The only way to do that is to never collaborate with anyone else.
Not necessarily. You can also treat project politics and social skills like any other technical skills that you need on your team like network engineering or database optimization.
If you can find trusted collaborators with those social and political skills, you can make a lot of things happen without necessarily being very good at it yourself.
Team building has a lot of parallels with building a full stack technology. Or building a sports team.
The real answer is to either learn these skills or, as you suggest, delegate them. Hoping to find something that doesn't involve "all this mess" at all will be fruitless.
I don't think it's even just that, it seems to be something about the price.
I work on a piece of closed-source free software, and we consistently get support requests from unbelievably entitled assholes. The worst of them are the ones that have some technical knowledge; they will not only demand things be fixed or implemented, they make completely erroneous statements about how easy it would be to fix/implement with the conviction that they are 100% correct, with a level of arrogance that is impossible to fathom how they could have written their email with a straight face.
The support requests we receive for a paid offering from the same company are 99% of time much more pleasant people (of course there are the, "I PAID FOR THIS YOU MUST FIX IT!!!1!" on occasions, but they're a definite minority).
Sounds like a great time to give them a refund because they didn’t get the product they thought they were getting.
Too passive aggressive? :)
When I want to give something away, I list it for some nominal fee like $10, then just tell them to keep it. Because when I used to list things for free, I got the dredges of society bothering me. Asking for delivery, asking me to hold it for 3 months til they can find a truck, cussing at me for saying no to both of these, cussing me because I sold it to someone else already, telling me long sob stories to guilt me. I've never had any of that happen when asking for money(except one guy wanted me to deliver it for $20, which was a fair-ish offer).
I wonder if that same 'pay but you'll get it back under the table' model could work for software? At least until the word got out, I guess.
Anyway, if your project involves convincing hundreds of maintainers to increase their cognitive/work load in order to include your fancy new foreign workflow breaking language into their project, you have to expect pushback.
In those days, I was part of a core development team for a project with a fairly large community. A few bad users and a few bad development team members is all it takes to poison something like that.
Now I barely even contribute to Open Source projects even when I fix them for my own uses.
This has not been my experience. Perhaps consider that the problem is not the users.
> the active sabotage some angry Linux kernel devs are trying to pull because they don't like Rust
On the other hand, users that demand you rewrite the project in their favorite language or otherwise accomodate their preferences over your own are pretty annoying.
Who's demanding a rewrite of Linux?
For some reason people feel that it is appropriate to throw barbs in their issue reports. Please to everyone out there, if you find an issue and want to report it (hurray open source!) please be kind with your words. There are real people on the other side of the issue.
Always remember, you catch more flies with honey than vinegar.
That seems to be a general characteristic. I strive to be cheerful and helpful whenever I'm asking for something. I feel like (sadly) it sets me apart from the crowd and helps me to get what I'm asking for. And IAC, with so little effort on my part I may brighten someone else' day and that makes me happy.
Just last week I asked housekeeping at a hotel for an old style coffee pot since I had brought my own coffee and filters. I started with "Can I pester you a moment?" and the conversation went up from there. Housekeeping was extremely friendly and helpful. Later I guessed this might have been her way to disarm some of the typical hostile interchanges she's been the brunt of.
There's a broader topic of ... just be nice to people. It doesn't cost anything. It does reassure me that this universe has been struggling with this for decades upon decades--witness the Malvin and Jim scene in WarGames. "Remember when you told me to tell you when you were acting rudely and insensitively?"
That's certainly how I felt when trying to get my drawing tablet to work properly under Linux Mint, although in my case I skipped filing an issue and just gave up and went back to Windows.
First of all, I wholeheartedly applaud Marcan for carrying the project this far. They, both as individuals and as a team proper, did great things. What I can say is a rest is well deserved at this point, because he really poured his soul into this and worn himself down.
On the other hand, I'll need to say something, however not in bad faith. He needs to stop fighting with the winds he can't control. Users gonna be users, and people gonna be people. Everyone won't be happy, never ever. Even you integrate from applications to silicon level, not everyone is happy what Apple has accomplished technically. Even though Linux is making the world go on, we have seen friction now and then (tipping my hat to another thing he just went through), so he need to improve his soft skills.
Make no mistake, I'm not making this comment from high above. I was extremely bad at it, and I was bullied online and offline for a decade, and it didn't help to be on the right side of the argument, either. So, I understand how it feels and how he's heartbroken and fuming right now, and rightly so. However, humans are not an exact science, and learning to work together with people with strong technical chops is a literal superpower.
I wish Hector a speedy recovery, a good rest and a bright future. I want to finish with the opening page of Joel Spolsky's "Joel on Software":
Technical problems are easy, people are hard.
Godspeed Hector. I'm waiting for your return.
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 activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code.
Writing the code is at most 5% of software development IME. This is what I always say to people I work with. I absolutely love writing code, but there are so many and more important activities around that, I can't just ignore them and churn out code.
This really depends on what you work on. And how good the managers are on your team. I talked to a manager at Google once about how he saw his job. He said he saw his entire job as getting all of that stuff out of the way of his team. His job was to handle the BS so his team could spend their time getting work done.
This has been my experience in small projects and in very well run projects. And in immature projects - where bugs are cheap and there’s no code review. In places like that, I’m programming more like 60% of the time. I love that.
But Linux will never be like that ever again. Each line of committed code matters too much, to too many people. Is has to be hard to commit bad code to Linux. And that means you’ve gotta do a lot of talking to justify your code.
I did some work at the IETF a few years ago. It’s just the same there - specs that seem right on day 1 take years to become standards. Look at http2. But then, when that work is done, we have a standard.
As the old saying goes, if you want to go fast, go alone. If you want to go far, go together. Personally I like going fast. But I respect the hell out of people who work on projects like Linux and chrome. They let us go far.
Someone who is in a management position, has good political skills and good connections will be way more efficient at doing some of this non-programming work.
This is something that even C-levels forget. Something that takes a CTO 2 minutes to do can take several months for a regular developer to achieve, and I have plenty of experience on and plenty of examples of that.
I have written plenty of code that's stuck on this first step in my life, including some that went to the very same LKML we're talking about here right now. Some of those things have already been independently written again by other people who actually managed to go further than that.
All the while: You are correct, being able to produce anything that solves a problem is much more valuable than being able to talk about it. But in order to unlock the value (beyond solving your own problem) absolutely requires communication
These are all engineering tasks, and the longer you spend on a team/in a company, the more likely it is you provide more value by doing this than by slinging code. You become a repository of institutional knowledge to dispense.
Even before we started coding, there was an RFC written by us. We have talked about it, discussed it, ironed it out with the chief architects of the project. When everything made sense we started implementing it. Total coding hours is irrelevant, but it's small when compared all the planning and it's almost finished now.
The code needs to tap and fit into a specific place in the pipeline. Finding and communicating this place was crucial. The code is not. Because you can write the most sophisticated code in the most elegant way, but if you don't design and implement it to fit to the correct place, that code is toast, and the effort is a waste.
So yes, code might be the most enjoyable (and sometimes voluminous) part, but it's 5% of the job, by weight, at most.
If you can communicate it can be 99% of the value. Getting someone to write something to back it up is trivial in comparison.
Perhaps "useless" was the wrong word the GP used. "valued" may be better.
It's fairly common for very useful/valuable code to be discarded because the engineer (or his management) failed to articulate that value to senior leaders as well as someone else who had inferior code.
People might also live their hobby dev experience better if they were really coding for themselves without any expectation except pushing the code to a repo. As a hobby dev, you don't have to make package, you don't have to have an issue tracker, you don't have to accept external contributions, you don't have to support your users if you aren't willing to have this on your shoulder. You don't even need a public git repo, you could just put a release tarball when release is ready on your personal website.
Yeah but FFS using email for patches when there are so much better ways of doing development with git? The Linux Foundation could selfhost a fucking GitLab instance and even in the event of GitLab going down the route of enshittification or closed-source they could reasonably take over the maintenance of a fork.
I get that the Linux folks want to stay on email to gatekeep themselves from, let's be clear, utter morons who spam on any Github PR/issue they can find. But at the same time it makes finding new people to replace those who will literally die out in the next decade or two so much harder.
This is not about spam, server management or GitLab/Gitea/whatever issue. This is catering to most diverse work methods, and removing bottlenecks and failure points from the pipeline. GitLab is down, everybody is blocked. Your mail provider is failing? It'll be up in 5 minutes tops, or your disk is full probably, go handle it yourself.
So Occam's razor outlaws all the complex explanations for mail based patch management. The answer is concise in my head:
> Mailing list is a great archive, it's infinitely simpler and way more robust than a single server, and keeps things neatly decentralized, and as designed.
This is a wind we can't control, I for one, am not looking and kernel devs and say "What a bunch of laggard luddites. They still use e-mail for patch management". On the contrary, I applaud them for making this run for this many years, this smoothly. Also, is it something different what I'm used to? Great! I'll learn something new. It's always good to learn something new.
Because, at the end of the day, all complex systems evolve from much simpler ones, over time. The opposite is impossible.
Well until you deal with email deliverability issues, which are staggeringly widespread and random. Email were great to send quick patches between friends like you'd exchange a USB key for a group project. For a project the size of Linux? It doesn't scale at all. There is a reason why Google, Meta, Red Hat, and [insert any tech company here] doesn't collaborate by sending patches via email.
mail-based patch management is fine for smaller projects, but Linux kernel is too big by now.. it sure is amazing how they seem to make it work despite their scale, but it's kinda obvious by now, that some patches can go unnoticed, unprioritized, unassigned, ...
and open source is all about getting as many developers as possible to contribute to the development. if I contribute something and wait months to get it reviewed, it will deter me from contributing anything more, and I don't care what's the reason behind it. the same goes for if I contribute something and receive an argument between two or more reviewers whether it's the right direction or not and there's no argumentative answer from a supervisor of the project and this situation goes on for months...
[citation needed]
It's what "open source" enables, but it may not necessarily be a desired goal of a FLOSS project.
It's not really enough to state your case. You have to do the work.
On the surface, the kernel developers are productive enough. Feel free to do shadow work for a maintainer and keep your patch stack in Gitlab. It it can be shown the be more effective, lots of maintainers are going to be interested. It's not like they all work the same way!
They just have a least common denominator which is store-and-forward patch transport in standard git email format.
Everyone still has at least the base branch they're working on and their working branch on their machine, that's the beauty of working with Git. Even if someone decides to pull a ragequit and perma-wipe the server, when all the developers push their branches, the work is restored. And issues can be backed up.
> Also, is it something different what I'm used to? Great! I'll learn something new.
The thing is, it's harder and more difficult in a time that better solutions exist. Routinely, kernel developers complain about being overworked and onboarding of new developers to be lacking... one part of the cause certainly is that the Linux kernel is a massive piece of technology, and another one that the social conventions of the Linux kernel are very difficult, but the tooling is also very important - Ballmer had a point with "developers developers developers".
People work with highly modern tools in their day jobs, and then they see the state of Linux kernel tooling, and they say "WTF I'm not putting up with that if I'm not getting paid for it".
Or to use a better comparison... everyone is driving on the highway in the same speed, but one car decides to slow down, so everyone else overtakes it. The perpetual difficulties of many open source projects to accomodate changing times and trends - partially because a lot of small FOSS is written by people for their individual usage! - are IMHO one of the reasons why there is so much chaos in the FOSS world and many private users rather go for the commercial option.
...which doesn't matter at all.
The people in charge decided on their preferred ways of communication. You may believe that there are better ways out there, and I may even agree with you, but ultimately it's completely irrelevant. People responsible decided that this is what works for them and, to be honest, they don't even owe you an explanation. You're being asked to collaborate in this specific way and if you're unable to do it, it's on you. If you want to change it, work your way to become a person who decides on this stuff in the project, or convince the people already responsible. Notice how neither of those are technical tasks and that they don't depend on technical superiority of your proposed methods either.
If you approach it from the viewpoint that you have the solution and they are Luddites, you will influence no one and have no effect.
You are missing one point, namely that email is probably the only communication medium that's truly decentralized. I mean, on most email providers you can export your mailboxes and go to someone else. You can have a variety of email clients and ways to back up your mailboxes. No git clone, no specific mailbox or server is in any way special, I think Linus emphasized recently that they made efforts to ensure kernel.org itself is not special in any way.
Yes, I find Github's or Gitlab's UI, even with all enshittification by Microsoft and whatnot, better for doing code reviews than sight-reading patches in emails. And yet I cannot unsee a potential danger that choosing a service — any service! — to host kernel development would make it The Service, and make any migration way harder to do than what you have with email. Knowing life, I'd say pretty confidently that an outcome would be that there would be both mailing lists and The Service, both mandatory, with both sides grumbling about undue burdens.
Have you ever been in a project which had to migrate from, say, Atlassian's stack to Github, or from Github to Gitlab, or vice versa? Heck, from SourceForge + CVS/SVN to Github or similar? Those were usually grand endeavors for projects of medium size and up. Migrate all users, all issues, all PRs, all labels, test it all, and you still have to write code while it all is happening. Lots of back-and-forth about preserving some information which resists migration and deciding whether to just let it burn or spend time massaging it into a way the new system will accept it. Burnout pretty much guaranteed, even if everyone is cooperating and there is necessity.
But you could probably build tools on top of email to make your work more pleasant. The whippersnappers who like newer ways might like to run them.
They're not micro kernel! They're not TDD! They're not C++! They're not CVS! Not SVN! Not SCRUM! Not Gitlab!
Yet the project marches on, with a nebulous vision of doing a really useful kernel for everyone. Had they latched on any of the armchain expert criticism of how they're doing it wrong all these years we wouldn't be here.
The question is - how long will it march on? The lack of new developers for Linux has been a consistent topic for years now. Linus himself isn't getting younger, and the same goes for Greg KH, Ted Ts'o and other influential leads.
When the status quo scares off too many potential newcomers, eventually the project will either wither or too inexperienced people drive the project against a wall.
Why would he need to, he's already a young whippersnapper.
For the last few years, I've been saying the following regularly (to friends, family and coworkers): communication is the hardest thing humans will ever do. Period.
Going to the moon, launching rockets, building that amazing app... the hardest thing of all is communicating with other people to get it done.
As a founder (for 40+ years and counting) I manage a lot of different type of people and communication failures are the largest common thread.
Humans have a very, very tough time assuming the point of view of another. That is the root of terrible communication, but assumptions are right up there as a big second.
On the Marcan thing... I just want to say, control what you can and forget the rest (yes, this is direct from stoicism). Users boldly asking for features and not being grateful? Just ignore them. Getting your ego wrapped up in these requests (because that's what it is, even if he doesn't want to admit it), is folly.
I contributed to Marcan for more than a year. I was sad to see the way it ended. I wish him well.
That's very true. I recommend some people to read "The Four Agreements", because that thin book has real potential to improve people's lives through active and passive communication.
Spoiler, but approximately 66% of the adult population make do without being able to maintain their own perspective independently of what their social circle tells them it is. I imagine that would make it extremely challenging to determine what someone else's perspective is. Especially if that perspective is being formed based on empiricism rather than social signalling.
And if we're making book recommendations, Non-Violent Communication is a gem of an idea.
[0] https://medium.com/@NataliMorad/how-to-be-an-adult-kegans-th...
stoics don't write multi-paragraph goodbye letters
Why you felt the need to add your comment, is a more apt question.
Eh, not really - "multi-paragraph goodbye letters" here refers to the overly dramatic fad that internet denizens sometimes engage in when they leave communities, and they tend to have a lot of whining.
Those types of goodbye letters are not the types of goodbye letters stoics would write.
> Why you felt the need to add your comment, is a more apt question.
If you were able to pick up so swiftly what the person I replied to was implying, you too should be able to have picked up that I replied because I disagreed with that implication.
The alpha male stoic carricutures, maybe. Real world stoics have not been above those.
>you too should be able to have picked up that I replied because I disagreed with that implication.
You could then just say that you disagree and state your case, without rudely asking why they posted it.
I doubt this, but would be curious to see a source.
> You could then just say that you disagree and state your case, without rudely asking why they posted it.
I didn't find it rude at all, and your reply was far less productive than my IMO neutral question. You took offense on behalf of someone else and inserted yourself when it was unnecessary and entirely reliant on your interpretation and perception. Now we're discussing your perceived slight instead of anything of substance.
Marcus Aurelius wrote extensive personal reflections in his "Meditations". Seneca wrote detailed letters to friends and family discussing philosophy, life, and death. Epictetus discussed death extensively in his Discourses, but sure, they were philosophical teachings rather than personal goodbyes.
They focus on acceptance and equanimity rather than formal farewells.
That said, "control what you can and forget the rest" is indeed stoicism, albeit simplified.
Asahi Linux is similar, given how hostile and undocumented Apple Silicon is, but it has a great amount of expectations of feature completeness and additional bureaucracy for code changes that really destroys the free-wheeling hacker spirit.
What I found is being able have this "afterburner mode" alongside "advanced communications" capabilities gives the real edge in real life. So, this is why I wish he can build his soft skills.
These skills occupy different slots. You don't have to sacrifice one for the other.
The BSDs. You can fork a BSD. Maybe he could try to mainline into the BSD, but would probably face a similar battle with the BSDs. Right, one again, the benefit mainlining into linux, and there is some (maybe limited) support to include Rust, is you can narrow your scope. You don't need to worry as much about some things because they will just sorta work, I am thinking like upper layers of the kernel. You have a CPU scheduler and some subsystems that, may not be as optimized for the hardware, but at least it is something and you can focus on other things before coming around to the CPU scheduler. You can fork a BSD, but most would probably consider it a hard fork. I also don't think any of the BSDs have developers who are that interested in brining in Rust. Some people have mentioned it, but as far as I know, nothing is in the works to mainline any kind of Rust support in the BSD kernels. So he would probably meet similar resistance if he tried to work with FreeBSD. OpenBSD isn't really open to Rust at all.
If Rust is the point you get up from the bed in the morning, why don't you focus on Redox and make it the new Linux? Redox today is much more than Linux was in 1991 so it's not like you would be starting from scratch.
You're probably not as good as Linus in, well, anything related to this field really. The only way to find out whether you actually are is to do the work. Note that also he spent a lot of time whining to people who were perceived as the powerful in the field. But in addition to whining he went and did the work and proved those people wrong.
Mind you, I'm a PHP developer by day, so this Rust-vs-C debate and memory management stuff is not something I've had experience with personally, but the "Rust is magical" section towards the bottom seems like a good summary of why the developer chose to use Rust.
Discussion at the time: https://news.ycombinator.com/item?id=33789940
I personally fall a little more on the side of the Linux kernel C devs. Inter-oping languages and such does bring in a lot of complications. And the burden is on the Rust devs to prove it out over the long haul. And yes, that is an uphill battle, and it isn't the first time. Tons of organizations go through these pains. Being someone who works in a .NET shop, transitioning from .NET Framework to .NET core slowly is an uphill battle. And that's technically not even a language change!
But I do agree, Redox would probably less friction and a better route if you want to get into OS dev on an already existing project and be able to go "balls to the walls" with Rust. But you also run into, Redox just has a lot less of everything. That is just because it's a small project.
«Undocumented» – yes, but «hostile» is an emotionally charged term that elicits a strong negative reaction; more significantly, though, it constitutes a flagrant misrepresentation of the veritable truth as stipulated within the resignation letter itself:
Which is consistent with marcan's multiple previous blog posts and comments on here. Porting Linux (as well as NetBSD, OpenBSD) onto Apple Silicon has been no different from porting Linux/*BSD onto SPARC, MIPS, HP-PA and other platforms.Also, if you had a chance to reverse-engineer a closed source system, you would have known that «hostile» has a very specific meaning in such a context as it refers to a system that has been designed to resist the reverse-engineering attempts. No such resistance has been observed on the Apple Silion computing contraptions.
I think they even left a "direct boot from image" (or something similar) mode as a small door to allow Asahi Linux development, if not to accelerate a little bit without affecting their own roadmap. Even Hector tweeted about it himself!
Right - but it kinda sounds like he's facing headwinds in a lot of different directions.
Headwinds from Apple, who are indifferent to the project, stingy with documentation, and not inclined to reduce their own rate of change.
Headwinds from users, because of the stripped down experience.
Headwinds from the kernel team, who are in the unenviable situation of having to accept and maintain code they can't test for hardware they don't own; and who apparently have some sort of schism over rust support?
Be a heck of a lot easier if at least one of them was on your side.
It took them a while to, but they finally offer boards based on AMD chips.
I don't need an upgrade now, but I feel a RISC-V framework is feasible once I do.
Many ARM SOC are designed to run on battery only so the wireless packages and low power states are better, my AMD couldn't go below 400mhz.
But yeah the "Apple M hardware is miles and leagues away" hypetrain was just a hypetrain. Impressive and genuinely great but not revolutionary, at best incremental.
I hope to be able to run ARM on an unlocked laptop soon. I run a Chromebook as extra laptop with a MediaTek 520 chip and it's got 2 days battery life, AMD isn't quite there yet.
It's more nuanced than that. Apple effectively pulled a "Sony A7-III" move. Released something one generation ahead before everybody else, and disrupted everyone.
Sony called "A7-III" entry level mirrorless, but it had much more features even when compared to the higher-end SLRs of the era, and effectively pulled every other camera on the market one level down.
I don't think even they thought they'd keep that gap forever. I personally didn't think it either, but when it was released, it was leaps and bounds ahead, and forced other manufacturers to do the same to stay relevant.
They pulled everyone upwards, and now they continue their move. If not this, they also showed that computers can be miniaturized much more. Intel N100 and RaspberryPi/OrangePi 5 provides so much performance for daily tasks, so unimaginable things at that size are considered normal now.
It's just another "Apple integrating well" story.
Their SoC is huge compared to competitors because Apple doesn't have to make a profit selling a SoC, they profit selling a device + services so they can splurge on the SoC, splurging on the SoC plus being one node ahead is just "being good", the team implementing Rosetta are the real wizards doing "revolutionary cool shit" if anything
...plus, they have a whole CPU/GPU design company as a department inside Apple.
Not dissimilar to Sony:
Sony Imaging (camera division) designed a new sensor with the new capabilities of Sony Semiconductor (fab), and used their exclusivity to launch a new camera built on top of that new sensor. Plus, we shall not forget that Sony is an audiovisual integration powerhouse. They one of the very few companies which can design their DSPs, accompanying algorithms, software on top of it, and integrate to a single product they manufacture themselves. They're on par with Apple's integration chops, if not better (Sony can also horizontally integrate from Venice II to Bravia or Mics to Hi-Fi systems, incl. everything in between).
The gap also didn't survive in Sony's case (and that's good). Nikon and Fuji uses Sony's sensor fabs to use their capabilities and co-design sensors with the fab side.
Canon had to launch R series, upscale their sensor manufacturing chops. Just because Sony "integrated well" when looked from your perspective.
Sony is also not selling you the sensor. It's selling you the integrated package. From sensor to color accuracy to connectivity to reliability and service. A7-III has an integrated WiFi and FTP client to transfer photos. A9 adds an Ethernet jack for faster transfers. Again, integration within and between ecosystems.
Compared to the incremental changes we've seen the previous 10 years before it arrived on AMD/Intel space, it was revolutionary.
What they did doesn't matter. Even if they merely took an intel laptop chip and stuck a chewing gum on it, the result was evolutionary.
So much so, that it put a fire under Intel's ass, and mobilized the whole industry to compete. For years after it came out the goal was to copy it and beat it.
What did you expect to call "revolutionary"? Some novel architecture that uses ternary logic? Quantum chips?
That is part of the challenge he chose to take on.
> Headwinds from users, because of the stripped down experience.
Users can be ignored. How much you get users to you is your own choice.
> Headwinds from the kernel team, who are in the unenviable situation of having to accept and maintain code they can't test for hardware they don't own
You don't have to upstream. Again, it's not the kernel team that chose to add support for "hostile" hardware so don't try to make this their problem.
> and who apparently have some sort of schism over rust support?
Resistance when trying to push an entirely different language into an established project is entirely expected. The maintainers in question did not ask for people to add Rust to the kernel. They have no obligation to be welcoming to it.
> Be a heck of a lot easier if at least one of them was on your side.
Except for the users all the conflicts are the direct result from the choice of work. And the users are something you have to choose to listen to as well.
Their boss, however, did ask for it, so yes, they do have an obligation to be welcoming to it.
"did ask for it" - did he? Because from my perspective it looks more like he gave the bone for corporations so they will shut up for rust in kernel. After some time it will end up "Sorry but rust did not have enough support - maintainers left and there were issues with language - well back to C"
I addressed your second point here: https://news.ycombinator.com/item?id=43075508
With all the drama, I wouldn't be the least surprised if he soon withdraws that provisional acceptance.
> "A lot of people actually think we're somewhat too risk averse," said Torvalds. "So when it comes to Rust, it's been discussed for multiple years by now. It's getting to the point where real soon now, we will actually have it merged in the kernel. Maybe next release."…
> "Before the Rust people get all excited," the Linux kernel creator and chief said. "Right? You know who you are. To me, it's a trial run, right? We want to have [Rust's] memory safety. So there are real technical reasons why Rust is a good idea in the kernel…”
> “And hopefully, it works out, and people have been working on it a lot, so I really hope it works out…”
https://www.theregister.com/2022/06/23/linus_torvalds_rust_l...
Last September he was still insisting he thinks the project will not fail, and he was not exactly subtle in his criticism of maintainers who refuse to engage with it in good faith.
> "Clearly, there are people who just don't like the notion of Rust, and having Rust encroach on their area.
> "People have even been talking about the Rust integration being a failure … We've been doing this for a couple of years now so it's way too early to even say that, but I also think that even if it were to become a failure – and I don't think it will – that's how you learn," he said.
> "So I see the whole Rust thing as positive, even if the arguments are not necessarily always [so]."…
> With impressive diplomacy, considering his outbursts of years past, Torvalds went on, "There's a lot of people who are used to the C model, and they don't necessarily like the differences... and that's ok.
https://www.theregister.com/2024/09/19/torvalds_talks_rust_i...
But yeah, I still don't think it's all that inaccurate: He may not have wanted it to fail, and still not think it's a technical failure... But socially? Still seems possible he'd be starting to think that while the Rust language per se is a technical success, all the drama surrounding the integration of it into Linux means that that is turning out to be a social failure.
(Or maybe I'm just projecting because that is what it looks like to me.)
I just wanted to also add that users will be users. Once its out, there will be endless posts about "why X" and "why not Y". No matter what you do, lots of people are going to be displeased. Its just the way things go. I hope he will want to pick it up again after some time.
Selling ads? Using it as a gateway to a commercial product? Selling support? Have some genius business plan that allows you to make money in the future? Fine, give it away no strings attached but expecting that users will be grateful is a mistake developers keep repeating. The free users are just as entitled, even more entitled as they don’t have a price tag for your efforts and don’t have a document specifying what are your obligations so they can assume scope of entitlements anyway they wish.
Since you gave it for free, you can’t refund an unhappy customers to make it go away. If it looks like a product, You will be stuck with people who think they did their part by using your products and you failed them. Some may make it a full time job to take a revenge on this injustice.
I’m not even sure that these users are at fault, you actually took something in exchange(like fame, street cred etc) and you are not delivering your part.
People become vocal when they are pissed.
> we brought the platform from nothing to one of the smoothest Linux experiences you can get on a laptop.
Despite the accomplishment this overselling irks me.
I say that also because I have been gotten quite a few responses from people that I should use asahi, while looking at what it supports it definitely would not make sense for me, and you cannot just present it to a macos alternative right now.
25 years ago (huh, long time), when Windows ME pissed me off for good, linux wasn't exactly known for being a daily driver but I gave it a try and, unsurprisingly, it did become reliable over the years. Other than Gnome's propensity to make stupid changes to default settings I can't remember the last time I had to even think about messing with the underlying system and other than a simple google search on the linux compatibility of hardware before I buy I just don't think about it. Actually, I take that back, when I first got my current laptop I was messing around to get the AMD mesa drivers (or whatever) working because I wanted to mess around with this fancy GPGPU thing.
Personally, if I were to buy a macbook it would be for the OS and not dodgy linux support because I've walked that road before. If the Christmas sales were just a tiny bit better though...
Imo modern linux experience is much better than the situation you describe, at least as long as you use certain type of hardware. In the past it was definitely harder. But wrt asahi, I want the "luxury" of using an external monitor with my 13" macbook air, and sadly, while in the past x86 machines I put linux I would put some effort and get AMD mesa drivers to work, I cannot do that here. I respect the effort put in the asahi project, but calling it suitable for a daily driver is misleading, unless you specify exactly what sort of daily driver you mean. Stuff like using an external monitor is pretty basic in my book of daily usage.
In hindsight.
> [Linux] did become reliable over the years.
Might have gone the other way. And if it had, nobody would be surprised at that either, now.
Oh no. I'm convinced majority of burnouts are almost entirely caused by dealing with shitty people and/or shitty processes.
Shitty processes sometimes happen without shitty people, the people involved just let it happen.
Or: he shouldn't steal people's time with false advertising :shrug:
Also if he wants to create an operating system, then these aren't even requests, but bug reports. So the users ate his false advertising, spent time to try out his system, then spent some more time to file bug reports, and then he calls them "entitled users".
I can't imagine then what's his problem. I don't get offended by people that can't even read. I don't normally call them people let alone entitled :\ Set up a bot that links them the device support page, and problem solved? I don't get it
I think that might be the problem.
It's comments like these that causes people to wear out.
No it isn't. You - fundamentally - don't get to control what people say to you. You need to filter how to take that. And that's incredibly hard. Especially in open source. You need to both be able to ignore (some version of "idiots, who can't be bothered to read") and be openminded enough to take weird requests, because they could be the starting point of a new major contributor. The second is optional, as long as you are happy just doing your thing, but then the former probably won't become a problem for you.
>You need to both be able to ignore
> and be openminded enough to ...
I'm know it's pretty pointless to argue because we see the world in a different way. But realize the (quoted) requirements are you putting on the open source developer.
A developer without these skills will burn out.
> A developer without these skills will burn out.
And I think that's something that should be said more directly. If you want to do open source (as in become the provider of load bearing infrastructure): Then you really need to realise what you are getting yourself into. Would I like that to be different? Sure. Would I bet on that changing? Absolutely not.
And yes, that absolutely means you can either do open source as a hobby, then nobody should ever be willing to rely on the thing you are building (because you can just say "i've got better things to do than fixing the security bug you got") or you can attempt to get other people to use and rely on it, but then you have to find a way not to burn out.
You don't get negative feedback if you don't open communications channels for that.
This some next level philosophy pondering, thanks.
It’s called a Code of Conduct. It exists and is in use by many organisations, including several open-source projects.
Wasn’t always like this, I think. Personally have seen the same with other projects and dealing with proprietary Apple APIs and their walled in garden is hard enough.
> “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS”
These are not even requests. These are objective statements he can either take note of for prioritisation or ignore. I can also say Asahi is useless to me until usb-c monitors support, but that's just my situation - there's no bad faith or request here. Previously that was the same for WiFi support.
I wish there was some good model for maintainers of bigger projects to deal with this on a personal level. The bigger the project, the more people there will be with unmet requirements and that's just life. It literally can't be solved.
I think the best way to deal with this is to just confidently say what you are and are not ready to get done. The social dynamic will always be this way, so we may as well take whatever criticism is useful, leave the rest behind, and move on.
Actually if this distro is my primary / only one I would like to be able to check CPU, GPU, etc. temperature. It is important to know if cooling is adequate or requires cleaning / repair.
In any case Marcan would be way better off having thick skin. Users will always be assholes (well same is generally true about vendors).
"Heavily under development and not ready for prime time use" should have been first line in readme and only reply to such feature request.
So it sounds like they bit more than they could chew.
what if after Linux and Git, Linus came up with his own memory safe language suited for kernel development?
Second, what’s the drama? I read the blog, and I’m guessing that on top of being burned out, which sucks, Marcan didn’t like a kernel developer using the phrase “we are the thin blue line” implies he’s politically liberal, in the US sense. He then says he may have been toxic on Mastodon, which might have got him secretly canceled?
All that said, I found his assessment of downstream v. upstream economics (if you can’t successfully upstream you’re doomed to rebase off a massive patch list) pretty interesting. I think the way it is now is the only way that’s good for users — if downstream forks could somehow maintain viability longer term, we would be splitting, e.g. security budgets, performance budgets, etc. I get that it sucks for a group working to upstream, and I am in no way shocked to hear personal politics plays some role in success upstreaming — open source is largely a personal / social capital economy - I guess all that said, hopefully the new Asahi maintainers can work well across what seems like ideology bounds. Maybe?
Marcan watched it unfold on the mailing list wanted Linus to step in and force the C dev to play nice. Since nothing happened, he went to social media and lashed out as a last resort. That's when Linus finally chimed in and pretty much said "you might be right, but this isn't the way to handle things".
He didn't want any Rust code at all touching his turf. He outright NACKed without any technical reason and refused any negotiations with the Rust team that any Rust build fails due to C code breaking changes would be their entire responsibility.
> This led to the C dev saying that while he likes Rust, he believes multi-language codebases are cancer and would stonewall all Rust code that touches his code.
I believe that was an attempt of damage control to save face and he actually meant to call Rust "cancer".
From what I saw on urbandictionary, it seems more likely to be something cops in high crime areas in the UK say.
Apparently it's political in the US, I have no idea, but as I understand it the maintainer just means 'I am here reviewing the change to keep the kernel in good order'.
It’s a poor choice of words for such (relatively) public communication.
I don't know his full biography, seems to be Chinese born and went to MIT, but he signs off 'Cheers', I think it's a reasonable possibility that he doesn't mean whatever politically charged US meaning it has by it.
It is not "at least some" and this isn't something to downplay.
You're, with your US perspective, saying 'hey words have meaning you know, don't downplay murdering homosexuals' while millions^ of people smoke fags in the UK every day.
(^probably? Maybe not any more, a lot of fag-smoking relative to murder at any rate.)
marcan had indicated donations are down, and it's hard to support ones livelihood just from donations alone - especially when they are down.
https://lore.kernel.org/rust-for-linux/c5a49bcb-45cf-4295-80...
And I've been watching from the sidelines, waiting for Asahi Linux to become "stable" enough to consider buying a Macbook and putting Asahi Linux on it.
But then marcan told his supportes to fuck off unless they commit to supporting his political ideas, which I was not willing to do.
I guess this comment will be seen as abuse from the HN crowd. Oh well...
As someone not in the know, would you mind elaborating.
Now, if you want me to explain what political ideas those were: I don't care. Whatever they are, I don't want to support it, even if I have those same ideas. Yes, I do think that open source communities should move away from the politics.
Out of curiosity what are his political views? It has been mentioned a couple of times here already and it seems to be part of the story.
Is this about Marcan’s outspoken support for transgender people? If so, why not simply say that in your comment, rather than framing it in such vague terms?
Surely you see why this is, actually, directly relevant and important context for your statement. It’s not some general political leaning you’re talking about - lumping this (prejudice against a minority group) into the same category as something like banal disagreements over taxation policy amounts to deliberately obscuring what you’re saying behind innuendo.
If you’ve got something to say about his political views in a public forum like this, at least do the people around you the courtesy of being upfront about what you’re actually saying.
I support the freedom of people chosing their sex or gender. At the same time, I'm not willing to fight their wars. And if they force me to go to war, then I pass.
If the group in question were gay people, or a racial minority, would you still treat the issue this way?
I think anyone working in serious open source projects just need to learn to ignore those users. I definitely would have the attitude of "I'm perfectly fine if no one uses my product" and have a lot of fun banning entitled users left and right.
It’s why things like CentOS being abandoned, terraform licensing, et. al. never bothered me. I’m not paying them, so :shrug:.
But again, maybe they can hire someone like me, whose sole job is to block the very worst entitled users.
Talk is cheap, send patches.
https://x.com/FFmpeg/status/1762805900035686805
I see a lot of FOSS maintainers continue to engage and defend themselves against people who have demonstrated themselves as unwilling to contribute in any way, yet expecting that free work be done for them. I wish more open source devs will keep in mind that FOSS work is a gift they're sending out into the world, and it's a common good that anyone can contribute to. That is not to say ignore all criticism or user requests, just that you hold absolutely no responsibility to placate emotionally draining people - the project is just as much their responsibility as yours.
I don't agree with Linus all the time (mostly because I don't have the technical knowledge to agree with), but I 100% agree to his attitude. I hope other large FOSS project maintainers have the same mindset.
Definitely a shame. I wonder if it would be in Apple's interests to actively support Linux on Mac. It would make Macs more attractive as developer machines, and I don't see how it would disadvantage them.
Trust me, we would know by now if it was. It's not.
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.
The only development they want is development inside XCode. Anything else is a hard no.
Define "a lot" and we can get closer to a common understanding.
Do the demigods of the Linux kernel - Linus and the core maintainers - personally want the kind of code Asahi is developing to be merged into the kernel? The author writes as if part of his drive was that Linus himself showed enthusiasm for getting Linux on Apple Silicon.
If there is interest in the work Asahi has done, then the Linux team needs to describe what they see as the gap between today's code quality and support model and what they want to see before upstreaming.
It sounds like the Linux team has been wishy-washy and needs to draw a line in the sand on their needs rather than handwaving about being part of the "community".
It would be fair to say "we don't like your attitude or trust you to work with us kindly over the years and don't want to deal with you", if that's the case. Just don't dance around it.
It sounds like you agree with me though. The Linux team needs to clearly define the expectation they have for code maintenance from the team trying to upstream Rust code (edit) and the Asahi team needs to acknowledge how/if they can meet those expectations.
The challenge is not dictating from high above some criteria; the challenge is discovering the criteria that will let the Linux project continue development as well as can be arranged. This is why you'll hear Linus say it's a learning experience, and not just make proclamation of how things shall be (at this stage).
Would you say that the Asahi team wasn't receptive to the pace at which the needed criteria were being developed?
My point is that between these two groups there seems to be a misunderstanding of expectations. And being the upstream org, and not having read every mailing list thread, I would expect the kernel team to have built a framework for accepting this kind of code. Or a framework for building the framework.
It sounds like the implicit answer to "Does Linux want Asahi contributions" is "low priority". Which is fine if that's communicated.
I sense you have been involved in these discussions already and have a strong opinion about the specifics of this topic. I don't mean that in a bad way.
I have very little personal interest in Asahi, I am not really part of that "conversation", but I dislike outsiders coming in and expecting to dictate how something that predates them should work. Everyone is entitled to their opinion, but that doesn't mean anyone else has to listen to it. If you want to understand, read linux-kernel the mailing list and watch people like Al Viro work (Minimum realistic time allotment: multiple months).
Perhaps the author jumped to conclusions after Linus himself started using Asahi Linux on his own laptop for Linux kernel development[0]. Note the praise for the Asahi team in the commit message.
[0]: https://news.ycombinator.com/item?id=32311150
Loved following his various social feeds. I was sad when he stepped away from the fediverse. I hope he comes back as just a regular hacker without this massive weight on his back.
I don't believe in the Linux project since a few years now, especially as "the bearded ones" are not interested in moving the project to a certain future, but only jerking on their old own code.
Good luck for the futur Hector, and thanks for what you managed to do until now with your team.
I personally lost my confidence in it when they stopped properly triaging security issues and flooded everyone interested with just noise.
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 merits, only to come back a year later when whatever company they work for suddenly sees it as important.
Project leads who will shift goalposts to avoid confronting the clear hostility their deputies show.
I’ve had OSS users call me personal number, or harass me over email for not having their pet interest prioritized over everything else. Often that’s because I’m blocked by the maintainers.
Open source can be extremely brutal and it’s a battle of stamina and politics as much as it’s one of technical merit.
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.
With proprietary software you usually have a corporate mandate, a goal etc to achieve. Any new tech is achieved as part of that drive. You can get people on board or not based on that, and once you’ve decided, there is someone to answer to if you can’t deliver.
Open source doesn’t have that. A project can go in twenty different directions at once, you can say you all agree to something and then have people sabotage it without being answerable to anyone.
Does that make open source worse? No. It’s the trade off for being open, which is extremely valuable but it is a very different push in terms of a product.
So leading well known open source project is politics on a small scale and there will be a lot of people who want to hurt or manipulate you.
If you decide to become a public person and want to have fans and supporters then be ready to have haters as well.