5 ms·
That article starts with too many inaccuracies to recommend it to anybody: - Teletypes were designed about a century before the era of mainframes. - Mechanical
by crosser 4y ago
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/ https://thevaluable.dev/guide-terminal-shell-console/
- acarl005 4y agoHi. 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.
- kevin_thibedeau 4y ago> This model was introduced with UNIX The UNIX IO system was adapted from Multics.
- epolanski 4y agoThat'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.
- torben-friis 4y agoI’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 ?
- nixpulvis 4y agoWe 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.
- szgupta 4y agoI 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.
- JdeBP 4y agoThat 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.
- 12311231231 4y ago> That article starts with too many inaccuracies to recommend it to anybody Why would you even read it after reading the title?
- deleted 4y ago[deleted]