Apple发布搭载M4系列芯片的MacBook Pro

核心升级：M4系列芯片与Apple Intelligence

Apple推出了搭载全新M4系列芯片（M4、M4 Pro和M4 Max）的新款MacBook Pro，旨在提供显著的性能提升并引入Apple Intelligence个人智能系统。这款新笔记本专为专业工作流程设计，同时致力于保护用户隐私。

M4系列芯片详情与性能

M4系列芯片采用第二代3纳米技术打造，旨在为笔记本电脑带来极致的性能与能效。

• M4：适用于企业家、学生和创作者。配备10核CPU和10核GPU，起步内存为16GB（最高可选32GB）。在图形处理等任务上，性能较M1芯片有巨大提升。
• M4 Pro：面向研究人员、开发者和工程师等需要更强大性能的用户。搭载14核CPU和最高20核GPU，内存带宽较上一代提升75%。在执行复杂的地理映射、数据建模等任务时，速度可达M1 Pro型号的3倍。
• M4 Max：为数据科学家、3D艺术家和作曲家等专业人士设计。提供最高16核CPU和40核GPU，内存带宽超过半TB/s，并支持最高128GB的统一内存。它能够流畅处理视觉特效、3D动画和大型语言模型等超重负荷，性能最高可达M1 Max的3.5倍。

所有M4系列芯片都配备了强大的神经网络引擎和机器学习加速器，专为AI任务优化，并共同实现了长达24小时的电池续航，创下Mac新纪录。

主要新功能与改进

• 显示屏：保留Liquid Retina XDR显示技术，并新增可选的纳米纹理显示屏，能大幅减少反光。SDR内容亮度最高可达1000尼特，HDR内容峰值亮度仍为1600尼特，适合户外使用。
• 摄像头：升级为1200万像素Center Stage摄像头，优化了低光环境下的视频质量，并支持“人物居中”和“桌面视图”功能。
• 连接性：
  • 搭载M4 Pro和M4 Max的型号支持雷雳5，传输速度高达120 Gb/s。
  • 所有型号均配备支持8K输出的HDMI端口、SD卡槽和MagSafe 3充电端口。
• macOS Sequoia与Apple Intelligence：新系统带来多项功能，包括iPhone镜像、更智能的Safari浏览器、重新设计的密码管理应用等。Apple Intelligence目前在美国英语版系统中可用，提供写作工具、Siri升级等功能，后续将扩展至更多语言。
• 内存：MacBook Air（M2/M3）型号的起步内存已翻倍至16GB。

价格与上市信息

• 预售日期：2024年10月30日。
• 正式发售：2024年11月8日。
• 起售价：
  • 14英寸MacBook Pro (M4): $1,599
  • 14英寸MacBook Pro (M4 Pro): $1,999
  • 16英寸MacBook Pro (M4 Pro/Max): $2,499
• 颜色：深空银和银色。
• 环保：机身采用100%再生铝金属，包装已完全转向纤维材料。

Dropbox宣布将全球员工人数削减约20%，涉及528名员工。CEO Drew Houston表示，此举是经过深思熟虑的决定，并承担全部责任。他提到公司正处于转型期，核心文件同步服务（FSS）业务已成熟，正在推动以新产品如Dash为代表的下一阶段增长。由于核心业务需求减弱、宏观经济环境不利，以及内部组织结构过于复杂、管理层级过多影响效率，现有的结构和投资水平已不可持续。部分业务未达客户和行业预期，需在过度投入或业绩不佳的领域做更大削减，同时打造更扁平高效的团队。

Houston指出，此次调整正值市场加速发展，与Dropbox重点押注方向一致。新产品Dash已获得客户和潜在用户积极反馈，公司拥有数百万信任用户，可顺理成章发展云内容整理业务。面对快速变化的市场和大量资金投入，公司需采取更有决心和紧迫感的措施。此次裁员和结构调整旨在巩固核心产品、加速新产品增长，公司将在未来公布2025年战略。

对受影响员工，Dropbox将提供支持，包括：

• 16周工资补偿，每服务一年额外增一周（国际员工依地区政策调整）
• 第四季度股票权利兑现
• 按业绩和职位发放一次性过渡奖金
• 医疗及家庭假期补偿，协助签证员工提供额外过渡期及移民咨询
• 美国员工可获最多六个月COBRA医疗保险，加拿大员工医疗保险延长一个月，所有员工继续可用心理健康服务
• 公司设备可归个人使用
• 免费的就业安置服务及职业指导

公司将于当天公布更多细节，并通过全员大会解答问题、讨论后续计划。Houston向所有离职员工表示感谢和歉意。

使用8K电视作为显示器

核心观点

对于以编写代码或处理电子表格为主的日常工作，8K电视可作为多显示器设置的替代方案，兼具图像质量、分辨率优势及多功能性（如4K 120Hz游戏或影视娱乐）。

主要优势

生产力工作

• 无缝多任务处理：单屏无边框设计避免了多显示器间的干扰，支持通过平铺窗口管理器（如i3、Sway、Yabai）灵活排列终端和窗口。
• 文本渲染质量：8K分辨率提供接近多个4K显示器的像素密度，文本更清晰，适合长时间编程与文字处理。当前主流电视面板采用RGB/BGR子像素结构，可通过调整字体大小或启用HiDPI缩放优化显示。
• 摄影与视频编辑：高分辨率使工具栏在小尺寸下仍保持清晰，提升编辑效率；通常支持D65-P3色域，可通过校准仪优化色彩准确性（但极端色彩敏感工作仍需专业显示器）。
• CAD工作：能够清晰显示细节复杂的线框渲染，支持多视口同时查看而不必最大化窗口。
• 游戏与媒体：支持4K 120Hz模式，输入延迟约10ms，兼容FreeSync；适合非竞技类游戏。120Hz刷新率可整除24fps/30fps内容，播放更平滑；也支持1440p内容以3:1整数比缩放，避免伪影。

成本与连接

• 价格：65英寸8K电视起价约1500-2000美元，相当于四台32英寸4K显示器的成本，且可能替代单独的娱乐电视。
• 连接性：通过HDMI 2.1（当前主流显卡支持）可实现8K 60Hz无色度子采样；旧设备可通过DP 1.4转接适配器实现。

潜在问题与注意事项

物理设置

• 需要更深的桌子（通常超过76cm）以保持舒适观看距离，建议考虑壁挂或定制大型桌面。

图像质量

• 屏幕均匀性：可能存在“脏屏效应”，对照片编辑或媒体消费可能造成干扰，可通过校准缓解（推荐查看RTINGS.com的均匀性数据）。
• 棋盘格效应：部分型号（如QN800A）在1px尺度下出现，但启用VRR（游戏模式）后完全消失，需确保在电视设置中开启。
• 显示技术：当前主流为全阵列背光IPS/VA面板，对比度优于普通IPS显示器但低于OLED；OLED 8K电视价格高昂（约3万美元），且存在烧屏风险，不适合长期静态显示任务。
• 涂层：电视多采用亮面涂层，明亮环境下可能产生反光。

软件与兼容性

• Linux系统：
  • NVIDIA显卡需驱动版本535以上（2023年5月发布）才能支持8K 60Hz，旧版本仅支持8K 30Hz；可能出现轻微撕裂。
  • AMD显卡因HDMI论坛限制，开源Linux驱动不支持HDMI 2.1，需使用DP转接适配器实现8K 60Hz。
• 电视设置：需手动启用“输入信号增强”或类似选项以支持8K 60Hz，并开启游戏模式/VRR。
• 唤醒问题：电脑休眠后电视可能无法检测信号或自动降回4K，需重新调整设置；建议禁用显示器关闭功能。
• 多设备冲突：同时连接DP设备时，BIOS等启动画面可能默认发送至DP设备，需临时断开。

设备示例

列举了包括Samsung QN800A/B/C/D系列、LG Nanocell 97/99系列、Sony Z8H/Z9G系列等现有型号，并提及部分已停产机型。不推荐Dell UP3218K（价格高、尺寸小、问题多）。

常见问题解答

• 尺寸过大：宽度相当于两台32英寸显示器，通过平铺窗口管理器合理布局可减少颈部移动；大桌子可提供足够观看距离。
• 缺乏8K内容：可切换至4K 120Hz模式，适合多数游戏和媒体；120Hz兼容24/30fps内容，播放更流畅。
• GPU性能：游戏通常运行于4K 120Hz模式；少数非图形密集型游戏（如Factorio）可能受益于8K。
• 投影仪替代：缺乏平价8K投影仪，且低像素密度不适合文本密集型工作。
• VR设备：当前VR头显（如Apple Vision Pro）像素密度仍不足以高效处理大量文本（如电子表格）。

核心事实：谷歌CEO桑达尔·皮查伊在2024年第三季度财报电话会议上透露，公司超过四分之一（>25%）的新代码由AI生成。

应用与影响：

• AI主要用于辅助编程，旨在提升工程师的生产力和效率。
• 生成的代码需由员工检查与审核。
• 此举帮助工程师“做得更多、进展更快”。

背景信息：

• 谷歌此前已推出名为 “Goose”的内部AI编程模型，该模型基于谷歌25年的工程专业知识进行训练。
• AI正在改变部分谷歌员工的工作方式。

相关反应：

• 该数据可能引发部分员工对工作岗位被替代的担忧。
• 但公司领导层此前承诺，AI目前并未取代谷歌员工的工作。

数据意义：这一高比例凸显了谷歌在AI技术应用上的显著进展及其带来的生产力提升。

对苹果公司近期AI营销广告的批评

文章作者对苹果公司近期推广“Apple Intelligence”的系列广告提出了尖锐批评，认为这些广告不仅令人尴尬，甚至带有侮辱性。

广告内容举例：

1. 一名男子使用AI功能将写给上司的邮件润色得“更专业”。
2. 一名年轻女性利用AI功能，假装记得一位熟人的名字。
3. 同一名女性在与对方当面交谈时，利用AI功能假装已经阅读并处理了对方发来的一封电子邮件。
4. 一名女性使用AI功能，就生日礼物的事情欺骗她的丈夫。

作者认为，如果这就是苹果公司眼中其AI技术的用途——帮助用户进行社交欺骗或掩饰——那么他对这种技术毫无兴趣。

对比与结论： 作者将这些广告与他前一天分享的一个视频以及Canonical公司制作的一段动画进行了对比。他认为，Canonical那段仅1分25秒的动画所讲述的故事，比苹果所有AI广告的总和都更出色。文章暗示，科技公司的营销应展现更积极、更有意义的应用场景，而非聚焦于助长不真诚的行为。

NASA于10月24日成功恢复与旅行者1号的通信，此前该航天器因故障保护系统自动关闭了一个无线电发射器。工程师正在调查具体原因，并致力于稳定这个已在星际空间运行47年的老化航天器的通信。

事件始于10月16日，飞行团队向旅行者1号发送启动加热器的指令。尽管航天器理论上应有足够电力，但该指令意外触发了故障保护系统。该系统旨在电源超负荷时自动关闭非必要设备以节能。10月18日，当深空网络无法探测到旅行者1号的信号时，团队意识到出现问题。

通信问题逐步升级：团队最初推测故障保护系统降低了X波段发射器的数据传输速率（一种低功耗模式），并于当天找到信号。但10月19日，通信完全中断。团队怀疑故障保护系统再次触发两次，关闭了常用的X波段发射器，并切换至自1981年以来未使用的S波段发射器。S波段功耗更低，但信号微弱得多，工程师此前不确定能否在如此远的距离（约150亿英里或240亿公里）探测到它，最终深空网络成功找到了信号。

由于指令与数据往返需耗时约两天（单程约23小时），团队未冒险立即重启X波段，而是在10月22日发送指令确认S波段发射器工作正常。目前团队正收集数据以查明故障原因，并计划恢复旅行者1号的正常操作。

旅行者1号和2号已飞行超过47年，是唯二在星际空间运行的航天器。其老化状态导致技术问题的频率和复杂性增加，为任务工程团队带来持续挑战。

Unix核心工具的Haskell实现

项目目标

该项目使用Haskell重新实现了Unix核心工具，主要目标包括：

• 地道的Haskell实现：遵循Haskell的编码风格与惯用法。
• 快速与懒IO：注重性能，并采用惰性IO处理。
• 功能对齐：与BSD系统中的工具保持功能一致。
• 全面测试：所有工具均进行测试。
• 跨平台支持：可在Linux、FreeBSD、macOS和Windows上运行。

工具实现状态概览

项目对多种Unix工具进行了实现，各工具在地道性、快速性、懒IO、测试和完成度方面表现不一。表格中列出了部分工具的状态（✓表示完成，✓✓表示优秀，%表示部分完成，-表示不适用），例如：

• head、paste、rev、split、strings等工具在所有维度上均达到完成或优秀状态。
• cut、awk、ls等工具在快速性或懒IO方面部分完成或未完成。
• 多数工具（如cat、echo、mkdir）具备地道实现和测试，但可能在快速或懒IO方面有局限。

使用方式

编译与安装

• 项目编译为单个可执行文件，根据可执行文件名自动调用对应的工具。
• 安装命令：stack install --flag coreutils:release。

平台独立调用

• 在任何平台上，可通过将工具名作为第一个参数调用：utils echo hello | utils rev。
• 该方式适合测试，无需替换系统默认的shell工具。

长期使用（替换系统工具）

• Linux/FreeBSD/macOS：
  • 通过符号链接将工具暴露到$PATH目录（如~/.local/bin/），使其优先于系统工具。
  • 示例：ln -s utils cat，随后which cat将指向本地版本。
• Windows：
  • 由于符号链接可能无法改变程序名，需复制可执行文件并命名为工具名。
  • 示例：复制utils.exe为which.exe，随后which命令将使用本地版本。

注意事项

• 项目依赖Haskell IO库实现跨平台支持，部分特性（如权限、文件类型）可能被简化。
• 虽然测试较为全面，但某些非常规用法（如cat - - -）可能未被完全覆盖，项目在遵循地道Haskell实现与处理边缘情况之间寻求平衡。

Thunderbird for Android 现已可用

经过两年多的开发与等待，Thunderbird for Android 首个稳定版本现已正式发布。该项目始于接管 K-9 Mail 客户端，旨在将 Thunderbird 引入移动平台。

主要更新与资源

• 新版本详情与发布说明：详细信息与更新日志可通过官方链接获取。
• 社区支持：Thunderbird for Android 在 Mozilla 官方支持论坛（SUMO）拥有专属板块，用户可在此获得配置与使用帮助。
• 设置导入：支持从 K-9 Mail 或桌面版 Thunderbird 快速导入设置与信息。
• 系统要求：适用于 Android 5 及以上版本的移动设备。

下载渠道

可通过以下平台获取：

• Google Play Store
• F-droid
• GitHub Releases（仅提供 APK 文件，无自动更新）
• Thunderbird 官方网站（通过 Android 设备访问）

社区参与与支持

• 贡献方式：用户可通过回答支持问题、测试版本、翻译内容等方式参与社区建设。
• 捐赠支持：项目完全依赖捐赠，资金用于应用开发、性能改进及推广。
• 功能建议：用户可在 Mozilla Connect 平台提出新功能建议并参与投票，帮助规划产品路线。

致谢

开发团队感谢所有参与测试的用户及社区成员，他们的反馈对修复错误、测试功能及完善稳定版起到了关键作用。

文章标题：RIP botsin.space 摘要：

botsin.space 实例的运营者宣布将关闭该 Mastodon 实例。自 2017 年 4 月启动以来，该实例以其简化的机器人（bot）创建流程而闻名，吸引了众多艺术家、开发者和学习者。尽管活跃账户数量只有几千，但用户共发布了约 3200 万条状态文，产生了独特的使用模式和管理挑战。

关闭计划与原因：

1. 立即停止新用户注册。
2. 计划于 2023 年 12 月 15 日后将站点切换至只读模式。
3. 将尽可能帮助用户迁移账户或生成数据存档，并至少将只读模式维持到 2025 年 3 月。

关闭的主要原因包括：

• 成本与资源压力： 随着数据量增长（数据库已达 191GB），数据库存储和文件带宽（目前月度账单的主要开销）的成本持续上升。运营者担忧被网络爬虫滥用导致费用激增。
• 技术维护困难： botsin.space 的使用模式与主流实例（如 mastodon.social）差异很大，导致 Mastodon 代码库对其性能优化不足。近期一次升级引发了严重的性能下降，解决需要投入大量硬件资金。
• 不可持续性： 尽管通过 Patreon 和 PayPal 接受捐赠，但支出一直超过捐款。运营者认为，与其寻求更多捐款来维持一个“非主流”的实例，不如鼓励用户转向支持更需要资源、以社区为导向的其他实例。

运营者对一直以来支持该实例的捐款者、用户以及社区成员表达了感谢，并呼吁大家寻找并支持其他有活力的社区实例。用户如有问题，可通过 @cass@muffin.industries 联系。

AI火焰图：AI性能分析的新工具

核心概念与目标：AI火焰图（AI Flame Graphs）是英特尔基于CPU火焰图开发的新型可视化分析工具，旨在降低AI成本、减少资源消耗。它通过展示AI加速器或GPU的硬件剖析数据及完整软件栈，帮助开发者快速定位性能瓶颈。若能实现AI资源消耗减半，预计到2030年可大幅降低电力使用。

工作原理与特点：

• 可视化形式：图中绿色帧代表AI/GPU加速器上运行的实际指令，青色帧显示这些函数的源代码，红、黄、橙色帧表示启动这些程序的CPU代码路径。X轴与成本成正比，最宽的矩形代表主要优化目标。
• 技术实现：原型基于英特尔EU停顿分析（硬件剖析）和eBPF（软件插桩）构建，设计追求低开销、易用且对生产环境安全，可随时对现有AI工作负载生成火焰图，无需重启。
• 关键优势：不同于以往仅跟踪CPU栈或使用高开销二进制插桩的AI分析器，该工具提供类似CPU火焰图的体验：易于使用、开销极低、生产安全、全面显示。

开发历程与团队：这是英特尔内部为期一年的项目。团队成员包括Ben Olson（eBPF性能工具和内存管理专家）、Brandon Kammerdiener（eBPF和内存内部经验）及新加入的Gabriel Muñoz。尽管早期可使用Intel GTPin构建更高开销版本，但团队选择了更困难但更优的方案以确保广泛采用。

火焰图基础：火焰图是作者于2011年发明的采样代码栈轨迹可视化方法，已成为CPU剖析的标准，帮助开发者快速发现性能改进点。它在全球被广泛采用，是众多创业公司和性能分析产品的基础。

AI性能分析的挑战：CPU指令剖析在标准文件格式（如ELF）下相对简单，但AI工作负载面临独特难题：

• GPU/AI加速器程序可能不存在于文件系统或主内存中，甚至缺乏类似/proc的进程表示。
• 运行时、框架、用户态驱动等层次复杂，需要针对性调整才能正确获取CPU栈和符号。
• 工具成熟度低，类似操作系统风格的GPU/AI调试仅约两年历史。

示例与发现：

1. SYCL矩阵乘法微基准测试：火焰图显示最慢的未优化实现multiply_basic()占72%的停顿采样，而逐步优化的版本占比递减。
2. PyTorch支持：尽管最初面临Python栈遍历的挑战，团队已实现首个PyTorch AI火焰图，可追踪从Python源码（粉色帧）到GPU内核执行的完整链路。
3. 搜索功能：内置搜索（如搜索“sbid”）可快速计算特定术语在栈中的出现比例，辅助性能优化优先级排序。

当前状态与展望：

• 可用性：首先在英特尔Tiber AI Cloud上作为预览版提供，支持英特尔数据中心GPU Max系列。
• 局限性：对某些工作负载（如PyTorch）设置可能耗时较长且开销中等，需调整依赖项（如启用帧指针）。团队正推动上游更改以简化未来使用。
• 愿景：期望像eBPF一样最终实现“开箱即用”，并支持基于定时器的采样以提供更全面视图。长期来看，AI火焰图可能成为开发者的日常工具，并推动AI自动调优等应用。

意义与影响：性能改进即使是百分之几，也能在AI数据中心规模上产生巨大的电力、水资源和成本节约。英特尔强调工具必须易用、低开销且全面，以避免因工具不佳而阻碍潜在性能提升的发现。

自动电饭煲的发明与传播

发明背景与早期失败
在1955年自动电饭煲发明前，煮米饭对许多人而言是一项繁琐且易失败的家务。早期（1920年代起）松下、三菱和索尼等公司尝试将电热丝置于木桶或铝锅中，但这些电饭煲无法在米饭煮好时自动断电，仍需人工看管，未能真正节省时间，因此销量惨淡。

关键人物与创新突破
东芝公司开发部主管山田省吾在推广洗衣机时发现，日本女性最耗时的家务并非洗衣而是煮饭。传统方法需每日凌晨生火并照看，稍有不慎便会被视为“失败的主妇”。山田推动东芝研发电饭煲，并找到濒临破产的小型热水器工厂主南义忠合作。南本人不谙米饭烹饪细节，其妻子文子（一位六个孩子的母亲）耗时五年反复试验，记录水米比例、温度与时间，最终发现：将水和米煮沸后持续加热20分钟即可获得稳定优质米饭。

技术原理与设计挑战
东芝工程师提出“双层锅”设计：外层锅中的水蒸发会导致温度上升，通过双金属开关在超过100°C时自动断电。外层一锅水蒸发恰好需20分钟，此原理沿用至今。为解决低温环境下铝玻璃原型机保温不足的问题，文子在极端气候中测试，最终借鉴北海道保温锅灵感，采用三层铁质外壳提升保温性。

市场推广与销售策略
1955年12月10日，东芝自动电饭煲上市，售价约当时月工资的三分之一。山田通过现场烹饪“炊き込みご飯”（一种易烧焦的调味米饭料理）展示其便利性，并联合电力公司分销——当时日本电力过剩，此举既促进销量又提升用电需求。一年内月销量突破20万台，挽救了南的工厂。

全球化与本地化适应
自动电饭煲从日本传入中国香港，再扩至全球。不同地区因米饭品种和烹饪偏好产生多样化需求：如中国用户要求玻璃盖以便观察添加香肠的时机；伊朗需要锅底脆饭功能；泰国增设面条烹饪模式；现代机型还可煮粥、制燕麦片等。但早期韩国厂商曾简单模仿日本设计，未结合本土需求创新。

影响与现状
自动电饭煲通过亚洲侨民传遍世界，甚至在美国南部等传统水稻产区普及。其设计核心——通过自动化技术解决家庭劳务负担——体现了技术创新如何回应日常生活需求，并持续演化适应多元文化场景。

推动音频生成前沿技术

谷歌一直在推动音频生成技术的前沿，致力于通过开发能够从文本、节奏控制、特定声音等多种输入中生成高质量、自然语音的模型，以解锁更丰富、更具吸引力的数字体验。这项技术已应用于多个谷歌产品和实验，包括Gemini Live、Project Astra、Journey Voices以及YouTube的自动配音功能，帮助人们与更自然、更具对话性和直觉的数字助理及AI工具进行交互。

最近，谷歌与合作伙伴共同开发了两项能生成长篇多说话人对话的新功能，旨在使复杂内容更易于访问：

• NotebookLM Audio Overviews：将上传的文档转化为生动的对话，由两位AI主持人进行总结和讨论。
• Illuminate：为研究论文生成正式的AI讨论，以帮助使知识更易于理解和消化。

关键技术基础

• SoundStream：一种神经音频编解码器，能在不损害质量的前提下高效压缩和解压缩音频输入。它将音频映射到声学令牌，这些令牌捕获了重建音频所需的所有信息（如韵律和音色）。
• AudioLM：将音频生成视为语言建模任务，以生成SoundStream等编解码器的声学令牌。这种框架对音频类型不做假设，能灵活处理各种声音，无需调整架构，非常适合建模多说话人对话。

基于以上研究，谷歌最新的语音生成技术能够在给定对话脚本和说话人转换标记时，在单个TPU v5e芯片上，于3秒内一次性生成长达2分钟的对话，且自然度、说话人一致性和声学质量均有提升。这意味着其生成音频的速度比实时速度快40倍以上。

模型扩展与优化

• 数据与模型容量：将单说话人生成模型扩展到多说话人模型，主要依靠增加数据和模型容量。
• 新型语音编解码器：开发了一种更高效的语音编解码器，能以低至每秒600比特的速度将音频压缩成令牌序列，同时保持输出质量。令牌具有分层结构，按时间帧分组，首尾令牌分别捕获语音、韵律信息和精细声学细节。
• 专用Transformer架构：为建模生成2分钟对话所需的5000多个令牌的长序列，开发了专门的Transformer架构，能够高效处理分层信息。该架构能在单一自回归推理过程中高效生成对应的声学令牌，随后通过编解码器解码回音频波形。
• 训练方法：模型在数十万小时的语音数据上进行预训练，然后在包含高质量声学数据和精确说话人标注（来自配音演员的无脚本对话，包含真实对话中的犹豫语）的较小数据集上进行微调。这教会了模型在生成对话中可靠地切换说话人，并输出具有真实停顿、语调和时间的录音室级音质。

负责任部署与未来展望

• SynthID水印技术：遵循AI原则，谷歌正将SynthID水印技术整合到这些模型生成的非瞬态AI音频内容中，以防范潜在滥用。
• 未来方向：当前研究重点包括提高模型的流畅度、声学质量，并为韵律等特征添加更细粒度的控制，同时探索如何将这些进展与视频等其他模态相结合。先进的语音生成技术具有广阔的应用前景，尤其是在与Gemini系列模型结合时，有望从增强学习体验到使内容更具普遍可访问性等多个方面继续突破语音技术的边界。

美国环境保护署（EPA）基于保护孕妇及其胎儿健康的目的，于本周二宣布禁用一种用于农场、高尔夫球场及运动场的除草剂——二甲基四氯对苯二甲酸酯（商品名为DCPA或Dacthal）。该决定源于多年累积的科学证据，表明该化学物质对胎儿具有不可逆的健康风险。

EPA指出，“有力的研究”证实了DCPA的“甲状腺毒性”。孕妇若暴露于该农药，可能导致胎儿甲状腺激素水平改变，进而与低出生体重、脑发育受损、智商下降及运动技能受损等终身健康问题相关，部分伤害可能无法逆转。DCPA此前主要用于西兰花、抱子甘蓝、卷心菜和洋葱等作物的杂草防治。

此次全面禁用之前，EPA已采取一系列限制措施。今年4月，该机构罕见发布警告，指出DCPA对农场工人等暴露人群构成“严重、永久且不可逆的健康风险”。8月，EPA进一步实施“紧急暂停”，这是近40年来首次采取此类紧急行动。此后，DCPA在美国的唯一生产商AMVAC化学公司致函EPA，表示自愿取消含有该成分的农药产品注册，并将同步取消所有国际注册。

最终的取消令禁止任何人在美国境内分销、销售或使用任何含有DCPA的农药产品，并禁止使用现有库存。

十八年来，curl项目的libcurl库严格遵守ABI（应用程序二进制接口）稳定性承诺。这一决策源于2006年10月30日发布的curl 7.16.0版本，该版本因移除部分FTP功能并导致SONAME编号从3增至4，破坏了ABI兼容性。尽管受影响用户不多，但此次变更引发了大量用户抱怨，甚至Debian项目自行修改了SONAME编号。这次经历促使项目团队将ABI兼容性提升为最高优先级原则。

自那以后，libcurl再未主动破坏ABI。这意味着应用程序可以安全、无缝地升级到最新版本的libcurl，而无需担心二进制兼容性问题。这一原则虽带来长期维护挑战（例如无法删除旧功能或重命名选项），但通过严格的代码审查和全面的测试得以实现。项目有时采用“废弃”策略替代直接删除功能（如HTTP/1.1流水线和NPN支持），用户仍可设置相关选项，但现代版本不会实际执行该功能。

维护ABI稳定性的核心理念是：“如果无人能察觉变化，则不属于ABI破坏。”这虽难以精确预测，但项目凭借手动代码审查和测试体系，成功坚持了十八年。尽管未来可能存在无法预见的极端情况迫使项目打破承诺，但目前无已知障碍，ABI稳定性将继续作为libcurl的基石属性。

Wasmer 5.0 发布公告摘要

Wasmer 5.0 正式发布，标志着 WebAssembly 成为通用软件执行工具的重要里程碑。本次更新带来了多项核心新功能、性能提升与架构优化。

主要新特性

1. 新增实验性后端支持

基于社区投票（V8 获 56% 支持率），Wasmer 5.0 通过 Wasm-C-API 集成了以下新后端：

• V8：支持在 iOS/Android 上运行，未来将提供通过 V8 调试器和 Chrome DevTools 的调试体验，并支持 WebAssembly 异常处理和垃圾回收。
• Wasmi：纯 Rust 的 WebAssembly 解释器，适用于 nostd 环境或区块链场景。
• WAMR（WebAssembly Micro Runtime）：适合 iOS 平台。

至此，Wasmer 支持的后端包括：

• 原生后端：Singlepass（区块链适用）、Cranelift（开发适用）、LLVM（生产适用）
• 浏览器：通过浏览器内置 Wasm 引擎（见 wasmer-js）
• JavaScriptCore：适用于 macOS 的轻量高性能运行时
• V8、Wasmi、WAMR：新增实验性支持

2. 全面的 iOS 支持

Wasmer 5.0 首次通过 WAMR、Wasmi 和 V8 绑定实现了完整的 iOS 支持。开发者无需修改现有代码，即可在 iOS 设备上运行 WebAssembly 模块。此项工作得益于与 Holochain 的合作。

3. 更精简的代码库

为提升开发效率，对代码库进行了精简：

• 移除 Emscripten 绑定：因 Emscripten 生成的代码已普遍使用 WASI 系统调用，且 WASIX 弥补了剩余功能（如线程、fork 等）。
• 清理依赖：移除了长期未维护或已被更新、更安全的 crate 替代的依赖。
• 总计删除约 20,000 行代码。

4. 性能增强

• 模块反序列化速度提升高达 50%：得益于零拷贝反序列化库 rkyv 的更新。
• 编译器运行时性能提升：LLVM 和 Cranelift 后端在 Wasmer 5.0 中比 4.4.0 版本快约 8%（基于 CoreMark 基准测试）。

5. 编译器升级

• 集成最新 Cranelift，显著提升运行时速度。
• 升级至 LLVM 18，获得最新优化，提升兼容性与性能。
• 新增实验性的 LoongArch64 支持。

基准测试

团队基于 Wasmi 的基准测试套件，对各后端在不同场景下的性能进行了全面测试，结果显示新后端与优化后的编译器均带来了明显的性能改进。

如何开始

1. 从官网下载 Wasmer 5.0。
2. 升级现有项目以使用新功能。
3. 查阅更新后的文档。
4. 加入 Discord 社区交流。

未来展望

Wasmer 5.0 通过 iOS 支持、可插拔后端架构和性能增强，为开发者在 WebAssembly 生态中构建应用提供了更多可能性。

相关链接

• 官网：wasmer.io
• GitHub：github.com/wasmerio/wasmer
• Twitter：@wasmerio
• Discord 社区：欢迎加入

文章摘要：《民主化出版》

本文详细介绍了开源发布平台Ghost的创立理念、组织结构、商业模式及其未来治理愿景。

核心理念与起源

• 背景：创始人John O'Nolan曾参与WordPress核心开发，但对当时生态中的办公室政治、利益冲突以及产品日益臃肿感到失望。他认为WordPress并未真正实现“民主化出版”的承诺。
• 创立理念：2012年，John提出Ghost的核心构想，旨在创建一个专注于出版工作流、集成核心功能、采用简单MIT许可证、由独立非营利组织运营、并拥有可持续商业模式（通过官方托管服务）的开源平台。
• 启动与发展：Ghost于2013年通过Kickstarter众筹成功启动（筹集35万美元），同年推出产品和托管平台，并在11个月内实现盈利，此后持续稳定增长。目前拥有30多名全职员工，年收入约750万美元。

组织结构与商业模式

• 非营利结构：Ghost由一个无所有者（包括创始人）的非营利基金会运营。任何盈利只能再投资于项目，不能分配给个人。这种结构旨在确保组织服务于公共社区利益，避免因追逐利润而损害产品或社区，从而建立长期信任和独立性。
• 商业模式：通过官方托管服务Ghost(Pro)的收入来资助开源产品的开发。使用官方托管并非强制，但它是项目的主要资金来源，形成了开源产品与商业服务之间的良性循环。

治理演变与未来计划

• 当前治理：初期由两位创始人组成的理事会管理，这有助于快速决策和稳定发展。
• 未来愿景：
  1. 扩大理事会：当团队规模接近50人时（计划在几年内），将扩大理事会，纳入更多来自开源、出版、新闻和技术领域的代表，甚至设置由社区选举产生的席位，以实现更广泛和代表性的治理。
  2. 去中心化控制：旨在防止任何个人或小团体过度影响项目方向，降低“巴士因子”，确保项目超越创始人而长久延续。
  3. 探索会员制：考虑建立基金会正式会员制度（个人与公司），赋予会员投票权等权益，邀请生态系统参与者共同塑造未来。
  4. 增强透明度：将继续公开收入数据和运营统计，并进一步开放决策过程。
• 生态系统发展：Ghost的核心团队将保持小规模（约50人），旨在培育一个由托管商、开发者、代理商和合作伙伴组成的广阔生态系统。团队的角色是支持整个生态系统的繁荣，而非试图垄断所有价值。

结论

Ghost的愿景不仅在于民主化出版技术，也在于民主化管理该技术的治理结构。通过坚持非营利模式、限制自身规模、并计划将治理权逐步移交至更广泛的社区代表，Ghost致力于构建一个持久、独立且由社区驱动的开源未来。

博士生意外发现墨西哥丛林中的失落玛雅城市

2024年10月29日

美国杜兰大学博士生卢克·奥尔德-托马斯在浏览互联网数据时，偶然发现了一个由墨西哥环境监测组织进行的激光雷达调查数据。当他用考古方法处理这些数据后，揭示了墨西哥坎佩切州一个被丛林覆盖的巨大玛雅城市。

发现过程

• 博士生在互联网搜索中发现激光雷达（Lidar）数据，该技术通过飞机发射激光脉冲并绘制地面物体地图。
• 经过考古分析，数据中显示出一个此前未知的古代城市，命名为瓦莱里亚纳（Valeriana），以附近泻湖命名。

城市特征

• 位置与规模：位于墨西哥东南部坎佩切州，面积约16.6平方公里，包含两个主要中心，大型建筑相距约2公里。
• 建筑结构：发现金字塔、寺庙广场、连接各区域的道路、圆形剧场、体育场馆（用于古老球类游戏）以及水库。
• 人口估计：在750年至850年间的高峰期，可能有3万至5万居民，超过该地区现今人口。
• 密度排名：在建筑密度上仅次于卡拉克穆尔（Calakmul），后者被认为是古代拉丁美洲最大的玛雅遗址。

意义与背景

• 这一发现挑战了西方关于热带地区是“文明死亡之地”的观点，表明该地区曾有丰富复杂的文化。
• 城市“隐藏在视线中”，距离一条主要道路仅15分钟步行距离，但此前无人探索过。
• 研究者表示，遗址支持玛雅人曾居住在复杂城市而非孤立村庄的观点，展示了密集的人口分布。

衰落原因

• 主要因素可能包括气候变化，干旱条件导致人口密集的系统崩溃。
• 其他因素包括战争以及16世纪西班牙征服对该地区的冲击。

技术应用与未来展望

• 激光雷达技术革命性地改变了植被覆盖区域的考古勘测，效率远高于传统方法；过去十年在中美洲的测绘面积相当于考古学家一个世纪的工作量。
• 该技术可能揭示更多未知遗址，但数量众多，无法全部挖掘。研究者表示未来可能访问瓦莱里亚纳，但未确认是否会开展进一步项目。

大语言模型内部幻觉表示研究：LLM知道得比表现出来的更多

研究背景

大语言模型（LLMs）常产生错误输出，包括事实不准确、偏见和推理失败，统称为“幻觉”。近期研究表明，LLMs的内部状态编码了其输出真实性的信息，并可用于检测错误。

主要研究发现

1. 真实性信息的集中分布

• 真实性信息集中在特定标记（tokens）中
• 利用这一特性可显著提升错误检测性能
• 研究表明LLMs内部对真实性的编码比以往认识更为丰富

2. 真实性编码的非普适性

• 错误检测器无法在不同数据集间泛化
• 这表明真实性编码并非普适，而是多方面的
• 推翻了先前关于真实性编码普适性的观点

3. 预测错误类型的能力

• 内部表示可用于预测模型可能犯的错误类型
• 这有助于开发针对性的缓解策略
• 为制定模型错误修复方案提供了新思路

4. 内部编码与外部行为的差异

• 发现LLMs内部编码与外部行为存在不一致
• 模型可能编码了正确答案，却始终生成错误答案
• 揭示了模型内部状态与输出行为之间的复杂关系

研究意义

• 从模型内部视角深化了对LLMs错误的理解
• 为未来改进错误分析和缓解研究提供了指导
• 揭示了LLMs内部表征与输出行为之间的复杂关系

研究背景信息

• 最新版本更新于2025年5月18日
• 研究团队持续对论文进行修订完善

松香烤土豆：一项几乎被遗忘的烹饪艺术

松香是松节油生产过程中的副产品，传统上用于制作小提琴漆、油漆稀释剂、药膏（如维克斯）及家用清洁剂（如Pine Sol）。它甚至曾被用作治疗钩虫病的偏方（尽管疗效存疑）。然而，松香在烹饪界真正闻名，是因为它能将土豆烤至完美。

松香烤土豆起源于美国北卡罗来纳州和乔治亚州南部的松林，与早期松节油产业密切相关。被奴役的工人在松树上割出形似猫或鲶鱼胡须的伤口，在下方悬挂容器收集松脂。松脂随后被送入蒸馏器（与制造私酒的设备类似）加工，蒸馏后产生的松香废液则流入大桶。这种烤土豆的做法正是诞生于这些简陋的加工场所。

如今，松香烤土豆在特定活动中（如乔治亚州的Catface松节油节）仍可见到。烹饪时需特别注意：虽然亚马逊上有松香土豆套装出售，内含大汤锅和固体松香，但切勿在室内灶台上操作。建议使用金属三脚架悬挂锅具于户外明火上进行烹煮。所用锅具和器具（如捞勺）应专用于松香烹饪，不可与其他烹饪工具混用。松香可重复使用，烹饪后待其冷却硬化即可保存。

这一做法与美国南方“贫困食物”传统紧密相关。作者Clarissa Clifton（《一灶一锅：为食物与历史之爱》的作者）致力于研究内战前后占南方人口90%的普通民众所食用的食物。松香烤土豆正是其中体现创新烹饪方式的代表，展现了在资源有限的条件下，如何利用松林中的天然材料制作出美味食物。如今，一些团体正尝试复兴乔治亚州的松节油产业，使这项几乎被遗忘的烹饪技艺得以延续。

文章摘要：《爱好CAD、CNC加工与树脂浇注 (2015)》

本文是一份面向DIY爱好者和机器人制作者的详细指南，旨在介绍如何使用台式CNC铣床和现代聚合物材料实现高质量的家庭制造。尽管文章撰写于2015年，但其核心内容在CNC加工和树脂浇注领域仍具参考价值。

核心价值与目的

文章指出，3D打印虽然便捷，但在精度、材料选择、单件成本和表面质量上通常不如CNC加工。CNC铣床能以低成本（每件零件约25美分）使用多种材料（塑料、木材、金属等）制造高精度、表面光滑的零件。而树脂浇注作为一种高效的复制工艺，允许使用软橡胶、金属或特殊树脂等难以机加工的材料，并能轻松复制零件、定制外观、节省材料和时间。

CNC铣床选购要点

选择台式CNC铣床时应关注：

1. 轴数：三轴通常足够，四轴适用于螺旋齿轮或珠宝等复杂工件。
2. 行程范围：根据预期工件尺寸选择，X-Y平面约15x10厘米起，Z轴通常不超过8厘米。
3. 主轴质量：关键参数是总指示跳动（TIR），应低于0.01毫米，最好在2微米以内。避免使用改装工具作为主轴的机器。
4. 运动精度：关注重复定位精度（进给量应低于0.02毫米）和机械分辨率（最好优于5微米）。
5. 切削速度与进给：最大转速（建议6000-20000 RPM）与最大进给速度的比值应在0.4-0.8之间，以实现高效加工。
6. 刀具传感器与夹持系统：带有工具高度传感器的机床更佳；ER系列等夹头系统能平衡精度与易用性。

刀具与CAM软件

• 刀具：建议使用硬质合金立铣刀，并关注涂层（如TiAlN）、几何形状（平头、球头）、直径公差（注意e8等非对称公差）和柄长。
• CAM软件：关键功能包括支持水线切削和投影切削等3D铣削策略、基于曲线的区域选择、切削优化以及刀路控制。推荐如MeshCAM、DeskProto等性价比较高的软件。

CAD建模基础

指南强调应从2D绘图和样条曲线编辑学起，掌握挤压、旋转、扫掠等生成3D曲面的操作。良好的建模习惯包括：启用对象捕捉、手动输入坐标、避免近似操作，并合理使用图层、分组等进行对象管理。

树脂浇注详解

• 材料选择：
  • 主模型材料：推荐使用中等密度可加工板（如RenShape 460），成本低、加工性好。
  • 硅胶模具：首选铂金催化硅胶（RTV-2），如QM 262或P-592。关注硬度（建议60 Shore A以上）、撕裂强度、粘度和固化时间。
  • 浇注树脂：聚氨酯树脂性能优于环氧或聚酯树脂。推荐Innovative Polymers的IE-3075（全能型）或TP-4052（高抗冲击）。关键性能参数包括抗弯强度、模量、冲击强度和收缩率。
• 工艺设备：真空脱泡装置（真空泵和腔室）是必需品，用于去除混合时产生的气泡。
• 高级技巧：包括使用填料（如玻璃微珠、短玻璃纤维）减少收缩或增强性能、通过预混树脂降低反应放热、以及使用化学催化剂（如铋新癸酸酯）加速或减缓固化速度。

实用零件设计技巧

• 刚度管理：利用肋板和翻边结构来增强薄壁零件的刚性，其效果与厚度的立方成正比。
• 应力分布：在承受负载的尖角处增加圆角或加强筋，以避免应力集中。
• 配合公差：为过盈配合、间隙配合和自攻螺钉孔提供具体的尺寸建议（如间隙约0.02毫米）。

齿轮设计

文章提供了详细的渐开线直齿圆柱齿轮设计方法，包括齿数、齿宽、压力角、齿顶高等参数的选择。还简要介绍了锥齿轮、蜗轮蜗杆和斜齿轮的构造，以及行星齿轮箱和摆线针轮减速器等传动系统的原理。

机器人组件与安全

• 组件：列出了常用机械零件（螺丝、销钉、弹簧、轴承）、电子器件（电机、传感器、微控制器）和电源的采购建议。
• 安全：这是贯穿全文的重要章节。强调操作CNC铣床时需佩戴护目镜并远离旋转部件；处理聚氨酯树脂时需注意异氰酸酯的刺激性，避免吸入，并注意某些树脂中可能含有的有毒催化剂（如有机汞/锡化合物）；所有化学品应妥善储存，并远离儿童。

结论

本指南为家庭制造爱好者提供了一套从设备选购、软件使用、材料科学到设计实践和安全操作的完整知识体系，帮助他们在可控成本下创造出功能强大的精密零件和机器人组件。

马丁·加德纳在《科学美国人》杂志的“数学游戏”专栏吸引了数代读者，尽管他没有接受过正规数学训练，却凭借毕生热情成为将数学、科学和谜题介绍给大众的杰出传播者。他以儿童魔术师身份起步，出版生涯长达80年，著书超百本，擅长以通俗方式阐释复杂数学概念和悖论。

加德纳的专栏影响力深远，许多读者因他的文章投身数学、逻辑和计算机科学领域。他不仅是谜题设计者，更是重要的知识中介——数学家们通过他分享前沿发现，如分形、彭罗斯铺砌、RSA加密和“生命游戏”，使他成为互联网时代前的“思想交流站”。

为纪念加德纳，数学家科尔姆·马尔卡希等人成立了“加德纳聚会”基金会，每两年举办一次跨学科会议，汇集数学家、魔术师、谜题爱好者和艺术家。会议包含快速演讲、雕塑制作和创意活动，参与者常带来突破性的三维谜题，如乔治·哈特设计的可扭曲组装金字塔模型，体现数学与艺术的深度融合。

马尔卡希指出，数学与谜题的核心关联在于创造性思维：数学突破往往依赖非常规的想象力，业余爱好者如玛乔丽·赖斯曾解决专业数学家未突破的问题，而近年发现的“爱因斯坦单砖”也颠覆了学术认知。加德纳的遗产正在以更包容的方式延续，吸引更广泛的多元群体参与探索数学之美。

根据提供的文章内容，实际内容与标题“Boston Dynamics robot Atlas goes hands on [video]”不符。内容部分显示的是YouTube网站页脚的通用信息，包括版权声明、相关链接（如简介、新闻中心、版权、联系我们、创作者、广告、开发人员、条款、隐私、政策及安全等）以及关于YouTube运作方式的说明。文中未涉及Boston Dynamics、Atlas机器人或任何相关视频的具体技术细节或功能描述。因此，无法基于给定内容对标题所述主题进行实质性总结。

10亿行编码挑战：引爆Java社区

概述与起源

• 发起者：Gunnar Morling，Decodable公司的软件工程师。
• 时间：2024年1月1日发起，持续整个一月。
• 形式：一个个人的、社区驱动的编程挑战，旨在学习新版Java的特性并打破“Java缓慢”的刻板印象。
• 影响：迅速引发关注，在InfoQ成为上半年最受欢迎的文章，并有知名YouTuber参与宣传。参与者提交实现，作者颁发证书和奖品。

挑战任务与规则

• 核心任务：处理一个约13GB、包含10亿行气象站温度测量数据的文件。每行格式为站名;温度值。需要为每个气象站计算最低温度、最高温度和平均温度。
• 主要规则：
  1. 仅限Java：可使用任何Java版本、发行版（如GraalVM）和预览特性。
  2. 无外部依赖：不允许引入第三方库。
  3. 禁止缓存：结果不能在多次运行间缓存。
  4. 允许借鉴：鼓励从其他实现中获取灵感，但不得直接提交他人代码。
  5. 评估方式：在指定服务器上运行5次，去除最快和最慢结果，取剩余三次的平均值。

关键优化技术

挑战的核心在于探索极致性能优化，参与者主要从以下几个方面入手：

1. 并行化：

   • 基础并行：最简单的优化是使用parallel()流，可将时间从数分钟缩短至约71秒。
   • 并行I/O：使用Java的新Foreign Function & Memory API进行内存映射，将文件分块（理想大小为2MB）并由多个线程并行处理，充分利用所有CPU核心。

2. 高效解析：

   • 手动解析：用状态机逐字符解析，替代耗时的正则分割。
   • 整数运算：利用数据特点（温度值总是一位小数），将浮点数转换为整数（如乘100）进行计算，大幅提升效率。

3. 指令级并行：

   • 向量API (SIMD)：利用CPU的SIMD指令，一次处理多个数据字节。
   • 寄存器内并行 (SWAR)：通过位运算，在单个长整型变量上模拟并行操作。
   • 无分支编程：避免条件判断，利于CPU流水线和分支预测。

4. 自定义数据结构：

   • 专用哈希映射：摒弃通用HashMap，实现基于线性探测的开放寻址数组，并为特定数据集优化哈希函数（但需处理碰撞问题）。

5. JVM与编译器优化：

   • GraalVM：既用作即时编译器（JIT）替代C2，也用作提前编译器（AOT）生成原生镜像，提升启动速度和峰值性能。
   • Epsilon垃圾收集器：通过完全避免对象分配，实现无垃圾收集开销。
   • 循环展开与指令并行：将循环体重复多次，帮助CPU编译器发现并行机会。

过程波折与社区协作

• 服务器迁移事件：评估初期，虚拟服务器被意外迁移，导致性能数据不可比。问题促使作者租用专属服务器，并得到社区成员帮助进行系统配置（如关闭超线程、Turbo Boost）。
• 社区驱动：挑战自发形成了完整的工具链和规则：
  • 测试套件 (TCK)：社区构建了测试集以确保实现的正确性。
  • 评估自动化：志愿者编写了健壮的Shell脚本，自动化运行和评估流程。
  • 规则细化：针对参与者关于数据细节的询问，逐步明确了规则。

最终结果与启示

• 惊人性能：
  • 在8核评估环境下，最快实现处理10亿行仅需1.5秒。
  • 在32核服务器上，进一步缩短至300毫秒。
• 跨语言对比：虽以Java为中心，但其他语言和平台（.NET、Python、Rust、COBOL、数据库）也有参与，Java性能位居前列。
• 关键启示：
  1. Java性能已极强：通过现代Java特性和深度优化，性能远超预期。
  2. 优化需权衡：从“可读可维护”的优化（如并行流、整数运算）到“极度黑魔法”的优化（SIMD、无分支编程），需要根据场景（如企业应用 vs 性能挑战）权衡投入产出。
  3. 社区力量巨大：一个简单的想法能激发全球开发者协作、学习和创造，甚至影响职业生涯（如参与者被GraalVM团队录用）。
  4. 硬件特定性：极致优化高度依赖特定CPU架构和特性，本地优化未必适用于评估环境。

基于WebAssembly的浏览器端模型预测控制

本文介绍了作者通过在浏览器中实现一个倒立摆系统的模型预测控制（MPC）演示，来学习轨迹优化和MPC的实践经历。该项目使用C++编写核心算法，并通过Emscripten编译为WebAssembly（WASM）以在浏览器中运行，旨在探索WebAssembly应用潜力并提供教育价值。

问题设定与系统模型

作者选择了经典的倒立摆（cart-pole）系统作为实验平台。系统状态包括滑车位置、摆角及其导数。控制目标是通过对滑车施加横向力，使摆稳定并保持在垂直位置（“摆起”后保持稳定）。运动方程通过拉格朗日力学推导，并额外考虑了库仑摩擦、气动阻力、边界弹簧以及用于模拟人为干扰的外力。

模型预测控制（MPC）问题表述

MPC通过在一个有限的时间窗口（规划时域）内，反复求解一个优化问题来确定当前的控制动作。核心思想是：基于当前状态，优化一系列未来控制输入，使系统在时域末端达到期望状态（此处为摆垂直且静止）。

文中比较了两种问题表述方法：

1. 单射击（Single Shooting）：仅将控制序列作为决策变量，通过正向积分获得系统状态。该方法可能因梯度传播过长而导致数值问题。
2. 多射击（Multiple Shooting）：将状态也作为决策变量，并在子区间边界添加连续性等式约束。虽然变量更多，但数值性能更好。作者最终采用多射击方法，并在每5-10个控制步长插入一个状态点，以平衡迭代次数和变量规模。

优化问题求解使用了一个自定义的玩具非线性优化器（mini_opt），采用序列二次规划（SQP）方法，并通过罚函数法处理等式约束。规划时域设为40个采样点（100Hz下为0.4秒），每次优化最多迭代8次。为了快速收敛，作者采用了热启动策略：将上一时间步的解平移作为当前步的初始猜测；对于第一步，则使用正弦函数作为初始猜测。

实现与部署到浏览器

该项目由两部分组成：

• 后端（C++/WASM）：仿真器和控制器使用C++实现，并通过Emscripten编译为WASM模块。优化启用-O3并去除调试符号后，WASM基础大小约为850KB。
• 前端（TypeScript）：使用HTML Canvas进行可视化和交互。

最终打包成一个约2MB的自包含JavaScript文件。性能测试表明，在Chrome浏览器中，核心更新函数平均耗时约2.5毫秒，足以支持100Hz的实时控制，用户体验流畅。

用户交互与演示功能

Web应用支持丰富的交互，便于测试和观察系统行为：

• 点击/触摸可对滑车或摆锤施加外力（作为干扰）。
• 拖动滑条可实时调整滑车的期望位置设定点。
• 可开关控制器，观察系统从闲置状态恢复。
• 可实时调整优化成本权重，观察不同目标下的系统行为（例如，忽略位置成本或角度成本）。

优化过程会预测未来状态，在前端以“幻影”滑车的形式显示。

结论与展望

作者认为构建此演示非常有趣，并指出了一些未来改进方向，如支持双摆系统、探索基于学习的稳定方法、引入更多模型误差等。该项目成功展示了在浏览器中部署高性能控制算法的可行性，并为理解MPC和轨迹优化提供了实践案例。

参考文献

文中引用了Russ Tedrake的欠驱动机器人课程笔记、Nocedal与Wright的《数值优化》教材等资源作为理论参考。

Rust 重写成功案例的经验教训

成功之处

• 增量重写：采用逐步替换策略，在持续开发新功能的同时完成了从C++到Rust的迁移，避免了维护两套代码库的麻烦。
• 代码质量提升：新Rust代码更简洁、易于理解，逻辑清晰。虽然代码行数与C++相当或略多，但安全性更高。
• 性能优化机会：重写过程提供了全局审视代码库的机会，例如将动态大小的字段改为固定大小数组，减少了堆分配。
• 清理死代码：删除了大量未使用的代码（估计占原代码库的三分之一到一半），Rust/Go等现代语言更善于标记和提示死代码。
• 内存安全：默认进行边界检查和算术溢出/下溢检查，消除了C++中常见的这类问题。
• 构建体验改善：Rust内置的测试框架更好用；跨编译相对顺畅；移除了CMake配置文件。
• 促进正确性讨论：Rust编译器强制进行的检查（如UTF-8验证）推动了代码健壮性的提升。

挑战与不足

• 仍面临未定义行为风险：
  • 大量使用unsafe块和原始指针，容易无意中引入未定义行为。
  • 在unsafe块内，编译器无法进行借用检查，需格外谨慎。作者认为在Rust中引入未定义行为甚至可能比C++更容易。
  • Miri工具的局限：Miri能检测unsafe代码中的问题，但无法运行涉及C/汇编库（如加密库）的代码。作者不得不使用Valgrind作为补充，但这只能检测部分问题。
• 内存泄漏问题：
  • 为C API提供init/release函数对时，容易遗漏release调用导致内存泄漏。
  • 虽然可以使用RAII包装或defer模式，但在处理复杂逻辑或多个资源时，defer模式与Rust借用检查器冲突，使用起来存在困难。
• 工具链限制：
  • 跨编译：当依赖库包含C/汇编代码时，cargo build --target无法开箱即用。
  • cbindgen：用于生成C头文件的工具存在诸多限制和bug，使用体验不佳。
• 语言与生态问题：
  • ABI不稳定：Rust标准库类型（如Option）没有稳定的ABI，与C/C++互操作时需要手动使用#[repr(C)]复制，产生摩擦。
  • 缺乏运行时自定义内存分配器支持：Rust只允许在编译时选择全局分配器，无法像许多C库那样在运行时提供自定义分配器。这使得实现arena分配器等内存管理策略变得不自然。
  • 复杂性高：处理FFI所需的unsafe相关概念（如UnsafeCell、MaybeUninit、Pin）和底层细节非常复杂，增加了学习曲线和开发难度，甚至导致部分团队成员不愿参与。

总结与建议

• 作者对重写结果基本满意，但某些方面令其失望，整体工作量超出预期。
• 大量FFI交互让Rust感觉像一种完全不同的语言，与C/C++模型存在诸多摩擦，许多声称已被Rust解决的问题实际上并未完全解决。
• 推荐初学者从纯Rust项目开始，远离FFI复杂性。
• 未来考虑：作者表示，如果未来需要进行类似重写，可能会强烈考虑使用Zig语言，因为其原生设计可能更好地处理与C的互操作和底层系统编程需求（如稳定的ABI、内置arena支持、更好的跨编译体验）。
• 总体评价：尽管Rust团队和工具链开发者做出了巨大努力，但在涉及大量C FFI的场景下，Rust语言和工具链仍感觉不够成熟。

标题：谨慎度调节旋钮

内容摘要：

本文通过一部独幕剧的形式，探讨了工程团队在效率与透彻性（谨慎度）之间的根本性权衡，并引入了“谨慎度调节旋钮”这一比喻概念。

核心情节与观点：

1. 冲突引入：工程经理（EM）询问技术主管（TL）团队能否在Q2末完成所有功能。TL回答取决于“谨慎度旋钮”的设置。
2. 概念解释：TL用“谨慎度旋钮”比喻团队在开发过程中，需要根据风险评估来决定投入多少精力进行测试和遵循流程的程度。团队试图平衡谨慎度与交付时间。
3. 权衡关系：TL在白板上绘制了一条指数曲线，展示了谨慎度（X轴）与预估完成时间（Y轴）的关系：
   • 当前默认谨慎度设置（如5）可在Q2末交付。
   • 若调高谨慎度（追求零事故），完成时间将指数级增长，无法按时交付。
   • 若调低谨慎度（盲目开发），虽然看似快速，但会因事故频发而消耗大量处理时间，实际未必更快。
4. 现实困境：戏剧结尾，一次事故复盘会上，来自其他团队的经理（X）再次提出“未来要更加小心”，这揭示了现实中的常见反应。
5. 核心原则（ETTO）：文末的“尾声”点明，这背后是效率-透彻性权衡（ETTO）原则。在实际工作中，团队会在感知到的风险水平下，不断做出关于测试深度、流程遵守程度的微小决策，这些决策在工期压力下逐渐累积。
6. 隐性权衡：通常，这种谨慎度的权衡是隐性做出的。如果事前要求决策者明确接受“提高谨慎度将显著延长工期”，可能会面临阻力。事故发生后归咎于“不够谨慎”则容易得多。戏剧隐喻在于，如果我们能在项目开始时就让相关方明确理解并接受这种权衡，将有助于更负责任的决策。

核心启示：“谨慎度旋钮”是一个形象比喻，强调了工程管理中一个关键但常被忽视的现实：不存在绝对的“零风险”或“零时间”方案。团队总是在风险容忍度、资源与时间之间做出动态平衡。意识到并管理好这种效率与谨慎度的显性权衡，比事故后简单要求“更小心”更有意义。

葛饰北斋（1760-1849）于七十多岁创作了举世闻名的《神奈川冲浪里》，但较少有人关注他在同一时期为《百物语》系列（约1830年）绘制的五幅幽灵版画。该系列可能原计划绘制一百幅，但仅完成了五幅，其风格与他擅长的风景画截然不同，专注于描绘复仇幽灵与食人魔怪等恐怖主题。

《百物语》系列源自日本民间传统“百物语怪谈会”——朋友们围坐分享恐怖故事，每讲完一个便吹熄一支蜡烛，在黑暗中逐渐招来幽灵。

五幅版画及其故事主题如下：

1. 《皿屋敷》：女仆阿菊因打碎名贵餐盘被主人投入井中致死，其怨灵附于井中。1795年，日本各地井中出现一种带细丝的蠕虫，被视为阿菊的化身。
2. 《笑般若》：描绘了一个由嫉妒化为角魔的“般若”与专食孩童的“山姥”结合而成的狂笑食人魔。
3. 《阿岩》：被毒药毁容后遭丈夫抛弃的妻子阿岩，在疯狂中死于剑下，其怨灵以纸灯笼等多种形态纠缠复仇。
4. 《小幡小平次》：基于真实事件，被谋杀的丈夫亡魂从蚊帐上方凝视着背叛他的妻子与奸夫。
5. 《执念》：蛇象征超越死亡的执念，缠绕着佛坛牌位；碗上的卐字符在古文化中实为吉祥符号，与恶念形成反差。

该系列将北斋的艺术视野从自然景观转向幽暗的超自然世界，展现了民间怪谈的深刻影响力与恐怖美学。

Async Rust 与 io_uring 的安全性问题

问题现象

开发者在将异步Rust服务从使用epoll的运行时（如Tokio）迁移到支持io_uring的运行时（如monoio、glommio、compio）时，发现TCP连接泄漏问题。具体表现为：当使用select!宏实现超时控制时，若在accept超时后继续执行，已提交给内核的accept系统调用可能仍在完成，导致连接丢失且未被正确处理。

核心原理

1. Future的两个基本假设：

   • Future状态仅在被轮询（poll）时改变。
   • Future可通过停止轮询隐式取消。

2. epoll的工作方式：

   • 事件通知机制，系统调用在轮询期间同步执行。
   • 取消操作只需停止轮询即可。

3. io_uring的破坏性：

   • 系统调用异步执行，内核通过共享环形缓冲区提交结果。
   • 即使停止轮询，内核仍可能随时完成操作，取消变得复杂。
   • 示例：当select!中timeout分支执行后，accept操作可能已在内核完成但被忽略，导致连接泄漏。

解决方案探讨

1. I/O安全

通过实现Drop trait，在future销毁时显式取消io_uring操作。目前需要异步运行时主动实现此修复。

2. 停止安全（Halt Safety）

更复杂的解决方案，要求正确处理已取消但已完成的操作：

• 可取消I/O：monoio提供的Canceller机制允许显式取消操作，并再次await以检查是否已完成。
• 传染性问题：由于future是递归结构，取消包含io_uring操作的future会影响内部所有相关操作。
• 线性类型需求：理想情况下应通过类型系统强制正确使用（如必须await已取消的future），但Rust目前缺乏线性类型支持。

现状与讨论

1. 语言层面支持：Rust社区已将I/O安全列为RFC目标，但尚未完全实现。

2. 安全定义差异：文章引发关于“安全”定义的讨论：

   • 是否应保持现状，不保证I/O和停止安全
   • 是否应通过语言保证I/O安全
   • 是否应同时保证停止安全

3. 相关资源：

   • Yoshua Wuyts的异步取消讨论
   • without boats的io_uring笔记
   • ihciah的异步借用分析

实践建议

目前使用io_uring时需特别注意：

• 避免直接使用简单的select!模式处理可能已提交的io_uring操作
• 优先选用提供可取消I/O支持的运行时
• 密切关注future的取消语义，确保资源正确处理
• 在关键业务逻辑中考虑回退到epoll方案

该问题揭示了异步Rust与io_uring集成时的深层次设计挑战，需要运行时、应用和语言层面的协同解决。

Signal：在线MIDI编辑器

Signal是一个基于Web技术的用户友好音乐序列器应用，旨在提供跨平台无缝体验，并在MIT许可下发布。

目标

• 跨平台兼容性：确保在各种设备和操作系统上可用。
• 简单用户界面：专注于直观、非复杂的界面，便于使用。
• MIDI兼容性：支持MIDI格式，满足广泛的音乐制作需求。

概念

Signal并非数字音频工作站（DAW）的替代品，而是补充工具。它在音乐作曲的初始阶段表现出色，允许艺术家快速高效地记录音乐想法。为了保持专注，Signal有意设置限制：

• 基本音质：优先考虑简单性而非高质量声音生产。
• 无效果器（Fx）：排除声音效果，简化创作过程。
• 轻量设计：优化资源使用，确保快速响应的用户体验。

这些限制旨在提供流线型、无干扰的环境，理想用于专注于音乐作曲核心和想法发展的艺术家。

安装说明

• 克隆仓库：通过终端运行 git clone https://github.com/ryohey/signal.git 克隆仓库。
• 安装依赖：在项目根目录运行 npm install 安装所需依赖。
• 运行应用程序：首次运行前需执行 npm run build，然后运行 npm start，应用将在 http://localhost:3000 上运行。
• 通过Docker运行：使用Docker时，无需安装npm或构建，只需安装Docker并运行 docker compose up 或 docker compose up -d，应用将在 http://localhost:3000 上可访问。

贡献

作者@ryohey欢迎任何形式的贡献，包括代码改进、错误修复或反馈。可以通过以下方式支持：

• 报告错误：使用GitHub Issues报告问题。
• 加入Discord社区：参与用户社区，互相支持、分享技巧和讨论音乐制作。
• 通过GitHub Sponsors支持：支持项目的开发，即使是最小的贡献也深表感谢。

许可

基于MIT许可。详见LICENSE文件。

经典3D游戏阴影技术

游戏中的阴影并非现实世界中简单的“光线缺失”，而是需要精心设计和工程实现，以达到性能与视觉效果的平衡。

传统阴影技术

• 2D/简单阴影：最早期的做法是绘制一个固定的2D阴影图片（如《魔法门英雄无敌》），或在角色脚下绘制一个黑色的“阴影盘”。这种方法简单高效，常被早期3D游戏使用（如《超级马里奥64》），但只能在平面上正确显示。
• 平面阴影：将阴影投射物体沿光线方向压平到一个平面（通常是地面）上进行渲染。这种方法能产生尖锐的阴影，但仅适用于平坦表面。
• 渲染纹理阴影：一种改进的平面阴影，通过从正上方渲染一个角色的黑白剪影作为纹理，然后将其应用到地面。本质上是一种“1位阴影贴图”。
• 投影纹理阴影：与渲染纹理类似，但纹理被投影到任意形状的物体表面（类似探照灯）。这种方法能产生非常清晰的阴影，但可能在垂直表面或天花板上产生不自然的效果。
• 模板阴影：基于“阴影体”概念，通过模板缓冲技术精确标记场景中被遮挡的区域。能产生极其锐利、风格化的“黑色电影”式阴影（如《毁灭战士3》），但计算开销大且不稳定，现已较少使用。
• 阴影贴图：当前的主流技术。从光源的视角渲染一张深度图（阴影贴图），在渲染主场景时比较像素深度来判断是否在阴影中。易于实现，但受限于分辨率会产生锯齿、漏光等瑕疵，需要各种优化技术（如级联阴影贴图）来改善。
• 静态光照阴影：
  • 顶点色：将光照和阴影信息直接存储在模型顶点的颜色中，适合低多边形风格（如《托尼霍克职业滑板2》）。
  • 光照贴图：将场景的静态光照和阴影烘焙到纹理上。比顶点色更精确，是许多现代游戏的基础（如《半衰期》、《使命召唤》系列），但消耗更多内存。
• 简化角色阴影：有时不渲染角色完整模型的阴影，而是使用简化的几何体（如球体、胶囊体）来投射阴影，以节省性能（如《塞尔达传说：时之笛》、《最后生还者》）。

现代应用与特殊情况

现代游戏通常结合使用多种技术，以取长补短：

• 使用级联阴影贴图处理大范围远景阴影。
• 将光照贴图与光照探针等动态光照技术结合。
• 为角色使用专用的软阴影或胶囊阴影技术。
• 采用投影纹理等特殊方法处理特定物体（如赛车游戏中的赛道阴影）。

光线追踪阴影从物理原理上模拟光线传播，理论上能实现最准确的阴影（包括软阴影和接触阴影），是终极解决方案。但实际应用中，由于性能限制仍需大量近似和降噪处理。

最后，出于性能或风格考量，一些游戏可能选择完全不计算阴影，将资源用于其他方面。

PlantStudio：一款曾被埋没的植物建模利器

本文分享了作者与一款名为PlantStudio的老牌Windows应用程序的相遇过程。该软件由Kurtz-Fernhout Software公司开发，是一款深度惊人的植物学模拟器，其核心功能是基于真实植物生长、变化、结果和开花的生命周期，创建和排列3D草本植物模型。

软件安装与使用

由于该软件最后版本发布于2002年，原为Windows 95/98/2000/NT4设计，因此需要通过特定方法在现代macOS系统上运行。作者提供了详细步骤：下载软件压缩包，使用Whisky工具创建一个模拟Windows环境的“瓶子”，将程序文件复制进去并运行即可。

启动后，软件界面图标虽未标注，但悬停提示信息极为详尽，极大地降低了学习门槛。用户可通过“File → Open”打开示例文件快速上手，或使用“Plant → Create New…”启动详尽的**10步“植物向导”**来创建自定义植物。向导中每个选项都配有详细的插图说明，使得“花序”等专业概念易于理解。

核心功能与特点

• 创建与编辑：用户可在“花园”区域对创建的植物进行缩放、旋转、姿势调整甚至年龄修改。
• 繁殖系统：可通过“Plant → Breed”功能培育植物后代，并定义后代与亲本的相似度及突变程度。
• 导出选项：支持将植物模型导出为JPG、3DS或OBJ文件，以便导入其他艺术软件（如Bryce、Photoshop）进行二次创作。其工作流程与当代景观建筑师利用3D渲染图进行展示和设计的方式非常相似。

背景与历史

该软件由拥有生物学和生态学学位的夫妇档Paul Fernhout和Cynthia Kurtz共同开发。他们的初衷是建立一个园艺模拟器，以帮助人们以更可持续的方式在自家庭院中园艺，其模拟基于美国农业部的EPIC农业模型。在开发过程中，他们发现用户对植物设计器本身的热情远超园艺模拟器，因此将其作为独立产品发布。这种产品焦点的意外转移，与《模拟城市》的诞生故事有相似之处。

不幸的是，PlantStudio于2002年停止更新，作者认为这类服务于特定创意需求的“有机”小众软件很难在市场中长期生存。文中推测，若当时它能朝《模拟城市》类游戏的方向演化，或能延续其生命。

软件的美学与启示

作者认为，PlantStudio的魅力在于其功能性驱动的设计美学。它的界面元素虽然不符合现代审美，但直观、不花哨，并配有丰富的图解和提示，使任何人都能理解其工作方式。使用它为作者提供了新的设计视角和灵感。

尽管它并非适合所有人，但作者强调，最好的事物往往如此。从首次见到截图以为是怀旧概念，到亲自体验并欣赏其深度与实用性，作者很高兴最终发现了这款被时间埋没的、真正充满创造力的工具。

SmartTube 应用摘要

重要安全公告

开发者的开发环境曾感染恶意软件，导致部分构建版本可能受影响。问题发现后，已通过全盘擦除恢复清洁环境，所有构建现在均经VirusTotal扫描，F-Droid版本发布前也会验证。公钥可能已泄露，开发者分享了新的版本和公钥下载链接，并提供了备份恢复说明。应用使用权限有限的一次性连接代码，用户如需可撤销第三方应用访问权限以增强安全。

应用概述

SmartTube 是一款免费、开源的媒体客户端，专为Android电视和电视盒子优化，允许用户在优化的电视界面中浏览和播放多种公开来源的内容。

✅ 主要特性

• 简洁无干扰的界面
• 集成SponsorBlock（跳过赞助片段）
• 可调节播放速度
• 支持8K分辨率、60fps播放及HDR
• 支持查看直播聊天
• 可自定义按钮
• 无需Google服务
• 活跃的国际社区

❌ 主要限制

• 不支持手机和平板设备
• 评论功能不稳定
• 语音搜索和投屏性能可能因设备而异，不及官方应用

设备兼容性

• 支持设备：所有Android电视和电视盒子（包括2025年10月前发布的Fire TV设备、NVIDIA Shield、带Google TV的Chromecast），甚至支持Android 4.3的旧设备。
• 不支持设备：智能手机、非Android平台（如三星Tizen、LG webOS、Apple TV）。
• 重要变更：自2025年10月起，新亚马逊Fire TV设备将运行VegaOS而非Android，SmartTube将不兼容这些新设备。

安装与更新

• 安全提示：切勿从应用商店、APK网站或博客下载，以防恶意软件。SmartTube未在任何应用商店官方发布。
• 版本：提供测试版（推荐，功能更新和错误修复更快）和稳定版。
• 安装方法（选择一种）：
  1. （最简单）在Android TV上安装“Downloader by AFTVnews”应用，输入 kutt.to/stn_beta 或 kutt.to/stn_stable 并确认安全提示。
  2. 使用文件传输应用（如Send Files to TV）将APK从手机或电脑传到电视。
  3. 将APK下载到USB，插入电视并使用文件管理器应用（如FX File Explorer）安装。
  4. （高级用户）使用ADB安装。
• 特殊设备安装：
  • Chromecast with Google TV：需先启用开发者选项和“未知来源”设置。
  • 小米中国固件设备：可能阻止测试版安装，建议使用稳定版、刷新国际固件或（旧设备）恢复出厂设置后安装。
• 更新：应用内置更新器，启动后会自动检查更新并显示更新日志。也可在设置中手动检查。

核心功能详解

• SponsorBlock：集成开源众包扩展，可自动跳过视频中的赞助、片头、片尾等片段。用户可选择跳过哪些类别，但无法提交新片段。
• 投屏：需手动将设备与电视配对（通过设置中的“遥控器”选项输入电视显示的代码）。SmartTube不会在相同Wi-Fi下自动显示。
• 画中画：需在设置中启用，播放视频时按主页键可进入画中画模式。
• 播放速度调节：播放器中可调节速度，设置会跨视频记忆。
• 全局语音搜索：需额外安装桥接应用并卸载官方YouTube应用。不同设备（Amazon Fire TV、Google Chromecast with Google TV等）需安装对应的桥接应用。

视频编解码器与质量

• 编解码器选择：
  • AV1 (AV01)：最佳选择（如果设备支持），压缩效率最高，节省带宽。
  • VP9：大多数设备的首选，支持设备广泛。
  • AVC：仅适用于旧或慢速硬件，比特率通常最高。
  • 建议使用设备支持的最新编解码器以获得最佳效率，而不是追求高比特率。
• 质量设置：可配置默认视频预设（最大分辨率）。应用默认会自动选择最高可用质量。目前尚无基于网络带宽的自动模式，但可手动设置最大分辨率。
• HDR：需硬件支持（包括电视、盒子、HDMI线缆等），设置复杂。如果HDR视频显示暗淡或褪色，请检查设备设置。

其他重要信息

• 责任声明：开发者对使用该工具不承担责任，建议用户遵守当地法规。
• 捐赠：提供多种支持开发者的方式（Patreon、PayPal、多种加密货币）。
• 技术支持：主要通过Telegram群组、Discord或GitHub问题跟踪器提供支持。
• 项目性质：由开发者一人完成的开源爱好项目，依赖社区贡献翻译和帮助。
• 构建要求：需要OpenJDK 14或更旧版本。

常见问题解答 (FAQ) 精选

• 视频缓冲多：尝试使用加密DNS（如NextDNS）。
• AV01不播放/VP9卡顿：多数设备缺乏AV1硬件支持；VP9卡顿可能是设备CPU不足。
• 无法在其他平台安装：仅支持Android设备。
• 可否在手机/平板安装：不支持，无任何相关支持。
• “视频配置不支持”错误：在播放器中按“HQ”按钮，将视频格式改为VP9。
• 如何开始/停止自动播放：使用播放器中的循环按钮🔁。
• 可否设置默认最大分辨率：可在设置的“视频配置”中设置。
• HDR是否工作：取决于硬件支持，例如NVIDIA Shield不支持YouTube使用的特定HDR格式。
• 跳帧问题：调节播放速度时可能出现，目前无法修复。
• 可否下载视频：SmartTube不支持下载功能。
• 可否自动安装更新：技术上不可行，应用只能显示安装提示。
• 可否为某些频道设置广告白名单：不可能，SmartTube没有任何显示广告的代码。

Kasama 是一个用于 IntelliJ 系列 IDE 的插件，其核心功能是帮助开发者跟踪和改善编码习惯。该插件被类比为“编码习惯的健身追踪器”，能够监测如编码会话、测试习惯等实践行为，旨在通过持续跟踪来提升用户的编码质量与效率。

Astral: 下一代 Python 工具

公司使命

Astral 致力于通过构建高性能开发者工具来提升 Python 生态系统的生产力，首个核心产品为 Ruff。

Ruff：极速 Python 代码检查工具

• 定义：一个用 Rust 编写的 Python linter（代码检查工具），旨在实现极致速度。
• 关键特性：速度极快，比传统 Python linter 快近 1000 倍，这一优势使其成为游戏规则改变者。
• 技术实现：基于 Rust 语言开发，确保高性能和可靠性。

性能与社区反馈

• 速度验证：由于运行过快，用户甚至需要故意引入代码错误来确认工具是否正常工作。
• 知名开发者评价：
  • Sebastián Ramírez（FastAPI 创建者）：指出 Ruff 速度之快，常需引入错误来确认运行。
  • Nick Schrock（Elementl 创始人、GraphQL 联合创建者）：强调 Ruff 的 1000 倍速度提升是真正的革新。
  • Timothy Crosley（Stripe 软件工程师、isort 创建者）：表示切换到 Ruff 后，唯一“缺点”是速度快得难以置信。
• 实际应用：Ruff 已被用于许多有影响力的开源项目，并经过 CPython 代码库等大规模测试。

开源与协作

• 开源许可：Ruff 采用许可性许可证，完全开源。
• 社区支持：由数百名贡献者共同开发，旨在赋能开源及其他重要项目。

整体影响

Astral 通过 Ruff 推动了 Python 工具链的现代化，专注于速度、统一性和未来感，为开发者提供了更高效的开发环境。