SeekTune 项目总结

项目概述

SeekTune 是一个用 Go 语言实现的音乐识别算法项目，其核心算法基于 Shazam 的音频指纹识别原理。该项目通过整合 Spotify 和 YouTube 的 API，实现了歌曲的查找、下载和识别功能。

技术栈与依赖

• 编程语言: Go (后端) + Node.js (客户端前端)
• 关键依赖: FFmpeg (音视频处理), YT-DLP (YouTube 下载), Spotify API (歌曲信息获取)
• 数据库支持: 默认使用 SQLite，也可配置为 MongoDB

主要功能

1. 歌曲下载: 通过 Spotify 歌曲链接（桌面版或网页版）下载音乐文件。
2. 本地歌曲入库: 将本地音频文件（支持多种格式）的指纹信息保存到数据库，以便后续识别。
3. 音乐识别: 输入一个 WAV 格式的音频文件，系统会从数据库中匹配出最相似的歌曲，并返回一个按匹配分数排序的结果列表。
4. 数据管理: 支持删除数据库中的指纹记录以及本地的歌曲文件。

部署与使用

部署方式

• Docker 部署: 提供 docker-compose 配置，可通过单条命令构建并运行整个应用。
• 原生安装: 需要分别安装后端 Go 依赖和前端 Node.js 依赖，然后启动客户端和后端服务。

核心使用流程

1. 配置环境: 需要设置 Spotify API 的 Client ID 和 Client Secret。如使用 MongoDB，还需配置相应的环境变量。
2. 运行服务: 启动前端应用（npm start）和后端服务（go run *.go serve）。
3. 执行操作:
   • download <spotify-link>: 下载歌曲并将其指纹存入数据库。
   • save <path>: 保存本地歌曲文件的指纹信息。
   • find <wav-file>: 识别输入的音频片段。
   • erase: 清理数据库或同时删除歌曲文件。

技术参考

项目开发参考了多篇关于 Shazam 算法工作原理的技术文章，旨在从原理层面理解和实现音频指纹识别。

其他信息

• 作者: Chigozirim Igweamaka
• 许可证: MIT License

文章概要：Stable Fast 3D —— 快速从单张图像生成3D资产

核心突破 Stability AI推出的Stable Fast 3D模型，能够从单张图像在0.5秒内生成高质量3D资产，大幅提升了3D重建的速度与效率。

工作原理与输出 用户上传单张物体图像后，模型快速生成完整的3D资产，包括：

• UV展开网格
• 材质参数
• 反照率颜色（减少光照混合影响）
• 可选的四边形或三角形重网格化（仅增加100-200毫秒处理时间）

性能优势

• 速度极快：在7GB显存的GPU上生成时间仅0.5秒；通过Stability AI API调用也仅需约1秒。
• 质量优异：生成高质量的UV网格与材质参数，纹理受光照影响小。
• 对比旧模型：相比前代SV3D模型（需10分钟），速度提升显著，同时保持输出质量。

应用场景

• 游戏与影视制作：适用于前期快速原型设计，生成静态资产（如背景物体、家具）。
• 电商与零售：快速创建商品3D模型。
• AR/VR：加速沉浸式内容开发。
• 建筑与设计：支持快速可视化设计。

使用方式 可通过Stability AI API或Stable Assistant聊天机器人使用，并支持在3D查看器中查看成果，在兼容设备上体验AR功能。

总结 Stable Fast 3D以突破性的速度和高质量输出，为3D资产创建提供了高效工具，尤其适合需要快速迭代与原型设计的行业。

文章摘要：《Just Disconnect the Internet》

本文探讨了在重大网络安全事件后，人们常提出的“系统不应连接到互联网”这一建议的现实可行性与复杂性。作者认为，这种看似简单的方案在实践中面临诸多挑战，需审慎考虑。

核心观点

1. 现代系统的互联性本质：现代商业计算机主要是通信设备。大多数业务系统（如航空订票系统）的价值依赖于实时或近实时的网络通信，断网将使其核心功能失效。此外，网络连接对于系统维护、更新和适应变化的需求也至关重要。

2. “断网”定义的模糊性：“不连接互联网”存在从严格物理隔离到各种虚拟私有网络的多种程度。文章列举了从完全单机、严格气隙隔离、到使用各类VPN和云私有网络的一系列情况，指出每种情况的安全性和风险都不同，笼统地建议“断网”缺乏具体可操作性。

3. 离线/受限网络环境的高昂成本：作者基于实际工作经验指出，运营非联网环境将导致成本和时间的大幅增加（通常增加3到10倍）。这源于：

   • 软件生态的互联网假设：操作系统、开发工具链、软件包管理器、证书信任等几乎整个软件生态都预设了互联网连接。
   • 运维复杂性：在离线环境中进行软件更新、许可证管理、内部服务证书配置、依赖项部署等变得极其繁琐和低效。
   • 技术债务：软件供应商通常不会优先考虑离线场景的支持，导致相关功能体验糟糕，用户不得不处理各种临时解决方案。

4. 现实应用的稀少性：严格的网络隔离主要见于国防、情报和部分金融等高度管制行业，这些领域通常也以成本高昂和进度缓慢著称。这并非巧合。

现实建议

尽管作者认为减少系统互联网连接是理想方向，但鉴于现状，他提出了当前可行的务实建议：

• 在云环境中应用严格的网络策略：利用云服务商提供的功能（如AWS的私有子网、VPC端点）构建受限网络环境，相对易于实现。
• 开发软件时考虑离线支持：为需要“电话回家”的功能提供禁用或端点重定向选项，并提供自托管方案。优先使用系统证书信任库。
• 避免部署时外部依赖：不要假设能够访问外部资源（如LetsEncrypt）。容器化技术（如Docker）并未根本解决问题，反而可能因第三方镜像的默认配置增加离线管理的难度。

结论

作者强调，与互联网的连接性本身与特定安全事件（如CrowdStrike更新导致的问题）是正交的。在理想情况下，安全更新应能迅速交付到离线环境，但现实中这往往难以实现。文章的核心在于批判性地审视“断网”这一笼统建议，揭示其在复杂现实环境中的操作难度，并呼吁业界更好地支持离线场景，同时为当前用户提供切实的应对思路。

域名安全漏洞：逾百万域名面临被劫持风险

核心问题：DNS认证缺陷导致“跛脚域名”易被接管

研究发现，超过一百万个域名——包括许多《财富》100强企业和品牌保护公司注册的域名——因大型网络托管商和域名注册商的认证漏洞，面临被网络犯罪分子接管的风险。

根本原因在于域名系统（DNS）的配置缺陷。当域名的权威名称服务器缺少足够的信息（即域名成为“跛脚域名”），无法正确解析查询时，某些托管和DNS提供商允许用户在不访问真实域名所有者账户的情况下，直接声明对该域名的控制权。

漏洞的历史与现状

• 此类攻击并非新事。2016年，安全研究员马修·布莱恩特曾展示如何利用DNS弱点接管至少12万个域名。
• 2019年，窃贼利用此方法接管了在GoDaddy注册的数千个域名，用于发送炸弹威胁和勒索邮件（GoDaddy称随后修复了该漏洞）。
• 最新研究（由Infoblox和Eclypsium联合发布）表明，至今仍有许多大型托管和DNS提供商存在此认证弱点。

威胁规模与滥用情况

• Infoblox估计目前约有100万个“Sitting Duck”域名（即易受接管的跛脚域名），自2019年以来，至少已有3万个域名被劫持用于恶意目的。
• 被劫持的域名被犯罪团伙用作全球分布的“流量分配系统”，以隐藏网络流量的真实源或目的地，并将用户导向恶意网站。
• 具体滥用案例包括：
  • 钓鱼攻击和垃圾邮件系统。
  • 作为Cobalt Strike等恶意软件的命令与控制（C2）服务器。
  • 创建看起来相似的子域名进行定向钓鱼。
  • 犯罪团伙囤积被劫持域名以备后用。

受害者与案例

许多被劫持的“Sitting Duck”域名最初由品牌保护公司注册，用于防御性域名注册（即为顶级品牌预留相似域名）和打击商标侵权。例如：

• clickermediacorp[.]com：原为CBS Interactive Inc.的域名，后被犯罪分子通过DNSMadeEasy接管。
• anti-phishing[.]org：由反网络钓鱼工作组（APWG）注册的域名也遭劫持。

易受攻击域名的三个共同属性

1. 域名使用或委托的权威DNS服务提供商与域名注册商不同。
2. 域名的权威名称服务器中没有该域名应指向的互联网地址信息。
3. 权威DNS提供商存在“可被利用”的漏洞，即攻击者无需域名所有者的注册商账户即可在该提供商处声明域名控制权并设置DNS记录。

各方回应与解决方案

• DNSMadeEasy：其创始人史蒂夫·乔布认为责任在于域名注册人，而非非注册商的DNS提供商，并称会关闭滥用账户。
• Digital Ocean：承认机会存在，并正与研究人员合作探索额外缓解措施，将问题根源归为域名所有者的管理不善。
• Hostinger：计划在数周内实施基于SOA记录的域名验证系统，以验证域名归属，并弃用可能被滥用的预览域名功能。
• 最佳实践：过去成功解决此问题的DNS提供商通常为账户持有者分配随机的名称服务器，要求其在注册商处更改后才能生效，并确保新分配的名称服务器与之前的记录不匹配。

结论与呼吁

研究机构指出，若全球DNS相关各方（包括政府、监管机构和标准组织）不加强合作、减少相互指责，针对“Sitting Duck”域名的攻击将继续上升，最终使域名注册人和普通互联网用户受害。报告呼吁相关方考虑长期解决方案，以应对DNS管理攻击面的漏洞。

SnowflakeOS 是一个基于 NixOS 的 Linux 发行版，专注于初学者友好和图形用户界面（GUI）体验。它旨在提供简单、不可变和可复制的操作系统设计，以简化用户使用。然而，该项目目前仍处于开发阶段，尚未准备好用于日常使用。

Foobar2000 音频播放器简介

foobar2000 是一款高级免费音频播放器。

核心特性

• 格式支持：原生支持所有主流音频格式，并可通过附加解码器组件支持更多格式。
• 播放功能：支持无缝播放。
• 网络串流：可在本地网络中串流音乐，并能控制网络音频播放器或另一设备上运行的foobar2000。
• 界面与自定义：在Windows和macOS上提供易于自定义的用户界面布局，支持自定义键盘快捷键。
• 标签与转换：具备高级标签管理功能，支持抓取Audio CD并将所有支持的音频格式进行转码。
• 音频处理：完全支持ReplayGain。内置多种DSP效果，并可通过组件扩展；在Windows上可通过VST适配器加载VST效果，在macOS上支持Audio Units。
• 电台与扩展：支持互联网电台（集成Radio Browser）。采用开放组件架构，允许第三方开发者扩展播放器功能。
• 隐私与平台：无附加条件，不进行遥测或数据收集。支持Windows、macOS、Android和iOS平台，Windows版本可通过Wine在Linux上运行。

最新动态 (2026-02-24)

关于foobar2000的Linux兼容性有状态更新。目前有非官方的Linux重新打包版本在流通，这些版本随意组合了旧的Wine开发版本和foobar2000。官方对此无法控制，并强烈建议不要安装，因为已收到大量来自这些版本的崩溃报告。

官方建议：

1. 始终直接从foobar2000官网下载，并配合使用Linux发行版自带的Wine版本。
2. 或者，如果用户具备相关知识，可自行安装最新开发版本的Wine。

目前，Wine与foobar2000之间的兼容性问题正在双方的最新构建版本中得到解决。

Google 索引过程中处理 JavaScript 的机制研究总结

研究背景与目的

Vercel 与 SEO 咨询公司 MERJ 合作，通过分析超过 10 万次 Googlebot 抓取数据，实证研究 Google 对 JavaScript 的爬取、渲染和索引能力，旨在澄清现代 Web 应用 SEO 中的常见迷思。

Google 渲染能力的演进

Google 的渲染能力已从早期仅支持静态 HTML，发展为目前使用最新版 Chrome 浏览器进行通用、无状态且带内部缓存的渲染。Google 会尝试渲染几乎所有 HTML 页面，不保留 Cookie 状态，且禁止通过 User-Agent 判断来展示不同内容（Cloaking）。

核心研究发现（打破四大迷思）

1. 迷思一：“Google 无法渲染 JS 内容”
   • 事实：Google 能 100% 成功渲染包含复杂 JS 交互、异步 API 加载、Next.js 框架及 React Server Components (RSC) 流式内容的页面。
2. 迷思二：“Google 对 JS 页面区别对待”
   • 事实：无论 JS 复杂度如何，渲染成功率无显著差异。但若初始 HTML 响应中包含 noindex 标签，Google 将直接跳过渲染，通过客户端 JS 移除该标签是无效的。
3. 迷思三：“渲染队列和延迟显著影响 SEO”
   • 事实：渲染延迟影响较小。中位数延迟仅 10 秒，75% 的页面在 26 秒内完成渲染。带有不影响内容的查询参数（如 ?ref=）或更新不频繁的页面，渲染延迟相对较长。
4. 迷思四：“JS 密集型网站页面发现更慢”
   • 事实：Google 能成功发现完全渲染页面及未渲染的 JS 数据负载（如 RSC payload）中的链接。链接的来源格式不影响爬取优先级。维护良好的 sitemap.xml 可消除不同渲染模式间的发现时间差异。

渲染策略对比

• SSG（静态生成）与 ISR（增量静态再生）：在爬取效率、链接发现、渲染完整性和速度上表现最优。
• SSR（服务端渲染）：整体表现良好。
• CSR（客户端渲染）：爬取效率和渲染时间表现较差，且存在因渲染失败导致无法索引的风险。

实践与优化建议

• 拥抱 JS 并注重性能：自由使用 JS 框架，但需优化性能以减少资源消耗，避免影响大型网站（10,000+ 页面）的抓取预算。
• 关键 SEO 元素前置：核心 SEO 标签和重要内容应通过 SSR 或 SSG 确保存在于初始 HTML 响应中。
• 规范链接与资源管理：使用真实的 <a> 标签构建内部导航链接；确保关键 JS、CSS 和 API 资源未被 robots.txt 屏蔽。
• 维护 Sitemap：定期更新 XML Sitemap，并在内容发生实质性变化时准确更新 <lastmod> 标签。
• 关注核心 Web 指标：页面速度直接影响用户体验和转化率，仍是关键排名因素。开发者应将重心放在构建高性能应用上，而无需过度担忧 Google 的渲染兼容性。

华盛顿州立大学研究团队在《酒店营销与管理杂志》发表的研究发现，在产品营销中使用“人工智能”一词会显著降低消费者购买意愿。该研究对1000名受访者进行了实验，结果显示当产品描述包含“人工智能”时，消费者的购买意向明显下降。

研究表明，提及人工智能会削弱消费者的情感信任，从而降低购买欲望。在高风险产品类别（如昂贵电子产品或医疗设备）中，这种负面影响尤为突出，因为消费者更担心金钱损失或安全风险。实验显示，同一款智能电视在描述中包含“人工智能”时，购买意愿远低于省略该术语的描述。

研究者测试了八个不同产品和服务类别，结果一致显示：在产品描述中使用人工智能相关术语会形成销售劣势。这一现象反映出消费者对人工智能炒作的日益疲劳，与科技研究公司Gartner此前指出的生成式人工智能已过“期望膨胀高峰”的趋势相吻合。

研究建议营销人员谨慎处理产品描述中的人工智能表述，应聚焦于具体功能和优势，避免过度使用技术噱头，特别是针对高风险产品时需着重建立情感信任。

Cardie - 开源商业名片设计与分享平台

这是一个开源项目，允许用户设计并管理个人商业或信息名片。用户可以创建名片并通过链接或二维码分享，可将其打印，也能将他人的名片保存至虚拟钱包。每张创建的名片都可获得访问分析数据，支持随时编辑内容，并可设置隐私（仅限持有链接者查看）。项目当前处于开放测试阶段，功能可能频繁变动且存在缺陷。

项目状态： 该仓库已被归档。作者表示若未来兴趣恢复可能会继续开发，但目前时间与精力将投入其他项目。

主要功能：

• 设计不限数量的名片
• 通过链接或二维码分享名片
• 将他人名片保存至虚拟钱包
• 获取名片访问分析数据
• 随时编辑已创建的名片
• 隐私设置（仅限链接持有者可见）

安装步骤概要：

1. 克隆仓库并创建Python虚拟环境
2. 安装项目依赖（requirements.txt 和 requirements-dev.txt）
3. 复制并配置.env文件
4. 创建Django超级用户
5. 执行数据库迁移
6. 运行开发服务器（python manage.py runserver）
7. 访问管理界面（http://127.0.0.1:8000/admin）并配置服务器对象

生产环境附加要求：

• 需要设置环境变量，如 DJANGO_ALLOWED_HOSTS、SECRET_KEY、DEBUG=False 等。

开发与贡献：

• 使用 djlint 进行模板检查。
• 使用 ruff 进行代码检查与格式化。
• VS Code 用户可安装对应扩展以获得自动格式化支持。
• 贡献指南请见 CONTRIBUTING.md 文件。

Servo 项目月度进展总结

新特性与 Web API

• Web API 更新：新增对 document.fonts.ready、GPUShaderModule.getCompilationInfo()、window.customElements.getName、表格 <caption>、document.visibilityState、CanvasRenderingContext2D.measureText() 以及 URL.parse() 等 API 的支持。
• OpenXR 支持：新增实验性 OpenXR 后端，允许 Servo 在 VR 头显（如 Quest 3）上渲染 WebXR 内容（目前仅限 Windows 平台）。

渲染与布局引擎

• 并行表格布局：启用并行表格布局，利用 Rayon 和多核 CPU 加速行与列的排版计算。
• Flexbox 引擎进展：新 Flexbox 布局引擎新增对行容器 min-height 和 max-height 的支持，并完善了容器及项目的基线对齐功能。
• 字体与元素样式：支持通用字体族（如 sans-serif），修复 Android 和 OpenHarmony 的字体匹配问题；替换元素（如 <img> 和 <canvas>）的宽高限制现遵循元素宽高比，并新增对 aspect-ratio 属性的支持。

调试、平台与工具

• 开发者工具：通过 Firefox devtools 调试时现支持查看页面控制台日志，并新增了 devtools 协议分析器以调试连接本身。
• 平台支持：servoshell 新增实验性 OpenHarmony 支持，优化了 Android 地址栏行为，支持本地文件目录列表，并修复了按 Escape 键意外退出的问题。

构建优化与开发者指南

• 二进制体积优化：Nightly 版本采用 ThinLTO 构建，结合移除调试符号或旧版布局引擎（layout_2013），可使 servoshell 二进制文件体积缩减 12.8% 至 20.1%。
• 文档与构建：Servo Book 正式成为官方文档中心；默认构建不再启用 crown linter 以简化流程（可通过参数手动启用）。
• 贡献规范：提交代码现强制要求“签名确认”（Sign-off），以确保通过 DCO（Developer Certificate of Origin）检查。

资金、社区与纪念

• 捐赠与资金：每月定期捐赠增至 2955 美元，项目已上线 thanks.dev 平台。LFX 捐赠渠道即将关闭，建议迁移至 GitHub 或 Open Collective。资金将用于购置专用 CI 服务器以显著缩短构建时间。
• 技术分享：团队成员在 GSTC 2024 等会议及个人博客上分享了 Servo 的长期愿景、基于 Servo 的新浏览器 Verso 的架构探索，以及 devtools 的修复过程。
• 缅怀：悼念于 7 月 4 日逝世的 Servo 早期核心成员 Alan Jeffrey，感谢其在并发系统、编程语言、形式化验证等多个领域的卓越研究与贡献。

PyTorch – Torchchat: 无处不在地与大语言模型对话

重要通知

torchchat 已不再进行活跃开发。 有关更多详情，请参阅相关公告。

概述

torchchat 是一个展示如何无缝运行大语言模型（LLMs）的小型代码库。它支持通过多种方式运行LLM：

• 使用 Python（PyTorch环境）
• 在 C/C++ 应用程序（桌面或服务器）中
• 在 iOS 和 Android 移动设备上

更新历史

• 2025年2月3日：新增支持 DeepSeek R1 Distill: 8B 模型。
• 2024年9月25日：新增对 Llama3.2 11B 模型的多模态支持。

核心功能

torchchat 的主要用途包括：

1. 通过 PyTorch / Python 运行模型：支持交互式聊天、文本生成以及在浏览器中运行聊天。
2. 在无 Python 环境的桌面/服务器上运行：
   • 使用 AOT Inductor 进行编译以加速执行。
   • 通过 C++ 运行器 执行。
3. 在移动设备上运行：
   • 部署并运行于 iOS。
   • 部署并运行于 Android。
4. 评估模型：使用 lm_eval 库评估模型精度。

技术亮点

• 新增对 Llama 3.2 11B 的多模态（图像+文本）支持。
• 通过命令行与多种流行LLM交互（如 Llama 3, Llama 2, Mistral 等）。
• 提供原生 PyTorch 执行性能。
• 支持多种硬件和操作系统：
  • Linux (x86)
  • macOS (M1/M2/M3)
  • Android (支持XNNPACK的设备)
  • iOS 17+ 且内存≥8GB (iPhone 15 Pro+ 或搭载Apple Silicon的iPad)
• 支持多种数据类型：float32, float16, bfloat16。
• 支持多种量化方案和执行模式：
  • Python模式：Eager（急切执行）、Compile（编译执行）。
  • 原生模式：AOT Inductor (AOTI)、ExecuTorch。

支持的模型

torchchat 支持大量模型，并为其提供了别名。以下为部分示例：

注：完整列表请参考文档中的表格，包含针对聊天、生成、代码等不同场景优化的变体。

安装

1. 确保已安装 Python 3.10。
2. 克隆仓库并创建虚拟环境（强烈推荐）：

   git clone https://github.com/pytorch/torchchat.git
   cd torchchat
   python3 -m venv .venv
   source .venv/bin/activate
   

3. 运行安装脚本：

   ./install/install_requirements.sh
   mkdir exportedModels
   

使用命令

主要通过 python3 torchchat.py <命令> 进行交互。主要命令分类如下：

• Python 推理命令：

  • chat：通过CLI进行交互式聊天。
  • generate：根据提示生成文本。
  • server：启动本地REST API服务器（兼容OpenAI API规范）。
  • browser：在本地浏览器中聊天（需先启动 server）。

• 导出命令：

  • export：将模型导出为 AOT Inductor (.pt2) 或 ExecuTorch (.pte) 产物。

• 模型管理命令：

  • download：下载模型权重。
  • list：列出所有支持的模型。
  • where：显示已下载模型的存储路径。
  • remove：删除已下载的模型。

• 评估命令：

  • eval：使用 lm_evaluation_harness 评估模型。

运行方式详解

1. 通过 PyTorch/Python 运行（Eager模式）

这是最简单的运行方式。

• 交互式聊天：python3 torchchat.py chat llama3.1
• 文本生成：python3 torchchat.py generate llama3.1 --prompt "写一个关于男孩和他的熊的故事"
• 启动API服务器：python3 torchchat.py server llama3.1，然后可通过 curl 等工具向 http://127.0.0.1:5000/v1/chat/completions 发送请求。

2. 在桌面/服务器运行（无Python依赖）

• 使用 AOT Inductor (AOTI)：
  1. 导出编译后的模型：

     python3 torchchat.py export llama3.1 --output-aoti-package-path exportedModels/llama3_1_artifacts.pt2
     # 如有CUDA，建议添加 --quantize torchchat/quant_config/cuda.json
     

  2. 运行：
     • 通过Python：python3 torchchat.py generate llama3.1 --aoti-package-path exportedModels/llama3_1_artifacts.pt2 --prompt "你好，我叫"
     • 通过C++运行器：

       # 编译运行器
       torchchat/utils/scripts/build_native.sh aoti
       # 执行
       cmake-out/aoti_run exportedModels/llama3_1_artifacts.pt2 -z <模型路径>/tokenizer.model -i "从前有一个"
       

3. 在移动设备运行（使用ExecuTorch）

1. 安装 ExecuTorch：

   export TORCHCHAT_ROOT=${PWD}
   ./torchchat/utils/scripts/install_et.sh
   

2. 导出适用于移动端的模型（通常需要量化以优化性能和大小）：

   python3 torchchat.py export llama3.1 --quantize torchchat/quant_config/mobile.json --output-pte-path llama3.1.pte
   

3. 部署与运行：
   • 在桌面测试：
     • Python：python3 torchchat.py generate llama3.1 --pte-path llama3.1.pte --prompt "你好"
     • C++运行器：编译 (build_native.sh et) 后使用 et_run 命令。
   • 部署到 iOS：
     • 要求：Xcode 15.0+，Cmake，开发配置文件（需增加内存限制权限）。
     • 步骤：打开提供的Xcode项目，编译运行，将导出的 .pte 模型和 tokenizer.model 文件复制到设备上的App目录。
   • 部署到 Android：
     • 推荐方式 (Android Studio)：下载 executorch.aar，将模型和分词器文件推送到设备 (adb push)，用Android Studio打开项目并运行。
     • 脚本方式：运行 sh torchchat/utils/scripts/android_example.sh 可自动完成环境设置和构建。

4. 模型评估

评估功能仍在开发中，使用 lm_eval 库，默认评估 wikitext 任务。

python3 torchchat.py eval llama3.1 --dtype fp32 --limit 5
# 也可评估导出后的模型
python3 torchchat.py eval llama3.1 --pte-path llama3.1.pte --limit 5

设计原则

torchchat 体现了PyTorch“用户体验至上”的设计哲学：

• 原生PyTorch：核心功能均用PyTorch编写。
• 简洁与可扩展性：强调组合优于继承、避免不必要的抽象、容忍一定的代码重复以换取可读性。
• 正确性：通过广泛的单元测试确保组件的可靠性。

社区与支持

• 加入 Discord 社区进行交流和贡献。
• 遇到问题或错误，请提交GitHub Issue，并附上完整命令、输出以及运行 system_info.txt 脚本生成的系统信息。

许可证

torchchat 使用 BSD 3 许可证发布。请注意，你对第三方模型的使用可能受其自身许可证约束。

这篇文章讲述了作者为了深入理解计算机底层工作原理，通过代码模拟一个简单CPU的经历。

背景与动机

• 作者意识到自己不理解现代计算机的内部工作原理，参考了《But How Do It Know?》一书。
• 该书从NAND门开始，逐步描述了一个简单8位计算机的构造。
• 作者倾向于通过实践和代码来学习，而非仅阅读理论，因此决定用代码实现书中描述的简单计算机。

项目概述

• 项目命名为“simple-computer”，用Go语言编写。
• 实现了一个简化的CPU，其代码逻辑基于大量的逻辑门开关模拟。
• 作者将原书的8位计算机升级为16位，以获得更多内存空间用于存储字符集等数据。
• 项目实现了键盘输入和屏幕文本显示功能。为连接外部世界，键盘和显示器的I/O部分使用了Go通道与GLFW窗口通信，但计算机的其余部分均为模拟电路。
• 作者还编写了一个简陋的汇编器，并编写了几个示例程序。

开发过程与挑战

• 开发耗时约一到两个月的业余时间。
• 主要挑战在于理解并正确实现各组件间的数据传输，特别是字节序的处理。
• 没有堆栈指针寄存器，使得函数调用和状态保存很麻烦；没有中断机制，键盘输入需要轮询。
• 汇编编程体验糟糕，寄存器数量少，编程困难。

学习收获 作者通过此项目理解了：

1. 数据如何在系统总线上于各组件间移动。
2. 简单ALU的工作原理。
3. 简单的取指-解码-执行周期。
4. 缺少堆栈和中断机制对计算机功能的影响。
5. 汇编器的功能。
6. 外围设备如何与简单CPU通信。
7. 简单字体的工作原理及显示方法。
8. 简单操作系统可能需要提供哪些基础服务。

未来展望

• 作者打算继续学习更多计算机架构知识，例如从早期RISC处理器开始，进而了解现代CPU的缓存等特性。
• 这些知识对其日常工作并非必需，但作者乐在其中。

联合发射联盟（ULA）对业余摄影师实施严格新规

联合发射联盟（ULA）近期开始向在卡纳维拉尔角太空发射场41号发射台设置遥控相机的摄影师发送电子邮件，要求他们签署一份新的“年度协议”。该协议明确规定，摄影师可以为媒体或社交媒体拍摄ULA的火箭发射影像，但不得独立销售这些作品（包括作为印刷品或年历出售）。ULA将定期核查媒体发表情况，若未发表或照片被用于非编辑性销售，设置遥控相机的权限可能被撤销。

摄影师群体的反应与历史背景

• 业余摄影师们对这一突如其来的政策感到震惊和不满。许多人依赖出售照片来弥补前往发射场的高昂成本（如交通、住宿等），新政策直接影响其生计。
• 过去十多年间，随着数字相机的普及、声波触发技术的平民化，以及NASA通过“社交媒体活动”邀请业余爱好者参与，发射场逐渐向专业媒体以外的摄影爱好者开放。业余摄影师通过分享独特影像，为航天任务积累了大量公众关注，形成了一种互利关系。知名业余摄影师（如John Kraus、Tim Dodd）甚至通过作品获得了业界认可。
• 新政策被认为切断了这种共生关系。ULA允许业余摄影师继续充当公司宣传者，却禁止其通过个人销售获得收入。

法律与公平性争议

• 法律专家指出，发射场位于军事基地内，属ULA运营的设施，其有权制定访问规则，因此新规并不违反第一修正案。然而，新规在公平性上存在争议：传统媒体的雇员（如报纸摄影师）仍可销售照片（如印刷品），而业余爱好者则被完全禁止，这构成了区别对待。

可能的动机与未解之谜

• ULA及CEO托里·布鲁诺均未对新政策的动机作出公开解释。外界猜测可能源于：个别业余摄影师的不当行为、发射场人群管理困难、或此前某次发射准备中发生的心脏病事件引发法律风险担忧等。
• ULA声称新规仅为“将以往口头沟通的规则明确化”，但多位摄影师否认此前存在此类明文或口头限制。

行业影响与应对建议

• 新规可能显著减少ULA发射任务的业余摄影师参与，导致影像覆盖减少。摄影家蒂姆·多德等人质疑，在Atlas V火箭即将退役、Vulcan火箭时代来临之际，减少报道似乎不合常理。
• 法律专家建议，摄影师可通过社会压力促使ULA改变政策，例如拒绝签署协议、不参与ULA发射拍摄、不在社交媒体分享相关影像，并持续向ULA官员质询政策变化。
• 值得注意的是，ULA近年在美国发射活动中仅占3%-5%的份额，摄影师仍有其他公司的发射任务可拍摄。

中世纪黑海东北海岸的“新英格兰”

历史背景与起源

• “新英格兰”一名并非仅指美洲。中世纪时期，在克里米亚半岛区域存在另一个“Nova Anglia”（新英格兰）。
• 该殖民地据称由1066年诺曼征服后逃离英格兰的盎格鲁-撒克逊贵族建立，并存续至13世纪。

盎格鲁-撒克逊流亡与瓦兰吉卫队

• 拜占庭帝国的瓦兰吉卫队最初由罗斯人和斯堪的纳维亚人组成，但从11世纪末起，英格兰人成为重要组成部分，并持续至1204年。
• 诺曼征服后，大量盎格鲁-撒克逊领主及随从因不满诺曼统治而移民至拜占庭帝国。
• 历史文献（如坎特伯雷的戈塞林、奥德里克·维塔利斯的记载、《劳顿编年史》及《爱德华萨迦》）共同描述了这一流亡：约1075年，由名为西格德（Siward）的“格洛斯特伯爵”率领，约350艘船经直布罗陀海峡前往君士坦丁堡。
• 他们帮助拜占庭皇帝击退了塞尔柱突厥人的围攻（可能在米海尔七世或阿历克塞一世统治时期），随后获准加入瓦兰吉卫队。

“新英格兰”殖民地的建立

• 《爱德华萨迦》和《劳顿编年史》记载，部分流亡者不满足于仅服役，向阿历克塞一世皇帝请求赐予自治领土。
• 皇帝指明黑海北部有一片旧属拜占庭但被异教徒占据的土地，允诺若其夺回便可免税拥有。
• 流亡者北上征服该地，驱逐原住民，建立“新英格兰”（Nova Anglia），并以英格兰城镇命名新定居点（如伦敦、约克）。
• 地理描述表明该地位于君士坦丁堡东北方向约六天航程处，与克里米亚半岛位置吻合。

支持“新英格兰”存在的证据

1. 拜占庭势力恢复：11世纪末，拜占庭帝国在黑海东北岸（克里米亚及亚速海）重建影响力，与历史记载相符。
2. 地名证据：14-16世纪意大利航海图在黑海东北沿岸标注了多个相关地名：
   • 苏萨科：可能源于“萨克森人”（Saxons）或“萨塞克斯”（Sussex）。
   • 洛迪纳：明显与“伦敦”相关，且常与河流名称一同出现。
   • 瓦兰吉相关地名：如瓦兰吉港、瓦格罗波利等，分布于克里米亚半岛及亚速海沿岸，被认为特指“英格兰瓦兰吉人”。
3. 13世纪文献：方济各会修士记载了克里米亚/亚速海区域存在信仰基督教、居住于坚固城市的“萨克西人”（Saxi），并详细描述了其成功抵抗鞑靼人进攻的战役，表明该社群在13世纪仍具军事实力。

结论

综合历史文献、地名证据及独立史料，中世纪黑海东北海岸的“新英格兰”殖民地很可能真实存在。它由11世纪末流亡的盎格鲁-撒克逊人建立，存续数世纪，并为拜占庭帝国持续输送“英格兰瓦兰吉”战士，甚至至14世纪时该卫队的“母语”仍为英语。该殖民地的存续为理解中世纪人口流动、军事组织及文化传播提供了重要视角。

文章标题：我是如何遭受激光眼伤的

本文作者叙述了一次工作场所激光安全事故。1999年春季，作者在一家激光公司担任激光安全官员。一日，他在公司室外听到激光设备闪光灯的异常声响，循声发现两名客户和一名销售工程师鲍勃正在停车场进行未经授权的激光演示实验，试图开发一种用激光去除道路标线的方法。

此次操作存在多重严重违规：

1. 设备与防护不当：他们将一台高功率Nd:YAG激光器（Quanta-Ray PRO350）移至室外，连接在一个类似拖车的装置上。两名客户佩戴的是仅适用于氩激光的防护镜，对Nd:YAG激光的1064nm波长完全无效；销售工程师鲍勃甚至未佩戴任何防护眼镜。
2. 严重安全隐患：
   • 实验损坏了公司新铺的停车场标线。
   • 激光光学元件损坏，导致光束失控，未照射地面而是烧毁了公司副总裁新吉普车的车漆，并穿透轮罩切断了刹车线。
   • 光束反射自车辆的抛光钢面，可能直射回操作者自身及四周。
   • 实验地点紧邻链式围栏，另一侧是一所小学，存在照射风险。
   • 向上有多个机场（包括军事机场）的空域，存在激光照射飞机的风险。

作者在试图制止时，被散射的激光束击中。数月后检查发现右眼周边视网膜出现轻微漂白，导致视野中出现一小块淡黄色区域。

事件在一场及时雨中告终，雨毁坏了价值25万美元的激光系统。涉事的销售工程师鲍勃两周后离职。

作者通过此故事强调了遵守安全规程的重要性，并得出了一个讽刺性的教训：在所有可能伤害的旁观者中，切勿伤害安全官员。

Tulip创意计算机摘要

产品概述
Tulip是一款售价仅59美元的便携式一体化计算机，专注于音乐创作、写作和编程。其设计强调简洁、专注与趣味性，无浏览器或社交媒体等干扰，旨在激发用户创意。

核心功能

1. 运行环境：基于低功耗实时微控制器，直接启动MicroPython环境，内置代码编辑器及音乐示例程序。
2. 音乐合成：搭载功能齐全的AMY合成器，支持加法、减法及FM合成（类似DX-7和Juno-6），可通过Python代码控制所有振荡器参数。
3. 图形编程：提供可编程图形API，支持硬件精灵和滚动背景，允许用户使用LVGL在触摸屏上开发游戏或合成器界面。
4. 连接与控制：支持MIDI、I2C和Wi-Fi，可外接可选Alles音箱实现多声道音频演出（最多可组建数十通道的环绕声系统）。

技术规格

• 合成器支持120个振荡器、立体声、滤波器、混响、合唱、FM及PCM采样。
• 通过Tulip专属BBS系统“Tulip WORLD”实现文件共享。
• 完全开源，包含硬件、操作系统及合成器DSP代码。

价格与购买

• 售价59美元（仅覆盖部件与制造成本，含少量未来开发支持费用）。
• 通过Makerfabs购买，支持全球配送。
• 可选双通道DAC模块（5.80美元），用于控制模块合成器。

社区参与
提供Discord社区及GitHub开源仓库，鼓励用户参与讨论、开发与贡献。

这篇深入的技术文章全面解析了Wi-Fi技术，旨在帮助读者理解无线网络的性能关键，并做出明智的升级决策。文章指出，Wi-Fi速度的最大瓶颈通常是客户端设备（如手机、笔记本电脑），而非路由器。路由器的营销宣传常存在夸大。

核心概念与关键因素

• 距离与障碍物是关键：Wi-Fi信号强度随距离增加而急剧衰减，穿越墙壁、地板等障碍物会进一步大幅降低速度。因此，靠近路由器/接入点（AP）才能获得最佳速度。
• 客户端限制：绝大多数移动客户端设备（手机、平板）仅支持2×2 MIMO，这限制了其最大PHY（物理层）速率，通常在866 Mbps（Wi-Fi 5 80MHz）或1201 Mbps（Wi-Fi 6 80MHz）左右。因此，即使购买顶级路由器，也无法突破客户端设备的这一限制。
• PHY速率与实际吞吐量：设备报告的PHY速率是理论最大值，实际应用层吞吐量通常约为PHY速率的70%（±10%），其余为Wi-Fi协议开销。
• 频谱与信道：2.4 GHz频段拥挤（仅3个不重叠信道），易受干扰。5 GHz频段信道更多、干扰少，但穿墙能力稍弱。DFS（动态频率选择）信道支持对于获得160MHz宽信道和避免邻居干扰至关重要。
• 营销宣传警惕：路由器型号中的数字（如AX11000）是所有频段最大速度之和，对于单个客户端设备毫无意义。真正的差异在于设备“在距离上”的性能表现。

Wi-Fi代次演进

• Wi-Fi 5 (802.11ac)：引入80MHz信道、256-QAM、波束成形。主流设备PHY峰值866 Mbps（2×2, 80MHz）。
• Wi-Fi 6 (802.11ax)：主要提升效率（OFDMA技术），支持1024-QAM和160MHz信道（需DFS）。峰值PHY达2402 Mbps（2×2, 160MHz）。显著提升了多设备并发性能。
• Wi-Fi 6E：将Wi-Fi 6扩展至6 GHz新频谱（新增1200MHz），提供大量160MHz信道，避免DFS冲突，利于实现千兆以上无线速度。
• Wi-Fi 7 (802.11be)：引入320MHz信道、4096-QAM（极难在现实中稳定使用）和多链路操作（MLO）。当前技术尚未完全成熟，非紧急需求可等待。

如何改善Wi-Fi速度

1. 检查并升级客户端设备：确保设备支持Wi-Fi 5/6及较高规格。
2. 优化路由器位置：将主路由器放置在家庭中心、开阔无遮挡处。
3. 使用有线回程接入点（AP）：这是改善远距离Wi-Fi速度最有效的方法。将一台普通路由器配置为AP模式，通过以太网线连接至主路由器，并放置在信号需求最迫切的区域。
4. 避免无线扩展器/中继器：它们通过重复传输信号，会严重降低吞吐量并增加延迟，仅作为最后手段。
5. 谨慎选择Mesh系统：Mesh网络便于安装，但无线回程的卫星节点会共享带宽，性能通常不如有线回程的AP。优先考虑支持有线回程的Mesh或直接使用AP。
6. 手动选择信道：在路由器设置中，为2.4GHz频段选择1、6或11信道，为5GHz频段优先选择DFS信道（如需160MHz则必须支持），以避开邻居干扰。
7. 分离频段名称（可选）：将2.4GHz和5GHz的SSID设置为不同名称（如“HomeWiFi”和“HomeWiFi-5G”），可强制客户端连接到更快的5GHz频段。

设备选购建议

• 核心特性：选择支持 4×4 MIMO、DFS信道、160MHz (HE160) 信道宽度的Wi-Fi 6中端路由器，这是目前性价比最高的选择。
• 品牌推荐：文章推荐了如TP-Link Archer AX80、GL.iNet Flint 2等型号，它们通常具备上述特性，价格约在170-230美元。
• Wi-Fi 7/6E考量：Wi-Fi 7路由器（如TP-Link BE550）价格下降，但技术仍在发展。Wi-Fi 6E路由器能更好地保证160MHz信道，但价格较高。2×2 MIMO的Wi-Fi 7路由器是体验新技术且控制成本的可行选择。

总结

实现高速无线体验的关键在于理解距离、障碍物和客户端设备限制的核心影响。避免被路由器的营销数字误导，通过优化位置、优先采用有线回程AP扩展覆盖、并选择具备关键特性（4×4 MIMO, DFS, 160MHz）的Wi-Fi 6中端路由器，大多数用户能够以合理的成本构建出高效、稳定的无线网络。

开普勒400年前的太阳黑子手绘帮助解开现代之谜

一篇发表在《天体物理学杂志快报》上的论文显示，日本和比利时的天文学家团队利用现代分析技术重新研究了17世纪天文学家约翰内斯·开普勒的太阳黑子手绘图，解决了长期困扰天文学界的一个谜团。

历史背景 17世纪关于谁最早观测到太阳黑子存在激烈争论。中国天文学家早在公元前364年至28年就有记录。开普勒在1607年使用暗箱观测并绘制了太阳黑子（最初误认为是水星凌日），后于1618年更正。他的手绘基于在布拉格家中的观测及与宫廷机械师尤斯图斯·比尔吉合作时的观测。

“蒙德极小期”之谜 从1645年到1715年左右，太阳黑子记录极少，这一时期被称为“蒙德极小期”。德国天文学家古斯塔夫·斯波勒在1887年和1889年的论文中指出此现象，英国的爱德华和安妮·蒙德进一步研究了黑子随时间变化的纬度分布。斯波勒还提出了“斯波勒定律”，即太阳周期开始时黑子出现在较高纬度，随周期推移向低纬度移动。

一个关键未解问题是：太阳活动周期如何过渡到蒙德极小期？基于树木年轮的重建数据相互矛盾——有的得出一个极短（约5年）或极长（约16年）的太阳周期，而有的则得出正常的11年周期。

开普勒手绘的新分析 日本名古屋大学的久川尚和同事转向开普勒的早期手绘寻求线索，这些手绘比现有的望远镜观测早几年。研究团队对开普勒的暗箱投影图进行了“去投影”分析，修正了图像颠倒和角度问题，并与当代数据对比。

发现与结论 分析表明，开普勒绘制的太阳黑子位于较低纬度。根据斯波勒定律，这意味着该黑子群属于前一个太阳周期（太阳周期-13）的末尾，而非新周期（太阳周期-14）的开始。结合后续望远镜观测中新周期黑子出现在较高纬度的数据，团队将两个周期之间的过渡时间缩小到1607年至1610年之间。这一结论支持了前一个太阳周期为正常持续时间的观点，而非极端的短周期或长周期。

该研究通过利用历史手绘和现代分析技术，为解决长期存在的太阳活动周期过渡之谜提供了关键独立证据。

核心观点：基因组作为生物体的生成模型

本文提出一个核心理论框架：基因组编码了一个生物体的生成模型。该观点受到机器学习和神经科学的启发。

关键类比与机制

• 类比基础：基因组的作用被类比为变分自编码器。
• 模型构成：基因组被设想为一个连接主义网络，它包含一个压缩的潜在变量空间。这些潜在变量代表了发育过程中可能的形态或特征的抽象可能性。
• “编码”与“解码”：
  • 编码（学习）：进化过程充当“学习算法”，通过自然选择塑造和确定模型的“权重”（即基因及其相互作用关系）。
  • 解码（发育）：发育过程充当“解码”过程，利用基因组中编码的模型，在特定环境输入下，将潜在变量空间的表征“解码”为具体的、可观测的生物体表型。

理论解释力

该生成模型框架能够解释生物系统的一些基本特征：

1. 复杂、分布式的遗传架构：大多数性状由众多基因微效贡献，而非单个基因决定。生成模型的分布式表征特性与此相符。
2. 发育过程的鲁棒性与可演化性：
   • 鲁棒性：模型能够容忍一定的输入扰动（如环境变化、基因突变），仍能输出稳定的表型。
   • 可演化性：潜在变量空间的结构允许进化探索新的表型可能性，而无需完全重建整个系统。

理论价值

该理论不仅提供了一个强大的概念隐喻，还具备可形式化的优势，为连接基因型与表型提供了一个可能的数学框架，并与发育生物学和进化论的现有观点兼容。

OpenAI生存危机深度分析

OpenAI作为生成式AI浪潮的领头羊，其长期生存能力面临多重严峻挑战。核心矛盾在于：生成式AI目前缺乏足够的大众市场实用性，但构建和运行成本极其高昂。这引发了对其长期可持续性的根本性质疑。

一、与微软的复杂共生与竞争关系

OpenAI与微软的深度绑定既是其生命线，也是隐患。微软通过多轮投资（总额据报道达130亿美元，其中大量为Azure云服务抵用券）获得了OpenAI所有“前AGI”阶段技术的访问权、销售权及49%的股份。这意味着微软实际上拥有并可以竞争OpenAI的技术（例如其自研的MAI-1模型），同时在OpenAI盈利时还能获取高达75%的利润。OpenAI被紧密锁定在Azure生态系统中，其生存与发展极度依赖微软的资源与条款。

二、不可持续的财务消耗

OpenAI正以史无前例的速度“烧钱”。据《The Information》估算，其2024年运营亏损可能高达50亿美元，主要支出包括：

• 云服务成本：约40亿美元，用于支撑ChatGPT及底层模型。
• 模型训练成本：可能高达30亿美元。
• 人力成本：约15亿美元。 尽管收入估计在35-45亿美元之间，但增长难以抵消成本。公司需要不断进行史诗级的融资（单轮可能达50亿至100亿美元），且几乎没有成功的商业先例可循。当前的资本市场环境和其独特的非营利-营利混合结构，使其后续融资难度极大。

三、技术、数据与市场困境

1. 技术瓶颈：基于Transformer的架构存在根本限制，模型改进多是线性的（更快、更多数据），而非质的飞跃，且成本随规模急剧上升。
2. 数据危机：训练下一代模型所需数据量剧增，但可用合法数据面临枯竭，且使用网络数据存在持续的法律风险。使用AI生成的“合成数据”可能导致“模型退化”。
3. 市场适配性弱：生成式AI尚未出现“杀手级应用”或实现广泛的商业化价值证明，更多依赖于行业FOMO（错失恐惧症）。竞争加剧导致价格战，利润空间被压缩。
4. 能源限制：大规模扩展AI算力需要美国电网进行数十年未有的巨幅升级，而当前基础设施建设项目审批和建设周期漫长（40-70个月），这构成了一个庞大的物理瓶颈。

四、生存的必要条件与作者结论

作者认为，OpenAI要在当前形式下存活两年以上，必须同时实现以下几乎不可能的条件：

1. 与微软的复杂关系中成功导航。
2. 持续进行史上最大规模的融资。
3. 取得革命性技术突破，将模型成本降低数个数量级。
4. 开发出全新的、能创造大量新就业或自动化经济活动的应用场景。
5. 这些应用场景必须足以验证其惊人的资本支出。

结论是悲观的：作者认为OpenAI当前模式不可持续，没有盈利路径，消耗率过高，且依赖于缺乏历史先例的多重奇迹发生。其生存与否不仅关乎自身，更直接影响整个生成式AI市场的信心和相关投资。作者虽然希望自己的判断是错的，但基于现有公开数据和逻辑推演，OpenAI面临的是一个深具根本性且多层面的生存危机。