leansensei

Not if you preserve reasoning in the KV cache, 32k ctx is nothing.

Easy to say "should".

What's the point, when we have Chat Control 2.0?

Unchecked immigration, lax policing.

Damn, this is a fantastic evaluation, thanks!

It does, beautifully. Now let's wait for an NVFP4 GGUF!

Check out cactus needle, might be what you're looking for.

Easy to do with Unsloth Studio.

And if you're running it on a dGPU, power limit it, because you lose very little in terms of token generation performance, since it's memory-bound.

RTX 4060 and above. Ideally RTX 50 Series, because you can run NVFP4-quantized GGUFs that give you better prefill AND better quality.

Huh what? Qwen3.5-35B-A3B runs just fine with maximum context, on an RTX SUPER 12 GB, with offloading of some expert layers to DDR4-3200.

Same story on an RTX 4060 Ti 16 GB. MTP is a serious boost to tg.

Downloading the model is a simple hf command that HuggingFace's web UI even gives you.

llama.cpp is trivial to use, and so is llama-swap, if you want to use other models too.

If you don't know what arguments to run it with, you download ggrun and use that.

Local LLMs are incredibly capable and don't need expensive hardware. A $500 GPU will do. Or even cheaper.

This is all trivial.

Oh no, we do, because the software world has been abusing what engineering means for decades, in order to inflate job titles. Most people are programmers, not software engineers, and that's OK.

Not really, you can do great things without them. I've been summarizing hundreds of documents. I've added MCP servers to my internal business tools (Elixir apps) and can chat with the Nous Hermes agent over Telegram about pending orders, inventory level, historical product prices, etc., without having to click/dick around with a web UI.

Sure, it cannot replace SOTA models for agentic coding, except for small, well-scoped refactorings. But even a model like ministral-3:8b or qwen3.5:9b is a boon for so many smaller use cases!

Europe was never at the frontier of any tech? Huh what now?

...and you'd be wrong.

Thanks, that was not clear to me from skimming the docs.

However, this NIF also returns more fields than the disksup function.

It's because the most familiar thing to me that uses a NIF was Exqlite, so that was my starting point.

Using Rust and Rustler turned out to be way easier and it also now works across Elixir versions 1.14 to 1.18.

The post explains why I don't want to use disksup. You have to start an extra application (os_mon) and configure disksup to update the starts more frequently than the default of every 30 minutes.

Do we really need to do all that instead of the equivalent of a df?

Agree about the C code, which is why the latest version (on GitHub, the HEAD, not yet released in Hex.pm) is now using Rust and Rustler.

Why not C? It made no difference, we're talking about a few function calls.

"Abo" in German means "subscription" (from the French abonnement). Show some cultural sensitivity about these languages.

Thank you for ntfy, it's such a useful piece of software!

Wekan looks close to pre-Atlassian Trello.

Just use Wekan. Problem solved.

apt install geeqie

That's all.

That's the VAG marketing strategy. Share most parts, have the customer pay for the brand.

Also try out Garage.

I've been working on a kinda-sequel to my first technical book, Northwind Elixir Traders. This one (Phoenix Product Codex) is about developing and deploying a production-grade REST API with Elixir and Phoenix.

Zed is great but not so great if you are trying to copy/cut/paste with the keyboard layout being anything other than latin.

I'm working on my second self-published technical book related to Elixir. The first one has been a surprising success, but since it was about learning to use Ecto on the basis of an old pedagogical toy database (and tiny dataset), the new book is about the development of a production-grade REST API with Elixir and Phoenix.

I find that many books out there are focused on documenting the "happy path" for rather small and simplistic applications without boundary conditions or business thinking behind them.

So, I thought (as with the first books) that it mix things up by also documenting the business context, the questions, decisions, and the decision-making process itself, as well as all the gotchas and "side-quests", rather than showing "here's how you do it" and then expecting the reader to suddenly make the jump from tutorial hell to actually software engineering.

Overall, it's enormously enjoyable, and I hope it goes as far as the first book, and possibly even farther.

This is The Incredible Story of Deft... https://leanpub.com/deft