Hector Martin / Héctor Martín Cantero / @marcan42 / マルカン / @marcan42x / @marcan@treehouse.systems / Asahi Lina / Asahi Linux - Developer of Asahi Linux with a VTuber persona. Made Byuu's death unbelievable. Constantly accuses others of harassment and abuse. Hates Hacker News and Kiwi Farms.

[Ducks Sorted in a Row]

If you're contributing code with 0-days in them then that is a skill issue

Not always. Memory vulnerabilities can occur as the result of moving things around and in an environment with a lot of moving parts they're pretty much unavoidable. Even John Carmack ran the RAGE codebase (a game for which Microsoft wrote to congratulate him on having the lowest crash rate of any game on the 360 at the time) through some static analyzers and they found a myriad memory issues. Simply writing off things that could compromise 90% of the servers in the world as something only retards do is a bad idea.

embedded Rust isn't memory safe

Are you referring to the `unsafe` keyword? If so, then yes, it sucks, but you can use it to cordon off all your unsafe code that interacts with the hardware itself (because you don't have a choice), but it can be encapsulated and audited the same way you do C code, and the rest of the system around it can be memory safe. If not, then I have no idea what you're talking about.

C++11

C++ in the kernel would be an unmitigated disaster without some very strict rules. And honestly, I agree with Linus' assessment of it.

Honestly if I were to pick any nu-language to integrate into the kernel it'd have to be Zig (caveat: once it gets standardized), I've drank all the koolaid on that one and more - it's a lot more memory-safe than C but without any of the horrible trappings of C++ or Rust, not the least of which is the autistic insistence on the backwards object model that necessitates RAII.

 

[The Real Slim Shady]

He had ONE job. Just get upstream Linux support into M1. Get hardware working and shut up and submit patches.

For all his bitching and moaning, all he's listed is as A maintainer of a single soundcard driver for ARM/APPLE support? Huh.

Speaking of which did he fix that overheating issue? Apple has full control of hardware and software, so they were overdriving the speakers to get them loud as fuck (they do this with all their devices, compare how loud iPhone can be vs some flagship Android phone), and then they monitor the speaker temperature and turn down the volume if they get too hot. The hardware will burn the speakers if there isn't any software to monitor it, if you run them at full blast long enough. I remember Hector (perhaps under Asahi Lina name, ha-ha) posted some photos of the macbook saying he is working on the sound driver to not burn the speakers, but I never saw a confirmation post and I was looking at his profile often those days.

the moment they move to something more normal it would attract more normies and less hardcore autists

The mailing list is good because it's everything-agnostic. If you have Internet access, you can send an email. There are scripts in git to turn your diffs into a form that you can paste to the email and attach it, you can literally send patches from Outlook if you disable HTML email.

 

[Nobody Important]

Hector still fails to understand it isn't all about him. Like a lot of people who quit things, he seems to have failed the "going away" part.

Spoiler: text

On 2025/02/07 4:37, Danilo Krummrich wrote:
> On Thu, Feb 06, 2025 at 06:19:42PM +0900, Hector Martin wrote:
>>
>> If shaming on social media does not work, then tell me what does,
>
> Most importantly be *consistent* with good technical arguments, calmly focus on
> your actual matter rather than escalating any surrounding details.
>
> Accept that sometimes things can't be reached directly, but additional work is
> needed to change the preconditions.
>
> Goals aren't reached by burning bridges, but by building them. Sometimes you
> may not be able to build a bridge where you would like to. But you can still
> look for alternative routes with and within the community.
>
> Surely, it does take time and energy, but certainly there's no shortcut.

I'm not talking about individual technical problems. You cannot solve
social and community problems with technical arguments.

Yes, given enough patience and technical argumentation, you can get code
into the kernel, or maybe even get some existing code refactored. That
doesn't change the fact that the process is often quite terrible,
hostile to newcomers, demoralizing, and by wide consensus much worse
than practically any other FOSS project, even those of similar scope to
the kernel.

And what I see, is very little effort to improve that status quo, or at
least very little that yields any actual change that isn't just
band-aids (e.g. tooling like b4, which is nice and appreciated, but
doesn't fix any underlying issues). And that's not going to change no
matter how many long technical arguments we have on the MLs (or even off
MLs, since MLs are also not particularly good for this, and I've seen
multiple arguments only reach a resolution after being redirected to IRC).

But I've used up all my spoons for this, and clearly Linus doesn't think
there's a problem in this thread worth replying to other than myself, so
I'm giving up on fighting for any change or being part of the kernel
maintainer community. Whether the rest of the kernel community chooses
to continue to live in an ugly bubble or actually try to fix some of
these systemic issues, is up to them.

- Hector

https://lkml.org/lkml/2025/2/7/16

 

[revenge of rebecca]

I am afraid that Hector Martin is still contributing under his Asahi Lina persona.

https://lkml.org/lkml/2025/2/7/15

Spoiler

Date Fri, 7 Feb 2025 04:57:13 +0900
Subject Re: [PATCH v6 01/26] fuse: Fix dax truncate/punch_hole fault path
From Asahi Lina <>


On 2/7/25 4:44 AM, Dan Williams wrote:
> Asahi Lina wrote:
>> Hi,
>>
>> On February 6, 2025 1:10:15 AM GMT+01:00, Dan Williams <dan.j.williams@intel.com> wrote:
>>> Vivek Goyal wrote:
>>>> On Fri, Jan 10, 2025 at 05:00:29PM +1100, Alistair Popple wrote:
>>>>> FS DAX requires file systems to call into the DAX layout prior to unlinking
>>>>> inodes to ensure there is no ongoing DMA or other remote access to the
>>>>> direct mapped page. The fuse file system implements
>>>>> fuse_dax_break_layouts() to do this which includes a comment indicating
>>>>> that passing dmap_end == 0 leads to unmapping of the whole file.
>>>>>
>>>>> However this is not true - passing dmap_end == 0 will not unmap anything
>>>>> before dmap_start, and further more dax_layout_busy_page_range() will not
>>>>> scan any of the range to see if there maybe ongoing DMA access to the
>>>>> range. Fix this by passing -1 for dmap_end to fuse_dax_break_layouts()
>>>>> which will invalidate the entire file range to
>>>>> dax_layout_busy_page_range().
>>>>
>>>> Hi Alistair,
>>>>
>>>> Thanks for fixing DAX related issues for virtiofs. I am wondering how are
>>>> you testing DAX with virtiofs. AFAIK, we don't have DAX support in Rust
>>>> virtiofsd. C version of virtiofsd used to have out of the tree patches
>>>> for DAX. But C version got deprecated long time ago.
>>>>
>>>> Do you have another implementation of virtiofsd somewhere else which
>>>> supports DAX and allows for testing DAX related changes?
>>>
>>> I have personally never seen a virtiofs-dax test. It sounds like you are
>>> saying we can deprecate that support if there are no longer any users.
>>> Or, do you expect that C-virtiofsd is alive in the ecosystem?
>>
>> I accidentally replied offlist, but I wanted to mention that libkrun
>> supports DAX and we use it in muvm. It's a critical part of x11bridge
>> functionality, since it uses DAX to share X11 shm fences between X11
>> clients in the VM and the XWayland server on the host, which only
>> works if the mmaps are coherent.
>
> Ah, good to hear. It would be lovely to integrate an muvm smoketest
> somewhere in https://github.com/pmem/ndctl/tree/main/test so that we
> have early warning on potential breakage.

I think you'll probably want a smoke test using libkrun directly, since
muvm is quite application-specific. It's really easy to write a quick C
file to call into libkrun and spin up a VM.

If it's supposed to test an arbitrary kernel though, I'm not sure what
the test setup would look like. You'd need to run it on a host (whose
kernel is mostly irrelevant) and then use libkrun to spin up a VM with a
guest, which then runs the test. libkrun normally uses a bundled kernel
though (shipped as libkrunfw), we'd need to add an API to specify an
external kernel binary I guess?

I'm happy to help with that, but I'll need to know a bit more about the
intended usage first. I *think* most of the scaffolding for running
arbitrary kernels is already planned, since there was some talk of
running the host kernel as the guest kernel, so this wouldn't add much
work on top of that.

I definitely have a few tests in mind if we do put this together, since
I know of one or two things that are definitely broken in DAX upstream
right now (which I *think* this series fixes but I never got around to
testing it...).

Cc: slp for libkrun.

~~ Lina

 

[Real Abyss]

Did he really think Linus would respond "oh no you are such an important developer for the kernel PLEASE DONT LEAVE!! we will completely redo the entire contribution process, which is certainly not more effort than you figuring out how to mail and format patches"?

Edit:

I am afraid that Hector Martin is still contributing under his Asahi Lina persona.

Do you think he'll compartmentalize his ragequit or carry his crying and bitching over to his weebsona?

 

[The Real Slim Shady]

That
doesn't change the fact that the process is often quite terrible,
hostile to newcomers, demoralizing, and by wide consensus much worse
than practically any other FOSS project, even those of similar scope to
the kernel.

Newcomers don't get to write mainline code. If you are new, you first prove your worth by writing good code, and then send it to a maintainer (who would be guiding you from the start and give you a useful task, that is on your skill level to start with), and then the maintainer would commit your patch. This is why there is a separate field for the author name and the comitter name in git. It is not hostile, it is a QA thing.

Demoralizing? If you were raised being told you are a child prodigy, and then functioning in a community that is constantly asspatting and never tells you negative information directly, that is just a hard landing in reality. kernel.org is not a kindergarten, Hector's previous FOSS projects were just all done by various huggy-feely groups.

I wouldn't call it "worse than practically any other FOSS project". Being told your code sucks is normal if it sucks. If you are lucky, the person will be diplomatic about it, but most people in FOSS have little way with words.

 

[Markass the Worst]

I am afraid that Hector Martin is still contributing under his Asahi Lina persona.

https://lkml.org/lkml/2025/2/7/15

Called it. Hector is too predictable.

 

[reptile baht spaniard rid]

What other FOSS projects are similar in complexity to the Linux kernel? Maybe by lines of code, but everything else runs above the kernel …

 

[jakkufurosuto]

Ragequit!

View attachment 6950230

Spoiler: text

I no longer have any faith left in the kernel development process or
community management approach.

Apple/ARM platform development will continue downstream. If I feel like
sending some patches upstream in the future myself for whatever subtree
I may, or I may not. Anyone who feels like fighting the upstreaming
fight themselves is welcome to do so.

Signed-off-by: Hector Martin <marcan@marcan.st>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1e930c7a58b13d8bbe6bf133ba7b36aa24c2b5e0..c9623439998709c9d6d6944cbd87e025356422da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2177,7 +2177,6 @@ F: sound/soc/codecs/cs42l84.*
F: sound/soc/codecs/ssm3515.c

ARM/APPLE MACHINE SUPPORT
-M: Hector Martin <marcan@marcan.st>
M: Sven Peter <sven@svenpeter.dev>
R: Alyssa Rosenzweig <alyssa@rosenzweig.io>
L: asahi@lists.linux.dev
---
base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37
change-id: 20250207-rm-maint-af7cccc22871
Best regards,
--
Hector Martin <marcan@marcan.st>

https://lkml.org/lkml/2025/2/7/9

he actually did it

 

[neger psykolog]

The mailing list is good because it's everything-agnostic. If you have Internet access, you can send an email. There are scripts in git to turn your diffs into a form that you can paste to the email and attach it, you can literally send patches from Outlook if you disable HTML email.

See I don't even barely understand a word you just said. Diffs? "Patches from outlook"?
This secret wisdom should be protected otherwise next thing you know they'll add emojis and a fucking reels feature like has been added to everything else.

Working as intended.

 

[Ducks Sorted in a Row]

What other FOSS projects are similar in complexity to the Linux kernel? Maybe by lines of code, but everything else runs above the kernel …

I'd argue there's a good chance that Chromium is more complex than the Linux kernel, though not entirely out of necessity, but just reflecting the sprawling corporate structure that birthed it (as per Conway's Law).

 

[revenge of rebecca]

If Hector Martin is fed up with the Linux kernel, I am sure there are other projects that he can work on. For example, he can ditch his work on apple silicon and apply to work as a GrapheneOS contributor!

 

[Atlas Sneezed]

What other FOSS projects are similar in complexity to the Linux kernel? Maybe by lines of code, but everything else runs above the kernel …

Doing such a comparison is nasty because Linuxes LOK are kinda inflated by autogenerated lines from graphics drivers (hi AMD!). First thing that comes to mind is gcc, you really need to be autistic to write a good compiler. Chromium would be my second contender

 

[Heartbeat]

I wonder how Hector will turn out in future now that his physical identity now has less authority, clout, and sway than his weebsona in a place that's his very own autism thunderdome. His presence in the kernel? Gone. His presence on socials? Gone. This is like a spiritual 41%, now he's a completely empty vessel that's ready for the possession by weeb demon Asahi.

 

[ScooterL]

>> solve social and community problems
>> improve that status quo
>> fix some of these systemic issues

Hector wants to solve, improve and fix people.

Like every other troon, he's a controlling narcissist.

 

[Prokhor Zakharov]

But I've used up all my spoons for this

Mentioning spoons = argument is immediately invalid.

 

[Edict of Expulsion]

But I've used up all my spoons for this, and clearly Linus doesn't think
there's a problem in this thread worth replying to other than myself, so
I'm giving up on fighting for any change or being part of the kernel
maintainer community.

This fat autistic faggot bitch. He said the line.

Then immediately retreats into his schizo multiple personalities to continue contributing to the kernel as the troon persona lina.

This tranny faggot is nuttier than a fruitcake.
Anime. Not even once.

Does he do the tranny voice in his head when he types out the lina emails.

Hector marcan and his line are dead. The twisted orc of lina is all that remains. Classic cautionary tale.

 

[ellroy]

Not always. Memory vulnerabilities can occur as the result of moving things around and in an environment with a lot of moving parts they're pretty much unavoidable. Even John Carmack ran the RAGE codebase (a game for which Microsoft wrote to congratulate him on having the lowest crash rate of any game on the 360 at the time) through some static analyzers and they found a myriad memory issues. Simply writing off things that could compromise 90% of the servers in the world as something only retards do is a bad idea.

Again, skill issue if you don't want to use modern tools to improve your code especially when the biggest contributors to the kernel code are corporations that should have software engineering practices in place to limit such issues. Generally games developers have their backs against a wall which explains their lack of quality code and Carmack took his time with RAGE.

Are you referring to the `unsafe` keyword? If so, then yes, it sucks, but you can use it to cordon off all your unsafe code that interacts with the hardware itself (because you don't have a choice), but it can be encapsulated and audited the same way you do C code, and the rest of the system around it can be memory safe. If not, then I have no idea what you're talking about.

I was referring to that which inherently defeats the point of pushing Rust because the biggest argument for is memory safety. The solution to this problem is doing what C has been doing so the advantages of having introduced this language into your kernel has been nullified. I'm also vaguely aware of the how immature a lot of Rust tools are for embedded devices and the advantage is simply not there.

C++ in the kernel would be an unmitigated disaster without some very strict rules. And honestly, I agree with Linus' assessment of it.

Somehow Apple's Driver Kit and Metal API, Microsoft's kernel graphical subsystem, and Nvidia's CUDA doesn't have an issue with using C++. Yes, you can not use exception handling. If you wish to call a certain library, you would have to audit a library's code to ensure the library being called does not invoke exception handling. Linus' assessment as far as I'm aware was back when C++03 was the standard. My point about smart pointers in C++11 was that a solution existed to the "memory-safety" issue, a solution that even Red Hat played around with for several years before dropping it in favor for Rust. It seems like Linus just chose Rust out of the blue and in comparison to the lively public debate on systemd, there wasn't one for Rust. Now that debate is happening in real time because maintainers are getting frustrated with Rust for Linux.

Honestly if I were to pick any nu-language to integrate into the kernel it'd have to be Zig (caveat: once it gets standardized), I've drank all the koolaid on that one and more - it's a lot more memory-safe than C but without any of the horrible trappings of C++ or Rust, not the least of which is the autistic insistence on the backwards object model that necessitates RAII.

I don't disagree about Zig and would chose it over Rust, but again, I'm biased for the mature solution of C and C++.

 

[August Levasseur]

Honestly if I were to pick any nu-language to integrate into the kernel it'd have to be Zig (caveat: once it gets standardized), I've drank all the koolaid on that one and more - it's a lot more memory-safe than C but without any of the horrible trappings of C++ or Rust, not the least of which is the autistic insistence on the backwards object model that necessitates RAII.

I don't disagree about Zig and would chose it over Rust, but again, I'm biased for the mature solution of C and C++.

You're all overlooking the one true solution: Go for Linux

 

[IKOL]

ou're all overlooking the one true solution: Go for Linux

*Its_All_Tranny_Tech.gif*