OpenBSD is "the way things should be" according to a certain group of people. Generally feels good if you're tired of the Linux Mexican design standoff, but will sometimes leave you either very happy or very confused depending on whether or not you're on the same page as the developers.
I haven't used NetBSD extensively myself, but it seems to be a pretty simple system with a focus on portability.
None of the above matters if what you want to use doesn't work on your hardware. Test each one.
IMHO:
FreeBSD = general purpose
(Open|Net)BSD = more specialized
> but it's really about what you want and what you need.
So I'm agreeing with you!
Meanwhile Linux is a breeze. Faster, more responsible pulling 650MB/s on AES cryptsetup benchmark. BTRFS is actually quite good and LXC replaces jails. Transfers can easily saturate my gigabit connection. Don't think I'm going back so soon.
>you can't run the big cores at full throttle all the time because they just use too much power.
Yes you don't do that...not even on servers (sometimes).
With a take like that you're either a CPU micro-arch engineer working at the bleeding edge of research in this area or you have no idea how this actually works. One of the major ways we power optimize a core is by just making all the variable size structures smaller. That is, fewer/narrower execution units, smaller ROBs, smaller caches, less deep predictors, etc. Less hardware running means less leakage, which is the knob we're talking about controlling with little cores.
Now, in theory you can partially power gate a cache to turn, say, a 6-way cache into a 4-way cache, but doing so is extremely complicated from a correctness perspective and is really not something anyone is actually doing today.
And, anyways, fwiw: area is not really the a concern for modern SoCs at this point, it really is an issue of power/thermals. The feature size has gotten so small that they can afford to pack in extra stuff like accelerators and get good value out of them on the basis that it allows them to expend less energy than if they were to just use the CPU. For example, one big reason you see a lot of mobile SoCs with dedicated hardware for inference is because they have space and doing it with dedicate hardware lets them avoid burning a ton of energy on the CPU/GPU.
Cpu(core) hot-plug and a unified cache is not something new, it's also really hard for the OS to get full load (eff+perf cores) without swapping in and out.
>area is not really the a concern for modern SoCs at this point
It is...it's called cost.
OpenBSD is focused on correctness, security ("secure by default"), portability, and good documentation. (it is my choice.) It is the only one I know of that has had only 2 of the worst kind of security hole (remote hole in default install) since about 1996. It is the source of pf (firewall) and OpenSSH and I think other things that are used elsewhere. OpenSSH is widely trusted. It is not as fast at disk i/o as FreeBSD and doesn't have ZFS or Bluetooth support, or USB support for some use cases, I gather (though I use it with some USB things all the time).
FreeBSD seems focused on performance and stability, and some people say it is not as secure as openbsd, especially out of the box. Other people debate, and on it goes. It has the most users of the 3.
NetBSD seems focused on portability, and ... I don't know, fun hobby-ness? I know least there.
Have to go with NetBSD there. :)
More seriously, you could give them test rides inside QEMU before you decide.
It's most known for its portability and the number of architectures it supports, which many interpret as a comment on the quality of its underlying architecture.
SDF runs on it so you can play with it there.
OpenBSD is known for its security but I've run into too many rude people in their community which has never happened to me with NetBSD, maybe just a coincidence.
FreeBSD is known for its performance and being more up to date with drivers, etc but feels more "messy" and therefore less BSDish to me.
Take all of this with a grain of salt, just one man's take.