31–40 of 52 posts
The remote host just needs kermit or zmodem (sz/rz), since at least K95 supported zmodem also.
There are paid for SSH clients (SecureCRT) that has the feature with Zmodem. Nice to have it on free software.
I remember mostly ignoring Kermit back in my BBSing days; by the time "SuperKermit" came along, which could get performance competitive with ZMODEM, it alreayd seemed ancient. Then, around 1991, a friend gave me access to his college Unix account so I could play with Gopher, Archie, and TinyFugue (the world of MUDs/MUCKs/etc.). The catch: to get to his account from my home machine, I had to call into a Florida state…
For context, on the other side of the wall where we were doing this was a Cray, probably a Cray 1. The one with the bench seating in a semicircle on top of cooling hardware.
Earlier quoted context omitted.
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'…
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.
I complied Kermit for IBM's AIX in ~1989 as a study in "how compatible is AIX to other Unixes?" Kermit source code remains the high-water mark in my memory for how many different, incompatible, non-standard platforms one piece of software can support. More than even Unix itself, as it could also run on VMS and non-Unixes of the time. I have never in my life seen so many `#ifdef`s and such complicated "Am I running on…
Which is interesting because most autoconf programs I've seen do the opposite. They have all these defines and then don't use them. Just seems like a waste of time. Cmake has been better but still sometimes cmake will pass and the code still doesn't build
"the name Kermit is used by permission of Henson Associates, Inc." that certainly would never happen nowadays.
Good Lord. That takes me back. I ported Kermit to the Computervision CGOS environment. It was very popular in the user community. Internally, it was used to transfer files between systems over the terminal concentrator when you didn't want to walk down to the machine room, scavenge a mag tape, and put up with FUTIL.
I had never heard of CGOS, but this is still up on the Kermit archive! https://kermitproject.org/archive.html Are you Val? Looks like you had to add some hacks to deal with long file naming conventions on CGOS but short filenames on CP/M.
For several of them, it is possibly the only surviving publicly accessible code.
For example, the GUTS (Gothenburg University Timesharing System) implementation-I doubt you will find any other code written for GUTS anywhere online. Maybe some offline archive at some former user still has some code for it, maybe this is all that survives
Earlier quoted context omitted.
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'…
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.
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).
I complied Kermit for IBM's AIX in ~1989 as a study in "how compatible is AIX to other Unixes?" Kermit source code remains the high-water mark in my memory for how many different, incompatible, non-standard platforms one piece of software can support. More than even Unix itself, as it could also run on VMS and non-Unixes of the time. I have never in my life seen so many `#ifdef`s and such complicated "Am I running on…
Which is interesting because most autoconf programs I've seen do the opposite. They have all these defines and then don't use them. Just seems like a waste of time. Cmake has been better but still sometimes cmake will pass and the code still doesn't build
Earlier quoted context omitted.
Which is interesting because most autoconf programs I've seen do the opposite. They have all these defines and then don't use them. Just seems like a waste of time. Cmake has been better but still sometimes cmake will pass and the code still doesn't build
Autotools on little endian Linux is the biggest waste of CPU time imaginable.