2024-06-01

38 篇热帖

1. UI elements with a hand-drawn, sketchy look (wiredjs.com)

Wired Elements:手绘风格UI组件库

Wired Elements 是一套提供手绘、草图风格视觉的通用UI元素集合。这些元素特别适用于线框图、原型设计,或纯粹为了获得趣味性的手绘外观。

主要特点:

  • 独特外观:每个元素都绘制得足够随机,确保没有任何两次渲染会完全相同,如同手绘形状一般独特。
  • 多种使用方式:既可用于快速构建线框图和交互原型,也能为正式项目增添艺术风格。
  • 交互演示:提供一个简单演示,展示如何使用 wired-element 控件改变由 rough.js 绘制的草图圆圈。
  • 多框架支持:用户可以通过在线的 Sandbox 立即尝试该组件库,并且支持 Vanilla JavaScript、Vue、Svelte、React 等多种主流前端框架。
  • 开源与可扩展:项目代码托管在 GitHub,提供详细的使用文档和 API 说明,便于开发者查看和使用具体组件。

技术栈与许可: 该项目基于 RoughJS(用于实现手绘效果)和 Lit(用于构建Web组件)开发。项目采用 MIT 许可证,并欢迎通过 Open Collective 或 GitHub 进行赞助以支持其持续开发。

2. Napster sparked a file-sharing revolution 25 years ago (torrentfreak.com)

Napster:25年前点燃文件共享革命的火花

25年前,Napster的诞生标志着音乐乃至整个数字媒体消费方式的一次革命性转折。其影响深远,不仅彻底改变了行业格局,更催生了我们今天使用的流媒体服务。

技术基础与构想

  • MP3格式的铺垫:1993年,德国工程师卡尔海因茨·布兰登堡等人发明了MP3编码格式。该格式能在大幅压缩音乐文件体积的同时,保持可接受的音质,为音乐在有限存储空间和早期互联网上的传输扫清了障碍。
  • “点唱机”幻想:MP3的出现让行业憧憬的“万能点唱机”(即随时点播任何曲目的服务)显得不再遥远,为Napster的出现创造了技术与理念条件。

Napster的诞生与爆发

  • 起源:1990年代末,年轻的肖恩·范宁(肖恩·帕克协助)于1999年6月1日推出了Napster软件。其核心构想是建立一个全球性的、去中心化的计算机网络,让用户能够相互共享MP3音乐文件。
  • 病毒式传播:Napster迅速获得数千万用户追捧。它提供了一个免费、海量的音乐库,体验远超实体唱片店,被用户视为神奇的“技术魔法”。

音乐产业的恐慌与法律打击

  • 行业震动:Napster的免费共享模式直接冲击了依赖CD销售的高利润音乐产业。美国唱片业协会(RIAA)及各大唱片公司高层陷入恐慌。
  • 诉讼与关闭:2001年初,Napster全球用户超过2640万,达到顶峰。但RIAA及Metallica、Dr. Dre等艺人的诉讼随之而来。法院下达禁令,Napster网络于2001年7月被迫关闭,并以数百万美元和解。

持久的涟漪效应与产业变革

  • 法律替代品的探索:Napster关闭后,Grokster、KaZaA、LimeWire等后续文件共享软件兴起,同时BitTorrent技术也逐渐发展。这证明了用户对“无限访问”数字音乐需求的巨大潜力。
  • 催化合法数字音乐市场:Napster揭示的需求直接催生了苹果iTunes音乐商店等合法购买渠道。但单曲下载模式未能复制“全部可听”的体验。
  • 流媒体时代的奠基:Napster的“体验种子”最终在瑞典人丹尼尔·埃克心中发芽,他创立了Spotify。Spotify等流媒体服务利用类似的技术原理(早期甚至借鉴了点对点技术),最终成为音乐产业的主要收入来源。CD衰落为小众藏品。
  • 超越技术的影响:Napster的冲击波彻底重塑了音乐产业的商业模式、消费者习惯和价值链,其影响持续至今,并将继续塑造未来的数字娱乐 landscape。
3. Man scammed after AI told him fake Facebook customer support number was real (www.cbc.ca)
5. 60 kHz (2022) (ben.page)

WWVB广播站:60 kHz频率的时间广播

广播站概述

  • WWVB是位于科罗拉多的广播站,由美国国家标准与技术研究院(NIST)运营。
  • 该站以60 kHz频率持续广播当前时间,昼夜不停。

技术细节

  • 60 kHz属于低频谱段,带宽有限,每秒仅能广播一位二进制数字。
  • 广播完整时间信号需要一分钟,因为传输时间信息以二进制形式进行。

无线电时钟的应用

  • 美国所有无线电时钟依赖WWVB广播来自动设置时间。
  • 时钟每天接收一次广播,设置自身时间,并根据用户设置的时区进行调整。
  • 这一过程使时钟无需手动校准即可保持准确,实现自动同步。

意义与评价

  • 该系统通过简单可靠的技术解决了时钟自动计时问题。
  • 它体现了基于坚实技术的创新,强调无形贡献者在世界运作中的作用。
9. Eye exercises for myopia prevention and control: comprehensive systematic review (www.nature.com)

眼保健操预防和控制近视的效果:全面系统综述

文章信息
发表日期:2023年9月22日
期刊:Eye(2024年第38卷,473–480页)
DOIhttps://doi.org/10.1038/s41433-023-02739-x

研究目的

评估眼保健操在预防和控制近视方面的效果。

研究方法

  • 数据来源:系统检索了截至2022年12月15日的九个中英文数据库中关于眼保健操的对照实验研究。
  • 分析方法:采用随机效应模型进行荟萃分析,并辅以敏感性分析和亚组分析,评估眼保健操与对照组在三个指标上的差异:
    1. 视敏度(使用标准化均数差SMD衡量)
    2. 屈光误差(使用标准化均数差SMD衡量)
    3. 保护/缓解效果(使用风险比RR衡量)

主要结果

共纳入11项研究,涉及921名参与者。多数研究存在偏倚风险(9项研究在至少两个方面存在偏倚问题,2项研究在两个方面存在高偏倚风险)。

  1. 对视敏度的影响(7项研究):

    • 干预后,眼保健操组的视敏度出现下降(SMD = -0.67,95% CI -1.28 至 -0.07,P = 0.03)。
    • 其效果并不优于对照组(SMD = -0.50,95% CI -1.16 至 0.16,P = 0.14)。
  2. 对屈光误差的影响(2项研究):

    • 眼保健操干预的效果与对照组无显著差异(SMD = -1.74,95% CI -6.27 至 2.79,P = 0.45)。
  3. 对保护/缓解效果的影响(7项研究):

    • 眼保健操显示出优于对照组的保护/缓解效果(RR = 0.40,95% CI 0.23–0.71,P < 0.01)。

结论

总体而言,该荟萃分析表明,眼保健操在预防或控制近视进展方面的效果有限或无效。在获得强有力的证据支持其疗效之前,现有证据建议停止实施眼保健操政策。

10. De-googling, so far (blog.nradk.com)

去谷歌化实践总结

搜索引擎

  • 主要使用DuckDuckGo:已用6-7年,基本够用但搜索结果有时过于字面化。其“bang”功能(如!g跳转Google)非常实用。
  • 尝试过Kagi:搜索质量优秀,支持自定义网站排名,但存在两个问题:基础套餐每月仅300次搜索额度不够用;需登录使用,与隐私保护理念冲突。最终回归DuckDuckGo。

电子邮件

  • 同时使用ProtonMail和Fastmail
    • ProtonMail:注重隐私、端到端加密,但较难使用第三方客户端。
    • Fastmail:配合自定义域名使用,提供掩码邮箱功能,Web界面简洁,与开源邮件客户端兼容良好。
  • 找到可用替代方案相对容易。

照片存储

  • 放弃Google Photos后,未使用其他主流云服务(如OneDrive、iCloud等)。
  • 选择自托管Immich:功能丰富,尽管未正式发布但足够稳定,支持从Google Takeout导入数据。

云存储/文件同步

  • 最初自托管Nextcloud,但同步大量文件时速度较慢。
  • 当前方案简化:重要文件存储在家庭服务器,通过sshfs挂载到笔记本访问,辅以FileBrowser提供Web界面。
  • 需要协作和频繁分享的用户切换难度更大。

日历与联系人

  • 依赖CalDAV/CardDAV协议,以Nextcloud作为服务端。
  • 客户端使用Fossify Calendar、GrapheneOS默认联系人应用及DavX5进行同步。
  • GNOME桌面环境自带日历和联系人应用也支持这些协议。

手机操作系统

  • 使用GrapheneOS:基于Android,移除谷歌服务以增强隐私安全。
  • 优点:可通过沙盒化方式安装Google Play服务,限制其权限。
  • 挑战与权衡
    • 仅支持Google Pixel设备。
    • 不使用Google Play服务时:银行类应用完全无法使用,部分应用通知缺失,需依赖Aurora Store安装应用。
    • 安装沙盒化Google Play服务后体验改善(如通知正常、金融应用可用),但仍无自动更新等完整功能。
    • Android Auto依赖专有应用,需安装沙盒化Google Play才能在GrapheneOS上使用。
  • 替代考虑:虽曾考虑iPhone,但不愿将控制权交给另一家科技公司,坚持选择开源可信赖的方案。

地图服务

  • OpenStreetMap地图数据质量高,常用Organic Maps等客户端。
  • 但难以完全放弃Google Maps:因其集成了路线导航、公共交通、实时路况、商户评论和营业时间等完整生态,网络效应显著。

视频平台

  • YouTube几乎无替代品:技术成本与创作者/观众网络效应构成双重壁垒。
  • 曾关注PeerTube和Nebula.tv,但前者缺乏主流创作者,后者内容常同步发布于YouTube,使用频率低。

结论

  • 完全避免谷歌产品极度困难,常需牺牲便利性。
  • 许多领域已存在可行且注重隐私的替代方案。
  • 自托管可提供更多自由与隐私控制权。
  • 实践原则:在可行范围内逐步减少对谷歌的依赖。
11. Stealing everything you've ever typed on your Windows Recall PC is now possible (simonwillison.net)

Windows Recall功能存在重大安全漏洞:两行代码即可窃取用户历史输入内容

Windows 11的Recall功能会每隔几秒自动截取屏幕画面,通过本地OCR识别将文字存储在SQLite数据库中,形成可搜索的历史活动记录。然而,这一功能设计带来了严重的安全和隐私风险:

  1. 安全威胁:恶意软件只需针对该SQLite数据库文件,即可轻易获取用户曾输入或浏览的大量敏感信息。
  2. 实际测试:在测试中,使用现成窃密软件配合Microsoft Defender for Endpoint时,虽然防病毒软件最终检测到威胁,但在其完成自动修复(耗时超过10分钟)前,Recall数据早已被窃取。
  3. 适用性质疑:有观点认为,该功能仅适合少数需要频繁回溯工作记录的高管用户,对于绝大多数普通用户而言,自动截屏并存储所有操作内容的做法严重侵犯隐私。
12. What I think about Lua after shipping a project with 60k lines of code (blog.luden.io)
13. Nginx Unit: open-source, lightweight and versatile application runtime (unit.nginx.org)

NGINX Unit 摘要

NGINX Unit 是一个开源的、轻量级且多功能的应用程序运行时。它作为单一服务器提供Web应用程序的基本组件,包括运行应用程序代码(支持WebAssembly)、服务静态资产、处理TLS和请求路由。该工具由nginx团队从零开始创建,注重高效性和运行时完全可配置性。

注意:NGINX Unit 不再接收来自项目维护者的新功能或增强,表明项目可能进入维护状态。最新版本为1.34.2,发布于2025年2月26日。

资源与文档

  • 快速入门指南:可在GitHub页面访问。
  • 更新日志、新闻档案:提供版本历史和发布说明。
  • RSS订阅:用于跟踪更新。
  • 关键功能讨论:深入了解其特性。
  • 未来计划:基于GitHub的路线图。
  • 教程课程:完整的NGINX Unit教程可供观看。
14. Bento: Open-source fork of the project formerly known as Benthos (www.warpstream.com)

Bento:Benthos 项目的 MIT 开源分支

背景与起因

  • 项目起源:Benthos 是一个使用 Go 编写的轻量级流处理框架,最初作为 Kafka Connect 的更简单、更轻量级替代方案而广受欢迎,拥有近8000个GitHub星标和数百名贡献者。
  • 收购事件:Redpanda 宣布收购 Benthos 项目。原项目作者 Ashley Jeffs 在过去7年中做出了近3500次提交,并建立了活跃的社区。
  • 变更措施:收购后不到12小时内,Redpanda 迅速实施以下变更:
    • 将项目更名为“Redpanda Connect”,并禁止使用“Benthos”名称。
    • 重组 Discord 和 Slack 社区,引导用户迁移至 Redpanda 频道。
    • 将 GitHub 仓库转移至 Redpanda 名下,并拆分为两个使用不同许可证的仓库。
    • 关键变更:将部分核心集成和连接器重新许可为专有软件,包括一些由非收购关联的开源贡献者编写的集成。

分叉决定与动机

  • 核心关切:WarpStream(一家依赖 Benthos 作为其产品 WarpStream Managed Data Pipelines 核心组件的公司)对许可证变更表示严重担忧。
  • 直接原因:WarpStream 采用 BYOC(自带云)部署模式,其客户环境中的代码必须保持清晰和稳定的许可证。混合或频繁变更的许可证会给客户带来法律风险。
  • 立场声明:WarpStream 强调他们原本反对“开源核心”或“源代码可用”的商业模式,认为这可能导致后期的许可变更或功能限制。他们不希望创建分支,但认为这是应对快速商业化变更的唯一负责任做法。

Bento 项目详情

  • 分支定义:从原始 Benthos 项目分叉,命名为 Bento,作为对 Benthos 的致敬,但独立于现已更名的 Redpanda Connect。
  • 许可证承诺:100% 采用 MIT 许可证,并承诺永久保持此许可证。所有未来更改都将在 MIT 许可下发布。
  • 文档与资源
    • 新的 GitHub 仓库已建立。
    • 原始 Benthos 文档的托管版本已保留并可访问。
  • 社区与治理计划
    • 目标是建立共享治理模型,邀请其他官方维护者加入。
    • 计划创建独立的 GitHub 组织,配备专用的 CI/Docker 基础设施。
    • 寻求与对 Benthos 有商业兴趣的公司(包括竞争对手)合作,以共同维护项目。
  • 社区邀请:欢迎原 Benthos 社区成员、贡献者和相关公司参与,共同延续项目的开源精神。

后续步骤

  • 短期行动:WarpStream 将继续维护 Bento 分支,确保其产品依赖的稳定性。
  • 长期愿景:推动项目走向独立、开放的治理结构,确保社区驱动开发,避免单一公司的过度控制。

总结:面对 Redpanda 收购后对 Benthos 项目进行的快速商业化和许可证变更,WarpStream 决定分叉该项目并创建 Bento。Bento 将保持100% MIT 开源许可,致力于延续原 Benthos 的开放精神,并寻求社区合作建立可持续的治理模式。

15. Arthur Whitney releases an open-source K with MIT license (shakti.com)
18. Go: Sentinel errors and errors.Is() slow your code down by 3000% (www.dolthub.com)

Go语言错误处理策略性能对比分析

本文通过基准测试评估了Go语言中不同错误处理策略的性能影响,重点分析了哨兵错误(sentinel errors)与errors.Is()方法的效率问题。

测试方法与策略

研究创建了多种模拟对象存储的接口,针对“值未找到”场景测试了六种主要错误处理策略:

  1. 布尔值策略:不返回错误,通过额外布尔返回值表示状态
  2. 哨兵错误直接比较(ErrEqual):使用预定义错误变量与==直接比较
  3. 带nil检查的哨兵错误比较(ErrEqualNilCheck):先检查错误非nil再比较具体值
  4. errors.Is()方法:使用标准库函数检测错误(支持错误包装)
  5. 带nil检查的errors.Is()(ErrorsIsNilCheck):先检查错误非nil再调用errors.Is()
  6. Panic/recover机制:通过panic表示错误状态

关键性能发现

在AMD EPYC 7571处理器上的测试显示显著性能差异:

值未找到场景(从快到慢):

  • 布尔值策略:3.423 ns/op(基准)
  • ErrEqual:7.366 ns/op(慢2.15倍)
  • ErrEqualNilCheck:8.293 ns/op(慢2.42倍)
  • errors.Is():19.35 ns/op(慢5.65倍)
  • errors.Is()NilCheck:19.34 ns/op(慢5.65倍)
  • Panic:241.5 ns/op(慢70.55倍)

值找到场景(从快到慢):

  • errors.Is()NilCheck:2.939 ns/op(基准)
  • ErrEqualNilCheck:2.994 ns/op(慢1.02倍)
  • 布尔值策略:3.05 ns/op(慢1.04倍)
  • ErrEqual:3.24 ns/op(慢1.10倍)
  • Panic:12.77 ns/op(慢4.35倍)
  • errors.Is():18.04 ns/op(慢6.14倍)

错误包装的影响

当错误经过多层包装时,性能差异更为明显:

  • 值未找到:包装错误策略比布尔值策略慢117-120倍
  • 值找到:包装错误策略比布尔值策略慢约1.09-2.62倍

性能下降主要源于错误创建和包装的成本,而非errors.Is()本身。

核心结论与建议

  1. errors.Is()代价高昂:使用时应先检查错误是否非nil,避免在正常路径上承受性能损失
  2. 直接==比较也有开销:虽然比errors.Is()稍好,但因错误包装问题不推荐使用
  3. 错误包装增加成本:使哨兵错误检查显著变慢,包括增加errors.Is()的开销
  4. 哨兵错误在错误路径上不可避免地更慢:即使采取预防措施,在错误触发时仍比布尔返回慢数倍

设计理念建议

文章提倡:

  • 不透明错误处理:仅检查错误是否存在,不深入检查具体内容
  • 分离状态检查与错误处理:通过额外返回值(如布尔值)表示可预期状态,将错误保留给真正异常情况
  • 避免错误用于控制流:错误应代表异常条件,而非常规业务逻辑

作者指出,在其数据库项目Dolt中通过避免哨兵错误、谨慎使用错误包装,已实现了数个百分点的性能提升。

重要提醒:虽然性能差异显著,但实际影响取决于具体使用场景。建议在性能关键路径上测试验证,而非全面避免所有哨兵错误。

20. Ticketmaster confirms data breach with a SEC filing (stackdiary.com)

Ticketmaster 数据泄露事件摘要

事件确认

  • 公司: Live Nation Entertainment (Ticketmaster) 已向美国证券交易委员会提交 Form 8-K 文件,正式确认数据泄露事件。
  • 发现时间: 公司于 2024年5月20日 发现其第三方云数据库环境中存在未授权活动,该环境主要包含其子公司 Ticketmaster 的数据。

泄露过程与时间线

  1. 5月27日: 一名暗网用户声称拥有 5.6亿 Ticketmaster 用户数据(包括姓名、地址、邮箱、电话、订单详情等)并准备出售。
  2. 5月29日: 著名黑客组织 ShinyHunters 在黑客论坛上重新发布了数据出售信息,引发了广泛关注。
  3. 5月30日: 网络安全组织 vx-underground 收到样本数据后,高度确信数据是真实的
  4. 5月31日: 一系列关键事件发生:
    • 金融机构桑坦德银行(Santander)的数据也被声称遭泄露并以200万美元价格出售,其与Ticketmaster泄露的关联尚不明确。
    • 安全研究机构 Hudson Rock 发布报告,引用威胁行为者的话指出,两起泄露事件均是通过攻破 云服务提供商 Snowflake 实现的,且该攻击者声称已入侵 约400家公司
    • Snowflake 发布安全公告,承认相关事件,但未明确说明入侵方式。
    • Live Nation 正式向 SEC 提交文件,披露数据泄露。

关键争议与现状

  • 威胁行为者的诉求: 攻击者最初曾向 Snowflake 索要 2000万美元,以阻止数据外泄。
  • 安全漏洞根源: 根据 Hudson Rock 的报告,单个凭证 导致了大规模的数据窃取。但 Snowflake 后续声明否认其系统被入侵,并将责任归咎于客户自身 “未能遵循最佳安全实践”
  • 信息模糊性: 各方(包括 Snowflake、Ticketmaster)的公开声明均较为模糊。截至目前,Ticketmaster 尚未开始通知受影响的用户
  • 潜在规模: 综合多方信息,此次事件 可能是有史以来规模最大的数据泄露事件之一,但除 SEC 文件外,官方直接确认的信息仍然有限。

后续措施

  • Live Nation 表示已 立即展开调查,聘请了领先的取证专家。
  • 公司正在与 执法部门合作,并计划通知 监管机构和受影响的用户
  • 事件仍在评估和风险缓解过程中。
21. Ticketmaster confirms data hack which could affect 560M globally (www.bbc.co.uk)
24. Everything I know about the fast inverse square root algorithm (github.com)

快速平方根倒数算法详解

算法概述

快速平方根倒数算法通过一系列令人惊叹的位操作和整数运算,高效计算浮点数 x 的平方根倒数 1/√x。该算法因出现在《雷神之锤3》源代码中而闻名,由约翰·卡马克推广。其核心思想是利用IEEE 754浮点数的二进制表示与对数函数的近似关系,通过整数运算实现快速近似计算。

算法代码

float Q_rsqrt(float number) {
  long i;
  float x2, y;
  const float threehalfs = 1.5F;

  x2 = number * 0.5F;
  y  = number;
  i  = *(long*)&y;                            // 将浮点数位模式解释为整数
  i  = 0x5f3759df - ( i >> 1 );               // 核心计算:整数减半并与魔数相减
  y  = *(float*)&i;                           // 将结果解释回浮点数
  y  = y * ( threehalfs - ( x2 * y * y ) );   // 牛顿迭代法改进精度
  return y;
}

历史背景

该算法在1999年为3D图形计算优化而生。当时硬件性能有限,计算反平方根(用于向量归一化、光照计算等)非常耗时。现代硬件已可通过专用浮点单元快速完成此计算,但该算法仍是数值计算和硬件理解的优秀范例。

核心原理

1. 浮点数的二进制表示

IEEE 754单精度浮点数(32位)分为三部分:

  • 符号位(1位):正负号
  • 指数位(8位):表示范围(偏移127)
  • 尾数位(23位):表示具体数值

数值 N 计算公式为: N = (-1)^S × 2^(E-127) × (1 + M/2^23)

2. 位模式与对数的近似关系

将浮点数的位模式直接解释为整数 I,会发现其与 log₂(x) 存在近似线性关系:

log₂(x) ≈ I / 2²³ - 127

这种近似源于浮点数的指数部分线性编码了数值的数量级。

3. 魔数常数的推导

基于对数性质 log₂(1/√x) = -0.5 × log₂(x),通过代数变换得到:

I_y ≈ -0.5 × I_x + C

其中 C = (3/2) × 2²³ × (127 - σ)σ 是优化近似精度的调整参数。

计算当 σ ≈ 0.0450465 时:

  • C = 1.5 × 2²³ × (127 - 0.0450465) = 1598029824
  • 转换为十六进制:0x5f3759df

因此核心操作 i = 0x5f3759df - (i >> 1) 实际上是通过整数移位(相当于除以2)和减法实现对数域的线性近似。

4. 牛顿迭代法改进精度

初始近似误差较大,通过牛顿迭代法优化:

y_{n+1} = y_n × (1.5 - 0.5x × y_n²)

代码中的 y = y * (threehalfs - (x2 * y * y)) 即为此公式的实现。该迭代避免了除法运算,仅使用乘法和加法,单次迭代即可将误差降至约0.175%。

算法特性

  1. 仅适用于正常浮点数:对零、次正规数(sub-normals)和特殊值(无穷大、NaN)不适用
  2. 非精确计算:是快速近似算法,误差可控
  3. 硬件友好:充分利用整数移位、加法和乘法,避免昂贵的浮点除法和开方

结论

快速平方根倒数算法体现了对浮点数底层表示的深刻理解,通过数学近似和数值方法的结合,在硬件限制下实现了高效计算。虽在现代硬件上已无必要,但它仍是计算机科学中数值优化与硬件理解的经典范例,展示了如何将数学洞察转化为高效工程实践。

27. Einstein went to his office just so he could walk home with Gödel (www.futilitycloset.com)

阿尔伯特·爱因斯坦曾表示,他去普林斯顿高等研究院上班的目的“仅仅是为了有幸能与库尔特·哥德尔一起步行回家”。两人每天会在上午10点到11点间于爱因斯坦家中会面,随后一同步行半小时前往研究院。下午1点或2点,他们又会一起步行返回,并讨论政治、哲学和物理学话题。爱因斯坦的传记作者佩尔·尤尔格劳估计,这些散步占据了爱因斯坦工作日的约30%时间。

爱因斯坦的秘书海伦·杜卡斯在1946年写道:“我知道有一次,一位司机突然认出这位在街上步行的美丽老人的面容后,开车撞上了树。”而哥德尔并未引起这类困扰。哥德尔在写给母亲的信中说:“到目前为止,我还没有觉得自己的‘名声’有任何负担。只有当一个人变得像爱因斯坦那样,街上的每个孩子都认识他时,麻烦才会开始。”

(内容源自2009年出版的《没有时间的世界:哥德尔与爱因斯坦被遗忘的遗产》)

28. Lessons learned from 6 months of operating a tiny news archive (hiandrewquinn.github.io)

这篇文章分享了运营一个小型芬兰语新闻归档网站六个月的经验心得。网站作者创建此项目,是为了解决个人学习“简易芬兰语”新闻时难以获取往期内容的不便。

文章的核心经验总结如下:

  1. “家常菜”式网站:作者认为,针对特定、明确需求而构建的“小型网站”能带来最佳体验。该项目正是为了解决一个特定痛点(获取学习材料)而诞生,并持续为学习带来益处。

  2. Cronjobs与Git的协同:项目的技术架构基于三个逐层演进的Git仓库,通过定时任务(Cronjob)自动运行:

    • 仓库一:定时抓取并归档原始网页。
    • 仓库二:定时将原始归档内容转换为格式规范的Markdown并附带英文翻译。
    • 仓库三:定时将Markdown内容生成为一个Hugo静态网站。 这种结构使得任何环节出现问题时,都可以轻松回退到之前的版本进行修复。
  3. 简单至上:项目追求极致的简单。例如,它完全没有使用数据库,而是直接将第一个Git仓库本身作为数据源。整个网站是纯静态的,可以直接部署到Github Pages,几乎无需维护。

  4. 本地工作流的高效:所有中间数据都保存在可公开获取的Git仓库中。作者编写了一个本地Python脚本,可以克隆仓库二的内容,并在本地文件系统上快速生成用于记忆的闪卡。这种本地处理方式比任何在线API调用都更快、更可靠。

  5. HTML与CSS的纯粹:网站完全没有使用JavaScript,仅由HTML和极简的无类CSS构成,旨在清晰地并排展示芬兰语和英文。作者认为,为解决特定任务(如查找单词原形)而引入JS所带来的复杂性,远超过其收益。

  6. pandoc工具的强大:作者高度赞赏pandoc工具,暗示其在内容转换流程中发挥了关键作用。

总而言之,作者通过一个实践案例强调了为特定需求构建简单、可维护、静态网站的价值,并展示了如何利用Git、定时任务和命令行工具高效地实现自动化工作流,从而将个人兴趣项目转化为长期有用的学习资源。

29. CERN Root (root.cern)

CERN ROOT 项目概述

项目性质

CERN ROOT 是一个用于数据处理、统计分析、可视化和存储的模块化科学软件工具包。它主要面向高能物理(HEP)等领域,但也广泛应用于其他科学和工业领域。

主要资源

  • 学习:提供教程和指南,帮助用户入门和使用 ROOT。
  • 参考:包含详细的 API 文档和用户手册。
  • 论坛:用户交流、提问和获取帮助的社区平台。
  • 画廊:展示使用 ROOT 创建的可视化示例和应用案例。

最新动态与公告

  • C++ 纪录片发布:邀请参加关于 C++ 的纪录片首映(2026年6月4日 CET 21:00),该片涉及 ROOT 项目。
  • ROOT 高级课程 2026:组织首届 ROOT 高级课程,以回应社区需求。
  • ROOT Hackathon:举办第三届黑客松活动“The Fixathon 2.0”,时间定于2026年5月11-12日,地点在 CERN IdeaSquare。
  • 安全漏洞说明:就近期常见漏洞发布了官方声明,说明 ROOT 是否需要更新。

版本发布历史

ROOT 持续更新,近期发布的版本包括:

  • Release 6.40.00(2026年5月20日):最新稳定版。
  • Release 6.40.00-rc1(2026年4月23日):发布候选版。
  • Release 6.38.04(2026年3月12日)
  • Release 6.38.02(2026年2月25日)
  • Release 6.38.00(2025年11月27日)
30. Can ketones enhance cognitive function and protect brain networks? (www.urmc.rochester.edu)

酮体可增强认知功能并保护大脑网络

罗切斯特大学德尔蒙特神经科学研究所的研究人员发现了酮体可以拯救大脑海马网络中的机制。这些发现基于先前的研究,表明酮体能够减轻神经和认知方面的影响。

随着年龄增长,大脑自然会变得更易产生胰岛素抵抗。这导致神经元之间的通信中断,引发情绪变化、认知衰退,最终可能导致神经退行性病变。该研究由神经科学副教授Nathan A. Smith等人领导,他们研究了在创伤等突发情况下出现胰岛素抵抗时(即在症状发展成糖尿病或阿尔茨海默病等慢性疾病之前)大脑中发生崩溃的机制。

Smith指出:“一旦神经元功能丧失,其连接便无法恢复,因此我们需要在功能最初受损时进行识别。”该研究发表在《PNAS Nexus》期刊上,通过理解如何修复受损神经元的功能,有望预防或延缓阿尔茨海默病等毁灭性疾病。

研究人员使用小鼠模型,聚焦于负责学习和记忆的海马体。他们发现急性胰岛素抵抗损害了神经元功能的多个方面,包括突触活动、轴突传导、网络同步、突触可塑性和动作电位特性——这些过程对支持神经元内外的通信至关重要。

随后,研究人员施用了酮体的一种形式D-βHb(当身体燃烧脂肪而非葡萄糖供能时,肝脏释放的副产物)。结果发现,先前因急性胰岛素抵抗受损的突触活动得到修复,轴突传导增强,神经元重新同步,突触可塑性也得到提高。

Smith表示:“这项研究对于开发靶向胰岛素抵抗/低血糖相关疾病(如糖尿病或阿尔茨海默病)中特定神经元功能障碍的酮体疗法具有重要意义。我们接下来将探索星形胶质细胞和其他胶质细胞在急性胰岛斯抵抗中的作用。”

该研究由美国国立卫生研究院、国家科学基金会和国防部资助,团队成员来自罗切斯特大学、石溪大学、哈佛医学院、纪念斯隆凯特琳癌症中心等多个机构。

31. Re-Evaluating GPT-4's Bar Exam Performance (link.springer.com)

对GPT-4律师资格考试表现的重新评估

研究背景与问题

OpenAI在2023年3月推出GPT-4时,宣称该模型在律师资格考试中达到了“第90百分位”或“前10%考生”的成绩,并被广泛报道。然而,律师资格考试作为评估人类或AI律师能力的代理指标存在局限性,例如其内容普遍性与实际司法管辖区法律无关,且考试任务(尤其是选择题)不能反映执业律师的实际工作。此外,人类是“闭卷”考试,而GPT-4凭借庞大的训练语料相当于“开卷”,可能高估了其相对于人类的能力。

OpenAI声称其百分位估计是“保守”的“下限”,但缺乏详细的方法论文档支持。这一估计的可靠性对法律实践和AI安全均有重要影响:若能力被高估,可能导致法律专业人员或非专业人士不当依赖AI,引发不良法律后果;同时,透明度的缺乏可能损害AI安全部署的信心。

研究方法与发现

本文通过多种方法重新评估GPT-4的考试百分位,并验证其原始分数的有效性。

1. 百分位估计的重新计算

  • 数据源问题:OpenAI引用的“第90百分位”可能基于伊利诺伊州律师资格考试2月场的数据,但该场次考生多为重考者(前次未通过),成绩普遍较低,导致估计偏高。
  • 使用7月场数据:使用同一来源的7月场数据计算,GPT-4的总分百分位约为第68百分位,论文部分低于平均水平。
  • 更准确的比较基准:作者使用官方全国考试委员会(NCBE)数据,估计首次参加考试者和通过者的百分位:
    • 与首次考试者相比:GPT-4总分百分位约为第62百分位,论文部分约第42百分位。
    • 与通过考试者相比:GPT-4总分百分位降至约第48百分位,论文部分仅约第15百分位。
  • 与GPT-3.5的对比:GPT-3.5的提升显著,但GPT-4的绝对表现远低于OpenAI声称的水平。

2. 原始分数的验证

  • MBE分数复制:成功复制了GPT-4的MBE(律师资格考试选择题部分)分数(158分),确认该部分成绩可靠。
  • 论文分数质疑:论文部分(MPT + MEE)的评分方法存在重大偏差,与官方协议不符:
    • 未使用官方评分标准或评分指南。
    • 评分员未接受律师资格考试评分的专业培训。
    • 缺乏盲评和校准程序。 这些问题使论文分数(140分)的有效性存疑,若该分数被高估,GPT-4的实际百分位可能更低。

3. 超参数影响分析

  • 温度设置:调整温度(0至1)对MBE表现无显著影响。
  • 提示工程技术:相比基础提示,“最大化定制”的提示(包含示例和系统指令)能显著提高MBE成绩,但即使在此条件下,其论文表现仍较低。

研究意义与影响

对法律行业

  • 若将律师资格考试视为律师能力的代理指标,GPT-4的实际能力远低于宣传,尤其在论文写作(更贴近律师实际工作)方面表现平庸。这可能暂时缓解律师对职业被替代的担忧。
  • 但若业界过度信赖高估的能力而使用GPT-4处理复杂法律任务,可能导致司法误用、律师失职或非专业人士无效代理等问题。

对AI安全与开发

  • 强调了AI能力评估中透明度和严格方法论的重要性。不准确或夸大的能力描述可能误导公众和决策者,阻碍安全部署。
  • 呼吁开发者实施更严谨、透明的评估流程,确保AI发展符合安全与价值导向,避免引发意外危害。

结论

OpenAI对GPT-4律师资格考试成绩的“第90百分位”声明可能被高估。本文的重估显示,GPT-4的实际表现(尤其是论文部分)远低于该声称,与通过考试者相比仅处于中等偏下水平。这一发现凸显了对AI能力进行准确、透明评估的紧迫性,以确保法律行业和AI开发的安全与可信。尽管GPT-4相比前代有显著进步,但未来需更严谨的方法来衡量其真实能力。

32. How to Distribute Postgres Geographically (xata.io)

分布式 PostgreSQL 部署模式

本文介绍了一种将 PostgreSQL 数据库分布到多个区域或云环境的模式。该模式不依赖于特定托管服务,仅使用标准 PostgreSQL 功能即可实现。

核心模式

  1. 数据分离:将租户特定的数据表控制平面表分开。
  2. 数据就近:将租户数据表放置在最靠近用户预期所在区域的数据中心。
  3. 全局视图:使用 PostgreSQL 的 Foreign Data Wrappers (FDW)分区功能创建一个全局数据视图。
  4. 集中管理:将认证和控制平面数据保留在单个区域内。

适用场景与原因

适用条件:该模式适用于大多数数据模型可以按特定键(如客户ID)划分为“租户”,且每个租户天然“亲和”于某个特定区域的情况。典型例子是 B2B 多租户 SaaS 应用(如 Notion 克隆、Slack、GitHub)。

采用原因

  • 降低延迟:将数据存储在用户所在区域可减少往返时间。
  • 数据驻留法规:满足某些地区(如欧盟)对数据存储位置的法律要求。
  • 支持边缘计算:配合 Cloudflare Workers 等边缘平台时,需要分布式数据策略。
  • 多区域/多云容灾:避免单点故障,缩小故障影响范围。

架构与实现

  1. 集中式控制平面

    • 用户表、工作空间列表、成员关系等控制平面数据集中存储在一个中央区域。
    • 登录和注册请求由中央区域处理,生成 JWT 等令牌。
    • 应用程序栈在每个区域部署(或运行在边缘),后续请求使用令牌认证并路由到对应租户数据所在的区域。
  2. 分布式租户数据

    • 每个租户的数据(如特定工作空间的页面)存储在与其亲和的区域。
    • 所有外键关系都在租户内部,因此可以独立分布。
    • 需要为租户数据生成全局唯一 ID(如 UUID、ULID)以避免冲突。
  3. 使用 FDW 和分区创建全局视图

    • 设立一个“控制器节点” PostgreSQL 实例。
    • 使用 postgres_fdw 扩展,将各区域数据节点上的表映射到控制器节点的不同模式中。
    • 在控制器节点上创建一个分区表(如 global.pages),以各区域映射表作为其分区。
    • 通过查询该分区表,即可获得跨所有区域数据的全局视图。
    • 插入数据时,如果指定了 region 列,数据会被路由到正确的远程节点。

当前局限性

该模式在需要频繁通过全局视图访问或写入数据时存在局限:

  • 性能影响复杂:访问远程表(尤其跨洋)比本地慢,数据传输成本高。PostgreSQL 的查询优化器目前对此优化不足。
  • 跨区域写事务非 ACID:通过全局视图执行涉及多个远程表的事务时,由于 FDW 不支持两阶段提交,无法保证原子性等 ACID 特性。

未来展望

此模式非常适合大多数单租户查询场景的 SaaS 应用。其变体也可用于水平扩展(例如,在同一区域内按租户 ID 哈希分片到多个节点)。

随着 PostgreSQL 的 FDW、分区和查询规划器不断改进,未来全局视图的性能有望提升,使该模式适用于更广泛的应用场景。作者团队正致力于推进相关技术发展。

33. Heroku Postgres is now based on AWS Aurora (blog.heroku.com)

Heroku 最新推出基于 Amazon Aurora 基础设施的 Heroku Postgres Essential 数据库计划。新计划支持 pgvector 扩展、无行数限制,并提供最高 32 GB 存储选项,在事务性查询性能上比前代计划最高提升 3 倍

主要新计划如下:

产品 存储 最大连接数 最大行数 最大表数 月费
Essential-0 1 GB 20 无限制 4,000 $5
Essential-1 10 GB 20 无限制 4,000 $9
Essential-2 32 GB 40 无限制 4,000 $20

所有计划均兼容 PostgreSQL 14、15、16 版本,提供全托管服务,适用于开发测试、原型构建、教育培训、低流量网站及初创公司等多种场景。

迁移信息:原有的 MiniBasic 计划将分别自动迁移至 Essential-0Essential-1,迁移过程将于 2024年5月29日 开始,旨在最小化停机时间。用户也可提前手动升级至任意新计划。

未来规划:Heroku 将基于与 Amazon Aurora 的合作,推出下一代基础设施,支持存储计算解耦(存储可扩展至 128 TB)、更多连接与扩展、近零停机维护,以及满足 HIPAA 和 PCI 等合规要求的 Shield 选项。单租户数据库试点计划已开放等待列表。

34. Windrecorder – Personal Memory Search Engine (github.com)

Windrecorder – 个人记忆搜索引擎

Windrecorder 是一款运行在 Windows 上的开源个人记忆搜索引擎,是 macOS 上 Rewind 或 Copilot Recall 的替代工具。其核心功能是通过录制屏幕内容,帮助用户回溯和检索记忆线索。所有数据完全在本地处理和存储,无需联网,充分保障用户隐私。

主要功能

  • 屏幕录制:支持录制多个屏幕、单个屏幕或仅活动窗口。文件体积小,系统资源占用低,确保稳定持续的录制,并支持实时回放。
  • 智能索引:仅对变化的场景进行索引,更新OCR文本、页面标题、浏览器URL等信息至数据库。支持自定义跳过条件(按窗口标题、进程名、包含文本或屏幕静止时间)。
  • 自动维护:在电脑闲置时自动进行数据库维护、视频压缩和清理过期视频。
  • 查询与统计:提供完整的WebUI界面,用于回放屏幕、进行OCR/图像语义查询。并提供活动统计、词云、时间线、散点图等数据总结。
  • AI扩展:支持使用AI(LLM)进行标签总结。
  • 多语言支持:内置简体中文、英文和日文。

技术特性与扩展

  • OCR引擎:除Windows内置识别外,还支持多种第三方OCR引擎,以提升识别准确率和多语言支持:
    • Rapid OCR(基于PaddleOCR)
    • 微信OCR(中英文识别精度高)
    • Tesseract OCR(支持100+语言)
    • 支持贡献自定义OCR引擎。
  • 图像嵌入:可通过扩展模块安装图像嵌入功能。

安装与使用

  1. 环境准备:需预先安装 ffmpegGitPython(推荐3.11版本,暂不支持3.12)。
  2. 获取代码:通过 git clone 命令将项目克隆到本地空间充足的分区。
  3. 安装运行:运行 install_update.bat 安装依赖并配置。之后运行 start_app.bat 启动,工具会最小化至系统托盘,通过右键菜单使用。
  4. 数据存储:所有数据(视频、数据库)存储在项目下的 userdata 目录中。移动应用时,可删除 .venv 文件夹并重新运行安装脚本。
  5. 最佳实践:建议在WebUI中设置“开机启动”,以实现无感记录。工具会在画面无变化、排除列表内或锁屏时自动暂停录制,并在空闲时执行维护任务。

工作原理

提供两种录制模式供选择:

  1. 自动灵活截图:默认每3秒截图,内容变化时索引,每15分钟自动将历史截图转为视频。资源占用低,适合需要存储、回放和搜索记忆线索的用户。
  2. FFmpeg直接视频录制:以15分钟为单位录制视频,录制完成后再索引(查询数据最多有15分钟延迟)。资源占用中等,可流畅完整记录电脑活动。

屏幕静止、匹配排除列表或锁屏时自动暂停录制并进行空闲维护。

存储空间估算

  • 每小时视频:2-100 MB(取决于屏幕变化和显示器数量)。
  • 每月视频:10-20 GB(取决于屏幕使用时间),可通过压缩预设压缩至原始大小的0.1-0.7倍。
  • 每月SQLite数据库:约160 MB。

常见问题与解决方案

  • 鼠标指针录制闪烁(FFmpeg模式):这是一个Windows历史问题,可通过使用十六进制编辑器修改 avdevice-XX.dll 文件解决。
  • WebUI最近时段无数据:工具正在索引时,WebUI不会显示最新数据。可等待索引完成后刷新,或删除 db 目录下以 _TEMP_READ.db 结尾的临时数据库文件后刷新。
  • OCR不可用或识别率低:检查系统是否安装了目标语言的语言包/输入法,或安装第三方OCR引擎以获得更高精度和多语言支持。

项目状态与相关资源

  • 注意:该项目仍处于早期开发阶段,使用中可能遇到一些小问题,欢迎提交反馈。
  • 致谢:感谢 chineseocr_lite、Windows.Media.Ocr.Cli、wechat_ocr、tesseract-ocr、uform、streamlit 等开源项目。
  • 类似工具:文章列出了在跨平台、Windows、Linux、macOS及Android上提供类似功能的其他工具,包括开源和商业选项。
36. DataFusion Comet: Apache Spark Accelerator (github.com)

Apache DataFusion Comet:Apache Spark 高性能加速器

Apache DataFusion Comet 是一个为 Apache Spark 设计的高性能加速器,基于强大的 Apache DataFusion 查询引擎构建。它旨在显著提升 Spark 工作负载的性能,同时利用通用硬件,并能与 Spark 生态系统无缝集成,无需更改任何代码

核心性能优势

  • 性能与成本:在 TPC-DS @ SF 1000 (1TB) 基准测试中,可实现约 2倍的速度提升,从而带来约 50% 的成本节约
  • 灵活性:用户可以选择将相同的工作负载在现有集群上完成时间减半,或用大约一半的资源维持当前性能水平。
  • 无硬件要求:Comet 在通用硬件上运行,无需 GPU、FPGA 或其他专用加速器,节省来自更高效地利用现有基础设施。

加速范围

Comet 通过原生 Rust 实现替换 Spark 的算子和表达式,使用 Apache Arrow 在 JVM 和原生代码间进行零拷贝数据传输。主要加速组件包括:

  • Parquet 读取:与 Spark 查询规划器集成的原生 Parquet 读取器。
  • Apache Iceberg:加速从 Spark 读取 Iceberg 表时的 Parquet 扫描。
  • Shuffle:支持哈希和范围分区的原生列式洗牌。
  • 表达式:支持涵盖数学、字符串、日期时间、数组、映射、JSON、哈希和谓词类别的数百个 Spark 表达式。
  • 聚合:支持 FILTER (WHERE...) 子句的哈希聚合。
  • 连接:支持哈希连接、排序-合并连接和广播连接。

无缝集成与快速开始

Comet 被设计为 Spark 的即插即用加速器,集成过程无需修改现有 Spark SQL、DataFrame 或 PySpark 代码。

  • 兼容性:支持 Apache Spark 3.4、3.5、4.0 和 4.1,并对 Spark 4.2 提供实验性支持。
  • 安装:通过将对应 Spark 和 Scala 版本的 JAR 包添加到 Spark classpath 并启用插件即可完成安装。
  • 配置示例:典型的配置包括指定 JAR 路径、启用 CometPlugin、设置 Shuffle 管理器以及开启堆外内存等。

社区与许可

  • 社区:用户可通过 DataFusion 的 Slack 和 Discord 频道交流与提问。
  • 贡献:欢迎社区贡献代码、文档或性能优化,具体可参考贡献者指南。
  • 许可:项目采用 Apache License 2.0 开源许可。
37. Show HN: I built a backend so simple that it fits in a YAML file (manifest.build)

Manifest:用YAML配置文件构建的AI后端路由系统

核心功能

Manifest 是一个开源的AI推理路由系统,旨在帮助用户优化AI订阅使用、控制成本。它通过一个简单的YAML配置文件作为后端,将用户的LLM(大语言模型)调用智能路由到最佳模型和提供商。

工作原理(三步流程)

  1. 接入代理:将自主代理、应用程序、编码助手等任何第三方工具连接到Manifest。
  2. 连接提供商:添加所有可用的模型及其成本信息。支持所有基于订阅或用量的云提供商(兼容OpenAI或Anthropic端点)以及本地模型。
  3. 路由与控制:定义路由规则,为每个查询设置合适的模型和提供商。添加故障转移和限制,并实时可视化每一美元的支出。

支持的提供商类型

Manifest 不局限于特定列表,支持同时使用多种提供商:

  • 自带密钥(BYOK)提供商:使用主要提供商的API密钥,按用量付费。
  • 订阅提供商:连接已有的月度订阅(如Anthropic, GitHub Copilot, OpenAI等),优先使用订阅额度,超限后回退到按量付费。
  • 自定义提供商:接入任何兼容OpenAI或Anthropic的第三方提供商。
  • 本地模型:作为一级提供商支持Ollama、LM Studio和llama.cpp,允许在本地基础设施上运行开源模型。

关键特性

  • 成本控制:可连接多个AI订阅,设置预算限制和通知,优化支出。
  • 灵活路由:支持基于请求内容复杂度、自定义HTTP头、主模型与回退模型链(最多5个备用)等多种路由规则。
  • 免费模型支持:可整合来自OpenRouter等提供商的免费模型,与付费模型混合使用。
  • 无缝集成:可作为OpenAI API的直接替代品(Drop-in replacement),仅需更改端点URL。提供针对多种SDK和代理的集成教程。
  • 开源自托管:完全开源。提供基于Docker的自托管版本(支持本地模型)和更易设置的云托管版本。

目标与使命

Manifest 的使命是让所有用户(从个人开发者到企业)都能以可承受的成本高效使用AI,无需牺牲质量。它通过提供工具来简化通常需要专业知识才能实现的AI效率优化技术。

其他信息

  • 免费使用:基础版本免费,用户可连接自己的API密钥开始路由请求。
  • 社区与资源:提供Discord社区、GitHub代码库和Docker Hub镜像。
38. Multi-Array Queue (github.com)

Multi-Array Queue 是一种新型的队列数据结构,它继承了基于数组队列的优势(如内存局部性),同时克服了其主要缺陷——固定容量的限制。

该队列的底层由多个对象数组支撑,这些数组的大小呈指数级增长,并且所有数组均处于使用状态,但仅预先分配第一个具有 initialCapacity 的数组。其详细描述与性能数据可在相关论文中查阅。

相关资源:

  • 交互式模拟器:用于直观了解该队列的工作原理。
  • Javadoc 文档:提供 BlockingMultiArrayQueueConcurrentMultiArrayQueue 两种实现的文档。

开发状态(截至2024年):

  • 此代码处于早期阶段,仅具有学术研究价值,不建议用于生产环境
  • 作者声明因代码量较小,将独立维护,因此不接受合并请求(Pull Requests),但欢迎评论、测试与反馈。

后续发展:

  • 2026年,一个真正的无锁(Lock-Free)Multi-Array Queue 被开发出来,但由于128位CAS(比较并交换)原子指令无法从Java中访问,其实现采用了不同于Java的技术。

许可证: MIT 许可证。