5 ms·

> It is really slow, with a text user interface or menu driven interface. It should be stressed that "really slow" is relative. 1200 baud for text, specificall

> It is really slow, with a text user interface or menu driven interface. It should be stressed that "really slow" is relative. 1200 baud for text, specifically scrolling text, is really usable. You feel it much more if you're constantly repainting a screen (because now you're sending 2K of text over at 120 cps). But scrolling simple prompts, simple menus, text messages are all fine at 1200 baud. That's faster than reading speed for most people. Systems were kept terse due to slower rates, but when it came down to actually "using" the systems, folks weren't typically shouting at their machines to go faster. When BBSs became more focused on software than messaging, speed became a much bigger issue.

thesuperbigfrog 5y ago
>> but when it came down to actually "using" the systems, folks weren't typically shouting at their machines to go faster. Did you ever download or upload files? >> scrolling simple prompts, simple menus, text messages are all fine at 1200 baud. Yes, on a 80 column text screen, there was only so much you could see at a time. People who have only seen web pages with inline images at high resolution that load instantly would probably see 1200 baud as slow.
- laumars 5y ago
  You are arguing the exact same points the GP made but using selective quoting to make it sound like a rebuttal.
jasonjayr 5y ago
Really slow -- as in waiting for the messaging system to search/display the list of all waiting messages, being loaded over a slow IDE hard drive with limited memory .... But yea. Once you got to 1200 baud; the phone line could fling text at you just beyond normal reading speed; if all it was doing is sending that. Add in a lot of ANSI or terminal escape codes, and it can feel a bit sluggish till 56kbps
- bitwize 5y ago
  Emacs still has aggressive terminal optimization code in it that calculates the smallest set of terminal commands necessary to repaint a screen in one state, into the desired state. So Emacs may still be usable -- not ideal but usable -- at 1200 baud. Something similar exists for vi, but I don't know if Vim has it.
  - DonHopkins 5y ago
    ITS Emacs (the original TECO verision) using the SUPDUP display protocol supported "line saving", so it could tell your terminal to stash a line in memory before overwriting it, so later it could almost instantly redisplay that line when you scrolled back to it. That was really great at 300 baud. 1200 baud too, of course. But modems used to cost about a dollar a baud. https://github.com/PDP-10/supdup/blob/master/supdup.mss#L635 https://github.com/PDP-10/supdup/blob/master/supdup.mss#L635 I posted this earlier about the Gosling Emacs screen redisplay algorithm. That was the code that RMS rewrote. https://news.ycombinator.com/item?id=26114104 https://news.ycombinator.com/item?id=26114104 To be fair, RMS a right to fuss and complain, because UniPress did kind of pull the rug out from under him. The display update optimization code that Gosling wrote was pretty ugly but amazingly brilliant dynamic programming stuff, and it had a skull-and-crossbones warning in the comments. RMS originally used the display update code from Gosling Emacs, but then rewrote it all from scratch for later versions of Gnu Emacs, after UniPress threatened him not to use it. As modems and networks became faster, and people started using window systems instead of terminals, having an "Ultra-hot screen management package" became less important. But it's a really cool algorithm, a great example of dynamic programming, and Gosling even published a paper about it! https://news.ycombinator.com/item?id=22849522 https://news.ycombinator.com/item?id=22849522 James Gosling's Emacs screen redisplay algorithm also used similar "dynamic programming techniques" to compute the minimal cost path through a cost matrix of string edit operations (the costs depended i.e. on the number of characters to draw, length of the escape codes to insert/delete lines/characters, padding for slow terminals, etc). https://en.wikipedia.org/wiki/Gosling_Emacs https://en.wikipedia.org/wiki/Gosling_Emacs >Gosling Emacs was especially noteworthy because of the effective redisplay code, which used a dynamic programming technique to solve the classical string-to-string correction problem. The algorithm was quite sophisticated; that section of the source was headed by a skull-and-crossbones in ASCII art, warning any would-be improver that even if they thought they understood how the display code worked, they probably did not. https://donhopkins.com/home/archive/emacs/skull-and-crossbones.txt https://donhopkins.com/home/archive/emacs/skull-and-crossbon... Trivia: That "Skull and Crossbones" ASCII art is originally from Brian Reid's Scribe program, and is not copyrighted. https://donhopkins.com/home/archive/emacs/mw/display.c https://donhopkins.com/home/archive/emacs/mw/display.c /* 1 2 3 4 .... Each Mij represents the minumum cost of +---+---+---+---+----- rearranging the first i lines to map onto 1 | | | | | the first j lines (the j direction +---+---+---+---+----- represents the desired contents of a line, 2 | | \| ^ | | i the current contents). The algorithm +---+---\-|-+---+----- used is a dynamic programming one, where 3 | | <-+Mij| | M[i,j] = min( M[i-1,j], +---+---+---+---+----- M[i,j-1]+redraw cost for j,2 4 | | | | | M[i-1,j-1]+the cost of +---+---+---+---+----- converting line i to line j); . | | | | | Line i can be converted to line j by either . just drawing j, or if they match, by moving . line i to line j (with insert/delete line) */ https://donhopkins.com/home/documents/EmacsRedisplayAlgorithm.pdf https://donhopkins.com/home/documents/EmacsRedisplayAlgorith... https://dl.acm.org/doi/10.1145/1159890.806463 https://dl.acm.org/doi/10.1145/1159890.806463 A redisplay algorithm, by James Gosling. Abstract This paper presents an algorithm for updating the image displayed on a conventional video terminal. It assumes that the terminal is capable of doing the usual insert/delete line and insert/delete character operations. It takes as input a description of the image currently on the screen and a description of the new image desired and produces a series of operations to do the desired transformation in a near-optimal manner. The algorithm is interesting because it applies results from the theoretical string-to-string correction problem (a generalization of the problem of finding a longest common subsequence), to a problem that is usually approached with crude ad-hoc techniques. [...] 6. Conclusion The redisplay algorithm described in this paper is used in an Emacs-like editor for Unix and a structure editor. It's performance has been quite good: to redraw everything on the screen (when everything has changed) takes about 0.12 seconds CPU time on a VAX 11/780 running Unix. Using the standard file typing program, about 0.025 seconds of CPU time are needed to type one screenful of text. Emacs averages about 0.004 CPU seconds per keystroke (with one call on the redisplay per keystroke). Although in the interests of efficency we have stripped down algorithm 5 to algorithm 6 the result is still an algorithm which has a firm theoretical basis and which is superior to the usual ad-hoc approach. More info: https://news.ycombinator.com/item?id=22850973 https://news.ycombinator.com/item?id=22850973
GekkePrutser 5y ago
Uhmmm try running your terminal at 9600 baud, and see how quickly you get bored with it :) And that's 4 times as fast. I did this for a while recently because I needed to access something over a serial port and it was not fun. 1200 is really slow.
- ericbarrett 5y ago
  This slow speed is one of the reasons the curses library and its descendants try to only repaint small sections of the screen using escape codes to move the cursor. Ironically it's also quite helpful with some modern terminals that are very heavyweight on graphical (pixel) redraws. E.g. I can refresh a TUI app using MacOS Terminal.app 30x a second using ncurses; but a naive wipe/redraw at that rate produces visible flickering and artifacts.
  - GekkePrutser 5y ago
    That's true, though it really surprised me how slow it felt. In the end I pumped the terminal speed up to 115k2 and it still felt very slow. Especially quickly paging through logfiles with 'less'. I remember spending part of my college days on green screen 9600 baud terminals (before they bought enough X terminals for everyone) and they felt snappy back in the day. And there was already a lot of TUI stuff going on back then. And in those days I didn't even know about gnu screen (or today's tmux) yet! I think I've just gotten spoilt with today's computer performance.
- dusted 5y ago
  1200 is not too bad on a bbs, I'm often doing that on my c64. 300 is slow! I used 9600 setting up an rs/6000 last week, and it was fast enough that I didn't notice. I live in a weird alternate universe.
  - GekkePrutser 5y ago
    Not that weird, I still have a bunch of SPARC Netras with serial ports only (no video) and several HP-UX boxes <3 I love that old stuff, and figuring out how to use their boot managers etc. On the Netras the configuration is actually stored on a smart card. Very cool.
VLM 5y ago
I would also toss out the concept that what moderns call "speed" is actually latency. Latency of even a 300 baud modem is essentially instant, in some cases faster than modern heavily buffered cable modem services. Hit enter and it starts responding instantly. People are used to a second or so latency on modern web pages, when shopping on amazon or whatever. Then they see a 300 baud modem vs a 30 megabit cable modem and think if "hit a key see response" takes a second at 30 megabits/sec then at 300 bits/sec 100K times slower, it must be "hit a key see response 100K seconds later" LOL no nothing like that at all. UIs were generally lower latency aka "faster" back in the old days than they are now.
- jart 5y ago
  Bufferbloat is easy to address if you've got a $50 ubiquiti router that can shape traffic. A bigger I'd say is when ISPs add jitter and other forms of unreliability to make SSH unusable unless you upgrade to business class.

thesuperbigfrog 5y ago

>> but when it came down to actually "using" the systems, folks weren't typically shouting at their machines to go faster. Did you ever download or upload files? >> scrolling simple prompts, simple menus, text messages are all fine at 1200 baud. Yes, on a 80 column text screen, there was only so much you could see at a time. People who have only seen web pages with inline images at high resolution that load instantly would probably see 1200 baud as slow.

laumars 5y ago
You are arguing the exact same points the GP made but using selective quoting to make it sound like a rebuttal.

jasonjayr 5y ago

Really slow -- as in waiting for the messaging system to search/display the list of all waiting messages, being loaded over a slow IDE hard drive with limited memory .... But yea. Once you got to 1200 baud; the phone line could fling text at you just beyond normal reading speed; if all it was doing is sending that. Add in a lot of ANSI or terminal escape codes, and it can feel a bit sluggish till 56kbps

bitwize 5y ago
Emacs still has aggressive terminal optimization code in it that calculates the smallest set of terminal commands necessary to repaint a screen in one state, into the desired state. So Emacs may still be usable -- not ideal but usable -- at 1200 baud. Something similar exists for vi, but I don't know if Vim has it.
- DonHopkins 5y ago
  ITS Emacs (the original TECO verision) using the SUPDUP display protocol supported "line saving", so it could tell your terminal to stash a line in memory before overwriting it, so later it could almost instantly redisplay that line when you scrolled back to it. That was really great at 300 baud. 1200 baud too, of course. But modems used to cost about a dollar a baud. https://github.com/PDP-10/supdup/blob/master/supdup.mss#L635 https://github.com/PDP-10/supdup/blob/master/supdup.mss#L635 I posted this earlier about the Gosling Emacs screen redisplay algorithm. That was the code that RMS rewrote. https://news.ycombinator.com/item?id=26114104 https://news.ycombinator.com/item?id=26114104 To be fair, RMS a right to fuss and complain, because UniPress did kind of pull the rug out from under him. The display update optimization code that Gosling wrote was pretty ugly but amazingly brilliant dynamic programming stuff, and it had a skull-and-crossbones warning in the comments. RMS originally used the display update code from Gosling Emacs, but then rewrote it all from scratch for later versions of Gnu Emacs, after UniPress threatened him not to use it. As modems and networks became faster, and people started using window systems instead of terminals, having an "Ultra-hot screen management package" became less important. But it's a really cool algorithm, a great example of dynamic programming, and Gosling even published a paper about it! https://news.ycombinator.com/item?id=22849522 https://news.ycombinator.com/item?id=22849522 James Gosling's Emacs screen redisplay algorithm also used similar "dynamic programming techniques" to compute the minimal cost path through a cost matrix of string edit operations (the costs depended i.e. on the number of characters to draw, length of the escape codes to insert/delete lines/characters, padding for slow terminals, etc). https://en.wikipedia.org/wiki/Gosling_Emacs https://en.wikipedia.org/wiki/Gosling_Emacs >Gosling Emacs was especially noteworthy because of the effective redisplay code, which used a dynamic programming technique to solve the classical string-to-string correction problem. The algorithm was quite sophisticated; that section of the source was headed by a skull-and-crossbones in ASCII art, warning any would-be improver that even if they thought they understood how the display code worked, they probably did not. https://donhopkins.com/home/archive/emacs/skull-and-crossbones.txt https://donhopkins.com/home/archive/emacs/skull-and-crossbon... Trivia: That "Skull and Crossbones" ASCII art is originally from Brian Reid's Scribe program, and is not copyrighted. https://donhopkins.com/home/archive/emacs/mw/display.c https://donhopkins.com/home/archive/emacs/mw/display.c /* 1 2 3 4 .... Each Mij represents the minumum cost of +---+---+---+---+----- rearranging the first i lines to map onto 1 | | | | | the first j lines (the j direction +---+---+---+---+----- represents the desired contents of a line, 2 | | \| ^ | | i the current contents). The algorithm +---+---\-|-+---+----- used is a dynamic programming one, where 3 | | <-+Mij| | M[i,j] = min( M[i-1,j], +---+---+---+---+----- M[i,j-1]+redraw cost for j,2 4 | | | | | M[i-1,j-1]+the cost of +---+---+---+---+----- converting line i to line j); . | | | | | Line i can be converted to line j by either . just drawing j, or if they match, by moving . line i to line j (with insert/delete line) */ https://donhopkins.com/home/documents/EmacsRedisplayAlgorithm.pdf https://donhopkins.com/home/documents/EmacsRedisplayAlgorith... https://dl.acm.org/doi/10.1145/1159890.806463 https://dl.acm.org/doi/10.1145/1159890.806463 A redisplay algorithm, by James Gosling. Abstract This paper presents an algorithm for updating the image displayed on a conventional video terminal. It assumes that the terminal is capable of doing the usual insert/delete line and insert/delete character operations. It takes as input a description of the image currently on the screen and a description of the new image desired and produces a series of operations to do the desired transformation in a near-optimal manner. The algorithm is interesting because it applies results from the theoretical string-to-string correction problem (a generalization of the problem of finding a longest common subsequence), to a problem that is usually approached with crude ad-hoc techniques. [...] 6. Conclusion The redisplay algorithm described in this paper is used in an Emacs-like editor for Unix and a structure editor. It's performance has been quite good: to redraw everything on the screen (when everything has changed) takes about 0.12 seconds CPU time on a VAX 11/780 running Unix. Using the standard file typing program, about 0.025 seconds of CPU time are needed to type one screenful of text. Emacs averages about 0.004 CPU seconds per keystroke (with one call on the redisplay per keystroke). Although in the interests of efficency we have stripped down algorithm 5 to algorithm 6 the result is still an algorithm which has a firm theoretical basis and which is superior to the usual ad-hoc approach. More info: https://news.ycombinator.com/item?id=22850973 https://news.ycombinator.com/item?id=22850973

GekkePrutser 5y ago

Uhmmm try running your terminal at 9600 baud, and see how quickly you get bored with it :) And that's 4 times as fast. I did this for a while recently because I needed to access something over a serial port and it was not fun. 1200 is really slow.

ericbarrett 5y ago
This slow speed is one of the reasons the curses library and its descendants try to only repaint small sections of the screen using escape codes to move the cursor. Ironically it's also quite helpful with some modern terminals that are very heavyweight on graphical (pixel) redraws. E.g. I can refresh a TUI app using MacOS Terminal.app 30x a second using ncurses; but a naive wipe/redraw at that rate produces visible flickering and artifacts.
- GekkePrutser 5y ago
  That's true, though it really surprised me how slow it felt. In the end I pumped the terminal speed up to 115k2 and it still felt very slow. Especially quickly paging through logfiles with 'less'. I remember spending part of my college days on green screen 9600 baud terminals (before they bought enough X terminals for everyone) and they felt snappy back in the day. And there was already a lot of TUI stuff going on back then. And in those days I didn't even know about gnu screen (or today's tmux) yet! I think I've just gotten spoilt with today's computer performance.
dusted 5y ago
1200 is not too bad on a bbs, I'm often doing that on my c64. 300 is slow! I used 9600 setting up an rs/6000 last week, and it was fast enough that I didn't notice. I live in a weird alternate universe.
- GekkePrutser 5y ago
  Not that weird, I still have a bunch of SPARC Netras with serial ports only (no video) and several HP-UX boxes <3 I love that old stuff, and figuring out how to use their boot managers etc. On the Netras the configuration is actually stored on a smart card. Very cool.

VLM 5y ago

I would also toss out the concept that what moderns call "speed" is actually latency. Latency of even a 300 baud modem is essentially instant, in some cases faster than modern heavily buffered cable modem services. Hit enter and it starts responding instantly. People are used to a second or so latency on modern web pages, when shopping on amazon or whatever. Then they see a 300 baud modem vs a 30 megabit cable modem and think if "hit a key see response" takes a second at 30 megabits/sec then at 300 bits/sec 100K times slower, it must be "hit a key see response 100K seconds later" LOL no nothing like that at all. UIs were generally lower latency aka "faster" back in the old days than they are now.

jart 5y ago
Bufferbloat is easy to address if you've got a $50 ubiquiti router that can shape traffic. A bigger I'd say is when ISPs add jitter and other forms of unreliability to make SSH unusable unless you upgrade to business class.