As someone that also has a fondness for the old Macs, I absolutely love seeing projects like this. I love seeing an active, vibrant classic Mac community and new software for ancient machines. This is great!
No, but different people code for different reasons, and neither is more or less "wrong."
Some people (usually the ones who tend to like AI) see coding simply as getting a problem solved, and aren't as interested in how it happens.
Others see code as an artform, and a journey to appreciate in itself. For them, knowing that they are using their knowledge and experience to solve problems that not just anyone can, is part of the fun. It gives us a sense of worth and accomplishment, and that's why we like doing it.
To me it's similar to actual art/painting. Of course artists get upset at AI because they don't want their industry to leave them behind and make them feel unnecessary or less special.
But I don't fault the ones who don't think the way I do... it's just a different way of looking at it.
I agree completely. Personally, I think the art of programming was lost the moment we started using human-readable languages.
Some people see coding as simply getting a problem solved, and aren't interested in how the CPU actually does it. Others appreciate the craft of painstakingly arranging machine instructions, understanding every register and every clock cycle, and knowing they're solving problems that not just anyone can.
For us, that's where the sense of worth and accomplishment comes from. Using a high-level language to have a compiler do all the interesting work rather misses the point.
But I don't fault people who use Python, C++, or even assembly. It's just a different way of looking at it.
I built Flynn (well Claude did) and that's awesome you tested MoofTCP with it.
Coincidentally a couple of weeks ago I got annoyed my 512Ke couldn't go online and had Claude build talkip[1] which was fun and works surprisingly well.
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 |
Do you have a good sense of what alllowed you to improve it so noticeably? Maybe fundamental design errors in the original, more modern algorithms available to you, or knowing where to skip (or remove from the hot path) functionality that goes rarely or totally unused?
Our family Mac was the first machine I loved. Unfortunately I never got to use with so much as a modem, so I have no first hand experience with using MacTCP.
Without seeing the memory saving metric and error bars, these are marginal improvements. Kudos on making a thing but I'm not seeing it. I also don't have a 68k mac though so maybe I don't see this being a big deal.
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.
Yeah, I'd personally be happy about a new implementation even if it didn't really improve anything, just because I think there's value in having an actively-developed version.
> MacTCP is wonderful, but it is old, and on a 4 MB Mac Classic with a SCSI Wi-Fi/Ethernet adapter like BlueSCSI it can be slow to answer, hungry for memory, and awkward to set up.
Which... I don't own a Mac Classic, so I can't speak it its factual accuracy, but that doesn't sound like bashing.
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!
A usb4vc, rgb2hdmi and a tashtalk (for appleshare) can let an agent fully control a classic Macintosh.
It works so well I had Claude make vcctrl[1] with a full set of skills and an MCP server to fully automate deployment and testing. No more sdcard swaps.
Given the lack of protected memory and the various toolbox hooks, has anyone made an init to control the system? Back in the Classic Mac lab days we’d puppet an entire system with At Ease over local talk.
As someone that also has a fondness for the old Macs, I absolutely love seeing projects like this. I love seeing an active, vibrant classic Mac community and new software for ancient machines. This is great!
a vibrant community of AI agents, I guess
the community of humans still exists! i've got several hard drive images and regularly fire up system 6.0.7 or 7.1 to tinker in THINK C.
with a few simple modifications to minivmac, i have access to my host machine through toolbox calls.
Despite all the advancement of AI, i doubt Claude decided by itself to make a TCP stack for 68k Macs without some human's involvement.
No, but different people code for different reasons, and neither is more or less "wrong."
Some people (usually the ones who tend to like AI) see coding simply as getting a problem solved, and aren't as interested in how it happens.
Others see code as an artform, and a journey to appreciate in itself. For them, knowing that they are using their knowledge and experience to solve problems that not just anyone can, is part of the fun. It gives us a sense of worth and accomplishment, and that's why we like doing it.
To me it's similar to actual art/painting. Of course artists get upset at AI because they don't want their industry to leave them behind and make them feel unnecessary or less special.
But I don't fault the ones who don't think the way I do... it's just a different way of looking at it.
I agree completely. Personally, I think the art of programming was lost the moment we started using human-readable languages.
Some people see coding as simply getting a problem solved, and aren't interested in how the CPU actually does it. Others appreciate the craft of painstakingly arranging machine instructions, understanding every register and every clock cycle, and knowing they're solving problems that not just anyone can.
For us, that's where the sense of worth and accomplishment comes from. Using a high-level language to have a compiler do all the interesting work rather misses the point.
But I don't fault people who use Python, C++, or even assembly. It's just a different way of looking at it.
I built Flynn (well Claude did) and that's awesome you tested MoofTCP with it.
Coincidentally a couple of weeks ago I got annoyed my 512Ke couldn't go online and had Claude build talkip[1] which was fun and works surprisingly well.
1. https://github.com/ecliptik/talkip
BTW, the story behind "moof" and how it relates to old Macs: https://en.wikipedia.org/wiki/Dogcow
So disappointing to see no direct numeric comparisons with the original.
(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 |
Do you have a good sense of what alllowed you to improve it so noticeably? Maybe fundamental design errors in the original, more modern algorithms available to you, or knowing where to skip (or remove from the hot path) functionality that goes rarely or totally unused?
Our family Mac was the first machine I loved. Unfortunately I never got to use with so much as a modem, so I have no first hand experience with using MacTCP.
Without seeing the memory saving metric and error bars, these are marginal improvements. Kudos on making a thing but I'm not seeing it. I also don't have a 68k mac though so maybe I don't see this being a big deal.
Is not a marginal improvement an improvement worth having?
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.
Yeah, I'd personally be happy about a new implementation even if it didn't really improve anything, just because I think there's value in having an actively-developed version.
I mean I guess but the readme made it sound like this would be a night and day difference. A lot of bashing of the original.
? The only reference I see is
> MacTCP is wonderful, but it is old, and on a 4 MB Mac Classic with a SCSI Wi-Fi/Ethernet adapter like BlueSCSI it can be slow to answer, hungry for memory, and awkward to set up.
Which... I don't own a Mac Classic, so I can't speak it its factual accuracy, but that doesn't sound like bashing.
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!
A usb4vc, rgb2hdmi and a tashtalk (for appleshare) can let an agent fully control a classic Macintosh.
It works so well I had Claude make vcctrl[1] with a full set of skills and an MCP server to fully automate deployment and testing. No more sdcard swaps.
1. https://github.com/ecliptik/vcctrl
Given the lack of protected memory and the various toolbox hooks, has anyone made an init to control the system? Back in the Classic Mac lab days we’d puppet an entire system with At Ease over local talk.