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 this platform or that one? Does it have this feature or that feature? No, what about this other one? Is it HP-UX maybe? HP-UX 6? No, 7? No, 8? No, what about VMS? No, how about SunOS? No, how about Unix System III?" ...on and on, seemingly endlessly.
Kermit was an extraordinary monument to portability in an era when "portable" often meant "we have individually accommodated every incompatible system anyone has ever built or might possibly still be using, however improbably."
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
There was for a brief period a Middle Path, called libiberty (now mostly subsumed into gnulib). It generated GNU-compatible shim functions for whatever system you happened to be on that translated those calls into the native calls. So you wrote one clean GNU-esque codebase and gnulib patched together essentially a translation layer for it when you built.
That was one ethos that was taught at the UC Davis CS program in the 90's-00's. They had clusters of IRIX, Linux, Sun, HP-UX, and (sometimes) MINIX boxes. Homework and lab projects would be nondeterministically graded on any except MINIX. It was also beneficial to add portability for Windows with MS and/or Borland toolchains for some projects. BSD sockets was pretty cross-platform with some idiosyncratic gotchas per platform.
It saddens me whenever someone or a group religiously tie their opinions or assumptions to a particular platform and irrationally scoff at others or refuse to consider that other things exist, are used, and function.
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 network that let you dial in and connect to machines on various college campuses. The network ran on some IBM minicomputer. And, it didn't connect to the Unix machine, oh no. It connected to a VAX, which was then on the same local network as the Unix machine.
So I had to dial in to the IBM machine, connect from it to a VAX, and then telnet from the VAX to the Unix box.
Incredibly, this all worked with only mildly annoying lag...but then I tried to transfer a file from the Unix machine to my personal machine. ZMODEM didn't work. XMODEM didn't work. I think I tried one or two other things that I've forgotten.
Then I remembered Kermit, and its reputation for being able to handle difficult connections. It got the file through on its first try.
Exactly my experience, the faster file transfer programs failed me on the crappy dialups of the day… but Kermit came to the rescue. As I recall it gave you a running tally of retries and all that.
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.
I found it essential for the same reasons, in those early Internet days... PAD, -> UNIX host (x.25), -> VMS "mainframe" (dual stack), on to Internet (TCP/IP).
Trumpet Winsock in PPP mode, or SLIP ATTACH or invoking a SLIP server daemon upon login, worked with UCF/UF library VAX systems back then. Just needed to use CTRL-C to break out of their login scripts and get a prompt.
Bill Catchings (the undergrad who helped Frank da Cruz with the original spec and coding) still blogs. It has been a while since he spoke specifically about kermit, but he has one or two interesting posts about the 40th anniversary of Kermit.
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.
The Kermit Software Source Code Archive is such a treasure trove of software for obscure systems
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
I honestly don't remember. It took me a moment to even get back to TPL, a variation on RATFOR. I don't remember anything about the BYU conversion. That must have happened after I left CV.
I am a gray beard and still use Kermit regularly for embedded development. It’s very handy for automating things over a serial port console. I wonder how much adoption it sees with the younger crowd.
I remember back in the day Kermit was pretty heavyweight. We used sz/rz for file transfer [z-modem: good to see the man pages are still up! https://linux.die.net/man/1/sz]. Is there a reason to prefer Kermit?
Kermit as a file transfer protocol, in the more modern implementations at least, supports 4K and 9K blocks, streaming mode (no need for ACKs), sliding windows, etc. As a protocol, it also has an OS-agnostic way to do file management; you can send commands like delete, rename, copy, etc. and the remote end does it in a general way. It's like SFTP, only a few decades earlier.
Kermit initially competed with xmodem which was very primitive (but a lot smaller/simpler).
By the time zmodem became popular, the biggest remaining selling point of Kermit was the built-in scripting. Not much use for one-off BBS-style transfers, but very handy for keeping a directory in sync etc.
I used Telix under IBM PC-DOS for scripting. The SLT scripts were as versatile as Expect or Tcl in that day.
I used MS-Kermit as a terminal emulator on the same system. I was accessing academic Unix systems and probably also remote access at my first job. MS-Kermit had a keycode translation capability that I used extensively.
My 2400/MNP5 modem sometimes only had a 7-bit connection. Without being 8-bit clean, I couldn’t directly use the Meta key with GNU Emacs. But sometimes I did achieve an 8-N-1 clean connection in the same modem pool!
So I wrote up two large tables for MS-Kermit: one for the 7-bit connection that would send ESC to simulate Meta for Emacs. And one for 8-bit-clean operation that used ALT as Meta and sent the ASCII code >=128.
I eventually submitted them to the GNU Emacs project and one was distributed with Emacs 18. Eventually, they were forced to remove it during a copyright/license cleanup audit. But it was my claim to 15 minutes of fame.
Can you elaborate more on how you use it or do you recommend any codebase to learn more?
I remember evaluating Kermit and ymodem for my embedded work too, but didn't end up using them. Maybe I didn't understand Kermit fully. I wanted something to connect over serial (usb cdc and ble) via the browser and manage files and the state of the device.
I always end up writing something worse and half-baked in the end..
Why wasn’t Kermit used by BBSes? Even at the time I remember having read about it in computer magazines, but I got my first modem in ‘82 or so and I don’t recall ever seeing it in the wild. My first actual contact with it was uploading firmware I wrote to an embedded controller. But the thing it was actually designed for? Not even once.
So… why? We didn’t collectively settle on YMODEM and ZMODEM until many years later. There were lots of early protocols to choose from back then, too. Punter, anyone? No Kermit, though.
Kermit had licensing issues in those days. And many bbs were focused on one specific system so many of the auto translate and nice compatibility features of Kermit weren’t that important.
And finally Kermit didn’t have great defaults especially compared to ymodem and zmodem. So getting good performance out of Kermit was much harder than the others.
All of that added up to much lower adoption outside of the mainframe world.
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's some discussion of it here: https://www.kermitproject.org/misconceptions.html#notslow
It did fine iff you had a good Kermit implementation at the BBS. Most used the most basic possible version of the protocol, which was godawfully slow, but I did some dialup at the end of the BBS era (93-95) where someone showed me how to use Kermit properly with large packets and sliding windows. It was every bit as fast as Zmodem, though I don’t recall if it supported transfer resuming.
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).
A good example of the defaults being incredibly important to any application. If your defaults are super slow then most people are going to come away with the impression that your application is slow.
FTP is another great example where people got the impression that it was prone to corrupting transfers because the default setting was to corrupt binary transfers.
One cool feature is that you can use C-Kermit to do inline file transfers over the open SSH session. It doesn't work over a terminal muxer like screen/tmux, but it is pretty useful for a quick way to transfer files between the client and the remote host.
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.
Ages a ago I used it on Coherent OS via dial up to sign into a Sun Server at work that I used for USENET and general internet access. When I dialed in the server would hang up and call be back so I would avoid Long Distance Charges. ckermit handled that itself, fun times.
I purchased the book to help with the project, I should go and dig it out :)
It (or rather, they, as there are a number of Kermit books) is pretty good. I've got a few on my bookshelf. OK, I'll admit, more Kermit and UUCP books than I probably need, but oh well. The Kermit books are mostly available online now also: https://www.kermitproject.org/booksonline.html
Nowadays, Henson Associates wouldn't sue a 45 year old file transfer protocol over it, either; their rights to a name would generally not be universal to that degree, as long as it doesn't proliferate into a collection of software named after individual muppets. The letter of "sure that's fine" saves them legal fees each decade someone discovers it and I assume also exempts this single case from counting as trademark dilution.
I had an Apple 2+ back in 1992. It was an old computer, even then.
The Apple 2+ only supported displaying capital letters.
I remember calling a few local BBSes using terminal software that let me press the right arrow (I think) and the character key, and it would display the character inverted (white background, black letter).
Hayes 1200 baud serial modem (I think) hooked up to a serial card.
Have you not been on the internet much lately? As the sibling comment pointed out, it’s Anubis, which shows up on a lot of websites of FOSS devs (and which has been discussed endlessly on HN).
Even though the price of RAM has gone up recently, it's still (even if you don't adjust for inflation) several orders of magnitude cheaper than it was in 1981...
I suppose that's one way to measure, but would a "real world measure" i.e. cost of the amount of ram to realistically run the apps/software/OS of the time be more relevant?
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 this platform or that one? Does it have this feature or that feature? No, what about this other one? Is it HP-UX maybe? HP-UX 6? No, 7? No, 8? No, what about VMS? No, how about SunOS? No, how about Unix System III?" ...on and on, seemingly endlessly.
Kermit was an extraordinary monument to portability in an era when "portable" often meant "we have individually accommodated every incompatible system anyone has ever built or might possibly still be using, however improbably."
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
There was for a brief period a Middle Path, called libiberty (now mostly subsumed into gnulib). It generated GNU-compatible shim functions for whatever system you happened to be on that translated those calls into the native calls. So you wrote one clean GNU-esque codebase and gnulib patched together essentially a translation layer for it when you built.
Autotools on little endian Linux is the biggest waste of CPU time imaginable.
Once upon a midnight dreary, while
I compiled, weak and weary,
Over many a quaint and curious
emerge of GNU more—
While I nodded, nearly napping,
suddenly there came a tapping,
As of someone gently rapping, rapping at my chamber door.
“’Tis just automake,” I muttered, “gently checking CPU floor—
Only this, and nothing more.”
“Automake!” said I, “thing of evil!—automake still, if GNU or devil!—
Whether Linus sent, or whether Stallman tossed thee here ashore,
Desolate yet all undaunted, on this desert land enchanted—
On this home by horror haunted—tell me truly, I implore—
Is there—is there caching in Gentoo?—tell me—tell me, I implore!”
Quoth automake, “Nevermore.”
It would be nice if automake remembered your system in a cache.
Ah.. yup.
That was one ethos that was taught at the UC Davis CS program in the 90's-00's. They had clusters of IRIX, Linux, Sun, HP-UX, and (sometimes) MINIX boxes. Homework and lab projects would be nondeterministically graded on any except MINIX. It was also beneficial to add portability for Windows with MS and/or Borland toolchains for some projects. BSD sockets was pretty cross-platform with some idiosyncratic gotchas per platform.
It saddens me whenever someone or a group religiously tie their opinions or assumptions to a particular platform and irrationally scoff at others or refuse to consider that other things exist, are used, and function.
Agreed, specially those that talk about Linux distros when they actually mean UNIX/POSIX.
Today’s version would be to grade shell script homework randomly on either Linux or macOS :)
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 network that let you dial in and connect to machines on various college campuses. The network ran on some IBM minicomputer. And, it didn't connect to the Unix machine, oh no. It connected to a VAX, which was then on the same local network as the Unix machine.
So I had to dial in to the IBM machine, connect from it to a VAX, and then telnet from the VAX to the Unix box.
Incredibly, this all worked with only mildly annoying lag...but then I tried to transfer a file from the Unix machine to my personal machine. ZMODEM didn't work. XMODEM didn't work. I think I tried one or two other things that I've forgotten.
Then I remembered Kermit, and its reputation for being able to handle difficult connections. It got the file through on its first try.
Exactly my experience, the faster file transfer programs failed me on the crappy dialups of the day… but Kermit came to the rescue. As I recall it gave you a running tally of retries and all that.
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.
I found it essential for the same reasons, in those early Internet days... PAD, -> UNIX host (x.25), -> VMS "mainframe" (dual stack), on to Internet (TCP/IP).
Trumpet Winsock in PPP mode, or SLIP ATTACH or invoking a SLIP server daemon upon login, worked with UCF/UF library VAX systems back then. Just needed to use CTRL-C to break out of their login scripts and get a prompt.
Bill Catchings (the undergrad who helped Frank da Cruz with the original spec and coding) still blogs. It has been a while since he spoke specifically about kermit, but he has one or two interesting posts about the 40th anniversary of Kermit.
https://www.billcatchings.com/2012/04/frog-from-my-past.html https://www.billcatchings.com/2013/11/kermit-oral-history-pa...
and here is a link to the oral history he discusses:
https://www.computerhistory.org/collections/catalog/10274641...
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.
The Kermit Software Source Code Archive is such a treasure trove of software for obscure systems
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
I honestly don't remember. It took me a moment to even get back to TPL, a variation on RATFOR. I don't remember anything about the BYU conversion. That must have happened after I left CV.
I am a gray beard and still use Kermit regularly for embedded development. It’s very handy for automating things over a serial port console. I wonder how much adoption it sees with the younger crowd.
I remember back in the day Kermit was pretty heavyweight. We used sz/rz for file transfer [z-modem: good to see the man pages are still up! https://linux.die.net/man/1/sz]. Is there a reason to prefer Kermit?
Kermit as a file transfer protocol, in the more modern implementations at least, supports 4K and 9K blocks, streaming mode (no need for ACKs), sliding windows, etc. As a protocol, it also has an OS-agnostic way to do file management; you can send commands like delete, rename, copy, etc. and the remote end does it in a general way. It's like SFTP, only a few decades earlier.
In modern times, I use it as a powerful ssh wrapper and BBS client. Its character-set translation is ideal for CP437 to UTF8. See https://www.openkermit.org/ckermit/ssh/ and https://www.openkermit.org/ckermit/bbs/
Kermit initially competed with xmodem which was very primitive (but a lot smaller/simpler).
By the time zmodem became popular, the biggest remaining selling point of Kermit was the built-in scripting. Not much use for one-off BBS-style transfers, but very handy for keeping a directory in sync etc.
I used Telix under IBM PC-DOS for scripting. The SLT scripts were as versatile as Expect or Tcl in that day.
I used MS-Kermit as a terminal emulator on the same system. I was accessing academic Unix systems and probably also remote access at my first job. MS-Kermit had a keycode translation capability that I used extensively.
My 2400/MNP5 modem sometimes only had a 7-bit connection. Without being 8-bit clean, I couldn’t directly use the Meta key with GNU Emacs. But sometimes I did achieve an 8-N-1 clean connection in the same modem pool!
So I wrote up two large tables for MS-Kermit: one for the 7-bit connection that would send ESC to simulate Meta for Emacs. And one for 8-bit-clean operation that used ALT as Meta and sent the ASCII code >=128.
I eventually submitted them to the GNU Emacs project and one was distributed with Emacs 18. Eventually, they were forced to remove it during a copyright/license cleanup audit. But it was my claim to 15 minutes of fame.
Can you elaborate more on how you use it or do you recommend any codebase to learn more?
I remember evaluating Kermit and ymodem for my embedded work too, but didn't end up using them. Maybe I didn't understand Kermit fully. I wanted something to connect over serial (usb cdc and ble) via the browser and manage files and the state of the device.
I always end up writing something worse and half-baked in the end..
Why wasn’t Kermit used by BBSes? Even at the time I remember having read about it in computer magazines, but I got my first modem in ‘82 or so and I don’t recall ever seeing it in the wild. My first actual contact with it was uploading firmware I wrote to an embedded controller. But the thing it was actually designed for? Not even once.
So… why? We didn’t collectively settle on YMODEM and ZMODEM until many years later. There were lots of early protocols to choose from back then, too. Punter, anyone? No Kermit, though.
Kermit had licensing issues in those days. And many bbs were focused on one specific system so many of the auto translate and nice compatibility features of Kermit weren’t that important.
And finally Kermit didn’t have great defaults especially compared to ymodem and zmodem. So getting good performance out of Kermit was much harder than the others.
All of that added up to much lower adoption outside of the mainframe world.
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's some discussion of it here: https://www.kermitproject.org/misconceptions.html#notslow
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.
It did fine iff you had a good Kermit implementation at the BBS. Most used the most basic possible version of the protocol, which was godawfully slow, but I did some dialup at the end of the BBS era (93-95) where someone showed me how to use Kermit properly with large packets and sliding windows. It was every bit as fast as Zmodem, though I don’t recall if it supported transfer resuming.
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).
A good example of the defaults being incredibly important to any application. If your defaults are super slow then most people are going to come away with the impression that your application is slow.
FTP is another great example where people got the impression that it was prone to corrupting transfers because the default setting was to corrupt binary transfers.
Same. I was very active in BBSing in the late 80's through the mid 90's. Kermit was the protocol of last resort.
GOO. I remember Punter well.
One cool feature is that you can use C-Kermit to do inline file transfers over the open SSH session. It doesn't work over a terminal muxer like screen/tmux, but it is pretty useful for a quick way to transfer files between the client and the remote host.
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.
TIL that the original Kermit (after which this tool was presumably named?) is already more than 70 years old: https://en.wikipedia.org/wiki/Kermit_the_Frog
Nice and congratulations
Ages a ago I used it on Coherent OS via dial up to sign into a Sun Server at work that I used for USENET and general internet access. When I dialed in the server would hang up and call be back so I would avoid Long Distance Charges. ckermit handled that itself, fun times.
I purchased the book to help with the project, I should go and dig it out :)
It (or rather, they, as there are a number of Kermit books) is pretty good. I've got a few on my bookshelf. OK, I'll admit, more Kermit and UUCP books than I probably need, but oh well. The Kermit books are mostly available online now also: https://www.kermitproject.org/booksonline.html
"the name Kermit is used by permission of Henson Associates, Inc."
that certainly would never happen nowadays.
Nowadays, Henson Associates wouldn't sue a 45 year old file transfer protocol over it, either; their rights to a name would generally not be universal to that degree, as long as it doesn't proliferate into a collection of software named after individual muppets. The letter of "sure that's fine" saves them legal fees each decade someone discovers it and I assume also exempts this single case from counting as trademark dilution.
C-Kermit? I (barely) remember tinkering with the FORTH version on a Epson HX20 (late in its life) anno 1995. The sources seem to originate (today) at https://atariwiki.org/wiki/Wiki.jsp?page=Kermit%20Protocol%2...
I'm amazed to see that Kermit is still alive and kicking. Thank you, team!
I had an Apple 2+ back in 1992. It was an old computer, even then.
The Apple 2+ only supported displaying capital letters.
I remember calling a few local BBSes using terminal software that let me press the right arrow (I think) and the character key, and it would display the character inverted (white background, black letter).
Hayes 1200 baud serial modem (I think) hooked up to a serial card.
That's how I knew I was sending a capital letter.
Not sure if it was Kermit though..
I used Kermit in many projects when I was younger, including synchronising data from remote branches of a Pool equipment company using dial-up modems.
Those were the days lol.
ok but what's the anime 'checking if you're not a bot' gatekeeper? asking for a friend...
Anubis.
https://hn.algolia.com/?q=anubis
Have you not been on the internet much lately? As the sibling comment pointed out, it’s Anubis, which shows up on a lot of websites of FOSS devs (and which has been discussed endlessly on HN).
Yeah. It's pretty unprofessional.
The site is a personal blog. There's no expectation, explicit or implicit, that it be "professional".
"1981 was a different time for computing. It was expensive (both hardware and software)"
doesn't sound so different anymore...the VCs have managed to go back to the future...
Even though the price of RAM has gone up recently, it's still (even if you don't adjust for inflation) several orders of magnitude cheaper than it was in 1981...
This graph (https://ourworldindata.org/grapher/historical-cost-of-comput...) doesn't contain the latest uptick, but just to get the picture:
1981: 1 TB of memory cost 12.8 billion $ (at least theoretically - I'm not sure if worldwide RAM production for that year was more than 1 TB?)
2023: 1 TB of memory cost 1088 $
I suppose that's one way to measure, but would a "real world measure" i.e. cost of the amount of ram to realistically run the apps/software/OS of the time be more relevant?
So if 32GB of RAM used to cost $400 million and now costs $250, is that better?