The Kermit Project
Now hosted by
New York City USA • firstname.lastname@example.org
Frank da Cruz
29 April 2021
I was the manager of the DEC-20s and Bill's boss, and I had outlined what was needed: a file-transfer protocol following the ISO OSI layered model that could work for the widest possible variety computers and operating systems including our own DEC-20 mainframes, our IBM mainframes, and the " Superbrain" CP/M microcomputer we were about to place in a public terminal room so users could download their mainframe files onto floppy diskettes (so strictly speaking the first real Kermit transfer, i.e. between two computers, took place a few weeks later between the DEC-20 and the Superbrain). Why were we doing all this? It's explained here.
The Kermit protocol had to be platform independent and super-robust to allow error-free transfer of both binary files and text files between any two kinds of computers, even on bad or restricted data connections. And it had to use a well-defined common intermediate representation for text files "on the wire" so no Kermit program would have to know the details of any other Kermit's file system, record format, or character encoding (e.g. ASCII vs EBCDIC). To these requirements, Bill added the proviso that protocol had to be extensible and "made it so".
Bill worked out the details of the basic protocol and wrote the first two implementations; one for the DEC-20 and one for CP/M. A few months later the IBM PC was announced and Bill adapted his CP/M version to PC-DOS and turned it over to another programmer in our group, Daphne Tzoar. Meanwhile the IBM mainframe version was written for VM/CMS by Vace Kundakci of our IBM systems group. Soon, we also had a bare-bones 4.2BSD Unix version from our Computer Science Department.
We contributed these programs to user groups like DECUS (DEC) and SHARE (IBM), and before long Kermit software was in use at universities, companies, and government agencies all over the world, which began to send us Kermit programs they had written for other platforms: PDP-11/RSX, VAX/VMS, various other mainframe OS's (Burroughs, CDC, Cray, Honeywell, Sperry/Univac...), variations on CP/M Kermit for different incompatible micros; variations on PC Kermit for incompatible DOS PCs. Meanwhile we wrote an all-new full-function C-Kermit program for Unix and Macintosh Kermit for the brand-new Mac, based on C-Kermit. In 1985 Bill left Columbia and I took over Kermit protocol and software development myself and stuck with it for 27 years.
The Kermit Project thrived for about 30 years as a Columbia department within the Computer Center, distributing Kermit software — at first on magnetic tape, later over BITNET, and finally on the Internet — and producing the highly-successful Kermit 95 software for Windows and releasing new and more powerful versions of it for another eight years until our Windows and security programmer, Jeffrey Altman, was laid off in 2003, along with our last "Kermite", Max Evarts. Then Christine Gianone, Kermit Project writer and business manager since 1987, was laid off in 2005.
The Kermit Project at Columbia University was canceled in 2011 and I (the last remaining member) was laid off that same year. Since then I've been working on C-Kermit from time to time at its new home but without any urgency because as far as I know, hardly anybody uses it any more... Except me!
In brief: I spend all my online time connected via SSH from Kermit 95 to a Unix host for web authoring, transferring files (mostly images) back and forth in the same session via Kermit protocol.I spent my final months at work releasing C-Kermit 9.0 (the first Open Source release), changing other Kermit software licenses to Open Source, sending stuff to the Columbia Archive and the Computer History Museum, opening the new post-Columbia Open-Source Kermit Project website, and then moving to the Bronx. After that I didn't hear much about Kermit (even though I still had the same email address), so I worked on other projects, such as these:
Kermit 95* as a terminal emulator ssh'd into shell sessions on the remote Web servers, one of which is NetBSD and the other Red Hat Enterprise Linux. I do all my "web authoring" on these remote systems using the GNU EMACS text editor. I create the web pages from scratch by typing in the text and the HTML markup on the best keyboard ever made, the UNICOMP Linux keyboard, which is almost exactly like the IBM PC/AT keyboard, the same heft and feel and clickiness, and the keys are in the right place... In particular the Esc and Ctrl keys are in easy reach of touch typists who might need to use them often. I type at 120 words per minute and I'm pounding away on this thing for more hours per day than I care to admit! And the keyboard is at 10 or 15 years old; it's a tank!
To take full advantage of EMACS's seemingly limitless capabilities, a good terminal emulator is essential, and Kermit 95 (in my opinion) is the best there is; I use its VT220 emulator (I used to use VT320 but Unix hosts forgot about VT320 decades ago). K95 is much better than a real VT220 because (for example) it can handle Unicode UTF8 so I can freely mix text in different languages (e.g. English, Spanish, German, Russian, and if I needed to, even Arabic, Yiddish, Hindi, Inuit, or any other language). To see an example of this, visit this page and look at the list of languages just under the flags at the top; that page was created in exactly the manner described here**, except of course some of the language names were copied and pasted into the terminal session because I don't have any way of typing Hindi or Traditional Chinese!
The history websites demand enormous amounts of research. For the computer history site, where big sections focus on the era from 1890 to (say) 1950, old photos must be downloaded from wherever I can find them on Web; others I might scan myself from old books and manuals or from physical photos found in library archives or private collections, and still others are screen shots taken from old movies. For the New Deal site, I go out and take photos myself.
In all these cases, the images wind up on my PC. Usually I crop, resize, and/or enhance them in Photoshop on the PC. Then I upload them to the web server with Kermit. I don't have to switch to some other application to transfer the files; I don't have to make a new connection or re-authenticate myself. I do it in the same session I'm already using to access the Web server and create the HTML files. How do I do this? C-Kermit is installed on the Web server. I have a shell script there, "g" (for "get"), so I can type (say) "g ibm650.jpg" at the shell prompt and poof, the ibm650.jpg file is uploaded to the server without me ever having to leave the Unix shell, no escaping back or anything like that. Here's the "g" script:
The command-line option "g" means "get", and "w" means "write over any existing file of the same name", which is normally what I want to do. "$1" is the filename. Or list of filenames/wildcards to transfer multiple files in the same operation without having to worry about text mode versus binary mode because Kermit takes care of that automatically, so text files that go between (say) Unix and Windows have their record formats converted automatically, whereas photos are sent without conversions. Here's an example of a page I made using the method just described, showing card punch machines from 1890 to the 1930s, with text and images interwoven: C-Kermit executing a program called Photogallery written in C-Kermit's built-in scripting language (see the code here). Why did I write this program in Kermit language instead of (say) C? Because a program written in the Kermit language will "stay written" as new versions of Kermit are released, whereas programs written in C are guaranteed to break as C itself changes — or its libraries do (notably glibc) — and have to be constantly "upgraded" to "comply" with the "new standard". So every time I need to write a program to make my website work easier, I write it in C-Kermit.#!/bin/bash kermit -wg "$1" || exit chmod 644 $1 || exit ls -l $1* exit
Bottom line: if you spend a lot of time on a PC creating and maintaining websites on Unix-based servers, while doing your image processing on the PC, AND you're a fast typer, Kermit might well be the ideal tool. While interacting with the Unix host you can do practically everything — including uploading images — on your keyboard without constantly having to reach for the mouse.
The same applies to a somewhat lesser degree if you have a Linux or Mac OSX workstation on your desk. In that case you would use C-Kermit on your desktop computer in a shell session to make a connection to the Web server; everything else is the same except that the terminal emulation is done by computer's terminal program, through which you access the shell. And that you would have to use something like GIMP rather than Photoshop for image processing.
|*||Kermit 95 is no longer sold by any of the companies that used to sell it, like Manning Software, E-Academy, or OnTheHub. You might be able to find it at Amazon or Ebay. If all else fails, contact me and I'll see what I can do. Even though the last release was in 2003, it still works just fine in Windows 10 (and all previous Windows versions back to Windows 95) if you follow the instructions in the FAQ.|
|**||Entering text in different writing systems from an English keyboard requires a compose key or a keymap. I have my K95 compose key set to Ctrl-apostrophe, after which the next two keys "compose" the desired character, e.g. 'c' and then comma for 'ç' (c-cedilla); thus it is possible to touch-type in German or Spanish or other "Latin-1" language without your fingers ever leaving the home keys. To type text in Russian, which uses a different alphabet, I use this keymap.|