
Show HN: Trickle/tritty, a 600 baud pipe/terminal - sjmulder
https://asciinema.org/a/9ujH6KQcVMF1VJztzXrfCpJqI
======
sjmulder
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](https://github.com/sjmulder/trickle)

~~~
amigoingtodie
Why 600?

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

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

~~~
sjmulder
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.

------
Stratoscope
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](https://en.wikipedia.org/wiki/Silent_700)

~~~
KGIII
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.

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

~~~
Stratoscope
You young whippersnappers with your fast cars and fast modems!

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

------
js2
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](https://en.wikipedia.org/wiki/Novation_CAT#The_Apple-CAT_II)

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

------
predakanga
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](https://www.ivarch.com/programs/pv.shtml)

------
amigoingtodie
Why is that so soothing?

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

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

------
dnel
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

~~~
carry_bit
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.

------
cat199
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/](http://sensi.org/~svo/glasstty/)

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

------
juancampa
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](https://www.youtube.com/watch?v=vWBpzveKvGA)

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

~~~
juliangoldsmith
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.

~~~
cat199
> 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.

~~~
juliangoldsmith
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.

------
jankotek
> * 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.

~~~
cpcallen
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?

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

~~~
cat199
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..

