苹果在欧盟恢复渐进式网页应用（PWA）功能

苹果公司已改变此前计划，决定在欧盟地区保留主屏幕渐进式网页应用（Home Screen web apps）的原有功能。

事件经过

• 在iOS 17.4首个测试版中，欧盟用户的渐进式网页应用出现工作异常，后续测试版及候选发布版使问题加剧。
• 苹果最初计划移除欧盟地区的此项功能，声称是为了遵守欧盟《数字市场法》（DMA）时，因支持非WebKit浏览器引擎会带来复杂的安全和隐私问题，并需要构建新的集成架构。
• 在收到众多用户希望保留该功能的请求后，苹果决定恢复支持。

苹果的决定与官方解释

• 苹果更新了相关页面说明，表示将沿用iOS 17.3及之前版本中主屏幕网页应用的现有功能。
• 恢复后的PWA功能将依然直接构建于WebKit及其安全架构之上，并与iOS原生应用的安全和隐私模型保持一致。
• 受影响的开发者和用户预计可在2024年3月初iOS 17.4正式发布时重新获得该功能。

欧盟《数字市场法》背景与苹果的配套措施

• 欧盟《数字市场法》的执行截止日期为2024年3月8日，苹果计划在3月5日前后发布iOS 17.4以符合法规。
• 为遵守DMA，苹果此前已公布一系列调整计划，主要包括：
  • 应用分发：允许经过苹果批准、采用人工审核流程的第三方应用商店在欧盟运营。
  • 费用结构：将标准佣金从30%降至17%；对使用苹果支付处理的应用额外收取3%费用；对通过非App Store渠道分发的应用，收取每次首次安装0.50欧元的“核心技术费”（首百万次安装豁免）。
  • 浏览器引擎：强制要求在欧盟支持除WebKit之外的其他浏览器引擎（如Firefox）。
• 在推出上述措施的同时，苹果最初却决定在欧盟禁用PWA功能，外界推测其原因是认为需要为所有非WebKit浏览器提供支持，但实际情况并非如此。

相关方反应与欧盟监管关注

• 苹果的提案引发了广泛批评，Spotify首席执行官称其为“勒索”，Epic Games首席执行官则斥之为“恶意合规”。
• 欧盟委员会在2月下旬表示正在审查包括苹果在内的所有“守门人”的合规方案，并特别关注了PWA问题，已向苹果和应用程序开发者发送了信息请求以进行评估。

Weather.gov 2.0 项目概述

该代码库是Weather.gov网站（美国国家气象局）的2.0版本开发项目，主要目的是提供透明度和提高公众意识。公众可以提交问题、评论和拉取请求，但不保证其代码会被合并。

运行与访问 克隆代码库后，只需运行 just zap 命令即可设置容器环境。容器运行后，可通过以下地址访问：

• 应用程序： http://localhost:8080
• API代理状态： http://localhost:8081

项目文档 项目在 docs/ 目录下提供了丰富的指南，面向产品负责人、开发人员、设计师、研究人员等角色，并包含架构决策记录，解释了技术选型的缘由。

AI政策 项目遵循美国国家海洋和大气管理局AI战略计划及相关行政命令，接受AI辅助编写的代码，但对其质量标准要求更高。核心规定包括：

1. 责任归属：人类贡献者必须理解代码所解决的问题及解决方案，并对提交的代码（包括AI生成）负全责。
2. 透明度：所有包含AI辅助代码的合并请求必须进行披露，注明所用AI模型名称、版本、相关环境等信息，以帮助理解代码来源。
3. 质量检查清单：贡献者需确保已标记所有AI生成的代码改动，亲自运行并解释代码功能，且能向任何人清晰说明代码变更内容、解决的问题及改进之处。

代码结构概览 项目采用模块化结构，主要目录及功能如下：

• api-interop-layer：位于网站与API之间的Node.js应用。
• api-proxy：用于代理API调用和插入静态数据的开发调试工具。
• docs：包含各类文档、架构图、代码审查模板、开发指南、产品路线图等。
• forecast：核心应用，包括：
  • backend：基于Wagtail CMS的后端，负责提供预报页面。
  • frontend：JavaScript及其他客户端资源。
  • locale：用于生成翻译的消息文件。
  • spatial：管理空间数据库的Django子应用。
• justfile：类似现代化的Makefile，用于执行开发者命令。
• scripts：包含各种实用功能的Shell脚本。
• spatial-data：用于生成WFO（天气预报办公室）地图的Node.js实用应用。
• terraform：用于管理基础设施和部署网站的代码。
• tests：包含Playwright端到端测试脚本和（已弃用的）翻译测试脚本。

历史背景 该Git仓库是Weather.gov 2.0项目的第二次迭代。之前的代码库使用Drupal构建，当前仓库是为了迁移到Wagtail/Django框架而创建的。

项目状态 FastUI 项目已不活跃（详见 #368），但仍处于开发中，文档和 Slack 讨论频道可供参考。

核心理念 FastUI 提出了一种通过声明式 Python 代码定义 Web 应用程序用户界面的新方法。其核心是实现后端与前端的真正关注点分离：

• 后端（Python）定义整个应用程序逻辑和界面。
• 前端（React）专注于实现可复用的 UI 组件，无需关心业务逻辑。
• 前端无需编写 JavaScript 或使用 npm，后端开发者即可构建响应式 Web 应用。

技术原理 FastUI 基于 RESTful 架构原则，但更接近 Roy Fielding 原始论文中的定义：前端不主动了解应用，仅根据后端指令组装组件。其优势包括：

• 功能开发只需在后端进行。
• 前后端部署可完全解耦。
• 鼓励重用经过测试的开源 UI 组件。
• 通过 Pydantic 和 TypeScript 确保前后端通信模式的一致性验证。

组成结构 FastUI 包含四个部分：

1. fastui Python 包：提供 Pydantic 模型和工具，可与 FastAPI 等框架集成。
2. @pydantic/fastui npm 包：包含 TypeScript 接口和 React 基础机制。
3. @pydantic/fastui-bootstrap npm 包：基于 Bootstrap 实现的 FastUI 组件。
4. @pydantic/fastui-prebuilt npm 包：提供预构建的 React 应用，可通过 CDN 直接使用，无需安装构建。

示例演示 文中以一个简单的 FastAPI 应用为例，展示如何用 Python 定义用户列表和详情界面：

• 后端通过 /api/ 端点返回由 FastUI 组件（如 Page, Table, Details）构成的列表。
• 组件内部使用 Pydantic 模型数据。
• 前端预构建应用负责渲染这些组件，无需编写前端代码。
• 示例代码展示了定义数据模型、处理点击事件（GoToEvent, BackEvent）和路由。

组件与可扩展性 FastUI 已定义丰富的组件集，所有组件均可在演示应用中查看。其设计理念不限于 Python 和 React，允许：

• 使用其他前端框架（如 Vue）或技术（如边缘计算生成 HTML）。
• 为移动端或物联网等平台开发前端。
• 使用其他后端语言（如 Rust、Go）实现组件模型。

总结 FastUI 旨在让后端开发者通过 Python 代码快速构建 UI，实现前后端职责分离和高效开发，尽管项目当前不活跃，但其架构原则和实现方案具有参考价值。

Ente：开源端到端加密的谷歌相册替代品

核心概述

Ente 是一款开源、端到端加密的云相册应用，旨在作为谷歌相册（Google Photos）的隐私友好型替代方案。它结合了高级加密技术、跨平台支持与用户友好的设计，致力于提供安全且功能完整的照片备份与管理服务。

主要特点与用户反馈

🔒 隐私与安全

• 端到端加密（E2EE）：所有照片、视频及元数据均加密，确保只有用户可访问。
• 零知识加密：服务提供方无法查看用户内容，优于谷歌等商业服务。
• 开源透明：代码公开可审计，增强信任度。

🌐 跨平台与功能

• 多平台同步：支持 iOS、Android、Web 等系统，跨设备无缝访问。
• 原始质量保留：保持照片/视频的原始分辨率、HEIC 格式及 EXIF 元数据。
• 实用功能：包括快速缩略图加载、地图视图、家庭共享相册、自动备份及释放本地存储空间。

👨‍💻 用户体验与支持

• 界面美观易用：设计简洁直观，操作流畅。
• 活跃开发团队：快速响应 bug 修复与功能请求，客服反馈积极高效。
• 家庭计划：支持共享存储，无额外费用。

💰 价格与性价比

• 低价订阅：例如 10GB 存储仅需 10 欧元/年或 1 欧元/月。
• 价值突出：用户认为其价格合理，相比免费但牺牲隐私的服务更值得选择。

待改进之处

• 部分用户提到缺少视频压缩预览等高级功能。
• 偶有性能优化需求（如初期加载速度），但后续更新已大幅改善。

用户总结

多数用户称赞 Ente 是最优秀的谷歌相册替代品，完美平衡了隐私、功能与成本。其开源特性和加密技术尤其受到隐私重视者的青睐，尽管仍有少量功能缺口，但开发团队的积极态度让用户对其未来发展充满信心。

使用 Bash 从零编写 Minecraft 服务器的技术要点总结

核心挑战与解决方案

• 二进制数据处理：Bash 原生不支持空字节处理，通过将数据保留在管道中而非存入变量，结合 dd 与 xxd 实现二进制数据读写，解决了协议解析的核心障碍。
• 协议支持：实现了 Minecraft 的 Java 版协议，使用 ncat 监听 TCP 端口，并通过 Bash 脚本处理连接。

关键数据类型实现

• VarInt/VarLong：自定义了编码与解码函数，利用模运算与位移操作，替代了参考实现。
• IEEE 754 浮点数：通过调用 awk 计算幂函数来实现浮点运算，并优化性能（将循环移入 awk 减少外部调用）。
• Position 数据类型：利用 Bash 位操作将 64 位长整数分解为三个坐标（X:26位，Z:26位，Y:12位）。
• NBT 格式：简化实现，未完成全部解析器，依赖从原版服务器获取的二进制数据块。

服务器核心功能实现

• 连接流程：实现了握手、Join Game 等数据包。
• 区块与光照数据：
  • 使用简化的 Chunk Section 结构（单个 16x16x16 区块）。
  • 通过调色板机制映射方块 ID，采用 8 位块定义长度（支持 256 种方块）。
  • 生物群系统采用简化映射（所有区域设为平原）。
• 插件系统：通过覆盖钩子函数（如 hook_chunks）扩展功能，示例包括随机方块生成和挖矿小游戏。

项目限制与特性

• 性能：Bash 脚本处理速度较慢（如浮点转换约 10ms），多线程通过共享内存（/dev/shm）通信。
• 依赖：需要最新版 BusyBox，未测试 GNU 核心工具链。
• 兼容性：仅支持单人模式或有限的多人互动，协议实现聚焦基本游戏功能。

目标与意义

• 实验性质：作为编程思维练习，探索 Bash 处理复杂二进制协议的能力。
• 开源代码：项目名为“Witchcraft”，代码托管于 GitHub，遵循 Minecraft 协议文档开发。

技术亮点

• 创造性地使用命令行工具（dd, xxd, awk）处理二进制流。
• 通过优化外部调用显著提升性能（浮点运算速度提升约 35 倍）。
• 实现了一个可扩展的服务器框架，尽管存在性能与功能限制，但完整演示了 Bash 在实时游戏服务器中的可行性。

Bash 调试技巧总结

调试命令

• set -x：在脚本顶部添加 set -x，或运行时使用 bash -x script.sh，可以打印每一行执行的命令，变量已展开。
• bash -X：与在脚本顶部使用 set -x 效果相同。

逐行确认

• trap read DEBUG：在脚本中使用此命令，会在每一行代码执行前停止，等待用户输入（如按回车）继续。
• 高级逐步调试技巧：在脚本开始处添加 trap '(read -p "\[$BASH_SOURCE: $LINENO] $BASH_COMMAND")' DEBUG，会在每行前显示脚本文件名（$BASH_SOURCE）、行号（$LINENO）和即将运行的命令（$BASH_COMMAND），并等待用户确认。

错误消息处理

• 使用函数 die() { echo $1 >&2; exit 1; }，可在命令失败时调用，例如 some_command || die "oh no!"，以便退出程序并打印错误消息到标准错误。

加州批准Waymo扩展至洛杉矶和旧金山半岛

核心批准

加州公用事业委员会（CPUC）消费者保护与执法部（CPED）于2024年3月1日正式批准了Waymo的建议信0002。此项批准授权Waymo将其无人驾驶自动驾驶车辆部署服务扩展至洛杉矶地区和旧金山半岛的新增区域。批准即日生效。

背景与过程

• 法律依据：此次批准基于CPUC之前的决定（D.20-11-046，经D.21-05-017修订）和决议TL-19136。该框架规定了持有客运许可的运输公司使用自动驾驶车辆收费服务的要求。
• DMV的角色：加州机动车管理局（DMV）负责评估自动驾驶车辆是否能在公共道路上安全运行，并于2024年1月11日批准了Waymo扩大其运行设计域（ODD）。
• Waymo的请求：2024年1月19日，Waymo提交了Tier 2型建议信0002，旨在获得批准其更新后的乘客安全计划，以便在新批准的ODD区域内扩展收费服务。Tier 2建议信适用于对已批准PSP进行实质性修改的情况。

公众意见

• 支持意见：CPED收到了81份支持回应，来自众多组织和个人，包括残障倡导团体、社区组织、经济发展机构、民选官员、劳工代表和交通倡导者。他们普遍强调了扩展服务在安全、无障碍、经济和环境方面的潜在益处。
• 反对意见：共收到5份抗议，来自南旧金山市、圣马特奥县、洛杉矶交通部、旧金山县交通局和旧金山出租车工人联盟。主要关切点包括：
  • 程序性质疑：认为Tier 2建议信程序未提供充分的通知和公众参与机会，并要求举行正式听证会。
  • 政策担忧：要求赋予地方政府更多监管权、标准化数据共享和脱离协议，并指出相关立法（参议院法案915）尚待解决。
  • 内容质疑：声称Waymo的乘客安全计划存在疏漏，未充分考虑到对急救人员和公众的影响，并质疑扩展决定的合理性。
• Waymo的回应：Waymo于2024年2月13日回复，辩称其完全遵循了部署决定的要求，反对意见未提出有效的程序异议依据，且许多议题属于政策层面，不适合通过此建议信程序解决。Waymo还提供了其与当地政府官员接触和培训的详细情况。

CPED的决定与理由

CPED审查后认为，所有抗议均未提出符合《一般命令96-B》规则7.4.2的有效程序异议理由。

1. 关于程序：部署决定已明确，当运营商需实质性修改其PSP时，提交Tier 2建议信是适当的机制。反对者要求举行正式听证会，但未能指明需要解决的具体事实争议，故该请求被驳回。
2. 关于政策议题：抗议中提出的许多政策性问题（如地方监管权、数据共享、环境审查等）属于对CPUC既有决定的重新辩论，超出了本次建议信评估的范围。这些问题应通过CPUC的正式规则制定程序（如R.12-12-011）来处理。
3. 关于乘客安全计划（PSP）：CPED认为，Waymo提交的更新版PSP完整且合理，符合部署决定的所有要求。该计划详细说明了Waymo为最小化乘客风险而采取的政策和程序，包括：
   • 乘客与公众教育。
   • 车内安全与无障碍功能。
   • 车辆识别与上下车协议。
   • 应对车辆内外不良事件的协议。
   • 乘客沟通与支持协议。
   • 新增安全功能：例如增强的外部照明、新的外部音频提示以方便与车外人员（包括急救人员）沟通，以及与特定公共安全机构合作以快速接收活动避免区域的通知。

最终结论

基于上述评估，CPED批准了Waymo更新的乘客安全计划，并授权其在请求的洛杉矶和旧金山半岛特定区域扩展无人驾驶收费客运服务。

文章摘要：45年工程师Malcolm澄清电热桑拿通风原理

本文基于45年经验的工程师Malcolm对电热桑拿通风的研究，总结了1992年芬兰电热桑拿通风研究的关键内容。Malcolm每天使用电热桑拿，并通过温度监测和分析，将34页的原始研究压缩为9页，专注于澄清空气流动、温度和湿度分布的科学原理。电热桑拿的通风动态与传统木柴桑拿不同，需要专门设计以避免问题如二氧化碳积聚和温度不均。

研究背景与目的 Malcolm指出，大多数北美电热桑拿用户不了解1992年芬兰研究，制造商通常关注其他问题（如UL温度标准），而非通风需求。该研究旨在通过实验确定电热桑拿的最佳通风配置，以实现三个目标：避免肺部二氧化碳过饱和、创建舒适的温度分布和均匀的蒸汽湿度。

研究方法与设置 研究在测试桑拿中进行，体积为8立方米，使用8千瓦电热炉（带25公斤石材）。通风系统包括四个进气口（T1-T4）和三个风扇辅助排气口（P1-P3），进气流量恒定为48公斤/小时（24立方英尺/分钟），进气温度约20°C。关键变量包括空气混合（气流模式）、温度分布（15个热电偶测量）和空气条件（湿度，使用湿度计测量）。

关键发现

1. 空气混合（气流模式）：

   • T1（地板附近）和T2（炉后）进气：冷空气沉降至地板，可能导致短路气流，降低空气交换效率。
   • T3（炉上方）进气：气流取决于流速，可能混合或沉降。
   • T4（炉与天花板中间）进气：冷空气立即与炉子上升热空气混合，均匀分布至天花板，促进最佳空气混合。
   • 排气口位置（P1-P3）不影响进气模式，但最佳组合为T4进气和P2（座椅下方）排气，这能有效混合上下层空气，减少二氧化碳积聚。

2. 温度分布：

   • 垂直温度差异典型：头部约90°C，座椅面80-85°C，脚板60-65°C，温差25-30°C。
   • 使用T4进气和P2排气时，温度分布最均匀；脚板温度最高（尤其当地板保温时）。
   • 地板保温（如泡沫板）可提高脚板温度，尤其对T3和T4进气有效。

3. 空气条件（湿度分布）：

   • T1/P1组合导致短路气流，蒸汽分布差，湿度不均。
   • T4/P2组合提供最佳湿度分布，蒸汽均匀扩展到桑拿下部。
   • 高排气流量（如196公斤/小时）无法解决湿度分布问题，反而可能破坏气流模式。

最佳通风配置

• 推荐组合：进气口在炉子上方（T4），排气口在座椅下方（P2）。这种配置：
  • 促进冷空气与热空气有效混合，维持低二氧化碳水平（符合芬兰法规要求的每小时6-8次空气更换）。
  • 提供最均匀的温度分布，最小化头部与脚部温差。
  • 实现最佳蒸汽混合，提升桑拿体验。
• 其他排气口位置（P1或P3）效果较差，尤其当进气口在低处时。

实践建议

• 确保密封性：桑拿应尽可能密封，以避免气流短路和干扰通风模式。
• 机械排气必要：研究确认电热桑拿需要风扇辅助排气。
• 额外进气口：Malcolm建议使用可控的四个通风口系统（A、B、C、D），其中B（T4）和D（P2）关键，以实现全面控制。

总结 Malcolm的总结强调了电热桑拿通风的科学基础，纠正了原始翻译中的错误，并提供了实证数据支持T4/P2组合的优势。研究帮助用户理解通风动态，优化桑拿健康和安全。

• 核心原则：

  1. 尽早且频繁地测量：性能优化的基础是量化问题。使用分析工具来定位瓶颈，并验证优化是否有效。测量应贯穿整个开发过程。
  2. 减少工作量：通过更高效的算法、重构代码以消除不必要的操作、将重复计算移出循环等方式，用更少的指令完成相同的任务，这通常能带来最大的性能提升。
  3. 理解系统瓶颈：确定应用程序是受CPU、GPU计算还是内存限制。优化错误的方向（如优化CPU，但瓶颈在内存）可能徒劳无功。
  4. 重新定义问题：有时可以解决一个更简单但效果等效的问题来获得巨大性能提升，例如在图形编程中用近似计算代替精确计算。

• 关键洞察：

  • 优化目标多样化：“性能”不仅指速度（延迟、吞吐量），还包括内存使用、能耗、安全性、稳健性等。优化往往需要在这些目标间权衡。
  • 关注系统整体：即使某个部分运行缓慢，如果它很少被调用或不影响整体资源（如磁盘空间、电池），也可能不是优先优化目标。应确保关键路径高效。
  • 算法与缓存：较低算法复杂度的方案不一定总更快。一个更高效的算法如果频繁导致缓存未命中，其表现可能不如一个看似低效但内存访问模式友好的算法。
  • 避免过早优化：正确理解Donald Knuth的完整名言——不要浪费时间优化非关键部分的细微效率，但应抓住关键3%的优化机会。不要以此作为编写低效代码的借口。

• 不同领域的差异：

  • 游戏开发：通常有严格的每帧时间预算（如16.7ms@60fps），优化目标是确保每帧内完成所有逻辑和渲染，而非单纯减少总运行时间。
  • 实时音频处理：时间预算极小（如1.3ms），错过截止期限会导致音频瑕疵。
  • 数据处理：可能面临每日处理窗口耗尽的“资源有限”问题，优化焦点在于提高吞吐量或重新设计流程。
  • 前端/Web性能：关注渲染效率、资源加载和用户体验，可参考Core Web Vitals等指标。

• 推荐学习资源与实践方法：

  • 书籍与课程：《Algorithms for Modern Hardware》、《Computer Systems: A Programmer's Perspective (CS:APP)》、《Writing Efficient Programs》、以及在线课程如“Performance Engineering of Software Systems”。
  • 博客与文章：Brendan Gregg的博客（系统性能）、Daniel Lemire的博客（SIMD与算法）、Agner Fog的优化手册（CPU底层）。
  • 工具：学习使用性能分析器（profiler）和跟踪工具，如Linux perf、Intel VTune、AMD μProf、NVIDIA Nsight等，具体工具取决于技术栈。
  • 实践建议：在资源受限的环境（如嵌入式系统）中编程，或通过挑战（如“十亿行挑战”）来积累经验。寻找导师并参与实际项目是提升技能的有效途径。
  • 思维方式：采用数据导向的设计思想，关注内存局部性和缓存利用。从第一性原理出发，理解硬件（CPU缓存层级、内存带宽）的基本限制。

本书《R: Introduction to Data Science (2019)》是哈佛数据科学系列课程中“数据整理与可视化”部分的配套教材。其姊妹篇《统计与预测算法》的网站另行提供。该书起源于作者在哈佛X系列课程中使用的课堂笔记。

书籍的图形主题可通过dslabs包中的ds_theme_set()函数复现。生成本书的Quarto源文件已在GitHub上开源。该作品采用知识共享署名-非商业性使用-共享同际4.0许可证授权，同时提供纸质书购买渠道以及免费的PDF版本（2019年10月24日版）。

作者在致谢中感谢了众多为本书做出贡献的人士，这包括：

• R及其相关包（如tidyverse、data.table、caret）的开发者和维护者。
• 提供了重要编辑、建议和帮助的个人，如Jenna Landy、David Robinson、Amy Gill等。
• 来自哈佛X课程协调员、助教以及历届学生们的贡献，他们的提问和建议帮助完善了书稿。
• 通过GitHub提交建议或修改的数十位社区贡献者。
• 提供部分课程资金支持的美国国立卫生研究院（NIH）。

WhatsApp获得美国地方法院支持，将能够全面审查以色列NSO集团的Pegasus间谍软件源代码。此前，WhatsApp指控Pegasus被用于在两周内非法监控约1400名WhatsApp用户，获取包括加密消息在内的敏感数据。WhatsApp于2019年对NSO提起诉讼，目标是规制全球范围内向政府出售先进恶意软件的未受监管产业。

NSO曾以美、以两国限制为由，试图阻止诉讼中的证据披露，但法庭否决了其全面禁止发现请求。近期，法院再次否决NSO只须披露Pegasus安装层信息的要求，并支持WhatsApp要求了解相关间谍软件“全部功能”，强调仅安装层信息无法揭示Pegasus访问与提取数据的具体操作。

WhatsApp认为Pegasus可拦截包括iMessage、Skype、Telegram、微信、Facebook Messenger、WhatsApp等多款应用的通讯，还可按不同需求定制，实现信息截获、截图、浏览记录导出等功能。为证实这些指控，WhatsApp获准获取针对其服务器或利用WhatsApp访问目标设备的所有相关间谍软件代码，涵盖疑似攻击前后一年内的所有版本。

该文章详细记录了作者作为ISP（互联网服务提供商）在自家居住建筑内部署光纤网络的完整过程，旨在提供一个实用、模块化且面向未来的室内布线方案。

背景与目标 作者认为光纤是几乎无需再更换的物理连接基础。但光缆仅到达建筑物入口并不足够，需要在建筑内部进行布线，以便连接公寓、机房等各处。作者决定以DIY精神升级现有布线，并记录过程。

建筑结构与设计思路 建筑有4层，存在预设的垂直管道便于布线。设计上，作者追求“规模经济”和“模块化”：安装超出当前需求但不过分超前的配置，以平衡实施成本、时间与未来扩展性。最终规划了11条光缆路由。

关键选材与决策

1. 光纤类型：选择单模光纤（OS2），因其兼容性、成本效益及近乎无限的带宽潜力，优于多模光纤。
2. 光纤标准：选择G.657.A2（抗弯曲光纤）。相较于G.652.D，其具有更小的弯曲半径（7.5mm），能轻松处理室内直角转弯，虽价格稍高但实用性极强。作者还3D打印了检查工具来确保安装合规。
3. 纤芯数量：选择12芯光缆。在直径增加不大的情况下提供最大扩展空间。
4. 线缆保护：选用了符合本地防火安全法规的护套材料，适用于垂直与水平安装。
5. 连接器：选用小型、通用的LC连接器，并选择UPC（蓝色，端面平）版本。因其在设备端更通用，通过转接线即可兼容APC（绿色，端面斜，用于PON）需求。

模块化安装系统 作者采用了类似数据中心“会客室”的模块化架构：

• 在每条光缆两端安装终端盒（内含配线架）。
• 12芯光缆的每根纤芯在终端盒内通过熔接方式连接到带有LC连接器的尾纤上。
• 最终在配线架上形成LC母口。需要建立特定连接时，无需铺设新线，只需在相应终端盒的端口间插接短跳线即可，极大简化了临时或新增电路的调配。

熔接过程 作者使用光纤熔接机进行了约300次熔接。过程包括：剥纤、清洁、高精度切割、对准、电弧熔接和热缩保护。虽过程繁琐，但能确保低损耗、高性能的永久连接。

测试与验证

1. 直观检查：用激光笔照射，检查光通性。
2. OTDR测试：使用光时域反射仪对每根纤芯进行精密测试，检测反射事件（熔接点、连接器、断裂等）和链路损耗，发现并修复了两个故障点。
3. 实际连接测试：使用1G和25G BiDi（单纤双向）光模块进行以太网链路测试，验证连接稳定性。

成果与性能 项目完成后，建筑内部拥有12条冗余光纤连接。作者已将大部分设备迁移至新光纤网络，运行稳定。文章最后探讨了理论传输速度：

• 使用当前商用的BiDi技术，可达到3.6 Tbps。
• 使用双工（Duplex）800GbE技术，可达14.4 Tbps。
• 若结合DWDM（密集波分复用）技术，理论极限可达数百Tbps甚至Pbps级别（引用了前沿研究），但实际中受设备成本限制，目前使用10GbE。

链路预算考量 文章分析了影响链路信号功率的因素：光纤长度损耗（极低）、熔接损耗（平均约0.01 dB）、连接器损耗（约0.3 dB/个）。对于室内短距连接，总损耗远低于典型光模块的链路预算，因此完全可行。但提醒若未来接入使用高分光比（如1：32）的PON网络，需关注整体链路预算是否充足。

总结 该项目成功实施了一个高性能、高灵活性、可扩展的室内光纤物理层基础设施。虽然初始部署（特别是熔接）需要专业知识和投入，但换来了未来几乎无限的扩展能力、极简的运维和卓越的网络性能。作者计划未来继续扩展该网络。

Konilo: 基于 Forth 的个人计算系统

概述
Konilo 是一个用 Forth 编写的小型、实用的个人计算系统，运行在一个微型虚拟计算机上。完整系统包括一个 ilo 虚拟机、一个包含 Konilo 系统的镜像文件（"rom"）以及一组用于存储代码和数据的块。

特性

• 双栈架构
• 64k 单元的字寻址（32 位）内存
• 30 条指令，每条指令四个字
• 基于块的数据存储
• 直接线程化的 Forth
• 包含块编辑器、工具和文档
• 最低物理系统要求低（已在 384k RAM 和 16 位宿主 CPU 的系统上测试）

下载内容
提供 Konilo 2025.5 版本（tar.gz、zip、发行说明）、夜间快照（tar.gz、zip）以及 konilo.sh 脚本（附说明）。可单独下载 ilo 虚拟机（多种编程语言实现）、ilo.rom、ilo.blocks、预构建的可执行文件及规范文档。

编程语言实现
ilo 虚拟机支持多种语言实现，包括：Ada、C、C#、C++、Common Lisp、D、Go、Hare、Haskell、Java、JavaScript (Node)、Kotlin、Lua、Nim、Pascal、Python、Retro、Rust、Scheme、Swift、TypeScript 等（更多实现包含在完整源代码中）。

文档与仓库
提供超文本文档手册、术语表和相关文章。代码仓库可通过 Fossil 或 Git 克隆获取。

开源与支持
Konilo 和 ilo 为开源项目。开发由 Patreon 平台上的支持者资助，文章末尾列出了致谢名单。

OpenIPC：IP摄像头的开源替代固件

项目概述

OpenIPC是一个针对IP摄像头的开源操作系统，由开放社区开发，旨在替代设备预装的闭源、不透明、不安全且常被弃用的厂商固件。它支持多种制造商的ARM和MIPS处理器摄像头。

核心特性

• 开源与许可：源代码以MIT许可证发布，允许用户为任何目的（包括作为专有软件的一部分）复用代码。仅要求用户将改进贡献回项目，并在商业使用时联系开发团队。明确禁止军事用途。
• 分发形式：
  • 提供预编译的二进制文件，便于终端用户安装。
  • 在GitHub上完全公开源代码，供开发者参与改进。
• 技术架构：
  • 使用Buildroot构建Linux发行版。
  • 集成多种流媒体服务器：Majestic（以二进制形式提供，遵循Prosperity Public License 3.0.0）、Divinus、Mini或Venc。

使用优势

• 用户自由与安全：赋予用户对视频流和设备的完全控制权，系统无后门、僵尸网络、挖矿恶意软件、键盘记录器或密码嗅探器等闭源固件常见风险。
• 功能基础与扩展：
  • 优先保证广泛的摄像头兼容性，支持基础的视频/音频流传输。
  • 支持多种高级功能：IPEYE云存储、YouTube/Telegram直播、SOCKS5代理、虚拟隧道设置等。
• 专业化应用：已有针对特定场景的项目，如无人机、施工头盔、测绘工具、医学视觉研究、水下捕鱼等专用摄像头。

项目资源

• 安装说明、预编译文件及源代码均可在项目页面获取。

将链接缩短器意外变成恶意软件蜜罐的经历

创建初衷与问题初现

作者创建了链接缩短器 y.gy，初衷是为个人项目提供服务，并提供免费无限使用的策略。然而，在服务上线的第一天，就有大量恶意链接（如钓鱼网站）被提交。这让他意识到，网络犯罪分子最积极寻找新的免费链接缩短服务，因为他们不断被其他平台封禁，需要新工具来隐藏其恶意流量。

应对恶意链接的措施

作者首先手动检查提交的链接，但很快发现需要更系统的方法。他采取了以下措施：

1. 域名级黑白名单：针对反复出现恶意链接的域名（如特定购物网站域名）进行封禁。同时，将其他链接缩短服务的URL也加入黑名单，以防止犯罪分子通过多层跳转规避检测。
2. 识别用户生成内容的子域名滥用：例如在 Replit、Wix 等平台上创建的恶意子域名。作者需及时封禁这些子域名，但他注意到不同平台的安全措施存在差异。
3. 应对更隐蔽的攻击：一些恶意链接采用地理围栏技术，仅在特定地区显示为钓鱼页面。作者通过重定向恶意链接至“诈骗警告”页面，并设法检测此类地理围栏内容，有效降低了滥用率。

转向付费模式以根本解决问题

尽管采取了上述措施，作者意识到免费API仍是根本漏洞，高级犯罪分子可能通过预付卡或盗刷信用卡继续滥用。他认为最有效的屏障是要求预先付款，因为支付处理商（如Stripe）的欺诈防护系统能有效过滤高风险用户。

因此，作者将API改为付费服务（每月4美元起），这大幅减少了流量，使其能使用商业级链接扫描服务进行持续监控。此举同时保留了免费的二维码生成器，因其直接指向目标URL，不经过y.gy服务器，不存在链接伪装风险。

总结与经验教训

作者得出以下关键结论：

• 免费模式可能吸引滥用：对于易被滥用的服务（如链接缩短、电子邮件），免费使用会在初期吸引大量恶意用户，给创始人带来巨大运营负担。
• 软件用途不可预测：作者原本预期服务主要用于营销链接跟踪，但实际上用户用途多样，包括缩短YouTube链接、创建SEO反向链接等。这表明软件的实际使用方式往往超出开发者的设想。
• 防范需前置：对于新发布的服务，应提前准备反滥用措施，尤其是对于易于被犯罪分子利用的领域。这次经历也让他对即将推出的电子邮件服务有了更充分的准备。

K8s 服务网格现状：免费时代终结，账单已至

文章指出，在Kubernetes中部署服务网格（Service Mesh）已成为一项日益重要的运营要求，它能提供服务间加密、访问控制、可观测性和弹性功能。然而，该领域正从免费使用转向商业化付费模式，企业需在预算和迁移决策中计入此项成本。

主要服务网格方案现状与变化

1. Linkerd

• 变化：自2.15.0版本起，停止发布“稳定版”，该功能被整合进其商业产品 Buoyant Enterprise for Linkerd。社区版仅提供功能可能变化的“边缘版”。
• 定价：采用按集群收费模式，每月2000美元/集群。作者认为此定价模式与当前集群数量增多、规模变小的趋势相悖，且对用户自托管的场景而言定价偏高。
• 建议：用户可选择使用“边缘版”，但需接受其不稳定的风险并加强内部测试。

2. Cilium

• 技术优势：采用eBPF技术，无需边车容器，性能优异。它集成了CNI、负载均衡、安全与可观测性等功能，能替代云厂商特定组件，提供跨云一致性体验。
• 重大事件：2023年12月被思科（Cisco）收购。
• 未来成本预警：作者预测，基于思科的商业风格，Cilium未来必然收费，且很可能定价高昂，成为一项高端多云产品。从Linkerd迁移到Cilium以节省成本可能只是短期选择。

3. Istio

• 现状：功能强大但极其复杂，以“问题之源”闻名。虽然免费开源，但其运维复杂性和故障风险带来很高的隐性成本。
• 作者观点：认为其复杂性带来的开销常常超过服务网格本身带来的价值，尤其当Linkerd在流量管理等功能上已迎头赶上时。

4. Consul Connect (HashiCorp)

• 定位：复杂度与功能介于Linkerd和Istio之间，面向大型企业，尤其在跨数据中心和可观测性方面表现出色。
• 定价与限制：采用按小时、按实例收费的模式（起步价约0.027美元/小时/实例），实际费用更高。仅支持AWS和Azure，且基础套餐不含支持服务。

5. 云厂商托管服务

• GCP：提供基于Istio的 Anthos（GKE Enterprise的一部分），按集群收费，简化了Istio的运维。
• AWS：App Mesh 免费，且能桥接ECS、EC2等服务，适合非纯K8s架构或混合环境。
• Azure：主推的托管Istio预览版。原有产品Open Service Mesh已弃用。

核心趋势与建议

• 免费时代结束：除了AWS App Mesh等特定情况，主流独立服务网格均已进入或即将进入收费阶段。
• 权衡决策：基础设施团队需谨慎选择，核心是在云平台锁定（使用云厂商服务）与灵活性/成本（使用独立网格）之间取得平衡。
• 无明确赢家：当前没有一种方案能完全满足所有需求，决策变得复杂。
• 行动建议：对于已深度使用Linkerd或Cilium的团队，应立即开始讨论未来策略：是准备支付费用、转向使用不稳定的社区版并加强测试，还是为未来可能更高的成本做好准备。

修正牛顿动力学理论能否否决行星九假说？

行星九假说的背景与依据

• 观测基础：天文学家通过柯伊伯带天体（KBOs）轨道的异常聚集现象，推测海王星外存在一颗隐藏的“行星九”。
• 行星九特征：推测其质量约为地球的10倍，轨道高度椭圆，距离太阳最远可达地日距离的30倍。
• 发现逻辑：类似1846年通过天王星轨道异常发现海王星的先例，但至今未被直接观测到，全球多个团队仍在搜寻。

修正牛顿动力学（MOND）的替代解释

• 理论核心：MOND在星系尺度上修正牛顿和爱因斯坦的引力理论，认为引力在极低加速度下偏离经典规律，可替代暗物质解释星系动力学。
• 关键研究：哈什·马图尔和凯瑟琳·布朗的研究表明，MOND无需调整参数即可解释KBOs轨道的聚集现象。
• 引力来源：在MOND框架下，KBOs轨道异常可能由银河系中心密集的数千万颗恒星引力导致，而非行星九。
• 轨道对应：MOND预测最远KBOs的椭圆轨道应与银河系中心对齐，这与观测数据一致，也与行星九假说的预测方向吻合。

两种理论的竞争现状

• 支持度对比：
  • 行星九假说：符合传统引力理论，但尚未发现直接证据。
  • MOND理论：挑战暗物质范式，能解释部分星系动力学，但难以说明引力透镜等现象，且需进一步验证。
• 研究者立场：作者保持中立，强调分析结果仅显示MOND与行星九假说在解释KBOs异常上具有同等效力，并未断言MOND正确。

未来验证方向

• 观测周期：未来5-10年发现更多KBOs后，可检验其轨道是否持续与银河系中心对齐。
• 理论发展：若MOND能持续解释新数据，可能动摇行星九假说；反之则强化行星九存在的可能性。
• 争议焦点：MOND需进一步证明其在星系团尺度等复杂环境中的解释力，而行星九假说需通过直接观测或间接约束获得突破。

结论

行星九假说与MOND理论目前处于竞争状态，两者均能解释现有柯伊伯带天体轨道异常，但机制截然不同。科学界需通过更多观测数据和对两种理论的深化研究，最终确定太阳系外围引力异常的根源。

文章标题：Remaking Super Mario World in Godot

这篇文章主要围绕一个YouTube视频展开，标题为“Can I Remake Super Mario World in Godot? (Part 1)”，内容是一位游戏开发爱好者分享其项目。作者拥有ROM黑客背景，希望通过使用Godot引擎重制经典游戏《超级马里奥世界》来学习和进入游戏开发领域。该项目被定位为一个热身练习，旨在探索如何在现代游戏引擎中实现对原作的忠实再现，而非简单复制资产或物理特性。

视频上传于2024年2月25日，通过结构化数据展示了元信息，包括缩略图和上传日期。其中包含一条用户评论，赞扬了作者的做法，认为其注重贴近原作的细节，与其他常见的粗糙复刻视频形成鲜明对比，获得了较多好评。

整体内容聚焦于项目的动机、方法和初步反馈，强调了作者从ROM黑客转向游戏开发的学习过程，以及社区对忠实再现经典游戏的积极认可。

北美最后的摩尔斯电码电台

历史背景与现状

摩尔斯电码曾是海事通信的通用语言，于1999年2月正式停止作为海事通信标准。然而，在旧金山以北的Point Reyes国家海岸，KPH海事电台仍是北美最后一个运营中的摩尔斯电码电台。该电台由两栋相距约25英里的建筑组成，曾负责监控太平洋和印度洋水域。尽管电台于1997年关闭，但几年后被一群无线电爱好者重新启用。

“无线电松鼠”群体

这些爱好者自称“无线电松鼠”，每周六聚集于此，发送海事新闻和天气报告，并接收零散信息。他们的主要通信对象是停泊在旧金山码头的二战时期船只SS Jeremiah O’Brien。发送信息时，他们使用名为“bug”的设备敲击摩尔斯电码字母，产生响亮的静电噪音回荡在建筑内。摄影师安·赫尔姆斯形容这“几乎像爵士乐”——一种依赖节奏和时机的音乐，不同操作者会产生细微差异。

设备维护与仪式感

电台内部分庞大设备可追溯至二战时期。志愿者们自行维修设备，并在eBay上搜寻较新设备的替换零件。为纪念电台历史，志愿者每周六早上举行“连续波教会”仪式，使用印有美国无线电公司旧标志的古董餐盘用餐。

摩尔斯电码的存续与传承

摩尔斯电码并未完全绝迹：美国海军仍对少数水手进行教学，2017年一名英国男子曾在海滩受伤后用手电筒发送摩尔斯电码求救。许多“无线电松鼠”已退休或临近退休，但当赫尔姆斯夏季访问时，发现一名17岁青少年在现场积极学习。这名年轻人出生于摩尔斯电码实际结束之后，却热衷于帮助延续这一传统。

本文配有多张图片，展示了电台控制中心内的模拟设备、操作设备的手部特写、志愿者工作场景等，生动呈现了这一独特社区的运作状态。

KamilaLisp 摘要

KamilaLisp 是一种受 Haskell 和 APL 等启发的、从头开始重写的函数式、灵活且简洁的 Lisp 方言。

主要特性与功能

该语言支持极其广泛的编程范式和功能模块，包括：

• 多种编程范式：支持并发、命令式、函数式、数组、面向对象、逻辑编程等。
• 高级数学与计算能力：提供任意精度复数/整数/十进制算术、众多数学函数（如伯努利数、伽马函数、傅里叶变换）、符号计算（微积分、级数展开、矩阵分解）以及机器字操作（贝塞尔函数、黎曼ζ函数等）。
• 数据处理与算法：包含 APL 风格的数组处理操作、集合操作、图数据结构及着色/聚类算法、后缀数组构造等。
• 并行与并发：通过 Actor 模型（守护线程、任务线程、消息传递）实现并行处理，支持函数式并行（如并行 map 和 filter）。
• 丰富的工具链与库：
  • 集成开发环境：支持远程会话、多工作区、项目管理和代码同步。
  • 数据 I/O：支持 JSON、CSV、XML、Base64 及多种压缩格式（XZ, gzip, lz4 等）和图片格式（PNG, JPG 等）的读写。
  • 网络与数据库：包含 HTTP 服务器、SQL 数据库连接、网络请求（fetch, wget）和套接字功能。
  • 系统交互：可作为 Shell 使用，提供 sh:ls、sh:glob 等命令的实现，并能管理进程。
  • 语言特性：支持模式匹配、尾递归优化、记忆化、模块系统、流、函数组合、柯里化等。

安装与使用

• 环境要求：需要 Java 17 JDK 或更新版本。
• 安装方式：
  1. 从源码构建：克隆 GitHub 仓库并使用 mvn package 构建。
  2. 使用预编译版本：下载指定版本的 JAR 文件，并可验证其 PGP 签名。
• 许可证：采用 GNU General Public License v3 许可证分发。

开发示例

文章提供了两个代码示例展示其语法风格：

1. SKI 组合子演算：通过模式匹配实现组合逻辑规则。
2. 列表与无点风格编程：使用类似 APL 的符号进行数组操作，展示其与 Haskell/APL 表达能力的对等性。

项目路线图

项目从原型（MalbolgeLISP）发展而来，经历了 v0.1（beta）、v0.2（beta）和 v0.3（release）阶段。v0.4 版本正在开发中，目标是实现编译器和字节码虚拟机。v0.3 版本遵循特定的版本命名规则（x 表示破坏性变更，y 表示非破坏性变更），且发布包均带有 PGP 签名。