spijdar

> Basically, we're about to recreate formalities, but managed by the private sector. To the extent that companies use AI in their work, they are going to have to track every pixel and every word and every note that is output by an AI system, and which parts were added or edited by humans after creation.

> That means that companies that want to protect their commercial interests aren't just going to get more protection based on how much work they get humans to do; they're also going to have to treat copyright's government-enforceable monopoly over expressive speech with the gravitas it deserves: not something you get automatically, but something you have to do real administrative work for.

Assuming this happens, wouldn't this mean that copyright becomes significantly less useful for people who aren't corporations and don't have the legal, financial, and administrative resources to produce this kind of bookkeeping?

The GPU would also be a problem. I don't think the Wii/Gamecube's GPU block really corresponds to any ATI/AMD card.

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.)

Yeah, I probably put too much weight on my anecdote. I didn't try looking for very long at all, and the case of Linux was made easier by the code being part of a small bundle of patches made by a couple of people, and the fact that Michael Ellerman was really nice, communicative on IRC, and accommodating to a very niche and bizarre set of patches.

I bought mine back in 2019, when I was ... 22. I was going through my "I want a real UNIX machine!" phase, and that's why I went through the motions of trying to make NetBSD "genuinely usable" on it.

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.
   */

Or, maybe, it was even more UNIX-y than I had thought. :-)

(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)

NetBSD has excellent binary compatible with 80s "unix", the problem is most (all?) of the 80s unix platforms it supports aren't x86.

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.)

It would be a little strange but not that strange for someone to have an idiosyncratic preference for GPT-5.5. It's still available as a Codex model (I think? It's selectable in Pi, not Codex itself), and it might perform differently enough from later GPT models that someone prefers it.

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.

Why not GPT-{5.6, 6, 6.1} Sol? They're all cheaper than GPT 5.5, and as "smart", if not "smarter", at least to me.

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

It's worth pointing out that merely having the chain-of-thought in latent space isn't by itself "The Most Forbidden Technique". Rather, it's doing what the authors propose as the next step in the paper:

  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.

Unless I'm misunderstanding, they're suggesting RL training against the CoT. Which, uh, that is The Most Forbidden Technique, as I understand it, when combined with the latent reasoning space. It allows for the model to "learn"/optimize for malicious behaviors that are just far enough away from the quantized token they're auditing against.

It's purely circumstantial, but 6 Sol supports no reasoning (same as 6 Luna and 5.6 Sol/Luna), while both Astra and 6.1 Sol do not support "reasoning = none".

Maybe?

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...

The absence of any comparison to Qwen3.8 Flash, another MoE model with a small-ish (6B) number of active parameters, is pretty striking. Instead, it's compared with Qwen3-Next 80B-A3B, a model released almost a full year ago.

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

> nobody™ still runs coreutils from 24 years ago.

  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] #

I'll take the honorary title of nobody ;-)

It's unfortunate that Sprite itself didn't really get absorbed into much of anything, and so doesn't have much of a footprint and isn't really remembered outside of LFS and a few even more niche bits.

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

Of course, even by 1992, there were multiple versions of Tcl coexisting... :-)

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

From my experience, it's possible to hate the high school/college years, but for them to also be comparably less terrible than what comes after, and so to look back at them with a strange kind of longing.

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.