该项目已迁移至新域名 getflocked.dev，所有内容将在短暂延迟后自动跳转至该地址的指定页面。用户无需手动操作即可完成访问转移。

苹果于2024年10月29日发布了全新的Mac mini，搭载M4和M4 Pro芯片。这款全新的台式电脑体积仅为5x5英寸，比前代设计小一半以上，同时性能大幅提升，并成为苹果首款碳中和的Mac。

核心升级与性能

• 搭载M4与M4 Pro芯片：M4芯片的CPU性能比M1机型提升最高达1.8倍，GPU性能提升最高达2.2倍。M4 Pro芯片则面向专业用户，提供高达14核CPU和20核GPU，首次支持硬件加速光线追踪，并首次配备雷雳5接口，数据传输速度可达120 Gb/s。
• 具体性能对比：与Intel Core i7机型相比，M4 Pro在音频处理、游戏性能、图像放大及AI语音转录等方面均有显著提升（例如AI转录速度提升最高20倍）。与M1机型相比，M4在电子表格计算、AI转录、全景图像合并等方面也快很多。

设计与连接性

• 极度紧凑的尺寸：得益于苹果芯片的高能效和创新散热架构，新Mac mini在仅5x5英寸的机身内集成了强大性能。
• 增强的端口布局：前面板新增两个USB-C端口和支持高阻抗耳机的音频插孔。后面板方面，M4机型配备三个雷雳4端口，M4 Pro机型则配备三个雷雳5端口。两者均标配千兆以太网口（可选配10Gb以太网）和HDMI端口。
• 显示支持：M4机型最高支持连接两台6K显示器和一台5K显示器；M4 Pro机型最高支持连接三台6K显示器。

Apple Intelligence与隐私

新款Mac mini为Apple Intelligence而构建，这是苹果的个人智能系统，能帮助用户写作、沟通和表达。功能包括：

• 全系统写作工具，用于改写、校对和总结文本。
• Siri功能增强，支持语音和键入指令。
• 新增Image Playground和Genmoji等功能。
• 整合ChatGPT（12月起）。
• 隐私保护：大部分处理在设备端完成，复杂任务通过Private Cloud Compute处理，保护用户数据。

环保里程碑

新Mac mini是苹果首款碳中和Mac，总体使用超过50%的再生材料，包括100%再生铝机身和100%再生稀土元素。通过使用可再生能源、投资清洁项目以及购买优质碳信用，其整体碳足迹减少了80%以上。包装也全面改为纤维材料。

发售与价格

• 售价：搭载M4的机型起售价599美元（教育优惠499美元）；搭载M4 Pro的机型起售价1399美元（教育优惠1299美元）。
• 发售时间：即日起接受预购，11月8日正式发售。
• macOS Sequoia：新系统包含iPhone镜像、Safari优化、更易的窗口排列、全新密码管理App等众多新功能。

附带服务

苹果提供以旧换新计划、AppleCare+服务，以及购机后的个人设置指导服务。

事件概述

作者在深夜收到来自托管商（Hetzner）的滥用投诉邮件，指控其服务器（IP: 195.201.9.37）对多个远程IP的22端口发起扫描连接，日志显示了大量被拒绝（DENIED）的连接记录。作者初步检查后，未发现服务器存在恶意软件入侵或异常活动迹象。

问题根源：IP欺骗与“回声”

通过抓包分析，作者发现真相并非服务器对外发起连接，而是有外部机器向其发送了大量TCP重置（RST）数据包。这是典型的“回声”（Backscatter）现象，表明有人正在互联网上使用作者的服务器IP地址作为伪造的源地址，向其他主机的22端口发送连接请求（SYN包）。目标机器响应这些伪造请求时，将RST包发回给了作者的服务器，从而触发了安全监控系统生成针对作者的滥用报告。

攻击模式与潜在动机

攻击者利用某些网络服务提供商未实施源地址验证（BCP38）的漏洞，能够发送源IP地址任意的网络数据包。攻击流程如下：

1. 攻击者向互联网上大量主机（可能特意选择了蜜罐或会自动发送投诉的网络）的22端口发送TCP SYN连接请求。
2. 这些请求的源IP地址被伪造为攻击者选定的目标（例如作者的服务器）。
3. 目标机器收到SYN包后，若端口开放，会向伪造的源IP发送SYN-ACK或RST响应；若端口关闭或受监控，则可能触发针对伪造源IP的滥用投诉。
4. 大量投诉可能导致目标服务器被托管商列入黑名单、警告甚至关闭。

作者最初排除了其运行的Tor中继节点与此事的关联，但后续调查发现，其他运行Tor中继的服务器也遭受了完全相同的攻击模式。这表明攻击者可能有意针对Tor网络参与者，试图通过大量投诉使托管商关闭这些节点，从而削弱Tor网络。

核心问题与现状

这种攻击并不新颖，但其有效性源于互联网基础设施的长期缺陷：尽管BCP38标准于1998年提出，旨在通过在与对等网络边界过滤数据包来阻止源IP欺骗，但至今仍有许多网络服务提供商未能实施。这使得单一的攻击者即可利用未过滤的网络，轻松实施大规模的IP欺骗攻击。

应对与建议

文章指出，由于难以追踪伪造数据包的真实来源，防御此类攻击具有挑战性。作者建议，若收到类似的滥用投诉，应检查服务器的入站流量（特别是来自高危端口的响应包），以确认是否为回声流量。在向托管商申诉时，可以尝试解释这种攻击原理，说明服务器是欺骗攻击的受害者，而非攻击源头。文章最后呼吁互联网社区应加强基础安全措施（如全面实施BCP38和RPKI）的部署，以从根本上解决此类问题。

本文探讨了投币电话（payphone）行业的历史、技术演变及其中滋生的投资骗局。

1. 技术演进与行业变革

• 传统模式：早期投币电话由电话公司拥有和运营，依赖电话交换机进行控制与计费。
• COCOT的出现：1970年，Robotguard公司引入了用户拥有并运营的投币电话，通过合规的防盗报警器接入电话网络，合法绕开了电话公司的控制，开创了COCOT模式。
• 智能投币电话普及：1984年AT&T拆分后，随着电子技术进步，更先进的COCOT（即“智能投币电话”）开始普及。它们能内部处理计费，功能上可媲美电话公司设备，并使远程管理成为可能，降低了运营门槛。

2. 成为骗局温床

• “被动收入”诱惑：投币电话的自动化特性被包装成低投入、高回报的“被动收入”机会，吸引了大量寻求快速致富的投资者。
• 商业模式复杂化：COCOT模式使得设备所有者、位置提供者、运营商可能分离，收入分成复杂，为不透明操作提供了空间。
• 关键的骗局案例：
  • ETS Payphones Inc.：该公司通过招募代表（多为保险经纪人），向投资者（许多是退休人员）以高价出售投币电话及场地租赁权，承诺每月固定回报并代为运营维护。实际上，ETS从未盈利，早期投资者回报来自后期投资者本金，构成庞氏骗局。2000年被SEC起诉，创始人入狱。
  • MMDS（多点多信道分布式服务）骗局：文章类比了同时期“无线电缆”行业的诈骗浪潮，骗子通过销售所谓的“股份”筹资，但从未真正建设网络，纯粹骗取资金。
• 欺骗性宣传：当时充斥着全国性分类广告，以“买下就退休”、“年入15万”等话术诱骗人们购买“现成的”投币电话路线，但这些生意往往不真实或已无利可图。

3. 行业衰退与骗局延续

• 行业萎缩：90年代末至21世纪初，手机普及导致投币电话使用率骤降，许多电话公司退出该业务，资产被少数大型运营商（如PTS）收购。
• 骗局模式互联网化：投币电话骗局的模式在互联网时代以新形式重现。例如，Pantheon Holdings公司于2005年左右推出“互联网信息亭”，向投资者高价出售设备，承诺代运营并回报收益，但同样因放置在低流量地点且无实际营收，构成欺诈。

总结：投币电话从电话公司垄断到用户可拥有的技术革命，虽然简化了运营，但也因易于包装成“被动收入”投资产品，加上复杂的分成模式和监管缝隙，使其在90年代成为金融骗局的集中地。ETS庞氏骗局是其典型代表。尽管行业本身已随着技术变迁而衰落，但这种利用新兴自动化技术进行的投资诈骗模式，在后来的互联网时代依然延续。

告别WordPress

作者在参与WordPress项目14年以上后正式离开。其贡献包括作为Meetup和WordCamp的演讲者与组织者、核心代码贡献者、插件开发者、照片贡献者，并长期担任WordPress官方求职网站的版主。

离开的原因

作者自2017年左右开始逐渐疏远WordPress项目，认为该“社区”存在严重不诚实现象：

• 观察到许多贡献者因工作重点与项目领导层（Matt Mullenweg）的意愿不符而被忽视。
• 看到在隐私、可访问性、治理等领域做出重要贡献的成员受到虐待并被排挤。
• 批评众多WordPress公司利用项目的“美德”作为借口，支付低薪并滥用员工，甚至威胁员工“能力不足无法离开”以维持低待遇。
• 对Automattic公司（WordPress.com背后的企业）的“邪教式”文化表示不信任，曾因目睹朋友受虐而拒绝认真参与其招聘试用。
• 认为WP Engine（作者2018年加入的公司）是生态系统中最诚实的公司，因其直言盈利目的且支付了相对较高的薪酬。

当前WordPress的动荡

作者指出，WordPress当前的内部冲突（“内爆”）进一步证实了其判断。尽管之前仍在开发自己的WordPress开发环境Kana并探索插件创意，但Matt Mullenweg对WP Engine的攻击行为成为“压垮骆驼的最后一根稻草”。作者认为这暴露了WordPress的本质：一个滥用、掠夺性的组织，以“美德”为掩饰剥削其他公司，榨取免费劳动力。同时，作者预测WordPress已过巅峰，未来相关公司将持续争抢不断缩小的市场份额，且当前领导与项目结构无法改变这一趋势。

告别与后续行动

基于以上原因，作者决定彻底离开：

• 归档了所有剩余的WordPress项目（Kana和网站主题），直至项目建立合理的治理机制。
• 停止参与Meetup和WordPress活动。
• 自2013年以来几乎每日负责的求职网站版主工作也已终止。

作者表示，如果WordPress未来能重获新生，减少其野心并建立符合其宣称美德的治理结构，他将重新考虑立场。

对仍在WordPress社区的成员的寄语

作者感谢所有曾交流与支持的社区成员，肯定了许多个体和小型社区的贡献。同时，他呼吁他们谨慎考虑自身行为对他人影响，避免将新成员引入可能受虐的生态系统。

史蒂夫·鲍尔默是一位被低估的CEO

核心论点

主流观点认为微软在史蒂夫·鲍尔默领导下陷入停滞，后被萨提亚·纳德拉“神奇”拯救。然而，这种叙事严重低估了鲍尔默对微软成功的贡献。在鲍尔默任期内，微软的财务表现强劲，并做出了关键的长期投资，为纳德拉时代及之后的成功奠定了基础。

鲍尔默的主要成就与长期投资

• 财务表现强劲：营收从1998年接任时的140亿美元增长至离任时的830亿美元，利润丰厚。
• 关键业务布局：
  • Azure云服务（2010年）：尽管最初不被看好，但如今已成为全球前三大云服务商，估值可能高达万亿美元。其建立的企业销售体系对成功至关重要。
  • Office 365（2010年发布）：成功将企业办公软件套装从盒装软件转向订阅制云服务。
  • Bing搜索引擎（2009年）：虽常被视为失败案例，但根据后续数据估算，其价值已达数百亿美元。
  • 企业销售团队：在鲍尔默时期（他本人即销售出身）得到极大强化和发展，成为微软产品（如Azure、Office 365）在企业市场成功的强大引擎，甚至能在竞争中击败免费提供的对手产品。
  • 其他成功投资：包括Xbox（收购Bungie，推出《光环》）、TypeScript编程语言、VS Code编辑器、Surface硬件产品线等。

对批评的回应

• 关于“错失风口”的批评：鲍尔默任期内确实有失败项目（如Windows Phone、Zune、HoloLens），但这在科技行业属常态，类似风险投资。评判CEO应看整体投资组合的回报，而非单个失败。微软在鲍尔默任期内的整体回报非常出色。
• 关于“缺乏远见”的批评：鲍尔默顶住了压力，坚持将Windows等成熟业务的利润投资于Azure、Bing等未来业务，这正是远见卓识的体现，尽管当时备受嘲笑。
• 关于“接手公司困境”的说明：鲍尔默接手时，微软已因反垄断案等因素被外界视为“将死”的巨人，行动受限。他成功清理了公司内部严重的政治障碍，为纳德拉留下了一个更健康的运营环境。

更广阔的视角

• 鲍尔默的遗产：他不仅确保了微软当时的财务健康，更通过Azure、Office 365等战略布局，为微软未来数十年的成功铺设了道路。
• 微软的长期强势：微软自1975年成立以来，持续强劲执行了近50年，在科技行业几乎无出其右。鲍尔默是这一长期成功历程中承上启下的关键一环。
• 对公司的意义：微软从一家盒装软件公司，成功转型为硬件（Xbox）和云服务（Azure）巨头，这种跨领域转型能力在业界罕见，而这些转型正是在鲍尔默任期内实现或启动的。

结论

鲍尔默是一位被外界叙事低估的CEO。他不仅在任期内带来了优异的财务业绩，更做出了具有前瞻性的战略投资，解决了公司内部的治理难题，为微软在纳德拉时代的辉煌铺平了道路。将微软的后续成功完全归功于纳德拉，是对鲍尔默深远贡献的忽视。

使用Cursor编写代码的经验分享

Cursor简介

Cursor是Visual Studio Code的分支，在核心界面中集成了大语言模型功能。它是一款商业产品，提供免费版和订阅版。其主要功能包括：

• Tab补全（仅订阅用户可用）：专有微调模型提供代码补全和下一个建议操作导航
• 内联编辑（免费/付费用户）：基于基础模型（如GPT或Claude）通过聊天界面编辑代码
• 侧边栏聊天（免费/付费用户）：更大空间的聊天界面，支持多文件代码示例建议
• Composer（免费/付费用户）：专门用于跨代码库重构，生成多文件差异供审阅批准

核心功能体验

Tab补全

• 最自然的日常编程工具：建议行、多行或整个函数的补全，并推荐下一个编辑位置
• 高效重构：例如重命名变量后，通过Tab键快速应用到整个文件的相关位置
• 自动修复和建议：能独立发现错误并提议修复，添加依赖时建议导入，根据函数签名和文档字符串生成完整函数
• 速度极快：建议几乎在停止输入后立即出现，无明显延迟
• 主要缺点：偶尔会错过建议（无法恢复）；极少数情况下会错误地接受被拒绝的建议，可能导致难以追踪的bug

内联编辑、侧边栏聊天和Composer

• 内联编辑：选中代码后通过快捷键激活，输入所需更改，生成差异视图供接受或拒绝。适用于函数内部代码修改或小范围重构。
• 侧边栏聊天：更大的多轮对话空间，适合单文件较大重构或基于当前文件创建新文件。能根据查询和后台索引自动猜测相关文件。
• Composer：专门为跨文件重构设计，提供更好的多文件差异审阅体验。

.cursorrules文件

• 位于工作区根目录，为各种聊天模式提供额外上下文
• 可包含代码仓库的编码标准、常用包和其他文档
• 有助于解决Cursor不遵守编码风格的问题（除非在编辑的文件中已存在该风格）
• 当前限制：每个工作区仅一个文件，对多语言单仓库设置较困难

工作流程的改变

库和框架使用减少

• 对于小型实用工具，更倾向于让LLM根据特定需求编写，而非引入通用库
• 这些库往往逐渐积累不必要的功能和复杂性
• 仅用一年以上的Node.js项目可能难以运行，有时不如从头开始

DRY原则的重新考量

• 不再过早抽象以减少技术债务
• 能够参考其他代码创建大量代码，而无需立即将其提取到函数或类中
• 如需重构共享逻辑，LLM可提供帮助

更愿意使用不熟悉的语言/框架

• 例如使用R语言进行数据可视化：描述所需可视化，即可获得正确的数据处理和ggplot可视化代码
• 任务时间从1小时以上缩短至5分钟
• 更少因不熟悉而放弃使用特定语言

快速迭代小型组件

• 在集成到大型代码库之前快速原型化小组件
• 可在动态类型语言中原型化逻辑，然后立即转换为强类型语言集成到Web应用中
• LLM可自动生成测试数据或创建后端模拟以编写前端

总结

• Cursor目前是LLM编码助手潜力的最佳体现
• 其真正价值不在于更快编写代码（实际编码并非瓶颈），而在于改变编码方式
• 无论未来是否继续使用Cursor，作者建议有意探索此类工具价值的人尝试使用

文章摘要

本文探讨了HTML原生表单验证功能强大但应用不足的原因，核心论点在于**setCustomValidity API 的命令式特性是其在声明式框架中推广的主要障碍**。

主要内容与结构

1. HTML表单验证方式

   • 使用特定输入类型属性：如 type="email" 或 type="number"。
   • 使用约束属性：如 pattern、maxlength 或 required。
   • 使用命令式方法：input.setCustomValidity(message)，可创建任意验证逻辑，是最强大的方式。

2. setCustomValidity 的缺陷与使用痛点

   • 纯粹的命令式API：没有对应的声明式属性，导致在React等声明式框架中使用时产生大量样板代码。
   • 初始状态验证复杂：要实现类似 required 属性的功能，需结合 useRef、useLayoutEffect 和 onChange 处理器，导致验证逻辑重复、代码内聚性差且易出错。
   • 繁琐的仪式：作者认为，这种复杂的实现是原生表单验证采纳率低的主要原因。

3. 理想的解决方案与用户态模拟

   • 缺失的属性：作者提出，一个声明式的 custom-validity 属性是关键，它允许以更简洁、更具声明性的方式定义验证逻辑。
   • 用户态实现：通过一个自定义的 <Input /> 组件，内部使用 useLayoutEffect 来监听 customValidity 属性的变化并调用 setCustomValidity，从而模拟此功能。

4. 展示其强大功能 通过两个复杂案例，证明了该模拟方案能优雅地处理：

   • 异步验证：例如检查用户名是否已被占用。使用 useQuery 管理异步状态，并通过 customValidity 属性统一描述加载中、错误和验证结果等状态。
   • 依赖字段验证：例如密码确认表单。通过比较两个输入框的值，轻松实现字段间一致性验证。

核心结论

作者总结道，setCustomValidity 方法本身功能全面，足以应对各类验证需求。但其命令式API设计导致了糟糕的开发体验，这是其未被充分利用的根本原因。通过创建一个声明式的包装组件可以弥补此缺陷，但作者期望未来能在HTML规范中原生支持类似的声明式属性，以从根本上改善问题。

理查德·斯凯瑞是极具影响力的儿童文学作家兼插画家。他的作品，如《忙忙碌碌镇》系列，通过将动物拟人化并描绘一个丰富、忙碌的世界，深深吸引了小读者。例如，作者回忆童年时曾严格模仿书中角色“小熊肯尼”的晨间 routine，甚至要求祖母准备书中的食物，这体现了斯凯瑞故事对孩子行为的模板化影响。

斯凯瑞于1919年生于波士顿，自幼更喜绘画而非文字。他早期就读于艺术学校，二战期间在军队中负责绘制宣传材料，战后成为插画师。他最初为“金色童书”系列工作，早期作品采用细腻的水彩风格描绘人类角色，但反响平平。直到他转向使用动物角色并发展出更自由、活泼的铅笔线条风格后，才迎来了创作突破。1963年出版的《我是兔子》展现了其优雅静谧的插画风格，而1968年的《最好的单词书》则以其“图画即词汇”的互动方式成为畅销经典，奠定了“斯凯瑞世界”的基础。

斯凯瑞创造了一个以“忙忙碌碌镇”为背景的连贯宇宙，角色如赫克猫、小猪一家和蚯蚓“小虫虫”不断出现。他的书看似描绘了一个甜美有序的社会，但也暗含一丝混乱与复杂性。1974年出版的《车来了》是其代表作，通过充满细节和动态的交通工具场景，捕捉了工业世界的“交通芭蕾”，并加入了寻找金色小虫的互动游戏。

值得注意的是，斯凯瑞于1967年移居瑞士，其作品常透露出一种欧洲式的、注重社区与责任的“文明”感。他坚持用动物而非人类作为主角，认为这能更好地激发孩子的天然共情心，尽管这也偶尔引发关于食肉动物与食草动物共存等荒诞问题的讨论。文章将此与阿特·斯皮格曼在《鼠族》中使用动物角色进行严肃历史叙事的手法作了简要对比，指出两者目的截然不同。

文章最后强调，斯凯瑞的天赋在于“画故事”而非仅仅“为故事配图”。他通过视觉叙事，将图像作为理解世界的第一语言，成功保留了童年视角的惊奇与细节，其作品因此得以跨越时代，持续引发共鸣。

InkSight：通过学习阅读与书写实现手写笔记的数字化转换

研究背景与目的

数字笔记具备持久、可编辑和易检索的优势，但许多人仍偏爱传统纸笔。将物理笔迹转化为“数字墨水”（在线笔画轨迹）能结合两者优点，保留真实手写风格并支持自由编辑。现有方案多依赖智能笔等专用硬件，阻碍了普及。为此，研究团队提出 InkSight，无需专用设备，仅通过手写笔记照片即可提取生成笔迹的笔画。

核心挑战

1. 监督数据有限：缺乏包含图像与真实数字墨水配对的大规模数据集。
2. 大图像可扩展性：模型需有效处理任意大小和分辨率的输入图像。

方法与技术结构

InkSight 摒弃了依赖梯度、轮廓等传统几何特征的方法，转而训练模型“阅读”（识别文本）和“书写”（输出符合人类书写动态的笔画）。

• 多任务训练：结合识别与去渲染（derendering）任务，赋予模型语义理解和书写力学知识，从而在缺乏大量配对样本的情况下实现良好泛化。
• 系统工作流：为降低大图像的计算成本，系统分三步运行：(1) 使用 OCR 提取单词级边界框；(2) 对每个单词单独进行去渲染；(3) 用数字墨水替换原图的像素表示。同时采用数据增强（如随机化角度、添加噪声和背景）缩小合成图像与真实照片的域差距。
• 视觉-语言模型架构：结合 ViT 编码器与 mT5 编码器-解码器。设计专用的墨水标记器（Ink Tokenizer），将笔画采样点的 x、y 坐标转换为大语言模型友好的 Token 序列。训练集包含 5 种混合任务，使模型在训练和推理时能准确区分任务类型。

实验结果

研究团队训练了 Small-p、Small-i 和 Large-i（约 10 亿参数）三个模型变体，并与 GVS 基线对比：

• 定性评估：模型能准确提取文本、忽略无关背景并有效处理遮挡。相比产生重复笔画且难以区分前背景的 GVS，Large-i 模型保留了更多细节并适应更多样的图像风格。
• 定量（人工）评估：评估者对模型输出与人工描摹数据进行盲测。结果显示，Large-i 模型生成的数字墨水质量与人工生成相当，87% 的输出被评为“好”或“仅有微小错误”。

结论

InkSight 提出了一种无需配对训练数据即可将手写照片转换为数字墨水的首创方法。该模型对复杂光照和遮挡等输入具有鲁棒性，能处理完整笔记并泛化至草图，且完全基于标准模块构建，显著降低了手写数字化的门槛。

文章标题“向量数据库是错误的抽象”提出了一个核心论点，即当前独立的向量数据库方案可能并非最优选择。与之相对，文章内容重点介绍了 Timescale 公司提供的替代方案，即在其 PostgreSQL 产品生态中整合向量与关键词搜索能力。

具体而言，Timescale 的产品线旨在提供更集成的解决方案：

1. Timescale Cloud：一个面向初创公司和企业的强大弹性云平台。
2. TimescaleDB Enterprise：适用于本地部署、边缘计算和私有云的自托管版本。
3. 开源产品 TimescaleDB：在 PostgreSQL 上支持时序数据、实时分析和事件。
4. Search 功能：这是在 PostgreSQL 上实现的向量与关键词搜索服务。

文章的核心立场是，将向量搜索作为独立数据库的抽象层可能是不必要的。Timescale 主张通过扩展 PostgreSQL 这一成熟且广泛使用的关系型数据库系统，来原生支持向量搜索和其他功能，从而为用户提供一种更统一、更强大的数据管理体验。这种集成方法旨在避免维护独立向量数据库带来的复杂性和额外开销。

Prisma Postgres 总结

Prisma Postgres 是 Prisma 公司推出的一项托管 PostgreSQL 服务，旨在为开发者提供一个始终在线、按需付费的数据库解决方案，并通过其独特的架构设计消除了传统“无服务器”数据库的冷启动问题，同时提供了慷慨的免费套餐。

核心优势与特性

1. 解决传统痛点：

   • 无冷启动：数据库从休眠状态恢复的延迟仅为毫秒级，保障了用户体验。
   • 慷慨的免费套餐：得益于高效的底层架构，Prisma 能够提供其他服务商难以负担的免费使用额度。
   • 简单定价：采用按查询量、数据出口量和存储量/事件传输量付费的模式，无固定计算成本。

2. 独特架构与技术：

   • 底层基础设施：服务直接运行在租用的全球数据中心的物理服务器（裸金属）上，而非 AWS 等主要云商，从而完全掌控硬件、性能和成本。
   • 核心执行环境：采用 Unikraft Cloud 平台，其核心是：
     • Unikernels：将 PostgreSQL 及其依赖打包成一个超轻量级、高度特化的二进制镜像（仅约 61MB，是原始镜像的 20%），如同一个为数据库量身定制的操作系统。
     • MicroVMs：这些 unikernel 镜像作为轻量级微虚拟机运行，基于 Firecracker 虚拟机监视器，启动时间在毫秒级。
     • 毫秒级云栈：包括定制的控制器和代理，配合多层级虚拟机快照技术，实现了快速启动、休眠和自动伸缩。
   • 高密度与经济性：这种架构允许在单台物理服务器上安全地运行数千个数据库实例，实现了极高的资源利用率和成本效益。

产品集成与现状

Prisma Postgres 作为 Prisma 数据层愿景的一部分，与 Prisma 生态深度集成：

• Prisma ORM：提供类型安全的查询和迁移管理。
• Prisma Accelerate：内置的连接池和全球边缘缓存层，可显著提升查询速度。
• Prisma Optimize：AI 驱动的查询分析与优化建议。
• Prisma Studio：可视化的数据编辑界面。

目前，Prisma Postgres 已进入 Early Access（早期访问）阶段，可用于实验和小型项目，但不建议用于生产环境。其技术愿景是未来为全球应用提供一个完全集成、高效且易于使用的数据层。

AI 火焰图（AI Flame Graphs）工具总结

工具概述

AI 火焰图是 Intel 开发的一款新型性能分析工具，旨在通过可视化 AI 加速器/GPU 硬件配置及完整软件栈，帮助降低 AI 计算资源与电力成本。该工具基于 CPU 火焰图技术构建，首个预览版已在 Intel Tiber AI Cloud（针对 Intel Data Center GPU Max Series）上线。

核心功能与结构

• 多层可视化：X 轴宽度与资源消耗成正比。绿色框代表 AI/GPU 加速器执行的指令，浅蓝色为源代码，红/黄/橙色为触发 AI/GPU 程序的 CPU 代码路径。开发者通过识别最宽的矩形来快速定位性能瓶颈。
• 指令偏移分析：区别于仅追踪 CPU 栈或使用高开销二进制插桩的传统工具，AI 火焰图以极低开销、生产环境安全的方式，直接分析加速器上的指令偏移，并展示全栈视图。
• 样本搜索：内置搜索功能可高亮特定术语（如停顿原因、函数名），并计算其在栈样本中的百分比。基于 EU 停顿（stall）的采样机制能精准定位阻碍代码向前推进的性能痛点。

技术挑战与解决方案

• 底层调试障碍：GPU/AI 程序通常不存于文件系统或主存中，且缺乏标准的进程表和调试接口。团队结合 eBPF 和现有硬件调试接口，克服了加速器内存不可达及符号解析等难题。
• PyTorch 全栈支持：工具已实现对 PyTorch（粉色框显示）的支持，能够完整追踪从 Python 源码到 GPU 内核（如 JIT 生成的 oneDNN）的执行路径。
• 配置与开销优化：当前部分复杂工作负载需修改依赖（如启用帧指针以支持栈回溯），存在一定配置成本与中等开销。团队正将相关优化推送到上游代码库，以实现未来的低开销“开箱即用”。

应用价值与对比

• 用户与收益：面向 AI 开发者与评估团队。虽初期需适应全栈视图，但熟练后可在一分钟内定位关键问题。预计可带来 10% 至 50% 以上的性能提升，显著降低数据中心能耗与资金成本。
• 技术优势：相比 NVIDIA Nsight Graphics 中缺乏 CPU 上下文且需拦截启动的浅层 GPU 火焰图，Intel 的方案支持随时进行低开销、全栈式的性能分析，提供更完整的系统级视图。

Integuru (YC W24) 总结

项目概述

Integuru 是一个使用大型语言模型（LLMs）逆向工程内部 API 的工具，适用于没有官方 API 的平台。这是其最早公开版本（v0），最新版已迁移至 www.integuru.com。核心思路是通过分析浏览器网络请求，生成可运行的集成代码。

主要功能与工作原理

• 输入：用户通过 create_har.py 生成 .har 文件（包含浏览器网络请求）、cookies.json 文件，并编写提示描述浏览器触发的操作（如下载水电费账单）。
• 处理流程：
  1. 识别目标请求：代理分析网络请求，找到执行所需操作的请求（例如，下载账单的 API 端点）。
  2. 构建依赖图：识别请求中的动态部分（如 accountId、userId），递归查找提供这些部分的其他请求，直到所有依赖仅基于认证 cookies。构建完整的请求依赖图。
  3. 代码生成：遍历依赖图，从叶子节点开始，将每个请求转换为可运行的 Python 函数，最终生成访问所有内部端点的代码。
• 输出：可直接运行的 Python 代码，模拟浏览器行为以自动化平台操作。

关键功能

• 依赖图生成：可视化请求间的依赖关系，支持输入变量（如年份选择），但当前仅限图生成阶段。
• 集成代码生成：自动生成包含所有依赖请求的完整代码，支持 --generate-code 选项。
• 模型灵活性：推荐使用 OpenAI 的 gpt-4o 进行图生成（支持函数调用），代码生成可切换至 o1-preview（如果账户可用）。

设置与使用

• 环境要求：Python 3.12，Poetry 包管理器，OpenAI API 密钥。
• 安装步骤：
  1. 设置 OPENAI_API_KEY 环境变量。
  2. 使用 poetry install 安装依赖。
  3. 运行 poetry run python create_har.py 启动浏览器并记录操作。
  4. 执行命令如 poetry run integuru --prompt "download utility bills" --model gpt-4o。
• 命令行选项：包括模型、提示、HAR 路径、cookie 路径、最大步骤、输入变量等。

测试与部署

• 单元测试：使用 pytest 运行。
• CI/CD：通过 GitHub Actions 自动化测试，定义在 .github/workflows/ci.yml，在推送和拉取请求时触发。
• 2FA 支持：如果目标平台使用双因素认证，用户需手动完成 2FA 并获取 cookies/令牌，后续流程不变。

隐私与数据政策

• 数据存储：所有数据（如网络请求和 cookies）本地存储在 .har 和 .json 文件中。
• LLM 使用：依赖 OpenAI 的云基模型（如 gpt-4o 和 o1-preview），但用户使用数据不会用于训练或改进模型。

其他信息

• 贡献与支持：欢迎通过 GitHub 提交问题或拉取请求；可通过 richard@integuru.com 联系。
• 演示：项目提供了演示示例，展示实际应用。

此工具简化了无官方 API 平台的自动化集成，通过 LLMs 智能分析网络请求，生成可维护的代码。

昆虫和微型生物利用静电进行移动、躲避天敌和收集花粉等行为，这一“空中电感”领域的研究正在揭示进化可能如何塑造这一现象。

主要发现

• 昆虫在飞行中会积累静电荷（类似穿着袜子在地毯上摩擦产生的电荷），这使其能够感知并影响周围环境中的物体。
• 研究证实，蜜蜂能探测并区分花朵发出的电场，并能在与花粉无接触的情况下，通过静电力跨空气间隙收集花粉。
• 蜘蛛、蜱虫等其他小型生物也具有类似能力。动物的静电对生态系统有直接影响，例如蜱虫和蛔虫等寄生虫借助宿主动物的电场搭便车，蜘蛛通过吐丝“乘风”进行长距离飞行。

关键研究与机制

• 蜘蛛网的主动吸引：研究者偶然发现，带负电的蜘蛛网能主动吸引带正电的昆虫猎物，表明静电改变了捕食的物理过程。
• 尺寸是关键：静电对小生物的影响远大于大生物。昆虫体重轻、表面积与体积比高，这些物理特性使其电荷密度更高，因此它们所处的世界比人类世界更具“电气性”。
• 传粉互惠：静电可能促进了植物与传粉昆虫之间的协同进化。蜜蜂能感知花朵上其他蜜蜂留下的正电荷，并利用静电收集花粉，提高了传粉效率。
• 静电的进化适应：最新研究测量了11种蝴蝶和飞蛾的静电荷，发现它们在飞行时都能积累高达5千伏/米的电荷，足以从6毫米外吸引花粉。此外，夜行性飞蛾携带的电荷较少，可能是为了减少在夜间被依赖非视觉线索的捕食者探测到的风险。
• 天敌探测：研究发现，毛虫身上的微小感应毛能在电场下偏转，当暴露于类似黄蜂产生的电场时，毛虫会表现出防御行为，表明猎物和捕食者可能仅通过静电就能相互探测。

进化意义与生态系统影响

• 证据表明，静电感知和携带能力可能像其他性状一样，受到进化力量的塑造。能够更好利用静电的生物（如静电探测能力更强的毛虫或电荷较低的夜行飞蛾）可能具有生存优势，相关基因和性状可能在后代中增强和普及。
• 整个生态系统可能依赖于这些看不见的电场。如果静电能力突然消失，许多动物可能需要适应，植物进化也可能受到影响（例如，花朵可能演化出产生合适静电场的特征）。
• 人类活动（电子设备、电线、化肥等）不断向环境中释放静电，可能会干扰依赖静电的生物系统。

未解问题与展望

• 虽然已证实静电在昆虫生态中具有功能，但关于其进化起源（是偶然还是适应性演化）以及具体机制仍需更多研究。
• 科学家希望能探索更多空中静电感的案例（如交配行为），并将动物利用静电的能力视为其常规感官能力的一部分。
• 该领域强调了通过研究远小于我们的生物，可以拓宽我们对自然界运作方式的理解。

Block Block Device 项目概述

项目性质
Block Block Device 是一个结合 Minecraft 模组与 NBDKit 插件的工具，允许用户在计算机上创建以 Minecraft 世界中的红石存储为基础的块设备。

核心功能

• 通过 Minecraft 中的红石方块实现物理存储模拟。
• 将虚拟块设备映射到计算机的 /dev/nbd0 等路径。

系统要求

• NBDKit
• Minecraft 1.19.3（多玩家需服务器端安装）
• NBD 客户端连接工具（如 nbd-client）

基本使用流程

1. 安装 Fabric 模组到 Minecraft。
2. 启动游戏并进入世界。
3. 运行 NBDKit 插件命令：
   nbdkit -f -v python ./craftnbd/craftnbd.py
4. 通过客户端连接：
   nbd-client -d /dev/nbd0（可能需要先执行 modprobe nbd）

模组功能细节

• 在端口 8394 上提供 HTTP 服务器，支持通过 HTTP 请求读写 Minecraft 世界中的方块。
• 游戏内命令：
  • /generate_memory：用内存单元填充区块。
  • /encode_chunk 和 /decode_chunk：读写区块中内存单元的数据。

POSIX 2024 标准更新摘要

历史背景

POSIX 标准起源于 Unix 操作系统的标准化需求，旨在解决不同系统间的互操作性问题。当前标准由 Austin Group 维护，POSIX 2024 是其最新版本，重点对 XCU 部分（Shell 命令语言与工具） 进行了现代化改进。

主要更新亮点

1. Shell 中对文件名的处理

• 问题：传统 shell 脚本错误地假设文件名不包含换行符（\n），导致基于 ls | read 等模式的脚本可能出错。
• 解决方案：
  • NUL 分隔符方案：find 新增 -print0 选项，xargs 支持 -0，read 支持 -d '' 以使用 NUL 作为分隔符。
  • 根本性方案：强烈建议（并鼓励实现报错）在创建或处理文件名时，若文件名包含换行符，则应产生错误或拒绝操作。此规则适用于 ls、cp、mv、rm、find、sed 等近 70 个标准工具。
• 影响：旨在使包含换行符的文件名变得不常见，从而使许多简单脚本在未来变得更加正确和安全。

2. 现代 C 语言支持

• 变更：POSIX 2024 现在要求符合 C17 标准（ISO/IEC 9899:2018），而不再要求过时的 C89 标准。
• 意义：这将推动工具链（包括嵌入式领域）对现代 C 特性的支持，使开发者能更自由地使用 Unicode 支持等新功能，而非局限于旧标准。

3. 限制管理与进程超时

• ulimit 增强：现在能报告并设置硬限制和软限制，新增了对核心文件大小、数据段大小、打开文件描述符数量、栈大小、CPU 时间和地址空间等的控制。
• renice 更新：支持 -n 选项以相对方式调整进程优先级。
• 新增 timeout 工具：可为命令执行设置超时时间，支持自定义信号并可在第一次超时后发送 SIGKILL，能处理子进程。

4. Makefile 兼容性改进

• 问题：不同实现的 make（如 GNU Make、BSD make）语法不兼容。
• 改进：POSIX 2024 增加了对 $^、$+、::=、!=、?=、+= 等操作符和宏赋值形式的支持，以及 .PHONY、.WAIT 等特殊目标。
• 目标：使编写可跨平台（尤其是 GNU Make 和 BSD make）运行的简单 Makefile 变得可行，尽管通配符（如 *.c）仍需手动处理。

5. 日志记录功能强化

• logger 改进：若无非选项参数，则从标准输入读取内容进行日志记录；支持通过 -f 记录指定文件内容、-p 设置日志优先级、-i 包含进程ID、-t 设置标签。
• 新行为：输入中的每一非空行都将作为单独的消息记录，便于批量日志记录和区分。

6. 国际化（i18n）支持

• 采纳 gettext 工具：POSIX 2024 正式采纳了 GNU 风格的 gettext 系统接口（如 gettext(3p)）和命令行工具（如 gettext(1p), ngettext(1p), xgettext(1p), msgfmt(1p)）。
• 应用：这使得在 shell 脚本中实现本地化翻译变得标准化。翻译基于消息ID（msgid）和消息字符串（msgstr），存储在 .po 文件中，编译为 .mo 文件后由系统根据区域设置自动加载。

7. 其他重要变更

• 工具标准化：readlink 和 realpath 工具现已成为标准的一部分。
• rm 增强：新增 -d 选项用于删除空目录，并支持 -v 显示详细信息。
• printf 升级：支持带编号的格式说明符（例如 printf '%2$s%1$s' a b 输出 ba）。
• sed 增强：支持使用 -E 来使用扩展正则表达式（ERE），s 命令支持 i（忽略大小写）标志。
• test 增强：支持 -ef、-nt、-ot 文件比较操作符，字符串比较（>、<）现在受区域设置排序规则影响。
• set 选项：支持 -o pipefail、-e 和 -u 选项，减少了依赖 bash 等非标准 shell 的理由。
• 固有工具（Intrinsic Utilities）：引入了新的一类工具，介于特殊内置命令和常规内置命令之间，主要面向 shell 解释器开发者。

总结：POSIX 2024 通过增强工具功能、统一行为、采纳现代实践（如 C17、gettext）和解决长期痛点（如文件名处理、Makefile 兼容性），显著提升了标准的实用性、安全性和现代性，为开发更健壮、可移植的脚本和应用程序奠定了基础。

为什么Matt Levine这样的人物如此稀少？

Matt Levine是金融行业最知名的新闻通讯作者（代表作《Money Stuff》），其影响力巨大：读者涵盖从普通民众到亿万富翁，甚至包括高盛CEO。他的通讯在彭博社发布，但许多读者仅因他而访问该平台。他以独特风格解读复杂金融议题，创造了如“内幕交易法则”等流行术语。

Levine的独特性

Levine的写作风格融合了严肃议题与幽默感，并辅以对复杂金融机制的基础解释。长期写作使他能频繁回溯过往报道，形成主题循环（如“债券市场流动性担忧”），读者通过预测案例结局来学习，如同解谜。

他的成功依赖三个关键要素，而这些要素在其他领域极难同时满足：

1. 拥有已知结果的案例：金融与法律领域（如诉讼、交易、犯罪）通常能在数年内明确结果，证据清晰（如公司文件、短信记录）。这类似于棋类游戏，易于分析总结。相比之下，军事战略、电影导演或CEO决策等领域案例稀少、结果模糊、难以验证。
2. 基于第一性原理的解释：Levine持续用基本经济学原理（如供需、市场效率、激励机制）剖析案例，纠正大众的直觉误解（如“建房不能降价”“企业随意涨价”）。这逐步构建了读者可迁移的真实知识。
3. 由高更新频率实现的间隔重复：通讯定期发布，主题反复出现但细节变化，利用间隔效应巩固学习。而一次性深度报道（如报纸专题）即使质量高，也易被遗忘。

为何其他领域难以出现“Matt Levine”？

大多数领域缺乏上述一个或多个要素：

• 刑事报道：案例虽多且快速解决，但缺乏可归纳的普适原理，更多是猎奇娱乐。
• 物流/能源领域（如 fracking、集装箱）：案例可能蕴含普遍原理，但往往保密，且受行业周期影响，案例“成熟”（如公司破产）可能需数十年。
• 药物开发等领域：可能三要素皆缺——失败原因常未知、过程不透明、耗时数十载、且结果高度特异，难以提炼通用规则。
• 进化生物学或古典哲学等领域：辩论可能数世纪无定论，且缺乏大量快速、清晰、可用于教学的案例。

“Levine本人”同样稀缺

即使领域满足条件，合适作者也极少，因为：

1. 作者需耐受重复：同一主题需反复讲解，这对作者的耐心和抗无聊能力要求极高。优秀专家未必是好教师。
2. 专业能力与写作动机的矛盾：真正精通某领域的人，往往更倾向于亲身实践而非解说，且实践所得远超解说收入。
3. 多重筛选：需同时满足：领域条件严格、作者具备实战经验、解释能力强、能长期忍受重复写作、对该领域怀有热情（但又不至于强烈到放弃写作去直接从业）。每一层都筛掉大量候选人。

结论

因此，“Matt Levine”的出现是领域特性与个人特质高度巧合的产物。试图通过奖励或平台机制催生其他领域的“Levine”是徒劳的，因为根本条件（领域特性与合适作者）通常无法人为创造。

内部员工窃取Instagram用户名？

本文最初于2024年10月28日以推文串形式发布，后于10月30日发布后续更新说明账户已恢复。以下为编辑后的完整故事：作者14年的Instagram账户@javier被盗，并怀疑系内部员工所为。

背景

• 作者自2010年10月（Instagram上线当月）注册@javier用户名，是早期用户之一，曾与Instagram首位员工通过邮件沟通。
• 多年来持续收到大量收购该账户的请求，多数来自无内容的空账号。
• 作者始终拒绝出售，仅忽略或限制相关用户。

被盗过程

• 2024年10月23日晚，作者发现账户被强制登出，密码失效。
• 账户关联邮箱被更改为陌生地址（r*******e@gmail.com），且未收到任何安全通知。
• 尝试通过Instagram官方渠道找回失败，账户内容被清除并替换为4条新帖子。
• 黑客将原内容转移至新账户@javier.typeshi，并使用已故记者Javier Arce的头像。

调查与怀疑

• 作者账户具备双重认证、独立私密邮箱及密码管理工具，未泄露凭据或验证码。
• 事件发生时无异常登录通知，排除了常规钓鱼攻击可能性。
• 作者认为系公司内部人员操作，依据包括：
  • Meta此前有员工因黑客行为被开除的先例。
  • oguser.com等论坛存在活跃的用户名黑市交易。
• 新账户所有者Javier "Jay" Sang（Rebel Music唱片公司CEO）曾于2024年4月向作者提出购买请求。

恢复与现状

• 作者通过个人网络联系Instagram内部员工，在协助下恢复了账户内容及消息访问权限，但原始用户名@javier尚未找回。
• 恢复内容相对容易，但用户名回收流程复杂，暴露了平台账户恢复机制的缺陷。
• 另一用户@joao也遭遇类似情况且未获解决，表明此非孤立事件。

最终结局

• 作者最终恢复了Instagram账户访问权限，并感谢协助的各方。
• 事件促使作者强调内容自主权的重要性，建议用户采用“在自有站点发布，同步至其他平台”（POSSE）策略，通过个人博客和联邦宇宙（Fediverse）控制内容分发。
• 作者将继续使用Instagram，但同时加强个人博客和去中心化平台的发布。

Slight创业失败复盘总结

产品定位

Slight是一个数据“交换板”平台，旨在将SQL查询转化为用户友好的界面。它通过参数化查询，为不同用户（技术/非技术、内部/外部）生成同步的交互方式（如电子表格集成、Web界面、SDK、API等），解决企业内数据分发的摩擦问题。

核心失败原因

1. 市场需求不足：尽管产品理念有价值，但未能形成足够的市场牵引力。

   • 大公司：因缺乏企业级功能（SSO、合规认证、旧数据库支持）而犹豫。
   • 初创公司：认为其解决的痛点（如SQL代码分享、CSV传递）并非紧迫问题。
   • 目标客户狭窄：理想客户可能仅为快速成长的B轮公司，群体过小。

2. 分发策略严重失误（作者自认最大责任）：

   • 产品类似BI工具，却采用BI分发套路，但未提供完整的替代方案。
   • 缺乏清晰的“楔入点”：未明确首个使用场景、由哪个团队主导、以及自然扩展路径。
   • 未能回答“公司如何从开始到生产环境采用Slight”的关键问题，导致客户不知如何采纳。

3. 资金与市场环境：

   • 融资时（2023年初）市场环境糟糕，资金追逐AI，SaaS支出被削减。
   • 作者强调市场困境是背景，根本原因仍是客户不足。

其他潜在因素

• 开源可能性：曾考虑开源以促进采纳，但因精力限制未能实施。作者认为类似产品未来可能以开源形式出现。
• 团队与执行：
  • 团队优秀但缺乏早期创业经验，在“快速迭代”与“功能完善”间需适应。
  • 可能过度工程化（如过早构建多租户基础设施）。
  • 创始人技能重叠，导致过早需招聘前后端工程师。
• 竞争：未过度关注竞品，但客户常要求对比，这是产品定位模糊的体现。

核心教训

• 分发与采纳至关重要：必须明确产品的端到端采纳路径，清楚向客户展示价值。
• 避免“无人地带”：目标市场过于狭窄，难以系统性触达。
• 验证需求：应通过实验（如简化用例、寻找不同切入点、专注垂直领域）来迭代分发策略，而非单纯增加销售努力。
• 创业本质：失败主因是“做没人要的东西”和“花费过多”。创始人需对公司的成功负责，并把握学习与迭代的速度。

总结：Slight拥有强大的团队和技术，但未能构建足够的市场需求，并在产品分发策略上存在重大缺陷。其失败凸显了即使在执行良好的情况下，市场契合与采纳路径的清晰度对B2B创业公司也至关重要。

《无敌号》游戏概述

《无敌号》是一款基于斯坦尼斯拉夫·莱姆经典科幻小说改编的独立游戏。游戏旨在探索人类理解的极限，讲述人类执意闯入不属于我们的领域的故事。

核心内容

• 故事背景：玩家将扮演科学家Yasna，在雷吉斯III星球醒来且失去记忆，需要揭开这颗未知星球的秘密。
• 探索体验：游戏将引导玩家穿越雷吉斯III星球令人惊叹的景观，这是一个表面荒芜但隐藏着深层危险的星球。
• 艺术风格：游戏采用独特的复古未来主义与原子朋克美学设计，并配以作曲家Brunon Lubas创作的沉浸式配乐。

开发信息

• 开发商与发行商：由11 bit studios S.A.开发和发行。
• 技术合作伙伴：与AMD合作，游戏页面标注了相关版权信息。

其他元素

• 游戏官网包含多张宣传图片，展示其艺术风格和场景。
• 页面底部列出了法律条款链接，包括隐私政策和用户协议。

WASM Audio Decoders：高度优化的Web Assembly音频解码器

项目概述

WASM Audio Decoders是一组专为浏览器使用而高度优化的Web Assembly音频解码器库。每个模块均支持在主线程上的同步解码，以及通过内置Web Worker实现的异步（多线程）解码。Web Assembly作为一种基于栈式虚拟机的二进制指令格式，允许在浏览器中实现接近原生代码的执行速度。在实践中，这些解码器的性能与浏览器原生实现相当，甚至在某些情况下更快。

解码器列表及特性

所有解码器均采用内联WASM构建，以简化与Webpack等转译器的打包流程。内联的WASM使用yEnc进行高效二进制编码，并通过gzip压缩以减小文件体积。预构建的压缩JavaScript文件可通过NPM获取，或在各解码器的dist文件夹中找到。

1. mpg123-decoder

   • 功能：将MPEG Layer I/II/III解码为PCM。
   • 大小：77.0 KiB（压缩后）。
   • 支持环境：浏览器和NodeJS。
   • 特性：内置Web Worker支持。
   • 基础：基于mpg123。

2. @wasm-audio-decoders/flac

   • 功能：将FLAC和Ogg FLAC数据解码为PCM。
   • 大小：67.2 KiB（压缩后）。
   • 支持环境：浏览器和NodeJS。
   • 特性：内置Web Worker支持，多通道解码（最多8通道），支持完整的FLAC比特深度和采样率。
   • 基础：基于libFLAC和codec-parser。

3. ogg-opus-decoder

   • 功能：将Ogg Opus数据解码为PCM。
   • 大小：114.3 KiB（压缩后）。注意：启用机器学习增强功能时，大小将增至4.0 MiB。
   • 支持环境：浏览器和NodeJS。
   • 特性：内置Web Worker支持，多通道解码（最多255通道），使用Opus 1.5最新的机器学习增强功能以实现高质量语音解码。
   • 基础：基于libopus和codec-parser。

4. opus-decoder

   • 功能：将原始Opus音频帧解码为PCM。
   • 大小：85.5 KiB（压缩后）。
   • 支持环境：浏览器和NodeJS。
   • 特性：内置Web Worker支持，多通道解码（最多255通道）。
   • 用途：适用于已从容器（如Ogg、Matroska (WEBM) 或 ISOBMFF (mp4)）中提取出Opus帧的用户。
   • 基础：基于libopus。

5. @wasm-audio-decoders/opus-ml

   • 功能：将原始Opus音频帧解码为PCM（带机器学习增强）。
   • 大小：3.9 MiB（压缩后）。
   • 支持环境：浏览器和NodeJS（需要WASM SIMD支持）。
   • 特性：内置Web Worker支持，多通道解码（最多255通道），使用Opus 1.5最新的机器学习增强功能以实现高质量语音解码。
   • 用途：适用于已从容器中提取出Opus帧的用户。
   • 基础：基于libopus。

6. @wasm-audio-decoders/ogg-vorbis

   • 功能：将Ogg Vorbis数据解码为PCM。
   • 大小：99.3 KiB（压缩后）。
   • 支持环境：浏览器和NodeJS。
   • 特性：内置Web Worker支持，多通道解码（最多255通道），支持完整的Vorbis采样率。
   • 基础：基于libvorbis和codec-parser。

开发指南

前提条件

• Linux或类似Linux的环境（例如WSL）。
• NodeJS 18.x或更高版本。
• Emscripten 4.0.7。

初始设置

1. 克隆仓库：git clone https://github.com/eshaz/wasm-audio-decoders.git
2. 进入目录并初始化子模块：cd wasm-audio-decoders 然后 git submodule update --init。

安装依赖

运行 npm install 安装构建依赖。 运行 npm run install-decoders 为每个解码器安装依赖。

构建

1. 在终端中设置Emscripten路径（例如：source path_to_your_emscripten_installation/emsdk_env.sh）。
2. 运行 npm run configure 配置库（仅在首次构建或更新Makefile后需要）。
3. 运行 npm run build 构建库。构建产物将位于各库的dist文件夹中。

测试与贡献

• 运行 npm run test 执行测试套件。
• 项目欢迎所有贡献，建议通过Issues提问或评论，通过Pull Requests提交更改。

许可与归属

• 本项目源代码采用MIT许可证。
• 项目中包含的外部源代码（如作为git子模块包含并编译到dist文件中的解码库）可能具有不同的许可条款。
• OggOpusDecoder最初基于AnthumChris/opus-stream-decoder，并为Web应用进行了优化。
• 项目包含来自madler/zlib的puff WASM构建，用于解压WASM二进制文件。

本文介绍了在KDE Plasma Wayland会话中改善Xwayland窗口调整大小时出现视觉故障的技术细节与解决方案。

问题背景

在X11环境下，窗口调整大小通常会立即执行，但应用程序重绘新尺寸内容需要时间。若此时合成器合成屏幕，会导致视觉故障（如内容裁剪或出现未重绘区域）。X11通过帧同步协议（基于_NET_WM_SYNC_REQUEST和XSync计数器）解决此问题，确保窗口管理器、合成器和客户端按序协调更新。

Wayland环境下的挑战

在Wayland会话中，合成器（如KWin）不直接通过X11复合扩展获取窗口内容，而是依赖Xwayland将图形缓冲区附加到wl_surface。这导致了一个时序问题：合成器可能在收到XSync请求确认（表示客户端已完成重绘）后、但Xwayland尚未提交新尺寸缓冲区时更新窗口位置。例如，拖动窗口左边缘后，窗口位置已更新，但表面仍为旧尺寸，导致右侧边缘突出装饰区域。

解决方案：增强的帧同步流程

KWin引入了改进的同步机制，确保窗口位置更新发生在XSync确认和Xwayland提交新缓冲区之后：

1. 阻止表面提交：合成器通过设置_XWAYLAND_ALLOW_COMMITS属性为0，阻止Xwayland提交wl_surface。
2. 发送同步请求：合成器向客户端发送_NET_WM_SYNC_REQUEST消息。
3. 调整窗口大小：合成器调用xcb_configure_window()调整客户端窗口。
4. 客户端处理：客户端重绘窗口并确认XSync请求。
5. 解除提交阻止：收到确认后，合成器将_XWAYLAND_ALLOW_COMMITS设为1，允许Xwayland提交。
6. 最终更新：待Xwayland提交包含新尺寸缓冲区的wl_surface后，合成器才更新窗口位置，确保视觉一致性。

应用程序支持与现状

多数基于GTK和Qt的应用程序支持_NET_WM_SYNC_REQUEST协议，因此能正确参与帧同步。不支持的应用程序在调整大小时仍可能出现视觉故障。

总结

通过此改进，KWayland（KWin的Wayland版本）成为少数能正确处理X11窗口在Wayland环境下帧同步的合成器之一。该方案虽增加了流程复杂性，但有效解决了视觉故障问题，提升了用户体验。

Ding Dong Doorbell 应用摘要

Ding Dong Doorbell 是一款移动应用，允许用户利用 QR 码作为虚拟门铃系统。该应用适用于 iOS 和 Android 平台，旨在通过简单步骤实现远程门铃通知功能。

主要功能和步骤：

• 下载应用：用户需从相应平台下载 Ding Dong Doorbell 应用。
• 创建和放置 QR 码：应用内生成一个专用 QR 码，用户将其打印或放置在门口。
• 访客扫描：访客使用智能手机摄像头扫描门口的 QR 码。
• 接收通知：无论用户身在何处，应用都会在手机上推送通知，提醒有访客到来。

关键特点：

• 远程通知能力，确保用户及时知晓访客。
• 简化门铃设置，无需传统硬件设备。
• 跨平台支持，覆盖主流移动操作系统。

万圣节的深层历史溯源

本文探讨了万圣节及其全球同类节日（如亡灵节、伊朗的乔哈尔珊比·苏里节）之间的深层文化关联，试图追溯其可能的共同古老起源。

现代节日的共性

• 跨文化的节日模式：世界上多个文化区域都庆祝一种节日，其特征包括：食用甜点、生者与死者界限模糊、点燃烛火或篝火、以及佩戴装扮。
• 历史关联的疑问：这些节日在日期和具体形式上不同，但共享上述核心元素，引发了它们是否在遥远过去拥有共同起源的思考。

节日的历史记载与起源

• 万圣节的直接起源：源于古代凯尔特人的萨温节（11月1日），该节日以篝火、宴饮以及相信精灵在这一夜游荡于世为特征。至9世纪，萨温节元素被基督教化，融入了诸圣节（11月1日），其前夜则演变为“诸圣节前夕”，即万圣节的雏形。
• 亡灵节的起源：在16世纪的墨西哥，阿兹特克人对亡灵女神的崇拜与基督教诸圣节融合，形成了亡灵节。
• 文献记载的局限：关于萨温节最早的可靠文字记载来自10世纪的爱尔兰史诗，描述简略，细节不多。

考古证据与更古老的联系

• 新石器时代的天文对齐：考古发现，爱尔兰新石器时代的数座通道墓葬（如人质之丘）的入口设计，恰好在萨温节当天被阳光照亮。这表明萨温节的时间选择可能根植于数千年前的天文观测。
• 仪式细节的线索：有研究理论提出，在萨温节期间，苏格兰曾存在将人绑在立石上进行献祭的仪式。其中两个关键细节——使用致幻饮料和神圣武器——与已知的前印欧宗教实践惊人地相似，暗示了极其古老的渊源。

前印欧信仰的宇宙观

• 宇宙观的演变：学者沙朗·佩斯·麦克劳德论证，存在一种前印欧宇宙观，认为神灵居住在光明的天空，人类居于下方。而在凯尔特文化中，这种观念可能发生了逆转，神灵的领域被转移至地下或水域。
• 信仰转变的可能原因：这一转变可能始于青铜时代晚期，与气候变化有关，并伴随着将祭品投入水域（如湿地和沼泽）的实践。著名的“沼泽尸体”可能便是这种仪式的体现。
• 节日元素的深层寓意：万圣节的象征物——南瓜灯的英文名“jack-o'-lantern”一词，据说源于沼泽上空的诡异磷火。这可能与上述将幽冥世界与水域联系起来的古老观念存在关联。

结论

文章认为，万圣节及全球类似节日，可能共同承载着一套极其古老的信仰与仪式体系。这一体系围绕一个特定夜晚展开，人们相信此时人类世界与神灵、死者、精灵世界之间的帷幕会暂时揭开。尽管缺乏确凿的历史文献连接，但跨文化的相似性、考古证据以及比较神话学的研究，都为这一“万圣节可能拥有一万年历史”的推测提供了有趣的线索。

《华盛顿邮报》因阻止哈里斯背书遭大量退订与辞职潮

核心事件

• 所有者干预：在距选举日不到两周时，所有者杰夫·贝索斯阻止《华盛顿邮报》为副总统卡玛拉·哈里斯（Kamala Harris）提供总统候选人背书。
• 退订规模：截至周一中午，已有超过20万数字订阅用户取消订阅，约占该报250万总订阅量的8%，且数字仍在增长。
• 内部反应：多名专栏作家和编委会成员辞职以示抗议，包括近期普利策社论写作奖得主戴维·霍夫曼。

关键争议与各方表态

• 贝索斯的解释：称此举是为了回归《华盛顿邮报》作为“独立报纸”的传统，避免“偏见的感知”。
• 内部质疑：前执行编辑马蒂·巴伦等人指出，决定时机（临近大选）与“回归传统”的说法不符，缺乏与编委会的实质讨论。
• 贝索斯回应：周一晚发文承认“时机不理想”，称属“规划不周”而非“有意策略”；否认与特朗普有任何利益交换，但承认自己作为其他公司（如与政府有数十亿合同的蓝色起源）的所有者“并非《华盛顿邮报》的理想所有者”。

深层背景与影响

• 政治敏感性：该报多年来多次报道特朗普及其关联方的不当行为，社论曾将特朗普称为对美国民主实验的威胁。
• 商业关联疑云：蓝色起源高管在决定公布数小时后与特朗普会面，贝索斯称对此不知情，但承认这为批评者提供了“弹药”。
• 行业冲击：如此大规模的退订在行业内罕见，被视为反映当前政治极化环境下读者强烈情绪的标志。

Marmite 是一个极简的、零配置的静态网站生成器，旨在快速将 Markdown 文件目录转换为静态网站。其核心设计理念是简单易用，仅需一个命令即可完成建站，避免了其他生成器繁琐的初始设置。

核心工作流程：

1. 读取输入目录中的所有 .md 文件。
2. 使用 CommonMark 解析为 HTML 内容，并从前置元数据或文件名中提取可选元数据。
3. 为每个页面生成对应的 HTML 文件。
4. 将渲染好的静态网站（包括 static/ 和 media/ 目录）输出到指定文件夹。

主要特点与功能：

• 极简与零配置：提供单一下载即用的二进制文件，开箱即用，无需复杂配置。
• Markdown 支持全面：支持 CommonMark、GitHub Flavored Markdown 及扩展，允许使用原始 HTML、表情符号、维基链接、Obsidian 链接等。
• 内容组织与元数据：通过 tags 分组类似内容，通过 stream 分流内容至不同列表；使用 date 属性区分“文章”和“页面”。
• 功能丰富：支持多作者、作者主页、分页、静态搜索索引、多种 RSS 订阅源、内置带实时重载的 HTTP 服务器、自动重建以及亮/暗模式切换的内置主题。
• 高度可定制：支持自定义配置、模板、CSS/JS，易于替换首页和集成评论系统。
• 开发友好：支持数学公式、Mermaid 图表、构建时语法高亮以及 CLI 命令快速初始化主题。

安装与使用：

• 安装：可通过 cargo install、下载预编译二进制文件（支持多平台）、Homebrew、Arch Linux AUR、FreeBSD 包管理器或 Docker 镜像进行安装。
• 基本用法：运行命令 marmite <输入文件夹> <输出文件夹> 即可生成站点。
• 开发模式：使用 --serve --watch 参数启动带实时重建和 WebSocket 热重载的本地服务器。
• CLI 工具：提供详细的命令行选项，用于服务、监视、绑定地址、指定配置、初始化模板和生成配置文件等。

Marmite 面向以按时间顺序发布文章为主要用途的博客场景，生成的网站为扁平 HTML 结构。如果其简单性无法满足复杂需求，项目也推荐了 Cobalt、Zola 等其他静态网站生成器。

项目概述

此仓库由GitHub维护，用于公开发布其收到的《数字千年版权法案》（DMCA）移除通知和反通知。该项目受到Lumen（前身为Chilling Effects）和Google的启发，旨在通过提高透明度来记录可能抑制言论的法律通知。

核心目的

• 透明度：GitHub认为，持续、具体的透明度对良好的治理至关重要。公开这些通知有助于记录其潜在的“寒蝉效应”，即法律通知可能不合理地压制互联网用户的言论。
• 信息中立：发布的通知仅表明GitHub在特定日期收到了该通知，不代表被指控的内容违法、错误或用户行为不当。GitHub不对通知中索赔的有效性作任何判断。

通知的注解说明

为便于理解，GitHub在发布的通知原文中会添加少量注解（仅编辑隐私信息及不可操作的URL）：

1. 给予修改机会：自2021年3月起，对于未指控整个仓库侵权的通知，GitHub会联系仓库所有者，给予其约一个工作日的时间自行删除或修改涉嫌侵权的内容，以避免整个仓库被禁用。
2. 部分URL处理：若通知中指控的多个文件或仓库仅部分构成侵权，其他URL会被替换为[invalid]（或2021年3月前使用的[private]）。[private]也用于标记隐私信息的删节。
3. 活跃的fork网络：自2021年3月起，若通知指控一个正在被积极fork的仓库侵权，且提交者指明了所有已知的fork，GitHub可能会处理整个fork网络。
4. 大型fork网络：若被指控的仓库fork数量超过100个，且提交者通过审查代表性样本后，宣誓相信全部或大部分fork均构成相同程度的侵权，则GitHub可能会禁用整个网络。

用户参与指南

• 不接受直接贡献：请勿向此仓库提交Pull Request或其他贡献。
• 提交DMCA通知：版权所有者应通过GitHub的专用联系表单提交正式通知。
• 回应DMCA通知：仓库所有者如被移除内容，有两个主要选择：
  1. 联系GitHub，表示愿意修改内容以移除涉嫌侵权部分。
  2. 如果认为通知有误，可提交正式的反通知。GitHub将在等待10-14天后，若版权所有者未提起法律诉讼，则恢复内容。
• 政策倡导：对于版权法的普遍关注，鼓励用户向版权局或当地立法者表达意见，并可联系GitHub分享关切。