Much, much improved with the introduction of pkgng. Now you can use the stock binary packages without going through the ports tree. The workflow is "pkg update", "pkg install ...", "pkg upgrade", "pkg delete ..." (includes automatic dependency removal). It's basically the same user experience as APT or yum. Then, there's whatever PC-BSD uses, which is also supposed to be very user friendly. (I wouldn't know. PC-BSD stopped supporting 32-bit PCs a few releases back, so I gave up on it.)

That said, you can still build and distribute custom packages---the biggest strength of the FreeBSD Ports tree compared to other distributions, in my opinion. This too has improved with the introduction of the OPTIONSNG framework and the Poudriere build system. It used to be that you had to manually run "make config" per port or to somehow shoehorn per-port options into /etc/make.conf. All of that's been replaced with a much more sensible way to configure the port build process. For example, the following sets the default versions of Perl and Apache to pull in as dependencies (if needed by the port), and then it configures several ports:

  WITH_OPENSSL_PORT=YES
  DEFAULT_VERSIONS= perl5=5.18 apache=2.4
  ca_root_nss_SET=  ETCSYMLINK
  moreutils_UNSET=  MANPAGES

Poudriere handles en masse package building. If you want to build and distribute your own custom package repository, you'll want to use Poudriere to manage the process for you. For more information see http://www.bsdnow.tv/tutorials/poudriere first, then RTFM. It's super easy to use. Also, you can custom build a few packages with Poudriere, but fall back on the main FreeBSD package repository. It's pretty stellar.

Nowadays, I only need to use portsnap/portupgrade when bootstrapping my Poudriere deployment.

Er, I mean portmaster, not portupgrade. I haven't used portupgrade for some time now.

FreeBSD has recently included a new binary package manager (pkg) which seems to work well enough, but in all honesty it's still feels a few years behind apt / pacman / yum.

The nice thing is how well you can mix and match ports (source based management, in case you weren't aware) with the binary packages. And FreeBSD ports are surprisingly easy to manage too.

It's also worth mentioning that FreeBSD runs circles around a lot Linux distributions when it comes to upgrading. There's a tool, literally called freebsd-update, which is the equivalent of apt-get dist-upgrade and makes the whole process so painless you could be forgiven for thinking you were running a rolling release OS.

> And FreeBSD ports are surprisingly easy to manage too.

It's been ages since I've used FreeBSD, but I have fond memories of using portupgrade (and portinstall, which comes with it) to manage source-based ports. It's probably faster to do make && make install instead, but the automation from portupgrade is useful and the -c/-C options can be helpful, as is its control over when to clean the package build dir.

I sort of grew up with the BSDs as my first introduction to a Unix-like environment, and in all honesty it was the reason I first migrated to Gentoo when I started using Linux (the Gentoo way was more familiar). I now use Arch for personal use (and Ubuntu for services), but I think the FreeBSD philosophy is in many ways superior. Clunky, perhaps, but usually void of unnecessary complexity.

> FreeBSD has recently included a new binary package manager (pkg) which seems to work well enough, but in all honesty it's still feels a few years behind apt / pacman / yum.

You don't expect someone to be able to write a full-featured bug-free package manager equivalent to those that have matured over a decade in under a two years do you? What't they've done so far is beyond impressive and at this pace it will be improved beyond the competition within 3 years.

I think the FreeBSD devs have done a cracking job with pkg and I did comment about how it's a new package manager to give context that it's likely to be refined and improved upon with time.

All I was just trying to give a balanced opinion but it seems you can't post anything on here these days without someone finding criticism. {sigh}

> You don't expect someone to be able to write a full-featured bug-free package manager equivalent to those that have matured over a decade in under a two years do you?

Well, you kind of would, wouldn't you? It seems that this should be a well-understood problem these days, at least unless you're going to do something wildly experimental like Nix. Maybe this says more about the archaic languages and systems we're still, though.

(Not that I know much about 'pkg' specifically. What does it do that's different from every other mainstream package manager out there? Why not use APT, for example? Since Debian has a FreeBSD flavour, presumably APT should be able to run without too much tweaking.)

As others stated, binary package management is state-of-the-art now, thanks to the `pkg` command (aka the pkgng system). In fact I can never remember all the sub commands for apt+dpkg but pkg is a dream by comparison. I particularly like `pkg audit` - https://www.freebsd.org/doc/handbook/pkgng-intro.html#pkgng-...

Btw, I would completely disagree that the sysadmin side is or was behind Debian. FreeBSD is way easier to sysadmin than most Linux, even without pkg.

> Btw, I would completely disagree that the sysadmin side is or was behind Debian. FreeBSD is way easier to sysadmin than most Linux, even without pkg.

This may be true now but it certainly wasn't the case in the early 2000s. When we switched, our number of systems went up by an order of magnitude (100s) but the amount of sysadmin time required actually went down. Consistent package management and debconf were most of the reason.

Interestingly I switched from Linux to FreeBSD around 2002, primarily because I was frustrated with Linux sysadmin. Perhaps I was more of a newbie but the inconsistencies in Linux system organization and the confusing, low quality, half-obsolete docs, and unbounded time required for troubleshooting were some of the reasons. When I switched to FreeBSD and started using ports, my sysadmin time dropped significantly. But I was only using a single system.

You can configure ports the way that you like on one system. Then tarball /usr/local and bring the tarball to every other system. Just wipe out the existing /usr/local and replace it. This is supposed to be a feature that reduces time spent.

The ports stay very much up to date and I've never had an update break my system (in contrast to my experience on Ubuntu and even Slackware - must admit I haven't used Debian that much). I like the way it embraces the fact that updates will sometimes require manual intervention and so there's a standard file that you read before updating and occasionally there are things you have to do, but as long as you follow that you'll be fine. I also think the split between ports and base system works well.

At an implementation level the packaging system is still made of twine - Ruby scripts that call Makefiles are not my idea of robust engineering. But I've gradually come to accept that, just like the project's continued use of CVS, they've managed to make it work.

The Ruby scripts (assuming you're referring to portupgrade?) are optional.

The FreeBSD Project might still maintain a CVS repository, but all development's been moved to Subversion. Or if Git is your thing, they have some kind of synchronization set up with https://github.com/freebsd/freebsd.

Isn't Ruby scripts that call Makefiles exactly how Homebrew works on the Mac? :-D