Data de-dupe is FUBAR. It's why snv_134, which was supposed to be final was scrapped.
I hadn't heard of a FreeBSD kernel issue, but if that's true, it might just be for the best for the next 6 months at least. de-dupe is kinda a useless feature if you're not a hosting company anyway. A hosting company could take advantage of storing tons of mostly-the-same VMs. It's not the few hundred GB in our dozens of base VM images that concerns me though. It's the terra-bytes of multimedia and databases.
Plus de-dupe takes a lot of RAM. A lot. There was a time where it would've been very nice, but as it stands, it's really a niche product to come up with a situation where it's RAM requirements, and it's rather small storage savings might make sense.
Lack of proper package management (you can't compare ports to yum or apt) is a dealbreaker for me. Ports is minimal and you can, conceivably, grow a real package management system out of it, but it's not one.
That's just silly. Having used pkg, pkgutil, pkg-get, apt-get, and ports near daily for awhile ports hands down beats anything on the *solaris platforms.
For one, you can find the libraries you want and they actually work.
Postgres 8.4 on FreeBSD? No problem. With plperl? No problem. OpenSolaris? Well, if you want to run 32bit Postgres on a system with 48GB of RAM sure. No 64bit for you though. And Oracle shutdown the Postgres build farm servers they were hosting.
Just because FreeBSD stores it's package information in makefiles and pkg stores it in a catalog doesn't change the end result. Ports are as easy to use (if you bother to read the very simple README), and offer far more robust support and packages than any flavor of Solaris I'm familiar with.
There was a time I'd have agreed about Ports, but 30 minutes later I had read the README and realized I was just being lazy. ;-)
