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

    互联网与文化blog.burntsushi.net

    我的自由开源软件故事

    My FOSS Story

    2次上首页
    1年跨度
    919累计得分
    214条评论

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

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

    导读

    这是 ripgrep 作者 Andrew Gallant(burntsushi)的长文自述,讲述他多年维护 ripgrep、Aho-Corasick 等知名开源项目的心路历程:如何在有本职工作的情况下坚持写 FOSS,如何面对喷子和负面反馈,以及如何设定边界、管理情绪、有分寸地沟通。文章坦诚讨论了开源维护者常被忽视的心理负担。

    为什么经久不衰:它真实呈现了开源维护者的情感与心理代价,并给出了设定边界、理性沟通等实用心得,对任何参与或依赖开源的人都有持久价值。

    关键词 开源维护ripgrep心理健康设定边界

    HN 评论精选

    沉默的多数用户感激维护者的付出,喷子的声音不代表社区全貌

    喷子比潜水者声音大得多,我们这些沉默的大多数知道构建免费工具要付出多少时间和汗水。白天有全职工作还要维护人们想用的大型项目,精神消耗极大,尤其收到的还都是负面评价。我爱读你的 Rust 代码,读 ripgrep 源码和 Aho-Corasick 的构建过程让我着迷,正是这些让我爱上了 Rust。

    k4ch0w查看英文原文

    Burntsushi, Andrew. My man. You don't know me, we have never talked but bro I admire the shit out of you. Trolls are much louder than lurkers. There are a silent majority of us that know how much time and sweat goes into building free tools. We appreciate what you do because you do it for love of being a hacker and showing everyone else how you did it. I don't think people realize how hard it is having a day job and then building a huge project people want to use. It's mentally taxing. It sucks even more when it's only negative things. Life is already hard man, why do these people have to keep trolling you? It's enough to make you want to flip the desk and give it all up. I love reading your Rust code, and seeing how active you are on reddit/hacker news. Going through how you built the Aho Corasick crate and comments on you trying to reverse hyperscans teddy algo. was amazing for me. I spent so many hours that day reading ripgrep source code. I was amazed and what you did and the comments everywhere about why, like why the printer was pull/push. The whole time, I was geeking over what you did so much that you started my love of Rust. Anyways, thanks for just being you man.

    文章关于情绪、沟通和依赖审查的段落尤其值得细读

    摘录几段喜欢的段落:作者坦言自己是情感驱动的人,情绪可以成为改进代码的内在动力;深思熟虑的沟通很重要,否则即使正确也可能因表达方式而适得其反;即使是作者本人,也不可能审查自己依赖的每一行代码。

    faitswulff查看英文原文

    By no means a summary of the article, but I liked these passages in particular: On emotions: > When I was a young adult, I'd pride myself on being “logical” and “free of emotional decision making.” Like all good lies we tell to ourselves, there's a kernel of truth to it. But for the most part, at least for me personally, I am a deeply emotional being. > Emotions run deep and can be a really useful well to tap for intrinsic motivation. For example, for some time after ripgrep was released, I began to immediately hate touching the code that was responsible for printing search results. It was convoluted, buggy and difficult to change. While rewriting is a perfectly logical decision to make on purely technical grounds only, I was motivated to do it because I didn't like the way it made me feel. My emotion helped drive me to make things better for myself. On communicating thoughtfully in order to communicate effectively: > ...being thoughtful in one's communication is important to advance your cause. If you're thoughtless, even if you're correct, you risk working against your own ends because the person on the other end might not be able to look past your thoughtlessness. On the fact that even the author can't and doesn't read every line of every dependency they pull in: > ...As someone who uses FOSS and tries hard to be discriminating with the dependencies I use, it is just not possible for me to review every line of code I depend on. Even if I could somehow manage to read it all, I certainly wouldn't be able to understand it all in enough detail to be confident that it was doing what I thought it was doing.

    不对他人抱期待、不在意他人眼光,是开源维护者的必修课

    作为维护过大型开源项目的人,我深有同感。我的两点成长心得:一是不要用自己的标准要求所有人、不对任何人抱期待,生活会少很多失望;二是别太在意别人怎么想,做到这点后连喷子都伤不到你了。

    silisili查看英文原文

    As someone who worked on a sizeable open source project, I sympathize with all of this. For me, part of growing as a person and making my own life easier were two things. First, to not hold everyone else to your own standards. That is, don't expect anything from anyone. Life gets a lot less disappointing that way. The other is to stop dwelling on what other people think. This one is hard, but if you can truly get there life gets a lot less stressing, programming included - you don't take such offense to the trolls. I think it's an unspoken part of aging and learning. You rarely see a shy old guy in the locker rooms. All that said, as a complete aside, I have tremendous respect for Mr Gallant. Everything he writes is gold, and if you haven't yet, I'd recommend taking a look at his awesome open source projects.

    社区缺少给开源作者正面反馈的合适渠道

    在 GitHub 上给 FOSS 项目正面反馈的惯例是什么?在 issue 里夸奖会给后来读帖的人添噪音。GitHub 有没有专门用于表扬的 issue 类型?还是该私下联系作者?我想在每天安装各种包时有个快速表达感谢的方式。

    tppiotrowski查看英文原文

    What is the convention for giving positive feedback to FOSS projects on Github? Giving positive feedback on an issue thread adds noise for future people reading the thread. Does Github have an issue type for praise? Do you attempt to get the authors email address and contact them directly? Do you star the repo? I'd like a quick way to show my appreciation throughout the day as I `yarn add` various packages...

    历次讨论

    同类还值得读

    1. 如今电脑上几乎所有操作在感知上都比 1983 年更慢(2017)

      Almost everything on computers is perceptually slower than it was in 1983 (2017)

      2017 年的推文串认为,尽管计算机硬件比 1983 年快得多,日常操作的感知速度却常常更慢:启动、界面响应和网络应用被层层抽象、动画、后台检查与网络依赖拖累。

      互联网与文化上首页 5 次 · 2017–2020twitter.com
    2. 网站肥胖危机

      The Website Obesity Crisis

      Maciej Cegłowski(idlewords)的经典演讲文稿《网站肥胖症危机》,批评现代网页越来越臃肿:动辄数 MB 的 JavaScript、追踪脚本和广告,把本可以轻…

      互联网与文化上首页 5 次 · 2016–2021idlewords.com编辑精选
    3. 亚马逊那本标价 23,698,655.93 美元的苍蝇书

      Amazon’s $23,698,655.93 book about flies

      博文讲的是亚马逊上一本关于果蝇的二手书被标到 23,698,655.93 美元。

      互联网与文化上首页 5 次 · 2011–2022michaeleisen.org
    4. 浏览器 User-Agent 字符串的历史

      History of the browser user-agent string (2008)

      2008 年的经典文章用戏谑的“创世纪”口吻,讲述浏览器 User-Agent 字符串如何从简单的标识演变成层层叠加的伪装:浏览器为了绕过按 UA 分发的网站检测,纷纷把自己伪装…

      互联网与文化上首页 5 次 · 2012–2022webaim.org编辑精选
    5. 最后的问题——艾萨克·阿西莫夫

      The Last Question - Isaac Asimov

      阿西莫夫最著名的短篇科幻小说《最后的问题》的在线全文。

      互联网与文化上首页 5 次 · 2009–2019multivax.com编辑精选

    打赏支持

    打赏二维码

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

    WeChat

    关注向阳乔木

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

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

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