2024 04 04 HackerNews

2024-04-04 Hacker News Top Stories #

一句话摘要 #

‘Lavender’: The AI machine directing Israel’s bombing in Gaza 文章揭露了以色列军队如何使用名为“Lavender”的人工智能系统来标记加沙地带的嫌疑人进行轰炸。

Tips for linking shell companies to their secret owners 文章提供了追踪壳公司及其秘密所有者的方法和技巧，包括使用高级技术和数据库。

7.4 earthquake in Taiwan, 34km depth 美国地质调查局（USGS）的地震地图显示台湾发生了7.4级地震，深度34公里。

Anonymous public voicemail inbox 网站提供了一个公共语音信箱，用户可以拨打电话留言，内容多样且随机。

Subroutine calls in the ancient world, before computers had stacks or heaps 文章讨论了在计算机没有堆栈的时代，如何进行子程序调用的技术。

A Gentle Introduction to the Art of Mathematics 这是一个免费开源的数学教科书网站，涵盖逻辑、集合、关系等数学基础主题。

PyTorch Library for Running LLM on Intel CPU and GPU GitHub页面介绍了一个PyTorch库，用于在Intel CPU和GPU上加速大型语言模型的推理和微调。

Reflections on Distrusting xz 博文讨论了对xz压缩工具的不信任，怀疑其可能包含安全漏洞。

LiveView Is Best with Svelte 博文讨论了结合使用Phoenix的LiveView和Svelte来构建高效Web应用程序的优势。

Improvements to static analysis in GCC 14 文章介绍了GCC 14中静态分析的改进，包括新的警告和边界检查功能。

‘Lavender’: The AI machine directing Israel’s bombing in Gaza #

https://www.972mag.com/lavender-ai-israeli-army-gaza/

这篇文章揭示了以色列军队如何使用名为“Lavender”的人工智能系统来标记加沙地带成千上万名嫌疑人以进行暗杀行动。

该系统在战争中发挥了关键作用，将几乎所有被怀疑是哈马斯和巴勒斯坦伊斯兰圣战组织的军事翼成员，包括低级别成员，标记为潜在的轰炸目标。在战争初期，军队几乎完全依赖于“Lavender”，将多达 37,000 名巴勒斯坦人标记为嫌疑激进分子，他们的家庭也被列为可能的空袭目标。军队在家中袭击目标人员，而不是在军事活动中，这是因为从情报角度来看，更容易在他们的私人住所找到这些人。

文章还详细描述了“Lavender”系统的运作方式，以及军队如何放宽了允许在轰炸目标时杀害的平民数量等信息。整体来说，这篇文章揭示了以色列军队如何使用人工智能系统来指导对加沙地带的轰炸行动，导致许多平民在战争初期被杀害。

HN 评论 791 comments | 作者：contemporary343 | 9 hours ago #

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

评论中的观点归纳如下：

对于 AI 系统用于杀人的担忧，以及对国际法保护下的人员被以政治而非法律为由定为恐怖分子的批评；

关于 AI 系统从分类到杀戮的过程，以及对 IBM 在纳粹时期的合作的谴责；

对于 AI 系统在军事行动中的使用，以及对 IDF 使用 AI 系统的质疑；

以及对于以色列对加沙的围困和对平民的袭击的谴责。

Tips for linking shell companies to their secret owners #

https://gijn.org/stories/tracking-shell-companies-secret-owners/

这篇文章介绍了如何追踪壳公司的真实所有者。壳公司通常被用于隐藏资产所有者的身份，有时候会显得像在寻找不明飞行物一样困难。然而，有一些强大的工具可以帮助新手在这个复杂领域追踪到那些极力隐藏资产的人。文章提到，壳公司通常需要文件才能注册，而在寻找这些前台公司的真实所有者时，可以通过追踪银行转账路线等高级技术来揭示他们的身份。

文章还介绍了一些调查壳公司和最终受益所有者（UBOs）的技巧，包括在 OpenCorporates 进行快速公司或个人名称搜索，订阅企业风险数据库，以及使用 ICIJ Offshore Leaks Database 等。此外，还提到了一些实用的技巧，如尝试不同拼写、交叉搜索其他免费门户等。

总的来说，文章强调了持之以恒的重要性，因为文件往往会揭露隐藏的秘密。通过使用各种工具和技术，记者可以追踪到那些试图隐藏财富的人的真实身份和资产。

HN 评论 287 comments | 作者：chippy | 7 hours ago #

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

这篇帖子中的评论观点主要集中在对 Delaware LLC 的隐私保护和所有者信息公开的讨论，评论者认为 Delaware LLC 通常是一个黑匣子，难以追踪所有者信息；

也有人指出美国作为西方最大的避税天堂之一，维持了很高的隐秘性；

还有人讨论了公司所有者信息公开对于交易透明度和合法性的重要性，以及对于资产所有者信息公开的必要性和合法性的争议。

7.4 earthquake in Taiwan, 34km depth #

https://earthquake.usgs.gov/earthquakes/map/?extent=16.34123,-246.42334&extent=28.51697,-223.43994

这个链接指向美国地质调查局（USGS）的最新地震地图页面。页面显示了过去一天发生的 USGS 测得的 2.5 级以上的地震情况。在过去的一天里，共发生了 71 次地震。

HN 评论 175 comments | 作者：throwaway598 | 23 hours ago #

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

在这篇帖子的评论中，有关地震在台湾的影响：

有人感受到强烈的震感，台北有电力中断，但大部分人都安全；

有人分享了在地震中的恐惧体验和建议躲避地震的方法；

还有人讨论了建筑结构的安全性和建筑规范对地震的影响；

另外，也有关于海啸预测和海啸对海岸地区的影响的讨论。

Anonymous public voicemail inbox #

https://afterthebeep.tel/

网站 https://afterthebeep.tel/ 是一个语音信箱网站，用户可以拨打电话并在“嘟”声后留言。

留言内容包括问候、询问、开玩笑等各种主题，每条留言的长度和内容各不相同。留言内容涵盖了各种有趣和随机的话题，展示了用户留言的多样性和创意。留言列表显示了日期、长度和简要内容，用户可以在网站上收听这些留言。

HN 评论 96 comments | 作者：unixispower | 1 day ago #

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

这篇帖子中的评论观点主要涉及到早期技术的开放性和可塑性，以及对安全性和隐私的看法。

评论者们分享了早期 90 年代和 00 年代的经历，提到了当时的技术环境相对不那么封闭，充满了探索和玩耍的乐趣。

他们回忆起了当时通过电话系统和计算机系统进行各种尝试和操作的经历，强调了当时的技术环境与现在的安全性控制和权限管理的巨大差异。

评论者们还讨论了早期的网络安全问题，以及一些有趣的技术玩法，展示了对技术的热爱和探索精神。

Subroutine calls in the ancient world, before computers had stacks or heaps #

https://devblogs.microsoft.com/oldnewthing/20240401-00/?p=109599

这篇文章讨论了在计算机没有堆栈或堆的古老时代，如何进行子程序调用。在那个时候，计算机操作是没有堆栈或堆的。编译器为每个传入的函数参数定义了一个秘密的全局变量，为每个函数定义了一个秘密的全局变量来保存返回地址，以及为函数的每个局部变量定义了一个秘密的全局变量。

在没有堆栈的情况下，编译器将参数值分配给相应的秘密全局变量，将返回地址分配给函数的秘密“返回地址变量”，然后跳转到函数的开始。函数从其秘密全局变量读取参数，并使用与其逻辑局部变量对应的预定义秘密全局变量。当函数完成时，它跳转到函数的秘密“返回地址变量”中保存的地址。

文章还展示了一个示例代码，演示了如何在没有堆栈的情况下进行函数调用和返回。文章指出，这种方法无法支持递归，因为递归调用会覆盖返回地址变量，导致外部调用完成后跳转到错误的位置。

另外，一些编译器甚至使用自修改代码来实现子程序调用。最后，文章提到了一些处理递归和子程序调用的解决方案，以及一些处理子程序调用的指令。

HN 评论 127 comments | 作者：signa11 | 19 hours ago #

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

讨论中提到了在古代世界中，计算机没有堆栈或堆的情况下如何进行子程序调用；
提到了一些关于动态数组或其他数据结构的预堆/预栈算法；
讨论了如何让两个数组共享静态分配的空间；
提到了一些 8 位计算机上的文字处理器是如何工作的；
讨论了一些编辑器如 Emacs 和 Vim 如何处理文本；
SQLite 和 Oracle 等数据库引擎也使用了类似的数组技术；
讨论了旧版 MacOS 如何分配每个应用程序的资源；
讨论了递归函数如何进入 ALGOL 的故事；
讨论了 Forth 解释器和一些机器的工作方式；
讨论了 GNU 试图消除核心实用程序中的人为限制的目标；
讨论了现代软件开发中对内存使用的态度。

A Gentle Introduction to the Art of Mathematics #

https://giam.southernct.edu/GIAM/

这个网址是关于《A Gentle Introduction to the Art of Mathematics》（数学艺术的温和介绍）的主页。这是一个免费、开源的教科书，当前版本是 3.1。

该教科书涵盖了数学基础领域的多个主题（逻辑、集合、关系、函数和基数），并向读者介绍了许多数学证明技巧（直接证明、间接证明、反证法、逆否命题、数学归纳法、组合证明和魔术）。

每章节开头都有有趣的引言。内容包括文本、练习册、提示与解答手册以及一些评论链接。该教科书使用 GNU 自由文档许可证 1.3 版授权，采用 PDFLaTeX 排版，XFiG 制作图形，GIMP 修改照片。

现在还可以通过 CreateSpace 获得印刷版的 GIAM。GIAM 的源代码托管在 GitHub 上。此外，还提供了其他版本的 GIAM。

HN 评论 60 comments | 作者：Keegs | 1 day ago #

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

评论中的观点归纳如下：

1. 评论者对数学引言书籍的质量表示赞赏，认为书中对函数、关系和基本证明技巧等概念进行了基本介绍，内容不错；
1. 有人建议寻找更具个性化的数学书籍，而非传统教科书式的介绍，推荐 Ian Stewart 的《From Here to Infinity》等书；
1. 也有人认为该书比其他推荐书籍更适合引入高等数学，认为学习基本数学概念和证明技巧的课程是准备学习高等数学的更好方式。

PyTorch Library for Running LLM on Intel CPU and GPU #

https://github.com/intel-analytics/ipex-llm

这个 GitHub 地址（ https://github.com/intel-analytics/ipex-llm）是关于加速在 Intel CPU 和 GPU 上进行本地 LLM 推理和微调（LLaMA、Mistral、ChatGLM、Qwen、Baichuan、Mixtral、Gemma 等）的内容。这是一个 PyTorch LLM 库，可以与 llama.cpp、HuggingFace、LangChain、LlamaIndex、DeepSpeed、vLLM、FastChat、ModelScope 等无缝集成。

该库构建在 Intel PyTorch 扩展（IPEX）之上，以及 llama.cpp、bitsandbytes、vLLM、qlora、AutoGPTQ、AutoAWQ 等优秀工作的基础上。它提供了与 llama.cpp、Text-Generation-WebUI、HuggingFace transformers、HuggingFace PEFT、LangChain、LlamaIndex、DeepSpeed-AutoTP、vLLM、FastChat、HuggingFace TRL、AutoGen、ModeScope 等的无缝集成。

ipex-llm 已经优化/验证了 50 多个模型（包括 LLaMA2、Mistral、Mixtral、Gemma、LLaVA、Whisper、ChatGLM、Baichuan、Qwen、RWKV 等），可以在此处找到完整列表。

最新更新包括支持直接从 ModelScope 加载模型、添加初始 INT2 支持、支持自我推测解码、支持广泛的 LLM 微调等功能。此外，还提供了各种代码示例、性能基准测试、教程等内容。详细信息请参阅 ipex-llm 文档网站。

HN 评论 83 comments | 作者：ebalit | 13 hours ago #

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

有人认为 Intel 有机会在下一代消费级 GPU 中推出 32-48GB VRAM，打破 AMD 和 Nvidia 长期推行的“8-16GB VRAM”限制；
有人指出 Intel 在 AI 领域与 Nvidia 竞争时处于劣势，因为软件优化主要针对 Nvidia 的 CUDA；
有人认为 Intel 错失了增加 VRAM 的机会，下一代卡只有 12GB，而需求却是高 VRAM；
有人提到 Optane 产品在 AI 模型中可能具有优势，因为它是位地址寻址的；
有人认为 Intel 应该推出更多 VRAM 的工作站 GPU，而不是模仿其他公司；
有人认为增加 RAM 以避免工程解决方案一直是成功的策略；
有人认为大型语言模型需要大量 VRAM，而市场需求也在增加；
有人认为 Intel 应该推出消费级 GPU，以吸引机器学习爱好者，从而提升企业 GPU 的吸引力；
有人认为 Intel 和 AMD 应该效仿 Nvidia 的策略，推出大量 VRAM 的卡，以吸引开发者；
有人认为 Intel 应该推出廉价的高 VRAM GPU，以满足工作需求。

Reflections on Distrusting xz #

https://joeyh.name/blog/entry/reflections_on_distrusting_xz/

这篇博文讨论了对 xz 压缩工具的不信任，并探讨了一个名为“Jia Tan”的实体可能在多年操作中追求的目标是否仅仅是 ssh 后门。

作者怀疑这并非唯一目标，因此迄今为止的每个修复都可能是不完整的，因为系统仍在运行该实体编写的代码。文章提出了如果 xz 包含隐藏的缓冲区溢出或其他漏洞，可能会被利用来攻击其他软件包的威胁。作者还考虑了 xz 的全面威胁面，涉及到“信任的信任”等噩梦情景。

文章讨论了潜在的攻击方式，包括通过修改文档中的 png 图像来利用缓冲区溢出，以及可能的后续攻击目标。作者还提到了“Jia Tan”在 xz 中引入新解码器的情况，以及与 xz 作者 Lasse Collin 的合作，暗示了可能的影响。

最后，作者建议 Debian 回退到早期版本的 xz，并提到了自己创建的 xz-unscathed 分支，以避免受到“Jia Tan”涉及的提交的影响。文章强调了需要对所有可能受到影响的提交持怀疑态度。

HN 评论 299 comments | 作者：edward | 15 hours ago #

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

讨论中提到可能存在“沉睡者”概念，即潜伏在开源项目中等待指令的人员；
担忧潜伏维护者的数量，认为渗透容易且难以检测，可能存在许多；
认为国家情报机构可能会派人监视重要开源软件项目；
讨论了潜伏者可能的成本和效率，以及发现漏洞的机会；
强调了开源模式的韧性，指出 FOSS 模型在应对长期渗透尝试时表现出色；
讨论了维护者的压力和时间限制，以及对维护者的信任和治理框架的需求；
提出通过感谢和稳定就业来解决维护问题；
讨论了潜在的恶意维护者和开源项目的安全问题；
讨论了政府通过压力或合同方式获取后门的可能性；
讨论了开源供应链和闭源商业软件的安全问题。

LiveView Is Best with Svelte #

https://blog.sequin.io/liveview-is-best-with-svelte/

这篇博文讨论了如何结合使用 Phoenix 的 LiveView 和 Svelte 来构建最佳的 Web 应用程序。作者从 Sequin 公司的实践出发，分享了他们开始使用 LiveView 的经历，以及在使用 LiveView 时遇到的一些挑战。LiveView 是一种独特的构建 Web 应用程序的方式，它使得服务器负责渲染页面，并且具有状态。与传统的 SPA（单页面应用程序）和传统的服务器渲染应用程序不同，LiveView 在前端和后端之间建立了一种新的交互方式。

文章指出了在使用 LiveView 过程中遇到的一些困难，例如处理客户端状态、前端组件之间的通信等。作者介绍了 LiveSvelte 这一伴侣库，它使得在 LiveView 中结合使用 Svelte 变得更加容易和高效。LiveSvelte 允许在 LiveView 中渲染 Svelte 组件，从而提供了一种前后端协作的新范式。通过 LiveSvelte，作者强调了如何将更多的责任转移到前端，让前端具有自己的状态，并利用现代 JavaScript 组件框架的成熟性。

总的来说，文章强调了 LiveView 与 Svelte 结合的优势，以及如何通过这种结合方式实现更高效的 Web 应用程序开发。通过这种方式，作者认为 LiveView 最适合作为后端为前端的一种解决方案，为前端应用程序提供了一个高效的平台。

HN 评论 123 comments | 作者：keturakis | 12 hours ago #

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

这篇帖子中的评论观点主要包括：

多人游戏中使用客户端和服务器端默认运行的代码模式，以实现预测和同步状态。
LiveSvelte 构建的游戏 https://territoriez.io/使用乐观更新展示游戏状态，强调逻辑共享避免重复编写。
对 https://generals.io/的克隆提出改进建议，包括地图设计、游戏逻辑等。
讨论使用 Elixir 和 Gleam 编写游戏逻辑的可行性，以及 LiveView 在此过程中的作用。
对 LiveView 和 Svelte 在客户端状态管理、网络连接等方面的讨论。
对 LiveView 在离线状态下的可用性进行探讨，以及与 CRDT 和 LiveSvelte 结合创建 PWA 的可能性。
讨论在客户端和服务器端管理状态的优势和挑战，以及不同技术栈的比较和应用场景。
LiveView 与其他技术（如 ColdFusion、Web Forms、JSF、PHP、Spring、Rails）的相似性和差异。
对 LiveView 在 BEAM VM 下的运行优势的讨论，以及与其他技术栈的比较。
LiveView 的工作原理、与 Phoenix Sockets 的关系以及在事件触发时更新状态的机制。

Improvements to static analysis in GCC 14 #

https://developers.redhat.com/articles/2024/04/03/improvements-static-analysis-gcc-14-compiler

这篇文章介绍了 GCC 14 中静态分析改进的内容，主要是通过使用-fanalyzer 选项在编译时识别 C 代码中的问题，而不是在运行时。作者在过去五个 GCC 版本中一直在开发-fanalyzer，这是一个静态分析步骤，通过对 C 源代码进行“符号执行”，有效地模拟代码在执行路径中的各种可能情况。

在 GCC 14 中，作者实现了一个新的警告：-Wanalyzer-infinite-loop，能够检测一些简单的无限循环情况。例如，作者展示了一个代码示例，演示了如何使用-fanalyzer 选项成功检测到无限循环的情况。

此外，文章还介绍了在 GCC 13 中增加的边界检查功能，以及在 GCC 14 中新增的文本图表功能，用于可视化预测的缓冲区溢出情况。作者还对 C 字符串操作进行了改进，包括模拟期望空终止字符串的 API、添加新的函数属性 null_terminated_string_arg 等。

另外，作者还介绍了 GCC 14 中的“污点分析”功能，用于跟踪受攻击者控制的输入、消毒的位置以及未经消毒的使用位置。作者修复了许多相关 bug，并在 GCC 14 中默认启用了这一功能。最后，作者鼓励读者尝试 GCC 14，并指出可以在 Compiler Explorer 网站上尝试新编译器。

HN 评论 63 comments | 作者：dmalcolm | 10 hours ago #

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

GCC 的 falyzer 功能被认为是其杀手锏之一，使得在 C 编程中更容易理解错误，且错误消息类似于 Rust，更友好。
有人怀疑 Rust 的流行程度是否归功于其错误消息，认为学习新技术时最大的阻碍是令人沮丧或不清晰的错误。
Rust 的良好错误消息部分受益于从 Elm 学习，但 Rust 通过长时间的努力和关注获得了良好的错误消息。
人们习惯于好的错误消息并要求更多，这是保持错误消息高质量的良性循环的一部分。
修改 NixOS 配置时的一个错字可能导致类似于 C++03 模板的错误转储。
在 Nix 代码中迭代最痛苦的部分之一是开发对常见问题的直觉，而不是依赖于解析堆栈跟踪。
C 语言中的一个难题是很难判断程序员编写的内容是否错误，因此警告有时会很难或过度。
对于有符号溢出，可以使用-fsanitize=signed-integer-overflow。
Clang 经常给出比 GCC 更好的错误消息，一些警告或错误的实现可以捕获更多情况，而 clang-tidy 能够进行更好的静态分析。
使用 goto 在某些情况下是明确正确且优雅的，避免 goto 可能导致代码变得难以维护。
strcpy 和 strcat 没有太多优势，更安全的版本在许多情况下仍然不安全，而且使用起来更烦人。
使用标准 C 字符串函数时，应考虑使用 snprintf 或编写自定义函数以确保安全性。
strncpy 常被误解，它不保证输出是以空字符结尾的，可能导致漏洞。
使用 strncpy 时必须紧随 dst[sizeof dst - 1] = 0，否则可能会出现难以发现的瞬时错误。
在 C 中，goto 在某些情况下是可以接受的，而 strcpy 和 strcat 在某些情况下是有效的，但大多数情况下都会导致问题。