That doesn't reflect the reality of life for those in the bottom half of the wealth distribution, and especially for those in the bottom quarter. $30K is a lot of money to them. The 30th percentile of income in the US in 2023 was under $30K. They're hoping to grow their $50K to $100K or $150K before retiring at 70.
The user interface is literally 1000x better. That's all
Linux is enormously higher performance but it is a huge pain in the ass to squeeze the performance out AND retain any level of readability
which is why there are like a dozen vendors selling various solutions that quietly compile their proprietary filter definitions to bpf for use natively in the kernel netfilter code...
I just today deployed an $800 mikrotik in my house that can route 10 gbps at wire speed. on the CPU. with firewall and nat rules applied. no joke. 4 million packets per second is, like, a lot, post-filtering and with any substantial packet size.
This was doable back in 2008 with about $15k of x86 gear and a Linux kernel and a little trickery with pf_ring. The minute AMD K10 and Intel Nehalem dropped, high routing performance was mostly a software problem... Which is cool as hell, compared to the era when it required elaborate dedicated hardware, but it does not make it cheap or easy. Just, commodity. Expensive commodity.
Now you can buy a device off the shelf for $800 that will do it on the CPU, to avoid the cost of Cisco or Juniper, and it has a super simple configuration interface for all the software-based features. Everything you could do in L3/L4 on a Linux platform in 2008, for like, 1/16th the price, with vastly less engineering effort. It is just like, a thing you buy, and it all kinda works outta the box.
No pf_ring trickery, no deep in-house experience, just a box you buy on a web site and it moves 10 gbps with filtering for $800
There's no real magic here: they use absolutely shockingly enormous ARM chips from Amazon/Annapurna. You can build an $800 commodity platform that rivals a $15k commodity platform in 2008, and both of them replace what used to cost $500k.
Is it as good as Cisco or Juniper? oh, certainly not. Will it route and filter traffic at much greater rates, for $800, than anything they have ever been bothered to offer? ABSOLUTELY
I'm really confused by "about $15k of x86 gear ... The minute AMD K10 and Intel Nehalem dropped, high routing performance was mostly a software problem". What kind of $15k machine would you have needed? That's a heck of a lot more than even the most expensive K10 2008 CPU (which according to Wikipedia seems to be Opteron 8384 (quad core, 2.7GHz, 1.0GHz HT, $2149 November 2008), supports up to 8 CPUs per machine, I guess that's what you mean.)
OpenBSD's pre-journaling FFS is ancient and creaky but also extremely robust
I am not sure there is a more robust, or simple, filesystem in use today. Most networking devices, including, yes, your UPS, use something like FFS to handle writeable media.
I am not accustomed to defending OpenBSD in any context. It is, in every way, a museum, an exhibition of clever works and past curiosities for the modern visitor.
But this is a deeply weird hill to die on. The "Fast File System," fifty years old and audited to no end, is your greatest fear? It ain't fast, and it's barely a "file system," but its robustness? indubitable. It is very reliably boring and slow. It is the cutting edge circa 2BSD
edit: I am mistaken, the FFS actually dates to 4.1BSD. It is only 44 years old, not 50. Pardon me for my error.
OpenBSD FFS is robust in the sense of 'it is unlikely an FFS bug will lose your data'. But it is ancient, and, well, there are reasons for filesystem developments in the last half century, like 'not losing your data thanks to blackouts or hw bug'.
The lack of at least a journaling FS is inexcusable in a modern OS. Linux and Windows have had it for 25 years by now, and we could argue softupdates are roughly equivalent (FreeBSD has had SU+J for years now too).
This post sounded faintly crazy to me, so I went into a little wiki-hole consisting primarily of mailing lists and dev docs
Turns out, the main reason `pf` is non-portable is that half of it runs inside Berkeley-type network stacks, often in kernel space, but the remainder is in user space.
So the miserable single-threaded `pf` on OpenBSD is still, in some part, single-threaded on FreeBSD, but for certain rule-sets, you will get the benefits of FreeBSD's intensively re-entrant and multithreaded TCP/IP, because those parts of `pf` are embedded in the network stack.
So depending on workload, a given `pf` configuration on OpenBSD might be perfectly equal to its FreeBSD counterpart, or hundreds of times slower. I feel like this gives a lot of context to the OP's grousing around "10 gbps"
P.S. To confess my own biases: a port of a `pf` configuration to a platform where some rulesets are high performance and others are not, that would not be very attractive to me. An improvement, but not a solution. I would be looking to move to a Linux stack. Baby steps, I guess. I have done worse things to better people!
P.P.S. I suspect this coupling between a re-entrant TCP/IP stack and a single-threaded firewall process is also why FreeBSD `pf` is never even close to feature parity with its OpenBSD counterpart -- it is just easier to do new stuff with a simpler model
