3 ms·

Many of the claims on this page are supported with links to commits, mailing lists posts, etc. However then there is this claim, which lacks any link supporting

Many of the claims on this page are supported with links to commits, mailing lists posts, etc. However then there is this claim, which lacks any link supporting it: > FreeBSD's malloc (jemalloc) is very forgiving of buggy/hostile code compared to something like otto malloc. Sounds vague. I'm not disputing it, as I haven't read the code of the two mallocs. But I would be curious about the details. Does anybody know what that's about? I was under the impression that jemalloc was seen as quite robust, not least thanks to doing away with free-lists (which is also true for otto malloc, as far as I can tell from cursory research).

emaste 4y ago
> Many of the claims on this page are supported with links to commits, mailing lists posts, etc Their links to commits, mailing list posts, etc., are cherry-picked and taken out of context to present their view. For one example, they suggest that the FreeBSD community is unwilling to make changes to improve things, and say "some of their users like it that way though", linking to https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/019997.html https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01.... If you actually read the thread that response is taken from (starting at https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/019994.html https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01...) you'll see a wholly different picture: a FreeBSD developer proposed a change, there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made. The FreeBSD src git repo has hundreds of thousands of commits, and anyone can post to mailing lists, so of course it's possible to find examples of mistakes being made, or misguided posts from developers or users. I very much welcome constructive criticism and ideas for improving the security landscape within FreeBSD.
- acoppora 4y ago
  > there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made. Help me understand here. The reply by Julian is a huge overreaction. The text you quote seems to be condemning him (a user, not the developer) for fighting a seemingly worthwhile change on the principle of it being the way it was for a long time. So doesn't that kind of prove the point that you're saying isn't true?
  - emaste 4y ago
    The blog post offers the linked reply to support the claim that FreeBSD "blatantly disregards security in favor of performance and appeasing their enterprise consumers."
    - acoppora 4y ago
      Seems like you're making a bit of a jump there. :-)

emaste 4y ago

> Many of the claims on this page are supported with links to commits, mailing lists posts, etc Their links to commits, mailing list posts, etc., are cherry-picked and taken out of context to present their view. For one example, they suggest that the FreeBSD community is unwilling to make changes to improve things, and say "some of their users like it that way though", linking to https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/019997.html https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01.... If you actually read the thread that response is taken from (starting at https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/019994.html https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01...) you'll see a wholly different picture: a FreeBSD developer proposed a change, there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made. The FreeBSD src git repo has hundreds of thousands of commits, and anyone can post to mailing lists, so of course it's possible to find examples of mistakes being made, or misguided posts from developers or users. I very much welcome constructive criticism and ideas for improving the security landscape within FreeBSD.

acoppora 4y ago
> there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made. Help me understand here. The reply by Julian is a huge overreaction. The text you quote seems to be condemning him (a user, not the developer) for fighting a seemingly worthwhile change on the principle of it being the way it was for a long time. So doesn't that kind of prove the point that you're saying isn't true?
- emaste 4y ago
  The blog post offers the linked reply to support the claim that FreeBSD "blatantly disregards security in favor of performance and appeasing their enterprise consumers."
  - acoppora 4y ago
    Seems like you're making a bit of a jump there. :-)