It's bad the other way, too. btop on a 50×232 terminal over an actual 57600 BPS serial line is unusable, even in 16-colour mode. It does not have even the most basic of full-screen TUI redraw optimizations, and outputs the entire screen again and again.
It's the version where a committee put in em-dashes to replace Jefferson's semi-colons, if those pictures are accurate. This is not unexpected given the provenance; but a semi-colon version would have made for a more interesting discovery.
Actually, it's orthodox; and it's fetch that isn't. FreeBSD is actually the odd one out, for having an extra tool for doing the same thing. The ftp tool in all of the BSDs, including FreeBSD, speaks HTTP, and has done since Luke Mewburn did lukemftp (later to be named tnftp) and Theo de Raadt did likewise, both based on the original 4.2BSD ftp, back in the middle 1990s.
That does not really present any argument that we should be teaching your way of working to VIM novices, instead of teaching them the obvious arrow keys first and the hjkl navigation later.
Yes, hjkl navigation is certainly one of the things that should learn about a vi clone. But are novices well served, in the 2020s, by that being the primary thing that they learn before anything else?
This is not a criticism of this WWW site specifically. The VIM doco has the same priorities, teaching hjkl navigation before arrow keys. (So do nvi2 and NeoVIM.) The problem is that the received wisdom, that arrow keys are some newfangled idea that might not have reached your terminal manufacturer yet, is massively out of date.
Even if one does not teach the arrow keys first, the BS SPC SO (Control+N) DLE (Control+P) set is surely worth teaching early on. One cannot make any reasonable argument that terminals might not have spacebars. (-:
Although Microsoft then spoiled that explanation a couple of years later by switching to a virtual machine system instead of the NT kernel emulating the not-present Linux kernel.
The naïveté of that position is that the users are not informed ahead of time that there's a random chance of a political protest popping up on their screen, so do not get to make an informed choice before it is perhaps too late. It's not mentioned in the doco. It's obfuscated in the source code as an 'extra tree' in an array of xpmtrees. The commit that added this had the commit message 'willem'.
It is interesting to read M. Allbery's comment side by side with the discussion here on Hacker News about a CLAUDE.EXE program with hidden behaviour that subtly changes the way that it outputs an information banner based upon timezones, hostnames, and domain names.
Further LWN commentary (as observed at https://news.ycombinator.com/item?id=48736518) is that the result would not be solely drama but potentially some fairly nasty real world consequences for some people.
I am sure that DARPA, BBN, USC Information Sciences Institute, and many others will be overjoyed to learn that they've been erased from history by the new narrative that Venture Capitalists Built Everything. (-:
We probably should not read too much into the fact that the Daily Mail's guide to what's currently on television no longer lists a documentary from 2023. Except, perhaps, that the Daily Mail's search engine gaming is clearly quite effective.
It's wild to see people having this argument in the subjunctive in 2026. I've had a convert-systemd-units tool since 2014, and provided Debian packages for the toolset that it is part of for around that long.
The annoying thing, looking at that, is that libnsfb (the library that netsurf-fb uses to construct its UI) once had a driver, deleted back in 2018, that could work directly with a Linux framebuffer device. This could have been easily adapted into a similar driver for wscons/wsdisplay/wskbd on OpenBSD and NetBSD.
Instead, libnsfb is now layered on top of SDL in the non-X11 non-Wayland case, with all of the dependencies and extra stuff that that entails, which of course you'll have to build. SDL3 explicitly doesn't handle dumb framebuffers and full wscons, explicitly requiring foreign KMS systems from Linux on the BSDs.
libnsfb then proceeds to ignore almost all of SDL anyway and draw its own UI directly, with SDL being little more than a glorified framebuffer-as-bitmap system with a couple of basic blitting operations.