Re: C-kermit fails

[Frank da Cruz <fdc@columbia.edu>]

You're right, there was also some awful stuff in the good old days but
somehow it didn't affect me much.  We ran an IBM 360/91 for 11 years and
never experienced any software rot.  The DEC-20s were especially good; we
field-tested each new release of the OS (TOPS-20) and any problems that we
reported, they fixed.  During normal operation, between field tests, if we
ever found a problem we submitted an SPR (software performance report) and
they fixed the problem promptly; applications continued to work through
five or six major OS releases.  The important point was the vendor's
commitment to not breaking existing applications, including well-defined
mechanisms for reporting problems when they occurred and getting them
fixed, rather than a response to the effect of "we have deprecated that
feature".

Of course eventually these proprietary platforms and OS's ceased to exist
and then it was back to Square One for everybody. That's why I appreciate
Unix so much, and why I am so sensitive when Unix (Linux) OS packagers
deliberately remove features that people use.  In the present case, I would
ask what harm is there in leaving the stdin buffering items where they have
been all these years?  If they were a bug or a security risk, there might
be a reason to remove them but only if the bug or risk could not be fixed
without doing so.  If I was in charge and I believed there was something
unhealthy about the current mechanism, I would add a new function to do the
same thing (stdin buffer-peeking), explain its advantages, and recommend
that applications "migrate" to it over time, but I would still leave the
old stuff in place because, unless I'm missing something, there is no good
reason not to. The first rule should be, "do no harm" because you never
know what the effects be be down the road.

- Frank


On Fri, Jul 31, 2020 at 4:23 PM Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 7/31/20 11:22 AM, Frank da Cruz wrote:
> > Software development was not like
> > this when computing was dominated by companies like IBM and DEC, who were
> > dedicated to preserving their customers' investments in software because
> if
> > they didn't, they'd lose those customers.
>
> That wasn't my experience at all. IBM and DEC regularly broke user
> applications
> and said the equivalent of "If you don't like it, then just keep running
> the old
> OS on the old hardware." They then tried to sell you new stuff, and if you
> refused they eventually stopped supporting the old stuff.
>
> For example, circa 1978 if you wanted to use a PDP-11/70 and selected
> DEC's
> operating system RSTS, you would have been kinda out of luck by around
> 1983 when
> the PDP-11/70 was obsolete. DEC told customers to switch to VAX/VMS, and
> gave
> some upgrade paths (late-1970s VAX hardware would emulate PDP-11s and if
> you
> threw DEC some more money VMS would support RSTS user processes, albeit
> inefficiently) but DEC dropped those upgrade paths in later VAX hardware
> and you
> were stuck. The last RSTS release was in 1992 and DEC stopped supporting
> RSTS
> soon after.
>
> Had you selected Unix instead in 1978, you'd have been golden. Your
> software
> would still run today, with only minor changes. I still run some personal
> Unix-based software now that I originally ran on a PDP-11 in the late
> 1970s.
>
> And it wasn't just DEC. I remember the FAA using IBM mainframes in their
> air
> traffic control systems designed in the 1960s and written in 360 assembler
> with
> CCW programs. The FAA kept running this stuff on an old IBM OS on old IBM
> hardware until IBM told them around 1980 that IBM wouldn't support it any
> more.
> IBM then sold the FAA on a replacement system called AAS that cost
> billions and
> never worked. See
> <
> https://www.sebokwiki.org/wiki/Federal_Aviation_Administration_(FAA)_Advanced_Automation_System_(AAS)>
>
> for some of this sad history.
>
> Although I'm sure one can cite examples of old-time backward
> compatibility, I'm
> exceedingly skeptical that the old days were any better than now overall
> in that
> department. Quite the contrary. In particular, the GNU C library is *much*
> better about backward compatibility than IBM and DEC were in the "good old
> days".
>