Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-31 Thread Raf Czlonka
On Sat, Jan 31, 2015 at 12:17:09AM GMT, Joel Rees wrote:

 I half-sympathize with his concerns. It _seems_ nice to have the
 bundle of patch cables all connected and ready, and one switch
 separate from the patch cable bundle to actually turn the box on and
 patch it in.
 
 Seems being the operational word, and the issue of where one is
 looking for the switch being, perhaps, the missed point?

For me, personally, the switch is '#', or lack thereof, in front of
'daemon_flags' :^)

One character instead of 'daemon_enable=YES/NO' seems pretty good to me.

The only use case I can think of where that wouldn't work is having the
daemon disabled at boot and still being able to start it by hand with
custom flags later on. If you do require that kind of functionality,
however, then '/etc/rc.conf{.local}' is not the right place to do that,
IMVHO (hint is in the 'rc') and there are plethora of other ways this
can be achieved.

Regards,

Raf



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-30 Thread Christopher Barry
On Thu, 29 Jan 2015 07:53:13 -0500
Nick Holland n...@holland-consulting.net wrote:

rsyncd_flags=
slowcgi_flags=
unbound_flags=

am I understanding correctly that in the snippet above, slowcgi will not
be started, while the other two (will|may) start with default flags?

--
Regards,
Christopher Barry

Random geeky fortune:
A chicken is an egg's way of producing more eggs.



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-30 Thread Joel Rees
On Fri, Jan 30, 2015 at 8:49 PM, Stuart Henderson s...@spacehopper.org wrote:
 On 2015-01-28, James Ryland Miller james.ryland.mil...@gmail.com wrote:
 As a brand new OpenBSD user, I *love* how the flags work in rc.conf.local:

   says to me that the daemon is being called with no flags.

 Unfortunately you run into an inconsistency here, which occurs exactly
 because of this double-duty:  actually means use the default flags from
 the daemon_flags line in /etc/rc.d/somefile.rc.


Which is half of what opendaddy is missing.

I half-sympathize with his concerns. It _seems_ nice to have the
bundle of patch cables all connected and ready, and one switch
separate from the patch cable bundle to actually turn the box on and
patch it in.

Seems being the operational word, and the issue of where one is
looking for the switch being, perhaps, the missed point?

-- 
Joel Rees



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-30 Thread James Ryland Miller
On Fri, Jan 30, 2015 at 5:49 AM, Stuart Henderson s...@spacehopper.org wrote:
 On 2015-01-28, James Ryland Miller james.ryland.mil...@gmail.com wrote:
 As a brand new OpenBSD user, I *love* how the flags work in rc.conf.local:

   says to me that the daemon is being called with no flags.

 Unfortunately you run into an inconsistency here, which occurs exactly
 because of this double-duty:  actually means use the default flags from
 the daemon_flags line in /etc/rc.d/somefile.rc.

Yes, I understand that now. It still makes more sense to me
the way it is currently implemented.


-- 
James R. Miller



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-30 Thread Stuart Henderson
On 2015/01/30 18:25, James Ryland Miller wrote:
 On Fri, Jan 30, 2015 at 5:49 AM, Stuart Henderson s...@spacehopper.org 
 wrote:
  On 2015-01-28, James Ryland Miller james.ryland.mil...@gmail.com wrote:
  As a brand new OpenBSD user, I *love* how the flags work in rc.conf.local:
 
says to me that the daemon is being called with no flags.
 
  Unfortunately you run into an inconsistency here, which occurs exactly
  because of this double-duty:  actually means use the default flags from
  the daemon_flags line in /etc/rc.d/somefile.rc.
 
 Yes, I understand that now. It still makes more sense to me
 the way it is currently implemented.

It does, until you really want no parameters whatsoever and need to use
foo_flags=  to work around it ;)



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-30 Thread Ingo Schwarze
Hi,

Joel Rees wrote on Sat, Jan 31, 2015 at 09:17:09AM +0900:
 On Fri, Jan 30, 2015 at 8:49 PM, Stuart Henderson s...@spacehopper.org 
 wrote:

 Unfortunately you run into an inconsistency here, which occurs exactly
 because of this double-duty:  actually means use the default flags
 from the daemon_flags line in /etc/rc.d/somefile.rc.

The description of how it works is correct, but the double-duty
does not cause this quirk.  For ports daemons, we have the same
logic ( - default flags,   - empty flags) even though there
is no double duty for ports, enabling/disabling being controlled
by the pkg_scripts variable.

Eliminating the double duty would not solve the problem of
distinguishing default flags and no flags.

Keeping the double duty does not prevent solving the admittedly not
very intuitive distinction of  and  .  For example, one could
redefine  as no flags and use something like DEFAULT for
default flags - but that would make rc.conf.local(8) very ugly
(DEFAULT on almost every line) and error-prone (easy to forget
putting DEFAULT there; defaults should be, well, the default,
without explicitly asking for them).  One could also define something
like NOFLAGS to mean no flags without conflicting with the
existing NO - but that looks like a gratuitious change with no
functional advantage over  .  So i think we should just leave it
as it is.

 Which is half of what opendaddy is missing.
 
 I half-sympathize with his concerns. It _seems_ nice to have the
 bundle of patch cables all connected and ready, and one switch
 separate from the patch cable bundle to actually turn the box on and
 patch it in.
 
 Seems being the operational word, and the issue of where one is
 looking for the switch being, perhaps, the missed point?

If you maintain rc.conf.local(8) by hand, you can just comment out
the flags line and add flags=NO to disable a base daemon.  That's
your master switch to throw without ripping out all your beautiful
patch cables.

If you use a configuration management tool to maintain configurations
across many machines, that's a job for the configuration management
tool, not for rc.conf.local(8).  For that reason, ajacoutot@ is
adamant that rcctl(8) will always delete the flags from rc.conf.local(8)
when disabling a daemon.

Yours,
  Ingo



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-30 Thread Ingo Schwarze
Hi Christopher,

Christopher Barry wrote on Fri, Jan 30, 2015 at 07:45:31PM -0500:
 On Thu, 29 Jan 2015 07:53:13 -0500
 Nick Holland n...@holland-consulting.net wrote:

rsyncd_flags=
slowcgi_flags=
unbound_flags=

 am I understanding correctly

No.

 that in the snippet above, slowcgi will not be started,
 while the other two (will|may) start with default flags?

They will all start with default flags (assuming that rsyncd,
which is a package daemon, is mentioned in pkg_scripts).

To disable a base daemon (like slowcgi), you need

  slowcgi_flags=NO

This is explained in rc.conf.local(8), by the way.

Yours,
  Ingo



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-30 Thread Stuart Henderson
On 2015-01-28, James Ryland Miller james.ryland.mil...@gmail.com wrote:
 As a brand new OpenBSD user, I *love* how the flags work in rc.conf.local:

   says to me that the daemon is being called with no flags.

Unfortunately you run into an inconsistency here, which occurs exactly
because of this double-duty:  actually means use the default flags from
the daemon_flags line in /etc/rc.d/somefile.rc.



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-29 Thread Nick Holland
On 01/28/15 17:25, openda...@hushmail.com wrote:
...
 Most of my daemons don't have any flags ...
...
Really?  Look closer...

IF the vast majority of daemons didn't have any flags at all, maybe
there'd be some merit to this, but I don't think that's true.

Here's a moderately simple rc.conf.local on one of my machines
ftpd_flags=-llSA
mountd_flags=
nfsd_flags=-tun 4
ntpd_flags=
pkg_scripts=rsyncd
portmap_flags=
rsyncd_flags=
slowcgi_flags=
unbound_flags=

portmap has one option flag which is not useful in startup scripts.
mountd has two, one of which might be useable in startup scripts, though
admittedly really making things unusual.  The rest all have important
and often useful flags.  YOU may not use them often, but some people
probably do.

OpenBSD uses a Sane Default model, so very often the flags ARE empty,
but a lot (I'd guess most, based on that model and spot checking of
daemons listed in rc.conf) of the daemons have knobs that some people
need to twist.  You may not, but while we appreciate your support, you
aren't our only user. :)

Nick.



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-29 Thread opendaddy
Greetings Nick!

On 29. januar 2015 at 12:48 PM, Nick Holland n...@holland-consulting.net 
wrote:

On 01/28/15 17:25, openda...@hushmail.com wrote:
...
 Most of my daemons don't have any flags ...
...
Really?  Look closer...

IF the vast majority of daemons didn't have any flags at all, maybe
there'd be some merit to this, but I don't think that's true.

Here's a moderately simple rc.conf.local on one of my machines
ftpd_flags=-llSA
mountd_flags=
nfsd_flags=-tun 4
ntpd_flags=
pkg_scripts=rsyncd
portmap_flags=
rsyncd_flags=
slowcgi_flags=
unbound_flags=

portmap has one option flag which is not useful in startup scripts.
mountd has two, one of which might be useable in startup scripts, 
though
admittedly really making things unusual.  The rest all have 
important
and often useful flags.  YOU may not use them often, but some 
people
probably do.

OpenBSD uses a Sane Default model, so very often the flags ARE 
empty,
but a lot (I'd guess most, based on that model and spot checking 
of
daemons listed in rc.conf) of the daemons have knobs that some 
people
need to twist.  You may not, but while we appreciate your support, 
you
aren't our only user. :)

Indeed, don't get me wrong, I use flags all the time as well. I'm just arguing 
for a cleaner separation between startup and configuration for a slightly more 
semantic (and better looking) `rc.conf.local`, ie.:

ftpd_enable=YES
ftpd_flags=-llSA
mountd_enable=YES
nfsd_enable=YES
nfsd_flags=-tun 4
ntpd_enable=YES
portmap_enable=YES
rsyncd_enable=YES
slowcgi_enable=YES
unbound_enable=YES

Thanks for your feedback!

O.D.



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-29 Thread Raf Czlonka
On Thu, Jan 29, 2015 at 11:16:41PM GMT, openda...@hushmail.com wrote:

 Indeed, don't get me wrong, I use flags all the time as well. I'm just
 arguing for a cleaner separation between startup and configuration for
 a slightly more semantic (and better looking) `rc.conf.local`, ie.:
 
 ftpd_enable=YES
 ftpd_flags=-llSA
 mountd_enable=YES
 nfsd_enable=YES
 nfsd_flags=-tun 4
 ntpd_enable=YES
 portmap_enable=YES
 rsyncd_enable=YES
 slowcgi_enable=YES
 unbound_enable=YES

Semantic? Maybe. Better looking? Most certainly not!

Configuration == Startup

Basically, if you are configuring a daemon, that is by using
${daemon_flags}, then you *intend* to *run* it. If you *don't* intend to
run it, *don't* configure it (or hash it out)!

Simple? Simple!

 Thanks for your feedback!

You're welcome :^)

Regards,

Raf



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-29 Thread Theo de Raadt
 On 29. januar 2015 at 12:48 PM, Nick Holland n...@holland-consulting.net 
 wrote:
 
 On 01/28/15 17:25, openda...@hushmail.com wrote:
 ...
  Most of my daemons don't have any flags ...
 ...
 Really?  Look closer...
 
 IF the vast majority of daemons didn't have any flags at all, maybe
 there'd be some merit to this, but I don't think that's true.
 
 Here's a moderately simple rc.conf.local on one of my machines
 ftpd_flags=-llSA
 mountd_flags=
 nfsd_flags=-tun 4
 ntpd_flags=
 pkg_scripts=rsyncd
 portmap_flags=
 rsyncd_flags=
 slowcgi_flags=
 unbound_flags=
 
 portmap has one option flag which is not useful in startup scripts.
 mountd has two, one of which might be useable in startup scripts, 
 though
 admittedly really making things unusual.  The rest all have 
 important
 and often useful flags.  YOU may not use them often, but some 
 people
 probably do.
 
 OpenBSD uses a Sane Default model, so very often the flags ARE 
 empty,
 but a lot (I'd guess most, based on that model and spot checking 
 of
 daemons listed in rc.conf) of the daemons have knobs that some 
 people
 need to twist.  You may not, but while we appreciate your support, 
 you
 aren't our only user. :)
 
 Indeed, don't get me wrong, I use flags all the time as well. I'm just 
 arguing for a cleaner separation between startup and configuration for a 
 slightly more semantic (and better looking) `rc.conf.local`, ie.:
 
 ftpd_enable=YES
 ftpd_flags=-llSA
 mountd_enable=YES
 nfsd_enable=YES
 nfsd_flags=-tun 4
 ntpd_enable=YES
 portmap_enable=YES
 rsyncd_enable=YES
 slowcgi_enable=YES
 unbound_enable=YES
 
 Thanks for your feedback!

You've had your say.  It is not changing to please you and hurt everyone
else.  Do you get it?  I doubt it.



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-29 Thread Calvin
There's also simplicity of implementation. Even a few more
lines means more bugs. Having the parameters as one and
checking for less cases means simpler software, and simple
is reliable.


From: owner-m...@openbsd.org [owner-m...@openbsd.org] on behalf of Raf Czlonka 
[rczlo...@gmail.com]
Sent: January 29, 2015 8:03 PM
To: misc@openbsd.org
Subject: Re: Wouldn't `daemon_enable=YES` make more sense than 
`daemon_flags=` in rc.conf.local?

On Thu, Jan 29, 2015 at 11:16:41PM GMT, openda...@hushmail.com wrote:

 Indeed, don't get me wrong, I use flags all the time as well. I'm just
 arguing for a cleaner separation between startup and configuration for
 a slightly more semantic (and better looking) `rc.conf.local`, ie.:

 ftpd_enable=YES
 ftpd_flags=-llSA
 mountd_enable=YES
 nfsd_enable=YES
 nfsd_flags=-tun 4
 ntpd_enable=YES
 portmap_enable=YES
 rsyncd_enable=YES
 slowcgi_enable=YES
 unbound_enable=YES

Semantic? Maybe. Better looking? Most certainly not!

Configuration == Startup

Basically, if you are configuring a daemon, that is by using
${daemon_flags}, then you *intend* to *run* it. If you *don't* intend to
run it, *don't* configure it (or hash it out)!

Simple? Simple!

 Thanks for your feedback!

You're welcome :^)

Regards,

Raf



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread Jorge Gabriel Lopez Paramount

Quoting Ingo Schwarze schwa...@usta.de:


Most of my daemons don't have any flags so it looks a bit strange
(and messy) with all these empty flag specs.


That's a matter of taste and purely aestetical without any functional
consequences, so if it's an argument at all, it carries almost no
weight.


There are worse ways of starting up daemons, like systemd.

--
Best regards,
Jorge Lopez.



This message was sent using IMP, the Internet Messaging Program.



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread opendaddy
Hi,

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 
rc.conf.local:

  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:

ntpd_enable=YES
ntpd_flags=-s

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.

Thanks.

O.D.

(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 
two,
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-
Usability/dp/0321965515




-- 
James R. Miller



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread J Sisson
On Wed, Jan 28, 2015 at 4:05 PM,  openda...@hushmail.com wrote:
 Indeed, `daemon_flags=YES` wouldn't make any sense at all. What I'd like to 
 see is:

 ntpd_enable=YES
 ntpd_flags=-s

 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.


This is one of those cat $file | grep $pattern arguments.  Sure, you
can split it out, but if it can be done with grep $pattern $file,
why bother?


 Thanks.

 O.D.

 (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
two,
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-
Usability/dp/0321965515




--
James R. Miller




-- 
BSD is what happens when Unix programmers port Unix to the x86.
Linux is what happens when x86 programmers write a Unix-like.
Windows is what happens when x86 programmers run all of their
programming textbooks through a blender, eat the ground up
remains of the text, and then code up what they can read in the
toilet 3 days later.



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread Theo de Raadt
 Indeed, `daemon_flags=YES` wouldn't make any sense at all. What I'd like to 
 see is:
 
 ntpd_enable=YES
 ntpd_flags=-s
 
 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.
 
 Thanks.
 
 O.D.
 
 (1) http://en.wikipedia.org/wiki/Unix_philosophy

I've think you've had your say.



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread opendaddy
On 29. januar 2015 at 12:02 AM, Theo de Raadt dera...@cvs.openbsd.org wrote:

I've think you've had your say.

Thank you sir!

O.D.



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread James Ryland Miller
Or you can just learn that ${daemon_flags} does both - enables/disables
the daemon in question and sets its flags (if any).

Exactly.

On Wed, Jan 28, 2015 at 6:16 PM, J Sisson sisso...@gmail.com wrote:
 On Wed, Jan 28, 2015 at 4:05 PM,  openda...@hushmail.com wrote:
 Indeed, `daemon_flags=YES` wouldn't make any sense at all. What I'd like 
 to see is:

 ntpd_enable=YES
 ntpd_flags=-s

 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.


 This is one of those cat $file | grep $pattern arguments.  Sure, you
 can split it out, but if it can be done with grep $pattern $file,
 why bother?


 Thanks.

 O.D.

 (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
two,
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-
Usability/dp/0321965515




--
James R. Miller




 --
 BSD is what happens when Unix programmers port Unix to the x86.
 Linux is what happens when x86 programmers write a Unix-like.
 Windows is what happens when x86 programmers run all of their
 programming textbooks through a blender, eat the ground up
 remains of the text, and then code up what they can read in the
 toilet 3 days later.



-- 
James R. Miller



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread opendaddy
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 two,
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-Usability/dp/0321965515



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread James Ryland Miller
Due to OpenBSD's excellent convention over configuration (1), most people 
don't need flags.

As a brand new OpenBSD user, I *love* how the flags work in rc.conf.local:

  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.

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 two,
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-Usability/dp/0321965515




-- 
James R. Miller



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread Raf Czlonka
On Thu, Jan 29, 2015 at 12:05:24AM GMT, openda...@hushmail.com wrote:

 Indeed, `daemon_flags=YES` wouldn't make any sense at all. What I'd
 like to see is:
 
 ntpd_enable=YES
 ntpd_flags=-s
 
 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.

Or you can just learn that ${daemon_flags} does both - enables/disables
the daemon in question and sets its flags (if any).

And you saved yourself from having to memorise and type yet another
variables every time for daemons which (sometimes) might require flags.

Raf



Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=` in rc.conf.local?

2015-01-28 Thread Ingo Schwarze
Hi,

openda...@hushmail.com wrote on Wed, Jan 28, 2015 at 10:25:50PM +:

 Wouldn't `daemon_enable=YES` (like FreeBSD's rc.conf) make more sense
 for enabling daemons than `daemon_flags=` in rc.conf.local?

No, `daemon_flags=` is better.
When you do need flags, it needs only one variable instead of two,
which means less complexity.
Besides, having both cases (with and without flags) use the same
syntax instead of two different syntaxes is simpler.

Note that there *is* an ugly issue in the vicinity.  Base daemons
are enabled with daemon_flags, package daemons are enabled with
pkg_scripts.  But that asymmetry cannot be resolved because the
startup order of package daemons must be specified, while the startup
order of base daemons is hardcoded in rc(8) and cannot be changed.
Your suggestion wouldn't help at all with that problem.

 Most of my daemons don't have any flags so it looks a bit strange
 (and messy) with all these empty flag specs.

That's a matter of taste and purely aestetical without any functional
consequences, so if it's an argument at all, it carries almost no
weight.

Yours,
  Ingo