ellroy
kiwifarms.net
- Joined
- Feb 2, 2021
💪 Tough Guys 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.
- Thread starter Markass the Worst
- Start date
-
🏰 The Fediverse is up. If you know, you know.
-
Want to keep track of this thread?
Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
Create account
- Joined
- Nov 12, 2022
I can feel Torvald's rage and disgust in that email, he didn't even read it after typing because there's a typo in the last sentence.
This is very cathartic. I hope "Asahi Lina" stops contributing too.
- Joined
- Jul 13, 2017
I've heard that Torvald's rages used to be infamous and he would swear and all sorts of shit - sad he seems to have chilled out a bit but still funny/great that he was so on-point with what he said.
ellroy
kiwifarms.net
- Joined
- Feb 2, 2021
I posted about this back in August. Hector was having his Asahi Lina alter ego use his stream keys to contribute, so I believe the contributions where from his account but under the guise that another person was doing it (exactly zero maintainers fell for it). I think he has removed his ability to contribute up stream so his Asahi account will have to get their own keys. I'm sure when that day comes, there will be a very interesting email chain.
just Reading a post
kiwifarms.net
- Joined
- Jul 30, 2024
I DID NOT QUIT THE KERNEL, THE KERNEL QUIT ME.
LMFAO
This is what you get when you try to play autistic game of thrones Hector.
You end up looking like the spiteful fag you are, when someone with actual clout shuts you down.
Now fuck off and make your enemy's list.
Rullepoelse
kiwifarms.net
- Joined
- Jul 6, 2022
It's such a shame Linus has mellowed out. Would've loved to see him post that the way he would have 10 years ago.
- Joined
- Jul 13, 2017
I think its good to provide a link to some of his top responses for some khantext here: https://adtmag.com/blogs/dev-watch/2014/04/linus-torvalds-rants.aspx
An example of a few:
For anyone not familiar Linus Torvalds like "created Linux" or some shit and is legendary for swearing like fuck at retards in emails - you can't really argue with him since he literally created linux (email is here: https://fossbytes.com/linus-torvaldss-famous-email-first-linux-announcement/).
He took a break for a while and toned down his emails unfortunately: https://www.newyorker.com/science/e...sive-e-mails-the-creator-of-linux-steps-aside
...
“Please just kill yourself now. The world will be a better place"... I wonder what his KF username is?
- Joined
- Dec 13, 2022
Acting like a hysterical faggot.
Calling in Linus for a comment, and he got one.
Continues to act like a hysterical faggot.
Linus is a faggot but hector is a tranny faggot, below even niggers.
I really wonder how many of the idiots donating to Hector’s patreon will drop him over this.
He had ONE job. Just get upstream Linux support into M1. Get hardware working and shut up and submit patches.
Well the tranny compulsion of burning bridges with even loyal toadies marches on.
Chance of hector pulling a byuu and 41%-ing rose three sizes that day.
Calling in Linus for a comment, and he got one.
Continues to act like a hysterical faggot.
Linus is a faggot but hector is a tranny faggot, below even niggers.
I really wonder how many of the idiots donating to Hector’s patreon will drop him over this.
He had ONE job. Just get upstream Linux support into M1. Get hardware working and shut up and submit patches.
Well the tranny compulsion of burning bridges with even loyal toadies marches on.
Chance of hector pulling a byuu and 41%-ing rose three sizes that day.
- Joined
- Dec 16, 2019
For all his bitching and moaning, all he's listed is as A maintainer of a single soundcard driver for ARM/APPLE support? Huh.
He likely would have posted something similar, Martin is simply too small of an idiot for Linus to get very angry over. The famous Linus rants are universally against people Linus respects.
Anyway, are we going to get cooties from sharing a top level domain with this faggot?
(As an aside, anyone who has an in with Tim Apple has the chance to convince him to do something really fucking funny, as Apple could release all the support necessary for Linux to boot natively today - you know they have it developed internally "just in case" and btfo Martin forever.)
- Joined
- Dec 16, 2023
Hector is a ridiculous bitch, a whiner, and a social media brigading asshole, but there is one thing I can agree with him on. There needs to be a movement to memory safe languages. That is well past due. Many 0-day bugs are a result of using non-memory safe languages and people making simple mistakes in such code. Using an inherently memory safe language would mitigate this problem. I understand why people continue to use non-memory safe languages, not only do more people know them at an expert level, but they have a number of advantages as a result of their long history of use. But, at some point it has to be decided to cut ties with practices that are inherently detrimental in a number of serious ways.
the only real change I think linux should make is moving off the dogshit mailing list based contribution system onto something modern. I have like half a dozen patches and a few drivers for hw that I simply cannot be bothered to upstream since it's too annoying.
it's hard to search it too so who knows how much stuff got lost in the noise
- Joined
- Jul 13, 2017
hell no, this is vintage autism with vintage autists.
the moment they move to something more normal it would attract more normies and less hardcore autists
esoteric wisdom like this that is used to maintain the kernel or operating system or whatever of everything from your mobile phone to your toaster that you try to fuck each night should be gate kept as hard as fucking possible - the entry requirements should explicitly always require navigating some old-ass mailing list system to read or write anything so that they magic is not lost.
just Reading a post
kiwifarms.net
- Joined
- Jul 30, 2024
For some reason, he is not happy with being the guy who got Linux working on the M1 Macs. He seems to want to take over the entire GNU/Linux project and have his edicts carried out.
The way he has decided to do it is to use the tranny cabal cancel culture shit. Where he tries really fucking hard to collect "dirt" on prominent maintainers and cause drama. So he can ascend the ladder.
But because his hair grows inwards in to his own brain instead of out of his head. He is fucking retarded and any plans he makes he self sabotages and fucks up like the rube he is.
He is at the same level as people who brag about getting DooM to play on baby testers and fridges. Then tries to trick people in to thinking he invented the program in the first place.
Thing is Linus Torvolds has dealt with low rank cockroaches like him before in the mailing lists. The reason why he is being polite. Is because Linus knows he is chump and he is not worth his time.
- Joined
- Dec 13, 2022
Two things I can’t get over is how hector is so out of it to choose a tranny mastodon site, of all sites, if it’s really true that mastodon is really hard to recreate if you lose the account. Which is hilarious. And how he is already a tranny in the wielding a social media hug box to sperg out.
Talk about absolutely building your castle on sand. A tranny 41%s? Account gone. Fights with whatever landlord in its life and gets evicted? Account gone. The wrong news item happens or the tranny has a hissy fit over who knows what, account gone.
Absolutely embarrassing nigger IQ levels.
Also for the rust implementation, accepting the kernel process necessitates doing bassackwards stuff.
The never break user space has definitely and unavoidably led to ugly code and architecture and other things have also.
You maintain two approaches, a shim that treats the existing C code as a trusted oracle since its battle tested and hardens and just politically difficult to change.
The secondly an out of tree modification for rust guarantees that modifies the c code.
Then the rest doesn’t have to know if it’s talking to the shim code or the more invasive code.
Essentially, you treat the existing C implementation as a trusted “oracle” because it’s battle-tested and stable, while acknowledging that upstream modifications to it are challenging to get accepted. In practice, you can maintain two complementary strategies:
1. Out-of-Tree Patch Set:
Here, you directly enhance the C side with additional guarantees that align with Rust’s safety requirements. This version can be used in environments where you have control over the kernel tree (or for specialized use cases) and where you’re willing to bear the extra maintenance overhead of diverging from upstream. It gives you the ability to enforce the invariants you need more robustly.
2. Upstream-Compatible Shim:
For broader acceptance and upstream integration, you implement a shim layer that sits between the Rust code and the stable C API. This shim abstracts away the unsafe details of the C implementation, presenting an interface to Rust as if it were natively designed with those guarantees. Under the hood, it still calls the well-established C code. This approach minimizes changes to the core kernel and leverages the existing, stable behavior while still giving Rust a safe and ergonomic API.
By keeping both paths, you can develop and test your Rust abstractions against a version with direct guarantees (via the out-of-tree patches) and also maintain an upstream-friendly variant that doesn’t require invasive changes to the core kernel. This dual-path strategy maximizes both safety and compatibility, allowing you to ship something useful across different environments.
In summary, a two-pronged approach—one for controlled, enhanced safety (out-of-tree) and one for upstream integration (shim)—is indeed a practical solution that balances the realities of kernel development with Rust’s safety goals.
Talk about absolutely building your castle on sand. A tranny 41%s? Account gone. Fights with whatever landlord in its life and gets evicted? Account gone. The wrong news item happens or the tranny has a hissy fit over who knows what, account gone.
Absolutely embarrassing nigger IQ levels.
Also for the rust implementation, accepting the kernel process necessitates doing bassackwards stuff.
The never break user space has definitely and unavoidably led to ugly code and architecture and other things have also.
You maintain two approaches, a shim that treats the existing C code as a trusted oracle since its battle tested and hardens and just politically difficult to change.
The secondly an out of tree modification for rust guarantees that modifies the c code.
Then the rest doesn’t have to know if it’s talking to the shim code or the more invasive code.
Essentially, you treat the existing C implementation as a trusted “oracle” because it’s battle-tested and stable, while acknowledging that upstream modifications to it are challenging to get accepted. In practice, you can maintain two complementary strategies:
1. Out-of-Tree Patch Set:
Here, you directly enhance the C side with additional guarantees that align with Rust’s safety requirements. This version can be used in environments where you have control over the kernel tree (or for specialized use cases) and where you’re willing to bear the extra maintenance overhead of diverging from upstream. It gives you the ability to enforce the invariants you need more robustly.
2. Upstream-Compatible Shim:
For broader acceptance and upstream integration, you implement a shim layer that sits between the Rust code and the stable C API. This shim abstracts away the unsafe details of the C implementation, presenting an interface to Rust as if it were natively designed with those guarantees. Under the hood, it still calls the well-established C code. This approach minimizes changes to the core kernel and leverages the existing, stable behavior while still giving Rust a safe and ergonomic API.
By keeping both paths, you can develop and test your Rust abstractions against a version with direct guarantees (via the out-of-tree patches) and also maintain an upstream-friendly variant that doesn’t require invasive changes to the core kernel. This dual-path strategy maximizes both safety and compatibility, allowing you to ship something useful across different environments.
In summary, a two-pronged approach—one for controlled, enhanced safety (out-of-tree) and one for upstream integration (shim)—is indeed a practical solution that balances the realities of kernel development with Rust’s safety goals.
- Joined
- Nov 23, 2024
problem is that this also attracts hysterical trannies like marcan who try to subvert entire projects into switching to different tech stacks and adopting CoC's catering to trannies and their attention fetish because doing things the normal way is pROblEmAtiC. they are usually deeply autistic, disturbed individuals never leaving their computer shed and having to use a communication system from the 1980s does absolutely nothing to filter them out
Last edited:
ellroy
kiwifarms.net
- Joined
- Feb 2, 2021
If you're contributing code with 0-days in them then that is a skill issue and you have no business contributing to the kernel. There was a solution to some of this with smart pointers when C++11 standard arrived but Linus refused to touch it. After his struggle session, he decided Rust was the best path forward when in reality it isn't because Rust standard was and remains incomplete and embedded Rust isn't memory safe; remember, Linux runs on a lot of embedded devices. I think the ones pushing for Rust the loudest are the least competent systems programmers.
The Kernel isn't perfect but its been pretty rock solid with a good security practices. The biggest vulnerabilities of recent memory are the result of social engineering, not zero days.
- Joined
- Dec 2, 2018
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.
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++ 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.
- Joined
- Nov 12, 2022
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 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
kiwifarms.net
- Joined
- Aug 6, 2021
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.
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
> 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
revenge of rebecca
kiwifarms.net
- Joined
- Feb 14, 2024
I am afraid that Hector Martin is still contributing under his Asahi Lina persona.
