That was such a mind blowing experience coming from a DOS background. It would split your terminal horizontally and you could see each other type in real time.
Before the days of SMS, and even before the days of instant messengers like ICQ and AIM, I taught the split-screen `talk` command to my girlfriend so we could chat while I was working. We've been married for 20 years now.
The one program truly blew my mind at the time was Netrek - the first networked multi-player realtime graphical space fighting game. I've wasted so much time late into the nights playing the game in the lab instead of doing coursework.
The admin came to the lab from time to time and said we're hogging the workstations with the game and banned the game during daytime.
I remember ca. 2000 my best friend busting into my office, pushing me aside, logging in savagely to something and having a sight of relief.
He managed to send back a fleet or something - it was a real time game where you needed to do stuff at the right time (after sometimes a few hours). I do not remember the name of the game but it was fashionable for some time (not sure if it was text based or not)
Those games are still kicking around. Played Neptune's Pride a while back, would not recommend, seems designed to devour your waking (and what should be sleeping) life.
It's a fast paced multi-player space battle game with a top down graphic 2D view. It's like Command and Conquer, with each unit controlled by a different player.
"talk" was often bugged (and IIRC, used UDP) so it was soon updated by xtalk and then ytalk. ytalk was like the kitchen sink of talk, with a huge feature set and compatibility with everything that went before. Everyone had to get ytalk for sure.
Oh man, that brings it back! ytalk on the university student server was just about the first instant messaging system I used. My typing speed went way up after a few weeks.
Long before Unix talk, ITS (the Incompatible Timesharing System at the MIT AI Lab) had a program called UNTALK, written by a user named UNCOLA, that supported split screen text chat, back around 1992 or earlier.
Getting Started Computing at the Al Lab by Christopher C. Stacy. MASSACHUSETTS INSTITUTE OF TECHNOLOGY ARTIFICIAL INTELLIGENCE LABORATORY WORKING PAPER 235 7 September 1982:
>If you want to link to someone who is on another ITS machine, you can use the TALK program. The program is run by typing:
>*:talk uname@host
>To exit TALK terminating the conversation, the user who initiated TALK must type ^C.
>This method of comlinking is less versatile than the backnext commands, and only works across ITS machines (not locally).
>Another useful comlink program is UNTALK. UNTALK is similar to TALK but does not work across machines. However, on a display terminal, UNTALK splits the screen horizontally and allows the two people to type at the same time on their part of the screen.
The "backnext commands" he referred to would actually let you not only perform a text chat link (albeit not split screen), but also take over another user's TTY, to type into and see the output of their DDT shell and programs. There was no security other than obscurity on ITS, and that feature of linking to and sharing another user's TTY was meant for collaboration, helping, and teaching people, and also initializing and configuring output-only serial devices like line printers.
History of the Net is Important, by Keith F. Lynch:
>[...] ITS stood for the Incompatible Time-sharing System, an obvious take-off on CTSS, the Compatible Time-Sharing System. (Just as Unix is a take-off on the earlier TENEX, TWENEX, and MULTICS.)
>All four ITS machines also had UNTALK, a split-screen conferencing program similar to the later “talk” on Unix and PHONE on VMS. I was told it was written by a user whose ITS username was UNCOLA and who had committed suicide. I don’t know if it was the first program of that type, but it was the first I had seen.
Even before that, ARPANET TIPs supported a low level way of text chatting (not split screen) called a "TIP to TIP Link" (documented on page 5-4 of the "Users Guide to the Terminal IMP") where each participant bounced their packets off of a port on some host, without actually logging in or going through the host.
I did a summer program at MIT around then and remember a program that let you send popup messages in xwindows to other users or to a channel. You could subscribe to any channel and use wild cards. I remember being hacked by someone to subscribe "*" and being unable to use my terminal for a while until i figured out how to unsubscribe without being able to see what i was typing under the wall of messages. I thought it was called zyphermail but the interent seems to have no memory of this.
Back in the days of ARPANET mailing lists, there used to be an "educational" mailing list called "please-remove-me", that was for people who asked an entire mailing list to remove them, instead of removing themselves, or sending email to the administrative "-request" address.
So when somebody asked an entire mailing list to remove them, somebody else would add them to the "please-remove-me" mailing list, and they would start getting hundreds of "please remove me" requests from other people, so they could discuss the topic of being removed from mailing lists with people with similar interests, without bothering people on mailing lists whose topics weren't about being removed from mailing lists.
It worked so well that it was a victim of its own success: Eventually the "please-remove-me" mailing list was so popular that it got too big and had to be shut down...
...Then there was Jordan Hubbard's infamous "rwall incident" in 1987:
You might be thinking of Zephyr, which was part of Project Athena. My school was using Athena, and I occasionally received zephyrgrams from people at MIT.
I remember that one of the financial banking software we were using had an internal chat that was basically using "write"(?) underneath to send messages to another users terminal (it was running on Sun Solaris I think).
When I started college, all of our classes would assign a temporary (semester-long) account on one of the various Vax 11/780s supplied by the computing center.
Talk wasn't available yet (pretty sure we were on 4.1 BSD), so we'd use write(1) to communicate to each other (e.g., to figure out where someone was sitting in the lab). To block someone from writing to you (often desired, because write(1) would just spew over whatever you were currently looking at), you'd use the "mesg" command, which our University set as default to 'y'. I figured out that running 'mesg y' effectively just gave open write permission to your tty.
With that knowledge in hand, I started a practical joke where I'd remap someone's keys by redirecting an stty command to their tty, e.g.:
% stty erase e > /dev/tty03
which would make 'e' the backspace key for the duration of their terminal session. Much hilarity ensued.
It always annoyed me that the Unix terminal subsystem is too dumb to handle multiple writers to the same terminal at once without them potentially corrupting each other’s output. There are some techniques to reduce the incidence of this but none of them are foolproof, whereas a better design could be.
Maybe that was too hard when people used to use hardcopy terminals (actual ttys), although even there it possibly could have done better than it actually does.
But certainly by the time people had softcopy terminals with cursor positioning (like the DEC VT series and its emulators), a better experience could have been possible. For example, what if the functionality of curses was actually in the tty driver, so if another process wrote to the terminal it would appear as a new window, which could then be dismissed without altering the output of the underlying program? Or, to avoid putting too much in kernel space, the tty subsystem could live in a user-space daemon (possibly one process per terminal), and then applications would talk to it over IPC
>Or, to avoid putting too much in kernel space, the tty subsystem could live in a user-space daemon
On Unix, that's what "pseudo ttys" are for (i.e. /dev/pty*)!
For example, that's how Emacs lets you run multiple shell sessions in sub-processes, such that they have full job control (i.e. ^Z and ^C works to interrupt or stop sub-processes in the shell, since they're handled by the TTY). That's also how xterm and the Mac Terminal emulator work, providing the shell sub-process with its own pseudo tty with job control, even though there's not a corresponding /dev/tty* serial port driver. It's like a virtual serial port using a device driver with "TTY Line Discipline" but without an actual TTY.
ChatGPT correctly explains it better than I can or anything I can find with google:
Unix pseudo ttys, or pseudo-terminal devices, such as /dev/pty*, are a key mechanism in Unix and Unix-like operating systems for enabling communication between different processes. Pseudo-terminals are designed to provide the same interface and functionality as physical terminals or terminal emulators. They consist of a pair of devices, the master side (e.g., /dev/ptmx) and the slave side (e.g., /dev/pts/N), which are used to establish a bidirectional communication channel.
Pseudo-terminals are useful for running programs that expect to interact with a terminal, even when there is no actual terminal involved. This is particularly important for terminal-based applications like Emacs, which can run sub-shells within their own window or buffer.
Emacs, an extensible and highly customizable text editor, can leverage pseudo-terminals to run sub-shells, like bash or zsh, within its own environment. [Omitted detailed instruction on how Emacs sets up a pty for a sub-shell.]
By utilizing pseudo-terminals, Emacs can provide an integrated environment where users can work with both text files and interactive shell sessions seamlessly. This enhances productivity and enables users to harness the full power of Emacs' editing and navigation features while working with the shell.
> >Or, to avoid putting too much in kernel space, the tty subsystem could live in a user-space daemon
> On Unix, that's what "pseudo ttys" are for (i.e. /dev/pty*)!
No, that’s not what I was talking about. On just about every Unix, even with ptys, the line discipline code (or STREAMS modules for SysV-derived systems) still runs in kernel mode.
On Linux, you could implement something like what I was talking about with CUSE - have a character device which implemented the termios ioctls in a user-space daemon instead of in the kernel tty driver. That’s very different from how most Unix systems implement ptys
But what I was actually thinking about was a daemon which exposed over IPC an API a lot richer than termios. Something closer to curses.
Back when I was at university the x servers on our terminals were not secured, and other people could open output on your terminal. A favourite was a program that sent cockroaches scurrying around the screen whenever you moved a window.
My university got a bunch of SGI Indy's for cheap as a marketing ploy by the importer, and everyone could log in to all the machines. It became a lot of peoples first experience of the privacy implications of webcams (they had them built in) and taught a lot of people the value of paying attention to the privacy covers.
Jordan Hubbard wrote: "One of the people who received my message was Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he wasn't exactly pleased. (I hear his Interleaf windows got scribbled on)"
>Here's the explanation he sent to hackers_guild, and some replies from old net boys like Milo Medin (who said the program manager of the Arpanet in the Information Science and Technology Office of DARPA Dennis G. Perry said they would kick UCB off the Arpanet if it ever happened again), Mark Crispin (who presciently proposed cash rewards for discovering and disclosing security bugs), and Dennis G. Perry himself:
>Actually, Dennis Perry is the head of DARPA/IPTO, not a pencil pusher
in the IG's office. IPTO is the part of DARPA that deals with all
CS issues (including funding for ARPANET, BSD, MACH, SDINET, etc...).
Calling him part of the IG's office on the TCP/IP list probably didn't
win you any favors. Coincidentally I was at a meeting at the Pentagon
last Thursday that Dennis was at, along with Mike Corrigan (the man
at DoD/OSD responsible for all of DDN), and a couple other such types
discussing Internet management issues, when your little incident
came up. Dennis was absolutely livid, and I recall him saying something
about shutting off UCB's PSN ports if this happened again. There were
also reports about the DCA management types really putting on the heat
about turning on Mailbridge filtering now and not after the buttergates
are deployed. I don't know if Mike St. Johns and company can hold them
off much longer. Sigh... Mike Corrigan mentioned that this was the sort
of thing that gets networks shut off. You really pissed off the wrong
people with this move!
>Dennis also called up some VP at SUN and demanded this hole
be patched in the next release. People generally pay attention
to such people.
Jordan's infamous rwall incident is the kind of thing that might have triggered the rumored "explosive bolts" the Defense Communication Agency was once talking about installing, that would violently separate the MILNET and ARPANET in case of national emergency.
>DCA must have the ability to partition the ARPANET and MILNET in
case of an "emergency", and having non-DCA controlled paths between
the nets prevents that. There was talk some time ago about putting
explosive bolts in the mailbridges that would be triggered by
destruct packets... That idea didn't get far though...
