Hacker News Reader

Comment by crosser | Hacker News Reader

That article starts with too many inaccuracies to recommend it to anybody: - Teletypes were designed about a century before the era of mainframes. - Mechanical teletype did not have an "I/O driver" in it. - OS on Mainframe computers did not have a "Kernel", and neither "I/O driver", "Line discipline" or "TTY driver". This model was introduced with UNIX, the OS that ran on minicomputers. - Was ChatGPT used to write this article? ;)

I've recently stumbled upon an article on the same topic, but containing competent and accurate information, I have a link because I recommended it to a friend: https://thevaluable.dev/guide-terminal-shell-console/

View on HN

Hi. I definitely took some liberties with terms here. For example, I said "I/O driver" instead of, say UART driver because I didn't want to get overly specific on the historical part. That wasn't the focus of this article. Thanks for linking this other one, as it fills in those parts well.

That's quite an unnecessarily toxic comment, besides all your criticism seems fixated with the introduction on teletypes.

I enjoyed the blogpost, I trust the authors of a terminal emulator to give me a good overview on the topic and I enjoyed it.

I’ve seen many times descriptions of how original teletypes work and how that influences modern terminals.

However, something that I have not seen yet and I’d love to check is an attempt to redesign the terminal from scratch separating historical baggage from the parts that still make sense nowadays.

How would a designer create this tool without the historical precedence? Is tradition holding us back? What new standards could we reach ?

I love this sentiment. Your questions would make for a very interesting post.

While we haven't rebuilt from absolute ground zero, Warp is definitely trying to extend the capabilities of a terminal (emulator) from what's historically been possible. For example, we introduced a dedicated input editor so you can have an IDE-like experience in the terminal. It's fundamentally different from how input is entered in a traditional terminal. But with this innovation, we've had to be careful to ensure that all the input features you expect in a normal terminal (even obscure ones like `alt-.`) work how you'd expect, _and then some_.

Overall though, starting from scratch is hard because we need to stay backwards-compatible with all the CLIs we use everyday.

That was already done in the 1980s and early 1990s. Microsoft/IBM operating systems evolved the notion of consoles, still-handle-based I/O devices that responded to additional first-class I/O system calls (beyond the read/write/ioctl model) for 2-D addressing, direct output buffer manipulation (including reading of the output buffer), keyboard input that did not hide the decoding of key chords into characters, and mouse input.

We like some of the baggage for two main reasons. 1) some designs were well thought out back when resources and performance really mattered, a lot, so they make for fast and efficient implementations enforced by spec. 2) perhaps more importantly, we like our old tools to continue working, plain and simple.

> This model was introduced with UNIX

The UNIX IO system was adapted from Multics.

> That article starts with too many inaccuracies to recommend it to anybody

Why would you even read it after reading the title?

Reply on news.ycombinator.com