81–90 of 110 posts
The article mentions 'Terminate'. That software was a joy to use. https://web.archive.org/web/19980627010642/http://www.termin...
Yeah, Terminate was a big step up from Telix. Wow that takes me back.
Still would love if desktop terminal emulators would implement the zmodem receiver side, so that you can ssh into some host of your choice and just type "sz" to copy arbitrary files of your choice onto your local system.
Just use sshfs, or rclone mount, and use the old cp -r to get your files. MC can connect to ssh/ftps too, and you can copy files and dirs from pane to pane.
This type of automatic transfer makes it very convenient to generate figures on a server (where the data lives) and then view them locally. It’s a much better workflow than having to use sshfs or scp.
What I wrote is really quite similar to an old transfer program like zmodem with the added feature of auto opening a file if I choose.
Earlier quoted context omitted.
Yeah, Terminate was a big step up from Telix. Wow that takes me back.
I used both of those, as well as ProComm Plus (PCPLUS.EXE). Thanks for the trip down memory lane!!!
Earlier quoted context omitted.
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. $ ls -lh /usr/bin/cp -rwxr-xr-x 1 root root 123K Apr 3 19:…
It's not that the programs are getting bigger. It's just that the bytes are getting smaller.
I used this frequently to move files back in the dialup modem days, after doing an ugly redirect to get the Zmodem binary on the far end, and because of its superior compression, Zmodem was faster than uucp/uucico (when you were lucky enough to have the uucp suite installed and configured, which unlike Kermit and Zmodem, required root privileges...)
Last year we implemented "ymodem over BLE" for reasons that are complicated and possibly stupid. It felt familiar but strange and wrong to do such a thing. Worked great though.
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…
I have a brand new system sitting here next to me on the bench that uses SLIP framing for packetizing Protobufs :)
Earlier quoted context omitted.
Just use sshfs, or rclone mount, and use the old cp -r to get your files. MC can connect to ssh/ftps too, and you can copy files and dirs from pane to pane.
It’s just not the same as having transfers available on the remote command line. I have a program I wrote that maintains a local server with a port forwarded over SSH. Then on the remote side I have a client program that sends a file(s) (or folder) back to my local computer. It can either save the file or open it, depending on the command I ran. This type of automatic transfer makes it very convenient to generate fig…
lrzsz is one of the first packages i install when configuring a new system. being able to send and receive files between remote and local without needing a separate ssh session is such a time saver. it's really fast as well. i do wonder if anyone has developed something more modern to make it even more performant?
I have used bare netcat to transfer files. works well enough when the link is good, when it's not... Well I suspect that is when you dig out better tools. nc -l 1234 > fname nc host 1234 < fname
It supports flakey networks and it has tons of features.
Earlier quoted context omitted.
It’s just not the same as having transfers available on the remote command line. I have a program I wrote that maintains a local server with a port forwarded over SSH. Then on the remote side I have a client program that sends a file(s) (or folder) back to my local computer. It can either save the file or open it, depending on the command I ran. This type of automatic transfer makes it very convenient to generate fig…
Once you mount everything as local with rclone, transferring protocols have no sense, everything should be part of a filesystem. Plan9 did it right, there's no difference between local and remote once you get the grasps of 'bind'.
It doesn’t matter if you mount a remote server locally… unless your data is of a trivial size, you still want to do the processing remotely.
I see this as a theory vs practice difference. In theory having one unified file system is great and the way to go. In practice… there are issues.
Earlier quoted context omitted.
That's pretty funny. I don't remember ever coming across configs for Kermit or other protocols, just the [K]ermit | [Z]modem -type options on the front end of whatever clients I was trying out. I wonder why more than one client would default to such comparatively-lame settings for Kermit though.
The whole protocol does. IIRC you basically have to get a Kermit prompt and issue your commands to the server. Which is easy if you use an actual Kermit client, like Columbia put out (though apparently for the last 12 years it's been an independent project no longer affiliated with the university), but most people just used the internal version that came with their terminal program - with the primary effect being tha…
The default of "always work" is amply demonstrated by the fact that Kermit is available for CP/M, and can be compiled on a working CP/M-80 system from .HEX files that you just blast over the serial port. Obviously, due to system constraints, this is not a fully modern Kermit.
But it works. And if you want error checking and reliable file transfer on a Kaypro, it's not a bad way to do it.