从今天起本博客将启用 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 …

最近 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日更新

前言: 新天新地,将一切都更新了 [1]

不知不觉间放任这边长草很久了,从上次 折腾主题 到现在都快三年了, 而从上次 写了篇告白信 到现在也有快两年了。 这期间曾经把主题配色从 Bootstrap 2 默认的 白底黑字改成了让眼睛更舒适的黑底白字,也不过是用 drop-in 的配色方案而已,没有本质上的改进。

洞中一日世上千载,两年里 Bootstrap 已经升上 v3.3 , 而 Pelican 则已经升到 3.5 了。 早就眼馋 Bootstrap 和 Pelican 中的诸多新功能新设计,不过无奈于时间有限只能饱饱眼福。

近日想写的东西越积越多,终于下定决心花了前前后后 两个月 的时间重新设计了一遍 Pelican 的主题,配合一些我觉得有用的插件。于是本博客就变成你们现在看到的样子了。 (以及本篇博文也用了两个月的时间写完,其间还发了几篇别的短文,算是恢复写博客的尝试吧 …

现在这里的界面风格要从 Google 在 I/O 2014 大会 上公布Android L 也即 后来的 Lollipop 说起。 他们在谈论界面设计的时候公布了他们的 设计准则: Material Design (中文非官方翻译 )。 当然这只是一些准则,总结并描述了之前在 Web 设计和移动端 App 界面设计方面的一些规范, 并且用材料的类比来形象化的比喻这个准则。关于 Material Design 的更多中文资料可 参考这里

看到 Material Design 之后就觉得这个设计风格非常符合直觉,于是想在这边也用上 Material Design。 但是我在 Web 前端科技树上没点多少技能点,所以想找找别人实现好的模板 或者框架直接套用上。在网络上搜索数日找到了这几个:

Polymer Paper Elements

Polymer
Polymer logo

Google …

这篇也是源自于水源C板上板友的一个问题,涉及Linux上的控制台的实现方式和历史原因。因为内容比较长,所以在这里再排版一下发出来。 原帖在这里

可以设置不带缓冲的标准输入流吗?

WaterElement(UnChanged) 于 2014年12月09日23:29:51 星期二 问到:

请问对于标准输入流可以设置不带缓冲吗?比如以下程序

#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
    FILE *fp = fdopen(STDIN_FILENO, "r");
    setvbuf(fp, NULL, _IONBF, 0);
    char buffer[20];
    buffer[0] = 0;
    fgets(buffer, 20, fp);
    printf("buffer …