本文介绍分享textures网站免费提供高质量PBR纹理与3D模型资源。自2018年以来，网站持续推出1700多种纹理及大量3D模型，用户可将这些素材应用于各类项目，包括商业用途，且全部资源均无版权限制。网站近期活跃用户众多，并鼓励用户通过Patreon平台支持项目发展。

文章摘要：我如何通过重塑大脑成为数学高手（2014）

个人背景与转变

作者原是一个偏爱文学、惧怕数学的人，通过成年后从零开始学习数学，最终成为工程学教授。26岁从军队退役后，她才开始学习基础代数与三角学，这被视为成人神经可塑性的典型例子。

核心观点：流利度优于单纯理解

作者通过自身学习俄语和数学的经历，提出学习数学和科学应像学习语言一样，注重通过重复练习达到流利，而非仅追求理解。她认为：

• 流利度是理解的基础：持续练习能建立神经“组块”，将知识内化为潜意识能力，从而在需要时快速调用。
• 仅追求理解易导致“能力错觉”：学生可能以为听懂了课堂内容，但缺乏练习会导致实际应用失败。
• 教育中的失衡：当前美国教育过度强调概念理解，忽视了重复、记忆和练习对巩固知识的关键作用。日本的“公文数学”方法正是通过高强度练习提升学生流利度的例证。

学习方法论：借鉴语言学习

作者将语言学习策略应用于数学：

• 刻意练习：例如，对公式 ( f = ma ) 反复进行变换、代入和单位分析，直至内化。
• 组块化：通过练习将知识点整合为神经子程序，类似象棋大师记忆棋局模式。
• 交错练习：混合不同问题类型，以增强知识的灵活运用能力。

教育现状与建议

• 对Common Core标准的批评：虽提倡概念理解、程序技能和应用的平衡，但实践中往往偏重理解，导致学生缺乏真正的操作能力。
• 神经科学支持：专家（如象棋大师、飞行员）依赖深层组块在压力下快速决策，说明流利度的重要性。
• 呼吁改革：教育者应平衡理解与练习，鼓励学习者尝试新学科（如数学、物理、语言），通过重复练习建立基础流利度，从而打开新的可能性。

结论

作者强调，数学和科学的精通依赖于通过重复获得的流利度，而非孤立的理解。这种方法不仅适用于她个人从文学转向工程的经历，也为改善STEM教育提供了可行路径：通过练习将知识转化为潜意识能力，才能在长期中维持并灵活应用理解。

文章通过作者的个人经历和观察，批评了Passkey技术在实际应用中的一系列问题，指出其原本作为终结密码的理想已逐渐破灭。

最初的愿景与技术热情 作者于2019年参与开发了Rust语言的WebAuthn库（webauthn-rs），初衷是推动实现无密码、无用户名等更安全便捷的认证方式。早期实践（如在Kanidm中）展现了出色的用户体验，激发了社区对“终结密码”的乐观预期，该库也影响了多个项目和实现。

标准制定中的问题 作者指出WebAuthn标准并非完全开放，浏览器市场由Chrome主导。例如，“认证器选择扩展”因Chrome未实现而被移除，尽管该扩展对企业安全策略（限制认证设备型号）很重要。Chrome以“不应有设备歧视”为由，但自身却通过内部功能支持策略限制，导致不平等。此外，标准制定的“面对面会议”主要在美国举行，排除了国际参与者的有效意见。

Passkey的推行与用户体验崩溃 2022年Apple推出Passkey后，行业人士将Passkey定义为“居民密钥”，但安全密钥（如Yubikey）的居民密钥存储容量极低（虽已提升至100个，仍不足），将用户排除在外。当前，Chrome、Safari甚至强制用户使用手机扫码（caBLE）等体验较差的方式。Android系统则直接根据网站设置决定激活何种设备，剥夺用户选择权。

广泛的技术故障与用户失望 多个平台出现严重问题：GitHub报告中安全密钥因存储满无法注册、Android设备因平台Bug无法创建Passkey、凭证丢失或重复等。作者亲历Apple Keychain四次清除所有Passkey，其他用户也反馈类似经历。技术复杂性和不稳定性导致连技术早期用户都遭遇困难，引发广泛失望。

结论与建议 作者认为，由于市场争夺和糟糕的用户体验，Passkey很可能失败，仅被小众技术用户接受。其伴侣（非技术人员）因体验差已放弃Passkey，作者也认为密码管理器提供更佳体验。他建议：

• 使用如Bitwarden等密码管理器管理密码。
• 若使用Passkey，应存储在自控的密码管理器中，避免平台锁定。
• 安全密钥可谨慎用于解锁密码管理器或邮箱。
• 企业环境可考虑设备证书和智能卡，虽UI传统但可避免平台牵制。

尽管失望，作者将继续维护webauthn-rs相关项目，但正在探索替代方案。

微软开源MS-DOS 4.00

微软与IBM合作，在MIT许可证下正式发布MS-DOS 4.00的源代码，这是操作系统历史上的一个重要时刻。此前，微软已将MS-DOS 1.25和2.0的源代码发布给计算机历史博物馆，用于参考和研究。

历史背景

MS-DOS 4.0版本有着复杂的历史：微软与IBM合作开发了部分代码，但同时也创建了一个名为Multitasking DOS（MT-DOS）的分支，该分支未广泛发布。MT-DOS最终影响了后来成为OS/2的操作系统的发展。

发现与发布过程

• 英国研究员Connor "Starfrost" Hyde在与前微软首席技术官Ray Ozzie的通信中，发现了Ozzie收藏中未发布的DOS 4.0 beta二进制文件。这些文件最初是在Ozzie供职于Lotus时发送给他的。
• Starfrost联系微软开源计划办公室（OSPO），探索发布DOS 4源代码的可能性，以研究DOS 4、MT-DOS和OS/2之间的关系。
• 微软员工Scott Hanselman与互联网档案爱好者Jeff Sponaugle合作，对这些原始磁盘进行成像，并扫描了原始打印文档，称为“Ozzie Drop”。
• 微软档案中未找到MT-DOS的完整源代码，但成功定位了MS-DOS 4.00源代码。微软与IBM共同决定公开这些资源。

发布内容

• 源代码：MS-DOS 4.00完整源代码，以MIT许可证发布。
• 额外资源：包括未发布的beta二进制文件、ibmbio.com源代码、文档PDF和磁盘镜像。
• 微软表示将继续探索档案，如发现更多内容可能更新发布。

技术运行

该软件已在多种系统上成功运行：

• 原始IBM PC XT
• 较新的Pentium计算机
• 开源模拟器PCem和86box

致谢与合作

感谢Ray Ozzie、Starfrost、Jeff Sponaugle、微软和IBM的团队，以及数字考古软件（如Greaseweazle、Fluxengine等）的开发者。特别致敬原始代码作者，其中一些人仍在微软和IBM工作。

此发布旨在保存操作系统历史，并促进开源创新。所有资源已通过微软开源项目发布在GitHub上。

NAND：一个基于NAND门的16位可编程计算机

项目概述

NAND是一个完全由时钟和NAND门模拟构建的图灵完备16位计算机，在Web浏览器中运行。它基于“Nand to Tetris”课程及其相关书籍中的Jack-VM-Hack平台。项目包含一个完整的工具链：CPU、机器语言、汇编语言、汇编器、虚拟机语言、虚拟机翻译器、编程语言（Jack）、编译器、集成开发环境（IDE）和用户界面。

核心特性与示例

项目提供了多个示例程序以展示其能力：

• Average：演示控制流、算术运算、I/O和动态内存分配。
• Pong：展示面向对象编程的乒乓球游戏。
• 2048：展示递归和复杂应用逻辑的数字拼图游戏。
• Overflow：一个故意导致栈溢出的程序，用于演示“虚拟机逃逸”。它利用系统缺乏运行时栈溢出检查的特性，使程序执行流跳转到内存中未定义的区域。
• SecretPassword：通过栈溢出（栈破坏）修改函数返回地址，从而调用程序中原本无法访问的函数，实现了任意代码执行。
• GeneticAlgorithm：一个复杂的生物模拟程序，利用简单的机器学习（自然选择）来进化“点”使其达到目标。它通过多种优化技术克服了NAND的硬件限制。

Jack编程语言

NAND使用名为Jack的弱类型面向对象编程语言。其主要特点包括：

• 语法：类似Java，但本质上是弱类型的。
• 类型系统：底层仅有有符号16位整数一种类型。int, char, boolean 是语法上的区分，编译器不进行严格类型检查，允许类型混合使用。
• 内存管理：采用手动内存管理。开发者必须为不再使用的对象调用dispose方法来释放堆内存，否则会导致堆内存泄漏和程序崩溃（错误代码ERR6）。
• 运算符优先级：没有运算符优先级，必须使用括号来明确表达式计算顺序，否则行为未定义。
• 自定义类型：支持定义类、构造器、方法、函数和字段变量。
• 未定义行为：文中列举了多种可能引发未定义行为的情况，包括运算符优先级混淆、-32768的特殊性、参数数量错误、类型强转不当、栈溢出、修改栈帧或内部寄存器等。

硬件规格与限制

• 架构：哈佛架构，指令内存（ROM）与数据内存（RAM）分离。
• CPU：累加器式机器，仅有两个操作码，指令集相对简单。
• 内存：总共有4 KiB（32,768字）的RAM。
  • 堆：14,336个地址。
  • 屏幕：8,192个地址（映射到512x256像素的屏幕）。
  • 键盘：地址24576（提供专用API访问）。
  • 静态变量：240个地址。
  • 全局栈：1,792个地址。
• 屏幕：512x256像素，位图映射。
• 键盘：支持所有ASCII字符及多个功能键。

系统架构与工作流程

1. 编译：Jack源代码由递归下降解析器编译器编译成虚拟机（VM）代码。
2. 翻译：虚拟机代码被翻译成汇编语言。
3. 汇编：汇编语言被汇编成机器语言。
4. 执行：机器语言在模拟的NAND门CPU上执行，CPU遵循哈佛架构。

• Jack操作系统（OS）：默认与用户程序一起编译，提供内存管理（Memory）、数学运算（Math）、屏幕输出（Output）、键盘输入（Keyboard）、图形绘制（Screen）和字符串处理（String）等核心服务。开发者也可以提供自定义的OS实现。
• 实现：NAND的核心NAND门逻辑模拟器使用Rust编写，并编译为WebAssembly在浏览器中运行。编译器和虚拟机翻译器用TypeScript编写。

IDE与用户注意事项

• IDE：基于Web，使用contenteditable实现，功能完整但体验不佳，速度慢且有bug。
• 内存管理：必须手动管理内存，注意分配和释放。
• 表达式：务必使用括号明确运算顺序。
• 数字范围：仅支持-32768到32767的整数，无浮点数，需注意整数溢出。
• 程序加载：IDE仅验证.jack文件，不验证.vm文件，因此加载自定义VM代码可能导致未定义行为。

常见问题

• 并非完全由NAND门构成：描述为“由NAND门构成”是出于教学和理论目的。实际系统是基于“Nand to Tetris”规范的完整软件模拟。
• 设计来源：严格遵循“Nand to Tetris”课程规范，作者实现了CPU、汇编器、VM翻译器、编译器的具体实现，并将其移植到Web环境。
• 类型声明的意义：虽然底层只有整数，但显式类型声明有助于编译器确定实例方法属于哪个类，实现正确的编译转换（如s.appendChar()转为String.appendChar(s, ...)）。

PEP 686 总结

提案目的：本提案旨在从 Python 3.15 开始，将 UTF-8 模式设为默认模式。这意味着 Python 将默认使用 UTF-8 作为文件、标准输入输出（stdio）和管道（pipes）的编码方式。

核心变化与动机：

• 变化：默认启用 UTF-8 模式。用户仍可通过设置环境变量 PYTHONUTF8=0 或命令行选项 -X utf8=0 禁用此模式。
• 动机：UTF-8 已成为事实上的文本编码标准。主流的文件格式（如 JSON、TOML、YAML）、开发工具、网站及其他编程语言（如 Node.js, Go, Rust）均默认使用 UTF-8。将 Python 的默认编码改为 UTF-8 可提升互操作性。此外，许多开发者（尤其是在 Unix 上）常因忘记 Python 默认编码依赖于平台，而在读写 UTF-8 文件（如 JSON、Python 源码）时未指定 encoding="utf-8"，导致不一致的默认编码引发许多错误。

规范细节：

1. 默认启用：如上所述。
2. 新增 API locale.getencoding()：由于 UTF-8 模式会影响 locale.getpreferredencoding(False) 的行为，该新 API 用于获取不受 UTF-8 模式影响的区域编码。此 API 在 Python 3.11 中引入。
3. 修复 encoding="locale" 选项：根据 PEP 597，即使在 UTF-8 模式下，当指定 encoding="locale" 时，TextIOWrapper 也应使用区域编码。此不一致行为已在 Python 3.11 中修复。

向后兼容性影响：

• 主要影响：此变更主要影响 Windows 用户，因为大多数 Unix 系统已使用 UTF-8 区域设置。
• 潜在问题：依赖于旧默认编码的程序可能在 Windows 上出现 UnicodeError、乱码（mojibake）甚至静默数据损坏。
• 迁移指南：
  1. 临时禁用 UTF-8 模式。
  2. 使用 EncodingWarning（来自 PEP 597）找出所有受默认编码影响的位置。
  3. 对于省略 encoding 参数的情况，考虑显式指定 encoding="utf-8" 或 encoding="locale"。
  4. 如果使用了 locale.getpreferredencoding()，考虑改用 "utf-8" 或新的 locale.getencoding()。
  5. 在启用 UTF-8 模式下测试应用程序。

被拒绝的替代方案：

• 弃用隐式编码：因为对许多仅处理 ASCII 文本或只在 Unix 上运行的应用而言过于繁琐，且大量警告会导致用户忽视。
• 为管道使用 PYTHONIOENCODING：虽然能缓解兼容性问题，但会使“默认编码”的概念复杂化，且本身也存在向后兼容问题。

教学影响：

• 新用户：减少了初始学习负担，他们无需在学习初期就深入了解文本编码。
• 现有用户：需参考向后兼容性部分以适应变更。

Pharo 12 版本发布

Pharo 是一种纯面向对象的编程语言和强大环境，专注于简洁性和即时反馈。其核心特性包括：

• 简洁而强大的语言：无构造函数、类型声明、接口或原始类型，语法精炼，以对象和消息传递为核心。
• 实时沉浸式环境：在开发、测试和调试中提供即时反馈，无需传统的编译和部署步骤。
• 卓越的调试体验：支持单步执行、重启方法、动态创建方法等高级调试功能。
• 社区驱动与开源：由全球社区贡献，采用 MIT 许可证发布，完全开源。

Pharo 12 重点更新

本次版本聚焦于改进、清理和模块化，同时提升了可用性和速度。主要亮点包括：

新断点系统

取代旧的断点和监视点，提供可配置、可组合且可扩展的调试点模型。新增功能包括：

• 链式断点（条件激活）
• 专用浏览器和集成选项
• 支持条件断点、一次性断点和对象中心断点

工具与框架改进

• 默认使用可伸缩流体类语法
• Spec2 UI 框架增强，支持 GTK 4，并迁移更多工具至 Spec2 控件
• 精简的 Metacello 包管理器
• FFI（外部函数接口）的更稳健严格模式

系统优化

• 重构与领域特定转换的新架构
• 代码加载速度提升
• 通过优化包标签实现快速浏览
• 方法协议的内存使用优化
• 编译器简化与改进

虚拟机增强

• 支持大型镜像与永久空间
• 字符串/字节数组比较加速

开发与贡献

Pharo 12 是 1895 个 Pull Requests 的整合成果，关闭了 865 个问题，并有超过 70 位贡献者参与。此外，多个关联项目（如 NewTools、Spec、Iceberg、Roassal 等）也为本次版本做出了贡献。

社区致谢

Pharo 由全球社区共同打造，感谢所有通过提交代码、报告 bug、参与讨论和提供反馈的贡献者。

了解更多：

• 探索 Pharo：https://pharo.org/features
• 下载试用：http://pharo.org/download
• 学习文档：http://pharo.org/documentation

发布日期：2024年4月26日

创建自己的无线互联网服务提供商（WISP）指南

本文旨在帮助读者启动自己的互联网服务提供商，专注于构建**无线互联网服务提供商（WISP）**的最初阶段，从可行性评估到连接首批客户。指南未涉及客户规模扩大（如100、1000或10000用户）后的挑战，如需个性化协助，可预约作者咨询。

入门介绍

• 什么是WISP？ 解释无线互联网服务提供商的概念、建设动机及相关术语。
• 成本估算：提供一个可复制并自定义的Google Sheets链接，用于构建WISP的成本核算。
• 作者背景：介绍指南作者及其动机。

分步指南（10个步骤）

1. 评估区域：确保目标区域适合建设无线互联网网络。
2. 寻找光纤提供商：找到可购买光纤连接的建筑，并利用其屋顶启动无线网络。
3. 寻找中继站点：通过无线方式将网络延伸至客户区域。
4. 选择硬件平台：评估可用的无线硬件选项。
5. 计费与客户管理：确保具备收款和客户支持能力。
6. 网络拓扑设计：设计可靠且可扩展的网络结构，包括路由器、交换机、IP地址和VLAN等。
7. 建设基础设施：安装光纤连接和中继站点的硬件。
8. 安装首个客户：使第一位客户上线。
9. 市场推广：宣传服务以吸引更多用户。
10. 日常维护：确保网络在恶劣天气等情况下稳定运行。

其他资源

• FCC表格477：介绍美国联邦通信委员会要求的半年度填报流程。
• 工具清单：列出安装中继站点和客户所需工具。
• 中继瞄准指南（即将发布）：提供正确的中继瞄准技术。
• 中继设备清单：用于建立点对点无线连接的设备选择指南。
• 射频基础与信道规划（即将发布）：避免自干扰的信道选择策略。
• 多单元住宅服务指南：为公寓楼等提供服务的最佳实践。
• 谷歌地球使用指南：利用谷歌地球规划和构建网络的技巧。
• 屋顶与梯子安全（即将发布）：现场安全注意事项。

协助方式

本指南由Outpost Plus组织支持，其专业人员可提供咨询和项目协助，用户可通过联系方式进一步讨论需求。

API设计原则：“无抽象”

核心理念 API资源如同API的“名词”，其命名与建模是设计中最具挑战性也最关键的部分。Increase团队采用“无抽象”原则来指导这一过程，这与Stripe的抽象化方法形成对比。

用户差异决定设计哲学

• Stripe用户：多为初创公司，不熟悉支付网络细节，需要快速集成。因此，Stripe擅长提取复杂领域的核心特征，将其抽象为易于理解的资源（如将不同卡网络的拒付原因代码统一为PaymentIntent的枚举）。
• Increase用户：通常对支付网络有深入了解，注重金融科技细节，因Increase提供的直接网络连接和深度集成而使用。对他们而言，隐藏底层复杂性（如用单一资源混合ACH转账和电汇）会造成困扰而非便利。

“无抽象”原则的具体体现

1. 使用真实世界命名

   • 直接采用底层网络的术语为API资源和属性命名。例如，ACH转账的参数名称遵循Nacha规范字段。

2. 强调不可变性

   • API资源倾向于模拟真实世界的事件或消息，因此多为不可变资源。通过将一组相关不可变资源（如ACH转账生命周期中的所有网络消息）归类到一个状态机“生命周期对象”下，形成清晰的结构。
   • 示例：ach_transfer对象包含一个随时间变化的status字段，以及在生命周期不同阶段创建的不可变子对象（如approval、submission、acknowledgement），每个子对象记录具体事件的时间戳和数据。

3. 按用例分离资源

   • 如果同一类API资源在不同实例上可执行的操作差异显著，则将其拆分为多个独立资源。
   • 示例：主动发起的ACH转账（ach_transfer）与收到的ACH转账（inbound_ach_transfer）操作完全相反，因此分为两个资源。这使得API更冗长，但长期来看更具可预测性。

团队承诺与实施

• 工程团队从一开始就承诺遵循此原则，这减少了后续设计决策时的认知负担。
• 示例：在处理电汇时，联邦储备系统要求的Input Message Accountability Data字段直接按原始名称暴露，而非尝试设计更“友好”的别名，这有助于用户理解其与底层系统的映射关系。

原则的适用性

• “无抽象”并非适用于所有API。选择抽象程度时，需考虑集成开发者的领域经验、投入精力等因素。
• 如果构建抽象化API，新增功能前需仔细考量；如果构建轻量抽象API，则应坚持原则，抵制添加抽象的诱惑。

Mac操作系统在多显示器支持方面存在诸多问题，主要包括以下几点：

1. 窗口记忆功能失效：MacOS无法可靠记住应用程序窗口在多显示器间的位置，重新启动应用时窗口经常重置到主显示器，需要用户手动调整。

2. 全屏应用处理不当：全屏应用（如游戏）无法正确处理多显示器，常出现副显示器未调暗、窗口错位或应用异常崩溃等问题。

3. Dock栏使用不便：当Dock设置为侧边时，仅出现在最外侧显示器上，跨越多显示器访问非常低效；置于底部时又容易与窗口交互冲突。

4. 菜单栏显示问题：菜单栏仅在当前活动显示器显示，由于视觉区分不明显，用户常无法确定其出现位置，影响操作效率。

5. 窗口错位与人体工学缺陷：窗口偶尔会错误地出现在非预期显示器；典型水平排列的多显示器设置导致颈部疲劳，且视觉焦点不在中心位置。

6. 工作分流困难：跨显示器分配工作内容体验不佳，第二显示器常沦为低频信息堆放区，实际利用率低。

文章作者尝试多种布局（包括对称水平、垂直堆叠等）后认为，Mac在多显示器管理上的根本缺陷数十年未有实质性改进。尽管存在第三方工具可部分缓解窗口管理问题，但系统级的Dock、菜单栏及人体工学设计缺陷仍无法解决。许多用户反馈外部显示器连接稳定性也是常见问题。

后续讨论补充：

• 作者建议尝试更大单显示器（如5k或6k显示密度），但指出当前超宽显示器缺乏足够像素密度。
• 不少用户推荐Display Maid、Rectangle Pro等第三方窗口管理工具。
• 作者不使用Spaces和全屏模式，因这些功能同样存在bug且不适合多显示器工作流。

DDC OLED：如何通过HDMI端口驱动微型显示器

本文记录了作者将一块小型OLED显示屏直接连接到HDMI端口的DDC（显示数据通道）上的实验过程。该实验利用了HDMI线缆中隐藏的低速I2C总线（用于显示器信息读取），无需微控制器或其他额外硬件，仅通过笔记本电脑的HDMI端口为OLED供电和传输数据。

核心原理与硬件连接

• DDC协议：原用于读取显示器支持的分辨率等信息，基于I2C总线。现代HDMI/DisplayPort接口均支持此协议。
• 接线：从破损HDMI线缆中提取关键引脚：SCL（时钟）、SDA（数据）、5V电源、DDC接地（GND）和HPD（热插拔检测）。
• 热插拔检测：HPD引脚需通过20kΩ电阻上拉至5V，以向电脑发出“已连接”信号。
• 电源与信号：HDMI端口的5V引脚可提供最大50mA电流，足以驱动OLED屏；SCL/SDA线已内置上拉电阻。

软件配置与测试

1. Linux I2C工具：
   • 加载i2c-dev模块，通过/dev/i2c-*访问I2C设备。
   • 使用i2c-tools中的i2cdetect扫描设备，结合ddcutil识别HDMI对应的I2C总线（如/dev/i2c-4）。
2. 初始化OLED：
   • 屏幕使用SSD1306控制器，通过发送初始化命令（如0xAF开启显示）激活。
   • 参考现有库代码完成初始化序列，包括电荷泵启用等必要步骤。
3. 数据传输优化：
   • SMBus限制每次传输最多32字节，可通过直接使用ioctl配置从设备地址绕过限制，提升帧率至5-10FPS。
   • 图像需转换为单色格式，并通过旋转和转置处理将水平像素字节转为垂直像素字节，以适配SSD1306的页面寻址模式。

实现为系统显示器

作者尝试将OLED屏变为Linux系统的扩展显示器：

1. xrandr虚拟显示器方案：
   • 通过扩展帧缓冲区大小（如--fb 2048x1080）并定义新监视器（--setmonitor）在扩展区域创建虚拟屏幕。
   • 限制鼠标移动范围至主监视器区域，避免光标进入无意义区域。
2. 帧缓冲捕获：
   • 使用python-xlib库捕获虚拟监视器区域的图像。
   • 通过XFixes（借助ctypes绑定）获取并叠加鼠标光标图像。
   • 将图像实时转换为单色格式并发送至OLED屏，实现约2-10FPS的桌面内容显示。

总结与局限

• 成果：成功通过HDMI的DDC通道驱动OLED屏显示系统桌面内容，无需外部控制器。
• 局限：帧率较低（依赖于I2C带宽），且通过xrandr创建直接关联输出的显示器尝试失败（可能因非标准分辨率被驱动拒绝）。
• 改进方向：可优化脚本仅发送变化部分以提升帧率，但作者因实用性有限未进一步深入。

该项目展示了利用现有接口中未被充分利用的潜力实现有趣硬件hack的可能性，完整代码已发布于GitHub。

Market Village：一个已消失但数字永存的地方

Market Village 位于多伦多北部 Steeles Ave. East 4390号，是一个已存在超过5年的购物中心。尽管现实中它已被拆除，但通过在线数字记录，人们仍能虚拟探索这个曾经的商场。

已拆除的现实

• 商场于2018年12月底被拆除，原计划由 Remington Group 开发重建为 Remington Centre，包括大型购物中心、夜间市场和公寓塔楼。
• 由于树木保护、邻居投诉、遗产保护等加拿大常见问题，建设项目延迟，5年后现场仍是一片荒地。
• 原开发计划中，商场部分可能已取消，改为更多住宅公寓；投资者可拿回本金，但无利息补偿。

数字存档与虚拟探索

• 尽管商场已消失，但 Google Maps、Yelp 和 360度照片 等在线资源仍显示其店铺信息、评论和内部布局，让游客误以为它仍存在。
• 通过 360度照片球，用户可点击蓝点虚拟“传送”到商场内部，体验如“2018年2月某个周三上午10点”的宁静场景。
• 这些数字遗存使商场成为一个“未绑定在时间中的地方”，允许人们进行虚拟探险。

商场特点与用户体验

• 原始设计为露天村庄风格，后加盖屋顶，保留了独特的“村庄”元素，色彩大胆、设计简单。
• 店铺多为普通人经营的实用生意，商品溢出到公共区域，营造出活跃氛围。
• 用户评论多样：正面评论包括对冷冻饺子等划算美食的推荐；负面评论涉及客户服务差、空间狭窄、店员态度粗鲁等。
• 示例：有顾客抱怨店员禁止拍照，或商场过道拥挤易撞到商品。

供应商转移与新生

• 大部分 Market Village 的供应商已北迁至附近的 Denison Centre，一个更现代的商场。
• 例如，Yan's Soy Foods（严氏豆制品）在新址经营，以豆制品闻名，评分达4.8星，其姜味布丁口感软滑、微甜带辣。
• 作者后来访问 Denison Centre，发现类似“Oomomo”的便利商店和拥有众多水族箱的鱼店，但面包店肉馅产品评价不佳。

结语

Market Village 虽已物理消失，但数字记录使其精神永存，并成为虚拟旅行和回忆的载体。读者可分享个人故事，并参考作者建议的“如何保存已消失的地方”指南，进行数字 preservation。

FCC以3:2投票恢复网络中立规则，禁止屏蔽与限速

美国联邦通信委员会（FCC）以3比2的投票结果，恢复了禁止互联网服务提供商（ISP）屏蔽、限速或优先处理特定网络流量的网络中立规则。

行业强烈反对，称其为“网络致命”

有线电视游说团体NCTA（互联网与电视协会）对FCC的决定提出强烈批评，称其为“市场干预”，并认为这将对美国弥合数字鸿沟的努力构成威胁。该团体指出，此举恰逢联邦政府正投入420亿美元，资助ISP向未服务和服务不足地区部署网络的计划。NCTA首席执行官迈克尔·鲍威尔表示：“该命令不仅不及时且不合法，它非但不能实现网络中立，反而有导致‘网络致命’的风险。”

法律争议焦点：宽带是否应被定义为电信服务

此次法庭斗争的核心在于FCC是否有权将宽带定义为“电信服务”。这是依据《通信法》第二章（Title II）对ISP实施公共运营商监管的必要前提。互联网服务提供商（ISP）希望，最高法院正在发展的“重大问题原则”能阻止FCC在没有国会明确指示的情况下对宽带进行此种分类。

对此，FCC民主党委员杰弗里·斯塔克斯反驳称，“重大问题审查”仅适用于“极端案件”，而本案远未达到这一标准。他强调，FCC数十年来一直对通信服务进行分类，1996年《电信法》已明确编纂了委员会继续履行此职能的权力。

共和党委员寄希望于最高法院推翻决定

FCC的共和党委员对民主党的多数决定进行了猛烈抨击。委员布伦丹·卡尔表示：“美国互联网在没有1930年代那种政府指令与控制式监管的情况下蓬勃发展。”他认为FCC的决策反复受到奥巴马政府（2015年）和拜登政府（今年）的政治压力，并缺乏可信的政策依据。

卡尔还批评法院赋予了FCC过多的权力，并希望当前最高法院能裁定，只有国会才有权决定是否将第二章规定适用于宽带。他总结道：“国会从未通过法律规定互联网应像公用事业一样受到严格监管，也没有授权FCC做出此类决定。行政部门向该机构施压，要求其声称拥有实际属于立法部门的权力。”

苹果发布八款面向设备端使用的小型AI语言模型OpenELM

苹果公司发布了名为OpenELM的八款小型AI语言模型，专为在设备端运行设计。

核心技术特点

• 上下文窗口：最大支持2048个token。
• 训练数据：基于公开数据集，包括去重后的RefinedWeb、PILE、RedPajama子集及Dolma v1.6子集，总计约1.8万亿token。
• 核心优化：采用“分层缩放策略”，更高效地分配各层参数，在减少计算资源消耗的同时提升模型性能。
• 性能对比：在类似规模的小型语言模型中，OpenELM的准确率比Allen AI的OLMo 1B模型提高2.36%，且所需预训练token数量减少一半。

开源与透明度

苹果同步开源了训练OpenELM所使用的CoreNet库，并提供了可复现的训练配方（包括模型权重文件）。苹果强调，此举旨在推动开放研究、确保结果可信，并支持对数据和模型偏见及潜在风险的调查。公司表示，发布源代码、模型权重和训练材料是为了“赋能和丰富开放研究社区”。

注意事项与未来应用

• 苹果提醒，由于模型基于公开数据集训练，其输出“可能存在不准确、有害、有偏见或令人反感的情况”。
• 这些模型尚未集成到消费设备中。但据传闻，预计在6月WWDC上发布的iOS 18更新可能包含利用设备端处理以保护用户隐私的新AI功能。为提升Siri能力，苹果也可能采用谷歌或OpenAI的技术来处理更复杂的、非设备端的AI任务。

Qwen1.5-110B 大语言模型发布

Qwen团队发布了其Qwen1.5系列中首个超过1000亿参数的模型——Qwen1.5-110B。该模型在基础模型评估中达到了与Meta-Llama3-70B相当的性能，并在聊天评估（如MT-Bench和AlpacaEval 2.0）中表现出色。

模型特点

• 架构：基于标准的Transformer解码器架构，采用分组查询注意力（GQA），提升模型服务效率。
• 上下文长度：支持32K tokens的上下文。
• 多语言：支持包括英语、中文、法语、西班牙语、德语、俄语、韩语、日语、越南语、阿拉伯语等在内的多种语言。

模型性能

基础模型评估

在与Llama-3-70B、Qwen1.5-72B等模型的基准测试对比中，Qwen1.5-110B表现出强大的竞争力。主要结果如下（部分数据）：

评估结果表明，110B模型的能力至少与Llama-3-70B模型相当，其性能提升主要源于模型规模的扩大。

聊天模型评估

Qwen1.5-110B-Chat在聊天基准测试中表现显著优于之前的72B模型：

一致的评估改进表明，即使后训练配方变化不大，更强大、更大的基础语言模型也能带来更优秀的聊天模型。

开发与使用

文章建议用户参考Qwen1.5博客，了解如何在多种框架和工具中使用该模型，包括Transformers、vLLM、llama.cpp、Ollama、LMStudio、SkyPilot、Axolotl、LLaMA-Factory等。

总结与展望

Qwen1.5-110B是Qwen1.5系列中最大、也是首个参数超千亿的模型。它展示了与最新SOTA模型Llama-3-70B竞争的性能，并显著优于自家72B模型。这表明在模型规模上仍有很大的扩展空间以提升性能。团队相信未来通过同时扩展数据和模型规模，可以达到最佳效果，并暗示下一代Qwen2系列即将推出。

本文是对谷歌公司此前声明的回应，主要围绕谷歌搜索算法更新与广告业务的关系展开。文章作者驳斥了谷歌关于“2019年3月核心更新并非回滚此前更新”的说法，并依据多家行业媒体、SEO工具公司的数据报告指出，此次更新使得大量在2018年更新中排名下降的网站排名提升，其行为模式与“回滚”高度相似。作者批评谷歌在此问题上的回应模糊且单方面否认，缺乏实质数据支撑。

文章的核心在于质疑谷歌搜索业务的独立性。作者引用了美国司法部反垄断诉讼中披露的内部邮件，指出谷歌广告部门高管（如Jerry Dischler）曾多次向搜索团队施压，要求采取措施增加搜索查询量以提升广告收入。邮件显示，时任搜索负责人Ben Gomes曾表示搜索业务“与金钱关系过于密切”，并担忧过度受广告业务影响。另一封邮件中，谷歌广告部门负责人Prabhakar Raghavan提到需要在“查询方面采取激进措施”。这些证据表明，尽管谷歌声称自然搜索结果不受广告系统影响，但其高层决策和团队协作中，广告业务对搜索业务施加了实质性影响。

谷歌在回应中引用的部分证人证词（如Ben Gomes和Jerry Dischler），被作者认为未能有效反驳上述邮件证据，反而通过“有机团队独立运作”等语义措辞回避了广告部门对搜索业务施压的根本问题。作者总结认为，谷歌未能以透明和有实质证据的方式澄清其搜索算法的运作及与广告业务的界限，其回应忽视了邮件中揭示的内部冲突和压力，这对SEO行业从业者和受算法影响的用户都是不公的。

本文介绍了在价格仅0.1美元的RISC-V微控制器CH32V003上实现神经网络推理的方案。该MCU资源极其有限，仅具备2KB SRAM和16KB Flash，并采用不支持乘法的RV32EC指令集。

为应对此挑战，作者选择MNIST手写数字识别作为测试任务，并采用量化感知训练方法优化神经网络。核心策略是使用极低比特数（如二值、三值、四位）的权重表示，以大幅压缩模型体积并避免乘法运算，推理过程仅通过加法和位移操作实现。

实验发现，模型精度与权重存储的总比特数成正比。例如，使用四位权重时，可通过增加权重数量来弥补比特数的减少。在优化训练流程（包括数据增强、余弦学习率调度等）后，作者实现了以下成果：

• 大模型：12KB权重，测试准确率超过99%，单次推理耗时13.7毫秒。
• 小模型：1KB权重（4512个二值参数），准确率达94.22%，推理仅需1.88毫秒。

整个推理引擎被集成到仅16KB Flash中，无需任何32位乘法指令。该项目证明，通过精心的模型量化和优化，神经网络可在资源极度受限的嵌入式设备上高效运行。