8 ms·

HTTP "Referer" is the one that makes me sad.

hsbauauvhabzb 4y ago
The fact that terminals being an emulation of a teletype comes a close second. And the origins of /usr/bin a definite third.
- doctor_eval 4y ago
  A teleprompter? Is that a typo? Did you mean a teletype?
  - hsbauauvhabzb 4y ago
    Sorry yes teletype.
- mort96 4y ago
  Honestly, the typewriter interface is pretty useful. A program can make text appear on the screen by just writing ASCII (or these days, UTF-8) bytes. The only sad part is the design of escape sequences, but that's more a consequence of chaotic evolution rather than the fact that it's emulating a typewriter (and most of the evolution happened with the early software terminal emulators). Honest question: How would you design a simple text outputting protocol? Would it be radically different to how it's done today, or would it be the same basic ideas but cleaned up a bit?
  - R0b0t1 4y ago
    Hm, I've actually thought about that a lot. I'd probably keep the bytestream format. It is insanely useful. However I might open up multiple streams. Stream one is basic IO. Stream two could be formatting info. Streams above that implementation dependent, but you could probably start defining them for keyboard/mouse/HID IO or audio and video. Then to make it work over the internet just shove it over SSH or TLS. The one downside that has is if you separate the formatting from the data you can not recreate the session without keeping time info somehow. So, might need a fix for that. The only other real alternative I'm aware of is moving the formatting into the API "stream" that communicates using the machine ABI. This is a terrible solution. It's what Windows uses.
  - hsbauauvhabzb 4y ago
    I think that text output protocol is the wrong way of thinking about it. It should be a rich data stream capable of advanced features like objective stuff. Think ps, but then you’re able to navigate the output and perform additional functions. I think a subset of html would work for this. I think the biggest danger would be scope creep, but a terminal shouldn’t just be thought of as text.
    - benlivengood 4y ago
      Unix chose the midpoint between raw unformatted byte input and output (*argv being a raw byte array and stdout being binary or not existing at all and outputs would be configured by whatever was passed into argv) and structured results or a typed-function interface (like COM or CORBA or XML). Either extreme would have been untenable for a cohesive simple operating system, but I do wish Unix had leaned a bit farther toward the typed-interface design. We even had all the ASCII file/group/record/unit control characters.
    - wruza 4y ago
      Think ps, but then you’re able to navigate the output and perform additional functions We already have gtk, qt, appkit, win32, web based frontends for almost everything, and none of them produced anything remotely interoperable. The main advantage of just text is that you see its structure right there in a terminal and may reason about it without referring to the documentation of ps result-related set of structures with all the possible bells and whistles embedded into a large xml-like document schema (which is of course full of legacy and references to other specs, because compatibility and standardization).
  - hsbauauvhabzb 4y ago
    I’ve always been curious though, can VT escape sequences be used to perform user actions? E.g. can you coerce stdout to execute an additional command?
    - yencabulator 4y ago
      TTY emulators have a long history of being vulnerable to all kinds of nasty things. For example: https://seclists.org/fulldisclosure/2003/Feb/att-341/Termulation.txt https://seclists.org/fulldisclosure/2003/Feb/att-341/Termula... One would hope that we're past the bad times, but at the same time brand new projects like the kitty terminal emulator let stdout read and delete arbitrary files. And verifying something is safe is just hard, these are not even e.g. memory safety bugs, they're "features".
      - aumerle 4y ago
        No, kitty does not let stdout out read or delete arbitrary files. First of all stdout is an integer in a lookup table in your kernel, It cant read or delete anything. I assume you mean it lets programs read or delete arbitrary files by writing to and reading from the tty device. And even that is not true. The kitty graphics protocol does let a program delete arbitrary files in the TEMP directory. It does not let anyone either read or list the contents of any part of the filesystem.
        yencabulator 4y ago
        > First of all stdout is an integer in a lookup table in your kernel, It cant read or delete anything. Oh come on, you know what everyone means. "Output with potentially hostile content". Right now it seems kitty will happily delete e.g. /tmp/.X11-unix/X0. That sounds fun. https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-transmission-medium https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-trans... https://github.com/kovidgoyal/kitty/blob/5541e3c2ff441aea31940924ff952c968a77a30e/kitty/graphics.c#L423-L424 https://github.com/kovidgoyal/kitty/blob/5541e3c2ff441aea319...
        4y ago
  - thayne 4y ago
    > How would you design a simple text outputting protocol? If I were to design terminal control today, I might have a separate file descriptor for a pipe that is used for control communication instead of sending control codes inline with the text. And I would definitely have a way to query the capabilities of the terminal directly, instead of looking it up in a terminfo database.
    - Dylan16807 4y ago
      > I might have a separate file descriptor for a pipe that is used for control communication instead of sending control codes inline with the text. How do you keep that synchronized with the text for things like moving the cursor between words?
      - account42 4y ago
        Having all data in a single steam also makes it easier to buffer messages like a complete log entry with colors and then output that by just writing one buffer to stdout.
vikingerik 4y ago
At least that one saves a byte on every request. The cumulative savings are in the terabytes by now.
- deleted 4y ago
  [deleted]
- tomjakubowski 4y ago
  It saves 2TB/year, just on Google searches! (4e6 requests/minute)
  - 13of40 4y ago
    It's a big world. I'm sure there's someone offsetting this by keeping a 2TB hard drive just filled with 'r's.
    - a9h74j 4y ago
      > keeping a 2TB hard drive just filled with 'r's. r-chive.org
brians 4y ago
That’s to balance out Traveller.

The fact that terminals being an emulation of a teletype comes a close second. And the origins of /usr/bin a definite third.

doctor_eval 4y ago
A teleprompter? Is that a typo? Did you mean a teletype?
- hsbauauvhabzb 4y ago
  Sorry yes teletype.
mort96 4y ago
Honestly, the typewriter interface is pretty useful. A program can make text appear on the screen by just writing ASCII (or these days, UTF-8) bytes. The only sad part is the design of escape sequences, but that's more a consequence of chaotic evolution rather than the fact that it's emulating a typewriter (and most of the evolution happened with the early software terminal emulators). Honest question: How would you design a simple text outputting protocol? Would it be radically different to how it's done today, or would it be the same basic ideas but cleaned up a bit?
- R0b0t1 4y ago
  Hm, I've actually thought about that a lot. I'd probably keep the bytestream format. It is insanely useful. However I might open up multiple streams. Stream one is basic IO. Stream two could be formatting info. Streams above that implementation dependent, but you could probably start defining them for keyboard/mouse/HID IO or audio and video. Then to make it work over the internet just shove it over SSH or TLS. The one downside that has is if you separate the formatting from the data you can not recreate the session without keeping time info somehow. So, might need a fix for that. The only other real alternative I'm aware of is moving the formatting into the API "stream" that communicates using the machine ABI. This is a terrible solution. It's what Windows uses.
- hsbauauvhabzb 4y ago
  I think that text output protocol is the wrong way of thinking about it. It should be a rich data stream capable of advanced features like objective stuff. Think ps, but then you’re able to navigate the output and perform additional functions. I think a subset of html would work for this. I think the biggest danger would be scope creep, but a terminal shouldn’t just be thought of as text.
  - benlivengood 4y ago
    Unix chose the midpoint between raw unformatted byte input and output (*argv being a raw byte array and stdout being binary or not existing at all and outputs would be configured by whatever was passed into argv) and structured results or a typed-function interface (like COM or CORBA or XML). Either extreme would have been untenable for a cohesive simple operating system, but I do wish Unix had leaned a bit farther toward the typed-interface design. We even had all the ASCII file/group/record/unit control characters.
  - wruza 4y ago
    Think ps, but then you’re able to navigate the output and perform additional functions We already have gtk, qt, appkit, win32, web based frontends for almost everything, and none of them produced anything remotely interoperable. The main advantage of just text is that you see its structure right there in a terminal and may reason about it without referring to the documentation of ps result-related set of structures with all the possible bells and whistles embedded into a large xml-like document schema (which is of course full of legacy and references to other specs, because compatibility and standardization).
- hsbauauvhabzb 4y ago
  I’ve always been curious though, can VT escape sequences be used to perform user actions? E.g. can you coerce stdout to execute an additional command?
  - yencabulator 4y ago
    TTY emulators have a long history of being vulnerable to all kinds of nasty things. For example: https://seclists.org/fulldisclosure/2003/Feb/att-341/Termulation.txt https://seclists.org/fulldisclosure/2003/Feb/att-341/Termula... One would hope that we're past the bad times, but at the same time brand new projects like the kitty terminal emulator let stdout read and delete arbitrary files. And verifying something is safe is just hard, these are not even e.g. memory safety bugs, they're "features".
    - aumerle 4y ago
      No, kitty does not let stdout out read or delete arbitrary files. First of all stdout is an integer in a lookup table in your kernel, It cant read or delete anything. I assume you mean it lets programs read or delete arbitrary files by writing to and reading from the tty device. And even that is not true. The kitty graphics protocol does let a program delete arbitrary files in the TEMP directory. It does not let anyone either read or list the contents of any part of the filesystem.
      - yencabulator 4y ago
        > First of all stdout is an integer in a lookup table in your kernel, It cant read or delete anything. Oh come on, you know what everyone means. "Output with potentially hostile content". Right now it seems kitty will happily delete e.g. /tmp/.X11-unix/X0. That sounds fun. https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-transmission-medium https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-trans... https://github.com/kovidgoyal/kitty/blob/5541e3c2ff441aea31940924ff952c968a77a30e/kitty/graphics.c#L423-L424 https://github.com/kovidgoyal/kitty/blob/5541e3c2ff441aea319...
        4y ago
- thayne 4y ago
  > How would you design a simple text outputting protocol? If I were to design terminal control today, I might have a separate file descriptor for a pipe that is used for control communication instead of sending control codes inline with the text. And I would definitely have a way to query the capabilities of the terminal directly, instead of looking it up in a terminfo database.
  - Dylan16807 4y ago
    > I might have a separate file descriptor for a pipe that is used for control communication instead of sending control codes inline with the text. How do you keep that synchronized with the text for things like moving the cursor between words?
    - account42 4y ago
      Having all data in a single steam also makes it easier to buffer messages like a complete log entry with colors and then output that by just writing one buffer to stdout.

vikingerik 4y ago

At least that one saves a byte on every request. The cumulative savings are in the terabytes by now.

deleted 4y ago
[deleted]
tomjakubowski 4y ago
It saves 2TB/year, just on Google searches! (4e6 requests/minute)
- 13of40 4y ago
  It's a big world. I'm sure there's someone offsetting this by keeping a 2TB hard drive just filled with 'r's.
  - a9h74j 4y ago
    > keeping a 2TB hard drive just filled with 'r's. r-chive.org

brians 4y ago

That’s to balance out Traveller.