Apps超级推荐(三)

      今天推荐一个看电视的软件——TVU Player。

        在Appe
Store里,有两个类似软件,一个是收费的TVU
Player,要价4.99;另一个是免费的TVULite。TVULite号称一个台只能看两分钟,但是我貌似一直都可以看⋯⋯大家就装免费的好了,缺
点是不能全屏观看。需要注意的是,此软件仅能在WiFi网络中使用,不可在3G网络下使用。对于iPod Touch来说,就不用担心这个问题了。

        如图,里面有大部分CCTV以及凤凰台,凤凰资讯台。       

推荐度:4/5

下载地址:

TVULite(免费):

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=298423761&mt=8

TVU Player ($4.99)

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=323640984&mt=8

Apps超级推荐(二)

        对于初到一个陌生城市的人来说,找到吃饭的地方才是头等大事。对于一家餐馆,口味,价格等等因素都是需要考虑的,找到一家附近的餐馆更是困难。这里要介绍的软件,正是为了满足这样的需要诞生的——Urban Spoon。

       

      
上图是软件的主界面。如果你使用iPhone 3G/3GS平台,软件会根据GPS确定用户所在位置;使用iPod
Touch的话,则会根据Wifi信号进行定位,当然精度就不会像GPS那样准确了。软件的主界面分为三栏:第一列中可以选择城市;第二列则是餐馆风格,
例如意大利风味,巴基斯坦风味等等;第三列则是人均消费水平,从几元到几百元不等。选定相关项目后,点击下方图表锁定,然后——用力摇晃!

        在经过筛选之后,软件会给出餐馆名称,点击即刻看到餐馆相关信息,包括地址,电话,等等。最重要的是,可以看到其他用户对该餐馆的评价!如果点击地址,则会自动启动Google Maps进行导航。

      该软件还可以使用其他一些方式来寻找餐馆,信息十分全面,大家不妨试试看。

       价格:免费

       推荐度:4/5

       下载:http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewArtist?id=284708452

Snow Leopard初试

主要涉及细节,像Grand Central,OpenCL, 64-bit kernel这样涉及深层次的变化就不谈了。

1. 硬盘空间。全新安装Snow Leopard占用磁盘空间在4GB左右(仅安装简体中文语言包,不安装打印机驱动),安装Xcode 3.2之后也只有不到7GB。和Leopard动辄十几GB的体积相比,苗条了60%以上。即使是升级安装,也能节省出5GB以上的硬盘空间。

2. 外观。除了几张新墙纸以外,没有发现风格变化。但是在升级安装时,感觉貌似系统色彩饱和度被提高了。

3. Exchange同步支持。这个算是一大卖点,Snow Leopard支持同步Exchange 2007中的邮件、日历和地址簿。由于本人习惯采用Google Calendar中的CalDAV进行日历同步,所以仅测试了邮件和地址簿的Exchange服务器同步,感觉良好。

4. gcc从4.0.2更新到4.2.1,这个貌似没什么好说的,再诅咒Universal Binary一次。

5. 字体。这段参考了jjgod的文章,http://blog.jjgod.org/page/2/,在此一并谢过。

最大的变化之一:添加了Hiragino Sans GB字体。说实话,对于这种类似雅黑的宽胖字体我很不喜欢,特别是简体中文,感觉臃肿虚浮。但是这个字体的好处在于,它同时包括了简体中文和繁体中文,而且提供了w3和w6两种粗细。唯一的遗憾在于,它实在太像雅黑了,而雅黑时我除了宋体以外最憎恶的字体。

另一个显著的变化,是黑体(简)的加入。和华文黑体相比,字形要稍微瘦长一些,在笔画结构上倒没有显著差异。

另一个变化,就是加入了英文等款字体Menlo。和过去的默认等宽字体Monaco相比,Menlo在小号字体的次像素平滑方面做得貌似要好很多,以至于打开终端的时候我被shock了一下。

6. 乱七八糟的变化:切换输入法出现屏幕提示。为不同程序设定不同输入法。

屏幕截图文件名成了“屏幕快照 2009-08-28 下午09.38.21”这样的形式。

Stack在“网格”模式下可以进入深层文件夹。

QuickLook速度加快。

Dock上的右键菜单变成灰色透明。

新的QuickTime(图标真恶心)。

iCal添加新账户出现向导。

预览提供了完整的pdf注释工具。

Multi-Touch触控板可以手写输入中文。

其他慢慢发掘中。

遗憾:

在我的MacBook上无法启用64-bit内核⋯⋯

在我的MacBook上无法启用OpenCL⋯⋯

在我的MacBook上无法启用H.264硬件解码⋯⋯

QucikSilver 的preference打不开⋯⋯

还好,我实验室还有一台iMac,明天去给它升级了⋯⋯

Day 33

      上周末打算买iPhone 3GS,由于本地没有Apple Store,AT&T网上下订单失败,于是只好找到本地惟一一家AT&T,骑车50个街区……
      由于以前iPhone只摸过一下,所以没什么认识,就从头写起。
      1. 首先,iPhone 3GS对处理器和内存进行了升级,系统速度明显快了很多,像Maps这样的程序立即可以启动,感觉不到任何延迟。短信进入的时间也不到三秒。因为美国这边电话费便宜但短信价格高,所以发短信的人很少,估计Apple也都不怎么重视短信功能。由于AT&T彩信还没有开通,所以没有办法测试,是否有耗电过大的问题也就不得而知了。
      2. 其次是网络,WIFI信号比laptop弱很多,但是在学校连上wifi以后速度还是不错的。至于3G网络,实测下载速度大概在200kB/s以上,但是相当耗电,一般我也只是在电脑上网时候才开。当然即使开着没有数据传输的话差别就不是很大了。
      3. 摄像头。这次对对摄像头的升级效果明显,特别是Tap to focus功能,除了自动对焦以外还可以自动调整白平衡和曝光补偿。在光线较强的地方画质虽然和相机还有差距,但是色彩等方面还是比较让人满意的,唯一的问题是有时候边缘会出现一些暗区。但是在光线较暗的地方就很难让人满意了,基本没有什么改进。
摄像功能很强大,而且可以即时进行裁减和上传,应该说还是比较贴心的。
      4. 指南针。这个非常好,在Maps里点两下定位就可以显示方向了。由于采用磁场定位,所以精度相当高。而且打开罗盘以后地图也会随着旋转,作为手持GPS非常方便。
      顺便说说GPS定位,A-GPS的定位速度非常快,而且准确度还不错,在房间里基本上误差也不会超过15米,在外边准确度还会更还一些。不知道以前做得如何,反正我觉得比Garmin eTrex Vista HCx好用多了:-)
 
以上是iPhone 3GS的一些改进,下面是作为没用过iPhone的新用户的一些感受。
      1. 邮件。由于学校采用Exchange作为邮箱服务器端,所以Push Mail就十分方便了,根据测试,邮箱收到邮件后5秒内手机就会有提示,非常方便。而且在同步时iTunes会自动将Mail中的帐号同步,这样就免去手动设置的麻烦。
      2. Calendar。由于比较忙,所以平时用的最多的可能就是Calendar功能。但是iPhone有一个地方让人不爽,就是只能与一个Exchange帐户同步,这样的话就不能直接和Google Mobile Sync同步了。解决办法是:通过CalDAV进行同步,而且可以实现双向同步,但是延迟貌似比较大,至少没有Push Mail那么快了。
      3. App Store非常方便,但是大于10MB的软件不能通过手机下载,我只好用过电脑来下载,但是实际上还是通过3G下载的……实在多次一举。类似的软件还有TUV Player等,不知道是不是因为牵扯运营商利益。
      4. 键盘,这个比较不爽,因为很容易按错。横屏的时候好很多,但是竖屏确实有点小了。手写我还没试过。
 
      总之,个人觉得iPhone 3GS还是值得推荐的手机,确实比较方便。但是由于WM系统很少用,Palm和黑莓也只用过老款机器,所以还不能进行比较。
 

Folding@Home

       对于一个从事理论化学或者计算化学“研究”工作的人来说,Folding@Home的确是一个不错的玩具。
      最早接触FAH是在高中时候写一篇关于分布式计算的乌七八糟的文章。那个时候算的叫一个慢啊。。。
      对于FAH就不做介绍了,大家可以到http://folding.stanford.edu/Chinese/Main进行更详细的了解,以及http://fahwiki.net/,更为详细深入的介绍。
      严格来说,FAH并不是一个理论化学或者计算化学软件包,更确切地说,FAH是一个分布式计算平台,类似于BOINC;真正的算法部分则采用了GROMACS分子动力学软件包和AMBER分子力场。之前还有基于Tinker和QMD量子化学的计算程序,但是现在都不采用了。不妨从整个计算过程来探讨这个问题。主程序fah6本身并不负责计算,准确来说fah6只是一个调度程序,负责收发数据、平衡负载以及进程管理。fah6有一个重要的功能,就是根据当前运行的平台下载相应的计算内核。举例来说,如果是系统采用多核心处理器或者多处理器,fah6就会自动下载FahCore_a2作为计算核心。FahCore_a2是一个采用了MPI实现并行的计算内核,以GROMACS作为计算方法。类似的内核还有很多,在http://fahwiki.net/index.php/Cores可以看到一份完整的列表,例如FahCore_11是采用Nvidia CUDA技术使用GPU运行的内核。
      我们可以看一眼FAH网站上的统计数据(http://fah-web.stanford.edu/cgi-bin/main.py?qtype=osstats),截止当地时间2008年12月24日05:08:54。

OS Type

Current TFLOPS*

Active CPUs

Total CPUs

Windows

243

255033

2349894

Mac OS X/PowerPC

5

6582

123083

Mac OS X/Intel

28

8872

72696

Linux

45

26181

350540

ATI GPU

993

9031

23771

NVIDIA GPU

1753

15932

57854

PLAYSTATION®3

1553

55076

707720

Total

4620

376707

3685558

    

我们可以计算一下X86处理器(我们假设几乎所有Windows系统都是基于X86构架的处理器)和GPU在进行这样的分子动力学计算时的平均效率:
      X86平台计算效率:0.00102688 TFLOPS/CPU (其中Mac OS X/Intel平台达到了0.0031560 TFLOPS)
      GPU平台计算效率:0.110003 TFLOPS(NVIDIA:0.110030 TFLOPS;ATI:0.109955 TFLOPS)
      二者相差:107倍

      这个数据是软件的计算核心反馈的真实数据,而非峰值或理论值。因此NVIDIA官方所声称的250倍性能应该并非虚言。根据个人经验,分子力学以及分子动力学中大量的矢量运算很可能是造成这种性能差异的主要原因。

     最后说说Macintosh平台上的安装吧。推荐去http://www.stanford.edu/group/pandegroup/folding/release/FAH6.02-OSX-Intel-Console.tgz下载Console版本(http://www.stanford.edu/group/pandegroup/folding/console-userguide.html 有一份比较详细的参数说明),手动建立~/Library/Folding@home目录,将fah6和mpiexec解压缩至该目录下,然后:

Armadillo:Folding@home Armadillo$ cd ~/Library/Folding@home/
Armadillo:Folding@home Armadillo$ ./fah6 -configonly -smp

      接下来根据自己需要进行一些设置。为了使fah6能够自动运行,我们需要将启动脚本加入launchd中:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>EnvironmentVariables</key>
    <dict>
        <key>HOME</key>
        <string>/Users/Armadillo</string>
    </dict>
    <key>Label</key>
    <string>edu.stanford.folding.client</string>
    <key>OnDemand</key>
    <false/>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/Armadillo/Library/Folding@home/fah6</string>
        <string>-smp</string>
        <string>-verbosity</string>
        <string>9</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>ServiceDescription</key>
    <string>Folding@home client</string>
    <key>Umask</key>
    <integer>22</integer>
    <key>UserName</key>
    <string>Armadillo</string>
</dict>
</plist>

      将上面这些文本保存为/Library/LaunchDaemons/Folding@home.plist,你也可以在ProgramArguments中加入更多参数,但是注意不得包含空格,分成两个string即可。接下来就可以启动FAH了:

launchctl load -w /Library/LaunchDaemons/Folding@home.plist

      如果执行ps -ef|grep fh6以及ps -ef|grep FahCore能看到相应的进程就证明已经开始计算了。可以通过执行fah6 -queueinfo查看队列情况,在unitinfo.txt中查看计算进度,在FAHlog.txt中查看输出信息。相应的计算log在work文件夹下。

Apache一个BUG

      今天把lighttpd换成Apache(别问我原因),于是下载了httpd-2.2.9.tar.bz2回来编译。

     
由于有很多文献要读,我在这个http
server上建了一个目录,然后用脚本定时将实验室机器上的Paper同步到这个目录上,再在俺的MacBook上用另一个脚本下载回寝室。为了阅读方便,这个http
server上存放文献的目录开着Index。但是今天发现autoindex模块无法在Linux系统上显示中文文件名。于是在Firefox里面查看了一下Index页面的信息,发现发送编码居然是ISO-8859-1,也就是Western西方字符编
码。这就奇怪了,我明明在httpd.conf里指定了AddDefaultCharset UTF-8的啊。。。。

      于是我打开autoindex模块的源代码,modules/generators/mod_autoindex.c,发现其中是这样判断编码的:

      if (autoindex_conf->ctype) {         
          ctype = autoindex_conf->ctype; 
      }                                     
      if (autoindex_conf->charset) {       
         charset = autoindex_conf->charset;
      }                                    
      else {                            
  #if APR_HAS_UNICODE_FS             
          charset = "UTF-8";            
  #else
          charset = "ISO-8859-1";
  #endif
      }
  
      所以使用ISO-8859-1貌似是因为编译时预处理else中的判断结构出现了错误。那么APR_HAS_UNICODE_FS是个什么东西呢?查了一下,APR是Apache Portable
Runtime(Apache可移植运行库)的缩写,这是一个用来保证上层程序可以跨平台编译运行的中间层。APR_HAS_UNICODE_FS是在srclib/apr/include/apr.h中定义的,而这个apr.h则是在configure时srclib/apr/include/apr.h.i生成的:在Windows下APR_HAS_UNICODE_FS=1,而在Linux及Unix下APR_HAS_UNICODE_FS=0,然后根据APR_HAS_UNICODE_FS的值,在编译autoindex模块时选择采用ISO-8859-1或者UTF-8编码。

      这下问题就很明白了,这个http server系统是RHEL
5,locale是UTF-8,这样的话正好与mod_autoindex.c的初衷相违背:只要是在Linux系统下编译时,不管系统locale如何
设置都使用ISO-8859-1编码生成Index。
   
      目前几乎所有主流Linux发行版的默认locale几乎清一色都是UTF-8,但是Apache中的autoindex_module非但不能判断locale采用相应的编码,反而不分青红皂白就用了ISO-8859-1编码。。。。这实在是。。。太汗了。

    嗯,有时候Hacking一下软件还是很有意思的。