On Oct 13, 2005, at 12:37 AM, Pavel A. Grodek wrote:
> Your time estimates (6 months to a year) also seem to be very similar
> to what I have in mind - 1-2 years to the final release. And that
> means that these boards are not "most popular m0n0wall platform" for
> next m0n0, the hardware _will_ change before release. Both soekris and
> WRAP are long overdue for new versions and I believe they will be
> updated soon.
While new models may come out (Soren has already discussed same),
they won't be "cheap" like the current boards are, and this alone
will ensure that an ample supply remains. (Neither board's CPU is in
any danger of being seen on an EOL list anytime soon.)
The only thing I see replacing part of the market currently held by
Soekris and PC Engines is nano-ITX (should it ever catch on),
and possibly a bit of 'mini-itx' especially where Intel decides to
enable $100 boards (with more CPU) or VIA continues to kick butt
with their C3 line of CPUs.
> In this area it depends on the user's mindset. As with most
> security-related applications, there are some influential and very
> paranoid users out there. And they don't like to have a piece of code
> in their firewall that they can't verify.
How many verify their BIOS?
> Sure, most home users with
> "I have nothing to lose on my machines" mentality don't give a shit,
> but I'd be much more comfortable deploying a firewall and knowing
> there are no bombs in the binary drivers that handle private traffic
> (and wireless is, by definition, "private").
I think you fail to understand the amount of structured testing that
the FreeBSD 'ath' and 'madwifi' drivers get.
(Both are deployed in the Atheros test lab.)
No part of OpenBSD undergoes as much testing as the HAL used in the
> It's not the question of "free", it's the question of "safe". Imagine
> a disgruntled programmer putting something nasty in Atheros binary
> drivers. Ask yourself - do you want some major attack caused by this
> to happen at _your_ site?
1) This would require someone *at* Atheros (or Sam Leffler) to do
The risks are actually quite low.
2) Its been shown (by Ken Thompson no less) that even in the presence
of 100% source code availability, that its
essentially trivial to install a "trojan horse" into the mix.
Thompson did it with YACC, which "understood" when it
was producing the grammar for the compiler, and the compiler
ended up "understanding" when it was building
the "login" program, and allowed a "back door".
So your argument here is moot in the extreme.
OpenBSD is also making some huge mistakes with the GCC toolchain.
My advice (worth what you paid for it), is to avoid
Theo and his crew like the proverbial plague.