2026-01-16

https://news.ycombinator.com/item?id=46635345

总结：Palantir 为 ICE 开发的 ELITE 应用及其潜在影响 (Summary: Palantir's ELITE App for ICE and its Potential Impact)

根据 404 Media 的报道，美国移民及海关执法局 (ICE) 正在使用 Palantir 公司开发的名为 ELITE 的工具，进行大规模的潜在目标筛选和追踪。该工具与 Google 地图类似，但其设计目的是为了识别和标记可能成为被捕目标的人口密集区，特别是移民聚集地。

核心功能及细节：

• 地图定位与目标识别: ELITE 在地图上显示潜在的被捕目标，并根据人口密度等因素进行标记。
• 个人资料 Dossier: 点击地图上的目标后，ELITE 会显示该个人的详细资料，包括姓名、照片、外星人编号 (Alien Number, 美政府为每位移民赋予的唯一代码)、出生日期和完整地址。
• “信心分数” (Confidence Score): ELITE 还会提供关于目标当前地址的“信心分数”，用于评估目标的准确位置。
• 内部文档支持: 404 Media 获取的 ICE 内部材料和官员证词提供了 Palantir 为 ICE 构建技术基础设施与实际行动之间的最直接联系。

道德与伦理问题：

文章强烈批评了 ELITE 应用可能助长种族歧视的风险，并将其与纳粹时期的数据分析能力进行类比。作者质疑 Palantir 员工在开发此类工具时的良知和动机，并探讨了他们如何在享受优越的工作条件和高薪待遇的同时，面对其工作可能造成的负面影响。文章暗示该工具可能被用于非法拘留和针对特定人群的“消失”行动，并提及了 ICE 执法过程中发生的针对平民的暴力事件。

总而言之， ELITE 应用代表了一种利用先进技术进行大规模移民追踪和潜在目标筛选的实践，引发了对执法公正性、隐私保护和道德责任的严重担忧。

OpenBSD/arm64 在 Apple Hypervisor 上的运行支持

摘要：

OpenBSD/arm64 现在可以在 Apple Hypervisor 下作为虚拟机运行，这得益于 Helg Bredow 和 Stefan Fritsch 提交的一系列代码。该开发对使用较新 Apple Silicon Mac 模型的用户来说是一个令人期待的消息。

主要内容：

• Hypervisor 支持: OpenBSD/arm64 现在支持在 Apple Hypervisor 上运行。
• viogpu.c 修复: Helg Bredow 的提交修复了 viogpu.c 文件中的一个问题。该修复涉及将 viogpu_wsmmap() 函数修改为返回物理地址，而不是内核虚拟地址 (KVA)。这解决了在 Apple Hypervisor 上启动 X11 时内核崩溃的问题，并确保了 QEMU 显示正常。此外，还添加了 bus_dmamap_sync(9) 调用，以确保在将帧缓冲区传输到主机内存时，其他 CPU 也能看到更新。
• if_vio.c 的 MTU 支持: Stefan Fritsch 的提交为 if_vio.c 文件添加了对 MTU 功能的支持。具体来说，实现了对 VIRTIO_NET_F_MTU 的支持，允许从 Hypervisor 获取硬 MTU 值。代码还使用 ETHER_MAX_HARDMTU_LEN 作为硬 MTU 限制，并在 Hypervisor 请求的 MTU 大于此值时重新进行功能协商。
• 测试和反馈: 这些开发得益于 kettenis@ 和 @helg 的审查、反馈和测试。
• 当前状态： 该功能目前已包含在 OpenBSD 快照中，鼓励用户在拥有硬件和能力的情况下进行测试并报告问题。

关键词: OpenBSD, arm64, Apple Hypervisor, 虚拟机, 虚拟化, MTU, 帧缓冲区, Apple Silicon

肯塔基坠机事件调查更新：波音公司曾知晓结构缺陷

根据美国国家运输安全委员会 (NTSB) 的调查，2023年11月在肯塔基州发生的UPS货机坠毁事件，其根本原因与波音公司15年前已发现的结构性缺陷有关。

事件经过:

• UPS运营的MD-11F货机在路易斯维尔机场起飞准备期间，引擎从机翼上脱落，导致飞机失控坠毁。
• 事故造成15人死亡，包括3名机组人员和12名地面人员。

调查发现:

• NTSB的最新调查报告指出，引擎安装组件上的裂纹是由于关键轴承和其安装座的“疲劳”造成的。
• 此前，波音公司曾在四次事故中发现过相同部件的失效情况，影响了三架不同的飞机。
• 2011年，波音公司向运营商发送了一封“服务信”，警告他们注意该问题，并建议每五年对该部件进行一次目视检查。服务信并非具有法律约束力的文件。
• 波音公司还指出了飞机维护手册中检查程序的变更，并建议可安装改进的轴承组件，但并非强制要求。

专家观点:

• 前航空事故调查员、现任航空安全顾问Tim Atkinson认为，波音公司认为该部件失效不会对飞行安全造成影响，是“令人不安的”。他强调，该结构是连接引擎和机翼的关键部件，承受推力和阻力等载荷。

背景信息:

• MD-11飞机最初由麦克唐纳道格拉斯公司设计生产，后被波音公司于1997年收购。
• MD-11的生产于2001年停止，但波音公司持续提供零部件和售后服务。
• 波音公司的内部流程近年来受到批评，尤其是在737 MAX飞机设计中存在缺陷的软件问题，导致了2018年和2019年两次事故，共造成346人死亡。此外，2024年初一架新737 MAX飞机的舱门掉落事件也引发了对工厂质量控制的质疑。

波音公司回应:

• 波音公司表示，他们继续支持NTSB的调查，并对失去亲人的家庭表示深切的慰问。

后续情况:

• NTSB的调查仍在进行中，尚未就事故原因得出任何最终结论。最终报告预计将在未来发布。

https://en.wikipedia.org/wiki/List_of_individual_trees

人工智能代理的困境：复杂性、采用度和数据飞轮 (AI Agent Challenges: Complexity, Adoption, and Data Flywheels)

本文分析了为什么尽管人工智能技术取得了显著进步，但我们仍然难以构建出能够解决各种日常问题的通用人工智能代理。文章认为，问题的关键在于人工智能代理的应用范围和采用难度，并提出了一个四象限图来分析不同应用场景的挑战与机遇。

四象限图分析：

文章将人工智能代理的应用场景划分为四个象限，横轴代表解决问题的难度，纵轴代表采用的难易程度：

1. 容易解决，容易采用 (Easy to Solve, Easy to Adopt): 例如，回答支持问题、搜索引擎替代。这是目前最常见的应用场景，但由于门槛低，大型模型提供商（如OpenAI、Google、Anthropic）能够迅速积累大量数据，并凭借其庞大的用户基础和资源优势，容易在这一领域占据主导地位，形成“价值陷阱”。
2. 容易解决，难以采用 (Easy to Solve, Hard to Adopt): 例如，企业内部的流程自动化（如退货处理、密码重置）。虽然应用相对简单，但需要企业级别的决策和复杂的集成，因此数据积累受限于单个客户，但企业特定定制化可以提高产品的粘性。
3. 难以解决，容易采用 (Hard to Solve, Easy to Adopt): 例如，代码生成。由于采用简单，开发者可以快速体验并提供反馈，形成数据飞轮，从而加速模型迭代和性能提升。这是目前人工智能代理发展最快的领域。
4. 难以解决，难以采用 (Hard to Solve, Hard to Adopt): 例如，复杂的工程或运维工作流。虽然潜在价值巨大，但需要大量的投资和定制化，且评估与实施过程也比较复杂。

核心观点：

• 数据是唯一的护城河： 无论在哪个象限，数据都是构建强大人工智能代理的关键。
• 采用难度是数据飞轮的关键： 容易采用的产品能够更容易地收集数据，从而加速模型迭代和性能提升。
• 代码生成领域的成功： 代码生成之所以能取得快速进展，主要是由于其容易采用，并能快速生成反馈数据，形成强大的数据飞轮。
• “难以解决，难以采用”象限的潜力： 尽管挑战较大，但“难以解决，难以采用”象限蕴藏着巨大的商业潜力，未来值得关注。
• 用户体验的重要性： 新的用户体验范式可能会改变用户对人工智能产品的采用方式。

总结：

文章认为，未来人工智能代理的发展方向将更多地集中在“难以解决，难以采用”象限，虽然面临更大的挑战，但也有可能带来更大的回报。 企业需要关注用户体验，构建数据护城河，才能在激烈的竞争中脱颖而出。

tldraw 项目贡献政策更新总结 (Summary of tldraw Contribution Policy Update)

以下是对 tldraw 项目贡献政策更新的总结：

主要变化：

• 自动关闭外部贡献者提交的 Pull Request (Pull Requests): tldraw 项目将开始自动关闭来自外部贡献者的 Pull Request。
• 继续欢迎 Issues, Bug Reports 和 Discussions: 项目仍然欢迎用户提交 Issues (问题报告), Bug Reports (错误报告) 和参与 Discussions (讨论)。

政策原因：

• AI 工具生成贡献增加: 随着 GitHub 上许多开源项目的遭遇，tldraw 也面临着大量由 AI 工具生成的贡献。
• AI 贡献的质量问题: 这些 Pull Request 通常缺乏完整的上下文，对代码库理解不足，且提交者很少参与后续沟通。
• 维护者的承诺: 保留 Pull Request 代表了维护者仔细审查并认真考虑贡献的承诺。为了保持承诺的意义，需要更具选择性。

当前策略：

• 先关闭再选择性重新打开: Pull Request 将首先被关闭，只有真正值得考虑的 Pull Request 才会选择性地重新打开。
• 大多数 unsolicited 提交将不被审查: 预计大多数未经邀请的提交将不会被审查。

未来展望：

• 临时政策: 这项政策是暂时的，直到 GitHub 提供更好的贡献管理工具。
• 期待 GitHub 更新: 项目希望 GitHub 很快推出管理功能，以便可以重新开放贡献。
• 感谢与耐心: 项目感谢所有过去的、现在的和未来的贡献者以及对项目的支持者，并请求大家耐心等待，共同应对开源领域的新挑战。

总结：

tldraw 项目为了维护代码质量和社区健康，采取了限制外部贡献的临时政策，主要原因是 AI 生成的贡献质量普遍不高。 项目期待 GitHub 提供更好的管理工具后，能够重新开放贡献。

英国最新海上风电竞标结果：规模空前，价格低廉

英国近日完成了有史以来规模最大的海上风电竞标活动（AR7），成功授予了总计 8.4 吉瓦（GW）海上风电项目容量，其中固定式风电项目 8.2 GW，浮式风电项目约 200 兆瓦（MW）。 这足以满足近 1000 万户家庭的用电需求。

主要亮点:

• 规模巨大: AR7 是欧洲有史以来规模最大的海上风电竞标，共有 19 个项目（总潜力 24 GW）参与竞标。
• 价格低廉: 竞标平均价格为英格兰和威尔士的每兆瓦时 (MWh) 91.2 英镑，苏格兰为 89.49 英镑。 远低于新建燃气或核电厂的成本。
  • 燃气电厂：约 147 英镑/MWh
  • 核电厂：约 124 英镑/MWh
• 节省成本: 新海上风电项目预计每年可为消费者节省约 17 亿英镑，减少对燃气发电的依赖。
• 浮式风电突破: 此次竞标授予了 192 MW 的浮式风电项目，标志着商业规模浮式风电技术的重要进展，为深水区域风电开发铺平了道路。
• 投资与就业: 预计该项目将吸引约 220 亿英镑的私人投资，并支持英国约 7000 个就业岗位。
• RWE 获益最大: 德国能源巨头 RWE 在本次竞标中获得了近 7 GW 的海上风电项目合同，占据了最大份额。

重要意义:

英国能源部长埃德·米利班德表示，此次竞标标志着英国在能源自主权上的重大进步，有助于实现清洁能源目标，并降低对外国能源的依赖。 此次竞标结果表明，海上风电是英国建设大规模电力的新且最具成本效益的方式。

总结:

此次英国海上风电竞标活动不仅规模空前，价格也低廉，对于英国实现能源安全、降低能源成本和实现气候目标具有重要意义。 浮式风电项目的加入也为未来深水风电的发展奠定了基础。

Svelte 安全漏洞修复公告

Svelte 团队发布了针对 devalue, svelte, @sveltejs/kit, 和 @sveltejs/adapter-node 四个包的补丁，修复了五个漏洞。请立即升级到以下版本：

• devalue: 5.6.2
• svelte: 5.46.4
• @sveltejs/kit: 2.49.5
• @sveltejs/adapter-node: 5.5.1

对于依赖这些包的其它包，更新后的版本已经包含了升级后的依赖项。

Svelte 团队对负责任地披露这些漏洞的安全研究人员、帮助处理披露过程的 Vercel 安全团队以及发布修复程序的维护人员表示感谢。

漏洞详情

以下是对每个漏洞的简要概述，详细报告可在相应的安全公告中查看：

• CVE-2026-22775 (devalue): devalue.parse 函数存在拒绝服务 (DoS) 漏洞，可能导致内存/CPU 耗尽。影响 devalue 版本 5.1.0 到 5.6.1，且需要解析用户控制的输入。SvelteKit 应用使用远程函数时尤其易受攻击。如果未启用远程函数，则 SvelteKit 不受影响。
• CVE-2026-22774 (devalue): 与 CVE-2026-22775 类似，devalue.parse 函数也存在拒绝服务 (DoS) 漏洞，可能导致内存耗尽。影响 devalue 版本 5.3.0 到 5.6.1，且需要解析用户控制的输入。SvelteKit 应用使用远程函数时尤其易受攻击。如果未启用远程函数，则 SvelteKit 不受影响。
• CVE-2026-22803 (@sveltejs/kit): 远程函数二进制形式反序列化器存在内存放大 DoS 漏洞。影响 @sveltejs/kit 版本 2.49.0 到 2.49.4，并且启用了 experimental.remoteFunctions 标志以及使用了 form 功能。恶意请求可能导致应用程序挂起并分配大量的内存。
• CVE-2025-67647 (@sveltejs/kit, @sveltejs/adapter-node): 使用预渲染时存在拒绝服务 (DoS) 和潜在的服务器端请求伪造 (SSRF) 漏洞。影响 @sveltejs/kit 版本 2.44.0 到 2.49.4 和 @sveltejs/adapter-node，且应用程序至少有一个预渲染的路由。如果没有配置 ORIGIN 环境变量，或者没有使用实施主机头验证的反向代理，则可能发生 DoS 和 SSRF 漏洞。在特定情况下，可能通过缓存中毒导致跨站脚本攻击 (XSS)。
• CVE-2025-15265 (svelte): 通过 hydratable 功能存在跨站脚本攻击 (XSS) 漏洞。影响 svelte 版本 5.46.0 到 5.46.3，且使用了 hydratable 功能，并传入未经过清理的用户控制字符串作为键。攻击者如果能够控制 hydratable 中的键，可能导致 XSS 漏洞。

Svelte 团队鼓励用户通过仓库中的安全选项卡（或 Svelte 仓库）私下报告发现的任何安全漏洞。团队正在努力改进开发和审查流程，以在漏洞发布之前捕获潜在的缺陷。

Wiz Research 发现 CodeBreach 漏洞：AWS GitHub 仓库供应链安全风险

Wiz Research 发现了一个名为 CodeBreach 的关键漏洞，该漏洞使 AWS Console 的供应链面临风险。该漏洞允许攻击者完全接管关键的 AWS GitHub 仓库，尤其是 AWS JavaScript SDK，该 SDK 是为 AWS Console 提供支持的核心库。通过利用 CodeBreach，攻击者可以注入恶意代码，从而引发平台范围内的破坏，不仅可能影响依赖于 SDK 的众多应用程序，甚至威胁到 Console 本身，进而威胁到所有 AWS 账户。

该漏洞源于 AWS CodeBuild CI 管道处理构建触发器方式中的一个细微缺陷。仅两个缺失的字符就允许未经身份验证的攻击者渗透到构建环境并泄露特权凭据。Wiz Research 的研究揭示了他们如何利用这种配置错误来完全接管仓库，并提供了 CodeBuild 用户加固自身项目以抵御类似攻击的关键建议。

Wiz Research 负责任地向 AWS 披露了所有发现，AWS 迅速修复了该问题，并实施了全球性的 CodeBuild 服务加固措施，以防止类似攻击。其中，新的 拉取请求评论审批 构建门禁为组织提供了一条简单而安全的路径，以防止不受信任的构建。AWS 安全公告：https://aws.amazon.com/security/security-bulletins/2026-002-AWS/

此问题遵循了 Nx S1ngularity 和最近针对 Amazon Q VS Code 扩展的供应链攻击中常见的模式，这些攻击都源于 CI/CD 配置中的细微错误，导致了不成比例的影响。仅在七月份，一名威胁行为者就利用了类似的 CodeBuild 问题对 Amazon Q VS Code 扩展的用户发动了供应链攻击 (https://aws.amazon.com/security/security-bulletins/AWS-2025-015/)。这种日益增长的趋势突显了组织加固其 CI/CD 管道的紧迫性。

2025 年 1 月 16 日更新： 早期报告错误地将此问题识别为 CodeBuild 服务本身的漏洞。问题实际上源于受影响的 AWS 仓库 CodeBuild 管道中的细微配置错误，而不是服务范围内的缺陷。尽管如此，CodeBuild 用户仍可能在自己的项目中引入相同的配置错误，因此我们强烈建议查看以下“所需操作”部分，以保护自己的 CodeBuild 管道。

所需操作和缓解措施

虽然受影响的 AWS GitHub 仓库的下游用户无需立即采取行动，但我们强烈建议所有 AWS CodeBuild 用户实施以下安全措施，以保护自己的项目免受类似问题的影响：

• 防止不受信任的拉取请求触发特权构建：
  • 启用新的 拉取请求评论审批 构建门禁。
  • 或者，使用 CodeBuild 主机运行器 通过 GitHub 工作流程管理构建触发器。
  • 如果必须依赖 webhook 过滤器，请确保其正则表达式模式已锚定。
• 保护 CodeBuild-GitHub 连接：
  • 为每个 CodeBuild 项目生成 唯一的、细粒度的个人访问令牌 (PAT)。
  • 严格限制 PAT 的权限，仅限于 所需的最少权限，如 https://docs.aws.amazon.com/codebuild/latest/userguide/access-tokens-github.html 所示。
  • 考虑使用专用的、没有特权权限的 GitHub 帐户进行 CodeBuild 集成。

利用 Wiz 查找易受攻击的 CodeBuild 项目

Wiz 客户可以使用 Wiz 威胁情报中心 中的预构建

خلاصه Briar: پیام‌رسان امن و غیرمتمرکز

Briar یک برنامه پیام‌رسان است که برای فعالان، روزنامه‌نگاران و هر کسی که به یک راه امن و پیشرفته برای ارتباط نیاز دارد طراحی شده است. برخلاف برنامه‌های پیام‌رسان معمولی، Briar به سرور متمرکز وابسته نیست و پیام‌ها مستقیماً بین دستگاه‌های کاربران همگام می‌شوند. این ویژگی امکان ارتباط را حتی در صورت عدم دسترسی به اینترنت از طریق بلوتوث یا وای‌فای فراهم می‌کند. در صورت وجود اینترنت، Briar می‌تواند از شبکه تور برای محافظت از کاربران در برابر شنود استفاده کند.

نحوه نصب:

• اندروید: از طریق Google Play Store، F-Droid یا دانلود مستقیم APK از وب‌سایت Briar.
• سایر پلتفرم‌ها: (اطلاعاتی در متن اصلی وجود ندارد)

ایجاد حساب کاربری:

• نام مستعار و گذرواژه (حداقل 8 کاراکتر) انتخاب کنید.
• حساب کاربری به صورت امن روی دستگاه ذخیره می‌شود و بازیابی آن در صورت حذف برنامه یا فراموشی رمز عبور امکان‌پذیر نیست.

افزودن مخاطبان:

• از راه دور: با ارسال یک پیوند briar:// به مخاطب مورد نظر.
• از نزدیک: با اسکن کد QR یکدیگر برای اطمینان از اتصال به شخص صحیح.

ویژگی‌های کلیدی:

• پیام‌رسانی امن: تمام پیام‌ها به صورت سرتاسری رمزگذاری می‌شوند.
• گروه‌های خصوصی: امکان ایجاد گروه‌های خصوصی برای ارتباط با مخاطبان مشخص.
• انجمن‌ها: ایجاد انجمن‌های عمومی برای بحث و تبادل نظر.
• وبلاگ‌ها: هر کاربر دارای یک وبلاگ شخصی است که می‌تواند اخبار و به‌روزرسانی‌ها را با مخاطبان خود به اشتراک بگذارد.
• خوراک RSS: امکان اضافه کردن و مدیریت خوراک‌های RSS برای دنبال کردن اخبار از وب‌سایت‌ها.
• اتصال از طریق تور: استفاده از شبکه تور برای ارتباط امن و ناشناس.
• تنظیمات امنیتی: امکان قفل کردن برنامه با پین، الگو یا گذرواژه و تنظیم زمان عدم فعالیت برای قفل اتوماتیک.

نکات مهم:

• حساب کاربری Briar به صورت محلی ذخیره می‌شود و امکان بازیابی آن وجود ندارد.
• برای اتصال به اینترنت از طریق تور، ممکن است نیاز به استفاده از پل‌ها باشد.
• Briar به طور خودکار اطلاعات مخاطبان را با یکدیگر به اشتراک نمی‌گذارد.
• Briar از نسخه 4 اندروید به بعد پشتیبانی می‌کند.

危机：计算机科学家在文明崩溃时代的角色 (Jīwēi: Jìsuànjī Kēxuéjiā zài Wénmíng Būhé Shídài de Yuánzé)

摘要 (Zhāiyào): 本文是菲利普·罗格威教授在ECS 20课程的最后一堂课的编辑整理版，探讨了计算机科学家在文明和环境崩溃背景下的角色。他认为，我们普遍回避这些问题，但继续“一如既往”的做法似乎是疯狂的。罗格威教授呼吁反思我们作为个人、社会、以及技术学科学生的身份，并质疑我们所做的事情的价值。

主要内容 (Zhǔyào Nèiróng):

• 背景 (Bèijǐng): 罗格威教授指出，我们正处于文明和环境崩溃的边缘，并质疑计算机科学家在加剧或缓解这一威胁中扮演的角色。
• 反思 (Fǎnsī): 他鼓励学生进行深刻的反思，质疑他们遵循社会期望的行为，并思考自己所做的事情是否真正有意义。
• 个人经历 (Gèrén Jīnglì): 罗格威教授分享了他自己对选择的反思，以及他过去三十多年的职业生涯，主要集中在密码学和教学。他承认，尽管最初的动机是追求知识，但他也在寻求成为“重要人物”，这让他感到自负和过时。
• 危机现实 (Jīwēi Xiànshí): 他强调了气候危机、疫情、大规模灭绝、法西斯主义、食物和水资源短缺以及核战争威胁等现实问题，认为这些问题预示着一个黑暗的未来。
• 数据与环境 (Shùjù yǔ Huánjìng): 罗格威教授指出，由于森林退化，加州森林已经变成了净污染源。他还引用了数据显示，人类和家畜现在占陆地鸟类和哺乳动物生物量的95%，表明我们对地球上其他物种的剥削。
• 技术的影响 (Jìshù de Yǐngxiǎng): 他批评了计算机科学在推动监控资本主义、选举操纵、战争和分心经济等负面趋势中的作用。
• 解决方案 (Jiějué Fāng'àn): 罗格威教授提出了几项建议：
  • 停止假装一切正常 (Tíngzhǐ Jiǎzhuāng Yīqiè Zhèngcháng): 承认问题的严重性。
  • 停止吹捧技术解决方案 (Tíngzhǐ Chuībèng Jìshù Jiějué Fāng'àn): 认识到技术本身可能也是问题的一部分。
  • 停止将创新视为目的 (Tíngzhǐ Jiāng Chuàngxīn Shìwéi Mùdì): 认识到创新应服务于更广泛的社会进步。
  • 揭露动机 (Jiēlù dònggù): 了解不同领域工作的真正动机，通常与追逐金钱和权力有关。
  • 抵制虚假宣传 (Dǐzhì Xūjiǎ Xuānchuán): 警惕计算机科学领域的专业术语和表达方式。
  • 结束不感兴趣的学术研究 (Jiéshù Bù Gǎn Xìngqù de Xuéshù Yánjiū): 承认学术研究也可能受到利益的影响。
  • 反抗或退出 (Fǎnkàng huò Tuìchū): 采取行动改变现状，或者选择一种更简单、更可持续的生活方式。
• 结论 (Jiélùn): 罗格威教授表达了对计算机科学能否帮助解决当前危机的怀疑，并呼吁我们认真反思自己的工作和选择，以避免对世界造成更大的损害。他强调了“不成为什么”的重要性，而是专注于成为一个更有价值的人。

关键词 (Guānjiàn Cízì): 文明崩溃 (Wénmíng Būhé), 气候危机 (Qìhòu Jīwēi), 技术 (Jìshù), 计算机科学 (Jìsuànjī Kēxué), 责任 (Zérèn), 反思 (Fǎnsī)

Shellbox 概述 (Shellbox Overview)

Shellbox 是一款基于 SSH 的轻量级云服务器服务，旨在提供便捷、经济的开发和测试环境。以下是 Shellbox 的主要特点和功能：

核心特性:

• 轻量级实例: 每个 Shellbox 提供 2 个 vCPU、4GB RAM 和 50GB SSD 存储空间。
• 纯 SSH 访问: 用户通过 SSH 协议连接，无需特殊的客户端或浏览器插件。
• 持久状态: Shellbox 在断开连接时会暂停，并在下次连接时恢复到之前的状态。
• 基于使用的计费: 运行中的 Shellbox 每小时 0.05 美元，停止状态每小时 0.005 美元。
• 自动成本控制: 当余额低于 5 美元时，Shellbox 将自动停止运行。
• HTTPS 端点: 每个 Shellbox 自动获得一个带有自动 TLS 加密的公共 URL。
• 完整 SSH 支持: 支持端口转发和 SCP 文件传输等 SSH 功能。
• 预付费余额: 用户可以预先充值，并且可以退还未使用的余额。

常用命令:

Shellbox 使用 SSH 协议进行管理，以下是一些常用的命令：

• ssh shellbox.dev create <name>: 创建一个新的 Shellbox，<name> 为 Shellbox 的名称。
• ssh shellbox.dev list: 列出所有 Shellbox 的状态、URL。
• ssh shellbox.dev connect <name>: 连接到指定的 Shellbox，使用 ssh -t 命令。
• ssh shellbox.dev delete <name>: 永久删除指定的 Shellbox。
• ssh shellbox.dev billing: 显示账户余额和使用情况。
• ssh shellbox.dev funds <amount>: 向账户充值 <amount> 美元。
• ssh shellbox.dev refund <amount>: 退还 <amount> 美元的未使用的余额。
• ssh shellbox.dev payments: 显示支付历史记录。
• ssh shellbox.dev help: 显示帮助信息。

文件传输:

Shellbox 支持使用 scp 命令进行文件传输：

• scp -O file.txt shellbox.dev:dev1:/root/: 将本地文件 file.txt 传输到 Shellbox dev1 的 /root/ 目录。
• scp -O shellbox.dev:dev1:/root/file.txt ./: 从 Shellbox dev1 的 /root/ 目录下载 file.txt 到本地当前目录。

计费和充值:

用户可以通过提供的链接 (https://pay.paddle.com/...) 充值，并可以通过扫描二维码或访问链接完成支付。 账户余额信息可以在 ssh shellbox.dev billing 命令中查看。

总结：如何在大型公司中处理“糟糕”项目

本文讲述了作者在职业生涯中对如何在大型公司中处理“糟糕”项目看法转变的经历，总结了如何平衡表达观点和保持有效性。

什么是“糟糕”项目？

“糟糕”项目可能体现在以下几个方面：

• 用户体验 (UX)：产品过于复杂，解决的问题并不存在，打断了现有工作流程。
• 技术：设计过于复杂，使用了错误的技术库，架构性能不佳。
• 政治：追逐炒作趋势，主要目的是为晋升辩护。

项目是否“糟糕”具有主观性，往往需要在权衡利弊后做出最佳选择。随着经验的积累，工程师会逐渐形成对项目的“品味”，能够预见到一些项目最终会失败。

为什么难以阻止“糟糕”项目？

• 行动偏好： 大型公司通常重视速度和快速交付，表达担忧会减缓进度，因此除非问题足够严重，否则你的意见可能被忽略。
• 负面形象： 频繁提出异议容易被贴上“负面”、“制造问题”的标签，而很少获得因避免灾难而应有的认可。
• 人际关系： 提出反对意见可能会影响他人的晋升或损害领导的“心头好”项目，导致人际关系紧张。
• 资源有限： 工程师的时间和精力有限，而公司产生错误想法的能力是无限的，试图阻止所有“糟糕”项目可能导致过度投入并产生厌倦情绪。

如何管理影响力？

作者建议将影响力视为银行账户，定期积累影响力，并在关键时刻进行“取款”。不同规模的问题需要不同程度的影响力消耗：

• 小问题 ($5 取款)：代码审查的细节问题。
• 中等问题 ($500 取款)：挑战架构决策或推迟时间表。
• 重大问题 ($50,000 取款)：试图阻止领导的“心头好”项目。

过度消耗影响力会导致“政治破产”，失去影响力和工作效率。

何时表达观点？

在表达观点之前，需要评估以下三个因素：

1. 项目与自身团队的距离： 距离越近，成本越低。
2. 项目失败对自身团队的影响： 影响越大，回报越高。
3. 项目失败对公司整体的影响： 影响越大，需要采取行动。

如何行动？

• 直接干预： 直接指出问题，并尝试阻止项目（适用于关键时刻）。
• 间接引导： 与团队沟通，引导他们找到更好的解决方案 (适用于技术问题)。
• 保持沉默： 对于影响较小或难以改变的项目，保持沉默，并制定应对措施。
• 管理团队： 诚实地与团队分享信息，避免虚假宣传，并为团队提供支持。

结论

作者总结，在大型公司中，表达观点和保持有效性之间需要找到平衡。 必须战略性地使用影响力，选择合适的战斗，并在必要时接受现实。 最终目标不是阻止所有“糟糕”项目，而是尽可能地保护自身团队和公司，同时保持理性和积极的态度。

好的，以下是对 JuiceFS 内容的总结，中文，不超过 800 字：

JuiceFS 简介

JuiceFS 是一个基于 Apache 2.0 协议开源的高性能 POSIX 文件系统，专为云原生环境设计。它将数据存储在对象存储（如 Amazon S3），并将元数据存储在兼容的数据库引擎（如 Redis、MySQL、TiKV）中。

核心优势：

• 无缝集成： JuiceFS 允许将海量云存储直接连接到大数据、机器学习、人工智能等应用平台，无需修改现有代码，即可像使用本地存储一样高效利用云存储。
• POSIX 兼容： 完美兼容 POSIX 标准，可与现有应用无缝对接。
• Hadoop 兼容： 提供 Hadoop Java SDK，兼容 Hadoop 2.x 和 3.x，以及 Hadoop 生态系统中的各种组件。
• S3 兼容： 提供 S3 网关，提供 S3 兼容的接口。
• Kubernetes 集成： 提供 Kubernetes CSI 驱动，方便在 Kubernetes 环境中使用。
• 高共享性： 支持数千客户端的共享读写。
• 强一致性： 确认的修改会立即在所有挂载点可见。
• 卓越性能： 延迟低至毫秒级别，吞吐量可扩展至理论无限（取决于对象存储大小）。
• 数据加密： 支持数据在传输和静态时的加密。
• 全局文件锁： 支持 BSD 锁 (flock) 和 POSIX 记录锁 (fcntl)。
• 数据压缩： 支持 LZ4 或 Zstandard 压缩数据。

架构

JuiceFS 由三部分组成：

1. JuiceFS 客户端： 协调对象存储和元数据存储引擎，实现 POSIX、Hadoop、Kubernetes、S3 网关等文件系统接口。
2. 数据存储： 存储数据，支持多种存储介质，包括本地磁盘、公有云/私有云对象存储、HDFS 等。
3. 元数据引擎： 存储文件名称、大小、权限、创建/修改时间、目录结构等元数据，支持 Redis、MySQL、SQLite、TiKV 等多种引擎。

数据存储方式：

每个文件会被分割成固定大小的 Chunk（默认 64MiB），Chunk 又由多个 Slice 组成，Slice 再由固定大小的 Block（默认 4MiB）组成。这些 Block 最终存储在对象存储中，元数据则存储在元数据引擎中。

快速入门

使用 JuiceFS 需要：

1. 选择并配置合适的元数据引擎。
2. 选择并配置支持的对象存储。
3. 下载并安装 JuiceFS 客户端。

关键特性

• 完全 POSIX 兼容
• 完全 Hadoop 兼容
• S3 兼容
• Kubernetes CSI 驱动
• 高共享性
• 强一致性
• 卓越性能
• 数据加密
• 全局文件锁
• 数据压缩

文档： 快速入门指南

JuiceFS 致力于为用户提供高性能、高可靠的云原生文件存储解决方案。

[Logic for Programmers] 发布前的一些痛点 (Prolog 相关的)

这篇文章记录了作者在为 Logic for Programmers 新版本添加 Answer Set Programming (ASP) 和 Constraint Logic Programming (CLP) 章节时，对 Prolog 语言的一些抱怨。虽然作者也推荐了一些学习 Prolog 的资源，但本文主要集中于其对 Prolog 语言设计中一些缺陷的批评。

主要痛点：

• 缺乏标准字符串: Prolog 的字符串处理方式不统一，不同实现之间不兼容。SWI-Prolog 中的字符串操作在 Scryer Prolog 中可能无法使用。
• 缺乏函数: Prolog 主要通过规则和谓词进行逻辑表达，缺乏函数支持。虽然这种设计允许双向推理（谓词可以向前或向后运行），但对于简单的操作，例如在列表长度的基础上加一，需要编写多行代码。作者认为 Picat 提供了函数支持，同时保留了双向推理的优点，因此更倾向于使用 Picat。
• 缺乏标准集合类型: 除了原子和数字，Prolog 主要使用列表和复合项（可以看作元组）作为数据类型。缺乏键值映射和结构体类型，使得数据处理不够灵活。
• 缺乏布尔值: true 和 false 不是值，而是控制流语句。无法直接存储布尔值，需要通过事实来间接表示。
• Cut 的使用: Cut (!) 用于阻止回溯，虽然可以优化性能，但也容易导致程序错误。条件语句的实现也依赖于 Cut，这使得条件判断难以预测，容易出错。
• 非 Cut 的使用（+）: Prolog 中的否定 ( \+ ) 的行为难以理解，可能与预期不符，导致难以调试。
• 非默认查询的复杂性: 在进行复杂查询时，例如需要获取所有满足特定条件的节点，需要使用 bagof/3 函数，并且需要注意变量绑定才能获得所有结果。
• 符号项的混合感觉: Prolog 中符号项的处理方式不够直观，例如 a^b 被映射到 ^(a, b)，这使得代码可读性降低。
• 排序问题: sort/2 函数默认返回一个去重后的有序列表，如果需要保留重复项，则需要使用更加复杂的处理方式。
• 缺少尾逗号: Prolog 代码中规则结尾使用点号 (.)，作者希望能够使用尾逗号，以减少代码修改时的语法错误。

作者的总结:

虽然作者承认这些痛点，但他也表示可以通过一些方法解决这些问题，并且在写作过程中也发现了一些解决方案。作者对 ASP 印象深刻，并期待在书中分享相关内容。作者也发现了一些解决问题的技巧，例如通过命令行运行 SWI-Prolog 查询。

总而言之，这篇文章表达了作者对 Prolog 语言设计的一些不满，同时也展示了作者在学习和使用 Prolog 过程中的思考和探索。

事件总结：2026 年 1 月 15 日服务性能下降

事件概要：

2026 年 1 月 15 日 16:40 UTC 至 18:20 UTC 期间，平台观察到 Issues（问题）、Pull Requests（拉取请求）、Notifications（通知）、Actions（动作）、Repositories（仓库）、API 和 Account Login（账户登录）等服务出现延迟和超时问题。

影响范围：

• 受影响服务： API Requests、Issues、Pull Requests、Actions。
• 影响程度： 平均 1.8% 的 Web 和 API 请求失败，峰值短暂达到 10%。
• 用户影响： 大部分影响体现在未认证用户身上，但认证用户也受到影响。

根本原因：

此次事件的根本原因是数据存储基础设施的一次升级。升级到新的主要版本后，出现了意外的资源竞争，导致依赖这些数据集的各个服务出现查询速度变慢和超时等问题。

缓解措施：

为了解决问题，平台已回滚到之前的稳定版本。

事件进展与恢复：

• 16:56 UTC: 开始调查 API Requests、Actions、Issues 和 Pull Requests 的可用性下降报告。
• 16:57 UTC: API Requests 出现可用性下降。
• 17:06 UTC: Actions 出现可用性下降。
• 17:07 UTC: 多个服务出现性能下降，特别是 Issues、Pull Requests 和 API。正在进行调查和缓解工作。
• 17:14 UTC: Actions 恢复正常。
• 17:35 UTC: API Requests 出现性能下降。
• 17:44 UTC: 观察到部分恢复迹象，尤其是认证用户。未认证用户可能继续受到影响。缓解工作仍在进行。
• 17:51 UTC: API Requests 恢复正常。
• 18:36 UTC: 所有服务观察到恢复迹象，但将继续监控。
• 18:42 UTC: Issues 和 Pull Requests 出现性能下降。继续调查。
• 18:54 UTC: Pull Requests 恢复正常。
• 18:54 UTC: 事件已解决。

后续措施：

平台正在努力改进此类升级的验证过程，以便在全面发布前发现高负载条件下可能出现的问题，缩短检测和缓解时间。

游戏生命中由滑翔机碰撞产生的静止结构：23位案例研究

本文介绍了游戏生命中，通过滑翔机碰撞产生的静止结构的研究进展，重点讲述了如何解决23位静止结构合成问题。

背景：

• 游戏生命中，静止结构是指在游戏规则下永不改变的图案。
• 早期研究表明，并非所有静止结构都可以通过滑翔机碰撞产生，一些静止结构需要自宇宙初始就存在。
• 目前已发现一些难以合成的静止结构，如由“400spartans”用户产生的、人口为154的静止结构。
• 寻找小人口静止结构的合成方法比较容易，但超过一定人口后变得困难。

项目进展：

• 该项目旨在找到所有23位（严格意义上，所有岛屿都是必要的）静止结构的合成方法，此前已成功解决了22位静止结构。
• 研究人员最终找到了最后一个难以解决的静止结构，其系统名称为 xs23_g88m9icz1iu146，人口为23。
• 此前，已经成功合成18位、19位、20位、21位静止结构。
• 随着位数的增加，静止结构数量呈指数级增长，且合成难度不断增加。

方法：

• 大规模生成合成配方： 使用计算机搜索生成大量合成配方，筛选出需要人工干预的配方。
• 转移和踩踏 (Transfer and Stomp): 利用已知的合成步骤，通过“转移”技术，将步骤从一个静止结构应用于另一个静止结构。
  • transfer.py 脚本用于提取“组件模板”，模板仅记录滑翔机位置和受影响的静止结构部分。
  • transfer.cpp 和 Stomp 是 transfer.py 的 C++ 替代方案，提供多线程支持和更精确的模板匹配。
  • Stomp 使用了一种更精细的“模板”概念，考虑了未发生变化的细胞的邻域计数，并构建了一个模板树来优化搜索。
• 组件农场 (Component Farming): 通过让滑翔机随机碰撞物体，寻找新的组件。
• Mr. Component: 一种新的方法，用于发现由多个部分组成的组件，这些部分需要精确同步才能成功。

启发式规则：

为了避免搜索空间爆炸，Stomp 采用了以下启发式规则来过滤组件：

• 忽略纯清理步骤。
• 忽略人口小的组件（<7）。
• 忽略静止结构中幸存部分太少的组件（<30%）。
• 忽略涉及多个不连通变化的组件。
• 忽略涉及不必要的“船-位”反应。
• 忽略与最大连通组件不交互的小组件。

结果：

• 利用已知的组件，研究人员已经解决了大部分问题，仅剩下约2000个23位目标需要解决。
• 最终，通过 Stomp 搜索和 Mr. Component 方法，成功解决了所有目标，其中最复杂的配方包含 47 步和 178 个滑翔机。

总结：

该项目展示了通过计算机搜索和协作，解决游戏生命中复杂合成问题的能力。 改进的工具和方法，如 Stomp 和 Mr. Component，极大地提高了寻找合成配方的效率，推动了游戏生命研究的边界。

格陵兰局势：美丹合作受阻，欧洲增兵应对

事件背景：

2026年1月，美国总统特朗普表达了对格陵兰岛的兴趣，意图将其接管，以获取其矿产资源并加强对北极地区的控制，以应对俄罗斯和中国的崛起影响力。这一举动引发了丹麦、格陵兰以及欧洲盟友的担忧和反对。

主要内容：

• 美丹分歧： 丹麦和格陵兰代表与美国政府（副总统JD Vance和国务卿Marco Rubio）在华盛顿举行了会晤，就特朗普的格陵兰岛接管意图产生了“根本性分歧”。丹麦外交部长Lars Løkke Rasmussen公开表示，特朗普仍然表达了“征服”格陵兰的愿望。特朗普则表示，如果不采取行动，俄罗斯和中国将占领格陵兰。
• 欧洲增兵： 为了应对潜在的局势，法国、德国、挪威和瑞典等多个欧洲国家宣布向格陵兰岛增派军队。法国已派遣约15名山地步兵部队前往努克进行军事演习，德国计划在周四派遣13名人员组成的侦察小组。丹麦也宣布增加在格陵兰的军事存在，并由其他北约盟友轮换部署。丹麦国防部长Troels Lund Poulsen表示，此举旨在建立更常态化的军事存在。
• 北约角色： 虽然欧洲军队的部署旨在应对潜在的局势，但欧洲军方官员并未表明其目的是阻止美国采取军事行动。北约方面将所有问题转介给丹麦方面处理，但承认正在考虑如何集体加强在北极地区的北约存在。
• 工作小组： 为了缓解紧张局势，丹麦宣布与美国成立一个工作小组，旨在讨论如何解决双方的差异，同时尊重丹麦王国的红线。丹麦国防部长认为该工作小组是“比没有工作小组要好”，但强调对话并不意味着危险已经消除。
• 格陵兰当地反应： 格陵兰当地居民对三方会晤表示欢迎，但也指出这引发了更多的问题。一些人认为欧洲国家增派兵力是为了抵御可能的美国军事行动，因为他们认为美国对格陵兰的兴趣在于其矿产资源。
• 特朗普态度： 特朗普在椭圆形办公室对媒体表示，他尚未就会晤内容接受简报，但相信“什么都会解决”。丹麦外交部长Rasmussen则明确表示，丹麦不会允许美国接管格陵兰，并认为格陵兰人不会接受美国的统治，因为美国无法负担格陵兰的北欧福利体系。

总结：

美国对格陵兰岛的兴趣引发了与丹麦和欧洲盟友之间的紧张关系。面对美国可能的军事行动，欧洲国家纷纷增兵格陵兰，并与美国成立工作小组，试图通过对话解决分歧。 格陵兰当地居民对局势表示担忧，但对三方会晤的结果持谨慎乐观态度。