[ On Friday, October 19, 2001 at 21:46:15 (-0400), Todd Vierling wrote: ]
> Subject: Re: stdio FILE extension 
>
> "Appropriate support mechanisms" is far more than a SMOP.

Sure -- but a lot of that work would benefit far more than this one purpose.

>  What you're
> implying, possibly without even knowing it, is a boatload of extra baggage
> in ld that walks the line of ELF compliance.

Perhaps -- but binary emulation is only one of the potential solutions.

(and I guess we'd better talk about the relative merits of strict ELF
compliance vs. ABI compliance some other time....  :-)

No matter what I'm talking about it's one heck of a lot less extra
baggage than what's already there to support the relatively small
segment of users relying on non-native binaries for important production
uses.  (An no, Netscape Communicator does not count in my opinion,
especially not since Mozilla has become more stable and usable than the
equivalent Netscape 4.x releases.)  My point here is that I'm not
complaining about the extra baggage I'm not using for non-native
emulation so why should I or anyone else complain about that added for
_native_ backward compatability?

NetBSD is not a primarily binary-only OS release.

NetBSD is not host to any really significant number of binary-only
applications.

So far as I know NetBSD isn't even used as the basis for any significant
commercial binary-only operating system on which third-party binary-only
applications are used.

Indeed it would even seem, on the surface at least, that the goal of
maintaining backwared binary compatability in perpetuity is contrary to
other presumably more important goals for NetBSD.

Meanwhile the extra baggage of maintaining shared libc ABI compatability
is if not directly impacting performance and resources, it is apparently
beginning to distract somewhat on the maintenance side of things.

> After the breakage, we analyzed the issue in depth and realized just how
> widespread the problem is.

So, did anyone write up this analysis so it could be documented for
future generations?  What was posted to these lists just doesn't quite
cut it as convincing, well founded, technical reasoning; and it sure a
heck isn't an appropriate place to document something as important as
you seem to be trying to claim it is.  The few comments scattered in the
CVS repository are no more convincing or appropriately located.  What's
been re-iterated in this thread has certainly been no more convincing.

> NetBSD does have an installed base to take care of, whether or not you
> personally see it between the horse-blinders.  You may be perfectly happy
> recompiling the system on a particular dividing point, but the multitude of
> NetBSD users are not.

Excuse me!  I happen to be one of those NetBSD users and I happen
represent at least two different segments of the installed base of
NetBSD users (third-party users of the source as well as users of the
release products).  I suspect you literally cannot have any more
statistically significant numbers to represent the users you're talking
about.  You still don't even have any better definition of that dividing
point than I do so how can you have surveyed them about it?

In other words I too am extremely and directly interested in taking care
of the installed base of NetBSD users.  I just happen to have a very
realistic perspective on what one can expect during the transition
across any major OS release upgrade, and that's because I've actually
managed many such upgrades on many different platforms and operating
systems and in many different types of production environments.


BTW, I know quite a few *BSD people (in all three camps, though most I
know are actually FreeBSD users) who don't even trust the release
binaries and will do a "make {world,build}" even though it can't really
be of any benefit other than to prove that they've got the source from
which their running OS was built and thus they can subsequently expect
to be able to patch it with much greater likelihood of success if/when
that might be necessary.  I even know a few Linux users who do the same.
For certain this class of user is far more rare in the Linux world,
though not always for the reasons you might expect -- many I know
personally do want to re-build the world but find it too complex a
process and many have expressed great desire for the clean one-step
builds of FreeBSD, which is the same reason why more FreeBSD users will
do "make world" than NetBSD users will do "make build".


In the end this isn't something I'm demanding must be done -- I'm just
trying to point out how contradictory it is to dismiss the mere
possibillity of doing it for the reasons cited so far.  I can understand
the "once burned twice shy" syndrome, but this is getting ridiculous.

-- 
							Greg A. Woods

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