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