Kermit - Misconceptions and Controversies
Kermit protocol originally was designed to operate under the worst conditions, and its robust default tuning was at the expense of speed. Thus there has been a widespread misconception that Kermit is a slow protocol, despite the fact that its performance extensions (long packets, sliding windows) were designed, documented, and implemented by the mid-to-late 80s, and additional ones (control-character "unprefixing", locking shifts, streaming) in the 1990s.
The misconception is bolstered by the fact that most Kermit implementations that do not come from the Kermit Project are, indeed, quite slow since they implement only the barest minimum (robust) subset of the protocol. Unfortunately, Kermit protocol itself is often judged by such implementations, as, for example in:
or in well-known communications software such as Windows HyperTerminal. To illustrate, here are measurements of file-transfer throughput for Kermit 95 1.1.20 and HyperTerminal on the same Windows 95 PC, using the same built-in 56K Winmodem for a connection to the same host at the same phone number, with a serial port speed of 115200 BPS, transferring a (precompressed) ZIP file 108K in length with Kermit protocol:
HyperTerminal Kermit 95 Upload 227 CPS = 7.9 Minutes 2831 CPS = 36 Seconds Download 358 CPS = 5.0 Minutes 5121 CPS = 21 Seconds
In both cases, C-Kermit 7.0 is on the other end, with all its default settings (the higher download speeds are a feature of 56K modem technology). Small wonder that people whose only experience with Kermit protocol is through products like HyperTerminal think Kermit is slow.
Kermit's reputation also suffered from:
- Statements found in modem manuals, usually in the "file transfer protocols" section or the glossary, such as this one: "Kermit - An asynchronous file transfer protocol used mostly with mainframe computers. It is very slow and should not be used when faster options such as ZMODEM are available" (3Com / US Robotics 56K XJ Modem User Guide, 1997, and also most other USR manuals). Or: "If you are using a slow transfer protocol, such as Xmodem or Kermit, try Zmodem or Ymodem/G instead" (Multitech Z-Multimodem MT5634ZPC-PCI Internal Data/Fax Modem Owners Manual, 1998).
- Statements found in software manuals like this one in the Microsoft Press Windows 98 Resource Kit, Chapter 21: Modems and Communications Tools, page 1020, "Using HyperTerminal - File Transfer Protocols": "Kermit: An extremely flexible protocol, found most often on Digital Equipment Corporation (DEC) VAX computers, IBM mainframes, and other minicomputers. However, Kermit is quite slow and should not be used if faster options are available on the other computer."
- Entries in popular computer and telecommunications reference books, such as Newton's Telecom Dictionary (Flatiron Publishing, 12th Edition and earlier; the 13th edition, January 1998, came with an updated and more accurate Kermit entry).
- Statements in the popular press based upon these misconceptions. See, for example, the November 1998 Mobile Computing review of Kermit 95.
In fact, Kermit protocol can be just as fast or faster than other popular protocols on any given connection, while retaining its superior error recovery and data conversion characteristics, as demonstrated in the 1993 Kermit Project benchmarks from Kermit News #5* (click graph at left). For more about performance, see:
How Efficient Is Kermit?, Kermit News #4; Chapter 12 of Using C-Kermit, 2nd Edition.
Beginning in early 2000, the major Kermit software releases (Kermit 95,
C-Kermit, MS-DOS Kermit) implement a new "streaming" form of the Kermit
protocol that is negotiated automatically on reliable connections, such as
Telnet or SSH; in this case file-transfer speeds are about the same as FTP,
and sometimes faster since Kermit adds compression.
__________________
| * | There was a lot of controversy — "flame wars" as they were called in those days — when these benchmarks were published. But the benchmarks are reasonably accurate. The conditions and details were clearly stated, the tests were run and re-run, the results checked and rechecked. However the measuring tools available at the time were accurate only to the second, which could skew results for short files at high communication speeds rather dramatically one way or the other, depending on the direction of rounding. Whatever the merit of the arguments on each side, the point was to show that Kermit was not an inherently "slow" protocol "that should not be used" as almost everyone believed at the time for the reasons listed above. |
"Kermit Is a Relic of a Bygone Era".
Since Web browsers have largely replaced terminal emulators among mass-market end users for online connections, many people believe that Kermit software is no longer used. It's true that it's no longer a top desktop software choice in the mass market as it was in the 1980-1995 timeframe, but its popularity has grown in technical and commercial areas, especially among computer professionals within organizations where diverse platforms and communication methods are used for demanding tasks such as network management, alpha and numeric paging, software distribution and patching, remote troubleshooting, setting up automated data transfer procedures, EDI, mobile applications, automated configuration of PBXs, routers, hubs, and terminal servers, and so forth, and as the bundled communications piece in numerous products including barcode readers, postal sorters, operating-room anesthesia monitors, fast-food cash registers, blood analyzers, scientific instruments, networking equipment, program-driven milling and die-cutting machines, healthcare management systems, medical and pharmaceutical claim submission packages, inventory control systems, and car and auto-parts dealership packages.
The software is fast, robust, flexible, and stable (an almost forgotten concept) and the scripting language is powerful and easy to learn. Scripts are portable across platforms and communication methods. Even in a TCP/IP-only setting, modern Kermit software has distinct advantages:
- Unlike normal FTP, Telnet, Rlogin, and SSH clients, Kermit is innately scriptable.
- It can convert between character sets.
- It can transfer a mixture of text and binary files in a single batch.
- It can preserve file attributes such as dates and permissions.
- It can transfer directory trees, even between unlike file systems (e.g. Unix, VMS, Windows).
- It can act as a network service itself*.
- It supports several secure authentication methods.
- It can encrypt securely authenticated sessions.
Of course FTP is everywhere**. Wouldn't it be great if all the
features of Kermit — scriptability, automatic text/binary mode switching,
recursion, recovery, character-set conversion, etc — were available in an
FTP client? They have been since 2001 — CLICK HERE to see.
__________________
| * | The Internet Kermit Service, described in Internet RFCs 2839 and 2840, offers a flexible, high-function alternative to FTP service for Unix (most varieties: Linux, Mac OS X, Solaris, FreeBSD, AIX, HP-UX, etc) and Windows NT/2000/XP/Vista/7. |
| ** | Well it was everywhere. Although secure versions of FTP have been available for a very long time, they have been retired in most places in favor of SFTP and SCP, which are less secure and less functional. But that's another story. |
"Kermit is only for serial ports and modems".
See the Kermit timeline. In September 1991, MS-DOS Kermit 3.11 was released with its own built-in TCP/IP stack and Telnet protocol. In 1992, C-Kermit for Unix, VMS, AOS/VS, and other operating systems was released with TCP/IP support and a built-in Telnet client. In 1995, Kermit 95 was released with TCP/IP support and a built-in Telnet client. In 1998, C-Kermit and Kermit 95 were released with Kerberos IV, Kerberos V, and SSL/TLS security. In 2000, an advanced and super-functional FTP client was added to C-Kermit. In 2002 Kermit 95 had a built-in SSH V1/V2 client and C-Kermit could make SSH conections using the external Unix ssh program. In the same year the Kermit Project obtained a government license for export of K95 software with strong cryptography. Since 1991, then, network-capable Kermit clients have offered a fast and convenient combination of terminal emulation and file transfer on the Internet, that works the same way as on a serial or modem connection. Even before that, certain Kermit programs worked over various proporietary networks such as DECnet, LAT, NETBIOS, STARLAN, etc, as well as pre-Internet ISO standard networking methods such as X.25.
"Nobody uses serial ports or modems any more".
Just as most of today's "ordinary end users" no longer rely on Kermit software for connecting their desktops with the outside world, neither do they make much use of serial ports or modems or, for matter, even know what they are. That's not quite the same as saying nobody uses them any more. Exceptions include:
- The hurricane researchers who are deploying data collection buoys in the paths of big hurricanes. There's not a lot of Internet in the middle of the ocean. Similarly (in another project we were involved in a while back), placing calls from water monitoring stations all over the wilderness of Canada to home base periodically to upload their data or receive instructions or updates.
- The banks that prefer to use modems for funds transfers because they are simply more secure than the Internet. Ditto for medical insurance claim submission and, still in many cases, the charging of credit cards.
- The network managers and sysadmins for whom serial ports are the access of last resort when some server or RAID box or router or switch is malfunctioning, and for paging the on-call staff when the network can't be used.
__________________
| * | See announcement of MS-DOS Kermit 3.11 in the Info-Kermit Digest of 16 September 1991, and of C-Kermit 5A, 23 November 1992, in the same archive, which is the complete Info-Kermit Digest from 1983 to 1995 all in one flat text file, 132433 lines, 5.76MB. In fact, as seen earlier in the digest, MS-DOS Kermit was making TCP/IP connections as early as 1989 using external drivers. Beginning with version 3.11, MS-DOS Kermit had its own built-in TCP/IP stack and Telnet protocol, a true marvel of compact programming, considering the whole thing fit on a floppy disk and ran in DOS versions back to 2.0. Kermit 95 for Windows, of course, has been a TCP/IP client (and server) since Day One (which was in 1995 of course). Those who still believe Kermit is just a simple modem program are invited to take a look at this page or this one. |
"Kermit's Text-Mode Interface Is a Throwback".
It's the old tradeoff. GUIs took the mass market by storm in the 1980s (Macintosh) and 90s (Windows) because they were easy to learn. That does not necessarily mean they are easy to use. Command and scripting languages are harder learn but are more powerful than GUIs.
- Point-and-click user interfaces are labor intensive. If it takes 37 mouse clicks to perform a certain action, then it takes 37,000 mouse clicks to perform the same action 1000 times.
- Point-and-click user interfaces are unstable. When you use a particular interface a lot, you become accustomed to exactly where are all the controls are. But when the next release of the software (OS or application) comes out, everything is different. Why? Because its makers don't have to worry about "backwards compatibility" in terms of breaking existing procedures or scripts, because there are none — just people with habits that have to be unlearned and relearned.
- Point-and-click user interfaces are not portable. Coding for any particular one locks you out of all the others. Even within a certain platform or window manager, fashions and APIs change over time, leaving applications stranded. This form of "software decay" was virtually unknown prior to the popularization of the GUI.
- A command language lets you create files or macros that have the computer do the laborious, repetitive, and/or routine tasks for you. That's what computers were supposed to be for. Kermit's command language is not broken by new Kermit releases. Kermit command scripts are platform independent and are simple plain-text files readable by humans, viewable and editable on text terminals and in text editors, and transportable from one platform to another by ordinary, nonproprietary means.
The time you invest in learning a command language pays off again and again as you use it to automate complicated or repetitive tasks, especially when you can depend on it not to lock you into a particular platform or change out from under you in ways that break all your procedures.
"Kermit Is Too Complicated!"
Kermit has been around for a long time. Features are added — and rarely, if ever, removed — as time goes on, so it seems to become increasingly complicated: more commands, more options, more syntax rules. Is that good or bad? Here's an excerpt from a FreeBSD newsgroup discussion, circa 2000:
: >> What's a good, simple terminal emulator to use on my 4.0-RELEASE laptop
: >> for serial /console connections to routers and switches?
: >
: >kermit wins here hands down!
:
: I beg to differ. Consider minicom.
:
: If you come from the dos world, you will feel at home with minicom, which
: is modelled after Telix' user interface.
:
: Also, it has the habit to do the right thing in quite a number of
: situations (but don't press alt-b, when you're connected to your
: company's sun server console :-)
:
: If you need All bells and whistles, scripting, you name it, of course
: kermit is the software of choice, but for simple task I found
: it too awkward to get running most of the time. Too much set this
: and configure that before it starts to do anything. No comfortable
: dialer configuration, automatic phonebook and whatnot...
:
Well, C-Kermit has all that too — just not in "GUI" or curses form, so
you have to put in a little effort to learn it.
The tradeoff is as follows...
Some tools like Minicom do just one thing (in the UNIX spirit). So to do that thing, you have to learn how to use that tool (Minicom in this case).
But the thing that Minicom does is very similar to the things that Telnet and Rlogin do, except on different kinds of connections. So if you make network connections too, you also have to learn Telnet and/or Rlogin.
But Kermit does both things: it makes both serial (direct or dialed) and network connections. But this means you have to tell it which thing to do ("set this, configure that"). The advantage is: everything else is the same on both kinds of connections, whereas it can be very different with the other packages (e.g. Rlogin quoting rules, Telnet escaping rules, sending BREAK, etc).
Of course we can carry this further. Maybe you want to transfer files with the same computers you connect to with minicom, cu, tip, seyon, pcomm, telnet, or rlogin. For this you would need Zmodem, FTP, rcp, etc etc — again, lots more programs and interfaces to learn. Or you can use Kermit to transfer files on all these kinds of connections, using just one interface — the same one you were already using.
Then maybe you're not an American, so you might need to have character sets translated on your connection — telnet, rlogin, FTP, dialout, whatever. Here you're getting into deeper water. Where are the Telnet, Rlogin, FTP, and dialout clients that do this? I don't know. But Kermit does it. Plus it can also convert character sets of local files, just like iconv or recode (oops, more user interfaces to learn!).
And on and on. Now, suppose you want to automate some complicated task, like dialing out, logging in, checking for some new files, downloading them if they are there, uploading some other files, etc. Maybe you could do this with some combination of shell scripts (which shell?), Expect, Runscript, Perl, Tcl, etc, plus Cu, Zmodem, etc (more interfaces!), or you could do it with Kermit, using the same commands you already learned.
Now suppose you want to do the same thing, but this time on a network connection. No worries: Just use the same script, but change a line or two to tell it to make a network connection instead of a dialout one. Everything else stays the same.
Now suppose you want your network connection to be secure. For this you could use ssh, scp, ktelnet, srp-telnet, etc. Or you could use Kermit, which supports Kerberos IV, Kerberos V, SSL/TLS, and SRP security (and in some versions, also SSH), and has all the same capabilities on secure connections that it does on clear-text ones — file transfer and management, character-set conversion, scripting, etc.
Now suppose your boss tells you to stop using FreeBSD (boo!) and move all your applications to some other operating system: Linux, AIX, Solaris, SCO, QNX, HP-UX, VMS, VOS, even Windows. No problem. Since Kermit is available for all those platforms, the same script runs on them too, and lots more; just change a line here and there to account for different file and device name formats.
Now suppose you have all these wonderful scripts, dialing directories, and so forth, but then you have to fly to another state and demo them there. Will they still work? After all, you're dialing from another area code. Again, no problem: Kermit takes care of all that. How about another country? Same thing. Kermit knows all about area codes, country codes, and dialing rules.
These days I suppose Kermit is something like EMACS. You have to put some effort into learning it, but once you do, it can save you huge amounts of time and work from then on. In many cases, you can look through the Kermit Script Library and find an example that shows how to do what you want.
Finally, for those who abjure "feature bloat" and want a version of Kermit that is "lean and mean" and "free" like in the old days, there is G-Kermit.
THE LICENSING DISCUSSION
THE FOLLOWING IS HISTORICAL."Why Isn't C-Kermit Part of Linux?"
AS OF JULY 1, 2011, KERMIT SOFTWARE IS OPEN SOURCE AS EXPLAINED HERE, AND C-KERMIT 9.0 IS BEING INCLUDED WITH MOST IF NOT ALL LINUX AND OTHER FREE UNIX DISTRIBUTIONS.
In fact C-Kermit is a part of increasingly many Linux and BSD distributions, though in some cases it might not be installed by default.
The Kermit Project has to make money from its work to pay for itself; it is not subsidized in any way. In fact we do give most of our software away ("free" in the sense of "free beer"), but some packages such as Kermit 95 and E-Kermit are sold to raise the operating funds we need to continue our work; others such as C-Kermit and MS-DOS Kermit are free for "own use" or internal use but must be licensed for commercial redistribution.
All Kermit software could be "free in the sense of freedom" if the Kermit Project were dependably funded to produce free software, but this has not been the case since about 1984.
"Why Doesn't Kermit Have a Standard Open Source License?"
First, note that there is a GNU Public License (GPL) version of Kermit, called G-Kermit, and you can find it in many operating system distributions. However, it is strictly a remote-end file transfer program and does not include the communication, scripting, security, and other features of C-Kermit, Kermit 95, and MS-DOS Kermit.
About the larger licensing question, here's a discussion from a 2001 newsgroup thread:
On 25-Feb-2001 in one of the Linux newsgroups, somebody wrote, explaining
why they did not use C-Kermit:
:
: But it still isn't free software.
:
(Meaning: it does not have an Open-Source license such as GPL or BSD,
permitting anybody to do whatever they want with it, including sell it.)
So what? Lots of software isn't free. Everybody is happy to pay money for retail software and in return receive bugs, headaches, no documentation, no upgrades, and no technical support.
C-Kermit is free to you if you want to use it. If you ask for technical support, you get it. C-Kermit is free to Linux packagers if they want to include it. But it's not free to people or companies who want to make money directly from it. Seems fair to me.
The Kermit Project was giving software away before there was a GNU project or FSF, before there was a Linux or FreeBSD. We all grew out of the same environment — university computer centers and CS departments in the early days of the ARPANET, where we were paid to develop software. We had secure jobs, so free software made sense. We all shared everything and it was fun. But those days are gone. Virtually nobody is paid to develop publicly available software in universities any more. The very foundation of the free software movement no longer exists. Now free software is developed by:
- Students who will soon get real jobs.
- People stealing time from their real jobs.
- A very few individuals who are actually paid to do it.
- Companies that hope it will destroy their competition.
- Companies that believe it will somehow turn a profit.
This is all fine with me — everybody should do what they please if it doesn't hurt anyone else. But it's not exactly a sound and stable system. Unpaid developers have little incentive to care about what their users want. And, with very few exceptions, the unpaid development model does not provide a career path except in the sense that if you become famous for some free creation, then you can get a high-paying job at an investment bank and disappear from the scene (except that as programming jobs go offshore, you're not likely to get ANY job).
The Kermit Project is one of the last surviving university-based nonprofit software development projects. We're here full-time to serve and help our users, year after year, decade after decade. The money has to come from somewhere, and believe me, we've tried every funding model. Sure, Kermit would be more popular if it was "free in the sense of freedom", but that would also kill it.
In the end, I think doctrinaire insistence on license purity is kind of silly, if not disingenuous. If the software is free to you, then what do you care if it's not free to somebody else who wants to sell it? If you yourself want to sell it, why do you think you have the right to expropriate somebody else's labor for your own enrichment? If everybody thought that way, nobody would do any useful work and we'd all starve. (More and more people are waking up to the necessary connection between labor and compensation. Free software is a fine idea when everybody has a job and time to work on software too. Now that programming jobs are increasingly scarce, the true meaning of the free software movement begins to emerge.)
Suppose your company had a commercial product of which Kermit was a critical component (as many do). Doesn't it make good sense to pay for it, thus assuring its survival and continued development, as well as giving you a voice in its future directions? Lots of companies think so. If they don't mind, why should you?
The fact is, C-Kermit is highly functional, useful, modern, well-documented, aggressively developed and supported software that can be in Linux if you want it to be. As of C-Kermit 7.0, 1 January 2000, nothing is stopping Linux packagers from including it. They'll do it if their customers ask them to.
- Frank da Cruz
THIS SECTION IS HISTORICAL TOO. See THIS PAGE.
The nonprofit Kermit project is funded entirely by the income it generates: Kermit 95 and E-Kermit sales and licenses, support contracts, licensing of other Kermit programs for commercial redistribution, and book sales.
Links: