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 

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


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 

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:


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
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to