Ars Technica article focused on Wireguard regarding FreeBSD

Not to speak of getting his commit bit restored under sort of "mentorship", after he managed to get his commit bit revoked.
I suspect that's where Netgate influence played a part.
 
By the way, what happened to "Ban the Box"?
How does his arrest record have anything to do with anything? We've been told repeatedly, by similar media outlets that "Box" is bad, and #banthebox
Who am I kidding!

Look at it from a different angle: people are worried because some code with security issues might have made it into a dotzero-Release.
They are not worried about code quality in general, they are just worried about their security, their own ass.
But they realize there is nothing they can do, there is nobody they could fire, there is no contract they could cancel. So they start looking for somebody to blame, for whatever crazy non-reason - because they have no better clue. They behave like Dilbert's manager.

That's bad enough and it wont' help. I don't know how California law treats tenants, but in some contries there is a serious problem, being practically impossible to get rid of them even when they rot the building. So there may be two sides to that story, and the conclusion might just be that there is a guy who takes action to get something done, which not necessarily is a bad trait - and it is entirely unrelated to coding quality anyway.

So, concerning the coding quality. A company would be oblidged to do something useful with their money in order to satisfy their customers, and this is (more or less) a self-regulating circuit. But FreeBSD is no company, and we cannot just move some money from development to testing. Things are done on best-effort, and so your security is built on a promise which is normally kept, but there aren't any guarantees. You have to live with that. (In commercial software there would be guarantees, but when it comes bad and your stuff is stolen, they are mostly useless.)

What worries me more is that there is a company, and that company puts money on the table to get some code done. Now their business equates their business, and so I wouldn't care about it at all, as I don't need to buy their products.
But it is FreeBSD where that code ends up. And one one side such is an important benefit to FreeBSD, but on the other side FreeBSD might become an instrument of foreign stakeholders with whatever agenda. And that is what I would worry about - much more than criminal records of anyone.
 
Personal conduct has little to do with skill and ability. See Ersoy (? Not 100% sure) for more on that. That guy could be a millionaire from his prize money in mathematics, but is more or less homeless and roams the globe. And he is reported to be socially challenged like RMS. But one heck of a math wizz.

So if someone deserves a commit bit should not be tied to anything but his skill - or we must sooner or later lay down where the line is between conduct and f.e. skin color or religion. Only factor should be skill, nothing else.
 
Nothing personal, sidetone, but I see that logic as flawed.
You're either misunderstanding, or you're not explaining yourself. I agreed with you on part about how, what Macy did as for that's software is DIFFERENT than what he did as a landlord. It's when things become extreme, as if he was a serial killer, or a total slimeball who stabs and robs people, where we wouldn't want him as a committer or want nothing to do with his software contributions regardless of his ability or even if he had perfect discipline on submitting code. When what someone does in their life, when it matters to something as software commits, only matters when either because we want nothing to do with him, or because his ethics in his real life will influence what he does as a software contributor.

The author of the Ars Technica article conflated unrelated facts, and didn't provide the whole story, just slammed Macy for associations.

Macy also got a criminal record for what he did, and he probably lost his property, when he fled for Italy. That's his real life punishment. His reputation as a committer is a different topic, that has nothing or little to do, with what kind of landlord he was.

Squatter's rights in some places are ridiculous. Like I said, someone off of the street can break into a home, occupy it, and have rights to live there. The property owner doesn't have rights to kick out the burglarizers or trespassers. It can be to the extreme, where, when the property owner finally gets them out, they smear shit on the walls. This is how ridiculous squatters rights are. It can be even, someone filing a false police claim on someone they live with. Then, when the person comes back from jail, the property owner has THEIR personal possessions damaged disrespected, thrown out, and CAN'T ENTER THEIR OWN HOME. It takes time to kick the squatter out, and damage is done. NOW, I KNOW that these were leased tenants who didn't do this, but it shows the crazy amount of leeway some tenants have to be unwanted. What was the reason the landlord wanted them out? Was it because they were horrible tenants, or didn't pay their rent for a year? Or was it because he wanted to build a parking lot.
 
The FreeBSD Foundation is a non-profit corporation/company. It has a lot of ability for what it has, but it doesn't have the funding like a major for-profit.
The FreeBSD Foundation was created in order to have a legal entity that can sign contracts. It was not intended to act as the general manager (aks supernanny) of the project.

But, like all adminstrative entities, it tends to be imagined as the "one in charge". This is the reason why administrative entities in general tend to always grow (usually without doing much good on the matter itself, because they weren't designed for that).
 
So if someone deserves a commit bit should not be tied to anything but his skill - or we must sooner or later lay down where the line is between conduct and f.e. skin color or religion. Only factor should be skill, nothing else.

So I'd be curious what was the exact cause that led to Matt Macy's commit bit being revoked the first time, and for which reason it got reinstated later?
While Matt Dillon's was not, even though everybody knows his skills are probably far superior compared to the big majority of developers?
 
IIRC, the most common cause is "commit bit taken in for safekeeping" - in other words, the committer has been absent from FreeBSD project work for a long time, or that the committer self asks for the commit bit to be taken in, because of ENOTIME to work on FreeBSD.
 
You're either misunderstanding, or you're not explaining yourself.
You seem to be contradicting yourself in those two statements and the one I pointed out before.

Though that may well be my brain full of toxins misunderstanding you. I can hardly make my own thoughts coherent in writing at times. And though my writing ability has come back since posting it's a short term stay.
 
Several FreeBSD community members would only speak off the record. In essence, most seem to agree, 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.

I am sorry, I don't have insights into the FreeBSD development process, but I was wondering if this is true. If it is, can someone explain what Phabricator is?
 
So if someone deserves a commit bit should not be tied to anything but his skill - or we must sooner or later lay down where the line is between conduct and f.e. skin color or religion. Only factor should be skill, nothing else.
No. Writing tests/constraints that unconditionally return true are not among the skills that I would consider the most wanted for a kernel developer. Together with that criminal record (self-justice driven by mere greed) and what he wrote afterwards, e.g. calling others "envious no-doers", while seeing himself as a mover & shaker, shows a certain mindset that is a very dangerous character trait to any engineering task. It takes some good amount of serious guru meditation to overcome such serious personal disablilities. IOW these so-called soft skills are equally important as the hard skills that define a gifted SW-engineer/programmer. Shame on those who granted the commit bit to him & maybe others of that same yukky mindset.
 
I do remember tales of a certain ReisswolfFs.

"Reißwolf" is a pictorial german word for a shredder, consisting of "reißen" (tear) and "Wolf" (wulf)…
 
I wonder how much hand wringing the author and commenters over there did regarding the development system for Linux that allowed code that broke hardware into an actually released version of the kernel and major distribution? With customer's computers physically broken and requiring system board replacements for a fix, it certainly should have risen to a greater scandal for the Linux community than a bad code getting into a pre-release version of FreeBSD then subsequently removed. Strange that I can't find any articles from Ars regarding that (may just be my bad searching skills).

My TLDR version of the incident:
Bad code got pushed into late pre-release.
Code review caught the bad code before it made it into release.
Review is happening to make sure bad code doesn't so easily make it that close to a release version.

But, the FreeBSD world is on fire, the OS is crumbling, and will soon be relegated to the dustbin of history, according to the article and commenters there.
 
I wonder how much hand wringing the author and commenters over there did regarding the development system for Linux that allowed code that broke hardware into an actually released version of the kernel and major distribution?
Although it's a horrible story, it's just whataboutism in this context. I don't care how bad Linux is, I care how great FreeBSD (normally) is.
Bad code got pushed into late pre-release.
Well, it got pushed into the development branch, but made its way unopposed up to 2nd release candidate.
Code review caught the bad code before it made it into release.
No, raised eyebrows from "outside" did that.
Review is happening to make sure bad code doesn't so easily make it that close to a release version.
That's the normal/expected course of things. Seems it didn't work too well here.
But, the FreeBSD world is on fire, the OS is crumbling, and will soon be relegated to the dustbin of history, according to the article and commenters there.
The article implying pars pro toto in a matter-of-facts style is yet another thing.
 
No, raised eyebrows from "outside" did that.
Yes, for me, this is the key part of it. It didn't (so far as I can see) get stopped by any FreeBSD developers, and that is an issue.

But I don't think there's any point ranting and raving or pointing fingers or getting personal about it. It does seem like a bit of a failure and it could have affected FreeBSD badly. Luckily it didn't. But something a bit stronger than luck is desired, and it seems that message is taken on board: https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057127.html

It's a volunteer project (mostly) - how are you helping improve things? The more people trying the BETAs and RCs and the more people actually reviewing code - the better. But I suspect most of us here (including I freely admit, myself!) will mutter something about skills and time and slink away leaving the hard work of reviews to the same tired core of people.
 
There are definitely problems.
I now worry, how far is it allowed/acceptable to constructively discuss what one thinks or worries about, only quoting source links from freebsd.org after doing hours of research in official pages, mailing lists archives, and phabricator?
 
can someone explain what Phabricator is?
From the Wiki: Phabricator is a FreeBSD-hosted service that provides pre-commit code review workflows.

A website where a developer proposes a change or addition to FreeBSD with code changes on display.
There are commiters who are summoned by 'Herald' the phab bot for code review and some commiters will set themselves as a reviewer.
So the code review should provide fixes for code style and function.
The code author has to fix code to pass go at each stoppage..
Then when enough reviewers approve it the code gets commited to HEAD.

So phab is a code fixup and review process.
Our code collabration tool.
 
On Saturday, I saw one comment about this on one of the mailing lists by someone who brought it up questioning why no one was talking about it. I didn't see any comments by anyone anywhere else that mattered. Probably no one on technical locations is talking about it cause no animals were harmed, no people were killed, it didn't affect 99% of anyone and the issue is being addressed by and for those who actually work on such things.

You don't do anything today that you didn't do last week. You won't do anything next month that you aren't doing now (except possibly experiment with WireGuard). All in all, when wg gets implemented, you'll be very happy and no one will be crying over spilled milk.
 
My point has been, and always will be, that the most important thing that happened is ... nothing.

You're kidding right? Sure, you're right, nothing happened but it wasn't through review or testing, but rather luck that the author of wireguard looked at the code and made it public. It's a bit like looking down the barrel of a gun and squeezing the trigger just hoping someone else has removed the bullet.

I call that BAD systemic practices and horrible non existent quality control.

I think this, as the article implies, leads to the larger question of "what else has FreeBSD missed?"

Obviously, FreeBSD has limited resources, but something this big, this complex, and ANYTHING involving crypto, should spend a long, long time in code review, testing and QA. Period.
 
The odds aren't astronomical that the author of his own program, knowing it was being ported to important OS'es, would look at it.

Perhaps, the amount of eyes watching it, were also a high amount, as there were a lot of fans of those who wanted to see WireGuard in FreeBSD and PF Sense. There was a lot of encouragement to get it in by fans for some time, and putting it in at the last minute will always be prone to problems.
 
I wonder how much hand wringing the author and commenters over there did regarding the development system for Linux that allowed code that broke hardware into an actually released version of the kernel and major distribution? With customer's computers physically broken and requiring system board replacements for a fix, it certainly should have risen to a greater scandal for the Linux community than a bad code getting into a pre-release version of FreeBSD then subsequently removed. Strange that I can't find any articles from Ars regarding that (may just be my bad searching skills).

My TLDR version of the incident:
Bad code got pushed into late pre-release.
Code review caught the bad code before it made it into release.

Code review was not by core but by the developer of wireguard. If he hadn't made it public, and FreeBSD 13 was out today, it would have that wireguard code in it.
They (core) escaped this by luck rather than good systems being in place.
 
You're kidding right? Sure, you're right...
You are agreeing that I am right and that is true--nothing happened. Thank you. How it got to that point is an issue that needs addressing as I have stated more than once. Going on and on about something that did not happen is pointless and time consuming for us and this thread that is only a concern for forums and Ars but nowhere else that matters.

I think this, as the article implies, leads to the larger question of "what else has FreeBSD missed?"
This is a horrible question to ask and I've seen it asked on the amateur forums and Ars, too. Every project everywhere has something that was missed and had close calls where one can ask that same question. Again, it's pointless to ask and only worrisome to those who only want to make themselves feel superior.
 
Back
Top