* Most "unix" admins only know linux and will advocate for it vigorously because it is so much better than.. "what do you use again? Fedora? Ah, FreeBSD, something with F, I knew it!"
* Management not always listens to reason but just wants a discussion go away, so they listen to the loudest advocates.
* It is easier to copy a solution to a linux problem from stack overflow than to read the FreeBSD handbook, understand the problem and fix it.
* FreeBSD only is fun when one has a higher level of expertise: Knowledge of sh and at least a basic understanding of make are required, being able to at least read c code makes life much easier.
* Reading docs is hard. FreeBSD forces one to understand the standard unix tools that come with it. That means one has to spend some time reading the docs (or at least skimming over them so one knows where to look when the need arises). If one does not understand the tools, even simple init scripts are black magic.
* No exposure to FreeBSD at all: most hosting companies won't even list FreeBSD as an option (though in most you'll find some unix geek who'll happily connect KVM or IPMI and insert the install-CD for you).
* The FreeBSD community is much less forgiving than the linux community: Ask a question that can be answered easily by reading the handbook or some man-page and the response will probably be silence (rarely flaming, just silence).
And finally also some points where one could argue that it makes sense not to use FreeBSD from an economic point of view:
* When using FreeBSD one is regularly forced to clean up linux-BS when venturing outside what /usr/ports provides: #!/bin/bash - or even worse #!/bin/sh that actually wants a bash - is one of the most common problems.
* When compiling software from source that does not come from /usr/ports one regularly has to do research what $leenox-distro-package XY provides because documentation just gives command lines for the most common linux distributions. "Soo.... what exactly does that software need to compile when the docs tell me to simply apt-get foo-23.5 and bar-42.666?"
Some of my datacenter clients use freeBSD for various bits, and I have been that guy. In the end they're migrating away because it's incredibly hard to find experienced engineers. What you describe as "reading docs is hard" can be equated to "my team will be slower for negleglible gain." Dicking around with ports and make is fun, but at the end of the day, we seek lower latency services and faster outage response times.
EDIT: there's also a network effect in puppet / chef / ansible -- More work for your operations team when every community module for managing services doesn't support your platform of choice.
> What you describe as "reading docs is hard" can be equated to "my team will be slower for negleglible gain."
Yes, but only from a very short-sighted point of view. I cannot count the "devops"-meetings I had to attend as a consultant during which I hacked a command line that solved the problem the meeting was supposed to make a plan for and estimate costs...
I dare to argue that letting the ops learn the ropes on company time would have been much cheaper than my fees plus costs for working time employees spent on that meeting. But I understand this is very hard to quantify and that in a startup culture people don't want to think beyond the point where the financing is used up.
My fav. test for sysop/devop candidates: "Tell me how large the home directory of all users who use [t]csh as a login shell is on that machine; no, you cannot install anything, there is no perl, ruby or python. You have 90 seconds.". 99% fail. I've even interviewed people who applied for a sysop/devop positions who could not set up a host if not through puppet because they know sh1t about the target OS.
PS: Thanks for being "that guy" who allowed me to use a mature OS. People like you allowed me to have a 336 day uptime as the lower limit. Most of my machines have more than a thousand days of uptime :)
> My fav. test for sysop/devop candidates
But how do you query your LDAP server without installing additional tools? Because in 2016, we have more than one machine. Hundreds. Grepping /etc/passwd is missing the forest for the trees.
You can have all the shell experts, I need people who can write Chef code that passes peer review. kitchen lets us poke around the OS all we want to inspect proper functioning.
> People like you allowed me to have a 336 day uptime as the lower limit. Most of my machines have more than a thousand days of uptime :)
AFAIK, none of the BSDs have online kernel replacement facilities. So you willingly admit you haven't upgraded your kernels in years? I know fBSD has a reputation, but every once in a while this still happens: https://threatpost.com/freebsd-patches-kernel-panic-vulnerab....
You are missing my point, it's about being able to filter and transform textual output. If a sysop can only do what the UI provides s/he is useless when creative solutions are asked for.
> You can have all the shell experts, I need people who can write Chef code that passes peer review. kitchen lets us poke around the OS all we want to inspect proper functioning.
Every good sysop I've met can write your Chef code. Understanding system basics and managing with high level tools is not mutually exclusive. Tools like Chef are the result of exactly those sysops automating what they could. You know that saying? "Tomorrow I'll replace you with a shell script." ;)
> So you willingly admit you haven't upgraded your kernels in years?
Yes, I only update when a security problem concerns me and that is pretty rare with custom kernels that only have what is required. Even my desktop setups need a new kernel only once a year or so.
I'm (a little) ashamed to admit tech support via trolling. Linux sucks because you can't even [whatever].
It is nice to get a quick response of "it's just [whatever], noob".
Although, that was a last resort. I've met a couple of people that reread man pages every year, i've never quite picked up that practice. Once you get the hang of parsing the super terse examples, man is pretty great.
Indeed, it is. But one won't learn anything of value. One just learns the solution to a very specific problem. If one chooses to learn the basics, more often than not one will decide that it is quicker to dive into the problem and fix it than to "troll" tech support.
Recently I found my only machine running FreeBSD (as a testing machine) was kernel crashing occasionally. On a whim I googled '<machine name> kernel crash', and found a page which discussed an extra linux boot-time flag I had to add, to disable some feature of the graphics card. I couldn't figure out how to do the same thing on FreeBSD, so just switched to Debian, and added the magic option. No more crashes. Now the machine runs a FreeBSD VM on top of linux.
I mostly agree with you, but there are some unique facts that, back in the day, you just sort of had to know. something like
echo 1 > /proc/sys/net/ipv4/ip_forward
This is my favorite part of the Linux community. Ask something that you aren't sure of, and if it's wrong, you'll get quite some volume of responses correcting you!