hacker_news_top_comments_2025-10-16

Hacker News 高赞评论 - 2025-10-16

1. runjake 在“苹果 M5 芯片”话题中发表新评论

来看看我能不能把这个做成ASCII表格,并且让它能在HN的重新排版后保持原样。

    +------+------------------+--------------+----------+----------------+-------------------+-------------------+---------------------------+
    | 芯片  | 制程工艺         | CPU核心      | GPU      | 神经网络引擎   | 内存带宽          | 统一内存          | Geekbench6 (单核/多核)    |
    +------+------------------+--------------+----------+----------------+-------------------+-------------------+---------------------------+
    | M1   | 5纳米            | 8 (4性能+4能效)| 7–8核   | 16核神经网络  | 68.25 GB/秒       | 16 GB             | ~2346 / 8346              |
    | M2   | 5纳米 (第二代)    | 8 (4性能+4能效)| 8–10核  | 16核神经网络  | 100 GB/秒         | 24 GB             | ~2586 / 9672              |
    | M3   | 3纳米 (第一代)    | 8 (4性能+4能效)| 8–10核  | 16核神经网络  | 100 GB/秒         | 24 GB             | ~2965 / 11565             |
    | M4   | 3纳米 (第二代)    | 10 (4性能+6能效)| 8–10核 | 16核神经网络  | 120 GB/秒         | 32 GB             | ~3822 / 15031             |
    | M5   | 3纳米 (第三代)    | 10 (4性能+6能效)| 10核   | 16核神经网络  | 153 GB/秒         | 最高32 GB         | ~4133 / 15437 (9核)       |
    +------+------------------+--------------+----------+----------------+-------------------+-------------------+---------------------------+

作者: runjake | 发布于: 2025-10-15 19:57


2. hereme888 在”苹果 M5 芯片”话题中发表新评论

仅基础型号参数对比:

  • M1 | 5纳米制程 | 8核(4性能核+4能效核) | GPU 7-8核 | 16核神经网络引擎 | 内存带宽:68.25 GB/s | 统一内存:16 GB | Geekbench6单核2346 / 多核8346

  • M2 | 5纳米(第二代) | 8核(4性能核+4能效核) | GPU 8-10核 | 16核神经网络引擎 | 内存带宽:100 GB/s | 统一内存:24 GB | Geekbench6单核2586 / 多核9672

  • M3 | 3纳米(初代) | 8核(4性能核+4能效核) | GPU 8-10核 | 16核神经网络引擎 | 内存带宽:100 GB/s | 统一内存:24 GB | Geekbench6单核2965 / 多核11565

  • M4 | 3纳米(第二代) | 10核(4性能核+6能效核) | GPU 8-10核 | 16核神经网络引擎 | 内存带宽:120 GB/s | 统一内存:32 GB | Geekbench6单核3822 / 多核15031

  • M5 | 3纳米(第三代) | 10核(4性能核+6能效核) | GPU 10核 | 16核神经网络引擎 | 内存带宽:153 GB/s | 统一内存:最高32 GB | Geekbench6单核4133 / 多核15437(9核测试样本)

作者: hereme888 | 发布于: 2025-10-15 18:25


3. blactuary 在《我差点被”工作面试”骗局入侵》中的新评论

“用区块链改造房地产”这句话本身就是个危险信号

作者: blactuary | 发布于: 2025-10-15 16:40


4. 0xfaded 在 “M5 MacBook Pro” 中的新评论

致所有Linux用户:我最近买了一台顶配的M4芯片MacBook Pro来替换老旧的联想笔记本,现在非常后悔。本以为能用它来折腾大语言模型,但在Mac上进行本地开发实在糟心,到现在都没完全配置好。估计不久后就会换回Framework笔记本。

编辑:没想到引发这么多关注,看来得补充说明几点:

  1. 所有细节都有微妙差异。我不得不把所有的配置文件拆分成通用/Linux/Mac专用模块。除非项目组特意适配Mac,否则别指望能直接克隆编译任意C++项目

  2. 并非所有软件都原生支持arm64架构。有次想用DynamoRIO启动项目,结果发现根本不支持。其他用户也提到过Docker的各种兼容问题

  3. 窗口管理器让人头疼。我不喜欢那些动画效果和触控板手势切换屏幕的操作(没错,我已经深入研究过快捷键设置了)。要安装第三方窗口管理器还得关闭安全设置,因为它们需要通过注入显示服务并调用私有API来实现

我的切身感受是,过去把Linux生态的开放性视为理所当然(我本地始终保留着内核代码库以便随时检索错误信息)。失去这种自由就像被束缚了双手。讽刺的是我工作也用MacBook Pro,但整天都通过ssh连接Linux服务器。这机器当网页浏览器和终端模拟器倒是挺称职。

作者: 0xfaded | 发布于: 2025-10-15 15:23


5. 用户 mumber_typhoon 在”苹果 M5 芯片”话题下的新评论

M5版MacBook Pro仍在使用博通WiFi芯片,但M5版iPad Pro已经用上了N1和C1X芯片(给力)。

总的来说,苹果在硬件方面确实做出了令人惊叹的创新。

但苹果的软件团队真的需要加把劲了。M1芯片本身性能如此强大,对于大多数用户的日常使用场景根本不需要升级。然而在塔霍系统上,执行我过去几年完全相同的任务时,我的M1版MacBook Air却变得卡顿。真希望这不是苹果为了逼我升级而故意为之,否则就太让人失望了。

作者: mumber_typhoon | 发布于: 2025-10-15 13:37


6. DennisP在”苹果Vision Pro升级搭载M5芯片”中的新评论

Vision Pro刚发布时我特别感兴趣。但后来发现他们采用了应用模式,设备只能显示单个MacOS窗口。这下我把自己包围在一堆vim窗口和终端里的梦想就破灭了。

如果他们当初专注于最大化设备实用性而非盈利模式,或许结果会好得多。

作者: DennisP | 发布于: 2025-10-15 13:26


7. toddmorey 在 “Apple M5 芯片” 话题中发布新评论

现在的苹果公司给人的感觉是,他们的硬件团队表现远超软件团队。

作者: toddmorey | 发布于: 2025-10-15 13:20


8. CalRobert在”爱尔兰将艺术家基本收入计划永久化”中的新评论

他们原本试图把这个项目称为”全民基本收入”,直到有人指出这根本与”全民”背道而驰。这个项目完全扭曲了UBI应有的本质。

所有渴望成为艺术家但负担不起生计的人都被排除在外。而我的某个熟人,在伦敦卖房大赚一笔后,退休搬到韦斯特米斯郡的小屋靠这笔收益生活,偶尔随便弹弹吉他,却成了这个项目的资助对象。

很能说明问题的是,关于如何通过这个项目真正”成为”艺术家的信息少得可怜。

编辑补充:值得注意的是,他们提出了一些非常可疑的数据来声称这个项目带来了经济净收益。其中关键组成部分是心理健康效益,贡献了近8000万欧元。此外报告估计,基于公众为文化体验付费的意愿,观众参与艺术活动产生了1690万欧元的社会价值。

尽管我很看重心理健康(谁不是呢!)——但声称心理健康价值8000万欧元,而实际并未获得这笔资金,在需要为项目买单时毫无助益。发钱能改善人们的心理健康,这点我毫不意外。

我更期待看到为Deliveroo外卖员和炸鱼薯条店员工提供的基本收入计划。

作者: CalRobert | 发布于: 2025-10-15 12:34


9. kburman 在《告别无服务器架构带来性能提升与架构简化》中的最新评论

关键问题不在于无服务器架构不行,而是作者根本没理解他们所用的技术基础。把对延迟敏感的API放在无状态边缘运行时上,这种新手错误导致的痛苦完全在意料之中。

作者: kburman | 发布于: 2025-10-15 12:18


10. simul007 在《机器人正日益擅长模拟用户互动》中的新评论

大家好,我是某营销机构的负责人。因为客户的数据出现明显异常(5万访问量仅产生47笔订单),我开始深入调查这个问题。最终我编写了一个简单的用户行为追踪脚本,分析了200多家小型电商网站的数据,发现标准分析工具统计的流量中平均有73%来自机器人。

这些机器人模拟用户参与度的能力已经达到令人毛骨悚然的程度。我整理了调查结果,包括观察到的一些诡异行为模式,以及与广告技术圈内人的非公开对话。这似乎是个众人心照不宣的公开秘密——由于整个生态系统都依赖于此,没人愿意捅破这层窗户纸。

想请教各位开发者、创始人和营销人员,是否在自家数据中也发现过类似异常?

作者: simul007 | 发布于: 2025-10-15 11:11


11. 用户 grues-dinner 在《英国风力涡轮机弃用成本》中的新评论

人们反对一切事物。

  • 格构式架空高压线?视觉污染(应该用新型T型塔)、影响房价、风噪、嗡嗡声、干扰WiFi、致癌、修建检修道路、威胁飞机安全、危害鸟类

  • T型输电塔:单调乏味([链接])、有碍观瞻(我们更喜欢格构式)、同样存在上述多数问题

  • 地下电缆:破坏环境、终端站造成光污染/视觉污染、增加施工车辆、应该用高压直流而非交流电、影响房价

  • 太阳能农场:浪费优质土地(建高尔夫球场却可以)、存在噪音、施工污染、视觉污染(但400英亩刺眼难闻的油菜花田却可以接受)、影响房价

  • 陆上风电场:持续危害鸟类、需要修建道路、视觉污染、噪音、危险性、应该建在海上、影响房价、浪费土地、我在脸书上听说碳回收周期要500年

  • 海上风电场:视觉污染、干扰雷达、危害鸟类、莫名影响房价、航行危险、破坏海床

  • 修建检修道路:破坏乡村景观、未铺装路面扬尘、排水问题、影响房价

  • 不修建检修道路:破坏现有道路、重型货车占用地方公路、影响房价

  • 核电站:literally所有反对理由叠加,外加恐怖阴影

其中某些理由单独看或许成立,但归根结底是一群处处作梗的哗众取宠之徒——他们以为自己1991年花10万英镑购买、如今升值到90万英镑的房子就是宇宙中心。

关于外国势力干预
我确信这些人绝不会收取境外资金:https://www.bbc.co.uk/news/articles/c93k584nvgeo https://www.bbc.co.uk/news/articles/clyk1j92195o

作者: grues-dinner | 发布于: 2025-10-15 11:10


12. cookiengineer 在”自由软件基金会宣布 Librephone 项目”中的新评论

为什么他们不能直接与postmarketOS合作呢?

为什么我们非得用/e/OS而不是获得更好支持的LineageOS?毕竟/e/根本就是原样照搬。

为什么现在又要搞什么Librephone项目,而不是去和Fairphone、Pine64这些团队合作?

开源阵营输就输在各自为战,而专有设备却能做到高度整合。目前唯一接近这个目标的只有GrapheneOS、LineageOS和postmarketOS。

LineageOS现在面临巨大难题——新版Android强制要求的eBPF功能,这本来可以通过postmarketOS及其上游内核驱动来解决。GrapheneOS受困于Pixel设备限制,而这正是LineageOS的优势所在。

我们必须整合这个生态圈,因为单打独斗的话,谁都无法在科技巨头的碾压下独善其身。

作者: cookiengineer | 发布于: 2025-10-15 06:53


13. 用户krackers在《我是程序员,不是批准Copilot生成代码的橡皮图章》中的新评论

我发现LLM生成的代码最终会把审查和维护的负担转嫁给其他人。这些代码乍一看”像模像样”,能通过表面测试,所以很容易被合并。但当你基于这些代码进行开发时,就会意识到它们的基础搭建得很仓促,导致大量代码需要重写。对于一次性或探索性工作还好,但如果你所在的项目里,人们用LLM来”修复”之前LLM生成的代码带来的bug,那可就够呛了。

确实,对于使用者A来说,这确实提高了”开发速度”。但后续开发者B基于这些代码开发时速度的下降,却从未被准确追踪。这就像击鼓传花的游戏——如果你想在指标上做文章,最好去做新代码开发(虽然维护工作在绩效评估中向来不受待见,但现在代码腐化的周期被加速了)。

作者: krackers | 发布于: 2025-10-15 06:23


14. bigstrat2003在”自由软件基金会宣布Librephone项目”中的新评论

归根结底,我认为最关键的挑战并不在于二进制固件闭源包,而在于人们赖以管理日常生活的软件。即便能在手机上运行完全自由的操作栈,但若银行软件(或日益可能强制使用的政府身份认证程序)要求你必须使用科技巨头认证的手机系统,这一切又有什么意义?或许自由软件基金会对此无能为力,但在我看来,这正是他们能为普通用户争取自由发挥最大影响力的领域。

作者: bigstrat2003 | 发布于: 2025-10-15 00:36


15. jasonthorsness 在《为什么 SQLite 用 C 语言编写》中的新评论

在SQLite问世的最初十年里,现有的安全编程语言都尚未诞生。虽然可以用Go或Rust重写SQLite,但这样做可能引入的bug数量会远超修复的数量,还可能导致代码运行效率降低。

现代语言或许比C语言更能防止程序员写出有缺陷的代码,但如果你已经通过大量时间、精力和测试获得了无缺陷的代码,且代码变更频率很低(甚至为零),那么使用什么语言其实并不重要。即便SQLite是用汇编语言写的,也不会影响其价值。

作者: jasonthorsness | 发布于: 2025-10-14 23:36


16. freetime2 在《适用于常规软件却对人工智能失效的认知误区》中的最新评论

要了解驾驭大语言模型的实际挑战,看看苹果公司就知道了。一年多前他们举办了盛大的产品发布会,主打”苹果智能”,宣称要大量运用大语言模型实现智能工作流。但至今我们实际看到的只是几个制作表情包、汇总通知和校对文本的小工具。甚至连通知摘要功能都曾因严重”失控”而被迫撤回[1]。而在今年的iPhone发布会上,AI营销力度已明显收敛。

我认为苹果高管确实低估了让大语言模型达到苹果一贯的精细管控标准所需面对的难度。

[1] https://www.bbc.com/news/articles/cge93de21n0o

作者: freetime2 | 发布于: 2025-10-14 22:08


17. jrockway 在《我们别加密了(2019)》中的新评论

我认为如果不采用TLS,现在每家运营商都会往网站里插广告。增加中间人攻击的难度是件好事。运营商既不想承担代理配置的客服压力,也不愿处理自定义证书的麻烦(天知道你们IT部门多痛恨这种流量篡改带来的售后问题),所以TLS确实让我们免受过量广告侵扰。(当然他们确实会篡改DNS,这才有了DoH的必要性。如果你让流量容易被篡改,运营商就有充分的商业理由去动手脚。虽不愿承认但事实如此)

对于作者所谓”如今国家机构能轻松伪造证书”的观点,我不敢苟同。我不确定每次网页加载前我们做了多少证书透明度检查,但要么是国家机构在强制签发未录入CT数据库的证书,要么这类行为会被记录——你反而能借此锁定哪些国家在实施监控。这问题比起十年前已经缓和不少。

作者似乎忽略了证书提供的关键保障:”在$签发日期控制该网站的主体,此刻依然控制着该网站”。这个保证其实很有价值。

作者: jrockway | 发布于: 2025-10-14 14:11


18. sgarland 在《为何万物皆可扩展?》中的新评论

太感谢了。当我告诉别人他们那些过度复杂的流程完全可以用几台高性能服务器轻松搞定时,他们看我的眼神就像在看疯子。最多也就是争辩说”这样就不用管理基础设施了”。可事实是你还是得管——绝对要管。只不过部分工作被抽象化了,像操作系统维护这种本来管理服务器时就不算困难的部分有人代劳了,但你租用的各种XaaS服务仍然需要亲自配置和监控。

作者: sgarland | 发布于: 2025-10-14 12:55


19. BirAdam在《为何万物皆可扩展?》中的新评论

说实话……我们还得问清楚这指的是什么规模?

早在容器技术还没出现的时候,我曾为几家大型成人网站做系统架构。这些网站在大规模视频流媒体领域是先行者,当时同量级的玩家只有YouTube。

当时行业头部企业的典型架构是:haproxy作为前端代理,后面接nginx,再往后是若干PHP服务器,最后连接采用一主一从(主库读写、从库只读)的MySQL数据库。存储方案(当时)通常采用glusterfs。这套架构在当时足以支撑数十万并发用户,不过当时的视频质量远不如现在的标准。

如今在AWS上,用户每月花费的成本可能远超当年那套硬件方案,但获得的计算能力和存储空间却少得多。

作者: BirAdam | 发布于: 2025-10-14 12:35


20. 用户 frameset 在《KDE 庆祝成立 29 周年并启动年度募捐活动》中的新评论

时隔多年重回Linux桌面环境后,我彻底爱上了KDE。

最让我惊讶的是,居然没几个主流发行版将KDE设为默认或”首选”桌面环境。如果我是从Windows转来的新手用户,肯定会更偏爱KDE——只要坚持使用图形界面,就会发现它的操作逻辑非常直观,某些方面甚至颇为相似。

作者: frameset | 发布于: 2025-10-14 11:34