July 31 2014 2:41 AM, "Darren Pilgrim" wrote: >> >> No. I believe pf should be removed from FreeBSD and efforts refocused >> on keeping ipfw up to date and feature complete. It makes more sense to >> look at what pf, ipf, nbtables, etc. are all doing as a source of ideas >> for what we can do with ipfw. A decade ago, there was justification for >> adding pf: at the time, ipfw lacked some major features. >> >> Ipfw has since caught up. I see no remaining value in having more than >> one packet filter in the base. Ipfw is more mature and less broken, so >> we should keep it and ditch the rest in the name of survival efficiency. >>
pf is not simply replaceable in many environments. For example, people use it specifically for its integration with the spamd greylisting daemon. I think it's reasonable to assume they did so because the whole spam filtering stack performs better on FreeBSD than on OpenBSD. This was just recently mentioned on twitter: @ng_security Why was the pf ioctl needed buffer reduced in FreeBSD 10? I'm not able to load my full spamd blacklist anymore. @freebsd #spamd #pf https://twitter.com/ng_security/status/494982307905040384 I personally use pf for many reasons, spamd included. I don't think anyone out there is interested in forking spamd to play ball with ipfw so we would also be alienating these users who can't just change packet filters. Is there even an equivalent to pfsync for ipfw? I didn't think so, but I could be wrong... In the world of firewalls pf has been put on a quite a pedestal. OpenBSD pushed it hard and it marketed it well; people found it both powerful and easy to use which created a cult following and lots of word of mouth advertising. I find it hard to agree with removing pf from FreeBSD because of the existing userbase. If there was an experimental label on it I would find its removal easier to swallow. I think it's worth pointing out that nobody really wanted to maintain an incompatible fork of ZFS indefinitely either; it would be a monumental if not suicidal task. And who wants to deal with the bad PR about FreeBSD being years behind Illumos features or, *gasp*, even letting a native Linux implementation one-up us? People found a way to collaborate, OpenZFS movement was founded, and this is a mostly solved problem, OS nuances aside. I can appreciate that people seem to care more about their data than their packet filters and FreeBSD ZFS certainly moves a lot of servers and appliances furthering the userbase whether or not they're using FreeBSD or TrueOS or some other derivative. Let's continue to give people another reason to put FreeBSD in their datacenters. Let's try to compete in the firewall/packet filter space too. On a side note I'd also like to point out that FreeBSD has been advertising pf by listing it first in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html I'm sure there's a subliminal message being sent there, intentional or not. I don't want to see FreeBSD lose mindshare from its absence in a time where FreeBSD uptake seems to be rising thanks in part to bad decisions in the GNU/Linux camp. This feels like a solvable problem if funding and enthusiasm is put behind it. OpenBSD really sounds willing to collaborate if not just because they're tired of seeing neglected forks of one of their prized babies: FreeBSD, NetBSD, DragonFlyBSD, OSX, iOS... _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
