7 ms·

Why wasn’t Kermit used by BBSes? Even at the time I remember having read about it in computer magazines, but I got my first modem in ‘82 or so and I don’t recal

Why wasn’t Kermit used by BBSes? Even at the time I remember having read about it in computer magazines, but I got my first modem in ‘82 or so and I don’t recall ever seeing it in the wild. My first actual contact with it was uploading firmware I wrote to an embedded controller. But the thing it was actually designed for? Not even once. So… why? We didn’t collectively settle on YMODEM and ZMODEM until many years later. There were lots of early protocols to choose from back then, too. Punter, anyone? No Kermit, though.

compiler-guy 2mo ago
Kermit had licensing issues in those days. And many bbs were focused on one specific system so many of the auto translate and nice compatibility features of Kermit weren’t that important. And finally Kermit didn’t have great defaults especially compared to ymodem and zmodem. So getting good performance out of Kermit was much harder than the others. All of that added up to much lower adoption outside of the mainframe world.
_JamesA_ 2mo ago
GOO. I remember Punter well.
jgoerzen 2mo ago
The very oldest (early 80s) Kermit implementations were limited to 96-byte packets. Kermit gained support for 4K and 9K jumbo frames, sliding windows, etc., and was generally faster than ZModem -- when there was a modern implementation. But a lot of BBSs (and also client-side communication software) did their own from-scratch Kermit implementation, which was tiny packets and no sliding windows, so it was slow. There's some discussion of it here: https://www.kermitproject.org/misconceptions.html#notslow https://www.kermitproject.org/misconceptions.html#notslow
- jandrese 2mo ago
  This is what I remember. Kermit hated latency, and dial up modems had that in spades. It was much slower than Z-Modem for pushing files around.
  - icedchai 2mo ago
    Same. I was very active in BBSing in the late 80's through the mid 90's. Kermit was the protocol of last resort.
  - devilbunny 2mo ago
    It did fine iff you had a good Kermit implementation at the BBS. Most used the most basic possible version of the protocol, which was godawfully slow, but I did some dialup at the end of the BBS era (93-95) where someone showed me how to use Kermit properly with large packets and sliding windows. It was every bit as fast as Zmodem, though I don’t recall if it supported transfer resuming. I never used the translation features, though I can think of one particular summer where that would have been very useful (had a 7E1 connection - I got files to my PC by uuencoding to screen, saving the buffer contents to my PC, and then uudecoding them locally).
    - jandrese 2mo ago
      A good example of the defaults being incredibly important to any application. If your defaults are super slow then most people are going to come away with the impression that your application is slow. FTP is another great example where people got the impression that it was prone to corrupting transfers because the default setting was to corrupt binary transfers.

compiler-guy 2mo ago

Kermit had licensing issues in those days. And many bbs were focused on one specific system so many of the auto translate and nice compatibility features of Kermit weren’t that important. And finally Kermit didn’t have great defaults especially compared to ymodem and zmodem. So getting good performance out of Kermit was much harder than the others. All of that added up to much lower adoption outside of the mainframe world.

_JamesA_ 2mo ago

GOO. I remember Punter well.

jgoerzen 2mo ago

The very oldest (early 80s) Kermit implementations were limited to 96-byte packets. Kermit gained support for 4K and 9K jumbo frames, sliding windows, etc., and was generally faster than ZModem -- when there was a modern implementation. But a lot of BBSs (and also client-side communication software) did their own from-scratch Kermit implementation, which was tiny packets and no sliding windows, so it was slow. There's some discussion of it here: https://www.kermitproject.org/misconceptions.html#notslow https://www.kermitproject.org/misconceptions.html#notslow

jandrese 2mo ago
This is what I remember. Kermit hated latency, and dial up modems had that in spades. It was much slower than Z-Modem for pushing files around.
- icedchai 2mo ago
  Same. I was very active in BBSing in the late 80's through the mid 90's. Kermit was the protocol of last resort.
- devilbunny 2mo ago
  It did fine iff you had a good Kermit implementation at the BBS. Most used the most basic possible version of the protocol, which was godawfully slow, but I did some dialup at the end of the BBS era (93-95) where someone showed me how to use Kermit properly with large packets and sliding windows. It was every bit as fast as Zmodem, though I don’t recall if it supported transfer resuming. I never used the translation features, though I can think of one particular summer where that would have been very useful (had a 7E1 connection - I got files to my PC by uuencoding to screen, saving the buffer contents to my PC, and then uudecoding them locally).
  - jandrese 2mo ago
    A good example of the defaults being incredibly important to any application. If your defaults are super slow then most people are going to come away with the impression that your application is slow. FTP is another great example where people got the impression that it was prone to corrupting transfers because the default setting was to corrupt binary transfers.