4 ms·
There are a lot of reasons. The ports system has already been mentioned, and some people really like ZFS. More to the point, though, licensing differences ens
by apotheon 16y ago
There are a lot of reasons. The ports system has already been mentioned, and some people really like ZFS. More to the point, though, licensing differences ensure that more software (like ZFS) is legally compatible with FreeBSD than with any typical Linux+GNU distribution.
It has also been mentioned that FreeBSD is "a sysadmin's dream". A big part of the reason for this is its userland. The truth of the matter is that BSD tools are often much more consistent and less overly complex, and have better thought out basic functionality and interfaces, than GNU tools.
BSD Unix systems also resist the influence of the GNU project where many Linux distributions do not. For instance, in some distributions you will find far too many pieces of software that have nothing for man pages except a reference to how the real information is in a GNU Info page. The GNU project very much as a "not invented here" problem, where it not only wants to replace everything in the world -- even when it's "free software" -- with something weird and less usable that bears the GNU stamp on it. Meanwhile, the various BSD Unix systems insist on standardized tools and documentation that is easy to use, like man pages instead of Info pages.
Speaking of documentation, that's another good reason to use FreeBSD (or OpenBSD, for that matter). The big BSD Unix systems are among the best-documented OSes I have ever seen, and I have seen quite a few operating systems. Consider the completeness and helpfulness of the FreeBSD Handbook, which is actually one of the best pieces of documentation on the Web even for many Linux distributions, but is even more helpful for FreeBSD (of course).
Also . . . this is not comprehensive, but it might serve as a nice introduction to the whys and wherefores:
http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4lin...
I wrote a comparison as well, once, but I seem to have misplaced it.
- Nick_C 16y agoAlso, (I haven't run a BSD for several years, but, from memory) one of the biggest philosophical differences is that *BSD runs a monolithic kernel whereas Linux runs a modular kernel. Might not sound like much, but it is very different mindset when it comes to security, user-land and such. Is that still the case?
- koenigdavidmj 16y agoAll three of the major BSD derivatives have the ability to put parts of themselves in modules. They are all monolithic kernels, as is Linux. Monolithic, in kernel speak, does not refer to having everything compiled in; it is more concerned about what is in kernel space (can do anything it wants with the hardware) and what is in user space (what is restricted at the hardware level to playing in its own memory). Monolithic kernels have pretty much everything in memory, and microkernels have pretty much everything in moderately-privileged userspace processes that talk to each other via message passing.
- koenigdavidmj 16y agoEr, I apparently cannot be bothered to read my own posts. s/Monolithic kernels have pretty much everything in memory/Monolithic kernels have pretty much everything in kernel space/
- apotheon 16y agoIf it's any consolation, I understood what you meant.
- apotheon 16y agoWhat koenigdavidmj said is true. The kind of "modular" that applies to the Linux kernel (and applies just as much to the FreeBSD kernel) is not the same kind of "modular" as you get with a microkernel OS like MINIX 3. All the major BSD Unix systems and any OS that uses a Linux kernel are all monolithic kernel OSes.
- SwellJoe 16y agoI would just like to point out that I'm pretty sure ports is the longest running joke in UNIX-like systems. It always gets held up as an example of why FreeBSD is superior to Linux, and that's just insane. Its dependency resolution capabilities are awful, its third party repository capabilities non-existent, scripting it is an exercise in frustration, packaging for ports is easy but leaves me with feelings of horrible guilt because of the complete and utter lack of regard for the sanity of the end user, uninstallation is laughably weak particularly with regard to dependencies, and that's just the obvious deficiencies in the ports system. When you dig deeper, you find that the binary packages are universally unusable (often they don't even run because the libs they link against have been upgraded in the repository without updating the packages that depend on them), that you can't query ports for the actual state of the filesystem vs. what it thinks the state of the filesystem is because it simply doesn't know, and the list goes on and on. I find something new to hate about ports every single time I have to build something for it. apt-get and yum are vastly superior to ports in pretty much every single regard, though they are slightly harder to use for packaging software (but since ports doesn't support third party repositories in any reasonable fashion it doesn't matter, since you can't use the native package management on FreeBSD to distribute your applications anyway). Sorry for the angry rant, but my level of disgust at seeing ports held up as an example of something good about FreeBSD is impossible to contain. I generally think FreeBSD is a very fine operating system, with good documentation, and a very smart community. But, it's not because of ports.
- apotheon 16y ago> Its dependency resolution capabilities are awful Funny. I had more problems with APT dependency resolution than with ports dependency resolution, probably by an order of magnitude, despite the fact that APT was the best package system I had encountered in Linux-land. > its third party repository capabilities non-existent I must admit that APT's third-party repository capabilities are pretty nice. On the other hand, I have not needed a third-party repository with FreeBSD yet, so I have no basis for comparison. > scripting it is an exercise in frustration Strange. I've scripted half a dozen different things for working with ports, because it was so easy to do, then subsequently found out that someone else had not only already done the same thing but done it better and committed it to ports. Your experience is obviously much different from mine. > packaging for ports is easy but leaves me with feelings of horrible guilt because of the complete and utter lack of regard for the sanity of the end user What's so insane about its (lack of) regard for the end user? Do you just think end users should never have to wait for a compile to finish? Is this an implied rehash of what you've already said? What exactly is the problem in this case? > uninstallation is laughably weak particularly with regard to dependencies Uninstallation appears about on par with APT from where I'm sitting. > the binary packages are universally unusable I don't bother using the binary packages, for the most part, but I know there are bunches of people who basically run their FreeBSD systems entirely off binary packages. I suspect they would disagree with your assessment. > you can't query ports for the actual state of the filesystem vs. what it thinks the state of the filesystem is because it simply doesn't know Example, or clearer explanation, please. > since ports doesn't support third party repositories in any reasonable fashion it doesn't matter, since you can't use the native package management on FreeBSD to distribute your applications anyway I find this difficult to believe, but what the hell -- I haven't bothered looking into it. I'll just accept what you say for argument's sake, for now. > Sorry for the angry rant, but my level of disgust at seeing ports held up as an example of something good about FreeBSD is impossible to contain. That's obvious. Too bad your disgust for it runs completely counter to my own experience.
- apotheon 16y ago> The GNU project very much as a "not invented here" problem, where it not only wants to replace everything in the world -- even when it's "free software" -- with something weird and less usable that bears the GNU stamp on it. Oops. I lost track of how I was writing that sentence about halfway through. I meant to say this: The GNU project very much as a "not invented here" problem, where it not only wants to replace everything in the world -- even when it's "free software" -- but chooses to do so with something weird and less usable that bears the GNU stamp on it, and works in a fully incompatible manner. (emphasis to point out the differences)