最新

用反射等效替代方法调用和字段访问 → 使静态分析和反编译工具的效果大大降低。此功能为实验性，预计会有性能损失。

S2一年前在Hacker News上发布了我们的介绍博客文章（<a href="https://news.ycombinator.com/item?id=42480105">https://news.ycombinator.com/item?id=42480105</a>）。S2最初是一个无服务器API——可以把它想象成S3，但用于流数据。 流作为云存储原语的想法引起了很多人的共鸣，但缺乏开源选项成为了采用的一个障碍——尤其是对于那些本身就是开源项目的团队！因此，我们决定构建它：<a href="https://github.com/s2-streamstore/s2" rel="nofollow">https://github.com/s2-streamstore/s2</a>。 s2-lite采用MIT许可证，使用Rust编写，并使用SlateDB（<a href="https://slatedb.io" rel="nofollow">https://slatedb.io</a>）作为其存储引擎。SlateDB是一个基于对象存储的嵌入式LSM风格的键值数据库，这使得它非常适合提供与s2.dev相同的耐久性保证。 您可以指定一个桶和路径，以便在像AWS S3这样的对象存储上运行——或者完全跳过，直接在内存中运行。（这也使得它成为开发/测试环境的优秀模拟器）。 为什么不直接开放我们的云服务后端呢？s2.dev采用了一个解耦的架构，多个组件在Kubernetes中运行，包括我们自己的K8S操作员——我们在优化一个彻底的多租户云基础设施SaaS的操作时做出了权衡。通过s2-lite，我们的目标是推出一个操作简单的产品。两者之间有很多共享代码，现在都在开源代码库中。 一些功能仍然缺失（尤其是资源和记录的删除），但s2-lite已经基本准备就绪。请尝试在README中的快速入门，使用s2 CLI流式播放《星球大战》！ S2与Kafka或Redis Streams之间的主要区别在于支持大量的耐久流。我曾在关于代理会话的背景下撰写过相关博客（<a href="https://s2.dev/blog/agent-sessions#landscape">https://s2.dev/blog/agent-sessions#landscape</a>）。Kafka和NATS Jetstream将流视为预配置的资源，协议/实现围绕这种假设进行设计。Redis Streams和NATS允许更多的流，但没有适当的耐久性。 云服务是完全弹性的，但尽管lite是一个需要垂直扩展的单节点二进制文件，您仍然可以在很大程度上使用它。lite中的流在SlateDB中“仅仅是键”，而云对象存储是无底的——当然，元数据开销是不可避免的。 我很期待在s2-lite中改进写入的流水线处理以提升性能（已经在一个开关后面支持，但需要上游接口的更改以确保安全）。这是我们在s2.dev中广泛使用的一种技术。基本上，当您处理像S3这样的高延迟时，您希望在客户端和存储之间保持数据流动，而不是逐步进行，先等待确认再进行下一次写入。这就是为什么S2在无状态REST之外，还采用了基于HTTP/2的会话协议。 您可以使用`s2 bench` CLI命令自行测试lite的吞吐量/延迟。主要因素包括：您与存储桶区域之间的网络质量、远程存储的延迟特性、SlateDB的刷新间隔（`SL8_FLUSH_INTERVAL=..ms`），以及流水线处理是否启用（`S2LITE_PIPELINE=true`以体验未来）。 我会在这里收集想法和反馈，并回答任何问题！

我曾是他们平台上的企业客户。Cerebras开始频繁终止生产模型，并每隔几个月就更换一次。这次他们通知我们将终止Llama 3.3 70B，这是我所订阅的模型。 他们没有为我们提供替代计划，而是告诉我们其他所有计划都已售罄，并将我们踢出了他们的平台。 他们的Discord支持群里有多个企业客户都遭遇了相同的待遇。他们自己的支持人员告诉客户要迁移到Groq。 与一个如此频繁随机终止模型的公司建立稳定的业务是不可行的。这样一家公司不尊重客户（尤其是企业客户，而不仅仅是小型用户），如果决定停用你的模型，根本没有任何应急计划。 由于他们的架构限制，他们只能托管有限数量的模型。更新换代速度很快，因此如果你的模型被标记为弃用，你将被迫离开平台。 Cerebras适合个人爱好项目，但绝对没有能力向企业销售“企业”账户。

果然如此。几乎整个公司都离职了，工程部门只剩下不到15个人。

我已经构建代理好几年了，背景工程一直是瓶颈。我很好奇其他人遇到了什么问题。 我遇到的一些困难包括： - 调试代理在决策时实际看到的内容 - 在多代理模式中管理上下文 - 保持历史记录而不占用过多存储空间 你们花时间在什么问题上？

嘿，HN！我是Mudo的创作者。 我之所以制作这个应用，是因为我的治疗师一直让我记录我的焦虑，但我尝试过的每个应用都有20个问题、47种情绪，让我感到不知所措。我通常在两天后就放弃了。 所以我做了一个尽可能简单的版本：4种情绪（快乐、平静、悲伤、焦虑），一键完成。经过30天，我意识到我并不是像我想的那样“总是焦虑”——其实只是星期天晚上（对工作的恐惧）。 技术细节： - 使用SwiftUI构建 - 本地优先存储（注重隐私） - 可选的iCloud同步 - 没有后端，没有追踪，没有广告 目前只支持iOS（抱歉，Android用户）。免费版本运行良好，付费版解锁更多情绪和无限历史记录。 非常希望能得到反馈，特别是关于： - 免费版是否太有限？ - 我应该添加日记功能，还是保持简单？ - 如果你在跟踪焦虑，想要哪些功能？ 感谢你们的关注！

我之所以开发这个工具，是因为我厌倦了Stockfish给出的评估（+0.5），却没有解释实际的计划。大多数开局探索工具专注于统计数据（胜/负/平），而我希望有一个能够解释每一步背后战略意图的工具（例如，“白方走c4是为了限制d5”而不仅仅是“白方走c4”）。 项目概述： 综合数据库：我已经绘制并注释了超过3500个命名的开局变体，涵盖了从主流开局（如西班牙开局、西西里开局）到深度冷门的所有内容。 战略可视化：用户界面突出关键方格，并根据文本解释绘制箭头，动态地将逻辑与棋盘状态连接起来。 混合架构：对于3500多个核心变体，它提供我独有的战略数据。对于更深或更稀有的变体，它无缝地回退到Lichess Master API，以确保探索工具在20步深度内仍然可用。 技术栈：使用Next.js（应用路由）、MongoDB Atlas进行图形数据存储，以及Arcjet用于安全和速率限制。 目前该项目处于测试阶段。我正在努力扩展注释覆盖范围，但主要的理论框架已经绘制完成。 欢迎对用户界面/用户体验或数据结构提出反馈。

我想创建一个简单的老派角色扮演游戏，类似于传统的MUD或早期的MMO。刚刚发布了游戏的最小可行产品（MVP），使用了一些来自DCSS的开源资源。不过，与DCSS不同的是，这款游戏的战斗机制类似于《无尽的任务》（EverQuest）或《魔兽世界》（World of Warcraft），实时回合制战斗与技能和法术的使用相结合。<p>这个想法是回归到一种不再手把手引导玩家的游戏体验，让用户能够自由探索这个世界。试试看吧 :)

对于那些在2020年前曾参加过线下技术活动的人，你们会再去参加吗？<p>我觉得美国恢复线下活动的速度比世界其他地区要慢。