FreeBSD is a compelling and cutting-edge operating system that provides a wealth of features and advantages. FreeBSD’s deep OpenZFS integration, completely customizable packaging, and the ability to manage a huge fleet with a small team make it a clear contender for consideration in your next infrastructure build.
This one’s written by a company that, among other things, sells FreeBSD and OpenZFS support, so take that into account when reading the article.
Well I can tell you a damn good reason not to use FreeBSD: through the only year I had tried to use it on a small server I got hit by a driver regression on a high end network card driver on a “stable” release. I have never touched that god forsaken OS since.
If you think that doesn’t happen on Linux and Windows alike you are very very very mistaken.
To my experience, sure this kind of stuff may happen on Linux, but few times I experienced similar issues, but the issues were fixed quite fast, or I was able to get a workaround. Worst case, you install another kernel version., Unless your distro is shitty or badly maintained (Ubuntu for Raspberry Pi is one of these bad apples), the security/regression fix updates are quite fast AFAIK 6 months later the issue was not fixed on FreeBSD. At the time, I switched to OpenBSD which was better for my usage, anyway.
Was it an Intel NIC? Intel actually contributes the software for those. It would have happend on linux and windows also. They share code.
laffer1,
Yeah, sometimes I wish they’d do a better job though. They were dragging users along for years about implementing the 802.3ax EEE feature for their x500 10gbe nics, listed in official hardware specs, up until they were discontinued.
https://community.intel.com/t5/Ethernet-Products/802-3az-EEE-support-on-X550-T1-2-NICs/m-p/284819
EEE is the energy efficiency standard for ethernet used to reduce the power consumption in standby state instead of using full power 24×7. EEE needs to be negotiated to reduce power of the NIC AND the switch it is connected to, otherwise they both use full power 24×7. On 10gbe equipment you can physically feel the difference in heat output.
https://www.eetimes.com/optimize-energy-efficient-ethernet-ieee-802-3az-performance-in-bundled-links/
These are very popular (and expensive) nics used in data centers. Because intel postponed driver support indefinitely, and despite it being on the official specs, intel’s non-support may single-handedly be responsible for megawatts/gigawatts of wasted power in data centers. 🙁
They were sold as new up until last year and are still under warranty. They’ll be in use for years to come but can’t go idle.
https://www.intel.com/content/www/us/en/support/articles/000026530/ethernet-products/legacy-ethernet-products.html
No, it was a 3Com.
Sorry, but this is not an article, but an advertisement. Klara is far from an unbiased source of information. It’s also clear that FreeBSD is a mere vehicle for Klara’s services, which seems mostly centered around ZFS.
In trying to plug FreeBSD, it is telling that it’s mostly recounting what FreeBSD has been in the introduction and not a whole lot of what it is now.
As a long-time FreeBSD user, and always looking for opportunities to wave a BSD flag, I have to agree with r_a_trip — this item is basically just a “glossy” sales brochure for Klara.
I’d say it’s in the infomercial category, which can be useful. I certainly learned some new stuff here, and since OSnews had the disclaimer I also know to be at least somewhat sceptical.
Eh, Reason #1 is fine. ZFS is good and what not, no disrespect for the level of integration in FreeBSD.
Reasons #2 and #3 are like 20 years out of date.
Does any company seriously want custom build commands for packages? That seems like an old thing we used to care about 20 years ago.
Fleet Management? Any orchestration tooling you’re going to use is going to be built for linux first and foremost. Having great config file set up only gets you so far.
Some companies still build custom packages to select different build options. It’s not a large audience, as I think most of us have moved to packages.
Most projects that are built on top of FreeBSD or based on it have moved to a package-first model. (GhostBSD, MidnightBSD, etc) (disclaimer: I’m the MidnightBSD dev)
I think FreeBSD can be a great server OS if you focus on it exclusively or first. If you’re trying to mix BSD and Linux systems on a network, it gets messy since most of the decent management tools are no longer cool in favor of k8s. The work to make FreeBSD more container friendly is progressing but it’s never going to be linux. That’s a feature to some of us, but it also complicates adoption. Between bastiellebsd and bhyve, you can do quite a bit though.
If anything BSD, I’m looking for the next PFSense based on OpenBSD since PfSense/Netgate abandoned it in favor of FreeBSD
Try opnSense https://opnsense.org/, built on FreeBSD, forked originally from pfSense and m0n0wall.
That looks pretty sweet, thanks for the link. But that is a good point, I like pfsense and some of the networking on *bsd better. They haven’t changed as much as linux, which keeps my skills relavant. NetworkManager in linux is a huge pia for my mental state.
Bill Shooter of Bul,
No kidding. I even prefer scripting the command line tools to perform the network operations over trying to use network configuration files for complicated setups. The idea behind declarative abstractions is to simplify underlying complexity, but I find that sometimes they actually add complexity and double the learning curve. Using the shell commands you know exactly what’s happening. The declarative config files provide little control over what the system is doing. With commands it’s far easier to test and add diagnostics and automation as necessary.
I have the exact same issue with exim for email processing, asterisk for voip…ugh! I know exactly what I need the system to do: “if this then that”…child’s play. But instead we get these convoluted and foreign syntaxes that become increasingly awkward over the years as they evolve to support ever more specialized use cases. They end up recreating programmable primitives using half-assed pseudo languages that were never good programing languages to begin with. The result is software that is tedious to learn and customize, less optimized (no JIT compilation), less flexible.
People starting new software: please, consider building your framework around one of the many great existing scriptable programming languages. Don’t create something that turns into a cryptic single use Frankenstein syntax that slows admins down and nobody wants to learn.
In order to use Opnsense, you have to buy their hardware or use a cloud provider’s market image. Either way, it’s not “free as in beer” like pfSense’s community edition.
https://opnsense.org/download/ That is egregiously false. If you need proof there are hundreds of posts on reddit of people doing exactly that.
You can install and use OPNsense on generic hardware, and even get a free license for block lists with an agreement to share telemetry (which is used to build the blocklist anyway).
Using OPNsense hardware does get you access to the central management tools AFAIK (haven’t’ done it myself) but there is nothing stopping you from running it just like PFSense, and that is even encouraged.
Isn’t that team running parallel to pfsense, and pfsense, now is running Linux?