The CPU emulator tries to be pretty accurate about timing, but the I/O is not throttled, so that might be unrealistically fast (depending on your Internet connection).
You can reduce the mouse speed a bit using Preferences.app.
The fundamental issue is that there’s two acceleration curves being applied (the guest OS’s and NeXTStep’s). I experimented with the unadjustedMovement option (https://developer.mozilla.org/en-US/docs/Web/API/Element/req...) but it didn’t seem to help (and if anything, made things feel even harder to control)
Author of the post/creator of the site here. To save everyone the click, NeXTStep 3.3 is probably the best release to try out: https://infinitemac.org/1994/NeXTSTEP%203.3 (it was the last release that ran well on the original NeXT hardware, OPENSTEP 4.0 and later were mostly focused on Intel support).
If you'd like to play the NeXT version of DOOM and explore a few other apps, they're in the "Infinite HD" drive (you can get to different drives by clicking on the computer icon in the Workspace file viewer).
One change that went into 1.36 is that you can no longer use an exit node while advertising one (https://github.com/tailscale/tailscale/issues/3569). The Mac UI was not updated for that in time, but the next release the menu items should be disabled correctly.
Can you sent a message to [email protected] about this and include a bug report ID (option click on the Tailscale menu icon and choose Debug -> Bug Report…)?
What would you recommend? dlopen is only used when running in CLI mode (which is not super performance sensitive), but not making it slower than it needs to be would be good too.
upx is not used in the macOS build (we only mention it as a possibility in https://tailscale.com/kb/1207/small-tailscale/, which is for embedded systems), so I have no done any benchmarking with it.
There is a way to build an even smaller version of Tailscale for embedded systems, though there are some trade offs with regards to ease of use and security. https://tailscale.com/kb/1207/small-tailscale/ has more details.
The solution we ended up with was partially a matter of the minimum change to fix the issue, and partly because we have a lot of platforms to cover with a small team, so the fewer platform-specific concepts we have (frameworks in this case), the easier it is to maintain.