It feels very clean and well engineered, I always manage to break it via updates though (freebsd-upgrade vs ports vs pkg)
Apparently pkg-ng and ports are linked via a central database though now, so that should not be the case any longer.
As for why? I disliked systemd and was told to "evolve or gtfo" so I gtfo since I didn't like the way it was being forced on me and the few gripes I had with it fell onto people who seemed to be acting very defensively. But I digress.
I'm a systems administrator, in my next employment I will be attempting to get into a company that is making use of freebsd ( hopefully by then I'll be breaking it much less often of course :) )
Always read /usr/ports/UPDATING after upgrading your ports tree, before upgrading any ports. This usually has what's going to break and instructions about how to manage. It does seem like it's not updated as often these days though.
There are several tiers. Nowadays installing a release version of FreeBSD, packages will get updates quarterly with security updates in between as required. In effect the system is suited for production and very stable by default.
Other tiers include the stable and current branches which track development more closely.
freebsd-upgrade has been absolutely fool-proof for me. Mixing ports and pkg is not advisable even though they use the same database since versions are often not in sync.
Boot environments on ZFS with beadm provide a brilliant way to protect against catastrophic updates. I don't know of any other popular OS that offers something comparable.
If you boot a Fedora 22/23 machine with root on btrfs, you get something similar, I believe: dnf notifies you of OS upgrades, you click 'yay', the system reboots, makes a snapshot and installs upgrades. If installation fails, the snapshot is rolled back; if it completes successfully, the system reboots again and you're good to go. It's apparently been in since systemd 183: https://wiki.freedesktop.org/www/Software/systemd/SystemUpda...
There's a very great difference between using BSD on the desktop vs. using it on a server. FreeBSD is years behind Linux in desktop support in terms of GPU drivers (still no haswell graphics support), desktop environment slickness and audio latency etc.
It will fall further behind still in the near future, as desktop Linux embraces Wayland.
I recently switched my personal box to FreeBSD. I honestly find it significantly easier to manage than Linux, and have greater trust in its reliability merely from its simplicity.
> Anybody who has ever had the grace of managing IPTables on Linux
Nowadays few people manage IPTables directly. Long ago I used to maintain my own convoluted scripts (ipfwadm, ipchains, iptables...) but once I discovered Shorewall I never looked back - multi-interface multi-VLAN rounting setups can now be sanely managed from the comfort of very readable configuration files.
On that note, I'm currently on Debian Stretch which has a Linux 4.2 kernel and consequently great support for nftables (iptables replacement).
I never truly grokked iptables but configuring nftables reminded me of putting up a pf firewall on OSX. In fact, I'd say it was even easier. The docs could be a tad bit better, but the actual format itself is intuitive and easy to understand.
I'd highly recommend it over iptables if one has the chance.
Its a fork that has a different development focus. The biggest difference is that the OpenBSD version has an improved config file format, and the the FreeBSD one supports SMP.
What issues do you have with Java on FreeBSD? I only just got FreeBSD running on my dev machine, but I've been able to work on (build/run) my Scala projects easily enough.
The issue was that in the past JDK (offered by Sun and Oracle) had no binaries available for FreeBSD (I believe the source was available but was not the same that Sun JDK was built from). If you wanted to run it, you would have to download the Linux version and run it in compatibility mode.
Later FreeBSD get some kind of deal with Sun to provide native Sun JDK for FreeBSD and made them available through http://www.freebsd.org (you can check web archive to see older versions).
Nowadays starting since JDK 7, OpenJDK supposed to be fully compatible with OracleJDK, so it should no longer be a problem anymore.
Have you tried lately? Java used to be a big issue on FreeBSD, but that hasn't been the case in several years. Now it works as well as any other platform.
Yahoo! was using FreeBSD machines in production for many years. They were very stable. Since WhatsApp team came out of Yahoo!, they kept using FreeBSD machines.
Netflix has the OpenConnect server/service that is used to bring content closer to the users by caching content at the ISP. It's a FreeBSD box with NginX and Bird BGP
I work on the OCA team at Netflix. I can confirm we run FreeBSD on our CDN servers.
I was at Google for several years before Netflix, and I believe that any claims of FreeBSD being used by Google are either outdated or misguided. AFAIK, Google was linux from day 1.
> Many major companies like Google or Netflix use FreeBSD in production.
Citation needed on that Google part. It seems unlikely to be true on any meaningful scale. (That is, when writing a FreeBSD advocacy article, maybe you should not be using the largest Linux user in the world as the FreeBSD example).
As far as I know, FreeBSD is more secure than most of the out of the box Linux versions(not considering jails). Does anyone know an article that illustrates this?
That used to be the case, but Netflix started building out their own CDN a few years ago and they've migrated away from their legacy providers. Netflix is now serving about a third of US peak time internet traffic from FreeBSD.
I'm not sure I'd place much faith in ASLR these days. Bittau's Blind Return Oriented Programming (BROP) http://www.scs.stanford.edu/brop/ makes that only a speedbump, not a real obstacle, for any server that suffers from a stack overflow vulnerability and respawns after a crash. Basically, you can read the return address off the stack a byte at a time by detecting the difference between a crash (you got the overflowed byte wrong) and no-crash (you got the overflowed byte correct). Doesn't take long to recover the return address, and hence find the text location. Their paper is a really fun read!
We all know that exploit mitigations aren't perfect. But to not even bother using them... that's just ridiculous. There are plenty of scenarios where ASLR helps prevent exploitation. And the fact that FreeBSD doesn't even have it is pretty damning.
I didn't say not to bother; I just said the protection provided by ASLR is weaker, even on 64-bit systems, than most of us believed a couple of years ago.
I definitely think people should give FreeBSD a try. I also think they should give different flavors or linux a try (e.g. Arch Linux). What I don't agree with is using FreeBSD or a non-mainstream OS in production unless you really know what you're doing.
There are many reasons for this, but the most important one is what the article alluded to; there is a plethora of resources for troubleshooting an issue. If you can't install a package like `gfortran` on something like ubuntu, then you can head over to askubuntu and will likely get the solution to your problem.
What I think FreeBSD (or any less widely used OS for that matter) should do is create the right kind of easily searchable support structure that people coming from Ubuntu and CentOS take for granted.
If you read the article closely, it does not point to a canonical support structure. This does not mean there isn't one or for that matter, many. But, what I can decipher is that there isn't a de-facto site that you can get help from.
I'm sure many people will tell you that the FreeBSD man pages [0] are an incredible resource and some of the best written man pages out there. From experience, the official handbook [1] was incredibly helpful as well.
That said, the forums are not the most helpful place because there are /so/ many configurations out there and so many "right" ways to do things that it makes finding a working solution incredibly difficult.
I used FreeBSD for a couple of years but now use Arch (after a fling with Ubuntu in between). Reasons I switched (some of which may have been addressed since):
* building everything from source got old
* lack of support for hardware (Linux has gotten really good at having drivers for hardware)
* ports of desktop applications were not always available, and the POSIX shim to use Linux applications didnt always work without some hacking
* On the server side, Linux pretty much caught up on performance
* As the Linux community has grown, the resources available to Linux users are amazing. FreeBSD feels like Linux used to - always having to hack around and try to research how to make it work and nothing quite working smoothly (on the desktop - less of an issue for servers, where FreeBSD has always shined). Linux has reached a point where I use Linux as my primary desktop OS, and it works great. FreeBSD for the desktop feels like a step backwards.
You....don't have to. You haven't had to for years. Just use pkg instead of ports.
> * lack of support for hardware (Linux has gotten really good at having drivers for hardware)
Other than wireless, FreeBSD's driver support is pretty solid. I have a cutting edge machine (haswell-e, nvidia, ddr4, etc) and not one device is unsupported. In fact, FreeBSD has much less hassle with the audio driver than any Linux distro I've tried.
> * ports of desktop applications were not always available, and the POSIX shim to use Linux applications didnt always work without some hacking
Well yeah, it's still a different OS. If you need some specific commercial software (source unavailable), you'll probably have to jump through some hoops to get it working.
> * On the server side, Linux pretty much caught up on performance
Sure. But when performance is on par, it's not really a factor anymore. At that point, it's just what is easiest/most enjoyable to manage.
> * As the Linux community has grown, the resources available to Linux users are amazing. FreeBSD feels like Linux used to - always having to hack around and try to research how to make it work and nothing quite working smoothly
I've never run into this issue. As long as you aren't just trying to run commands from stackoverflow, you should be able to adapt things for the few nuances pretty easily. It's really just about knowing your OS. Again, not necessarily true for commercial software...but the case for most FOSS.
pkg(1) works out of the box now. It's faster and way simpler than apt-get/yum.
> * lack of support for hardware (Linux has gotten really good at having drivers for hardware)
I recommend sticking with commodity hardware and making sure your chipset is supported before hand.
> * ports of desktop applications were not always available, and the POSIX shim to use Linux applications didnt always work without some hacking
Also happens. If only more applications made themselves POSIX compliant.
Normally though, just patching a few things in /files in the port is enough. Sometimes all it takes to port an app from Linux to FreeBSD is just fixes to makefile/automake/cmake files.
> * On the server side, Linux pretty much caught up on performance
Can you elaborate more on what you mean?
> * As the Linux community has grown, the resources available to Linux users are amazing. FreeBSD feels like Linux used to - always having to hack around and try to research how to make it work and nothing quite working smoothly (on the desktop - less of an issue for servers, where FreeBSD has always shined). Linux has reached a point where I use Linux as my primary desktop OS, and it works great. FreeBSD for the desktop feels like a step backwards.
Some things in FreeBSD are painful. I can use both FreeBSD and linux pretty efficiently and get done what I want.
That said, I have the opposite impression you have. To me, Linux seems like a hack and a step backwards.
For one, since linux as a kernel only covers so much area, distributions are left to curate how many of the design decisions go down.
Put yourself in the shoes of a developer who goes out of his or her way to learn upstart, for instance. You invest a good part of your time into the codebase, with a sense of confidence you're going to be able to utilize this onward in your career and future projects.
Then you find, this system you spent time learning is now obsolete and you have to relearn everything, There's systemd.
Imagine if this were to happen every few years with a new piece of software. You want to know why it feels useless to learn Xorg? Because they're trying to phase it out for mir. Well, mir isn't "done" yet, and even if it was ready, other software has to integrate with it. There is a huge collaboration that has to take place between developers learning how mir works, and keep in mind, they're getting exacerbated having a new system replace the old every couple of years. Then you have to manage the snafu of packaging it and how you engineer a switch like mir into the release.
Linux may seem more bleeding edge than BSD, but this is only a veneer. To developers, it's hell having your investment in learning something dashed away and having your time put into some venture you may or may not agree with.
BSD drastically simplifies these pains for devs. There is something called the "principle of least surprise". As well, freebsd's base system includes tools like rc(8), package management, etc. which in turns gives a vastly more cohesive experience.
I appreciate the work of both systems greatly - but few give a really care to the real reason you see drama over things like systemd. From my view in using BSD, it's like Linux's universe doesn't even care for its' developers time and sacrifice.
For some reason, I can't edit my last paragraph. It submits but doesn't change.
From my view in using BSD, it's like Linux's universe doesn't even care for its' developers time and sacrifice. Distributions lax on standards, throw out the baby with the bath water whenever a new system comes on the block and leaves upstream and vendors to clean up the mess.
Keep in mind - no one can read every developer mailing list for every project, let alone participate when these things turn into politics. You may see things that are critical of the architecture of a new technology, and then opposing criticism that the legacy systems are outdated and hard for new engineers to understand. Both may be valid, but they conceal something deeper, an outsider comes out of nowhere calling the shots and want to rip up a lot of stuff that works.
All I know is that developers who invest their time maintaining these systems get a raw deal. Maybe the new system, be it mir, systemd, etc. really improves the experience and will work out "long term". But developers are already jaded and heard this too many times.
Starting with 10.0 they improved packaging, so you can use FreeBSD in binary-only setup.
As for your other problems, FreeBSD is targeted toward servers so that's where your problems come from. I like FreeBSD a lot and have been using it since version 4.7, but I still prefer to use OpenSuSE for my desktop/laptop.
I tried putting BSD on my laptop, but quickly got annoyed by graphics and sound not working and software missing. I know most things work, and most software is available, but I need more than that.
Now I went back to Ubuntu because I'm to lazy to set up Arch. I'm not even using a tiling VM anymore.
While I see great value in BSD as a server OS, Linux is just much more convenient on the desktop, and this leads to a circle where I use what I know, what I use what I know. So I tend to also run Ubuntu on servers because it's one system less to know.
Though still, if I needed to build a file server, or an environment where security is important, I would take a closer look at BSD.
I recently switched my dev machine (laptop) from Ubuntu to FreeBSD because I wanted the experience. I wrote a post about it[0]. Basically, wifi and graphics were a PITA and I brute forced my way into getting them working.
After getting past those two though, everything else just worked. The simplicity of the system compared to Debian/Ubuntu is just astounding.
I haven't yet gotten into jails or bhyve, but those are the next two things I'm very excited to work toward.
I've found that OpenBSD has incredibly complete support for many laptops, going so far as to support Thinkpads with touchscreens and digitizer pens out of the box.
Overall I find FreeBSD's desktop to be more usable, even though OpenBSD has more streamlined configuration in some parts of the system.
I agree! For instance, my wifi card (Centrino 2230) is not supported on FreeBSD 10.2-STABLE but it has been available on OpenBSD for a little while. It is now supported in HEAD but won't be in STABLE until 11.0 next year.
I decided to go with FreeBSD because, from what I read, it seemed like it and 3rd-part packages are kept more up-to-date. As a server-side and front-end developer, this is somewhat more immediately important than "complete security".
Edit: Additionally, jails and bhyve are a big motivator to pick FreeBSD over OpenBSD, personally.
About 3rd party packages: FreeBSD ports are always current, binary packages are available as quarterly and current. With OpenBSD, it's all frozen on release, and you basically have to run -CURRENT to get recent packages.
Man, I definitely am scared to! I haven't quite figured out the environment though. It was such a relief just to get graphics working in the first place. I don't I have the time to put up with volatile nightly builds. But as I said, I have no clue how volatile CURRENT is. But with your suggestion, I'll have to read.
I thought I heard something about OpenBSD wanting a native bhyve replacement. But vmm sounds awesome! Thanks for pointing that out!
These posts should never be allowed on Fridays. I should be out drinking (or doing what normal people do) on Friday nights, not at home installing another OS.
I like FreeBSD a lot but I found OpenBSD to be even nicer. Mostly because the of the practice they have of including real examples of command usage in UNIX man pages. Sounds like a small reason, but it was quite a boon.
Caveat: This was a while ago. I don't know if FreeBSD has adopted the same practice.
> A really big difference is that FreeBSD is the kernel and userland together.
Can someone explain the significance of this as the author seems to keep glossing over it. What's does he mean by saying they are "together" and what is the advantage of it?
The userland and kernel are developed together by the same group of people/project. So the design is consistent across the system. In Linux the kernel comes from Linus and the kernel development team. The userland usually comes from the GNU core utils team, the distro creator and several other places. This can cause disconnects between how various things in the system work, kernel patches to get a random features to work, etc.
The significance is that you have one group building the kernel and userland which allows for implementation and testing of features that cross that boundary. A non-FreeBSD example is the recent work on pledge in OpenBSD. Kernel changes were made in conjunction with changes to a significant part of the userland. That is a minor example, but gives the feel of how having the same set of eyes look to the whole system can be a benefit.
I think what the OP is referring to is that Linux is just the kernel, whereas a full "GNU/Linux" distribution is the GNU userspace utilities (the command line utilities), compilers, etc and other things (not necesarily part of GNU).
The author might be saying that the FreeBSD OS is essentially treated as a single distribution that is both developed, maintained, and packaged cohesively by a single team, as opposed to Linux, where the kernel team (led by Linus) develops the kernel (and maintains/integrates associated parts such as device drivers and filesystems), other devs develop other utilities, and distribution teams pull together everything else (usually either a company such as Canonical or Red Hat, or often a team of volunteers such as with Debian.)
For the latter, it really comes down to a difference in philosophy: because FreeBSD is a single, cohesive unit, there's less room for differing opinions and variety in the mix, which can deliver solid results but with reduced "moving fast and breaking things" that sometimes result in faster innovative leaps that you might see on Linux. (But how much do you enjoy seeing your core infrastructure broken? e.g., this is also why Debian has three tracks - stable, testing, and unstable, to accomodate different levels of risk.)
(Your choice of operating systems may have nothing at all to do with your choice of governance -- but the solid, stable approach could be characterized as conservative and the move fast and break things could be progressive ;) personally, I like both at different times)
If you download the source of freebsd, the userland tools come together with it, they are developed as a whole with the kernel side of things. Even the clang/llvm compiler will get built by a 'make buildworld'
You have a full working system from source, while with linux you need kernel, binutils, gcc, in different pieces, not developed as a cohesive whole
I really wanted to try FreeBSD because of ZFS. Then I've seen benchmarks of ZFS between FreeBSD and ZFS on Linux on Ubuntu. Ubuntu was nearly double the speed in the benchmarks. I was sold to Ubuntu. Simple.
Did you compare performance on your own workloads?
We test ZoL with each major release, and while stability has improved significantly, it becomes apparent that ZFS can have wide performance differences depending on configuration and use case.
This is true with all ZFS implementations, but with ZFS on Linux not being native there are even more variables.
> If your understanding of the server OS does only allow you to copy/paste random strings from Stackoverflow, you might not really enjoy FreeBSD (or anything besides Ubuntu) — but then, why are you operating a server in the first place?
To serve stuff.
(To expand on this -- most people don't use software, they use software to GET STUFF DONE. Very few people want to operate a server. They operate a server because it allows them to do something they want to. If your FreeBSD pitch is "you should want to operate a server," you're already not reaching most of your possible audience.)
What you said can be applied to anything:
"most people don't use programming languages, they use programming languages to GET STUFF DONE".
If everyone strictly followed this we wouldn't be using any programming languages other than Java or Python.
Using FreeBSD does not preclude you from getting stuff done, but you do need to have an inclination to try out new (for you) things in your machines right now. It takes some critical mass of enthusiastic adopters (not sure what this number is, but it's there) for your statement to start applying to a wider audience. And from this articles perspective, this critical mass needs to know servers well enough.
That type of viewpoint is hurting our industry. Just blindly doing things is not productive at all. You should learn and understand what it is you are doing before you do it. Just getting shit tonnes of stuff done is not productive at all if you don't understand how or why you are doing it.
Truck drivers actually know how to drive, Crane operators know how to run a crane, and people operating production servers costing businesses time and resources should also act in the best interest of the business.
As a counterpoint. Truck drivers don't need to know how to build a truck nor to crane operators need technical understanding of the materials in the crane's structure.
Yes, but I was talking about its usage, not it's construction. Most of the users of FreeBSD know how to operate it, but may not understand OS theory about how the kernel and userland work together.
Understanding everything beforehand is not what I was attempting to communicate, but simply researching and understanding why a stack overflow comment is the answer, before just copy-pasting it into the terminal. Like reading the man pages of the commands to be run before running them.
Crane operators do need to know a lot more than just pushing buttons. If not, cranes tip over, get blown over, and sometimes people die. I've seen it happen.
Truck drivers, not so much. Although, when your truck breaks down in the middle of nowhere during a blizzard and you have a load where you get paid based on timely delivery, I'd bet having some knowledge on the truck's internals would be helpful.
As another counterpoint, my small business that runs full-stack in AWS and FreeBSD - I am most certainly not perfectly educated in server and network management, and actually excel in software engineering as opposed to server management and configuration.
AWS lets me get shit done. I know enough to get several services running on an EC2 server, and I don't have close to the $100k+ required to hire an excellent network engineer.
That's part of why AWS, GCE, and DO (and their contemporaries) exist. I'm more educated than most at this point, but that's only because of doing when necessary to get things done.
I wasn't trying to imply a person needs to have the entire set of domain knowledge before operating a server, but simply researching about what you are attempting to do before just copy-pasting bash lines into your terminal and not even recognizing how it even works at all.
AWS lets you not have to know a great deal about setting up servers and networks, which is great, because they are very skilled at it when they set it up for you. Then, all you need to research is what you need to do/use to deploy your apps.
Well, being an engineer at a company that provides private cloud services and a long-time programmer, I'd wait to ensure that application stays secure before singing the praises of easy.
While I agree that making things more accessible is great, "really understanding the network" and "security" are more important than ever. The types of things happening now are similar to 15 years ago when "developers" were making Access databases that are still around today and are all sorts of a mess. I've seen companies dump tens or even hundreds of thousands of dollars just to keep them going.
Now, something similar is happening but it's with web-based applications. Much more exposed. If you don't know your stuff you, your company, or most importantly, your customers will eventually get burned.
Those interested in FreeBSD for their desktop might want to take a look at PC-BSD http://www.pcbsd.org which is a FreeBSD variant geared towards desktop users.
Just a word of warning, Jordan Hubbard and Kip Macy work for iXsystems and are pushing for both PC-BSD and FreeNAS to move to NextBSD, which is basically bringing half of OS X into FreeBSD. (Probably inspired by Jordan's days of working at Apple.)
As such, I've switched to recommending people just go with FreeBSD lately. It's a bit of work, but with some helpful guides, you can help people avoid most of the pitfalls (ex http://files.byuu.org/temp/os/freebsd-10.html). And once you learn the basics, you'll be in a great position to administer your system going forward.
Thanks for the shout-out. Thankfully, the FreeBSD Foundation itself doesn't seem particularly receptive to the NextBSD effort (judging from their most recent quarterly status), so there's no danger of it being merged soon.
I think its a little premature to worry about NextBSD in the context of PC-BSD. PC-BSD has brought some stuff from OpenBSD over, but I it doesn't sound like they do stuff without proof of working.
I guess Linux has SystemD and the BSDs have NextBSD to be fearful of.
> I guess Linux has SystemD and the BSDs have NextBSD to be fearful of.
Pretty much. But the FreeBSD developers have a history of being much more conservative on these types of changes. But then again, Debian used to as well. So you never know.
I'm all for people experimenting and trying out new types of init systems and the like. I just don't like having them forced upon me when they're clearly not ready for production. I'm also really worried about the lock-in effects. The BSDs are already feeling the pain of software growing dependencies on the unportable systemd (the most egregious was Brasero, a CD-burning tool, recently having an argument over a systemd dependency.) I don't want to see the BSDs repeat the same mistake.
It's enough "fun" dealing with networking idiosyncrasies like SO_NOSIGPIPE vs MSG_NOSIGNAL, kqueue vs epoll; audio idiosyncrasies like OSS vs ALSA; input idiosyncrasies like devd vs udev; etc as it is. Let's not add another one with init system dependencies. Desktop applications have done fine for the past 50 years without init system dependencies, why start now?
I'll watch. LaunchD isn't bad on the OS X boxes we have[1] and I guess coming from NeXTSTEP, Mach isn't something I have a problem with. I will see how it works, but I'm an OpenBSD user these days so I will wait and see what they think.
1) my main complain has already been addressed with the switch from XML
I've actually listened to the BSD Now podcast episode where they discussed NextBSD…
IIRC, launchd is a simple process manager, and it never had anything to do with XML. XML/plists are used in Apple's implementation of launchCTL, the command line client.
> IIRC, launchd is a simple process manager, and it never had anything to do with XML.
Everyone thought that, until someone came along and wrote a launchd attempt that put an XML parser into the process #1 program. It was publicized back in 2014.
I'm a programmer, not a professional sysadmin, but for my side projects I have to manage my own servers (well, small VMs, but you know what I mean) and for this I definitely prefer BSD.
In fact, I prefer BSD in general over Linux, and while I tried to run it on my main dev laptop, a never ending trickle of minor frustrations with hardware support (suspend/hibernate never worked right, weird issues with docking/undocking (I have a Dell latitude), audio, etc.) eventually forced me back to Ubuntu.
So, for the time being I think I'll stick with Linux for my workstations and BSD for my servers :)
I wonder why this got so many votes to be honest, it's from May 2014 and as far as why one would want to try FreeBSD it is not very detailed. That being said:
I use FreeBSD and (obviously) prefer it, but:
1) ZFSonLinux has made huge steps forward and actually (at least in my opinion) is production ready and rock solid (of course it's not as good as ZFS on FreeBSD though, for example it's lacking some features and of course it's not as proven as of now)
2) Usable containers finally have come to Linux in the form of Docker and everybody is absolutely hyped about it (I would argue though that Jails has more features, is more stable and mature)
The most obvious reason for me to use FreeBSD though is just the difference in philosophy. Don't rapidly make big changes, think everything through, don't surprise users, don't make upgrades that call for massive user intervention, and it's democratically governed and yes, it's a complete OS. Code quality is also better (have you actually looked at what code makes it into the Linux Kernel?), and I would argue therefore security and stability is way better.
Just my 2 cents, nothing wrong with Linux, have used it for years, now I would not want to go back though.
And a small Side Note: No systemd, not to start a flame war, but it is taking over the linux-sphere and I find it's design just horrific
There's little technical difference. Both BSD and Linux provide set of kernel-level mechanisms that allow you to run "containers", ie. process trees that are completely isolated from each other and from the host OS. They are roughly comparable, I believe, with mostly minor technical differences.
The huge practical difference right now is that on Linux, Docker and LXC (as in linuxcontainers.org) provide a high-level, fairly opinioned framework and set of infrastructure pieces to build, run and manage containers — and there are no fully equivalent tools on BSD, at least none that are as featureful or mature.
If you want to do containerized deploys on BSD, you'll be writing scripts that set up jails, call rctl, set kernel parameters with sysctl, and so on. There's ezjail [1], but it's nowhere near Docker in terms of scope.
I actually wish there was something on Linux that was less monolithic and better designed than Docker. Its image management is badly designed and annoying to use, and after all this time it still suffers from design flaws such as needing to be the parent of all containers (completely unnecessary given that we have cgroups).
http://doger.io has links to a lot of simple Linux container runners!
I'm working on a simple FreeBSD jail runner: https://github.com/myfreeweb/sandblast The main idea is machine-friendly configuration: your higher level software (PaaS, CI, etc.) produces a JSON config and pipes it to sandblast, which runs a script in the container.
I have a piece of software running in jails on our servers, I wrote a script to assemble the jail (although this could just be expanding a tar file, and copying in the service configuration file), and add to jail.conf, (maybe add to rc.conf.local if you want to autostart). I didn't need to sysctl, or rctl. I also wrote a small rc file (that just calls /usr/sbin/jail -c name to start, and jail -r name to stop)
(ok, i also setup a devfs rule, because i had issues with built in ones and various patch levels of FreeBSD -- and my service needs access to /dev/random)
The only non-obvious thing is you need /libexec/ld-elf.so.1 in order to run dynamically linked libraries.
I've had issues this year w/ Ubuntu 14.04 machines where the kernel modules would not build, resulting in zpools that could not be imported. I guess that's more of a packaging issue than a code issue.
I periodically have unexpected behavior where my filesystem doesnt mount right and I have to re-mount, or the nfs exports have to be re-exported, etc. I've assumed this was due to incomplete configuration on my part but it's clearly not as brainless to set up as native fs.
Matt Ahrens, one of the original ZFS authors, has somewhat recently stated that for ZFS the OpenSolaris/Illumos/FreeBSD versions are on par, but Linux and OSX are behind.
Sorry if I'm too harsh, but saying that ZoL is "rock solid" and "production ready" sounds like a joke to my ears.
ZFS is an extremely complex filesystem, and it took Sun _years_ of internal testing first, and hundreds of angry customers later (sadly, at some point, the only way to improve a product is through real world testing), to reach a milestone where it was really production ready.
I know that on these days of dockers and unicorns, "production ready" has very different meaning than years ago, but still...
Of course you can't compare the trouble Sun originally had in creating ZFS with the difficulty of porting it to Linux when it has been used for years and you can built on stable code and learn by the other implementations. This comparison is quite unfair and lacking in substance. It's not like the ZoL guys had to start from scratch and reverse engineer
It depends of course, I would always choose FreeBSD over Linux when it comes to ZFS, but then again I would always choose a BSD-OS regardless of whether I want to use ZFS or not.
Take it certainly with a grain of salt, but the developers themselves announced ZoL to be production ready in 2013/03[1], Richard Yao (also a developer of ZoL) argued in a blog post in 2014/09[2] that ZoL was stable and production ready and elaborated on this. Some interesting comments also are here[3].
And all this also was quite a while ago, ZoL has been used by users for years now, it's come a long way, I have used it to some extent a while ago and had no bad experiences.
In the end everyone has to decide for themselves what "production ready" really means, and how high the threshold is to deserve that label. But I think that you can reasonably make the argument, that it is...
Small reason to use Linux--Linux has taken over the embedded market. Hardware vendors (e.g., Broadcom, Intel) offer BSP (board support packages) for Linux but not any of the BSDs.
The BSP in embedded does sort-of what the PC BIOS does. The BSP is the code to bring the microcontroller from cold start to booting something. Booting Linux is supported by large vendors.
Embedded hardware vendors also offer Linux drivers. Not so much anything else.
This is indeed true, systemd was the one thing triggered me to check with BSD again after quite a few years.
Netbsd used to be the embedded BSD flavor, but comparing to linux it's nearly nothing these days. linux thrived in the embedded OS space and pushed aside QNX, OS9, Vxworks, WinCE and NetBSD.
155 comments
[ 3.0 ms ] story [ 174 ms ] threadI like it.
It feels very clean and well engineered, I always manage to break it via updates though (freebsd-upgrade vs ports vs pkg)
Apparently pkg-ng and ports are linked via a central database though now, so that should not be the case any longer.
As for why? I disliked systemd and was told to "evolve or gtfo" so I gtfo since I didn't like the way it was being forced on me and the few gripes I had with it fell onto people who seemed to be acting very defensively. But I digress.
I'm a systems administrator, in my next employment I will be attempting to get into a company that is making use of freebsd ( hopefully by then I'll be breaking it much less often of course :) )
Other tiers include the stable and current branches which track development more closely.
Boot environments on ZFS with beadm provide a brilliant way to protect against catastrophic updates. I don't know of any other popular OS that offers something comparable.
It's not infected with systemd.
Edit: Downvotes? This is a selling point, with all major linux distros leaving very little choice for those who dislike systemd.
I'd be more interested in hearing about everything else.
It will fall further behind still in the near future, as desktop Linux embraces Wayland.
On a server though, it's just fine.
The single biggest thing which stood out for me was PF (from OpenBSD). Anybody who has ever had the grace of managing IPTables on Linux, give PF a go with /etc/pf.conf (docs: https://www.freebsd.org/doc/handbook/firewalls-pf.html, my config: https://github.com/jamescun/infrastructure/blob/master/roles...).
Nowadays few people manage IPTables directly. Long ago I used to maintain my own convoluted scripts (ipfwadm, ipchains, iptables...) but once I discovered Shorewall I never looked back - multi-interface multi-VLAN rounting setups can now be sanely managed from the comfort of very readable configuration files.
I never truly grokked iptables but configuring nftables reminded me of putting up a pf firewall on OSX. In fact, I'd say it was even easier. The docs could be a tad bit better, but the actual format itself is intuitive and easy to understand.
I'd highly recommend it over iptables if one has the chance.
The only time I will advice not spending time on FreeBSD, is when you have to deal with Java.
A single year of FreeBSD has taught me more than 10 years of Linux about UNIX and by extension made me more proficient with both systems.
I've done Java, Scala, and Clojure development on FreeBSD and had no problems whatsoever.
Later FreeBSD get some kind of deal with Sun to provide native Sun JDK for FreeBSD and made them available through http://www.freebsd.org (you can check web archive to see older versions).
Nowadays starting since JDK 7, OpenJDK supposed to be fully compatible with OracleJDK, so it should no longer be a problem anymore.
interview with Scott Long of Netflix on BSD Now http://www.bsdnow.tv/episodes/2013_12_25-the_gift_of_giving
I was at Google for several years before Netflix, and I believe that any claims of FreeBSD being used by Google are either outdated or misguided. AFAIK, Google was linux from day 1.
Citation needed on that Google part. It seems unlikely to be true on any meaningful scale. (That is, when writing a FreeBSD advocacy article, maybe you should not be using the largest Linux user in the world as the FreeBSD example).
OpenBSD is definitely more secure out of the box than Linux.
> Many major companies like Google or Netflix use FreeBSD in production.
Erm. Well, the company's so huge that I'm sure there's something with some freebsd in it somewhere, but... not really.
I've worked with freebsd extensively in a past job, where it was used for licensing reasons. I don't agree with this article.
They're actively giving back a lot of their work too: http://v4.freshbsd.org/search?q=netflix
http://networkfilter.blogspot.com/2014/12/security-openbsd-v...
There are many reasons for this, but the most important one is what the article alluded to; there is a plethora of resources for troubleshooting an issue. If you can't install a package like `gfortran` on something like ubuntu, then you can head over to askubuntu and will likely get the solution to your problem.
What I think FreeBSD (or any less widely used OS for that matter) should do is create the right kind of easily searchable support structure that people coming from Ubuntu and CentOS take for granted.
If you read the article closely, it does not point to a canonical support structure. This does not mean there isn't one or for that matter, many. But, what I can decipher is that there isn't a de-facto site that you can get help from.
The forums and mailing lists are also full of very knowledgeable users and developers.
Besides, FreeBSD's Jails eat Docker for lunch as long as you don't need a point and click App store for your containers.
That said, the forums are not the most helpful place because there are /so/ many configurations out there and so many "right" ways to do things that it makes finding a working solution incredibly difficult.
[0] https://www.freebsd.org/cgi/man.cgi
[1] https://www.freebsd.org/doc/handbook/
* building everything from source got old
* lack of support for hardware (Linux has gotten really good at having drivers for hardware)
* ports of desktop applications were not always available, and the POSIX shim to use Linux applications didnt always work without some hacking
* On the server side, Linux pretty much caught up on performance
* As the Linux community has grown, the resources available to Linux users are amazing. FreeBSD feels like Linux used to - always having to hack around and try to research how to make it work and nothing quite working smoothly (on the desktop - less of an issue for servers, where FreeBSD has always shined). Linux has reached a point where I use Linux as my primary desktop OS, and it works great. FreeBSD for the desktop feels like a step backwards.
You....don't have to. You haven't had to for years. Just use pkg instead of ports.
> * lack of support for hardware (Linux has gotten really good at having drivers for hardware)
Other than wireless, FreeBSD's driver support is pretty solid. I have a cutting edge machine (haswell-e, nvidia, ddr4, etc) and not one device is unsupported. In fact, FreeBSD has much less hassle with the audio driver than any Linux distro I've tried.
> * ports of desktop applications were not always available, and the POSIX shim to use Linux applications didnt always work without some hacking
Well yeah, it's still a different OS. If you need some specific commercial software (source unavailable), you'll probably have to jump through some hoops to get it working.
> * On the server side, Linux pretty much caught up on performance
Sure. But when performance is on par, it's not really a factor anymore. At that point, it's just what is easiest/most enjoyable to manage.
> * As the Linux community has grown, the resources available to Linux users are amazing. FreeBSD feels like Linux used to - always having to hack around and try to research how to make it work and nothing quite working smoothly
I've never run into this issue. As long as you aren't just trying to run commands from stackoverflow, you should be able to adapt things for the few nuances pretty easily. It's really just about knowing your OS. Again, not necessarily true for commercial software...but the case for most FOSS.
No need nowadays.
pkg(1) works out of the box now. It's faster and way simpler than apt-get/yum.
> * lack of support for hardware (Linux has gotten really good at having drivers for hardware)
I recommend sticking with commodity hardware and making sure your chipset is supported before hand.
> * ports of desktop applications were not always available, and the POSIX shim to use Linux applications didnt always work without some hacking
Also happens. If only more applications made themselves POSIX compliant.
Normally though, just patching a few things in /files in the port is enough. Sometimes all it takes to port an app from Linux to FreeBSD is just fixes to makefile/automake/cmake files.
> * On the server side, Linux pretty much caught up on performance
Can you elaborate more on what you mean?
> * As the Linux community has grown, the resources available to Linux users are amazing. FreeBSD feels like Linux used to - always having to hack around and try to research how to make it work and nothing quite working smoothly (on the desktop - less of an issue for servers, where FreeBSD has always shined). Linux has reached a point where I use Linux as my primary desktop OS, and it works great. FreeBSD for the desktop feels like a step backwards.
Some things in FreeBSD are painful. I can use both FreeBSD and linux pretty efficiently and get done what I want.
That said, I have the opposite impression you have. To me, Linux seems like a hack and a step backwards.
For one, since linux as a kernel only covers so much area, distributions are left to curate how many of the design decisions go down.
Put yourself in the shoes of a developer who goes out of his or her way to learn upstart, for instance. You invest a good part of your time into the codebase, with a sense of confidence you're going to be able to utilize this onward in your career and future projects.
Then you find, this system you spent time learning is now obsolete and you have to relearn everything, There's systemd.
Imagine if this were to happen every few years with a new piece of software. You want to know why it feels useless to learn Xorg? Because they're trying to phase it out for mir. Well, mir isn't "done" yet, and even if it was ready, other software has to integrate with it. There is a huge collaboration that has to take place between developers learning how mir works, and keep in mind, they're getting exacerbated having a new system replace the old every couple of years. Then you have to manage the snafu of packaging it and how you engineer a switch like mir into the release.
Linux may seem more bleeding edge than BSD, but this is only a veneer. To developers, it's hell having your investment in learning something dashed away and having your time put into some venture you may or may not agree with.
BSD drastically simplifies these pains for devs. There is something called the "principle of least surprise". As well, freebsd's base system includes tools like rc(8), package management, etc. which in turns gives a vastly more cohesive experience.
I appreciate the work of both systems greatly - but few give a really care to the real reason you see drama over things like systemd. From my view in using BSD, it's like Linux's universe doesn't even care for its' developers time and sacrifice.
From my view in using BSD, it's like Linux's universe doesn't even care for its' developers time and sacrifice. Distributions lax on standards, throw out the baby with the bath water whenever a new system comes on the block and leaves upstream and vendors to clean up the mess.
Keep in mind - no one can read every developer mailing list for every project, let alone participate when these things turn into politics. You may see things that are critical of the architecture of a new technology, and then opposing criticism that the legacy systems are outdated and hard for new engineers to understand. Both may be valid, but they conceal something deeper, an outsider comes out of nowhere calling the shots and want to rip up a lot of stuff that works.
All I know is that developers who invest their time maintaining these systems get a raw deal. Maybe the new system, be it mir, systemd, etc. really improves the experience and will work out "long term". But developers are already jaded and heard this too many times.
As for your other problems, FreeBSD is targeted toward servers so that's where your problems come from. I like FreeBSD a lot and have been using it since version 4.7, but I still prefer to use OpenSuSE for my desktop/laptop.
Now I went back to Ubuntu because I'm to lazy to set up Arch. I'm not even using a tiling VM anymore.
While I see great value in BSD as a server OS, Linux is just much more convenient on the desktop, and this leads to a circle where I use what I know, what I use what I know. So I tend to also run Ubuntu on servers because it's one system less to know.
Though still, if I needed to build a file server, or an environment where security is important, I would take a closer look at BSD.
After getting past those two though, everything else just worked. The simplicity of the system compared to Debian/Ubuntu is just astounding.
I haven't yet gotten into jails or bhyve, but those are the next two things I'm very excited to work toward.
[0] http://blog.eatonphil.com/2015-11-18/two-weeks-of-freebsd---...
Overall I find FreeBSD's desktop to be more usable, even though OpenBSD has more streamlined configuration in some parts of the system.
I decided to go with FreeBSD because, from what I read, it seemed like it and 3rd-part packages are kept more up-to-date. As a server-side and front-end developer, this is somewhat more immediately important than "complete security".
Edit: Additionally, jails and bhyve are a big motivator to pick FreeBSD over OpenBSD, personally.
About 3rd party packages: FreeBSD ports are always current, binary packages are available as quarterly and current. With OpenBSD, it's all frozen on release, and you basically have to run -CURRENT to get recent packages.
The OpenBSD team is working on a hypervisor too: http://undeadly.org/cgi?action=article&sid=20151101223132
ZFS + jails + DTrace though… :-)
I thought I heard something about OpenBSD wanting a native bhyve replacement. But vmm sounds awesome! Thanks for pointing that out!
Caveat: This was a while ago. I don't know if FreeBSD has adopted the same practice.
Can someone explain the significance of this as the author seems to keep glossing over it. What's does he mean by saying they are "together" and what is the advantage of it?
The author might be saying that the FreeBSD OS is essentially treated as a single distribution that is both developed, maintained, and packaged cohesively by a single team, as opposed to Linux, where the kernel team (led by Linus) develops the kernel (and maintains/integrates associated parts such as device drivers and filesystems), other devs develop other utilities, and distribution teams pull together everything else (usually either a company such as Canonical or Red Hat, or often a team of volunteers such as with Debian.)
For the latter, it really comes down to a difference in philosophy: because FreeBSD is a single, cohesive unit, there's less room for differing opinions and variety in the mix, which can deliver solid results but with reduced "moving fast and breaking things" that sometimes result in faster innovative leaps that you might see on Linux. (But how much do you enjoy seeing your core infrastructure broken? e.g., this is also why Debian has three tracks - stable, testing, and unstable, to accomodate different levels of risk.)
(Your choice of operating systems may have nothing at all to do with your choice of governance -- but the solid, stable approach could be characterized as conservative and the move fast and break things could be progressive ;) personally, I like both at different times)
You have a full working system from source, while with linux you need kernel, binutils, gcc, in different pieces, not developed as a cohesive whole
I find the claim hard to believe and would like to see the benchmark if you can dig it out.
Did you compare performance on your own workloads?
We test ZoL with each major release, and while stability has improved significantly, it becomes apparent that ZFS can have wide performance differences depending on configuration and use case.
This is true with all ZFS implementations, but with ZFS on Linux not being native there are even more variables.
To serve stuff.
(To expand on this -- most people don't use software, they use software to GET STUFF DONE. Very few people want to operate a server. They operate a server because it allows them to do something they want to. If your FreeBSD pitch is "you should want to operate a server," you're already not reaching most of your possible audience.)
If everyone strictly followed this we wouldn't be using any programming languages other than Java or Python.
Using FreeBSD does not preclude you from getting stuff done, but you do need to have an inclination to try out new (for you) things in your machines right now. It takes some critical mass of enthusiastic adopters (not sure what this number is, but it's there) for your statement to start applying to a wider audience. And from this articles perspective, this critical mass needs to know servers well enough.
Truck drivers actually know how to drive, Crane operators know how to run a crane, and people operating production servers costing businesses time and resources should also act in the best interest of the business.
Understanding everything beforehand is not what I was attempting to communicate, but simply researching and understanding why a stack overflow comment is the answer, before just copy-pasting it into the terminal. Like reading the man pages of the commands to be run before running them.
Truck drivers, not so much. Although, when your truck breaks down in the middle of nowhere during a blizzard and you have a load where you get paid based on timely delivery, I'd bet having some knowledge on the truck's internals would be helpful.
AWS lets me get shit done. I know enough to get several services running on an EC2 server, and I don't have close to the $100k+ required to hire an excellent network engineer.
That's part of why AWS, GCE, and DO (and their contemporaries) exist. I'm more educated than most at this point, but that's only because of doing when necessary to get things done.
AWS lets you not have to know a great deal about setting up servers and networks, which is great, because they are very skilled at it when they set it up for you. Then, all you need to research is what you need to do/use to deploy your apps.
While I agree that making things more accessible is great, "really understanding the network" and "security" are more important than ever. The types of things happening now are similar to 15 years ago when "developers" were making Access databases that are still around today and are all sorts of a mess. I've seen companies dump tens or even hundreds of thousands of dollars just to keep them going.
Now, something similar is happening but it's with web-based applications. Much more exposed. If you don't know your stuff you, your company, or most importantly, your customers will eventually get burned.
Also, BSD Now http://www.bsdnow.tv and BSDTalk http://bsdtalk.blogspot.com are excellent podcasts for BSD.
Which many people, including myself, feel is a disastrously bad idea (ex http://blog.darknedgy.net/technology/2015/08/26/0/). It has a lot of similarities to Linux and systemd.
As such, I've switched to recommending people just go with FreeBSD lately. It's a bit of work, but with some helpful guides, you can help people avoid most of the pitfalls (ex http://files.byuu.org/temp/os/freebsd-10.html). And once you learn the basics, you'll be in a great position to administer your system going forward.
I guess Linux has SystemD and the BSDs have NextBSD to be fearful of.
Pretty much. But the FreeBSD developers have a history of being much more conservative on these types of changes. But then again, Debian used to as well. So you never know.
I'm all for people experimenting and trying out new types of init systems and the like. I just don't like having them forced upon me when they're clearly not ready for production. I'm also really worried about the lock-in effects. The BSDs are already feeling the pain of software growing dependencies on the unportable systemd (the most egregious was Brasero, a CD-burning tool, recently having an argument over a systemd dependency.) I don't want to see the BSDs repeat the same mistake.
It's enough "fun" dealing with networking idiosyncrasies like SO_NOSIGPIPE vs MSG_NOSIGNAL, kqueue vs epoll; audio idiosyncrasies like OSS vs ALSA; input idiosyncrasies like devd vs udev; etc as it is. Let's not add another one with init system dependencies. Desktop applications have done fine for the past 50 years without init system dependencies, why start now?
1) my main complain has already been addressed with the switch from XML
IIRC, launchd is a simple process manager, and it never had anything to do with XML. XML/plists are used in Apple's implementation of launchCTL, the command line client.
http://www.nextbsd.org/welcome-to-ghost/ NextBSD is explicitly a "science project" – they don't want upstream FreeBSD to become NeXTSTEP :)
Everyone thought that, until someone came along and wrote a launchd attempt that put an XML parser into the process #1 program. It was publicized back in 2014.
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/la...
In fact, I prefer BSD in general over Linux, and while I tried to run it on my main dev laptop, a never ending trickle of minor frustrations with hardware support (suspend/hibernate never worked right, weird issues with docking/undocking (I have a Dell latitude), audio, etc.) eventually forced me back to Ubuntu.
So, for the time being I think I'll stick with Linux for my workstations and BSD for my servers :)
I use FreeBSD and (obviously) prefer it, but:
1) ZFSonLinux has made huge steps forward and actually (at least in my opinion) is production ready and rock solid (of course it's not as good as ZFS on FreeBSD though, for example it's lacking some features and of course it's not as proven as of now)
2) Usable containers finally have come to Linux in the form of Docker and everybody is absolutely hyped about it (I would argue though that Jails has more features, is more stable and mature)
The most obvious reason for me to use FreeBSD though is just the difference in philosophy. Don't rapidly make big changes, think everything through, don't surprise users, don't make upgrades that call for massive user intervention, and it's democratically governed and yes, it's a complete OS. Code quality is also better (have you actually looked at what code makes it into the Linux Kernel?), and I would argue therefore security and stability is way better.
Just my 2 cents, nothing wrong with Linux, have used it for years, now I would not want to go back though.
And a small Side Note: No systemd, not to start a flame war, but it is taking over the linux-sphere and I find it's design just horrific
The huge practical difference right now is that on Linux, Docker and LXC (as in linuxcontainers.org) provide a high-level, fairly opinioned framework and set of infrastructure pieces to build, run and manage containers — and there are no fully equivalent tools on BSD, at least none that are as featureful or mature.
If you want to do containerized deploys on BSD, you'll be writing scripts that set up jails, call rctl, set kernel parameters with sysctl, and so on. There's ezjail [1], but it's nowhere near Docker in terms of scope.
I actually wish there was something on Linux that was less monolithic and better designed than Docker. Its image management is badly designed and annoying to use, and after all this time it still suffers from design flaws such as needing to be the parent of all containers (completely unnecessary given that we have cgroups).
[1] https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/j...
I'm working on a simple FreeBSD jail runner: https://github.com/myfreeweb/sandblast The main idea is machine-friendly configuration: your higher level software (PaaS, CI, etc.) produces a JSON config and pipes it to sandblast, which runs a script in the container.
in jail.conf i just have
(ok, i also setup a devfs rule, because i had issues with built in ones and various patch levels of FreeBSD -- and my service needs access to /dev/random)The only non-obvious thing is you need /libexec/ld-elf.so.1 in order to run dynamically linked libraries.
There's also the PC-BSD Warden. With it, one generally does not write scripts to "set up jails, call rctl, set kernel parameters with sysctl".
See the PC-BSD 10.1 Handbook chapter 8:
* http://download.pcbsd.org/iso/10.1-RELEASE/amd64/docs/html/c...
I know a zraid3 FreeBSD/ZFS root array will still boot with two drives failed and one drive acting wonky. Not so sure about Linux.
I periodically have unexpected behavior where my filesystem doesnt mount right and I have to re-mount, or the nfs exports have to be re-exported, etc. I've assumed this was due to incomplete configuration on my part but it's clearly not as brainless to set up as native fs.
ZFS is an extremely complex filesystem, and it took Sun _years_ of internal testing first, and hundreds of angry customers later (sadly, at some point, the only way to improve a product is through real world testing), to reach a milestone where it was really production ready.
I know that on these days of dockers and unicorns, "production ready" has very different meaning than years ago, but still...
It depends of course, I would always choose FreeBSD over Linux when it comes to ZFS, but then again I would always choose a BSD-OS regardless of whether I want to use ZFS or not.
Take it certainly with a grain of salt, but the developers themselves announced ZoL to be production ready in 2013/03[1], Richard Yao (also a developer of ZoL) argued in a blog post in 2014/09[2] that ZoL was stable and production ready and elaborated on this. Some interesting comments also are here[3].
And all this also was quite a while ago, ZoL has been used by users for years now, it's come a long way, I have used it to some extent a while ago and had no bad experiences.
In the end everyone has to decide for themselves what "production ready" really means, and how high the threshold is to deserve that label. But I think that you can reasonably make the argument, that it is...
[1] https://groups.google.com/a/zfsonlinux.org/forum/m/?fromgrou...
[2] https://clusterhq.com/2014/09/11/state-zfs-on-linux/
[3] http://linux.slashdot.org/story/14/09/11/1421201/the-state-o...
The BSP in embedded does sort-of what the PC BIOS does. The BSP is the code to bring the microcontroller from cold start to booting something. Booting Linux is supported by large vendors.
Embedded hardware vendors also offer Linux drivers. Not so much anything else.
Netbsd used to be the embedded BSD flavor, but comparing to linux it's nearly nothing these days. linux thrived in the embedded OS space and pushed aside QNX, OS9, Vxworks, WinCE and NetBSD.