This is seriously impressive!!
What are you planning on doing with this? Where should I follow along?
1,238 karma · joined November 22, 2011
https://github.com/HanClinto
hanclinto at gmail dot com
What are you planning on doing with this? Where should I follow along?
I think it's easy to lose sight of these pockets of mundane goodness, and I appreciate you highlighting them.
All have best-in-class context length, and the numbers look very impressive. Very excited to see this release!
Not to be "that guy" [0], but (especially for users who aren't already in ChromaDB) -- how would this be different for us from using a RAM disk?
> "ChromaFs is built on just-bash ... a TypeScript reimplementation of bash that supports grep, cat, ls, find, and cd. just-bash exposes a pluggable IFileSystem interface, so it handles all the parsing, piping, and flag logic while ChromaFs translates every underlying filesystem call into a Chroma query."
It sounds like the expected use-case is that agents would interact with the data via standard CLI tools (grep, cat, ls, find, etc), and there is nothing Chroma-specific in the final implementation (? Do I have that right?).
The author compares the speeds against the Chroma implementation vs. a physical HDD, but I wonder how the benchmark would compare against a Ramdisk with the same information / queries?
I'm very willing to believe that Chroma would still be faster / better for X/Y/Z reason, but I would be interested in seeing it compared, since for many people who already have their data in a hierarchical tree view, I bet there could be some massive speedups by mounting the memory directories in RAM instead of HDD.
Especially if you want other apps to run at the same time, I think it's safer to stick with something more like 9b. You can see a table with quantized sizes here [0] -- yes, there are smaller quants than Q4_K_XL, but then you're down in the weeds with nickel-and-diming things, and if you want to even keep something like a (memory-hungry) instance of VSCode running, good luck.
IMO -- if 9b is doing the job, stick with 9b.
We made a similar game several years ago for the Pyweek game competition, but there wasn't the fun "letter invaders" style that this one has.
https://pyweek.org/e/RegExExpress/
I really like your implementation!
Might be good to limit some of the special operators to give more focus -- otherwise the early levels are a bit too solvable with ".*"
Which fact did I report incorrectly?
I was not answering the question in generalities. I was answering the question that asked for specifics about this case ("why so many drawn guns? Fun music videos aside, what was the background here?"). The answer: serving a warrant for kidnapping and drug trafficking.
You may disagree with my :opinion: (that armed response during the serving of a warrant for kidnapping is reasonable, or that the cops should not have disconnected his cameras), but you can't just claim that I'm lying about the facts of this case and then not bring receipts.
I don't live in Adams County, but they are our direct neighbors here in rural southwest Ohio. We like Afroman over here. :)
I think the answer to your question is the warrant that they were serving involved kidnapping and an alleged torture dungeon along with drug trafficking charges. Yes, it may sound ridiculous on the surface, but an informant apparently testified to this and a judge approved it, so that's the warrant they were serving.
If one reads the warrant and considers the possibility that the testimony of the witness might have been true, then their show of force seems much less unreasonable.
Disconnecting his cameras? Stealing his money? That's absolutely not reasonable in any case. Afroman has a lot of support in our rural Ohio community, and we're all cheering for him. :)
Yes, thank you for the validation! That was the core of what sparked this for me -- my cartoon drawing of blockchain is that it's dependent on problems that are difficult to solve (improve this codebase), but easy to verify (loss went down).
Like you noted, this is also cool in that it's valuable work (unlike most of these workloads)
I appreciate the opportunities for optimization you've laid out (such as zkVM) but it feels like that would be optional compared to the basic thing here?
And yeah -- what one _does_ with the crypto-credits is pretty open-ended. Like you said, drawing on the swarm for training or inference or whatever you need -- it feels like the sort of thing that one could use as a GPU battery of sorts. Most of my personal GPU work goes in bursts -- but most of the time my GPU is sitting idle.
Most of the other GPU share-cropping sorts of ideas I've seen floating around lack the ability to independently prove that work was done. Having a global metric for a shared target like this seems to solve what has been lacking in a lot of other distributed systems I've seen.
Looking at the graph on the website, it looks like it's already got a bit of a scoreboard and independent verification / validation of results. Feels like it would be a relatively small jump to crowdsource this and put it into a formal blockchain.
But the next natural question is: Would we stand to gain anything by adding blockchain to this?
To my smooth-brain naiveté, this feels like the sort of thing that we could reward with some sort of cryptocurrency in a blockchain? It's difficult to achieve gains, but it's relatively quick to independently verify (5 minute training runs).
I know "blockchain all the things" is sooooo 8 years ago, but I'm looking at the descending graph of progress here, and wondering if being able to claim improvement tokens (even for no reason other than NFT-esque bragging rights) wouldn't be a cool thing here?
I'm asking this as someone who knows next to nothing about crypto or blockchain or any of those things, but mainly thinking of trying to gamify assigning GPU rigs to "mining" these measurable improvements.
That said, I also wouldn't hate seeing an official playground where it is cordoned / appreciated for bots to operate. I.E., like Moltbook, but for HN...? I realize this could be done by a third party, but I wouldn't hate seeing Ycombinator take a stab at it.
Maybe that's too experimental, and that would be better left to third parties to implement (I'm guessing there's already half a dozen vibe-coded implementations of this out there right now) -- it feels more like the sort of thing that could be an interesting (useful?) experiment, rather than something we want to commit to existing in-perpetuity.
It sounds like a fan-driven reboot of this game has a fairly decent following, in a very similar way to what UO experiences? It feels like there is still player desire to have mundane sorts of immersive RPG experiences in this way.
It feels difficult to create hobbyist peripherals that interface with ones' phone -- trying to get cross-platform credentials to plug your own Arduino in via USB or connect via Bluetooth feels like a chore. I like the idea of phones communicating via some sort of audio library (ultrasonic maybe?) -- like R2-D2 chirping back and forth to communicate with other droids. I think this sort of thing could be part of a nice network of cross-device communication.
I don't know if there are "family-friendly" presets for such things, but so far Copilot has been reasonably helpful at helping me along -- I just don't have it all working yet. If you have any resources you come across, I would be interested in comparing notes. :)
The backwards compatibility here is pretty clutch. I agree -- if he can build something that is compatible with old files AND pushes things forward for new, then this could do some really awesome stuff.
For criminal cases, there are public defenders, but for civil cases, I don't believe there is any such thing?
If you can afford a lawyer and your opponent can't, there is a lot that you can do to bully your opponent into making it not worth it for them to fight the case.
One of my controversial opinions is that -- if we can enable easy access to AI, then we can give provide much broader access to legal or medical advice. Maybe not the best, maybe not always right, but even if it's average-ish advice, then I think that could often be better than nothing at all.
We can't completely prevent bad people from doing bad things with AI, but I see this as one of the clear ways that we could do some really good things with AI.
Here's holding out hope that we'll still be able to see an M5 Ultra then! :)
The 128gb limitation feels like it's portrayed as a limitation of the M5 chip itself -- not just of the Macbook Air product line.
If one wants to serve large-ish LLMs locally, an M3 Mac Studio w/ 512 GB/RAM is still a super compelling option, and I was hoping that the M5's would bump us up to 1TB of unified memory.
Don't get me wrong -- seeing them use LMStudio as the benchmark for measuring local LLM inference is super awesome for the local / open-source LLM community, but seeing this have the same 128GB cap as the M4 is... disappointing?
M3 Studio is still the best option if one wants 512GB.