挑戰自己的能力極限 - 寫出最好的程式

寫出漂亮的程式碼，是每個寫程式成痴的 Coder 所追求的，對這些人來說，每次的寫作都是在追求自己能力的極限。常耳聞，有人面對自己寫出的程式碼，可獨自欣賞久久不能自己，飲茶配酒又吟時作對以讚嘆那數十行的程式，撇清自戀成份不談，其中面對那追求頂尖的程式碼之美的渴望，可想而知。

就有一些 Online Judge 網站，提供大量的程式題目，讓高手們痛快的挑戰自己的極限，其中有人追求的是程式碼長度，有的則是追求程式的效能，網站內的評分項目雖不盡相同，卻同是追求各種程式撰寫的極限。此外，排名機制和資料庫可以讓我們清楚看到，自己在面對世界各地的高手時的程度差距，更進一步相互交流。深思『為什麼可以寫出這樣的程式？』以提升自我。

在此推薦一個網站：

http://www.spoj.pl/

對程式痴人來說，在閒暇時挑戰寫程式的極限，也真是不錯的休閒活動。而想要精進自己寫程式能力的人，由此緞練一番，確也是很好的方法。

後記

慚愧

實作 Print Binary

經常做二進位的運算，在 Debug 時也常會需要檢視一下二進位形式的數值內容，可以自己寫一個函式去 Print 出來，因此筆記在這，以後隨時可以 Copy & Paste :P。

void print_binary(int type)
{
       int size = sizeof(int) * 8; /* 1 Byte = 8 bits */
       int i = size - 1;
       char s[size+1];

       while (i+1) {
               s[i--] = (1 & type) ? '1' : '0';
               type >>= 1;
       }
       s[size] = '\0';

       printf("%s\n", s);
}

快速開機實作瓶頸簡記

最近，『Fast Boot』、『快速開機』、『5 秒開機』、『XPUD』這些關鍵字紅到爆炸，經常在快速開機的討論話題中所聽到。自從 EeePC 的推出，自豪的標榜 15 秒開機後，『快速開機』的話題越來越熱門，然後 Aspire One 驚人的 11 秒開機，讓『開機的速度』一時間變成了各家研究的首要方向。不久前。由知名 Penk 所發展的 7 秒開機 XPUD，直到最近『 Intel Moblin 』所展示的 5 秒開機，都著實讓人感到不可思議。

接下來呢？難道 5 秒開機真的已經是極限了嗎？

由於到處打工，也碰到許多與相關的案子，近來更被許多老闆們要求進行加快開機的速度。進行加速的過程中，從開始幾秒鐘為單位的計較，到最後連小數位以下的時間都要精精算計，每一次都證明了『5 秒鐘』似乎真的是極限。

一個開機速度所會碰到的瓶頸大致上如下：

1. Kernel Initializing
2. Driver Initializing
3. Filesystem Initializing
   
4. I/O

通常 Kernel + Driver + Filesystem 使用 2 秒（經過數不清的調較和修改 kernel 後），Userspace Initializing + Xorg + Desktop Environment 用 2.x 秒，整個估算大概會是 5 到 6 秒鐘。經過測試，其實應該有可以再加速的空間。

仔細觀察了 Kernel，Synaptic Touchpad 就吃了 0.5 秒，IDE 的 probe 也吃了 0.6 秒，單是這兩支 driver 就吃掉了近五分之一的開機時間，實在是慢的驚人。其中有趣的是，通常在 netbook 上，ide1 沒有 Device，但在這部份卻要花上 0.16 秒，讓人很想要 dirty hack ，直接讓 kernel 閃過 ide1 的 scan。 :P

其實在整個開機流程中，最大的瓶頸在於 I/O，Userspace 的程式都伴隨著大量的 config file、Font、Library，如何提升載入速度是很重要的課題。這部份，Moblin 的 Super Readahead 作法的確很暴力，利用多引線平行榨乾 I/O，使重要的檔案預先載入。另外，由於 SSD 讀取速度極快，一般來說將每個 block 加大，或也是個提升速度的方法，不過這部份還要待測。

Xorg 現在很聰明，不吃 config file 一樣自己跑得很開心，原因是他將自動偵測的機制放在裡面了，這樣讓 User 們不再需要了解痛苦的 X 設定，但確讓 X 的啟動速度拖慢了，在這部份，雖然已經有人再著手改進，如：『 Fedora OneSecondX 』，但目前還是要花點時間啟動 Xorg，想必還是需要再研究看看。

在 netbook 上，一般的 Desktop Environment 已經被所謂的 Application Launcher 所慢慢取代，但無論如何，他們都有很多的 *.desktop 和 Icons 需要被載入，如何改進並加入 cache 機制就是一個很重要的方向，與其使用 Readahead 的方式去增進這部份的速度，還不如直接使用 cache 去解決。

後記

將最近研究『Fastboot』的筆記大致隨筆了一下，許多想法還待實作，希望有朝一日能做到『1 秒』開機，不過現在看來真的是天方夜談。（笑！光 Kernel 都跑不完了）

咦！？要是把 Userspace 的東西強行植入 Kernel，會不會是一個可行的方法呢？反正這年頭就是要髒，髒才有錢賺不是嗎？

使用 inotify 監視某資料夾的一舉一動

在 Linux 下監視某個資料夾的變化，有很多種方法，可以土法煉鋼的定時去掃描、檢查修改時間，也可以去將檔案一一開啟比對，不過往往這些過程，都伴隨著大量且多餘的 IO 存取。對此，使用 inotify 就顯得比較方便且有效率。自從 hal 的出現後，我們已經可以使用 inotify 去攔截某個檔案或資料夾一舉一動的 event，若是整合 GLib ，短短數行即可實作出來。

#include <glib.h>
#include <sys/inotify.h>
#include <sys/types.h>
#include <errno.h>

void inotify_events_io_func(GIOChannel *channel, GIOCondition condition, gpointer data)
{
  char buf[1024];
  struct inotify_event *event;
  gint index = 0;
  gint len = 0;
  gint fd = g_io_channel_unix_get_fd(channel);

  while(((len = read(fd, &buf, sizeof(buf))) < 0) && (errno == EINTR));

  while(index<len) {
      event = (struct inotify_event*)(buf+index);

      /* read events */
      switch(event->mask)
      {
          case IN_MODIFY:
              printf("MODIFY\n");
              break;
          case IN_CREATE
              printf("CREATE\n");
              break;
          case IN_DELETE:
              printf("DELETE\n");
              break;
      }

      index += sizeof(struct inotify_event) + event->len;
  }
}

int main(int argc, char* argv[])
{
  GMainLoop *loop;
  GIOChannel *channel;
  gint ino_fd = 0;
  gint ino_wd = 0;

  /* inotify */
  ino_fd = inotify_init();
  ino_wd = inotify_add_watch(ino_fd, "/usr/share/applications", IN_MODIFY | IN_CREATE | IN_DELETE);
  channel = g_io_channel_unix_new(ino_fd);
  g_io_add_watch(channel, G_IO_IN, (GIOFunc)inotify_events_io_func, (gpointer)NULL);

  loop = g_main_loop_new(NULL, FALSE);
  g_main_loop_run(loop);
}

該範例將會監聽 /usr/share/applications 資料夾內的檔案更動 event ，並印出來。因為該資料夾是 FreeDesktop.org Spec 中用來記錄桌面 application 資訊的，當安裝或是刪除軟體時，即會收到檔案新增或刪除的 event。