| [ Home ] [ Kermit 95 ] [ C-kermit ] [ Scripts ] [ Current ] [ New ] [ FAQ ] [ Support ] |
Kermit 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. This 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 suffers from:
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 shown in:
For further information about performance, see:
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 a Telnet connection; in this case file-transfer speeds are about the same as FTP, and often faster, since Kermit adds compression.
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. In fact, Kermit software is more popular than ever, 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, 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, and flexible, 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:
(*) The Internet Kermit Service, described in Internet RFCs 2839 and 2840, offers a flexible, high-function alternative to FTP service, now available for Unix (most varieties: Linux, Solaris, FreeBSD, AIX, HP-UX, etc) and Windows NT/2000/XP.
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? Now they are -- CLICK HERE for more information.
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.
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.
"Why Isn't C-Kermit Part of Linux?"
In fact C-Kermit is a part of increasingly many Linux and BSD distributions, including SuSE and, most recently, Red Hat 9 (though you might have to hunt for it on the CDs or perform a Custom installation).
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:
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 -- READ THIS).
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
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: