Sigh. If you're doing bulk file transfers, you never hit that problem. If you're sending enough data to fill up outgoing buffers, there's no delay. If you send all the data and close the TCP connection, there's no delay after the last packet. If you do send, reply, send, reply, there's no delay. If you do bulk sends, there's no delay. If you do send, send, reply, there's a delay.

The real problem is ACK delays. The 200ms "ACK delay" timer is a bad idea that someone at Berkeley stuck into BSD around 1985 because they didn't really understand the problem. A delayed ACK is a bet that there will be a reply from the application level within 200ms. TCP continues to use delayed ACKs even if it's losing that bet every time.

If I'd still been working on networking at the time, that never would have happened. But I was off doing stuff for a startup called Autodesk.

John Nagle

Removing the "just" obviously makes it less condescending:

=> Why didn't you use sshd?

Removing the "you" could make it less personal:

=> Why was sshd not used here?

Removing the past-tense makes it more forward looking (the past can't be changed, but people often defend their past decisions especially because they are unchangeable, the future however is less threatening):

=> Could sshd be used here?

And to further open it up to criticism and add humility (which is important, since sometimes the obvious standard solution doesn't scale/work/apply to the use case):

=> Would there be any tradeoffs using sshd here?

This IMHO is the least-threatening and not too elaborate way to formulate this sentence.

But one thing can make this even less threatening. Don't write in on the code review for everybody to see, tell it to the person 1:1 in private and give them a chance to look good to their peers. The old adage "Praise in public, criticize in private" is still one of the most important things IMHO when relaying criticism.

A few examples:

Datatypes lets most newer Amiga programs load any type of file of a format that people have written datatype libraries for. E.g. all image viewers and editors that supports datatypes (pretty much all the were still under development when datatypes where introduced) can load pretty much any image format you can think of without any explicit application support as people are still writing them. Datatypes support also exists for e.g. music, word processing documents and others. For some applications it makes sense to have their own custom filters for some formats, but datatypes provides a minimum level of support for even obscure formats, as well as continued support for new formats for applications that are no longer in development.

Similarly any app that supports XPK can transparently decompress and compress any compression format you drop a library for into the right directory (and in fact there's a XPK datatype, that if installed lets any application that supports another datatype - such as for images, or documents - support compressed versions of the same).

Assigns is one of my favorites: Amiga applications typically load libraries from "libs:". "Libs:" is a virtual directory that is the union of a set of paths that typically includes "progdir:libs/" (but doesn't have to). "progdir:" again is a virtual directory that refers to the directory the application is installed in. It's somewhat like $PATH, except you can create your own assigns, and lookups are handled at OS level. You can somewhat simulate it on Linux with combinations of various obscure filesystem drivers, but there's nothing like the ease of use of assigns. Assigns are also given special treatment in filesystem dialogs/requesters, which meant that e.g. having a "docs:" and "pics:" assign or similar was common ways of creating shortcuts to the stuff you used the most, without needing any explicit support anywhere.

And these names also extends to volumes/labels of physical media. Think backup application that knows the label of the DVD you burned file X to. Want to restore it? Backup application could ask you to insert DVD labelled "August 2014", or on AmigaOS it would just try to open the file "August2014:X" and AmigaOS will ask you to please insert volume "August2014" with no application support needed. This is admittedly a feature that was far more important when dealing with physical media was more common.

OS support for running controls/widgets (gadgets in AmigaOS) in separate threads ensures a high degree of responsiveness even when the machine is under high load.

Ease of writing filesystem drivers means you find stuff like FrexxEd - a text editor that exposes the open buffers as files, so that you can operate on the open buffers with any tools that can process a file.

Pervasive AREXX support meant pretty much every application can be fully scripted, either "natively" in AREXX, or from pretty much every language by talking to the applications AREXX port.

> what lessons are you talking about?

Decomposing applications and treating the system as a whole, for starters. For AmigaOS this was an absolute necessity: You wouldn't have the space to effectively multitask on a machine with 512KB RAM if everyone needed to pull in huge amounts of different dependencies. So there was a lot more effort into standard components, or replacements for standard components, that allowed applications to do more with very little.

Not being wasteful, certainly. Above I mentioned FrexxEd. The custom filesystem in FrexxEd might seem like unnecessary bloat. But on a small system it meant that you did not have to write to a temporary file in T: which would commonly be assigned to RAM:T/ which would mean you'd suddenly have a second copy of the file in memory, instead of just processing what was already there. Similarly, the way cut and paste is implemented in AmigaOS is intended to be able to deal with efficient buffering to T: in case it has been re-assigned to a slow device (even a harddrive would have been slow enough to make the UI sluggish if you were to cut and paste a large chunk of data).

But the things that made these applications work well on such small machines also makes them blazingly fast on modern machines where UI's are somehow still sluggish even when they don't add much functionality (it's another matter if a super-complex UI is slow)