vopi

Then, you can serve it faster/cheaper than the frontier LLMs. It's basically distilling a small but extremely common use-case from LLMs and serving it. Then RLCD comes into play to update weights when a new model comes out, etc.

Any thoughts on what the next potential "cheap" win to be distilled from frontier LLMs is? I'm going to need to play around with this.

I think they are pretty fair and explicitly say “Distillation itself is a legitimate training method […] Distillation is commonly used because it reduces the resources needed to achieve more advanced capabilities”. And go on to say their definition that makes it illicit in these cases.

And, also, they almost certainly __were__ tricking users and sending their data overseas.

Do you see it any differently?

>Might as well use LLMs for the whole thing next time, since we will be accused of doing so anyway! :D

The original comment you replied to was talking about "the loss of network effect" and you sounded dismissive of it. It might not even matter, but I think it's somewhat fair to say it could have an impact.

It’s definitionally an ad hominem against Jared. If he stuck to why he thought it was bad for Bun to do this, I would be more slightly sympathetic.

Will Fable be back behind an ID verification step? I wouldn't be shocked if that happened. However, this specific support page and the ID veridiction process is not new. It is currently enforce.

It appears (but I can't be certain and don't think it's in bad faith) that many people are under the assumption that this is a result of the Fable banning. As a datapoint, I did some form of KYC verification to use OpenAI's cybersecurity platform a few weeks ago.

To be clear: I still think this is an important discussion.

[0]: https://old.reddit.com/r/ClaudeCode/comments/1smpjg8/well_iv...

Edit: truthbe above pointed out there was a privacy policy change.

>By far the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast, languages that require fundamental rethinking of memory management, mutation, data structuring, polymorphism, laziness, etc., might be a better fit for a ground-up rewrite, but we're undertaking this more as a port that maintains the existing behavior and critical optimizations we've built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.

TLDR: Typescript -> Go is much easier than Typescript -> Rust/Zig/$OTHERNATIVELANG

"Welcome to The Khipu Field Guide - Travel back in time to the Inkan empire of the 14th through 16th century. Explore how the Inkas used cloth to communicate and record commitments. Journey with me, as I work with other khipu scholars, to decipher the enigma behind a knotted mop of camelid yarn."

There is some statistical analysis here but part of my hopes in posting on HN is perhaps someone here might get nerdsniped by it.

Never tried the later enterprise Google Glass, but it always seemed generally to be more of a smart watch with a prism strapped to your face than a future-tech(tm) assistant strapped to your face.

although, there is a VOD channel on YT that might be better.