Readit Newsnovoreorx commented on GNU recutils: Plain text database gnu.org/software/recutils... · Posted by u/polyrand
Reminds me of https://news.ycombinator.com/item?id=45458455
In the AI era, the rec file seems to be a great choice for formatting text that will be feed into LLMs. Imagine converting an HTML table into a RAG file, the context will be much clearer.
They primarily serve different purposes, but they could complement each other.
Durable Streams are a lightweight network protocol on top of standard HTTP. When you are building a synchronisation layer for let's say a local-first app, you need to not only exchange data over some lower-level protocol (i.e. HTTP / SSE / WS), but you also have to define a higher-level protocol on how the client & server are going to communicate - i.e. how to resume data fetching once the client reconnects, based on the last data that the client received (~offset). Since the reconnect & offset should be automatically handled by the Durable Stream, you could just build your domain logic on top of it.
CRDTs are primarily meant to resolve data conflicts, usually client-side, based on a defined conflict resolution strategy (i.e. last-writer-wins). Some of the CRDT libraries, like automerge, loro or yjs, also implement a networking layer to exchange the data between nodes (could be even P2P), meaning they already have a built-in mechanism for reconnection and offset (~send me data since X). However, nobody forces you to use their networking layer, meaning that with Durable Streams, you would have a good starting point to build your own.
Great answer! I was always confused about how CRDTs were transferred. Like you said, existing implementations often come with their own in-house networking solutions. Now it's totally clear, since CRDTs are only about data, it's no wonder their transfer methods differ. That makes Durable Stream a very good companion to work with CRDTs—the boundaries are clear, and they complement each other perfectly.
I also feel that I could give Durable Stream's protocol spec to a coding agent, and it could blend into the best suited implementation for my current project (say, a Go repo). The simple yet sophisticated spec is more valuable than a bunch of SDKs.
https://django-ninja.dev/ should be mentioned in this discussion, it's the best thing happen to my 12 years Django career
Agreed.
If the only way to get your digital property back is a public plea to your Lord, that's called feudalism. Everyone should be treated fairly, not only those who can get their public pleas heard.
You just made it clear to me why I felt not resonated and a bit uncomfortable reading that article, despite I thought I should be. Because what I want to see is something straight like "fuck you Apple", not a begging and emphasis on how much the author has contributed to the megacorp.
novoreorx commented on Poetiq shatters ARC-AGI 2 benchmark at half the cost poetiq.ai/posts/arcagi_ve... · Posted by u/flavio87
Am I crazy to think these models have actually surpassed human performance on ARC 2? https://www.lesswrong.com/posts/DX3EmhmwZjTYp9PBf/ai-perform...
This is not surprising, rather, it's the 100% figure that makes me skeptical. In fact, the intelligence level of ordinary people isn't that high, and AI can indeed surpass it. Otherwise, why would we use it?
novoreorx commented on Go is portable, until it isn't simpleobservability.com/b... · Posted by u/khazit
This article reminds me of the days before LLMs ruled the world, when the word "agent" was most commonly used in the DevOps area, representing the program that ran on a remote machine to execute dispatched jobs or send metrics. Now I wonder how many developers would look at "agent" and think of this meaning.
If I were the person at Apple in charge of this kind of matter, I would ignore this case, just as I do for other regular people. Everyone should be equally not cared for by Apple. That's how Apple sucks in a way I can accept myself still using their product.
Seems to be another great way to build local-first applications, which makes me think of CRDT, and come up with this silly question: what's the relationship between Durable Stream and CRDT, are they replacements for one another, or can they work well together?
I was happy to read this part at first, because it highlights what I hate most about Headless CMS. Hearing a company in the industry admit to this problem gave me hope that they are now going to fix it or have better solutions. But no, the rest of this article is just rambling about how 'you don't really know about CMS'. I mean, if you know better than us do, then why can't the experience of using Headless CMS be better? You are here to solve the problem, right?