Ars Technica article focused on Wireguard regarding FreeBSD

Thanks, but I learnt long ago to largely stay away. The message seemed loud and clear, that FreeBSD -CURRENT was unwelcome in any context in the FreeBSD Forums. I ceased showing my version of FreeBSD in my signature, and so on.
 
Thanks, but I learnt long ago to largely stay away. The message seemed loud and clear, that FreeBSD -CURRENT was unwelcome in any context in the FreeBSD Forums. I ceased showing my version of FreeBSD in my signature, and so on.
This doesn't seem to be the intention. It's just to make clear not to look for support regarding -CURRENT.

Of course, with these forums largely structured as "support forums", there's not much room left where -CURRENT would be considered on-topic ;) But that's still different from "forbidden".
 
  • Thanks
Reactions: a6h
I spend far more time in Reddit than here because sadly, discussion of -CURRENT is forbidden.
Forums is targeted at end-users, i.e. RELEASE users
1. John is using or going to use the system, as is.
2. John has some questions and/or problems about that.
3. To John, FreeBSD is a production system.

Consequently, Forums is not a place for following discussions:
1. Whether OS is dead, alive or have a future.
2. How to change, improve or destroy it.
3. Why it's not this, or not that.

CURRENT is forbidden, because
1. CURRENT != production. That's the whole point.
2. /src goes bad, OS goes south. You should know enough, looking for a way out.
3. Thus, we have mailing-lists, the de facto centre of such discussions.
 
CURRENT is forbidden
But … it isn't ;) At least, that's too simple and isn't stated that way anywhere in forum guides and rules.

What's stated clearly is that no support for -CURRENT is given and questions seeking for help with it aren't welcome … and that makes sense, as you explained.

Some general discussion in the "off topic" area (that isn't exactly off-topic IMHO, just more discussion than support character) about -CURRENT would probably be fine. The important question is, does it also make sense? As soon as technical questions are touched, of course the mailing list is the much better place, cause a lot of people read and write there and you will find the necessary knowledge.

But I think you could come up with something touching -CURRENT that could make sense here. Just as one scenario I can come up with spontaneously: There is a forum about porting software. If you want to do a full build test of your ports, you will need -CURRENT. Depending on the context, mentioning this could be helpful – of course, for questions about it, it's "move to the mailing list" again.
 
  • Thanks
Reactions: a6h
  1. sed 's%John%(failure|???|gh_origin)%g'
  2. sed 's/such\ discussions/universe/'
Yes. That's the best way to describe it. Nice ;)


But … it isn't ;) At least, that's too simple and isn't stated that way anywhere in forum guides and rules.
You're correct. It's not as strick as the way I've described it. That's why it's a good thing I'm not a Mod. If I was, people were getting ban, left and and right. Member numbers never pass 3 digits!
 
I finally found some official information:

https://docs.freebsd.org/en_US.ISO8859-1/articles/committers-guide/pre-commit-review.html

I see 2 things:

All non-trivial changes should be reviewed before they are committed to the repository.

Code review can be an iterative process, which continues until the patch is ready to be committed. Specifically, once a patch is sent out for review, it should receive an explicit “looks good” before it is committed.

Which all makes sense to me.
So basically this guy totally neglected common sense official guidelines. Not good.
Not sure why this hasn't been made more formal with the use of some tools; maybe it's a way to play nice when developers are actually willing to be nice.
Okay, maybe I would request reviews for all changes, not just the non trivial ones, but in general I don't think it's a problem with the process per se. They do the right things, it's just how they implement them in the process.
Even having some respect for the basic concepts of the agile philosophy, I would say some things should be a bit stricter. Unfortunately you can't always expect nice guys.
 
Thanks, but I learnt long ago to largely stay away. The message seemed loud and clear, that FreeBSD -CURRENT was unwelcome in any context in the FreeBSD Forums. I ceased showing my version of FreeBSD in my signature, and so on.
I would expect overall support is really the domain of the mailing lists for current. If you need support for current, you're probably not supposed to use it. If you want to give feedback for current then PRs and mailing lists are your destination.

I think that's the determination for the forums' rules (as I see it).
 
This is in the off topic section in terms of a production or stable release, and it's enough the topic of FreeBSD about FreeBSD as a whole. That guideline is about asking help or for technical information. It encourages mailing lists for technical help about CURRENT, because not enough users who use CURRENT are on the forum. It didn't say CURRENT can't absolutely be asked about here.

It's about FreeBSD. It's going to be discussed, maybe also here because this is the forum where common users use it, because there's a lot of chatter about it.

It got as far as STABLE anyway, if it were a purely technical discussion.
 
[...snip...]
So basically this guy totally neglected common sense official guidelines. Not good.
Yes. The fact he was able to is the problem.
Not sure why this hasn't been made more formal with the use of some tools; maybe it's a way to play nice when developers are actually willing to be nice.
Okay, maybe I would request reviews for all changes, not just the non trivial ones, but in general I don't think it's a problem with the process per se. They do the right things, it's just how they implement them in the process.
Even having some respect for the basic concepts of the agile philosophy, I would say some things should be a bit stricter. Unfortunately you can't always expect nice guys.

This I made indirect mention about a while back. It's the format of the FreeBSD core that's the issue, in that there's not one director or controller. Compare this to Linux, where Torvalds will just say yay or nay to such a thing.

This is not to say the way FreeBSD is run is bad, it's just different and autonomy is preferred. However, there needs to be, it seems, a better approach to getting stuff into the main branch without sufficient auditing. How this is achieved depends on the core team and also what the other developers are willing to accept. All code has reviewer(s), but is this sufficient? It seems this code was working to a number of people's satisfaction, sans the obvious bugs found at the last minute.

Finally, you cannot impose something onto a team of volunteers (mainly) that you would in a paid, work environment. You cannot implement such things as "agile philosophy" on a project like this.

In fact, pet peeve here, I've seen too many of these approaches in my working lifetime; they're junk (or maybe I'm too cynical - or both!).
<rant>I draw the analogy of a basketball coach, with 5 great 3-point shooters and no one over 6'4", attempting to play the post game. In other words, you work with the people and the business you have, not the approach of some 'guru' who had a book published as the next big thing.:rolleyes:</>

I apologise, I digress.
 
It could be simply, here's what's wrong, and FreeBSD and PF-Sense need better code review policies in their base.

The committer is going to lose the commit bit anyway if it hasn't already happened, after all of this.

GPLv2 code going from base to kernel would be an easy mistake to make, and getting help from the WireGuard author could have prevented this. As far as I know, the only reason the module was GPL was so the committer could make it work with Linux, and the commiiter had an interest in it working on FreeBSD. As a few have said, it didn't make it to the 13.0 release. Also, rushing things into a coming Release will always be prone to problems.

FreeBSD and PFSense also seemed to have gotten the message from the mistake.
 
Last edited:
It could be simply, here's what's wrong, and FreeBSD and PF-Sense need better code review policies in their base.

Instead, the author drags FreeBSD, PF Sense and WireGuard through the mud to get to his written agenda of FreeBSD needs better code review policies in its base. [...]

Acting like there's a fire emergency at FreeBSD, PfSense and WireGuard, and premising, these operating systems are so horrible they almost single-handedly had a cataclysmic failure that's going to end all existence of life is unhealthy.

"I have to set everything on fire and cause panic to get results!"

This method is impulsive and unhealthy.
Now as a reaction to your post I re-read that article again (3rd time). Sorry for the harsh wording: your post is close to complete BS... worst that I could find was that the author states:
How did so much sub-par code make it so far into a major open source operating system? Where was the code review which should have stopped it? And why did both the FreeBSD core team and Netgate seem more focused on the fact that the code was being disparaged than its actual quality?
Well, these are in fact legitimate questions, right?! Are you mixing up your personal aversions against "such extremes as squatter's rights" while at the same time calling for justice for one of those guys who kick each other's ass* to get a seat next to one of the math cracks in a univ's test? Did you verify if the tenants were perfectly legal tenants with a valid legal contract or squatters???
Enough. Your post is simply ridiculous. In no line in that article I can find FreeBSD is "dragged through the mud". It points out a serious problem and provides hard facts that you can prove yourself. Yes, it might seem to be yellow press style if you're a hardcore disciple of the almighty free BeaSD, but it does not contain any wrong infos FMLU. Please carefully & thoroughly check your biases.
* This is just wild guessing without proof. I do not know MM's marks/grades in math.
EDIT +hardcore before "disciple of the almighty free BeaSD"
 
The author didn't post both sides of the story. What you accused me of, the author is guilty of. This is my point. I didn't say, Macy was right, I said, both sides of that story weren't presented by the author, when I know there are extremes. Did the author who used the ad hominem do that? So then the author wants us to assume, that directly relates to the next point about software.
??? I can not follow. It all happens inside your brain. Your (not-so-free, because we all have a history) decision.
I also didn't say, there wasn't a coding problem. I'm for method of review being improved, which FreeBSD got the message. I said, this got blown out of proportion for something that didn't hit release.
If you didn't hear the bells ringing: it was in a release candidate revision. FreeBSD 13-RC something.
said that FreeBSD and PfSense got dragged through the mud.
FreeBSD dragged through the mud? Nowhere. The article explicitely states that contract to implement WireGuard into the FreeBSD kernel was without a deadline (which is highly questionable in consideration of what happened).
 
The article highlights issues with holes in the projects governance. A single committer (who happened to belong to a company with questionable business practices) manages to dump 40k lines of unvetted code into HEAD just on a whim. Something is wrong right there with that margin of freedom.

This is a sound article.
Totally agree! As a retired Oil & Gas industry Internal & Joint Venture Audit Mgr for 2 major oil companies, I'm sure that FreeBSD's image would benefit exponentially if the honchos would admit that their swamp needs draining - not now, but right now! A re-evaluation and restructuring of all internal controls is absolutely essential. Been there! Seen the very same thing! with corporate IS depts. OpenBSD may be silently positioning themselves in the wake of the mis-management?

Everybody can have a bad hair/code/whatever day! But proper internal controls will pick that up in jig time!!
BTW, I'm no developer or power user. Just an amateur enthusiast with my confidence in FreeBSD's commitment to clean code shaken.
 
I'm accusing you of nothing but to be biased & acting in reflex to protect your beloved pet. Your pet cat was unveiled to be a monster, a cruel killer occasionally, so you try to protect your pussycat. That's my oversimplified model of what happens to many of us disciples when we read that article.
And why did both the FreeBSD core team and Netgate seem more focused on the fact that the code was being disparaged than its actual quality?
And rightly so. I'm going to ask exactly that question when we'll have an Office Hours on that topic. I'm <subcomandante@freenode>. Sidenote: that last e-mail I quoted from <markj@> did read:
Dear FreeBSD Community,

In light of the recent commentary on FreeBSD's development practices,
members of the Core team would like to issue the following statement. [...]
and not
[...] the members of the Core team [...]
or
[...] all members of the Core team [...]
 
Guys, please don't get personal.
We should all be friends, as we love FreeBSD
:)

Being still curious, and trying to understand, I searched and read around a bit more.

Yes. The fact he was able to is the problem.
It was accepted by two users, a gmail address user and grehan, the maintainer of the PowerPC port, even though constantly new crashes and other serious problems surfaced.
This was sufficient to push the crap code on Nov. 29.
But there was no thorough code review.
Basically some installs and "works for me, except of the crashes".

FreeBSD developer danfe (Alexey Dokuchaev) joined the review on Nov 30, after it landed in -HEAD, looked at the code and immediately commented, but got ignored.
Until the bug fixing stopped when the review finally got closed by Matt Macy on Mar. 12, two testers continued to post lengthy bug/crash reports, which indicated that there were serious problems in many places.

This I made indirect mention about a while back. It's the format of the FreeBSD core that's the issue, in that there's not one director or controller. Compare this to Linux, where Torvalds will just say yay or nay to such a thing.
I couldn't find any hint that possibly people in the core team involved themselves in actual review.
No idea why, if wireguard was considered as an "important addition".
Blind trust in Macy, or fear of getting sprayed with s**t if/when the bomb goes off?
Or fear of being considered as a "nest polluter" if one dares to insistently criticize the obvious problems of a pride project ?

All code has reviewer(s), but is this sufficient? It seems this code was working to a number of people's satisfaction, sans the obvious bugs found at the last minute.
...when others started to actually look into the code.
Donenfeld, Kyle Evans and Dunwoodie intensively worked for almost two weeks, when on Mar. 15 Donenfelds' mail went out, which initiated the public popping of the Wireguard bubble.
So internally the bomb must have exploded not later than around end of February/beginning of March.

Now I am asking myself:
Was the import of the pfSense Wireguard fixes the wakeup call that triggered the chain of remedial events?


Because, it revealed the quantity and seriousness of the bugs fixed by Netgate until then.
I guess this could have been the time in which the formation of the already-mentioned three-men-emergency team occurred, when Kyle Evans looked at Matt Macy's work, had his OMFG moment, and contacted Donenfeld and Dunwoodie.

Look at the impressive list, which indicates which plenty of surprises can be found in Matt Macy's work:

List of Wireguard bugfixes imported from pfSense said:
Merge the following fixes from https://github.com/pfsense/FreeBSD-src
1940e7d3 Save address of ingress packets to allow wg to work on HA
8f5531f1 Fix connection to IPv6 endpoint
825ed9ee Fix tcpdump for wg IPv6 rx tunnel traffic
2ec232d3 Fix issue with replying to INITIATION messages in server mode
ec77593a Return immediately in wg_init if in DETACH'd state
0f0dde6f Remove unnecessary wg debug printf on transmit
2766dc94 Detect and fix case in wg_init() where sockets weren't cleaned up
b62cc7ac Close the UDP tunnel sockets when the interface has been stopped

This list gave keywords for the ArsTechnica article recherche, and it was easy to find a lot more issues.
So I don't think that ArsTechnica should be blamed.

Instead it should be asked, what led to such poor oversight of a such-promoted addition implementation work?
Which reforms could work preventing such happen again?

How can such investigation be done in an open way, so nobody does feel fear of speaking out?
I find revealing that the developers the ArsTechnica author spoke with, wanted to stay anonymous.
Fear of being open, this is not good.

The current handling of the issue reminds me much of the handling of the meltdown accidents in the Leningrad NPP in 1975, then again in Chernobyl 1982, and finally again in 1986, this time so massive that it could no longer be covered up.
The absolute secrecy was the cause that the same mistake was being repeated several times, at a big cost.

So, imho the first step reforming things should be to ensure nobody needs to be afraid to speak out, even when it might anger some brass hats.
Otherwise there cannot be true collective brainstorming.
 
It could be simply, here's what's wrong, and FreeBSD and PF-Sense need better code review policies in their base.
Yes.
Instead, the author drags FreeBSD, PF Sense and WireGuard through the mud to get to his written agenda of FreeBSD needs better code review policies in its base.
I don't think he does, BUT, he does try.
He alludes at a conflict of interest between Long and Netgate and FreeBSD and then presents no evidence of this, AT ALL.

He quotes "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."

I am not sure why the "community members" would want to "speak off the record" about commit bits. Seriously, this is just junk journalism at its finest. This story is more opinion than fact and we all know about opinions!

In fact, public information about commit bits is easily found. For example, expiry of bits and commit bits in general. Sheez, that was secretive stuff, hey?


According to the Salter, Macy is on the Most Wanted List. Knowing there's such extremes as squatter's rights, we didn't get both sides of the story. It goes to say, he's a criminal who threw old people down the stairs, then jumping to the next thing about software, without providing a rational relation of two separate subjects. As if the author has a personal vendetta against the committer. The committer is going to lose the commit bit anyway if it hasn't already happened, after all of this.

Putting aside the morals of Mr Macy, Salter does make the point that Macy was distracted by this. But, this is a lame excuse by Macy. Salter's reporting of it only seeks to downplay Macy's part. It's Macy's code, he has to be responsible for it. It was a bit of a mess, but more than that it was not reviewed sufficiently by either Netgate or FreeBSD. That's the troubling part.

GPLv2 code going from base to kernel would be an easy mistake to make, and getting help from the WireGuard author could have prevented this. As far as I know, the only reason the module was GPL was so the author could make it work with Linux, and the author had an interest in it working on FreeBSD. As a few have said, it didn't make it to the 13.0 release. Also, rushing things into a coming Release will always be prone to problems.
Because Macy copy/pasted large chunks of GPL, it would have been a problem. This all points back to Macy's integrity as a coder.
It's almost impossible to review code and look for contrary licensing, you just have to rely on the author to be ethical.
 
I read it again with better understanding of the different actors. It's less biased than I originally made it out to be.

Donnefield and others pointed out problems with the implementation into base of stable. It got that far, but the problems were known. Not as it were a completely hidden problem, that was easy to remove it due to known problems.

It would have been better if Macy didn't decline help by the WireGuard author to get it ported.

Edit:
It seems it's the way this information is presented to grab attention.

I also looked at the linked story about Macy as a landlord. He legally tried to get the tenants out for some time. Some laws about that are extreme. After that didn't work, he started doing illegal things to condemn the building after that didn't work. If the laws are, someone has 6 months or a few years notice to move out, or gets a discount on a few months rent that's perfectly good. If the laws are that, the landlord can't lose the tenants absolutely at all for a good reason, then... I don't judge so harshly. As I pointed out, some laws about this are extreme.

Macy made the wrong decision. For that, he lost half a million dollars, got a criminal record and was extradited from Italy for jail time.
 
So it looks to me like that the Core team left him his commit bit even through his four years in jail, while others get booted after 18 months without making a commit. Interesting!
This for itself is no problem IMHO. In contrast, a prisoner has plenty of time, and to do s/th useful can be vital in there.
 
grahamperrin Cause most redditors are children under 18 years old and never use FreeBSD even though they post there. On the mailing lists you'll find everyone using FreeBSD and most do as a career or a FreeBSD developer.
 
  • Thanks
Reactions: a6h
That's an outdated edition of the Guide. Instead:


For clarity:

https://docs.freebsd.org/en/articles/committers-guide/#pre-commit-review

Similarly, the first edition of the Ars Technica article referred to an outdated edition of the FreeBSD Handbook. In an e-mail to the author, I briefly explained and requested a correction, he was "happy to oblige".



I see 2 things:

> All non-trivial changes should be reviewed before they are committed to the repository.

… totally neglected …

For clarity: that (the first of two things) was not totally neglected.



Some problems with the the noise of controversy:
  • basic facts are overlooked
  • where there's reading between the lines, there's the danger of imagination being misrepresented as fact and then echoed (or up-voted) without challenge.
 
Back
Top