4 ms·

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

dist-epoch 3y ago
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.
- fragmede 3y ago
  Fascinating. Do you know why?
  - dist-epoch 3y ago
    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-line-inside-the-windows-console/ https://devblogs.microsoft.com/commandline/windows-command-l...
    - GoblinSlayer 3y ago
      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.
  - H4ZB7 3y ago
    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.
  - deleted 3y ago
    [deleted]
- thayne 3y ago
  I'm not sure if this was they reason for them, but one potential problem is synchronization between the two bands.
rbanffy 3y ago
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).
- fouronnes3 3y ago
  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.
  - SiempreViernes 3y ago
    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.
    - H4ZB7 3y ago
      [flagged]
  - rigid 3y ago
    > 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.
    - dmytrish 3y ago
      Yes, but even UART could handle some kind of a simple multiplexer protocol with multiple data streams.
MisterTea 3y ago
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.
d_tr 3y ago
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.
- charcircuit 3y ago
  >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.

dist-epoch 3y ago

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.

fragmede 3y ago
Fascinating. Do you know why?
- dist-epoch 3y ago
  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-line-inside-the-windows-console/ https://devblogs.microsoft.com/commandline/windows-command-l...
  - GoblinSlayer 3y ago
    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.
- H4ZB7 3y ago
  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.
- deleted 3y ago
  [deleted]
thayne 3y ago
I'm not sure if this was they reason for them, but one potential problem is synchronization between the two bands.

rbanffy 3y ago

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

fouronnes3 3y ago
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.
- SiempreViernes 3y ago
  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.
  - H4ZB7 3y ago
    [flagged]
- rigid 3y ago
  > 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.
  - dmytrish 3y ago
    Yes, but even UART could handle some kind of a simple multiplexer protocol with multiple data streams.

MisterTea 3y ago

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.

d_tr 3y ago

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.

charcircuit 3y ago
>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.