5 ms·
> 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-pi
by 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?