HN user

snthpy

950 karma

snthpy.at.hn

Chief Excel Officer, MAD* Scientist, Pythonista, Rustacian, PRQL Core Contributor (: ML, AI, Data)

* twitter: [@T0bias_Brandt](https://x.com/T0bias_Brandt) * github: [@snth](https://github.com/snth/) * [PRQL](https://prql-lang.org/)

Posts13
Comments810
View on HN

I love both of those and actually only started playing Mini Metro this month. Such synchronicity(!), although mediated by whatever is probably happening on the Play Store, this is less surprising then it would have been 50 years ago.

What is the best way to deploy these on CPUs, arm64 ones in particular?

I'm interested in the CPU inference application of these models with things like the FairyFuse kernels.

I've tried trillim previously but was disappointed that i got higher tok/s just with similar sized models through ollama using just Q4_K_M quants.

I see there is bitnet.cpp and litespark-inference. What else should i look at?

Thanks. This relates to some questions I've got. I was playing around with the previous generation smaller models and found that i wasn't getting any speedups from the T1 and T2 binary/ternary models compared to standard Q4 quants of straight qwen3.6 models. I was wondering whether unpacking of the ternary encoding was impacting inference speed?

If that's the case then why not just train at Q2? I guess the counterargument is that then you lose the nice properties of things like the FairyFuse kernels. I wish there were some good discussions of these trade off.

GPT-5.6 13 days ago

OT but how are y'all sharing your skills and agents across harnesses?

I have a bunch of Claude Code Plugins and yesterday asked Codex to make them accessible to itself. It wanted to rewrite most of it. I was hoping i could get by with some symlinks or something to avoid drift.

GPT-5.6 13 days ago

Not just RLHF but also RLVR, and isn't that the litter lesson though?

My sense of the Sutton Dwarkesh interview was that he was calling out that he didn't mean just longer datasets, but rather learning through exploration and that's exactly RL.

"a new distributed consensus service called Meerkat powered by a consensus algorithm called QuePaxa, published in 2023 by researchers at EPFL. QuePaxa differs from Raft in that all replicas can perform writes at all times, and progress is never halted due to a timeout"

Interesting

Really, does this work now? What about NotebookLM? I was using it a lot until i realised it was only analysing the transcripts and not the video because i was mostly using it for technical ones with important charts.

Looks cool. A somewhat adjacent question: what is the best, or what are common, approache(s) for handling time in knowledge graphs?

Hi, Yes I'm in the same boat as you - had to switch to US language instead of UK. I've been addiing the anglisised versions of words to my dictionary as I go along so it's becoming less of an issue over time. Maybe I'll switch to FUTO in order to not have to deal with this anymore. Gboard has one nice feature though in that I have multiple languages enabled so I get correct predictive completion in non-English languages.

For learning ClearFlow, I used the Games app available from the "Clearflow Games" section on their website: https://clearflowkeyboard.github.io/

I also have the issue of the thumb getting in the way so I spent a couple of days playing the games to get my layout memory up and then it became usable without frustration and I'm not looking back now although I occasionally still forget the odd letter location.

Claude Tag 29 days ago

I think this is the right direction. I'm increasingly viewing AI as coworkers and explaining it as such to higher ups as well. My colleagues also have different strengths and weaknesses and i know what to check and what i can rely on more. Being able to interact with Claude like i do with them will help with that. Unfortunately I'll need it in MS Teams for that. (Pls spare me your rants about Teams. We also use Windows. Deal with it.)

I switched to ClearFlow a month or two ago after learning of it on Hackernews. It is available in GBoard.

I'm happy with the switch. Like any keyboard switch (I've gone from Qwerty to Dvorak and now a Colemak-dh derivative with about ten years on each) it takes some time to learn the layout. Overall I'm happy with it though and there are less frustrating misinterpretations and corrections needed.

This post was swiped on it with only two corrections and the second one was my fault as i misremembered a key location.

Will It Mythos? 30 days ago

I miss Fable. Will it ever be back? As a non-US citizen living in Africa i fear that i will have to wait for an equivalent non-US model.

Thank you! This is the concept I've been looking for. I always had the sense that compositional data transformation frameworks like PRQL or LINQ should have a clean categorical interpretation. I was exploring how this could be expressed in terms of monads but they usually start with the data while I was trying to formalise the composition of the transformations. I think transducers are it.

Transducers are just the morphisms in the category of the reducing-functions. No problem!

I like this and think it's a great idea. Leveraging git makes a lot of sense (content addressed filesystem, efficient storage and sync protocol with pack files etc ..., widely deployed).

From a cursory look my impression is that it deviates from git too much and therefore I can't use my git knowledge to predict how it will behave. I'm quite rusty on git internals but afair .git/refs/ is great because you can do what you like in there but the downside is that it doesn't hook into the rest of the git structure.

So how does this work with branches, worktrees, etc...? Having a jsonl message log in .git/refs/h5i/msg seems very linear. Presumably you store commit refs in the json obj or context dag, but what if I rebase the branch and the original commits are dropped because they're not referenced anymore? Or say I follow the conversation and want to rewind a few messages and branch from there in a separate worktree, how does that work?

Your repo README does say:

- "It uses dedicated refs, so it doesn’t pollute your working tree or your normal branch graph."

- "Because these are Git objects, they are content-addressed, deduplicated, pushable, fetchable, and survive `git gc`."

- "Because the log lives in refs/h5i/msg, a conversation survives clones, machines, and branches — it travels with h5i share push / pull, and divergent sends from two machines union-merge with no message lost."

Therefore these look like design decisions and it would be nice to understand them better.

My first instinct would be to put most of what you have under .git/refs/h5i/ in a .h5i folder in the repo itself and manage some shadow branches under .git/heads/.h5i/ with multi-parent commits pointing at the context commit as well as the previous h5i message commit along with some hooks to handle rebases etc ... . That way battle hardened git machinery gets used and more importantly to me, I can leverage my existing git knowledge to understand dependencies. That would go against your "it doesn’t pollute your working tree or your normal branch graph" goal but I'm of the "explicit is better than implicit" Python school so I like to have the details exposed as long as I can filter them out easily (or by default).