上週翻譯完 【譯】替 swap 辯護：常見的誤解 之後很多朋友們似乎還有些疑問和誤解，於是寫篇後續澄清一下。事先聲明我不是內核開發者， 這裏說的只是我的理解， 基於內核文檔中關於物理內存的描述 ，新的內核代碼的具體行爲可能和我的理解有所出入，歡迎踊躍討論。
這種誤解進一步的結論通常是：「使用虛擬內存肯定會減慢系統運行時性能，如果物理內存足夠爲什麼還要用虛擬的？」 這種誤解是把虛擬內存和交換區的實現方式類比於「虛擬磁盤」或者「虛擬機」等同的方式， 也隱含「先用物理內存，用完了之後用虛擬內存」也即下面的「誤解3」的理解。
首先，交換區（swap） 不是 虛擬內存。操作系統中說「物理內存」還是「虛擬內存」的時候在指程序代碼 尋址時使用的內存地址方式，使用物理地址空間時是在訪問物理內存，使用虛擬地址空間時是在訪問虛擬內存 …
這篇翻譯自 Chris Down 的博文 In defence of swap: common misconceptions 。 原文的協議 是 CC BY-SA 4.0 ，本文翻譯同樣也使用 CC BY-SA 4.0 。其中加入了一些我自己的理解作爲旁註，所有譯註都在側邊欄中。
翻譯這篇文章是因爲經常看到朋友們（包括有經驗的程序員和 Linux 管理員）對 swap 和 swappiness 有諸多誤解，而這篇文章正好澄清了這些誤解，也講清楚了 Linux 中這兩者的本質。值得一提的是本文討論的 swap 針對 Linux 內核，在別的系統包括 macOS/WinNT 或者 Unix 系統中的交換文件可能有不同一樣的行爲， 需要不同的調優方式。比如在 FreeBSD …
這是一個很有意思的問題，你可以試着先猜一下。
基於對系統中保存文件的瞭解，可能有這樣的思考過程：
問題中「大多數」其實是個挺不精確的稱呼，換個精確點的問法：你覺得你的系統中 文件大小的中位數 大概在什麼範圍內？或者說，文件系統中 文件大小的分佈情況 一般是怎樣的曲線？
這個問題其實還有多種別的問法，比如：一個常見的桌面或者服務器系統中，多大的文件算大文件， 多小的文件算小文件，什麼範圍內的大小算是普通呢？
經歷過基本的科學教育的人 …
上篇 「柱面-磁頭-扇區尋址的一些舊事」 整理了一下我對磁盤類存儲設備（包括軟盤、硬盤，不包括光盤、磁帶）的一些理解， 算是爲以後討論文件系統作鋪墊；這篇整理一下我對閃存類存儲設備的理解。
這裏想要討論的閃存類存儲是指 SSD 、SD卡、U盤、手機內置閃存等基於 NAND 又有閃存轉換層的存儲設備（下文簡稱閃存盤），但不包括裸 NAND 設備、3D Xpoint （Intel Optane）等相近物理結構但是沒有類似的閃存轉換層的存儲設備。 閃存類存儲設備這幾年發展迅猛，SD卡和U盤早就替代軟盤成爲數據交換的主流， SSD 大有替代硬盤的趨勢。 因爲發展迅速，所以其底層技術變革很快，不同於磁盤類存儲技術有很多公開資料可以獲取， 閃存類存儲的技術細節通常是廠商們的祕密，互聯網上能找到很多外圍資料， 但是關於其如何運作的細節卻很少提到。所以我想先整理一篇筆記，記下我蒐集到的資料，加上我自己的理解。 本文大部分信息來源是 Optimizing Linux with cheap flash drives 和 A Summary on …
在 SSD 這種新興存儲設備普及之前，很長一段時間硬盤是個人計算機的主要存儲設備。 更往前的磁帶機不常見於個人計算機，軟盤的地位很快被硬盤取代，到 SSD 出現爲止像 MiniDisc 、 DVD-RAM 等存儲設備也從未能挑戰過硬盤的地位。硬盤作爲主要存儲設備，自然也影響了文件系統的設計。
這篇筆記稍微聊一聊硬盤這種存儲設備的尋址方式對早期文件系統設計的一些影響，特別是 柱面-磁頭-扇區尋址（Cylinder-head-sector addressing, 簡稱CHS尋址）的起源和發展。 大部分內容來自維基百科 Cylinder-head-sector 詞條 這裏只是記錄筆記。現今的硬盤已經不再採用 CHS 尋址，其影響卻還能在一些文件系統設計中看到影子。
如右圖所示，一塊硬盤(Hard Disk Drive, HDD)是一個圓柱體轉軸上套着一些磁碟片(platter)， 然後有一條磁頭臂(actuator arm)插入磁碟片間的位置 …
zfs 這個東西倒是名不符實。叫 z storage stack 明顯更符合。 叫 fs 但不做 fs 自然確實會和 btrfs 有很大出入。我反而以前還好奇為什麼 btrfs 不弄 zvol ， 直到我意識到這東西真是一個 fs ，名符奇實。—— 某不愿透露姓名的 Ext2FSD 開發者
Btrfs 和 ZFS 都是開源的寫時拷貝（Copy on Write, CoW）文件系統，都提供了相似的子卷管理和 快照(snapshot）的功能。網上有不少文章都評價 ZFS 實現 CoW FS 的創新之處，進而想說「 Btrfs 只是 Linux/GPL 陣營對 ZFS …
ZFS 在設計之初源自於 Sun 內部多次重寫 UFS 的嘗試，背負了重構 Solaris 諸多內核子系統的重任，從而不同於 Linux 的文件系統只負責文件系統的功能而把其餘功能（比如內存髒頁管理， IO調度）交給內核更底層的子系統， ZFS 的整體設計更層次化並更獨立，很多部分可能和 Linux/FreeBSD 內核已有的子系統有功能重疊。
似乎很多關於 ZFS 的視頻演講和幻燈片有講到子系統架構，但是找了半天也沒找到網上關於這個的說明文檔。 於是寫下這篇筆記試圖從 ZFS 的早期開發歷程開始，記錄一下 ZFS 分層架構中各個子系統之間的分工。 也有幾段 OpenZFS Summit 視頻佐以記錄那段歷史。
惠狐 megumifox 寫了篇 用PulseAudio將電腦的聲音用手機放出來 ，文末提到想知道我怎麼用樹莓派轉發 USB 的，於是寫篇文章記錄一下。
家裏有個裝了 Arch Linux ARM 的樹莓派3B 閒置着，裝了 Arch Linux ARM 偶爾上電更新一下，
不過因爲性能實在不適合做別的事情於是一直在吃灰。某日 給老婆安利幻想萬華鏡和老婆看片
的時候， 老婆不吃安利於是遷怒鍵盤鼠標鍵盤鼠標被長長的 USB 線扯着感覺很難受
，於是偶發奇想，能不能利用一下樹莓派的多達 4 個 USB 2.0 端口接鼠標鍵盤呢，
這樣鼠標鍵盤就可以跟着樹莓派來回走，不用拖着長長的 USB 線了。
上網搜了一下， Linux 環境有個 usbip 工具正好能做到這個。原理也很直觀， usbip 能把 USB …
這篇是翻譯自 Brandon Invergo 的博客的英文文章 Using GNU Stow to manage your dotfiles 。 Brandon Invergo 的博客採用 CC-BY-SA 3.0 授權，因此本文也同樣採用 CC-BY-SA 3.0 ，不同於其它我寫的文章是 CC-BY-NC-SA 4.0 授權。
我自己已經使用此文中介紹的方案管理 我自己的 dotfiles 快 3 年了。最早想採用這樣的管理方案是爲了方便在多臺 Arch Linux 系統之間同步配置， 後來逐漸主力系統也更新換代了一次，又同步到了自己的 vps 上去，目前管理多個 Arch Linux 上都多少都有這套配置。甚至裝好 Arch Linux 添加好用戶最初做的事情就是安裝 …
從今天起本博客將啓用 GitHub Issue 作爲留言系統。 原本使用的 Disqus 將繼續保留一段時間，目前沒有關閉的計劃。
換用 GitHub Issue 是計劃了好久的事情了，最初重做這個主題的時候就有考慮過。 這個想法的契機是看到了這篇 GitHub hosted comments for GitHub hosted blogs ，然後立馬覺得這個想法很符合寄宿在 GitHub Pages 上的博客。 一個限制是要求評論者必須有 GitHub 賬戶，考慮到我的博客的受衆這個要求估計不算太過分。 使用 GitHub Issue 的好處麼，比如自帶的 GFMD 富文本格式，郵件通知，還有訂閱和取消訂閱通知，郵件回復， 這些方面都不比第三方留言系統遜色。
換用 GitHub Issue 另一方面原因是最近聽說 Disqus 被部分牆了，想必以後牆也會越來越高。之前曾經試過在這個博客換上多說， 然而效果我並不喜歡，多說喜歡侵入頁面加很多奇怪的東西 …
我喜歡 Arch Linux ，大概是因爲唯有 Arch Linux 能給我對整個系統「瞭如指掌」的感覺。 在 Arch Linux 裏我能清楚地知道我安裝的每一個包，能知道系統裏任何一個文件是來自哪個包， 以及我爲什麼要裝它。或許對 Debian/Fedora/openSUSE 足夠熟悉了之後也能做到這兩點， 不過他們的細緻打包的結果通常是包的數量比 Arch 要多個 3 到 10 倍，並且打包的細節也比 Arch Linux 簡單的 PKGBUILD 要複雜一個數量級。
每一個裝過 Arch Linux 的人大概都知道，裝了 Arch Linux 之後得到的系統非常樸素，按照
ArchWiki 上的流程一路走下來的話，最關鍵的一條命令就是
pacstrap /mnt …
在上篇文章 「桌面系統的混成器簡史」 中我介紹了其它桌面系統中的混成器的發展史和工作原理， 話題回到我們的正題 Linux 系統上，來說說目前 X 中混成器是如何工作的。 這篇文章將比上一篇深入更多技術細節，不想看太多細節的可以直接跳過看 結論 。
首先，沒有混成器的時候 X 是這樣畫圖的：
X 的應用程序沒有統一的繪圖 API 。GTK+ 在 3.0 之後統一用 Cairo 繪圖， 而 Cairo 則是基於 PDF 1.4 的繪圖模型構建的， GTK 的 2.0 和之前的版本中也有很大一部分的繪圖是用 Cairo 進行， 其餘則通過 xlib 或者 xcb 調用 X 核心協議提供的繪圖原語繪圖 …