From xemacs-m  Fri Jul  4 09:56:50 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id JAA22811
	for <xemacs-beta@xemacs.org>; Fri, 4 Jul 1997 09:56:50 -0500 (CDT)
Received: from Canada.Sun.COM ([129.155.5.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA04346 for <xemacs-beta@xemacs.org>; Fri, 4 Jul 1997 08:21:47 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (SMI-8.6/SMI-5.3)
	id KAA13850; Fri, 4 Jul 1997 10:56:18 -0400
Received: from verve.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id KAA18505; Fri, 4 Jul 1997 10:56:16 -0400
Received: by verve.canada.sun.com (SMI-8.6/SMI-SVR4)
	id KAA05689; Fri, 4 Jul 1997 10:56:16 -0400
Date: Fri, 4 Jul 1997 10:56:16 -0400
Message-Id: <199707041456.KAA05689@verve.canada.sun.com>
From: Georg Nikodym <georgn@Canada.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: Solaris dynamics? 
In-Reply-To: <9707031753.AA04163@cfdevx1.lehman.com>
References: <199707031510.LAA08224@verve.canada.sun.com>
	<9707031753.AA04163@cfdevx1.lehman.com>
X-Mailer: VM 6.32 under 20.3 "Athens" XEmacs  Lucid (beta10)
Reply-To: georgn@Canada.Sun.COM
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo

>>>>> "RC" == Rick Campbell <rickc@lehman.com> writes:

 RC> And if the exception were eliminated, I wouldn't have a problem.
 RC> There is no good reason for tying developers hands in this
 RC> manner.

An example.  /usr/lib/libsocket.so.1 performs its duty by talking
with a STREAMS module called sockmod.  In Solaris 2.3 (development on
2.3 stopped around October 1993), we shipped by mistake a libsocket.a.
One really large customer linked against it. Problem was that this
customer sold software to a bazillion other large customers.  Couple
that with everybody bitching about Solaris performance.  In Solaris
2.4 and 2.5, improvements were made which involved substantially
changing the protocol between libsocket.so.1 and sockmod (even simple
bug fixes can have this effect).  Those folks that statically linked
with libsocket.a in 2.3 were now talking the wrong language to
sockmod.  Application breakage.  Bad juju.  Do we hear about it?  No.
Customer simply "certifies" their app against 2.3.  Move forward in
time, people want to buy Ultras because they want the app in question
to go fast.  Problem is that the Ultras run 2.5 minimally.  Now we
hear about it.  Of course, the application developer doesn't want to
change _anything_ because then they say they have to restart their QA
cycle for the new OS which is 18 man-months (that mythical metric).
This is not something they are going to do at the expense of the
release schedule for the current development.  Stalemate.

The root problem is that some applications break with each release of
the system software.  This causes people the spend millions
re-certifying their environments on each release.  The creates
back-pressure affecting our ability to develop and sell new
technology.  So there is a tension between the demand for new
technology and the cost of application re-certification.  Given
infinite engineering resources, this tension would be irrelevant...

 RC> When you make it easier, it will happen more,
 RC> i. e. it sure the hell is Sun's fault.

Ahh, the "make more guns, more people will shoot themselves" argument.
;-)  Smith & Wesson's fault.  I suppose, though, that if we keep on
claiming that software doesn't cause cancer we might be at risk of
having to pay out a major legal settlement in 20 years...
:-) :-)

 RC> Anyway, my point was that Martin's choice of ``the oldest OS
 RC> version around'' isn't really all that old.

It shipped in very early 94.  Three and a half years is plenty old in
this business.

 RC> However, he shouldn't have to be worrying about such things.  He
 RC> should be able to build on 2.6.  In fact, as was brought out at
 RC> the start of this conversation, the executable *does* work on
 RC> older versions -- you have to lie about the names of the dynamic
 RC> libraries, but once you do, things work.  The stumbling block is
 RC> the way that the underlying mechanism works, that is, the part
 RC> that's Sun's doing.

Would it be that we could all choose what we worry about.  We
shouldn't have to worry NULL pointers, memory leaks, etc either.  But
we do.  And dammit, that's Ritchie's fault.

Incidentally, the 2.6 binary of XEmacs does not work with earlier due
to an implementation change in ctype.h.  There is no symlink game you
can play here.

While on the subject of symlink games, might I suggest one in which
rootification is not required.

   1. Make yourself a $HOME/tmp/stupid_lib_links
   2. Make symlinks there
   3. LD_LIRARY_PATH=$HOME/tmp/stupid_lib_links stupid_app

 RC> If Sun would simply continue to allow what is known to work, I
 RC> would not be faulting them.  Period.

What is "known to work", unfortunately does not.

 RC> Are we a big company with big customers still using Lemacs 19.4?
 RC> I thought not.

No but we break people's .emacs files every release and I for one have 
given up trying to keep the 30 XEmacs users here current and happy.

