HP3000-L Archives

May 2002, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stan Sieler <[log in to unmask]>
Reply To:
Stan Sieler <[log in to unmask]>
Date:
Thu, 2 May 2002 11:24:42 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (60 lines)
Re:
> Did I understand you to mean that HP-UX 11 vs 10 is short these 29
> subroutines???  If so I'd like to retract my comment about "poor planning..."
> instead I'd like to substitute "grossly stupid non-planning...".   I suspect
> that this involves renaming or substituting new subroutines for the 'old'
> ones.

It's another example of HP yanking out working code.  They've
done that a number of times in the history of HP-UX.  The other two
relatively big examples I remember off hand: graphics support in the
9000/834 was yanked between 8.0 and 9.0 (IIRC), and Context Dependent
Files were yanked either then or between 9.0 and 10.0.


> The intelligent way to eliminate/rename
> subroutines is to announce that they will be phased out in the future and
> give everyone at least a couple of releases to get their code changed over to
> new subroutines.

In many cases they do that ... but for some software/features,
one has to ask "why phase them out?"!

(The routines I mentioned are in a library called "portnls";
the 11.00 Release Notes claims that portnls had been "deprecated"
for a couple of years.)

In the portnls example, we're not dealing with dropping HP-IB support here ...
but with dropping software used by no other part of the kernel,
software that doesn't need to *ever* change.  Indeed, we're discussing
something that *cost* them money to drop (file updates, documentation
updates), and cost them nothing to keep.

In some other cases, HP could try to claim that the cost of testing
the software after OS changes was "too expensive".  That's usually not
an acceptable claim: their testing suites should be automated, and
the cost to the user should be considered as well.  For software
like portnls, it cost them money to *remove* tests from their suites,
and would cost nothing to keep the tests in.

In some other cases, the software might only be of use on select models,
which might not be under support now (or soon).  The graphics software
in the 9000/834 would fall into this category.  Does that justify
dumping it?  Of course not ... the HP Way would say "at the minimum,
leave it in, even if you can't afford to test it".  That approach gives
the user a choice.

Well, I tried to defend HP-UX somewhat, but that might not have come
across very well, so let me try a shorter statement without asides:

HP does usually try to document forthcoming changes/deletions in HP-UX,
and usually provides some documentation on how to cope with such changes.
In some cases, they offer (for a fee) porting assistance to cope with
such changes.

Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2