Hacker News Reader

Comment by fouronnes3 | Hacker News Reader

I'm wondering if one day we'll see an alternative to terminal technology that leaves behind in-band signalling for good.

View on HN

It wouldn't be called a "terminal" then, and wouldn't be connected to a tty (at least not on Unix-like OSs).

A lot of the power of the terminal metaphor is its simplicity and universality. You can implement one as a purely mechanical device (as has been done numerous times), or as an application running on your graphical environment. With a GUI terminal window you can run the very same applications you'd run on a ASR-33 teletype (although the sounds and smells won't be present).

I don't understand why such legacy support is necessary for 99% of my terminal use cases. I just want to run command-line programs in something that doesn't emulate weird hardware from last century, but uses OS standard text input and display. I will never be convinced that setting colors and cursor positions with keycodes is a good design.

I know it sounds unbelievable, but the default apps bundled with stock operating systems have not, in fact, been selected to exactly match your personal use cases.

There's actually this rather common expectation that the end user is the one that is in charge of personalising their system to their exact needs.

> I don't understand why such legacy support is necessary for 99% of my terminal use cases.

People need to run apps via uart or any other kind of remote link that might come in the future.

Yes, but even UART could handle some kind of a simple multiplexer protocol with multiple data streams.

It's the OS's job to expose a stream interface on top of a UART.

There was a graphical terminal called the Blit (sold as the AT&T 5620, succeeded by the DMD 630 and then the 730 "Multi-Tasking Graphical Terminals"). They implemented windowing, multiple streams, graphics and a lot more on top of serial connections. Essentially, multiplexing streams on top of "a UART". What you describe is more or less what they did back then, minus the windowing and multi-tasking functions, because we let the host OS deal with that.

There is even a neat 5620 emulator for macOS you can download from the app store. It requires a proprietary shell running for that tty, and I never took the time to figure out exactly how it works.

https://archives.loomcom.com/3b2/documents/DMD_Terminal/ has some good docs on that, and bitsavers.org has a ton more on the 630 and 730.

I hope one day someone finds a ton of them forgotten in a warehouse in the middle of a desert in the US, because, where I live people recycle old computers with an uncanny dedication (those barbarians!).

which would be in-band signalling again since uart is just timed 0's and 1's over a single tx and rx signal.

Windows has out-of-band terminal controls (size, ...) through a terminal API.

They decided it was a bad thing (also compatibility) and now they implemented in-band ANSI escape sequences and recommend them.

Fascinating. Do you know why?

The biggest one is compatibility with Linux console apps.

But also the difficulty of running a terminal session outside the traditional Windows command line app (think VS Code terminal pane).

https://devblogs.microsoft.com/commandline/windows-command-l...

Surely VS Code terminal pane can't display arbitrary unix terminal session, so this shouldn't be a concern. Arguably windows makes it easier: since color control is out of band, it can be ignored and only text is displayed.

because of the hacker community circle jerk. there was no rational reason. it's like back when people used ANSI.SYS to display a text file with colors. it's leet factor and has no application in reality.

I'm not sure if this was they reason for them, but one potential problem is synchronization between the two bands.

Plan 9 is built as a text first graphical system without any text terminal protocols. Like Unix it has a command line but it's just a typewriter, you cant control the cursor. Instead you have draw(3) which serves the graphical facilities of a system which you load assets into and issue draw commands to manipulate and display them. Of course to maintain backwards compatibility there is vt(1) which is a graphical program that transparently gives you a vt-100 or 220 display.

I don't think in-band signaling is the problem. You can describe anything with a sequence of symbols and I find it elegant to be honest. It's just that the protocols are outdated and fragmented.

>You can describe anything with a sequence of symbols

That does not mean it is efficient. If the data is on the GPU then with in-band signaling you have to copy it off of the GPU to send it to the terminal and then the terminal has to copy it back to the GPU.

Reply on news.ycombinator.com