[ previous ] [ next ] [ threads ]
 
 From:  Chris Buechler <cbuechler at gmail dot com>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] The future
 Date:  Wed, 12 Oct 2005 20:13:46 -0400
a few more comments...

On 10/12/05, Manuel Kasper <mk at neon1 dot net> wrote:
>
> First of all, I'd like to give a quick overview of m0n0wall as it
> exists today - an experiment I started in 2003 that now runs about
> 15,000 firewalls worldwide.

I must say I'm curious where this number came from.  :)  Download
stats and referrals to m0n0.ch/wall/ from private IP's (likely from
m0n0wall webGUI's) can tell some of the story, but I don't see where
it could be very accurate.


On development activities:
I've heard more than once from people who have contributed in the past
that they would contribute more if it was a more open development
environment.  The -dev list is intended for that purpose, but it gets
a lot of noise.  pfSense has a private committers-only dev list that
isn't archived anywhere, and is invite-only, and has turned out to be
a great resource for the developers (you can be a lot more open and
not watch what you're doing so much when your words won't be forever
archived by Google).  I would suggest a committers-only, invite-only
list.

IRC also proves very useful for discussions between pfSense devs. 
Real time communication, though it can be difficult with devs in many
time zones around the world, is invaluable for many reasons.


On FreeBSD, for those who haven't followed and messed with 4.x vs. 5.x
vs. 6.x as much as I have:
FreeBSD 4 is a hard act to follow, but there's no question we can't
continue with it.  4 has one of the fastest general-purpose TCP/IP
stacks ever written.  Given m0n0wall's core focus on embedded devices,
speed of the choice OS is critically important.  As 5.3 showed us,
we'll have serious issues if the next OS choice degrades performance
significantly.  Though none of the options will be as slow as 5.3,
especially when put under higher pps load (with BitTorrent being the
ultimate test).

I consider FreeBSD 5.x in many ways to be an "oops" release in some
ways, and if you read things from FreeBSD developers and supporters,
they don't come right out and say that but they certainly lead you to
believe that.

Dru Lavigne, if you don't know, one of the most widely known BSD
writers/documenters (ONLamp, O'Reilly BSD Hacks book, etc.) and a
FreeBSD trainer, advocate, and PR person at times it seems, wrote back
in July (on choosing which FreeBSD version to use, 5 or 6):

--
I like Colin Percival's quote on whether or not to use this beta:

"If I was deploying a new server today, I'd install FreeBSD 5.4. If I were
planning on installing a new server next month, I'd install FreeBSD
6.0-BETA-whatever-number-we're-up-to-by-then."
--

I have great respect for Dru and appreciate her work (ditto for
Colin), so don't take this wrong.  I'm sorry, but that's absolute
bullshit.  So Dru and Colin would recommend, this was in July, that if
deploying a server in August you skip the current "stable"
"production" 5.x and use a beta of a non-stable release on a
production server?!?  Yes, shows great confidence in 5.x there.

My point is, they know 5.x was a stepping stone to something better,
and are making 6.x into that "something better".  From my experience,
6.x is better already (though honestly, on my servers, I haven't had
many issues with 5.x since 5.3-release at all).

So don't think "5.x sucks so 6.0 can't possibly be any better".

6.0's network performance is already greatly improved from 5.x, though
it's still way behind 4.x.  The current funded TCP optimization work
should improve that further.  Supposedly in SMP environments, 6.x is
already faster in networking than 4.x (> 30% faster I've heard), but
still much slower in single processor environments.  Given that modern
hardware is moving to multi-core processors, that's definitely the
right direction for the project.  Doesn't help us much with today's
embedded devices though, nor those of the foreseeable future.

-Chris