程序写诗

http://www.dopoem.com/poem/dopoem.php
现在竟然有这种东西，看来写诗也没有什么技术含量。

Ext3文件系统

记得在四月份看到一份文件系统的测试报告，在那份报告中指出ext3格式化后的硬盘会损失8%左右的空间。这段时间的使用感受表明，损失的不止8%，可能在10%左右。也就是说，一个100G的硬盘，格式化后还有90G左右，空间浪费是相当严重的。

ubuntu论坛上有人解释说，这是ext3保留了5%的空间给super user，用mkfs.ext3的-m参数可以设置这个保留的百分比。在mkfs.ext3的man page上是这样说的：

-m reserved-blocks-percentage

Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default percentage is 5%.

尽管这样是有利于系统的运行，可是实在没有必要留这么多。用mkfs.ext3格式化一遍硬盘当然可以，更经济的办法是用tune2fs，可以在线调整 ext3分区的参数。tune2fs -m 2 /dev/sdb2之后后，sdb2的可用空间多500MB左右，对于一个19G的分区，这个数字已经相当可观。

Enlightenment Theme U-235

更新了一下，screenshots:

Liquid maya

折腾了两天，发现liquidmaya真是个折磨人的东西。要用这个东西，得先装个renderman渲染器，Pixar的当然最好，但是license实在太难找了。很多人推荐3delight，这个玩意儿也要license，真麻烦。aqsis支持的特性较少，现在用scons管理后，编译起来也有麻烦。pixie的问题是不稳定，不过只有它能用了。

FC5也是个折腾人的东东，SVN的Pixie是不能用FC5的gcc编译的，不知道是gcc4.1的问题还是pixie的问题，编译execute.o的时候会耗尽所有的内存(2G的内存很快就用完了)，然后扔出个“段错误”。Maya8要求用gcc4.02，这个版本可以用来编译pixie，大概也要消耗1.2G的内存，但是编译出来的渲染器错误太多……pixie提供的几个samples都渲染错误。FC5的compat-gcc3.2编译出来的就没有问题，还算稳定，编译所消耗的内存也只有gcc4的1/3，不过渲染速度就差了点。比较幸运的是，liquidmaya可以在gcc3.2编译的pixie上编译成功。

顺便把liquidmaya做成个rpm包，管理起来方便点。scripts/dojob.py要自己处理一下(我把它放到/opt/pixie/bin里)，要不然shadow map无法自动使用。

pixie支持的特性倒是不少(可惜没有CSG，要有这个的话就牛比了，好像aqsis支持这个)，快赶上PRman了，不过提供的shader很少，要用的话就得自己动手写，renderman.org上也有一些，不知道能不能编译成功。

看来PRman卖8000多$$$也不算贵。