3 ms·

I've looked through the various pages linked trying to find out what Kermit actually is and have yet to find out. Ironically the 'About' link 404s.

by ginko 5y ago

usrn 5y ago
It's an old file transfer program.
- whartung 5y ago
  Yes, that's true, but it's understating it quite a bit. Kermit (actually , C-Kermit) is a serial communication program. Simply, it allowed you to connect to your serial port, and then interact with serial devices. Commonly the device you were interacting with was a modem, but that wasn't necessarily true. You could be connected straight up into another computer. Kermit is also a file transfer protocol, similar to XMODEM/YMODEM/ZMODEM. These protocols were used to ensure that copy operations operated reliably through the use of checksums and whatnot. Serial was the most common physical layer that this was used over, but not necessarily the only layer. The Kermit protocol was quite sophisticated and able to work at various levels of advancement and compatibility. It was able to work over connections that were not 8-Bit pure. It supported dynamic window sizes to help boost performance. They used to publish the simplest of BASIC programs to act as a receiver so that you could use it to bootstrap moving over a more capable program that was more sophisticated for your platform. Speaking of that, Kermit was widely ported to most any system out there. As an example, the HP-48G calculator had Kermit built into it. Because of that, we used to use the HPs for data collection in the field, and then upload the results to a PC using Kermit. XMODEM et al were widely popular and supported. Kermit was also, but because of C-Kermit, its wide distribution, it was also its own little world. C-Kermit also had an innate scripting language making it very useful for ad hoc, automated workflows.
wyldfire 5y ago
My experience with it was when BBSs were common and access to The Internet was limited to universities. If you wanted to upload or download a file, you could use one of these programs like Kermit to manage the file transfer. My recollection was that invoking it was a manual step at first but I recall it being triggered automatically by the terminal/dialer program (for downloads at least). I almost always used xmodem, ymodem or zmodem. I had that same impression described in this article that Kermit was "slow".
- tyingq 5y ago
  >I had that same impression described in this article that Kermit was "slow". Most of that was default settings. Kermit had defaults that assumed the worst...non-8bit-clean, no hardware flow control, small uart buffers, etc. If you tweaked the settings (sliding windows, packet size, etc), the differences in speed were negligible.
fmajid 5y ago
It's a program you use to connect to devices over serial ports (including via modem), and it has file-transfer capabilities built-in. I first started using it with my HP-48SX calculator in the 90s. It's still the first tool I reach out when communicating over serial devices, e.g. SBCs that don't have a graphical console like running OpenBSD over a BeagleBone using the UART to connect, or Cisco switches using the serial cable.
tyingq 5y ago
Before it was common for a home PC to have IP connectivity (via SLIP, PPP, etc), you needed a program to connect to your modem, dial a terminal session into a remote server, handle file transfers,etc. Sometimes these programs bundled both the terminal/dial up and the file transfer functionality. Other ones were terminal/dialers, but would spawn a separate file transfer program. Kermit was the bundled type...both the terminal/dial and file transfer was built-in. It was also more scriptable than a lot of other solutions...it had an embedded script language with send/expect functionality. So, for example, if you had a bank of ethernet connected modems, you could script whatever commands where needed to connect to them and dial. Or you could connect and script against the unix (or other) shell on the remote end. It's even handy for this type of thing today, as it can use ssh as the connection instead of dial up. It was also the most portable program of this type, with versions that would run on MS/DOS, Windows, Unix, IBM mainframes, Multics, CPM, etc. I used it quite a lot because I was a unix admin, and our work didn't offer SLIP or PPP dial-in. So, I could use kermit to run batch jobs to connect, download my recent work, maybe some usenet news data, etc. Or, just use it as a terminal program at home to get a unix shell prompt from a computer at work, upload files, and so on.
- tssva 5y ago
  Kermit supported much more than serial connections. It supported DEC LAT, telnet/telnet SSL and rlogin natively. Through external apps it supported TN3270, TN5250 and ssh.

I've looked through the various pages linked trying to find out what Kermit actually is and have yet to find out. Ironically the 'About' link 404s.

by ginko 5y ago

I've looked through the various pages linked trying to find out what Kermit actually is and have yet to find out. Ironically the 'About' link 404s.

usrn 5y ago

It's an old file transfer program.

whartung 5y ago
Yes, that's true, but it's understating it quite a bit. Kermit (actually , C-Kermit) is a serial communication program. Simply, it allowed you to connect to your serial port, and then interact with serial devices. Commonly the device you were interacting with was a modem, but that wasn't necessarily true. You could be connected straight up into another computer. Kermit is also a file transfer protocol, similar to XMODEM/YMODEM/ZMODEM. These protocols were used to ensure that copy operations operated reliably through the use of checksums and whatnot. Serial was the most common physical layer that this was used over, but not necessarily the only layer. The Kermit protocol was quite sophisticated and able to work at various levels of advancement and compatibility. It was able to work over connections that were not 8-Bit pure. It supported dynamic window sizes to help boost performance. They used to publish the simplest of BASIC programs to act as a receiver so that you could use it to bootstrap moving over a more capable program that was more sophisticated for your platform. Speaking of that, Kermit was widely ported to most any system out there. As an example, the HP-48G calculator had Kermit built into it. Because of that, we used to use the HPs for data collection in the field, and then upload the results to a PC using Kermit. XMODEM et al were widely popular and supported. Kermit was also, but because of C-Kermit, its wide distribution, it was also its own little world. C-Kermit also had an innate scripting language making it very useful for ad hoc, automated workflows.

wyldfire 5y ago

My experience with it was when BBSs were common and access to The Internet was limited to universities. If you wanted to upload or download a file, you could use one of these programs like Kermit to manage the file transfer. My recollection was that invoking it was a manual step at first but I recall it being triggered automatically by the terminal/dialer program (for downloads at least). I almost always used xmodem, ymodem or zmodem. I had that same impression described in this article that Kermit was "slow".

tyingq 5y ago
>I had that same impression described in this article that Kermit was "slow". Most of that was default settings. Kermit had defaults that assumed the worst...non-8bit-clean, no hardware flow control, small uart buffers, etc. If you tweaked the settings (sliding windows, packet size, etc), the differences in speed were negligible.

fmajid 5y ago

It's a program you use to connect to devices over serial ports (including via modem), and it has file-transfer capabilities built-in. I first started using it with my HP-48SX calculator in the 90s. It's still the first tool I reach out when communicating over serial devices, e.g. SBCs that don't have a graphical console like running OpenBSD over a BeagleBone using the UART to connect, or Cisco switches using the serial cable.

tyingq 5y ago

Before it was common for a home PC to have IP connectivity (via SLIP, PPP, etc), you needed a program to connect to your modem, dial a terminal session into a remote server, handle file transfers,etc. Sometimes these programs bundled both the terminal/dial up and the file transfer functionality. Other ones were terminal/dialers, but would spawn a separate file transfer program. Kermit was the bundled type...both the terminal/dial and file transfer was built-in. It was also more scriptable than a lot of other solutions...it had an embedded script language with send/expect functionality. So, for example, if you had a bank of ethernet connected modems, you could script whatever commands where needed to connect to them and dial. Or you could connect and script against the unix (or other) shell on the remote end. It's even handy for this type of thing today, as it can use ssh as the connection instead of dial up. It was also the most portable program of this type, with versions that would run on MS/DOS, Windows, Unix, IBM mainframes, Multics, CPM, etc. I used it quite a lot because I was a unix admin, and our work didn't offer SLIP or PPP dial-in. So, I could use kermit to run batch jobs to connect, download my recent work, maybe some usenet news data, etc. Or, just use it as a terminal program at home to get a unix shell prompt from a computer at work, upload files, and so on.

tssva 5y ago
Kermit supported much more than serial connections. It supported DEC LAT, telnet/telnet SSL and rlogin natively. Through external apps it supported TN3270, TN5250 and ssh.