Note that updates to this post are listed as addendums at the bottom, rather than removing sections that are no longer true in current versions of FreeBSD.
There is no definitive way of knowing how many security issues are present in a piece of software or a collection of software. You can only look at history and attitudes for a project (and perhaps other factors such as language used) and extrapolate from there.
> knowing what bugs exist or other issues that effect security is hard
I agree. For example, according to [1]: "In the autumn of 2004, [Dan] Bernstein taught a [University of Chicago graduate level] course about computer software security, titled "UNIX Security Holes". The sixteen members of the class discovered 91 new UNIX security holes. Bernstein, long a promoter of the idea that full disclosure is the best method to promote software security and founder of the securesoftware mailing list, publicly announced 44 of them with sample exploit code."
This was 15 years ago, but it does reveal just how hard it is to know how many vulnerabilities are out there.
It's both. There's a lot of prose questioning the intent and competency of FreeBSD developers. The addendum for instance smarmily suggests that the PTI patch had no review at all when it certainly did and the referenced post even contains a link to that review.
I take issue with you treating yourself more harshly than the OP's author treats his machine. Just to hit one point as the OP has all kinds of non-disputable other points, I'd wager no typical linux distribution ships with swap encryption enabled, do you know if any of them do?
Once you’re setting up a BSD, you’ve signed up for lots of post install configuration. The installers just aren’t meant to be as “batteries included” as a Linux installer.
I’d go so far as to say that you shouldn’t touch a FreeBSD or OpenBSD install unless you’ve already done and maintained a gentoo, arch, or LFS install.
OpenBSD is much easier to install and get working than any of the Linux distros you mentioned. Post install configuration might take all of an hour, and it's secure by default, unlike those mentioned.
And by "post install configuration," I mean adding XFCE or other DE or WM, along with whatever apps you like. No tweaking needed to close security holes.
There’s a bit of silliness with resource limits (that I think should be configured to match the user’s hardware or at least mentioned in the installer), but overall I agree completely. The base system includes a couple of window managers, including CWM which is quite nice. On a laptop you have to enable APM, but after that you’re just about done.
I’d say it’s about equivalent to a simple Arch install on easy hardware, although OpenBSD comes with quite a bit more security stuff pre-configured.
I suppose I could agree if only so the new FreeBSD user has a reference to compare by going through what the guys on the other side of the tracks have to do to rebuild everything from source, kernel and ports. For FreeBSD users its a pair of svn updates, a make world, maybe a reboot, and a portmaster -fa. From what I remember with slackware and from lightly reading advocacy threads like this one it's unusual for linux folks to build their own anything with the exception of the kernel.
I haven't touched any of those Linuxes yet run FreeBSD as my primary laptop OS, a home server and a few remote servers just fine. It takes more time to get FreeBSD running properly than, say, Debian, but nothing to put new users off. There are HOWTOs on how to get it quickly operational on a solid level, for example, for desktop use [1].
While you're doing the initial configuration, you get to learn a good deal about what the OS is made of. I found investing a little time to get familiarized with the system components results in more confidence as a user, rather than simply letting the OS do its magic and then wondering how it works later on. Like moving into a new house... You want to know where the fuses are and how to shut off the gas valve.
Most Linux images deployed on cloud providers I’ve seen don’t even have swap by default… it’s up to the user to add swap if necessary. I haven’t seen any installers default to encrypted swap, however.
Keep in mind that this article is specifically discussing defaults, though, not necessarily the overall potential for security hardening. There are certainly some security-related features FreeBSD is missing when compared to other BSDs (OpenBSD) or Linux distributions, but some of what is called out can absolutely be accomplished by system administrators after installation, or as part of image deployment… but it would be better if the defaults evolved to be more secure without extra configuration.
As general purpose operating systems go, there was another interesting article from earlier this year comparing popular Linux distros which found that Ubuntu (18.04) had the best overall posture with regard to use of hardening and mitigation mechanisms out-of-the-box vs. versions of CentOS/RHEL, Debian, and OpenSUSE at the time. Some of this was due to the newer Linux kernel version being used, but also thanks to hardening of binaries, etc.
> Our experiments indicate that Ubuntu 18.04 shows the largest adoption of OS and application-level mitigations, followed by Debian 9.
I think it’s probably because for server usage, RHEL/CentOS is used significantly more than Fedora (with its shorter supported lifecycle), and Fedora is essentially the upstream for shakeout testing prior to inclusion in RHEL/CentOS, so hardening and security technologies – e.g. SELinux, fstack-protector, etc. – are very close. RHEL/CentOS 7 was based largely on Fedora 19, and newly-released RHEL 8 is based largely on Fedora 28.
I was really interested in FreeBSD a while back. Guess I should look elsewhere after reading this since I'm kind of a newbie and it would've taken me a while to figure all this out on my own.
The point is you shouldn't avoid implementing best practice security because it will "never be on the network".
And quite frankly, deliberately shipping a product with gimped security, especially when it comes to OpenSSH, is kind of not very excusable and has nothing to do with "stability".
Not really, this guy is kinda missing the point of FreeBSD - which is stability not security. Many of these problems are overstated or non-issues for desktop systems. If you do have a need for any of the changes this guy is talking about, then you can make the change. If you just want max security, OpenBSD is a thing. But this list of complaints probably isn't much worse than many linux distros.
For context on "is FreeBSD any good?" > FreeBSD foundation has a list of testimonials from users of FreeBSD including Netflix, Whatsapp etc. Many security focused and trusted companies.
No, it doesn't. HardenedBSD is one guy who became sore when FreeBSD rejected his patches due to complete lack of design, simple and common C programming errors and overall extremely poor code quality. Despite being provided with the usual review and suggestions he kept submitting them like that and at some point FreeBSD devs became bored with his attitude and moved on. And that's how HardenedBSD came to life.
Author thought that having ASLR is absolutely must (hint: it's not[1].) HardenedBSD is poorly reviewed ASLR implementation by a person who didn't take criticism well + recommended new defaults from subj.
Later hBSD added neat things like different update mechanism (hint: it's the same minus delta patches), retpoline enabled by default a little earlier than FreeBSD and probably still haven't disabled it.
It's a fact that FreeBSD had poor defaults for ages and only recently (last couple of years) started cleaning things up. That said I never seen FreeBSD user running default system settings. Many not even running GENERIC kernel, me included.
I think FreeBSD has a lot of issues, but 90% are political bullshit.
It seems to mostly be a philosophical issue. FreeBSD security is certainly a lot better than it was, just expect that the defaults probably aren’t what you’re looking for.
OpenBSD developers almost always change features for security reasons. They aren’t afraid of writing their own utilities or maintaining entire projects to do things in a cleaner way. This can lead to compatibility and/or performance issues, but at the same time you get a very nicely integrated base system.
I know less about FreeBSD, but they seem to place more responsibility on the user for building a system using their primitives. The choices they make with regards to backwards compatibility and defaults make sense in this context. FreeBSD is also usually the first stop for ex-Linux users who have become disenchanted by systemd or other changes to the system.
Linux as a whole doesn’t really have to choose a side because distributions have their own opinions and there’s enough eyes across popular packages to have decent security while maintaining a huge number of features.
There are kernels of truth in this document that circle around a politics/bureaucracy issue in FreeBSD that has existed forever. But the overall motif about security is laughable diatribes of a typical OpenBSD fan that understands little about kernel work while flailing around about how secure their pet uniprocessor operating system is.. yes, uniprocessor. It is trivial to DoS an OpenBSD machine accidentally on any kind of modern hardware because the locking model is state of the art circa 1980. Security! The only real facepalm this document describes accurately is that FreeBSD still bundles sendmail. The rest of this is basically a slanted view of things that don't matter when running a high scale internet service with FreeBSD -- I know because I did so.
It does, the whole thing is a thinly veiled OpenBSD uber alles rant. The author's twitter bio states "i'm a weeb / dj / photographer that likes openbsd" -- The references in the doc to LibreSSL, OpenSSH purity, OpenSMTPD, pf "unmaintained", OpenNTPD are codewords for "OpenBSD is better than FreeBSD".
The article mentions OpenBSD 4 times (vs Linux 2, Windows 2), in all cases directly comparing a default or feature in OpenBSD to the same default or feature in FreeBSD. Whether the author is an OpenBSD fan or not, I didn't come away with the feeling that OpenBSD was the suggested solution to the problem.
I found it interesting, anyway, but didn't come away with any inclination to use OpenBSD on my next deployment.
It's the topic that matters, no? When talking about BSD security, comparisons to how a security-focused BSD does it seems fair to me. OpenBSD is indeed "better" than FreeBSD when discussing security defaults. Not features or performance, security. I felt the theme was also whether FreeBSD users were aware of the situation, and whether they were able to meaningfully consent to it because they're defaults after all.
I don't think I can agree scientifically. OpenBSD developers do subjectively seem to think more holistically about security, and having less features lowers the total number but not the ratio and in practice it doesn't seem to have what I would consider a statistical magnitude difference in the type and ratio of incidents that plague C Unix-likes. In the article the author links to one of Ilja van Sprundel's excellent talks; the takeaway is basically that more eyes actually work for security and you could therefore infer Linux is a magnitude more secure than BSD.
I've been quite negative in this thread because the overall debate on these topics is pretty frivolous. We already have the tools at our disposal to do magnitude greater secure software and splitting hairs over which BSD has better defaults is missing the forest for the trees.
>Do you have a specific language in mind that offers improvement?
Any language with memory and type safety should comprise as much as possible of the whole system. See the Singularity OS from Microsoft Research, or whatever that Rust OS project is called.
Almost all the major, nicknamed, headline-grabbing RCE bugs in the last two decades are memory or type safety issues in C or C++ code.
Every C or C++ developer claims safe code is possible or even easy in their favorite language, but history has proven them very wrong.
I'm not banking on any language shift at the moment but could see a plausible case in the past for Ada and maybe now Rust after some more years of maturity both down to the metal. But both of these suffer from some awkwardness around the toolchain for integration into a traditional BSD right now, at least Rust may overcome that in time.
syskaller is in use by the major BSDs and stricter compilers and other static analysis tools have been a far bigger impact IMHO than the OpenBSD style mitigations. I would like to actually see some kind of case studies where OpenBSD mitigations have protected a user where they'd have been let down by say Linux or FreeBSD or OpenBSD without them.
I think a less snake oil approach to security is done by the seL4 folks, the difference in approach makes the *nix security mitigation people somewhat cringe worthy.
As someone who hasn’t cared especially much about any *BSD since moving on from NetBSD, I can’t help but notice that a) your bio here calls out FreeBSD, and b) your posts here seem way more rant-like than anything in the post or the comment thread.
Maybe - and I'm only saying this because I care - there are a lot of decaffeinated brands on the market that are just as tasty as the real thing.
Heh except if you actually read the comments I present Linux as the high water mark twice for security and stability.
Maybe - and I'm only saying this because I care - you should consider through hiking and come back to the discussion when you are less easily offended by the facts at hand into low grade trolling and have requisite attention span and reading comprehension to participate meaningfully in the conversation.
Sure, say you configure a Linux, OpenBSD, and FreeBSD machine to provide some useful service. A "stack" as they call it these days. None of these OSes are going to have a large attack surface outside that "stack", and that is the primary liability in running an internet service. There are relatively rare occurrences like the TCP SACK bug that affected Linux and Netflix' non-default FreeBSD RACK TCP stack. Every UNIX-like written in C without formal verification is subject to incidents like that from time to time. Every other security concern is addressed in an OS-agnostic fashion with failure domains, limits of scope/networking, access controls, monitoring, and operations procedures.
Now what Linux, and to a lesser degree FreeBSD, can do is survive real world usage at scale. OpenBSD cannot. It would fall over or require magnitude more machine count to do the same workloads that people use Linux and FreeBSD to run. So all the exploit mitigation diatribe and "great defaults" and pet projects are cute but funny when you try and throw shade onto others with them. As I said, there are some kernels of truth that pertain less about security and more about overall health in FreeBSD this doc accidentally hits on, but running some hobby software like opensmtpd on openbsd isn't going to save the world from real cybersecurity issues.
Among those "cute pet projects" are OpenSSH, LibreSSL, OpenNTPD, and PF. The internet at large, and even FreeBSD itself, would be all the poorer for not having these projects available.
As someone who has run web servers with both FreeBSD and OpenBSD, I think some of your criticism in this thread is valid, but you really crossed the line into blatant fanboyism with that one at the least.
Only really OpenSSH from your list applies though.
LibreSSL isn’t really in widespread usage outside of OpenBSD and has still been vulnerable to some of recent the OpenSSL exploits.
OpenNTPD is more widely used but lots of people still go for other alternatives and frankly I’m not convinced OpenNTPD offers anything significant over the competition anyway.
pf is barely used outside of OpenBSD and frankly why should it be when Linux has iptables (which does the job well) and FreeBSD has ipfw (which also does the job well). pf is also a decent firewall but it’s also a crowded market with lots of really decent alternatives written by their respective platform hosts.
I do actually quite like OpenBSD though. But outside of OpenSSH, OpenBSD is slowly becoming less relevant to the wider industry as other platforms catch up on security and even over take in terms of enterprise features.
Could you elaborate on the issues with multiprocessing on OpenBSD? I haven’t had any difficulties running multiple Firefox processes across multiple cores on my machine. How have you DoS’ed it?
Yes, run https://github.com/antonblanchard/will-it-scale on operating systems with hilarious grandstanders like OpenBSD and Illumos, then run it on Linux and compare the results. Run a highly parallel make on a modern server and tell me which OS remains usable for other work. OpenBSD runs acceptably on 2-4 core laptops with HT disabled because a desktop workload doesn't typically invoke a lot of the kernel implementation during steady state, but you can do it there with a moderate disk and network load. That said, syscalls are more expensive in OpenBSD than contemporary operating systems so even as a uniprocessor OS it is funny.
Fair points. I’ll wager that most users are willing to accept the trade-offs in favor of security, given that it likely won’t affect most day-to-day usage.
(Also, I’m missing what’s so “funny” and “hilarious” about it.)
Will-it-scale has a dependency on hwloc which is not supported on OpenBSD.
Do you have a better synthetic benchmark to suggest?
And "speed" does depend on expectations. Compute tasks should be approximately equivalent, right? And os-limited tasks with many syscalls less so. You don't specifically state your expectations. Just that you are disappointed.
This is really the benchmark you want. There are only a dozen lines to patch. AFAICT OpenBSD neither has a cpuset(3) like API nor any intention of growing one, so you can just delete all the affinity code.
My main complaint about FreeBSD is basically an extension of the issue of poor defaults. They import features and third party software without planing out how it should fit into the system as a whole.
By far the worst offender i ZFS. Having ZFS as an option on FreeBSD (or Linux) is wonderful, but it's extremely clear where ZFS has its origin. ZFS feels like it was just bolted into FreeBSD and no one has a plan for making it feel like it belongs.
OpenBSD has been incredible successful in building a base system that feels like everything belongs together and working in a similar fashoin
My experience with FreeBSD is that the culture expects administrators to take on much more of a systems integrator role than most operating systems, somewhat like how Arch Linux or Gentoo compare to other Linux distributions. The overall experience is very different than either of those for a variety of reasons, but I think the similarities are there at a more abstract level.
Support for ZFS in FreeBSD installer, support for ZFS boot environments, etc, etc are surely the things that make you feel that ZFS was "bolted into" FreeBSD. Or, perhaps, you haven't used FreeBSD+ZFS as much.
I was thinking about the command line tools. It's extremely clear that they came from Solaris and there has been no effort made to make them feel more like they belong in a BSD system.
Why? It makes perfect sense to me. For something that should be shipped by default with an OS there should be one preferred option. It not like you can't install another after installation.
That's a lovely sentiment, and a great one to base a language that has an emphasis on instruction and readability on.
But unless you also wish to argue that "there should be preferably only one programming language", it also follows that there are other sentiments upon which to base languages.
Here's one that seems to fit the continuing analogy: TMTOWTDI.
The world has room for multiple philosophies, and that's a good thing. I happen to prefer PEP20 to TMTOWTDI, and Python to Perl, as might be expected.
I wasn't trying to say that there should only be one programming language, and I don't think it follows from the statement I quoted. I take it more like this: You use the correct tool for the job, and if there are inferior tools then just get rid of them.
In the context of the discussion, I happen to think that one packet filter/firewall in an OS is the correct number, unless each has significantly different uses. Such is not the case in FreeBSD.
I remember this from previous rounds of hn discussions, but I didn't catch last time that the author actually claims that having a code of conduct is distracting FreeBSD from adopting his favorite sysctl and rc.conf defaults. Kind of apples and oranges. Does not paint the author in a good light.
93 comments
[ 2.4 ms ] story [ 162 ms ] thread- https://news.ycombinator.com/item?id=11318508
- https://news.ycombinator.com/item?id=12484248
- https://news.ycombinator.com/item?id=16008688
Note that updates to this post are listed as addendums at the bottom, rather than removing sections that are no longer true in current versions of FreeBSD.
I'm curious about this statement. Which languages do you think indicate greater security, which ones tend to indicate the opposite?
However, knowing what bugs exist or other issues that effect security is hard. Let alone comparing.
I agree. For example, according to [1]: "In the autumn of 2004, [Dan] Bernstein taught a [University of Chicago graduate level] course about computer software security, titled "UNIX Security Holes". The sixteen members of the class discovered 91 new UNIX security holes. Bernstein, long a promoter of the idea that full disclosure is the best method to promote software security and founder of the securesoftware mailing list, publicly announced 44 of them with sample exploit code."
This was 15 years ago, but it does reveal just how hard it is to know how many vulnerabilities are out there.
[1] https://upclosed.com/people/daniel-j-bernstein/
I’d go so far as to say that you shouldn’t touch a FreeBSD or OpenBSD install unless you’ve already done and maintained a gentoo, arch, or LFS install.
And by "post install configuration," I mean adding XFCE or other DE or WM, along with whatever apps you like. No tweaking needed to close security holes.
I’d say it’s about equivalent to a simple Arch install on easy hardware, although OpenBSD comes with quite a bit more security stuff pre-configured.
While you're doing the initial configuration, you get to learn a good deal about what the OS is made of. I found investing a little time to get familiarized with the system components results in more confidence as a user, rather than simply letting the OS do its magic and then wondering how it works later on. Like moving into a new house... You want to know where the fuses are and how to shut off the gas valve.
[1] https://cooltrainer.org/a-freebsd-desktop-howto/
As general purpose operating systems go, there was another interesting article from earlier this year comparing popular Linux distros which found that Ubuntu (18.04) had the best overall posture with regard to use of hardening and mitigation mechanisms out-of-the-box vs. versions of CentOS/RHEL, Debian, and OpenSUSE at the time. Some of this was due to the newer Linux kernel version being used, but also thanks to hardening of binaries, etc.
> Our experiments indicate that Ubuntu 18.04 shows the largest adoption of OS and application-level mitigations, followed by Debian 9.
https://capsule8.com/blog/millions-of-binaries-later-a-look-...
And quite frankly, deliberately shipping a product with gimped security, especially when it comes to OpenSSH, is kind of not very excusable and has nothing to do with "stability".
https://www.freebsdfoundation.org/about/testimonials/
Author thought that having ASLR is absolutely must (hint: it's not[1].) HardenedBSD is poorly reviewed ASLR implementation by a person who didn't take criticism well + recommended new defaults from subj.
Later hBSD added neat things like different update mechanism (hint: it's the same minus delta patches), retpoline enabled by default a little earlier than FreeBSD and probably still haven't disabled it.
It's a fact that FreeBSD had poor defaults for ages and only recently (last couple of years) started cleaning things up. That said I never seen FreeBSD user running default system settings. Many not even running GENERIC kernel, me included.
I think FreeBSD has a lot of issues, but 90% are political bullshit.
[1]: https://arstechnica.com/information-technology/2017/02/new-a...
It would have been interesting to have some more info on this part too:
>It does not go in depth about changing FreeBSD's more serious low-level problems that require code changes.
Does anyone have any resources to read up on this? I’ve been reading “The design and implementation of the FreeBSD operating system” by the way.
OpenBSD developers almost always change features for security reasons. They aren’t afraid of writing their own utilities or maintaining entire projects to do things in a cleaner way. This can lead to compatibility and/or performance issues, but at the same time you get a very nicely integrated base system.
I know less about FreeBSD, but they seem to place more responsibility on the user for building a system using their primitives. The choices they make with regards to backwards compatibility and defaults make sense in this context. FreeBSD is also usually the first stop for ex-Linux users who have become disenchanted by systemd or other changes to the system.
Linux as a whole doesn’t really have to choose a side because distributions have their own opinions and there’s enough eyes across popular packages to have decent security while maintaining a huge number of features.
I feel very at home with FreeBSD and it has been a consistently good experience over many years.
I found it interesting, anyway, but didn't come away with any inclination to use OpenBSD on my next deployment.
I've been quite negative in this thread because the overall debate on these topics is pretty frivolous. We already have the tools at our disposal to do magnitude greater secure software and splitting hairs over which BSD has better defaults is missing the forest for the trees.
Do you have a specific language in mind that offers improvement? Or am I reading too much into the sentence?
>We already have the tools at our disposal to do magnitude greater secure software
Mind sharing more details on the tools? Specifically with respect to System / OS Level programming.
Any language with memory and type safety should comprise as much as possible of the whole system. See the Singularity OS from Microsoft Research, or whatever that Rust OS project is called.
Almost all the major, nicknamed, headline-grabbing RCE bugs in the last two decades are memory or type safety issues in C or C++ code.
Every C or C++ developer claims safe code is possible or even easy in their favorite language, but history has proven them very wrong.
syskaller is in use by the major BSDs and stricter compilers and other static analysis tools have been a far bigger impact IMHO than the OpenBSD style mitigations. I would like to actually see some kind of case studies where OpenBSD mitigations have protected a user where they'd have been let down by say Linux or FreeBSD or OpenBSD without them.
I think a less snake oil approach to security is done by the seL4 folks, the difference in approach makes the *nix security mitigation people somewhat cringe worthy.
Maybe - and I'm only saying this because I care - there are a lot of decaffeinated brands on the market that are just as tasty as the real thing.
Maybe - and I'm only saying this because I care - you should consider through hiking and come back to the discussion when you are less easily offended by the facts at hand into low grade trolling and have requisite attention span and reading comprehension to participate meaningfully in the conversation.
Now what Linux, and to a lesser degree FreeBSD, can do is survive real world usage at scale. OpenBSD cannot. It would fall over or require magnitude more machine count to do the same workloads that people use Linux and FreeBSD to run. So all the exploit mitigation diatribe and "great defaults" and pet projects are cute but funny when you try and throw shade onto others with them. As I said, there are some kernels of truth that pertain less about security and more about overall health in FreeBSD this doc accidentally hits on, but running some hobby software like opensmtpd on openbsd isn't going to save the world from real cybersecurity issues.
As someone who has run web servers with both FreeBSD and OpenBSD, I think some of your criticism in this thread is valid, but you really crossed the line into blatant fanboyism with that one at the least.
LibreSSL isn’t really in widespread usage outside of OpenBSD and has still been vulnerable to some of recent the OpenSSL exploits.
OpenNTPD is more widely used but lots of people still go for other alternatives and frankly I’m not convinced OpenNTPD offers anything significant over the competition anyway.
pf is barely used outside of OpenBSD and frankly why should it be when Linux has iptables (which does the job well) and FreeBSD has ipfw (which also does the job well). pf is also a decent firewall but it’s also a crowded market with lots of really decent alternatives written by their respective platform hosts.
I do actually quite like OpenBSD though. But outside of OpenSSH, OpenBSD is slowly becoming less relevant to the wider industry as other platforms catch up on security and even over take in terms of enterprise features.
(Also, I’m missing what’s so “funny” and “hilarious” about it.)
Do you have a better synthetic benchmark to suggest?
And "speed" does depend on expectations. Compute tasks should be approximately equivalent, right? And os-limited tasks with many syscalls less so. You don't specifically state your expectations. Just that you are disappointed.
I installed FreeBSD last night, you can just tick/untick these options during the install which addresses most of the article.
[ ] enable sendmail
[ ] enable sshd
[ ] enable ntp
[x] encrypt swap
By far the worst offender i ZFS. Having ZFS as an option on FreeBSD (or Linux) is wonderful, but it's extremely clear where ZFS has its origin. ZFS feels like it was just bolted into FreeBSD and no one has a plan for making it feel like it belongs.
OpenBSD has been incredible successful in building a base system that feels like everything belongs together and working in a similar fashoin
I think we are missing some context here?
The author never explains how 3 firewalls are bad. It seems this is probably some Linux hack trying to slander FreeBSD.
"There should be one-- and preferably only one --obvious way to do it."
But unless you also wish to argue that "there should be preferably only one programming language", it also follows that there are other sentiments upon which to base languages.
Here's one that seems to fit the continuing analogy: TMTOWTDI.
https://en.wikipedia.org/wiki/There's_more_than_one_way_to_d...
Now, you may not like that one, and that's fair. I frankly like Python less the more I use it, but it still has its place in my toolkit.
I wasn't trying to say that there should only be one programming language, and I don't think it follows from the statement I quoted. I take it more like this: You use the correct tool for the job, and if there are inferior tools then just get rid of them.
In the context of the discussion, I happen to think that one packet filter/firewall in an OS is the correct number, unless each has significantly different uses. Such is not the case in FreeBSD.