The column-number switch on the site is a clever idea, but I don't think it works. The columns are limited to a fixed height (that depends on their number). The fixed height forces readers to scroll down each column and then back to the top to read the next.
The site should imitate newspapers either more or less closely. In either case, first limit column height to something like 80% of the viewport to eliminate scrolling within columns. The column switch can select column width as a fraction of screen width.
More closely: when the content is too long for one set of columns, split it into multiple newspaper-style pages. The reader scrolls vertically through the newspaper pages.
Less closely: use columns arranged side-by-side in a horizontally scrollable container. The reader scrolls vertically to reach the container, then horizontally through the columns.
51% doesn't tell you much by itself. Benchmarks like this are usually not graded on a curve and aren't calibrated so that 100% is the performance level of a qualified human. You could design a superhuman benchmark where 10% was the human level of performance.
This is interesting, TFA lists Opus at 59. Which is the same as Claude Code with opus on the page you linked here. But it has Droid agent with Opus scoring 69. Which means the CC harness harness loses Opus 10 points on this benchmark.
I'm reminded of https://swe-rebench.com/ where Opus actually does better without CC. (Roughly same score but half the cost!)
(I didn't downvote you.) Plan 9 made some really cool design decisions, and I keep looking for places to use 9P. I also believe that Plan 9, as an artifact of its era, bet too heavily on the mouse and pixel-mapped graphics. Text, character-cell terminal emulation, and SSH won for good reasons. "GUI > terminal" is a separate matter from "Plan 9 > Unix".
In some important ways, even text with hacky escape codes is more useful and more robust than a fundamentally graphical interface. Text scales up and down with display size and pixel density. Text works over high-latency links and enables simple latency compensation like in Mosh. Text gives you universal copy-paste. Text is more accessible for humans and for machines.
I use a virtual terminal daily on my phone. If we literally used rio GUIs designed around the three-button mouse and desktop pixel density, it would be a lot less ergonomic. I'd like to see a successor to the VT220 lineage, but it's easier to imagine it built on text.
> I also believe that Plan 9, as an artifact of its era, bet too heavily on the mouse and pixel-mapped graphics. Text, character-cell terminal emulation, and SSH won for good reasons. "GUI > terminal" is a separate matter from "Plan 9 > Unix".
What era? That is exactly the workflow of everyone using macOS and Windows around here.
Connecting to cloud environemnts is also done via a mix of RDP, VNC, Web GUI based tooling, akin to a modern X Windows replacement.
Classic Xerox PARC-derived GUIs are very useful but not a replacement for the terminal. I also connect to my workstation over RDP, then use a terminal emulator.
Windows is a good example of what I mean. Windows system administration has become unmistakably more text- and console-centric over time with the rise of PowerShell. Windows has started shipping an SSH service and made its graphical interface optional on the server.
The web has avoided falling into the same trap. Web UIs are, for the most part, delivered to the user as hypertext rather than rio-style pixels. They rarely hard-require a mouse and have adapted well to touchscreens. Graphics in new web UIs is usually vector (SVG).
You are missing the part that PowerShell has exactly a Xerox PARC like experience, first with PowerShell Integrated Scripting Environment, nowadays the same experience is available in VSCode.
Replicating the experience of using something like Smalltalk transcript window.
Of course Windows has SSH support, it needs to interoperate with UNIX, given that UNIX won the server room.
No need for SSH to talk with Windows Core/Nano, it can be done via Web GUI administration, or PowerShell remoting.
> Replicating the experience of using something like Smalltalk transcript window.
As far as I know from Pharo, the Smalltalk transcript logs plain text and is less capable than xterm. So what you care about is not the capabilities of the terminal but having a long-lived interactive session/REPL or a REPL integrated with an editor?
> No need for SSH to talk with Windows Core/Nano, it can be done via Web GUI administration, or PowerShell remoting.
I was thinking of the administrator connecting to Windows from their Mac or Linux/BSD machine. I don't know if that's a good idea compared to them getting a Windows VM and using Windows-to-Windows PowerShell remoting as you suggest.
The concept of an XTerm it's far inferior to Emacs either as a REPL with a shell (eshell), the scratch buffer of the whole Elisp environment. Ditto with 9front with remote mounts and device binding. When you can use a remote component you can do NAT by importing /net in the spot from a remote machine. When you import /proc from another one you can suddenly debug processes of another machine.
Acme with shells are still far superior too. I can edit and script the editor's content and panes and run scripts on them. I can reuse Acme as a Mail, Usenet and maybe Irc client on the spot. I can cut, copy and paste with a mouse faster than a keyboard and yet maintain the Sam commands which are like the ex/ed ones but easier for some tasks (recursive searchs) without getting yourself mad with classic regexps. Heck, I can run filters a la vi under Acme but without being bound to a terminal and thus worried about the input/output on pipes.
How come a graphics powered REPL is less capable than a window that pretends to be a tty from the 1970's?
You can certainly use the same Web GUIs from macOS and GNU/Linux as well, as for Powershell remoting, no need for VM when Powershell nowadays is written in modern portable .NET.
> How come a graphics powered REPL is less capable than a window that pretends to be a tty from the 1970's?
I mean the Smalltalk transcript and its capabilities alone, not Smalltalk as a whole. The transcript apparently just logs plain text; xterm supports color and text formatting like bold and italic. I'm guessing that, per https://news.ycombinator.com/item?id=47058849, you'd want fancy text displayed separately in the GUI.
> as for Powershell remoting, no need for VM when Powershell nowadays is written in modern portable .NET.
The transcript on Smalltalk is a bad point when the environment itself (the object browser) it what matters in the end. You already have a logical browser far superior to boldted pipes under XTerm. Even 9front has a ndb(1) tool (not just useful for network settings) which can be reused as a small text database a la GNU recutils.
With rio windows I get an actual text stream to copy and paste (and grep and wahtnot), not the text, terminal control codes for bold and colour and often DEC decorations such as the ones in Nethack for walls.
With 9front you don't use SSH except against Unix. The motho there is too use 9p and import remote 'cpus', devices, auth against different servers... total orthogonality. You can spawn remote windows as if they were local. Heck, you can debug remote processes as if they were local too. By comparison SSH looks primitive...
No, it's the opposite. in order to send commands to a hosts you shouldn't need a terminal emulator (twice or thrice, depending on the SSH, tmux and the VTY subsystem under Unix) and even sending baud information. 9front just gives you the graphical window and the shell. Mosh? Ok, 9p and more can be almost stateless in order to not drop the connections. Still, you aren't bound to neither escape codes nor to crude hacks as SINWINCH and horrors to copy and paste text under Tmux/Screen. Don't get me started on trying to do such tasks with URL's.
Text? I do that under 9front, too. Heck, rc it's simpler there than sh itself.
I can bind remote machines and use their scripts as if they were my own. I can import remote devices. I can do stuff without resorting to crude hacks with openssl and nc. C itself it's far simpler. Text, you say? No locales, and UTF8 everywhere. I can freely resize the windows and still cut and paste stuff like nothing. It's 2025. The closest workflow under Unix would be Bitlbee + any client for it, msmtp and mbsync for Email and any graphical client against the SLRN cache in order to be as usable.
Rio can use different fonts just fine, you know. There are several users using 24 px fonts on HD screens without no issues. With riow you get 'virtual desktops' a la cwm/i3 and the like.
>Three button mouse.
I don't do mouse chords, but I get more universal copy and paste as I stated that the old Unix itself, with shorter and easier scripts again... than Unix.
On snarf/paste instead of the menu, modyfing rio/sam and the like for a keybinding can be something done under an afternoon. Riow can already manage windows and close then with keybings among the mentioned virtual desktops.
Oh, and BTW... for vi users... I consider the Sam regular expresions far more powerful than the vi keys themselves. I can highlight the text with the mouse and write a sam command (on acme too) which affects the selection and in an easier way than the old syntax. The best of both worlds. RSI? Well, that's a point for Unix, but with the Windows key + 1-4 the mouse usage can be reduced a lot.
And, again, the 9front API it's dumb simple; I'm pretty sure doing stuff like mapping the Windows key +j-k-l to mouse button 1-2-3 would be something relatively easy, even setting sticky menus. With that small patch tons of usability issues would go away. Meanwhile, under X.org, Wayland, evdev and the $toolkit of the day... good luck.
I don't think there is a client that will let me connect to 9front from Android, is there?
I see what you mean in this and the other comment. With 9front, you rely less on issuing commands to remote machines because you can directly access their resources. It's worth keeping in mind when comparing Plan 9 and Unix from a Unix user's perspective.
Being able to pick large fonts on the server isn't the same as leaving the fonts up to the client. When I use terminal emulators, SSH, and tmux, I can switch between different clients with different resolution, pixel density, and screen orientation and have the text display acceptably on each (minus text reflow for history, which is an issue).
> I consider the Sam regular expresions far more powerful than the vi keys themselves.
I agree, structural regular expressions seem like a better version of vi commands. It was reasonably easy to make some complex edits in https://github.com/martanne/vis when I tried it, and it felt like I'd only scratched the surface. I could see myself still using vis if it had tabs like Vim. (Tabs are a stated non-goal for vis.)
Drawterm, for sure. It should be under FDroid. On 9p itself, check termux.
> When I use terminal emulators, SSH, and tmux, I can switch between different clients with different resolution, pixel density, and screen orientation and have the text display acceptably on each (minus text reflow for history, which is an issue)
Oh, I understand. But you can set the font= environment variable before launching a tool and choose your own font for that window/tool. For instance, you can run sam with a totally different font than rio windows.
GitHub and Codeberg links on the site don't open for me. ("To protect your security, codeberg.org will not allow Firefox to display the page if another site has embedded it. To see this page, you need to open it in a new window.") This is because of the use of frames:
Preserving the examples for history. I wish HN had a <details> tag. The closest would be to collapse this comment.
Edit: Thanks, moderator. :-)
---
Turn 1, user:
is replacing my main PC with a NeXTcube a good idea?
---
Turn 2, K2.5 (bold font replaced with "*foo*"):
That's a very interesting question! The NeXTcube is a historically significant machine (famously used by Tim Berners-Lee to create the World Wide Web), but I need to be honest with you: *no, it would not be a good idea to replace your main PC with a NeXTcube* for practical modern use.
Here's why:
*Hardware Limitations*
- *Released in 1988* with a 25-33 MHz Motorola 68030 processor
- *8-64 MB of RAM* (compared to modern PCs with 16-64 GB)
- *No modern connectivity*: No USB, Wi-Fi, Bluetooth, or Ethernet as we know it
- *Display*: Monochrome or limited color, low resolution by today's standards
*Software Ecosystem*
- Runs *NeXTSTEP* (which evolved into macOS), but software support ended decades ago
- No modern web browsers, office suites, or development tools
- Cannot run Windows, modern Linux, or contemporary macOS applications
*Practical Realities*
- Finding working hardware is difficult and expensive (collectors' items)
- Replacement parts are scarce and costly
- No security updates for 25+ years
- File format compatibility issues with modern systems
*What You Could Use It For*
- Historical computing experience
- Running legacy NeXTSTEP software
- Museum piece or collector's item
- Learning about computing history
The Better Alternative
If you're drawn to the NeXT aesthetic or philosophy, consider:
- *Modern macOS* (direct descendant of NeXTSTEP)
- *Linux with a tiling window manager* (similar workflow)
- *Vintage computing as a hobby* alongside your main PC
Would you like suggestions for achieving a similar experience or workflow on modern hardware?
---
Turn 2, K2 (no bold font):
Short answer: No—unless your goal is specifically to collect or experiment with a historic machine, a NeXTcube is a terrible day-to-day replacement for a modern PC.
Why it fails as a “main” computer today
1. 30-year-old hardware
25 MHz 68040, 16–64 MB RAM, 400 MB SCSI disk (if you’re lucky), no built-in Ethernet, no USB, no Wi-Fi, no audio-in, 2-bit grayscale display. You will feel the slowness in everything from un-zipping a file to loading a web page.
2. Obsolete software base
NeXTSTEP 3.3 is gorgeous but frozen in 1995. No modern browser build, no TLS 1.3, no video codecs past MPEG-1, no Dropbox/OneDrive/Zoom/Slack/Steam/Spotify. You can ssh out, but you can’t run contemporary apps.
3. Storage and connectivity pain
SCSI-2 drives are dying; 50-pin replacements cost more per GB than a 4-TB NVMe stick. Getting files on/off the machine usually involves FTP-over-Ethernet or burning a CD-ROM on another computer.
4. No security updates
The last patch was released before the commercial web really existed. Putting it on the open Internet is asking to be scanned and possibly exploited within minutes.
5. Display and peripherals
The original 17" NeXT MegaPixel monitor is fixed-frequency 1120×832@68 Hz grayscale. Adapters to VGA exist, but color is impossible and refresh rates annoy modern LCDs. Sound is 16-bit 22 kHz mono; the optical drive is a 660 MB magneto-optical cartridge.
6. Power and parts
The cube power supply is a custom 350 W linear unit that runs hot; capacitors are drying out. When it dies you will be scavenging eBay or recapping it yourself. Spare motherboards cost more than a whole used ThinkPad.
7. Productivity software
There are serviceable versions of Mathematica, FrameMaker, Lotus Improv and OmniWeb 3.x, but file-format compatibility stops at Office 97-era documents. You will constantly round-trip files through another machine.
What it is good for
- Historical research, museum exhibits, retro-programming in Objective-C 1.0 or 68k assembly.
- Demonstrating the birth of the World-Wide Web (Tim Berners-Lee’s first server ran on a NeXT).
- Enjoying the UI that later became macOS (AppKit, Dock, Services, .app bundles).
- Collecting: a working color NeXTcube with turbo slab and original laser printer is a conversation piece worth several thousand dollars.
Practical compromise
Keep your modern PC (or a quiet mini-PC/Mac mini) for real work and run a NeXT emulator instead:
- Previous (68k emulator) boots NeXTSTEP 3.3 on macOS or Linux.
- VirtualNeXT (based on Previous) for Windows.
- QEMU’s “next” target is improving.
You get the look-and-feel, can compile legacy code, and still have 4K video calls when you need them.
Bottom line
A NeXTcube is a beautiful, important machine—buy one if you love vintage hardware—but do not voluntarily make it the computer you rely on to pay bills, join Zoom meetings, or play YouTube.
I agree. It seems like interpreting one instruction per frame is the developer's way to guarantee real-time performance. I don't want to discourage the developer from experimenting with this design. What I think they should do is determine the most instructions they can interpret each frame.
And the best Art Directors today almost all have a background in creating art themselves, in some fashion. I suspect that will remain true in the AI world as well, at least for the foreseeable future.
https://dbohdan.com/#meta is my personal wiki. Recently added pages include the first complete transcript of "The Dragon Speech" by game designer Chris Crawford and how I made Claude rework elegiac poems into Rupi Kaur-style "Instapoetry" using Gwern Branwen's technique.
http://dbohdan.sdf.org/ is my hobby site about the SDF Public Access Unix System, the Small Internet, and NetBSD.
The site should imitate newspapers either more or less closely. In either case, first limit column height to something like 80% of the viewport to eliminate scrolling within columns. The column switch can select column width as a fraction of screen width.
More closely: when the content is too long for one set of columns, split it into multiple newspaper-style pages. The reader scrolls vertically through the newspaper pages.
Less closely: use columns arranged side-by-side in a horizontally scrollable container. The reader scrolls vertically to reach the container, then horizontally through the columns.
reply