Which is interesting because most autoconf programs I've seen do the opposite. They have all these defines and then don't use them. Just seems like a waste of time. Cmake has been better but still sometimes cmake will pass and the code still doesn't build

That was one ethos that was taught at the UC Davis CS program in the 90's-00's. They had clusters of IRIX, Linux, Sun, HP-UX, and (sometimes) MINIX boxes. Homework and lab projects would be nondeterministically graded on any except MINIX. It was also beneficial to add portability for Windows with MS and/or Borland toolchains for some projects. BSD sockets was pretty cross-platform with some idiosyncratic gotchas per platform.

It saddens me whenever someone or a group religiously tie their opinions or assumptions to a particular platform and irrationally scoff at others or refuse to consider that other things exist, are used, and function.

Exactly my experience, the faster file transfer programs failed me on the crappy dialups of the day… but Kermit came to the rescue. As I recall it gave you a running tally of retries and all that.

For context, on the other side of the wall where we were doing this was a Cray, probably a Cray 1. The one with the bench seating in a semicircle on top of cooling hardware.

I found it essential for the same reasons, in those early Internet days... PAD, -> UNIX host (x.25), -> VMS "mainframe" (dual stack), on to Internet (TCP/IP).

Trumpet Winsock in PPP mode, or SLIP ATTACH or invoking a SLIP server daemon upon login, worked with UCF/UF library VAX systems back then. Just needed to use CTRL-C to break out of their login scripts and get a prompt.

I had never heard of CGOS, but this is still up on the Kermit archive! https://kermitproject.org/archive.html Are you Val? Looks like you had to add some hacks to deal with long file naming conventions on CGOS but short filenames on CP/M.

I remember back in the day Kermit was pretty heavyweight. We used sz/rz for file transfer [z-modem: good to see the man pages are still up! https://linux.die.net/man/1/sz]. Is there a reason to prefer Kermit?

I used Telix under IBM PC-DOS for scripting. The SLT scripts were as versatile as Expect or Tcl in that day.

I used MS-Kermit as a terminal emulator on the same system. I was accessing academic Unix systems and probably also remote access at my first job. MS-Kermit had a keycode translation capability that I used extensively.

My 2400/MNP5 modem sometimes only had a 7-bit connection. Without being 8-bit clean, I couldn’t directly use the Meta key with GNU Emacs. But sometimes I did achieve an 8-N-1 clean connection in the same modem pool!

So I wrote up two large tables for MS-Kermit: one for the 7-bit connection that would send ESC to simulate Meta for Emacs. And one for 8-bit-clean operation that used ALT as Meta and sent the ASCII code >=128.

I eventually submitted them to the GNU Emacs project and one was distributed with Emacs 18. Eventually, they were forced to remove it during a copyright/license cleanup audit. But it was my claim to 15 minutes of fame.

Can you elaborate more on how you use it or do you recommend any codebase to learn more?

I remember evaluating Kermit and ymodem for my embedded work too, but didn't end up using them. Maybe I didn't understand Kermit fully. I wanted something to connect over serial (usb cdc and ble) via the browser and manage files and the state of the device.

I always end up writing something worse and half-baked in the end..

Kermit had licensing issues in those days. And many bbs were focused on one specific system so many of the auto translate and nice compatibility features of Kermit weren’t that important.

And finally Kermit didn’t have great defaults especially compared to ymodem and zmodem. So getting good performance out of Kermit was much harder than the others.

All of that added up to much lower adoption outside of the mainframe world.

The very oldest (early 80s) Kermit implementations were limited to 96-byte packets. Kermit gained support for 4K and 9K jumbo frames, sliding windows, etc., and was generally faster than ZModem -- when there was a modern implementation. But a lot of BBSs (and also client-side communication software) did their own from-scratch Kermit implementation, which was tiny packets and no sliding windows, so it was slow. There's some discussion of it here: https://www.kermitproject.org/misconceptions.html#notslow

GOO. I remember Punter well.

It (or rather, they, as there are a number of Kermit books) is pretty good. I've got a few on my bookshelf. OK, I'll admit, more Kermit and UUCP books than I probably need, but oh well. The Kermit books are mostly available online now also: https://www.kermitproject.org/booksonline.html

Nowadays, Henson Associates wouldn't sue a 45 year old file transfer protocol over it, either; their rights to a name would generally not be universal to that degree, as long as it doesn't proliferate into a collection of software named after individual muppets. The letter of "sure that's fine" saves them legal fees each decade someone discovers it and I assume also exempts this single case from counting as trademark dilution.

Anubis.

https://hn.algolia.com/?q=anubis

Have you not been on the internet much lately? As the sibling comment pointed out, it’s Anubis, which shows up on a lot of websites of FOSS devs (and which has been discussed endlessly on HN).

Yeah. It's pretty unprofessional.

Even though the price of RAM has gone up recently, it's still (even if you don't adjust for inflation) several orders of magnitude cheaper than it was in 1981...

This graph (https://ourworldindata.org/grapher/historical-cost-of-comput...) doesn't contain the latest uptick, but just to get the picture:

1981: 1 TB of memory cost 12.8 billion $ (at least theoretically - I'm not sure if worldwide RAM production for that year was more than 1 TB?)

2023: 1 TB of memory cost 1088 $