[jlg23]

After 18 years of running FreeBSD on my servers, my $0.02:

Politics/marketing:

* 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.

Knowledge/Community:

* 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?"

[jldugger]

> 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).

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.

[jlg23]

TL;DR: You are absolutely right - but that is very, very sad.

> 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 :)

[jldugger]

This is a attitude classic case of engineers optimizing for the wrong damn thing. Sure, we've all sat in on 18 month projects that should have been a five line shell script. One hopes that whatever expert is teaching ops "the ropes" knows this already. But at least you get a consultant paycheck for their ignorance.

> 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....

[jlg23]

> 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 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.

[jfoutz]

> 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.

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.

[jlg23]

> It is nice to get a quick response

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.

[CJefferson]

Often finding an answer gives me useful knowledge I can then use in other circumstances, but I can't possibly know every corner of my OS.

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.

[jfoutz]

Well, this specific case is trolling zealots, not tech support.

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

You know exactly what you need to do, but haven't memorized the name of the bit to twiddle to get the behavior you want. Now there are, of course, tools to configure these sorts of things. More importantly, google and stackoverflow help immensely with this kind of thing.

[chucky_z]

> the response will probably be silence (rarely flaming, just silence).

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!