That brings us back to requiring the user to present ID to the camera while doing a live-selfie, that would be a honest, belt-and-suspenders approach that's worth a look. Thanks for doing all the heavy lifting.
I noticed they also seemingly have a very difficult time managing to collect your chat logs for export/download...or rather, acknowledging that such a request was even made.
Honestly, for practical engineering purposes not that much. The Navier-Stokes equations are an approximation for a mathematically ideal in-compressible fluid. Even ignoring compressibility, physical fluids in the real world are not continuous fields since they are composed of discrete molecules. However, for that small class of problems where an analytic solution can be found, then it means you can be confident in the answer (it won't blow up to infinity), and that there are no other alternate solutions to the same problem.
Basics yes, details no, and if you are deep in a mathematical proof the details matter. For example, I seriously doubt you will find an average 7th grader (or even a professional engineer outside of the nuclear power field) able to give you a good explanation or even definition of the void coefficient, and how it may interact with the fuel temperature coefficient of reactivity for a particular reactor design. Do you?
I don't think there is anything in this article that actually demands bra-ket notation (a state in some Hilbert space), that couldn't be more clearly written with standard notation for a Euclidean inner/outer product, but I suppose everyone has their own preferences for notation.
You know its a doozy when the author writes a disclaimer at the top saying that bra-ket notation was chosen in order to make the algorithm and data structures clearer.
I'm not sure that is the case in this instance. Certainly general writing is a lot more variable and harder to classify, and on the other extreme certain one-line code changes don't have enough information to say anything. However, a blob with a 500+ line code change and 200+ lines of comments is a dead ringer for some of the current class of LLMs. That isn't to say it this behavior couldn't be obfuscated, but some basic categorization could probably separate the majority of human authored commits vs. AI commits. Heck, you could probably train an AI to detect commit-style just by using pre-2022 code archives and existing known-to-be-AI edits/commits.
Was this done by manually reviewing commit messages? I think it would be interesting/useful to have a tool that could use some basic heuristics about LLM generated code to detect code-blobs even if they are not explicitly called out in a commit message.
Very nice to see this older hardware getting repurposed. I have been running 2x Tesla V100s in a dual-core supermicro X10DRU-i server. With qwen3.6-27B-mtp I get about 35-40tok/s for inference for moderate context sizes (<128k), and have run long running agent tasks on it which consume 100s of millions of tokens (>$100s if I had to pay claude API costs). However, the main purpose that I have to for these cards is for scientific compute, the FP64 performance (7+ TFLOPS!) is fantastic given their age, and not something you can get on even the latest consumer grade cards since Nvidia nerfed their performance after Kepler. The server lives in the basement though...it is freaking loud!
Hardly seems worth the effort, perhaps things have improved since 2019. It would be interesting to see an updated benchmark, but if your going to end up with code that looks like C++ to get proper performance, you might as well write it in C++. My biggest problem with Julia is that they decided to use column-major indexing for multi-dimensional arrays (i.e. FORTRAN/MATLAB style). This makes interoperability with C/C++ and python numpy a real pain, since you can't do zero-copy array sharing between the two without one side being forced into strided-access. For that reason alone I haven't adopted it in any of my work-flows.
I have a old supermicro X10DRU-i server with two Tesla V100's (48 GB VRAM) and 128GB RAM and have been running qwen3.6-27B with a lot of success. I would say it's performance on my use case (modifying and extending a ~70kloc C++ code base) has been excellent. I have no benchmarks, but it seems comparable to claude sonnet 4.6 in capabilities. I run it with llama.cpp:
I regularly get ~22tok/s when context utilization is below <65k, but it does slow done to ~13tok/s when the context is nearly full (lots of swapping to RAM). I have been using the qwen-code harness though, since it is far more token efficient than claude-code which injects massive prompts that chew up the context window. I plan on trying it with pi next.
I'm keeping my ~$20/mo claude subscripts for the planning prompts, and then hand it off to qwen for implementation. It's been working well so far.
I know. I'm struggling to understand how this is a github repo/HN article. I've been using claude-code with a llama.cpp server and a dummy API key, and all that is required is to define 2 environmental variables to point claude at the local endpoint. Am I missing something?
We might already be there. I've been running Qwen-3.6-27B with 8-bit quantization locally with llama.cpp (~100k context window), and to be honest for my use case, 40-50% of the time it is more usable than claude-code. I only have the $20/mo plan, so I often hit rate limits after 2-3 prompts. And while the local model is slower, it just keeps chugging, is practically free, and more often than not produces code similar to claude. I wouldn't be surprised if in 6-12 months we have local models which are comparable to opus 4.6...which I personally consider as a tipping point where agentic coding became practical.
> At the same time, new versions of FFmpeg brought support for new codecs and file formats, and reliability improvements, all of which allowed us to ingest more diverse video content from users without disruptions.
While it is good they worked to get their internal improvements into upstream, and this is certainly better behavior than some other unmentioned tech giants. It makes one wonder (since they are presumably running it tens of billions of times per day), if they were involved in supporting these improvements all along. If not, why not?
Neat, but also hilarious! Searching for "mug" gives results where the first item listed (ABC-00008297) is a mug model with a hole not only in the top to pour in your drink, but also in the side and bottom (just in case you wanted more access to your liquid).
No idea, you can still get one-off boards here and there, but buying anything in quantity has been tricky. I can only surmise supermicro's resources are largely tied up with AI data center build out, with everything else relegated to short runs.
Nice write up! For this sort of thing, I have leaned towards AMD Epyc, Intel e810, and DPDK for the software stack. Unfortunately, lately the supermicro H13SSL line of mobo's appear to have become near-unobtainable with ridiculous 6+ month lead times.
My comment was directed at your statement "that at no point in history was the US dollar 100% backed by gold (or silver, originally). Never." which is entirely false. The US dollar (the currency unit), was at one point quite literally an exact weight of silver. This is no longer the case, but it was true in the past. This has nothing to do with the nation debt, or what is backing it. Obviously, the national debt isn't collateralized by precious metals or anything else except the military and power to raise taxes.