C-kermit fails

C-kermit fails

[Mike]

Hi,

I normally install kermit on my Linux Ubuntu PC with the command
  sudo apt-get install ckermit

Now I get the message "E: Package 'ckermit' has no installation candidate"

Has something changed?

I sent this messagee to the C-kermit developer, Frank da Cruz (fdc@columbia.edu) and he said the following:
--------------
Apparently glibc was changed in a way that broke C-Kermit,
so the reaction of Linux packagers was to remove C-Kermit
from their distribution.  Somebody else wrote me about
this earlier today concerning Debian:

Debian's "solution" to the problem was to drop the package
after the initial bug was filed, without contacting
upstream about it at all(!), hence presumably why this is
news to you. I've done some digging, and it appears glibc
is to blame (they removed an interface in 2.28). This
patch from gentoo, which also apparently didn't think
about telling you (sigh) appears to fix it:

https://685096.bugs.gentoo.org/attachment.cgi?id=589698

I have verified that it compiles now. 

The right thing to do would be to encourage the glibc
people to put back the symbol that they deleted.  Because
if this change broke C-Kermit, it's likely to have broken
a lot more applications.
--------------------

This is all above my skill level. Can someone out there help me? This is a critical need.

—————————————
R. Michael Reynolds, mobile/text: 631-374-2537  michael@rmrco.com
Remote Measurements & Research Co.,  214 Euclid Ave., Seattle WA 98122
—————————————

Re: C-kermit fails

[Florian Weimer]

* Mike:

> I normally install kermit on my Linux Ubuntu PC with the command
>   sudo apt-get install ckermit
>
> Now I get the message "E: Package 'ckermit' has no installation candidate"

> This is all above my skill level. Can someone out there help me?
> This is a critical need.

Please contact the Ubuntu support forums.

In the meantime, the minicom or screen packages might be replacements
if all you need is access to serial lines.

Re: C-kermit fails

[Zack Weinberg]

On Fri, Jul 24, 2020 at 12:29 PM Mike <michael@rmrco.com> wrote:
> Frank da Cruz wrote:
>> Apparently glibc was changed in a way that broke C-Kermit,
>> so the reaction of Linux packagers was to remove C-Kermit
>> from their distribution.  Somebody else wrote me about
>> this earlier today concerning Debian:
>>
>>> Debian's "solution" to the problem was to drop the package
>>> after the initial bug was filed, without contacting
>>> upstream about it at all(!), hence presumably why this is
>>> news to you. I've done some digging, and it appears glibc
>>> is to blame (they removed an interface in 2.28). This
>>> patch from gentoo, which also apparently didn't think
>>> about telling you (sigh) appears to fix it:
>>>
>>> https://685096.bugs.gentoo.org/attachment.cgi?id=589698
>>
>> I have verified that it compiles now.
>>
>> The right thing to do would be to encourage the glibc
>> people to put back the symbol that they deleted.  Because
>> if this change broke C-Kermit, it's likely to have broken
>> a lot more applications.

The symbol that was removed (_IO_file_flags) was never a documented
part of the stdio interface.  The code that is gated on its definition
uses other undocumented internals of stdio; we do in fact have plans
that may cause those symbols to disappear as well.  This thread is the
first we've heard about C-Kermit depending on it, and we haven't heard
of *any* other application that does.  (Although it's possible that
redistributors of other applications didn't bother telling us about
problems either.)

The right fix for upstream C-Kermit would be to bypass stdin
altogether and use only read(0, &ch, 1), together with the <termios.h>
interfaces for querying the kernel-side input buffer. I looked at the
code briefly and it seems like coninc() and in_chk() already do this.
It's not clear to me why cmdgetc() ever uses getc(stdin) and/or
getchar().

zw

Re: C-kermit fails

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

On 7/24/20 10:36 AM, Zack Weinberg wrote:
> The symbol that was removed (_IO_file_flags) was never a documented
> part of the stdio interface.

True, though lots of programs want to know about stdio readahead and it's 
unfortunate that glibc and other C libraries don't provide a documented way to 
get it.

We have a Gnulib module for discovering stdio readahead. As seen here:

https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/freadahead.c#n36

Gnulib uses the guard "#if defined _IO_EOF_SEEN || defined _IO_ftrylockfile || 
__GNU_LIBRARY__ == 1" to be as portable as possible to various glibc-like 
libraries, so I suggest the attached minimal patch to C-Kermit.

[-- Attachment #2: c-kermit.patch --]
[-- Type: text/x-patch, Size: 621 bytes --]

--- c-kermit/ckucmd.c	2020-04-25 13:43:15.000000000 -0700
+++ c-kermit-fix/ckucmd.c	2020-07-24 11:43:43.436751064 -0700
@@ -7575,9 +7575,10 @@
 
 /* Here we must look inside the stdin buffer - highly platform dependent */
 
-#ifdef _IO_file_flags			/* Linux */
+#if defined _IO_EOF_SEEN || defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1
+    /* glibc and similar libraries */
     x = (int) ((stdin->_IO_read_end) - (stdin->_IO_read_ptr));
-    debug(F101,"cmdconchk _IO_file_flags","",x);
+    debug(F101,"cmdconchk glibc-style","",x);
 #else  /* _IO_file_flags */
 #ifdef USE_FILE_CNT			/* Traditional */
 #ifdef VMS

Re: C-kermit fails

[Frank da Cruz]

Somebody else sent a simpler patch, you can see it here:

http://kermitproject.org/ckglibc228.diff

Ever since yesterday I've had mail coming in from people who reported that
different Linux distributors (e.g. Debian, Ubuntu) had dropped C-Kermit
from their packages collection.  They were surprised when apt-get said,
nope, we don't have that.  In some cases, these people are in a big rush
because of some emergency or deadline.  So casually removing something from
your header files is kind of like a COVID-19 virus, it strikes a few people
at first and then starts multiplying, affecting end-users and developers
alike.  The cardinal rule for OS developers was once "maintain backwards
compatibility" or more simply stated, "do no harm".  I've been a programmer
since 1965 if you can believe it, and have watched helplessly as this rule
started being thrown out the window starting around 1990.

I just put up a new C-Kermit version that has a simpler patch, please let
me know if you see a problem with it; it was sent to me by someone else; at
present I don't have access to anything but Red Hat and NetBSD:

http://kermitproject.org/ckglibc228.diff

I'm going to be forced to turn this into a real release ASAP, long before I
was planning to, and I would hope that the Linux packagers who tossed
C-Kermit will put it back once this settles down (and better still, that
they contact me when they find out about a problem).  You have only heard
about C-Kermit so far, but how do you know other applications won't be
affected?  It's better to leave things in, especially in libc.  If we can't
depend on libc, what's the use in even trying to write stable software?

Anyway another problem with your patch is, believe or not, C-Kermit is
written to be buildable on platforms going back to the 1970s (Bell Research
Unix V8) and 80s (HP-UX 5.0) so compound #if statements can't be used.

I'd encourage you to put the missing symbol (and code supporting it) back
in glibc and be more careful about removing things that "nobody uses" or
"nobody *should* use".  But since the new glibc is already out in the wild,
I'll still have to support the systems that have the missing symbol from
now on, just like I still support dentists' offices that have ancient
versions of SCO Xenix.

- Frank

On Fri, Jul 24, 2020 at 2:47 PM Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 7/24/20 10:36 AM, Zack Weinberg wrote:
> > The symbol that was removed (_IO_file_flags) was never a documented
> > part of the stdio interface.
>
> True, though lots of programs want to know about stdio readahead and it's
> unfortunate that glibc and other C libraries don't provide a documented
> way to
> get it.
>
> We have a Gnulib module for discovering stdio readahead. As seen here:
>
> https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/freadahead.c#n36
>
> Gnulib uses the guard "#if defined _IO_EOF_SEEN || defined
> _IO_ftrylockfile ||
> __GNU_LIBRARY__ == 1" to be as portable as possible to various glibc-like
> libraries, so I suggest the attached minimal patch to C-Kermit.
>

Re: C-kermit fails

[Frank da Cruz]

Sorry, I pasted a wrong URL into my last message; the new C-Kermit version
(for testing only), 9.0.305 Alpha.01 is here:

http://kermitproject.org/ckdaily.html

- Frank

On Fri, Jul 24, 2020 at 3:41 PM Frank da Cruz <fdc@columbia.edu> wrote:

> Somebody else sent a simpler patch, you can see it here:
>
> http://kermitproject.org/ckglibc228.diff
>
> Ever since yesterday I've had mail coming in from people who reported that
> different Linux distributors (e.g. Debian, Ubuntu) had dropped C-Kermit
> from their packages collection.  They were surprised when apt-get said,
> nope, we don't have that.  In some cases, these people are in a big rush
> because of some emergency or deadline.  So casually removing something from
> your header files is kind of like a COVID-19 virus, it strikes a few people
> at first and then starts multiplying, affecting end-users and developers
> alike.  The cardinal rule for OS developers was once "maintain backwards
> compatibility" or more simply stated, "do no harm".  I've been a programmer
> since 1965 if you can believe it, and have watched helplessly as this rule
> started being thrown out the window starting around 1990.
>
> I just put up a new C-Kermit version that has a simpler patch, please let
> me know if you see a problem with it; it was sent to me by someone else; at
> present I don't have access to anything but Red Hat and NetBSD:
>
> http://kermitproject.org/ckglibc228.diff
>
> I'm going to be forced to turn this into a real release ASAP, long before
> I was planning to, and I would hope that the Linux packagers who tossed
> C-Kermit will put it back once this settles down (and better still, that
> they contact me when they find out about a problem).  You have only heard
> about C-Kermit so far, but how do you know other applications won't be
> affected?  It's better to leave things in, especially in libc.  If we can't
> depend on libc, what's the use in even trying to write stable software?
>
> Anyway another problem with your patch is, believe or not, C-Kermit is
> written to be buildable on platforms going back to the 1970s (Bell Research
> Unix V8) and 80s (HP-UX 5.0) so compound #if statements can't be used.
>
> I'd encourage you to put the missing symbol (and code supporting it) back
> in glibc and be more careful about removing things that "nobody uses" or
> "nobody *should* use".  But since the new glibc is already out in the
> wild, I'll still have to support the systems that have the missing symbol
> from now on, just like I still support dentists' offices that have ancient
> versions of SCO Xenix.
>
> - Frank
>
> On Fri, Jul 24, 2020 at 2:47 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
>> On 7/24/20 10:36 AM, Zack Weinberg wrote:
>> > The symbol that was removed (_IO_file_flags) was never a documented
>> > part of the stdio interface.
>>
>> True, though lots of programs want to know about stdio readahead and it's
>> unfortunate that glibc and other C libraries don't provide a documented
>> way to
>> get it.
>>
>> We have a Gnulib module for discovering stdio readahead. As seen here:
>>
>> https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/freadahead.c#n36
>>
>> Gnulib uses the guard "#if defined _IO_EOF_SEEN || defined
>> _IO_ftrylockfile ||
>> __GNU_LIBRARY__ == 1" to be as portable as possible to various glibc-like
>> libraries, so I suggest the attached minimal patch to C-Kermit.
>>
>

Re: C-kermit fails

[Zack Weinberg]

On Fri, Jul 24, 2020 at 3:41 PM Frank da Cruz <fdc@columbia.edu> wrote:
> Somebody else sent a simpler patch, you can see it here:
>
> http://kermitproject.org/ckglibc228.diff

This is still wrong, __FILE_defined is another implementation-use-only
symbol, and it doesn't mean that the things you're actually trying to
use are available.  (I am sorely tempted to delete it from the next
release just to underline this point.)  If you need a stopgap for now,
this is as correct as it gets:

- #ifdef _IO_file_flags            /* Linux */
+ #if __GLIBC__ >= 2           /* GNU libc >= 2.0 */

... however, we are planning to stop exposing *any* of the internals
of the FILE struct, Real Soon Now, at which point there will be
nothing you can put here that will be correct.  We will consider
adding a musl-compatible __freadahead, probably before that happens,
but the right fix, again, is to remove all the code that can call
getchar/getc(stdin), relying exclusively on read(0, &ch, 1).  Then you
wouldn't need to poke around in stdio internals on *any* platform.

> I'd encourage you to put the missing symbol (and code supporting it) back in glibc

Sorry, no, not going to put it back.

zw

Re: C-kermit fails

[Paul Eggert]

On 7/24/20 12:41 PM, Frank da Cruz wrote:
> So casually removing something from
> your header files is kind of like a COVID-19 virus

This strikes me as a bit unfair, as those parts of the header files have always 
been explicitly private.

Zack is right that C-Kermit's best bet for portability/reliability is to remove 
uses of getchar/getc. This would render unnecessary that unportable cruft in 
ckucmd.c.

If age and experience is a qualification for an opinion here, I will confess 
that I've also been writing code since the 1960s, and my opinion is that 
programs that stick their fingers into stdio's internals bear the responsibility 
for the consequences. And I write this despite helping to maintain code (Gnulib) 
that does exactly what C-Kermit's ckucmd.c does. When the new glibc came out the 
Gnulib developers didn't complain that glibc's changes were "like a COVID-19 
virus"; we simply adapted Gnulib and moved on.

Re: C-kermit fails

[Frank da Cruz]

 The reason I use getchar/getc is that Kernighan and Plauger recommend it
because it's buffered and avoids needless context switches.  I'm sure you
guys don't care much about the efficiency of character loops, but some of
the ancient machines where C-Kermit runs are pretty slow.  Computers and
operating systems are supposed to serve the needs of human beings.  But
when you make non-backward-compatible changes to operating systems that
break existing applications, you force people to stop what they are working
on (a cure for some deadly disease, perhaps) and search for a new version
of the application they were using that "complies" with the new "standard",
and then, not finding one, hunt down and contact the developers, if they
are still alive, and beg them to "update" their software.  When you think
of a more "correct" way of accomplishing something, by all means add it to
the system, but without removing the old way, so existing software
continues to run.  Unix is supposed to be a family of operating systems
among which software source code is portable, allowing a degree of freedom
in computer purchases.  It's not perfect, to be sure, as anyone who looks
at the #ifdef soup in the C-Kermit code can attest, but it sure beats the
situation back in the early 80s, when most universities had DECSYSTEM-20s
and all the software was written in languages that didn't exist on any
other platform and certainly don't exist today (Macro-20, SAIL, BCPL..).
At Columbia U the transition from DEC-20 to Unix (DEC Ultrix at first) was
a massive job; NO software could be ported, all the applications had to be
rewritten from scratch, in C of course.  But going from Ultrix to SunOS to
Solaris and finally to Linux was relatively painless.  So I think the
objective of Unix OS developers should be *towards* compatibility rather
than away from it, as seems to be the case with glibc.

- Frank

On Fri, Jul 24, 2020 at 5:07 PM Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 7/24/20 12:41 PM, Frank da Cruz wrote:
> > So casually removing something from
> > your header files is kind of like a COVID-19 virus
>
> This strikes me as a bit unfair, as those parts of the header files have
> always
> been explicitly private.
>
> Zack is right that C-Kermit's best bet for portability/reliability is to
> remove
> uses of getchar/getc. This would render unnecessary that unportable cruft
> in
> ckucmd.c.
>
> If age and experience is a qualification for an opinion here, I will
> confess
> that I've also been writing code since the 1960s, and my opinion is that
> programs that stick their fingers into stdio's internals bear the
> responsibility
> for the consequences. And I write this despite helping to maintain code
> (Gnulib)
> that does exactly what C-Kermit's ckucmd.c does. When the new glibc came
> out the
> Gnulib developers didn't complain that glibc's changes were "like a
> COVID-19
> virus"; we simply adapted Gnulib and moved on.
>

Re: C-kermit fails

[Paul Eggert]

On 7/24/20 4:45 PM, Frank da Cruz wrote:

> Unix is supposed to be a family of operating systems
> among which software source code is portable, allowing a degree of freedom
> in computer purchases.

Sure, but only if developers do their job properly. A developer can easily write 
and run C code that is unportable by assuming a particular memory-management 
algorithm, or particular stdio.h internals, or whatever. If that happens and the 
application fails to run on a different OS or OS release, the problem is with 
the app, not with the library it's built upon.

Besides, the particular code we're talking about isn't portable even among Unix 
variants. It won't run on 7th Edition Unix (1979), for example. Nor will it run 
on the stdio.h implementation described in K&R's classic 2nd edition (1978). The 
code is a deliberately unportable hack, and the only way that it can stay 
relevant is if it's continually maintained as platforms evolve. If such 
maintenance is too heavy a lift then a better way to go is to follow Zack's 
suggestion and use standard interfaces as defined by POSIX.

Re: C-kermit fails

[Florian Weimer via Libc-alpha]

* Zack Weinberg:

> On Fri, Jul 24, 2020 at 3:41 PM Frank da Cruz <fdc@columbia.edu> wrote:
>> Somebody else sent a simpler patch, you can see it here:
>>
>> http://kermitproject.org/ckglibc228.diff
>
> This is still wrong, __FILE_defined is another implementation-use-only
> symbol, and it doesn't mean that the things you're actually trying to
> use are available.  (I am sorely tempted to delete it from the next
> release just to underline this point.)  If you need a stopgap for now,
> this is as correct as it gets:
>
> - #ifdef _IO_file_flags            /* Linux */
> + #if __GLIBC__ >= 2           /* GNU libc >= 2.0 */
>
> ... however, we are planning to stop exposing *any* of the internals
> of the FILE struct, Real Soon Now, at which point there will be
> nothing you can put here that will be correct.

I'm not sure if we can really do that (in the sense that there will be
nothing that works to replace this construct), but I completely agree
that this is undefined and should remain so.

If you do not like the stdio library, write your own I/O library (or use
another existing one).  Do not try to patch up the implementation using
internal details.

Keep in mind that each time you access library internals in this way,
you make it harder for us to make changes, including fixes for bugs you
might yourself have requested, because such changes may invalidate
existing programs.

Thanks,
Florian

Re: C-kermit fails

[Maciej W. Rozycki]

On Fri, 24 Jul 2020, Frank da Cruz wrote:

>  The reason I use getchar/getc is that Kernighan and Plauger recommend it
> because it's buffered and avoids needless context switches.  I'm sure you
> guys don't care much about the efficiency of character loops, but some of
> the ancient machines where C-Kermit runs are pretty slow.

 I can't speak for other people, but myself I do care, and I also enjoy 
using vintage computers, although maybe not as old as DECSYSTEM-20 (a VAX 
is probably the oldest piece I have).

 Since you already use #ifdefs to provide code alternatives then may I 
suggest that you keep the relevant piece for the systems where the gain 
from using getchar/getc is actually noticeable and switch to documented 
standard interfaces for contemporary systems?

 This way you'll keep the benefits for everyone: much needed performance 
for the old systems and portability for current systems where any gain 
from fiddling with libc internals accidentally exposed is lost in the 
noise?

>  Computers and
> operating systems are supposed to serve the needs of human beings.  But
> when you make non-backward-compatible changes to operating systems that
> break existing applications, you force people to stop what they are working
> on (a cure for some deadly disease, perhaps) and search for a new version
> of the application they were using that "complies" with the new "standard",
> and then, not finding one, hunt down and contact the developers, if they
> are still alive, and beg them to "update" their software.

 Yes, this is painful indeed, and much overlooked by software developers 
nowadays IMO.

> At Columbia U the transition from DEC-20 to Unix (DEC Ultrix at first) was
> a massive job; NO software could be ported, all the applications had to be
> rewritten from scratch, in C of course.  But going from Ultrix to SunOS to
> Solaris and finally to Linux was relatively painless.  So I think the
> objective of Unix OS developers should be *towards* compatibility rather
> than away from it, as seems to be the case with glibc.

 This is why we have a set of standards for the interfaces we promise to 
support.  Please try and stick to them.

  Maciej

Re: C-kermit fails

[Frank da Cruz]

On Fri 32 Jul 2020 Maciej W. Rozycki <macro@linux-mips.org> wrote:
> Since you already use #ifdefs to provide code alternatives then may I
> suggest that you keep the relevant piece for the systems where the gain
> from using getchar/getc is actually noticeable and switch to documented
> standard interfaces for contemporary systems?
>
That's what I have always done since C-Kermit first appeared in 1985, and
it's why C-Kermit is so full of #ifdefs.  Although I'm not sure I accept it
is incumbent on developers to stop using fread because somebody can't be
bothered to implement a politically correct way to peek into the buffer to
see if any characters are there.  This is necessary to prevent the program
from blocking on an input request at a time when it might productively be
doing something else.  Which is a classic problem that must be solved in
every terminal emulator.  Of course there are more modern ways to write
terminal emulators, e.g. using threads or whatever, but these are not
available on all the platforms where C-Kermit runs.  Not even select() is
available on all those platforms. But the whole point of C-Kermit is to not
have to write a whole new program for each platform, but to have a single
code base that is portable among as many platforms as possible.

I have no control over what operating-system makers do (or the makers of
glibc), and if they think it's OK to break existing applications I'll have
to program around it when I could likely be doing something more useful.
But ever since Unix went public, and especially since the free versions
appeared, I find that I spend more time redoing everything I already did
before than I spend doing anything new.  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.

- Frank


On Fri, Jul 31, 2020 at 8:41 AM Maciej W. Rozycki <macro@linux-mips.org>
wrote:

> On Fri, 24 Jul 2020, Frank da Cruz wrote:
>
> >  The reason I use getchar/getc is that Kernighan and Plauger recommend it
> > because it's buffered and avoids needless context switches.  I'm sure you
> > guys don't care much about the efficiency of character loops, but some of
> > the ancient machines where C-Kermit runs are pretty slow.
>
>  I can't speak for other people, but myself I do care, and I also enjoy
> using vintage computers, although maybe not as old as DECSYSTEM-20 (a VAX
> is probably the oldest piece I have).
>
>  Since you already use #ifdefs to provide code alternatives then may I
> suggest that you keep the relevant piece for the systems where the gain
> from using getchar/getc is actually noticeable and switch to documented
> standard interfaces for contemporary systems?
>
>  This way you'll keep the benefits for everyone: much needed performance
> for the old systems and portability for current systems where any gain
> from fiddling with libc internals accidentally exposed is lost in the
> noise?
>
> >  Computers and
> > operating systems are supposed to serve the needs of human beings.  But
> > when you make non-backward-compatible changes to operating systems that
> > break existing applications, you force people to stop what they are
> working
> > on (a cure for some deadly disease, perhaps) and search for a new version
> > of the application they were using that "complies" with the new
> "standard",
> > and then, not finding one, hunt down and contact the developers, if they
> > are still alive, and beg them to "update" their software.
>
>  Yes, this is painful indeed, and much overlooked by software developers
> nowadays IMO.
>
> > At Columbia U the transition from DEC-20 to Unix (DEC Ultrix at first)
> was
> > a massive job; NO software could be ported, all the applications had to
> be
> > rewritten from scratch, in C of course.  But going from Ultrix to SunOS
> to
> > Solaris and finally to Linux was relatively painless.  So I think the
> > objective of Unix OS developers should be *towards* compatibility rather
> > than away from it, as seems to be the case with glibc.
>
>  This is why we have a set of standards for the interfaces we promise to
> support.  Please try and stick to them.
>
>   Maciej
>

Re: C-kermit fails

[Paul Eggert]

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".

Re: C-kermit fails

[Frank da Cruz]

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".
>

Re: C-kermit fails

[Paul Eggert]

On 7/31/20 5:17 PM, Frank da Cruz wrote:
> what harm is there in leaving the stdin buffering items where they have
> been all these years?

I don't know and I'm too lazy to look up whether it was for thread-safety or 
buffer safety or performance or whatever. I seriously doubt whether some glibc 
developer said, "Oh, let's change stdio internals for no good reason."