[HN Gopher] Kermit - Misconceptions and Controversies (2021)
___________________________________________________________________
Kermit - Misconceptions and Controversies (2021)
Author : zdw
Score : 49 points
Date : 2022-04-24 04:59 UTC (1 days ago)
(HTM) web link (www.columbia.edu)
(TXT) w3m dump (www.columbia.edu)
| jandeboevrie wrote:
| Kermit is one of those utilities I use almost daily. In my case
| to script a connection sequence to a hardware device via serial.
| (Few timed keystrokes and a string of text).
|
| Ubuntu 20.04 removed Kermit, so I packaged it up as a snap to be
| able to use it again:
| https://raymii.org/s/blog/Ive_packaged_up_CKermit_as_a_snap_...
| mhdhn wrote:
| File transfer protocol and related software. Some links
|
| https://en.m.wikipedia.org/wiki/Kermit_(protocol)
|
| https://www.kermitproject.org/kermit.html
| jhallenworld wrote:
| One thing about Kermit- it used to be the gold standard for CLI
| usability: editing, history, ESC-completion and context sensitive
| ?-help. I think it was directly inspired by the TOPS-20 operating
| system.
|
| For example, user types "?" after entering screen
| C-Kermit>screen ? screen action, one of the following:
| clear cleol move-to C-Kermit>screen _
| voxadam wrote:
| Archive:
| https://web.archive.org/web/20220424041605/https://www.colum...
| ngcc_hk wrote:
| Can't remember why but old day this is the only software that
| work. There are faster one like z modem, but not always work.
| ginko wrote:
| I've looked through the various pages linked trying to find out
| what Kermit actually is and have yet to find out.
|
| Ironically the 'About' link 404s.
| tyingq wrote:
| Before it was common for a home PC to have IP connectivity (via
| SLIP, PPP, etc), you needed a program to connect to your modem,
| dial a terminal session into a remote server, handle file
| transfers,etc.
|
| Sometimes these programs bundled both the terminal/dial up and
| the file transfer functionality. Other ones were
| terminal/dialers, but would spawn a separate file transfer
| program.
|
| Kermit was the bundled type...both the terminal/dial and file
| transfer was built-in. It was also more scriptable than a lot
| of other solutions...it had an embedded script language with
| send/expect functionality. So, for example, if you had a bank
| of ethernet connected modems, you could script whatever
| commands where needed to connect to them and dial. Or you could
| connect and script against the unix (or other) shell on the
| remote end. It's even handy for this type of thing today, as it
| can use ssh as the connection instead of dial up.
|
| It was also the most portable program of this type, with
| versions that would run on MS/DOS, Windows, Unix, IBM
| mainframes, Multics, CPM, etc.
|
| I used it quite a lot because I was a unix admin, and our work
| didn't offer SLIP or PPP dial-in. So, I could use kermit to run
| batch jobs to connect, download my recent work, maybe some
| usenet news data, etc. Or, just use it as a terminal program at
| home to get a unix shell prompt from a computer at work, upload
| files, and so on.
| usrn wrote:
| It's an old file transfer program.
| whartung wrote:
| Yes, that's true, but it's understating it quite a bit.
|
| Kermit (actually , C-Kermit) is a serial communication
| program. Simply, it allowed you to connect to your serial
| port, and then interact with serial devices. Commonly the
| device you were interacting with was a modem, but that wasn't
| necessarily true. You could be connected straight up into
| another computer.
|
| Kermit is also a file transfer protocol, similar to
| XMODEM/YMODEM/ZMODEM. These protocols were used to ensure
| that copy operations operated reliably through the use of
| checksums and whatnot. Serial was the most common physical
| layer that this was used over, but not necessarily the only
| layer.
|
| The Kermit protocol was quite sophisticated and able to work
| at various levels of advancement and compatibility. It was
| able to work over connections that were not 8-Bit pure. It
| supported dynamic window sizes to help boost performance.
| They used to publish the simplest of BASIC programs to act as
| a receiver so that you could use it to bootstrap moving over
| a more capable program that was more sophisticated for your
| platform.
|
| Speaking of that, Kermit was widely ported to most any system
| out there. As an example, the HP-48G calculator had Kermit
| built into it. Because of that, we used to use the HPs for
| data collection in the field, and then upload the results to
| a PC using Kermit.
|
| XMODEM et al were widely popular and supported. Kermit was
| also, but because of C-Kermit, its wide distribution, it was
| also its own little world. C-Kermit also had an innate
| scripting language making it very useful for ad hoc,
| automated workflows.
| wyldfire wrote:
| My experience with it was when BBSs were common and access to
| The Internet was limited to universities. If you wanted to
| upload or download a file, you could use one of these programs
| like Kermit to manage the file transfer. My recollection was
| that invoking it was a manual step at first but I recall it
| being triggered automatically by the terminal/dialer program
| (for downloads at least). I almost always used xmodem, ymodem
| or zmodem. I had that same impression described in this article
| that Kermit was "slow".
| tyingq wrote:
| >I had that same impression described in this article that
| Kermit was "slow".
|
| Most of that was default settings. Kermit had defaults that
| assumed the worst...non-8bit-clean, no hardware flow control,
| small uart buffers, etc. If you tweaked the settings (sliding
| windows, packet size, etc), the differences in speed were
| negligible.
| fmajid wrote:
| It's a program you use to connect to devices over serial ports
| (including via modem), and it has file-transfer capabilities
| built-in. I first started using it with my HP-48SX calculator
| in the 90s. It's still the first tool I reach out when
| communicating over serial devices, e.g. SBCs that don't have a
| graphical console like running OpenBSD over a BeagleBone using
| the UART to connect, or Cisco switches using the serial cable.
| compiler-guy wrote:
| The claim about how Kermit can be just as fast as it's
| contemporaries like zmodem if it is configured correctly is
| absolutely true.
|
| It's also a statement about the power of defaults. By the time
| you research out how to make kermit as fast as zmodem, you may as
| well have switched to zmodem which does it for you.
|
| Configuring it was easy (I did it myself plenty of times), but
| "switch to zmodem" is a much easier set of instructions.
| whoopdedo wrote:
| Although the page says it was updated in 2021 (to change some FTP
| links to HTTP) the tag at the bottom says 2011.
|
| Some of the noted advantages of Kermit I don't see as relevant
| for new systems. Character sets? I use UTF-8 for everything. Text
| mode files? I treat everything as binary. File permissions and
| directory trees? Tar preserves those and more. Besides, I've
| never wanted to save more than a timestamp when copying between
| different computers.
|
| But it still holds up for being text-driven. In a what-old-is-
| new-again way a lot of the world has moved back to CLI since this
| was written. And for the same reason, because text interfaces are
| easier to automate.
|
| That said, I don't think a GUI is inherently unscriptable. There
| have been macro and automation tools for windowing systems. I
| think it mostly the attitude of GUI design doesn't consider
| automation a priority while CLI does. (I'd even say it's nearly
| impossible to make a text interface that can't be automated.) A
| macro I create to control a GUI will become obsolete when the
| application designer decides to move the buttons around for
| purely aesthetic reasons. Breaking changes like that are rare in
| text applications.
| tyingq wrote:
| >Text mode files? I treat everything as binary.
|
| This is still an issue today with Windows vs everything else. I
| regularly filter ^M out of source files. There's all sorts of
| hackery in tools like gitbash, wsl and clipboard buffers, etc.
| rlpb wrote:
| My editor autodetects and preserves the line ending character
| sequence when I save. If I want to change it, I just need to
| change the setting. Doesn't yours? Why is this still an issue
| for you?
| tyingq wrote:
| Yes, there are a variety of ways to deal with it, though
| editor autodetect doesn't solve every issue I have with \r.
|
| One example is ":r! wl-paste" within vim. The carriage
| return is there, and if I join two lines, it ends up in the
| middle, where ":set ff unix" doesn't help me when I save.
| joezydeco wrote:
| The bigger problem is Windows not supporting USB serial ports
| over 1MBaud.
|
| I've got a dozen embedded designs with SoCs that can go >3Mbit
| but since Windows users are my common denominator, I'm stuck at
| 1.
| Brian_K_White wrote:
| Back in the days of serial terminals I made a sweet single-floppy
| terminal, customized to support a sco xenix application, with
| nothing but a bootable dos floppy and ms-kermit, and it worked
| better and was simpler for the users than the procomm plus they
| had been using.
|
| It was all because of how scriptable and customable ms-kermit
| was.
|
| Not only I was able to make all the terminal emulation and
| keyboard keys work perfect, I even made the disk user self
| maintaining where the disk could copy itself, so they never had a
| problem with the disks wearing out in a dirty shop environment.
|
| And it was all dirt cheap and dead simple for the users and
| business owner to maintain unlike a proper network booting
| solution would have been at the time.
|
| The window of time where that articular awesomeness mattered was
| small, but it sure was awesome.
|
| It wasn't even doing any kermit file transfers, just acting as a
| swiss army knife of a scriptable configurable serial terminal
| running on essentially free 8088 and 8086's with no hd's, ram, or
| nics.
| NoGravitas wrote:
| I used C-Kermit back in my dialup terminal days. It was a well-
| kept secret, I guess, that a properly tuned Kermit was
| significantly faster than ZModem.
| TomMasz wrote:
| Tuning was the key. Once you understood the protocol and the
| robustness of your connection, it was easy to configure Kermit
| to run fast.
| zabzonk wrote:
| Ah, this takes me back. I wrote implementations of the Kermit
| protocol for the Z80, 6502 (both in assembler) and the 8086
| (mostly in C, but some assembler for the interrupt-driven I/O).
| It was a really nice and easy to implement protocol, and very
| sturdy - you could unplug the serial port connection and then re-
| plug it, and the file transfer would restart where it was
| interrupted.
|
| This would have been mid-1980s.
___________________________________________________________________
(page generated 2022-04-25 23:02 UTC)