[Debtags-devel] Updating tags on svn

[Thaddeus H. Black]

Enrico wrote:

> Do we have an agreed and shared definition of 'utility'?

No.  Well, yes.  We usually know a utility when we meet it, but defining
the concept in a few words is not easy.

> At the moment, I pulled this from the role::sw:utility description:
> 
>  A program designed for general support of the processes of a
>  computer.  .  Applications which are useful to attain a goal, but
>  which are not the specific application to use to solve that goal.
> 
> Is this ok?

Firstly, Enrico, I understand that a man's concentration and attention
only go so far.  This post slightly shifts the foundation under
role::sw.  If mental sanity requires you to ignore this post for now,
ignore it.  I'll get back to it later in the year.  In the meantime,
your most recent vocabulary proposal will do no harm.

In answer to your question, the thread's discussion does begin to
clarify the utility/application concept.  Clausewitz once observed that
one can cross a ditch cleanly only in a single leap, never in several
small jumps.  Occasionally so it is with us.  Some tags cannot be split
cleanly in two parts, but can be split cleanly at once in four or five.
I think that I see the way out of the dilemma now.  Try this:

  role::sw:utility
  role::sw:daemon
  role::sw:application
  role::sw:game

That does it.  Daemons and games are neither utilities nor applications,
but parallel classes of the same kind on the same level.  (One can lump
the games and the daemons with the applications if one wants to, but it
doesn't help.  After all, one can lump the utilities with the
applications, too, if one wants to.  One can lump everything with
everything... which puts us right back where we started before debtags.
In this case, we should not lump.)

With the fourfold division, the key is to define role::sw:utility
correctly.  Then the other three tags fall neatly into place.  If so,
here is a draft definition for role::sw:utility:

 A lean, tightly focused tool (or a collection of such tools), normally
 run noninteractively, which
 .
   * reports the state of the system in some respect (as find(1));
   * automates a well defined task (as cp(1));
   * filters a stream of text or data (as sed(1));
   * displays data in a simple, noninteractive way (as xloadimage(1));
     or
   * fetches or reports data by a specific protocol (as rsync(1)),
     implements a basic client to such a protocol (as ssh(1)), or
     talks to a daemon.
 .
 Also, a basic tool which provides a generic front end with an
 unembellished interface (as bash(1), xterm(1), or login(1)).
 .
 Other programs with interactive interfaces, drop-down menus,
 clickable widgets, full-screen ncurses interfaces, etc, are usually
 applications rather than utilities.  Applications also include
 large-scale interpreters like perl, compilers like gcc, full-screen
 front ends like mc, data presentation tools like gnuplot, pagers like
 less, full-screen editors like vim, any attempt at artificial
 intelligence, and any tool which transforms data in an intricate,
 adaptive or highly nonobvious way.  Use role::sw:application for such
 programs.
 .
 Daemons and games are neither utilities nor applications,
 incidentally.  Use role::sw:daemon and role::sw:game.  However,
 observe that role::sw:daemon does not include utilities which can be run
 in daemon mode but normally aren't; and that role::sw:game does not
 include utilities which manipulate the state of a game but are not
 games in themselves.  The role::sw:utility tag is proper for these.

You know an application when you meet it.  The concept is felt not seen.
There probably is no brief, complete way to put the concept into words.
What we need is not to abandon the concept but rather to put enough of
it into words that the package maintainer knows what we are talking
about.  There will be borderline cases, but this is so with almost any
tag.  As for the user, our definitions will not trouble him; once he has
seen a few role::sw:utilities and a few role::sw:applications, he will
find the distinction intuitive.

The role::sw:application tag covers a lot of different kinds of
packages, of course---compilers, editors, etc---but this is precisely
what makes the tag useful.  When diverse packages share a significant
quality other packages lack, these packages demand a tag to express the
distinction.  This is true even if the quality is subjective.
Role::sw:application is such a tag.

If I have committed another debramism here, please correct.
Nevertheless it seems to me that the concept is sound.  The test of the
definition is whether it accords more or less with your subjective sense
of the thing.  If it does, then please post terse refinements to the
draft.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20050816/63f16dea/attachment.pgp