This is my number one reason for moving to FreeBSD 11.1. FreeBSD 11.0 was weird because they enabled IPSEC, but did not enable NAT_T in the GENERIC kernel.
At least partially because you only have another year of support for FreeBSD 10.x, whereas FreeBSD 11.x is expected to be supported until 2021. This includes security fixes.
11.x may supported until 2021, but 11.1 itself will only be supported up until 11.2 is released + 3 months. So if 11.2 is released before the end of July 2018, then 10.4 which has an EOL of October 31st, 2017 would actually be supported for longer.
Generally speaking, more conservative users will wait at least until the xx.1 point release before switching to that major version, but if you're on the very conservative side you may want to wait until xx.2. However, there are numerous updates even between minor point releases which you could apply if any errata are discovered if you don't mind.
Yes, but the point of point-releases is that they're largely about maintenance and hardware support - so moving from 10.x to 11.x might take some testing, maybe rewriting some management scripts, etc, but 11.1 to 11.2 should be easier since nothing major changes about the system. Having a year's buffer to migrate means that if there are issues, you can fix them or get them fixed before 10.x EOLs and you're stuck running an unsupported OS.
As far as I understand it, that is nothing more than an urban legend based on the fact that 5.0 was a terrible, rushed release and not meant for production (it was also marked as such). That mistake has not been repeated since, to my knowledge.
I mean it's obvious that you'd want the latest release, and there's no release numerically higher than that one. But I understand, for some, laconic and prejudicious snarks are more pleasing than trying to understand what the interlocutor is trying to communicate.
If you're on the edge about trying FreeBSD on some server instead of Linux, I strongly suggest diving in. I decided to go with FreeBSD on my home server after some back-and-forth, and it has been nothing but a thoroughly positive experience.
- The structure of the system makes total sense to me, making it easy to do stuff.
- The system is relatively simple in its design, which means I actually feel like I could troubleshoot any aspect of it. With Linux I often end up in a situation where I think, "Okay, and that component is in $complex_subsystem_12 so I have no chance of fixing it."
- The documentation is great. For regular system maintenance, mostly everything you'll ever need is in the FreeBSD Handbook and you can often find separate, but equally complete, documents for more specific tasks like the Porter's Handbook, the Project Model documentation, the Developer's Handbook and the various system architecture/design books floating around.
I've been on the fence but tipped back. I'm also always on the fence about Arch vs Ubuntu. But the speed and ease with which you get an application like NextCloud fully running on Ubuntu is unmatched. I don't want to spend time tweaking php.ini (anymore), I just want to install nginx and php7 en find that <? phpinfo(); ?> just works. And when I want to VNC into the box for various reasons, I just want it to work and not mess with x configs or put up with very ugly theme-less windows. The BSD pull is there (even more from OpenBSD), I feel it, but after an evening of struggle I often revert back to Ubuntu LTS. I have run Gentoo on my server, back when I didn't have kids nor required regular sleep. Now I just want stuff to work and run after installing it. I want Snaps and Docker to just work after apt installing them.
> But the speed and ease with which you get an application like NextCloud fully running on Ubuntu is unmatched
What cooled these worries for me was realising that if I know something to be much easier in Linux, it takes very little to launch a virtual machine and run it in that. So far it hasn't been needed!
I agree, I would also like that add that I learned a lot more about Linux when I learned FreeBSD. It it also a nice system for Java applications these days too, which I struggled with 5+ years ago.
One of the big differences between FreeBSD and Linux is that FreeBSD is designed and built as a complete system, whereas Linux is a kernel plus a collection of userland utilities from third-parties all of which has been configured by a vendor.
Neither approach is necessarily right or wrong, just different.
I keep hearing this ad nauseam, but what makes a system useful in the first place is the vast repository of third-party applications and not the base install (which you call "a complete system").
FreeBSD still has a plethora of 3rd party applications, it's just that they enforce things like what you can put in /etc and /var and so on, making things much more regular.
It's a FOSS project. Typically, FOSS operating systems differentiate on system features/applications and not on 3rd party applications. Things like package management, file system support, etc.
The FreeBSD Ports Collection[1] is the main means of installing 3rd party software on FreeBSD. Precompiled packages are available, too. You can view a list of available ports on FreshPorts[2]. Of course you can always just compile and build your own software if you choose.
Lately, since pkg was introduced I find myself installing stock packags most of the time. Only if I want X compile time feature enabled I'd use the ports system. Updates are faster as well. I used to `make world`, now I just do `freebsd-update -r <release> upgrade`.
I'm still a new user so I deliberately choose to compile ports to learn the FreeBSD way of thinking about stuff, understand how packaging works under the hood, and not fall into the trap of thinking it's "almost a Linux". Compiling ports is surprisingly convenient (at least after I learned the config-recursive make target...) and works most of the time.
But that said, letting the compilation of JDK 1.8 run overnight isn't exactly convenient, and for the next install I'm likely to use precompiled packages, confident that I do know how to compile ports on my own should I want to.
Yes, cases similar to building jdk from the ports collection are exactly why prebuilt packages exist. It's now very easy to provision a new system since the new package manager was introduced in 10R, pretty much like in Linux. Yet you also have the option of using ports tree and customizing packages yourself using `make config` and the building and installing them using `make` and `make install`. This is easier than installing source rpms or debs and customizing your build mainly because it's menu driven and all the popular options are on the menu.
FreeBSD provides a quartely branch (enabled by default since 10.2) with prebuilt packages that are supported up to 3 months, to avoid moving too fast and breaking things. There's also the latest branch, with the latest and greatest stuff.
The Ports collection is similar in scope to any of the application databases maintained by Linux distros such as Redhat and Ubuntu.
In fact, many of the packages are exactly the same from the same upstream. The differences are freebsd specific patches to fix small (like enabling or disabling different compile flags) or large (for example in the case of gnome or openjdk which requires effort to port) issues, but the packages are all there.
For a while there, one such feature was ZFS. I know ZOL is a thing, and the pool versions are the same, but I'd bet ZFS on FreeBSD is still more stable/standard than ZOL. (It's been a while since I tried to learn the differences between ZOL/ZFS under FreeBSD so that could be out of date)
But how can we measure the quality of the base system? I tried FreeBSD again a while back, but there were pretty bad bugs even in basic UNIX utilities like grep [1], some utilities + UTF-8, and I also had some kernel panics.
[1] I reported one of them in the FreeBSD bug tracker (+ patch). OpenBSD was actually really quick to solve this (I think tedu@ patched it), while the bug lingered for a long time with no activity on FreeBSD's end.
Linux used to be able to run just as lean as the BSDs, and perhaps still can (see Slackware).
but i fear that as it has gotten more attention in the corporate world more and more complexity has crept in as said corporate world wants something akin to AD and group policy so that the compute resources can be matched more closely to the division flow charts.
This, in combo with a ongoing "users are sheep that need a shepherd" attitude from certain elements of the community leads to complexity piling on.
From my experience and reading online, most people suggest spinning up a small Linux vm in bhyve and running docker from it instead of through FreeBSD.
Yes Heinz has added support for FreeBSD to Fifo and it works. Having setup a fairly large fifo setup . I can say its not as painful as Openstack or Vmware.
Well I mean you can run it, I was not even aware there is some effort[1] to run it.
What I was trying to say is that in my opinion this is one of inherent flaws in Docker and I think docker is really a dead end (I'm not talking about dead end of containerization, but just this kind of approach).
What people actually expect from containerization is essentially what Kubernetes is currently providing (quickly spinning new instances of processes, autoscaling, load balancing, rolling updates etc), but I already see questioning why docker is even needed at that point when really cgroups are used to restrict resources and processes already provide enough isolation.
I'll add that if you're installing a new system, install 11.1 or 12 (CURRENT), not 10.4. 10.4 is an update for people already on the old-stable 10.x branch.
Same recommendation for desktop too. Switching from Arch to FreeBSD couple of months ago was the best move I could do.
Silly way to compare stuff but my Arch always run with processor at 70-72 degrees Celsius. Same setup on FreeBSD and my processor runs at 39-45. Since everything else but kernel runs as exact copy it shows to me that FreeBSD either has less kernel overhead or does scheduling better.
A serious question, since such recommendations are regularly thrown around in these threads.
Can you run FreeBSD with a recent AMD GPU (I know that there is the proprietary NVIDIA driver)? Does Wayland work? What about HiDPI screens with GNOME? Is there support for Dropbox now? Is Chrome supported? Does it use GPU acceleration for movie playback?
(As far as I could gather the answer to most of these questions is still 'no'.)
Sorry I have no need or use for any of the listed packages/items. Nvidia works extremely well. I don't have AMD. I won't be using Wayland any time soon even if I could. GNOME is or is becoming systemd hostage so I won't install it ever on any system. Dropbox is not welcome for me. Chromium works well. I think GPU acceleration works well.
It all depends on what you use but definitely works well for my needs.
No, I was running 'pure' Arch, same as I do with FreeBSD now. List of my packages is very minimal so it can be assumed they reliably work the same way on both systems.
I am using offlineimap, mutt, vdirsyncer, khal, khard, w3m, urxvt...
That said, if using as a critical file server, etc be sure to do some system managment practice in a VM to get the commands down 1st - one of the major ways Linux differs from FreeBSD is that storage managment is radically different - and these are the kinds of commands you'll need to run in this context, only rarely, and typically when dealing with critical issues (disk fails, yadda).. so good to make sure you have solid fundamentals before putting all of your critical stuff there - not because of system issues, but because of potential PEBCAK issues..
Do you or anyone similarly have any suggestions or recommendations about NetBSD or OpenBSD? With Linux, the decision to choose Debian and CentOS has been easy for me. Ubuntu is very popular and Debian is at the top of the lineage tree. Similarly, RHEL or CentOS is very popular in the industry where RHEL is at the top of the lineage tree and CentOS is just the rebranded RHEL made available for free.
But with BSD, inspite of being very interested in it, I have not been able to pick one due to analysis paralysis. If I have enough time only to spend time with one of the BSDs, what possible criteria should I use to evaluate them against one another and pick one?
Give OpenBSD a try. Of the BSDs I've tried, it's the one that feels the most "tasteful", if that makes sense. Everything in the base system is well-documented, well-executed and feels consistent, and most things just do the right thing with minimal configuration.
The two things that made me install FreeBSD rather than OpenBSD was (1) the better hardware support when it comes to Intel-derived architectures, and (2) not as opinionated and, frankly, in many cases plain rude, project leads.
From a technical and documentation standpoint, OpenBSD is utterly fantastic and FreeBSD is doing its best to get ahead.
79 comments
[ 17.3 ms ] story [ 1990 ms ] threadI couldn't find anything about those extensions being enabled by default in 10.4.
Generally speaking, more conservative users will wait at least until the xx.1 point release before switching to that major version, but if you're on the very conservative side you may want to wait until xx.2. However, there are numerous updates even between minor point releases which you could apply if any errata are discovered if you don't mind.
10.4 = Versoin 10, Services Pack 4
11.1 = Version 11, Services Pack 1
At least that is how i think of it. Am I missing something? What isn't obvious about it?
I think the number of times I've witnessed discussions over the decades regarding "which version of FreeBSD should I use?" numbers in the hundreds.
10.4 is intended for individuals who are still running 10.x
sheesh.
:D
- The structure of the system makes total sense to me, making it easy to do stuff.
- The system is relatively simple in its design, which means I actually feel like I could troubleshoot any aspect of it. With Linux I often end up in a situation where I think, "Okay, and that component is in $complex_subsystem_12 so I have no chance of fixing it."
- The documentation is great. For regular system maintenance, mostly everything you'll ever need is in the FreeBSD Handbook and you can often find separate, but equally complete, documents for more specific tasks like the Porter's Handbook, the Project Model documentation, the Developer's Handbook and the various system architecture/design books floating around.
What cooled these worries for me was realising that if I know something to be much easier in Linux, it takes very little to launch a virtual machine and run it in that. So far it hasn't been needed!
Neither approach is necessarily right or wrong, just different.
I mistakenly assumed that OP was referring to 3rd party applications that were exclusive to FreeBSD.
[1] https://www.freebsd.org/ports/index.html [2] http://www.freshports.org/categories.php
All the ports are simply automatically configured with "--prefix=/usr/local".
But that said, letting the compilation of JDK 1.8 run overnight isn't exactly convenient, and for the next install I'm likely to use precompiled packages, confident that I do know how to compile ports on my own should I want to.
FreeBSD provides a quartely branch (enabled by default since 10.2) with prebuilt packages that are supported up to 3 months, to avoid moving too fast and breaking things. There's also the latest branch, with the latest and greatest stuff.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/p...
In fact, many of the packages are exactly the same from the same upstream. The differences are freebsd specific patches to fix small (like enabling or disabling different compile flags) or large (for example in the case of gnome or openjdk which requires effort to port) issues, but the packages are all there.
[1] I reported one of them in the FreeBSD bug tracker (+ patch). OpenBSD was actually really quick to solve this (I think tedu@ patched it), while the bug lingered for a long time with no activity on FreeBSD's end.
but i fear that as it has gotten more attention in the corporate world more and more complexity has crept in as said corporate world wants something akin to AD and group policy so that the compute resources can be matched more closely to the division flow charts.
This, in combo with a ongoing "users are sheep that need a shepherd" attitude from certain elements of the community leads to complexity piling on.
https://wiki.freebsd.org/Docker
Using FreeBSD as the Docker host requires the Linux compatibility layer, like Windows and macOS.
https://thenewstack.io/native-docker-comes-windows-mac/
[1] http://project-fifo.net
So with these requirements you can't run it on anything but Linux.
FreeBSD actually has compatibility mode and can run Linux binaries, but why would I want that instead of running a native code?
What I was trying to say is that in my opinion this is one of inherent flaws in Docker and I think docker is really a dead end (I'm not talking about dead end of containerization, but just this kind of approach).
What people actually expect from containerization is essentially what Kubernetes is currently providing (quickly spinning new instances of processes, autoscaling, load balancing, rolling updates etc), but I already see questioning why docker is even needed at that point when really cgroups are used to restrict resources and processes already provide enough isolation.
[1] https://wiki.freebsd.org/Docker
Silly way to compare stuff but my Arch always run with processor at 70-72 degrees Celsius. Same setup on FreeBSD and my processor runs at 39-45. Since everything else but kernel runs as exact copy it shows to me that FreeBSD either has less kernel overhead or does scheduling better.
A serious question, since such recommendations are regularly thrown around in these threads.
Can you run FreeBSD with a recent AMD GPU (I know that there is the proprietary NVIDIA driver)? Does Wayland work? What about HiDPI screens with GNOME? Is there support for Dropbox now? Is Chrome supported? Does it use GPU acceleration for movie playback?
(As far as I could gather the answer to most of these questions is still 'no'.)
It all depends on what you use but definitely works well for my needs.
I am using offlineimap, mutt, vdirsyncer, khal, khard, w3m, urxvt...
FreeBSD's hardware support is pretty poor - they don't even support intel graphics cards from 3 years ago - https://wiki.freebsd.org/Graphics#Intel_Graphics. WiFi support can also be spotty.
That said, if using as a critical file server, etc be sure to do some system managment practice in a VM to get the commands down 1st - one of the major ways Linux differs from FreeBSD is that storage managment is radically different - and these are the kinds of commands you'll need to run in this context, only rarely, and typically when dealing with critical issues (disk fails, yadda).. so good to make sure you have solid fundamentals before putting all of your critical stuff there - not because of system issues, but because of potential PEBCAK issues..
But with BSD, inspite of being very interested in it, I have not been able to pick one due to analysis paralysis. If I have enough time only to spend time with one of the BSDs, what possible criteria should I use to evaluate them against one another and pick one?
From a technical and documentation standpoint, OpenBSD is utterly fantastic and FreeBSD is doing its best to get ahead.