Subject: failure notice
To: None <netbsd-bugs@netbsd.org>
From: None <MAILER-DAEMON@mail.netbsd.org>
List: netbsd-bugs
Date: 08/03/2000 17:58:57
Hi. This is the qmail-send program at mail.netbsd.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<netbsd-bugs@netbsd.org>:
This message is looping: it already has my Delivered-To line. (#5.4.6)
--- Below this line is a copy of the message.
by mail.netbsd.org with SMTP; 3 Aug 2000 17:58:55 -0000
by mail.iac.spb.ru with SMTP; 3 Aug 2000 13:23:19 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@weird.com (Greg A. Woods)
To: netbsd-bugs@netbsd.org (NetBSD Bugs and PR posting List)
Subject: Re: bin/10625: /usr/bin/cmp is unable to compare rather large files
In-Reply-To: <5tvgxsmc9s.fsf@tremor.sibyte.com>
References: <20000720161002.EE7648D@proven.weird.com> <20000727014544.84492DE0@mabelode.imrryr.org> <20000727033322.066B88D@proven.weird.com> <mailpost.964668817.31843@baton.sibyte.com> <5tvgxsmc9s.fsf@tremor.sibyte.com>
Reply-To: netbsd-bugs@netbsd.org (NetBSD Bugs and PR posting List)
Organization: Planix, Inc.; Toronto, Ontario; Canada
Message-Id: <20000727045217.735D18F@proven.weird.com>
Date: Thu, 27 Jul 2000 00:52:17 -0400 (EDT)
Sender: netbsd-bugs-owner@netbsd.org
[ On , July 26, 2000 at 21:23:59 (-0700), Chris G. Demetriou wrote: ]
> Subject: Re: bin/10625: /usr/bin/cmp is unable to compare rather large files
>
> so the choice is:
>
> (a) spend time blocked (not utilizing the CPU), or
>
> (b) spend time blocked (not utilizing the CPU) and then chew a bunch
> of CPU and memory bandwidth copying data?
well OK.... but still the overhead in the latter option is quite
miniscule compared to the time the process spends getting the data off a
spinning disk in the first place :-)
I suppose on a tightly coupled multi-processor system that memory
bandwidth is more of an issue and it's not just something that slows
down the currently running process; but in a single-CPU system I don't
think the impact on overall system throughput will be that big...
> "go read the license." it may be freeware, but for the majority of
> purposes (in my opinion) the license is such that it may as well not
> be.
>
> If AT&T wants people to use their open-source-ish software, they're
> gonna have to do something more sane with the licensing. The good
> thing is, at least some people there -- including at least one lawyer
> -- understands that.
I did read it (again just before I posted too). It looks pretty simple
and straight forward to me (even simpler than the BSD copyright!):
>From sfio_1999/NOTICE/sfio.notice:
----------------------------------------------------------------------------
The authors of this software are Kiem-Phong Vo, David Korn and Glenn Fowler.
Copyright (c) 1991, 1996 by AT&T Labs - Research.
Permission to use, copy, modify, and distribute this software for any
purpose without fee is hereby granted, provided that this entire notice
is included in all copies of any software which is or includes a copy
or modification of this software and in all copies of the supporting
documentation for such software.
THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T LABS MAKE ANY
REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY
OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
----------------------------------------------------------------------------
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!
--
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>