電影不怎麼好看，但歌曲動人心弦。一開始還當作一般電影在看，但總覺得沒把原作者偉伯的意境表現出來，到後半段的時候目光全都集中在「歌詞」上，根本不看人物表演。歌詞翻譯得真好，看了很有感覺，配合美妙的歌聲真讓人進入忘我的境界了（講得有點誇張…）。
　　所以電影可以看看，但也只值得看一次…倒是歌曲能一聽再聽！

　　自從去年初訂了 Linux-Mandrake 的服務以後，就一直沈浸在其中。因為要教學弟用 Linux ，而 Debian 缺少圖形安裝界面，學弟們覺得很難學（不長進？），所以親自下海學 Linux-Mandrake 來教他們。Linux-Mandrake 是很方便沒錯，機乎不用額外設定就灌好中文化圖形環境了，教起來頗容易。
　　這幾個禮拜看了 Debian Weekly News 後，突然很想再玩玩 Debian。一年沒碰果然很多設定都生疏了，得一邊查文章（摩托學園）一邊修改設定。花了一個下午的時間終於設定好 WindowMaker 環境、中文字型和 JAVA…等等的設定，蠻有成就感的咧～

　　玩 Linux 需要發自內心的動力才能學很多東西，不然像學弟們都只有三分鐘熱度，學到很多皮毛而已。其實大多數想學 Linux 的人只是因為 Linux 目前很熱門，並非出於對這些東西的熱情。而我本身是被自由軟體的精神所感動，就像上一篇文章的 Marcus Brinkmann 一樣，才會一頭鑽進這個世界之中。
　　細數一下對我意義重大的 Linux 套件好了。一開始因為中文環境支援差，自己又很肉腳，所以 CLE( Chinese Linux Extension)自然成為領我進門的套件。以前的CLE對各知名套件都有做中文擴充，其中 Linux-Mandrake 以新切的桌面環境吸引我，有很長一段時間都用它做事常工作。後來受到玩 FreeBSD 的同學影響，加上「Debian無痛起步法」的幫助，且 Linux-Mandrake 安裝空間變得愈來愈大，就跳到 Debian 的懷抱中囉！一直用 Debian 灌 server、灌桌機，直到一年前才重學 Linux-Mandrake。
　　在這一年當中也接觸過其它套件，如 Knoppix、Gentoo…等等，但始終沒再好好的安裝使用 Debian。之前碰 Solaris 時有想過，學很多種但生疏倒不如學得少但專精，這是放棄學習 Solaris 的主要原因。現在這情形似乎又發生了，而我決定以深入 Debian 為目標，把時間省下來做其它方面的進修。Linux-Mandrake 就只在教新手時使用吧！再會了～Linux-Mandrake！

　　「程式設計師最重要的特質是，當你對電腦下達一個指令時，腦海裡能夠看見電腦如何完成這個指令。」作業系統核心 Hurd 的開發者 Marcus Brinkmann 在一次訪談中提到。這句話我非常認同，每次寫程式有這種感覺時，這支程式通常不會有任何問題，且很容易修改。相反的，如果下指令時無法預見執行流程，那這支程式一般說來會有錯誤，且難以找出錯誤所在，也不好修正問題。

　　文章中另外提到了「多數程式師在預測程式效能方面的能力非常糟糕」、「你為機器撰寫程式，但也是為人而撰寫程式。」這些意見都是 Marcus Brinkmann 多年來累積的經驗，再加上參與 Hurd 開發的心得所歸納的結論，值得有心成為「專業」程式師的人細細品味。

　　下面節錄訪談中講到這方面的段落。訪談全文在此。

Advice for new programmers

Nikolaos S. Karastathis: I am sure that many of the people who read this interview are considering becoming programmers. Could you please provide some advice for aspiring software developers? Do you think it is better to learn many programming languages at once, or just stick with one language and learn it extensively? What are the most important qualities that programmers should possess?

Marcus Brinkmann: You should have a look at as many different languages as you can get hold on (and as you have time). Also for all other tools. You can not get proficient in all of them, or even any substantial number, but you should know your way around them and expose yourself to as many ideas as possible. However, note that a language is merely a tool of expressing your ideas programmatically. As every other tool, you need to learn when and how to apply it to a given problem. And as with every other tool, it can help you or be in your way.

To become an expert programmer, you need to know what tools are available, but you also need to pick some tools that suit your needs particularly well and become good at them. So, for some languages you will want to learn them really, really well. Unfortunately, as so often in life when you leave the plane of abstraction and get down to the details of the implementation of an idea, tools like compilers cease to be black boxes. When you become a better programmer, you will be exposed to implementation details about your tools, including the hardware of your computer, that you never wanted to know. For example, you will start to worry about things like in which pattern your program will access memory, and how that interacts with the CPU’s memory cache. You won’t find this knowledge in most books. The best way of learning this is by doing and experiencing it.

Here is an example from the real world. Many years ago I bought a PDA with GNU/Linux on it, the Agenda VR3. The device had many problems and was not very successful. One particular problem was that the calendar function was very slow. Somebody profiled the code and found out why. It happens that the calendar used the bits in an integer field as flags, that’s a standard idiom. But instead using the shift operation “1 << n” to access the individual bits, the programmer used the math function “pow (2, x)", and on that architecture, all floating point arithmetic was just painfully slow. We don’t know what the author of that code thought. Clearly, the code was “correct” in that it achieved the goal. Maybe the programmer thought of pow() as a black box. Maybe he knew that he was using floating point arithmetic, but thought that the compiler could optimize it to a shift operation. In this case, the author didn’t know the language and his compiler good enough (if I recall correctly, the type casting rules prevented such an optimization).

This illustrates that the most important quality of a programmer is to visualize in your mind what the computer is doing when you give it certain instructions. This is important both to be confident that your code is correct, and at a greater level of detail to give a good estimation of your code’s performance when it is actually compiled into a program and run. Most programmers are notoriously bad at predicting the efficiency of their code. The better you know your tools, and the more experience you got, the better will be your ability to say with confidence what the computer will actually do with your code, and you will be able to fine tune your program to make the system behave more the way you want it. Of course, on a global scale, you will need profilers and debuggers to help you with this.

I want to add one more thing: You program for a machine, but you also program for human beings. Never forget that. Even the best performing code can be useless if no human can figure out what it is doing and why it is doing it the way it does. So, another important quality is that you can write documentation and good comments into your source code, and that you can structure your source code in a way that it is accessible to your fellow developers. Most of the important programming in the world today is a team effort. Read high quality source code to pick up common idioms and follow coding style guidelines.