Inference engines like llama.cpp will offload model and context to system ram for you, at the cost of performance. A MoE like 35B-A3B might serve you better than the ones mentioned, even if it doesn't fit entirely on the GPU. I suggest testing all three. Perhaps even 122-A10B if you have plenty of system ram.

Q4 is a common baseline for simple tasks on local models. I like to step up to Q5/Q6 for anything involving tool use on the smallish models I can run (9B and 35B-A3B).

Larger models tolerate lower quants better than small ones, 27B might be usable at 3 bpw where 9B or 4B wouldn't. You can also quantize the context. On llama.cpp you'd set the flags -fa on, -ctk x and ctv y. -h to see valid parameters. K is more sensitive to quantization than V, don't bother lowering it past q8_0. KV quantization is allegedly broken for Qwen 3.5 right now, but I can't tell.

As for Datastar, all the signal and state stuff seems to me like a step in the wrong direction.

None of this could be justified without the war on drugs. Plus we'd get rid of the prime motivator for a lot of the world's crime.

Dynamic typing is why I eventually switched. Haskell scratches the same itches that Clojure did, but the compiler and type system are immensely helpful, and keep saving me from tripping over my own feet.

Are you certain? I'd think most open source development is done by paid developers, on company time.

https://www.nvisioncenters.com/farsightedness/and-age/

And people will no longer need a duplicate set of libraries on their machines, all the way down to the gfx drivers. New software, and old stuff with 64-bit support, should have a lot less compatibility issues.

As for drivers, AMD has pledged to open source their Vulkan and OpenCL implementations. While that release has been pending "legal review" forever now, alternative open source drivers are making great progress thanks to Vulkan's simpler driver model. While NVidia's generally had the "better" driver, both from adhering less strictly to the spec and having the manpower to routinely fix application bugs in their driver, that's all changed with Vulkan/DX12 being significantly closer to the hardware.

I'd say things are looking up for market balance.

I intentionally break such requests by dropping anything beyond the host name.

If someone are sending data in the open, I don't want their clients to keep working thanks to built-in support for redirects.

I'd rather not be subjected to (and pay for) more security theater, or see every small business out there drown in a paper mill suitable for the fortune 500s.

We are already liable for any gross misconduct.

IMO you don't need to know either C or asm to be a great programmer. Read a book on operating systems instead and you'll know all you need to about hardware. Add a thorough coverage of algorithms and data structures, and you're in a better position to write effective software than many I've worked with.

We shared all of this work with the upstream projects, as we had no interest whatsoever in maintaining private forks and because better quality infrastructure attracts more users, which again leads to further improvements or at least ensures the project stays maintained.

With only 16% of the votes they also lost 1/4th their seats from the previous election, which was won by a labor/left coalition.

The norm is 37.5 hour work weeks. We're entitled to a 0.5 hour lunch break every day, but that's unpaid unless you're required to spend it on-site.

If you're dead set on adding type declarations, perhaps you'd be better off with Haskell or something?

As for the strength of 256 bits, the Wikipedia page on brute force attacks should tell you how infeasible attacking even a 128 bit key is: http://en.wikipedia.org/wiki/Brute-force_attack

More material here: http://www.haskell.org/haskellwiki/Video_presentations#Intro...