On 7/21/14, 7:27 AM, Andreas Nilsson wrote:
On Sun, Jul 20, 2014 at 7:41 PM, Alexander Kabaev <kab...@gmail.com> wrote:
On Sun, 20 Jul 2014 10:15:36 -0400
Maxim Khitrov <m...@mxcrypt.com> wrote:
On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels <lars.eng...@0x20.net>
wrote:
On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote:
all of that is true, but you are missing the point. Having two
versions of pf on the bsd's at the user level, is a bad thing. It
confuses people, which puts them off. Its a classic case of divide
an conquer for other platforms. I really like the idea of the
openpf version, that has been mentioned in this thread. It would
be awesome if it ended up as a supported linux thing as well, so
the world could be rid of iptables. However i guess thats just an
unrealistic dream
And you don't seem to get the point that _someone_ has to do the
work. No one has stepped up so far, so nothing is going to change.
Gleb believes that the majority of FreeBSD users don't want the
updated syntax, among other changes, from the more recent pf versions.
Developers who share his opinion are not going to volunteer to do the
work. This discussion is about showing this belief to be wrong, which
is the first step in the process.
In my opinion, the way forward is to forget (at least temporarily) the
SMP changes, bring pf in sync with OpenBSD, put a policy in place to
follow their releases as closely as possible, and then try to
reintroduce all the SMP work. I think the latter has to be done
upstream, otherwise it'll always be a story of diverging codebases.
Furthermore, if FreeBSD developers were willing to spend some time
improving pf performance on OpenBSD, then Henning and other OpenBSD
developers might be more receptive to changes that make the porting
process easier.
I am one person whose opinion Gleb got completely right - I could not
care less about new syntax nor about how close or how far are we from
OpenBSD, as long as pf works for my purposes and it does. This far
into the thread and somebody has yet to provide a comprehensive list of
the benefits that we allegedly miss, or to come up with the real
benchmark result to substantiate the performance claims.
Focusing on disproving anything Gleb might be believing in on the
matter, while an interesting undertaking, does nothing to give you new
pf you supposedly want. Doing the work and bringing it all the way to
will completeness for commit - does.
It was stated repeatedly by multiple people that FreeBSD's network
stack is way too different from OpenBSD, we support features
OpenBSD doesn't and vice versa, vimage is a good example, which throws a
giant wrench into the plan of following OpenBSD 'as closely as
possible', even as the expense of throwing away all of the SMP work
done in pf to date.
I like vimage, don't get me wrong, but it also seems to have lost traction.
If vimage is the only thing holding a pf import back there ought to be some
discussion about which is a priority.
As one involved with Vimage, I get feedback all the time that lets me
know it's in really heavy use in some pretty interesting commercial
situations. It HAS lst some traction in terms of added work, but
that's because it's solid enough for people to use.
In the situations where it's being used, it's a game changer and rhe
conversation goes something like:
"hey vimage and pf don't work together.. guess that makes the firewall
decision easy.. use ipfw"
Also, the openbsd stack has some essential features missing in freebsd,
like mpls and md5 auth for bgp sessions.
/A
_______________________________________________
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"
_______________________________________________
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"
