You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the integration of macipgw into Netatalk, I took the time to try it out.
FTP is not reliable under NAT. However we should be able to figure out why. Active FTP was common in the early 1990s and we should strive to make it work. There are many reasons to use FTP:
A) Clients exist all the way back to System 6
B) FTP clients work with 68000 processors
C) Uploads and downloads are possible
D) Better usability wise than using XModem
E) Works with period-correct hardware (i.e. SUN workstation) all the way up to the most modern devices
Of the things we can still do in this current year, IRC and FTP still are available, with Gopher proxies for WWW access and not much else. SMB doesn't work on 68000 processors and it's debatable which one is better, SSH is too limited on 68K machines to have much value in the modern age, NFS can be just as bad as SMB and we won't even think about Telnet. NFS and SMB have more overhead than FTP does and can be slower.
There is a handful of FTP clients available, but my favorite on a 68K machine is Fetch 2.1.2, which as far as I can tell only supports Active FTP. PASV is an option with Fetch 3.0, but it's slower and takes up more space on disk for a 68K system running off a pair of floppy disks. This doesn't describe every person's situation, but I feel that if we can't at least make a good faith effort to identify and figure out the problem, we can at least understand it and provide a good explanation for it. If there's a problem with NAT, then we should figure out what the issue is. If it's macipgw, then our odds should be better.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Since the integration of macipgw into Netatalk, I took the time to try it out.
FTP is not reliable under NAT. However we should be able to figure out why. Active FTP was common in the early 1990s and we should strive to make it work. There are many reasons to use FTP:
A) Clients exist all the way back to System 6
B) FTP clients work with 68000 processors
C) Uploads and downloads are possible
D) Better usability wise than using XModem
E) Works with period-correct hardware (i.e. SUN workstation) all the way up to the most modern devices
Of the things we can still do in this current year, IRC and FTP still are available, with Gopher proxies for WWW access and not much else. SMB doesn't work on 68000 processors and it's debatable which one is better, SSH is too limited on 68K machines to have much value in the modern age, NFS can be just as bad as SMB and we won't even think about Telnet. NFS and SMB have more overhead than FTP does and can be slower.
There is a handful of FTP clients available, but my favorite on a 68K machine is Fetch 2.1.2, which as far as I can tell only supports Active FTP. PASV is an option with Fetch 3.0, but it's slower and takes up more space on disk for a 68K system running off a pair of floppy disks. This doesn't describe every person's situation, but I feel that if we can't at least make a good faith effort to identify and figure out the problem, we can at least understand it and provide a good explanation for it. If there's a problem with NAT, then we should figure out what the issue is. If it's macipgw, then our odds should be better.
Beta Was this translation helpful? Give feedback.
All reactions