Neither approach is necessarily right or wrong, just different.
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.
[1] https://www.freebsd.org/ports/index.html [2] http://www.freshports.org/categories.php
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...
All the ports are simply automatically configured with "--prefix=/usr/local".
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.
I mistakenly assumed that OP was referring to 3rd party applications that were exclusive to FreeBSD.
[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.
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!
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..
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.
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.
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...
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.
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.
https://wiki.freebsd.org/Docker
Using FreeBSD as the Docker host requires the Linux compatibility layer, like Windows and macOS.
- 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.