BillStrong

TrueNAS Scale is Linux based, but Core is FreeBSD based, and is the product they made for storage purposes before they made scale.

There was a card just detailed on Hot Chips that used a whole bunch of RISC-V CPUs on 2nm to run at 1.8GHz, but really low power, for compute on a CXL card that could also have SSDs for cached storage.

So, don't assume they would crank up the GHz.

I mean, why would we wait til then? AMD is buying a company that put LLama 3.1 7b(or something close) on silicon, and can give you 15k t/s, Qwen just released Qwen 3.8 Next that seperates the intelligence from the database, so the intelligence is 6b and the rest can be done on CPU. You can put that 6b on the AMD silicon, and then use another accelerator to speed up the database if you need fast PP, and you are now much faster than the B300 after optimizations such as caching the Prompt once, and keeping it around, and many others.

Suddenly, you can put that on the CPU next to an NPU, or on its own card, on the motherboard or on a GPU.

There is a project to use the Snow Leopard kernel and open source components and some bits from the prerelease Snow Leopard on PPC to create a working PPC Snow Leopard.

I wonder if something like that might be a short term viable path to get working apps. Something like the non-opensource libraries as a download pack for certain each release of Mac OS X, for at least versions Apple no longer supports, to get working programs, then you could slowly work toward open implementations.

Also, Mac is a moving target. Each year, there is a new version that is basically its own little snowflake, with older things deprecated and newer things added.

Windows 11 will still run Windows apps from Windows 3.1, because they have a backwards compatibility effort that Apple eschewed.

Now that makes it more complex to emulate all the features, but the core features used by most programs get emulated, and then just add features for specific programs to get them to work. And games tend to use core features and DirectX or OpenGL, mostly, whereas productivity apps and other things can do lots of weird things that are non-standard.

For Mac OS X, you really need to handle each versioon of Mac OS X. There are some core features that may work across versions, and some features that are available only on certain versions, then some features that are unique.

Hardware acceleration for OS X era OSes, for one.

VMs with GPU passed through. You can get Mac compatible GPUs that will work, look for the Dortania OpenCore guide GPU lists to find one that works for the version of Mac OS X it runs on. Looking on Macintosh Repository, that game will run on Intel CPUs and Snow Leopard, 10.6+. (IDK for sure.) You can emulate Intel Mac OS X using QEMU on linux machines, there are some scripts that make it easy from Proxmox that I use.

You can also emulate PPC Mac OS X and pass through devices, but I have not tried to do this, so your mileage may vary.

It is easier to emulate 10.7+ versions than 10.6, but you can get it to work from 10.4 with work.

Did they release their code under the GPL? FreeBSD is not GPL licensed, its 2 clause BSD licensed, so this wouldn't apply to that portion.

And you could still use the unexec method until this very latest release a few days ago, if you didn't want the pdumper.

Emacs does this to create its image with all the added functionality above the minimum required to run elisp, then has a mechanism to pull in text files because elisp is just text anyway.

They just chucked the old system for a portable version of it, but until this last release, they still had to option of doing it the old school way.

The AMD Zen 6 line is targeting 7GHz in the upcoming releases, on 2nm, so......

That is a relatively simple system. It cuts out use cases.

For instance, history, newer information is mixed with older authoritative information.

The same thing for religious institutions, where the older items may be the more authoritative for the purposes.

Already predicting which versions to avoid, huh.

Yes, much higher computation required to encode it, and decode it, both.

It is still ironic to me that my Steam Deck has decode AV1 acceleration, on a really old CPU/GPU combo.

Essentially all of the processing of the video data, barring the container format which the CPU uses to know what part of the data to send to the GPU or the Audio chip or codec.

And HW acceleration is generally a preset baked in version of the encoder or decoder. These are mostly codec specific.

So, no using hardware from previous versions.

Now, you can see some software that tries to use the GPU itself, instead of the dedicated hardware acceleration, to decode, but that isn't the HW accelerated, and may not operate in real time.

At the same time, that will consume much more power, eliminating some of the advantages or the pure HW rendition, especially important for mobile.

I could see an argument being made for encoding, if it is 2x or faster than the CPU, but I haven't looked at any in a while, so don't know the speeds.

Yes and no. It is just Zig, but that is the advantage. And compiling it to an special function that could work as an end seems to be a doable thing, so you would just have to have the compiler in your agent.

They work better for coding workloads. Essentially, the more regular the output, the more the faster model gets right, the less the big model has to do.

Writing tends to have more false positives. I haven't tried this particular one, however, but that is the general trend.

It does to an extent. One thing I will give AI, because of the nature of LLMs, you are essentially arguing with the median level of the input that trained the model. So, for someone new to the subject, you get access to patterns that will bring them up to a certain level.

Getting past that is problem we face now.

As long as you don't keep calling out to the CPU, that is.

Tool calling, searches, cache movement if used, and even debug steps all stall the GPU waiting for the CPU.

There was a test of turning one of the under 1B Qwen3+ models into a kernel that didn't stall by the CPU as one GPU pass that saw quite a bit f perf lift over vLLM, I believe, showing this is an issue still.

Its been a month, so I don't remember more details than this.

Even in humans, negative stimuli carries more weight than positive, in the general case.

Without reading it yet, my first thought would be to test a general ratio, something similar to human interpersonal relationship ratios like 30% negative to mostly positive, and positive are targeted, such as reinforcement not just for the good job, but reinforcement for the improvement.

And ensure the negative is targeted, such that you point out tendencies to be avoided rather than just specific instances.

Of course, most human interaction online has none of this, so, would be hard to replicate.

Look on HuggingFace, there is a template that is supposed to fix the updates for the Qwen Models.

https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates

Maybe will help you?

I think the article misses the actual point?

The browser is faster because they went native, in particular, GPU.

Every issue described is text rendering related. Everyone.

And I would bet most of the SwiftUI issues could be solved with a text render cache.

Something like Casey Murati's refterm toy that showed what that can do with no other optimizations, or the work for GPU accelerated terminal emulators like alacritty or ghostty.

Have you thought about Zig? If you limit it to CompTime, isn't that just a scripting language that happens to be compiled to binary?