3 ms·

It was probably a good abstraction for its time. The driver for the particular terminal was abstracted away in the OS, meaning that programs only had to handle

It was probably a good abstraction for its time. The driver for the particular terminal was abstracted away in the OS, meaning that programs only had to handle a pre-defined set of signals and IO. It is, however, a needlessly complex abstraction as of now. The lack of a real terminal device means that the OS maintains such pseudo devices for the sole purpose of being able to spawn multiple virtual terminals.

JonathonW 4y ago
But it's a convenient least-common-denominator and abstraction layer for text-mode applications. We might not be using physical teletypewriters now (or VT100-style video terminals), but it's really convenient to be able to write an application once and know that it's going to just work whether I'm running it in a text-mode console or in xterm or in gnome-terminal or over ssh or in tmux within any of those or... Sure, we could come up with some other standard, but the TTY interface is one we already have, with a huge amount of code already written to work with it; why fix what isn't broken? Contrast this with Windows; until recently, command-line applications there were pretty tightly coupled to the console host that they ran within [1]; this made remoting of command-line applications difficult and means you had to go through extraordinary hoops just to do things like replace the system's console UI with something like ConEmu or run a terminal within something like Visual Studio Code. More recent versions of Windows try to improve this situation, by adding support for Unix-style pseudoterminals [2] (what they call ConPTY) to the console subsystem. And since ConPTY terminals are based around the same standards as TTY terminals on *nix, things like OpenSSH remoting can now "just work", even for existing command line apps on Windows. [1] See here for some of the gory details of how this works and how it differs from the conventional *nix approach: https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/ https://devblogs.microsoft.com/commandline/windows-command-l... [2] Blog post describing the PTY infrastructure on Windows: https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ https://devblogs.microsoft.com/commandline/windows-command-l...
- zokier 4y ago
  > why fix what isn't broken? Its brokenness is debatable, see for example https://lwn.net/Articles/343828/ https://lwn.net/Articles/343828/

JonathonW 4y ago

But it's a convenient least-common-denominator and abstraction layer for text-mode applications. We might not be using physical teletypewriters now (or VT100-style video terminals), but it's really convenient to be able to write an application once and know that it's going to just work whether I'm running it in a text-mode console or in xterm or in gnome-terminal or over ssh or in tmux within any of those or... Sure, we could come up with some other standard, but the TTY interface is one we already have, with a huge amount of code already written to work with it; why fix what isn't broken? Contrast this with Windows; until recently, command-line applications there were pretty tightly coupled to the console host that they ran within [1]; this made remoting of command-line applications difficult and means you had to go through extraordinary hoops just to do things like replace the system's console UI with something like ConEmu or run a terminal within something like Visual Studio Code. More recent versions of Windows try to improve this situation, by adding support for Unix-style pseudoterminals [2] (what they call ConPTY) to the console subsystem. And since ConPTY terminals are based around the same standards as TTY terminals on *nix, things like OpenSSH remoting can now "just work", even for existing command line apps on Windows. [1] See here for some of the gory details of how this works and how it differs from the conventional *nix approach: https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/ https://devblogs.microsoft.com/commandline/windows-command-l... [2] Blog post describing the PTY infrastructure on Windows: https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ https://devblogs.microsoft.com/commandline/windows-command-l...

zokier 4y ago
> why fix what isn't broken? Its brokenness is debatable, see for example https://lwn.net/Articles/343828/ https://lwn.net/Articles/343828/