Mu 是一个开源（AGPL-3.0）平台，通过单一 MCP 端点为智能体（Agent）提供了一套包含 67 种“真实世界”工具的完整工具集，涵盖网页搜索、邮件（SMTP）、存储、日历和市场等功能。与简单的 API 封装不同，Mu 是一个自包含的运行环境，拥有自己的 Web 界面、命令行工具（CLI）和智能体核心。 主要功能包括： * **统一访问：** 通过 MCP 为 Claude 或 Cursor、CLI 以及 Web SDK 提供工具支持。添加新工具会自动同步更新所有界面。 * **自托管或托管：** 以单个 Go 二进制文件形式提供，支持自托管，也可直接使用 `micro.mu` 服务。 * **智能体集成：** 支持主流大语言模型（Claude、OpenAI、Ollama），并内置记忆和状态管理功能。 * **可扩展性：** 操作员可以通过 JSON 轻松自定义信息流、提示词和频道，或使用 Go 开发新服务。 * **运营控制：** 内置身份验证、付费工具的积分计费系统，以及用于管理第三方密钥的管理员控制功能。 Mu 通过基于注册表的集中式架构取代了碎片化的工具集成方式，实现了智能体、人类与互联网之间的无缝交互。
每日HackerNews RSS
抱歉。
本摘要探讨了计算的基础及其在理解人类心智中的作用。这一研究的核心是**图灵机**，它是一个抽象模型，将算法定义为一组机械的符号操作指令。该模型改变了数学，并成为计算机科学与人工智能的基石。 在认知科学中，**经典心智计算理论（CCTM）**认为心智本质上就是一个计算系统。这一观点常与**心智表征理论（RTM）**相结合，暗示思维是通过一种“思维语言”（心语）进行的。尽管经典计算主义侧重于基于规则的符号操作，但它面临着来自**联结主义**（通过神经网络模拟心智）和**计算神经科学**（强调生物真实性）的挑战。 关于心理状态是由功能组织（功能主义）、物理大脑状态还是外部环境关系（外在论）所定义的，哲学界仍存在争议。对 CCTM 的主要批评包括其可能无法模拟非算法的创造性思维、时间动态的作用，以及认知在多大程度上是具身的。尽管存在这些争议，计算模型仍然是探索物理系统（无论是硅基还是生物系统）如何产生智能的主导框架。
对不起。
**Shitty** 是一款采用 C++23 编写的高性能、内存不安全（memory-unsafe）终端模拟器，旨在实现低延迟、快速启动以及可预测的资源占用。它是对 *Zutty* 的硬分叉及彻底重写，利用原生 GPU 计算后端（Linux 下的 Vulkan 和 macOS 下的 Metal）实现了业界领先的渲染速度，在可打印 ASCII 字符和最差情况下的随机字节基准测试中，其性能表现均优于 Alacritty、Kitty 和 Ghostty 等竞品。
主要特性包括：
* **性能：** 通过基于变更的渲染（damage-driven rendering）和持久化 GPU 字形缓存进行了优化。
* **兼容性：** 支持 VT52/VT5xx 控制序列、Unicode、多种鼠标协议（SGR、urxvt）以及现代键盘协议（Kitty、modifyOtherKeys）。
* **灵活性：** 提供强大的配置选项，涵盖字体路径、窗口几何形状以及剪贴板集成（包括 OSC 52）。
* **开发：** 使用 Clang 构建，摒弃了通用的窗口工具包，采用了自定义的事件循环层。提供完善的测试套件，并集成了 Nix 以实现便捷部署。
尽管目前正从 GPLv3 协议向 MIT 协议的代码库过渡，Shitty 始终将速度和技术效率置于广泛的协议支持之上（例如省略了 sixel 或双向文本支持）。它是一款专为追求极致原始终端吞吐量的用户打造的专业工具。
“Shitty”是一款新的终端模拟器，因其高性能、极具挑衅性的命名以及开发过程在 Hacker News 上引发了广泛讨论。
**核心要点：**
* **性能表现：** 开发者声称，得益于高效的渲染模型和基于 Ragel 的状态机解析器，“Shitty”在吞吐量方面优于 Ghostty、Alacritty 和 Kitty 等现有终端。
* **争议性开发：** 该项目主要由人工智能生成。开发者正致力于将代码库从基于 GPL 的基准转为 MIT 许可证，以便于库的使用。这种做法在许可证伦理以及 C++ 实现中“内存不安全”的问题上引发了批评。
* **社区反应：** 社区观点两极分化。支持者称赞其技术野心和幽默的命名（双关了终端命名中常见的“tty”后缀）；而批评者则认为该名称不够专业，可能会阻碍其在企业环境中的应用。
* **实用性之争：** 讨论中的一个反复出现的主题是：终端速度是否仍然是一个有意义的指标。尽管一些用户痴迷于延迟和吞吐量，但许多人认为现代终端已经足够快了，对于日常工作流程而言，启动速度和功能特性比原始渲染速度更为重要。
参赛者声明 参赛者必须同意遵守俄亥俄州展览委员会制定的指导方针和规则。若我获奖，我确认必须提交我的艺术作品原件，以供在俄亥俄州博览会上展出。我确认俄亥俄州博览会保留该艺术作品的所有权利。 总冠军条款与细则 获奖后，入选艺术家须与俄亥俄州展览委员会签署一份规定条款与细则的协议。艺术家将保留版权，但最终入选作品的所有权将转移给俄亥俄州展览委员会。俄亥俄州展览委员会保留以各种形式复制该艺术作品进行销售的权利，包括但不限于明信片及其他商品。该艺术作品也可用于俄亥俄州博览会的营销和宣传资料。
俄亥俄州博览会近期将海报设计比赛的第一名颁发给了一张人工智能生成的图片，这一决定在 Hacker News 上引发了激烈争议。批评者认为，该图片是典型的“AI 垃圾”，并指出其中明显的错误（如畸形的动物和毫无逻辑的背景细节）作为其质量低劣的证据。
许多参与者不仅对 AI 的使用表示不满，还对评委表现出的品味匮乏感到沮丧。评论者指出，获奖作品那种混乱且高密度的构图，似乎被误认为是“努力”和“技巧”的体现。这引发了更广泛的讨论，涉及人类艺术价值的贬低、业余比赛中 AI 的伦理问题，以及大众无法或不愿分辨 AI 生成内容与人类创作之间的区别。
针对上述反弹，博览会宣布将重新评估 2027 年的比赛规则，明确禁止提交 AI 生成的作品。尽管有人将此与历史上抵制 Photoshop 等工具的行为相提并论，但许多人仍坚持认为，此类比赛应优先考量人类的表达和切实的技能，而非生成式模型的便捷。
拒绝访问 您没有权限访问此服务器上的 "http://www.nbcsandiego.com/nbc-7-responds-2/californians-data-deletion-requests-drop-become-enforceable-aug-1/4054771/"。 引用编号 #18.469e3617.1785711942.3a6b457c https://errors.edgesuite.net/18.469e3617.1785711942.3a6b457c
加利福尼亚州新的《数据删除可选提供法案》（DROP）将于 8 月 1 日生效。该法案允许居民提交一份具有法律约束力的单一申请，要求注册数据代理商删除其个人信息。该法律实施了严格的合规要求，包括一项“追溯性”条款，以确保即便数据此前已被出售或共享也能被删除；以及一项“前瞻性”要求，旨在防止数据重新进入代理商的系统。
Hacker News 上的讨论既强调了该法律在遏制“监控资本主义”方面的潜力，也表达了对其现实执行情况的怀疑。批评者指出“请求”一词听起来较为被动，而支持者则强调，违规行为将面临每天 200 美元的经济处罚。一些用户分享了因注册服务（如用于应用开发的 D&B）而导致垃圾信息泛滥的担忧，另一些用户则质疑该法律是否能有效针对大型科技实体，或者金融及信用报告领域是否存在漏洞。讨论帖还涉及了平台数据治理的复杂性，包括关于网站是否应允许用户清除其全部历史评论记录的激烈争论。
本项目探索了现代机器学习的极限，通过在 80 年代的 BBC Micro（搭载 8 位 MOS 6502 处理器）上运行自回归语言模型来验证其可能性。
主要的工程限制包括 32KB 的内存限制以及处理器缺乏原生乘法指令。为克服这些障碍，作者采取了以下方案：
* **使用 BitNet：** 采用一种量化方法，将权重存储在 $\{-1, 0, 1\}$ 的三进制集合中。这使得原本高昂的乘法运算被简单的加减法取代，并实现了每字节存储四个参数。
* **选择 Mamba (SSM)：** 与因 KV 缓存内存占用不断增长而受限的 Transformer 不同，Mamba 的递归架构保持了固定的状态大小，使其成为内存受限硬件的理想选择。
* **定制化推理：** 使用通过 CC65 编译的 C 语言引擎，并为激活函数采用了学习到的缩放偏移量，以及为采样采用了预计算查找表，因为 6502 无法计算指数运算。
最终，一个功能完备的微型 Mamba 模型得以诞生，展示了“机器共情”（mechanical sympathy）——即神经网络架构设计必须与底层硬件限制相匹配的必要性。你可以在基于 Web 的 BBC Micro 模拟器中直接运行该模型，体验在 1975 年代的硬件上生成文本的过程。
抱歉。
TinyNES 是一款小众的开源主机，它在复古硬件与现代可靠性之间架起了一座桥梁。与普通的 NES 克隆机不同，它使用了从旧硬件上拆卸下来的原装（或兼容）CPU 和 PPU 芯片，为那些比起 FPGA 或软件模拟更青睐真实芯片的纯粹主义者提供了原汁原味的体验。 该主机采用了插槽式芯片设计，易于维护，并能比老化的原版主机提供更纯净的音视频输出。然而，它严格保留了仅支持复合视频输出的特性，没有原生 HDMI 接口，忠实于原始硬件的局限性。虽然该主机在设计上支持罕见的 RGB PPU 芯片——且未来计划推出免焊接升级模块——但当前版本专注于为收藏者提供“真实”的 NES 体验。 归根结底，TinyNES 服务于复古游戏社区中的一个特定群体，他们认为现有的解决方案（如模拟器或 FPGA 克隆机）缺乏真实感。它的存在证明了即便在竞争激烈的市场中，人们对于能够保留 8 位时代原始特质与手感的高质量硬件级机器，依然有着执着的追求。
这篇 Hacker News 帖子讨论了“TinyNES”这一小众游戏主机项目，以及复古游戏领域的普遍趋势。
讨论始于一位用户对订单交付的担忧，项目创作者随后做出直接回应，确认新一批产品即将发货，并预告了一款即将推出的无焊式 RGB 升级板。
话题迅速转向复古游戏硬件的现状。用户们就原装硬件与现代改装及模拟器之间的优劣展开了辩论。一些收藏家更看重“原汁原味”的体验，他们常使用烧录卡、RAD2X 等 HDMI 转接器或 RGB 改装方案，以弥合老式主机与现代显示器之间的差距；而另一些人则认为，现代模拟技术与真实硬件已别无二致，且更加便捷。
讨论中还涉及了关于 NES 视频输出的技术细节，参与者澄清了原版 NES 主机并不具备原生 RGB 输出功能，通常需要像 NESRGB 板这样的改装才能实现。归根结底，这篇帖子凸显了该社区的一个反复出现的主题：使用原装硬件时的“繁琐”与追求便捷、高质量“即开即玩”的复古游戏体验之间的矛盾。
MicroCodex 是一款基于 C++23 构建的超轻量级编码代理，专为在终端本地运行而设计。它功能丰富，包括交互式终端界面、一次性提示（one-shot prompting）、持久化对话历史记录以及自动上下文压缩。
用户可通过简单的 curl 脚本在 macOS 和 Linux 上安装该工具，或从 GitHub 下载预编译的二进制文件。身份验证通过 OAuth 处理，允许用户直接通过 CLI 使用现有的 ChatGPT 方案。
MicroCodex 支持自定义文件系统“技能”以扩展其功能，并通过词法黑名单针对破坏性命令提供了基本的防护措施。但它并非沙箱环境；由于该工具的操作权限与底层进程相同，用户在使用时仍需谨慎。尽管目前暂不支持 MCP 和文本复制功能，但该项目已在 Apache-2.0 许可证下开源。它旨在为那些偏好高性能、终端原生环境来管理编码任务的开发者提供支持。
Paolo Anziano 近期推出了“MicroCodex”，这是一个使用 C++ 实现的 OpenAI/Codex 风格编程代理，其二进制文件大小不到 1MB。该项目旨在为资源受限的环境（例如嵌入式设备或大型主流工具无法运行的多代理工作流）提供一种轻量级的替代方案。
此次发布在 Hacker News 上引发了关于二进制体积小型化必要性的讨论。尽管一些持怀疑态度的人认为，与功能成熟的主流工具相比，极简体积在实际应用中并无太大优势，但开发者强调，该代理在工具使用和上下文管理等关键领域几乎达到了与主流工具相当的水平。
讨论还涉及了代码库规模与可维护性之间的权衡。批评者指出，较小的代码库并不一定更容易管理，并质疑将一个快速迭代的 JavaScript 工具移植为 C++ 版本后的长期维护难度；而支持者则看好在极简硬件上运行自主编程代理的潜力。开发者计划通过自动化更新提示来保持功能同步，并邀请社区贡献诸如 MCP 支持等缺失的功能。
403 禁止访问
这场讨论探讨了“将艺术与艺术家剥离”这一经典争议，其起因是对帕特里克·奥布莱恩（Patrick O’Brian）《奥布雷与马图林》（*Aubrey-Maturin*）系列的评论。
读者们对这些小说怀有深切的钦佩，称赞其丰富的历史细节、精湛的文笔，以及对领导力和友谊的深刻探讨。许多人认为该系列令人受益匪浅，甚至有人指出杰克·奥布雷（Jack Aubrey）的管理风格为项目领导力提供了实践经验。
然而，当发现奥布莱恩坎坷的个人生活（包括他与家人的疏远以及使用化名）时，一些读者的热情受到打击，他们认为作者的品行与其作品是密不可分的。这场讨论凸显了两种对立观点：
* **“剥离”阵营：** 认为奥布莱恩早已去世，其个人缺陷并不会“毒害”叙事，作品本身价值独立。他们认为道德把关是表演性的，或是幼稚的表现。
* **“问责”阵营：** 主张了解作者的背景对于理解作品的潜台词是必要的，且每个人都有权基于个人道德准则来选择关注和消费的对象。
最终，参与者们难以找到一个普遍适用的准则，往往得出的结论是：每一位读者都必须亲自决定底线所在。
作者通过创建一种树重写转换，探索了在 TypeScript 编译器中加入 Go 风格 `defer` 语句的可能性。通过解析 `defer` 并将其转译为执行闭包栈的 `try...finally` 块，该实现成功模拟了 Go 语言“后进先出”（LIFO）的清理行为以及立即求值的参数传递机制。 然而，作者最终认为 `defer` 并不适合 TypeScript。在 Go 中，`defer` 的优雅源于其将错误视为返回值的处理方式；而在 TypeScript 中，异常和异步控制流使得清理工作变得极为复杂。特别是处理清理过程中可能出现的多个错误时，需要使用繁琐的 `AggregateError` 逻辑，这与 JavaScript 标准的错误处理方式并不协调。 相反，作者主张采用 ECMAScript 的“显式资源管理”（Explicit Resource Management）提案。尽管它并不完美——作者不喜欢必须显式声明变量（如 `using _ = ...`）——但相比于通过修改编译器强行引入 `defer`，它提供了一种更符合惯用方式且原生的资源清理方案。
对不起。