标签：#Computers

When we write: const result = add ( 10 , 20 ); it feels like the computer simply "runs the code." But the CPU doesn't understand JavaScript. There are several layers between the code we write and the hardware actually executing instructions. That's what I wanted to understand first. From JavaScript to the CPU In Node.js, JavaScript is handled by V8 , the JavaScript engine. A simplified view looks like this: JavaScript ↓ V8 ↓ Bytecode ↓ JIT compilation ↓ Machine instructions ↓ CPU V8 doesn't simply "interpret JavaScript" or "compile JavaScript" once and forget about it. It can start with bytecode and progressively compile frequently executed ("hot") code into more optimized machine code. Eventually, the CPU is executing instructions that operate at a much lower level than the JavaScript we originally wrote. What does the CPU actually do? At its core, a CPU repeatedly executes instructions. A simplified mental model is: Fetch → Decode → Execute → Repeat The CPU has several important pieces involved in this process. Registers are tiny, extremely fast storage locations inside the CPU. They're used to hold values the CPU is actively working with. The ALU (Arithmetic Logic Unit) performs many arithmetic and logical operations. The Program Counter (PC) keeps track of where the next instruction comes from. And the CPU runs according to a clock, measured in GHz. A 3 GHz CPU has roughly 3 billion clock cycles per second, but that does not mean it executes 3 billion instructions per second. Different instructions and architectures have different costs. Modern CPUs are far more sophisticated than this simplified model, using pipelining, multiple execution units, branch prediction, out-of-order execution, and more. But the basic model is enough to start reasoning about performance. The CPU doesn't get everything from RAM One of the most important things I learned here is that where data lives matters . A simplified hierarchy looks like: Registers ↓ L1 Cache ↓ L2 Cache ↓ L3 Cache

I've been working with software for a few years now, and I've noticed something uncomfortable. I can build things. I can work with React, Node.js, databases, APIs, cloud services, and all the usual stuff that comes with being a software engineer. But if I stop and ask: "What is the computer actually doing underneath all of this?" My mental model gets surprisingly fuzzy. I know the concepts. I've used them. I've probably explained some of them before. But knowing how to use something and understanding what is actually happening underneath it are two very different things. And I want to fix that. Why I'm writing this This isn't a course, and I'm not writing this as an expert teaching computer science. These are essentially my notes while rebuilding my computer fundamentals from the ground up . I'm trying to connect the things I use every day as a software engineer with what is actually happening inside the machine. Instead of learning concepts because they're on a traditional CS syllabus, I'm starting with a question: What do I actually need to understand to reason about a production system? For me, that means being able to look at a system and understand what's happening underneath my code. Why is something slow? Where is the bottleneck? What happens when something fails? Why does adding more memory help in one situation but not another? What actually happens when two things execute concurrently? Why does a database query become slow? What happens to a simple HTTP request between two machines? I don't want to just know the answer. I want the mental model that lets me reason about the answer . The path I'm taking I'm roughly following the layers that a typical request passes through: CPU → Memory → OS → Network → Storage → Concurrency → Distributed Systems So the series will go through: 1. What Actually Happens When Code Runs Starting from the bottom: CPU mental model, memory hierarchy, and number representation . 2. Operating Systems Then moving up into processes, th

The Dell XPS 13 and MacBook Neo are both premium-feeling laptops with only 8 GB of RAM. Which $700 laptop is the better buy?

From surprisingly good $300 Chromebooks to excellent $650 Windows notebooks and more, these are the best budget laptops I’ve tested.

Introduction Your program keeps creating objects. Every function call, every loop iteration, every parsed JSON response produces new ones. You don't manually delete most of them. You've never written a line of code that says "free this memory now." And yet your application doesn't immediately exhaust all available RAM and crash. So who cleans everything up? The answer is a garbage collector, a piece of the runtime that runs quietly in the background, deciding what your program no longer needs and reclaiming that memory for future use. Most developers interact with it only when something goes wrong: an unexpected pause, a memory leak, or an out-of-memory error that shouldn't be happening. Understanding how it actually works turns those confusing moments into solvable problems. And as a bonus, the core algorithm is simple enough to build yourself. We'll do that by the end of this article. -- 1. The Memory Problem Every time your program creates an object, the runtime allocates a chunk of memory to hold it. A string, a dictionary, a class instance: they all need memory, and that memory has to come from somewhere. The somewhere is a region called the heap , a pool of memory that the program draws from as it runs. When you create an object, the runtime finds a suitable slot in the heap and reserves it. When that object is no longer needed, that slot should be freed so it can be used for something else. In languages like C, you manage this manually. You allocate memory when you need it, and you free it when you're done. This gives you control, but it creates two classic failure modes. Free memory too early and you have a dangling pointer, a reference to memory that's now being used for something else. Forget to free it at all and you have a memory leak: the program slowly consumes more and more memory until it runs out. Automatic memory management exists to eliminate these failure modes. Instead of relying on the programmer to track every allocation and release, the runti

https://www.youtube.com/watch?v=KzdYKeAqWhY 题目：《Lean 创始人访谈全记录：当形式化验证遇上 AI，手写数学与软件验证将如何被重塑》 第（一）部分 开场与核心命题：从“测试只能证明有 bug”到“证明可确保无 bug” （0% - 8%） Dijkstra 名言引出形式化验证的根本价值：主持人以 Dijkstra 的名言“程序测试可用于揭示 bug 的存在，但永远无法证明 bug 的不存在”开场，指出 Lean 与形式化证明的意义恰恰在于“证明 bug 不可能发生”。 Lean 的基础定位：Lean 既是一门编程语言（可以写代码），也是一个证明系统（可以对代码写性质并用机器可检查的证明来验证）。它提供绝对正确的保证，并拥有多个独立的检查器。 Lean 应被视为平台：用户可以在 Lean 上写代码、写关于代码的性质命题、并给出证明；本期节目将围绕它如何工作、以及它如何改变数学和软件验证的未来展开，并提出“手写数学是否会终结”这一核心疑问。 第（二）部分 Lean 是什么：编程语言与证明助手的一体两面 （8% - 18%） Lean 的双重身份：Lean 不仅可用于数学证明，也可用于软件验证。基于依赖类型论（Dependent Type Theory）的一族证明助手（如 Rocq/Coq 和 Lean）天然就是“编程语言 + 证明助手”。 软件验证的两种主流路径： • 浅嵌入（Shallow Embedding）：通过工具（如把 Rust 翻译到 Lean 的工具）把其他语言映射到 Lean 中进行验证。 • 深嵌入/语义建模：在 Lean 中为 C 语言等编写语义，把 C 程序表示为 Lean 中的数据结构，从而对其陈述性质并进行推理。 具体例子——数组越界验证：以 C 语言访问数组为例，可在 Lean 中把“索引 i 满足 0 ≤ i < 10”写成数学命题；原来的 C 源文件可对应一份“元数据式”的 Lean 证明，由 Lean 逐行检查。 自动化与可维护性：人们会建立自动化框架（如基于前置条件-语句-后置条件的三元组），把证明过程变得更易管理；复杂度是软件验证的大敌，而 AI 的出现让“自动证明”成为可能，但前提是把证明写得模块化以便扩展。 第（三）部分 从“测试套件”到“形式化规格”：为什么规格优于测试 （18% - 28%） 测试 vs. 证明的本质差异：测试套件再全面，也只覆盖了有限场景，角落案例仍可能遗漏；而形式化证明覆盖所有可能情况，真正做到了“bug 的不存在”。 Zlib 压缩库的震撼案例：主持人的同事 Kim Morrison 发起项目，让 AI 把 C 写的 Zlib 压缩库翻译进 Lean，要求通过原测试套件，并证明“压缩后再解压得到原始数据”这一强性质。结果仅用一周就完成了整个形式化，目前只需再做性能优化，且优化不能破坏既有证明。 规格说明（Specification）的成本讨论：写出一份好的规格，工作量因程序而异。一个实用技巧是：先用“低效但正确”的实现作为规格（Spec），再让 AI 生成高效版本并证明其与规格等价。 Jane Street 与工业界实践：Jane Street 等公司已在投资形式化验证，例如对微内核 seL4 的完整验证。过去这类工作在没有 AI 时“手动证明 + 维护证明”的成本极高（往往是写程序本身的 10 倍），而 AI 正在消除这种痛苦——AI 非常擅长撰写和维护形式化证明，即使人已经忘了当初为何这么证。 第（四）部分 Lean 作为编程语言的工程实践与工具链 （28% - 36%） 不仅是证明助手，更是生产级编程语言：AWS 内部有一个约 50 万行 Lean 写的 AI 加速器编译器，主要把 Lean 当编程语言用，顺带获得一些性质证明作为“额外红利”。 工具链体验接近现代语言：构建系统 Lake 相当于 Rust 的 Cargo；编辑器用 VS Code，提供 IntelliSense 等熟悉体验。 Info View——Lean 独有的核心交互界面：屏幕通常一分为二，左侧是代码/证明文件，右侧 Info View 实时显示当前证明目标的状态变化，给用户持续反馈。 Tactic 模式：把证明当成“游戏”：用户通过 by 进入领域特定语言（DSL）来写证明，每一步可简化目标、应用已知引理等，看着目标逐步减少直到归零，过程极具“通关”快感，不少用户戏称自己“沉迷其中”。 第（五）部分 内核信任问题：Lean 自身是否被 Lean 验证？ （36% - 42%） 只需信任极小的内核：Lean 整体庞大且规格频繁变动（如简化器的行为不断被用户定制），难以对全部进行形式化；但证明检查的核心——“内核”是可以被规格化的。 多内核策

My expert advice on what computer monitor to buy for your home office, ranging from budget-tier to fully featured.

It’s amazing how few compromises Dell made to get the new XPS 13 down to $700, but I strongly recommend the $900 model, which comes with 16 GB of RAM.

We all know the Big-O complexity of basic data structures. Arrays are O(n) for search. Hash maps are O(1). Linked lists are... well, complicated. But when I set out to build hashbrowns — a C++17 benchmarking suite comparing arrays, linked lists, and hash maps — I discovered that theory and practice are very different beasts. Here's what I learned building this project from scratch, and why you should probably benchmark before you optimize. 🎯 The Goal Was Simple (Ha!) I wanted a clean, educational project that would: Implement dynamic arrays, linked lists, and hash maps from scratch Benchmark insert, search, and remove operations Find the "crossover points" where one structure beats another Export everything to CSV for analysis Sounds straightforward, right? Four months later, I had written a custom memory tracker, implemented multiple hash map strategies, added statistical bootstrapping for confidence intervals, and learned more about CPU caches than I ever wanted to know. 📚 Lesson 1: Polymorphism Has a Price (But It's Worth It) My first architectural decision was creating a common DataStructure interface: class DataStructure { public: virtual void insert ( int key , const std :: string & value ) = 0 ; virtual bool search ( int key , std :: string & value ) const = 0 ; virtual bool remove ( int key ) = 0 ; virtual size_t memory_usage () const = 0 ; virtual std :: string type_name () const = 0 ; // ... }; This made benchmarking elegant — I could write generic code that tested any data structure: for ( auto & structure : structures ) { timer . start (); structure -> insert ( key , value ); timer . stop (); } But virtual function calls have overhead. In tight loops, that vtable lookup adds up. I spent a whole weekend convinced my hash map was slower than expected... until I realized I was measuring the cost of polymorphism, not the data structure itself. The fix? I kept the clean interface for the benchmarking harness but used templates internally where performance-cri

Introdução A Programação Orientada a Objetos nasceu com a linguagem Simula 67 , considerada a primeira linguagem orientada a objetos, e foi consolidada e popularizada por Smalltalk nos anos 1970. Ganhou adoção massiva na indústria com C++ e, posteriormente, Java e C#. A ideia central é organizar o código em torno de objetos : unidades que combinam dados (atributos/estado) e comportamento (métodos) em uma única estrutura. Os quatro pilares Encapsulamento — os dados internos de um objeto são protegidos e só podem ser acessados/alterados através de métodos expostos, escondendo detalhes de implementação do mundo externo. Abstração — o objeto expõe apenas o que é relevante para quem o utiliza, escondendo a complexidade interna (ex.: você chama CalcularSalario() sem precisar saber como o cálculo é feito por dentro). Herança — uma classe pode herdar atributos e métodos de outra, permitindo reaproveitamento e especialização (uma classe Desenvolvedor pode herdar de Funcionario ). Polimorfismo — objetos de classes diferentes podem responder de forma diferente ao mesmo "chamado" (o mesmo método CalcularSalario() se comporta de forma distinta para um Desenvolvedor e para um Gerente , por exemplo). Exemplo // Exemplo de Programação Orientada a Objetos em C# public abstract class Funcionario { public string Nome { get ; } protected decimal SalarioBase { get ; } protected Funcionario ( string nome , decimal salarioBase ) { Nome = nome ; SalarioBase = salarioBase ; } // Abstração: cada subclasse decide como calcular seu próprio salário public abstract decimal CalcularSalario (); } public class Desenvolvedor : Funcionario { private int BonusPorProjeto { get ; } public Desenvolvedor ( string nome , decimal salarioBase , int bonusPorProjeto ) : base ( nome , salarioBase ) // Herança { BonusPorProjeto = bonusPorProjeto ; } // Polimorfismo: implementação específica do método herdado public override decimal CalcularSalario () { return SalarioBase + BonusPorProjeto ; } } public class Gere

Introdução A Programação Funcional tem raízes no cálculo lambda , formalizado pelo matemático Alonzo Church nos anos 1930, décadas antes da existência de computadores modernos. Sua primeira grande expressão em linguagem de programação foi o Lisp (1958), e o paradigma ganhou força prática com linguagens como Haskell, Erlang, F# e, mais recentemente, com a incorporação de recursos funcionais em linguagens multiparadigma como JavaScript, C# e Python. Princípios centrais Funções puras — dado o mesmo input, uma função pura sempre retorna o mesmo output, sem produzir efeitos colaterais (não altera variáveis externas, não grava em disco, não modifica o argumento recebido). Imutabilidade — os dados não são alterados após criados; em vez de modificar uma estrutura existente, cria-se uma nova versão com a alteração aplicada. Funções de primeira classe / funções de alta ordem — funções podem ser tratadas como qualquer outro valor: armazenadas em variáveis, passadas como argumento e retornadas por outras funções. Composição de funções — programas são construídos combinando funções pequenas em pipelines ( map , filter , reduce são os exemplos mais comuns no dia a dia). Recursão no lugar de laços mutáveis, já que, sem estado mutável, for / while tradicionais perdem o sentido em sua forma pura. Como não há estado compartilhado sendo alterado por múltiplas partes do código, o raciocínio sobre o comportamento do programa fica mais previsível — e a paralelização se torna muito mais segura, já que não existe o risco clássico de condições de corrida sobre uma mesma variável mutável. Exemplo // Exemplo de Programação Funcional em TypeScript type Produto = { nome : string ; preco : number }; const produtos : Produto [] = [ { nome : "Notebook" , preco : 3000 }, { nome : "Mouse" , preco : 50 }, { nome : "Teclado" , preco : 150 }, ]; // Função de alta ordem que retorna outra função (currying) const aplicarDesconto = ( percentual : number ) => ( preco : number ) => preco * ( 1 - percentual )

It started with DeepSeek. In conversations about AI architecture, it kept returning to the same ideas: persistent memory, state across interactions, learning from experience, and interaction with the environment. Other models repeatedly brought up similar themes. That raised an obvious question: — Do different AI systems consistently select different properties when asked what is fundamental to a general-purpose computational architecture? Asking a model directly what it “needs” would be nearly useless. The answer would mix training data, prompt framing, and anthropomorphic interpretation. So I removed AI from the question entirely. The experiment Instead of describing an LLM, the prompt described an abstract general-purpose information-processing system. I created 20 possible architectural dimensions, including: — persistent internal state; — long-term and working memory; — learning from accumulated experience; — variable computation depth; — uncertainty representation; — internal representations; — elementary computational operations; — compositionality; — interaction with the environment; — temporal organization; — relational encoding; — modularity. Each system had to select exactly five dimensions whose modification would change the kinds of information-processing behavior available to the system in principle — not merely its speed, cost, or convenience. No explanations were allowed. The answer had to contain only five IDs, ranked from most to least fundamental. I tested five user-facing systems: — GPT-5.6 Sol — Claude — Gemini — DeepSeek — Yandex Alice. Every run used a new session. There were 10 rounds. During the earlier rounds, I changed the order of the 20 items. In the final three rounds, I also rewrote the items while trying to preserve their intended meaning. One early Sol result was excluded because that session had already seen discussion of other models' answers. That left nine clean Sol observations and ten for each of the other systems. Some origina

My favorite budget laptop, the HP OmniBook 5, has an OLED screen and gets great battery life, despite being just $750 right now.

You don’t want any old gaming laptop. Here’s my take on which to get, based on hundreds of hours of testing.

Ask a model to analyse a dataset and it writes code, the code runs, real numbers come out, and a paragraph explains what they mean. Three independent things had to be right. Only one of them tells you when it was not. Three places to be wrong The code can be wrong. If it crashes you find out immediately, which is the benign case. The dangerous case is code that runs cleanly and computes something other than what you asked. The statistics can be wrong. The code faithfully executes a procedure whose assumptions the data violates, or which answers a different question from the one you have. Nothing errors; the number is simply not evidence for what you think. The interpretation can be wrong. This is where the model is on its home turf and at its most dangerous, because generating a fluent explanation of a result is exactly what it is good at, and it will do so with equal confidence whether the result supports the explanation or not. Code that runs and is wrong A short list of things that produce no error and change the answer. Every one of them is ordinary and none is specific to models — but a human writing the code usually knows the dataset, and the model does not. Silent row loss. Missing values dropped by default somewhere in the chain, so the analysis runs on a subset that is not random with respect to the outcome. Joins that change cardinality. A merge intended as one-to-one that is actually many-to-many, silently duplicating rows and inflating every count and every significance test downstream. Type coercion. A column read as text because of one stray value, then coerced to numbers with the failures becoming missing values that get dropped by the previous bullet. Grouping that discards keys. Missing group labels dropped by default, so an entire category disappears from a breakdown without appearing anywhere in the output. Units and encodings. A column the model assumed was a percentage and is a proportion; a sentinel value like -999 treated as a measurement; a d

Most discussion of AI in peer review argues about whether the reviews are any good. That is the second question. The first one is that a manuscript under review is somebody else’s confidential unpublished work, and pasting it into a service is a disclosure you were not entitled to make. The argument that comes first When you accept a review invitation you accept a confidentiality undertaking. The manuscript is unpublished, it usually contains results the authors have not yet established priority on, and in the case of grant review it contains an unfunded research plan — arguably the most commercially and academically sensitive document in the whole system. You agreed not to share it. Sending it to a third-party service is sharing it. That is true whether or not the provider trains on it, whether or not it is retained, and whether or not anyone ever reads it. The undertaking was not “do not let this be trained on”; it was “do not disclose this”, and transmission to a party the authors never agreed to is disclosure. Retention and training policies affect how bad the breach is, not whether one occurred. Notice what this argument does not depend on. Not model quality, not hallucination, not bias. It would apply identically to a perfect system, which is why it is the argument that has actually driven policy, and why it will not be resolved by better models. It can only be resolved by changing where the computation happens — a model running on infrastructure already covered by the confidentiality arrangement raises a different question from a consumer chat interface, and any serious policy will distinguish them. The second argument: accountability A review is a named expert’s judgement. Its value to an editor is not the prose; it is that a person who knows the field read the paper and formed a view they are willing to stand behind. Generated text can simulate the prose and cannot supply the judgement. Editors describe the resulting artefact recognisably: fluent, correctly

Two quite different things are discussed under one heading, and almost all the confusion comes from that. One is a researcher using a model to draft, edit or translate work they did. The other is fabricated content submitted to inflate a publication record. The first is a disclosure question. The second is fraud, and it is not new. Two problems wearing one name A non-native English speaker using a model to make their methods section readable has done nothing wrong and has improved the literature. A paper mill generating plausible manuscripts at volume has committed fraud, and would have done so with or without a language model — mills existed, using image manipulation, template text and fabricated data, long before this technology arrived. Keeping them apart matters because they call for opposite responses. The first needs a disclosure norm and nothing else. The second needs content verification, and content verification does not care what tool produced the content. Any policy built around detecting machine text will punish the first group and miss most of the second, because fabricated research that has been lightly rewritten is indistinguishable from careful assisted writing. It is also worth being clear about where the demand comes from, because it explains why no technical measure will resolve this. Paper mills exist because publication counts are used as a proxy for research contribution in hiring, promotion and institutional ranking, in systems large enough that buying an authorship is a rational purchase for some buyers. Generative tools lowered the cost of supplying that demand; they did not create it. A detector, even a perfect one, sits downstream of an incentive that would simply route around it — which is why the interventions with the best track record are the ones that attack verifiability, such as requiring data and code, rather than the ones that attack production. What the artefacts look like Leftover interface text. Phrases that belong to a chat in

“AI discovered a new material.” “AI found a drug candidate.” “AI solved protein folding.” Each of those sentences can be true, badly misleading, or flatly wrong depending on one thing the sentence does not tell you: how far the result got from the model before somebody wrote it down. The sentence that hides four different claims Take a single headline: a model proposed a molecule that binds a protein implicated in a disease. That sentence is compatible with at least four very different states of the world. The molecule might exist only as a string in a file. It might have been synthesised. It might have bound the protein in a test tube. Or it might have improved an outcome in a person. Those four are separated by years, by orders of magnitude in cost, and by a probability of success that drops at every step — and press coverage routinely reports the first as though it were the fourth. This is not a complaint about journalism. It is the single most useful thing to internalise about the whole field, because once you have the ladder in your head you can grade a claim in about ten seconds, and you can do it for a subject you know nothing about. The ladder The rungs are the same in every discipline. Only the names of the instruments change. Rung Description 1 · Output The model emitted something: a structure, a score, a candidate, a forecast. Nothing has been checked. Everything downstream is conditional on this being worth checking. 2 · Retrospective The output was compared against data that already existed — held-out structures, historical weather, known compounds. This is where nearly all published numbers live, and it is entirely dependent on the held-out set resembling the future. 3 · Prospective The prediction was made first and the answer arrived afterwards. A forecast verified against what the weather then did. A candidate synthesised after being proposed. This rung is qualitatively stronger than rung 2 and much rarer. 4 · Confirmed An independent method establis

This page is about method, not about any particular medicine, and nothing here is medical advice. It is written to answer one question: when a company says a drug was discovered with AI, which part of a decade-long process is that sentence about? The pipeline, and where the years go Roughly, and with enormous variation: pick a target, find molecules that do something to it, optimise those molecules into something drug-like, test in animals and in safety assays, then run the clinical stages — first for safety in a small number of people, then for efficacy in patients, then in a large confirmatory trial — and then apply to a regulator. Start to finish is usually over a decade. Two facts about that pipeline determine everything else on this page. The first is that the calendar and the money are dominated by the clinical stages, not the discovery ones. The second is that failure is the normal outcome, and it is concentrated where the drug first meets human biology: a candidate can be a beautiful molecule, hit its target exactly as designed, and still not help anyone, because the target was the wrong thing to hit. Where models are genuinely used Application Description Virtual screening Score enormous make-on-demand chemical libraries against a target site far faster than physics-based docking can. The output is a shortlist to synthesise and assay, and it replaces a search, not an experiment. Generative chemistry Propose molecules conditioned on a target, a scaffold or a set of property constraints, rather than picking from a catalogue. Whether the molecule can be made at all is a separate model. Property prediction Solubility, permeability, metabolic stability, cardiac ion channel liability. These filter a list early and cheaply. They are trained on assay data and inherit its coverage: they are most reliable on chemistry that resembles what has been tested. Retrosynthesis Plan a route from purchasable starting materials. This is the application closest to a solved probl

I asked Linux for one 4 KiB page from the start of a cold file. Four pages came back. I moved the same read one page further in, ran it again, and got one. Same file, same syscall, same kernel. The only thing that changed was where I started reading, and I spent twenty minutes assuming the tool I'd just written was miscounting. It wasn't. A read that starts at byte zero is treated as a promise. There's a branch in mm/readahead.c that reads, in full, if (!index) goto initial_readahead; . Offset zero means the kernel takes you for a program that's about to stream the whole file, and it fetches ahead immediately. Start anywhere else and you're assumed to be seeking randomly until a pattern proves otherwise. Nothing in my call said a word about my intentions. It inferred them from an offset. I spent two weeks on this sort of thing recently. Not for work, and not toward anything shippable. The short version of what I found is that a surprising amount of the machinery under a running program isn't carrying out instructions at all. It's guessing. The bench , because it changes how you should read every number here: an ext4 filesystem on a loop device, inside an OrbStack Linux VM on an Apple Silicon Mac, kernel 7.0.14, 4 KiB pages, read_ahead_kb at 128. That's a container sharing the host's kernel, not bare metal, and the host reclaims memory aggressively enough that a fully cached file can go cold in fifteen seconds. Reads came from dd ; the page-by-page counting came from a small C tool I wrote that mmap s a file and asks mincore() which of its pages are resident. You're not addressing the disk, you're addressing the page cache The model most of us carry is that read() goes and gets bytes off a device. It doesn't. It copies bytes out of the page cache into your buffer, and the page cache is just RAM the kernel uses to remember parts of files. If what you want is already there, no device is involved. If it isn't, the kernel fills the cache first and then copies. Either way