People are comparing this to 80’s 8-bit micro aesthetic, but I think the real comparator here is to 1. modern thin oscilloscopes, and 2. mainframe “support element” console pseudo-notebooks.
I want to talk a little bit more about that second one, because some people here probably haven’t heard of them:
If you buy a mainframe computer, there’s usually going to be a “local administration console” of some kind built in. This is usually something that looks like a laptop, but which isn’t a laptop per se; it’s repurposed laptop hardware—just the screen and the keyboard—built into hinge-out design such that it’s flat and tucked away into the mainframe chassis itself when not in use. When you pull it out, it springs out and the keyboard hinges up and locks, such that you can use it as a laptop.
But crucially, this “laptop” is not its own computer — rather, it’s wired to be the local display + keyboard of a little accessory server (the aforementioned “support element”) running within the mainframe chassis. And because that accessory server runs the top-level Baseboard Management Controller for the mainframe as a whole, that interface is the management interface for the mainframe — but not a watered-down IPMI web interface; rather, a full-fat GUI client interface with observability and control over the rest of the mainframe.
I’ve always found this “support element” peripheral hardware inspiring as a design approach. Not for the specific hardware involved, or the specific way these attach to the server, but for how the idea behind them could be generalized. Because this hardware interface is essentially an evolution of an older idea — putting a textual management interface as a TTY on a serial port, and giving the mainframe its own VT100-alike connected to that serial port. This is that, but graphical, and with support for things like plugging USB devices into the “laptop” hardware. What’s missing, is the protocol. Only this “laptop” can connect to the support element. But what if anything could?
Imagine if there was a modernized equivalent standard for “a serial port with a TTY attached to it”: a USB-C sub-protocol carrier supporting bonded USB and HDMI, but not to the host—rather, sandboxed under the IOMMU, routed to either the computer’s BIOS, its BMC, or its dom0 VM. Imagine if devices like laptops, tablets-with-keyboards, etc. could run “fullly-graphical terminal emulator” apps, that would support speaking this protocol with such hosts.
If this kind of standard existed, then, as an ops person, you wouldn’t need these built-in support-element peripherals on mainframes; you’d just carry around your laptop, and the mainframe would maybe have a stand to set it on and a retractable USB-C cable; and plugging the cable into your laptop with your fully-graphical terminal emulator open would get you a management console, supporting not just mouse/keyboard interaction but USB redirection, just as if you were running a local VM.
And you would get the same thing if you plugged your laptop into an Intel workstation supporting (and configured for) AMT; or any machine running a bare-metal hypervisor like ESXi. Plug a terminal into that port; get a management console.
Of course, it’s kind of clumsy to carry a laptop around. You’d want something more like one of these thin, modern oscilloscopes — something you can nestle in the crook of your arm while prodding at it with your other hand, or prodding at the computer-under-test itself.
Which — finally — is exactly the use-case DevTerm seems to be built for.
A shame that use-case is, for now, imaginary!
(I would note that Samsung’s DEX wire-protocol for “extending” Android devices to peripheral docks is very close, but not exactly the same. Maybe it could be adapted to fit this use-case!)