Invented by OpenBSD

I'm all for open source all the way, especially on a secure system, but OpenBSD+nVidia is basically unusable on the desktop. And that's a huge class of systems. You can't buy Intel PCIe cards; and AMD drivers are always a buggy mess.

> PF version runs on multiple cpus (OpenBSD's version is more advanced though)

I really hate the trade-off of FreeBSD SMP support, or OpenBSD queuing support. (yes, you can compile a FreeBSD kernel with ALTQ, but it's said to be buggy with SMP.)

> - FreeBSD Jails and Mac (These are extremely strong security features if implemented correctly. Especially jails are really undervalued/misunderstood IMHO.)

Aren't these are only necessary if you let people you don't trust into your system?

> - PF version runs on multiple cpus (OpenBSD's version is more advanced though)

Personally I dislike running PF on FreeBSD as it requires me to resort to old docs and use old syntaxes.

> - Capsicum (security)

Isn't this being ported as we speak?

For me, not being able to run a current kernel-accelerated qemu is a real problem. Is there anything preventing this work from being done, or is it just a matter of bhyve having the momentum so nobody's bothering?

Can you be more specific about that comment?

In particular FreeBSD security is so abysmal, once you plug it to the internet you can't really say is your computer anymore.

Edit: Downvote this: Windows Vista had ASLR and latest FreeBSD 10 does not.

5 years of base system support for a release branch with rolling-release ports/packages vs OpenBSD's "1 year and you're unsupported" model.

My recollection was that OpenBSD code was actually quite polished, and even elegant in lots of places. They also produced what I think were easily the best and most complete manpages out there. It was actually enjoyable to read both the code and manpages, and pretty easy to understand (assuming proficiency in C and basic machine architecture, of course).

What was not enjoyable, for me, was the constant hostility on the mailing list and frequent lashing out at others in various OSS communities (...as demonstrated in the OP). I know there there were others for whom that played no small part in their loss of interest in the project.

I wonder why you think so. I've only ever used OpenBSD and NetBSD on PCs and Unix workstations. I have never, ever, in any domain found NetBSD to have more "polish" than OpenBSD.

From the initial installation where OpenBSD helps you with everything and NetBSD, well, doesn't, to reading and using documentation (OpenBSD's man pages are the best around, with the possible oddball exception of some old Open Group pages which include code examples), OpenBSD seems to be miles ahead.

So I just wonder what you're talking about specifically.

Having seen NetBSD's source code more than once, "clean" is not exactly the thought that always comes to mind. Au contraire, OpenBSD has a simplicity-driven approach that's one of the cornerstones of most of the awesome stuff that they achieved.

That being said, NetBSD's build system is very good. OpenBSD's doesn't help too much in the portability department.

I was a huge NetBSD fan for many years, but I moved to OpenBSD about 6-7 years ago because I felt it actually had more consistency and polish. It's been so long now though that I don't remember specifics.

Form what little I've seen of the OpenBSD folks, having sound engineering and architecture is exactly how they attack security.

> NihBSD

Or SourgrapesBSD ? It's not clear that this was written "just to be different".

Edit: Yes, I missed it.

While the OpenBSD guys can be obnoxious twats at times, they were definitely in the right when they forked the OpenSSH code.

NetBSD's implementation, specifically with regard to how it handles deallocation, diverges from OpenBSDs - though its documentation is wrong.

LibreSSL (for example) will compile just fine on NetBSD, but as the logic of the two implementations differ so too will correct memory management in LibreSSL. This is just one example of how a port of secure code can be made insecure.

So it doesn't have to do with reallocarray specifically. It has to do with drawing out the security implications of the article under discussion.

And I got completely tired of "distributionitis" on Linux--"Oh, you can't upgrade that particular package without upgrading every other package on the system."

Modern Linux distros are messy and complex. I'm sure it's for good reason, they provider a ton of feature and tools for running very large installations. I just don't need that, we don't have more servers than you could reasonably manage manually.

I miss the consistency and simplicity of OpenBSD every time I log into one of our servers.

NetBSD very recently imported these functions (reallocarray and strtonum) to libc after much objection (over several years actually) to their poor APIs, yet finding that they crop up time and again in code used in base (and then multiple copies exist, in out of the way places). So, as a pragmatic solution they are now available from libc if _OPENBSD_SOURCE is defined. Cleaner API functions were proposed, with wrappers which would provide equivalent functionality for the OpenBSD functions. Some difference was noted, and recently fixed in these wrappers.

The root cause for the NetBSD changes then, seems to be that these functions keep cropping up, and the job of libc is to provide commonly used functions.

I believe the intention is, that the cleaner API is proposed to replace the original OpenBSD ones, which are not properly portable (strtonum for instance, returns hard coded english error strings in ASCII)

The root cause for the blog entry by Ted Unangst is probably that he is an OpenBSD developer and was involved in creating these functions, which are now being criticised.

These root causes don't seem the same to me.