Most recent update: Wed Feb 15 11:40:23 2006
This document pertains to Kermit "as a whole". Major Kermit programs, in turn, have their own specific FAQs, e.g.:
[ Contents ] [ Kermit Home ]
Here's a quick overview:
[ Contents ] [ Kermit Home ]
ftp://kermit.columbia.edu/kermit/
But that's OK since almost all access nowadays is through our website:
http://www.columbia.edu/kermit/
which provides quick access to our most popular items, such as:
But there are lots more, some of them dating back a decade or two. A concise (but long) list is here:
http://www.columbia.edu/kermit/aavsys.txt
The list is sorted by the contents of the "Machine" column. "Prefix" refers to the filename prefix, "Tape" refers to the subdirectory of the Kermit FTP site. Here's an example:
Prefix, Operating Program Program Released Tape Machine System Language Version yy/mm/dd Contributor MU D Honeywell MULTICS PL/I 2.0h 84/09/20 Oakland U
Kermit 2.0h for Honeywell MULTICS, written in PL/I at Oakland University, released 20 September 1984, is in the kermit/d directory of the FTP site, with filename prefix "mu". Even though the Prefix and Tape designators are listed in uppercase, you must enter them in lowercase because the FTP (and Web) site is now Unix-based (originally it was on a DECSYSTEM-20 where filenames were case-independent but shown in upper case). So to get the MULTICS version of Kermit, you would use FTP something like this:
$ mkdir multics (create a directory and cd to it) $ cd multics $ ftp kermit.columbia.edu (make the FTP connection) Name: anonymous (log in as user 'anonymous') Password: myuserid@host.domain (supply your actual email address) ftp> cd kermit/d (change directory to kermit/d) ftp> prompt (allow multiple files) ftp> ascii (transfer in ascii text mode) ftp> mget mu* (get all files whose names start with mu) ftp> bye (log off the FTP server) $
For detailed instructions about FTP, CLICK HERE. To find out how to use Kermit itself, instead of FTP, to download from the Kermit site, CLICK HERE.
[ Contents ] [ Kermit Home ]
Others discussed here:
There's nothing wrong with Telnet. In fact it's far superior to SSH as a virtual terminal protocol in terms of features and extensibility, not to mention platform neutrality. Of course clear-text Telnet is insecure because passwords travel in the clear across the network, but apparently few people realize that secure Telnet clients and servers have been available for years, and these are more secure than SSH for reasons explained HERE. (If you don't bother to follow the link, the short version is manageability, especially regarding recovery from compromised keys.) Increasingly, Internet standard security methods such as Kerberos and SSL/TLS are included in standard distributions of Unix (Linux, FreeBSD, OpenBSD, AIX, Solaris, HP-UX, ...), VMS, and other operating systems, supported in their Telnet and/or FTP servers and/or clients. And of course they are also supported by C-Kermit for Unix and VMS and by Kermit 95 for Windows (which also supports SSH v1/v2).
Similarly for FTP. SCP and SFTP are not only not platform neutral, they're diversity-hostile. They transfer files only in binary mode, which mangles text files across different platforms, to the same degree the platforms' text-file record formats and character sets differ. An extreme example would be a Variable-Block format EBCDIC text file on an IBM mainframe, binary transfer of which to Unix would do you little good indeed. FTP was designed with diversity in mind and secure versions are available.
Of course SSH has its place, but you should use it with your eyes open, especially from Windows (where key files are easily stolen). SSH is best suited for trivial cross-realm applications. For example, if you have guest IDs at other sites for building an application on different platforms. Formerly Telnet and FTP would be used for this but now these paths tend to be blocked. However, even if the remote site has Kerberos service or X.509 certificates, it would be unnecessarily time-consuming to set up the cross-realm authentication and/or ticket forwarding for little one-shot jobs like this. In this case, SSH with manual password authentication is fine.
But for more serious work, especially within large organizations such as universities, corporations, laboratories, and government agencies, where your whole online identity is at stake, a manageable centralized security architecture is essential.
[ Contents ] [ Kermit Home ] [ Kermit Security Reference ] [ The Kermit FTP Client ]
Licensing is a hot and contentious topic. The public increasingly expects software to be "free" (with various and differing interpretations of the word free), and yet software is the product of human labor, which ultimately must be paid for, particularly if it takes place full-time over a span of decades.
The Kermit Project is composed of a core of full-time computing professionals at Columbia University in New York City, plus volunteers at other locations. Although the University paid for the Kermit Project initially, funding was withdrawn in the mid-1980s, and since then we have been funded solely by the revenue we can generate through sales of books, software licenses, and support contracts.
With the exception of Kermit 95, which must be bought and paid for, Kermit software is free in the sense that you can get it for free -- including the source code -- by downloading it; you can use it for free (even within a commercial setting); and you can even get e-mail technical support for free (within reason).
However, this freedom does not extend to redistribution of the software in a commercial setting: furnishing it to customers or clients, bundling it with products, and so on. If you want to gain commercial advantage from our work, you must help to support our work by licensing the software for redistribution. The specific terms and conditions depend on the product and other factors, and are given on our licensing page. This policy is fair and makes perfect sense: if your business depends on our products, it is in your best interest to keep our product alive and strong.
A recent exception to this policy allows inclusion of C-Kermit with free (in the Open Source sense) operating-system distributions such as Linux and FreeBSD. See the C-Kermit License for details.
Another exception is G-Kermit, which is released under the GNU Public License.
[ Contents ] [ Kermit Home ]
[ Contents ] [ Kermit Home ]
[ Contents ] [ Kermit Home ]
[ Contents ] [ Kermit Home ]
[ Contents ] [ Kermit Home ]
[ Contents ] [ Kermit 95 ] [ Kermit Home ]
NOTE: "UNIX" is a general term covering the many operating systems that descended from the original Bell Labs UNIX operating system. Examples include: Linux, FreeBSD, NetBSD, OpenBSD, Solaris, SunOS, AIX, HP-UX, IRIX, OPENSTEP, NeXTSTEP, System V, Tru64, OSF/1, DG/UX, Unixware, Xenix, OpenServer, BSDI/OS, Ultrix, Digital UNIX, SINIX, and many more (for a longer list, CLICK HERE).
[ Contents ] [ C-Kermit ] [ Kermit Home ]
[ Contents ] [ MS-DOS Kermit ] [ Kermit Home ]
[ Contents ] [ IBM Mainframe Kermit ] [ Kermit Home ]