http://www.columbia.edu/kermit/misconceptions.html
The Kermit Project | Columbia University
612 West 115th Street, New York NY 10025 USA *
The Columbia kermit@columbia.edu
Crown
...since 1981
Home Kermit 95 C-Kermit Scripts Current New FAQ Support
Kermit - Misconceptions and Controversies
This page updated 2 August 2021: FTP links changed to HTTP.
* Kermit is Slow
* Kermit is a Relic of a Bygone Era
* Nobody uses serial ports or modems any more
* Kermit's Text-Mode Interface Is a Throwback
* Kermit is Too Complicated
* The Licensing discussion
---------------------------------------------------------------------
"Kermit is slow".
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:
* http://www.conklinsystems.com/analysis.shtml.
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.
Performance benchmarks graph
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.
---------------------------------------------------------------------
"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.
Just a few examples. But really, it has been about twenty years*
since Kermit was just a serial-port and modem program. Despite the
best efforts of industry to kill off serial communication, in the end
it is simple, self-contained, universal, compact, proven, and
relatively dependable and secure, whereas other methods are much more
complex and tend to depend on externals such as configuration files,
databases, ACLs, DNS, routers, switches, Perl modules, etc, any which
can break or become inaccessible, not to mention viruses, worms,
denial-of-service attacks, "evolving" protocols, and so on. And for
this reason serial-port and modem communication will live on for the
foreseeable future, at least in areas such as those noted above.
__________________
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.
BEGINNING IN VERSION 9.0, C-KERMIT HAS THE OPEN SOURCE SIMPLIFIED
BSD LICENSE.
"Why Isn't C-Kermit Part of Linux?"
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.
"Why Isn't Kermit Free?"
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:
* Manuals
* Sample Scripts
* Kermit Project Home Page
---------------------------------------------------------------------
Misconceptions and Controversies / The Kermit Project / Columbia
University / kermit@columbia.edu / 2006-2011