Date: Thu, 19 Aug 2004 09:34:33 +0100
From: Zefram <zefram@fysh.org>
To: lojban-list@lojban.org
Subject: [lojban] Re: samselpli ?
Message-ID: <20040819083433.GA3076@fysh.org>
References: <20040817235553.GZ3538@chain.digitalkingdom.org> <20040818084944.GB24841@fysh.org> <20040818191959.GG13226@chain.digitalkingdom.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040818191959.GG13226@chain.digitalkingdom.org>
User-Agent: Mutt/1.3.28i
Sender: lojban-list-bounce@lojban.org
Errors-to: lojban-list-bounce@lojban.org
Precedence: bulk
Reply-to: lojban-list@lojban.org
Content-Length: 1484
Lines: 28

Robin Lee Powell wrote:
>Unfortunately, I think you're right.  I sometimes forget the paucity of
>computer knowledge of the average user; if I found other things to put
>in a generalized lujvo for "program" (say, required operating system or
>processor, just to pool a couple of possible places out of my ganxo),
>the average user would literally have no idea how to fill them.

I don't see anything so unfortunate about it.  I don't think places
for OS and processor are appropriate for the lujvo we're talking about.
OS and processor are relevant from the programmer's point of view, but
they're not fundamental aspects of a program.  Many programs are portable.
We need a word to express the relationship between a program and the
OS/processor that it relies on, but I think "pilno" may be that word.
I suggest that a grammatical distinction between OS and processor is
not required here.

>And sysadmins, like me, prefer samru'e.

That would be a "process" in the Unix sense?  That is, a distinct thread
of running code, viewed from within the OS.  To my mind this is not
particularly close to the concept of "program"; a process could be said
to always be running a program, but it will run different programs from
time to time (programs invoke each other).  (I'm using "program" in its
most general sense, to include what we'd normally call a "function".
The distinctions between system call, function, library, and program
are gradually blurring in real life anyway.)

-zefram