When FBSD integrated ZFS, I took a look and decided that while I love that file/storage system, FBSD itself had turned more into a lesser version of itself. Perhaps this was due to more pressure from Linux, and fewer developers/contributors.
This entire Wireguard debacle has pretty much turned me off ever using FBSD again. From the inclusion of Sendmail as the default MTA (really? over Postfix) to the lack of development control outlined in this article, I can't trust it.
Perhaps Theo's strategy was the better path.
I'm also consistently impressed by the quality of comments at Ars Technica whenever I visit the site.
This convinced me to subscribe. We need more journalism of comparable quality.
“you either have a commit bit (enabling you to commit code to FreeBSD's repositories) or you don't. It's hard to find code reviews, and there generally isn't a fixed process ensuring that vitally important code gets reviewed prior to inclusion. This system thus relies heavily on the ability and collegiality of individual code creators.”
From my perspective, this whole thing is due to a severe failure of the development process. The sub-standard code should never have been committed. But if there is no process, is it really a failure? Or is this just how it is on FreeBSD?
It's not. We do a lot of code review, and it's done publicly. It's easy to look at the commit logs. I find it telling that the article doesn't spend even one word trying to delve into our code review practices. This case was an aberration.
Has there been any discussion about why the process failed in this case, and what is going to be done to make sure something similar doesn't happen in the future?
This is the review for the original commit, in case anyone is interested: https://reviews.freebsd.org/D26137
> The article starts as a gotcha piece
Haha, that’s the problem. You, Netapp, value saving face so very much that you are incapable of constructive response to well-meaning, fair, and honest criticism.
Thank you to Jason Donenfeld (Wireguard), Kyle Evans (FreeBSD) and Matt Dunwoodie (OpenBSD) for jumping in and fixing this in a week!
OpnSense is the truly open source alternative and is a solid option. It was started in protest of pfSense’s less open behavior.
That got me thinking what's so bad about returning true? What should they be returning?
Then I realized that what article must is trying to complain about is: "Validation functions which ALWAYS return true".
Code quality (especially when written under pressure) is unrelated to that and I've seen horrible code from from model citizens who check all the Twitter boxes of goodness.
It seems very dangerous to contribute to open source these days if you are not in the right Twitter cliques.
The nice thing is that the FreeBSD developers who were interviewed apparently remained fair and said that the target had produced high quality code before.
Nope. Lots of people contribute to Open Source without being in any Twitter cliques, they're just getting on with the work and doing their best.
One could also flip what you wrote, on its head and say "It seems very difficult to be visible in open source these days if you have been doing things that are illegal or frowned upon". It's the same thing, just without the persecution complex.
I don’t wish perpetual punishment on anyone for almost any reason. But still... it feels like some necessary self-improvement is sorely missing. I certainly say this as a person who is flawed and full of anti-patterns.
Anyone who would try to drive people out of their homes by destroying them while they live in them is a terrible person without redemption.
His inability to turn away money to do work he had no intention or capability to complete just demonstrates this.
Perpetual punishment is pointless but everyone has a right to know the kind of person they are dealing with.
The story is relevant, because:
1. It was already out there in the public. Skipping it completely would be unprofessional.
2. It gives a possible explanation for low code quality.
3. The developer in question is open about his past.
4. Person who went so far as resort to destruction and deceit in the physical world, could easily cut corner in the code review process:
> Person who went so far as resort to destruction and deceit in the physical world, could easily cut corner in the code review process:
This is a very dangerous delusion. It implies that producing flawed code requires some kind of moral blemish, a flawed character, a bad person. Truly upstanding citizen and high moral character would never submit a buggy code, but one can't expect otherwise from a criminal.
Nothing could be further from the truth. In my decades-long experience reviewing what must be by now megabytes of code, the code quality has absolutely no relationship to the moral character. Best people can produce - and regularly do produce - very flawed code (very much including myself, of course), and even excellent coders can be busy, tired, have temporary slip of attention, be wrong about particular API or language construct, mistaken, suffer from a burnout or a work-life issue... Even at their best, people produce flawed code all the time - that's why we have code reviews in the first place! It's not to weed out "that kind of people" who try to sneak into our pristine cohorts - it's because producing good code is hard, and producing flawless code all the time is nigh impossible to do by a single person. A concerted effort of multiple smart people over time is required to achieve even imperfect, but acceptable quality - and perfection is still an unattainable goal. It's a hard work, and it can't be done alone - nothing to do with character flaws.
And yes, left to their own devices, even the best people are subject to cognitive biases and fallacies - that's why it's impossible to effectively review one's own code and you need peer review. Not because you're suspected in being a criminal or at least a sloppy coder - but because you're human and as such, your best effort will never be perfect, especially not at scales modern code is produced.
> It was already out there in the public. Skipping it completely would be unprofessional.
Nonsense. Nobody expects every article about a person to include their complete biography. People expect including relevant stuff and throwing out irrelevant one. What is unprofessional is brining in irrelevant details to smear the character of a person to prejudice the reader against him from the start (that's why this BS goes first and the substantial part goes later). Instead of trusting the reader to judge on substance, the hack first creates an emotional prejudice which would cloud the mind of the reader and make a pre-formed opinion before the substantial part ever begun.
“Neither Netgate's responses, FreeBSD Core's, nor the off-record responses we heard from independent FreeBSD community members lead us to believe that there was in fact any process in place that could reasonably have been expected to catch this issue prior to it going out into the world in 13.0-RELEASE”
But it would help if he made it clear why he felt this criticism was specific to FreeBSD release13. It sounds to a naive reader like a critique that could apply to much of open source software. The author didn’t say that, but it’s a reasonable extrapolation to make.
This defensiveness in FreeBSD's response, this reaction of minimizing rather than facing up to the seriousness of the problem revealed here, the attempt to redirect the conversation towards anything but the specific issue, only reinforces the impression that FreeBSD may not be ready to deal with it effectively.
Of course, as FreeBSD is open source, its users are in no position to demand anything, but any potential user may, and should, attempt to determine how likely it is meet her needs in all respects.
Sure, I'd prefer postfix, but if you're just sending local email out for system checks or whatever, sendmail's okay.