marcusbasant

The most pro-EV administration in history

Interesting, I was considering trying to make an Ansible provider/plugin/whatever for System 6/7. Might reduce the back-and-forth with things like Infinite Mac on initial setup.

This is wild stuff, you should make a youtube demo of this if you haven't.

Thanks (again) for Flynn! I use it just about daily now, and it's been inspirational to my agents in developing patterns for 68k dev. I will have to check out your talkIP stack. I hope my claude didn't entirely steal it.

Given how hard it is to get the Classic online with 4MB, i can't imagine how big a PITA it is on the 512ke.

I can’t pretend to be an expert on the TCP/IP protocol but I asked my agent for its methodology. It says: smarter ACK handling, bigger TCP windows/segments, better retransmission discipline, an ASSM checksum routine, and ditching malloc for fixed memory space were some engineering decisions it made that lead to better performance.

Author here. Setting aside the effort and cost involved in refurbishing the Mac itself, I can assure you this was not a one-prompt project. It required some planning and steering to build something friendly without scope creep. Despite (or because of) the non determinism, there is still an art and science to engineering by prompt. Just as C and so forth were shortcuts to allow creativity without learning machine language and having to painstakingly manage a memory heap, LLM tools further allow us to manifest creativity.

Best description I heard is that LLMs are like “eyeglasses for the mind.” It levels the playing field for people like me who maybe don’t have time to learn classic Mac C, the retro68k dev environment, how the hell TCP/IP works at a low level, and all that. Maybe in the same way that professionally it’s allowing me to contribute to areas of the codebase that i couldn’t before and vice versa with my colleagues who used to rely on my area of expertise.

While I was certainly proud that I had some slightly unique or scarcer talent before, I don’t feel a need to be a gatekeeper about it in the new world (and I’m not suggesting you are), since I’m able to deliver a ton more value at a higher velocity now. That follows thru to personal projects like this, where I can finally do this kind of project and see results without losing too much of my precious free/family time.

I can say as the author, aside from subjectively better feel, the DHCP support and the pretty easy install are nice wins over MacTCP too. And just not relying on something that hasn't been supported for 30-odd years.

I'm not sure that anybody would expect a niche hobby project for rare 40 year old hardware to be "a big deal." Hope you're working on something fun and low-stakes too!

(I am the author - posting from an alt here)

It's pretty tedious to compare - Have to run diags, take screenshots, set up watchers on a modern machine, run comparisons on the classic mac hardware, and then transfer those back from the mac to the modern machine (I haven't set up a network share solution for the mac yet, so each transfer is power down and transfer via SD card), run thru agent for validation and feedback, and repeat for each iteration.

I went thru a few rounds of this (about 4 release candidates) before i decided that what I had was Good Enough and published it. I have noticed that Claude tends towards this "circumcizing the moquito" sometimes in the qa/validation phase.

Here's what I was able to measure from the test log data that I did transfer across:

| Measure | MoofTCP | MacTCP 2.1 |

|---|---|---|

| ACK of an echoed keystroke (median) | 2.8 ms | 4.5 ms |

| ACK of an echoed keystroke (worst case) | 16.8 ms | 17.6 ms |

| Delayed-ACK stall on interactive data | none | none |

| Wikipedia Reader, follow a link | 51.7 s | 53.2 s |

| Fetch 10 MiB over TAP | about 47–49 KB/s | about 49 KB/s |

| Advertised TCP window | 8,192 | 4,220 |

| Transmit stalls and retransmissions on the real Mac | 0 | not measured |