The same reason tar and dd and practically everything operates on blocks not bytes, plus the same reason the shell doesn't act until eol delimiter, the opportunity to edit before submit.
I think talk could get away with it because on a shared local host both sides are accessing the same local physical resource directly, no tcp packet per byte.
The default `talk` and talk service were trash, and often there were protocol errors that would cause you to hang forever, vainly waiting for an answer (classic talk used UDP only.)
Eventually, a few competing offerings sprang up, in the form of `ntalk`, `xtalk` and `ytalk`. These were superior in every way, and sometimes required swapping out the service attached to inetd. Once you did that, it was a fantastic way to chat live and direct on Unix. Way better than the `write` we started with!
Great idea! After all why reinvent the wheel with TUI libraries built in a popular browser-based front-end javascript framework?
We must stand on the shoulders of giants!
I used talk back in 90ties and loved it and still missing it. Interfacing this with LLM is a nice touch.
I remember using talk back when first learning Linux in college. I enjoyed the character-by-character aspect of it.
Until you wind up chatting with a painfully slow typist. Even worse is when they typo a lot and take the time to fix them on the fly
Yes, I've wondered many times why there are no modern (human to human) chat interfaces that implements that, rather than sentence by sentence.
The same reason tar and dd and practically everything operates on blocks not bytes, plus the same reason the shell doesn't act until eol delimiter, the opportunity to edit before submit.
I think talk could get away with it because on a shared local host both sides are accessing the same local physical resource directly, no tcp packet per byte.
I get the same feeling when I see my colleagues writing in Notion, it's like invading their privacy.
It worked over the network as well
The default `talk` and talk service were trash, and often there were protocol errors that would cause you to hang forever, vainly waiting for an answer (classic talk used UDP only.)
https://en.wikipedia.org/wiki/Talk_(software)
Eventually, a few competing offerings sprang up, in the form of `ntalk`, `xtalk` and `ytalk`. These were superior in every way, and sometimes required swapping out the service attached to inetd. Once you did that, it was a fantastic way to chat live and direct on Unix. Way better than the `write` we started with!
Yes, in fact, when we talk about talk, we're really talking about ntalk. Keep in mind that it went through a very difficult time.
It should talk about it.
Interesting chat widget in the corner.
I've been looking for something similar I saw once, it was a chat widget connecting to everyone looking at the same webpage.
But it was called something like "aarrrgh!!" (the pirate), and I can't remember the name of the damn thing!
With today's technology, I miss being able to interact with other readers who are reading the article at that moment. It's so much fun!