Tl;dr RTFM!
昨天在折腾终端的 TERM 环境变量时总算正面遇上了之前就疑惑过的一个问题： bashrc 、 profile 、 xprofile 等等这些文件究竟是在何时、何种情况下被谁调用的呢？其实要弄清楚这个问题也很简单，阅读 Bash 的 manpage 就有很大帮助，再结合着看一些桌面管理器自带的脚本代码和做一点实验，就能弄得很明白了。这里就记录一下最终结果，略去实验过程了。
令 GNOME Terminal 支持 256 色
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 的启动参数正是如此。）
最后上张图：
在 Linux 上开启 Firefox 试验性 OMTC （从而恢复硬件加速）
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 无法使用硬件加速合成。
解决 systemd 休眠时无法切断电源的问题
systemd 作为一个功能强大的新一代 init 系统，功能不仅仅限于启动一系列 daemon ，还接管了日志、电源管理甚至部分的用户登录功能。在切换至 systemd 来管理电源后（卸掉了 pm-utils ，改用专为 Thinkpad 开发的 tlp ），我的 Thinkpad T430s 遇到了休眠后无法关机（使用的命令是 systemctl hibernate ，或者是通过 GNOME 来触发）的问题。经过一番搜索，找到了 /etc/systemd/sleep.conf 这个配置文件，简单设置即可 fix 。
这个文件默认是不存在的，需要自行建立，然后在文件中加入以下配置：
[Sleep] # A fix for unable to poweroff after hibernation HibernateMode=shutdown
原理是让内核在休眠后使用普通的关机流程（默认是“platform”，即通过 ACPI 进入 S4 之类的模式，在某些笔记本上可能无法正常工作）。具体详情可以 man systemd-sleep.conf 查看。
PHP 应用隔离的几种方法
禁用部分 PHP 函数加强系统安全
绝大多数 PHP 应用都只是单纯的 WEB 程序，很少用得到一些系统调用。一般最多用到一些列目录、读写删文件等。其他 system 、 passthru 等函数使用的最多的地方是 Web Shell 。作为一个运行着众多应用的服务器的运维，没有办法保证每一个程序的绝对安全，所能做的就是在自己的能力范围内尽可能增强系统安全性，通过权限隔离、限制等方法构筑“最后一道防线”。禁用一些一般不会用到的 PHP 函数就很有帮助。我的做法是在全局的 php.ini 中禁用掉这些函数，对于极个别需要其中某些函数的应用，在相应的 Apache VirtualHost/Directory 配置中通过 php_admin_value 来去掉限制。
Thinkpad T430s运行Linux
我的旧电脑——惠普 Compaq Presario CQ35-105TX 在经历了四年多的风风雨雨后，终于寿终正寝了。上个月底，经过长时间的考虑，我最终放弃了 Macbook Pro ，入了一台仰慕已久的 Thinkpad ，型号是 T430s 2352A32 。 T430s 是 T430 的薄款，但又不是 T430u 超级本或 T430i 低配版，配置上与 T430 完全相同，但轻薄了许多，电池续航有一点削弱（不过它的4芯电池具有快速充电功能，半小时充80%电量，还是不错的）。 Thinkpad 是很有特点的笔记本，不同于惠普、神舟之类普通的消费本，有很多特有的硬件和功能，就算运行 Windows 也需要费一番功夫装上一大堆驱动。幸运的是，在 Thinkpad 上运行 Linux 的人还是挺多的，有许多热心人为内核驱动以及各种文档做贡献，比如 ThinkWiki 和 ArchWiki ，上面有非常丰富的资料。不过，这款 T430s 比较新，相关资料比较少，因此有必要在这里记下我的一些心得、经验。
E17 一周体验记
Enlightenment 17（准确的版本号其实是0.17.0）是一个很有特点的“东西”，说它是桌面环境，它比 GNOME 、 KDE 之类的 DE 要轻得多，甚至比 XFCE 和 LXDE 都要轻；说它是窗口管理器，它又有自己的一套 toolkit —— EFL ，包括了从底层图形库到窗口组件库乃至 dbus 库等全套桌面开发设施，而且还具有跨平台、轻量高效的特点（有一个基于它的智能手机项目 OpenMoko）。按照官方的说法， E17 是一个 Window Manager 和 Desktop Shell ，也能算是一个小型的 Desktop Environment 。 E17 的开发过程极其漫长，从上世纪 90 年代 E16 正式版推出后， E17 经过了十几年的开发，才从 alpha 到 beta 到今天的正式版，此间甚至有 0.16.999 这样的版本号。十年磨一剑，其精雕细琢的程度让 GNOME3 汗颜（想想 GNOME Shell 3.0 吧，我实在无法接受那是一个“正式版”）。
为什么会想到要尝试 E17 呢？虽然我曾今是一个爱折腾的人，但近来已然感受到无意义的折腾是浪费时间，所以投身 E17 是有着一些更为实际的原因的—— GNOME3 sucks and I don’t like KDE！我的旧电脑是很早以前的奔腾双核，跑 GNOME3 感觉颇为吃力，各种特效都有些卡顿，开机时间极长，而且 GNOME Shell 本身太难用，不得不装一堆插件，这一方面加剧了卡顿的情况（这些插件都是 JS + CSS 的），另一方面又带来了严重的不稳定性——尤其令我无法忍受的是每次 GNOME 升级都要 break 掉一堆插件……因而，趁着换电脑的时机，我想尝试一把这个被一些人吹上天的、极具个性的 E17 。然而经过一周的体验，我最终还是将它卸载，换成了 Cinnamon （ GNOME3 的 Linux Mint fork ）。今天就让我讲讲这一周以来的感受以及放弃 E17 的原因。（由于卸载时过于仓促，没有留下截图， E17 的默认外观可以参看 TualatriX 的这篇文章及 E17 的官网风格。）
Linux 下 NVIDIA 显卡闭源驱动的一些优化
NVIDIA 对开源驱动开发的支持之差从 Linus Torvalds 那句著名的“Fuck NVIDIA”就可见一斑——几乎没有提供任何开发文档，开源驱动的开发基本要通过逆向工程进行。因而，想要获得较好的 3D 加速性能、 VDPAU 硬件解码功能、完整的多头显示支持等等，你必须使用 NVIDIA 闭源驱动。不过闭源驱动的一大问题就是文档匮乏、过时，一大堆神奇设置（不少还是隐藏的）让人摸不着头脑，其中一些项目的默认设置还有些问题，可能导致不小的性能损失。所以，在参考 NVIDIA Linux 驱动的官方文档和 ArchWiki 的基础上，我做了一些实验，摸索出了一些优化项，可以让你的桌面更加流畅（尤其是 GNOME Shell ）。