Date: Tue, 29 Jan 2002 20:19:49 -0600 From: "Mike Meyer" <mwm-dated-1012789189.18a176@mired.org> To: stable@freebsd.org Subject: *_enable="YES" behavior is bogus Message-ID: <15447.22597.666281.179771@guru.mired.org>
next in thread | raw e-mail | index | archive | help
I was going to say non-intuitive, since everyone likes slinging that
one around, but remembered what someone who knows more than a few
things about interface design had to say about "intuitive" interfaces:
When users say that an interface is intuitive, they mean that it
operates just like some other software or method with which they
are familiar.[*]
So I'll switch to something less ambiguous, and call these things
bogus.
If you build a kernel without INET, the following switches don't
result in any daemons being started if you set them to YES:
syslog_enable
sendmail_enable
lpd_enable
There are problably others, but I figured that was enough.
These are all things that are clearly useful on a system without an
internet connection. None of them start if you disable INET in the
kernel. Neither the defaults/rc.conf file, the rc.conf man page, nor
the man pages for those daemons mentiont that INET is required in the
kernel to run them. Nor do the LINT or GENERIC files mention that
turning off INET will cause various daemons useful on a machine
without an internet connection to quit working.
Oh yeah - I can't get to the machine even if I don't enable the
firewall.
If you believe that rc.conf should do the same thing no matter how the
kernel is compiled, these things are clearly bugs. They make the
behavior of firewall_enable="NO" with a firewall already enabled in
the kernel seem relatively minor. If anyone is actually willing to
look at fixing these things, I'll PR them. And probably start a
witchhunt for other rc.conf variables that can be broken by careful
selection of options in the config file.
Personally, I think that not taking an action is not the same thing as
taking the opposite of that action, and that people who change the
options in the kernel should know what those options do, and if they
can't find out from the documentation, they should ask. So simply
expanding the documentation and comments will solve the problem. I'd
rather commit a PR that does that than argue about what "not enabling"
means.
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
* p 150. Raskin, Jef. The Humane Interface. Addison-Wesley, 2000.
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?15447.22597.666281.179771>