2026-03-21

OpenCode 概要总结

OpenCode 是一个开源 AI 编码代理，旨在帮助开发者在终端、IDE 或桌面环境中编写代码。它具有以下主要特点和功能：

核心功能：

• 广泛的模型支持： OpenCode 支持连接来自任何提供商的 LLM 模型，包括 Claude、GPT、Gemini 等，并且通过 Models.dev 平台支持 75+ LLM 提供商，甚至支持本地模型。
• LSP 支持： 自动加载适合 LLM 的语言服务器协议 (LSP)，提升代码补全和智能提示的体验。
• 多会话支持： 允许在同一项目上并行启动多个代理，方便进行不同的任务或实验。
• 会话分享： 可以分享会话链接，方便参考和调试。
• 集成现有服务： 支持使用 GitHub Copilot 账户登录以及 OpenAI ChatGPT Plus/Pro 账户登录。
• 多平台支持： 提供终端界面、桌面应用程序和 IDE 扩展，适用于各种编辑器。

社区和影响力：

• 开源项目： OpenCode 拥有强大的开源社区，在 GitHub 上获得了 12 万 颗星，有 800 名贡献者，并进行了超过 1 万 次提交。
• 用户规模： 每月有超过 500 万 开发者使用 OpenCode。

隐私保护：

• 隐私优先： OpenCode 不会存储任何用户的代码或上下文数据，从而可以在对隐私敏感的环境中安全使用。

Zen – 优化模型：

• 可靠的模型选择： Zen 提供了 OpenCode 经过测试和基准测试的 AI 模型集合，确保编码代理的性能和质量，避免不同提供商之间的不一致性。

其他：

• OpenCode 旨在成为一个开源 AI 编码代理，致力于为开发者提供高效、可靠且安全的编码辅助工具。
• 用户可以加入等待名单，以获得新产品的早期访问权限。

Windows 11 更新计划：性能、可靠性和精良体验 (Windows 11 Update Plan: Performance, Reliability, and Craft)

以下是对 Microsoft Windows Insider 计划最新消息的总结，重点介绍了未来一年 Windows 11 的改进计划。

总体目标: 提升 Windows 11 的整体质量，重点关注 性能 (Performance)、可靠性 (Reliability) 和 精良体验 (Craft)。

近期更新（即将推出）:

• 任务栏自定义增强: 允许将任务栏移动到屏幕顶部或侧边，提供更多个性化选项。
• AI 集成优化 (Copilot): 更谨慎地集成 Copilot，减少不必要的入口点，例如在剪切工具、照片、小组件和记事本等应用中。
• 更新体验改进: 提供更多控制权，允许跳过设备设置中的更新、在重启或关机时避免安装更新，以及更长时间地暂停更新，同时减少自动重启和通知。
• 更快、更稳定的资源管理器 (File Explorer): 提升启动速度、减少闪烁、优化导航，并提高日常文件任务的可靠性。
• 小组件 (Widgets) 和推送体验控制: 提供更安静的默认设置、更灵活的控制，以及对 Discover 推送的个性化改进。
• Windows Insider 计划简化: 更清晰的通道定义、更易于访问的新功能、更高质量的构建、更透明的反馈循环以及与开发团队直接交流的机会。
• Feedback Hub 更新: 推出改进后的 Feedback Hub 应用，提供更快的反馈提交和社区参与体验。

未来一年重点领域:

1. 性能 (Performance): 提升系统响应速度和一致性。 * 系统性能优化: 降低 Windows 资源占用，释放更多性能用于应用程序。包括启动时间缩短、内存效率提升和更稳定的性能。 * 应用交互响应优化: 利用 WinUI3 框架减少交互延迟，提高启动菜单等核心体验的响应速度。 * 资源管理器改进: 降低搜索、导航和上下文菜单的延迟，加快大文件复制和移动速度，并提升日常文件任务的响应速度。 * Windows Subsystem for Linux (WSL) 增强: 提升 Linux 工具和环境在 Windows 上的性能、可靠性和集成度。包括更快的 Linux 和 Windows 之间文件性能、改进的网络兼容性、简化首次设置，以及更强大的企业管理控制。

2. 可靠性 (Reliability): 确保 PC 在需要时稳定可靠运行。 * Windows Insider 计划增强: 提高每个 Insider 通道构建的质量，并加强反馈信号，以改善构建质量。 * 操作系统、驱动程序和应用程序可靠性提升: 减少系统崩溃、提高驱动程序质量和应用程序稳定性。改善蓝牙连接、减少 USB 错误、提高打印机发现和连接的可靠性。 * Windows 更新体验改进: 减少更新中断，采用单次每月重启，并提供更新暂停、重启和关机控制。 * Windows Hello 生物认证增强: 提高面部识别和指纹识别的可靠性，降低重试次数。

3. 精良体验 (Craft): 将功能性产品转化为受用户喜爱的体验。 * 开始菜单和任务栏改进: 提高访问应用程序和文件的可靠性和灵活性，并提供更多个性化选项。 * 减少干扰，提升专注度: 简化设备设置、默认情况下提供更安静的小组件体验、简化设置选项，并减少通知。 * 搜索功能增强: 提供更快速、更准确的搜索结果，并在 Windows 表面提供一致的搜索体验。

其他信息:

• Microsoft 致力于通过 Secure Future Initiative 持续增强 Windows 的安全性。
• Microsoft 将继续听取用户反馈，以改进 Windows。

总而言之，Microsoft 致力于通过持续的改进和创新，构建更稳定、更快速、更可靠和更易用的 Windows 11 系统。

BYD电动汽车需求因油价上涨而激增：总结

核心内容：

由于中东地区紧张局势导致油价飙升，比亚迪（BYD）的电动汽车（EV）销量显著增长。消费者正在寻求替代能源，以应对不断上涨的油价。

关键细节：

• 销量领先： BYD已于2022年停止生产仅使用内燃机（ICE）的车辆。2025年，比亚迪成为全球最大的电动汽车制造商，售出超过460万辆电动汽车和插电式混合动力汽车，首次超过福特，位居全球第六。
• 亚洲市场需求激增： 在菲律宾马尼拉的一个比亚迪经销商处，订单量在短短两周内就积压了一个月的量。越南也出现类似情况，VinFast经销商的客流量增加了四倍。
• 全球油耗减少： 据英国Ember分析，2025年全球电动汽车的普及避免了每天170万桶的石油消耗，相当于伊朗出口量的70%。
• 亚洲受油价影响： 亚洲（特别是东南亚国家）的电动汽车普及率高于美国和欧洲，但仍然受到油价上涨的冲击。
• 政策调整： 一些国家，如老挝，正在削减电动汽车的注册和服务费，同时提高燃油汽车的费用。
• 泰国市场： 泰国汽车工业联合会的发言人表示，由于政府补贴减少，此前对2026年电动汽车需求的乐观程度较低。但如果油价维持或继续上涨，预计电动汽车需求将大幅增加。
• 美国和欧洲市场： 中国预计将出现最大的需求增长，但美国和欧洲等主要市场也在看到消费者转向电动汽车。
• 消费者行为： 根据Edmunds的数据，3月初，消费者对电动汽车的考虑度比上周增加了20%以上。
• 比亚迪优惠： 为了进一步推动电动汽车的普及，比亚迪计划为部分电动汽车提供18个月的免费充电服务。

总结：

中东地缘政治紧张局势导致的油价上涨正在推动全球电动汽车需求，特别是对比亚迪等领先制造商的电动汽车需求。亚洲市场受影响最为显著，各国政府也在调整政策以鼓励电动汽车的采用。 随着消费者寻求降低能源成本，并实现能源独立，电动汽车正变得越来越有吸引力。

HomeSec-Bench 性能评估：Qwen3.5 在 MacBook Pro M5 上表现出色

本文介绍了 HomeSec-Bench，一个用于评估大型语言模型 (LLM) 在实际家庭安全助手场景下的表现的基准测试。该基准测试由 Aegis-AI 开发，是 DeepCamera 去中心化 AI 技能生态系统的一部分。

主要发现：

• Qwen3.5-9B 的卓越表现: Qwen3.5-9B (Q4_K_M) 在 HomeSec-Bench 评估中取得了 93.8% 的通过率，仅比 GPT-5.4 (97.9%) 低 4 个百分点。该模型运行在 MacBook Pro M5 (M5 Pro 芯片, 18 核, 64GB 统一内存, macOS 15.3) 上，使用 llama.cpp，速度为 25 tok/s，首次标记时间 (TTFT) 为 765ms，且仅消耗 13.8 GB 统一内存。
• 本地 AI 的价值: 能够在笔记本电脑上运行的 9B 模型，在特定领域任务中表现出与 GPT-5.4 接近的性能，同时实现完全离线运行和完整隐私保护，是本地 AI 的核心价值。
• 本地模型 TTFT 优势: Qwen3.5-35B-MoE 的 TTFT (435ms) 低于所有 OpenAI 云模型，例如 GPT-5.4-nano (508ms)。
• 基准测试内容: HomeSec-Bench 包含 96 个 LLM 测试和 35 个视觉语言模型 (VLM) 测试，涵盖 16 个测试套件，包括工具使用、安全分类、事件去重等。
• 测试场景: 基准测试模拟了实际的家庭安全助手工作流程，例如推理、分诊和工具使用，而非普通的聊天场景。所有 35 张固定图像都是 AI 生成的。
• 实时演示: 可以观看基准测试套件在 Apple Silicon 上实时执行，展示每个测试的过程。

模型排行榜：

相关链接:

• 下载 Aegis: [/#download]
• GitHub 仓库: https://github.com/SharpAI/DeepCamera/tree/master/skills/analysis/home-security-benchmark

新闻出版商限制互联网档案访问，威胁历史记录 (Xīnwén chūbǎnshāng xiànzhì Hùliánwǎng Dàikù Fǎngwèn, Wēixié Lìshǐ Jìlù)

过去几个月，一种类似于新闻出版商停止向图书馆提供纸质报纸的现象在互联网上出现。互联网档案 (Internet Archive)，作为世界上最大的数字图书馆，自 90 年代中期以来一直致力于保存和公开访问互联网内容。其运营的“时光机” (Wayback Machine) 包含超过一万亿页存档网页，被记者、研究人员和法院广泛使用。

然而，最近《纽约时报》(The New York Times) 开始采取技术手段阻止互联网档案对其网站进行抓取，并有其他报纸，如《卫报》(The Guardian)，似乎也正在效仿。这些措施超越了传统的 robots.txt 规则。

主要内容和影响：

• 历史记录的威胁： 互联网档案长期以来是新闻网站的可靠存档，对于记录新闻故事的原始发布状态至关重要。许多文章会被编辑、更改或删除，互联网档案常常是唯一能够查阅这些变更的来源。出版商的阻止行为会使得这些历史记录逐渐消失。
• 出版商的担忧： 出版商采取此举的主要原因是担心人工智能 (AI) 公司抓取新闻内容。一些出版商，包括《纽约时报》，正在起诉 AI 公司，指控其未经授权使用受版权保护的材料进行模型训练。
• 错误的回应： 文章认为，出版商阻止非营利性档案机构的做法是错误的。互联网档案并非构建商业 AI 系统，而是致力于保存历史记录。为了控制 AI 访问而关闭这种保存行为，可能会导致数十年来的历史文献被毁。
• 法律依据： 文章强调，材料的可搜索性本身就是一种合理的“合理使用” (fair use)。法院已经承认，构建可搜索索引通常需要复制底层材料。这与谷歌复制书籍以创建可搜索数据库的案例类似，法院认为这是一种合理的“合理使用”，因为它具有改变性，促进了发现、研究和对创意作品的新见解。
• 互联网档案的角色： 互联网档案遵循同样的原则，就像实体图书馆保存报纸供未来读者阅读一样，它保存着互联网的历史记录。维基百科本身就链接到互联网档案中保存的 260 多万篇新闻文章，涵盖 249 种语言。
• 呼吁： 文章警告说，如果出版商阻止互联网档案，未来研究人员可能会发现互联网历史记录的大部分已经消失。解决 AI 训练相关的法律纠纷至关重要，但牺牲公共记录来应对这些争端将是一个深远且可能无法逆转的错误。

总结：

新闻出版商限制互联网档案访问的行为，威胁到互联网历史记录的保存。虽然出版商对 AI 抓取存在担忧，但阻止非营利性档案机构的做法是不可取的，并且可能导致重要的历史文献丢失。文章强调了互联网档案在维护公共记录方面的重要性，并呼吁出版商重新考虑其政策，以确保历史信息的持续可访问性。

Attention Residuals (AttnRes) 总结

本仓库是 Attention Residuals (AttnRes) 的官方代码库。AttnRes 是一种对 Transformer 模型中标准残差连接的替代方案，它允许每一层通过学习到的、输入相关的注意力机制，选择性地聚合之前层的表示。

核心思想与优势：

• 问题： 标准残差连接使用固定权重累积所有层输出，导致深度增加时，每一层的贡献被稀释，并且隐藏状态的幅度会无限制地增长（PreNorm 问题）。
• 解决方案： AttnRes 使用 softmax 注意力机制，对先前层输出进行累积： $$\mathbf{h}_l = \sum_{i=0}^{l-1} \alpha_{i \to l} \cdot \mathbf{v}_i$$ 其中，权重 $\alpha_{i \to l}$ 由每个层学习到的伪查询 $\mathbf{w}_l$ 计算得出。 这样，每一层都可以选择性地、根据内容感知地访问所有先前的表示。

Block AttnRes：

• 为了解决 Full AttnRes 在大规模应用中的内存问题 (O(Ld))，提出了 Block AttnRes。
• Block AttnRes 将层划分为 N 个块，在每个块内使用标准残差连接进行累积，然后在块级别进行注意力计算。
• 使用大约 8 个块即可恢复 Full AttnRes 的大部分优势，同时作为一种具有微小开销的、易于替换的方案。

关键技术细节（PyTorch 伪代码）：

• block_attn_res 函数: 在块内和块间应用注意力机制，将各个块的表示以及部分和进行堆叠，计算注意力权重，并进行加权聚合。
• forward 函数: 实现了前向传播过程，包括块内注意力、自注意力层、MLP 层，以及块边界时的块更新。

实验结果：

• Scaling Laws： AttnRes 在所有计算预算下都优于基线模型。Block AttnRes 的损失与使用 1.25倍 计算的基线模型相当。
• 下游任务： 在 Kimi Linear 48B / 3B 模型上进行评估，AttnRes 在多个基准测试中均有提升，尤其是在多步推理（GPQA-Diamond +7.5）和代码生成（HumanEval +3.1）方面。
• 训练动态： AttnRes 缓解了 PreNorm 稀释问题，输出幅度保持稳定，梯度范数在各层分布更均匀。

总结：

AttnRes 通过引入注意力机制到残差连接中，实现了对 Transformer 模型的改进。Block AttnRes 进一步优化了内存效率，使得 AttnRes 成为一种实用且高效的替代方案，在多个下游任务中展现出优越的性能。

引用:

@misc{chen2026attnres, ...} (arXiv:2603.15031)

FFmpeg 架构概览

本文档概述了FFmpeg包的架构，并提供了一个简单的播放器示例。

FFmpeg 包内容

FFmpeg 是一个工具和库的集合，用于处理各种音频和视频格式，包括编码、解码、转码和流媒体传输。

FFmpeg 工具

• ffmpeg: 命令行工具，用于在不同格式之间转换多媒体文件。
• ffplay: 基于 SDL 和 FFmpeg 库的简单媒体播放器。
• ffprobe: 简单多媒体流分析器。

FFmpeg 库

这些库允许开发者将 FFmpeg 的功能集成到自己的应用程序中：

• libavformat: 处理 I/O、多路复用和解复用。
• libavcodec: 编码和解码。
• libavfilter: 基于图的原始媒体滤镜。
• libavdevice: 输入/输出设备。
• libavutil: 常见的多媒体实用程序。
• libswresample: 音频重采样、样本格式转换和音频混合。
• libswscale: 颜色转换和图像缩放。
• libpostproc: 视频后期处理（去块/降噪滤镜）。

FFmpeg 简单播放器

FFmpeg 播放器基本流程是将多媒体流（来自文件或网络）解复用为音频和视频流，然后将这些流解码为原始音频和视频数据。

关键数据结构：

• AVFormatContext: 提供同步、元数据和多路复用功能的高级结构。
• AVStream: 连续的流（音频或视频）。
• AVCodec: 定义数据编码和解码方式。
• AVPacket: 流中的编码数据。
• AVFrame: 解码后的数据（原始视频帧或原始音频样本）。

基本流程：

1. 使用 avformat_open_input 打开多媒体文件。
2. 使用 avformat_find_stream_info 分析文件内容，识别流。
3. 遍历流，使用 avcodec_find_decoder 查找与流对应的解码器。
4. 为每个流分配 AVCodecContext 结构，并使用 avcodec_parameters_to_context 配置解码器。
5. 使用 avcodec_open2 打开解码器。
6. 使用 av_read_frame 从输入多媒体文件中解复用数据包。
7. 将数据包发送到解码器 (avcodec_send_packet)。
8. 从解码器接收解码帧 (avcodec_receive_frame)。
9. 处理解码后的原始视频帧。
10. 释放所有分配的内存。

代码示例：

代码示例展示了如何使用 libavformat 和 libavcodec 库从文件中读取多媒体流、分析内容、解复用音频和视频流，并解码视频流。它使用 AVFormatContext、AVStream、AVCodecContext、AVPacket 和 AVFrame 结构来管理多媒体数据。

构建和运行示例：

需要安装 meson 和 ninja。 提取示例代码到 ffmpeg-101 文件夹，然后执行 meson setup build 和 ninja -C build，最后运行 ./build/ffmpeg-101 sample.mp4。

日本餐桌上的筷子禁忌：一份实用指南 (Rìběn cānzhuō shàng de kuàizi jìnjì: yī fèn shìyòng gùidān) - Japanese Chopstick Etiquette: A Practical Guide

本文列举了在日本用餐时应避免的筷子使用方式，这些行为被称为 kiraibashi (筷子禁忌)。 避免这些禁忌有助于展现尊重和良好的礼仪。

主要禁忌分类及具体行为：

• 与佛教习俗相关的禁忌 (Yǔ Fójiào xísú xiāngguān de jìnjì):
  • 立て箸 (Tatebashi): 将筷子垂直立在米饭碗中，这与佛教葬礼上供奉米饭的方式相同，因此被视为极大的禁忌 (!!! - Serious)。
  • 橋箸 (Hashibashi): 将筷子像桥梁一样横放在菜肴顶部，表示用餐完毕。正确的做法是将筷子放在筷子架 (hashioki) 上。
• 与丧葬习俗相关的禁忌 (Yǔ sàngzàng xísú xiāngguān de jìnjì):
  • 合わせ箸 (Awasebashi): 用一双筷子夹取食物，然后传递给另一双筷子，这与火葬后收集遗骨并传递的过程相似，因此是禁忌 (!!! - Serious)。
• 不雅或不尊重行为 (Búyǎ huò bù zūnzhòng xíngwéi):
  • あ げ 箸 (Agebashi): 将筷子举过嘴巴的高度。
  • 洗 い 箸 (Araibashi): 用筷子在汤或饮料中清洗。
  • うら 箸 (Urabashi): 用筷子夹起食物，又放回菜肴中。
  • 拝 み 箸 (Ogamibashi): 用双手握住筷子表达对食物的感谢，这被认为是在祈祷时拿着物品，不尊重。在说“Itadakimasu” (用餐前表示感谢) 时也不应如此。
  • 押し 込み 箸 (Oshikomibashi): 用筷子将食物深埋进嘴里。
  • 落 と し 箸 (Otoshibashi): 筷子掉落。
  • 返 し 箸 (Kaeshibashi): 在上菜时翻转筷子，避免接触过嘴巴的筷子尖端接触食物。
  • か き 箸 (Kakibashi): 将嘴贴在盘子边缘，用筷子将食物推入。也指用筷子抓挠头部或其他身体部位。
  • か み 箸 (Kamibashi): 咬筷子。
  • くわ え 箸 (Kuwaebashi): 用筷子尖端含在嘴里。
  • こ じ 箸 (Kojibashi): 用筷子从菜肴底部挑出食物。
  • 指 し 箸 (Sashibashi): 用筷子指着人或物。
  • じか 箸 (Jikabashi): 用自己的筷子从公共菜肴中取食物，而不是使用公筷。
  • 涙 箸 (Namidabashi): 吃饭时让酱汁或汤从筷子尖端滴落。
  • 握 り 箸 (Nigiribashi): 用拳头握住筷子。
  • ね ぶり 箸 (Neburibashi): 舔筷子。
  • 振り 上 げ 箸 (Furiagebashi): 将筷子尖端举过手腕高度。
  • 振り 箸 (Furibashi): 用筷子甩掉筷子尖端的汤、酱汁或小碎片。
  • も ぎ 箸 (Mogibashi): 咬掉粘在筷子上的米粒。
  • 持ち 箸 (Mochibashi): 同时用一只手拿着筷子和盘子。
  • 楊 枝 箸 (Yōjibashi): 用筷子当牙签。
  • 横 箸 (Yokobashi): 将筷子并排排列，用它们像勺子一样舀取

伊利诺伊州初选中的加密货币超级政治行动委员会支出总结

加密货币行业的超级政治行动委员会（Super PACs）在伊利诺伊州初选期间投入了1420万美元。然而，高达90%（1280万美元）的资金被浪费了，因为它们流向了最终赢得初选的民主党候选人。

关键支出情况：

• 反对胜选者：
  • 1000万美元用于反对参议员候选人朱利安娜·斯特拉顿（Juliana Stratton），但斯特拉顿最终获胜。
  • 250万美元用于反对H-07选区的拉肖恩·福特（La Shawn Ford），福特也最终获胜。
• 反对落败者： 超级政治行动委员会还反对了罗伯特·彼得斯（Robert Peters，H-02选区），彼得斯在民意调查中排名第三，最终仅获得12%的选票。
• 支持胜选者： 超级政治行动委员会支持了比恩（Bean，H-08选区）和现任议员巴德津斯基（Budzinski，H-13选区），两人在民意调查中领先，最终获胜。

总体效果：

超级政治行动委员会在伊利诺伊州的唯一成功案例是支持那些结果本已高度可能出现的候选人。 总体而言，这些支出效率低下，并且仅消耗了超级政治行动委员会可用资金的不到6%。预计未来八个月内，将会出现更多的支出。

Ubuntu 26.04 LTS 引入密码反馈星号：一场 Linux 历史争论

Ubuntu 26.04 LTS (代号 Resolute Raccoon) 将于 2026 年 4 月 23 日发布，其最大的改变之一是 sudo 命令密码提示将显示星号 (*) 反馈，取代过去几十年来的空白提示。这一小小的用户体验改进引发了 Linux 社区一场罕见的激烈辩论。

历史背景：沉默的密码

sudo 命令最初由 Bob Coggeshall 和 Cliff Spencer 于 1980 年在纽约州立大学水牛城分校创建。最初的设计理念是在共享终端环境下，通过隐藏密码长度来防止“肩窥”攻击（即通过观察键盘输入猜测密码）。这种沉默的密码提示延续了近半个世纪。Linux Mint 曾率先在自己的配置中默认启用密码反馈，但主流发行版，包括 Ubuntu，一直坚持使用经典空白提示。

sudo-rs 的崛起：Rust 重写规则

Ubuntu 引入这一改变的关键在于 sudo-rs，一个用 Rust 语言从头重写 sudo 命令的替代版本。自 Ubuntu 25.10 起，Canonical 默认使用 sudo-rs，但用户并未察觉到行为上的显著变化。在 Ubuntu 26.04 发布前的两周，sudo-rs 项目合并了一个启用 pwfeedback 选项的补丁，Canonical 将该补丁应用到 Ubuntu 26.04 的开发版本中。需要注意的是，经典 sudo 包（有时称为 sudo-ws）不受影响，只有 sudo-rs 路径显示星号。

时间轴回顾：

• 1980: sudo 创建于 SUNY 水牛城分校，默认采用沉默的密码输入。
• Ubuntu 25.10 (2025年10月): Canonical 替换经典 C 版本的 sudo 为 sudo-rs (Rust)，用户行为基本不变。
• 2025年10月: 提交 bug 报告，请求默认启用 pwfeedback 以改善用户体验。
• 2026年2月: sudo-rs 项目合并 pwfeedback 补丁，Canonical 应用到 Ubuntu 26.04 开发版本。社区辩论爆发。
• 2026年4月23日: Ubuntu 26.04 LTS “Resolute Raccoon” 正式发布，密码星号反馈成为默认设置。

安全争论：双方观点

批评者认为，这种改变打破了历史安全措施，增加了密码长度暴露的风险。然而，sudo-rs 的开发者反驳称，隐藏密码长度的实际安全收益微乎其微。攻击者若能靠近屏幕观察密码，同样可以听到或看到键盘输入。此外，大多数用户使用与登录密码相同的 sudo 密码，而登录界面已经显示密码输入的占位符点，在终端隐藏星号而登录界面显示则属于“安全秀”。

对比表格：

恢复经典行为：

用户可以通过编辑 sudoers 文件（使用 visudo 命令以避免语法错误）添加 Defaults !pwfeedback 这一行来恢复沉默的密码提示。更改会立即生效。

更广泛的意义：

星号改变是 Ubuntu 26.04 更广泛现代化的一部分，包括使用 GNOME 50（在 Wayland 上运行）、Linux 内核 7.0 以及采用 Rust 语言编写的核心工具，例如 uutils/coreutils。

总而言之，Ubuntu 26.04 引入密码反馈星号，代表了用户体验和安全之间权衡的讨论，同时也体现了 Linux 系统持续演进的过程。用户可以选择恢复经典行为，而开发者则认为默认启用星号反馈更符合现代用户的使用习惯。

代码仓库摘要

这是一个包含 Arnold Robbins 所著 Linux Application Development By Example - The Fundamental APIs 一书代码的仓库。

主要内容：

• 代码来源: 该仓库存储了该书中提供的示例程序代码。
• 版权信息: 版权归 Pearson Education 所有 (2004, 2026)。
  • ISBN-13: 978-0-13-532552-0
  • ISBN-10: 0-13-532552-8
• 目录结构:
  • Documents 目录：包含相关文档，包括作者编写代码的许可证以及勘误表 (errata.txt)，勘误表会随着发现错误而更新。
  • 其他目录：分别对应书中的各个章节，存储了相应章节的示例程序。
• 问题反馈: 可以通过提交 Issue 来报告书中的问题或错误。
• 最后更新时间: 2025年10月10日 (IDT时间)。

总结: 该仓库是 Linux Application Development By Example - The Fundamental APIs 一书的代码示例集合，提供版权信息、文档和问题反馈机制。

总结：关于 openui-lang 解析器的经验教训

本文讲述了作者在构建 openui-lang 解析器时的经历，该解析器将 LLM 输出的自定义 DSL 转换为 React 组件树。最初，作者使用 Rust 构建了该解析器，并将其编译为 WASM，以期获得接近原生速度的性能。然而，实际情况并非如此，最终作者放弃了 WASM，改用 TypeScript 实现，并对流式解析进行了优化。

最初的尝试：Rust + WASM

• 设计目标： 利用 Rust 的速度和 WASM 在浏览器中的性能优势，构建一个高效的解析器。
• 解析流程： 包含 autocloser、lexer、splitter、parser、resolver、mapper 六个阶段，最终输出 ParseResult。
• 性能瓶颈： 尽管 Rust 代码运行速度很快，但 WASM 与 JavaScript 之间的边界调用带来了显著的开销。主要包括：将字符串复制到 WASM 线性内存、Rust 代码进行解析、将结果序列化为 JSON 字符串、将 JSON 字符串复制回 JavaScript 堆、JavaScript 使用 JSON.parse 反序列化结果。
• 尝试优化： 尝试使用 serde-wasm-bindgen 直接将 Rust 结构体转换为 JavaScript 对象，避免 JSON 序列化，但性能反而下降了 30%。原因是，WASM 和 JavaScript 使用不同的内存布局，serde-wasm-bindgen 需要进行大量的细粒度转换，导致性能下降。

转向 TypeScript 并优化流式解析

• 优化方案： 将整个解析器管道移植到 TypeScript，完全在 V8 堆中运行，消除了 WASM 边界的开销。
• 性能提升： 相比 WASM，TypeScript 的解析速度提升了 2.2x - 4.6x。
• 更深层次的瓶颈： 最初的流式解析方式，在收到每个 LLM chunk 后都会重新解析整个字符串，导致时间复杂度为 O(N²)。
• 最终优化： 引入了语句级别的增量缓存机制。仅对流中未完成的语句进行解析，已完成的语句则从缓存中读取，时间复杂度降低到 O(N)。
• 性能提升： 增量缓存机制使得总解析成本降低了 2.6x - 3.3x。

总结与教训

• 关注真正的性能瓶颈： 在选择实现语言之前，务必对代码进行性能分析，找出真正的瓶颈所在。
• 避免不必要的边界调用： WASM 与 JavaScript 之间的边界调用会带来显著的开销，应尽量避免。
• 算法优化的重要性： 算法的复杂度优化通常比语言级别的优化更能提升性能。
• WASM 的适用场景： WASM 更适合计算密集型且边界交互少的场景，例如图像/视频处理、加密和物理模拟等。
• WASM 与 JavaScript 的内存模型不同： WASM 和 JavaScript 使用不同的内存布局，直接传递对象会导致性能下降。

总而言之，该案例强调了在选择技术栈时，需要仔细评估性能瓶颈，并选择最合适的优化方案，而不是盲目追求新技术带来的性能提升。

Ghostling 项目总结

Ghostling 是一个演示项目，旨在展示基于 libghostty C API 构建的最小功能终端。该项目使用 Raylib 进行窗口和渲染，采用单线程设计，并使用 2D 图形渲染器，与 Ghostty GUI 使用的直接 GPU 渲染器不同。

核心组件：Libghostty

libghostty 是从 Ghostty 核心提取的嵌入式库，它提供了 C 和 Zig API，允许任何应用程序嵌入正确的、快速的终端仿真。Ghostling 使用 libghostty-vt，这是一个零依赖库（甚至不需要 libc），负责 VT 序列解析、终端状态管理（光标位置、样式、文本换行、滚动缓冲区等）和渲染器状态管理。libghostty-vt 本身不包含渲染或窗口代码，需要应用程序提供自己的实现。

主要功能

尽管 Ghostling 是一个精简的终端，但它包含以下功能：

• 文本换行和调整大小
• 24 位颜色和 256 色调板支持
• 粗体、斜体和反显文本样式
• Unicode 和多码位字符处理
• 键盘输入，支持修饰键（Shift、Ctrl、Alt、Super）
• Kitty 键盘协议支持
• 鼠标跟踪（X10、普通、按钮和任意事件模式）
• 鼠标报告格式（SGR、URxvt、UTF8、X10）
• 滚轮支持（视口滚动或传递给应用程序）
• 带有鼠标拖动滚动的滚动条
• 焦点报告 (CSI I / CSI O)
• 支持 Ghostty 终端仿真支持的大部分功能

未来计划

• Kitty 图形协议
• OSC 剪贴板支持
• OSC 标题设置
• Windows 支持 (libghostty-vt 支持 Windows)

限制

• Kitty 键盘协议支持因 Raylib 输入系统的限制而存在问题。
• Ghostling 并非为日常使用设计的完整终端，而是一个基于 libghostty 的最小可行终端。

构建

• 需要 CMake 3.19+ 和 Ninja
• 需要一个 C 编译器
• 需要 Zig 0.15.x 在 PATH 中
• 构建命令：cmake -B build -G Ninja 和 cmake --build build
• Release 版本的构建命令：cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release 和 cmake --build build

FAQ

• 为什么不使用 Zig？: libghostty-vt 有一个成熟的 Zig API，但为了展示更广泛的适用性，该演示项目使用了 C API。
• Rust 或其他语言呢？: libghostty-vt 的 C API 允许在各种语言中通过绑定使用。
• libghostty 是否需要 Raylib？: 不需要！libghostty 对渲染器或 GUI 框架没有要求，并且支持 WASM。
• 为什么使用 CMake 和 Raylib？: 选择 CMake 和 Raylib 是为了方便构建和演示，可以替换为其他构建系统和 GUI 库。

总而言之，Ghostling 是一个展示 libghostty 功能的演示项目，它提供了一个轻量级的终端仿真实现，可以嵌入到各种应用程序中。

软件定制革命？不值得期待。

核心观点： 尽管人工智能技术的发展使得软件定制变得更容易，但作者认为“软件定制革命”的说法过于夸大。 大多数人并不真正喜欢电脑，他们只是为了完成工作而使用它们。 软件定制并非大多数人的需求，尤其是那些需要处理大量工作和维护系统的企业。

主要论点：

• 定制软件的历史问题： 过去，定制软件通常质量低下，臃肿且复杂，因为客户付费导致开发方向偏离实际需求。
• 软件开发者自身的偏见： 软件开发者自然对构建软件充满热情，但这并不代表大众也喜欢构建软件。
• 大众对计算机的态度： 大多数人只是容忍电脑，他们希望避免与电脑打交道，并希望解决方案能够简化工作流程，而不是增加额外负担。
• 企业用户的真实需求： 小型会计事务所希望减少文案工作，区域物流公司希望优化路线，律师事务所希望提高时间利用率，他们真正需要的是解决问题，而不是设计和维护软件系统。
• 工具与使用者的区别： 拥有软件构建工具并不能保证每个人都会成为软件开发者。 就像挖掘机并不能让普通人变成建筑承包商一样，大多数人只希望问题得到解决，而不想承担构建和维护系统的责任。
• 人工智能的应用： 人们会使用人工智能来解决各种问题，但只有少数人会深入构建复杂的定制系统，这些人通常本身就对软件有兴趣。

总结： 作者认为，虽然人工智能降低了软件定制的门槛，但大多数企业和个人更希望依赖现成的解决方案，而不是自己构建和维护复杂的系统。 他们更关心的是问题的解决，而不是工具的使用。 “软件定制革命”的说法忽略了大众对电脑的真实态度和企业用户的实际需求。

作者介绍： Jason Fried，37signals 的联合创始人兼 CEO，该公司开发了 Basecamp 和 HEY。

Fortransky: 一个用 Fortran 编写的 Bluesky/AT 协议客户端

Fortransky 是一个纯终端 Bluesky/AT 协议客户端，使用 Fortran 编写，并采用 Rust 原生解码器处理 relay-raw 数据流。

架构:

Fortransky 的架构如下：

• Fortran TUI (src/): 终端用户界面，使用 Fortran 编写。
• C libcurl bridge (cshim/): Fortran 与 libcurl 之间的桥接，用于网络请求。
• Fortran iso_c_binding module (src/atproto/firehose_bridge.f90): Fortran 模块，作为 Rust 静态库的接口。
• Rust staticlib (bridge/firehose-bridge/): Rust 静态库，负责解码 relay-raw 数据流，将 envelope 转换为 CAR，再转换为 DAG-CBOR，最后转换为标准化 JSON。
• firehose_bridge_cli binary: Rust 编译的二进制文件，用于 relay_raw_tail.py 脚本。

会话状态保存在 ~/.fortransky/session.json 文件中。建议使用应用密码而不是主 Bluesky 密码。

构建依赖:

• 系统包 (Ubuntu/Debian):
  • sudo apt install -y gfortran cmake pkg-config libcurl4-openssl-dev
• Rust 工具链:
  • 需要 rustc >= 1.70。使用 rustup 安装。
• Python 依赖 (仅限 relay-raw 数据流路径):
  • relay_raw_tail.py 脚本需要 cbor2 和 websockets 库。
    • 选项 A (系统范围): sudo pip install cbor2 websockets --break-system-packages
    • 选项 B (venv): 创建 venv，安装依赖，然后激活 venv 或设置环境变量 FORTRANSKY_RELAY_PYTHON=$PWD/.venv/bin/python3。

构建过程:

1. 运行 ./scripts/build.sh。
2. 该脚本首先构建 Rust 桥接库 (cargo build --release)，然后运行 CMake。后续构建会跳过 Rust 步骤，除非代码有更改。
3. 使用 ./build/fortransky 运行客户端。

登录:

• 使用 应用密码 登录。
• 在主界面输入 l 命令，输入标识符和应用密码。
• 会话状态将保存到 ~/.fortransky/session.json。
• 可以使用 x 命令注销。

TUI 命令:

• 主界面:
  • l: 登录并获取时间线。
  • x: 注销并清除会话。
  • a <handle>: 查看作者的时间线。
  • s <query>: 搜索帖子。
  • p <handle>: 查看个人资料。
  • n: 查看通知。
  • c: 撰写帖子。
  • t <uri/url>: 打开线程。
  • j: 流式查看 (stream tail)。
  • m: 切换流模式 (jetstream / relay-raw)。
  • q: 退出。
• 帖子列表界面:
  • j / k: 移动选择。
  • n / p: 下一/上一页。
  • o: 打开选定的线程。
  • r: 回复选定的帖子。
  • l: 喜欢选定的帖子。
  • R: 转发选定的帖子。
  • q: 引用帖子。
  • P: 打开作者的个人资料。
  • /query: 搜索。
  • b: 返回主界面。
• 通知界面:
  • j / k: 移动选择。
  • n / p: 下一/上一页。
  • o: 打开线程。
  • r: 回复。
  • b: 返回。