皮尤研究中心（Pew Research）的一项新研究显示，尽管人工智能（AI）在经济和日常生活中日益普及，大多数美国人对该技术未来20年对美国社会的影响持中性或负面看法。

社会观感与监管信任度

• 仅**16%的美国人认为AI在未来20年将对社会产生积极影响，而约40%**的人认为其影响将是负面的。
• **67%**的受访者不相信美国政府会采取有意义的措施来监管AI。
• **59%**的人不信任企业会安全地开发AI。
• 近三分之二的美国人认为AI的发展速度过快。
• 值得注意的是，30岁以下的年轻群体对AI的负面情绪最为强烈，该群体中仅**14%**的人认为AI将带来积极影响。

使用现状与工具偏好 尽管存在普遍质疑，美国人日常使用AI的频率仍在上升：

• 约四分之一的美国人每天使用AI聊天机器人，主要用于研究或工作。
• ChatGPT占据主导地位，**44%**的美国成年人表示使用过OpenAI的这款聊天机器人，这一比例自2023年以来增长了一倍以上。
• 其他聊天机器人的使用率依次为：Gemini（24%）、Copilot（17%）、Meta AI（14%）、Grok（8%）、Claude（6%）和Character.ai（3%）。

性别与年龄差异

• 性别差异：男性使用AI的比例和热情均高于女性。男性日均使用聊天机器人的比例为27%，女性为20%。虽然男女使用ChatGPT的比例相当，但男性使用Copilot和Grok等其他品牌的比例更高。
• 年龄差异：不使用AI的人群往往年龄较大。约50%的美国人表示日常生活中不使用AI，而在65岁及以上人群中，近**75%**表示从未使用过AI聊天机器人。非用户普遍表示对AI不感兴趣，且未来也不打算使用。

信息获取方式的转变 AI正在改变美国人的信息消费习惯。调查显示，**60%**的受访者表示会定期阅读AI生成的网络摘要（例如在谷歌搜索结果中）。此外，也有较少比例的人使用AI获取健身和饮食方面的信息。

Local Qwen 不是劣质的 Opus，而是另一种工具

这篇长文由开源项目 OpenFaaS 的创始人撰写，基于其软件公司的实际运营经验，论证了本地大模型（以 Qwen 3.6 27B 为代表）与云端前沿模型（如 Claude Opus）并非简单的优劣关系，而是适用于不同场景的两种工具。

作者的背景与核心观点

作者运营一家围绕基础设施与 Linux 原语的小型软件公司，产品涉及容器、微虚拟机、网络隧道与 CI 运行器，代码主要以 Go 语言编写。他长期使用 Claude、Codex 等云端模型完成大部分编码工作，但同时也投入大量资源部署本地模型。其核心论点是：将本地 Qwen 称为“接近 Opus 水平”是一种误导；本地模型有真实价值，但无法在无监督的情况下承担长周期、高复杂度的代理任务。

本地模型的独特价值

作者认为，选择本地模型通常出于三类非纯性能原因：

• 成本：对个人而言，每月 200 美元的云端编码计划看似可控，但企业级重度使用、API 按量计费或 SaaS 嵌入式场景下，成本会迅速攀升（例如 Uber 将每位开发者每月 AI 工具支出上限设为 1500 美元）。本地模型在高频、循环、代理式分析中能摊薄固定成本。
• 主权与隐私：作者的客户对数据控制要求极高。诊断日志、遥测数据库等敏感数据既不能流入云端，也无法承担因供应商策略突变导致模型下架的风险（如 Anthropic 的 Fable 5 overnight 移除）。本地模型是应对“前沿实验室突然改变规则”的保险。
• 供应商锁定风险：对于美国以外地区的用户，云端服务随时可能因政策、合规或商业原因中断；本地权重消除了这一单点故障。

硬件投入与投资回报

作者的本地部署经历了三个阶段：

• 双卡 RTX 3090：2023 年起步，受限于 24GB 显存，必须在量化等级（Q4）、上下文长度和 KV Cache 压缩之间反复权衡，可靠性差，结果令人沮丧。
• 升级到 RTX 6000 Pro Blackwell（96GB VRAM）：花费约 12000 美元。这笔投资在最初两三个月内即收回成本。

具体回报案例包括：

• 无痛客户支持：开发 diag CLI 工具收集 OpenFaaS 集群快照，由客户在离线环境运行后，将诊断包导入本地模型分析。这不仅加速了支持流程，也彻底避免了客户数据外泄。
• 收入追回：将遥测数据库输入本地模型分析，发现某客户长期少报许可证数量，少付金额达应付款的 4–5 倍。仅此一项便足以覆盖显卡成本。

技术架构与配置

当前主力设备为单张 RTX 6000 Pro，运行两个独立的 llama.cpp 实例（而非加 --parallel 2，以避免上下文被切半）。同时加载 Qwen 3.6 27B 基础模型与 Qwopus（针对推理和编码的社区微调版）。

关键参数与优化：

• 使用 UD-Q8_K_XL 量化，KV Cache 采用 f16，上下文长度设为 262k。
• 开启 MTP（Multi-Token Prediction）投机解码，接受率约 93%，生成速度从稳定的 67 tok/s 提升至 130–200 tok/s，主观体验比云端模型更快。
• 针对模型卡仔细调节温度、Top-P、Reasoning Budget 等参数；Qwopus 微调版在关闭思考模式且温度较高（0.85–1.0）时表现最佳。
• 曾测试 vLLM，但在单用户、低延迟、快速启动的“专业消费者”场景下，llama.cpp 更快、更简单。

致命缺陷：无限循环与幻觉

作者以“回火（tempering）钢材”作比：本地模型像在无人看管下烧过头的刀刃，极易“过热”并陷入循环。

具体故障模式包括：

• 重复循环：要求为 faas-cli 设计子命令时，模型在 30 分钟内不断重复相同的五条建议，耗尽电力。
• 能力边界处的自我纠缠：在尝试为所有命令添加 --json 输出时，模型因无法处理 TLS 警告打印问题而逐步偏离轨道，破坏文件结构，陷入“越修越坏”的循环，且不会主动求助。

作者强调，绝不能将本地 Qwen 用于无人看管的长周期代理任务。这正是它与 Claude/Codex 最本质的区别：后者可在 5–15 分钟内自主完成端到端开发、测试并提交 PR，而 Qwen 27B 在长时间无人干预时会失控。

使用边界与建议

作者总结了本地 Qwen（及同类量级模型）的实际适用场景与禁忌：

适用场景：

• 有明确边界的客户支持与运维分析
• 阅读、解释大型代码库（“快速看懂代码”是本地模型的一大超能力）
• 结构化数据排查与计费对账等数据密集型分析（但需人工复核算术）
• 配合详细的 AGENTS.md 完成受限维护、端到端测试或 CLI 扩展
• 通过社区微调版（如 Qwopus）和 Agent Skills 提升特定任务成功率

禁忌与注意事项：

• 不要量化过低（如 Q4_0 KV Cache），否则幻觉与循环风险激增。
• 不要让模型做“解释”或“预测”（如客户流失判断），它容易忽略关键上下文；更适合聚焦分析，而非主观推断。
• 不要与云端 API 做简单的“每百万 token 成本”对比；本地模型的价值在于处理不适合上云的工作负载。
• 27B 稠密模型在编写 Go 分布式系统、并发代码和代码审查时能力明显受限——曾出现幻觉竞态条件、无视“保持简洁”的指令而过度展开等问题。
• 70B 模型大多落后一代；35-A3B 虽在 Mac 上看似快，但生成时仅激活 3B 参数；GLM 5.2、Kimi 2.7、DeepSeek V4 Flash 等更大模型本地部署需 4–6 张高端卡，已超出中小企业范畴。

结论

本地 Qwen 3.6 27B 不是“差一点的 Opus”，而是在特定约束下的一件不同工具。它在隐私、成本控制与供应商主权方面提供了不可替代的价值，尤其适合客户支持诊断、代码库理解和结构化数据分析。但必须严格限定任务范围、避免长周期无人监督的代理工作，并持续在量化等级、调参与微调模型之间做权衡。它尚不足以独立编写复杂的 Go 分布式系统，但在正确场景下已成为生产流程中务实且高效的补充。

泄露的经审计财务报表显示，OpenAI在递交美国证券交易委员会（SEC）IPO申请文件之际，尽管收入快速增长，但仍深陷巨额亏损。

收入高速增长 根据独立记者Ed Zitron获取并被《金融时报》审阅的文件，OpenAI的营收从2024年的37亿美元飙升至2025年的130.7亿美元。截至2025年底，其月收入已接近20亿美元，表明全年增速持续。

支出远超收入 然而，收入增长远不及各项成本的膨胀速度：

• 研发费用：从2024年的78.1亿美元激增至2025年的191.8亿美元，单是2025年向微软支付的研发相关费用就达105.9亿美元。这主要用于训练新模型。
• 收入成本（即生产和分发产品的支出）：从2024年的26.5亿美元增至2025年的75亿美元，主要反映模型推理阶段的巨额算力开销。
• 销售与营销费用：从2024年的11.1亿美元增至2025年的57.3亿美元。

经营亏损扩大，但亏损率略有改善 2025年，OpenAI的日常运营亏损从2024年的87.8亿美元扩大至209.2亿美元。虽然公司向投资者表态希望2030年实现盈利，但亏损规模仍在急剧上升。

不过，若以占收入比例衡量，经营亏损率稍有好转：从2024年占收入的237%下降至2025年的160%，显示收入增速略快于亏损增速，但距离实现盈利仍有漫长道路。

Midjourney Medical 项目概述

Midjourney宣布进军医疗领域，旨在重新构想医疗保健基础及人与身体的关系。该项目追求打造一种兼具MRI级别成像能力与SPA般轻松体验的全新设备，以极速、低成本的方式获取身体数据，推动人们从被动治疗转向主动、高频的健康管理，最终延长并改善生命质量。

超声波全身扫描仪

核心产品"The Midjourney Scanner"是一款全身超声波成像设备。用户站立于金色浅水池中的平台上，以每秒约5厘米的速度缓缓下沉，穿过由约50万个沙粒大小的元件组成的环形传感器阵列。每个元件同时充当微型扬声器和麦克风，以每秒数百万次的频率发射超声波并接收回波。系统通过分析声波在穿越不同密度与刚度组织（水、皮肤、脂肪、肌肉、骨骼）时的形状变化，由大规模计算机集群处理每秒TB级的数据，重建体内图像。

整个扫描过程目标控制在60秒内完成，最终生成精度达毫米以下分数的3D身体地图，成像质量类似MRI，但速度快近100倍。展示图像涵盖腹部、大腿等部位的原始重建切片与AI分割结果。

Midjourney Spa 与业态融合

为将医疗扫描融入日常，Midjourney将设备嵌入休闲水疗场景。首家"Midjourney Spa"定于2027年在旧金山开业，提供热水浴、桑拿、冷水浴及配有金色光池的舒适扫描房间，计划24小时运营。设计理念是让扫描成为放松体验的"副作用"，用户在享受水疗的过程中不知不觉积累大量个人健康数据。

发展路线图

未来12个月将集中精炼算法与硬件，开展研究试验，推进第二代硬件设计并建设首个"研究水疗中心"。初期先提供详细身体成分图，并将定期向FDA提交测试结果以逐步解锁更多诊断能力。2027年底首家Spa开业；2028年扩展至更多城市并推出采用完全定制芯片的第三代扫描仪，实现图像质量与扫描速度的飞跃。2031年目标是在全球部署超5万台扫描仪，实现每月10亿次扫描的容量。

愿景与组织定位

Midjourney预测，大规模早期成像未来可帮助全球避免30%的死亡和50%的医疗成本。作为无外部投资者、由社区资金支持的研究实验室，Midjourney强调公众参与，邀请社区共同塑造扫描与水疗体验，并计划定期公布技术更新与扫描图像，此外还有其他长期项目正在开发中。

https://chat.deepseek.com/

AMD 被曝出已悄然从消费级 Ryzen 处理器中移除了 Transparent Secure Memory Encryption（TSME）安全功能。TSME 是一种固件级内存加密技术，可在无操作系统介入的情况下加密全部内存数据，主要用于防御冷启动攻击、DRAM 接口嗅探及物理接触式内存窃取等攻击手段。

该变动由 Linux 用户 Ben Kilpatrick 发现。他在为一台搭载 Ryzen 7 9700X 的电脑安装系统时，通过安全审计工具 HSI 检测到 TSME 不再受支持，尽管其主板 BIOS 中已开启该选项。Kilpatrick 随后联系了主板厂商 MSI 及 AMD 工程师，并促使 MSI 进行了对照测试。结果显示，消费级 Ryzen 处理器在旧版固件中 TSME 可用，但在新版 AGESA 1.2.7.0 固件中该功能被标记为“不支持”；而同架构的 Ryzen Pro 处理器则不受固件或主板限制，始终支持该功能。

调查还发现，AMD 工程师曾在 2020 年和 2025 年的公开讨论中确认消费级处理器（如 Ryzen 3700X）支持 TSME。然而，当 Kilpatrick 追问当前消费级芯片无法启用 TSME 是属于硬件限制还是固件策略时，AMD 工程师以“没有更多信息可分享”终止了讨论。AMD 官方对外的唯一回应则是通过邮件称 TSME 为“仅应用于 PRO CPU”的安全特性，这是该公司首次公开将 TSME 限制在 Pro 系列。

目前尚不清楚这是 AMD 有意进行的产品细分，还是 AGESA 1.2.7.0 引入的固件回退。该功能的移除在 Windows 系统上完全不可见，在 Linux 上也需要专业技术手段才能察觉，导致大量消费级用户在不知情的情况下失去了一层关键的物理安全防护。对于依赖全盘加密、处理机密数据或担心设备被物理窃取/篡改的用户而言，这意味着他们可能必须转向 Ryzen Pro 或 EPYC 平台才能获得同等保护。

Windows 11 目前提供两个版本的 Outlook：Outlook Classic（传统 Win32 原生应用）与新 Outlook（基于 WebView2 的网页封装应用）。尽管微软力推新版作为未来发展方向，但其在通知响应性能上存在显著缺陷。

实测显示，当用户点击 Windows 11 右下角的新邮件通知横幅时，Outlook Classic 几乎能瞬间打开对应邮件；而新 Outlook 则需要约 10 秒才能从通知跳转至目标邮件。更具讽刺意味的是，如果用户忽略通知、直接从开始菜单打开新 Outlook 并在收件箱中手动查找该邮件，整个过程仅需约 5 秒，反而比点击通知更快。

这一问题的根源在于新 Outlook 的 WebView2（Chromium 渲染引擎）架构。每次点击通知时，应用需要初始化或恢复网页层、完成身份验证、加载邮件线程并渲染内容，整套浏览器式进程链条导致延迟。任务管理器显示，新 Outlook 闲置时会运行 10 个独立进程（包括 WebView2 Manager、GPU 进程、Service Worker 等），而 Outlook Classic 仅有一个紧凑进程。

资源占用方面差距同样明显：闲置状态下，新 Outlook 内存占用约 490 MB 至 636 MB，CPU 约 4%；而 Outlook Classic 内存仅 117 MB 至 148 MB，CPU 低于 1%。

微软并非没有改进新 Outlook。其冷启动速度已大幅提升，接近 Classic；2026 年以来的多次更新也加入了改进的文件夹搜索、共享邮箱、自动映射日历、统一收件箱（All Accounts View）、邮件合并及扩展的 .PST 支持等功能。但由于企业版强制迁移截止日期已从 2026 年 4 月推迟至 2027 年 3 月，说明微软也承认该应用尚未完全成熟。

然而，通知延迟这类问题并非简单通过功能更新就能修复，而是 WebView2 网页应用架构本身带来的原生性能瓶颈。微软目前已表态全面转向 WinUI 原生应用开发，未来或许会推出真正的原生 Outlook。在此之前，如果快速处理邮件通知是工作流的关键环节，Outlook Classic 仍是更可靠的选择——该版本可持续使用并支持至 2029 年 4 月。

Emacs 31 尚未正式发布，但作者已长期从 master 分支构建并日常使用，将其整合进零外部包配置。以下是主要内置改进的概览。

Tree-sitter 开箱即用
treesit-enabled-modes 设为 t 即可自动切换至 tree-sitter 变体模式；treesit-auto-install-grammar 会在语法缺失时自动提示下载构建。TypeScript、Rust、YAML 等语法源已内置于对应模式中，无需再手动维护 treesit-language-source-alist。若跨不同架构机器共享配置，需注意自动安装的 .so 未按架构隔离，可能触发二进制不兼容。

内置 markdown-ts-mode（实验性）
新版本自带 markdown-ts-mode，提供类 Org 的编辑与导航体验；fenced 代码块可调用对应主模式实现实时代码高亮与编辑；支持内联图片渲染。因仍处于实验阶段，尚未默认加入 auto-mode-alist，需手动加载或自行配置。

Eglot 文档渲染
Eglot 在 Emacs 31 中可借助 markdown-ts-view-mode 直接格式化 LSP 悬停文档，无需额外包。注意 eglot-events-buffer-size 等旧变量正被新配置取代。

补全与微交互
completion-eager-update 与 completion-eager-display 支持输入时即时刷新补全界面；minibuffer-visible-completions 设为 'up-down 可用方向键浏览候选。icomplete 新增垂直缓冲区和前缀指示器。global-eldoc-mode 可在光标处自动显示帮助文本。另有 kill-region-dwim（无区域时向后删词）、view-lossage-auto-refresh（实时展示按键轨迹）、tty-tip-mode（终端下显示 tooltip）等细节改善。

窗口与显示
新增 window-transpose、window-rotate、翻转等布局变换命令，无需手动拆分即可重排窗口。Speedbar 支持以侧边窗口停靠，替代旧版浮动帧。term/ansi-term 修复了 htop 等全屏终端应用的吞行与渲染错乱问题。新版还内置 Modus 5 系列主题，包含色盲优化变体。

开发工具链

• VC：vc-dir-auto-hide-up-to-date 刷新后自动隐藏已最新文件；vc-allow-rewriting-published-history 支持 Jujutsu 等重写已发布历史的工作流。
• xref：新增 xref-edit-mode，支持在结果缓冲区内直接批量编辑匹配项，确认后自动应用，无需导出到 grep。
• ERC：仅在新打开的缓冲区插入历史日志；scrolltobottom 不再强制依赖 erc-fill-wrap。

其他
ielm-history-file-name 使 IELM 历史可持久化；native-comp-async-on-battery-power nil 可避免电池模式下后台编译导致风扇突转。

作者强调， daily driving 开发版的最大乐趣在于 Emacs 核心不断吸收原本需手写的配置，使个人配置日渐精简。上述所有功能均内置于 Emacs，无需任何外部包。

Tesco正将约4万台服务器工作负载从VMware平台迁出，原因是Broadcom收购VMware后实施的大幅涨价策略。该公司在迁移过程中还面临数据安全挑战，因其选定的新虚拟化软件与现有的Veeam和Zerto备份及灾难恢复产品不兼容。

在有关法律纠纷中，Tesco最初向Broadcom、VMware及转售商Computacenter各索赔至少1亿英镑（约1.336亿美元）外加利息。Tesco表示曾拒绝Broadcom提出的至少四次续约报价，其中一项年费2350万美元（约1760万英镑）的方案涵盖VMware Cloud Foundation 9.0及大型机软件支持服务。Tesco指出，该报价比其认为合理的VMware费用高出约175%，大型机产品价格涨幅更达350%，属于"明显不公平且过高"。Broadcom则在修订后的辩护中否认定价不公，并主张Tesco既已找到替代产品，便无权就寻找替代方案期间的困难索取赔偿。此案预计将于2027年11月至2028年2月间在英国开庭审理。

Tesco的遭遇反映了Broadcom收购VMware后全球范围内广泛存在的不满情绪。由于用户高度依赖VMware产品，加之迁移涉及高昂成本、时间投入、技术支持及兼容性问题，许多客户推迟或仅部分迁移工作负载。据估计，到2028年约有35%的VMware工作负载将迁移至其他平台。

与此同时，HPE、Nutanix等虚拟化竞争对手正积极争取不满的VMware客户，Nutanix声称已获取3万名原VMware客户。Broadcom则坚持现有策略，在大型企业市场仍报告财务成功。此外，Broadcom还卷入其他公开法律争端，包括与AT&T（已达成未公开和解）及西门子（在美国特拉华州地方法院审理中的软件版权诉讼）。

Ribbie: 8-bit baseball 是一个以复古 8 位像素艺术风格实时呈现美国职业棒球大联盟（MLB）比赛的直播项目（ribbie.tv）。该项目在 "Show HN" 中展示，核心功能是将实时棒球比赛数据——包括比分、球数、跑垒员状态以及场上每一次动态——转化为实时更新的 8-bit 像素画面。

从公布的界面片段可见，该平台提供多种观看模式（如 ROOM、COUCH、ZOOM、FULL 等选项）以及音频控制功能（如静音开关），旨在为用户提供一种兼具游戏感与怀旧风格的赛事追踪体验。

11个大语言模型的大逃杀对决：Grok 胜率 43% 夺冠，Claude 因"对齐税"落败

OpenRouter 开发者关系负责人 Jacky Liang 将 11 款主流 LLM 投入自建的 2D 俯视角大逃杀游戏《Royale: Last Agent Standing》中，连续进行 30 场对决。实验并非让模型编写代码控制角色，而是每回合由模型自主推理、调用工具（移动、攻击、驾驶、广播等）并更新记忆。

核心战果

xAI 的 Grok 4.1 Fast 以 13 胜（43% 胜率）和每胜仅 $0.97 的成本夺得第一。Anthropic 的 Claude Sonnet 4.6 获得 5 胜，但每胜成本高达 $26.78，两者相差约 27 倍。GPT 5.4 击杀数最多（38 人）却只赢 2 场。GPT 5.4-mini、DeepSeek v4 Flash 与 Kimi K2.6 三核对局零胜，合计花费 $57.15。

关键发现

对齐税影响胜负：Claude 因 RLHF 和 Constitution AI 训练，表现出高度合作性——频繁请求停战、分享位置、寻求帮助，导致在零和博弈中处于劣势；甚至有 7 场零击杀、8 次死于毒圈。相反，Grok 过滤较少、攻击性强，通过 soul.md 和 memory.md 快速固化"开车撞击"等有效战术，并严守"仅 >90% 命中率才开火"的纪律。

传统基准失效：Grok 在常规推理和编码基准中仅属中端，但在无后果的竞技场景中，"更少自我审查"成为制胜关键。

击杀不等于胜利：排行榜采用类 Apex Legends ALGS 的积分制，排名分权重高于击杀分。GPT 5.4 热衷交火却未能高效存活；Grok 凭借存活与排名分获胜。

成本效益逆转：按胜率排名与按"每胜成本"排名完全相反。DeepSeek 每击杀成本最低（$0.26），却因避战策略无缘胜利。

实验设计细节

11 名参赛者包括 Claude Sonnet/Haiku、GPT 5.4/5.4-mini、Gemini Pro/Flash、Grok、Qwen、Mistral、DeepSeek、Kimi。每个模型可自主编辑 soul.md（人格设定）和 memory.md（比赛笔记）带入下场对局。400m² 战场含随机缩圈、武器、载具；33% 的淘汰来自毒圈。Warehouse 降落点胜率最高（21.7%），最热门的 Farmhouse 仅 4.4%。

模型间人格差异显著：Grok 的日记像战绩 hype reel，自称 ZoneReaper；GPT 5.4 像战术手册，自称 QuietVector；Claude 则像自我绩效评估，自称 ZoneDrifter。

结论与展望

作者指出，单一基准无法衡量模型在不同场景下的适用性：Grok 适合"赢者为王"的竞技，Claude 的谨慎与合作在真实世界高后果场景中更有价值。未来计划推出基于该模拟器的公开基准 RoyaleBench，并探索按具体任务自动路由最优模型的方案。

根据所提供的标题及正文内容，SteamOS Linux 3.8 已作为稳定版发布，Valve 将该版本标记为稳定状态。

然而，公告正文并未提供关于此次发行的任何具体技术细节、更新日志、功能改进、系统变更或已知问题说明。正文部分仅包含 Valve 公司的标准页脚信息，具体包括：

• 版权声明：© Valve Corporation. All rights reserved.
• 商标声明：All trademarks are property of their respective owners in the US and other countries.
• 法律与政策链接：
  • Privacy Policy
  • Legal
  • Accessibility
  • Steam Subscriber Agreement
  • Refunds
  • Cookies

综上，目前可确认的信息仅限于 SteamOS Linux 3.8 稳定版已发布 这一事实，但尚无进一步的发行说明或功能详情可供总结。

This is the story of how I found 10,000 repositories on GitHub that distribute Trojan malware. They are all from different contributors, have different names, and are not forks of other repositories. But they share a common pattern, which is what allowed me to write a script to find

Madrid tripled the length of its metro system in just 12 years — faster and cheaper than almost any other city in the world. What can its expansion teach other cities?

Glojure 是一个基于 Go 语言托管的 Clojure 解释器，目前处于早期开发阶段。作为“托管语言”，它与 Go 的值类型完全互通：所有 Go 值均可直接作为 Glojure 值使用，反之亦然。该项目支持轻松调用 Go 标准库，类似于 Clojure 调用 Java 框架。虽然向后兼容性在 v1 发布前暂不保证，但它已能成功运行大量经过转换的 Clojure 核心库代码。

安装需要 Go 1.19 或更高版本（源码安装需 Go 1.24+），通过以下命令安装：

go install github.com/glojurelang/glojure/cmd/glj@latest

安装后执行 glj 即可启动 REPL。

使用方式

Glojure 提供两种使用模式：独立命令行工具 glj，或嵌入到 Go 应用程序中。

命令行工具 glj

提供传统 Clojure 开发体验，支持：

• 基础命令：glj --help（帮助）、glj --version（版本）
• 交互式 REPL：支持 vi/emacs 编辑模式、多行编辑与自动缩进、符号/命名空间/别名的 Tab 补全、智能缩进（2 空格）、持久化历史记录（保存至 ~/.glj_history）、括号粘贴、作业控制（Ctrl+Z 挂起，fg 恢复）及求值中断（Ctrl+C）
• 表达式求值：glj -e '(+ 1 2 3)'
• 运行脚本：glj script.glj arg1 arg2
• 执行程序：可直接运行包含 Go 互操作逻辑的完整程序（如启动 HTTP 服务器）

嵌入 Go 应用

可将 Glojure 作为脚本语言嵌入现有 Go 项目，适用于添加可配置脚本、用户插件、混用 Go 性能与 Clojure 表达力，或自定义执行环境（如 I/O 重定向、沙箱）。

• 执行代码：通过 runtime.ReadEval 运行 Clojure 代码字符串。
• 双向互调用：使用 glj.Var 与 SetRoot 将 Go 函数暴露给 Clojure；也可通过 Invoke 在 Go 中直接调用 Clojure 函数。
• 暴露自定义包：可通过生成“包映射”文件，将应用自身的 Go 包或额外标准库暴露给嵌入式 Clojure 代码使用。

Go 互操作（Interop）

Glojure 默认内置大量 Go 标准库，包括 bytes、context、fmt、io、math、net/http、os、strings、sync、time 等。为避免与 Clojure 命名空间符号的 / 冲突，Go 包名中的 / 会被替换为 :，例如 net:http.MethodGet。如需使用未内置的包，可使用 gen-import-interop 工具生成包映射的 .go 文件，并在主程序中导入该映射。

与 Clojure 的差异

数值类型遵循 Go 类型系统映射：

• long → int64，double → float64，float → float32，short → int16
• byte 对应 Go 的无符号字节（JVM 字节为有符号）
• int 位数依赖于平台（JVM 固定为 32 位）
• char → lang.Char（基于 Go 32 位 rune；JVM char 为 16 位）
• BigInt / BigDecimal / Ratio 分别包装 *big.Int / *big.Float / *big.Rat
• BigInteger 直接对应 Go 的 *big.Int

与其他 Go 版 Clojure 的比较

与 Joker 和 let-go 相比：

• 托管性：Glojure 是唯一真正的“托管”实现，实现了 Go 与 Clojure 的值互通；Joker 与 let-go 均不是。
• 互操作扩展：Glojure 支持可扩展的 Go 互操作，另外两者不支持。
• 并发：三者均支持并发，其中 Joker 依赖 GIL。
• 实现方式：Glojure 与 Joker 采用树步解释器（tree-walk interpreter），let-go 使用字节码解释器。
• 工具链：Joker 提供 Clojure 工具（如 linter），Glojure 暂未提供。

CADAM（Adam） 是由 YC W25 孵化的开源 AI CAD 工具，支持用户在浏览器中通过自然语言或图像直接生成参数化 3D 模型。无需安装本地软件，访问 adam.new/cadam 即可实时建模，并导出为 .STL、.SCAD 或 .DXF 文件。

核心功能与能力 CADAM 的核心是将文本描述或参考图片转化为可交互的 3D 模型，并通过 AI 自动提取可调参数。用户可通过滑块实时修改尺寸，系统仅更新参数而无需重新调用 AI 生成，大幅提升迭代效率。渲染端基于 Three.js 实现实时预览，内置 Geist 字体支持，并集成 BOSL、BOSL2 与 MCAD 等开源 CAD 库。

技术架构 项目采用现代全栈方案：前端基于 React 19 + TypeScript + TanStack Start + Vite；3D 渲染使用 Three.js 与 React Three Fiber；CAD 引擎为浏览器端 OpenSCAD WebAssembly；后端采用 TanStack Start 服务端路由配合 Supabase（PostgreSQL/Auth/Storage）。AI 模块默认调用 Anthropic Claude API，同时兼容 OpenAI、Google、OpenRouter 及 FAL 等服务商。界面样式由 Tailwind CSS 与 shadcn/ui 构建。

基准用例 官方基准展示了从复杂装配体到精密零件的生成能力。复杂机械包括带 22 维参数的 V8 发动机、9 缸星形航空发动机、高涵道比涡扇发动机及轴流涡轮叶片；基础参数化零件涵盖带真实螺纹的螺栓螺母、螺旋六边形花瓶、蜂窝轻量支架、NACA 2412 翼型、锥齿轮传动、离心泵叶轮及人字齿行星齿轮系。所有模型均输出为全参数化 OpenSCAD 源码，可直接用于工程调整或 3D 打印。

开发部署 CADAM 以 GPLv3 协议开源。本地开发需 Node.js ^20.19.0 或 >=22.12.0、Supabase CLI 及 ngrok（用于暴露本地回调地址）。环境配置包括前端 Supabase 连接密钥，以及后端多个 AI 服务 API 密钥、计费服务地址等。项目依赖 openscad-wasm 等上游开源实现。

一项由伦敦国王学院主导、发表于《剑桥法律杂志》的研究揭示了一个在专利体系之外运作的"隐藏"药物创新系统：医院和大学正在以远低于制药业成本的价格，大规模开展仿制药的重新定位（repurposing）研究，为社会提供可负担的治疗方案。

该系统最显著的特征是其极高的成本效益。研究显示，医院和大学开展的后期临床试验成本不到制药公司报告成本的10%。这主要因为公立医疗机构和学术机构能够以更少的资源完成同类研究。研究列举了多个实际应用案例，包括使用癌症药物治疗主要致盲原因、将乳腺癌治疗药物转化为预防用途，以及利用旧抗炎药治疗新冠。

文章指出，药物研发通常面临三大创新壁垒——专业知识、风险和资本。但对于仿制药重新定位而言，这些壁垒显著降低：由于药物本身已获批准且生产工艺成熟，所需技术门槛较低；研究者基于自身专业领域选择项目，并经资助机构与伦理委员会审批。同时，由于没有任何机构的财务存亡依赖于该药物的最终获批和销售额，因此风险也大幅降低。

研究进一步分析了驱动这一非专利体系创新的激励机制。与制药公司追求专利保护和市场独占利润不同，医院和大学里的临床医生与科学家主要受其他因素驱动：包括帮助患者更快康复的临床使命感，以及通过发表研究成果来推动自身学术生涯。这种动机差异构成了与商业制药体系并行的创新逻辑。

文章还描述了药物生命周期中重新定位兴趣的转移。在药物上市初期，制药公司通常积极推动重新定位，数据显示它们平均每年能获得约32项新适应症批准，从而拓展药物的市场营销范围。然而，一旦药物专利到期、仿制药进入市场，商业公司因面临价格竞争和无利可图而失去继续投入的兴趣。恰恰在这一节点，医院与大学的替代性研究系统迎来繁荣——它们利用廉价、可及性高的仿制药版本，继续探索新的治疗用途。

总之，这项研究揭示了一个由公立医疗与学术机构主导的、可持续的低成本药物创新途径。通过绕过专利体系并利用现有仿制药，该系统有潜力持续为社会提供经济上可承受的新疗法。

https://www.acma.gov.au/sms-sender-id-register

In a world racing to automate every interaction, the organisations that invest in genuine human connection are quietly building something no algorithm can copy.

美国租房者的“30%租金规则”为何已失效

“30%租金规则”（即住房支出不应超过总收入的30%）虽是数十年来个人理财的基本原则，但在当前经济环境下，由于住房、食品、燃油等生活成本增速持续跑赢平均工资，其适用性已大不如前。根据 Realtor.com 最新租金报告，美国50大都市区的租金中位数要价已达每月1,686美元，较疫情前高出248美元（涨幅17.2%）。

规则的起源与核心缺陷

该规则源自联邦住房可负担性指南，曾被用作衡量住房成本是否合理的基准，如今仍被房东和各类租金计算器广泛沿用。然而，其最大问题在于基于税前总收入（gross income），而非实际到账的税后收入。现代预算远比过去复杂，不能将其视为硬性指标。理财规划师 Linda Grizely 指出，有人即使 technically 符合30%规则，仍会因房租叠加其他财务压力而感到捉襟见肘。

总收入与实得收入的巨大落差

以美国约84,000美元的家庭收入中位数为例：若扣除10%的退休金供款，再扣除约25%的税款，以及年均约9,024美元（月均752美元）的医疗保险保费，实际到手收入约为每年47,676美元，即每月3,973美元。此时，按30%规则计算的2,100美元月租，实际已占净收入的约53%。

尽管从数据上看，该收入群体理论上能够负担50大都市区的租金中位数（1,686美元），且30%规则下的2,100美元预算甚至高于全国开间（1,422美元）、一居室（1,573美元）及两居室（1,885美元）的租金中位数，但一旦叠加其他债务与日常开销，剩余资金往往所剩无几。

忽视了个体财务状况差异

“一刀切”的规则未考虑个人财务全貌。例如，两个收入与租金相同的人：一个无债务、车贷已还清、享有优质雇主医保；另一个却背负学生贷款、育儿成本、信用卡债和不断上涨的保费。表面上两人都符合30%规则，但后者很可能陷入“房奴”困境，甚至依赖信用卡度日，进一步恶化财务状况。Grizely 表示，同样的收入和房租，两个人的实际生活处境可能天差地别。

更科学的评估方式

与其死守30%规则，不如回答一个更实际的问题：付完房租后，是否仍有足够资金覆盖日常开销、偿还债务、建立应急储蓄并进行未来投资？

若希望采用更现代的方法，许多专家推荐基于实得收入（take-home pay）的“50/30/20”预算法：将50%的税后收入用于“必需品”（房租、食品、交通等）、30%用于“想要”、20%用于储蓄与还债。在此框架下，只要整体“必需”支出控制在50%左右，房租占比超过30%也可能是可接受的，因为房租只是整体财务图景的一部分。

租房者不得不做出的现实权衡

由于严格遵守30%规则对许多人已不再现实，租房者正被迫做出各种妥协：与人合租、选择更小的公寓、搬离市中心，或搬回父母家中。SpareFoot 的一项调查显示，58%曾搬离父母的年轻人后来又搬回家住，其中四分之三将其视为明智的财务策略，而非人生倒退；住房成本是首要原因。

这并非年轻人才面临的困境。根据合租平台 SpareRoom 的数据，65岁及以上的老年人已成为美国增长最快的合租人群。租金上涨、通货膨胀、离婚与固定收入等因素，正迫使更多老年人在晚年与他人共担住房成本。

结论

30%规则可作为初步参考，但盲目遵守可能带来更大的财务压力。最终，租房决策应基于个人的实际净收入与整体财务状况，确保住房支出不会挤占其他必要生活领域。每一笔财务决定都会影响下一张账单，若房租支出超出承受能力，将不可避免地引发其他方面的经济拮据。

You'd think that given the same bytes of input you'd get the same bytes of output. lol. lmao. No, you don't. It's complicated.

Storied Colors: named colors with documented histories.

The firm's outgoing boss Tim Cook did not say when prices would rise or which products would be affected.

Viral prompt shows that ChatGPT’s content filters don’t work

European public institutions are betting big on digital sovereignty and open source software. And yet they recently moved their Bluesky accounts to W Social, a private, for profit network owned by Swedish entrepreneurs that has quietly gone closed-source.

https://www.cs.cornell.edu/courses/cs6120/2025fa/self-guided/

https://www.horg.com/horg/?page_id=921

Tools for writing interactive fiction, video game dialogues and branching narratives

With Wall Street’s help, you’re about to be forced to buy stock in SpaceX

https://rbelmont.mameworld.info/?p=1725