[ On , July 26, 2000 at 22:40:45 (-0700), Chris G. Demetriou wrote: ]
> Subject: Re: bin/10625: /usr/bin/cmp is unable to compare rather large files
>
> the time spent on the overhead is little compared to the time spent on
> the I/O, sure.  but the time spent on the overhead is time that can't
> be used by other processes in the system.
> 
> there's no reason to waste the cycles.

True enough but on a well tuned multi-user machine I generally find
everyone gets their fair share and if someone wants to burn his share on
a bunch of simple cmps then so be it!  ;-)

> memory bandwidth is a big concern in modern systems, even
> single-processors.  and extra copies and wasting 2x the cache space
> make the problem 2x as bad.

Yes, except that in this case the time spent in moving the bits about is
accounted to the process in question and while it may not be nice to
waste cycles on a multi-user system, there's not much you can really do
to prevent people from doing even more stupid things!  ;-)

If I understand correctly the only contention for memory bandwidth on a
single-CPU system will be with devices that do DMA.  Of course if you're
busy copying blocks of data from kernel space to user space, and then
moving it about yet again in the process's space while someone else's
disk request gets filled then you will no doubt run into this problem.

> That's interesting; that wasn't the license that i thought was on that
> code...  thanks for pointing me at that.  very much.  (see the license
> on e.g. CDT and vmalloc and other things on that site.)

An early version of sfio has almost always (1993) been freely available
in AT&T's netlib system here:

	ftp://ftp.research.bell-labs.com/netlib/attgifts/

There is some rigamarole to go through to download Sfio_199[89] and now
Sfio_2000 too, but that's the license within it (and on the web form you
have to fill out if you get it directly from them).

	http://www.research.att.com/sw/tools/sfio/

I feel assured enough about the terms that I've put it on my mirror site
just to simplify things:

	ftp://ftp.weird.com/pub/mirror/att-sfio/*

Of their other cool generic C libraries, it is only cdt and vmalloc that
are still under the more restrictive licenses.

Note also that as of March 1, 2000 the source is available for ksh93i
too (as part of the ast-open kit).  Now whether you think that's a good
thing or not is another issue, but what it does mean is that at least
vmalloc is also attainable under this separate license (since it's a
part of the libraries in the ast-open kit)!  The license is a good deal
more complicated but it appears to be essentially "open source":

	http://www.research.att.com/sw/download/

> > So it's maybe not 100% in keeping with TNF's goals (you're not free to
> > make it un-free), but it's a lot less onerous than the GPL!
> 
> uh, i don't see how you figure you're not free to make it un-free.

perhaps "non-free" would have been a better term...

> "Permission ... for any purpose without fee [paid to AT&T] is hereby
> granted," not "Permission ... to distribute without fee for any
> purpose..."
> 
> All interpretations i've seen of that wording say it means you don't
> have to pay a fee to them to do all that stuff.

No, what I mean is that you or I are not able to take it for free
(i.e. under that license) and then charge a fee for it.  We can't make
it un-free.  We must give it away for free if we make it available.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>