[ previous ] [ next ] [ threads ]
 From:  "Mitch \(WebCob\)" <mitch at webcob dot com>
 To:  "Bosse Timothy" <Bosse dot tf at mellon dot com>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  RE: [m0n0wall] Hotspot Access Pages & modularity & so on.
 Date:  Thu, 18 Mar 2004 09:46:06 -0800
Hey - don't know if you intended to send this ONLY to me or not - but
anyways here goes.

> -----Original Message-----
> From: Bosse Timothy [mailto:Bosse dot tf at mellon dot com]
> Sent: Wednesday, March 17, 2004 3:15 PM
> To: Mitch (WebCob)
> Subject: RE: [m0n0wall] Hotspot Access Pages
> This is a difficult request for multiple reasons.
> 1) Security/Simplicity - I believe a router/firewall should do JUST
> that.  As more applications are added, there is a greater risk of
> security compromise.  KISS is always a good mantra to repeat.
> ESPECIALLY when you think a feature should be added.

Of course - which is why I was proposing modularity. There are loads of
people who don't need IPSec, and there are others who don't need WAP
support, and so on. Then there are those that need some sort of accounting
features - before you say that doesn't belong in a firewall I will tell you
I agree perhaps the SYSTEM doesn't, but certainly the packet counters or
SNMP loggin has to be there - it's the only place it can be.

> 2) Logistics - How do you propose to add new applications to a read-only
> FS?  What standard/method of plug-in/module/package management do you
> propose to use?  Will the proposed method greatly increase the size of
> the image?  Will the packages greatly increase the size of the package?
> What happens if you are out of space on the media or FS that you are
> attempting to add to?  I can think of several answers to each.  None of
> the answers I can come up with are all that pretty or easy to implement.

Packages could be added and obviously tested on a read write file system,
and then bundled into a customer read only package. Many people are already
using kernel hacking and so on to do this. I was proposing using the
existing FreeBSD package management system - I had asked if it was still in
the base monowall distribution, but didn't hear a response. There are lots
of ways to make this happen - that's not the point right now though - first,
should it happen at all. I'd say if it improves the breadth of the project
without destabilizing core functions that are essential to all users, then
it can only be good... time will tell.

> 3) Time/Resources - Unless somebody else wants to take a stab at writing
> something, Manuel is the one who is creating m0n0wall.  Each feature
> must be carefully thought out and implemented.  Support initially
> remains with Manuel until people are able to pick up on the changes that
> were made.  All of this requires a huge chunk of time and thought.

Of course, but I for one haven't ehard a reply from Manuel on the concept of
a module or package system to support extra features - could be done, but as
I said in a few of my emails, I think one of the key WEAKNESSES to free
software is the willingness of the community to splinter over minor
differences. With a package management system, and basic support in the web
interface for including extra config pages if they are present and follow a
certain format would allow the splinter groups to stay within the core
project without having to branch, and set up their own maintenance and site
and lists and so on - which benefits the core mono community as the larger
the community the broader the testing, and support and so on...

I'd certainly be intersted in helping, but to do the work in a vacuum is to
invite failure.

> 4) Other Methods - Manuel has provided an excellent document on how to
> make changes to the images.  Take a look at the m0n0wall Hacker's Guide.
> If people are really dead set on getting a function added, and they feel
> it's falling on dead ears, try developing it yourself.  You might, in
> the process of development, find out why it fell on dead ears in the
> first place.

Yup - and that works for features where you are the only one doing it. Why
should the dozens of individuals work in isolation on each minor variation
and have to resort to patching and remerging with each new mono release when
a little work on a package system could allow more community effort &
support on the core product?

> Honestly, I think requests just need to be made.  One of my biggest pet
> peeves is the fact that multiple people request a feature that has
> already been requested multiple times.  Read the archives, if it's
> there, read the archives to determine if it's been accepted/rejected.
> If it isn't make your request.

While I appreciate your angst at those not reading the archives, I can't
really expact that much - some of them are new and some of them - like
myself - are probably overworked. I spent a few hours a day keeping up with
lists and projects I'm interested in or support in some way - if I had to
read archives - (how much is reasonable - where's the standard - is it the
last 1000 messages or the last 6 months? ;-) If multiple people didn't make
a request, the community at large wouldn't realize the breadth of interest
in a particular feature.

> Manuel will make a decision to attempt the feature or not.  Either way,
> the debate over adding it or not is over at that point.  If you like the
> feature you will use it.  If you don't like it, you won't use it.  If
> you really don't want the feature in your image, refer to reason #4.

Don't recall seeing any response to the package system concept - I kicked a
few ideas out there but haven't seen a response yet.

> I don't develop that often or that well, so I keep my requests to a
> minimum and I stay thankful that somebody took enough time to create a
> product to the point it is today.

I do develop often, and well enough to keep employed, but am often busy
enough to prevent me from doing a lot of time on too many of the projects I
have interest in - if I am going to roll code, I like to make sure it is
general in use and accepted by the powers that be. I don't want to splinter
and spend valuable time creating a patch that will soon be forgotten unless
it is essential to my business or clients - I'd rather generalize it, adapt
it to the betterment of the project and contribute the effort to an active
project or branch to ensure it gets the longest life.



> -----Original Message-----
> From: Mitch (WebCob) [mailto:mitch at webcob dot com]
> Sent: Wednesday, March 17, 2004 4:39 PM
> To: Timothy Jans; m0n0wall at lists dot m0n0 dot ch
> Subject: RE: [m0n0wall] Hotspot Access Pages
> This is what I suggested and outlined before - Manuel - any opinions on
> an extention interface like I described?
> That would allow people needing features to extend the platform without
> having to branch the project, and would avoid the bloat for people who
> don't need the extras.
> m/
> > -----Original Message-----
> > From: Timothy Jans [mailto:timothy dot jans at pandora dot be]
> > Sent: Wednesday, March 17, 2004 1:10 PM
> > To: m0n0wall at lists dot m0n0 dot ch
> > Subject: Re: [m0n0wall] Hotspot Access Pages
> >
> >
> > Can't we make some kind of plugin system in m0n0wall (like they have
> > with
> > freesco)
> > so you can easely install (and remove) a 3rd party plugin.
> > That way everyone is happy ;)
> >
> > ----- Original Message -----
> > From: "Richard Morrell" <dick at dickmorrell dot com>
> > To: "John Voigt" <1geek at jvoigt dot com>
> > Cc: "David Rodgers" <david dot rodgers at kdsi dot net>; <m0n0wall at lists dot m0n0 dot ch>
> > Sent: Wednesday, March 17, 2004 9:32 PM
> > Subject: Re: [m0n0wall] Hotspot Access Pages
> >
> >
> > Quoting John Voigt <1geek at jvoigt dot com>:
> >
> > > ----- Original Message -----
> > > From: "David Rodgers" <david dot rodgers at kdsi dot net>
> > >
> > >
> > > >
> > > Well, for you it's a firewall.  A lot of people are using it with
> > > the Soekris box as a wireless router in their SOHO environment
> > >
> >
> > David is a disciple of the school of hard knocks and lack of
> > personality people. He has best interests at heart but he does need to
> > sharpen up his people skills to add to his obvious depth in network
> > technologies.
> >
> > Either that or lets set up a Paypal fund for an overdue personality
> > injection.
> >
> > Dick
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> The information contained in this e-mail may be confidential and
> is intended solely for the use of the named addressee.
> Access, copying or re-use of the e-mail or any information
> contained therein by any other person is not authorized.
> If you are not the intended recipient please notify us
> immediately by returning the e-mail to the originator.(B)