Hacker News Reader

Comment by daenney | Hacker News Reader

It seems that a lot f the issues the author has they can fix by moving over to OpenBSD. I'd be curious to hear what makes them stick with FreeBSD instead considering the complaint.

View on HN

I'm not the OP but OpenBSD is missing some pretty key features. My reasons to use FreeBSD over OpenBSD are:

  - Virtualization (jails, bhyve)
  - Filesystems (ZFS)
  - beadm (which requires ZFS)
  - Linuxulator

Which really is a shame because philosophically I think I'd prefer the OpenBSD camp

Also:

  - LLVM
  - Arm support
  - The handbook

I do envy OpenBSD's pledge() and arc4random() though.

OpenBSD man pages and FAQ are really good too. LLVM is not in the base install, but you can install clang from ports and build a program if you need to.

I agree with pledge() and arc4random(). They are both ridiculously easy to use. FreeBSD has Capsicum but it doesn't seem to be integrated.

Oh, and FreeBSD has DTrace. Judging from some recent commits it looks like OpenBSD is going to get some sort of tracing framework.

> OpenBSD man pages and FAQ are really good too.

Absolutely! I didn't mention the man pages because all BSDs have really good ones and they all use OpenBSD's mandoc these days.

It's unfortunate that Shawn and Oliver decided, after failing to upstream their ASLR patches, to make HardenedBSD a full fork. I wish they would reconsider, because Konstantin Belusov has begun an upstream from scratch implementation of ASLR. But HardenedBSD is so much more than just ASLR and for a network facing OS it's crucial to have as many layers of mitigation as possible. Jails with Capsicum and ZFS are so promising already.

And let's not forget that OpenBSD doesn't make use of modern hardware as well as Linux and FreeBSD or DragonflyBSD. SMP incompleteness is one of the issues.

Given the focus on security, don't expect to see SMP anytime soon if ever. It's a huge source of potential security bugs and attacks on the kernel.

As with all things in computer science, there haven been successful implementations of anything that we see as unsolvable in a Unix-derivative. It's sad that so little of even non-research results has been incorporated into mainstream operating systems. I'm sure nickpsecurity can expand on this in detail, but let's just say Burroughs, VMS, Eros, L4 are all things that come to minds as ancient production quality software which solved issues fundamentally. For a newer strain have a look at Barrelfish.

I've never seen or expected to see "limit yourself to one processor for better security" as actual advice. Maybe this is sarcasm that I'm misreading?

OpenBSD supports multiple cores fine as far as userland goes. If you have 8 cores and start 20 userland processes, they'll be scheduled on all 8 cores. But yes, the kernel itself is not as fine-grain multithreaded as some others. Whether that matters depends on whether waiting on the kernel turns out to be a bottleneck for your workload.

The kernel is undergoing rapid work to distribute load among cores for major subsystems right now...

But in practice, partial fine-grained locking is as useless as partial security. Which is why nobody cares.

It might be ok for compute-only tasks that spread calculations over threads or processes in userland, but anything involving input/outpout (e.g. networking) will block.

Not at all, SMP opens a huge can of worms both for userland and kernel security. Suddenly you have all sorts of weird race conditions to deal with and in some kernels (cough XNU) logic bugs that stem directly from how kernel subsystems interact with threads. I don't blame OpenBSD for not going down that route.

Which is why DragonflyBSD was forked during the disagreement on FreeBSD's SMPng. Matt implemented more of a message passing system instead and Sepherosa Ziehau made all kinds of improvements to share as little as possible between cores and thus enable higher scalability in particular for networking.

> Which really is a shame because philosophically I think I'd prefer the OpenBSD camp

The friendliness of the FreeBSD community is why I wouldn't even consider going over to OpenBSD.

Jails are a mechanism, not the mechanism. OpenBSD has chroot for most of the same use cases. Virtualization is long overdue but it's coming. ZFS is not my kink but I get it why people want it. Having worked on CoW file system for three years I came to the conclusion that its perceived appeal is what sells it, but use cases are very few (if any) without system-wide control service. :)

I have not used beadm though - what's the kicker?

Virtualization for amd64 and i386 is in progress. Rapid development is taking place on vmm/vmd. There is a port of dragonfly hammer fs which is less rapid.

OpenBSD doesn't appear to have Infiniband support either. :(

I use FreeBSD for a fileserver because it has rock solid ZFS support. At least at the time I set it up (I haven't looked recently), neither OpenBSD nor Linux supported ZFS nearly as well.

In terms of tool/system integration FreeBSD's ZFS is miles ahead of ZFSoL and this is unlikely to ever change. FreeBSD has its own userland that does not need to run anywhere else; updating it to integrate new kernel capabilities is comparatively easy. This can simply not happen for ZFSoL in the same way, since it would split this integration over a myriad of projects and then still require a distribution to make all the right choices.

With regards to OpenBSD, I think it was at the last EuroBSDCon in Stockholm during Henning's talk when he said that "ZFS was not the solution" or something to that effect. Quite rich, I thought, coming from a platform where software-mirroring and disk encryption is an either-or decision (at least was at the time).

Author is an OpenBSD user/dev.

Reply on news.ycombinator.com