Having ~5 posts like this on a daily basis where I need to respond with an asymmetric amount of effort to prevent people from getting misinformed is not sustainable. They wanted to push the view that it's useless and easily replicated and didn't bother doing any research/reading.
Conversation
Can you make a "common misconceptions" section in your documentation and mostly respond to falsehoods with that?
(A significant fraction of) the software development community has more time than you, beat them in efficiency or accept defeat and move on to willing users.
1
1
This person was more than capable of understanding the documentation if they had simply not been lazy and jumped right to dismissing the project as useless and without a niche. I don't understand why they had to do it. I shouldn't have to reply essentially rewording the README.
2
1
"The security mitigations in mozjemalloc are a marginal improvement over jemalloc and far weaker than hardened_malloc, see https://github[.]com/GrapheneOS/hardened_malloc/blob/master/README.md#mitigation_comparison for details."
Don't reply, update documentation and link.
2
I don't want to criticize other projects there, and it would need to be extremely carefully worded to make it clear that jemalloc's design choices are not wrong or poorly chosen but rather it's a performance oriented allocator, not a hardened allocator. Where's the limit too?
1
1
i.e. why compare specifically to jemalloc and not everything else? I have some comparisons about the philosophy / approach to OpenBSD malloc because it's the closest cousin of it and is the most direct inspiration for it. It just stopped being a viable platform for what I wanted.
1
1
1
I don't portray design choices in hardened_malloc as being more valid or better but rather I explain why it takes the approach that it does based on the goals and compromises. The jemalloc design isn't any less modern and it's not badly implemented. It's just not the same thing.
1
1
1
It very aggressively uses address space and it explicitly makes performance sacrifices as part of the design for security. I'm not on that thread telling them that they should use it. I simply don't want it portrayed unfairly/inaccurately and dismissed as something near useless.
1
1
1
I didn't propose that they use it. I'm not arguing that they should use it. It's only for 64-bit, reserves an extreme amount of address space as PROT_NONE and it makes significant performance compromises for security. That overview/comparison was totally bogus / offensive though.
1
1
It was a bad comparison, but moderators generally do not care about how bad/poorly researched your argument is or that you have a CoI. I have never seen someone banned for that on an open forum. They are extremely sensitive to anything that looks like a personal attack.
1
1
That's part of the moderation for GrapheneOS communities. I have serious issues with spreading misinformation and attacking other projects / products. I stop people from attacking things like Windows, iPhones, etc. all the time unless they're going to stick to factual criticism.
I'm just saying that you took a far too aggressive approach to an ignorant comment (see lists.torproject.org/pipermail/tor-) and it led to more effort than even a detailed technical-only rebuttal with a "this can harm my livelihood, please keep criticism of my work factual" at the end could.
2