2024 06 30 HackerNews

2024-06-30 Hacker News Top Stories #

Imhex是一款功能丰富、高度可定制的十六进制编辑器，专为逆向工程师和程序员设计，支持数据格式解析、可视化编辑及多种高级工具。

作者分享了给15年前自己的编程建议，包括修复系统错误、权衡代码质量与开发速度、提高工作效率等，以助于快速成长为优秀程序员。

Marc Andreessen回忆了Web浏览器Mosaic和Netscape的起源，涉及商业机会和风险投资，定义了Web浏览器的重要性。

文章详细分析了Factorio游戏中Lua实现的安全漏洞，恶意服务器可利用该漏洞在客户端执行任意代码。

博文讨论了浪费带宽、电池电量并惹恼系统管理员的方法，特别指出了Firefox for iOS的网络浏览器问题。

探讨了DevOps运动的兴起和衰落，指出DevOps理念已成为组织第二天性，但与最初意图存在差距。

Eclipse Foundation的Theia IDE项目正式推出，挑战微软的Visual Studio Code编辑器。

介绍了新型AEAD算法XAES-256-GCM，设计用于高级API和FIPS 140合规性，易于使用且避免重复nonce问题。

苏黎世联邦理工学院研究人员开发了可能最快的流算法，理论上可计算任何网络的最大运输流量。

文章讨论了网络内容是否属于免费软件的问题，指出公开网络内容常被视为公共资源。

Imhex: A hex editor for reverse engineers #

https://github.com/WerWolv/ImHex

ImHex 是一款面向逆向工程师、程序员以及那些在凌晨 3 点还珍惜视网膜的人的十六进制编辑器。该编辑器提供丰富的功能，包括：

特性丰富的十六进制视图
自定义类似 C++ 的模式语言，用于解析和突出显示文件内容
主题支持
数据导入和导出
数据检查器
基于节点的数据预处理器
从多种不同数据源加载数据
数据搜索
数据哈希支持
差异支持
集成的反汇编器
书签
特性丰富的数据分析器和可视化工具
YARA 规则支持
有用的工具
内置内容更新程序
现代界面
易于上手
模式语言

模式语言是为 ImHex 开发的完全自定义编程语言，允许您以类似 C 的语法定义结构和数据类型，然后用于解析和突出显示文件内容。此外，ImHex 还提供了数据库，用于格式模式、库、魔术和常量文件，用户可以在 ImHex-Patterns 存储库中查找和贡献文件。

安装 ImHex 需要满足以下最低系统要求：

操作系统：Windows 7 或更高、macOS 12.1 或更高、现代 Linux 发行版
CPU：x86_64（64 位）
GPU：OpenGL 3.0 或更高
RAM：256MB（更复杂的分析可能需要更多）
存储：100MB

ImHex 的编译需要 GCC（或 Clang）版本支持 C++23 或更高。许多依赖项已捆绑到存储库中，其他未捆绑的依赖项可以使用/dist 文件夹中的依赖项安装程序脚本进行安装。

对于插件开发，可以使用提供的模板项目开始开发插件。ImHex 还感谢许多贡献者和依赖项，如 Dear ImGui、ImPlot、ImNodes 等。ImHex 的大部分内容采用 GPLv2 许可，但某些部分采用 LGPLv2.1 许可，以允许为 ImHex 开发专有插件。

总体而言，ImHex 是一款功能强大的十六进制编辑器，为用户提供了丰富的功能和灵活的定制选项，适用于各种逆向工程和编程任务。

HN 评论 87 comments | 作者：wsc981 | 16 hours ago #

https://news.ycombinator.com/item?id=40828493

ImHex 是目前我用过的最好的十六进制编辑器，因为它具有文件模板、多种数据类型解释和速度快等优点。
010 Editor 也具备这些功能，但不需要花费 150 美元，而且是开源软件。
010 Editor 拥有更多预制模板，与 ImHex 的主要区别在于布局和美学。
ImHex 的模式语言很棒，对学习有很大帮助，被称赞为优秀的程序。
ImHex 可以通过设置下载附加资产，解释数据以各种格式编码，但似乎没有 CP437。
HxD 在 Windows 上被认为是最好的十六进制编辑器，但在 macOS 上没有真正的对手。
Hex Fiend 的模板格式易于扩展，用于分析许多不同的文件格式。
HxD 能够正确处理大量数据，而且可以打开整个块设备或整个系统 RAM。

A bunch of programming advice I’d give to myself 15 years ago #

https://mbuffett.com/posts/programming-advice-younger-self/

这篇博文是关于一位程序员分享给自己 15 年前的建议。作者提到了一些编程方面的经验教训，其中包括：

修复易出错的系统：作者分享了一个例子，团队中的系统容易出错，但没有人考虑如何让出错变得更难，作者花了十分钟时间更新了订阅层，使其在主线程上调用订阅者，从而消除了一类崩溃。
权衡质量和速度：作者强调了在实现速度和正确性之间的权衡，根据不同情境评估发布错误的影响，以确定适当的工作方式。
提高效率：作者建议花时间熟悉编辑器的快捷键、操作系统、命令行等工具，以提高工作效率。
解决深层次的错误：作者提倡解决错误时要深入一层，而不是仅仅修复表面问题，以建立对系统的深刻理解。
重视历史调查：作者分享了通过查看代码历史来解决问题的重要性，以及如何利用 git bisect 等工具进行故障排查。
编写糟糕的代码：作者提到，编写完美的代码不会给予反馈，而编写糟糕的代码会让你学到更多，因此需要在速度和质量之间取得平衡。
简化调试：作者分享了一些简化调试过程的技巧，如跟踪请求、限制并行性、打印程序状态等。
团队合作：作者建议在团队合作中，应该学会向更有经验的同事请教问题，以提高工作效率。
快速交付：作者指出交付速度很重要，需要建立一个不易出错的系统、快速的团队协作、一致的可重用模式等。

总的来说，这篇博文提供了一些建议，旨在帮助读者更快地成为一名优秀的程序员。

HN 评论 220 comments | 作者：marcusbuffett | 12 hours ago #

https://news.ycombinator.com/item?id=40829607

你不是你的工作，不要把工作当成个人事务。如果公司的人写糟糕的代码，你可以选择离开。
不要把公司的代码问题当面公开批评，可以选择离开。不要与无能的人浪费时间。
IT 工作市场不断变化，灵活性很重要。
如果公司的代码问题无法解决，可以选择离开。
市场对有技能和经验的开发者需求依然很高。
营销自己比以往更重要，AI 的出现增加了招聘过程中的噪音。
尝试升级问题，如果没有改变，再考虑离开。
了解编辑器的快捷键，快速打字，熟悉操作系统和终端，有效使用浏览器开发工具。
不要过度追求完美，写出能运行的代码，然后逐步改进。
了解其他语言和生态系统，扩展技能。
选择团队比选择技术更重要，找到能提升你的团队。
读代码和写代码结合学习，实践是最好的老师。

The story, as best I can remember, of the origin of Mosaic and Netscape [video] #

https://pmarca.substack.com/p/the-true-story-as-best-i-can-remember

这篇文章是由 Marc Andreessen 撰写的，题为《The true story – as best I can remember – of the origin of Mosaic and Netscape》。文章讲述了关于 Mosaic 和 Netscape 起源的真实故事。文章中提到了关于 Web 浏览器的发明和起源，其中 Marc 是其中一位共同发明者。

文章指出这个故事从未被完整或准确地讲述过，因此这次有机会进行详细叙述。Web 浏览器是大多数人体验互联网的方式，也可以说是互联网的窗口。文章中还提到了一些关于商业机会和风险投资的对话，以及对 Web 浏览器的定义和重要性。

HN 评论 120 comments | 作者：kjhughes | 1 day ago #

https://news.ycombinator.com/item?id=40825033

评论中提到视频播放器效果不佳，提供了 YouTube 链接。
有人指出关于 Spyglass/Microsoft 情况的细节不太准确，但确认 Spyglass Mosaic 是从头开始编写的。
有人回忆起早期 Netscape 团队，认为 Spyglass 比他们酷多了。
有人回忆起读过 Eric 的“Browser Wars”网络博客，引发了对 Microsoft 与 Spyglass 的讨论。
有人分享了关于早期网页浏览器的回忆，提到了使用 Lynx 等工具。
有人提到 Netscape 的创始故事，以及对 Mozilla 的看法。
有人分享了对 Netscape 的恐惧，因为图标中有船轮，选择使用 Internet Explorer。
有人回忆起早期使用计算机的经历，从 300 baud acoustic couplers 到 14.4K 调制解调器和 BBS，以及 Web 的发展。
有人评论视频内容，认为提问方式有些讨好，但仍然享受了视频。

Bytecode Breakdown: Unraveling Factorio’s Lua Security Flaws #

https://memorycorruption.net/posts/rce-lua-factorio/

这篇文章详细介绍了作者如何利用 Factorio 游戏中 Lua 实现的漏洞，使恶意服务器能够在客户端上执行任意代码。文章首先介绍了 Factorio 游戏及 Lua 在其中的应用，然后详细解释了如何利用 Lua 的弱点来实现攻击。

作者指出 Factorio 游戏中的 Lua 解释器暴露在网络中，使得攻击者可以利用这一点进行更多有趣的攻击。文章还介绍了 Lua 字节码的工作原理，以及 Lua 字节码验证器的问题。

作者展示了如何利用类型混淆漏洞来泄露地址，并最终创建了假对象，从而实现对内存的读写操作。文章最后指出，通过这种方式，攻击者可以利用 Lua 的各种功能来实现更多复杂的攻击，包括读取数据、写入数据以及控制指令指针等。

HN 评论 80 comments | 作者：memcorruption | 11 hours ago #

https://news.ycombinator.com/item?id=40830005

Lua 解释字节码时未检查参数意义，执行无效参数字节码，计划静态分析字节码，对简单情况有效。
Lua 开发者建议只接受源码，禁用直接加载字节码，保留可信字节码加载选项。
实现安全的字节码解释器不简单，需权衡简化实现和安全性。
Factorio 禁用字节码加载，修复安全问题。
验证程序极其困难，易遗漏，尤其对于类似 Lua 的复杂字节码语言。
Factorio 禁用调试库，修复安全漏洞。
加载原始字节码不安全，可使用预处理器生成 Lua 代码代替。
Factorio 禁用字节码加载，修复安全问题。
Lua 字节码应仅用于资源受限的嵌入式系统，避免安全漏洞和闭源程序。
JIT 和字节码同属一类，可能不可靠，建议禁用高风险系统的 JIT。
Lua 字节码应仅用于资源受限的嵌入式系统，避免安全漏洞和闭源程序。
JIT 自 Spectre 和 Meltdown 后不安全。
宿主环境允许用户提供字节码，可能导致安全漏洞，需设计可验证字节码环境。
JVM 字节码设计可验证，避免内部循环检查操作数类型。
Factorio 漏洞不影响未修改的单人游戏，已修复。

How to waste bandwidth, battery power, and annoy sysadmins #

https://rachelbythebay.com/w/2024/06/28/fxios/

这篇博文讨论了如何浪费带宽、电池电量并惹恼系统管理员。作者提到了一些关于完全破损的网络浏览器的问题，特别是针对 Firefox for iOS 的情况。

文章列举了一系列请求相同链接的示例，其中包括请求 feed、css 和 favicon 等资源。作者指出了请求 favicon.ico 时的问题，以及 Firefox for iOS 在访问网站时可能导致请求滥用的情况。

总的来说，文章强调了一些浏览器行为可能导致资源浪费和对服务器造成负担的问题，提醒读者注意避免这些情况。

HN 评论 132 comments | 作者：zoidb | 18 hours ago #

https://news.ycombinator.com/item?id=40828203

Firefox 在 iOS 上使用 WebKit 渲染引擎，但仍有其他网络层和脚本注入等功能。
iOS 允许第三方浏览器引擎，欧盟 iOS 17.4 版本开始。
Firefox 决定在 Android 上运行 uBlock Origin，提供出色的广告拦截功能。
Brave 浏览器基于 Chromium，有类似的反隐私/广告技术。
uBlock Origin 在广告拦截方面有巨大优势。
Firefox 在 Android 上运行良好，对一些网站可能有问题。
Firefox Android 用户体验因硬件不同而异。
Firefox Android 在加载 JS 页面上比基于 Chromium 的浏览器慢。

A Eulogy for DevOps #

https://matduggan.com/a-eulogy-for-devops/

这篇名为《A Eulogy for DevOps》的文章探讨了 DevOps 运动的兴起和衰落。文章指出，尽管 DevOps 的基本理念已经成为组织的第二天性，但最初的意图与实际结果之间存在巨大差距。文章提到，DevOps 的死因在于对导致软件难以编写的根本原因存在严重误解。文章描述了 DevOps 的概念，以及它在组织中的实际运作方式，包括软件发布流程、团队协作模式和技术实践。

作者指出，DevOps 的设计非常耗时且缓慢，开发团队需要协调发布软件，测试团队需要确保软件正常运行，运维团队需要按照操作手册进行部署。然而，这种模式存在许多问题，包括团队之间的沟通协调困难、软件部署速度慢、运维工作繁琐等。随着容器技术的普及，DevOps 得到了发展，但仍存在许多挑战，如运维工作仍然困难、监控和日志管理复杂等。

文章最终指出，当前团队越来越倾向于简化、不依赖特定平台的工具。作者呼吁组织应更加坦诚地审视他们真正需要的工具和实践，避免被行业的炒作误导。文章强调了对基础设施领域的回归和简化的重要性，以稳定性为重点，而非过度追求快速变革。

HN 评论 155 comments | 作者：weaksauce | 1 day ago #

https://news.ycombinator.com/item?id=40826236

评论中提到了“devops cycle”图表中的“构建、测试、部署”环节，强调了速度至关重要，但也指出了这种追求速度的代价；
有人认为持续集成和持续部署应该指向开发分支和容器，而不一定是直接发布到生产环境；
有人认为部署到生产环境频繁有利于基于主干的开发，减少了选择性部署的问题，提高了可靠性；
有人提到在大规模环境下，开发、测试和生产环境之间的差异会带来挑战，需要有效的解决方案；
有人认为快速发布降低了风险，促进了稳定性，尤其在受监管领域；
有人讨论了 Kubernetes 的优缺点，认为其复杂性和泄露实现细节可能导致问题；
有人提到 DevOps 的实践中可能出现的问题，强调了团队合作和文化的重要性；
有人认为 DevOps 的核心是快速反馈循环，但如何实现和适应不同情况需要自行决定；
有人指出 DevOps 在一些团队中被误解为专门角色，而不是团队内的一部分；
有人讨论了 DevOps 的成功和失败，强调了简化和减少 DevOps 工作量的重要性；
有人提到 DevOps 可能忽略了可复现性的重要性，以及在处理问题时可能出现的挑战；
有人谈到了在资源丰富的情况下，仍然选择使用小规模资源的现象；
有人感叹对专门的 QA 团队的怀念，认为现在开发人员和用户需要自行检查应用的工作。

Open source ‘Eclipse Theia IDE’ exits beta to challenge Visual Studio Code #

https://visualstudiomagazine.com/Articles/2024/06/27/eclipse-theia-ide.aspx

根据 Visual Studio Magazine 的文章，Eclipse Foundation 的 Theia IDE 项目经过七年的努力，现已正式推出，从测试版转为正式版，挑战微软类似的 Visual Studio Code 编辑器，两者在技术上有很多共同之处。Eclipse Theia IDE 是 Eclipse Cloud DevTools 生态系统的一部分，与 VS Code 在许可和治理方面有所不同。Eclipse Foundation 将其称为 VS Code 的“真正开源替代品”，VS Code 被微软描述为“基于开源构建”，但具有默认遥测等专有元素，用于收集使用数据。

Eclipse Theia IDE 与整体 Theia 项目的相关 Eclipse Theia 平台是独立的组件，用于基于现代 Web 技术构建 IDE 和工具。与 VS Code 的相似之处在于，Theia 基于驱动 VS Code 的 Monaco 编辑器构建，并支持相同的 Language Server Protocol（LSP）和 Debug Adapter Protocol（DAP），提供智能代码补全、错误检查等功能。

Eclipse Theia IDE 还支持与 VS Code 相同的扩展（通过 Open VSX Registry 而非微软的 Visual Studio Code Marketplace），这些扩展通常用 TypeScript 和 JavaScript 编写。在此时，微软的市场上有更多扩展可用于 VS Code，而 Open VSX Registry 中“适用于 VS Code 兼容编辑器的扩展”数量为 3,784。

Eclipse Foundation 在 2019 年比较了这两个工具，指出要在使用 VS Code 或 Eclipse Theia 作为工具平台之间做出良好决策，组织需要评估自定义项目需求。总的来说：

如果您想提供一些专注于代码的工具，并希望尽可能多的开发人员在其现有 IDE 中使用它，为 VS Code 提供扩展似乎是一个有效的选择。
如果您想为客户或自己的开发人员提供定制产品，该产品专为特定用例量身定制，可能包含比代码编辑更多的功能，您可能更适合使用 Eclipse Theia。

Eclipse Theia 允许开发人员使用单一的开源技术栈创建桌面和云 IDE。VS Code 是一个开发人员 IDE，从未打算用作其他 IDE 的基础，扩展或进一步分发。

Eclipse Foundation 今天强调了其 Theia IDE 与 VS Code 之间的另一个区别：周围的生态系统/社区。Theia IDE 的核心是由 Eclipse Foundation 主持的充满活力的开源社区，这确保了商业使用的自由，没有专有约束，并通过来自 Ericsson、EclipseSource、STMicroelectronics、TypeFox 等公司的贡献促进创新和可靠性。

Theia IDE 的开源基础、充满活力的社区支持以及支持商业使用的许可证为强大、灵活的开发环境奠定了基础，也体现了对用户偏好的尊重。选择 Theia IDE，开发人员和组织不仅仅是在采用一个 IDE；他们正在加入一个重视协作、自由和共同追求软件开发卓越的运动。

HN 评论 150 comments | 作者：avivallssa | 1 day ago #

https://news.ycombinator.com/item?id=40825146

早期使用 Theia 在 VS code 远程之前，对于在 VS code 框架中添加一些界面可扩展组件非常有用。
VS Code 与 Atom、vim、Emacs 等比较时，一个被低估的事实是扩展可以正常工作，非常容易安装和配置，Atom 对我来说无法使用，因为安装扩展后总是出问题。
VS Code 有缺陷，但扩展有限不是其中之一。
对于普通终端用户来说，他们真的不在乎系统中是否有额外依赖，这样的行为可能是他们想要的，即插件管理自己的依赖而无需用户输入。
Eclipse Theia IDE 是一个框架/基础，用于创建自定义 IDE 产品，而不是提供现成的 IDE。
人们对使用 Electron 编辑器感到不满，认为软件质量正在下降，人们愿意接受劣质、缓慢、臃肿的应用作为主要编辑界面。
人们对 Eclipse 品牌没有积极的感受，但 Eclipse Theia IDE 提供了一个独立于 Microsoft 的开放替代品。
人们希望停止使用 Electron 编辑器，认为软件质量正在下降，人们愿意接受劣质、缓慢、臃肿的应用作为主要编辑界面。
Eclipse Theia IDE 看起来很像 VS Code，他们复制了不好的设计。
人们对 Eclipse 品牌没有积极的感受，认为软件质量正在下降，人们愿意接受劣质、缓慢、臃肿的应用作为主要编辑界面。

The XAES-256-GCM extended-nonce AEAD #

https://words.filippo.io/dispatches/xaes-256-gcm/

在这篇文章中，作者介绍了一种名为 XAES-256-GCM 的新型 AEAD（Authenticated Encryption with Additional Data）算法，该算法设计用于高级 API 和 FIPS 140 合规性。XAES-256-GCM 具有 256 位密钥和 192 位 nonce。设计该算法的目标包括：

支持足够大的 nonce，以便为几乎无限数量的消息（2⁸⁰ 条消息，冲突风险为 2⁻³²）安全地随机生成 nonce；
完全符合 FIPS 140 标准；
在常见加密库的基础上实现简单。

文章详细介绍了 XAES-256-GCM 的设计原理和实现方式，包括如何计算派生密钥以及如何使用 AES-256-GCM。该算法的设计使得在高级 API 中使用变得更加简单，同时也提供了与其他加密算法的比较和测试向量。

总体而言，XAES-256-GCM 旨在成为一种安全、符合标准、互操作性强的 AEAD 算法，适用于高级 API，是一种可以与 XChaCha20Poly1305 和 AES-GCM-SIV 相辅相成的实现。文章还提到了一些赞助作者的公司以及作者个人的一些活动。

HN 评论 49 comments | 作者：FiloSottile | 24 hours ago #

https://news.ycombinator.com/item?id=40826683

设计非常巧妙：基于 CMAC，可以使用 AES-CBC 来推导密钥，其中低级别原语不可用。
密码学符号混合字节和位数，难以区分，数学符号不够明确。
似乎这篇工作提供了一种易于使用的方法来避免标准 AES-GCM AEAD 中的重复 nonce 问题。
标准 AES-GCM 中的 nonce 空间有限，是密码工程师对 GCM 最常见的问题之一。
这个工作使得随机 nonce 在第一位变得安全，避免了标准 AES-GCM 中的问题。
为什么使用 192 位 nonce 而不是 256 位？额外的位数在实际应用中不会被认为是昂贵的。
这个工作消除了标准 AES-GCM 中的“踩雷”问题，需要在~2^32 条消息后轮换密钥。
两个原语（基于计数器的 KDF 和普通 GCM）的组合使其符合 FIPS 标准。
随机 nonce 碰撞在大型文件系统部署中是一个巨大的问题。
加密中相同密钥和重复 nonce/计数器会产生相同的密码流，这可能破坏认证。
XAES 使用大密钥每条消息，因此实现了“优于生日”界限。
AES 块大小只有 128 位，因此在这之前是否会有问题？
XAES 消除了使用单个密钥加密的块的生日界限，实现了“优于生日”界限。

Researchers at ETH Zurich develop the fastest possible flow algorithm #

https://ethz.ch/en/news-and-events/eth-news/news/2024/06/researchers-at-eth-zurich-develop-the-fastest-possible-flow-algorithm.html

瑞士苏黎世联邦理工学院的研究人员开发出了可能最快的流算法。该算法由 Rasmus Kyng 编写，可以以数学上不可战胜的速度计算任何类型网络（如铁路、道路或电力）上的最大运输流量，同时保持最低成本。这一突破性工作涉及网络流算法，解决了如何在网络中实现最大流量同时最小化运输成本的问题。

这一算法可以应用于欧洲交通网络等情况，计算出最佳、成本最低的流量路径，无论是铁路、道路、水路还是互联网。Kyng 的算法计算速度极快，可以在计算机读取描述网络的数据的同时即刻提供解决方案。

在 Kyng 之前，没有人能够做到这一点，尽管研究人员已经研究这个问题大约 90 年。以前，计算最佳流量所需的时间远远超过处理网络数据的时间。Kyng 的方法消除了这个问题：使用他的算法，计算时间和网络规模以相同的速度增长，就像在徒步旅行时始终保持相同的步伐一样。Kyng 和他的团队开发了在理论上可能最快的网络流算法。两年前，Kyng 和他的团队在一篇开创性论文中证明了他们的概念。科学家们将这些新颖、几乎最优快速算法称为“几乎线性时间算法”，理论计算机科学界对 Kyng 的突破性工作反应强烈。

Kyng 的博士导师 Daniel A. Spielman 在耶鲁大学任应用数学和计算机科学教授，他将这个“极快”的算法比作保时捷超车马车。他们的论文获得了 2022 年 IEEE 计算机科学基础年会（FOCS）最佳论文奖，并在计算期刊《ACM 通讯》中被强调，流行科学杂志 Quanta 的编辑将 Kyng 的算法列为 2022 年计算机科学十大发现之一。

苏黎世联邦理工学院的研究人员已经完善了他们的方法，并开发了更多几乎线性时间算法。例如，第一个算法仍专注于固定的静态网络，其连接是定向的，意味着它们在功能上类似于城市道路网络中的单行道。今年发表的算法现在还能够计算随时间逐渐变化的网络的最佳流量。这种快速计算是解决高度复杂和数据丰富的网络的重要一步，这些网络在生物学中如分子或大脑，或人类友谊中动态变化非常快。

这些算法的进步不仅奠定了解决以前无法高效计算的非常大问题的基础，还改变了计算机首次计算复杂任务的方式。

HN 评论 14 comments | 作者：jeroenvlek | 12 hours ago #

https://news.ycombinator.com/item?id=40829459

算法在极限情况下接近线性。
他们表示在现实世界中，他们的算法任何实现都无法接近现有算法。
从 O(mn) 到 O(m) … 因此在计算中排除了 N（顶点数）…
常数因子太大，将比现有算法慢（在渐近意义上更差）。
2030 年，预计该算法将最优地解决某些 leetcode 面试问题。
摘要只是说时间是 m^(1+o(1))… 有人知道是否有更具体的界限陈述吗？
这是一个“小 o”，因此 o(1) 捕捉到随着 m 趋近无穷大而“除以 1”为零的项。
这是具体的界限。小 o 是一个函数，当 n 趋近无穷大时接近 0，被称为渐近可忽略的。
这意味着您可以选择常数，使算法接近 O(m)。
对于 O(m^(1+o(1)))，这意味着它是一个单一的界限，他们只是没有非常具体地说明。

All web “content” is freeware #

https://rubenerd.com/all-web-content-is-freeware/

这篇文章讨论了关于网络内容是否属于免费软件的问题。文章引用了微软人工智能部门首席执行官在 CNBC 的采访内容，指出自上世纪 90 年代以来，公开网络上的内容一直被视为公共资源，可以自由复制、再创作和再生产。

作者认为这种观点可能导致 Windows 软件也被视为免费软件，但也提到这种说法可能需要法律部门进一步审查。文章还探讨了人工智能技术的发展，指出一些管理者开始意识到他们在财务上的失败，因为这些模型对于非销售工具的人来说是不可持续的。此外，文章还提到了人工智能生成的内容被认为是低质量和低效率的趋势，以及人工智能技术可能已经接近巅峰。最后，文章指出人工智能供应商现在试图辩称一切都是公平竞争的，因为一直都是这样。

作者还对技术评论家现在提出的观点进行了讨论，认为聊天机器人和搜索引擎并无太大区别，但指出搜索引擎会链接到其来源，而聊天机器人却不会，这可能导致信息来源不透明。文章最后指出，这种现象可能是技术领域再次陷入泡沫的迹象。

HN 评论 91 comments | 作者：imadj | 17 hours ago #

https://news.ycombinator.com/item?id=40828441

Microsoft 被指控侵犯版权，应该加入明确限制以阻止他人使用其代码训练 AI，以便更容易对其提起诉讼。
机器学习依赖于版权的合理使用豁免，如果这种豁免被废除，整个领域将陷入困境。
在美国不会让 AI 被关闭，监管将采取谨慎态度，否则会转移到海外。
GPL 已经规定从 GPL 代码派生的代码应该是 GPL，这是否包括基于 GPL 代码生成的 LLM 的代码？
任何此类诉讼将在法庭外解决，不承认有罪，也不会通过公开证据泄露损害信息。
作者可以明确将作品奉献给公共领域，放弃任何版权，但即使在公共领域，也不意味着可以为所欲为。
Windows 可以免费下载，但要合法运行需要许可证，而不仅仅是激活密钥。
物理媒体在保存知识方面更具功能性，因此在数字化时代更为重要。
网络与 Web 不同，例如从 Apple Books 下载的电子书不是 Web 内容，即使来自互联网。
如果网络爬虫能在任何地方找到电子书，那么它就是公平竞争的，无论来源如何。