Appropriate tags for service names and syslog facilties?

[Tammy Fox]

On Tue, 2004-02-17 at 23:47, Mike MacCana wrote:
> On Tue, 17 Feb 2004, Tammy Fox wrote:
> 
> > When I was in RH Docs, we had the command versus application debate many
> > times over. ;-) Basically, my reasoning for ultimately deciding to use
> > command tags for services, daemons, and the like was because I think of
> > an application as something that has an interface other than the command
> > line -- GUI or at least a TUI.
> 
> service have an interface other than the command line.
> 

Right, but those interface are applications or menu items and should be
tagged accordingly.

> In each of the tutorials I'm writing, if there's an appropriate Red Hat
> GUI config tool for the service, I provide instructions on installing,
> configuring, enabling and starting the service graphically (as well as the
> standard command line method provided for all services).
> 
> Hence you end up with something like:
> 
> <para>
> Start the <command>httpd</command> service and set it to start by default.
> <guimenu>Main Menu</guimenu> =>
>  <guimenuitem>System Settings</guimenuitem> =>
> <guimenuitem>Services</guimenuitem>, select the <command>httpd</command> service
> and click Start to start the service (use Restart if it is already running).
> </para>
> 

In this instance, the menu item is HTTP and should be tagged as a
guimenuitem. You are referring to the name of the menu item, not the
actual service.

> > IMO it is more fitting to use the
> > same style for commands, services, daemons, etc.
> 
> To be honest I don't know why Red Hat even bothers using the word
> 'daemon'. It has too many meanings in Unix (some people use it descrive a
> Sys V service, others the binaries run by that service, others an
> application that has been backgrounded by any method).
> 
> I find it best to avoid using the term 'daemon' completely. The only place
> where it still matters is TCP Wrappers, which is fast becoming irrelevant,
> due its limited application support and filtering capabilities.
> 
> Mike