HN user
The knowledge is lossy, and code generation itself is non-deterministic (temperature), so the operator-tree executor must be interference from other DB implementations, because it's uncommon to have a bytecode interpreter
We've shipped some code generated by Qwen3.6 27B to production (under OpenCode). It lacks the breadth of knowledge of models like Opus, but if a change is fully inferable from the prompt and the surrounding code, it works very well. It won't be able to write something from scratch that requires niche knowledge (say, a performant inference engine tailored to Blackwell GPUs), but if it's just a PR adding a new use case to an existing project (which is usually just "load from the DB, do some invariant checks, modify the entities, store them back"), it works as well as Sonnet (provided you have the correct configuration, like recommended temperature and top-p settings, the model isn't over-quantized, you have at least 150k tokens of context available, etc.).
Even if no Rust code for it was seen during training, an LLM can trivially transpile SQLite's C codebase to Rust on the fly. For example, I just asked ChatGPT to write John Carmack's famous Fast Inverse Square Root algorithm in Erlang, without searching online or thinking, and it transpiled it immediately (while also extracting the knowledge in the same step). SQLite's semantics/code are stored in the middle layers of an LLM, and the last layers are able to convert it into any representation, as conditioned by the prompt. Cursor's experiment is deeply flawed because they merely extracted the model's compressed, lossy knowledge of SQLite's codebase and then just ran a bunch of tests/fixing rounds to make up for the lossiness. The claim that the agents built it from scratch is false.
I reproduced it in Sqlite with short-lived reads/writes though. Other DBMSes seem to not have this issue (IIRC MySQL will block a write if WAL falls behind)
On the page you linked:
However, if a database has many concurrent overlapping readers and there is always at least one active reader, then no checkpoints will be able to complete and hence the WAL file will grow without bound.
This scenario can be avoided by ensuring that there are "reader gaps": times when no processes are reading from the database and that checkpoints are attempted during those times.
Dunno, maybe Rails has a built-in workaround for this.
My workaround was to run a separate thread that monitored the WAL size on disk every second. If it went above the target size of 8 MB, my framework would enter "slow down" mode, where all reads and writes were artificially delayed by calling "sleep()", starting at 16 ms and gradually increasing the sleep time based on a few heuristics.
This allowed the application to have short gaps with no reads or writes, so the checkpointer could actually proceed.
They use WAL in SQLite. If I continuously perform reads/writes so that they overlap with no gaps, I can make their VM go down because SQLite will not have time to initiate a checkpoint to trim the WAL file. SQLite waits for a time window without any active reads/writes before starting a WAL checkpoint. If there isn't one, the WAL will grow indefinitely, eating up all the disk space on the VM.
It's in SQLite's documentation, and almost no one switching to Sqlite seems to be aware of it because no one discusses it in blog posts like these. I guess most projects switching to SQLite have very low traffic and no malicious users (yet)
Ollama uses 4 bit quants and a very short context window by default. It can easily break on anything more complex than a simple chat.
Qwen3.6 below Q8 often can't exit a reasoning loop (until it hits max output token count), forgets to insert a tool call, often mistakenly inserts them inside the thinking block... It's still usable though.
How was qwen3.6 launched?
The thing is, everyone has their own variant of "qwen3.6 27b" depending on the launch parameters, ranging from "SOTA in its class" to "completely broken"
VPN, accessible only from inside the corporate network
Yes, Rocket.Chat
We've been self-hosting GitLab for about a year now, and I don't remember it ever going down or being unavailable. We self-host almost everything else too (except for online meetings), and it's all been pretty stable as well. Some of the tools we self-host do go down occasionally, but it's usually just a matter of restarting the VM or adding more storage.
It converges to "almost deterministic" on highly predictable outputs (i.e. code) with the right sampling params (say, you only sample the most probable token without randomness/high temperature) and with self-correction loops
they turned it into something unreadable
Did you compare the code before/after? It's a mechanical line-by-line port, and most of the code is identical to the old version, just with Rust syntax. They have an example in the blog post.
On artificialanalysis.ai, Kimi 2.7 Code is way worse than GLM 5.2 at everything (general intelligence, coding, agentic tasks).
But here, both Kimi 2.7 and its derivative SWE-1.7 are ahead of GLM 5.2. This tells me the benchmarks they use are cherry-picked.
Pragmatically, often users without new browsers and OSses are not the best clients
Hmm, it could be fat enterprise clients with locked-down software versions (legacy, security etc.) That's where most of the money is, isn't it?
Judging by the examples, if I understand it correctly, J-space supports higher-order logical / multihop transformations, but it is limited in size because of the limited network depth (max number of layers). When we emulate "reasoning," we basically extend J-space and allow the higher-order transformations to continue for longer, toward a more logical conclusion.
It sounds like instead of generating reasoning tokens end-to-end, we could probably only loop the middle layers (the ones most related to J-space) while skipping the first and last layers (less related to J-space) It probably explains why [0] worked. OP accidentally extended J-space? Also reminds of looped transformers.
Probably an instance of:
"The Reversal Curse: LLMs trained on "A is B" fail to learn "B is A"
Fable 5 was released on June 9 and removed on June 12. GLM-5.2 was released on June 13. It would be an amazing feat to make a model SOTA in just 3 days but I highly doubt it. It's more like z.ai released an existing checkpoint earlier than planned to capitalize on the news
$40k gets you almost-Opus
GLM 5.2 is "almost Opus," and it needs at least 8xH200s for comfortable inference (so it's closer to $400k than $40k).
They suggest using this modified model:
A REAP-pruned (≈22% of experts removed), Int8-mix NVFP4 quantized version of GLM-5.2, ≈594B parameters.
I wonder how it behaves in practice outside of benchmarks. Qwen3.6, even at 6-bit quantization, often gets stuck in loops while reasoning. And here they've also removed some experts. I mean, sometimes an 8-bit or 16-bit small model can be smarter than a lobotomized large model. I heard the consensus is you shouldn't go below 8 bit for coding.
Also, it's not clear what is left of the available context when you try to fit a lobotomized model into 4 RTX 6000s. Anything below 100k is barely usable because it often hits compaction before it's able to gather the necessary context P.S. found in the repos, 240k context
I run a corporate AI server and coding peak hours here are 1PM-5PM judging by AI usage stats. My guess is that people spend 9AM-12PM in meetings and at lunch, and the actual coding starts around 1 PM.
From the perspective of LLM inference, you currently mostly care about:
- Memory bandwidth; BUT the requirements are currently capped because models have stopped growing at around 1-1.5 trillion parameters for quite a while now. You only need more bandwidth if you're optimizing for the highest possible concurrency (i.e. you're a cloud provider). Also, MoE exists.
- Support for native low-precision math (like FP4 and FP8); BUT once your GPU supports native FP4 (Blackwell+), there's generally no reason for GPUs to go lower because of the obvious quality degradation.
- VRAM capacity - just like memory bandwidth, it's practically capped by 1-1.5 trillion parameter models and is unlikely to need much more in the near future. Also, the current trend is toward miniaturization: modern 30B-class models (which require far less VRAM), now completely destroy 200B-class models from just two years ago on most tasks. We also have better understanding now how to compress contexts.
Most model improvements currently seem to come from RL/harness-based methods, not from scaling models or running new algorithms that require fundamentally new GPUs.
So I don't see why GPUs that exist today must become "outdated" in a few years. They'll be seen as outdated by hyperscalers because they need to serve the maximum number of users as cheaply as possible, so of course they'll replace their GPUs with newer ones that have higher memory bandwidth or more tensor cores. But you don't need that for local inference.
Yeah people don't realize these "toy models" now completely destroy gpt-4o on most tasks, and no one called gpt-4o a toy model back in the day... It was OpenAI's flagship model from 2024 to 2025.
Some countries and jurisdictions still have laws that allow for the involuntary confinement of tuberculosis patients, I guess dating back to the times when tuberculosis was rampant in those countries? And most professionals seem to be okay with the policy:
https://theunion.org/news/is-involuntary-incarceration-of-tb...
17% said that, as a matter of principle, the involuntary incarceration of TB patients was inappropriate on any grounds.
Regionally, members from Europe Region had the highest percentage of respondents objecting to the policy as a matter of principle (26.2%) while the North America Region had the lowest (3%).
The emergence of multi-drug resistant tuberculosis in the 1990s is probably one of the reasons:
Respondents most strongly supported the policy of incarceration for patients known to have multidrug-resistant TB (49.7%)
See my answer in this same subthread. I was perplexed myself as to why I was diagnosed based on just one radiology report. But the moral of my story is that you can always try to obtain a second opinion from another doctor. I'm not saying doctors shouldn't be trusted in general.
never read or send .env, .env.*, .pem, id_, .aws/, .ssh/.
A think a better practice is to not store those things in the repository folder in the first place.
I have a memory of myself lying motionless for what felt like forever and staring at a wallpaper featuring Disney characters. Years later I found photos from when I was around 1 year old and the home had those wallpapers (we stayed there for a few months). I remember feeling somewhat self-aware, like I was trying to understand why I was lying there, what those characters on the wallpaper were, what I was doing there at all. And I strongly felt the passage of time, like the whole episode dragged on forever. Maybe I had just woken up while my mom was in the kitchen? It's like I suddenly became self-aware, maybe that's why I remembered it :)
Yeah, I know! It was strange. They gave me a test, and it came back negative, but they insisted it was negative because I had "latent tuberculosis," which supposedly wasn't detectable by the test yet but was about to become active.
I forgot to mention that, besides getting a second opinion from another radiologist, I also took a more modern test at another private clinic. That test has better detection rates than the one the state clinic used, and it came back negative too.
I have suspicions they had some kind of government quota to keep the hospital staffed with patients in order to receive funding. Or they were just completely incompetent. I pushed back by bringing them another radiologist's report and the results of a better test that I paid for myself, so I guess they decided to back down.
A few years ago (before the AI craze), I was misdiagnosed with tuberculosis. I had a chronic cough, and an outsourced radiologist at a clinic found signs of tuberculosis. The findings were sent to the city's tuberculosis hospital, as required by the country's law. The doctors there took the radiologist's conclusion at face value and required me to stay at their hospital for at least 8 months under a strict, prison-like regime. There was no option to say no, because I was considered some kind of biohazard, and by law I had to comply.
Before I was admitted, I quickly found another radiologist, who diagnosed pneumonia instead. I sent his report to the chief doctor at the tuberculosis hospital, and after some deliberation they concluded that the original reading was wrong. Turns out the doctors there can't read scans at all and just believe whatever a radiologist says...
The funny thing is, they had already officially put me on the tuberculosis register and didn't want to admit they had made a mistake. So instead, they simply gave me another paper saying that I had been cured of tuberculosis by them... in 7 days. I'm probably the only person in the country to defeat tuberculosis in a week :)
So if you don't trust the radiologist/doctor, maybe find another doctor if you can afford it? You can compare their conclusions and see if they match. Two unrelated doctors or radiologists saying the same thing is probably about as close to the truth as you're going to get. I'm not sure though whether I should trust AI or humans more. AI can hallucinate, but I've been misdiagnosed by humans so many times too...
I tried a few SOTA realtime avatar systems from Chinese labs and the actual quality was far worse than the amazing (cherrypicked) videos on their demo pages
I ran an analysis on hundreds generated videos featuring various races/ethnicities and found that Chinese models are overfitted on East Asian faces (predictable though) and have trouble properly animating many European/most African faces (bad lipsync).
They all had accumulating artifacts over the long term (the video stops being stable after N seconds, for example the image gets more and more washed out)
So I don't have high hopes here, everyone on the demo page is predictably East Asian and the output quality doesn't look better than prior art. I guess the innovation here is that it's end-to-end but we need to see if it's any good. WAN-derived image-audio-to-video systems used to be notoriously slow, here they boast 25 FPS for 192p but it's pretty slow actually, I managed to reach similar FPS for 720p with prior art.