Why: to experience what it's like to do computing under such constraints, and to learn more about Unix programming.
I find it interesting to see how programs like pagers, web browsers and such deal with screen updates. I'm aware of the role of curses in general terms but it's fascinating to see it in action. For example, running from a PuTTY session scrolling up in less(1) is very efficient as it reuses the scrollback buffer, but not on macOS' Terminal.app (as in the video).
Any remarks or questions re. the concept or implementation are welcome. C programming is a hobby and a lot of this lower level Unix stuff was new territory for me.
Warning: Since the tritty program does not set the TTY baud rate (as shown by the “stty” command), programs cannot properly detect the slowness of the terminal, and will not compensate and/or optimize for it. Therefore this should not be seen as an accurate portrayal of life in 600bps.
I settled on that as the default because it's slow enough to clearly show it working from simple use (e.g. you don't need to open elinks to see it's slow) but fast enough to not discourage playing around with it.
Of course, there's a -b option that takes any rate between 50 and 57600 baud (the upper limit there because I'm not sure if it would keep up).
Why: to experience what it's like to do computing under such constraints, and to learn more about Unix programming.
I find it interesting to see how programs like pagers, web browsers and such deal with screen updates. I'm aware of the role of curses in general terms but it's fascinating to see it in action. For example, running from a PuTTY session scrolling up in less(1) is very efficient as it reuses the scrollback buffer, but not on macOS' Terminal.app (as in the video).
Any remarks or questions re. the concept or implementation are welcome. C programming is a hobby and a lot of this lower level Unix stuff was new territory for me.
Source: https://github.com/sjmulder/trickle