這個週末利用了一些空檔時間，替 libfetch 加上了 RFC 2617 的 Digest authentication scheme 支援。原先的 libfetch 只支援 Basic authentication scheme，這使得帳號密碼的 Base64 會以明碼的形式在網路上傳遞，這是一件有點危險的事情，有心人士只要在你和主機中間，就有機會攔截到你的帳號密碼。Digest authentication scheme 利用了 nonce 和 MD5，把帳號密碼多做了一次加密處理，所以可以保護帳號密碼即使被攔截到也非常難以被破解。
我實作的部分並沒有涵蓋全部 RFC 2617 提到的範圍，但是已經足以和 apache 的 mod_digest_auth 溝通。剩下來還沒實作的部分，包括非 MD5 的加密演算法，以及 qop=auth-int 的全文加密部分。
動手以前問了一下 phk，他說據他所知沒人碰這一塊，所以我就把程式寫一寫，丟到 GNATS，剩下的就交給 des 啦。
下班回來，看到門上夾了一張通知，是公寓經理來通知我們要漲房租了。我們所住的兩房兩衛公寓，即將從四月份開始，調漲九十美金，漲幅大約五趴。
去年底和公寓經理聊天的時候，她提到大概漲個幾十塊錢吧，想不到一次漲了九十塊，實在有點不爽。不過問了一下身邊的朋友，結果幾乎都碰到類似的情況。比起從 1045 漲到 1250，和另一個從一千四漲到一千九的，我們的漲幅還算小的咧。
灣區住，大不易呀！
今天早上又翻了一下組織圖，赫然發現大老虎換了老闆了。不知道是不是我錯過了什麼，所以我就向克萊門打聽了一下是不是有什麼新消息。
「哈囉，你知道大老虎的主管換人了嗎？」
『是啊，他要去管新的部門了。在還沒找到新的大老虎之前，他兩邊都管。』
「聽起來我們要換老闆了？」
『你可以自願去接替大老虎，當個老虎總監呀。』
「我？你別搞笑了，我是老虎隊的菜鳥耶！」
『那不重要，重要的是你能享受一天到晚開會的工作。』
「呃，算了吧，我討厭開會。」
『真可惜，那你就永遠不能當主管了。』
嗯，看來，在我愛上一天到晚開會的工作以前，我還是乖乖的寫程式好了。
裁員滿一週，我才開始寫下過去一週的心情。
二月十二日，預定裁員當天，我提早一個小時到公司，但是並不是往自己的位子去，而是直接前往目前專案所在的部門繼續開發工作。辦公室內的會議室大半都被公 司給預定了下來，有不少的會議室裡面還堆著空的箱子，想必這些會議室是用來裁員時給老闆和他們的部屬們談話用的。我埋頭在程式堆裡面，時間過得很快，一下 子就中午了，我推開大門出去隔壁大樓買午餐，外帶回到自己的位子上吃，刷了通行證回到自己的大樓，嗯，我的識別證還有效，所以我沒被裁員，在心裡偷笑了一 下。在裁員當天之前，我並不緊張焦慮，從來不認為會砍到我。下午，大老虎發了個群組通知信，帶著一點他個人風格的黑色幽默說：「如果你看到這封信，表示你 安全了，」 順便召開一個臨時的老虎全員會議，只是我當時正在另一邊參加 Code review，所以就沒參加。
隔天，克萊門緊張兮兮的跑來找我說：「你知道老虎隊也有人被砍嗎？」我嚇了一跳，因為原本大老虎跟我們說老虎隊應該沒事的。原來裁員並不如原先猜測 的按照部門來砍，而是每個部門砍掉不同比例的員工，所以「人人有機會，個個沒把握」。一一對照員工個人檔案和組織圖，好一會兒我才發現被裁員的比爾坐在我 斜對面，但是從來沒有合作過。當時覺得，啊，雖然不認識，但是替他難過一下。克萊門接著提到共事過的瑞吉夫、史黛西，還有傑夫，通通都被裁掉了，這更令我 感到震驚。瑞吉夫和我合作開發過同一個系統，史黛西規劃專案進度與主持會議有條不紊，而和傑夫雖然只有過一面之緣，但是他也在短短幾個小時的 Code review 其間指出我程式的一些問題，可見功力深厚。他們幾個有的是柏克萊的高材生，有的曾經當過小公司技術副總，連這樣優秀的工程師都不能保住工作，那像我這種半 路出家的三腳貓以後怎麼待下去。
被砍的員工似乎沒有一定的特徵：有的已經白髮蒼蒼，有的是剛畢業的年輕小伙子；有的才剛進公司沒多久，有的甚至已經超過十年；有的部門被砍掉大半， 剩下的工程師調去支援別的服務；有的國家只保留幾個聯絡窗口，剩下的全部砍掉。除了被砍的第一線員工之外，經理級的也不少，包括一些總監們甚至是副總裁 們，都不能倖免於難：
之後的幾天，狀況一一浮現。例如瑞吉夫在裁員當天早上還發了一封信給大家說要改寫某個介面的參數，但是中午過後，人已經離開公司。上禮拜發信給說要 找泰吉斯設定測試機，卻收到他們主管私下的回信說泰吉斯被裁員了，以後請找西瑞亞。今天早上還收到史黛西設定的會議通知，不過她已經離職，所以也不會再由 她來主持會議。
經過這次裁員，感覺像是經歷了一場戰役，雖然早就心裡有數，傷亡難免，但是總是有身邊的人會中彈倒地，壯烈犧牲。還好公司並不像之前聽說的那麼殘 忍，宣布裁員名單之後就把人踢出公司，不少人還有機會回到自己位子上整理個人物品，發信向同事告別，甚至有的部門還有歡送午餐會，讓離開的同事們還能保有 一些尊嚴。
之後呢？很難說還有沒有下一波裁員。也有同事講冷笑話的說：「要是微軟買了雅虎，也不用宣布裁員，叫我們改行寫 Forth 就夠讓大家自願離職了。」唉，整個事件可能還得再拖個幾個月吧。
一直在想替這些工具取個名字，不然叫做 cc wrapper 和 ld wrapper 好像挺遜的。想來想去，就暫時叫做 cctidy 和 ldtidy 好了，不然乾脆兩個加起來合稱 devtidy，然後去 sf.net 註冊一個專案。
這兩天把 ldtidy 再改寫，加入了更多功能。現在已經可以處理 -rpath-link 和 -rpath。此外，除了會檢查連結順序以外，現在還會檢查相依關係了。
中大型專案裡面，一個函式庫拉幾十個函式庫進來，有的是 .so，有的是 .a，時間一久，經過幾次改版，大概從此之後就再也沒人能找出這些函式庫到底哪些還有在用，哪些應該拿掉。ld 並不會幫你過濾掉用不到的函式庫，objdump 也會照單全收的告訴你所有的函式庫我通通都要（NEEDED），所幸 nm 會幫你列出 symbol，所以 ldtidy 才有機會藉著 symbol 的交互參照，決定哪些函式庫有用到，哪些函式庫沒有。
整個相依關係可以畫成一棵樹，假設我們正在編譯的 A.so 拉了 B.so C.so D.so，其中 B.so 拉了 F.so 而 D.so 拉了 H.so，當我們一股腦兒的拉了 [A-H].so 的時候，ldtidy 會很盡責的列出它們的相依關係，並且在最後提出警告說「A.so 不需要 -lE」「A.so 不需要 -lG」。
不過在實際上的開發案例中，這些函式庫有可能是隨著其他的函式庫的 -config 一起帶進來的，例如 xml2-config --libs 會帶入 -L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm，但是可能你的程式從頭到尾都沒有用到和 iconv 有關的那一塊，這樣的話 ldtidy 就會抓到「正在編譯的程式不需要 -liconv」，但是因為它是跟著 `xml2-config --libs` 一起進來的，要把它拿掉有執行上的困難，所以 ldtidy 只會把這個當成 WARNING 而非 ERROR，只會顯示訊息，而不會中斷連結。
如此一來，ldtidy 不但可以幫忙檢查連結順序，也可以幫忙檢查函式庫相依關係囉。
前一篇的 ld wrapper 解決的是函式庫連結順序的問題，而這一篇的 cc wrapper 解決的是標頭檔相依性的問題。
在某些專案內，常常會碰到需要繼承一個通用模組，然後實作底下的方法來執行一些特定的動作，而最常見的開發方式便是複製一個已經會動的模組，把裡面的主邏輯換掉，直接套用已經寫好的介面或者輔助函式。 這的確是最簡單的方式，但是也造成了很多後遺症。
舉例來說，一個檔案被複製好幾次以後，每個人都加上了自己所需的標頭檔。有一天老闆說，去寫一個 foo 的模組吧，拿 bar 來改就行了。開發者把 bar 的檔案打開一看，洋洋灑灑前面放了幾十個標頭檔，想必 bar 本身也是複製過好幾手的模組了。這些標頭檔，也許留著並不會影響現在程式的編譯，但是卻會破壞程式的相依性並且拖長編譯時間，甚至日後被其中之一的標頭檔 的變動而拖累變成無法編譯。
這時候，開發者怎麼決定這幾十個標頭檔哪一些有用到而該留著，哪一些沒用到而要砍掉？
cc wrapper 就是來解決這個問題。它的用法和 ld wrapper 一樣，都是藉著類似 ccache 的方式來執行，把執行檔放在系統之中的任何位置，然後在環境路徑裡面優於 /usr/bin 的地方放一些名叫做 cc c++ gcc g++ 的連結指向這支 cc wrapper，或者直接定義環境變數 CC 和 CXX 指向這些連結，接下來的工作便交給 cc wrapper 執行。
cc wrapper 會掃瞄 *.c *.cc *.cpp 之類的原始碼檔案，找出標頭檔，並且利用「真 cc」的 -M 功能，決定這些標頭檔的真實路徑，加上呼叫「假 cc」時傳入的 -D 變數，cc wrapper 無須擔憂條件式編譯（-DFREEBSD 與 #ifdef FREEBSD ... #include ... #endif）以及多重引用路徑（程式中有 #include
接著 cc wrapper 會檢查標頭檔之間的相依關係，並且確認該原始檔是不是真的需要該標頭檔。在某些情況下，多餘的標頭檔並無法被掃乾淨，例如 a.c 拉了 b.h c.h d.h，而 b.h 拉了 d.h，所以即使 a.c 裡面只用了 b.h 和 c.h，而完全不使用 d.h 所定義的函式或變數，cc wrapper 也只能列出來說「a.c 可能不需要 d.h」而不能直接斷定「a.c 不需要 d.h」，因為即使從 a.c 中移除 d.h，該 d.h 一樣會跟著 b.h 被帶入編譯。
另外 cc wrapper 會幫助程式開發者把標頭檔放在正確的位置。例如 a.c 裡面拉了 a.h，而 a.h 拉了 b.h，但是 a.c 使用了 b.h 所定義的函式，反而 a.h 的宣告和 b.h 無關，這時候 cc wrapper 會先警告「a.h 不需要 b.h」，而當開發者從 a.h 移除了 b.h 後，將會造成 a.c 的編譯失敗，這時候開發者再把 #include "b.h" 補回 a.c，這才是正確的位置。
有了 cc wrapper，將會有效的抓出程式中用不到的標頭檔，降低維護的成本，減少編譯出錯的機率。
這週末寫了一支開發工具 cc wrapper，連同之前寫的 ld wrapper，大概可以包一個開發工具套件吧。ld wrapper 可以降低連結出錯的機率，而 cc wrapper 可以修正檔案相依關係並提高編譯速度。
今天先介紹 ld wrapper。
在大型的專案常常遇到一個問題，就是拉了一大堆的函式庫進來編譯，這些函式庫裡面有些是 .a 有些是 .so，而不同的 .so 又可能拉了同一份的 .a 進來，或者某 .a 拉了另一個 .a。這時候如果沒注意版本控制和連結順序，就會在二進位檔案裡面埋下地雷，造成日後難以追蹤的問題。例如，A.so 拉了舊版 B.a，C.so 拉了新版 B.a，而程式會拉到 A.so 和 C.so，所以編譯的時候會需要連結這三個檔案。某天，程式出錯了，而用 gdb 從 C.so 追下去的時候，無法得知目前挖到的 B.a 是舊版還是新版。另外如果 D.a 會使用 E.a，則 D.a 也必須在 E.a 的前面。
要避免這個方法，有一個小技巧：永遠把 .a 放在 .so 的前面，另外先載入的也要放前面。這個小技巧聽起來簡單，但是要是面臨幾十個目錄，每個目錄都拉少則三五個，多則數十個函式庫來編譯，那檢查起來就很累人了。
我寫了一個 ld wrapper，來幫忙執行上面這項工作，而程式開發者不用作任何改變，只要把「假 ld」放在路徑之中優先於「真 ld」的位置，讓「假 ld」的 wrapper 來執行順序的檢查工作，如果沒問題再呼叫「真 ld」來連結，就可以避免因為連結順序而造成的問題啦。這個執行模式的點子來自 ccache。
附註：另一個方法是在 gcc 編譯的時候加上某個現在臨時想不以起來的參數，但是這樣會拉長編譯所需時間，所以不建議。
雅虎董事會正式拒絕了微軟的併購，看起來和之前預期的一樣（詳見：公司未來的五個結局）， 但似乎也沒把話說死，現在就等微軟的回應。雅虎董事會覺得微軟開價 31 太低，分析師也估計微軟會加碼到 35，而且新聞也提到了一年之前曾經有開價 40 的併購提議，只不過當時並未公開，而且 Semel 拒絕而不了了之，這次微軟直接將併購案訴諸投資大眾，大概是想藉著股東們的力量施壓雅虎董事會吧。新聞還有提到微軟打算在雅虎董事會發動政變，聽起來挺嚇 人的。
至於微軟到底會不會加碼呢？之前有新聞揭露，光是為了準備 31 的併購案，微軟就已經要借錢來買雅虎了，如果加碼到 35 甚至 40，那對於微軟的資金壓力就更大了。我想微軟的投資人應該不太高興，因為併購案公布後的這一週，微軟就跌了八趴，現在雅虎拒絕了微軟，不知道雙方的股價 會有怎樣的互動。
不過在擔心這個之前，還有一個更早要來臨的事件，就在下禮拜二。
和朋友聊到有經歷過裁員的公司，描述的過程都大同小異，沒概念的可以參考 這一篇，只是我聽到的美國的版本更硬，被通知之後直接由警衛 押 送出公司，然後過幾天公司再把位子上的私人物品打包寄回家。
希望我以及身邊的同事朋友們都能順利度過這一關。
看來今天下班前就有答案了。同事們聊八卦，有人支持微軟，有人支持估狗，有人覺得都好，重要的是股價炒高一點就好，像我就是。
這兩天 YHOO 的股價甚至高過 MSFT，不知道會不會因為答案揭曉而有劇烈的變化。
記得很久以前謠傳微軟想買雅虎的搜尋部門，雅虎不想拆開賣而作罷。哈，突發奇想一下，不知道現在有沒有可能把雅虎拆兩半，「雅虎搜尋」賣給微軟，「雅虎非搜尋」賣給估狗，這樣皆大歡喜。
這兩天想弄一個地圖的應用，書籤裡面存了一堆東西都指向 flickr.tw，想起了之前事件，但是確有令人出乎意料的發展。身為開發者，看著存了一堆 broken link 的書籤，心裡實在不痛快，再炒炒冷飯洩憤。
之前 Yahoo! Inc 發律師信給 CK，要求歸還 flickr.tw，CK 索性關了網站，一了百了。當時我亂猜（詳見：Flickr.tw 最後還是關站了），Yahoo! Inc 會在 flickr.tw 過期之後搶進，今天一看，顯然我猜錯了。
根據 Whois 記錄，舊的 flickr.tw 在 2007-11-18 過期，CK 也的確放棄續約，但是 Yahoo! Inc 並沒有接著註冊，反而就這樣擺著，直到 2007-12-21，由另一位 Eric Lin 註冊了 flickr.tw 然後指向國外的 web hosting 網站。
老實說，我實在不知道高層在想什麼，這件事情絕對是個全盤皆輸的局面：
最後誰得利了呢？搶註冊的 Eric Lin 嗎？不知道，等著他的不一定是洽詢購買網域名稱的交易，也許是另一封催討網域名稱的律師信。
最近有同事提醒我說我講太多了。坦白說，我這兒寫的都是已經見報的東西拿來炒一炒，沒有什麼「內幕消息」，了不起加上一點喃喃自語罷了。如果你想瞭解我身邊發生的事情，以及我對這些事情的想法，歡迎繼續收看；如果你想從我這裡挖到一點公司內幕，那你可能要失望了。
今天看到一則新聞：
簡單翻譯一下：
雅虎最近的併購和合作案，有下列五種可能的結局：
我個人覺得一是最理想的情況，但是離目標還有一段距離，革命尚未成功，同志仍須努力。三、四機會都不大，沒什麼好討論的。對於微軟，我之前已經提過（詳見：Powerset 的創業團隊和工作環境）： 「要是 Microsoft 買下 Yahoo! 然後叫我改用 Windows Server 寫 ASP .NET，那還不如叫我滾蛋比較快。」不過如果只是換個招牌，我還是繼續用在 Unix 上寫 GCC，我倒是沒有那麼痛恨微軟。至於估狗，傳說中的絕佳福利和超高的股票選擇權（雖然已經五百多了，但是還是有人喊出上看八百），自然是一大誘因，雖然 也有碰過有人抱怨估狗的員工健康保險不好之類的小問題，但是瑕不掩瑜，依然是「全世界科技人最想加入的公司」。
以最近發生的事情來說，我覺得裁員對我影響不大，最多就是卡住申請身份的流程一段時間，但是在「賣給微軟」以及「和估狗合作」兩者之間擇一，則是令 人陷入兩難。賣給微軟之後，以 Hotmail 當例子，即使花了八年，最後還是把絕大多數的主機換成了 Windows，這表示將來總有一天的工作內容會受影響。和估狗合作的話，表示公司將割捨一部份甚至全部的搜尋與廣告事業，我自己對這些相關技術也很有興 趣，而且我身邊超過半數的台灣同事們都在這塊的相關領域，這會對我們的職業生涯有立即的改變和衝擊。
不過，畢竟我只是個小囉囉，就算再怎麼多廢話也只是自己的喃喃自語罷了，繼續寫程式比較實際。
