HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    系统与基础设施rachelbythebay.com

    fork() 会失败

    fork() can fail

    2次上首页
    6年跨度
    989累计得分
    430条评论

    2014 — 2020,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    这篇博文指出一个常被忽视的 Unix 陷阱:fork() 可能失败(例如进程数达到 ulimit 上限),而很多程序不检查其返回值,导致严重后果。作者结合实际案例说明忽略这一错误检查会带来怎样的故障与安全隐患。

    为什么经久不衰:它揭示了一个看似简单却屡屡造成真实事故和漏洞的系统调用陷阱,提醒开发者认真检查每个返回值,这一教训至今仍然适用。

    关键词 Unixfork错误处理系统编程

    HN 评论精选

    用亲身经历说明无节制 fork 能直接搞垮整个系统

    我年轻时还不懂 Unix,和朋友在 NBS 实习时好奇一直递归调用 fork() 会怎样,就写了个程序跑起来。结果 PDP-11 上的系统几乎整个锁死,管理员冲进机房大喊'你们干了什么'。最后只能硬重启,还得手工用 ncheck 和 icheck 修复损坏的文件系统。几天后有人塞给我一本《Lions Notes》,那是我操作系统内核学习的开端。

    kabdib查看英文原文

    When I was young and really didn't understand Unix, my friend and were summer students at NBS (now NIST), and one fine afternoon we wondered what would happen if you ran fork() forever. We didn't know, so we wrote the program and ran it. This was on a PDP-11/45 running v6 or v7 Unix. The printing console (some DECWriter 133 something or other) started burping and spewing stuff about fork failing and other bad things, and a minute or two later one of the folks who had 'root' ran into the machine room with a panic-stricken look because the system had mostly just locked up. "What were you DOING?" he asked / yelled. "Uh, recursive forks, to see what would happen." He grumbled. Only a late 70s hacker with a Unix-class beard can grumble like that, the classic Unix paternal geek attitude of "I'm happy you're using this and learning, but I wish you were smarter about things." I think we had to hard-reset the system, and it came back with an inconsistent file system which he had to repair by hand with ncheck and icheck, because this was before the days of fsck and that's what real programmers did with slightly corrupted Unix file systems back then. Uphill both ways, in the snow, on a breakfast of gravel and no documentation. Total downtime, maybe half an hour. We were told nicely not to do that again. I think I was handed one of the illicit copies of Lions Notes a few days later. "Read that," and that's how my introduction to the guts of operating systems began.

    不检查 mkdir/chdir 返回值导致 home 目录被删,与 fork 失败是同类错误

    这让我想起遇到过的最离谱的 bug 之一:以 root 运行时,mkdir 创建目录、chdir 进入、再递归删除目录内容,通常没问题;但以非 root 运行时 mkdir 和 chdir 都失败了,程序接着把我的整个 home 目录删光了。

    cperciva查看英文原文

    This reminds me of one of the most epic bugs I've ever run into: mkdir("/foo", 0700); chdir("/foo"); recursively_delete_everything_in_current_directory(); Running as root, this usually worked fine: It would create a directory, move into it, and clean out any garbage left behind by a previous run before doing anything new. Running as non-root, the mkdir failed, the chdir failed, and it started eating my home directory.

    setuid() 失败同样可被利用提权,Android 曾两次中招

    同一家族的问题:setuid() 也可能失败!如果目标用户已达到进程数 ulimit,setuid() 会像 fork() 一样失败。这是应用被利用的经典途径,Google 在 Android 上至少踩过两次坑(ADB 和 Zygote),都导致了提权漏洞。检查返回值,所有返回值都要检查!

    jwise0查看英文原文

    In a similar family, note also that setuid() can fail! If you try to setuid() to a user that has has reached their ulimit for number of processes, then setuid() will fail, just like fork() would for that user. This is a classic way to get your application exploited. Google did it (at least) twice in Android: once in ADB [1], and once in Zygote [2]. Both resulted in escalation. Check your return values! All of them! [1] http://thesnkchrmr.wordpress.com/2011/03/24/rageagainstthecage/ [2] https://github.com/unrevoked/zysploit

    引用《C 程序员十诫》强调必须检查错误码

    如果函数声明了在出错时返回错误码,你就必须检查那个错误码,哪怕检查会让代码膨胀三倍、手指敲得生疼;因为如果你觉得'倒霉事不会轮到我',诸神必将惩罚你的傲慢。(出自《C 程序员十诫》)

    spudlyo查看英文原文

    If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest "it cannot happen to me", the gods shall surely punish thee for thy arrogance. [0] [0]: http://www.lysator.liu.se/c/ten-commandments.html

    历次讨论

    同类还值得读

    1. TTY 揭秘(2008)

      The TTY demystified (2008)

      经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理,包括线路规程、终端驱动、信号与控制字符等机制。

      系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选
    2. 为什么 GNU grep 这么快

      Why GNU grep is Fast

      FreeBSD 邮件列表上一篇广为流传的帖子,解释 GNU grep 为什么快:核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O,让程序在搜索时“…

      系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.org
    3. Xplain:为普通人讲解 X11

      Xplain – Explaining X11 for the rest of us

      《Xplain》是作者(HN 用户 Jasper_)写的一系列 X11 长文,用他在浏览器中重建的 X11 绘图模型做交互演示,讲解 X11 的绘图模型与窗口系统设计。

      系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选
    4. 旋风教程:为 Linux 创建极小 ELF 可执行文件(1999)

      A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)

      breadbox 写于 1999 年的经典教程,主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。

      系统与基础设施上首页 6 次 · 2007–2025muppetlabs.com
    5. PostgreSQL 内部原理

      The internals of PostgreSQL

      《The Internals of PostgreSQL》是一本免费在线书籍,系统讲解 PostgreSQL 的内部实现,包括查询处理、并发控制、WAL、缓冲区管理等核心机制。

      系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。