On 28. januar 2015 at 11:45 PM, "James Ryland Miller" 
<james.ryland.mil...@gmail.com> wrote:
>As a brand new OpenBSD user, I *love* how the flags work in 
> "" says to me that the daemon is being called with no flags.
>"YES" doesn't tell me that; it just tells me that I might have to 
>look in another config file somewhere.

Indeed, `daemon_flags="YES"` wouldn't make any sense at all. What I'd like to 
see is:


Considering we're talking about two different things here (one for enabling it 
and one for configuring it), one could argue that this would be more in line 
with the core Unix philosophy (1) of "doing one thing and doing it well".



(1) http://en.wikipedia.org/wiki/Unix_philosophy

>On Wed, Jan 28, 2015 at 5:33 PM,  <openda...@hushmail.com> wrote:
>> Hello,
>> On 28. januar 2015 at 11:02 PM, "Ingo Schwarze" 
><schwa...@usta.de> wrote:
>>>When you do need flags, it needs only one variable instead of 
>>>which means less complexity.
>> Due to OpenBSD's excellent "convention over configuration" (1), 
>most people don't need flags.
>> Your argument that the current scheme leads to less complexity 
>is nonsensical at best. Less characters maybe, but are we really 
>joining together two different variables (startup and 
>configuration) for the sake of saving space?
>> Like Einstein said, "things should be as simple as possible, but 
>not any simpler". `daemon_flags` carries absolutely no indication 
>of whether this daemon is to be enabled or not. Like my teacher 
>used to say, good design should, where possible, make immediate 
>sense to the user (2). In the case of `rc.conf.local`, this is 
>possible by splitting the current variable into 
>`daemon_enable=YES` and `daemon_flags=""` respectively.
>> As for `pkg_scripts`, I'm also a fan of the way FreeBSD handles 
>this by letting you specify `<pkg>_enable="YES"` directly in order 
>to keep things consistent.
>> Having said that, this is pretty much where my admiration of 
>FreeBSD ends :-)
>> Many thanks!
>> O.D.
>> (1) https://en.wikipedia.org/wiki/Convention_over_configuration
>> (2) http://www.amazon.com/Dont-Make-Think-Revisited-
>James R. Miller

Reply via email to