博客

Mark 一下 ELRepo

适合不想纠结内核编译，直接 rpm/yum 升级的糙快猛解决方案

关于学习能力

新产品是基于某个开源框架开发的，有一个至关重要的特性，需要框架底层有支持才能完成。相关的函数，就在文档里写着，但是开发同学愣是没有发现，其主管甚至做好了重新创造轮子的计划。。。幸好我特别关注这个特性和进度，也一直在关注这个框架相关的技术，当知道难处以后去把文档浏览一遍，立刻就发现了这个函数，早上来通知开发同学一测试，大功告成。

今天和人说起来，我现在就是典型的"信息工作者"，每天处理大量信息，然后产生出对工作有用的新信息出来，推动进步。只动眼睛和大脑，不写代码不动手，最后动动嘴写写邮件就是我看得见的物理产出。

文档放在那里不会用，不去读。我认为就是学习能力的问题。或者英语不好？总之不善用知识的人，肯定很难适应IT行业。

但这个主管肯定是有能力的，可能是太相信手下的程序员？我觉得这又是一个态度的问题：你完全信任手下能构建好相关的知识体系吗？是否轻易得把这个性命攸关的因素交托在他人手上？

作为技术主管，除了完成绩效、确认手下都在正确出力之外——这也是包工头的工作模式——还需要为个人怎么去学习和发展头脑、团队如何做好知识管理而努力

如何获得 RHEL kernel 的单个patch

记得以前 redhat 发布的 kernel srpm 包，里面是一个2.x.xx的原版kernel + 一大坨 RH 自己的 patch。后来不知道出于什么考虑，它只提供"混淆"版本的kernel源代码，对需要研究订制内核的开发者来说非常不爽。

想要拿到单个的patch，官方的说法是访问https://access.redhat.com/knowledge/sources/，但是需要成为红帽的订户才能登入...

于是就有了 RedPatch 这样的良心项目：它没有公开得把 patch 提供出来任意下载——估计这么做是违反协议的）——而是把 patch 一个个 commit 到源码树里，这样我们访问这个 git 树就能获得单个patch 了！

Mark 一下 JMAP 和 switchboard

http://switchboard.spatch.co/examples/

信息化时代的父女对抗

一直在给小朋友 Nexus 7 用，因为 Android 有一套多账号系统，可以对子帐号限制哪些应用她能用。换句话说，我是 root 用户，她是普通的 user，root 和 user 的数据区还是隔离的...

但是小姑娘猜出了她爹的 root 密码之后，就一直偷偷的使用 root 功能看！电！影！直到前天晚上才被发觉.

天空飘来五个字儿，那都不是事

很小的时候，肯定是在10岁以前，在类似《读者》的一个刊物上看到：（以下内容引自百度百科）“有一个大王叫犹太王大卫。某一天做了一个梦，梦中梦见一个神仙。神仙告诉犹太王一个方法，无论是多么的艰难都会顺利的度过；无论怎么富有和有权利也不会骄傲自负。结果梦醒后犹太王想不起来神仙告诉他的方法，他就召集大臣悬赏，谁要是知道他梦中的方法他就赏这个人一辈子的荣华富贵。结果大臣们想个好几天终于给犹太王一个答案，那就是：这也会过去。之后犹太王大卫就把这句话刻在了戒指上，来警示自己 。”

后来想起这句话，总觉得应该是翻译过来的，而不是本土自制的心灵鸡汤；但一直也没有找到英文原文。今天无意中从生活大爆炸里面看到，This Too Shall Pass，解决了多年来心头的一个疑惑。

利用firefox修复pdf文件

某同事体检，留了QQ邮箱，体检结果寄到了邮箱里。

现在他需要把这个pdf文件交给另外的人，麻烦在于这个pdf在QQ邮箱里的preview是能看到的，但是下载下来是无法用Adobe打开。

上网搜了一下，倒的确有在线修复工具。尝试修复，无果。

后来想到firefox不是也内置一个pdf.js做PDF的在线查看么。。。于是用firefox打开之，结果还不错，5页的PDF，后四页都正确解析出来了，第一页是空白；所幸第一页就是这个体检机构的封皮，于是重新打印到PDF文件后面的4页生成新文件，搞定

一台老服务器上的 send(, , ,MSG_MORE) bug

上次研究完 HAProxy，觉得这东西搭配 Postfix 挺好，就安排给运维了，结果运维同学反馈，加持了 HAProxy 以后，返回 220 欢迎信息时间显著变长，于是昨天就抽时间和运维一起分析这个事儿

我的第一反应是 Postfix 处理 Proxy Protocol 有延时，比如反向DNS查询什么的，于是首先在 Postfix 服务器上执行 tcpdump

观察到，当客户端连接 HAProxy 之后，立即 HAProxy 就和 Postfix 完成了3WHS，然后足足等了 3 秒，才从 HAProxy 发来了 "PROXY X.X.X.X XXXX"

现在可确认延时发生在 HAProxy 上，接着去 HAProxy 机器上 strace -tt HAProxy进程

观察到，当完成和后台 Postfix 的 3WHS 之后，的确就立即把 "PROXY X.X.X.X ... "发送了，但是等了3秒，才recvfrom后面的 220

问题出在哪里呢？？仔细看传送"PROXY X.X.X.X ..."的系统调用，原来是用的 send() syscall，而且，它使用了 MSG_MORE 这个参数... (不明白什么是 TCP_CORK 的同学可自行搜索，HAProxy 在这里使用 MSG_MORE 是很有道理的)

但为什么这个延时长达3秒实在理解不能，在我自己的机器上试了一下，是200ms，查看 sysctl 里面的 tcp 设置也没有头绪，对于这种古老的RHEL4服务器只能出大招了：因为这个HAProxy是为SMTP代理专用的，直接修改HAProxy源码，把MSG_MORE注释变成0就一切正常了

看到一个迅雷运维同学的博客，Mark一下

http://blog.netzhou.net/

从搜狐的技术评级所想到的

下午和KCN领导聊天的时候随口提到这个事情，不完全是吐槽

总之，目前搜狐的技术委员会评出的3.1，比某度的某些T5还要靠谱一些。这个给业务在某些程度上造成了困扰，希望这个制度能越来越好，并且技术委员会能在2014年发挥除了考核之外，更大的作用

以当下的苛刻要求而言，在业务部门而不是研发部门的，年过30的同学，想在这条道路上精进到4.x，是一件很困难的事情——除非你做出一个牛逼的平台产品出来

我严肃的思索了一下，当初我从eyou跳槽来搜狐的话，3.1或许能符合要求，3.2是绝对达不到标准的（应聘运维可能还能有4.x的机会）

所以，就只能和BAT竞争毕业生了，同时要给很好的机会，很好的导师，很好的环境，来帮助其成长

附：我自己觉得自己在技术上做得比较得意的事情

1. 拿到了天大路由器的登录和enable口令
2. eyou.com 的日历，把"事件"用一个链表数据结构很好的表示并存在硬盘上
3. eyou MTA 第一版
4. 写了一个 bridge，以及 SMP 下的各种坑
5. 2004年，就建了一对很棒的前端CSS + JS组合
6. eyou的编译脚本和安装脚本
7. DV工具
8. 搜狐通行证，Nginx Module + JS 我一个人全包
9. web.py 的大工程

最遗憾的事情，是进搜狐后，对运维的认识不够，很久很久以后，才形成认识和方法；否则很多事情能做得更好