[ previous ] [ next ] [ threads ]
 
 From:  Kris Maglione <bsdaemon at comcast dot net>
 To:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] The future
 Date:  Wed, 12 Oct 2005 18:04:53 -0400
A list of pros/cons follows, but here are my picks:
  If I were the only developer:  Core: Perl;           webGUI: Perl/TT2;
fw: pf; Shaping: ALTQ; OS: DragonFly; SCM: SVN
  In reality:                    Core: Python or Ruby; webGUI: PHP;     
fw: pf; Shaping: ALTQ; OS: DragonFly; SCM: SVN

As for the language, I have to state first and formost, that I have a
strong prejudice against Java. I hate coding in it and don't like the
kind of code that it promotes. I also think that, even with GCJ, it's
too giant for m0n0wall. GCJ compiled apps still use loads of memory, as
far as I know. Also, GNU Classpath isn't tiny either.

If we're going OO, I'd say either Python or Ruby. I think that Python
probably has the advantage in terms of a developer base. I'm not very
familiar with either of the two languages, but know a little more of
Python than Ruby. Anyway, I can say that I would /much/ prefer Python
over Java, even if size and performance weren't issues. Someone else can
argue for Ruby over Python.

I like a lot of things about Perl, but it's very easy to write Perl
wrong (which, needless to say, ends in disaster). A strong benefit,
though, is that the Template Toolkit is absolutely awesome, and would
remove the need for using PHP alongside it, and, therefore, save space.

I can definately make an argument for using purely PHP 5, but I have no
experience with it's OO features, so I can't argue that aspect. All that
I have to say about it is that it's easy to pick up, and a lot of people
are attracted to contribute to m0n0wall based on it's exclusive use of
PHP (at least that's the impression that I get).


For the OS, I'm totally opposed to Linux. For one, m0n0wall is the only
viable BSD based firewall, in my opinion. For another, I'm mildly
prejudiced against linux, and tend to percieve it as less stable and
more bloated than the BSDs. I lean towards DragonFLY because it's a
continuation of the FreeBSD 4.x line. It's meant to be lean (and mean?)
and fast, and is based on some great ideas and principals. As for
FreeBSD 6.x, I think it's a bad option until a stable branch is
released, which will be too long, in my opinion. OpenBSD tends to do
poorly in networking benchmarks, though it may be better as a router
than a server. NetBSD does fairly well in networking benchmarks, and it
runs just about anywhere, which could be a plus. In all, though, I think
that Dragonfly is moving in the right direction and is the one to go with.


For the firewall, I'd absolutely go with pf, only for the fact that
pfsync is such a perfect compliment to Carp. That is my entire argument
for it, and, as far as I'm concerned, it's enough.

I also have to nominate ALTq over dummynet. ALTq was designed for QoS
scheduling, while dummynet was designed to simulate less than ideal
network conditions. It works fairly for traffic queueing/flow control,
but ALTq is of a superior design for the purpose


For the SCM, I would lean towards SVN. It's starting to replace CVS as
it is, and there's no sense in having to migrate later. It also has a
good number of features that make it easier to use and faster/more
efficient/more reliable than CVS. There are also decentralized versions
of SVN available that might merit consideration. At the very least they
would save bandwidth over SVN, and SVN would, at the very least, save
bandwidth over CVS.

I guess that's it.