相见恨晚

曾经有一个机会让我早点转到GNU/Linux的怀抱，我没有珍惜，等到失去的时候我
才追悔莫及，人世间最大的痛苦莫过于此，如果上天能给我一次再来一次的机会，
我会对GNU/Linux说三个字:我爱你。如果有机会让我选择从什么时候开始学
GNU/Linux，我希望是从接触电脑开始。

刚开始用GNU/Linux是不顺手的，因为以前的习惯养成了用鼠标点来点去的习惯。
而且一直离不开office的使用（在Office的领域，MS还是无人能敌）。但是当你开
始用Makefile来处理一些自动化的过程，用Python来当计算器的时候，你已经离不
开GNU/Linux为你提供的这些便捷。

刚开始用GNU/Linux装软件是不顺手的，因为在Windows下习惯了鼠标双击
install.exe。Linux下"./configure; make;make install"或者rpm包的安装对于
一个新手来说，都是很繁琐的过程。Debian Apt的出现，改变了这个局面。慢慢
地，现在习惯的安装过程变成了apt-get install <software>

而最后促使我把日常的操作系统改为GNU/Linux的是VirtualBox，我现在使用
Ubuntu+VirtualBox(Windows XP)。在Windows下用到的软件就只是Office和游戏
了。虽然VirtualBox下运行的Office有点慢，但作为文本处理，速度已经够了。
（我发现Ubuntu+VirtualBox+XP下运行Office速度跟Vista竟然差不了多少）

最近学习Latex，以及：PSTricks, PyX, Matplotlib, GNU Pic，更是感觉到了GNU
软件的强大。

姚期智_志在中国计算机科学2020计划~zz

http://www.newsmth.net/bbscon.php?bid=272&id=41398

知易行难

上午听完Professor Xian-He Sun的讲座：Reevaluating Amdahl's Law in the Multicore Era。

很多人对他提出的所谓的"Weak Scalability"不以为然。觉得算不了什么，以为没有解决自己的固定问题规模要得到时间加速比的问题。
这是他们对固定时间增加问题规模的加速比的意义不清楚。解决问题的规模，同样重要。只是以前很少人做罢了。
像BlueGene现在有25,200个核，就是为了解决更大规模的问题。
1988年Custafson's Law提出的时候，Custafson的贡献是真正做出了n-cube，并且把speedup跑到了1,000以上。

对于Memory-Wall的问题，大家都希望着工艺能够进步，硬件能够解决这个问题，但是等到的只是CPU和内存速度差距越来越大。
Sun老师说的一句话很有道理，说他不会等着硬件来解决这个问题，而是在现在的限制条件下，他通过其他方法能做什么。

关于Data Prefetching，Sun老师说他去Stanford演讲，Stanford这帮人在Memory上做prefetching，结果不行，Sun在IO上做，结果得到一个比较好的结果。这篇paper也被推选为一个会议的best paper。

[Softwares]Nutch

刚在自己机器上安装了Nutch，一个开源的搜索引擎。读了 Doug Cutting的blog：

About five years ago I was working with Mike Cafarella on Apache Nutch, an open-source web-search engine. Initially we were able to crawl and index on four machines in parallel, but with a lot of manual steps. Inspired by two Google papers, we implemented a distributed filesystem and MapReduce implementation that automated most of these steps. Operation became much simpler, and we were then able to easily run Nutch on twenty machines, with near-linear scaling.

因为inspired by two papers, we immplemented...
一件巨大的事情，开始就是这么简单。
笔记

札记

这几天因为网络关系，在干活的时候只能是埋头coding，要连接网络需要重新配置。突然发现效率比以前提高。
难道上网会分散工作精力？我自以以前只是上网查资料而已。
难道不需要查资料？这几天事实证明，只有很少的时候需要。而且因为需要查的目标明确，查了资料后又断掉网络，重新工作。
把相似的工作放在一起做，这可能是效率提高的一个原因。

Paper Reading

读paper的关注点从是什么（What）往如何实现（How）上转移。
读了几篇重要会议上的文章，发现基本都是用模拟器来实现。
从学习的过程来说，入门一个领域最快的方法就是读paper和重复其中的实验结果。
这些时间得靠挤出来。

现在主要的工作时间在调试模拟器，但并不是在建模。要建立模型，需要对模拟的
精度提高并且和实际系统进行校验。

札记

调试程序的时候碰到困难，有一种又困又紧绷的感觉。努力克服中。

[Readings]Debugging Methodology

I searched the web: "Why debugging is hard". The result leads me to a ACM SIGSOFT Software Engineering Notes -- "Debugging Methodology" in 1983. This short summary tells us some of the common questions in debugging. And it is a delightful reading. To quote a few:

Dan Moore from Bell Laboratories addressed the queations of "why is debugging hard?" and "what are programmers thought processes during debugging?" His observation was that debugging appreared to require both analytic and intuitive thought modes. (His hypothesis is) debugging is hard because it is difficult to transfer the locus of thought from one hemisphere to the other.

Elaine Weyuker pointed out that 90% of the bugs were found by desk checks and test runs, while the remaining bugs were found using program dumps. (barely use debuggers)

(Elaine Weyuker)80% of the bugs are easy bugs and 20% of the bugs are hard bugs. ... a frequent cause for a hard bug is that the programmer develops a mind set as to how the program is supposed to work when in fact it works differently.

What is hard about debugging?
While there was general agreement that debugging is hard, there is very little consensus as to why it is hard. Here is a list of suggested reasons:
- Debugging is hard because it requires repeated switches between intuitive and analytic thought modes.
- Debugging is hard because programmers develop a mind set that their program should work one way when in fact it does not.
- Debugging is hard because the available debugging tools are not adequate.
- Debugging is hard because the program semantics change as the user finds and coreects bugs. This make it difficult for the user to develop a consistent model of program behavior.

What unusual tools were useful for debugging?
Someone displayed the binary image of the program directly onto a bit-map screen. Someone else found that a program history management system was useful. ... There were several program in real-time was a useful freature.

For extensional reading, read my note of learning GDB.

firefox自定义engkoo英汉/汉英翻译引擎

Mycroft Project提供了自定义firefox引擎的简 便方法。到Mycroft Project的Create/Submit Plugin页面，填好下面的表格：


点击"Generate Plugin"，然后"Install Plugin"，新建一个Tab，选自己自定义的引擎，看看在自己的浏览器里面试试可不可以用。

如果测试结果正确，提交这个Plugin。

你可以参照这个方法自定义其他的搜索引擎。也可以试试我自 定义的两个引擎。

[Software]Gnome Do - OpenSearch Plugin

OpenSearch Plugin can be used with Mycroft

[Softwares]Ubuntu one & gmbox

gmbox发布0.1版本

体验Ubuntu One

[Softwares]Chickenfoot

Web上的萬能瑞士刀: Chickenfoot

[学习笔记]m5 full-system mode

安装使用了m5 full-system。
跑了其中一个benchmark。
学习笔记记在我的个人主页。

[Softwares]Insert Images in gmail

Gmail Labs's Image feature
1. Select "Settings->Labs"


2. Enable "Inserting Images"

[Readings]Business Rules of Thumb

"The job of the leader is to ask the right questions."

"Teamwork requires people who can take on the real work of leading at all levels of the organization."

"Start with small experiments that solve real problems that people are having. See what works and build on that."

-- Business Rules of Thumb by by Bruce Eckel