最近终于把博客升级到了 WordPress 6（是的我并没有抛弃我的博客……），经过了多年争议之后 Gutenberg Block Editor 终于成为了默认，很是不适应。还好最近因为工作需要使用 Notion，学习曲线还不算太陡峭。
然而更大的问题是使用多年的 CodeColorer 插件终于也彻底坏掉了——只要启用就连首页都无法渲染出来。在尝试了多个新插件之后终于发现了这个宝贝：Enlighter，不但少有地支持 inline & block，甚至还提供了 CodeColorer 等插件的兼容模式！谢天谢地不需要批量修改旧文章……
ThinkPad BIOS/UEFI 中的 Startup 标签页里，有一项叫做“Boot Order Lock“的功能，我一直不明白它的作用。官方解释是：
If you select Enabled, the boot priority is locked for your future use.
然而令我纳闷的是，如果我有权限修改 BIOS/UEFI 设置的话，我自然也可以关掉这个选项然后再调整启动顺序。要知道启动顺序本来就需要 BIOS/UEFI 的管理员权限（即使用“管理员密码”）修改，普通用户（即使用的是“开机密码”）的话这些设置都是灰的（事实上普通用户除了能开机以外几乎就没有能改的 BIOS/UEFI 设置）。至于开机使用 F12 选择一次性的启动设备则是由另一个选项控制的。难道这个 Boot Order Lock 设置只是一个鸡肋的双保险？
与此同时，在折腾 Linux UEFI 引导（使用的是 rEFInd ）时，我发现其中一步一直无法成功—— efibootmgr 修改 UEFI EEPROM 的启动项（包括增删启动项或者调整顺序）看起来成功了，但是重启后修改总是丢失。以至于我一直以为是 ThinkPad UEFI 支持度不够，最后使用的是修改已有的 Windows Boot Manager 启动项，将其指向 rEFInd。
直到有一天，我突然反应过来——难道这个启动顺序重启后被重置的问题，是 Boot Order Lock 导致的？试验了一下，立马证实了我的想法——关闭这个选项后 efibootmgr 就能正常修改启动顺序了。事实上，这个选项打开时， Windows 下的 Easy UEFI 之类的软件也遇到一样的重启后修改丢失的问题。原来，这个选项的真实目的和作用就是禁止 OS 修改 UEFI EEPROM 里记录的启动顺序……
今天在调试一个其他问题时碰巧发现了一个奇怪的情况：根据我的 RewriteRule ，明明应该被 rewrite 到静态 HTML 缓存的请求，却在返回的 HTTP 头里看到了 PHP ！这个 rewrite 规则应该是经过测试的，怎么突然就失效了？
第一怀疑对象是自己手贱。毕竟是个人 VPS 上的 Apache 配置，也没有使用版本控制之类的，不能确定是不是改过什么。就排查了一下。结果发现 RewriteLogLevel 这个配置竟然无效了？一查才发现，原来 Apache 2.4 里把 rewrite 日志合并到了 error 中，只需要在错误日志里加上 rewrite:traceN 就行了（其中 N 是错误级别，4足够，8应该是最详细的）。盯着错误日志看了半天，发现一个“有趣”的现象——明明已经正确匹配、 rewrite 到了静态文件，却又接着发起了 sub request ，请求了 index.php ？！
为了更好说明问题，我把我的配置简化了一下，大概是这样：
新年的第一篇博客，感谢正在阅读的你。新年快乐！新年新气象，由于种种原因，我最后下定决心把博客整体迁移到 HTTPS 。简单记录一下过程。
申请的是 StartSSL 的免费版证书。体验很一般。整个网站响应缓慢，界面一股十年前的风格，还动不动丢失 session 必须重新来过，周末晚上也不提供服务。一开始使用了宿舍地址，被拒绝；人工沟通后被告知要使用个人的永久地址，折腾了好几次才办下来。不过也因此确定了一件事情：整个验证服务很多关键点上都是客服人工操作，直接回复发验证码过来的那个邮箱竟然在很短时间内就收到了客服的答复（赞一下效率）。不过还是觉得，有些地方明显是可以程序自动化的，期待今年夏季要上线的 Let’s Encrypt 。另外，鉴于 StartSSL 的用户体验，愿意掏一点点钱的话，可以去 namecheap 买最便宜的那个证书，一年也只要10刀，省心不少。
部署的话网上有很多文档了。首先（或者说，应该在申请证书的时候）应该自己先搞清楚一些公私钥体系的基本概念：根证书、 CA 、服务器证书、服务器私钥这些是什么东西。简单来说 HTTPS 的核心是一个公私钥加密系统，私钥必须保密存放在服务器上，公钥（证书）会被服务器传送给客户端使用。为了确保这一对密钥真的属于这个服务器，还构建了一套信用体系：浏览器内置了若干 Root CA ，这些 CA 可以信任（签署）其他下级 CA 或者是某个服务器证书。浏览器拿到服务器发来的证书时就会检查这个信任链。如果任何一环的签署有问题（甚至干脆就是自己给自己签发的），就会变成“不可信证书”。
GNU Octave 的目标就是制作一款类似 MATLAB 的开源数学软件，在它的 bug tracker 分类里就直接有一项： Matlab Compatibility ，维基百科里也说可以认为这就是一个“ Software Clone ”。然而事实上，通过在这学期的 Numerical Analysis 课程中使用 Octave 替代 MATLAB 的经历，发现两者不兼容的地方还是有很多的。总结起来就是，不要对 portability 抱有太大幻想，几乎所有大型 MATLAB 都需要人工修改才能 port 到 Octave 上。
由于不小心把水杯打翻，水从散热孔流入机身，我的 T430s 在不到两年之后就光荣退役了，成为了我使用时间最短的一台电脑……本来 T 系列是有一定防水能力的，水从键盘上面浇下去顶多怀个键盘。可不巧从散热孔进去，电源模块烧掉了，又不能单换，只能换主板……最后，由于加拿大维修费太贵，我咬牙决定买台新电脑—— ThinkPad X1 Carbon 2nd Gen ，14寸轻薄超极本却有 i7 4600U ， 8G 内存， 256G 硬盘，最关键的是—— 2560×1440 高分辨率屏幕！之前说我的 T430s 1600×900 的分辨率就已经很高，如今这个就可真是实打实的高分屏了。脑热买下后才突然担心起来——这接近苹果 retina 级别的屏幕用起来该不会很痛苦吧？ Windows 和 Linux 对高分屏的支持有没有苹果那么好呢？使用了一周后，我可以对各位想要尝试高分屏的朋友说一句——放心吧！
UPDATE: GNOME Terminal 从 3.12 的某个小版本后就不再设置 COLORTERM 环境变量，因而判断是否是 GNOME Terminal 的方法变得更加 tricky 了。
其实标题有点歧义， GNOME Terminal 本来就支持256色，不过也许是为了最大兼容，它并没有设置环境变量来声称自己支持。所以，只需要 export TERM=xterm-256color 就能让命令行程序知道终端支持256色了。把它加进你的 .bashrc 或者 .profile ，打开一个新 Bash 或者新 session 看看你的终端程序（比如 vim ）等等是不是颜色丰富了一些呢？
另外，如果你使用 tmux （byobu），可以修改你的 .tmux.conf 文件（ byobu 则是 .byobu/.tmux.conf ），让 screen/tmux 会话也更漂亮一些：
set -g default-terminal "screen-256color"
不过等等！修改 TERM 变量其实是一件很危险 + tricky 的事情，尤其当你使用 screen/tmux 之类东西的时候（参见 tmux FAQ ）……而且，你很有可能使用不止一种终端模拟器/tty，非 GNOME Terminal 也许就不支持256色，甚至压根不是 xterm 系，这样设置 TERM 可能导致 terminfo 出错。
折腾了很久（期间顺便弄清楚了这几个配置文件分别是在什么时候、什么情况下以什么顺序加载）。最后挑选了一个最佳方案，即在 .bashrc 中加入这一段：
if [[ ($COLORTERM == gnome-terminal || $(cat /proc/$PPID/cmdline) == *gnome-terminal* ) && $TERM != screen* ]]; then export TERM=xterm-256color fi
如此便仅在 GNOME Terminal 、且不在 screen/tmux 会话中时设置为 xterm-256color 。此外，如果你有使用一些快捷键等方式快速启动 Byobu/screen/tmux ，那么要注意检查一下快捷键所对应的命令应该类似： env TERM=xterm-256color byobu （这类直接调用一般不会执行 .bashrc ）。（事实上， Archlinux 的 byobu 包中带的 byobu.desktop 的启动参数正是如此。）
最后上张图：
Update: Firefox 40 起已经默认启用 Linux 下的 OMTC 支持（见这篇开发博客），无需再按照本文说明强制手动开启。
UPDATE: 发现开启 (Fixed)layers.offmainthreadcomposition.async-animations 会导致右键菜单无法响应鼠标位置，必须使用键盘控制。推荐关闭。
最近在玩儿一些 HTML5 游戏的时候发现我的 Firefox 图形渲染似乎比之前卡了很多。明明很早之前就强制开启了硬件加速却没觉得有效果。在 about:support 中一看，“GPU 图像加速窗口”竟然又变成了 0/1 Basic ，虽然下面的“WebGL 渲染器”正确识别到了我的 Intel 集显。根据文档，这说明部分启用了硬件加速，但由于不支持硬件合成器，所以事实上是把内容交给显卡计算后再读取出来显示。
搜索一番，看到这篇博客： No more main-thread OpenGL in Firefox (important note for Linux users who use OpenGL) 。才知道原来从去年开始， Firefox 正式将 OpenGL 合成从主线程移出来了。虽然 Off Main Thread Compositing （OMTC）已经实验了很长时间（搜索一下就可以看到不少 2012 年的记录），但在 Linux 上还是存在问题，所以就默认关闭，导致 Linux 无法使用硬件加速合成。