我一直都喜欢在用的 OS 上面禁用掉光标闪烁，因为一个不停闪烁的光标实在是让我觉得焦躁。有个专门的网页教你怎么在各个平台禁用光标闪烁（http://www.jurta.org/en/prog/noblink）。
但是在 Windows 10 上面，禁用光标闪烁后会有一个后果——任务栏活动窗口的高亮闪烁不会消退。
具体说来就是图中这样，橙色的高亮即使在鼠标点击之后仍然会保留。
相比于光标闪烁，这个除了关闭程序否则永不消退的高亮更是让人难受，于是只能启用光标闪烁。
这次写的真是个无比闲得慌的事情。。。
前两天升级和迁移了一个 MySQL 环境，因为：
OK，于是就找了个凌晨，下线、升级了，初看起来一切正常。
但是到了第二天，问题出现了。开发说从 MySQL 同步数据到 mongodb 非常慢，只有原来的 1/36！
于是都开始怀疑是 mongodb 的问题，难道是程序逻辑有问题？写新版本的 mongodb 没有对参数什么的？但是得到否定的答复。
。。。。。。
折腾了好一会儿，看了 mongodb 的各种文档之后，看了一下一直在跑着的 mongostat 输出，发现是有出现过高并发的写入（但不是出现问题的同步造成的），至少，这说明了——mongodb 升级后的写入功能本身是没有问题，事实上，观察到的结果是有提升。排除了 mongodb 的问题，心想是否可能 MySQL 的数据库问题，看了一眼慢日志，结果确实发现有大量的同一个超过 1s 的查询，时间点和同步一致。
问了一下开发，他们说这个查询应该会被缓存住，第一下很慢，但是后面就很快了！好吧，我看了一眼 MySQL 的查询缓存：
mysql> show status like 'Qcache%';
哈！全部是0，查询缓存被关闭了！
再查了一下 MySQL 的参考文档：
query_cache_type ... This variable defaults to OFF as of MySQL 5.6.8, ON before that.
MySQL 在 5.6 之前的版本是默认开启查询缓存的，而 5.6 开始却默认关闭了它！
于是，设置 query_cache_type=1 之后，重启 MySQL，同步一切正常了。
总结：MySQL 做了这个改动，但是却没有在它们的升级文档中给出说明；开发把程序一个重要的功能依赖于这个数据库缓存，也没有说明。谢谢你们一起给我出了难题！当然，更重要的一个事情是——升级之前没有彻底的测试过！！！所有人都想当然了，这是流程规范的问题。
Hacker News 上面出现了一个讨论(https://news.ycombinator.com/item?id=11729287)，是关于 Google Chrome 去除了将 Backspace 键作为回退到上一个页面的快捷键功能。
我很惊讶很多人在回帖里面对 Chrome 开发者的这一决定表示支持，因为：
我觉得我还是继续用 Firefox 吧
一直是在用 php-fpm 内置的 chroot 功能在跑手头的几个 php 论坛站点。
但是最近将整个 chroot 环境迁移至新的地方之后，出现问题了：
有一个论坛一直是返回 502 状态码。看了下，发现 dmesg 输出有一些信息：
...
[444346.942769] php-fpm[13096]: segfault at 1fae98fc ip 00007f53655429df sp 00007f5347847d80 error 6 in libresolv-2.17.so[7f5365537000+16000]
[444500.294150] php-fpm[13149]: segfault at 1fae98fc ip 00007f53655429df sp 00007f5347847d80 error 6 in libresolv-2.17.so[7f5365537000+16000]
[444500.407066] php-fpm[13151]: segfault at 1fae98fc ip 00007f53655429df sp 00007f5347c07d80 error 6 in libresolv-2.17.so[7f5365537000+16000]
...
chroot 里面的根目录结构是以前从 CentOS 7.1 拷贝创建的，看来和 7.2 不兼容。libresolv 里面发生了 segfault，说明问题应该是和 DNS 解析有关。
试了几次之后，把 7.2 的 libnss 相关 so 文件拷贝到 chroot 里面后，问题解决了。以防万一，接下来干脆把 chroot 里面的所有 so 更新了一次。
仔细想了想，最近一年的时间里，对我的生活改善最为明显的技术是——HEVC/H.265 编码的视频。
现阶段唯一的缺陷是硬件解码的支持并不广泛，Intel 也只有从 Skylake 才开始支持 HEVC/H.265 的硬件编码、解码，不过也只是 8-bit 色深的，10-bit 的基本没有效果，仍然只能靠软解码，吃 CPU。就拿手头的 Intel NUC6I5SYH 来说，它的 CPU —— Core i5-6260U 碰到 HEVC 10-bit 的 4K 视频文件，是无法流畅播放的。（这是当然的，其实笔记本的 i7-4700HQ 都没法流畅播放的，基本没试过其它什么场景能把 CPU 负载跑到这么高的。）
不是说一定要看 10-bit 而不是 8-bit 的视频文件，只不过多数能找到的片源都是 10-bit 的了。
才发现 RHEL/CentOS 7.2 引入的更新的版本 systemd 支持这种直接编辑 override 文件的方式
systemctl edit mariadb.service
hhvm 大概是我见过的稳定性最差的开源软件之一了，也不知道这项目到底有没有QA的，反正我是碰到过很多次一更新，这破东西就挂了，起不来
当日志文件已经被删除的时候，kill -SIGUSR1 `cat $pid` 滚动 mongodb 日志，它会挂掉。
https://jira.mongodb.org/browse/SERVER-11719
https://jira.mongodb.org/browse/SERVER-15643
https://jira.mongodb.org/browse/SERVER-11087
看起来是修复无望。
FFS…
因为 Kibana 3 早就停止开发和维护了，也不支持新版本的 Elasticsearch，现在无论愿不愿意其实都该使用 Kibana 4 了，但是对于我来说 Kibana 4 有很大的问题——无法在饼图里面添加 Top N 之后，把其它的东西统统归入“其它(other)”值里面去。缺乏这个功能，很多时候都导致图表的实际意义并不大了，因为没有正确显示某个值的百分比。
Github 上面早有 issue 提交和跟踪了，但是还没有解决。
Kibana 4 另外的一个失望之处是矢量地图被抛弃了。
只能希望慢慢修复好吧。。。
前段时间一同事在问为甚么同样是 curl ，在 CentOS 7 上面抓取一个网页的域名解析延迟总是会多 150ms 左右？甚至在抓取 localhost 时候也是一样。具体说来，使用的命令是：
[root@centos7 ~]# curl -o /dev/null -s -w \
'%{time_namelookup}:%{time_connect}:%{time_starttransfer}: \
%{time_total}:%{speed_download}\n' http://localhost
0.150:0.151:0.151:0.151:47442.000
对比了一下 CentOS 6 上面的结果，确实差距很大
[root@centos6 ~]# curl -o /dev/null -s -w \
'%{time_namelookup}:%{time_connect}:%{time_starttransfer}: \
%{time_total}:%{speed_download}\n' http://localhost
0.001:0.001:0.001:0.001:114975.000
同事怀疑是 CentOS 7 的域名解析方式有变化，然而我换做用 wget 去抓发现 CentOS 7 延迟也是很低的，排除了这个可能。原因应该是出在 curl 上面。
排查方式：
用 ltrace 加上 -T 参数打印时间戳跟踪了一下，发现是 curl_easy_perform() 这个函数这里出了问题：
Google 了一番之后，发现这个问题其实已经有了修复，将 50ms, 100ms, 150ms… 这样的延迟增长替换为 4ms, 8ms, 16ms… 这样的了。只不过 CentOS 7 里面的版本较老，还没有加入这个补丁。
今天因为 RHEL 7.2 的发布，看了下 Changelog，也已经合入这个补丁了。
https://bugzilla.redhat.com/show_bug.cgi?id=1130239