From owner-freebsd-current  Mon Oct  7 11:57:18 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id LAA18143
          for current-outgoing; Mon, 7 Oct 1996 11:57:18 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA18134;
          Mon, 7 Oct 1996 11:57:12 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA14614; Mon, 7 Oct 1996 11:50:43 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199610071850.LAA14614@phaeton.artisoft.com>
Subject: Re: I plan to change random() for -current (was Re: rand() and random())
To: wollman@lcs.mit.edu (Garrett Wollman)
Date: Mon, 7 Oct 1996 11:50:42 -0700 (MST)
Cc: terry@lambert.org, ache@nagual.ru, joerg_wunsch@uriah.heep.sax.de,
        freebsd-hackers@FreeBSD.org, current@FreeBSD.org, bde@zeta.org.au
In-Reply-To: <9610071829.AA06015@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Oct 7, 96 02:29:49 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> >> Well, it sounds like "golden code" syndrome....
> 
> > It *is* "golden code syndrome".
> 
> > That doesn't make it any less of a valid argument.
> 
> I would say it's more like Terry bitching like he usually does about
> somebody making a piece of code act like it's supposed to on the
> grounds that someone, somewhere actually depends on the bugs in it.
> I for one am quite sick of your whining.
> 
> Around here we call that attitude ``UNIX Hacker bug #78''.

With respect, Garrett, I'm the one who usually bitches about code *not*
actinlg "like it's supposed to".

I'm probably most famous for complaining about the BSD 4.4-Lite VFS
code, as integrated by CSRG, not acting like John Heidemann's thesis
(the design document) dictates it should act.

However, I will argue against change when the historical behaviour is
"important".


I will note for the record that most of the refusal to adopt SVR4
conventions, like the init level abstraction, are a result of inertia:
general support for historical BSD'isms, without regard to technical
merit.


Here we have an issue where the technical merit is relative: it depends
on if you depends on the "random" behaviour" or if you depends on the
"pseudo" behaviour.  This is the main ideological debate.


Again, with respect, "act like it's supposed to" is relative in this
case.  Unlike the VFS code, where CSRG has provably damaged the
implementation -- demonstrable by even a cursory examination of the
design document it purports to implement -- and which you have actively
prevented me from correcting.

This is not simply "Terry bitching".


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.