Open Source Software Community - it's about ethics in Code of Conducts

  • 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
There's a decade old stereotype that incels or redpillers or however you want to call them refer to women as "females" unusually often, and leftists take this as the incels like, dehumanizing women by referring to them in a way like they're talking about animals. They would take this stereotype so seriously that I remember ResetEra at times would straight up suspend or ban people for using the word "female" in almost any context, like it got to the point that the word itself is suspect.
They aren't even calling them foids, or woms

For example, I don't see Haskell
They probably would if there were more than 5 haskell devs in the world.

It's also the perfect example of the Troon mentality that is ruining modern software. They declare it "memory safe" then immediately require unsafe carveouts in order for it to be even remotely useful.
As far as I know, if you need to do something with linked lists, the library is using unsafe code to do it. And I imagine if you were going to implement linked lists in rust yourself, if you wanted to do a singly linked list, or had some other reason, like not being able to use external libraries like the kernel, you will have to also use unsafe rust for that.

Then the problem is, from what I understand they've purposefully made working with memory in what they consider unsafe ways feel clunky compared to C where that is a core part of the language. Using pointers, and handling memory explicitly. It's why I think C is probably the perfect level of abstraction for something like a kernel, or firmware. It's above assembly, but you do manually handle memory when you have to allocate it dynamically, and it's on the person writing it to decide what approach is going to be best.
 
If you're just going to blame the programmer then why not blame the programmer for all bugs written in C? I thought the point of Rust was to make the path of least resistance be to write memory safe code. If that's putting unsafe {} or .unwrap() everywhere then surely, by Rust's standards, we blame the language.
The unsafe block just makes it the way that C is by default, and with C have no alternative. It's like keeping a chirping fire alarm without replacing the batteries, then blaming the manufacturer that it didn't warn you about the fire. You literally wanted it to happen.

It's beyond silly to jump on a single CVE in Rust code like it's some sort of a gotcha when it's next to 159 fucking CVEs in C, and that's even with safe mode turned off. Grasping at straws doesn't begin to describe it. Yes, rust in safe mode eliminates entire classes of problems. It's not up for discussion because it's mathematically guaranteed as long certain invariants known ahead of time are preserved. You have no such choice in most other languages.
 
The unsafe block just makes it the way that C is by default, and with C have no alternative. It's like keeping a chirping fire alarm without replacing the batteries, then blaming the manufacturer that it didn't warn you about the fire. You literally wanted it to happen.

It's beyond silly to jump on a single CVE in Rust code like it's some sort of a gotcha when it's next to 159 fucking CVEs in C, and that's even with safe mode turned off. Grasping at straws doesn't begin to describe it. Yes, rust in safe mode eliminates entire classes of problems. It's not up for discussion because it's mathematically guaranteed as long certain invariants known ahead of time are preserved. You have no such choice in most other languages.
It is a fucking gotcha when Rust makes up less than 0.05% of the code base and had any at all in spite of its supposed safety gurantees.
 
when it's next to 159 fucking CVEs in C,
But is it really guaranteed that a CVE is caused by lack of "memory safety"? Aren't there multiple causes for introducing privilege escalations and vulnerablilities?
I think those CVEs would still exist in languages like Rust, because it is a design problem.
 
It is a fucking gotcha when Rust makes up less than 0.05% of the code base and had any at all in spite of its supposed safety gurantees.
This is a great example of footbal fan mentality extended to languages. Of course it's memory safe - that's a feature of the language that's not up to debate. It also contains a feature where you can disable that. If you disable that, it's no longer guaranteed to be memory safe. How is that remotely surprising or controversial. Did you expect this part of code to never contain any bugs, in perpetuity, until the end of time? Also it's at 0.3% currently.

But is it really guaranteed that a CVE is caused by lack of "memory safety"?
That's like crashing your car on the highway and being surprised that it happened because your car has brakes.
Aren't there multiple causes for introducing privilege escalations and vulnerablilities?
I think thosse CVEs would still exist in languages like Rust.
Depends on the cause. If the cause is something like use after free or buffer overflow, then Rust makes this impossible before compile time.
 
The unsafe block just makes it the way that C is by default, and with C have no alternative
And for the overwhelming majority of things like that we can use any language we want. For things like the kernel, you’re doing a lot of “unsafe” and that’s why the entire Rust meme is retarded here.
 
1766104634419.png


> delayed

FUCKING called it. But oh, I sure am glad that Francis decided attending mujahadeen G*een P*rty meetings and supporting their fellow heckin' tranxfolx like Ariadne "The Ogre" Conill about how oh so hard it is to be transgender takes precedence over the only thing keeping him off the street. Hopefully when the inevitable ACK arrives someone more stalwart can inherit the project. Maybe Mate Kukri? At this point Libreboot might legit be better off in the hands of a Canonical employee than a gimp like Francis. Speaking of Trannyadne, Francis reposted a Mastodeet from el ogro containing the following:

link / archive


El Ogro said:

I want you to understand​


Dec 2, 2025 · 4 min read

I want you to understand what it is like to be transgender during this time.

I want you to understand the threat to doctor-patient confidentiality. In June, the Department of Justice began targeting clinics and health systems which provide treatment for gender dysphoria with subpoenas requesting personally identifying information about patients. While these subpoenas currently target clinics which provide services to minors, it is clear that they are testing the waters for expanding their inquiry to adult patients. Although compliance with these subpoenas is likely illegal as disclosure of these records would violate HIPAA, I worry that I will be included on a list of transgender individuals and targeted for discrimination as a result.

I want you to understand the threat to medical care for trans people more broadly. Like with the subpoenas, these efforts are starting with trans children. Although I am privileged to have private health insurance through my employer, private insurers often use Medicare coverage determination criteria as a baseline for their policies. I worry that I could be denied access to medically necessary health care in the future.

I want you to understand that one does not simply quit taking hormones. Abruptly stopping HRT can leave the body in a hormonal state that may never fully return to baseline and potentially reverses some of the desired effects. This outcome is often distressing, and loss of access to medical care may lead many to self-manage their HRT. Due to confidentiality concerns, such self-managed treatment will likely not be monitored with lab work. Managing hormone therapy without proper medical supervision can be dangerous.

I want you to understand what it is like to travel as a transgender US citizen. As a result of Trump’s Executive Order 14168, it is no longer possible for transgender people to obtain a US passport that correctly reflects their gender presentation. Traveling with identity documents that do not match your gender presentation can be dangerous abroad. In some cases you can even be denied entry or even deported. Such policies discourage trans people from traveling due to fear of discrimination.

I want you to understand what it is like to be a transgender worker. A report from The Williams Institute of Law at UCLA shows that over 80% of transgender employees in the US have experienced discrimination or harassment at work at some point. Contrary to some optimistic portrayals during Pride Month, this is actually getting worse: the Movement Advancement Project 2025 NORC survey reports a significant uptick in discrimination and harassment complaints. If that wasn’t enough, Lambda Legal also reports a surge in the volume of requests submitted to their help desk.

I want you to understand what it is like to be a transgender entrepreneur. Based on a report from Pitchbook, only 0.8% of venture capital funding went to female-founded companies in 2025, the lowest since 2015. While we do not yet have data for LGBTQ founders in 2025, StartOut estimated that only 0.5% of companies which raised venture capital from 2000-2022 were founded by LGBTQ founders. These numbers plainly highlight ongoing social inequities.

I want you to understand what it is like to be a transgender leader in open source. While the open source community has made progress toward inclusion, a study by the Linux Foundation observes that people identifying as women, non-binary, LGBTQ+ or disabled were three times more likely to report threats. Another study found that simply having a Code of Conduct did not make projects safer. Without meaningful enforcement, participants continued to experience harassment. Even meaningful enforcement isn’t enough. For example, after rejecting Xlibre in Alpine due to their reactionary background, a notable alt-right Linux podcaster made a video targeting me, focusing on my transgender identity rather than the technical merits.

I need you to understand that while things are dire for trans people right now, we can fight back and win. At the same time, we must confront these realities: human decency demands it. Support politicians who fight anti-trans policies. Donate to law firms like Lambda Legal. If you are a business owner, hire trans people: we have been driving innovation since time immemorial. If you are an investor, invest in trans founders: the same StartOut report that shows that only 0.5% of funded companies were founded by LGBTQ founders also observed that those founders created more jobs with less funding than their peers.

LMAO

"For example, after rejecting Xlibre in Alpine due to their reactionary background, a notable alt-right Linux podcaster made a video targeting me, focusing on my transgender identity rather than the technical merits."

SUFFAH WAYTRANNY! Also >>> technical merits geg, as if this loony troon didn't have a tizzy and make Wayback as an actual reactionary spergout, only to abandon it two weeks later. Just goes to show nothing made by and for trannies is built to last. The main reason for why I'm not so worried about Libreboot is beacause I true and honest men like my boy Mate and Nick Chin are behind most of the real progress in Libreboot as of late, including the T1700, 3050 Micro and T480/s ports (as well as their respective Coreboot upstreams). Francis just seems to be a janny that adds them to the lbmk compiler and dilates over his latest retarded distraction. Obligatory Ogre:

1766105810243.png
 
This is a great example of footbal fan mentality extended to languages. Of course it's memory safe - that's a feature of the language that's not up to debate. It also contains a feature where you can disable that. If you disable that, it's no longer guaranteed to be memory safe. How is that remotely surprising or controversial. Did you expect this part of code to never contain any bugs, in perpetuity, until the end of time? Also it's at 0.3% currently.


That's like crashing your car on the highway and being surprised that it happened because your car has brakes.

Depends on the cause. If the cause is something like use after free or buffer overflow, then Rust makes this impossible before compile time.
So are those 159 CVEs specifically for memory corruption/buffer overflows?
 
The unsafe block just makes it the way that C is by default, and with C have no alternative. It's like keeping a chirping fire alarm without replacing the batteries, then blaming the manufacturer that it didn't warn you about the fire. You literally wanted it to happen.

It's beyond silly to jump on a single CVE in Rust code like it's some sort of a gotcha when it's next to 159 fucking CVEs in C, and that's even with safe mode turned off. Grasping at straws doesn't begin to describe it. Yes, rust in safe mode eliminates entire classes of problems. It's not up for discussion because it's mathematically guaranteed as long certain invariants known ahead of time are preserved. You have no such choice in most other languages.
From internet:
"As of December 2025, the Linux kernel contains approximately 25,000 lines of Rust code.
This represents a small fraction of the overall codebase, which consists of about 34 million lines of C code."

My own flawed test on a slightly old kernel tree suggests similar numbers using something like :
find . | egrep "*.rs$" |xargs cat |wc -l

Anyway, there are ~1300 times more C code than Rust code, so C having 159 CVEs compared to 1 for Rust actually makes rust look pretty poor.
And that is assuming that EVERY SINGLE C CVE was a memory error.
Hint, most C CVEs are NOT memory errors so this makes rust look even worse.

Using my brain and math it does look like these statistics paint a very poor image for Rust when it comes to safety.
Since Rust code is >10 times more likely to result in CVEs it is either the language that is a poor choice for writign systems code (it is)
or it is a sign that rust kernel developers are a lot less skilled in writing quality code than the C kernel devs (they are)

TL;DR
The data shows:
1, Rust production code in the kernel is an order of magnitude more insecure than the C code
2, Rust developes are probably not very good programmers.
 
And for the overwhelming majority of things like that we can use any language we want. For things like the kernel, you’re doing a lot of “unsafe” and that’s why the entire Rust meme is retarded here.
Still better to have an option to keep at least some of it safe. I can't find a 100% accurate source on how much of it is unsafe, but it seems to be less than 10%: https://mars-research.github.io/doc/2024-acsac-rfl.pdf


Anyway, there are ~1300 times more C code than Rust code, so C having 159 CVEs compared to 1 for Rust actually makes rust look pretty poor.
Pretty unhinged to suggest that 159 looks better than 1 in any way when there's dozens of CVEs every single day and this is the first Rust one since it was introduced into the kernel in like 2020. There were 159 just in this batch. Not all time. So the data paints a very different picture than your post describes.

Does it matter? There's no need to make those convoluted arguments: everybody knows that writing code inevitably introduces bugs. It's not like your team starts winning or something when you manage to find a gotcha and say "a-ha!" grasping at straws trying to find any, just any fault in Rust code. No need to make something as inconsequential as the choice of programming language a part of your identity. Just pick the best tool for the job, or even just a tool you enjoy.
 
That's like crashing your car on the highway and being surprised that it happened because your car has brakes.
I think you misread what I said. I meant to say that programming languages are rarely the silver bullets made out to be. Some stuff is CVE because of the program design, and any languages will not solve it.
 
Are you even white? This is like niggers being unable to parse what "per capita" means because it involves a proportion and not absolute numbers.
This doesn't mean what you think it means.

Tell that to all the Rust trannies then.
Can I tell it to Cniggers instead? There's lots and LOTS of absolutely desperate, pathetically hopeless us vs them here in this very thread with al the C fanboyism. We're the red team, so we like C, Republicans, red meat, don't like transsexuals. They're the blue team, so they like Rust, vegan food, Democrats, and like transsexuals. It's been like that all day every day for years.
 
God damn C programmers, constantly inserting themselves into programming projects and discussions
- No one, ever
 
From internet:
"As of December 2025, the Linux kernel contains approximately 25,000 lines of Rust code.
This represents a small fraction of the overall codebase, which consists of about 34 million lines of C code."

My own flawed test on a slightly old kernel tree suggests similar numbers using something like :
find . | egrep "*.rs$" |xargs cat |wc -l

Anyway, there are ~1300 times more C code than Rust code, so C having 159 CVEs compared to 1 for Rust actually makes rust look pretty poor.
And that is assuming that EVERY SINGLE C CVE was a memory error.
Hint, most C CVEs are NOT memory errors so this makes rust look even worse.

Using my brain and math it does look like these statistics paint a very poor image for Rust when it comes to safety.
Since Rust code is >10 times more likely to result in CVEs it is either the language that is a poor choice for writign systems code (it is)
or it is a sign that rust kernel developers are a lot less skilled in writing quality code than the C kernel devs (they are)

TL;DR
The data shows:
1, Rust production code in the kernel is an order of magnitude more insecure than the C code
2, Rust developes are probably not very good programmers.
This would make sense if:

- Rust was introduced into the Kernel last week, not in 2020
- The number of CVEs was linearly dependent on the "quality" of code
- The amount of scrutiny per line of code was equal per-language
- The number of CVEs per a unit of scrutiny was constant regardless of language

I see you are desperate to latch onto anything you perceive as FINALLY redeeming C in your eyes. Yes, a Rust CVE! After all these years! At last, the perfect proof of the inferiority of the language I don't like. Now I can show everyone on Kiwifarms why it's so bad, with like, math and sheeit. Oops, forgot to factor a few things in.
 
Can I tell it to Cniggers instead? There's lots and LOTS of absolutely desperate, pathetically hopeless us vs them here in this very thread with al the C fanboyism. We're the red team, so we like C, Republicans, red meat, don't like transsexuals. They're the blue team, so they like Rust, vegan food, Democrats, and like transsexuals. It's been like that all day every day for years.
I'm not a C programmer and I don't give a shit if C is attacked. I'm only holding Rust to the same standards its advocates hold C to.
 
- The number of CVEs was linearly dependent on the "quality" of code
So you mean that most of CVEs are caused by Rust programmers being novices while the CVEs of C language are from experts?
Also you still didn't answer if all 159 CVEs are caused by memory issues, or are just design issues?
- The amount of scrutiny per line of code was equal per-language
I don't see how does this affects the judgement. Obviously, the new stuff will always be more inspected, it is normal.
I see you are desperate to latch onto anything you perceive as FINALLY redeeming C in your eyes. Yes, a Rust CVE! After all these years! At last, the perfect proof of the inferiority of the language I don't like. Now I can show everyone on Kiwifarms why it's so bad, with like, math and sheeit. Oops, forgot to factor a few things in.
Nobody denies here that C requires manual de-alocation etc compared to newer languages, but we argue that replacing or adding Rust to an existing project written in C causes much more problems than it solves, even if it makes the job easier regarding memory checks.

Personally I have no issue with Rust existing. More power to those that manage to make Rust compile DOS executables or target MOS chips.
But I highly dislike this "rush" to re-write existing projects in Rust. My biggest concern is the higher memory, space requirements associated in general with these projects.
 
So you mean that most of CVEs are caused by Rust programmers being novices while the CVEs of C language are from experts?
Bitch please

Also you still didn't answer if all 159 CVEs are caused by memory issues, or are just design issues?
Lol I am not wading through CVEs to convince you of anything and besides it's irrelevant

Nobody denies here that C requires manual de-alocation etc compared to newer languages, but we argue that replacing or adding Rust to an existing project written in C causes much more problems than it solves, even if it makes the job easier regarding memory checks.
Like what kinds of problems? Clearly if it was causing problems the consensus would be to not introduce a new language. And the maintainers, Torvalds included, judged that it does solve a lot of problems.
 
the maintainers, Torvalds included, judged that it does solve a lot of problems
Same crew judged that adding a CoC solves a lot of problems so historically they are very easily swayed by the winds of Reddit-popularity.
 
Back
Top Bottom