3 ms·

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., an

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.

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.