從 知乎 轉載

和上篇文章一樣，這篇也是來自一個知乎上我回答的問題。

原問題：为什么 Linus Torvalds 不愿意将 Linux 变成 GPLv3 授权？

我的回答：

這裏有段 Linus Torvalds 在 DebConf 14 上的 Q&A: https://youtu.be/1Mg5_gxNXTo?t=47m20s

其中關於 GPLv3 和協議的那一段在47:20開始到57:00左右。 裏面 Linus 對自己的觀點澄清得很清楚了。 看u2b或者聽英語有困難的請留評論，我抽空可以試着翻譯一下。

從 知乎 轉載

轉載幾篇知乎上我自己的回答，因爲不喜歡知乎的排版，所以在博客裏重新排版一遍。

從今天起本博客將啓用 GitHub Issue 作爲留言系統。 原本使用的 Disqus 將繼續保留一段時間，目前沒有關閉的計劃。

換用 GitHub Issue 是計劃了好久的事情了，最初重做這個主題的時候就有考慮過。 這個想法的契機是看到了這篇 GitHub hosted comments for GitHub hosted blogs ，然後立馬覺得這個想法很符合寄宿在 GitHub Pages 上的博客。 一個限制是要求評論者必須有 GitHub 賬戶，考慮到我的博客的受衆這個要求估計不算太過分。 使用 GitHub Issue 的好處麼，比如自帶的 GFMD 富文本格式，郵件通知，還有訂閱和取消訂閱通知，郵件回復， 這些方面都不比第三方留言系統遜色。

換用 GitHub Issue 另一方面原因是最近聽說 Disqus 被部分牆了，想必以後牆也會越來越高。之前曾經試過在這個博客換上多說， 然而效果我並不喜歡，多說喜歡侵入頁面加很多奇怪的東西 …

在上篇文章 「桌面系統的混成器簡史」 中我介紹了其它桌面系統中的混成器的發展史和工作原理， 話題回到我們的正題 Linux 系統上，來說說目前 X 中混成器是如何工作的。 這篇文章將比上一篇深入更多技術細節，不想看太多細節的可以直接跳過看 結論 。

原始的 X 的繪圖模型

首先，沒有混成器的時候 X 是這樣畫圖的：

X 的應用程序沒有統一的繪圖 API 。GTK+ 在 3.0 之後統一用 Cairo 繪圖， 而 Cairo 則是基於 PDF 1.4 的繪圖模型構建的， GTK 的 2.0 和之前的版本中也有很大一部分的繪圖是用 Cairo 進行， 其餘則通過 xlib 或者 xcb 調用 X 核心協議提供的繪圖原語繪圖 …

（原本是想寫篇關於 Wayland 的文章，後來越寫越長感覺能形成一個系列， 於是就先把這篇背景介紹性質的部分發出來了。）

Linux 系統上要迎來 Wayland 了，或許大家能從各種渠道打聽到 Wayland 是一個混成器，替代 X 作爲顯示服務器。 那麼 混成器 是個什麼東西，桌面系統爲什麼需要它呢？ 要理解爲什麼桌面系統需要 混成器 （或者它的另一個叫法， 混成窗口管理器(Compositing Window Manager) ），在這篇文章中我想回顧一下歷史， 瞭解一下混成器出現的前因後果。

首先介紹一下混成器出現前主要的一類窗口管理器，也就是 棧式窗口管理器(Stacking Window Manager) 的實現方式。

早期的棧式窗口管理器

棧式窗口管理器的例子，Windows 3.11 的桌面

我們知道最初圖形界面的應用程序是全屏的，獨佔整個顯示器（現在很多遊戲機和手持設備的實現仍舊如此）。 所有程序都全屏並且任何時刻只能看到一個程序的輸出，這個限制顯然不能滿足人們使用計算機的需求， 於是就有了 窗口 …

我的 RSS 訂閱着一個博客叫 The Old New Thing ，作者是Windows開發者之一的 Raymond Chen ，記錄 Windows 中的很多有趣的技術細節。 這個博客中的一些精彩內容還被他寫成了一本書，中文名叫《Windows編程啓示錄》 (ISBN: 978-7-111-21919-4) 而英文書名就叫 The Old New Thing — Practical Development Throughout the Evolution of Windows (ISBN: 978-0-321-44030-3)。

今天看到這個博客的一篇文章說 你用「簡單地」次數越多我越懷疑你不懂這個詞的意思 ， 描述他看到某個博客上指導讀者打開命令行、執行某條魔法命令、從命令輸出抽取參數、 改寫配置文件、用魔法命令重啓服務，並把這些工作描述爲「簡單地」。

的確正如 Raymond 指出，一個人覺得簡單的事情對別人並不一定是簡單的。 搜了一下我自己寫的東西，的確很多地方寫了「簡單 …

上次介紹過 這個博客改換了主題 ， 本以爲這個話題可以告一段落了，沒想到還能繼續寫呢。

寄宿在 Github Pages 上的靜態博客通常有兩種方案，其一是使用 Jekyll 方式撰寫，這可以利用 Github Pages 原本就有的 Jekyll支持 生成靜態網站。另一種是在 本地 也就是自己的電腦上生成好，然後把生成的 HTML 網站 push 到 Github Pages ，這種情況下 Github Pages 就完全只是一個靜態頁面宿主環境。

我用 Pelican 生成博客，當然就只能選擇後一種方式了。這帶來一些不便，比如本地配置 pelican 還是有一點點複雜的，所以不能隨便找臺電腦就開始寫博客。有的時候只是想修正一兩個錯別字， 這時候必須打開某臺特定的電腦纔能編輯博客就顯得不太方便了。再比如 pelican 本身雖然是 python 寫的所以跨平臺，但是具體到博客的配置方面， Windows …

最近 mazk 說我 life 分類裏的文章太少 ，所以想了想寫了這篇。

很多人問過我爲什麼要來日本留學，嘛原因之一是我英語太差了，相對而言日語比較好。 另一方面，我比較喜歡日本的學術氛圍。這個當然是主觀體會，而不是客觀的評價，只是我 覺得相對於 歐美喜歡研究基礎架構技術 ， 日本則偏向實用層面 。

說個具體一點例子，最近看到這篇新聞說 卢布贬值影响中央气象台预报准确率？ ，其中提到：

因为卢布贬值，天气预报的准确率会有所降低

也說道：

不过经我多年的观察，中国中央气象台的预报准确率实在是不怎么样，具体到我生活的地区， 实际天气状况和中国中央气象台预报的出入较大……

相信不少人也有類似的體會。

天氣預報是事關人們生活的重要信息，其準確度對生產生活當然有很大影響。 說到增加天氣預報的準確度，人們自然會想到高性能的超級計算機比如 天河二號 ，想到環繞在地球高空的 氣象衛星 ，想到遍佈世界各地的氣象站觀測臺。想想這麼多耗資不菲的高尖端項目被國家投入， 用來改善天氣預報的準確程度，看起來這的確是一個困難的科研課題。

話說回來，準確預測氣溫、氣壓、溼度、降水概率等等這些事情對於生產生活固然重要， 不過對一般民衆而言，天氣預報最重要的作用就只是回答 明天我該穿多厚的衣服，出門是否需要打傘 這種問題 …

透明計算 具體是什麼，因爲他們沒有公開技術細節所以我並不知道，只是看 公開出來的演示視頻 ，感覺似乎只要能從手機上遠程登錄系統桌面，就能算是透明計算了。 如果透明計算真是這個意思，那麼我似乎已經用着這個技術很多年了嘛。

Xorg 上常用的遠程桌面工具有很多，基於 VNC 協議的、基於NX的和基於 RDP 協議的都能找到， 直接 ssh X forwarding 效果也不錯。只是這些方案的一個 不太易用 的地方在於，需要 通過 ip 訪問到遠程的電腦，所以在跨越 NAT 之類的情況下不太容易使用。

於是今天介紹一個使用方便設置也簡單的方法： 通過 chrome-remote-desktop 在 archlinux 上使用遠程桌面。這個方案的優勢在於，藉助 Google 的雲端服務器（內部貌似是XMPP協議下的握手） 方便地實現了 NAT 穿透，無論什麼網絡環境基本都能使用。當然，要支持遠程登錄， 位於遠端的登錄的計算機必須一直開着 …

上個月就在 狗爹(godaddy) 上買了個自己的域名 farseerfc.me 準備用在這個 博客上，當時試着轉到過這個域名，發現 自定義域名(custom domain) 只支持 http 不支持 https ，想着還要買自己的證書，於是就扔在了一旁。不用自定義域名的話， 放在 github.io 上是可以用 HTTPS 的。 今天在 #archlinux-cn 上受大牛 quininer 和 lilydjwg 點播， 發現 cloudflare 有提供 免費的支持 SSL 的 CDN 服務 趕快去申請了一個，感覺非常讚，於是就換過來了。

設置的方法按照 這篇博文 說的一步步做下來，如它所述，用 CloudFlare …