I have read this with interest but the obsessive compulsive developer inside me keeps bothering me with questions like "isn't it worrying/depressing that today's best OS & applications are stuck with interfaces modeled with messy, leaky or no abstraction at all after devices used more than 100 years ago with no opportunity for radical improvement in sight ?". Sometimes I have the feeling that in software we are building skyscrapers on foundations of mud (usually after I read C code).
I think it is important to keep in mind that (for example) a Mac user that never uses Terminal.app or another terminal-emulation app probably has no reliance on the TTY abstraction. The abstraction is present in his operating system, but if it were absent or broken, the the user would probably not notice anything different.
I had to add the word "probably" to the above statement because I have not actually tried disabling the TTY subsystem in OS X and verifying that all the apps typically used by non-programmers continue to work normally.
Moreover, when our typical Mac user visits a web site, probably nothing goes wrong if the TTY subsystem on the web server is absent or disabled. (Of course, the administrators of the server will not be able to ssh into the server, but these days, a significant fraction of web servers are adminned using methods that do not rely on anyone's being able to ssh into the servers.)
I kind of agree with parent, though: during my more obsessive moments I do get worried / depressed that a large fraction of programmers are still reliant on software reliant on the TTY abstraction. Although I appreciate minimalist software and software ecologies consisting of many small tools (each of which does one thing well) as much as the next programmer, I would have expected that in 2015 there would be popular minimalist software ecologies not reliant on the TTY abstraction.
I will end my comment with 2 paragraphs designed to prevent nitpicking replies:
Yes, I know that Plan 9 is a minimalist software ecology not reliant on the TTY abstraction. Since on its best day, back when Bell Labs' Computer Systems Research Group ran Plan 9, Plan 9 almost certainly had fewer than 500 users, I would not call Plan 9 popular, however.
I do not dispute that the TTY abstraction remains the natural and the best tool for certain peripheral tasks, e.g., driving serial ports, which continue to have their uses, e.g., in hardware hacking because serial ports are so vastly less complex than something like USB.
An interface being used for over 100 years is hardly an argument that it's a bad interface. The opposite, really. Can you give more of a concrete reason or example why something is wrong with TTY other than "messy/leaky abstraction"?
I wish to be able to write this:
screen.print("text");
and when VGA displays are invented:
screen.print(someImageBuffer);
and when 3D accelerators appear:
screen.print(some3Dshape);
And it should just work.
OK, but you have to admit it does the job and few (none?) people complain about the limitations of VT100 terminal emulation.
If we could start from scratch what would a contemporary TTY be like? Would it be better in terms of functionality, multi-platform capability? What would be the advantage?
I don't know if it's fair to describe this as a limitation of VT100 (and I haven't RTFA yet), but some things that AFAIK terminals don't get right yet:
- Screen's scrollback buffer and my terminal's scrollback buffer don't know about each other. If I swap screen tabs frequently, my terminal scrollbar becomes useless. OTOH, if I use a tabbed terminal, I'm guessing it would use a different VT100 in each tab and that wouldn't work very well with screen.
- I'd like to be able to drop a marker in my bash prompt, and easily scroll back to the top of the previous command.
- For that matter, I'd like to be able to selectively hide the output of previous commands, and when I want to look at it again I'd like to be able to view it in less instead of just unfolding it in-place.
The scrollback buffer problem is annoying, but I just don't think there's a good solution to it.
screen (and tmux) basically store their own scrollback. The advantage here is that you can then page through the line history on another terminal or even another computer. The downside is that that your terminal (xterm/iterm/whatever) has to decide what to show when you page up. It has no way to read screen's internal scrollback, so it can either show you old non-screen lines, or hide the scrollback entirely. Switching into/out of screen will just add to the confusion.
(I think some terminals will hide the scrollback history when they spot the TTY in curses-style mode, and only bring it back when that process quits?)
One other annoyance for me is the behaviour of scrollback with a command like 'less' or 'more'. If you are paging down through a file, then scroll back up, some terminals will show you earlier lines of the file you are viewing, while others show you 'pre-less' scrollback.
There may not be a good solution currently, but I don't believe that no good solution is possible even in theory. Which makes me wonder if the VT100 paradigm is holding us back.
Like, if a VT100 understood the concept of tabs natively, it seems like this wouldn't be a problem. Screen could just map its windows onto VT100 tabs, and the terminal would know what to do with that.
I don't know if adding tabs to VT100 emulators would be remotely feasible, or a good idea if it was, but I expect there's something in this space that would be an improvement on what we have.
Eh. A real VT100 should understand tabs, you can set them with 'Esc H' oddly the DEC manuals don't say what the effect of resetting tabs would be (I'd guess it defaults to multiples of 8 characters).
Not \x08 tabs, but tabs like recent firefox and chrome use (as if you had several terminal windows with separate ptys and screen contents, but all in one window-manager window).
Uniformity and documentation. If you want to do something fancy with the terminal (ncurses like) and try go get into the topic, you'll find a dozen different standards that add bits and peaces with only very cryptic documentation and not much example code. It's quite frustrating.
I would be quite affected if I opened my desktop and noticed some bulky components using vacuum tubes mixed in only for compatibility with some historic peripheral my grandpa used in his twenties.
When I wrote my comment I was reacting to what I thought your point was: that the console itself might be obsolete and that we should just use binary protocols or some such. Now that I've read some more comments and watched the Destroy All Software video linked to in another comment I think I understand your point better.
In my day job I write software for archival preservation of digitized cultural materials, so I tend to think in terms of preserving access for generations. In this context the continuance of the whole UNIX model makes my job easier. I really really want for computers in the coming decades to be able to interact with, or at least emulate, my software and data.
I can see the limitations and of the TTY as implemented. I still think we need to preserve textual middle layer(s) and UIs, both for historical reasons and because those layers are very useful. I'm guessing we probably both agree about that.
This comes at a good time for me -- I'm getting interested in TTY emulation.
Currently on a learn-Emacs kick. Every couple of years I start using it then back off due to general cruftiness. However, it is undeniably featurefull, and the idea of just learning one last editor rather than a bunch of half-baked ones is appealing.
What about embedding Emacs, through a TTY interface in whatever new fancy cool TM editor experiment you want?
emacs is almost exactly the other way round - it provides its own TTY interface so you can run a shell or UNIX command inside its own buffers!
Good luck with the emacs learning. I've been a user for years and have barely scraped the surface of its features. Luckily, you don't need to be an expert in emacs for it to be a good editor.
The classic MacOS (not the UNIX-based one) has no terminal abstraction. The basic mechanism of the system is a GUI. That was a good move. (Not having a CPU dispatcher was a bad move; the underlying MacOS is very DOS-like.)
Then there's X-Windows, which was explicitly designed as a terminal system. There were special-purpose X-terminals once.
In the phone space, things are less terminal-like. Although, amusingly, the interface to the phone modem usually accepts the Hayes AT command set.
