eog，也就是gnome的默认图片查看器──GNOME之眼，打开同一张jpg图片会比其他程序打开模糊很多，而且很明显，看下图：
上面是eog的效果，下面是gPicView打开的效果，用的图片是同一张，可以这样重现：随便在那里截个图，保存成无损的png格式，然后在用gPicView打开此png，另存为jpg格式，质量设置成90%，当然也可以用eog来另存，效果也是一样的。然后再用eog和gPicView同时打开这张jpg图片，就可以看到对比的效果了。
是我的eog有问题还是eog本身的问题呢？我的版本是‘GNOME 之眼 2.26.3”。干脆删了以后都用gPicView算了。。。
基本是参照WD的这篇文章来做的，devnull这个overlay貌似不是很稳定，本来想昨天就做的，结果昨天死活加不了，今天却又好了。
话说加了这个devnull后全局启用ubuntu这个use，再全局 -cleartype 这个use，重新编译了那几个包，效果还真是不错的。
另外，我这里启用 10-hinting-slight.conf 的效果比启用 10-hinting-medium.conf 的效果更好一点。
我就只管贴图了，具体方法就看wd的文章好了。
下图是我的firefox浏览自己的blog时截的，下面那个窗口的是未调时的截图效果，上面是现在的效果：
调整前后对比图
是不是好一点呢？不过好像普通字体变粗了一点点，然后粗体却反而变细了一点点。。。
最近很多人给我留言，说我的feed输出在Google Reader里不正常，所有格式都没了，换行也不见了。
但是我用thunderbird订阅自己的blog却是很正常的，为此特意用GR订阅了自己的blog看了下，确实是所有文字都成了一陀，惨不忍睹。
为此，近几天找了好久的原因，到现在，虽然根本原因还是没找到，不过换行问题算是暂时解决了。
我对比了自己的feed输出和其他WP的blog的输出，其实格式上都是一样的，都是xml里没个item都有description和content:encoded两块内容，其中description里是没有任何换行标记的摘要，一般长度不会很长，也就是说会截断文章；而content:encoded里才是真正的HTML化的全文内容，一般在WP的后台选择了feed输出全文以后，这段才会有。
但是我一直是选择输出全文的，为什么还是会乱掉呢？莫非GR只认我的description那段了？而thunderbird等却可以显示真正的全文，这样的解释倒是可以说明为什么在不同的阅读器里会有不同的表现。
意识到这一点后，我就想干脆把feed里的description那段去掉得了，于是看下了WP的代码，找到了 wp-includes/feed-rss2.php 的47行，
|
1 |
<description><![CDATA[<?php the_excerpt_rss() ?>]]></description> |
然后把这行给删掉了。终于实现了在GR里断行，哈哈。
剩下的问题是，为什么大家都有description，但是只有我的显示有问题？难道xml里有指定用不用description的字段么？
哦，还得记得下次升级了WP以后，都得再改一次这个文件。。。
======== 20090902 16:52 update ========
原来还有一个文件没有改过来，导致刚才订阅 http://li2z.cn/feed/atom/ 的同学还是乱的，但是订阅 http://li2z.cn/feed/ 的同学就是正常的。。。
于是再删掉 wp-includes/feed-atom.php 的第44行：
|
1 |
<summary type="<?php html_type_rss(); ?>"><![CDATA[<?php the_excerpt_rss(); ?>]]></summary> |
这回，应该都好了吧。。。
写这篇文章是因为看到了cnbeta上最近接二连三地出现类似这篇的文章。
虽然我还是认为此文的作者多少还是有点标题党，因为那个 ./a 其实可以是任何东西，这样就说是“一个命令”也太无聊了点。但是我在公司的RHEL4的服务器上试验了之后，确实可以非法提升权限。不免有点担忧。
于是我顺藤摸瓜，在那个提供hack代码的网站上不费吹灰之力，就找到了一、二、三3个能非法提升root权限的程序，而且这几个程序是一周内公布的，所以相信真要找的话，还能找到很多，何况还有人家未公布的呢？
不过大家也不用太担心，这些程序都有个共同点，见到的最厉害也只能危及2.6.27的内核，而现在的内核都是 2.6.30/31 的时代了。
但是，我公司的2.6.9-55.ELsmp内核的EHRL4服务器就遭殃了，3个程序都中招了，这就说明了保持更新的重要性。一般这种服务器更新都会比较谨慎，有时候甚至无人去管理更新的事情，而且大多都是开着ssh的，这样的linux其实一点都不安全，我就见过一台服务器，老出这样那样的怪问题，最后我去看的时候，大部分/bin和/usr/bin下的常用可执行文件都已经被修改过了，文件的时间也都是一样的，而且正是这个时间开始才反常的。究其原因，正是因为这台公网IP的机器开着SSH，而且root密码还是无敌的“123456”。。。这样，即使那机器本身没有什么重要的文件，一旦被攻陷，损失和麻烦还是不少的，更何况局域网的其他机器也会受到牵连。
在这里，有必要给大家几点建议，做到以下几点linux才能真正安全一些
先这么多了，有其他再补充。。。
标题其实是“废话”。因为，其实稍微熟悉web原理的都知道，理论上，所有可执行的程序/脚本，都可以被server程序（例如apache/mini_httpd/lighttpd/nginx等）调用，只要能够输出HTML，都可以成功。
而这个用bash做CGI的想法，纯属闲着无聊的时候，瞎想出来的。不过有这个想法的，我肯定不是第一人，这里和这里都有类似的描述。
不过，我这个Web From Scratch的过程还颇有点波折，试了蛮久才成功，就在此记录一下。
其实，说白了都是也就一句话：扩展名不能随意取。当然这个只是针对我这个主机的apache来说的，其他的server可能有其他的规则，暂且不做定论。
之前我一直把我的脚本文件名写成index.sh，结果怎么试都不行，后来无意中改成inedx.py（虽然里面还是#!/bin/bash开头的）居然就可以了，于是我就找到原因了，现在我改成个更通用的index.cgi了，哈哈。
另外关于.htaccess，由于自己也是一知半解，就不讨论了，有兴趣的话，可以看看这里，这里只贴下我用到的代码，可以把对此域名的任何路径的请求都让index.cgi来处理。
|
1 2 3 4 |
RewriteEngine on DirectoryIndex index.cgi RewriteCond %{REQUEST_URI} !(index.cgi) RewriteRule ^(.*)$ index.cgi/$1 [L] |
来看看我的bash，就是简单地输出服务器信息：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
#!/bin/bash #下面这两行头一定要有，不然可是会引发 500 Internal Server Error 错误的。 echo "Content-type: text/html" echo "" echo "<h1>Bash CGI works!</h1>" env | while read line;do echo "<b>" echo "$line" | cut -d= -f 1 echo "</b>=<i>" echo "$line" | cut -d= -f 2- echo "</i><br>" done |
最近几天，可以点击 http://hzlug.org/abc?xxx=yyy 观察这个脚本运行的效果，以后可以把这个地址做它用，嘿嘿。
可以看到 REDIRECT_URL 和 QUERY_STRING 这两个环境变量分别是路径和参数，这样理论上就可以用一个脚本来完成很复杂的功能了~
至于HZLUG到底会做成什么样子，还请大家多多提意见哦~
有时候，在脚本里操作剪贴板是很有用的，比如，你可以用scrot截屏以后贴到paste，然后把url直接放到剪贴板里，方便与人分享；又比如，你可以在选择了一段不和谐的文字的时候，通过按一个快捷键悄悄地把文字变成base64加密以后的内容发给好友；再比如，复制一个单词或者一段文字，按一个快捷键可以在剪贴板里放置翻译后的结果等等。当然肯定有更多方便的应用等你来发现。
在实现复杂应用之前，我们应该先对linux的剪贴板有个基础的了解，其实，linux（准确地说是带X的GNU/linux操作系统）的剪贴板分为3个：
1. 中键主剪贴板
2. 中键辅剪贴板
3. ctrl+v剪贴板
用过linux的朋友肯定都知道一个很方便的特性：鼠标选中一段文字就相当于windows的“复制”，然后在其他程序里按下鼠标中键就相当于“粘帖”，可以把刚才选中的文字粘帖出来。这个经常会让像我一样的linuxer养成一种习惯，以至于在朋友电脑上偶尔使用的windows的时候，也会经常点中键，却什么也出不来。。。同时，这也造成了linux比较损鼠标中键的现象，因为一般的杂牌鼠标，为了节约成本，鼠标中键的轴只有一端是固定的，所以这个轴很容易断，中键都很脆弱，没按几下会坏掉了，我的几个坏鼠标基本上都是中键不灵。。。
呃。。怎么说到鼠标去了，言归正传，这个用中键粘帖的剪贴板我们暂且称为“中键主剪贴板”，另外还有一个“中键辅剪贴板”，一般用户很少用到，“ctrl+v剪贴板”就无须多解释了，就是和windows一样的那个剪贴板，大家平时可能只把这个当成“正宗”的剪贴板吧。
xsel 是用脚本操作剪贴板时需要用到的命令，xsel同时支持这3个剪贴板，那么我们来看看xsel是如何区分这几个剪贴板的：
-p, –primary 指定操作 中键主剪贴板
-s, –secondary 指定 中键辅剪贴板
-b, –clipboard 指定 ctrl+v剪贴板
-x, –exchange 还可以交换 中键主剪贴板 和 中键辅剪贴板 ，这样辅就可以起到一个中间变量的作用了。
下面看看常用的操作：
-i, –input 从标准输入读入到剪贴板
-a, –append 往剪贴板里添加内容 （PS：我发现当某个剪贴板内容为空的时候，使用这个选项会导致xsel出现段错误，不知道是不是应该去报告bug）
-c, –clear 清除剪贴板的内容
-o, –output 输出剪贴板的内容
于是，有了这些好玩的操作，我本来这个
|
1 |
scrot /tmp/scrop_tmp.png -bcsd 3 -e "echo | upaste -image \$f ; rm \$f" |
贴图脚本就改成了这样了：
|
1 |
scrot /tmp/scrop_tmp.png -bcsd 3 -e "echo | upaste -image \$f | xsel -bi; rm \$f" |
这样帖完图以后，URL就直接在ctrl+v剪贴板里了，发给别人也相当轻松了，哈哈。。（upaste是帖东西到http://paste.ubuntu.org.cn，并返回url的perl脚本）
另外，你可以可以看看 xclip 等其他程序，如果有必要的话，下期再介绍啦，哈哈。
下午，看到toy上说UltraEdit出linux版了，做为一个曾经的UE迷，马上就下载来试了一下。
发现，这个虽然是beta版本，但是已经有较强的可用性了。这个测试版本第一次运行的时候，会弹出提示说可以用到2009年9月1号，到时候肯定还是要交钱的，价格貌似和windows版的一样，截图说话吧：
（点击放大）
由于python的模块很强大，用python来收发邮件，就显得很轻松了。
python不仅有email模块，还有专门处理pop、smtp甚至imap的模块。
下面就来演示一下这几个的用法，先看看怎么用pop3和email模块来收邮件。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
>>> import poplib >>> p=poplib.POP3_SSL('pop.gmail.com') #如果服务器不需要启用SSL，那么只需要用 poplib.POP3('xxx.com') 就好了。 >>> p.user('linuxcn.ibot') '+OK send PASS' >>> p.pass_('密码') '+OK Welcome.' >>> p.stat() #统计状态，返回一个元组，第一个表示几封邮件，第二个表示一共几个字节 (2, 4543) >>> p.list() #返回每个邮件的状态 ('+OK 2 messages (4543 bytes)', ['1 3679', '2 864'], 15) >>> p.retr(2) #获取某个邮件的全文，这个邮件就是我自己给另一个测试账号发的邮件，元组里包含了邮件头和邮件的正文。 ('+OK message follows', ['Delivere ...为了排版方便，此处有删节... e--'], 869) >>> mailsrc='\n'.join([l for l in p.retr(2)[1]]) >>> print mailsrc #如果上面还看不出啥的话，这样看应该就明显了。 Delivered-To: linuxcn.ibot@gmail.com Received: by 10.216.47.83 with SMTP id s61cs422102web; Sat, 15 Aug 2009 07:58:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.180.16 with SMTP id c16mr2819847waf.57.1250348310512; Sat, 15 Aug 2009 07:58:30 -0700 (PDT) Date: Sat, 15 Aug 2009 22:58:30 +0800 Message-ID: <ae14629e0908150758n49649527xf326b8c1a60f36bf@mail.gmail.com> Subject: =?UTF-8?B?5rWL6K+V5Li76aKY?= From: LLY <bones7456@gmail.com> To: linuxcn.ibot@gmail.com Content-Type: multipart/alternative; boundary=001636417e2fe4c3a904712f669e --001636417e2fe4c3a904712f669e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 5rWL6K+V5q2j5paHCg== --001636417e2fe4c3a904712f669e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 5rWL6K+V5q2j5paHPGJyPgo= --001636417e2fe4c3a904712f669e-- >>> p.quit() #收完邮件了，理论上是要退出一下的 '+OK Farewell.' >>> import email #源码得到了，现在轮到email模块登场了 >>> e=email.message_from_string(mailsrc) #这个就可以把邮件源码转换成一个email的对象了。 >>> print e['subject'] #这个是编码后的主题 =?UTF-8?B?5rWL6K+V5Li76aKY?= >>> print email.header.decode_header(e['subject'])[0][0] #这个是解码后的主题 测试主题 >>> e.get_payload() #获取当前email的有效部分，可以看到有这个邮件有两个部分，从上面的邮件源码，我们也可以得知，此邮件确实有text/plain 和 text/html 两部分 [<email.message.Message instance at 0xb751102c>, <email.message.Message instance at 0xb751172c>] >>> e.get_payload(0) #获取有效部分的第一个，这个还是一个email对象的实例。 <email.message.Message instance at 0xb751102c> >>> type(e) <type 'instance'> >>> type(e.get_payload(0)) <type 'instance'> >>> import base64 #解码邮件正文还得用上base64模块 >>> print base64.decodestring(e.get_payload(0).get_payload()) #解码正文的第一部分 测试正文 >>> print base64.decodestring(e.get_payload(1).get_payload()) #解码正文的第二部分，是html，看来只多了个br而已，哈哈 测试正文<br> |
当然，上面的例子只是最简单的，复杂的附件什么的，也可以用库里的相关函数一一搞定的。另外，看文档的意思，传了get_payload的第二个参数按理应该能自动调用base64模块解码的，但是不知道为什么，我没有试验成功，只能自己手工解了~
下面，再来看看怎么用smtp发邮件，如果是复杂的邮件，也需要建立一个email对象的实例，把正文/附件等一一放上去就好，但是作为演示，我们就用邮件的源码来发一个纯手工的，哈哈
|
1 2 3 4 5 6 7 8 9 |
>>> import smtplib #加载模块 >>> msg='To: linuxcn.ibot@gmail.com\r\nFrom: my@localhost\r\nSubject: test\r\n\r\nthis is msg body\r\n' #邮件的源码 >>> s=smtplib.SMTP('smtp.163.com') #同样这里也有SMTP_SSL，到底用什么要看服务器的设置 >>> s.login('bones7456','密码') #一般都要登录了，才能发邮件，login里提供两个参数，用户名和密码 (235, 'Authentication successful') >>> s.sendmail('bones7456@163.com','linuxcn.ibot@gmail.com',msg) #发送邮件，三个参数分别是 from/to/msg，就这名简单就成功了。。 {} >>> s.quit() (421, 'closing transmission channel') |
就这么几行，一封邮件就发出去了，够简单吧。。。更详细的内容就看官方文档吧~
JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。它基于JavaScript Programming Language, Standard ECMA-262 3rd Edition – December 1999的一个子集。 JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯（包括C, C++, C#, Java, JavaScript, Perl, Python等）。这些特性使JSON成为理想的数据交换语言。
以上摘自JSON官方介绍，这个格式是如此地简单，以至于光看这篇官方文档就可以完全掌握了，而无须其他过多地介绍了。
最初看到这个JSON，是在twitter上，这种小交互量的场景很适合用JSON，比XML更轻巧些。今天，看到新闻，taobao也搞了个开放平台，里面也支持JSON和xml这两种格式，所以我觉得这个格式以后会越来越流行，特发此文关注下。
