5 ms·

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'

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

random778 11y ago
"1,000,000 times the performance and there's still an ASR-33 in the middle ..." [http://www.cs.unm.edu/~fastos/05meeting/PLAN9NOTDEADYET.pdf http://www.cs.unm.edu/~fastos/05meeting/PLAN9NOTDEADYET.pdf] There are people (Alan Kay et al.) apparently born with Nada's glasses, but industry as a whole doesn't believe them.
- thinkpad20 11y ago
  What does Nada's glasses refer to? I'm unaware of this expression and searching did not elucidate.
  - cathexis 11y ago
    They Live: https://en.wikipedia.org/wiki/They_Live https://en.wikipedia.org/wiki/They_Live
digi_owl 11y ago
At the other end, it allows things like: http://arstechnica.co.uk/information-technology/2015/08/surfing-the-internet-from-my-trs-80-model-100/ http://arstechnica.co.uk/information-technology/2015/08/surf...
angdis 11y ago
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?
- skriticos2 11y ago
  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.
- philh 11y ago
  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.
  - mikekchar 11y ago
    Italics. And even worse (because it is more common), bold. Hey, let's throw in "I want to have something bold and italics and this colour". Possibly I'm rare, but I'm frustrated very frequently...
  - jimktrains2 11y ago
    That isn't the terminal, though, that's the software using it. A VT100 could be made to do any of that.
  - joosters 11y ago
    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.
austinbirch 11y ago
A related talk, well worth watching: https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world
hollerith 11y ago
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.
jefurii 11y ago
Do you worry that all kinds of devices around you are using old technology like wires, resistors, diodes, and other such?
- leaveyou 11y ago
  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.
  - jefurii 11y ago
    Ha! Yeah I guess you would. 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.
  - digi_owl 11y ago
    Is that not mixing implementation and specification?
jimmaswell 11y ago
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"?
- leaveyou 11y ago
  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.

random778 11y ago

"1,000,000 times the performance and there's still an ASR-33 in the middle ..." [http://www.cs.unm.edu/~fastos/05meeting/PLAN9NOTDEADYET.pdf http://www.cs.unm.edu/~fastos/05meeting/PLAN9NOTDEADYET.pdf] There are people (Alan Kay et al.) apparently born with Nada's glasses, but industry as a whole doesn't believe them.

thinkpad20 11y ago
What does Nada's glasses refer to? I'm unaware of this expression and searching did not elucidate.
- cathexis 11y ago
  They Live: https://en.wikipedia.org/wiki/They_Live https://en.wikipedia.org/wiki/They_Live

digi_owl 11y ago

At the other end, it allows things like: http://arstechnica.co.uk/information-technology/2015/08/surfing-the-internet-from-my-trs-80-model-100/ http://arstechnica.co.uk/information-technology/2015/08/surf...

angdis 11y ago

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?

skriticos2 11y ago
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.
philh 11y ago
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.
- mikekchar 11y ago
  Italics. And even worse (because it is more common), bold. Hey, let's throw in "I want to have something bold and italics and this colour". Possibly I'm rare, but I'm frustrated very frequently...
- jimktrains2 11y ago
  That isn't the terminal, though, that's the software using it. A VT100 could be made to do any of that.
- joosters 11y ago
  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.

austinbirch 11y ago

A related talk, well worth watching: https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world

hollerith 11y ago

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.

jefurii 11y ago

Do you worry that all kinds of devices around you are using old technology like wires, resistors, diodes, and other such?

leaveyou 11y ago
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.
- jefurii 11y ago
  Ha! Yeah I guess you would. 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.
- digi_owl 11y ago
  Is that not mixing implementation and specification?

jimmaswell 11y ago

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"?

leaveyou 11y ago
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.