Not sure if it’s just the messaging but sacking someone from the team because a technology is switched sounds really weird. Even if said person is just on the core team because of said technology. Maybe my view on open source projects is simply different though.
If only if they’d support Dragonfly, OpenBSD or even NetBSD, I’d go opnsense.
FreeBSD is, to me, just a boring BSD that lacks leadership and just follows Linux’s decisions. This is why Dragonfly was forked, and as far as I am aware, nothing’s changed.
I’m sorry to ask, but what are you talking about? FreeBSD’s development seems to be completely unrelated to Linux’s, and why would I want an OS I rely on for infrastructure to be exciting? FreeBSD seems to have some of the best engineering (read, not hacking together random stuff until they feel it’s time for a release) I’ve seen in any OS, the system is consistent, the documentation is excellent, the system is reliable and provides the features its target users want. Th only complaint I have with it as a firewall OS is they never kept up with OpenBSD’s changes to PF, which means having to know two syntaxes if using both.
The highly praised cryptokey routing tunnel system that is available for Linux, MacOS, Windows, Android, iOS, OpenBSD and FreeBSD, as well as having a mostly-portable Go implementation?
I assume you are referring to the developer who implemented, poorly, wiregard in the kernel scheduled to release in FreeBSD 13, only to have it ripped out because there were major concerns brought up?
About FreeBSD being an unfortunate choice of an OS for opnsense to run on.
FreeBSD’s development seems to be completely unrelated to Linux’s
It isn’t, unfortunately. It copied the worst decisions Linux made, such as the fine-grained locks approach to SMP, and the complexity it brings. This is literally the reason Dragonfly exists.
For that matter, Dragonfly was relatively recently boasting about the superior performance of its network stack relative to both FreeBSD and Linux. An achievement that has nothing to do with putting more man-hours of effort (Dragonfly has few developers, and FreeBSD is a huge community with significant corporate funding), and everything to do with straight up better engineering.
the documentation is excellent
Yet FreeBSD is infamously significantly worse than NetBSD and OpenBSD in documentation. It might compete with Dragonfly on that topic, but only because Dragonfly is a small team which effort is focused on actual development.
provides the features its target users want
Excessively self-fulfilling statement.
as a firewall OS is they never kept up with OpenBSD’s changes to PF
Is one of many reasons I’d rather use something else as base for a router/firewall.
It isn’t, unfortunately. It copied the worst decisions Linux made, such as the fine-grained locks approach to SMP, and the complexity it brings. This is literally the reason Dragonfly exists.
That’s a lot of assertion. FreeBSD uses fine-grained locking because it has good performance and fits well with C. Linux uses a mixture of fine-grained locking and RCU. FreeBSD imported ConcurrencyKit a few years back and so now also has a rich set of lock-free data structures for use in the kernel. Dragonfly pushed in the direction of lightweight message passing, but it’s not clear from any of the concurrency benchmarks that I’ve seen that this was in any way better (in general, I strongly prefer message passing and shared-nothing concurrency, but C is a terrible language for trying to use this kind of model).
The reason that Dragonfly exists depends on who you ask. If you ask Matt Dillon, it’s because N:M threading was a terrible idea and 1:1 threading was the right approach. If you ask any of the FreeBSD kernel developers who were around at the time, it’s because Matt Dillon kept committing broken code and shouting at people that they needed to fix the things he’d broken.
For that matter, Dragonfly was relatively recently boasting about the superior performance of its network stack relative to both FreeBSD and Linux
On what kind of workload? Netflix gets insane performance out of the FreeBSD network stack with large transactions by supporting in-kernel fast-paths for TLS (just the crypto, not the control-plane parts) and things like aio_sendfile. Last time I looked, they were getting around double the per-core performance with TLS that BBC iPlayer was getting from Linux without TLS. At the opposite extreme, Verisign was running half of their root servers on FreeBSD (half on Linux, so a bug in one wouldn’t take out the entire root) and servicing a lot more requests from the FreeBSD ones, particularly the subset of those that were using netmap with an aggressively specialised userspace network stack. Netmap is enabled for pretty much all NICs in FreeBSD, it’s available as a patch set for Intel NICs on Linux. DPDK provides similar abstractions now, but Netmap has been in-tree in FreeBSD for over a decade.
FreeBSD was not copying Linux with Jails, it was the first such system to exist in any operating system. Linux now tries to build the same abstractions out of namespaces, cgroups, seccom-bpf, gaffer tape and string. FreeBSD was not copying anyone with Capsicum, which still provides the best set of abstractions for writing compartmentalised applications of any OS. FreeBSD and Linux were both copying the same systems with the TrustedBSD MAC framework and KSMs, but the FreeBSD version is a lot more flexible.
Dragonfly pushed in the direction of lightweight message passing, but it’s not clear from any of the concurrency benchmarks that I’ve seen that this was in any way better
Message passing does lead to a more structured design, which has a myriad of benefits. When the difference in terms of development manpower is taken into account, there’s no doubt that the approach Dragonfly took was the better one in hindsight.
Yes, there is no doubt FreeBSD is better than Linux, but that is a low bar to meet.
FreeBSD was not copying Linux with…
See above. Linux is a mess and should be the textbook example on how not to do software development. FreeBSD has it beat by actually making decisions on where to go and following through.
It is just that they will many times blindly go forward with what Linux did. The fine-grained locks over message pasing was a fundamental fuckup I simply can’t pretend didn’t happen and makes me sad to think about every time FreeBSD comes up.
I believe the effort overhead associated to it will in time put FreeBSD (and Linux) very clearly behind Dragonfly in performance / scalability. And that wall will actually be insurmountable due to fundamental architectural issues, not something that hacking in some optimizations will get anywhere close to breaking.
To be honest, so many of the FreeBSD distros like PC-BSD and OPNsense seem to be filled with a lot of…. drrama. I think I’ll stick with base FreeBSD since I don’t want the rug pulled out from under me.
I’ve also noticed this and wonder what the issue actually is? My guess is that the *BSD style of integration of kernel + base system makes forks and “addons” more difficult to maintain since you always have to keep up with main. Any disagreement in direction in base is gonna be painful…
Contrast this with Linux, in which distros are figuratively a boxed Lego Kit. Construction of derivatives from base is reassembling a car into a truck and adding a truck cap from your “library” of parts.
Not sure if it’s just the messaging but sacking someone from the team because a technology is switched sounds really weird. Even if said person is just on the core team because of said technology. Maybe my view on open source projects is simply different though.
If only if they’d support Dragonfly, OpenBSD or even NetBSD, I’d go opnsense.
FreeBSD is, to me, just a boring BSD that lacks leadership and just follows Linux’s decisions. This is why Dragonfly was forked, and as far as I am aware, nothing’s changed.
Is it a disadvantage to be boring in the world of firewalls?
I’m sorry to ask, but what are you talking about? FreeBSD’s development seems to be completely unrelated to Linux’s, and why would I want an OS I rely on for infrastructure to be exciting? FreeBSD seems to have some of the best engineering (read, not hacking together random stuff until they feel it’s time for a release) I’ve seen in any OS, the system is consistent, the documentation is excellent, the system is reliable and provides the features its target users want. Th only complaint I have with it as a firewall OS is they never kept up with OpenBSD’s changes to PF, which means having to know two syntaxes if using both.
Have you heard of wireguard?
The highly praised cryptokey routing tunnel system that is available for Linux, MacOS, Windows, Android, iOS, OpenBSD and FreeBSD, as well as having a mostly-portable Go implementation?
No, tell me more.
I assume you are referring to the developer who implemented, poorly, wiregard in the kernel scheduled to release in FreeBSD 13, only to have it ripped out because there were major concerns brought up?
Your point?
About FreeBSD being an unfortunate choice of an OS for opnsense to run on.
It isn’t, unfortunately. It copied the worst decisions Linux made, such as the fine-grained locks approach to SMP, and the complexity it brings. This is literally the reason Dragonfly exists.
For that matter, Dragonfly was relatively recently boasting about the superior performance of its network stack relative to both FreeBSD and Linux. An achievement that has nothing to do with putting more man-hours of effort (Dragonfly has few developers, and FreeBSD is a huge community with significant corporate funding), and everything to do with straight up better engineering.
Yet FreeBSD is infamously significantly worse than NetBSD and OpenBSD in documentation. It might compete with Dragonfly on that topic, but only because Dragonfly is a small team which effort is focused on actual development.
Excessively self-fulfilling statement.
Is one of many reasons I’d rather use something else as base for a router/firewall.
That’s a lot of assertion. FreeBSD uses fine-grained locking because it has good performance and fits well with C. Linux uses a mixture of fine-grained locking and RCU. FreeBSD imported ConcurrencyKit a few years back and so now also has a rich set of lock-free data structures for use in the kernel. Dragonfly pushed in the direction of lightweight message passing, but it’s not clear from any of the concurrency benchmarks that I’ve seen that this was in any way better (in general, I strongly prefer message passing and shared-nothing concurrency, but C is a terrible language for trying to use this kind of model).
The reason that Dragonfly exists depends on who you ask. If you ask Matt Dillon, it’s because N:M threading was a terrible idea and 1:1 threading was the right approach. If you ask any of the FreeBSD kernel developers who were around at the time, it’s because Matt Dillon kept committing broken code and shouting at people that they needed to fix the things he’d broken.
On what kind of workload? Netflix gets insane performance out of the FreeBSD network stack with large transactions by supporting in-kernel fast-paths for TLS (just the crypto, not the control-plane parts) and things like
aio_sendfile. Last time I looked, they were getting around double the per-core performance with TLS that BBC iPlayer was getting from Linux without TLS. At the opposite extreme, Verisign was running half of their root servers on FreeBSD (half on Linux, so a bug in one wouldn’t take out the entire root) and servicing a lot more requests from the FreeBSD ones, particularly the subset of those that were using netmap with an aggressively specialised userspace network stack. Netmap is enabled for pretty much all NICs in FreeBSD, it’s available as a patch set for Intel NICs on Linux. DPDK provides similar abstractions now, but Netmap has been in-tree in FreeBSD for over a decade.FreeBSD was not copying Linux with Jails, it was the first such system to exist in any operating system. Linux now tries to build the same abstractions out of namespaces, cgroups, seccom-bpf, gaffer tape and string. FreeBSD was not copying anyone with Capsicum, which still provides the best set of abstractions for writing compartmentalised applications of any OS. FreeBSD and Linux were both copying the same systems with the TrustedBSD MAC framework and KSMs, but the FreeBSD version is a lot more flexible.
Speaking of RCU style things, SMR was introduced for memory and is now also used by vfs.
Message passing does lead to a more structured design, which has a myriad of benefits. When the difference in terms of development manpower is taken into account, there’s no doubt that the approach Dragonfly took was the better one in hindsight.
https://www.dragonflybsd.org/performance/
The network perf data I was thinking about, took a while to find: https://leaf.dragonflybsd.org/~sephe/perf_cmp.pdf
Yes, there is no doubt FreeBSD is better than Linux, but that is a low bar to meet.
See above. Linux is a mess and should be the textbook example on how not to do software development. FreeBSD has it beat by actually making decisions on where to go and following through.
It is just that they will many times blindly go forward with what Linux did. The fine-grained locks over message pasing was a fundamental fuckup I simply can’t pretend didn’t happen and makes me sad to think about every time FreeBSD comes up.
I believe the effort overhead associated to it will in time put FreeBSD (and Linux) very clearly behind Dragonfly in performance / scalability. And that wall will actually be insurmountable due to fundamental architectural issues, not something that hacking in some optimizations will get anywhere close to breaking.
It must be hard being a contrarian in the face of people who actually do the work. Or not really addressing any of their points.
Let me fix that for you:
Message passing may lead to a more structured design, which might result in a myriad of benefits.
I thought message passing used fine grained locks, just down one abstraction layer
To be honest, so many of the FreeBSD distros like PC-BSD and OPNsense seem to be filled with a lot of…. drrama. I think I’ll stick with base FreeBSD since I don’t want the rug pulled out from under me.
I’ve also noticed this and wonder what the issue actually is? My guess is that the *BSD style of integration of kernel + base system makes forks and “addons” more difficult to maintain since you always have to keep up with main. Any disagreement in direction in base is gonna be painful…
Contrast this with Linux, in which distros are figuratively a boxed Lego Kit. Construction of derivatives from base is reassembling a car into a truck and adding a truck cap from your “library” of parts.
This is why, in my narrow opinion, cathedral style development has won over bazaar style.
It’s won? Many Linux distros are bazaar style (e.g. Debian or Arch), as well as Linux itself.
I remember that at one point the OPNsense project wanted to support different BSD bases including OpenBSD. It seems this never materialized.
SecurityRouter is based on OpenBSD, and it’s awesome, but unfortunately it’s being abandoned and no longer supported starting in 2022.