1作者: yousef0626 天前原帖
Most consensus libraries (Raft, Paxos) treat the state machine as a pure black box. This is fine until your state machine needs to actually do something, like charge a credit card, fire a webhook, or send an email.<p>If a leader crashes after the side effect but before committing it, you get duplicates. This is my attempt at fixing this problem from first principles ish: build chr2 to make crash-safe side effects first-class citizens.<p>mechanism:<p>Replicated Outbox: Side effects are stored as &quot;pending&quot; in replicated state. Only the leader executes them under a fencing token.<p>Durable Fencing: A manifest persists the highest view using atomic tmp+fsync+rename. This ensures a &quot;zombie&quot; leader can&#x27;t wake up and double-execute stale effects.<p>Deterministic Context: Application code receives a deterministic RNG seed and block_time from the log, ensuring 1:1 state transitions during replay.<p>Strict WAL: Entries are CRC’d and hash chained. it is designed to prefer halting on mid-log corruption over guessing.<p>The Trade-offs: Side effects are intentionally at-least-once; &quot;exactly-once&quot; requires stable effect IDs for sink-side deduplication. It’s a CP system safety over availability.<p>Repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;abokhalill&#x2F;chr2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;abokhalill&#x2F;chr2</a><p>if you’ve ever had “exactly once” collapse the first time a leader died mid flight, you know exactly why I built this.
4作者: dangoodmanUT27 天前原帖
快速搭建了一个非常具体的代理,允许下游定义用于代理请求的IP,并内置了速率限制机制,以协调客户端之间的上游速率限制。这在你拥有多个IP的代理节点时特别有用,无论是想使用特定的IP,还是希望在这些IP之间轮换使用。此外,它还可以防止由于不同客户端无法协调速率限制而导致的上游速率限制问题。Opus在我的规格说明中基本上能够一次性实现每个功能,这非常酷(这也显示了规格说明的有效性)。
9作者: oger27 天前原帖
在混沌通信大会上,制作一个一维乒乓球游戏算是一种入门仪式。我受到在38C3上看到的一个版本的启发,为39C3制作了自己的版本。很多人都喜欢玩这个游戏,甚至Elliot Williams在他的39C3 Hackaday播客中也提到了它。我可以证明:这款游戏确实很有趣,因为乍一看它非常简单——但等到速度加快时就另当别论了……对于这样一个小项目来说,乐趣与工作量的比率相当不错。 我借此机会在我现有的代码基础上玩了一下Claude Code,发布了一个相对不错的GitHub仓库。它运行得非常顺利,没有任何问题或编译错误——真令人印象深刻。这是测试一些功能的好方法。 希望你们玩得开心,自己动手制作一个版本。而且还有很多创意可以实现。我期待着你们的反馈! 我们会不会最终形成一个联网的一维乒乓球游戏联盟呢? ;-)
33作者: ag827 天前原帖
<a href="https:&#x2F;&#x2F;xcancel.com&#x2F;dyushag&#x2F;status&#x2F;1993143599286886525" rel="nofollow">https:&#x2F;&#x2F;xcancel.com&#x2F;dyushag&#x2F;status&#x2F;1993143599286886525</a><p><a href="https:&#x2F;&#x2F;claude.ai&#x2F;share&#x2F;e368b733-71a4-4211-99f5-6b6cc717b575" rel="nofollow">https:&#x2F;&#x2F;claude.ai&#x2F;share&#x2F;e368b733-71a4-4211-99f5-6b6cc717b575</a>
1作者: iamgaazi27 天前原帖
Hi HN,<p>I’m building QR Spaces after noticing how freelancers and small agencies end up sharing too many separate links (portfolio, socials, contact, calendar).<p>The idea is simple: instead of another generic link-in-bio page, you get one QR-powered profile with your own custom domain.<p>This is still early. Right now I’m mainly trying to validate: - who feels this pain more (freelancers vs agencies) - whether QR-based sharing is actually useful in real life<p>I’d really appreciate honest feedback or criticism. Happy to answer any technical or product questions.