近两年的新 Thinkpad （包括部分 Ideapad ）用户也许会注意到，在联想的宣传中有时会看到“30天休眠”、“智能混合休眠”、“快速启动”之类的宣传语，在联想的电源管理软件中也可以看到“启用30天睡眠”这样的设置。不过不少人都不知道这个功能到底是什么意思，开启那项设置似乎也没有任何变化。
其实，联想所说的“30天睡眠”是 Intel 7系列芯片组新引进的功能—— Rapid Start Technology ，缩写 RST ，在Q、H、Z系列芯片组上可以见到。 Intel 有另一项更加广为人知的技术缩写同为 RST ，即 Rapid Storage Technology ，与 SSD 、 RAID 有关。这个 Rapid Start Technology 也与 SSD 有些关系，简单来说就是在 SSD 上开辟一块空间用作休眠，在系统睡眠达到指定时间后，芯片组将自动把内存写入这块区域，并把内存断电，从低耗电睡眠转换为零耗电（不过仍然有自放电效应，一般来说可以支撑一个月）的休眠。“唤醒”时芯片组会自动把那块区域从 SSD 读入内存，再从睡眠状态恢复。
今天凌晨，笔者忍受着缓慢不堪的校园网，看完了 WWDC 2013 的直播。第一次观看直播，并且在此之前没有关注过相关的预测和消息，使笔者得以较少地受到外界评论先入为主的影响，有了一些自己的想法。
早上醒来翻看新闻，果然如预想的一样，铺天盖地的 WWDC 相关新闻几乎都以“ iOS 7 扁平化新设计”为主题，伴随而来的是漫天的苹果、谷歌、微软三大粉丝团的互掐，以及一些“苹果死忠”的愤怒，间或还冒出一些得意洋洋的“米粉”和“煤油”。然而，iOS 7 全新的设计是否可以用“扁平化”来概括？更进一步地，iOS 7 是否仅仅只带来了被“拍扁”的设计？让我们先把成见放下，把被各种评论和宣传塞满的脑袋放空，一起来看看“扁平化”是什么，“新” iOS 究竟新在哪儿。
我的旧电脑——惠普 Compaq Presario CQ35-105TX 在经历了四年多的风风雨雨后，终于寿终正寝了。上个月底，经过长时间的考虑，我最终放弃了 Macbook Pro ，入了一台仰慕已久的 Thinkpad ，型号是 T430s 2352A32 。 T430s 是 T430 的薄款，但又不是 T430u 超级本或 T430i 低配版，配置上与 T430 完全相同，但轻薄了许多，电池续航有一点削弱（不过它的4芯电池具有快速充电功能，半小时充80%电量，还是不错的）。 Thinkpad 是很有特点的笔记本，不同于惠普、神舟之类普通的消费本，有很多特有的硬件和功能，就算运行 Windows 也需要费一番功夫装上一大堆驱动。幸运的是，在 Thinkpad 上运行 Linux 的人还是挺多的，有许多热心人为内核驱动以及各种文档做贡献，比如 ThinkWiki 和 ArchWiki ，上面有非常丰富的资料。不过，这款 T430s 比较新，相关资料比较少，因此有必要在这里记下我的一些心得、经验。
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 的官网风格。）
最近在做项目时遇到了一个 case ：需要实现一个强制下载功能（即强制弹出下载对话框，阻止浏览器尝试解析显示某些文件格式），并且文件名必须保持和用户之前上传时相同（可能包含非 ASCII 字符）。
前一个需求很容易实现：使用 HTTP Header 的 Content-Disposition: attachment 即可，还可以配合 Content-Type: application/octet-stream 来确保万无一失。而后一个需求就比较蛋疼了，牵扯到 Header 的编码问题（文件名是作为 filename 参数放在 Content-Disposition 里面的）。众所周知， HTTP Header 中的 Content-Type 可以指定内容（body）的编码，可 Header 本身的编码又该如何制定？甚至， Header 究竟是否允许非 ASCII 编码呢？
如果放任编码问题不管，那么你一定会遇到在某个系统及浏览器下下载文件时文件名乱码的情况；如果你尝试搜索解决，那么你很可能会找到一堆自相矛盾的解决方案（我可以负责任地告诉你，其中的99%都是不符合标准的 trick 罢了）。让我们来看看到底应该如何优雅完美地解决这个问题吧！
NVIDIA 对开源驱动开发的支持之差从 Linus Torvalds 那句著名的“Fuck NVIDIA”就可见一斑——几乎没有提供任何开发文档，开源驱动的开发基本要通过逆向工程进行。因而，想要获得较好的 3D 加速性能、 VDPAU 硬件解码功能、完整的多头显示支持等等，你必须使用 NVIDIA 闭源驱动。不过闭源驱动的一大问题就是文档匮乏、过时，一大堆神奇设置（不少还是隐藏的）让人摸不着头脑，其中一些项目的默认设置还有些问题，可能导致不小的性能损失。所以，在参考 NVIDIA Linux 驱动的官方文档和 ArchWiki 的基础上，我做了一些实验，摸索出了一些优化项，可以让你的桌面更加流畅（尤其是 GNOME Shell ）。