OpenBSD Innovations
openbsd.org
openbsd.org
I liked it because it was rock solid and configurations were simple and straightforward. It also made some things, like read-only bind mounts, easier than Linux did at the time.
However we finally gave up because the update/upgrade process was a big pain compared to Debian so it was harder to schedule updates, and because it was hard to find people who were familiar enough with it to take anything off my plate.
Now only using it for firewalls. Everything else on Debian linux which is slowly getting more annoyingly opaque with stuff like systemd that infuses magic and binary-format logs and stuff into things that used to be easy to debug. Who knows, maybe we'll be begging it to come back into our arms again one day.
I learned a ton, and definitely recommend this as the next step for someone who installed a BSD in a VM and is intrigued.
Edit: hardware for building a router that is.
It's small, quiet and has 2 ethernet for WAN and LAN and you can plug in an official USB Wifi dongle addon and it's good to go as a router.
You need to pick a few addons from the bare machine, like memory (I went with 8GB to run many containers), ssd (I went with m2 instead of emmc) and a case.
It's x86, so you'd have maximum compatibility for architectural differences.
Throwing a NIC in an old box works well, but any board with 2 or more network connections will suffice.
I just went to a local computer shop and picked up a HP desktop which was likely off a business lease, then tossed another NIC in. It works a charm and routes gigabit just fine.
https://man.openbsd.org/pf.conf.5
That + https://www.openbsd.org/faq/pf/example1.html were more than enough to get me going.
Then I installed FreeBSD on an arm based sbc I use as a server and NAS. It has been a joy to use there. Basically rock solid, and the scheduler seems to prioritize interactive processes so that even under heavy load I can diagnose what’s going on quickly. I now prefer it to Linux in shell environments. I also have openBSD on a thinkpad laptop, which has been fun
About which one to use, Manuel Kasper, the original m0n0wall author, encourages to use and contribute to OPNSense, which is also the one I would personally choose after [0] happened.
> This is a Cisco HSRP patent document with the word "Cisco" crossed out and the word "IETF" written in crayon.
That one got me.
When the first CARP release hit I immediately set it up on a pair of SUN Ultra1 pizza boxes I had gotten on eBay after the .com crash (with a third cold-spare) and ran that way for years. My ISP even called me at one point to find out what "those weird mac addresses" were on the SUN hardware.
They, of course, ended up being too power hungry and I moved to PC-Engines Alix boxes. When I wanted more horsepower as my internet speed increased, I moved first to a pair of PC-Engines APU boxes, and now to one APU and one virtualized OpenBSD firewall.
CARP has always been rock solid throughout, both on the internal and external interfaces of my firewalls. Rolling reboots for patches, updates, OS upgrades or hardware failures are a non-issue. No one in my family ever notices. Combine that with multi-homed ISPs and the internet at my house is more solid than a lot of enterprises and there's no expensive hardware or software involved.
I guess that was a long-winded way to say: Home consumers CAN benefit from high availability! It just isn't packaged in an easy to use or cheap enough form factor for them.
I used CARP for HAProxy in lab environments, but that is as 'close to home' as it got.
CARP is useful for any time you need to take a service down residing behind CARP. Updating an HAProxy box, for example. Failover/disable the node you'll be performing maintenance on, which is >0.1% of the year.
It's one of those problems that don't happen often enough for me to really spend time debugging, but is annoying nonetheless.
Long story short pay extra close attention when when mixing vrrp and carp on the same network segment.
https://queue.acm.org/detail.cfm?id=2090149
Key paragraph:
"The OpenBSD team, led as always by their Glorious Leader (their words, not mine), decided that a RAND license just wasn't free enough for them. They wrote their own protocol, which was completely incompatible with VRRP. Well, you say, that's not so bad; that's competition, and we all know that competition is good and brings better products, and it's the glorious triumph of Capitalism. But there is one last little nit to this story. The new protocol dubbed CARP (Common Address Redundancy Protocol) uses the exact same IP number as VRRP (112). Most people, and KV includes himself in this group, think this was a jerk move. "Why would they do this?" I hear you cry. Well, it turns out that they believe themselves to be in a war with the enemies of open source, as well as with those opposed to motherhood and apple pie. Stomping on the same protocol number was, in their minds, a strike against their enemies and all for the good. Of course, it makes operating devices with both protocols in the same network difficult, and it makes debugging the software that implements the protocol nearly impossible."
"As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization. Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112. We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply."
https://www.openbsd.org/lyrics.html#35
Obviously the correct thing to do is get numbers via IANA but what is the least wrong thing to do when your project is too small to do this. Camp on unused numbers? If your project is successful enough they will eventually be granted. Use whatever number matches the closest fit? Pick some screwball assignment that failed to gain any actual use?
There's very good reasons Git won, this is among them.
(Emphasis mine.)
Imagine if as a result all hardware would he compatible with all os’. Suddenly openbsd, freebsd and linux distros would be dominating the desktop.
To summarize: He mentioned a lack base posix utilities in these languages (posix compliant utilities), and that changes like this take a long time (stack protector took 10 years to implement), and that these new toolchains would dramatically increase build times (like haskell cgrep vs openbsd grep), and that openbsd requires that base can build base on all platforms and some of these languages won't work on some supported platforms (there wasn't enough address space on i386 for rust to compile itself, for example).
I realize some of this may be dated by now, but I assume the above are the types of concerns they would want to address.
So which of these layers upon layers of crap actually really, fundamentally fixes any of the core underlying problems (like using, in 2023, a memory unsafe language full of UB footguns to implement network facing services and not having the semblance of a proper security model)? Rather than just making them incrementally harder to exploit at the cost of ever increasing complexity and overheads that also get imposed on saner technologies which do not suffer from these problems in the first place?
How much faster (never mind secure, simple and robust) would our core computing infrastructure actually be if not everything was organized around a quixotic quest to partially mitigate some insane design decisions of C and the fact we're using a half-century outdated OS design?
And if you don't like OpenBSD, you can use something more secure, made with modern safe language or whatever it is you expect an OS to be.