知乎 轉載

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

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

我的回答:

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

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

DebConf 14: Q&A with Linus Torvalds

然後接下來就是我承諾的翻譯了 ...

知乎 轉載

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

原問題:C语言中“.”与“->”有什么区别?

除了表达形式有些不同,功能可以说完全一样阿。那为何又要构造两个功能一样的运算符? 效率有差异?可是现在编译器优化都那么强了,如果真是这样岂不是有些多此一举


刚刚翻了下书,说早期的C实现无法用结构直接当作参数在函数间传递,只能用指向结构的指针在函数间进行传递!我想这应该也是最直观的原因吧。

我的回答

首先 a->b 的含義是 (*a).b ,所以他們是不同的,不過的確 -> 可以用 * . 實現,不需要單獨一個運算符。 嗯,我這是說現代的標準化的 C 語義上來說, -> 可以用 * . 的組合實現。

早期的 C 有一段時間的語義和現代的 C 的語義不太一樣。

稍微有點彙編的基礎的同學可能知道,在機器碼和彙編的角度來看,不存在變量,不存在 struct ...

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

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

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

PacVis
Demo of PacVis

我爲什麼要做 PacVis

我喜歡 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 是這樣畫圖的:

ditaa diagram

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

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

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

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

桌面隱喻(Desktop Metaphor) 中每個窗口只佔用顯示面積的一小部分, 有其顯示的位置和大小,可以互相遮蓋。於是棧式窗口管理器就是在圖形界面中實現桌面隱喻的核心功能, 其實現方式大體就是:給每個窗口一個相對的“高度”或者說“遠近”,比較高的窗口顯得距離用戶比較近, 會覆蓋其下比較低的窗口。繪圖的時候窗口管理器會從把窗口按高低排序,按照從低到高的順序使用 畫家算法 繪製整個屏幕。

我的 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 指出,一個人覺得簡單的事情對別人並不一定是簡單的。 搜了一下我自己寫的東西,的確很多地方寫了「簡單 ...

2015年2月21日更新

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

寄宿在 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 上受大牛 quininerlilydjwg 點播, 發現 cloudflare 有提供 免費的支持 SSL 的 CDN 服務 趕快去申請了一個,感覺非常讚,於是就換過來了。

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

2015年2月14日更新

不知不覺間放任這邊長草很久了,從上次 折騰主題 到現在都快三年了, 而從上次 寫了篇告白信 到現在也有快兩年了。 這期間曾經把主題配色從 Bootstrap 2 默認的 白底黑字改成了讓眼睛更舒適的黑底白字,也不過是用 drop-in 的配色方案而已,沒有本質上的改進。

洞中一日世上千載,兩年裏 Bootstrap 已經升上 v3.3 , 而 Pelican 則已經升到 3.5 了。 早就眼饞 Bootstrap 和 Pelican 中的諸多新功能新設計,不過無奈於時間有限只能飽飽眼福。

近日想寫的東西越積越多,終於下定決心花了前前後後 兩個月 的時間重新設計了一遍 Pelican 的主題,配合一些我覺得有用的插件。於是本博客就變成你們現在看到的樣子了。 (以及本篇博文也用了兩個月的時間寫完,其間還發了幾篇別的短文,算是恢復寫博客的嘗試吧。)