Dropping support for old binaries

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  There is a proposal around  to drop support for old NetBSD
binaries in current ersions of NetBSD.  For example, nuking COMPAT_NOMID,
COMPAT_10, COMPAT_12, COMPAT_13 COMPAT_14, etc. from the the -current
source tree.  I'll let the original poster post his reasons for this
proposal on this list, but here's my response to that proposal:



	hello.  I don't know about others on this list, but one of the reasons
I use NetBSD is because of its excellent backward binary compatibility.
With this feature, it's possible for me to update systems to newer versions
of the OS, while maintaining installations of working systems  at the
application layer.  If I were running Linux, and to almost the same extent,
FreeBSD, if I wanted to upgrade the core OS to a newer version, either to
support newe hardware as older hardware wore out, or to get some additional
feature that I need, I would need to recompile all of the user level
applications that I'm using for the various production environments I
maintain and, very likely, I'd have to update those applications so that
they would run on the newer versions of those OS's.  This would entail a
lot more testing and vetting in order to update production systems.  With
NetBSD, I just update the OS with a high degree of confidence that my old
user binaries will continue functioning.  If they don't, I can usually
track down the issue to one or two "fixes" in the source changes that lead
to the breakage and resolve the issue.  A side effect of this feature is
that it's possible for me to maintain fewer versions of NetBSD in
production since I can update most production environments to the level of
NetBSD I'm prepared to run on a given day without worrying overly much that
it won't work somewhere.  I see Linux and FreeBSD users struggle with this
problem on a daily basis.  Their solution, for the most part, is to install
the latest version of which ever OS they're using on a given day, set up
their production environment at that level, and, let it run at that level
without change until it comes time to do a wholesale upgrade of the entire
environment.  In the mean time, as other environments come on-line in the
same company, they get which ever version of the OS is the newest thing as
those systems are brought up and, soon, they have an unmanagable hodgepodge
of OS versions and patch levels which becomes a nightmare to maintain.
If you want to see examples of this, just look at Amazon's AWS. They run an
ancient version of Linux and an old version of Xen on their systems mostly
because the upgrade process for Linux is so bad that it is taking them
years to figure out how to perform updates that won't break a myriad of
things in their production environments.  
	I work at a small company and we don't have the man power to recompile
and test every application in our  production environments every 1-3 years
or, for that matter, even every 4-7 years, especially those services that
customers rely on every day!  However, NetBSD's backward compatibility
features have enabled us to upgrade the OS, thereby allowing us to support
new hardware, enhanced security features, etc. without affecting service
levels.  If that goes away, I think we'll be removing one of the strongest
pillars that keeps NetBSD users around.  I'd like to suggest that the
reason you don't see a lot of bug reports about NetBSD backward
compatibility is because it has worked so well over the past 10-15 years,
and because when it has failed, it's usually been noticed and fixed
relatively quickly.  that may not be as true for cross OS compatibility,
but I think a lot of people are using NetBSD backward compatibility without
even thinking about it because they haven't had to.  I, for example,
remember working on a problem with the COMPAT_NOMID and COMPAT_09
options with NetBSD-5 a couple of years ago, and I was able to get a fix
committed that fixed them  in a couple of days once I figured out when the
change that broke them was made.  Suffice it to say, I'm strongly in
disagreement with dropping the old NetBSD compatibility options unless it
can be shown that maintaining them places undue burdens on future
development.  Even then, I think that undue burden should be argued on a
case by case basis.  

	Even as I write, I 'm thinking of another way  to demonstrate how much
the backward compatibility options are used.  If you search through the
mailing list archives for all the trace outputs which have been reported
over the years in various bug reports, I think you'll find a very high
percentage of them include references to system calls which are older than
the version of OS that's reported in the bugs themselves.  For example, a
user reports a problem with a binary on a NetBSD-6 system and in his ddb or
gdb output, you'll see references to NetBSD5 or NetBSD-3 system calls.
Like as not, the bug is not related to the backward compatibility of the
software that's failing, but something else.

	I'm done ranting, but I truly hope we don't decide that maintaining
backward compatibility is not a priority.  Such a decision would be a very
sad one for me indeed!

-thanks
-Brian