作者回顾了无密码身份验证的演变，并将现代通行密钥（Passkeys）与史蒂夫·吉布森（Steve Gibson）十多年前推出的 SQRL（安全、快速、可靠的登录）协议进行了对比。 早在 2013 年，作者就是 SQRL 的早期采用者，他意识到利用公钥加密技术取代共享密码是安全领域的未来。尽管作者和他在 Wirehive 的团队曾进行过实验性部署，但 SQRL 却难以实现主流化。其主要障碍在于协调性：它缺乏浏览器、操作系统和大型科技平台所需的广泛支持，难以推动行业变革。 如今，通行密钥在 SQRL 未能成功的地方取得了成功，这在很大程度上是因为苹果、谷歌和微软等行业巨头将该技术集成到了人们现有的工具中。虽然两者之间没有直接联系，但作者认为通行密钥是“成熟后的 SQRL”。归根结底，这篇文章是对那些往往先于其实际市场成功出现的远见卓识的致敬。它强调，虽然时机和平台集成是实现广泛采用的关键，但像吉布森这样的早期先驱者理应获得认可，因为他们在行业准备好实施之前就早已发现了解决方案。
每日HackerNews RSS
抱歉。
请启用 JavaScript 并关闭所有广告拦截器
抱歉。
### CHICKEN Scheme 6.0.0 版本摘要 CHICKEN Scheme 6.0.0 标志着一次重大的架构转型，重点在于实现完整的 **R7RS（小型语言）兼容性** 以及内部机制的现代化。 **主要变更：** * **核心兼容性：** 所有 R7RS 库模块现已整合至核心中。 * **编码与数据：** 系统内部全面使用 **UTF-8** 编码处理字符串。`(chicken blob)` 模块已被兼容 R7RS 的 `(chicken bytevector)` 字节向量操作所取代。 * **模块重组：** 许多原语已从 `(chicken base)` 移至标准的 `(scheme ...)` 模块中。若干旧版模块（如 `r4rs`、`srfi-*`）已被重命名或移除，以支持标准的 R7RS 等效模块。 * **FFI 与进程：** 外国函数接口（FFI）性能得到提升，现在可以直接传递字符串和符号而无需复制。进程管理经过全面重构；`process-*` 过程现在返回进程对象，而非进程 ID (PID)。 * **编译器与工具：** 新增的编译器选项（如 `-merge-reusable-closures` 等）提升了内存效率。构建系统现在依赖标准的 `configure` 脚本，Windows 支持已转向基于 POSIX 的工具链（例如 w64devkit）。 * **维护工作：** 进行了大量细微的 API 改进，包括更严格的符号打印、改进的路径处理，以及移除了已过时的旧版过程。
Chicken Scheme 6.0 的发布在 Lisp 社区中引发了广泛讨论。这一重大更新引入了对 R7RS 的全面支持、原生 UTF-8 字符串处理以及对外部函数接口（FFI）的改进，同时用 bytevector 替换了原有的 blob。
Chicken Scheme 是一个将 Scheme 源文件转换为 C 语言的编译器，允许开发者生成可移植的独立可执行文件。其名为“eggs”的生态系统，连同其生成小型、快速二进制文件以及提供实用堆栈跟踪的能力，常被视为其受欢迎的主要原因。6.0 版本还特别提到了对“Crunch”的支持，这是一个针对 Scheme 静态类型子集的编译器。
尽管爱好者们称赞 Chicken 具备“开箱即用”的体验、扎实的文档以及在生产软件中的实用性，但此次讨论也引发了关于 Scheme 生态系统长久以来的争议。一些用户对 Scheme 实现的碎片化表示不满，指出相较于 Common Lisp 更统一的库环境，对各种 SRFI（Scheme 实现请求）的依赖使得跨平台兼容性变得更加复杂。尽管存在这些顾虑，6.0 版本仍被广泛认为是该语言一个重要且期待已久的里程碑。
宏是 Common Lisp 的一项强大功能，允许程序员通过在编译时生成新代码来创建自定义抽象。与在运行时运行并处理数据的函数不同，宏在“宏展开阶段”发挥作用，在程序编译前直接操作源代码结构。 编写高效宏通常遵循三个步骤： 1. **建模**：写出一个宏调用的示例，以及你期望它生成的代码。 2. **实现**：使用反引号（backquote）语法创建一个 `defmacro` 作为展开模板，并利用解构参数列表来轻松解析输入。 3. **修复泄露**：确保宏不会“泄露”实现细节。这包括避免对同一表达式进行多次求值，并通过使用 `gensym`（生成唯一的、未驻留的符号）来防止变量名冲突。 归根结底，宏允许创建特定领域的语法，从而有效地扩展语言，使复杂模式的表达更加简洁。通过遵循“最小惊讶原则”，程序员可以构建健壮、可重用的抽象，使其行为可预测并能无缝集成到语言中。
抱歉。
一项“Effort”调查显示，五个受外国资助的非政府组织（包括 5Rights、数字仇恨打击中心（CCDH）和战略对话研究所（ISD））正协同开展一场旨在影响美国立法的行动。这些组织正积极在全美21个州和国会推动数字身份证及“儿童安全”法案，旨在复刻英国已实施的相关政策。
该报告强调，人们担心这些组织正在引入一套被英国政府用于监视和压制政治异见的监管模式。批评者认为，这些剥夺互联网匿名性并可能取缔VPN的框架，与威权政权的手段如出一辙。
调查记录了这些实体在遵守《外国代理人登记法》（FARA）方面存在的重大问题，包括未披露受外国领导层控制及游说活动的情况。值得注意的是，像ISD这样的组织已获得数百万美元的政府资助，用于监控和影响在线言论，常将政治异见与“虚假信息”混为一谈。报告最后警告称，通过采纳这些由外国设计的立法蓝图，美国正面临引入一套能够使政府主导的国内政治言论审查合法化并为其提供便利的基础设施的风险。
对不起。
排列#1FX★R'2D3D15001k5k排列#1FX★R'2D3D15001k5k超翻转棋盘格11.1×10¹⁹2.2×10¹⁹3.2×10¹⁹4.3×10¹⁹
这篇 Hacker News 帖子讨论了用户“Alen123”的一个项目，该项目允许用户滚动浏览魔方所有 43,252,003,274,489,856,000（约 43 百京）种可能的状态。
讨论很快延伸至几个不同的方向：
* **技术与哲学辩论：** 用户们就数字资产和 NFT 的“内在价值”本质展开了争论，一些人将庞大的魔方状态数与国际象棋或大规模数据排列等其他复杂系统进行了比较。
* **游戏与博彩：** 一位用户分享了关于设计一款基于魔方的赌场游戏的轶事，引发了关于技能型博彩、赌场优势以及“无法获胜”游戏的道德问题的讨论。
* **幽默的离题：** 评论区充斥着关于该数字庞大规模的笑话，用户们讽刺地提议将其作为一种“财富”指标、潜在的密码生成器或是一种“末日滚动”练习。
* **魔方文化：** 其他人则讨论了复原魔方的难度、背诵公式与编程中算法思维的区别，以及与该玩具相关的个人回忆。
总而言之，这篇帖子就像一个病毒式的“数字游乐场”，既突显了数学大数字令人敬畏的一面，也展现了科技社区异想天开的一面。
马克·吐温对佩奇排字机（一种极其复杂的排版机器）的痴迷，是创新史上一个引以为戒的故事。出于对一种能够模拟人类认知的设备的憧憬，吐温将自己的财富倾注在詹姆斯·W·佩奇的发明上，坚信它将彻底改变印刷业。
最终，这台机器失败了。尽管它拥有超过 18,000 个零件，但由于过于脆弱且成本高昂，无法与莱诺铸排机（Linotype）竞争。莱诺铸排机的成功在于重新设计了印刷流程，而非仅仅模仿人类劳动。这个项目导致了吐温的破产，也成为现代人工智能所面临挑战的历史先兆。
这个故事为技术发展提供了三条持久的教训：
1. **基于现实进行设计：** 技术必须具备可维修性和稳健性，而不仅仅是理论上的完美。
2. **普及需要时间：** 创新者往往高估了社会接纳复杂、颠覆性工具的速度。
3. **重新设计，而非简单复制：** 真正具有变革性的发明是重新思考任务的本质，而非仅仅将现有的相关人类动作自动化。
尽管吐温失去了财富，但他具有远见卓识，意识到自动化终将重新定义人类劳动与交流的未来。
这篇文章探讨了马克·吐温的经济破产，原因是他沉迷于投资佩奇排字机（Paige Compositor）——一台旨在实现排字自动化的复杂机器。尽管这一“机械奇迹”的失败是一次重大挫折，但评论者认为，马克·吐温一生中真正的毁灭性打击来自个人悲剧的累积，包括他的女儿苏西和妻子的相继离世。
讨论强调了关于技术发展的核心教训：
* **工程与复杂性：** 莱诺铸排机（Linotype）通过工业创新简化了印刷流程从而获得成功，而佩奇排字机则因过度设计及试图完美模拟人类手工劳动而失败。
* **创新神话：** 印刷机及类似发明的历史表明，成功往往并非源于单一的“顿悟”时刻，而是源于对无数细节的精益求精。
* **现代启示：** 评论者将此与当今的人工智能热潮进行对比，指出历史往往有惊人的“相似之处”——投资者经常押注于复杂且被过度吹捧的技术，却忽视了切实可行且节省劳力的解决方案。最终，该讨论强调了“现实扭曲”的危险性，以及在任何投资中把握时机、追求简洁和风险分散的重要性。
GPT 5.6 网络 GPT 5.6 Cyber
82 天前
请启用 JavaScript 和 Cookie 以继续。
围绕 OpenAI 新推出的“GPT 5.6 Cyber”模型的讨论，凸显了科技界对于现代人工智能护栏限制性日益增强的不满。用户愈发反感“思想授权”现象，即获取高级功能（尤其是网络安全领域）的权限被繁琐的验证流程或“可信访问”计划所阻碍。
此次辩论的要点包括：
* **家长式作风与安全：** 许多用户认为这些护栏只是流于形式，往往阻碍了正常的合法工作（如调试或安全研究），却又容易被绕过，从而导致用户感到厌烦并降低了工作效率。
* **替代方案的兴起：** 对 OpenAI 限制性模型的不满，助推了人们对开源权重模型及竞争对手（如 Kimi K3 或通义千问 Qwen）的关注，这些模型为开发者和安全研究人员提供了更少的门槛和更大的自主权。
* **职业影响：** 讨论触及了软件工程的未来，一些人担心过度的监管或对专有、受限 AI 的依赖，会贬低人类的技能，或在行业内滋生“寻租”行为。
归根结底，社区将这些限制视为一把双刃剑：它们本可能是保障安全的工具，但在实践中，却存在权力过度集中并疏远其本应辅助的工程师群体的风险。
这篇文章质疑了那种被广泛引用的观点，即认为动态、简洁的编程语言比静态语言在大型语言模型（LLM）中具有更高的 Token 效率或更强的适用性。 作者通过实验基准测试（如实现 `zstd` 解码器和 Pandoc 程序）表明，当任务从简单转向复杂时，归因于语言类型（例如动态与静态，或 J 语言等“密集型”语言与其他语言）的性能差距往往会消失。虽然一些动态语言在简单任务上表现出轻微的效率优势，但这些优势无法推广到更复杂、更现实的工作负载中，在后者中，模型微调和语言流行度等因素起着更大的作用。 作者强调，大多数公开的 LLM 编程基准测试存在缺陷，往往受困于“奖励操纵”、琐碎的问题集或特定的测试环境错误。研究结果表明，编程语言的选择并没有人们声称的那么重要；相比于静态或动态的分类，语言的流行度与模型表现的相关性更强。最终，作者得出结论：在 LLM 背景下对编程语言下普遍性结论还为时过早，因为当前的评估对任务细节和测试框架本身的局限性高度敏感，而非取决于语言的内在特性。
这篇 Hacker News 帖子讨论了哪种编程语言最适合编码代理。虽然原文试图根据 Token 效率和代码正确性对语言进行排名，但评论指出这些结果往往存在噪音且缺乏定论。
**讨论的核心观点包括：**
* **工具链与语言：** 许多人认为，语言的生态系统——特别是其标准库、静态分析工具和类型系统——比原始语法更重要。更强大的工具链减少了 LLM “猜测”或生成模板代码的需求，从而提高了可靠性。
* **代码库的“调性”：** 一些开发者偏好 Go 或 Rust，因为它们严格、主观或类型安全的特性会迫使 LLM 生成更规范的代码。相反，Python 等动态语言虽因其庞大的生态系统和训练数据集而受到赞誉，但也有人认为由于训练数据中编码标准不统一，这类语言更容易产生“垃圾代码”。
* **智能体现状：** 实际生产力往往取决于智能体使用工具（如编译器、代码检查器和搜索）来验证其工作的能力，而非仅仅是一次性生成代码。
* **“最佳”选择：** 目前尚无共识；“最佳”语言通常仍然是人类开发者最熟悉、足以进行代码审查和维护的那一种。
World Train Map（前身为 TrainRouter）是一个综合性的互动数字地图集，涵盖了全球 120 个国家的 1,247 条著名客运铁路线路。该项目并非行程规划工具，而是一个庞大的数据库，为每条线路提供详细信息，包括距离、时长、最高时速、运营商及车辆型号。 该平台提供基于 OpenStreetMap 数据的高精度全屏地图，利用线路关系确保与现实轨道精准对应。用户可以探索多种类别，如高速列车、观光列车、豪华列车、夜间列车以及遗产铁路。网站还提供对比数据，包括火车与飞机的碳排放对比、城市间交通指南，以及按速度、海拔和长度排列的排名。 秉持透明和开放的理念，该项目可免费使用，并提供开放数据集（CSV、JSON、GeoJSON）及公开的修正记录。尽管品牌名称已从“TrainRouter”更名为“World Train Map”，以更准确地体现其地图集的功能，但所有现有链接均保持有效。该项目持续优化地图精度，不断更新数据，旨在提供全球铁路基础设施的精确视图。
抱歉。