4 ms·

Kermit – Misconceptions and Controversies (2021)

58 points by zdw 5y ago

NoGravitas 5y ago
I used C-Kermit back in my dialup terminal days. It was a well-kept secret, I guess, that a properly tuned Kermit was significantly faster than ZModem.
- TomMasz 5y ago
  Tuning was the key. Once you understood the protocol and the robustness of your connection, it was easy to configure Kermit to run fast.
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.
jandeboevrie 5y ago
Kermit is one of those utilities I use almost daily. In my case to script a connection sequence to a hardware device via serial. (Few timed keystrokes and a string of text). Ubuntu 20.04 removed Kermit, so I packaged it up as a snap to be able to use it again: https://raymii.org/s/blog/Ive_packaged_up_CKermit_as_a_snap_for_Ubuntu_20.04.html https://raymii.org/s/blog/Ive_packaged_up_CKermit_as_a_snap_...
mhdhn 5y ago
File transfer protocol and related software. Some links https://en.m.wikipedia.org/wiki/Kermit_(protocol) https://en.m.wikipedia.org/wiki/Kermit_(protocol) https://www.kermitproject.org/kermit.html https://www.kermitproject.org/kermit.html
voxadam 5y ago
Archive: https://web.archive.org/web/20220424041605/https://www.columbia.edu/kermit/misconceptions.html https://web.archive.org/web/20220424041605/https://www.colum...
Brian_K_White 5y ago
Back in the days of serial terminals I made a sweet single-floppy terminal, customized to support a sco xenix application, with nothing but a bootable dos floppy and ms-kermit, and it worked better and was simpler for the users than the procomm plus they had been using. It was all because of how scriptable and customable ms-kermit was. Not only I was able to make all the terminal emulation and keyboard keys work perfect, I even made the disk user self maintaining where the disk could copy itself, so they never had a problem with the disks wearing out in a dirty shop environment. And it was all dirt cheap and dead simple for the users and business owner to maintain unlike a proper network booting solution would have been at the time. The window of time where that articular awesomeness mattered was small, but it sure was awesome. It wasn't even doing any kermit file transfers, just acting as a swiss army knife of a scriptable configurable serial terminal running on essentially free 8088 and 8086's with no hd's, ram, or nics.
zabzonk 5y ago
Ah, this takes me back. I wrote implementations of the Kermit protocol for the Z80, 6502 (both in assembler) and the 8086 (mostly in C, but some assembler for the interrupt-driven I/O). It was a really nice and easy to implement protocol, and very sturdy - you could unplug the serial port connection and then re-plug it, and the file transfer would restart where it was interrupted. This would have been mid-1980s.
whoopdedo 5y ago
Although the page says it was updated in 2021 (to change some FTP links to HTTP) the tag at the bottom says 2011. Some of the noted advantages of Kermit I don't see as relevant for new systems. Character sets? I use UTF-8 for everything. Text mode files? I treat everything as binary. File permissions and directory trees? Tar preserves those and more. Besides, I've never wanted to save more than a timestamp when copying between different computers. But it still holds up for being text-driven. In a what-old-is-new-again way a lot of the world has moved back to CLI since this was written. And for the same reason, because text interfaces are easier to automate. That said, I don't think a GUI is inherently unscriptable. There have been macro and automation tools for windowing systems. I think it mostly the attitude of GUI design doesn't consider automation a priority while CLI does. (I'd even say it's nearly impossible to make a text interface that can't be automated.) A macro I create to control a GUI will become obsolete when the application designer decides to move the buttons around for purely aesthetic reasons. Breaking changes like that are rare in text applications.
- tyingq 5y ago
  >Text mode files? I treat everything as binary. This is still an issue today with Windows vs everything else. I regularly filter ^M out of source files. There's all sorts of hackery in tools like gitbash, wsl and clipboard buffers, etc.
  - rlpb 5y ago
    My editor autodetects and preserves the line ending character sequence when I save. If I want to change it, I just need to change the setting. Doesn't yours? Why is this still an issue for you?
    - tyingq 5y ago
      Yes, there are a variety of ways to deal with it, though editor autodetect doesn't solve every issue I have with \r. One example is ":r! wl-paste" within vim. The carriage return is there, and if I join two lines, it ends up in the middle, where ":set ff unix" doesn't help me when I save.
compiler-guy 5y ago
The claim about how Kermit can be just as fast as it's contemporaries like zmodem if it is configured correctly is absolutely true. It's also a statement about the power of defaults. By the time you research out how to make kermit as fast as zmodem, you may as well have switched to zmodem which does it for you. Configuring it was easy (I did it myself plenty of times), but "switch to zmodem" is a much easier set of instructions.
joezydeco 5y ago
The bigger problem is Windows not supporting USB serial ports over 1MBaud. I've got a dozen embedded designs with SoCs that can go >3Mbit but since Windows users are my common denominator, I'm stuck at 1.
jhallenworld 5y ago
One thing about Kermit- it used to be the gold standard for CLI usability: editing, history, ESC-completion and context sensitive ?-help. I think it was directly inspired by the TOPS-20 operating system. For example, user types "?" after entering screen C-Kermit>screen ? screen action, one of the following: clear cleol move-to C-Kermit>screen _
ngcc_hk 5y ago
Can’t remember why but old day this is the only software that work. There are faster one like z modem, but not always work.
nas 5y ago
The major problem, IMHO, was the licensing of C-Kermit. Yes, if you used C-Kermit and set it up properly, it was as fast or faster than ZModem. However, ZModem had free implementations and was relatively ubiquitous. Columbia University was trying to use the license terms to extract enough money to maintain and improve C-Kermit. Compared with Zmodem or Ymodem, it wasn't a success. At least, that's how I remember things.
sliken 5y ago
I was a fan of kermit, especially once they added sliding windows for ACKs that allowed 99% of line speed instead of 33% or similar. Even just watching the modem lights you could see a huge difference. However their license meant you couldn't include the binary with a linux distro. The build system wasn't particularly user friendly, required much more than ./configure; make; make install. I ended up switching to qmodem (an app) with a zmodem plugin, minicom, and even occasionally screen (which supports serial to /dev/ttyUSB0 and the like). I believe they fixed the license, but the damage had already been done and seems like most used the distro provided tools.
mrlonglong 5y ago
I found kermit to be incredibly useful saving my stuff off the VMS running on the DEC VAX 8600 at university when I left. I still have the TLBs archived. Once I got a VAX emulator, I uploaded them and unpacked. Wonderful.

58 points by zdw 5y ago

I used C-Kermit back in my dialup terminal days. It was a well-kept secret, I guess, that a properly tuned Kermit was significantly faster than ZModem.

TomMasz 5y ago
Tuning was the key. Once you understood the protocol and the robustness of your connection, it was easy to configure Kermit to run fast.

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.

jandeboevrie 5y ago

Kermit is one of those utilities I use almost daily. In my case to script a connection sequence to a hardware device via serial. (Few timed keystrokes and a string of text). Ubuntu 20.04 removed Kermit, so I packaged it up as a snap to be able to use it again: https://raymii.org/s/blog/Ive_packaged_up_CKermit_as_a_snap_for_Ubuntu_20.04.html https://raymii.org/s/blog/Ive_packaged_up_CKermit_as_a_snap_...

mhdhn 5y ago

File transfer protocol and related software. Some links https://en.m.wikipedia.org/wiki/Kermit_(protocol) https://en.m.wikipedia.org/wiki/Kermit_(protocol) https://www.kermitproject.org/kermit.html https://www.kermitproject.org/kermit.html

voxadam 5y ago

Archive: https://web.archive.org/web/20220424041605/https://www.columbia.edu/kermit/misconceptions.html https://web.archive.org/web/20220424041605/https://www.colum...

Brian_K_White 5y ago

Back in the days of serial terminals I made a sweet single-floppy terminal, customized to support a sco xenix application, with nothing but a bootable dos floppy and ms-kermit, and it worked better and was simpler for the users than the procomm plus they had been using. It was all because of how scriptable and customable ms-kermit was. Not only I was able to make all the terminal emulation and keyboard keys work perfect, I even made the disk user self maintaining where the disk could copy itself, so they never had a problem with the disks wearing out in a dirty shop environment. And it was all dirt cheap and dead simple for the users and business owner to maintain unlike a proper network booting solution would have been at the time. The window of time where that articular awesomeness mattered was small, but it sure was awesome. It wasn't even doing any kermit file transfers, just acting as a swiss army knife of a scriptable configurable serial terminal running on essentially free 8088 and 8086's with no hd's, ram, or nics.

zabzonk 5y ago

Ah, this takes me back. I wrote implementations of the Kermit protocol for the Z80, 6502 (both in assembler) and the 8086 (mostly in C, but some assembler for the interrupt-driven I/O). It was a really nice and easy to implement protocol, and very sturdy - you could unplug the serial port connection and then re-plug it, and the file transfer would restart where it was interrupted. This would have been mid-1980s.

whoopdedo 5y ago

Although the page says it was updated in 2021 (to change some FTP links to HTTP) the tag at the bottom says 2011. Some of the noted advantages of Kermit I don't see as relevant for new systems. Character sets? I use UTF-8 for everything. Text mode files? I treat everything as binary. File permissions and directory trees? Tar preserves those and more. Besides, I've never wanted to save more than a timestamp when copying between different computers. But it still holds up for being text-driven. In a what-old-is-new-again way a lot of the world has moved back to CLI since this was written. And for the same reason, because text interfaces are easier to automate. That said, I don't think a GUI is inherently unscriptable. There have been macro and automation tools for windowing systems. I think it mostly the attitude of GUI design doesn't consider automation a priority while CLI does. (I'd even say it's nearly impossible to make a text interface that can't be automated.) A macro I create to control a GUI will become obsolete when the application designer decides to move the buttons around for purely aesthetic reasons. Breaking changes like that are rare in text applications.

tyingq 5y ago
>Text mode files? I treat everything as binary. This is still an issue today with Windows vs everything else. I regularly filter ^M out of source files. There's all sorts of hackery in tools like gitbash, wsl and clipboard buffers, etc.
- rlpb 5y ago
  My editor autodetects and preserves the line ending character sequence when I save. If I want to change it, I just need to change the setting. Doesn't yours? Why is this still an issue for you?
  - tyingq 5y ago
    Yes, there are a variety of ways to deal with it, though editor autodetect doesn't solve every issue I have with \r. One example is ":r! wl-paste" within vim. The carriage return is there, and if I join two lines, it ends up in the middle, where ":set ff unix" doesn't help me when I save.

compiler-guy 5y ago

The claim about how Kermit can be just as fast as it's contemporaries like zmodem if it is configured correctly is absolutely true. It's also a statement about the power of defaults. By the time you research out how to make kermit as fast as zmodem, you may as well have switched to zmodem which does it for you. Configuring it was easy (I did it myself plenty of times), but "switch to zmodem" is a much easier set of instructions.

joezydeco 5y ago

The bigger problem is Windows not supporting USB serial ports over 1MBaud. I've got a dozen embedded designs with SoCs that can go >3Mbit but since Windows users are my common denominator, I'm stuck at 1.

jhallenworld 5y ago

One thing about Kermit- it used to be the gold standard for CLI usability: editing, history, ESC-completion and context sensitive ?-help. I think it was directly inspired by the TOPS-20 operating system. For example, user types "?" after entering screen C-Kermit>screen ? screen action, one of the following: clear cleol move-to C-Kermit>screen _

ngcc_hk 5y ago

Can’t remember why but old day this is the only software that work. There are faster one like z modem, but not always work.

nas 5y ago

The major problem, IMHO, was the licensing of C-Kermit. Yes, if you used C-Kermit and set it up properly, it was as fast or faster than ZModem. However, ZModem had free implementations and was relatively ubiquitous. Columbia University was trying to use the license terms to extract enough money to maintain and improve C-Kermit. Compared with Zmodem or Ymodem, it wasn't a success. At least, that's how I remember things.

sliken 5y ago

I was a fan of kermit, especially once they added sliding windows for ACKs that allowed 99% of line speed instead of 33% or similar. Even just watching the modem lights you could see a huge difference. However their license meant you couldn't include the binary with a linux distro. The build system wasn't particularly user friendly, required much more than ./configure; make; make install. I ended up switching to qmodem (an app) with a zmodem plugin, minicom, and even occasionally screen (which supports serial to /dev/ttyUSB0 and the like). I believe they fixed the license, but the damage had already been done and seems like most used the distro provided tools.

mrlonglong 5y ago

I found kermit to be incredibly useful saving my stuff off the VMS running on the DEC VAX 8600 at university when I left. I still have the TLBs archived. Once I got a VAX emulator, I uploaded them and unpacked. Wonderful.