"Also I think a more important use of ports, is security fixes. When OpenSSL drops it's bug of the week you can patch openssl and rebuild the port tree. Then yo

"Also I think a more important use of ports, is security fixes. When OpenSSL drops it's bug of the week you can patch openssl and rebuild the port tree. Then you can push the new, patched binaries into production. A sysadmin can do this all without relying on the package maintainer, ie no waiting on Redhat to push out new rpms." I can't remember the last time I was aware of a security problem before Red Hat (and CentOS) had rolled out a fixed package. I usually know about security issues when I see a slew of update notifications from my servers (even though I'm on several security related mailing lists). Realistically, I rely on my OS vendor to provide my security fixes in a timely manner. If my systems security relied on me being able to apply patches manually in a timely manner, it would be a disaster waiting to happen. And, it is a big pile of labor I don't want on my plate. Besides, nothing stops one from installing the source package (whether RPM or deb), adding the patch, rebuilding, and pushing to your local yum or apt repository. That workflow is entirely reasonable on Linux, as well (historically easier, since maintaining a third party repo was so much easier for yum, though apt is a bit more cantankerous; it looks like FreeBSD finally supports multiple repositories and you don't need to mirror the whole ports tree just to provide a handful of custom packages, which used to be the case). ports does not provide a unique feature here, and if it is required to manually patch software in order to be reasonably quick to address security issues, that's a bug not a feature.