On Fri, Oct 05, 2001 at 08:27:31AM -0700, James Graham wrote:
> I think this is all making a mountain out of a molehill.  To me, the best
> suggestion I have seen is the one which reflected keeping old utmp around
> for deprecated backward compatibility, TO BE REMOVED IN A NEAR FUTURE
> RELEASE, but building an API ({get,set,put,end}utent((utmp_cookie_t *)))
> to be used immediately; this would give any third-party utmp-manglers
> AT LEAST six months, if not more, to get their act together.

Six months? Try four or five years. Some products don't get released
more than once every couple of years. Plus, depending on how schedules
fall, the change might not get into the next release of the product
(whatever product it is). 
 
> Any other process for doing this is going to be bloat.  We've already got
> an amazing amount of bloat there as it is, what with retaining all the
> backward compatibility to pre-1.0.  We must be the only OS on the face
> of the planet to have an eleven-year backward-compatibility timespan!

In 1993 I saw an Amiga running 3.mumblemumble (it was an OS release newer
than what was publicly released) successfully execute a program written
for AmigaOS 0.8 or 0.9 or so. That would be about 8 years of backwards
compatibility (for binaries). It might be worth a shot trying a current
version of AmigaOS to see if it is still compatible back to 1984 or 1985.

Also, since the Amiga didn't have VM then all of the compatibility stuff
was always in memory. NetBSD doesn't have that problem.
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

Seen on bottom of IBM part number 1887724:
DO NOT EXPOSE MOUSE PAD TO DIRECT SUNLIGHT FOR EXTENDED PERIODS OF TIME.