Kermit – Misconceptions and Controversies (2021)
columbia.edu
columbia.edu
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_...
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.
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.
This would have been mid-1980s.
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.
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.
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.
Ironically the 'About' link 404s.
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.
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.
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.
For example, user types "?" after entering screen
C-Kermit>screen ? screen action, one of the following:
clear cleol move-to
C-Kermit>screen _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.
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.