网页滚动劫持：破坏用户体验的十大原因

核心概念

滚动劫持（Scrolljacking）是指覆盖浏览器原生滚动行为，改变网页滚动速度、方向或效果的做法。常见的表现形式是动量滚动（平滑/惯性滚动）插件，它们虽被宣传为增强体验的功能，实则对互联网造成严重负面影响，破坏了自然、高效且可预测的浏览体验，通常会降低可用性、可访问性和性能。

权威研究支持

尼尔森·诺曼集团的一项可用性研究证实，大多数参与者因滚动劫持体验到至少轻度方向感错乱，部分用户将改变后的滚动行为误认为程序错误。任务导向型用户对此的容忍度显著低于探索型用户。研究还指出，由于滚动持续时间更长且屏幕更小，滚动劫持在移动设备上的问题更为严重。

十大负面影响

1. 违反用户预期
   用户熟悉从网页诞生以来的滚动模式。动量滚动插件用类似“糟糕电子游戏”的动画效果取代即时、可预测的移动，破坏肌肉记忆，让用户感觉在与页面“对抗”，而非自然互动。

2. 引发晕动症
   浮动、眩晕的动画效果可能使易感用户（数量远比想象中多）感到恶心，类似观看摇晃镜头。许多网站甚至不提供关闭选项，强制用户忍受不适。

3. 降低残障用户可访问性
   可访问性是一项基本权利。这些插件会干扰屏幕阅读器和键盘导航，为运动障碍或视觉受限用户引入时间延迟，可能导致网站无法使用，排斥了数百万用户。

4. 设备性能不一致
   相关插件在低端或旧设备上可能导致延迟、卡顿甚至崩溃，使得网站无法在各种硬件上流畅运行，违背了“网络应为所有人服务”的原则。

5. 损害高级用户效率
   追求效率和精度的高级用户（如快速浏览文档者）会被缓慢的动画拖慢工作流程，这相当于让赛车手以20英里/小时的速度行驶。

6. 增加页面加载时间
   插件增加了臃肿的JavaScript库、依赖项和动画渲染的CPU周期，导致页面加载变慢，尤其在移动网络或连接较差的地区，损害性能以换取美观。

7. 破坏浏览器原生功能
   现代浏览器已内置动量滚动设置。第三方插件可能覆盖或与这些原生功能冲突，导致自定义手势或系统级设置（如减少动态效果）失效。

8. 使滚动位置不清晰
   动画在操作与结果之间引入延迟，让用户难以精确定位页面位置，尤其在长页面中容易迷失方向，将快速导航变成猜谜游戏。

9. 增加维护开销
   插件需要定期更新以保持兼容性，且每次更新都可能引入新错误，为开发团队创造额外工作，消耗本可用于提升网站速度、安全性或优化的时间和资源。

10. 不尊重用户控制权
    覆盖默认滚动行为意味着开发者认为自己的设计优于用户偏好或需求，这种“我们比你更懂”的傲慢态度会损害用户体验，侵犯用户的自主权。

结论

滚动劫持和动量滚动插件如同“为了‘看起来酷’而把功能自行车改成独轮车”，它们增加不必要的复杂性，降低可用性并激怒用户。正如尼尔森·诺曼集团所言：“可用性是愉悦的基础。” 应放弃对滚动行为的改造，坚守原生、可预测、快速的滚动行为。核心建议是：别把滚动本身变成一个“问题”——就让人们正常地滚动。

文章摘要：Llama.cpp指南 – 从零开始在任何硬件上本地运行大型语言模型

本文详细介绍了如何使用Llama.cpp项目，在个人硬件上从零开始构建并本地运行开源大型语言模型。核心内容包括Llama.cpp的用途、环境准备、模型获取与量化、服务器启动以及性能优化配置。

背景与动机

作者起初对AI/LLM持怀疑态度，但在尝试ChatGPT后印象改观。然而，出于数据隐私和成本考虑（如避免API费用、处理敏感或商业数据），作者转向探索开源模型的本地部署方案。关键发现是量化技术（Quantization）能大幅减小模型体积和内存占用，使得在消费级硬件（包括CPU、AMD/NVIDIA GPU甚至树莓派）上运行LLM成为可能。

核心概念与硬件要求

• 硬件门槛低：运行LLM无需顶级硬件。一个支持AVX的现代CPU即可作为起点，但配备足够VRAM（≥8GB）的GPU（兼容NVIDIA、AMD、Intel）能显著提升性能。
• 性能因素：生成速度取决于硬件的矩阵运算性能和内存带宽，以及模型大小。通过选择适合硬件的模型量化级别，可在大多数配置上获得实时交互体验。
• 模型质量：通常模型参数越大，质量越高。本地运行通常限于200亿参数以下的模型（如7-8B模型），其质量虽与GPT-4等顶级模型有差距，但适用于通用任务和编程。
• 替代在线服务：本地LLM可通过提供OpenAI兼容API的llama-server，被支持自定义端点的工具调用。

Llama.cpp构建与准备

1. 环境准备：需要C++工具链（GCC/MSVC）、CMake、Ninja、Git和Python。推荐使用MSYS2环境构建，因其简化了依赖管理。
2. 从源代码构建：
   • 克隆仓库：git clone https://github.com/ggerganov/llama.cpp.git 并更新子模块。
   • 使用CMake配置构建（可自定义安装路径、关闭测试）：cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release ...
   • 编译并安装：cmake --build build --config Release -j X 和 cmake --install build。
   • 生成的二进制文件包括模型转换、量化、服务器、CLI和基准测试等工具。

获取与量化模型

1. 获取模型：从HuggingFace等平台下载模型（例如SmolLM2系列），注意选择Instruct微调版本以支持对话。需下载model.safetensors、config.json、tokenizer.json等文件。
2. 转换为GGUF格式：使用convert_hf_to_gguf.py脚本将HuggingFace格式模型转换为GGUF格式（一种为CPU高效推理设计的格式）。此步骤生成未量化的浮点模型文件。
3. 量化模型：使用llama-quantize工具对GGUF模型进行量化。有多种量化类型（如Q4_0, Q8_0），在模型大小、速度和质量间权衡。经验法则是选择在当前内存（VRAM/RAM）中可容纳的最大量化级别。量化显著减小模型体积（例如从BF16的3.4GB减至Q8_0的1.7GB），并可能提升生成速度。

运行与交互

1. 启动服务器：运行llama-server -m 模型文件.gguf，即可在本地启动一个Web聊天界面（默认http://127.0.0.1:8080）和OpenAI兼容的REST API。
2. Web界面功能：支持多轮对话管理、配置采样器参数（如温度、Top-K/P等），以控制输出多样性和质量。
3. CLI工具：llama-cli可用于直接进行文本补全或对话测试。
4. 基准测试：使用llama-bench测试不同硬件后端下的提示处理和文本生成速度。

配置与优化

• 服务器参数：可调整上下文大小（--ctx-size）、生成令牌数（--predict）、GPU卸载层数（--gpu-layers）等。
• 采样器详解：文章详细解释了多种控制生成行为的采样器，包括：
  • 温度：控制随机性。
  • Top-K/Top-P/Min-P：限制候选令牌范围。
  • DRY：防止无意义重复。
  • Mirostat：控制输出困惑度。
  • 重复惩罚：降低已出现令牌的概率。
• 系统提示：通过设定详细的系统消息，可以显著引导LLM的行为和输出质量。

高级构建：启用GPU与CPU优化

• GPU后端：为提升性能，可构建支持Vulkan（通用，兼容多品牌GPU）、CUDA（NVIDIA）或ROCm（AMD）等后端的版本。Vulkan构建相对简单，能带来数倍的性能提升（如示例中提示处理速度提升5倍以上）。
• CPU指令集优化：可通过CMake标志（如GGML_AVX512）启用特定CPU指令集（如AVX512、FMA）以优化CPU推理性能。

模型推荐与资源

• 寻找模型：推荐使用LLM Explorer等网站搜索和比较模型。
• 推荐模型：文中提及并推荐了Llama 3.1/3.2 8B、Phi 3.5、Gemma 2 9B和Qwen/CodeQwen 2.5等系列的开源模型。

总结而言，本文是一份实用的教程，指导用户利用Llama.cpp，在个人设备上以较低的硬件门槛私密、灵活地运行和实验开源大型语言模型。

文章总结：

Hetzner宣布对其在美国阿什本和希尔斯伯勒机房的云服务器（CCX和CPX系列）及负载均衡器产品进行价格调整，同时大幅降低包含的流量额度。

主要变化：

• 价格上涨：自2024年12月1日起（新客户），2025年2月1日起（老客户），产品价格将上调。涨幅不等，最低约4.17%（如CCX33），最高达27.52%（如CPX21）。
• 流量锐减：所有产品包含的免费流量额度均大幅下降，平均减少约88.19%。例如，原先许多产品包含20TB流量，调整后降至1TB至8TB不等。

Hetzner的官方理由： 公司称此次调整是为了实现全球客户之间的“公平”。他们表示，之前低资源使用客户实际上在补贴高资源使用客户，新价格结构将使定价更贴近实际资源使用情况，力求为客户提供最佳性价比。

客户与作者的反应：

• 文章作者质疑此解释，认为价格大幅上涨而带宽骤降难以理解，并指出许多客户正是看中Hetzner此前慷慨的带宽政策。
• 作者个人实例：其6台CPX21服务器月均使用流量为0TB，但调整后每月费用将从42.30欧元增至53.94欧元，而包含流量却从20TB降为2TB，认为这对其“低使用”用户并不公平。
• 将公告发布在美国感恩节当天也受到批评。

关键细节：

• 流量超额资费不变。
• 过渡期内，控制台和API将显示新价格，但旧产品的账单直至生效日前仍按旧价执行。
• 若不接受调整，用户可随时取消相关产品。

全球轮胎每年产生约600万吨微塑料碎片，占环境中微塑料污染的28%。这些由轮胎磨损产生的颗粒含有数百种化学添加剂，例如锌氧化物对水生生物高毒，而6PPD在环境中转化为6PPD-醌会导致鱼类大量死亡。重型车辆（包括电池较重的电动汽车）会加速轮胎磨损并产生更多污染。

当前轮胎颗粒常被归入一般微塑料类别，未被视为独立污染类型。研究者建议将其明确分类，以推动针对性研究和政策制定。例如，可通过“污染者付费”原则对车辆实施重量税，激励轻量化设计和绿色消费选择。同时，需要开发环保轮胎材料替代有害添加剂。

尽管欧盟的Euro 7排放标准为控制轮胎排放提供了基础，但全球范围内仍缺乏协调措施。文章呼吁建立类似气候变化领域IPCC的专门科学政策小组，并将轮胎污染纳入当前谈判中的全球塑料条约。标准化监测方法和更深入的生态影响评估（如颗粒扩散与毒性研究）也至关重要。

面对每年生产超过20亿条轮胎且车辆日益重型化的趋势，若不及时采取针对性行动，环境负担将持续加剧。轻量化征税和环保轮胎创新不仅能减少污染，也有助于推动交通系统可持续发展。

2024年运行1M并发任务内存消耗基准测试摘要

测试概述

本文在2024年末重做了并发任务内存消耗基准测试，旨在比较最新版本的编程语言和运行时在处理大量并发任务时的内存效率。测试焦点从多线程转向协程，所有代码基于相同场景：启动N个并发任务，每个任务等待10秒后退出，程序在所有任务完成后结束。

测试语言与环境

• 测试语言/运行时：Rust（使用tokio和async_std库）、C#（包括NativeAOT编译）、NodeJS、Python、Go（goroutines）、Java（虚拟线程，包括GraalVM native-image版本）。
• 环境：硬件为Intel Core i7-13700K，操作系统Debian GNU/Linux 12，各语言使用最新稳定版本（如Rust 1.82.0、Go 1.23.3、Java OpenJDK 23等）。程序以发布模式运行，禁用了国际化支持。

关键结果

基准测试通过逐步增加任务数量（从1个到1M个）评估内存消耗：

1. 最小内存占用（1个任务）：
   静态编译的语言（如Rust、C# NativeAOT、Go）内存占用最低，其中Go表现最佳。Java GraalVM native-image内存消耗高于其他静态编译语言。运行在托管平台或解释器上的语言（如NodeJS、Python）内存占用较高。

2. 10K任务：

   • Rust和C# NativeAOT内存增长最小，保持高效（C# NativeAOT仅约10MB）。
   • Go的内存消耗显著增加，高于预期；Java GraalVM native-image比Go更轻量。
   • 意外发现：静态编译的Go和Java GraalVM native-image内存消耗高于运行在VM上的C#。

3. 100K任务：

   • C# NativeAOT表现突出，内存消耗甚至低于Rust，成为最优选择。
   • Rust仍保持高效，但被C#超越。
   • Go被Rust、Java、C#和NodeJS超越，显示内存效率低下。

4. 1M任务：

   • C# NativeAOT彻底胜出，内存消耗最低，成为性能最强者。
   • Rust次之，但内存消耗高于C#。
   • Go表现最差，内存消耗是C#的13倍以上，且是Java的2倍以上，颠覆了“JVM内存占用高、Go轻量”的传统认知。

主要发现

• 语言改进：.NET与NativeAOT结合后内存效率大幅提升，与Rust竞争；Java GraalVM native-image也展现出高效性。
• 协程效率：Rust的异步运行时（tokio/async_std）在并发任务中内存增长缓慢，适合大规模并发。
• Go的劣势：尽管goroutines被视作轻量，但在大量并发任务下内存消耗显著高于其他语言，表现不佳。
• 通用趋势：高并发任务即使操作简单也会消耗大量内存，不同语言运行时存在权衡：一些在小规模任务中轻量，但扩展性差；其他则在大规模任务中保持高效。

结论

基准测试显示，2024年的语言运行时在并发内存效率上有显著变化。C# NativeAOT和Rust成为内存效率的领先者，而Go的goroutines在大规模并发下资源消耗不高效。选择语言时需考虑任务规模和内存约束。

乐高界面面板的用户体验设计

文章通过分析52种乐高积木装饰面板，探讨了复杂物理界面设计的基本原理，重点关注两个核心挑战：区分输入功能和组织界面布局。

区分输入功能

良好的输入区分能防止用户操作错误。历史案例表明，相似的控制元件（如二战轰炸机上形状相同的起落架与襟翼开关）会导致灾难性误操作。解决方案是引入编码系统，文章提出六种基本编码方式：

• 尺寸、形状、颜色：最基础且高效的区分方法。
• 纹理：便于盲操作，尤其适用于精密控制旋钮。
• 位置：利用符合人体工程学的默认手部位置来区分主次功能。
• 操作：通过不同的操作动作（如旋转、推拉）来强化功能隐喻（如起重机操纵杆向上推以提升吊臂）。

组织界面布局

在有效区分输入的基础上，清晰的组织结构能帮助用户建立准确的心理模型。文章对比了多种组织策略：

• 基于系统原理：类似苏联工厂控制台，将所有相关输入输出集中呈现，形成完整系统示意图。适用于理解陌生系统的内部工作原理。
• 基于功能：将控制同一产品功能的开关和指示灯归为一组（如汽车空调控制区）。这是最常见、最直观的组织方式。
• 基于操作：将操作方式相似的开关集中排列，即使它们控制不同功能。
• 基于技术：因技术限制而将不同技术的界面分开（如触摸屏与物理按键的分离）。
• 基于使用场景：从用户任务流程出发组织界面（如按“开机、装载、扫描”等步骤分组），对操作员最友好，但可能增加系统复杂度。

总结

文章通过乐高面板这一简化模型，阐明了物理界面设计的核心原则：首先运用多种编码方式清晰区分不同输入的功能，其次根据具体使用场景和系统特性，选择合适的组织策略来构建直观、高效的界面布局。不存在单一的“最佳”组织方式，设计师需在系统逻辑与用户任务之间取得平衡。最后展示的几个优秀乐高面板范例，均体现了清晰的视觉布局、明确的输入区分和简洁的组织结构。

分类账构建中的关键教训

金融科技公司必须确保资金追踪准确无误，但初创公司常因急于求成而犯下严重错误。作者分享了在股票交易平台工作的经历：团队采用单式记账系统，导致交易中丢失几分钱（称为“dancing cents”）。这引发用户愤怒，影响公司增长，最终被迫手动补偿错误。

单式记账系统仅记录资金流入流出，无法追踪资金流动原因，导致调试困难。例如，当交易涉及未来资产（如银行转账延迟）时，系统难以处理待处理金额，回滚错误也复杂。双式记账系统则通过同时记录资金来源和去向，提供完整上下文，确保每笔资金都被追踪，便于问题诊断。

双式记账系统的核心数据模型包括三个实体：

• 账户：代表资金视角（如用户账户、公司账户），分为正常贷方余额或正常借方余额。
• 条目：表示资金流动，总是成对出现（贷方和借方），状态为待处理、丢弃或过账。金额应独立于方向（避免使用负数）。
• 交易：确保条目成对平衡，支持部分失败和补偿操作，适用于Saga模式。

系统设计需考虑会计系统和工程系统的平衡：会计系统需高可用性和低延迟以支持报告和分析；工程系统需强一致性以确保数据准确。扩展分类账具有挑战性，但正确构建可成为业务增长的关键。

作者推荐了多份资源，包括Anvil、Martin Kleppmann和Modern Treasury的指南，以及Uber、Square等公司的实现案例，帮助开发者构建未来-proof的分类账系统。

• 案件进展：2024年11月27日，纽约联邦法官Jed Rakoff裁定The Intercept针对OpenAI的《数字千年版权法》（DMCA）核心指控可继续审理，但驳回了The Intercept指控OpenAI“故意分发删除管理信息的文章”以及针对微软的所有指控。

• 核心指控：The Intercept主张OpenAI在训练ChatGPT时使用其文章数据集，并移除了DMCA保护的版权管理信息（如作者名称、使用条款、标题），涉嫌违反DMCA。

• 案件背景与意义：

  • 这是首例不依赖版权侵权（需在美国版权局注册）而基于DMCA的数字新闻出版商诉讼突破驳回动议阶段。
  • 传统版权侵权诉讼要求作品事先注册，但大多数数字新闻出版商因成本或流程繁琐未完成注册。美国版权局2024年8月新增批量注册规则，但对多数出版商而言已错过时机。
  • 该策略为未注册版权的数字出版商提供了新的法律路径。

• 相关案件对比：

  • 此前，Raw Story和AlterNet基于类似DMCA的指控被另一法官驳回，但法官允许其提交修改后的诉状。该诉状已于2024年11月底提交，指控OpenAI故意移除版权管理信息以训练ChatGPT。
  • The Intercept案中存活的DMCA指控与Raw Story等修改后的指控可能相似，但不同法官可能做出不同裁决。

• 双方回应：

  • OpenAI表示其模型基于公开数据训练，遵循“合理使用”原则。
  • The Intercept的律师认为，此裁决使缺乏版权注册的数字出版商也能基于DMCA起诉OpenAI，可能鼓励其他出版商采取类似行动。

• 潜在影响与挑战：

  • 若以每篇被使用文章计算，每项DMCA侵权可索赔2500美元，累计金额可能巨大。
  • 时间流逝可能使新诉讼面临诉讼时效问题，但该裁决标志着法律策略的突破。
  • 尚不清楚其他出版商会否跟进，但代理律所认为该DMCA主张具有普遍适用性。

Prometheus 3.0 发布概要

重大里程碑：Prometheus 3.0 是继七年前2.0版本后的首个主要版本，标志着该项目从早期采用者工具发展为云原生监控标准组件的重要一步。

主要新功能与改进

1. 全新用户界面（UI）

   • 默认启用，采用现代化技术栈完全重写，界面更简洁、现代。
   • 新增类似 PromLens 的树形视图等特性，便于未来维护。
   • Beta 版后更新支持 UTF-8 指标和标签名。用户可通过特性标志临时启用旧 UI。

2. Remote Write 2.0

   • 全新协议版本，原生支持元数据、范例、创建时间戳和原生直方图。
   • 采用字符串 interning 减少数据包大小及压缩/解压的 CPU 消耗。
   • 改进了部分写入的处理，能向客户端提供更多细节。

3. 全面的 UTF-8 支持

   • 默认允许指标和标签名称使用所有有效的 UTF-8 字符（标签值在 2.x 已支持）。
   • 需确保指标生产端配置正确；不兼容时会使用下划线替换的传统转义方式。
   • PromQL 查询可使用新的引号语法或手动指定 __name__ 标签来查询 UTF-8 指标。
   • 目前仅 Go 客户端库已更新支持，其他语言将陆续跟进。

4. OTLP（OpenTelemetry 协议）支持增强

   • OTLP 摄取：可配置为原生的 OTLP 指标接收端点（/api/v1/otlp/v1/metrics）。
   • UTF-8 规范化：得益于 UTF-8 支持，可直接存储和查询 OpenTelemetry 指标，无需令人困扰的名称转换（如将点号改为下划线），减少了用户和工具的困惑。
   • 实验性地支持多种翻译策略以处理 OTLP 摄取。

5. 原生直方图（Native Histograms）

   • 一种实验性的高效、低成本指标类型，是经典直方图的替代方案。
   • 基于指数增长预设桶边界，无需手动选择桶边界。
   • 需通过 --enable-feature=native-histograms 启用，部分特性（如文本格式、访问函数）仍在设计中。

破坏性变更与迁移

• 此版本包含少量清理长期问题的破坏性变更，涉及特性标志、配置文件、PromQL 和抓取协议。
• 用户应阅读官方迁移指南，检查自身配置是否受影响。
• 升级建议：强烈建议先升级至 v2.55，再升级至 v3.0。支持从 v3.0 回滚至 v2.55，但不支持回滚到更早版本。

性能表现

• 相比旧版本（2.0.0 和 2.18.0），3.0.0 在 CPU 和内存使用效率上有显著提升。
• 性能测试基于相同的 PromQL 查询、配置和环境，突显了核心功能的向后兼容性和稳定性。

未来展望

• 治理模式更新，更具包容性。
• 进一步提升 OpenTelemetry 兼容性与功能。
• 在 Prometheus 治理下推动 OpenMetrics 2.0。
• 提升原生直方图的稳定性（支持自定义桶）。
• 持续优化性能。
• 为更多 SDK 和工具添加 UTF-8 支持。

获取与反馈

• 可从官方渠道下载二进制文件和容器镜像进行试用。
• 鼓励社区提供反馈和参与贡献。

Nodezator：通用 Python 节点编辑器

Nodezator 是一个通用的 Python 节点编辑器，它是一款桌面应用程序，通过可视化连接 Python 函数（以及一般的可调用对象）来生成灵活的参数化行为、数据、应用或代码片段。

核心定义与特性

• 它是什么：一个开箱即用、多功能的 Python 节点式界面。用户可以在其基础上定义自己的节点，并将它们分发给他人下载、安装和使用。分发方式灵活，既可自行分发，也可作为 Python 库通过 PyPI 分发。使用 PyPI 分发具有显著优势，因为它完全依赖 Python 软件基金会为所有 Python 用户免费提供的现有基础设施，安全可靠。
• 它不是什么：Nodezator 不是一个框架，因此不能用它来创建你自己的节点式界面。
• Python 集成：它使节点式编程成为可能，并能与常规的 Python 文本编程无缝集成。用户可以将节点布局导出为普通的 Python 代码，确保工作流不会过度依赖该应用程序本身。

节点定义与兼容性

创建节点非常简单直接：只需定义一个函数。Nodezator 会自动将 Python 函数转换为节点。用户可以将函数定义存储在本地磁盘的任何位置，启动 Nodezator 后提供路径即可加载。唯一的组织要求是将节点定义保存在独立的文件中并存放于一个文件夹内。

该工具兼容性极强，能够将任何 Python 可调用对象（包括类、方法等，甚至是用 C 语言编写的）转换为节点。这意味着 PyPI 上数十万个项目中的任何可调用对象几乎都可以被转换。

技术栈与维护

Nodezator 使用纯 Python 编写，基于 pygame-ce 库和部分 numpy 库开发。项目主要由开发者 Kennedy Richard Silva Guerra 个人维护，但这是一个严肃且活跃的项目，每年都会有几次重大版本发布。推荐中级 Python 用户使用，非程序员可在中级用户帮助下设置无代码/低代码工作流。

主要功能

1. 轻松集成第三方库：可以轻松地将第三方库（如 Pillow、matplotlib、CadQuery）中的可调用对象转换为节点并使用。
2. Nodezator 就是 Python：任何图表都可以直接导出为 Python 代码，极大地降低了对应用的依赖。与其他应用相比，将代码库迁移到纯 Python 或其他 Python API 的难度大大降低。
3. 套接字邻近检测：创新的交互功能，用户无需精确点击套接字即可拖出连接线或进行放置，只需鼠标足够靠近即可，大大提升了编辑效率。
4. 变量参数支持：支持定义具有可变参数（*args 和 **kwargs）的节点，这些节点会为每个接收的连接创建额外的套接字。
5. 专用小部件：例如，用于输入整数和浮点数的输入框，不仅支持鼠标拖拽增减和简单算术表达式，还支持使用一些 Python 内置函数和标准库模块的函数。
6. 函数式编程支持：节点不仅能表示对函数的调用，还可以表示对函数本身的引用（可调用模式）。这解锁了高阶函数等函数式编程能力。

节点管理与分发

• 创建：节点来源于组织在文件夹（称为“节点包”）中的 Python 脚本。
• 加载：通过指定文件夹路径即可加载。
• 分发：用户可以选择：
  • 在本地保留节点包。
  • 通过自己的方式分享。
  • 上传到 PyPI 作为 Python 包，供他人使用 pip 安装。
• 发现：有一个“节点画廊”网站，用户可以在其中搜索、下载节点包，也可以提交自己的节点包信息。

安装与使用

• 通过 pip 安装：运行 pip install --upgrade nodezator。安装后可通过 nodezator 或 python -m nodezator 启动。
• 作为独立应用使用：需要系统已安装 Python 以及 pygame-ce 和 numpy 库。下载源代码中的 nodezator 文件夹后，在其父目录运行 python -m nodezator 即可启动。
• 用户手册：在应用程序菜单的“帮助”中可打开，是最准确、最新的版本，网络版由其导出。

社区与支持

• 贡献：欢迎贡献，建议将拉取请求提交至 develop 分支。项目具备基于 GUI 自动化的系统测试能力。
• 问题反馈：
  • 紧急/关键问题（导致崩溃或功能失效）请提交至 GitHub Issues。
  • 次要问题、建议、反馈等请使用 GitHub Discussions。
• 联系：可通过 Twitter/X、电子邮件或 Indie Smiths 的 Discord 服务器联系开发者。
• 支持：可通过 Patreon、GitHub Sponsors、Liberapay 或 Ko-fi 进行捐赠支持。

许可与代码质量

• 许可证：Nodezator 源代码采用 The Unlicense 许可，贡献给公共领域。部分字体和图标也采用公共领域许可。
• 代码质量：项目已开发超过4年。部分代码经过多次审查和重构，设计精细且注释详尽，模块行数通常控制在500行左右，并有少量单元测试。较新的代码部分可能尚未完全优化，未来会进行重构和注释。

澳大利亚议会通过全球首部禁止16岁以下未成年人使用社交媒体的法律。该法律适用于TikTok、Facebook、Snapchat、Reddit、X和Instagram等平台，若系统性未能阻止未满16岁用户拥有账户，平台将面临最高5000万澳元（约合3300万美元）的罚款。法案在参议院以34票对19票、众议院以102票对13票获得通过。

核心内容与时间框架：

• 平台有一年时间制定执行禁令的具体方案，之后罚款才会生效。
• 修订条款加强了隐私保护：平台不得强制用户提供护照或驾照等政府签发的身份证明，也不得要求通过政府系统进行数字身份验证。

支持方观点：

• 总理安东尼·阿尔巴尼斯表示，该法律响应了家长对网络危害的担忧，并强调平台有“社会责任”优先保障儿童安全。
• 反对党参议员玛丽亚·科瓦契奇称该法案并非激进，而是必要之举，旨在要求社交媒体公司采取合理措施识别并移除未成年用户。
• 在线安全倡导者索尼娅·瑞安（其15岁女儿因网络诈骗遇害）称此法是“保护儿童免受网络严重伤害的重要里程碑”。

争议与反对意见：

• 儿童福利和心理健康专家警告，禁令可能孤立弱势青少年（如农村社区和LGBTQI群体），剥夺他们通过社交媒体寻求支持的机会。
• 批评者指出立法过程仓促、缺乏审查，可能侵犯所有用户的隐私，削弱家长决策权，并将儿童推向暗网等更危险渠道。
• 数字行业组织DIGI表示，该法案在一周内通过，导致社区和平台对具体执行要求“一无所知”。
• 社交媒体平台（如Meta、Snapchat）批评法案匆忙通过，未充分考虑现有年龄验证措施和证据，并对实施细节提出质疑。但平台均表示将在一年过渡期内配合监管部门（如电子安全专员）工作。

豁免与执行：

• 健康和教育类服务（如YouTube、Messenger Kids、WhatsApp、Kids Helpline、Google Classroom）可获豁免。
• 批评者认为政府可能为迎合家长关切（尤其在大选前）而推动立法，但此举效果存疑。

Glojure 是一个基于 Go 语言实现的 Clojure 解释器，其核心特点是“托管语言”：所有 Go 值都可作为 Glojure 值使用，反之亦然，从而实现了与 Go 标准库的无缝互操作。

主要特点

• 托管语言：Glojure 与 Go 的值系统双向互通，可直接调用 Go 库。
• 早期阶段：目前处于开发早期，可能存在错误、功能缺失和性能限制，在 v1 版本前不保证向后兼容。
• 两种使用方式：
  1. 独立命令行工具 (glj)：提供 REPL 交互环境，可直接执行 Clojure 表达式或脚本文件。
  2. 嵌入 Go 应用程序：作为脚本语言集成到 Go 程序中，支持添加脚本化配置、插件扩展，并实现 Go 与 Clojure 的混合编程。

安装与使用

• 要求：Go 1.19 或更高版本。
• 安装：通过 go install github.com/glojurelang/glojure/cmd/glj@latest 安装。
• 示例：
  • 启动 REPL：glj
  • 执行表达式：glj -e '(println "Hello")'
  • 运行脚本文件：glj script.glj

互操作性

• 内置支持众多 Go 标准库包（如 net/http、fmt、os 等）。
• Go 包名中的 / 会被转换为 : 以避免歧义（例如 net/http 在 Glojure 中为 net:http）。
• 可通过生成“包映射”来暴露自定义 Go 包，实现更灵活的扩展。

嵌入式使用

• 在 Go 中调用 runtime.ReadEval 执行 Clojure 代码。
• 可通过 glj.Var 在 Go 和 Clojure 之间传递函数。
• 允许控制执行环境（如自定义 I/O 或沙盒）。

与原生 Clojure 的差异

• 数字类型：例如 Go 的 int64 对应 Clojure 的 long，float64 对应 double。
• 字符：Go 的 rune（32位）对应 Glojure 的 Char，而 JVM 的 char 是 16 位。
• 大数类型：BigInt、BigDecimal 等类型在 Glojure 中对应 Go 的 *big.Int、*big.Float 等。

与其他 Go 实现的 Clojure 对比

Glojure 的独特优势在于其托管特性和可扩展的互操作性，使得它能够充分利用 Go 生态，同时提供 Clojure 的编程体验。

阿里巴巴发布开源推理模型QwQ-32B-Preview，成为OpenAI o1模型的公开挑战者。该模型由阿里Qwen团队开发，拥有325亿参数，支持约32000词的上下文长度。在AIME和MATH等测试中，其表现优于OpenAI的o1-preview和o1-mini版本。

QwQ-32B-Preview具备推理能力，可解决逻辑谜题和复杂数学问题，通过内部自我核查机制减少错误，但可能伴随响应延迟。模型仍存在局限性，如意外切换语言、陷入循环或在常识推理任务中表现不足。

该模型在Hugging Face平台开源，采用Apache 2.0许可证，支持商业应用。但仅部分组件公开，无法完全复现或深入解析系统。作为中国公司产品，其回应需符合监管要求，在涉及政治敏感话题（如台湾问题、天安门事件）时采用特定立场或回避。

当前AI领域对推理模型的关注度提升，因传统“扩展定律”（通过增加数据和算力提升性能）的有效性受到质疑。测试时计算（推理计算）成为新方向，谷歌等大厂正加大投入研发相关模型。

事件概述

比亚迪（BYD）推出了一款面向电网规模的钠离子电池储能系统（BESS）产品。该产品采用钠离子电池技术，标志着该公司正式进入钠离子储能赛道。

钠离子电池技术优势与局限

主要优势：

• 资源与成本： 钠元素自然丰度高，理论上制造成本低于锂离子电池。
• 性能： 具有更高的充放电速率、更宽的工作温度范围、更长的循环寿命。
• 安全性： 安全性得到改善，火灾风险相对较低。

当前局限：

• 能量密度较低： 比亚迪的新产品在一个20英尺标准集装箱中仅能容纳2.3MWh的容量，远低于目前主流锂离子BESS产品5MWh及以上的水平。这限制了其在空间要求高的场景（如电动汽车）中的应用，但对固定式储能的影响相对较小。

行业背景与市场趋势

钠离子电池因其材料成本低和安全性特点，被业界视为对锂离子电池供应链波动（如2021-2022年）及偶发安全事故的一种有潜力的替代方案。业内普遍认为，随着制造规模扩大，钠离子电池的成本优势将更加明显。

中国市场与比亚迪布局

• 领先实践： 中国已建成目前全球最大的钠离子电池储能系统，规模为100MW/200MWh，其中一半已并网运行。
• 企业投入： 中国企业正在该技术领域进行大量投资，技术提供商包括中国公司众钠电池（HiNa Battery）。
• 比亚迪规划： 比亚迪于2024年1月在徐州开工建设一座年产能达30GWh的钠离子电池工厂。作为全球最大的电动汽车制造商，比亚迪同时也在向锂离子电池和储能系统生产领域扩张，已成为该领域的主要参与者之一。

美国及全球进展

• 美国政策支持： 美国能源部（DOE）上周宣布投资5000万美元，设立“低成本富集钠离子储能（LENS）联盟”，旨在开发高能量、长寿命的钠离子电池技术。该联盟由阿贡国家实验室领导，并联合多个国家实验室。
• 美国初创融资： 美国钠离子BESS初创公司Peak Energy近期完成了由TDK Ventures领投的5500万美元A轮融资，显示了资本市场对该领域的关注。

这是一个基于Next.js、WebRTC和PeerJS构建的实时浏览器屏幕共享应用。用户可以创建或加入房间，与他人即时分享屏幕。

✨ 主要功能

• 实时共享屏幕与音频。
• 基于房间的分享系统。
• 支持跨浏览器。
• 简洁直观的界面。

📱 设备支持

• 主持分享：仅支持桌面/笔记本浏览器。
• 观看：可在所有设备（桌面、平板、手机）上运行。

🌐 浏览器支持

重要提示：在Chrome或Edge中，用户必须选择共享标签页选项才能使音频共享正常工作。

🛠️ 技术栈

• Next.js：React框架。
• PeerJS：WebRTC抽象库。
• Tailwind CSS：用于样式。
• shadcn/ui：UI组件。

🚀 快速开始

1. 克隆仓库：git clone https://github.com/tonghohin/screen-sharing.git
2. 进入项目目录并安装依赖。
3. 启动开发服务器。

📦 部署

• 云平台：可部署在任何支持静态站点托管的云平台上。
• 自托管：可使用Docker进行自托管，命令为： docker run -p 3000:3000 -d --name screen-sharing ghcr.io/tonghohin/screen-sharing:latest

👥 参与贡献

欢迎参与贡献，详情请阅读项目的贡献指南。

📄 许可证

该项目基于MIT许可证授权。

Ninja 是作者 Evan Martin 于 2011 年发布的一个构建系统，旨在与 Make 竞争，并已成为其最成功的开源项目，被 Chrome、Android、Meson 以及许多使用 CMake 的项目采用。

作者的核心反思是：在软件开发中，代码不如架构重要，而架构又不如社会因素（如协作、沟通和社区动态）重要。他分享了关于技术、架构设计、开源维护和个人教训的见解。

技术方面：Ninja 专注于速度，尤其是大型项目的增量构建。它通过精心优化（如字符串 intern、单次 stat 调用等）实现快速执行。其功能相对简单：解析构建文件、检查文件时间戳并并行执行命令。尽管有许多重写尝试，但尚无更快实现。

架构见解：

1. “汇编器”隐喻：Ninja 的关键设计是将其视为低级执行器，只负责构建动作图，而将高级逻辑（如文件查找）留给外部生成器程序。这迫使开发者明确成本，并允许 Ninja 保持简单快速。
2. 图表示：使用文件与命令之间的二分图，更好地模拟了构建过程。
3. 依赖日志：为高效处理 C 头文件依赖而设计的紧凑格式。
4. 端到端 / 崩溃唯一设计：每次构建都从头开始，利用内核缓存，避免了维护持久化进程的复杂性，同时专注于极致的速度优化。
5. 并行执行默认值：Ninja 默认并行执行命令，这无意中促进了更安全、通常更快的构建实践。

速度与性能：作者极度关注迭代构建速度对程序员体验的影响。Ninja 输出简洁（通常仅一行），专注于减少感知延迟。然而，他指出“快速”有多种含义，并警告小型项目可能感受不到优势。Ninja 意外地通过减少自身 CPU 占用，有时也提高了端到端构建速度。

社区与扩展：

• CMake 集成：主要由贡献者 Peter Collingbourne 完成，这对 Ninja 的广泛采用至关重要。
• Windows 支持：尽管支持 Windows 存在技术挑战且平台缺乏自由工具，但由于其庞大的用户基数，早期吸引了大量 Windows 用户。

相关工作：作者后悔未事先充分研究构建系统领域。他提到了 Bazel 的“动作图”概念、增量计算研究（如 Jane Street 的博客）以及学术论文《Build Systems à la Carte》。

开源维护者经历：作者坦言维护开源项目压力大，常常面临苛刻的需求、威胁性分叉和缺乏感谢的用户。他认为开源精神已从“平等共享”转变为更商业化的“客户-提供者”关系，这让他感到失望。他最终将项目移交给其他维护者。

总结：Ninja 的成功源于其专注的速度、巧妙的架构分离（“汇编器”模型）以及幸运地与 CMake 等生态系统集成。然而，其技术可扩展性存在局限，而作者的开源经历也揭示了维护大型流行项目的情感与社交成本。

PR过程对士气和生产力的负面影响

代码审查旨在提升代码质量和分享知识，但当PR评论数量达到数百条时，表明过程存在严重问题。例如，一位新开发者首次贡献就面临超过300条评论，其中大多是风格上的挑剔，这不仅无效，还具有毒性。

问题原因

• 缺乏自动化工具：团队仍为间距、命名约定或行长度争论，未使用如Prettier、ESLint或Black等工具自动处理，浪费时间。
• 风格过度关注：PR审查应聚焦于发现错误和提升可维护性，而非强制执行未文档化或标准化的任意风格规则。
• 错误管理指标：管理层有时将PR评论数量作为绩效指标，鼓励无价值评论；质量应优于数量。
• 有毒文化：一些团队将代码审查用作权力游戏，挑剔琐碎细节，使团队难以接近，尤其损害新成员士气。

解决方案

• 自动化琐碎事项：使用linters和auto-formatters消除90%的风格争论；可自动化的内容不应在审查中讨论。
• 聚焦重要方面：PR审查应专注于功能、可维护性和架构，而非间距或函数长度等细节。
• 定义并坚持风格指南：如果关注代码风格，团队应书面制定指南，并通过工具强制执行，而非无休止的PR辩论。
• 改进指标：停止奖励无意义活动；关注减少错误、加快部署时间或提高团队满意度等指标。

结论

数百条PR评论是危险信号，而非荣誉标志，表明过程已损坏。修复文化和工具，专注于高质量、可维护的软件开发，其他都是干扰。

Vince 是一个开源的自托管网站分析工具，旨在替代 Google Analytics，并专注于为单实体自托管场景提供核心功能。该项目源于对 Plausible Analytics 的 Go 语言移植，但更为精简和独立。

核心特性与功能

• 隐私友好：不使用 Cookie，符合 GDPR、CCPA 和 PECR 等隐私法规。
• 零依赖：提供单一可执行文件，无需额外运行时依赖，易于部署。
• 自动 TLS 支持：原生支持 Let's Encrypt，可自动配置 HTTPS。
• 全面的跟踪能力：支持出站链接跟踪、文件下载跟踪、404 页面跟踪以及自定义事件跟踪。
• 灵活的访问控制：支持公开仪表盘、可设置密码保护的唯一共享链接，确保数据访问的安全性。
• 无限制扩展：允许管理无限数量的网站，并且事件数量可根据可用资源进行扩展。
• 数据可视化：支持时间段对比、以及按城市、来源、页面和设备进行数据细分。

安装与部署 Vince 提供多种安装方式，包括通过安装脚本（适用于 macOS 和 Linux）、Docker 镜像或 Helm chart 进行部署。安装后，可通过命令行创建管理员账户并启动服务器。

与 Plausible Analytics 的主要区别 Vince 专注于轻量级自托管，因此在功能上与 Plausible 有所不同：

• Vince 优势：提供无限站点和事件支持、零依赖部署、自动 TLS。
• Plausible 优势：提供企业级功能、托管服务和多租户支持。 两者在基础分析功能（如访客、页面浏览、访问时长等）和隐私特性上相似。Vince 可作为现有 Plausible 脚本的兼容替代品，但目标是服务单实体场景，而非功能完全对等。

总结 Vince 是一个功能集中、部署简便、注重隐私的自托管网站分析解决方案，适合需要数据所有权和隐私合规，且不依赖复杂基础设施的个人或单一组织用户。

在AI图像生成技术盛行的时代，部分摄影师转向拥抱复古数码相机的瑕疵与低画质特性，将其视为一种艺术表达和对抗科技过度完美的方式。这一趋势尤其在年轻创意群体中兴起，他们倾向于使用2000年代初至中期的老式便携数码相机，以追求类似MySpace时代的“Y2K美学”——低分辨率、颗粒感和闪光灯下的褪色影像。

社区内部对“数码相机”的定义存在分歧：一部分人限定于2000年代初期的便携机型，另一部分人则扩展到同时期可换镜头相机。爱好者们推崇CCD传感器相机所带来的独特影像质感，尽管专家指出这更多源于时代审美而非传感器本身的魔法。

使用这些老相机面临诸多现实挑战：电池停产、存储格式过时（如xD、MemoryStick）、设备老化（电容损坏、传感器腐蚀）等。社区通过外接电源、寻找适配器等方式应对。社交媒体热度推高了二手市场价格，并伴随诈骗风险，但平台保护措施仍能提供一定保障。

从环保角度看，延长旧设备生命周期能减少电子垃圾。这些相机以其亲民价格降低了摄影门槛，鼓励更多人参与创作。爱好者们普遍认同，关键在于理解并利用每台设备的独特特性，享受创作过程而非追求完美画质。

稀疏自编码器在大语言模型可解释性中的直观解释

核心挑战：神经网络的“叠加表示”

理解大语言模型的主要障碍是其内部机制不透明。直接分析单个神经元是无效的，因为单个神经元通常不对应单一概念，而是呈现“叠加表示”——多个概念由神经元的组合来表达。这可能源于现实世界中存在大量稀疏的变量（例如，某个名人的出生地），而模型的神经元数量有限，因此必须以这种高效但难以解读的方式编码信息。

稀疏自编码器的工作原理

稀疏自编码器是一种用于将神经网络计算分解为可理解组件的技术。

• 基本结构：SAE包含一个编码器和一个解码器。编码器将模型的中间激活值（如GPT-3中12288维的向量）映射到一个通常维度更高（例如4倍）的中间表示。解码器再将其映射回原始维度，以重构激活值。
• 关键约束：稀疏性：如果不对中间层施加约束，SAE可能通过恒等映射完美重构输入，而毫无洞察。因此，在训练损失中加入稀疏性惩罚（如L1正则化），强制SAE只激活中间表示中的少数几个元素（例如，49512维中仅有约20个非零值）。这种稀疏的中间表示就是SAE学到的“特征”。
• 应用位置：每个SAE仅针对模型中的一个特定位置（例如，第26层和27层之间的激活）进行训练。要分析整个模型（如GPT-3的96层），需要训练数百个独立的SAE。
• 训练目标与损失函数：损失函数通常包含两部分：重构损失（L2损失，衡量解码器输出与原始激活的差异）和稀疏性损失（L1损失，由稀疏性系数缩放）。优化目标是这两者之和。重要的是，SAE并非直接为“可解释性”优化，可解释特征是优化稀疏性和重构准确性的副产品。
• 代码结构：典型的SAE由两个线性层（编码器和解码器）和中间的ReLU激活函数组成。后续改进方法如BatchTopK SAE直接保留前k个激活值，以获得更好的稀疏-重构权衡。

理解SAE学到的特征

SAE中间表示中的每一个激活的维度都可以被视为一个“特征”。

• 特征与概念：理想情况下，每个活跃的SAE特征对应一个可理解的概念或组件。例如，SAE的某个解码器向量可能学习到了类似于模型内部代表“金毛寻回犬”概念的方向。
• 数学解释：解码器矩阵可以看作一系列特征向量。SAE的稀疏表示充当权重，在重构时，仅由这些权重非零的特征向量进行加权组合。在机制可解释性的术语中，解码器向量对应于残差流空间中特征的线性表示。
• 特征识别与干预：当前通过查看最大化激活该特征的输入来主观判断其含义。研究者已发现分别对“金门大桥”、“神经科学”等概念有响应的特征。由于SAE解码器向量的形状与模型激活值相同，可以直接通过因果干预来验证特征含义：将某个特征的解码器向量缩放后加到模型激活值上，可以强制模型在输出中体现相关概念（如让模型在所有回复中提到“金门大桥”或“金毛寻回犬”）。

评估挑战

评估SAE是领域内的一大难题。

• 缺乏真实标准：对于自然语言，没有明确的、可测量的真实标签来判断特征是否“正确”或“可解释”。
• 主观评估：目前主要依赖主观判断，即查看特征激活的输入并评估其可解释性。
• 代理指标：常用的代理指标包括：
  • L0：SAE编码表示中平均非零元素的数量，衡量稀疏性。
  • 损失恢复率：用SAE重构的激活值替换原始激活后，模型下游任务损失的增加量。它衡量重构对模型性能的保持程度。
  • 通常这两个指标存在权衡。
• 训练与评估的脱节：训练时使用的是L1惩罚和重构损失，这与评估时使用的L0和损失恢复率指标并不完全对应。而这些代理指标本身也只是对主观可解释性评估的代理，后者又是对“模型如何工作”这一终极目标的代理。

结论

稀疏自编码器是模型可解释性研究领域的一个重要进展。尽管存在评估和理解的局限，但它们已证明能够：

• 揭示模型内部有意义的、可解释的特征。
• 实现因果干预等有趣应用（如寻找导向向量）。
• 助益于发现模型中的电路，从而可能用于移除内部偏见。

SAE代表了构建“机器学习模型的MRI”这一目标的早期里程碑。虽然它们目前无法提供完美的理解，但在检测模型潜在不良行为方面具有潜力。该领域的挑战是当前活跃的研究课题。