2024-09-22

25 篇热帖

1. They stole my voice with AI (www.jeffgeerling.com)

文章作者发现AI技术克隆了其声音,用于制作未经同意的产品宣传视频。核心内容如下:

  • 事件概述:作者在Elecrow公司的视频中听到与自己高度相似的声音,但从未录制相关旁白。推测该公司可能利用AI工具提取其YouTube视频中的声音并进行克隆,用于ESP32、RP2040等产品教程系列。
  • 背景与关系:作者与Elecrow曾有过合作(如评测CrowPi 2),双方保持邮件联系,该公司甚至曾提出付费合作意向。
  • 作者立场:认为未经授权克隆并使用其声音进行商业推广是不道德的;引用“Midler vs. Ford”案例说明未经同意使用他人声音的法律风险,但指出AI语音克隆目前缺乏明确法律先例。
  • 应对措施:作者已邮件要求Elecrow下架相关视频,并询问声音克隆是否属有意行为。他更倾向通过沟通解决,而非立即采取法律行动或YouTube投诉。
  • 呼吁与观点:强调企业不应盗用他人声音或形象进行产品推广,而应通过雇佣配音演员或与创作者合作获得授权。
2. Hy 1.0 – Lisp dialect for Python (github.com)

Hy 1.0 发布及其技术实践总结

Hy 1.0 发布的意义 开发者对 Hy 1.0(Python 的 Lisp 方言)的正式发布表示高度认可,认为其稳定的内部机制和 API 是构建高级库和框架的必要基础。此次发布引发了社区的广泛关注,官方网站在发布当天的独立访客数量显著增长。

宏(Macros)的应用与优势 开发者正利用 Hy 开发 ORM 和异步 Web 框架,核心优势在于通过 Lisp 宏提供更简洁的接口并消除样板代码:

  • 简化 ORM 定义:以 SQLAlchemy 为例,原生 Python 代码较为繁琐,而通过自定义的 defmodel 宏,可以用极简的语法定义数据库模型(支持一对一、一对多、多对多关系及时间戳字段等)。
  • 零运行时开销:宏仅在编译时将代码展开为原生的 SQLAlchemy 代码,不产生额外的运行时成本。
  • 无缝集成:宏生成的模型即为标准的 SQLAlchemy 2.0 ORM 对象。开发者可以将 Hy 作为数据库 Schema 的领域特定语言(DSL),而其余业务逻辑继续使用 Python 编写。

查询 DSL 的设计挑战 在开发查询 DSL 时,开发者发现 S-表达式与流式接口(Fluent Interface)的契合度较差。社区建议参考 Google 关于 SQL 管道语法的论文,使语法顺序与语义顺序保持一致。开发者计划引入类似 OCaml 的 |> 管道操作符或模仿列表推导式,并通过实际项目的迭代来完善最终设计。

MicroPython 兼容性 针对在 MicroPython 上运行 Hy 的可行性,社区指出由于 MicroPython 仅包含 Python 标准库的一个子集,直接运行存在限制。可行的替代方案是:在 CPython 环境下使用 hy2py 工具将 Hy 代码编译为纯 Python 代码,随后在 MicroPython 中运行(前提是代码结构需限制在 MicroPython 支持的范围内)。

3. Sanding UI (blog.jim-nielsen.com)

UI打磨:像木工一样细致地开发界面

文章提出了一种UI开发方法:通过反复点击和测试来发现并修复问题,如同木工用砂纸打磨木料般逐步完善。作者强调这种“点击测试”能暴露交互细节中的缺陷。

核心比喻

  • 开发过程:构建界面后大量点击测试,进行调整,再次测试,循环往复直至满意。
  • 类比木工:粗砂纸处理大瑕疵 → 细砂纸反复打磨并用手感受毛刺 → 直至平滑无误。
  • 关键目的:在变量复杂的软件中,通过反复交互来消除所有“毛刺”(即交互缺陷)。

实际案例:单选按钮的点击死区

作者在开发一个带标签的单选按钮时,使用flexbox布局轻松实现水平居中对齐:

<div class="container">
  <label for="control">Foo</label>
  <input id="control" type="radio">
</div>
<style>
.container {
  display: flex;
  align-items: center;
  gap: 0.5rem;
}
</style>

发现问题

在反复点击测试中,发现单选按钮与标签之间的间隙(gap)存在点击无效的“死区”——尽管已正确关联<label><input>for属性。

原因与解决

  • 根源:flexbox的gap属性创造了视觉间距,但该区域未被交互覆盖。
  • 解决方案:移除容器的gap,改为在<label>上添加内边距(padding):
    .label { padding: 0 0.5rem; }
    
    这使整个标签(包括与单选按钮的虚拟间距)均可点击,消除死区。

核心观点

  • 小细节累积会显著影响用户体验。
  • 推荐开发流程:打磨界面 → 交互测试 → 发现毛刺 → 修复 → 重复,直到交互完全平滑。
  • CSS的灵活性(如用padding替代gap)是解决此类问题的强大工具。
4. What happened to the Japanese PC platforms? (www.mistys-internet.website)

日本PC平台的衰落与转型

本文探讨了20世纪80至90年代日本独有的16位PC平台(NEC PC-98、Fujitsu FM Towns、Sharp X68000)逐渐消失并融入主流市场的原因及最终结局。

核心原因分析

1. Windows的普及与硬件抽象层

  • PC-98与FM Towns:在DOS时代,软件与特定硬件强绑定。由于这两款平台采用了与IBM PC相同的CPU架构,微软得以将Windows移植到其上。Windows引入的硬件抽象层使软件不再依赖底层硬件。随着Windows 95的普及,跨平台兼容性抹平了这些日本PC的独特性,厂商最终转向生产标准IBM兼容机。
  • X68000的落败:该平台采用Motorola 68000 CPU和自研操作系统。由于CPU架构不同,无法移植Windows以运行常规软件,导致夏普无法为老用户提供平滑的过渡路径,最终在竞争中出局。

2. 多任务处理推动市场整合

Windows胜出的关键特性是多任务处理。多任务环境要求更广泛的软件兼容性,这促使市场向拥有庞大软件生态的Windows平台集中。为了获得多任务能力,用户和开发者自然向Windows靠拢,其他封闭平台难以与之竞争。

3. 游戏市场的代际更替

在16位时代,FM Towns和X68000凭借强大的2D性能和街机移植游戏占据硬核玩家市场。但1994年后,32位主机(如PlayStation)不仅2D性能持平,3D性能更呈碾压态势。加之索尼针对成年PC玩家的精准营销,导致PC游戏小众市场萎缩,玩家大量流向家用主机。

4. 8位平台的提前衰退

与欧洲不同,日本的8位计算机(如MSX)在Windows时代到来前,就已被本土16位平台取代。由于未能成功演进至16位,其用户在Windows 95发布前就已流失。

最终结局

这些日本16位PC制造商并未像欧美的Commodore或Atari那样倒闭。它们成功转型为标准Windows PC制造商,虽然失去了独有的平台生态,但企业本身在微软接管全球PC市场的浪潮中得以幸存。

5. 'I Don't Want to Die.' He needed mental health care. He found a ghost network (www.npr.org)

文章摘要

本文讲述了36岁的前大学高尔夫球手拉维·库蒂尼奥因抑郁症、焦虑症和酗酒问题,在寻求心理健康护理时陷入保险公司“幽灵网络”困境,并最终不幸去世的悲剧故事。

核心问题:保险公司的“幽灵网络”

拉维患有抑郁症、焦虑症和严重的酗酒问题。为寻求治疗,他从德克萨斯州搬到亚利桑那州凤凰城,希望通过新的环境改变生活。他购买了市场上流行的Ambetter保险(由医疗巨头Centene公司运营),其保单显示拥有广泛的医疗服务提供者网络。

然而,拉维发现这是一个**“幽灵网络”。尽管目录上列有众多治疗师,但他和母亲芭芭拉·韦伯**多次尝试后,都无法找到一位能接受他保险、并能够及时就诊的心理治疗师或精神科医生。提供者名录信息严重过时、不准确,客服提供的帮助也极其无效且荒谬(例如推荐老年精神科医生)。

拉维的挣扎与系统的失败

  • 多次求助无果:拉维反复致电客服、搜索网络门户,母亲也利用自己的医疗倡导经验介入,但均无法获得有效转介。客服电话中甚至需要等待7-10个工作日才能邮寄一份可能也过时的提供者名单。
  • 公司监管与诉讼记录:Centene及其子公司此前已多次因提供不准确目录而面临伊利诺伊州、圣地亚哥等地的监管罚款和诉讼。亚利桑那州监管机构也曾发现其旗下计划未能维护准确目录。
  • 病情恶化:在寻找治疗师的漫长过程中,拉维的孤独感和成瘾问题加剧,导致多次酗酒复发、出现幻觉、癫痫发作,并数次被送入急诊室。他曾在电话中对母亲说:“我不想死。
  • 关键治疗受阻:当医院推荐他参加密集门诊治疗项目时,母子二人同样无法从Ambetter获得可行的项目列表。最终通过关系找到的一个项目,又因他体内残留有医院为治疗癫痫而使用的苯二氮卓类药物而三次拒绝接收他

悲剧结局与反思

2023年5月底,在最后一次被治疗项目拒绝后,拉维未能回复母亲的信息。友人赶到其公寓后发现他已因过量饮酒的并发症去世。官方裁定其死亡为意外。

文章指出,拉维的遭遇揭示了美国心理健康护理系统中的一个系统性问题:保险公司公布的网络内提供者名录往往虚假,患者实际无法获得所需护理。这种**“诱饵式营销”**使数百万像拉维这样的患者陷入无助。尽管法规要求保险公司在网络内无法提供及时服务时,应为患者安排网络外治疗,但在实践中,患者和家庭常常需要付出巨大代价甚至生命,才能证明这一权利的存在。拉维的案例凸显了保险网络不实、客服无效以及监管执行不力所带来的毁灭性后果。

6. WP Engine is not WordPress (wordpress.org)

文章核心摘要

本文是一篇针对托管服务商 WP Engine 的强烈批评,核心论点是 “WP Engine 不是 WordPress”。作者认为其通过误导性的品牌营销,让用户误以为是官方或正宗服务,实则严重损害了WordPress的核心承诺与用户体验。

主要指控与事实

  1. 品牌误导与商标问题

    • WP Engine的营销让普通用户(如作者母亲)误以为其是官方产品。
    • 作者认为,WP Engine的业务依赖于这种混淆,需要获得商标许可。
  2. 对开源社区的“掠夺”

    • 作者将WP Engine背后的银湖资本比作“掏空开源社区”的私募股权。
    • 对比数据:WP Engine(年收入约5亿美元)每周仅贡献40小时;而Automattic规模相当,每周贡献3,915小时。
  3. 破坏WordPress核心功能——修订系统

    • 核心问题:WP Engine默认为其150万个WordPress安装禁用文章修订功能
    • WordPress的承诺:修订系统是内容管理的基石,确保每次修改都被记录、可追溯、可恢复,承诺永不丢失数据。
    • WP Engine的做法:为了节省服务器存储成本,单方面关闭此功能。其支持页面声称是为了提高网站速度,但作者反驳称其他所有推荐主机均未默认禁用此项功能。
    • 后果:用户犯错后无法恢复历史版本,违背了WordPress保护内容的核心承诺。作者将此行为比作“剥离开采”WordPress生态系统。
  4. 提供的是“廉价仿冒品”

    • 作者认为WP Engine提供的并非完整的WordPress,而是被其“阉割、肢解”后看起来像WordPress的廉价版本,却收费更高。

作者的结论与呼吁

  • 定性:WP Engine是WordPress的“癌症”,为行业树立了恶劣先例,若放任可能蔓延。
  • 对用户的建议
    1. 立即联系WP Engine支持,要求至少开启其提供的3个修订版本。
    2. 理想情况下,应要求无限修订。
    3. 认识到用户拥有选择权,WP Engine依赖用户资金。
    4. 在选择主机时,考虑任何其他WordPress主机,因为WP Engine是已知唯一默认完全禁用修订功能的服务商。
7. It is hard to recommend Google Cloud (ashishb.net)

难以推荐 Google Cloud 的原因分析

本文作者通过分享在使用 Google Cloud 期间遭遇的多次服务关停、被迫迁移及价格变动经历,指出尽管该产品在技术和体验上表现优异,但其糟糕的商业策略导致难以向他人推荐。

核心痛点与被迫迁移经历

  • Google Domains 关停:Google 关闭了域名服务,迫使作者将多个子项目的域名映射迁移至新注册商,并在 Google Cloud Run 上重新验证域名和重建映射,过程繁琐痛苦。
  • Google Container Registry (GCR) 停用:GCR 将于 2025 年关闭并由 Artifact Registry (GAR) 取代,作者推测原因是 GCR 价格远低于 GAR(便宜10倍)。作者耗费大量时间将运行多年的项目及单页主页从 GCR 迁移至 GAR,过程艰难。
  • Google Cloud Monitoring 涨价:原本免费的监控服务突然宣布大幅涨价,迫使作者重新评估其定价竞争力并寻找合适的替代方案。

整体评价

  • 产品与技术优势:作者坚信 Google Cloud 是一款优于 AWS 和 Microsoft Azure 的产品。其用户体验(UX)更简单,基础组件(primitives)比 AWS 更完善,且可靠性非常接近 AWS。
  • 战略劣势:尽管产品工程出色,但频繁的服务变动、繁重且缺乏实际收益的迁移工作(continuous churn)暴露了其糟糕的商业策略,这也是作者认为难以推荐 Google Cloud 的根本原因。
8. Applied Mathematical Programming (web.mit.edu)

《应用数学规划》书籍摘要

书籍信息
《应用数学规划》由Bradley、Hax和Magnanti编写,于1977年由Addison-Wesley出版社出版。该书是麻省理工学院(MIT)课程15.053(商业分析中的优化方法)的参考教材。

在线可用性
为便于在线访问,书籍的大部分章节已重新排版。但第6、7和10章未重新排版,仍以原始章节的扫描版本提供。整本书(除第6、7和10章外)和各章节均可下载PDF文件。

主要资源

  • 整本书下载:提供完整的PDF版本(不包括第6、7和10章)。
  • 各章节下载:从第1章到第14章及附录A、B、C均有独立PDF链接。
  • 扫描版章节:第6章(铝工业战略与战术规划的整合)、第7章(美国商船队的任务与组成规划)和第10章(海军维修作业车间设计)以扫描形式提供。

附加练习与电子表格
该书还提供了一些基于Excel的练习和其他电子表格,用于辅助学习。这些练习是在书籍出版后开发的,主要涉及敏感性分析、线性规划求解等内容。例如:

  • 练习3.1至3.28的Excel文件。
  • 特定章节的示例电子表格,如第1.3节的高炉和投资组合选择示例、第2.3节的简单线性规划示例等。

用途与背景
该书旨在为商业分析中的优化方法提供理论基础和实践指导,覆盖线性规划、敏感性分析、对偶性、网络模型、整数规划、动态规划等主题。通过提供可下载的章节和Excel练习,支持课程学习和自学。

9. Twenty Years of FM Synthesis Inside Ableton Live (roberthenke.com)

Ableton Live中FM合成技术的二十年历程

FM合成的历史背景

FM(频率调制)合成技术由作曲家John Chowning于1967年在斯坦福大学人工智能实验室偶然发现。他通过调制正弦波振荡器的频率发现,当调制速率超过听觉感知时,音高变化会转变为音色变化,从而诞生了数字FM合成。该技术后被雅马哈公司专利化并商业化,1983年推出的DX7合成器以其独特音色成为技术里程碑,深刻改变了合成器领域。

Operator的诞生与设计理念

2004年,Ableton决定为其数字音频工作站Live添加内置合成器。FM合成因其CPU效率高、音色潜力大而被选中。开发者Robert Henke以雅马哈DX27为灵感,启动了代号为"Onyx"的Operator项目。设计面临的主要挑战是当时有限的屏幕分辨率,因此创新性地采用了上下文敏感的LCD中央显示界面,仅显示当前选中振荡器或模块的核心参数,该设计后来成为Live的通用UI范式。

Operator的核心功能与技术细节

Operator是一款四振荡器FM合成器,具有以下关键特性:

  1. 振荡器设计:采用查表法生成波形,支持加法合成创建用户自定义波形。振荡器可调至零赫兹以下,变为波形整形器。
  2. 调制系统:无调制矩阵,但通过LFO、滤波器与音高包络等提供丰富的调制源与目标,并支持MPE。
  3. 包络系统:七个包络(包括"全局时间"控制)具备触发、循环和同步模式,极大增强了声音设计灵活性。
  4. 特色功能
    • 全局时间:一键缩放所有包络的时间参数。
    • 音色控制:实为调制输入前的低通滤波器,用于抑制混叠噪音。
    • 立体声扩展:创建左右声道硬声像摆位的双声部,并伴随所有随机参数独立化,产生宽广立体声效果。
    • 循环噪声:一种可调音高的循环噪声波形,通过轻微FM调制可转为真实噪声。
  5. 音质优化:提供高质量的插值与抗锯齿选项,但其状态可根据音色需求(如利用混叠产生特殊音效)灵活调整。

技术实现与团队贡献

Operator采用C++实现,界面设计由Torsten Slama完成,并汇集了整个早期Ableton团队的反馈。其内部本质上是相位调制,这比频率调制更节省CPU且能获得近似效果。

二十周年纪念

为庆祝Operator诞生二十周年,开发者与同事共同制作并发布了免费预设包Operator20.alp,涵盖了过去二十年间创作的精选音色。文章亦提供了开发者个人使用的Live主题下载链接。

10. Show HN: PDF to MD by LLMs – Extract Text/Tables/Image Descriptives by GPT4o (github.com)

PDF to Markdown by LLMs 工具摘要

该工具是一个基于大型视觉语言模型(如GPT-4o)的PDF转Markdown服务,能够利用模型的视觉理解能力提取PDF中的文本、表格及图像描述,并生成结构化的Markdown输出,而非传统的OCR。

核心功能

  • 视觉模型OCR:理解文档上下文,而不仅仅是字符形状。
  • 并行处理:支持快速处理,约50页PDF在几秒内完成。
  • 表格保留:检测表格并格式化为标准的Markdown表格。
  • 智能批处理:可配置每批次处理页数,以平衡速度与精度。
  • 重试与退避:内置机制处理API速率限制和超时错误。
  • 灵活输入:支持文件上传或通过URL处理PDF。
  • 图像描述:为非文本元素生成[Image: description]描述标注。

成本(以OpenAI为例,平均每页约1500 token)

模型 每1000页成本(美元)
GPT-4o ~15
GPT-4o mini ~8
批量API ~4

:支持任何兼容OpenAI的视觉API,可在配置中更换端点和模型。

安装与配置

  1. 克隆仓库并设置Python虚拟环境,安装依赖。
  2. 创建.env文件配置以下必要项:
    • OPENAI_API_KEY
    • AZURE_OPENAI_ENDPOINT
    • OPENAI_DEPLOYMENT_ID
    • 可选:OPENAI_API_VERSION, BATCH_SIZE, MAX_CONCURRENT_OCR_REQUESTS等。
  3. 运行服务:可通过uvicornpython -m swift_ocr等多种方式启动,API默认运行在http://127.0.0.1:8000

使用方式

  • 上传文件
    curl -X POST "http://127.0.0.1:8000/ocr" -F "file=@/path/to/document.pdf"
    
  • 通过URL处理
    curl -X POST "http://127.0.0.1:8000/ocr" -H "Content-Type: application/json" -d '{"url": "https://example.com/document.pdf"}'
    
  • 响应示例
    {
      "text": "# 文档标题\n\n## 章节1\n\n提取的文本...",
      "status": "success",
      "pages_processed": 5,
      "processing_time_ms": 1234
    }
    
  • 提供健康检查端点/health和详细的错误码说明(如200、400、429等)。

配置与调优

主要配置变量包括:

  • BATCH_SIZE:每请求处理页数(1-10)。值越大速度越快,但精度可能下降。
  • MAX_CONCURRENT_OCR_REQUESTS:并行OCR请求数。
  • MAX_CONCURRENT_PDF_CONVERSION:并行PDF渲染数,建议与CPU核心数匹配。

调优建议

  • 高精度BATCH_SIZE=1
  • 平衡模式BATCH_SIZE=5MAX_CONCURRENT_OCR_REQUESTS=10
  • 最大吞吐BATCH_SIZE=10MAX_CONCURRENT_OCR_REQUESTS=20(需注意API速率限制)。

项目结构

代码采用模块化组织,包括:

  • app.py:FastAPI应用工厂。
  • config/:类型安全的配置(使用Pydantic)。
  • core/:核心功能,如异常处理、日志、重试逻辑。
  • services/:OCR服务和PDF转换服务。
  • api/:API路由、依赖注入和异常处理器。

故障排除

常见问题及解决方法:

  • 环境变量缺失:检查.env文件是否完整配置。
  • 429速率限制:降低MAX_CONCURRENT_OCR_REQUESTSBATCH_SIZE
  • 超时错误:大文件处理需要时间,内置退避机制。
  • 输出乱码:确保PDF未加密或损坏。
  • 表格格式错误:对复杂表格尝试BATCH_SIZE=1

许可证

使用AGPL v3许可(因依赖PyMuPDF)。如需MIT许可,需替换PyMuPDF为pdf2imagePoppler

11. Nextcloud: Open-Source Cloud Apps (nextcloud.com)

Nextcloud 概述

Nextcloud 是一个开源、自托管的云文件存储和内容协作平台,旨在为用户提供对自身数据的完全掌控,并作为 Microsoft 365 等商业套件的私有云替代方案。其核心价值在于保障数据隐私、安全与合规性,同时支持高效的远程协作。

核心特点

  • 数据主权:所有数据存储在用户自己的服务器上,避免向第三方泄露。
  • 协作与生产力:支持跨平台的文件共享、在线办公、通讯和团队协作。
  • 安全与合规:设计符合 HIPAA、GDPR 等法规要求,提供加密、审计和策略管理功能。
  • 开源与可扩展:基于活跃的社区开发,可定制且能从单板电脑扩展到服务于数千万用户的大规模部署。

主要产品(Nextcloud Hub)

Nextcloud Hub 是一个集成平台,包含以下核心模块:

  1. Nextcloud Files:自托管的文件存储与同步平台,提供桌面、移动和网页端访问,支持协作。
  2. Nextcloud Talk:提供私有的音视频会议、群聊、屏幕共享和 SIP 集成。
  3. Nextcloud Groupware:集成日历、联系人、邮件等团队效率工具。
  4. Nextcloud Office:基于 LibreOffice 的在线办公套件,支持实时协作编辑主流文档格式(docx, pptx, xlsx)。
  5. Nextcloud Assistant:集成的本地 AI 助手,可用于生成内容、基于数据回答问题、总结邮件等。
  6. Nextcloud Flow:用于自动化业务流程和内部工作流的工具,基于直观的组件构建。

客户与可信度

Nextcloud 被全球数千家组织、数百万用户所采用,其客户包括众多知名机构和企业,例如:

  • 政府机构:德国联邦信息中心(ITZBund)、奥地利联邦劳动与经济部、塞尔维亚议会等。
  • 教育与研究:柏林工业大学、南丹麦大学、索邦大学等。
  • 企业与金融机构:德国电信、宝马、Raiffeisen Informatik、慕尼黑储蓄银行等。
  • 国际组织与非政府组织:国际特赦组织等。

为何选择 Nextcloud

  1. 提升生产力:支持在任何平台、任何地点进行数据访问、共享和协作,打破组织边界。
  2. 完全控制:数据与通信始终在用户自有的服务器上,确保合规性,防止数据(包括元数据)泄露。
  3. 活跃的社区:拥有持续发展的开源社区,提供不断更新和改进,同时可获取企业级支持。

Nextcloud 强调其通过强大的访问控制、基础设施集成和人性化设计,为个人和组织提供了一个安全、高效且主权可控的协作解决方案。

12. Rawdrawandroid – Build Android apps without any Java, in C and Make (github.com)

Rawdrawandroid 项目概览

核心目的

Rawdrawandroid 是一个开发框架,允许开发者使用纯 C语言Make 构建、安装和运行 Android 应用程序,完全无需 Java 或 Kotlin。其主要目标是:

  • 极简化开发:通过标准 Makefile 管理构建过程,使命令和规则清晰可见,便于定制。
  • 轻量化产物:生成的 APK 体积极小(API 26 约 25kB,API 30 约 45kB)。
  • 快速迭代:实现约 2 秒的快速构建、安装和自动运行。
  • 跨平台一致性:基于通用的 C 语言和 rawdraw 库,代码可移植到 ESP8266、树莓派、Windows、Linux 和 Android 等多种平台。

主要特性与功能

框架提供的演示应用包含以下功能:

  • 创建支持 OpenGL ES 的窗口。
  • 访问 加速度计/陀螺仪 传感器和多点触控输入。
  • 调用 Android 软键盘 进行按键输入。
  • 使用 AAssetManager 在 APK 中嵌入并读取资源文件
  • 权限管理支持(如麦克风权限)。
  • 直接访问 USB 设备

开发环境搭建

项目支持在 LinuxWindows (通过 WSL) 下进行开发。

  1. 基础依赖:安装 openjdk-17-jdk-headlessadb 等。
  2. 获取 Android SDK/NDK
    • Linux (GUI):安装完整的 Android Studio,并通过 SDK Manager 安装 NDK。
    • Windows/WSL (命令行):下载 Android 命令行工具,使用 sdkmanager 安装指定版本的 build-tools、NDK、platform-tools 等。
  3. 获取代码:克隆 rawdrawandroid 仓库及其子模块。
  4. 设备准备:在 Android 手机上启用 开发者选项USB 调试

项目使用指南

  • 基础使用:可参考示例项目 rawdrawandroidexample。关键步骤是修改 Makefile 中的 APPNAMEPACKAGENAME,并同步更新 AndroidManifest.xml 中的包名和标签。
  • 处理权限:对于需要动态请求的权限(如录音),需在 AndroidManifest.xml 中声明,并在 C 代码中使用提供的辅助函数(如 AndroidRequestAppPermissions)进行检查和请求。
  • 辅助函数:框架提供了关键函数,如处理权限请求、键盘显示、获取 Unicode 字符以及应用生命周期事件(HandleResume, HandleSuspend, HandleWindowTermination)。
  • 调试:提供了使用 lldb 进行远程调试的详细步骤。

发布到 Google Play

应用可以通过此框架发布到 Google Play 商店(例如 ColorChord 应用)。发布前需进行配置调整:

  • 修改清单文件:设置 android:versionCode,将 android:debuggable 设为 false
  • 多架构支持:在 Makefile 中为 arm64-v8a, armeabi-v7a 等架构配置构建目标。
  • 指定 SDK 版本:在 AndroidManifest.xml 中明确 minSdkVersiontargetSdkVersion
  • 应用签名:生成真实的 keystore 文件用于正式签名,并使用 zipalign 工具对齐 APK。
  • 密钥管理:可选择让 Google 管理应用签名密钥,或上传自己的密钥。

注意事项

  • 风险声明:作者对代码不提供任何担保,且从未将使用此工具的应用发布到商店,因此用于商业应用可能存在未知风险。
  • 版本选择:构建时需注意选择合适的 NDK 和平台工具版本,文档提供了不同 SDK 版本(如 29, 30, 32, 34)对应的安装命令。
  • OpenXR 支持:项目已更新,支持与 Meta Quest 的 OpenXR 集成。
13. Cloudflare Is Breaking My SVGs? (www.lloydatkinson.net)

文章描述了作者在使用 Cloudflare Pages 部署网站时,发现 SVG 图标被错误处理的问题。

问题现象

  • 在本地构建或使用 Netlify 部署时,SVG 图标显示正常。
  • 部署到 Cloudflare Pages 后,包含颜色、渐变或复杂形状的 SVG 图标出现异常(如颜色丢失、变为全黑)。
  • 经检查,原因是 Cloudflare Pages 的构建过程错误地将 SVG 属性中的连字符格式(如 clip-path)转换成了驼峰格式(如 clipPath),导致 SVG 代码无效。

排查过程

  1. 作者通过对比本地、Netlify 和 Cloudflare Pages 的构建输出差异,排除了站点生成器(Astro)、Node 版本及图标库本身的嫌疑。
  2. 作者创建了一个全新的 Cloudflare Pages 应用并部署同一仓库,问题依旧,排除了个人项目配置错误的可能性。
  3. 作者使用 Cloudflare 的命令行工具 Wrangler 直接部署到 Cloudflare Pages,SVG 图标显示正常。
  4. 以上测试确认问题源于 Cloudflare Pages 的构建流程,而非内容服务方式。

临时解决方案 由于未能找到根本原因或相关配置项,作者编写了一个后处理脚本作为临时解决方案:

  • 脚本在构建完成后运行,遍历生成的所有 HTML 文件。
  • 它使用 JSDOM 解析文件,查找被错误转换的 SVG 属性(定义了一个包含数十个可能属性的修复列表)。
  • 脚本将找到的错误属性名(如 clippath)更正回正确的连字符形式(如 clip-path)。
  • 该脚本现已集成到作者的构建流程中 (pnpm run build; pnpm run cloudflare:svg),成功修复了部署后图标损坏的问题。

总结 作者在 Cloudflare Pages 部署时遇到了 SVG 属性被构建流程错误转换的特定问题。经过详尽的排查,确认问题仅发生在 Cloudflare Pages 的构建环节。最终,作者通过在构建后运行一个专门的属性修复脚本,暂时解决了此问题,并希望未来能找到更根本的解决方案。

14. What Is a Particle? (2020) (www.quantamagazine.org)

文章摘要:粒子是什么?

这篇文章探讨了一个根本性问题:组成宇宙万物的基本粒子究竟是什么? 尽管常被视为没有内部结构、没有体积的“点”,但粒子却拥有质量、电荷等明确属性,这一矛盾促使物理学家们从不同理论框架出发,给出了多样且不断深化的答案。以下是文中阐述的七种主要观点:

  1. 坍缩的波函数 根据量子力学,粒子由抽象的“波函数”描述,该函数代表粒子各种可能状态的概率分布。然而,一旦进行测量,波函数会“坍缩”到一个确定的状态,粒子便显示出具体的位置。因此,粒子可被看作是坍缩后的波函数。但观测为何以及如何导致坍缩,仍是未解之谜。

  2. 量子场的激发 量子场论将粒子重新定义为弥漫于全空间的“量子场”的局部激发或振荡。例如,光子是电磁场的激发,电子是电子场的激发。粒子失去了基础地位,变成了场上的能量“波包”。该理论能极高精度地预测粒子相互作用,是现代粒子物理学的通用语言。

  3. 庞加莱群的不可约表示 从更抽象的数学视角,粒子被视为“庞加莱群”的不可约表示。庞加莱群描述了时空的基本对称性(平移、旋转和 boosts)。1939年,尤金·维格纳证明,粒子正是在此群变换下保持不变的最简单对象,其内禀属性(如能量、动量、自旋)由此而来。例如,自旋本质上是世界存在旋转对称性的一个“标签”。

  4. 具有多层属性的实体 粒子不仅具有源于庞加莱群的时空属性,还拥有额外的“内部”对称性标签,如电荷、色荷、味等。这些属性对应更抽象的对称群变换(如 SU(3)、SU(2)、U(1))。粒子物理学的标准模型即是一个基于 SU(3)×SU(2)×U(1) 对称群的量子场论,成功描述了已知粒子及其除引力外的相互作用,但其结构来源仍是开放问题。

  5. 可能是振动的弦 弦理论提出,在极小尺度下,粒子并非点状,而是一维的振动弦,其不同的振动模式对应不同的粒子。该理论还需引入额外的紧致化空间维度,粒子的内部对称性(如色荷)可解释为在这些微观维度上的旋转。尽管极具启发性,但弦理论目前缺乏实验证据。

  6. 量子比特海洋的变形 “万物源于量子比特”这一前沿研究范式认为,宇宙万物(包括时空本身)都源于量子信息——纠缠的量子比特(qubit)。在此图景中,时空和粒子都是量子比特纠缠模式在低维系统中的全息投影。研究发现,当量子比特系统全息地编码一个时空区域时,总会自动产生对应的、位于高维世界中的局部能量激发——即粒子。粒子因此是量子比特系统在时空中的全息“变形”。

  7. 探测器中测量到的对象 另一派称为“散射振幅学家”的研究者,试图绕过量子场论复杂的中间过程,专注于直接计算“散射振幅”——即粒子碰撞时可能发生的变化的概率。对他们而言,粒子最直接的定义就是在实验探测器中被测量到的对象,而理论的核心任务是找到计算这些可观测量的更简洁、更基本的数学结构。

总结而言,对“粒子是什么”的回答从早期的波函数、量子场激发,发展到基于对称群的数学表示,再到弦理论、量子信息等更深刻的物理图像。当前的研究正沿着两条主要路径深入:一是探索粒子与时空如何从量子比特和全息原理中涌现;二是寻求更优美、更基础的数学框架来描述粒子相互作用。这个问题的答案仍在不断演进之中。

17. LHC experiments at CERN observe quantum entanglement at the highest energy yet (home.cern)
18. Compiling to Assembly from Scratch (keleshev.com)

《从头开始编译到汇编》摘要

书籍概述

本书《Compiling to Assembly from Scratch》由Vladimir Keleshev编写,旨在指导读者从零开始构建一个编译器,实现从源代码到汇编语言的完整过程,无捷径。书中使用TypeScript的子集(类似伪代码)进行讲解,并针对ARM 32位指令集作为目标,涵盖足够的编译器理论和汇编编程知识。

内容结构

书的内容分为两大部分和附录:

  • 第一部分:基线编译器
    包括高阶编译器概述、抽象语法树、解析器组合子、解析过程、ARM汇编编程基础,以及代码生成。这部分构建编译器的核心功能。
  • 第二部分:编译器扩展
    介绍高级功能,如基本标量数据类型、数组和堆分配、访问者模式、静态类型检查与推断、动态类型,以及垃圾回收。这些扩展增强编译器的实用性和复杂性。
  • 附录
    提供运行ARM程序的指南,以及GAS与ARMASM语法的对比,帮助读者在实际环境中应用所学。

技术细节

  • 编程语言:使用TypeScript的简化子集,代码风格类似伪代码,便于理解编译器逻辑。
  • 目标架构:ARM 32位指令集,专注于嵌入式或低级系统开发场景。
  • 源代码:书中所有代码在GitHub上公开可用,并提供Python和OCaml的移植版本,支持多语言学习和实践。

作者背景

作者Vladimir Keleshev是一名软件开发者,居住和工作在哥本哈根附近。他的经验涵盖嵌入式系统、安全关键系统、编译器开发,目前专注于金融领域的领域特定语言(DSL)。插画师Katiuska Pino为书籍封面和印刷版的15个章节绘制了插图。

版本与出版信息

  • 印刷版:共207页,尺寸为6×9英寸(152×229毫米),采用哑光硬封面,可在lulu.com购买,ISBN为978-87-980078-0-7。
  • 电子书版:最初于2020年以电子书形式出版,现已被在线版替代。书中提供了标准的学术引用格式,方便引用。
  • 在线版:取代原电子书版,提供数字访问。

其他资源

  • 联系方式:读者可通过电子邮件(vladimir@keleshev.com)或社交媒体(如Bluesky @keleshev.com)联系作者。
  • 协作:源代码在GitHub上开放,鼓励用户提交问题或拉取请求,促进社区互动。

本书通过理论与实践结合,帮助读者深入理解编译器工作原理和汇编编程,适合学习编译器设计和系统级开发的读者。

20. pgroll: PostgreSQL zero-downtime migrations made easy (github.com)

pgroll: PostgreSQL零停机迁移工具

核心功能
pgroll是一个开源命令行工具,专为PostgreSQL提供零停机、可逆的数据库模式迁移。它通过同时维护新旧数据库模式版本,确保在模式更新期间客户端应用持续运行,无需锁定数据库,即使存在破坏性变更也能保证兼容性,从而消除迁移风险并支持即时回滚。

主要特点

  • 零停机迁移(无数据库锁定,兼容破坏性变更)
  • 新旧模式版本同时可用
  • 必要时自动回填列数据
  • 问题发生时支持即时回滚
  • 适用于现有数据库,无需从零开始
  • 支持PostgreSQL 14.0及以上版本,兼容RDS和Aurora等云服务
  • 用Go编写,跨平台单二进制文件,无外部依赖

工作原理
pgroll采用扩展/收缩工作流,通过基于物理表的视图构建虚拟模式:

  1. 启动迁移:执行增量变更(如创建表、添加列),在物理模式中新增列并回填数据,通过触发器同步新旧列的写入,同时暴露新模式版本。
  2. 同时访问:客户端可通过配置search_path同时访问新旧模式版本。
  3. 完成迁移:确认所有客户端迁移至新模式后,删除旧模式,重命名新列至最终名称。

基本使用流程

  1. 初始化数据库pgroll init创建内部状态表。
  2. 导入现有模式(可选)pgroll baseline导入已有数据库结构。
  3. 启动迁移:编写迁移文件(JSON格式),执行pgroll start
  4. 配置客户端:客户端通过SET search_path使用新模式。
  5. 完成迁移:执行pgroll complete移除旧模式。
  6. 回滚迁移:随时执行pgroll rollback恢复到旧模式。

安装方式

  • 二进制文件:从发布页面下载对应系统版本。
  • 源码安装:需Go 1.24+,运行go install github.com/xataio/pgroll@latest
  • Homebrewbrew install pgroll(macOS/Linux)。

性能与文档
工具提供基准测试跟踪性能,文档涵盖高级用法、教程和详细选项。项目基于Apache 2.0许可,欢迎社区贡献代码或问题反馈。

22. Tetris shows promise in reducing PTSD symptoms (www.legalreader.com)

研究概述

一项由乌普萨拉大学研究人员领导的研究发现,经典游戏《俄罗斯方块》在减轻创伤后应激障碍(PTSD)症状方面展现出显著潜力。该研究发表在《BMC医学》上,专注于利用视频游戏减少侵入性记忆,这是PTSD的核心症状,表现为反复出现的创伤闪回,严重影响心理健康和日常生活。

背景与问题

PTSD通常伴随侵入性记忆,使患者反复体验创伤事件,导致睡眠障碍、注意力下降等问题。传统治疗如认知行为疗法需要多次临床会话,成本较高且不易普及。因此,研究探索了一种更简单、经济的家庭干预方法。

研究方法

研究针对COVID-19大流行期间经历创伤性压力的医护人员,共招募164名参与者。参与者被分为两组:一组进行引导治疗,包括玩《俄罗斯方块》游戏;另一组进行非视觉任务(如听收音机)作为对照。研究人员通过PTSD检查表(PCL-5)评估症状变化。

关键发现

  • 短期效果:干预后五周,玩《俄罗斯方块》的组平均每周闪回次数从15次降至1次,而对照组仅降至约5次。
  • 长期效果:六个月后,《俄罗斯方块》组的PTSD症状严重程度持续减轻,对照组改善较少。使用PCL-5评估显示,《俄罗斯方块》组的PTSD症状比对照组减少近一半。

理论基础

研究基于“心理旋转”概念:在《俄罗斯方块》中,玩家需视觉处理和旋转方块形状,占用大量认知资源,从而干扰大脑对创伤记忆的重播,防止闪回固化。

应用意义

该研究提出“认知疫苗”概念,即创伤后使用类似《俄罗斯方块》的简短干预,可预防PTSD发展。这种干预易于实施、成本低,为早期PTSD治疗提供了新方向,尤其适合资源有限或无法接受传统治疗的人群。

结论

研究证明,仅一次引导会话的《俄罗斯方块》游戏能显著减少PTSD侵入性记忆和症状,效果持久。这为非药物、非传统疗法在心理健康领域的应用开辟了新途径。

23. Flappy Bird for Android, only C, under 100KB (github.com)

Flappy Bird for Android:纯C实现,APK不足100KB

项目目标

使用纯C语言开发Android版Flappy Bird游戏,实现APK大小低于100KB的极简目标。

项目历史与背景

  • 2021年:作者发现rawdrawandroid项目,旨在用最小APK体积创建可理解且有趣的游戏。选择Flappy Bird作为开发对象。
  • 首次尝试:使用C++和ImGui开发,但遇到APK体积过大(约1MB)、崩溃问题,且未满足Google要求包含arm64-v8a架构库的规定。
  • 2024年9月:在Raylib Discord频道看到C#版Flappy Bird后,决定用C语言重新实现,竞争心态驱动其挑战100KB以下的目标。

技术实现

  • 构建工具:使用Android命令行工具和Makefile进行编译打包。
  • 音频处理:将声音文件压缩为MP3格式,通过OpenSLES进行播放。
  • 图像解码:采用upng库解码PNG图像。
  • 图形渲染:结合OpenGL ES 2、着色器(shaders)和Android Native Activity实现游戏画面。

构建方法

Windows环境

  1. 使用Visual Studio Code。
  2. .env.example创建.env文件。
  3. 运行build.bat脚本。

Linux/macOS环境

  1. 安装Android命令行工具。
  2. 在项目根目录设置.env环境变量(参照.env.example)。
  3. 执行Makefile构建项目。
  • 输出:签名后的APK文件位于FlappyBird/app/build/outputs/apk/FlappyBird-signed.apk

版权与致谢

  • 游戏及资源版权归属原作者DotGEARS,本项目不主张版权。
  • 项目灵感来源于:rawdrawandroid、Flapper、Raylib、ImGui。
25. One-time purchase alternatives to popular subscription tools (payoncealternatives.com)

摘要

本文介绍了一个名为“Pay Once Alternatives”的在线软件目录。该目录的核心目的是为用户提供流行订阅制软件的一次性付费替代方案。它旨在帮助用户发现那些允许“一次购买,永久拥有”的优质软件,从而避免持续的订阅费用。

该网站的结构是一个软件目录,其关键功能在于筛选和汇集那些提供一次性付款选项的软件产品。用户可以通过这个平台,找到可以替代常用订阅工具(如各类办公、设计、效率软件)的永久授权版本。

总结来说,这是一个专注于解决“软件订阅疲劳”的资源聚合网站,其主要价值在于为用户提供一个便捷的途径,去寻找和获取那些采用传统买断制销售模式的软件替代品。