What you could probably do is take a Wii emulator like Dolphin and virtualize the CPU. Basically combine Dolphin and KVM_PR, getting ~native CPU performance while still needing to do 3D translation and simulate the IOS side of the Wii.

(Wii games run with the CPU in the supervisor state IIRC, so you can't just run them as processes under an OS, you'd either need a proper hypervisor or to catch traps caused by running supervisor instructions in "problem state", a la KVM_PR.)

Nowadays it runs SunOS 4.1 with a port of KDE 1 on it, and netboots Sprite for fun.

Of course, after porting the Sprite kernel to said laptop, I learned why the Linux kernel is littered with comments like this, and why it was never quite the beautiful, elegant, UNIX :tm: machine I imagined it was.

  /*
   * Are you now convinced that the Swift is one of the
   * biggest VLSI abortions of all time?  Bravo Fujitsu!
   * Fujitsu, the !#?!%$'d up processor people.  I bet if
   * you examined the microcode of the Swift you'd find
   * XXX's all over the place.
   */

(of course, the laptop itself is lovely -- the plastic shell has a nice rounded edge for your wrists, and the keyboard uses proper mechanical switches that feel much nicer than actual Sun keyboards of that era)

Several years ago now, I ran into a problem with playing audio on NetBSD/sparc. I had an RDI PowerLite laptop, which is 80% of a SPARCstation 5 clone stuffed into a laptop chassis. Part of the 20% different was the audio chip, which was the same AMD ISDN chip used in the SPARCstation 1/2, doing mu-law audio.

Whenever I'd play audio, the laptop would instantly reset. Huh. That's weird. I ended up figuring out that someone had recently massively overhauled the audio driver subsystem in the kernel, and basically the relevant audio driver was missing some mutex operation, and an assert() was panic'ing the kernel.

For a non SMP system, the lock wasn't necessary (IIRC) but the new code was being more rigorous and causing a kernel panic.

The patch was pretty easy, just adding a few locks/unlocks. But I could never figure out what I was supposed to do with the patch after.

I'm probably just stupid. I don't want to imply there's no path to do this, I just never figured it out. I didn't try for long either, since getting 8-bit mu law audio working was just something goofy I was doing for fun.

But for comparison, when I found a bug in the signal handler for 32-bit PowerPC, my memory was that it was pretty straightforward to produce a patch: find the relevant maintainer, open a dialogue, and eventually submit a patch: https://marc.info/?l=linuxppc-embedded&m=160963760120837

Neither fix was ultimately very important, and neither would have impacted more than a couple dozen people on the entire planet. But Linux got a patch, while NetBSD didn't...

Current NetBSD still has good support for running SunOS binaries, though, including graphical ones. I'm certain you could get a SunOS 4.x binary from pre-1992 to run on NetBSD/SPARC. I've no idea how far back you could potentially go on NetBSD/m68k -- probably quite a ways, especially if the binaries are statically linked. SunOS pre-1988 was all static linking!

(Running "real" 4.3BSD binaries might be hard -- I think NetBSD/VAX defaults to ULTRIX compat, which is an either/or thing versus strict Berkeley Unix compatibility. Same binary format, similar but incompatible syscalls/data structures.)

To your point, though, I don't know if I've noticed that big of an impact going from 5.5 to newer GPT models. If I had to switch back, I'm not sure how much I'd miss the newer ones. People talk about e.g. Opus 4.6 similarly, I've noticed.

The bigger change in OpenAI-land IMO is the models got cheaper, generally.

Though, it has been a while since I've used 5.5.

  Hybrid generation can also make post-training more efficient. Because latent thoughts remain auditable during rollout, an external critic can assign step-level credit to latent spans, branch promising trajectories, or terminate ones whose latent reasoning has already gone wrong, before any text or tool call is produced.

Qwen3.8 27B scored notably higher in most of the provided benchmarks, including the German-specific ones. The only "downside" is that inference is much more costly and slow, since it's a dense model.

Qwen3.8 Flash-Next appears to usually "benchmark higher" than 27B, while remaining fast.

I'm sure I could dig up the equivalent benchmarks for Flash and do the comparison myself, but as far as inference goes, it's messy. Consider that Qwen3.5 35B-A3B scores higher than Qwen3.6 on some of the German-specific benchmarks.

So it seems superficially plausible that Qwen3.8 Flash-Next might not be "27B but faster" in the ways that are important for this model. Or it could just "be superior" in all ways.

Either way, I don't think an LLM has to be "the best" at anything to be worthwhile, necessarily. And I kind of distrust benchmarks on top of that, so...

I get that doesn't invalidate the real "point" of the model, but...

  Sprite 2.077 pc386
  
          Welcome to Sprite
  
  root@cherimoya [1] # cp --version
  GNU fileutils 3.9
  root@cherimoya [2] # cp --help | grep recurs
    -r                           copy recursively, non-directories as files
    -R, --recursive              copy directories recursively
  root@cherimoya [3] #

But I think the Sprite kernel and the Sprite-specific libraries (Pfs, Pdev, Fs_Select, Td_), as well as the Sprite-specific userspace, were pretty incredibly pieces of software given the limited resources they were created with.

For that matter, John Ousterhout's text editor and terminal emulator, mx and tx, were the substratum that Tcl was built on. There's a single library on Sprite, libmx, which mx and tx are based on. Tcl basically grew as the command language of libmx, originally two separate entities, then by mx 2.4 it was fully incorporated:

  eery@cherimoya [1] > cd /sprite/src/lib/mx
  eery@cherimoya [4] > grep Tcl *.c
  mxCmdAM.c:    Tcl_Interp *interp;
  mxCmdAM.c: Tcl_Return(interp, Cmd_BindingGet(mxwPtr->cmdTable, argv[1]),
  mxCmdAM.c: interp->result = Tcl_Merge(bindingCount, bindings);
  mxCmdAM.c:    Tcl_Interp *interp;
  [...]
  eery@cherimoya [10] > grep LIBS ../../cmds/mx/local.mk
  LIBS  = -lc -lmx -lsx -lcmd -ltcl -lX11

  eery@cherimoya [11] > ls /sprite/lib/sun4.md | grep tcl
  libtcl.a
  libtcl5.a
  libtcl6.2.a
  libtcl6.3.a

Like someone else in the thread said, they might have been miserable, but they had potential, options, future ambiguity. After a certain point, those narrow and solidify. A miserable past where the future wasn't set feels more glamorous than a miserable present railroaded into a miserable future.

That's just vibes, though.

But, more importantly, why do you reckon DEQNA would be hard to connect to a modern network? NetBSD still supports it when running on a q-bus VAX: https://github.com/NetBSD/src/blob/trunk/sys/dev/qbus/if_qe....

It has some pretty broken behavior regarding multicast/broadcast traffic IIRC, but nothing putting it behind a vlan or separate LAN altogether wouldn't solve. I've got a little lsi-11 system under my bed I'm hoping to, one day, get the Fuzzball [0] distribution running on. The 22-bit address extension wirewrap the previous owner did needs to be redone entirely, so it's been a "later" project for years now, but I am hoping my little DEQNA will be able to ping the Internet still.

[0] https://en.wikipedia.org/wiki/Fuzzball_router

The one and only web host [2] written in Nim [0], running on Sprite [1] ;-)

[0] http://nim-lang.org/

[1] https://github.com/OSPreservProject/sprite/blob/master/sprit...

[2] https://pomelo.shockfox.net/pub/src/httpd.nim

One thing I really don't get, and I really hope I never do, is leave the front page/README/etc so ... Claude-ified (or GPT, plausibly, I guess):

  native SCSI and ethernet drivers, proven on real hardware

  Quake — runs; a benchmark more than a game, for now

  running under emulation, real hardware next

  The grimoire records both, confidence-tagged

I know others will say the same about seeing LLM usage at all, and yeah... I don't really have a defense. It just feels like the "bare minimum of decency" to, well, at least make the front page less LLM-sounding.

(Yes, they could have just replaced the "regular" function keys with copy/paste keys, but I feel like that would have gone over about as well as the various times they've, uh, tried to replace the function keys)