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

    系统与基础设施phiresky.github.io

    在 GitHub Pages 或任意静态托管上托管 SQLite 数据库

    Hosting SQLite databases on GitHub Pages or any static file hoster

    3次上首页
    4年跨度
    2,097累计得分
    314条评论

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

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

    导读

    这篇博客介绍了一个巧妙的方案:利用 HTTP Range 请求,让浏览器直接对托管在 GitHub Pages 等任意静态主机上的 SQLite 数据库文件执行 SQL 查询,只按需下载所需的数据块。作者为此实现了 sql.js-httpvfs 库,把一个 668MB 的数据库以静态文件的方式变成了可查询的 Web 数据库。

    为什么经久不衰:它把'静态托管'和'动态数据库查询'这两个看似矛盾的需求结合在一起,无需任何服务器后端,是低成本发布小型数据集的持久经典方案。

    关键词 SQLite静态托管HTTP Range前端

    HN 评论精选

    用实际数据展示按需加载的效率:668MB 数据库只需 54KB 请求即可完成查询。

    打开浏览器开发者工具的网络面板,试试这条 SQL 查询,感受它有多聪明:select country_code, long_name from wdi_country order by rowid desc limit 100。它只新获取了 54.2KB 数据(49 个小 HTTP 请求)就返回了 100 条结果——而整个静态托管的数据库文件有 668.8MB!

    simonw查看英文原文

    Pop open the network pane in the browser tools and try running this SQL query for a demo of how clever this is: select country_code, long_name from wdi_country order by rowid desc limit 100 It fetches just 54.2KB of new data (across 49 small HTTP requests) to return 100 results - from a statically hosted database file that's 668.8MB! I have an animated GIF demo of this here: https://twitter.com/simonw/status/1388933800445452290

    指出核心机制就是 HTTP Range 请求头,可以直接在 XHR 中使用。

    我的疑问被这行代码解答了:xhr.setRequestHeader("Range", "bytes=" + from + "-" + to)。我有点惊讶居然可以直接这么做。

    tlb查看英文原文

    The question I had is answered by this line of code: xhr.setRequestHeader("Range", "bytes=" + from + "-" + to); I am a little surprised you can just do that. In https://github.com/phiresky/sql.js-httpvfs/blob/master/src/lazyFile.ts

    认为这是极具创意的技巧,Range 请求的思路可推广到更多文件格式。

    这轻松是我今年见过的最聪明的 Web 编程技巧。我见过它被用于视频或音频,但从没想过能用在数据库上。应该还有很多其他格式也适合这种做法。

    ianlevesque查看英文原文

    This is easily the most clever web programming hack I’ve seen this year. Bravo. I had seen this used for video or audio of course but it never occurred to me you could use it for databases. There are probably a ton of other formats this is good for too.

    指出 HTTP Range 与压缩不兼容这一历史遗留问题限制了该技术的进一步优化。

    HTTP Range 头的一大痛点是与 HTTP 压缩完全不兼容。这源于 HTTP 早期的歧义:开启压缩后请求字节范围,指的是未压缩流还是压缩流中的范围?唯一合理的答案是未压缩版本的范围,再实时压缩以节省带宽。但几十年前的这个设计决定至今阻碍着 Range 请求的有效使用——服务器和 CDN 都拒绝压缩 206 Partial Content 响应,而 SQLite 数据块其实往往可以显著压缩。视频流不受此影响,因为视频本身已压缩、没有冗余可去。

    apignotti查看英文原文

    A point of great pain for me in the use of HTTP range headers is that they are absolutely incompatible with HTTP compression. This boils down to an ambiguity found in the early days of HTTP: when you ask for a byte range with compression enabled, are you referring to a range in the uncompressed or compressed stream? The only reasonable answer, in my opinion: a range of bytes in the uncompressed version, which is then compressed on-the-fly to save bandwidth. I suspect the controversial point was that originally HTTP gzip encoding was used via pre-compression of the static files. On-the-fly encoding was probably too computationally expensive at the time. Anyway, the result of this choice done decades ago is currently preventing effective use of the ranged HTTP requests. As an example, it is fairly likely that chunks from the SQLite database can be significantly compressed, but both HTTP servers and CDN refuse to compress "206 Partial Content" replies. Interestingly, another use case of HTTP byte ranges is video streaming, which is not affected by this problem since video is _already_ compressed and there is no redundancy to remove anymore.

    历次讨论

    同类还值得读

    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

    关注向阳乔木

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

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

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