First off, let me apologize if I was too offensive. I wasn't trolling--that was my imagination playing devil's advocate, and meant to be rhetorical. As I am beginning to understand the fork, these wild ideas have no justification (well, maybe one or two still do...). :)
Chris Buechler wrote: > m0n0wall's focus on embedded platforms leaves it with a file > system that isn't suitable for a packaging system, and while > it might change slightly for version 1.3, it will still not > be suitable for most packages because it will never be a > "normal" file system. This answers one of my biggest questions about the fork. I've been fixated on the package system (though my previous mention of it was brief), thinking it was a solution for both projects. I had envisioned moving everything that isn't a core feature into an optional module. Instead of "m0n0wall is too resource-intensive to run on microsystem X," you get "m0n0wall will run on microsystem X with features A, B, and C, but not D." I wasn't aware that m0n0wall's file system makes this whole idea infeasible. Perhaps I should troll the m0n0wall list... :) Still, I think moving EVERY non-core feature (e.g., captive portal, load balancing, CARP, even VPN) into an optional module is the way to go for pfSense. Then, only the features a user needs are installed. The other features aren't there, and so they can't be used to comprise the system. In addition, a robust package system would open the door for third-party development of items beyond the scope of a firewall, like antispam and antivirus filters, or even just simple packages end-users could write to customize their system, like automatically dialing a pager number if the WAN goes down. As the community grows, there could even be some sort of certification for modules that pass security tests so users know which modules are deemed "safe." But I digress. Let me get back to the original thread. I also got the impression from the pfSense FAQs (yes, I did do some research before posting) that there was a bit more code sharing than there actually is, so I thought the projects were not quite as separate as they are. I understand now that that is not the case, and hence my concerns about patchy code were unjustified. Furthermore, Colin said it's a "one-way street" (which I assume goes from pfSense to m0n0?), so there's no duplicated work since m0n0wall can incorporate, say, the certificate manager that pfSense has already developed. (But the workforce/testers are still divided into whatever their respective ratios are.) You have all done a good job in answering my concerns. Very enlightening. And thanks for your speedy replies. It shows the pfSense community is alive and active, which further sets my mind at ease. I'll hold off on responding to everyone's comments individually, except please let me do one intentional troll: <TROLL> Scott, you've got it all wrong. In my overactive imagination, "unreasonable jerks" would refer to Manuel while you would be one of the "short-sighted egoists." :) </TROLL> --Bennett
