Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Jan 2002 20:33:28 -0500
From:      Bob K <melange@yip.org>
To:        Patrick Greenwell <patrick@stealthgeeks.net>
Cc:        stable@FreeBSD.ORG
Subject:   Re: Firewall config non-intuitiveness
Message-ID:  <20020125203328.A454@yip.org>
In-Reply-To: <20020125165307.C54729-100000@rockstar.stealthgeeks.net>; from patrick@stealthgeeks.net on Fri, Jan 25, 2002 at 05:05:48PM -0800
References:  <000c01c1a5ff$a4539870$0101a8c0@cascade> <20020125165307.C54729-100000@rockstar.stealthgeeks.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 25, 2002 at 05:05:48PM -0800, Patrick Greenwell wrote:
> 
> You know, I continue to be amazed at the attitude that says that things
> should be kept counter-intuitive and anyone who doesn't like it that way
> is ignorant. What possible benefit is there in perpetuating mislabeled
> behavior?
> 
> To me, it's very simple: there's this "firewall_enable" option in rc.conf,
> and I think that reasonable people would infer that if you set it to "no"
> it meant that you didn't want a firewall enabled(based on the name of the
> variable), yet that is not what happens.
> 
> All the documentation reading in the world isn't going to make me think it's a
> good idea to have "no" mean "yes" and I certainly don't think it's useful or
> helpful to cast aspersions on individuals who want "no" to actually mean "no."

The problem is that you're not taking into account the installed base of
users who twiddle this knob.  How many angry firewall admins will come
into being when the behaviour suddenly stops being, "don't load any
firewall rules" and starts being, "disable the firewall"?

Perhaps the variable could be renamed to something more specific.

-- 
Bob <melange@yip.org> | Please don't feed the sock puppet.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020125203328.A454>