年初买了raspberry pi，本来是想用来看高清视频，不过这小盒子的性能真不咋的，买了ipad之后更派不上用场，索性来做一个爬(fan)梯(qiang)服务器吧。
1. 首先是把原来的xbian刷成了archlinux,
然后肯定是修改mirrorlist啦，果然台北的源比北京清华大学的快很多
安装的软件有：
bftpd：用来在电脑和Pi之间传文件用，用户配置文件在/etc/ftpdpassword，启动用bftpd -d
python和python2：oh yeah你不知道下载下来的goagent适用于哪个版本所以都要装
python-pyopenssl、python2-pyopenssl和nss：同上
至此，就能运行goagent了，目前的版本是用python2.7 proxy.py这个命令
2. 路由器的设置：当然是把Pi的IP固定比较好，比如为192.168.1.5
3. proxy.ini的设置：
127.0.0.1全部换成192.168.1.5
profile=google_cn换成google_hk，虽然慢一点，但是起码你用whizz的时候不会访问不了google服务
proxy.pac的设置：
127.0.0.1全部换成192.168.1.5
4. 给goagent生成key：用管理员账号运行下列命令
rm -rf ~/.pki
mkdir -p ~/.pki/nssdb
certutil -d ~/.pki/nssdb -N
虽然官方说法不是这样，但是确实每次启动goagent都要用root账号才行有木有
5. iOS的代理设置：某个wifi名称后面点"i"，然后http代理里面选自动，填"http://192.168.1.5:8086/proxy.pac"
注意："http://"不可省略！
6. 给iOS安装证书：用safari直接打开http://192.168.1.5:8086/CA.crt的方法是很(xing)机(bu)智(tong)的！乖乖给ipad上的邮箱发封带有CA.crt附件的邮件好了。安装时的密码是锁屏密码来着
7. APP解决方案：至此，用safari可以访问twitter、facebook了，youtube不能看视频，使用twitter和facebook的客户端则无法访问，折中的办法是安装google whizz，web app嘛，勉强接受了
8. 最后一击：前面的步骤都成功以后，就可以考虑让Pi自己运行goagent不去管它了，当然最简(wu)单(nao)的办法就是一直通电，运行一次goagent就好。为了避免关掉putty窗口时goagent进程被冻结，应该
nohup python2.7 proxy.py &
看到output被转到某文件后，按回车回到CLI，然后输exit退出
2013年12月1日星期日
2011年1月3日星期一
Kindle3格式攻略
1月前买了一个kindle 3。先试过刷多看系统，但是因为无法忍受对英文和西班牙文的显示，而且mobi的支持也比较差，最后还是换回了原版系统。之后，小说类的基本都在网上下载mobi，部分专业书籍也藉由calibre转换为mobi，效果十分惊艳。但是很多专业书籍都是pdf，而即使是chm，很多也会大至几百兆，用calibre无法完成转换。因此，前两周对于kindle的使用基本停滞不前。今天趁着元旦“长”假还未结束，探索了一下专业pdf文档的处理方式，基本实现了大部分专业文档的阅读。把常见的处理方式罗列如下：
1、中文txt
发给username@free.amazon.com可以转换为mobi，但是字体较小，翻页需要等待较长时间。用acrobat或solid pdf tools转化为6寸pdf比较合适，宽、高尺寸为4.5、5.7inch左右，最好稍微留一点边距。
2、英文txt、几十M的chm
都可以用calibre或amazon的转换服务转换为mobi，格式基本上可算十分完美。
3、非扫描版中文pdf
对于中文字数较多的文档，pdf更易阅读，所以裁边即可。简单的可以用Govert's PDF cropper自动裁剪，复杂的可用pdfcropper裁剪。
4、非扫描版英文pdf
对于排版比较单一的，可以用solid pdf tools转换为word，然后另存为html，最后用calibre转换为mobi，效果还是十分不错的。但是对于一些排版比较复杂（或者说不规范，比如图片的标注是纯文本的）的，无论如何都达不到较好的效果，经常会出现一些格式错误，影响阅读。我采用的方法是裁掉白边，因为多数教材类pdf都有较大的白边，裁掉之后再横版阅读效果还不错。使用的软件为pdfconverter，可以奇数和偶数页分别自定裁剪范围。该软件为共享软件，未注册版本无功能限制，但是会在每一页中间加3道水印，不过对于阅读基本无影响。
5、扫描版pdf
没有十分好的转换方案。对于扫描得比较好的教材类，也就是每页有内容的部分大小基本一致的，可以用pdfcropper裁边然后横版阅读。
1、中文txt
发给username@free.amazon.com可以转换为mobi，但是字体较小，翻页需要等待较长时间。用acrobat或solid pdf tools转化为6寸pdf比较合适，宽、高尺寸为4.5、5.7inch左右，最好稍微留一点边距。
2、英文txt、几十M的chm
都可以用calibre或amazon的转换服务转换为mobi，格式基本上可算十分完美。
3、非扫描版中文pdf
对于中文字数较多的文档，pdf更易阅读，所以裁边即可。简单的可以用Govert's PDF cropper自动裁剪，复杂的可用pdfcropper裁剪。
4、非扫描版英文pdf
对于排版比较单一的，可以用solid pdf tools转换为word，然后另存为html，最后用calibre转换为mobi，效果还是十分不错的。但是对于一些排版比较复杂（或者说不规范，比如图片的标注是纯文本的）的，无论如何都达不到较好的效果，经常会出现一些格式错误，影响阅读。我采用的方法是裁掉白边，因为多数教材类pdf都有较大的白边，裁掉之后再横版阅读效果还不错。使用的软件为pdfconverter，可以奇数和偶数页分别自定裁剪范围。该软件为共享软件，未注册版本无功能限制，但是会在每一页中间加3道水印，不过对于阅读基本无影响。
5、扫描版pdf
没有十分好的转换方案。对于扫描得比较好的教材类，也就是每页有内容的部分大小基本一致的，可以用pdfcropper裁边然后横版阅读。
2010年3月26日星期五
初涉tcp基础一例
昨天很多同学抱怨说ftp的下载速度慢得要死。ssh进入服务器看了看
ifconfig
发现eth0的txqueuelen是10，其它几个界面都是1000. 某只告诉我，eth0的那个网络接口被学校给搞了，只能等下周去找那帮混蛋
今天起床之后搜索了一下txqueuelen，发现它是可以用
ifconfig eth0 txqueuelen 1000
进行设置的。但是改成1000之后，RTT变成了800ms左右（之前txqueuelen是10的时候RTT是150ms左右）。又尝试了几个不同数量级的txqueuelen值，发现这个值越大，RTT越大，感觉上的网络延迟也越大。但是txqueuelen又无法再继续小下去了，也就是说RTT最小就只能是150ms左右了。
于是，目前的情况看起来是这样：RTT不知道为什么变得十分大，系统自己为了减小RTT而把txqueuelen往小里调了。如果假设系统还没有自动调整的话，RTT可能已经800ms，比起平时的2ms增大了400倍。
那么RTT是如何影响带宽的呢？
根据这篇文章的介绍，我查看了服务器的相应参数
rmem_max=131071
wmem_max=131071
tcp_rmem=4096 87380 4194304
tcp_wmem=4096 16384 4194304
上面这些参数算下来神奇的跟提到的这篇文章中的计算参数十分吻合，算下来接收传输速度是400kbytes/s。而该服务器发起的传输速度为82kbytes/s，对于局域网的ftp，在10kB/s左右，几乎是不可忍受的. 更何况即使是这样高的RTT也是在系统自动调整之后达到的，如果其它参数保持不变，RTT可能会达到800ms，传输速度就只有不到2kB了。
然后就是处理的问题？应该人为的把tcp_rmem和tcp_wmem设定得大一点，还是应该把RTT降低呢？
除了前面提到的那篇文章外，这篇文章也指出，linux内核从2.6.17开始，就支持了自动调整tcp参数以达到最佳。查看了一下/proc/sys/net/ipv4/tcp_moderate_rcvbuf，确实是1，也就是说确实开启了自动调整。那么目前的状态，包括tcp_rmem、tcp_wmem和txqueuelen甚至是RTT，应该都是自动调整后系统认为的最佳状态，而其中系统自动调整作用不大的，应该只有RTT，因为照我的理解，RTT是一个数据交换过程的时间，某一端的处理不会对已经很大的RTT有太大的改善。此外，还可以推断，RTT明显增大是系统进行这一系列自动调节的原因之一。
那就来看一下调整RTT的收益：如果RTT能够恢复原来的2ms左右，那么传输速度可以加快70~80倍，也就是达到6400kbyte/s。另外，此时系统可能会自动对tcp_rmem、tcp_wmem和txqueuelen等参数再次进行微调，实际收益可能不止于此（当然只是我的推测）。不过现在我是没有办法调整RTT了，等下周如果那帮人发善心把RTT恢复到以前的状态，再来核对一下前面的那些参数会发生怎样的变化，再来算算实际传输速度吧
ifconfig
发现eth0的txqueuelen是10，其它几个界面都是1000. 某只告诉我，eth0的那个网络接口被学校给搞了，只能等下周去找那帮混蛋
今天起床之后搜索了一下txqueuelen，发现它是可以用
ifconfig eth0 txqueuelen 1000
进行设置的。但是改成1000之后，RTT变成了800ms左右（之前txqueuelen是10的时候RTT是150ms左右）。又尝试了几个不同数量级的txqueuelen值，发现这个值越大，RTT越大，感觉上的网络延迟也越大。但是txqueuelen又无法再继续小下去了，也就是说RTT最小就只能是150ms左右了。
于是，目前的情况看起来是这样：RTT不知道为什么变得十分大，系统自己为了减小RTT而把txqueuelen往小里调了。如果假设系统还没有自动调整的话，RTT可能已经800ms，比起平时的2ms增大了400倍。
那么RTT是如何影响带宽的呢？
根据这篇文章的介绍，我查看了服务器的相应参数
rmem_max=131071
wmem_max=131071
tcp_rmem=4096 87380 4194304
tcp_wmem=4096 16384 4194304
上面这些参数算下来神奇的跟提到的这篇文章中的计算参数十分吻合，算下来接收传输速度是400kbytes/s。而该服务器发起的传输速度为82kbytes/s，对于局域网的ftp，在10kB/s左右，几乎是不可忍受的. 更何况即使是这样高的RTT也是在系统自动调整之后达到的，如果其它参数保持不变，RTT可能会达到800ms，传输速度就只有不到2kB了。
然后就是处理的问题？应该人为的把tcp_rmem和tcp_wmem设定得大一点，还是应该把RTT降低呢？
除了前面提到的那篇文章外，这篇文章也指出，linux内核从2.6.17开始，就支持了自动调整tcp参数以达到最佳。查看了一下/proc/sys/net/ipv4/tcp_moderate_rcvbuf，确实是1，也就是说确实开启了自动调整。那么目前的状态，包括tcp_rmem、tcp_wmem和txqueuelen甚至是RTT，应该都是自动调整后系统认为的最佳状态，而其中系统自动调整作用不大的，应该只有RTT，因为照我的理解，RTT是一个数据交换过程的时间，某一端的处理不会对已经很大的RTT有太大的改善。此外，还可以推断，RTT明显增大是系统进行这一系列自动调节的原因之一。
那就来看一下调整RTT的收益：如果RTT能够恢复原来的2ms左右，那么传输速度可以加快70~80倍，也就是达到6400kbyte/s。另外，此时系统可能会自动对tcp_rmem、tcp_wmem和txqueuelen等参数再次进行微调，实际收益可能不止于此（当然只是我的推测）。不过现在我是没有办法调整RTT了，等下周如果那帮人发善心把RTT恢复到以前的状态，再来核对一下前面的那些参数会发生怎样的变化，再来算算实际传输速度吧
2010年3月10日星期三
被迫升级arch
今天凌晨更新了opera到10.10，无奈无法运行，说我需要libpng12，但你这里是libpng14。
——arch方便之处：以前用ubuntu的时候，遇到这种情况会陷入依赖地狱（可能因为当时手还很生）。而在arch，yaourt一个libpng12即可
今天上午再次打开电脑，smart登录管理器无法载入，awesome也无法加载壁纸，说我需要libjpeg7，但你这里是libjpeg8。于是依葫芦画瓢，yaourt了libjpeg7。
想看部电影，打开mplayer，说我也罢工了。无奈，只好pacman -Syu，好家伙，有800MB的更新需要下载。下着吧，更新完毕之后把libpng12和libjpeg7移除，一切正常。
对于滚动更新的arch，以后我该频繁定期更新还是半年才更新一次呢？
——arch方便之处：以前用ubuntu的时候，遇到这种情况会陷入依赖地狱（可能因为当时手还很生）。而在arch，yaourt一个libpng12即可
今天上午再次打开电脑，smart登录管理器无法载入，awesome也无法加载壁纸，说我需要libjpeg7，但你这里是libjpeg8。于是依葫芦画瓢，yaourt了libjpeg7。
想看部电影，打开mplayer，说我也罢工了。无奈，只好pacman -Syu，好家伙，有800MB的更新需要下载。下着吧，更新完毕之后把
对于滚动更新的arch，以后我该频繁定期更新还是半年才更新一次呢？
西厢计划试用成功
在twitter上看到同样热衷于翻墙的推友有一条关于“西厢计划”的推，点开一看，原来是一种用于linux系统的基于netfilter的翻墙技术。竟然还有linux专用的翻墙技术也，不试试怎么可能。
1、下载安装包：目前处于alpha阶段，貌似没有什么现成的包，只有到项目的googlecode页去下载源码包了
2、准备必需工具：除了INSTALL中要求的autoconf，automake，libtool之外，arch用户还需要安装kernel26-headers和ipset4（后者从aur安装）
3、按照INSTALL说明的步骤安装。make install完成之后测试时，iptables会报错说找不到libipt_ZHANG.o什么的，这时候把源码目录中extensions下的libxt_ZHANG.o拷贝到/usr/lib/iptables/libipt_ZHANG.so，并类似处理libxt_gfw.o就可以了，以后还有需要用到的iptables扩展可以做类似处理
4、用firefox测试：关掉autoproxy，连接youtube速度那是刚刚的，比youku、tudou什么的快。不过还是不时会出现连接重置，查看/var/log/iptables.log会发现连接重置果然是由gfw导致的，但是如何解决目前还不知道。。。
5、目前哪些网站要用西厢还要在ipset中自定义，所以我主要用它连接youtube等用翻墙软件无法很好的解决的网站，其它网站还是用autoproxy，不过要在其gfw-list中把对应youtube的项目去掉
6、作为一个linux使用者而非开发者，只有在此默念火星咒希望西厢开发顺利了。感谢开发出这项应用的童鞋们:_)
1、下载安装包：目前处于alpha阶段，貌似没有什么现成的包，只有到项目的googlecode页去下载源码包了
2、准备必需工具：除了INSTALL中要求的autoconf，automake，libtool之外，arch用户还需要安装kernel26-headers和ipset4（后者从aur安装）
3、按照INSTALL说明的步骤安装。make install完成之后测试时，iptables会报错说找不到libipt_ZHANG.o什么的，这时候把源码目录中extensions下的libxt_ZHANG.o拷贝到/usr/lib/iptables/libipt_ZHANG.so，并类似处理libxt_gfw.o就可以了，以后还有需要用到的iptables扩展可以做类似处理
4、用firefox测试：关掉autoproxy，连接youtube速度那是刚刚的，比youku、tudou什么的快。不过还是不时会出现连接重置，查看/var/log/iptables.log会发现连接重置果然是由gfw导致的，但是如何解决目前还不知道。。。
5、目前哪些网站要用西厢还要在ipset中自定义，所以我主要用它连接youtube等用翻墙软件无法很好的解决的网站，其它网站还是用autoproxy，不过要在其gfw-list中把对应youtube的项目去掉
6、作为一个linux使用者而非开发者，只有在此默念火星咒希望西厢开发顺利了。感谢开发出这项应用的童鞋们:_)
2010年3月9日星期二
皮蛋粥料理成功！
工具：美的紫砂煲 320W
材料：无铅皮蛋2个，大米，香油，盐
过程：
1、大米淘1次之后倒掉水，加少量香油和盐腌2个小时
2、大米加自来水入锅，开足火力开始加热
3、约1小时后剥1个皮蛋，切得尽量碎丢入锅里，或者用小刀把皮蛋一点一点的刮进锅里
4、熬得差不多时加入另一个切得不那么碎的皮蛋，再熬半个小时左右
5、开始吃了，配卤鸭腿，还算美味
历时：3个半小时
经验教训：
1、水加得太多。其实不必熬3个半小时，只是后来发现水太多又不舍得把溶化了皮蛋的水丢掉所以就多熬了一段时间。这次米加得很少，但是水加了1.5L左右，估计加1L差不多
2、熬的时间太长。缘故是水太多，估计熬两个半小时差不多
3、后来的一个皮蛋没有必要加。其实最开始加的皮蛋已经溶化到了粥里面，粥的味道也是完全来自于这个皮蛋，后来加的皮蛋完全没有起到提升味道的作用，反而喝粥的时候容易觉得有碱味。还是加一些肉类比较好，下次一定要试一下加点瘦肉，估计在熬到1个半小时的时候加就可以了
材料：无铅皮蛋2个，大米，香油，盐
过程：
1、大米淘1次之后倒掉水，加少量香油和盐腌2个小时
2、大米加自来水入锅，开足火力开始加热
3、约1小时后剥1个皮蛋，切得尽量碎丢入锅里，或者用小刀把皮蛋一点一点的刮进锅里
4、熬得差不多时加入另一个切得不那么碎的皮蛋，再熬半个小时左右
5、开始吃了，配卤鸭腿，还算美味
历时：3个半小时
经验教训：
1、水加得太多。其实不必熬3个半小时，只是后来发现水太多又不舍得把溶化了皮蛋的水丢掉所以就多熬了一段时间。这次米加得很少，但是水加了1.5L左右，估计加1L差不多
2、熬的时间太长。缘故是水太多，估计熬两个半小时差不多
3、后来的一个皮蛋没有必要加。其实最开始加的皮蛋已经溶化到了粥里面，粥的味道也是完全来自于这个皮蛋，后来加的皮蛋完全没有起到提升味道的作用，反而喝粥的时候容易觉得有碱味。还是加一些肉类比较好，下次一定要试一下加点瘦肉，估计在熬到1个半小时的时候加就可以了
2010年3月2日星期二
GTD and RSI prevention
前段时间在黑莓上安装了Pocket Informant，用其中的Franklin Covey功能做中期的任务规划，然后用其GTD功能来提示每天要完成的任务。在Getting Thing Down这本书中，有提到2分钟任务的重要性。而这个“2分钟任务”，便是今天要谈到的重点。
题目中的第二个名词，为RSI，即repetitive stress injury，是一个与人体工学ergonomic有关的概念。我之所以想到这个概念，是因为上周末去换眼镜，发现近视度数涨了100度，回来后想安装workrave但是又不想要跟gnome有关的依赖，经过一番搜索，得知了前述的概念。关于RSI prevention，我选用的软件是：电脑上用xwrits，手机上用闹钟的倒计时功能。
下面说到正题：GTD和RSI prevention软件的综合运用
首先，xwrits设置为每工作45分钟休息10分钟。由于xwirts只在键盘或鼠标有动作时计时，所以在进行看电子书或看电影等同样需要用眼睛的任务时需要手动用闹钟软件来倒计时。无论如何，每1小时都会有10分钟多一点的空闲时间，这段时间内是不能看电脑或看书的。
然后就要用到2分钟任务了。2分钟任务可以理解为一种头脑风暴，就是在关于任务的点子跳出来之后及时记录进GTD软件的inbox中，待日后解决。其中部分任务可以在前面提到的10分钟间歇进行，比如洗衣服，收拾房间，到便利店买东西，背诵已经记熟的课文，跟同学讨论讨论课内容，跟家里通电话等等。建立了这些任务之后，还要能够从GTD软件中很快的筛选出这些任务才有意义，因此，任务的context标签就派上了用场。我一般会把需要电脑或书完成的任务和不需要的分别归入不同的context，这样10分钟间歇的时候很方便就可以找到这些任务了。
昨天刚开始这种日程安排方式，觉得眼睛的劳累程度确实有所改善，干的事并没有因为休息而减少，而且觉得整个晚上都过得十分happy(我的日程安排仅针对晚上)。从今天开始做一个健康的人，恩。
题目中的第二个名词，为RSI，即repetitive stress injury，是一个与人体工学ergonomic有关的概念。我之所以想到这个概念，是因为上周末去换眼镜，发现近视度数涨了100度，回来后想安装workrave但是又不想要跟gnome有关的依赖，经过一番搜索，得知了前述的概念。关于RSI prevention，我选用的软件是：电脑上用xwrits，手机上用闹钟的倒计时功能。
下面说到正题：GTD和RSI prevention软件的综合运用
首先，xwrits设置为每工作45分钟休息10分钟。由于xwirts只在键盘或鼠标有动作时计时，所以在进行看电子书或看电影等同样需要用眼睛的任务时需要手动用闹钟软件来倒计时。无论如何，每1小时都会有10分钟多一点的空闲时间，这段时间内是不能看电脑或看书的。
然后就要用到2分钟任务了。2分钟任务可以理解为一种头脑风暴，就是在关于任务的点子跳出来之后及时记录进GTD软件的inbox中，待日后解决。其中部分任务可以在前面提到的10分钟间歇进行，比如洗衣服，收拾房间，到便利店买东西，背诵已经记熟的课文，跟同学讨论讨论课内容，跟家里通电话等等。建立了这些任务之后，还要能够从GTD软件中很快的筛选出这些任务才有意义，因此，任务的context标签就派上了用场。我一般会把需要电脑或书完成的任务和不需要的分别归入不同的context，这样10分钟间歇的时候很方便就可以找到这些任务了。
昨天刚开始这种日程安排方式，觉得眼睛的劳累程度确实有所改善，干的事并没有因为休息而减少，而且觉得整个晚上都过得十分happy(我的日程安排仅针对晚上)。从今天开始做一个健康的人，恩。
订阅：
博文 (Atom)
