> Drawterm
Cool, thanks. Sadly, F-Droid tells me their build is too old for my version of Android.
16,445 karma · joined December 20, 2011
I have a website/personal wiki with a collection of links on various subjects: https://dbohdan.com/.
I edit my comments a lot (sorry).
My username means "connected to a network", not "network Ed". :-)
Cool, thanks. Sadly, F-Droid tells me their build is too old for my version of Android.
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.
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.)
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).
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.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>Common Lisp Screenshots</title>
<meta name="description" content="Today's Common Lisp applications in action">
<meta name="keywords" content="">
<meta name="generator" content="ORT - Ovh Redirect Technology">
<meta name="url" content="https://simple.photo/vindarel/c352e2c0177b24786fb40041657485dd/common-lisp-screenshots/">
<meta name="robots" content="all">
</head>
<frameset rows="100%,0" frameborder=no border=0>
<frame name="ORT" src="https://simple.photo/vindarel/c352e2c0177b24786fb40041657485dd/common-lisp-screenshots/">
<frame name="NONE" src="" scrolling="no" noresize>
<noframes>
<body><a href="https://simple.photo/vindarel/c352e2c0177b24786fb40041657485dd/common-lisp-screenshots/">Click here</a><hr></body>
</noframes>
</frameset>
</html>
<meta http-equiv="refresh" content="0; url=https://simple.photo/vindarel/c352e2c0177b24786fb40041657485dd/common-lisp-screenshots/">
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 like the idea of on-device programming like this. While I haven't used it, I know there is a DSiWare application Petit Computer that lets you implement more complex (sprite-based) games in a Basic dialect: https://en.wikipedia.org/wiki/Petit_Computer. As DSiWare, it has an official video trailer: https://www.youtube.com/watch?v=4AYlEo3rJHs.
"Art director" seems accurate for what a skillful user of art generators with a specific vision does.
I have also thought that since people find "director" lofty (thanks to auteur theory?) and therefore pretentious to assume, one could borrow "producer" from Vocaloid: https://vocaloid.fandom.com/wiki/Producer (alternative front end: https://antifandom.com/vocaloid/wiki/Producer).
http://dbohdan.sdf.org/ is my hobby site about the SDF Public Access Unix System, the Small Internet, and NetBSD.
If I were maintaining multiple large sites or working with many collaborators, I'd rely on something standard or extract and publish my SSG. For a personal site, I believe custom is often better.
The current generator is around 900 SLOC of Python and 700 of Pandoc Lua. The biggest threats to stability have been my own rewrites and experimentation, like porting from Clojure to Python. I have documented its history on my site: https://dbohdan.com/about#technical-history.
I was thinking that until I read the forum thread and Stephen Rosen's comments. Now I'm thinking the most useful meta-runner would just try popular runners in order.
I have put up a prototype at https://github.com/dbohdan/python-script-runner.
I see it has been proposed: https://discuss.python.org/t/standardized-shebang-for-pep-72....
pipx can run Python scripts with inline script metadata. pipx is implemented in Python and packaged by Linux distributions, Free/Net/OpenBSD, Homebrew, MacPorts, and Scoop (Windows): https://repology.org/project/pipx/versions.
Example:
#! /usr/bin/env gorun
//
// go.mod >>>
// module foo
// go 1.22
// require github.com/fatih/color v1.16.0
// require github.com/mattn/go-colorable v0.1.13
// require github.com/mattn/go-isatty v0.0.20
// require golang.org/x/sys v0.14.0
// <<< go.mod
//
// go.sum >>>
// github.com/fatih/color v1.16.0 h1:zmkK9Ngbjj+K0yRhTVONQh1p/HknKYSlNT+vZCzyokM=
// github.com/fatih/color v1.16.0/go.mod h1:fL2Sau1YI5c0pdGEVCbKQbLXB6edEj1ZgiY4NijnWvE=
// github.com/mattn/go-colorable v0.1.13 h1:fFA4WZxdEF4tXPZVKMLwD8oUnCTTo08duU7wxecdEvA=
// github.com/mattn/go-colorable v0.1.13/go.mod h1:7S9/ev0klgBDR4GtXTXX8a3vIGJpMovkB8vQcUbaXHg=
// github.com/mattn/go-isatty v0.0.16/go.mod h1:kYGgaQfpe5nmfYZH+SKPsOc2e4SrIfOl2e/yFXSvRLM=
// github.com/mattn/go-isatty v0.0.20 h1:xfD0iDuEKnDkl03q4limB+vH+GxLEtL/jb4xVJSWWEY=
// github.com/mattn/go-isatty v0.0.20/go.mod h1:W+V8PltTTMOvKvAeJH7IuucS94S2C6jfK/D7dTCTo3Y=
// golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
// golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
// golang.org/x/sys v0.14.0 h1:Vz7Qs629MkJkGyHxUlRHizWJRG2j8fbQKjELVSNhy7Q=
// golang.org/x/sys v0.14.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
// <<< go.sum
package main
import "github.com/fatih/color"
func main() {
color.Green("Hello, world!")
}
/// 2>/dev/null ; gorun "$0" "$@" ; exit $?
//
// go.mod >>>
// ...Can you elaborate? I don't share this experience, and I'm interested in bringing static typing to a language without static typing, so I'd like to understand. In new Python and JavaScript codebases, optional typing has had clear benefits for refactoring and correctness and low costs for me. Legacy codebases can be different.
- Perl's decline was cultural - https://news.ycombinator.com/item?id=46175112 - Dec 2025 (460 comments)
- (!) Ask HN: Why did Python win? - https://news.ycombinator.com/item?id=37308747 - Aug 2023 (839 comments)
- Ask HN: Why is Python so popular for ML/DS? - https://news.ycombinator.com/item?id=16207834 - Jan 2018 (19 comments)
- Ask HN: Is Python dying? - https://news.ycombinator.com/item?id=11100251 - Feb 2016 (352 comments)
- Python is now the most popular introductory language at top U.S. universities - https://news.ycombinator.com/item?id=8001337 - July 2014 (362 comments)
- Ask HN: Why Python over Ruby? - https://news.ycombinator.com/item?id=682101 - July 2009 (196 comments)
- Ask HN: What does Ruby have that Python doesn't? - https://news.ycombinator.com/item?id=283639 - Aug 2008 (223 comments)
My service has been managed by runit and, most recently, nitro (https://github.com/leahneukirchen/nitro). Both have run as the service's user. They supervise the process and handle logging. I have found the design of daemontools and its derivatives runit and nitro elegant; it lives up to the reputation.
#! /bin/sh
"exec" "/usr/bin/env" "uv" "run" "--quiet" "--script" "$0" "$@"
# /// script
# dependencies = [
# "cowsay",
# ]
# ///
import cowsay
cowsay.cow("Hello, world!")
#! /bin/sh
"exec" "/usr/bin/env" "pipx" "run" "$0" "$@"
# ...> - Display lid is very fragile at the top where the wifi antennas are and can easily crack there
That's great. I hope it works out, and you have CI for NetBSD, OpenBSD, and illumos, too.
Go's support for NetBSD has been a big boon to the more casual NetBSD user who isn't going to maintain a port. It means a random Go open-source project you use probably works on NetBSD already, or if it doesn't, it can be fixed upstream. Maybe Zig could play a similar role.
It's a shame GitHub doesn't have native CI even for FreeBSD on x86-64. I can see the economic case against it, of course. That said, the third-party Cross-Platform GitHub Action (https://github.com/cross-platform-actions/action) has made Free/Net/OpenBSD CI practical for me. I have used it in many projects. The developer is currently working on OmniOS support in https://github.com/cross-platform-actions/omnios-builder.
This is a pretty common sentiment. I think it equates using AI with vibe-coding, having AI write code without human review. I'd suggest amending your rule to this:
> For coding, you can use AI. For software engineering, you can't.
You can use AI in a process compatible with software engineering. Prompt it carefully to generate a draft, then have a human review and rework it as needed before committing. If the AI-written code is poorly architected or redundant, the human can use the same AI to refactor and shape it.
Now, you can say this negates the productivity gains. It will necessarily negate some. My point is that the result is comparable to human-written software (such as it is).
> The VP8 specification describes how to decode the image into Y'CbCr format. To convert to RGB, Recommendation 601 [REC601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders.
I assume all process memory may contain residual secrets. As a mitigation in a password manager and an encrypted file editor, I prevent process memory from being swapped to disk with https://pkg.go.dev/syscall#Mlockall.