Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

351–360 of 1001 posts

Re: Resigning as Asahi Linux project lead

#351

A few questions. First, maybe Linux just is bound to always be a C only project. Linus Torvalds infamously dislikes C++, its sorta odd he didn't shut down Rust for Linux in the first place. Redox is on its way... Second, there are multiple types of compensation. I think the author was probably looking to be compensated in validation from others. Maybe if Linus Torvalds, replied to his email the author would be more i…

Why does disliking C++ make it odd that he is open to Rust? C++ is uniquely bad; disliking it doesn’t necessarily mean you only like C.

At this point you have a community of maintainers who expect it to remain a C project.

Which is very logical. If you add Rust, why not Zig, Nim, and every other low level language?

Re: Resigning as Asahi Linux project lead

#352

Earlier quoted context omitted.

[Putting my dusty Linux Distro Maintainer Hat on] 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…

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…

This. So very much this. If you burn bridges and then need them later, yeah, things are going to be hard.

Re: Resigning as Asahi Linux project lead

#353

A few questions. First, maybe Linux just is bound to always be a C only project. Linus Torvalds infamously dislikes C++, its sorta odd he didn't shut down Rust for Linux in the first place. Redox is on its way... Second, there are multiple types of compensation. I think the author was probably looking to be compensated in validation from others. Maybe if Linus Torvalds, replied to his email the author would be more i…

> Would be cool if Qualcomm hired Marcan

Marcan had a whole rant[0] in the thread that started all of this about kernel people being payed by corporations instead of being freelance like him. I'm not sure he wants to work for a corporation.

[0] https://lore.kernel.org/lkml/c5a49bcb-45cf-4295-80e0-c4b0708...

Re: Resigning as Asahi Linux project lead

#354

Earlier quoted context omitted.

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

As long as you compile with the version specified (e.g., `-std=c11`) I think backwards compatibility should be 100%. I've been able to compile codebases that are decades old with modern compilers with this.

In practice, C has a couple of significant pitfalls that I've read about.

First is if you compile with `-Werror -Wall` or similar; new compiler diagnostics can result in a build failing. That's easy enough to work around.

Second, nearly any decent-sized C program has undefined behavior, and new compilers may change their handling of undefined behavior. (E.g., they may add new optimizations that detect and exploit undefined behavior that was previously benign.) See, e.g., this post by cryptologist Daniel J. Bernstein: https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8...

Re: Resigning as Asahi Linux project lead

#355
post #93

Marcan links to an email by Ted Tso'o ( https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed... ) that is interesting to read. Although it starts on a polarising note ("thin blue line"), it does a good job of explaining the difficulties that Linux maintainers face and why they make the choices they do. It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining…

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

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

Re: Resigning as Asahi Linux project lead

#356

Earlier quoted context omitted.

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

> But then marcan told his supportes to f* off unless they commit to supporting his political ideas As someone not in the know, would you mind elaborating.

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.

Re: Resigning as Asahi Linux project lead

#357
post #199

Earlier quoted context omitted.

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

Your charitable reading is too charitable. One of the benefits of using types to help guarantee properties of programs (e.g. invariants) is that types do not get out of sync with the code, because they are part of the code, unlike documentation. The language implementation (e.g. the compiler) automatically checks that the types continue to match the rest of the code, in order to catch problems as early as possible.

Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + operator to be defined. So if your interface only accepts numbers it is unnecessarily restrictive.

Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work.

Re: Resigning as Asahi Linux project lead

#358

Earlier quoted context omitted.

This is a rude comment that isn't downvoted because of hive mind effects. Not biting.

You’re not biting because it’s true. 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.

Re: Resigning as Asahi Linux project lead

#359
This was a heartbreaking and terrible read. I've been feeling a bit of disillusionment about linux quite a bit lately, mostly due to bad/weird decisions being made at the distribution level. Reading this extends that disillusionment down to the kernel level.

The problems cited are portrayed as sociological problems, but I really wish people could recognize that all of them can be mitigated, either substantially or entirely, with a single purely-technical solution: microkernels.

* Almost nobody needs to upstream code to the kernel

* Trusted codebase size becomes negligibly small

* Maintenance burden for drivers, subsystems, etc., falls on the users of the subsystems affected, and not the entire community

* Broad language compatibility by service interface instead of ABI compatibility. The need for a singular compiler is reduced in scope down to the size of the subsystem instead of the entire ecosystem.

The biggest problem that can't be solved purely technically is the entitled user problem, but even that is partially solved. This is because the barrier to contribution is substantially lower:

* I can write code in Rust, but I don't know C.

* I can easily write simple drivers for some hardware features like battery managers and fan controllers and temperature sensors, but I don't know anything about kernels.

* I have a lower, but non-zero understanding of security, and would not feel comfortable writing code that runs on ring 0, but wouldn't feel inhibited writing code that benefits from process isolation.

Those attributes about myself inherently mean that for a microkernel OS, I can be a contributor, but for Linux, the best I can be is an entitled user.

Re: Resigning as Asahi Linux project lead

#360

Earlier quoted context omitted.

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…

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

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.

Post reply on HN