## Theseus：一种新的Windows模拟方法 这篇文章详细介绍了作者从开发retrowin32（一个Windows模拟器）转向一个名为Theseus的新项目的过程。受到AI辅助代码生成快速发展（如使用Claude构建的retrotick）的启发，作者质疑了模拟的核心目的，并探索了替代方法。 Theseus利用**静态二进制翻译**：它不解释或JIT编译x86指令，而是将整个程序翻译成源代码，然后利用优化编译器生成主机架构的本机机器码。这避免了JIT的复杂性，同时旨在提高性能。这个过程本质上是将.exe“编译”成一种携带虚拟x86状态的形式。 这种方法与**反编译**相似，突出了在运行特定程序时愿意手动协助，而不是追求通用兼容性。它还提供了诸如使用本机工具进行更轻松的调试和性能分析等优势。作者注意到与WebAssembly执行的相似之处，其中主机环境在受控的“机器”中运行代码。 最终，Theseus代表着一种向*提前*部分评估模拟过程的转变，简化了开发并可能解锁进一步的优化——甚至到手动用本机实现替换有问题代码段的程度。
每日HackerNews RSS
对不起。
启用 JavaScript 和 Cookie 以继续。
## Cal.diy：一个社区驱动的日程安排平台
Cal.diy 是 Cal.com 的完全开源分支，专为自托管和希望完全控制其日程安排基础设施的个人设计。它适用于个人、非生产环境的使用，需要高级的服务器管理、数据库管理和安全方面的技术知识。**与 Cal.com 不同，Cal.diy 移除了所有企业/商业功能**（如 Teams、SSO 和高级分析），并采用 100% MIT 许可 – 没有“开放核心”限制。
**要运行 Cal.diy，您需要 Node.js (>=18.x)、PostgreSQL (>=13.x) 和 Yarn。** 安装涉及克隆仓库，使用安全密钥（NEXTAUTH_SECRET, CALENDSO_ENCRYPTION_KEY）配置 `.env` 文件，以及设置数据库。Docker 和 Docker Compose 也支持，以便更轻松地部署。
虽然 Cal.diy 提供了灵活性，但它没有托管/管理的版本 – 您需要负责所有的维护和安全。该项目欢迎社区贡献（参见 `CONTRIBUTING.md`），但这些贡献与 Cal.com 平台是分开的。详细的文档，包括设置指南和集成说明（Google Calendar、Zoom 等），可在仓库中找到。
## Cal.com 战略转变推出 “Cal.diy”
Cal.com 发布了其日程安排软件的开源社区版 “Cal.diy”，但此举引发了争议。Cal.com 最初宣传本地部署开源具有安全优势，但现在*不建议*将 Cal.diy 用于生产环境，理由是法律责任。
这种转变导致了“诱饵和转换”的指责，用户指出之前的博客文章提倡开源安全性。一些人推测，这种变化是由商业问题或其托管服务中潜在的未公开安全漏洞驱动的。另一些人认为，这是为了限制志愿者贡献并控制未来的开发。
这场讨论凸显了开源许可的复杂性以及公司重新评估其承诺的可能性。用户正在探索替代方案，如 cal.rs 和 cal.diy 分支，一些人对公司将开源作为增长策略，然后在限制访问的做法表示沮丧。这一事件强调了真正由社区拥有的项目的重要性，以及依赖公司支持的开源计划的潜在陷阱。
框架公司于2026年4月进行的测试，使用配备英特尔®酷睿™Ultra X7 358H处理器、英特尔®Arc™B390显卡、2.8K触摸屏、32GB内存和1TB存储的Framework Laptop 13 Pro进行测试。显示亮度设置为250尼特，显示刷新率设置为60Hz，扬声器音量为30%，禁用Dolby Atmos®，并启用无线功能。电池续航时间通过在Windows 11的最佳电源效率模式下，在Netflix应用程序中流式传输Netflix 4K内容进行测试。电池续航时间因使用情况和配置而异。
Meta正在在美国员工的电脑上部署新的追踪软件，用于收集数据以训练人工智能模型。该软件将监控鼠标移动、点击、键盘敲击，并在与工作相关的应用程序内定期截屏，以提高人工智能自主执行任务的能力——特别是下拉菜单选择和键盘快捷键使用等领域。 根据内部备忘录，收集的数据*不会*用于员工绩效评估。Meta强调，其目的仅仅是通过提供真实世界的使用案例来增强其人工智能代理。据报道，已经采取了安全措施来保护敏感信息。 这项由Meta SuperIntelligence Labs团队主导的举措，旨在利用员工的工作流程来完善人工智能模型，并构建更强大的人工智能助手，以完成日常任务。
《大英百科全书》第十一版 文章贡献者 主题 辅助 《大英百科全书》第十一版 · 1910–1911 ∼◆∼ 完全可搜索、交叉引用和注释。
## britannica11.org：复活的1911年百科全书
一位开发者将1911年版《大英百科全书》重建为一个简洁、结构化且易于浏览的网站([https://britannica11.org/](https://britannica11.org/))。该项目重构了原始版本中约37,000篇文章，保留了原始格式、交叉引用以及指向扫描页面的链接。
用户可以搜索全文、按章节浏览以及访问贡献者信息。该网站旨在复制使用原始百科全书的体验，同时提供现代化的可用性。
讨论中，用户表达了对该项目的赞赏，提出了改进建议（例如并排文本和图像视图），并对潜在的大批量数据访问以用于研究和培训表示兴趣。开发者正在积极寻求关于搜索质量、导航和结构准确性的反馈。 许多用户也注意到1911年版本的独特视角和语气，反映了第一次世界大战前的乐观主义。
## 从简单的网页到现代的复杂性与更简单的路径
网页最初由简单的静态HTML页面组成。随着时间的推移，交互性通过表单和JavaScript增加，最初保持着直接的结构：HTML、CSS、JavaScript、服务器和数据库。然而，AJAX和单页面应用（SPAs）的引入——使用React、Vue和Angular等框架构建——极大地增加了复杂性。现代Web开发现在需要大量的工具（Webpack、Vite、TypeScript）来*转换*开发者友好的源代码为浏览器兼容的JavaScript，这通常与最终的运行时状态相去甚远。
这种复杂性源于弥合现代源代码与浏览器原生理解之间的差距。当前的生态系统堪比巴别塔，要求开发者掌握众多技术。
一种潜在的解决方案建议回归服务器渲染HTML，利用HTMX进行动态更新，并使用HTML Web Components构建可重用的UI元素。这种方法最大限度地减少JavaScript，简化工具，并更紧密地与浏览器基础保持一致。虽然需要改变思维方式，但它提供了诸如改进SEO、性能、可测试性以及更易于管理的开发流程等好处。这种更简单的替代方案旨在减少构建过程和工具开销，通过拥抱浏览器的原生能力，使Web开发再次变得高效。
## 现代前端开发的复杂性：总结
最近在Hacker News上进行了一场关于现代前端开发日益复杂的讨论。许多开发者对浏览器原生支持的基本UI元素不足表示沮丧——例如，轮播图和工具提示需要大量的自定义JavaScript，而不是简单的HTML标签。Open UI等倡议旨在解决这个问题，但进展缓慢。
这场辩论凸显了追求全面的浏览器API与对灵活性的需求之间的紧张关系。一些人认为标准化的组件可以简化开发，而另一些人则认为巨大的潜在变化使得标准化不切实际。
像HTMX这样的替代方案，强调服务器端渲染和最少的JavaScript，也被提出，但人们对其可扩展性和对复杂应用程序的适用性表示怀疑。核心问题似乎是，网页应用程序开始被视为两个独立的实体（前端和后端），导致了开销增加。最终，这场讨论表明人们渴望更简单、更高效的Web开发，但也承认了在简单性和现代Web应用程序的需求之间取得平衡的挑战。
## 未开发的潜力：创新的奶酪组合 奶酪世界仍然蕴藏着令人兴奋的可能性，源于对牛奶和技术组合的探索。许多“空白”并非源于化学限制，而是传统、地理或物流的限制。 一些有前景的想法包括**牦牛奶格鲁耶尔奶酪**，利用牦牛奶的丰富性结合瑞士技术，以及**白霉类水牛奶马苏里拉奶酪**，创造出极其浓郁的三重奶油奶酪。结合传统，**蓟花凝乳水牛奶托尔塔**可以产生一种风味浓郁、可舀取的奶酪。同样，**白霉类牦牛奶奶酪**有望带来一种独特浓郁的四重奶油体验。 除此之外，**用布包裹的绵羊切达奶酪**可以提供更致密、更结晶的切达奶酪，而**烟熏骆驼奶酪**可能可以克服骆驼奶酪具有挑战性的风味特征。最后，尽管存在物流障碍，**驯鹿奶硬奶酪**由于其牛奶的极高脂肪含量，可能成为你能想象到的最浓郁的硬奶酪。这些例子表明，大胆的奶酪制造商可以解锁真正的新颖美味的创作。
## 黑客新闻讨论：“奶酪元素周期表”
一个名为“奶酪元素周期表”（cheesemap.netlify.app）的新网站在黑客新闻上引发了争论。一些用户认为它是一个有趣且有用的资源，但许多人对它的准确性和来源表示怀疑。
主要担忧是强烈怀疑该网站很大程度上是由人工智能生成的，缺乏明确的来源或作者。几位评论员指出，表格和描述中都存在人工智能生成内容的明显迹象。这引发了关于信任人工智能生成内容的讨论，以及普遍认为如果没有可验证的信息，该网站的价值会降低。
尽管存在这些担忧，一些人还是为该网站辩护，认为它的娱乐价值超过了缺乏严格研究。其他人则指出了不准确之处，例如包含马奶酪或错误分类奶酪类型。讨论还涉及了人工智能生成网站的美学趋势以及“氛围投票”取代真正努力的潜力。
最终，这场对话揭示了人们对在线人工智能生成内容的日益关注，有时甚至是厌恶，以及对经过充分研究和精心制作的资源的持续欣赏。
## ctx：Claude & Codex 的本地上下文管理 **ctx** 是一款本地优先的工具，用于管理与 Claude 和 Codex 的对话，提供持久上下文、分支和搜索等功能——所有这些都不需要 API 密钥。它将数据存储在本地 SQLite 数据库和文件中，从而实现离线访问和完全控制。 **主要特点：** * **持久上下文：** 无缝恢复或分支对话，保留确切的聊天记录。 * **安全分支：** 从现有对话创建新的工作流，而不会影响原始对话。 * **索引搜索：** 快速找到已保存工作流和会话中的相关上下文。 * **上下文整理：** 钉住、排除或删除已保存的条目，以优化未来的模型输入。 * **本地优先：** 完全在本地运行，使用 SQLite 和文件——无需云依赖。 **入门：** 克隆仓库 ([https://github.com/dchu917/ctx.git](https://github.com/dchu917/ctx.git)) 并运行 `./setup.sh`。 使用 `/ctx start`、`/ctx resume` 和 `/ctx branch` (Claude) 或 `ctx start`、`ctx resume`、`ctx branch` (Codex) 等命令管理工作流。 网页界面 (`ctx web --open`) 允许详细查看和编辑上下文。 **使用场景：** 非常适合希望在多个会话中保持一致的上下文、试验不同的对话分支以及高效检索过去交互的开发者。
## Ctx：AI 代理的本地简历工具
Ctx 是一款新的、本地优先的技能，专为 Claude Code 和 Codex 设计，旨在改善工作流管理。它解决了原生 `/resume` 功能的局限性，提供了一个持久的、基于 SQLite 的系统，用于组织和继续编码代理会话。用户可以创建包含会话、笔记、待办事项和“简历包”的工作流，轻松搜索和从现有上下文分支。
该工具允许在 Claude 和 Codex 之间无缝恢复工作，保持稳定的会话绑定——确保代理继续*完全相同的*会话，而不仅仅是最新会话记录。虽然承认切换代理时由于失去“思考令牌”可能带来的性能影响，但开发者认为它对于长期任务和管理多个并发项目很有价值。
Ctx 可以通过单个命令 (`./setup.sh`) 轻松安装，并通过 `/ctx [命令]` 在 Claude 和 `ctx [命令]` 在 Codex 中访问。创建者最初是为个人使用而构建的，但与 Hacker News 社区分享，强调了它对于同时处理多个 AI 辅助编码会话的人的优势。 许多评论员讨论了类似的需求和项目，包括构建自定义框架和归档对话。
## 近期攻击链的 SIEM 检测 本指南概述了针对 Google Workspace 及相关系统的近期攻击链的检测策略，重点关注 OAuth 应用程序被攻陷以及随后的凭证滥用。 **关键检测领域：** * **OAuth 异常：** 警报与已知恶意 OAuth 客户端（Context.ai）相关的活动、过于宽松的应用程序授权以及来自意外 IP 范围的令牌使用情况。 * **横向移动：** 监控异常的 SSO/SAML 身份验证、可疑的电子邮件/Drive 活动（凭证收集）、不寻常的 OAuth 连接工具访问以及 Google Workspace 内的权限提升尝试。 * **环境变量访问：** 检测 Vercel 等平台中不寻常的环境变量访问模式，尤其来自用户帐户或不一致的来源。 * **下游凭证滥用：** 查询访问日志（AWS CloudTrail、GCP/Azure 审计日志、SaaS 提供商仪表板），以查找来自未知 IP 或在非活动期间使用的受损凭证。 * **泄露通知：** 优先处理并调查来自 GitHub、AWS 和 SaaS 提供商等平台的泄露凭证通知，作为潜在的入侵指标。 组织应将这些模式转换为 SIEM 规则（Sigma、Splunk、KQL 等），根据其特定的日志源验证字段名称，并建立正常活动的基线。 对这些指标进行主动监控和快速响应对于减轻此攻击链的影响至关重要。
## Vercel 漏洞总结
Vercel 近期发生的一起漏洞源于一个被攻陷的 OAuth 应用 – Context.ai，该应用与 Vercel 员工的 Google Workspace 账户关联。攻击者通过恶意软件（Lumma Stealer）获取访问权限，并在数月内利用此权限枚举客户的环境变量。
核心问题在于 OAuth 访问和环境变量处理方面的安全措施不足。具体而言，Vercel 之前缺乏环境变量的“敏感”标记，导致它们以明文形式暴露。虽然现在已实施此标记，但这并未完全解决问题，因为变量在构建过程中仍然可访问。
讨论的重点是需要更好的密钥管理实践，包括使用安全金库、限制 OAuth 范围以及实施短寿命凭证。人们对依赖第三方 OAuth 提供商以及类似平台中可能存在的广泛漏洞表示担忧。该事件还引发了关于人工智能在加速攻击中的作用，以及设计系统时假定提供方被攻陷的重要性。