星が広がる空 廣闊星空下
一人立ち止まって 一個人駐足
伝えられずにいる 傳達不到的思緒
この想い 見上げて 仰頭許下心願

目に見える物は 眼中映入的事物
全部 愛おしくて 全部都如此可愛
耳に届く音は 耳中傳入的聲音
何もかも 美しい 句句都如此美麗

星を 線で結んで 用線條將星星連起來
君を描いて 畫出你的樣子
瞳 の中に 映した 牢牢記在眼中
いつも 強がる 一直在 逞強的
私は突っぱねて 我一直在抗拒
本当は 君が居ないと 其實 沒有你
駄目なのに 就完全不行

遠く 遠く 続いてる空 向遠方延展的夜空
その向こうで 君は 何想う 那一端的你 在想什麼
いつか消える …
たま たま
向こうの世界は いつも 賑やか 對面的世界 總是很熱鬧
だけど どこか つまらなそうだ 但是 總覺得哪兒 有些無趣
『一緒に笑える』それだけのこと 『能一起歡笑』只有這一點
とても大切なこと 是最重要的事

ランコ ランコ
教えてくれた君への感謝は 你告訴我種種的感激之情
尽きないけど 「ありがとう」とは 無以言表 就連一句「謝謝」
照れくさくて 言えそうにない 都羞澀得 難以啓齒
今夜も 黙って乾杯 今晚也 默默乾杯

たま ランコ たま ランコ
「憂世鬱世」云々 嘆き節 聊起「憂世鬱世」云云 悲嘆處
肴に呷る 酒の苦味よ …
その花を 咲かせばあとは 那朵花 開了之後將如何
枯れるのが その定めか 就會枯了麼 宿命是如此麼
その命 散らしてつなぐ 那條命 將斷卻又續
思いを全て 受け取って 所思所想 全盤盡收
竹ノ花 竹之花

【七】 【七】
遠くに見ゆるその影に ふと過る 遠遠望去那背影 忽又消失
遠い日に交わした約束 遠久之日互換的約定
この手の届かぬところへ 歩み去る 漸漸走向伸手也無法觸及的地方
その背中に影を合わせて 將自己的身影重疊在那背影上
交わし足りぬ言葉 那些說不盡的對話
全てを胸に押し止め 全都壓在心底
ただただ願うのは 只是一心所願
愛した女の幸せか 所愛的女子是否幸福

竹ノ花 竹之花
咲けばただ 一旦開花的話
散るまでの身と聞けども 聽聞生命就僅剩到花謝爲止
その命の在る限り 只要那命還在
どうか生きてゆけと 還請一定要活下去
その幸せを願えばと …
君さえいなけりゃよかった 如果你從未出現過該多好
降り出した雨の中で 君に出会った時から 下起雨的那一刻 從遇到你那時起
君がいないということが 当たり前じゃなくなった 身邊沒有你的情況 就已經不再是平常
ああ こんなはずじゃない 啊 不應該是這樣的
ずっと自分勝手にさ 過ごせたはずなのに 明明一直是散漫地過着自己的日子
まるで僕じゃないような僕が さらけ出されてくよ 就像是帶出了不是我的另一面的我

君さえいなけりゃよかった こんな気持ちは知らないから 如果你從未出現過該多好 就不會知道這種心情
やらなくちゃいけないことが 手つかずのまま積もってく 一堆不得不做的事情 堆在手頭越積越多
僕じゃなくてもいいのなら こっちを見て笑わないでよ 如果不是我也可以的話 就別看着我這邊笑啊
大袈裟じゃなくてそれだけで 忘れられなくなるの 甚至那些不重要的事情 都變得難以忘記了

君の適当な話も 全部心に刺さります 你無意間隨口說的話 全都刺在心頭
気にしなけりゃいいのにな 残らずかき集めちゃうの 雖說只要不在意就可以了 卻一句不剩全收集了起來
ああ こんなはずじゃない こんなはずじゃない 啊 不應該是這樣的 不應該是這樣的 …
華咲 花開
望み望まれて此処に 此處有求有應
愛でたきものは此れに有り 此處有喜愛之物
夢と現と交えては 夢境與現世交匯時
幻想郷(幻の国) に、遊ぶがいい 可於幻想鄉玩

空を征く者がいる 有空中飛的
怪異を祓う者がいる 有驅散怪異的
其れ等を望む子等がいる 亦有期望她們的
御伽噺を耳にして 耳中聽聞怪誕軼事
思い巡らす其れ以上に 心中所思更爲怪異
生きる幻想が其処に居る 幻想中的生活正在彼處

何時の世も 凡世間
愛でたきものは 喜愛之物
往来の 往來的
童遊の 孩童遊戲
中にこそ有れ 亦正在此處

華咲 花開
真優雅、舞うたれば 當真優雅地翩翩起舞
華の都は、此れに有り 花都亦在此處
夢と現と交えては 夢境與現世交匯時
今日も変わりなく町角に 今日一如既往街頭巷角

華散 花落
口伝伝承 …

譯註

這篇是翻譯自 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 添加好用戶最初做的事情就是安裝 …

知乎 轉載

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

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

DebConf 14: Q&A with Linus Torvalds

我的回答:

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

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

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

知乎 轉載

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

原問題: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 核心協議提供的繪圖原語繪圖 …

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

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

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

本文中所有桌面截圖來自維基百科,不具有著作權保護。

早期的棧式窗口管理器

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

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