Comment by cperciva | Hacker News Reader

Comment by cperciva | Hacker News Reader

Parent Full thread

The recent WireGuard debacle left a bad taste about this. As it actually turns out, sometimes there is zero technical review for very important patches and a few blessed developers can (and sometimes do) just throw their stuff directly into trunk.

This seems like a misunderstanding of the FreeBSD development model. Yes, immature code landed in HEAD, but it was removed before the next release.

In general in FreeBSD there's no expectation that HEAD is always usable. Sometimes it won't even build! It's a place where code can land in the hope that it will be ready by the time the next release rolls around, but "remove code which isn't ready for prime time" isn't an exceptional case.

FreeBSD has a very strong history of post-commit code review, largely because every FreeBSD committer gets email when commits go into the tree -- that's a lot of eyeballs. We're moving towards increased pre-commit review thanks now that better tools are available for that, but that's a separate matter.

(Yes, Netflix runs FreeBSD HEAD. I think they're nuts.)

Thanks for clarification. Although IIUC the "bad" WireGuard implementation was stopped from being released just barely:

https://lwn.net/Articles/850098

It was rushed because a particular vendor wanted to have it as soon as possible. If not for Jason Donenfeld's diligence it looks like we would have out there in the open, full of bugs and all.

Doesn't seem like a normal occurrence though, seeing how much noise it made.

The WG code was introduced unusually late, I agree. Usually experimental stuff like that lands soon after a .0 release so that there's a year to iron out details before the next release. But this is a quantitative difference -- how close to the next release do you push experimental code into the tree -- not a qualitative difference.

And fundamentally the system worked! The code was deemed to not be ready and was yanked before the release.

https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...

> The three replaced almost all of Macy's code in a mad week-long sprint.

damn....

> Sleep to mitigate race conditions

ouch...

> Validation functions which simply return true

da f*

> strange hexadecimal output spamming the root console of their router

:D

> (Yes, Netflix runs FreeBSD HEAD. I think they're nuts.)

Sounds like chaos engineering to me ;)

Oh, they absolutely justify it on the basis that if a CDN node is unstable they'll just fail traffic across to another node. And as a FreeBSD developer I have to say that it's great having the OS (or at least the parts Netflix uses) stress tested -- you can't reproduce "1/3 of all internet traffic" in a test lab.

The reason I think they're nuts isn't stability but rather security. I guess since they're shipping these boxes around the world there's nothing really sensitive on them; but still, if I were in their shoes I would be worried about security bugs being introduced.

> The reason I think they're nuts isn't stability but rather security. I guess since they're shipping these boxes around the world there's nothing really sensitive on them; but still, if I were in their shoes I would be worried about security bugs being introduced.

Perhaps they have some really awesome IDS, and honeypots, and good security boundaries between components, etc. A company like that surely has a good plan in place.

Reply on news.ycombinator.com