最新

我的 Google 账号自 2024 年 3 月起被 GCP 停用。<p>过去 2 年里，我通过 ts-consult@google.com 提交了多次申诉。每次收到的都是同样的自动化模板，要求我解释情况，我回复了详细信息，然后就石沉大海，没有任何回应。从来没有真人回复过。<p>案例编号：#1-8622000037271<p>时间线： - 2024 年 3 月：账号被停用，提交申诉 - 2024 年 4 月：收到自动化信息请求，我回复了 - 2024 年 11 月：收到更多自动化邮件，我再次回复 - 2024 年 12 月至今：完全沉默<p>我是一名加州大学伯克利分校的计算机科学研究员。这严重影响了我的工作。<p>有没有人成功让 Google 审核过 GCP 停用申诉？如何才能联系到真人？

我读过很多据称是真正的 OpenClaw 用户分享的令人难以置信的故事，比如他们的助手（从有用型到戏剧性）(1) 规划旅行并预订一切；(2) 创办公司并建造东西；(3) 进入股市并赔光了钱……Moltbook 增加了更多乐趣。 有趣的是，我在我熟悉的技术社区里找不到一个 OpenClaw 用户，大概是因为设置它需要一些功夫，而且人工智能接管一切的概念对于普通的技术爱好者来说太可怕了。 我浏览了 Hacker News 上的评论，其中很多都在讨论这个想法，但没有分享第一手的用户体验。少数尝试过的 HN 用户因为各种原因放弃了/失败了： - <a href="https://news.ycombinator.com/item?id=46822562">https://news.ycombinator.com/item?id=46822562</a>（消耗了太多 token） - <a href="https://news.ycombinator.com/item?id=46786628">https://news.ycombinator.com/item?id=46786628</a>（同上 + 安全隐患） - <a href="https://news.ycombinator.com/item?id=46762521">https://news.ycombinator.com/item?id=46762521</a>（由于沙盒机制导致安装失败） - <a href="https://news.ycombinator.com/item?id=46831031">https://news.ycombinator.com/item?id=46831031</a>（moltbook 无法工作） 我闻到了炒作的味道…… HN 用户们，你们有人实际运行过 OpenClaw 并让它做过任何有用或有趣的事情吗？可以分享一下你们的经验吗？

<a href="https://archive.ph/lZlAs" rel="nofollow">https://archive.ph/lZlAs</a> <a href="https://www.theguardian.com/technology/2026/jan/31/us-authorities-reportedly-investigate-claims-that-meta-can-read-encrypted-whatsapp-messages" rel="nofollow">https://www.theguardian.com/technology/2026/jan/31/us-author...</a>

大家好，HN， 我分享一下 S2C 的 Alpha 版本，这是一个基于 S3 构建的状态机复制系统。 目标是让分布式应用程序在无需节点仲裁的情况下，也能保持状态的一致性，同时保证可用性和一致性。 这个想法源于一个使用 S3 的副项目，当时我需要强一致性的分布式状态，但又不想增加一个单独的共识依赖。最初我尝试直接使用 S3 进行协调，但变得很混乱。最终，我意识到我需要一个带有确定性日志的复制状态机，然后它就变成了一个独立的的项目。 为了缓解 S3 的延迟和 API 成本，它默认使用基于时间和大小的批量处理。 S2C 支持： - 可线性化的读写操作（单节点） - 精确一次的命令语义（对于具有稳定身份的节点） - 动态节点加入和从零节点开始的冷启动恢复 - 无需时钟或租约即可实现脑裂安全 - 快照、日志截断等 当然，它用延迟和 S3 操作成本换取了操作的简单性——并非用于取代高吞吐量的 Raft 环。而且，显然，它只适用于已经使用 S3（或具有类似保证）的架构。 到目前为止，它已经通过了混沌/故障注入测试（崩溃、分区、领导者 kill）；计划进行形式化验证。 它仍处于 Alpha 阶段，但我希望大家试用、实验并提供反馈。 如果您有兴趣，代码和一份深入的指南在这里：[<a href="https://github.com/io-s2c/s2c" rel="nofollow">https://github.com/io-s2c/s2c</a>]

“每请求的Token数” 这种计费模式对我们的生产环境来说一直具有误导性。真正的成本驱动因素似乎是以下几个乘数：重试/429错误、工具扇出、P95上下文增长以及安全检查。 在你的生产LLM系统中，最大的成本乘数是什么？哪些策略有效（限制、降级模式、回退、硬性失败）？