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

    编程与软件工程features.jsomers.net

    我如何逆向工程 Google Docs,以回放任意文档的击键

    How I reverse-engineered Google Docs to play back any document's keystrokes

    3次上首页
    6年跨度
    996累计得分
    273条评论

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

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

    导读

    作者逆向分析了 Google Docs 的实时协作协议(基于 Operational Transformation),利用文档自身的修订历史,把任意一篇文档从空白到定稿的每一次输入、粘贴和删除都还原并回放出来。文章既展示了协议细节,也引出了“云端文档永远记得你做过什么”的隐私与法律问题。

    为什么经久不衰:它把人人都在用却看不见的底层机制拆开给人看,而由此暴露的“编辑历史永久留存”问题,随着云办公普及和数据取证常态化,今天比 2014 年更值得警惕。

    关键词 Google Docs逆向工程操作变换隐私

    HN 评论精选

    Google 内部工程师证实,作者逆向出的协议细节大部分是对的,令人佩服。

    这篇博客 2014 年首次发布时,我正在 Google Slides 团队工作。Slides 和 Docs 关系极近,共享大量代码(当时办公位置甚至挨着)。整个团队都对作者逆向还原出的操作变换协议细节印象深刻,而且大部分都还原正确。据我所知,我们的工程总监后来还约他吃了顿午饭。

    erickj查看英文原文

    I was working on the Google Slides team at the time this blog post was originally published back in 2014. Slides and Doc are extremely closely related projects, sharing lots of code (and even sitting next to eachother, at the time at least). Our entire team was impressed with the details of the operational transform protocols that the author was able to reverse engineer, and for the most part get correct. IIRC our engineering director ended up calling the guy up for a lunch.

    从 OT 到 CRDT 的技术脉络解释了这套机制为何可行。

    考虑到 Google Docs 可追溯到 Google Wave 的历史及其操作变换(Operational Transformation)架构,这完全说得通,了解这段历史的话甚至有点显而易见。协作编辑的新替代方案是无冲突复制数据类型(CRDT)。

    parasubvert查看英文原文

    Given the history of Google Docs dating back to Google Wave with its architecture of Operational Transformations, this makes perfect sense and is a bit obvious if you know the history. https://en.wikipedia.org/wiki/Operational_transformation The new alternative to this approach for collaborative editing (and large scale distributed database concurrency without locks) are CRDTs: https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

    修订历史本就对用户可见,与其说是隐私漏洞不如说是技术亮点。

    我不理解为什么大多数评论都在谈隐私,而不是技术本身。这真的算隐私泄露吗?Google 从上线起就存储修订历史,这一点一直很明显——在界面里本来就能查看完整的修订记录……

    morgante查看英文原文

    I don't understand why most of the commenters here are focusing on the privacy implications rather than the technical aspects. Is this really a privacy breach? It's been obvious that Google stores revision history since it launched—you've always been able to access a thorough revision history in the UI itself...

    完整编辑历史一旦可被还原,将在法律取证中带来灾难性后果。

    等到律师在诉讼取证时要求提供文档历史,这会捅开一个巨大的马蜂窝。你以为重要的是最终那份合同、专利申请或产品规格?当律师、监管者和诉讼方想对付你时,你得从时间起点开始为每一次修改辩护。“是的,我们知道最终合同怎么写,但根据你 2003 年 1 月 7 日下午 5:21 的那次编辑,你的真实意图是……”

    cantrevealname查看英文原文

    This is going to open a huge can of worms when lawyers demand the document history for discovery. You think that the final contract, patent application, user manual, or product specification you wrote is what matters? When the lawyers, regulators, law enforcement, and litigious people want to get you, you'll have to defend every edit back to beginning of time. "Yes, we know what the final contract says, but based on your edit on January 7, 2003, at 5:21 pm and 0.210403 microseconds, your real intent was ...". "And then on June 12, 2006, you took out some words that have a bearing on this lawsuit -- obviously you were trying to cover things up." I was quite surprised to learn that during patent litigation for example, the history and changes made to your application do matter. I assumed that the final patent as issued is what matters and everything else is irrelevant. Well, lawyers have made it matter, and now things will be 10,000 times worse when they want to find something to argue. So great, now we have to worry about how someone might interpret every single edit rather than the final document.

    历次讨论

    同类还值得读

    1. 开源应用架构

      The Architecture of Open Source Applications

      《开源软件架构》(AOSA)是一本在线免费书,邀请知名开源项目的作者亲自剖析其内部设计,涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。

      编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选
    2. 编程语言简史:简短、不完整且多半错误

      A Brief, Incomplete, and Mostly Wrong History of Programming Languages

      一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章,用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。

      编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.com
    3. SQLite 是如何测试的

      How SQLite is tested

      SQLite 官方文档页,系统介绍 SQLite 的测试体系:多种测试方法(TCL 测试、模糊测试、回归测试、静态分析等)和海量测试用例,展示了这个小型开源项目如何靠极致测试获得…

      编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选
    4. 高级编程语言(2009)

      Advanced programming languages (2009)

      Matt Might 的经典文章,按用途推荐“高级编程语言”:如果追求就业就选主流语言,如果追求表达力、学术研究或创业,则推荐 Haskell、OCaml、Scala 等函数式语…

      编程与软件工程上首页 8 次 · 2009–2022matt.might.net
    5. 我的 Forth 与栈机器经历

      Yosefk - My history with Forth & stack machines

      作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程:既赞叹其简洁优雅、代码量小、可自举的优点,也坦率指出栈操作在实际编程中的痛苦,以及 Forth 社区文化中的问题。

      编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选

    打赏支持

    打赏二维码

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

    WeChat

    关注向阳乔木

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

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

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