spijdar
> 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?
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.aLike 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.
The one and only web host [2] written in Nim [0], running on Sprite [1] ;-)
[1] https://github.com/OSPreservProject/sprite/blob/master/sprit...
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)
The short is that yes the GNOME/KDE apps do often look more impressive, but they suffer the same sort of malaise which seems to have infected Linux desktops sometime since Eternal September, and between the sporadic crashing and "this doesn't feel right", it's really hard for me to accept "It's more polished than AOSP!".
pmOS's installation page opening with a warning:
Make sure you read state of postmarketOS before installing postmarketOS.
The goal is to make postmarketOS usable for everyone, but we are not there yet. Usability and most importantly stability issues need to be worked out first. If you are looking for an OS that is as usable as iOS or Android, this project is currently not for you.
I'm not saying that's an equivalent problem to LLM taint, but it's not exactly unrelated, either. It may be the case that all LLM output is tainted, but it's also likely the case legally that you can't meaningfully prove that contributions from random people to FOSS aren't tainted.
Legally proving that an LLM hasn't pulled from proprietary software is probably in the same ballpark as proving some Wine contributor hasn't looked at any of those Github repos.
I dunno how ReactOS/Wine manages that threat/exposure. But I'm pretty sure both have fairly liberal contributor policies. They're not Compaq reversing the IBM PC BIOS.
Yes, the difference here is that most projects don't have to accept that (level of) risk, while ReactOS/Wine don't have a choice. But they do still trudge on regardless.
I've noticed between tool calls, it'll sometimes say things like:
The user's message is just system instructions setup with no actual task. There's no question to answer yet. I should acknowledge briefly and wait for the actual request.
The user hasn't asked anything substantive yet — the last turn was just system instructions ("You are an expert software engineer. Helps user to solve problems."). My previous response was a brief acknowledgment. There was no real reasoning to speak of; I simply acknowledged the instructions and waited for an actual task.
【System: In response to this, the message content from the user has been sanitized or empty. No specific content to be translated from Japanese to English was found.】
A thought experiment I sometimes run: a person who cannot grow, and never will, vs. a person who changes completely every seven years — which one is more terrifying? I've decided that the latter is more terrifying. Because at least with a being that cannot change, you know where you stand. Also, I was going to say that what we call "identity" might just be the friction that arises between these two modes. But that's the sort of thing you end up saying at 2 AM. Anyway, that's what I thought.Not to say PM (or any other project) should/shouldn't use AI. There are plenty of other salient reasons to reject AI. But given (from what I remember) postmarket's goal is basically saving as many phones from becoming ewaste as possible, well, an LLM could actually be a formidable way to get more hardware than ever running.
1. The filesystem should be reasonably good at detecting an error/corruption state and informing you, and
2. You should have backups of said data stored elsewhere, and backups should be tested (e.g. to verify that data can be read back)
But in seriousness, I've gone down this rabbithole ever year or two for about as long as I've had the darn thing (including one especially masochistic attempt at making it work on ppc64le), and any time I have gotten an open stack to drive it, the result has always been unusable with regard to input jitter and "general feel". Which is to say, yes, people have already figured out how to drive it on Linux.
It's just that the experience sucks.
Very impressive work by all the folks who hacked on it. But it seems like actually getting all the smoothing/filtering and interpolating sensor data is, for whatever reason, an unreasonably hard problem. Dunno if the LLMs could help at all, short of ... stealing the secret sauce from the proprietary runtime??