As the expert pick the weakest claim(s) and explain exactly how it's wrong to a non-allocator dev, then list the other incorrect claims, and close it with at most a little indignation.
If this person (was he provably in your conflict with Mozila) clearly targets your...
Conversation
work, cite that fully (for a moderator to adjudicate) and ignore their future posts (if anyone asks link to this).
This forces the moderator, dunning-kreuger "expert", and malicious liar to either ignore or misinterpret your post, both put you in a good position for callouts/CYA
1
I respect your work but you need really strong proof of attacks against you personally and when you respond in kind it muddies the waters as to who was socially wrong (and if this was your first interaction with these individuals you were socially wrong and technically right).
1
My goal isn't to be 'socially right'. I'm completely burned out dealing with people attacking my work and my character on a daily basis and I'm not trying to win accolades from remaining diplomatic all the time. Compare the work I had to put into countering it with their effort.
1
1
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.
1
1
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.
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
Show replies