FreeBSD Quickstart Guide for Linux Users

In my experience, FreeBSD's greatest asset doesn't fit well on a feature list. It's that it has a different attitude towards change than Linux.

Linux is a diverse ecosystem, with tons of experiments driving it forward. Different package managers, different kernel patches, different userland configurations, different means of administration... and that's a great thing.

FreeBSD is not diverse or experimental. FreeBSD is a deliberately moving beast, that adopts technologies and ideas in a more methodical manner, often after other OS's (OpenBSD / NetBSD / DragonflyBSD / Solaris / Linux / OS X) have proved that the ideas are solid, and lasting, and then it integrates them carefully, so it still looks like FreeBSD (but with some new capabilities, or better performance, or whatever), rather than having drastically different administration mechanisms, or performance characteristics, or anything else.

Personally, I like this stability. I like that it's a platform that once learned, can be largely forgotten about. But that said, it does require learning first, and while it's powerful, it's not shiny or sexy. But even excluding the man pages and documentation, zfs, the pf firewall, and many other things I like about FreeBSD, this is the winner for me. I just love that it doesn't change unless the change is a large win.

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

And they both suck. ports and portage are horrible excuses for package management.

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

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

With ports it is entirely possible to install a package that does not work completely or at all due to missing dependencies. This is not something you ever need to think about with apt-get or yum. But on FreeBSD, I found it to be true of three or four packages out of a dozen or so that our software depends on (Apache, in particular, is really easy to screw up if you want any reasonable feature set; the ProFTPd port was broken for years). If you'd like an example, try installing the Apache port with all the major features that you'd expect in a virtual hosting environment, without intentionally installing all the pre-requisites in advance. You'll find that you've got a steaming pile of wreckage at the end of your nice long wait for it to build.

"Uninstallation appears about on par with APT from where I'm sitting."

It's trivially easy to remove a package required by other packages with ports. Meaning that it's entirely possible to break vast swaths of your system without warning.

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

I simply can't believe anyone could run a fully functional, and secure, FreeBSD system on nothing but binary packages. Many of them simply do not work once you bring the system up to date. The libraries move out from under the binaries, and they simply stop functioning. Either they'd be running an out of date, and thus insecure, system, or they're having to rebuild packages along the way to keep things working (and they'd have to test to know which stuff is broken, because ports and the pkg tools won't warn you when you're breaking stuff by updating software).

I also don't understand the mindset of anyone that chooses to wait hours for their system to be useful while they wait for a huge stack of ports to build. How little is your time worth to you?

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

rpm -V httpd

This command verifies the installation of httpd. Does what's running on the system match what the package contains? If not, it tells you which files have changed.

There is no equivalent for ports that I know of, and I'm pretty sure it would be deeply non-trivial to implement such a command because I don't think ports have a manifest or any sort of particular knowledge about what the payload of the package is. ports provides very little means of finding out what's already running on the system, which, from the perspective of someone trying to automate installation of a huge array of packages, while avoiding breaking any existing packages that the user may have pre-installed with custom options, is a pretty horrible experience.

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

Yeah, I find it difficult to believe, too. It's just stupid, but it's true. You can build a pkg and install it, but then there's no way to keep it up to date via native means (except requiring the user to download and install new pkgs over time, which is unacceptable when there are dozens of packages to deal with). You could also fudge your port into the ports tree, but that's undocumented, and the FreeBSD developers I talked to said it was a bad idea, and besides it still doesn't solve the problem of keeping your packages up to date using native means. You'd have to write a script or something that the user would need to run in addition to the usual ports management stuff to keep downloading and munging in your ports.

So, if you want to distribute a pile of applications and keep them up to date, you have to build your own update management system. Our products already have one (because it runs on hundreds of operating systems and versions, most of which don't have reasonable package management), but we strongly prefer to keep it native, since people already understand how to keep their system up to date using yum or apt-get, or whatever. We don't have that ability on FreeBSD.

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

Give it time.