It may come as a surprise, but this phenomenon of "uninterpretable" circuits designed by algorithms is 30 years old now.
Adrian Thompson's research in the 90s evolved FPGAs that did signal analysis with bizarre features:
- A tiny number of cells (far fewer than expected)
- No clock, despite performing signal analysis
- FPGA cells that were logically disconnected, but when removed caused the device to stop working
Even then their approach was taking advantage of the physics in the FPGA. One can only imagine how effective this could be when applied to circuit design with the compute budget of a frontier lab.
The conventional wisdom in cryptography is that if you don't know you need FIPS, if you don't have paper and a dollar figure telling you how much you need it, you don't need or want FIPS.
Could you explain what a git trailer is if not appended to the message body? My understanding is that trailers are just key-value pairs in a particular format at the end of the message; there's not an alternative storage mechanism.
Even so, trailers or message body might be moot - rerolling the committed at timestamp should be sufficient!
OCI artifacts, using the same protocol as container registries. It's a protocol designed for versioning (tagging) content addressable blobs, associating metadata with them, and it's CDN friendly.
Homebrew uses OCI as its backend now, and I think every package manager should. It has the right primitives you expect from a registry to scale.
A lot of folks think this, but did you also implement EDNS0?
The golang team also thought DNS clients were simple, and it led to almost ten years of difficult to debug panics in Docker, Mesos, Terraform, Mesos, Consul, Heroku, Weave and countless other services and CLI tools written in Go. (Search "cannot unmarshal DNS message" and marvel at the thousands of forum threads and GitHub issues that all bottom out at Go implementing the original DNS spec and not following later updates.)
This also happens on switching virtual desktops, even with reduce animations there is a 100ms+ delay before any input on the new desktop will be sent to the correct app.
Oh, this is quite similar to an online parser I'd written a few years ago[1]. I have some worked examples on how to use it with the now-standard Chat Completions API for LLMs to stream and filter structured outputs (aka JSON). This is the underlying technology for a "Copilot" or "AI" application I worked on in my last role.
Like yours, I'm sure, these incremental or online parser libraries are orders of magnitude faster[2] than alternatives for parsing LLM tool calls for the very simple reason that alternative approaches repeatedly parse the entire concatenated response, which requires buffering the entire payload, repeatedly allocating new objects, and for an N token response, you parse the first token N times! All of the "industry standard" approaches here are quadratic, which is going to scale quite poorly as LLMs generate larger and larger responses to meet application needs, and users want low latency outputs.
One of the most useful features of this approach is filtering LLM tool calls on the server and passing through a subset of the parse events to the client. This makes it relatively easy to put moderation, metadata capture, and other requirements in a single tool call, while still providing low latency streaming UI. It also avoids the problem with many moderation APIs where for cost or speed reasons, one might delegate to a smaller, cheaper model to generate output in a side-channel of the normal output stream. This not only doesn't scale, but it also means the more powerful model is unaware of these requirements, or you end up with a "flash of unapproved content" due to moderation delays, etc.
I found that it was extremely helpful to work at the level of parse events, but recognize that building partial values is also important, so I'm working on something similar in Rust[3], but taking a more holistic view and building more of an "AI SDK" akin to Vercel's, but written in Rust.
Not using the NVDEC and NVJPG units to decompress weights into registers? And you say you're using the whole GPU. There are entire blocks on the silicon going idle!
“Never believe that anti-Semites are completely unaware of the absurdity of their replies. They know that their remarks are frivolous, open to challenge. But they are amusing themselves, for it is their adversary who is obliged to use words responsibly, since he believes in words. The anti-Semites have the right to play. They even like to play with discourse for, by giving ridiculous reasons, they discredit the seriousness of their interlocutors. They delight in acting in bad faith, since they seek not to persuade by sound argument but to intimidate and disconcert. If you press them too closely, they will abruptly fall silent, loftily indicating by some phrase that the time for argument is past.” - Jean-Paul Sartre
Words to remember when one hears it's "just locker room talk" or "boys being boys" or "just a joke, lighten up".
I think any discussion of btrfs needs to acknowledge that raid5/6 support was promised in the early years, shipped in the kernel in 2013 and, until 2021's btrfs-progs 5.11 release, did not warn users that they risked data loss when creating volumes.
For near a decade btrfs raid5/6 was "unsafe at any speed" and many people lost data to it, including myself.
There's no need to call someone pointing out instability of a filesystem dishonest. That's bad faith.
I don't get why folks feel the need to come out and cheer for a tool like this, do you have skin in the game on whether or not btrfs is considered stable? Are you a contributor?
I don't get it.
But since you asked - let me find some recent bugs.
btrfs has eaten my data, which was probably my bad for trying out a newly stable filesystem around 15 years ago. there are plenty of bug reports of btrfs eating other people's data in the years since.
It's probably mostly stable now, but it's silly to act like it's a paragon of stability in the kernel.
Parity support in multi-disk arrays is older than I am, it's a fairly standard feature. btrfs doesn't support this without data loss risks after 17 years of development.
Adrian Thompson's research in the 90s evolved FPGAs that did signal analysis with bizarre features:
- A tiny number of cells (far fewer than expected)
- No clock, despite performing signal analysis
- FPGA cells that were logically disconnected, but when removed caused the device to stop working
Even then their approach was taking advantage of the physics in the FPGA. One can only imagine how effective this could be when applied to circuit design with the compute budget of a frontier lab.
https://cacm.acm.org/research/analysis-of-unconventional-evo...