Hello! Thank you for starting me up! I'm the Kermit protocol and I'm happy to hel... wait, you want to transfer what file? What the hell is a gigabyte? Well, man, OK, you're the user so you know best, but man, this is going to take like, days man, settle in, here we gooo
WHAT THE HECK WAS THAT? Did I just do megabytes per second? Holy shit. Am I high or something? What is this hardware? What is going on here?
No... wait... is that the end? Am I done here? No! No, I want to transfer more! More! Megabytes per second! Gigabytes per second! I can see it now, I want it, I want more, please, let's transfer another file, come on man, I want to ride again, please ple
My Commodore 64 has a USB interface nowadays (and a few replaced caps). Originally it only had a tape "drive" ie cassette. After a few years we got a 1541 floppy disc unit. Tick, tick tick, whiirrrrrrrr (think: trilled r on speed), fut (etc). Instead of 10-15 mins to load a game it loaded in a fair few seconds. Bear in mind that the 64 refers to 64 kilobytes.
The copy command on this laptop is 123Kb! ls is 135K. Elite on the C-64 has filled 3D polygonal space ships, space stations and stuff, a whopper of a galaxy and a HUD that gives you an excellent idea of what is where in 3D. You get a trading system and ship upgrades etc. Oh and music - The Blue Danube should play when one is docking with a space station. Obviously you'll need a driver for the joystick and keyboard too. You don't get the whole 64Kb to play with either - a fair bit of that is used by the system itself.
Before the C64 I used a ZX81 and before that a ZX80 - they had roughly 1 kilobyte of RAM. The ZX81 had a RAM pack upgrade which added 16Kb. It was a bit wobbly and required a strip of Bluetac to stop it crashing the computer when nudged. An uncle of mine calls "bloody luxury" on that - he learned programming with punched cards - probably ForTran.
This laptop's kernel is 12M and initramfs is 14M and a fallback image of 70M. Add to that a microcode image (7M).
You'll be glad to hear that Kermit weighs in at a svelte 26K (I've just installed it from the Arch AUR)
Elite on the C64 did not have filled polygons. It had hidden line removal. Still impressive.
Funny part about Elite is that they supposedly limited the number of galaxies to maintain the illusion that it was manually created instead of built at runtime using a pseudo random number generator with a preselected seed.
Now I'm wondering if there's ever been emulated software that crashed because it tried to calculate a data transfer rate, but the emulator transferred the data faster than the delta in the time measuring in the emulated machine, so it divided by zero.
Once when I should've been in college still, I was using the Telix terminal program on a 286 with a 2400MNP5 modem. Now Telix had a really awesome scripting language that could do all sorts of terminal magic, but that's a story for another day.
My connection to the Internet was 8-bit clean, and at the time I was an avid Emacs user/evangelist. (Since then, I have seen the light of vim's face and have never turned away.)
I saw that Emacs included a mapping file for mskermit to generate ESC sequences for Alt+Keypress, and I figured out that if I mapped each scancode for Alt+Keypress to the appropriate 8-bit code, it would convert my Alt key into a Meta buckybit, perfect for Emacs usage!
So I painstakingly mapped out each scancode and transcribed it into the ms-kermit configuration, and before long I was Emacsing in all its 8-bit-meta-glory.
I figured it would be useful to other Emacs users, and so I sent the file upstream. Lo and behold, it was incorporated into the standard Emacs distribution, and it stayed that way for a long, long time.
Unfortunately, since I had never formally assigned copyright or done whatever legal bit needs to be done to GPL the code, TPTB did an audit of the Emacs distro and culled any code that did not have solid legal footing. At that point, ms-kermit was really obsolete anyway, so I suppose it's all for the best!
My only source of internet in undergrad was dialing into my university's modem pool and getting a shell on the main server (a DEC Alpha running OSF/1). Browsing the web was done through lynx.
That worked fine but every now and then, a site would have some inline image that I'd want to see, so I'd view source to get the img URL and then download that to /tmp and transfer the file to my local machine via zmodem. Usually, it wouldn't be worth the effort. I'd also download mp3s off IRC via DCC and queue up a bunch of data for zmodem to transfer overnight or when I was in class. I really appreciated those bytes back then. Now, not so much.
This reminded me that I used to view images over my dialup connection directly in the terminal by catting the image to pbmtoascii and making my terminal font 1 pixel high. It wasn't exactly pretty but it worked.
LOL!! I thought I was the only person who did this. Back in the mid-90's I did the same thing. One day I was feeling a bit randy and decided to visit a certain centerfold magazine website and download some images that way.
Wow. I miss those days. Back when life was simple. I really wish my kids could experience working with TSR dos programs, and being intentional of what you are trying to do with a computer. Every k mattered back then.
I tried to track him down a few years ago so I could register my (previously pirated) copy of terminate. I figured better late than never. But I couldn’t find him.
I recall that there were some shenanigans with the sale of the company. I think there’s some messages floating around on newsgroups and around the place about it. I found this https://paste.ee/p/Z0ywP
I still use these protocols for embedded systems. There is almost always a CLI on a UART, so one should be able to transfer files.
Ymodem is simpler and smaller than Zmodem, but we've used both. I've used Zmodem at 921600 baud, but it needs fairly large buffers (for a UART) to work.
One of the big advantages is that TeraTerm for Windows exists, and supports xyzmodem. It means that I often don't have to write any host-side software for things like firmware update, and more important, don't have to touch Windows.
A former employer still insists on using Xmodem-1K even though Ymodem is almost the same and provides so many quality of life improvements with the header block. It was endlessly annoying to have to manually tell the receiving end the file size and name when a simple upgrade would obviate the need.
I have actually used 'sz' and 'rz' in relatively modern times for quick and dirty file transfer and found it very convenient in a very narrow set of use-cases.
However ...
It's a serious violation of the cleanliness and available attack surface involved in a terminal interface and we should be on the lookout for, and reject, similar interfaces and applications.
In order for zmodem to work over the terminal, the terminal program itself needs to know something about the text flowing over the connection and then invoke special, extra routines based on monitoring that textual flow.
This opens up all manner of weird, extra attack surface.
The beauty of the text terminal is that I can, theoretically, cat any file I want to without fear of what it contains. I can open up (perhaps with 'strings' or 'hexedit') any email attachment without fear of the strings that it contains. I can do this because I am using a dumb terminal.
As soon as the terminal is smart - even a little bit - you've got vectors for weird strings doing things you don't want them to.
I have bad news for you. Do you know what (n)curses is for? Its basically a library for those magic strings (and ascii control characters) that run extra routines in the terminal. And every terminal has these routines.
As I see it, the parent is specifically worried about the terminal needing to monitor input and fork a process in response. Control character handling should be pretty robust (or worst-case, a NOP). Curses-based programs read/write specific control characters to move the cursor, etc (really any tty should support control characters).
But they don’t fork a new process… (unless I’m very mistaken).
We have switches purchased in the last few years that use zmodem for firmware upload and recovery.
Annoyingly it still supports a maximum of 115200 baud, even though the serial port on the switch is physically USB-C, so on the one occasion we had a switch brick itself and had to use zmodem "in anger" it took quite a long time to upload the replacement firmware.
ooooooo whooooooo OOOOOOOOO AAAAAAAAAAAAAAA !!!!!!!!!!1!! qcjqrjrcorRC!!!
WHAT THE HECK WAS THAT? Did I just do megabytes per second? Holy shit. Am I high or something? What is this hardware? What is going on here?
No... wait... is that the end? Am I done here? No! No, I want to transfer more! More! Megabytes per second! Gigabytes per second! I can see it now, I want it, I want more, please, let's transfer another file, come on man, I want to ride again, please ple
Before the C64 I used a ZX81 and before that a ZX80 - they had roughly 1 kilobyte of RAM. The ZX81 had a RAM pack upgrade which added 16Kb. It was a bit wobbly and required a strip of Bluetac to stop it crashing the computer when nudged. An uncle of mine calls "bloody luxury" on that - he learned programming with punched cards - probably ForTran.
This laptop's kernel is 12M and initramfs is 14M and a fallback image of 70M. Add to that a microcode image (7M).
You'll be glad to hear that Kermit weighs in at a svelte 26K (I've just installed it from the Arch AUR)
Funny part about Elite is that they supposedly limited the number of galaxies to maintain the illusion that it was manually created instead of built at runtime using a pseudo random number generator with a preselected seed.
Once when I should've been in college still, I was using the Telix terminal program on a 286 with a 2400MNP5 modem. Now Telix had a really awesome scripting language that could do all sorts of terminal magic, but that's a story for another day.
My connection to the Internet was 8-bit clean, and at the time I was an avid Emacs user/evangelist. (Since then, I have seen the light of vim's face and have never turned away.)
I saw that Emacs included a mapping file for mskermit to generate ESC sequences for Alt+Keypress, and I figured out that if I mapped each scancode for Alt+Keypress to the appropriate 8-bit code, it would convert my Alt key into a Meta buckybit, perfect for Emacs usage!
So I painstakingly mapped out each scancode and transcribed it into the ms-kermit configuration, and before long I was Emacsing in all its 8-bit-meta-glory.
I figured it would be useful to other Emacs users, and so I sent the file upstream. Lo and behold, it was incorporated into the standard Emacs distribution, and it stayed that way for a long, long time.
Unfortunately, since I had never formally assigned copyright or done whatever legal bit needs to be done to GPL the code, TPTB did an audit of the Emacs distro and culled any code that did not have solid legal footing. At that point, ms-kermit was really obsolete anyway, so I suppose it's all for the best!
That worked fine but every now and then, a site would have some inline image that I'd want to see, so I'd view source to get the img URL and then download that to /tmp and transfer the file to my local machine via zmodem. Usually, it wouldn't be worth the effort. I'd also download mp3s off IRC via DCC and queue up a bunch of data for zmodem to transfer overnight or when I was in class. I really appreciated those bytes back then. Now, not so much.
But I could uuencode into a big buffer on my terminal program and uudecode locally.
[0] https://en.wikipedia.org/wiki/Slirp
https://web.archive.org/web/19980627010642/http://www.termin...
slrn --- NNTP/spool-based Usenet newsreader last updated: 2023-03-18T04:31:51 [UTC] repository: git://git.jedsoft.org/git/slrn.git tarfile: slrn-pre1.0.4-9.tar.gz ( size: 1563860 bytes; md5: f193d983e104a82ef4fd70b1037f8b60 ) github: https://github.com/jedsoft/slrn
https://github.com/BitchX/BitchX1.3
https://irssi.org/2023/03/31/irssi-1.4.4-released/
I recall that there were some shenanigans with the sale of the company. I think there’s some messages floating around on newsgroups and around the place about it. I found this https://paste.ee/p/Z0ywP
It felt familiar but strange and wrong to do such a thing. Worked great though.
Ymodem is simpler and smaller than Zmodem, but we've used both. I've used Zmodem at 921600 baud, but it needs fairly large buffers (for a UART) to work.
One of the big advantages is that TeraTerm for Windows exists, and supports xyzmodem. It means that I often don't have to write any host-side software for things like firmware update, and more important, don't have to touch Windows.
I have a brand new system sitting here next to me on the bench that uses SLIP framing for packetizing Protobufs :)
I have actually used 'sz' and 'rz' in relatively modern times for quick and dirty file transfer and found it very convenient in a very narrow set of use-cases.
However ...
It's a serious violation of the cleanliness and available attack surface involved in a terminal interface and we should be on the lookout for, and reject, similar interfaces and applications.
In order for zmodem to work over the terminal, the terminal program itself needs to know something about the text flowing over the connection and then invoke special, extra routines based on monitoring that textual flow.
This opens up all manner of weird, extra attack surface.
The beauty of the text terminal is that I can, theoretically, cat any file I want to without fear of what it contains. I can open up (perhaps with 'strings' or 'hexedit') any email attachment without fear of the strings that it contains. I can do this because I am using a dumb terminal.
As soon as the terminal is smart - even a little bit - you've got vectors for weird strings doing things you don't want them to.
But they don’t fork a new process… (unless I’m very mistaken).
pretty sure it won't work over mosh tho
Yep that's 1.5 million times the speed I used to get.
zmodem can also be used in embedded spaces to retrieve files if the only interface is a serial port.
Annoyingly it still supports a maximum of 115200 baud, even though the serial port on the switch is physically USB-C, so on the one occasion we had a switch brick itself and had to use zmodem "in anger" it took quite a long time to upload the replacement firmware.