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 生成,可能有误。

    系统与基础设施0x46.net

    点文件乱象

    Dotfile madness

    2次上首页
    3年跨度
    1,338累计得分
    695条评论

    2019 — 2022,它一次次回到首页

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

    导读

    这是一篇 2019 年的博客文章,批评 Linux 桌面上的"dotfile 之乱":各种程序擅自在用户主目录里丢下隐藏的配置文件和目录,而不遵守 XDG Base Directory 规范(把配置、缓存、数据分别放到 ~/.config、~/.cache、~/.local/share 等标准位置)。作者认为这既是污染,也让用户难以判断某个文件是谁创建的、能否删除。

    为什么经久不衰:家目录污染是每个 Linux/Unix 用户都会反复撞上的老问题,文中对"为什么该用 XDG 目录"的论证至今仍是这类讨论的标准参考,2022 年再度上首页说明问题远未解决。

    关键词 dotfilesXDGLinux家目录污染

    HN 评论精选

    真正的祸害是非隐藏文件(如 ~/snap),连改环境变量都躲不掉。

    在我看来真正的问题不是 dotfile,而是应用偷偷在我家目录里创建的普通(非隐藏)文件——作者也提到这点尤其糟糕。主目录里的点文件在 Linux 上不算新鲜事(.bashrc、.profile、.emacs 等),虽然更多应用改用 XDG 目录会更好;而且我 ls 时看不到它们,也就不烦我。但如今很多应用似乎觉得不问一声就往我家目录放普通文件没问题,这简直是野蛮行径。尤其是 Ubuntu 现在全力押注 snap,用 snap 就会在家目录建一个非隐藏的 snap 文件夹。 madness!有人抱怨时开发者还厚着脸皮说这没问题。我抽象上喜欢 snap/flatpak 的思路,但在它们改好、不再不问就建非隐藏文件之前,我绝不使用 snap。当然,这还叠加了操作系统"贴心"地替我建 Documents、Music、Video 等文件夹并把 XDG 环境变量指过去的时髦做法。不过至少那种情况用户还能改环境变量、删掉那些蠢文件夹,~/snap 就没这福气了。

    nycticorax查看英文原文

    To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't bother me. But nowadays, lots of applications seem to think it's OK to put normal files in my home folder without asking first. This is just outright barbarism. In particular, Ubuntu now seems like it's all-in on snaps, and if you use snaps, they create a non-hidden "snap" folder in the user's home folder. Madness! And when people complain, the devs have the gall to suggest that this is all fine: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053 I like the idea of snap/flatpak in the abstract, but until they get their act together, and stop creating non-hidden files in my home folder without asking first, I am never going to use snaps. And of course, all this is on top of the new fashion for the OS to "helpfully" create Documents, Music, Video, etc folders in my home folder, and set the XDG environment variables to point to them. Noooooope. But at least in that case the user can change the environment variables and delete the stupid folders. No such luck with ~/snap.

    根子在于缺少应用沙箱和权限隔离,而不只是文件放哪儿。

    真正的问题是:我运行的任何应用都以同等权限访问我所有的文件。App1 和 App2 不该往我家目录写数据,不该读彼此的数据,更不该能写彼此的数据。一个电子游戏能读我的报税表,搞什么。移动端和平板系统已经解决了这个问题,所有平台都得跟上。在那之前,基本每个应用都该跑在 Docker 容器里,那样它爱干什么干什么。

    sakoht查看英文原文

    The real problem is that any app I run accesss all files I own with equal permissions. App1 and App2 shouldn’t write their data to my home, or read each other’s data, or, please, be able to write each other’s data. A video game can read my tax forms. WTF. Mobile & tablet OSs solve this. Everything has to follow. Until then, basically every app should run in a docker container. Then it can do what it wants.

    反对首次运行即生成配置文件:既污染家目录,也让新选项无法被发现。

    "你多半会想在程序第一次运行时创建一个带合理默认值的配置文件"——请别这么做。把示例配置放进文档(/usr/share/PROG..)并在手册里提一句就好。统计上用户会装几百个应用,但只会定制其中一小部分,所以首次运行就无条件生成配置是家目录污染的最大元凶之一。另一个理由是版本升级:首次运行就生成配置,等于把那个版本的选项集合永久固化下来,以后新增了选项用户根本不会知道。

    theamk查看英文原文

    > You will most likely want to create a default configuration file with sane and sensible default values the first time your program is executed. Please don't. Include the example configuration in your docs (/usr/share/PROG..) and mention it in the manual. Statistically user will have hundreds of apps installed but will only ever customize a small fraction them. So creating config unconditionally on first run is one of the worst contributors to homedir pollution. Another argument is version upgrades: if you create configur on first run, you forever bake in the set of options present in that version. If later a new option is added, user will have no idea about it.

    Windows 上照搬 Unix 点文件同样荒谬,应该用 %APPDATA% 和隐藏属性。

    我个人觉得更离谱的是 Windows 上那些 Unix 优先软件(比如 ssh)的半吊子移植版创建的 dotfile 和点目录。Windows 有 %APPDATA% 和 %LOCALAPPDATA%,可以通过 ShGetKnownFolderPath 配合相应的 KNOWNFOLDERID 访问,所有程序都该把配置和缓存放在这些路径下。Windows 也不认识文件名/目录名开头的点是什么意思,它和 NTFS 有(可以说更好的)隐藏文件属性 FILE_ATTRIBUTE_HIDDEN,在创建或查询文件/目录时就能设置/读取,而不用拿正则去匹配一个句点。最讽刺的是微软自家软件也在 Windows 上创建点文件和点目录。

    delta_p_delta_x查看英文原文

    What I personally find more egregious are dotfiles and dot-dirs on Windows, created by half-baked ports of Unix-first software (such as `ssh`). Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths. Windows also doesn't know what the dot at the beginning of a file/folder means. Instead, it and NTFS have something that's arguably better: a hidden file attribute `FILE_ATTRIBUTE_HIDDEN`[2], that's again settable/gettable when a file/directory is created or polled, rather than regex-ing for a full-stop. The worst irony is Microsoft software creating dot-files and dot-dirs on Windows[3][4][5]. [0]: https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderpath [1]: https://learn.microsoft.com/en-us/windows/win32/shell/knownfolderid [2]: https://learn.microsoft.com/en-gb/windows/win32/api/fileapi/nf-fileapi-setfileattributesa?redirectedfrom=MSDN [3]: https://github.com/dotnet/sdk/issues/8678 [4]: https://github.com/OmniSharp/omnisharp-roslyn/issues/953 [5]: https://github.com/microsoft/vscode/issues/3884

    历次讨论

    同类还值得读

    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

    关注向阳乔木

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

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

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