Show HN: Trickle/tritty, a 600 baud pipe/terminal | Hacker News Reader

terminal

asciinema.org

65 pointssjmulder33 comments

What: a 600 baud (configurable) pipe and terminal

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

Why 600?

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).

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.

The “tritty” program does not set the baud rate on the TTY (with for instance cfsetspeed()), so programs running still think the terminal is fast. This means that programs (like Emacs) that have many optimizations for slow terminals, won’t use them, even though they would have been appropriate.

Thanks! I had seen the attribute but wasn't aware of its use. I'll read up on it and try to implement it appropriately.

Interestingly vim does seem to disable syntax highlighting after a while, as can be seen in the video. Since the rest of the colours etc continue working I don't think it's a rendering artefact.

I don't know if I can deal with such a high speed terminal. It really is too fast for comfortable reading.

When I first saw a 300 baud Texas Instruments Silent 700 terminal, it was an eye-opener. Sure, the thermal paper printouts faded pretty quickly, but at 30 characters a second it was three times as fast as the Teletype machines I used before.

Even with all that speed, it wasn't too fast for the human mind to comprehend. Not like this 600 baud monstrosity.

https://en.wikipedia.org/wiki/Silent_700

Dialing in to the 1200 baud MODEM pool was both uneconomical and didn't even confer any great benefits. The 900 baud pool was only like a buck a minute and the 1200 baud pool was $4 per minute!

That said, I might actually have to get off your lawn. My first was a 900 baud cradle. Hayes, I think? Maybe Digital? That was a whole lot of years ago.

I feel like a young brat now starting directly from 1200 baud.

You young whippersnappers with your fast cars and fast modems!

If it helps, my first computer contact was an HP 9100 in '72. I just hated it and would avoid them for years afterwards. ;-)

I played on Silent 700s when I was kid. My father would bring one from work every now and again and I would be allowed to play on it... a bit anyway (I was ~10 at the time). I remember being in awe at how sophisticated some things could be... that you could actually put the telephone receiver in a couple of rubber cups and the machine could "talk" to a remote machine far away. Wonder of science that. And no, I'm not saying that sarcastically either! The phone we'd put in the acoustic couple modem was itself still a pulse-dialer with a cord (cordless phones still weren't generally on the scene just yet, though DTMF dialing was a thing, a newer thing, but a thing).

Between that and the copy of 101 BASIC Computer Games book I had (and still have) from that era, my career was really started unbeknownst to me.

Beautiful. I looked at obtaining a teletype or similar device but these things take quite and investment of not only money but also time and effort now.

Maybe it would be fun to try and write a small program at 300 baud or so with a line editor like ed or ex. Not sure though if terminal scrollback is a good substitute for having printouts to refer back to.

Pedantic note: in this case baud and bits per second may be the same rate, but they technically denote different things. Baud denotes the symbol rate. If you’re able to transmit more than one bit per symbol, then the baud and bps are different amounts. For example, 1200 bps modems transmitted 2 bits per symbol and thus were 600 baud. That said, the term “baud” was almost always misused as a synonym for bps.

Speaking of modems, the coolest one ever made was the Novation Apple-CAT II:

https://en.wikipedia.org/wiki/Novation_CAT#The_Apple-CAT_II

My first modem was 600 baud. I used to like waiting a long time before source code would be in and I could check & run it. I would read the description of the game/program and in my mind I used to make up what it would be like. The reality was always nothing like it, but that was ok.

There was something fun about reading/typing in/very slowly downloading game/program listings. Later I had the same feeling with going to meetups and standing in line for ages to copy sources onto floppies.

It doesn't address the TTY part, but for limiting a pipe's throughput there's also pv[0]. It's main purpose is visualising pipe transfers, but the throttling support is solid.

[0] https://www.ivarch.com/programs/pv.shtml

Why is that so soothing?

Because you can actually read the man page as it's being blitted to the screen...

My first acoustic coupler was 300 baud. When using a BBS, it was pretty much the speed at which i could read. 600 seems insane. ;-)

Curiously I've experience using 63 baud PSK on amateur radio, setting this to that same speed feels slower than when receiving text over the air. I guess this must be some extra overheads somewhere

PSK31 and it's derivatives use a variable length encoding of the characters (for example, space is 1 bit and e is 2 bits). For English-like text that'll cause it to be faster than tritty.

Sweet.. was thinking about doing this myself but never got one of those elusive round-tuits that everyone talks about..

I shall look forward to the line-speed setting updates and combine with GlassTTY220 font for the ultimate in terminal bliss..

http://sensi.org/~svo/glasstty/

Wow... That font reminds me of the last time I visited the living computer museum.

Silly feature request: add a flag to enable sci-fi terminal sounds as the text appears. Something like: https://www.youtube.com/watch?v=vWBpzveKvGA

Well, not a serial terminal, judging by that ^c in the video! Worst thing about a slow baud rate is if you cat a big file you're gonna sit there and wait until it finishes flushing down the pipe before your ^c makes it up.

I'd expect the ^C to immediately kill the connection. It sends a SIGHUP, which indicates the serial line has been disconnected. (Based on the DCD line, per Wikipedia.)

Btw, nice work on sway.

> I'd expect the ^C to immediately kill the connection. It sends a SIGHUP, which indicates the serial line has been disconnected.

you're ignoring the actual line transfer of the control C up the wire from the keyboard, through various buffers and such..

not a serial guru by any means, so I could be wrong about the specifics, but if you've ever used a serial terminal, you'll know OP is correct.

I'd think the ^C would be transmitted by a physical disconnect, i.e. changing the state of the DCD line. The DCD disconnect should immediately trigger an interrupt, which should trigger a SIGHUP.

To be fair, though, I can't say I've used a proper serial terminal.

It seems to depend on the program. cat is very quick to respond to ^C whereas in vim, less and elinks often a large amount of text is printed before ^C is echoed and takes effect, like you describe. I suppose that has to do with the size of chunks written.

In reality though it's more about the trickling than actually mimicking a proper serial connection.

> * It simulates the experience of using a terminal over a slow serial connection.*

Not really, in old days we had telnet over TCP/IP. Now there is mosh which uses smart redraw and UDP.

Not sure what your point is.

Perhaps you are too young to have experienced only having access to the internet via a shared UNIX system which in turn was only accessible by serial terminal?

Add in some variable latency to better simulate a slow link.

yasss this would be awesome..

maybe some configurable tiny buffers on each 'end' would also be superb.

+1000 if they can overflow and generate garbage that causes your terminal to hose up..

Reply on news.ycombinator.com