AaronFriel

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.

https://cacm.acm.org/research/analysis-of-unconventional-evo...

Oh that's a surprising interaction. I use dark mode themes, is there something I haven't noticed?

Turn off "Animation Effects" in Settings and it will be instantaneous.

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.

Didn't X unban users like Dom Lucre who posted CSAM because of their political affiliation?

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.

What's the difference between this and the first link you shared?

If you're generating long reports, code, etc. with an LLM, partial strings matter quite a lot for user experience.

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.

[1] https://github.com/aaronfriel/fn-stream

[2] https://github.com/vercel/ai/pull/1883

[3] https://github.com/aaronfriel/jsonmodem

(These are my own opinions, not those of my employer, etc. etc.)

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".

Always exciting to see Robert Escriva's next database project. Building on top of the incredible engineering of S3 is clever, I'm definitely going to be looking at and learning from the implementation in wal3.

Looking forward to the benchmarks on using S3 for piece and the design of the scale out architecture.

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.

Is that what I said?

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.

5.15.37 - fixes data corruption in database reads using btrfs https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15....

5.15.65 - fixes double allocation and cache corruption https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15....

6.1.105 - fixes O_APPEND with direct i/o can write corurpted files https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1...

6.1.110 - fixes fsync race and corruption https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1...

6.2.16 - fixes truncation of files causing data corruption https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.1...

btrfs-progs 6.2 fixes corruption on zstd extent read https://btrfs.readthedocs.io/en/latest/CHANGES.html

6.15.3, 4: possible data corruption, seems to be reparable: https://www.phoronix.com/news/Btrfs-Log-Tree-Corruption-Fix

Are people that encountered these also dishonest?

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.

Respectfully to the maintainers:

How can this be a stable filesystem if parity is unstable and risks data loss?

How has this been allowed to happen?

It just seems so profoundly unserious to me.

I don't think those real identities should be public or deanonymizable from outside a given platform.

> KR (Korea) requires national identity numbers for gaming, which opens up a convenient opportunity to ban cheaters at the “soul” level. It is remarkably effective at keeping them out of game for longer periods of time—cheaters have to buy whole new identities to keep playing, so the bans really stick.

I detest "real name" policies and believe pseudonymous/anonymous discourse is helpful, perhaps even vital. But I am starting to believe that tying accounts to a "soul" or more expensive to forge identity is going to be the only way we get out of the Commentdämmerung we have today on social media. Whether it's posting invective, hateful diatribes on a platform or cheating in online games, it has to be more expensive than an email address to participate, but somehow also effectively free for most average people.

Maybe that takes the form of Worldcoin, or maybe some clever zk-snark proof of uniqueness-without-disclosing-identity from state or national ID programs, I don't know. But the current situation of a minority of people making vast swathes of the internet unpleasant is really quite untenable.

Of course the second hard part is figuring out how to do that without fully giving into the people who would want to spy on us all.

Surprised not to see Karnaugh maps mentioned here, as a tool for humans to intuitively find these simplifications.

https://en.m.wikipedia.org/wiki/Karnaugh_map

I had a hunch you'd reply and say as much!

It's just unfortunate for the many orgs delivering software that eventually customers start demanding this and it was really painful in Go.

Oh that's an interesting question, I've never tried to build a binary with "replace"-ing one of the builtin packages.

Maybe that works? But many of the standard library packages use linker shenanigans, if I recall, like //go:linkname pragmas. Maybe that's an issue, maybe not?

It would be interesting if the fork was unnecessary and it was possible to implement FIPS via package replacements! That would be a lot simpler.

The comment is accurate that if you don't need this, you can ignore it. It's likely not an avenue for backdoors. I wouldn't say it's security theater but it just isn't meaningful to most.

As for why not a library? Go has a pretty big "batteries included" implementation for networking. For customers demanding FIPS compliance it isn't enough to say, write all of your own application code to use a package that does FIPS-compliant TLS, but you have to make sure all of your libraries also use those algorithms. No rational person is going to vendor their entire dependency tree and maintain forks of the entire universe to swap `crypto/tls` and `net/http`. Well, some of these contracts are big enough to justify it, but whew, what a waste.

The FIPS compliant Go builds from Microsoft and now Go 1.24 make it a lot easier to check that box and unless a package implemented their own TLS stack it's easy to attest that the software uses FIPS validated crypto modules. Without that, good luck trying to sell to gov and highly regulated institutions in financial and health.

The upstream Go 1.24 changes and macOS support using system libraries in Microsoft's Go distribution are really significant for the large ecosystem of startups trying to sell to institutions requiring FIPS 140 certified cryptography.

For a variety of reasons - including "CGo is not Go" (https://dave.cheney.net/2016/01/18/cgo-is-not-go) - using boringcrypto and requiring CGO_ENABLED=1 could be a blocker. Not using system libraries meant that getting all of the software to agree on internal certificate chains was a chore. Go was in a pretty weird place.

Whether FIPS 140 is actually a good target for cryptography is another question. My understanding is that FIPS 140-1 and 140-2 cipher suites were considered by many experts to be outdated when those standards were approved, and that FIPS 140 still doesn't encompass post quantum crypto, and the algorithms chosen don't help mitigate misuse (e.g.: nonce reuse).

That data isn't sufficient for the claim you're making. Another interpretation could be that one President's CBP was approximately four times as effective.

The truth is harder to discern when each administration redefines encounters, but for example, the Trump administration deported fewer per annum than the Obama administration. I don't know what to make of that, myself, but I think that would come as a surprise to many voters.