最近几个月在这个博客发了不少歌词翻译 似乎有要转型成音乐博主的趋势 ,前段时间买了个新域名 sak.uy ,准备专门用来放这些东方歌曲的歌词翻译,于是分设了单独的博客「 Sakuya的音乐盒 」。主博客这边右侧边栏会有到音乐盒的链接。

曾经在这边的那些歌尽量保持 URL 跳转过去,新的歌词翻译会发到那边去,还想继续听歌的话请继续订阅那边的 RSS 呀。

主博客这边还是像往常一样保持记录生活点滴和技术经验好了。说道介绍技术, 有人问过我那些日语歌词上给汉字标注的假名都是我一个个手输的么? 一开始是手输的,后来发现了不错的自动化方案,于是这里介绍一下。

首先是 python-furigana

这是个 python 写的小程序(严格说是库),可以把一段日文转换成标准的 HTML 形式的 <ruby> 标签的振假名( ()仮名(かな) )。 它本身只是个方便的格式化库,实际工作是用 python-mecab 这个 binding 去查询 mecab 这个著名的日语语料分析库。要用它还得配合一些开源的 mecab 词典,这些在 …

惠狐 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 添加好用户最初做的事情就是安装 …

知乎 转载

和上篇文章一样,这篇也是来自一个知乎上我回答的问题。

原问题:为什么 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 的桌面

我们知道最初图形界面的应用程序是全屏的,独占整个显示器(现在很多游戏机和手持设备的实现仍旧如此)。 所有程序都全屏并且任何时刻只能看到一个程序的输出,这个限制显然不能满足人们使用计算机的需求, 于是就有了 窗口 …

我的 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 …