The BSDs do have comparatively miserable contributor experiences, though I understand why. At least from my very, very limited exposure.
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...
These days there are too many choices for FreeBSD, you can submit a GitHub PR, Phorge PR, Bugzilla patch, Phabricator patch, mailing list patch... sharing the code is not the hard part. For NetBSD, a Gnats PR and/or mailing list comment with a patch or link is still the way.
Getting a person's attention who can and will do something is still challenging if you don't know whom, which is the same problem I saw sending patches to Linux mailing lists which went unanswered, and was given no specific feedback or path forward privately contacting the corporate maintainers.
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.
Just out of curiosity, why the Sparc laptop? While I'd love to find one today to tinker with, I assume anyone who had one back then was mainly working on sun machine's / unix and needed some at home familiarity.
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)
Ahh a modern purchase! I get temptations every time I've seen a sparc powered laptop end up on Ebay, but never for a low enough price to justify the the tinkering urges.
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.
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".
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...
That is what stood out to me as well. Qwen 3.8 Flash can run on very limited hardware as well and it is at least as good as Sonnet 5 in benchmarks like DeepSWE. With its n-gram design you can get flash next running on very limited GPU resources, as little as 16GB of VRAM.
People follow the latest frontier lab models with great attention and migrate to the next big model on their subscriptions. Meanwhile these local models have quietly gotten REALLY good. It is not even an exaggeration. It has happened in the last couple of months.
"Local model you can run at 40 t/s on a gaming machine that is better than Opus 4.6" is way less exciting than "OpenAI IS DOING CRIME!!! OpenAI SOLVED NAVIER STOKES. DARIO SAYS GLM 5.3 BAD! SLOW DOWN THE FRONTIER!".
(edit: also... totally ignore that 27B dense column over there where Qwen 3.8 27B beats Kolibri on nearly every single benchmark. Why would I choose to run this model?)
The point of a model like this is aimed at providing local inference. You want the smartest model available, as long as it meets all of your other criteria. That isn't always maximizing on the absolute smartest model. There are many reasons to avoid a frontier model for now for a variety of reasons. All of this is even only relevant in the last 6 months anyhow. So it isn't like this is even some long term trade off or position I am proposing.
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...
Hey, I perfectly understand if not. But do you have the sources that were used to build those binaries?
The oldest version on the GNU ftp server is fileutils-3.13 [1]. I vaguely remember having some links to older versions, probably somewhere in my archived mail. But I don't remember if it was fileutils-3.9 or earlier.
I co-maintain GNU coreutils, so I am interested in reading them. If you have them, you can email me privately or on the public mailing list. Both are listed on the homepage [2].
When you get to packages that are old enough, DiscMaster[0] is helpful for this since these packages were often on magazine cover CD-ROMs! There are several files matching "fileutils-3.9.tar.gz"[1]; the two variants seem to be the original GNU release (182.9KiB, the one you're looking for), and what looks like the result of a "make install" (57.4KiB).
The original GNU release of fileutils-3.6 is there too (but be careful; one of the two files appears to include Makefiles from a ./configure run, while the other doesn't), though 3.7 and 3.8 don't appear to be. You'll need to sift through to find what you need in some cases, but it's an incredibly valuable research tool.
Note: To download a file, you'll need to click on the filename, and then click the small arrow at the top that looks like a red arrow pointing down to a white box with red/green lights. (Which I assume is their representation of a desktop computer.)
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:
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.
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...
reply