Loda's blog

ARM的商業模式是如何煉成的？

loda — Sun, 20 May 2012 16:30:55 +0000

ARM的商業模式是如何煉成的？

http://blog.csdn.net/szu030606/article/details/7580647

導讀：保守、嚴謹，又有一些皇族氣質，作為一家擁有純正英國血統的公司，ARM看似呆板的作風卻讓其在移動互聯網大潮中勢如破竹，沒有對手。也許過於看重產業鏈夥伴的聲音，導致ARM的決策有些遲緩，比如沒有更早的在中國設立研發中心。但這也許就是ARM與生俱來的基因，聽取生態系統中的夥伴的聲音，專注自己的事情。對於未來，ARM對伺服器市場充滿信心，在ARM總裁兼COO Tudor Brown看來，“ARM的技術太誘人了，Intel完全不在一個水準上。”電子工程世界對Tudor Brown進行了專訪，以下為全文：
三月中的某一天，我與ARM總裁兼COO Tudor Brown見面時，就拿出了自己的iPad並對他表示謝意：“如果沒有ARM，現在人們可能用不到這樣簡單有效的設備。”
在見面之前，我試圖打探一些關於Tudor的消息。讓我吃驚的是，作為一個英國人，Tudor在中國有著很多的好朋友，所以這次見面，我還有一個重要任務，就是為Tudor帶來老朋友們的祝福。畢竟，Tudor也許是以ARM總裁的身份最後一次參加中國媒體的訪談，因為在今年五月，他就要退休了。在休息室，我與同行的一名資深記者閒聊，在ARM成立上海辦公室時，她曾對ARM進行過專訪，“記得我們去上海的時候，都不知道ARM是怎麼回事兒，也不知道ARM的商業模式。而現在，ARM的成功是顯而易見的。”
如何描述ARM
我一直在思考如何詮釋Tudor，詮釋ARM以及詮釋整條產業鏈。
讓我們先從一張老照片說起吧。

這張照片是ARM的第一次合作夥伴大會，此時距離ARM獨立還不足一年，右三為當時ARM CEO，前任IET主席Robin Saxby爵士。右一為ARM CTO Mike Muller，這位前惠普員工當時是作為系統架構負責人加入ARM，2000年10月至今一直擔任CTO。
坐在他們對面的是ARM的三個投資方，分別來自Acorn、Apple和VLSI。
不過Tudor並沒有在照片中出現，作為最早加入ARM的12位員工，Tudor 和Mike Muller，Pete Harrod以及Al Thomas負責公司的硬體設計，主要從事視頻及記憶體設計。

再來看另外一張老照片，這張照片出自ARM的官方微博，原話為：“猜猜ARM 12位創始人有多少仍在ARM？答案是6位！即使明年布朗先生退休也還剩5位。公司的凝聚力真的很重要。”另外我想補充下，實際上其他一些創始人儘管已不在ARM，但ARM卻是他們服務的最後一個公司。
我想，ARM的這種企業文化應該是源於其獨特的商業模式，在這種授權方式的商業模式下，只有凝聚全產業鏈的資源才可以做到，對於產業鏈如此，員工自身更是有著如此強大的凝聚力。
說到授權模式，我們可以看看當年ARM所設想的三種授權：

所以我向Tudor提出了這個問題：“ARM當時是如何想到這種商業模式的？”
Tudor ：“這可能是從我很多年前的決定中得到啟發，當公司成立的時候我們清楚地知道ARM的技術是頂尖的。但是不要忘了我們是一家在英國的公司，而在英國是沒有龐大的半導體產業的，這種條件既是一種限制，同時也是一個創造新的商業模式的機會。當時我們想到了這樣一種模式，這個也是一個非常大的試驗，我們一旦確認了這是我們的目標後，我們就共同朝著這個目標去努力。在過程中ARM也在不斷地對這個業務模式進行調整，同時重新定義了公司的運營模式。這樣一種業務模式可能是要一個不太一樣的思維，和其他業務模式相比，它更傾向於在很多事情之間找到一個平衡點。如果你要找到最準確的平衡位置的話，是要不斷地去回顧我們取得的一些成績。”
Tudor以如何平衡授權費和版稅來舉例：“在一開始，我們決定一定要收授權的費用，用它來支撐公司運營的開銷。當我們的客戶取得成功以後版稅對我們來說就像一個獎勵機制，是公司能夠變得有盈利。其實當時我們已經做好了最壞的打算，即使我們永遠收不到版稅的費用的話，公司也是能夠靠授權費用生存下去。因為我們當時很清楚的認識到，我們的成功需要很多年時間。事實上ARM版稅收入直到1997年才有了明顯的增加。另外一個平衡，就是如何權衡利益歸屬，哪些是應該歸ARM所有，哪些是歸生態環境所有。如何平衡開發新產品與繼續使用舊產品之間的平衡。”
“所以在ARM裡，大家永遠都是在討論，甚至爭論，到底哪種結果才是最好的。這也是為什麼對於ARM來講，我們需要不停地聆聽客戶的需求。”Tudor表示。
20年前的SWOT分析
從一份廣泛流傳的關於ARM歷史的PPT中，我找到了20年前的SWOT分析，在這個20年前的分析中，明確的指出了ARM的優勢和劣勢。這是個很有趣的事，畢竟如果現在回過頭來看，很多分析現在仍然是正確的，而有些已然從弱勢變成了ARM的優勢。

EEWORLD冀凱：“如果讓您現在重新給ARM做一份SWOT分析，您會如何考慮？”
Todor ：在過去的這些年裡我們制定了很多原則，如公司應該怎樣運行，員工應該怎樣表現，比如說我們的原則裡面有一條就是團隊合作比個人的單打獨鬥更重要，我們要對事情作出快速回應，要求員工積極主動為客戶著想等等。我相信即使我要離開ARM公司，這一套標準在未來的20年裡還是會存在的。
如果說到SWOT分析，我們現在處在一個最好的時代，機會最多，當然我們的弱點仍然會存在，這需要我們不斷去正視、有效地解決。任何一個公司都會面臨各種威脅，其中對於我們來說有一個威脅就是我們可能會把自己的未來想的過於美好，這個也是一個非常大的威脅。我不認為ARM是一個過於自滿的公司，但我們要小心，因為每一家企業都有可能很容易走到那一步。這就是我認為ARM面對的最大威脅。
Quora
ARM技術涉及幾乎所有的電子產業，而我也試圖邀請行業從業者提問，力圖從各角度完整的描述ARM。
某中國IP行業從業者以及某SoC晶片公司從業者：現在使用ARM架構，大家可以很好地降低研發成本，加快產品上市週期。但從智慧手機市場來看，現在好像陷入了軍備戰爭。晶片的生命週期變得越來越短，從購買（授權）一個核至推出晶片，再到最終推出終端產品，這個時間對於大部分廠商來說是否過長？如何保證廠商收回投資？
Todor ：儘管看起來我們推出新產品的速度比較快，但這個問題並不能這麼簡單的看。我們有三個獨立的產品系列：A、R及M，以及我們的圖形產品Mali。這些產品授權給眾多公司或公司裡不同的設計團隊。以最流行的Cortex A系列來看，A9推出兩年半之後推出了A15，完全符合手持類消費電子產品更新週期。另外，儘管有一些技術市場領先的廠商可以在早期就推出新產品，但基於商業市場的種種原因，舊款產品持續時間很長。Cortex A9現在是最主流的高端移動處理器，但在ARM的所有產品出貨量中所占的比例依然相當少。我們出貨量最大的產品仍然是ARM7、ARM9及ARM11的授權。
另外需要注意的是，我們配合合作夥伴的產品開發計畫，推出最尖端的技術，這時，我們能夠聽到客戶更多的抱怨反而是研發進度過慢而不是過快。
飛思卡爾單片機市場經理曾勁濤：“ARM現在已經進入了伺服器、MCU等領域，未來ARM還打算進入哪個大的市場？ARM進入新市場的方式是通過自身成長抑或收購？”
Tudor：其實所有的市場對於ARM來說都是一樣的，我們的工作並不是針對某個市場去設計技術或產品，而是為一系列的應用提供一個合適的產品。事實上，的確在公司的歷史上，我們可能會針對部分細分的市場，比如五年前在MCU領域和現在的伺服器市場。但歸根結底，ARM的任務只是按照市場需求設計路線圖。
在MCU市場，我們需要推出更小的，功耗更低的產品，在伺服器市場我們則需要重點考慮產品性能，而對於手機市場，高性能，低功耗及安全性又都是重要的。與此同時，汽車電子要求安全及可靠性，當我們開發車用市場同時，發現工業或醫療設備中同樣需要該技術。所以對於ARM來說，哪怕我們只針對某個特定市場做開發，最後也可以變成普遍的需求。
關於第二個問題，ARM兩者都會考慮，縱觀ARM的歷史，物理IP及圖形IP兩塊業務都是通過收購得到的，我們更好地模式是通過收購之後，再通過自身使其成長，對於ARM來說，這是一個比較成功的模式。
QNX軟體公司中國南方部銷售經理哈駿元：“近年來，晶片廠商紛紛收購軟體作業系統公司，從而向市場提供更完整的系統級解決方案，例如英特爾收購風河，網路處理器供應商Cavium收購Montavisa。請問ARM在軟體技術的投入上有何計畫？尤其是面對ARM新進入的細分市場，如網路通信，工控和汽車市場。”
Brown：其實有一些企業會在某些市場達到一個成熟的情況下，在這些市場尋找一些收購的機會，但是有時這種收購的意圖有時我們看得清，有時我們看的不是很清楚。ARM的戰略是非常簡單的，我們是希望能夠打造一個開放的生態環境，所以如果一家企業要來支援ARM的話，最好的辦法就是能夠讓它獨立地對ARM進行支持，而不是由我們所控制。所以ARM向來是希望是一個使能者（Enabler）而不是控制者，這也是為什麼現在我們有這麼強大的、數量眾多的一個生態系統。這個模式也得到了我們合作夥伴的認可。
中國軟體行業協會嵌入式系統分會副秘書長何小慶：“ARM從ARM7開始一直發展到現在，包括後來推出的64位元指令集直指伺服器市場，這樣一個從低端到高端的覆蓋的領域越來越寬泛，我的問題第一個是要支持這麼寬泛的應用，今天的ARM會不會面臨著比以往更大的技術挑戰和商業上的不確定性。”
Tudor：的確，我們現在的產品覆蓋範圍比以前廣了許多，但我們並不是為了開發而開發，也不是為了兜售新產品而不斷創新，ARM以市場需求的角度開發，傾聽來自授權合作夥伴方的需求，他們會告知ARM的需求，從而一起去定義未來的產品路線圖。不同的聲音不光來自半導體廠商，還包括OEM廠商、作業系統公司、大學研究院，當然也包括我們自己。通過這些討論，我們會探討如何設計一樣新技術，以滿足各方需求。
ARM的業務模式決定產品在多次授權的情況下才可以成功，也就意味著我們要為更多人提供有價值的技術。
某IT資深媒體人：“有人評論ARM進軍伺服器領域的難度不比intel進軍移動互聯領域的難度小，您如何看待？”
Tudor：首先要澄清的一點是並不是說ARM已經在伺服器市場，而是說我們的技術可以被用在也將會被用在這個市場。為什麼我們相信ARM將會被用在伺服器市場呢，是因為我們的解決方案能夠提供遠遠超過現有解決方案的功耗，在性能功耗方面我們提供的是非常好的解決方案。但可能需要一點時間，因為目前這個市場，大家可能對Intel的X86比較熟悉，所以需要花時間讓生態系統逐漸來熟悉不一樣的技術。但是因為ARM提供的技術實在是太誘人了，所以這件事是一定會發生的。所以，我覺得這個難度不可以直接對比，因為從一個用戶的角度來看的話，Intel對移動市場並不能提供什麼吸引人的東西，所以並不是一個類似的、可比的情況。
關於中國
Tudor經常造訪中國，對於中國半導體產業的發展做出了極大貢獻。中芯國際設計服務副總裁湯天申博士對於Tudor的評價非常之高，他表示：“ARM 與中芯國際有著長期的合作，我們欣慰地看到，在 Tudor Brown先生的領導下，ARM成長成為全球第一的IP公司，成為中芯國際的戰略性的合作夥伴。我本人與Tudor Brown先生有幾次非常深入的交談，我非常讚賞他對IP產業和中國晶片設計產業的深刻理解和深邃前瞻。”
瑞芯微電子是一家受益於ARM的晶片設計公司，其首席市場官陳鋒提問：“請問Tudor對於中國芯未來有什麼期望？”
Tudor：如果你問我中國芯的未來會怎樣，這個是沒有人知道的，但是我能看到的是現在中國有些公司未來是一定會取得成功的。有些中國的企業已經在特定的領域呈現出來自己的經驗或者是專長，我可以確定他們會在這些領域維持住他們市場領導的地位。中國又是一個不太一樣的國家或者說是市場，很多各種各樣的實驗都在進行。現在的中國和矽谷一樣，成功或者失敗每時每刻都在發生著。但即便失敗發生，會有一批人得到了豐富的經驗以及創新的想法，可能會對下一輪的經營帶來一些積極地作用。當然對於我來說，可以簡單地將中國未來描述成一片光明，但是一定會有一些挫折，這個是很正常的過程。
與此同時，我也看到一些中國企業很樂於或者說很有信心地去改變他們的經營模式，儘管他們做的這些改變會帶來一些不可知的結果。比如說山寨現象，沒有人在它出現之前會預言到會有這個現象，其實也給很多人帶來了益處，而且目前這種模式在其他領域也得到了成功複製。我個人的結論是，一定會有一些傳統的半導體行業企業會獲得成功，但在中國這片神奇的土地上有大量的在改變遊戲規則的企業，他們可能會帶來一些不一樣的結果，這可能會成為對其他企業的威脅。
總體來說這是個令人興奮的未來，沒有人預計它到底會怎樣發生，但是我很願意看到到底是怎樣一個結果。前面提到了業務模式，其實在中國我們的業務模式也一直受到一些挑戰，我們也會針對中國做出一些改變。包括我們中國的團隊經常把一些本土客戶的需求告訴ARM全球，總部會針對需求進行一些調整。
ARM中國區總裁吳雄昂在此補充道：半導體行業本身就是一個全球性的行業，但是從消費電子市場終端劃分來看，又分為本土市場和國際市場。終端市場的差異化在經過了移動互聯與雲計算之後被放大了，呈現出多樣性特點。產品的更新速度更快造成了軟體工作量變多，對於半導體行業來講，深層的難度和挑戰增加了。
同時反過來講，半導體產業鏈重新洗牌以後，中國企業開始有了機會，自信心得到了提高。而如果產業鏈要不洗牌，純粹照搬西方模式，可能80%的半導體公司是很難存活在下來的。中國的客戶自信心有兩個點，第一個因為有本土市場與國際市場差異化的問題，這個本土市場不光只針對中國，而是全球化的西方市場與發展中國家市場的區別。第二個是在過去十年以來中國企業看到純粹靠成本競爭不是一條出路，所以他們在幾年間下大力度開展平臺化建設。在移動和互聯網產業鏈變化之後，通過對市場的積累，可以再對產業鏈進行創新。比如說原來做電視的可以做機上盒，做機上盒的又可以轉做手機。
另外生態鏈也在變革著，就是我們過去所謂的生態鏈合作，必須通過一家主導的公司來做。而現在這條生態鏈打亂了，重整後的生態鏈跟過去完全不同。這也是我覺得為什麼中國企業信心這麼高，投資這麼多的原因。
關於未來
對於ARM以及Tudor的未來，對這個話題感興趣的不光是媒體、ARM的合作夥伴甚至包括ARM的員工：“對ARM公司今後的發展有沒有一個新的思路或者是想法。”
Tudor：我堅信ARM現在處在一個非常良好的發展勢頭，接下來仍然會推出更多的非常好的產品，給我們的日常生活帶來一些變化。回頭看我在ARM長達25年的職業生涯，對我們在這個過程中取得的成績我也是倍感欣慰的。儘管我們有很好的技術，我也對ARM的技術很自豪，但更讓我自豪的是我們創造的這種虛擬的業務模式，可能在行業裡也是獨一無二的。能夠做到這一點的很大的原因是更多的時候我們是在聆聽，而不是去指導別人。所以更多時候我扮演的是一個催化劑的角色。”
“有沒有在任期間有一些比較遺憾的或者是還沒有達成的目標或是心願？”
Tudor：的確，這二十多年的過程中有時有一些失望我們也經歷過，我們也經歷過一些失敗，但是這些都是比較小的，所以也不會說是真正的遺憾，但是如果一定要說的話，ARM這個公司有時在看到一些變化的時候反應速度可能有點慢，因為可能更多的時候我們習慣了去聆聽，聽了很多以後再來做決定，這個導致我們有時反應速度稍微慢了一些。另外我們可能應該更早地在中國做一些工程技術方面的工作，大家可能也知道ARM在上海有一個設計中心，有很多我們的工程師，可能我們現在再回頭看，更早一點啟動中國工程會好一些，因為中國的產業發展比我個人預期的要快很多。
“很想知道您退休以後最想去做什麼，怎麼去安排自己未來的生活。”
Tudor：我很清楚地知道現在是一個最好的時機離開ARM，由一個更年輕的團隊帶領ARM進入下一段旅程。但在這麼長一段時間ARM在我的生活中成為我生命最重要的一個部分，現在很難說以後要幹什麼，因為可能得等到我真的離開了才能想到自己以後要做什麼。我相信我的未來還會很活躍，但是說在什麼領域以什麼方式的話現在還不清楚。
採訪後記：
ARM的成功一項最重要的原因就是懂得聆聽，這也是為何我這篇文章幾乎都在使用Tudor的原話，儘管這麼一篇文章遠遠不夠紀念Tudor的一切功績，但我希望通過這種方式來原原本本的展現Tudor，因為這些話都可以看做他二十五年的提煉。
在我徵集問題時，得到了廣大網友和產業鏈同仁的熱情回應，這裡不一一答謝，我僅代表他們，希望Tudor今後一切順利。

People who looked at this item also looked at…

中國出產拇指大小的Android 4.0電腦售價500元人民幣

loda — Sun, 20 May 2012 16:30:46 +0000

中國出產拇指大小的Android 4.0電腦售價500元人民幣

http://www.xinpuit.com/content-6-1616-1.html

作者：simpleit
當全世界都在詬病Android分化和分裂，硬體開發商卻在自顧自的繼續出產各種型號的Android設備。還記得去年CSDN報導過的一家挪威公司出品的《僅重21克：USB大小雙核Android迷你電腦Cotton Candy》嗎？現在國人的驕傲來了：一款大小差不多但是更便宜的搭載Android 4.0的具備USB插口和HDMI埠（注意是port不是plugin）的代號“Model#MK802”稱為“Android 4.0 Mini PC”的設備，就是下圖中的這個。

圖片來源：CNX Software
當然這款設備並為搭載雙核CPU，而是基於AllWinner A10 CPU。CNX Software給出了比較詳細的資料：

CPU	AllWinner A10 @ 1.5GHz + Mali 400 GPU
記憶體	512MB RAM
Storage	4GB Flash microSD slot (Up to 32GB)
網卡	WiFi 802.11b/g
USB	micro USB 2.0/OTG port USB 2.0 Host port
鍵盤	Android虛擬鍵盤或者 2.4G 無線鍵盤 + fly mouse
視頻輸出	HDMI (1080p)
支援的視頻格式	WMV/ASF/MP4/3GP/3G2M4V/AVI/MJPEG/RV10/DivX/VC-1/MPEG-2/ MPEG-4/H.263/H.264/1280720P HD 30 fps, 1080P/720480 D1 30fps
支援的音訊格式	AAC, AAC+, eAAC+, AMR-NB, AMR-WB, QCP, MP3, WMA, WAV, MIDI, M4A
作業系統	Android 4.0 (ICS)
電源輸入	5V/2A
機身尺寸	8.83.51.2cm
機身重量	200g

從給出的資料來看，比挪威的Cotton Candy重了不少。令根據liliputing提供的消息，該設備已經在AliExpress開售，價格$74美元。我從這些小東西身上看到了未來PC的雛形……

People who looked at this item also looked at…

LLVM (Low Level Virtual Machine) 筆記

loda — Sun, 20 May 2012 16:30:42 +0000

LLVM (Low Level Virtual Machine) 筆記

by loda

hlchou@mail2000.com.tw

很喜歡愛因斯坦所說的這段話,“ 在科學上,每一條道路都應該走一走. 發現一條走不通的道路,就是對於科學的一大貢獻.科學史只寫某人某人取得成功,在成功者之前探索道路，發現 ‘此路不通‘ 的失敗者統統不寫,這是很不公平的“ . 第一次看到LLVM技術時,當時會心想跨平台的技術,不是已經有了JAVA 虛擬機搭配JIT(Just In Time)技術,或是微軟所推的.Net 也基於支援IL Assembly可以在跨平台的方案上得到滿不錯的效能. 又一個新出的LLVM跨平台技術,真的能帶來跟以往不同的好處嗎?

在深入探究LLVM後,其實不論是在效能 (可以參考OpenBenchMark網站http://openbenchmarking.org/result/1204215-SU-LLVMCLANG23 ),支援語法的廣泛性(包括 C/C++ 都可以直接編譯為LLVM BitCode),並且也支援指標,函式指標,Inline Assembly,對於一般應用程式的轉換上,成本可以大幅度的降低,所產生的BitCode除了可以透過LLI（LLVM Interpreter)執行外,也可直接轉譯為所在平台的機械碼.對多數的開發者而言,光是可以讓C/C++開發的成果只要由開發者編譯一次後,就可以擁有跨平台的特性,對許多產品開發上就已經很有誘因了.

實際下載LLVM編譯安裝前,可以先透過http://llvm.org/demo/index.cgi 由LLVM所提供的線上測試網站,在這可以嘗試把不同的C/C++語言透過LLVM線上轉譯為對應的BitCode Assembly語法,而這樣的IR中間語法,就可以再透過LLC轉譯為不同平台上的原生Assembly Code.

LLVM是由Vikram Adve與Chris Lattne在2000年開始進行開發,透過編譯器的技術,可支援把C/C++,Object-C,Fortran,Java ByteCode,Python,ActionScript以及其他程式語言編譯為LLVM BitCode Assembly. 基於這跨平台的BitCode Assembly就可以再轉譯為目標平台的可執行機械碼. 並在2004年於 Code Generation and Optimization (CGO’04)上發表了’LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation ‘ Paper (文章可在這取得http://llvm.org/pubs/2004-01-30-CGO-LLVM.pdf, 投影片網址http://llvm.org/pubs/2004-03-22-CGO-LLVM-Presentation.ppt),介紹當時LLVM LifeLong Optimization 概念,並在這Paper中提到LLVM幾個主要的特色

1, RISC Like的指令集.

2, 以SSA(Static Single-Assignment) 形式提供數目不設限的虛擬暫存器

3, 以Load/store 指令存取型態定義的指標(Typed-Pointer)

4, 基於SSA可明確資料在運作過程中的傳遞流程

5, 提供跟語言無關的形態資訊

6, 在exception的支援上提供 setjmp/longjmp實作的Exception機制,並提供 invoke指令可呼叫一個需要帶有Exception Handler的函式,與提供Unwind指令,能透過Stack Frame回推到上一個invoke指令位置.

在2005年時,Chris Lattner加入了Apple,也藉此讓LLVM成為Apple官方所支持的編譯器方案.在2005年以前,LLVM一直沒有在實際的商業化產品中導入,直到2005年後,才開始應用在相關商業產品中.有關LLVM 技術在Mac OS X 上的演進可以參考以下的連結 http://arstechnica.com/apple/reviews/2007/10/mac-os-x-10-5.ars/11#llvm 與 http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/9 .

在支援C/C++的部份,LLVM的前端可以為llvm-gcc或是Clang.

以llvm-gcc來說,這是基於GCC修改而來支援 C/Object-C 的LLVM C Front End編譯器工具,並因此而擁有許多GCC故有的能力,llvm-gcc可用來產生最終的執行檔案,或是LLVM BitCode 二進位檔案,或是LLVM Assembly原始碼.llvm-gcc在不加入任何參數下的預設行為跟原本的gcc一樣,會產生最終的可執行檔案,如果是加上 -emit-llvm與-c則是會產生LLVM BitCode的二進位檔案,若加上-emit-llvm與-S則是會產生LLVM的Assembly原始碼.

既然已經有了llvm-gcc作為llvm的前端,又為何要有Clang呢? 可以參考這網頁上的訊息如下(http://linuxtoy.org/archives/llvm-and-clang.html )

Apple 使用 LLVM 在不支援全部 OpenGL 特性的 GPU (Intel 低端顯卡) 上生成代碼 (JIT)，令程式仍然能夠正常運行。之後 LLVM 與 GCC 的集成過程引發了一些不快，GCC 系統龐大而笨重，而 Apple 大量使用的 Objective-C 在 GCC 中優先順序很低。此外 GCC 作為一個純粹的編譯系統，與 IDE 配合很差。加之許可證方面的要求，Apple 無法使用修改版的 GCC 而閉源。於是 Apple 決定從零開始寫 C family 的前端，也就是基於 LLVM 的 Clang 了。

由此可知Clang(官方網站為http://clang.llvm.org/)將會是未來LLVM所主要搭配配的前端C/C++編譯器工作.

LLVM本身主要是從處理器CPU的角度來進行虛擬化,也就是說讓各種語言所開發的應用程式都可以透過前端編譯器轉譯為LLVM虛擬處理器所能執行的BitCode,再將 BitCode轉譯為不同處理器平台的指令集(目前支援像是x86, ARM, MIPS,PowerPC,Sparc,XCore,Alpha…etc 處理器指令集).也因此LLVM Compiler只需要專注再LLVM對BitCode轉譯為不同處理器平台機械碼優化的任務上即可,而不需在前端去面對各種不同程式語言的編譯與優化工作.LLVM的前端包括像是llvm-lua(http://code.google.com/p/llvm-lua/)可以把lua編譯為LLVM BitCode,或是llvm-java支援的class2llvm要把Java ByteCode轉譯為LLVM BitCode.

LLVM 的跨平台支援演示.

如下筆者以同樣是ARM平台來看,對同一個 BitCode Assembly,選擇要對Cortex-A9優化與要對ARM9優化選項後,所產生的組語有哪些差異

[root@localhost reference_code]#

[root@localhost reference_code]# arm-none-linux-gnueabi-gcc -mcpu=arm9 sample_ar

m9.s -ldl -o sample_arm9

//把BitCode Assembly 針對ARM 架構下的Cortex-A9處理器進行優化,並產生檔案到sample_cortexa9.s

#llc -O2 -march=arm -mcpu=cortex-a9 sample.bc -o sample_cortexa9.s

//把BitCode Assembly 針對ARM 架構下的ARM9處理器進行優化,並產生檔案到sample_arm9.s

# llc -O2 -march=arm -mcpu=arm9 sample.bc -o sample_arm9.s

//可再透過 Diff 比較針對Cortex-A9與ARM9優化後,兩者的差異 (各位可以自行嘗試,筆者就不再此列舉內容).

# diff sample_corei7.s sample_atom.s

兩者最直接的差異就是在所產生的組語中,Cortex-A9會加入對 ‘.fpu neon’ 指令集的支援,而這是在不支援Neon指令集的ARM9處理器上所不會有的.

最後不免要把兩段BitCode實際編譯驗證,

# arm-none-linux-gnueabi-gcc -mcpu=cortex-a9 sample_cortexa9.s -ldl -o sample_cortexa9

# arm-none-linux-gnueabi-gcc -mcpu=arm9 sample_arm9.s -ldl -o sample_arm9

並且比較基於兩個不同處理器優化下,所產生最終執行檔的Size差異.

# ls -l sample_cortexa9

-rwxr-xr-x. 1 root root 6877 May 13 23:42 sample_cortexa9

# ls -l sample_arm9

-rwxr-xr-x. 1 root root 7201 May 13 23:42 sample_arm9

筆者把一段C Code (由於重點是在演示如何把C Code轉 BitCode,再透過BitCode轉成不同平台的Assembly,所以在此就不偏重C Code的內容了),先轉成BitCode,之後再編譯為跨不同處理器平台的Assembly原始碼與最終的執行檔案,藉此演示LLVM在支援不同平台優化技術上的能力.

//透過clang 把C程式碼編譯為 BitCode 二進位檔案.

[root@localhost reference_code]# clang -O2 -emit-llvm sample.c -c -o sample.bc

[root@localhost reference_code]# ls -l sample.bc

-rw-r–r–. 1 root root 1956 May 12 10:28 sample.bc

//把BitCode二進位檔案轉譯為x86-64 platform assembly code.

[root@localhost reference_code]# llc -O2 -mcpu=x86-64 sample.bc -o sample.s

//編譯轉譯後的assembly code 為 x86-64 native execution file.

[root@localhost reference_code]# gcc sample.s -o sample -ldl

[root@localhost reference_code]# ls -l sample

-rwxr-xr-x. 1 root root 8247 May 12 10:36 sample

//把BitCode二進位檔案轉譯為 ARM Cortext-A9 platform assembly code.

[root@localhost reference_code]# llc -O2 -march=arm -mcpu=cortex-a9 sample.bc -o

sample.s

//編譯轉譯後的 assembly code 為 ARM Cortext-A9 native execution file.

[root@localhost reference_code]# arm-none-linux-gnueabi-gcc -mcpu=cortex-a9 sample.s -ldl -o sample

[root@localhost reference_code]# ls -l sample

-rwxr-xr-x. 1 root root 6877 May 12 10:54 sample

藉由上述的演示,我們可以知道LLVM如何透過LLC(LLVM Compiler)把同一段BitCode轉譯為ARM或x86平台的組語,而所產生的Assembly Code可以再透過GCC編譯為所在平台的執行檔. 有關LLVM的編譯環境運作示意圖,可參考下圖的所示.

透過LLVM前端把程式語言C/C++/Java/Fortran轉譯為BitCode Assembly,再藉由LLVM Compiler轉譯為不同平台差異的Assembly實作.

Clang的靜態分析語句引擎(static analyzer)

Clang不只是LLVM前端的C/C++/Objective C/C++ 編譯器工具,還支援對軟體開發極有幫助的靜態程式碼分析工具,有關LLVM的Clang靜態語句分析(Clang Static Analyzer)工具的介紹可以參考網站http://clang-analyzer.llvm.org/ ,這工具可用以分析C與Objective-C所開發的應用程式(尚不支援 C++/Objective-C++).目前這工具是以Open Source的方式釋出,並成為Clang 計畫的一部分.

其實市場上原本已有一些靜態程式語言分析的商業化工具,像是Coverity 或是 Klocwork,可在開發階段針對所撰寫的C/C++,Java應用程式潛在的設計問題提供分析結果,讓開發者針對這些分析內容先行解決,如此可減少在RunTime QA 人員找出Bug後,還要再提交給研發人員覆現問題的往返時間成本.好的程式語言靜態分析工具可以提前找出可能是在哪一行發生記憶體拷貝的溢位,避免QA週期透過窮舉法去走過所有程式邏輯的路徑,涵蓋範圍的不足.

在Clang基於LLVM環境編譯後,可以在llvm-3.0.src/tools/clang/tools/scan-build與llvm-3.0.src/tools/clang/tools/scan-view 這兩個路徑下取得scan-build與scan-view兩個Clang靜態分析工具編譯後的執行檔, scan-view 可用以檢視scan-build分析後產生到指定目錄中的結果報告.

接下來,筆者以如下的程式碼來驗證scan-build靜態分析程式碼的能力,

int main()

{

char *p,*xp;

char vBuffer[128];

int i;

p=malloc(128);

xp=(char *)malloc(222);

memset(p,256,0);

for(i=0;i<256;i++)

vBuffer[i]=0×00;

return 1;

}

這段程式碼中,筆者把malloc回來的pointer不作NULL檢查就直接使用,並刻意memset超出所配置記憶體的空間,或是透過 for 迴圈故意寫出超過Array配置大小的範圍,如下所示為透過scan-build執行後,產生的錯誤訊息

[root@www LLVM]# ~/scan-build clang -O3 -emit-llvm test.c -c -I/usr/local/bin/../lib/clang/3.0/include/

test.c:9:2: warning: Value stored to ‘xp’ is never read

xp=(char *)malloc(222);

^ ~~~~~~~~~~~~~~~~~~~

1 warning generated.

scan-build: 1 bugs found.

scan-build: Run ‘scan-view /tmp/scan-build-2012-05-20-6′ to examine bug reports.

最後的報告是產生在 /tmp/scan-build-2012-05-20-6 目錄下,可以透過 scan-view工具進行檢視,如下指令.

[root@www LLVM]# ~/scan-view /tmp/scan-build-2012-05-20-7

檢視後的 Bug內容為

File: test.c

Location: line 11, column 2

Description: Value stored to ‘xp’ is never read

以scan-build對這案例的分析結果來看,只有找出 xp 變數有被配置但沒有被使用的問題,其他更嚴重的溢位問題,並沒有被偵測出來. 以目前scan-build的分析能力,對商業化產品的開發,選擇Coverity 或klocwork這類功能比較完整的靜態程式碼分析工具,應該會是對軟體品質確保上有比較好的幫助才是.當然,若在一般性的檢查上,scan-build還是可以帶來一些幫助的.

SSA(Static Single-Assignment)

LLVM IR (Intermediary Representation)會以 SSA (Static Single Assignment) 的形式表述,在往LLVM Assembly進一步的探究前,SSA應該是最值得介紹的項目,也是目前LLVM Assembly在設計實作上的基礎思維. 簡要來說,SSA的技術是由Wegman,Zadeck,Alpern,與Rosen在1988來開始發展,目前已經應用在GCC 4.0,IBM或Sun的Java JIT Compiler. SSA主要的概念為每個變數會被限制只能被給值一次的中間形式(IR),也就是說在轉成IR型態後,原本認為的變數,會在每次內容被改變時,就會重新把結果給值到一個新的變數中,例如變數X在運算過程中內容被改變了5次,就會因此而產生五個與最終給值有關的中間形式靜態單一分配形式.

每個描述式結果都會對應到一個全新的變數 (也就是說假設所在的環境中,全新變數宣告的總數也是沒有上限的.)

原本的描述式

轉成SSA後

x=a + b

y=b + x

x=a + 21

x=c * x

y=x + b

x1 = a + b

y1 = b + x1

x2 = a + 21

x3 = c * x2

y2 = x3 + b

經過SSA 的Dead Code Elimination後,編譯器就可以識別出其實x1與y1是沒有必要存在而可以加以優化消除的,簡化後的結果如下所示

x2 = a + 21

x3 = c * x2

y2 = x3 + b

LLVM 跟Dalvik 執行環境的比較

從目前的趨勢上,LLVM很有機會在Android執行環境扮演一定程度的角色,相對於Dalvik Java 的執行環境,LLVM可以提供更貼近於平台Native應用程式的執行效能. 在跨平台的能力上,Dalvik可以選擇透過 Portable Interpreter (in C), Fast Interpreter (in Assembly)或基於Just-In Time Compiler編譯技術,在支援Neon指令集的平台上,JIT目前也能透過Neon指令產生優化後的結果.

而同樣的優勢,到了LLVM後又更進一步的改變,例如LLVM的IR(Intermediate Representation)是給LLVM直譯器/編譯器看的IR,相對於Java的ByteCode是一個被編譯後的結果,而JIT所做的優化則是根據每個Java ByteCode指令集操作改用原生指令實作所進行的優化(例如:把Dalvik move-wide指令用ARMv7 NEON指令實現,以進行加速),也就是說當從Java Code轉成ByteCode時,實際上有關應用程式流程的優化動作已經被進行過,所產生的ByteCode是適合直接上到Java處理器/虛擬機上執行的結果.

但,在LLVM透過Front-End所產生的結果則是一個還需要經過編譯的中間結果,並且是以SSA (Static Single Assignment) 編譯結果表述的內容,也就是說當BitCode要執行時,還需要透過LLI (LLVM Interpreter)或LLC (LLVM Compiler)來進行直譯或是編譯為目標平台原始碼的過程.

也因此,相較於Java JIT技術的結果,LLVM可以提供更接近於原生應用程式的效能,能根據基於LLVM IR所表述的SSA BitCode結果,重新優化編譯為目標平台的機械碼,相較於Java ByteCode的作法,是基於已經編譯好的ByteCode結果,把每個ByteCode指令改用以平台上的機械碼實現,LLVM能帶來的優化程度與結果是相對較佳的.

簡單來說,兩者最大的差異有

1, 從產生的執行碼來看: BitCode可以被LLVM編譯為原生碼,而且運作過程中直接呼叫Native函式庫,也可以直接被處理器執行.反觀Dalvik ByteCode,必須要基於Dalvik 虛擬機執行,就算是基於Dalvik JIT Compiler的技術,也只有部分的Dalvik ByteCode Trace-Run區塊可以被編譯為原生的機械碼,並不像是LLVM技術所產生的原生碼,是可以100%運作在原生碼執行的環境中.

2,從編譯後的原生碼重用性來看: LLVM可以把BitCode整個優化為原生碼,目前Dalvik ByteCode只支援執行時期階段的ByteCode JIT Compiler,一旦Dalvik應用程式結束,所有JIT編譯後的結果就消失了,必須要等下一次該Dalvik應用程式重新被載入執行,再根據每一個ByteCode Trace-Run區塊的Counter重新去決定哪些區塊要被編譯為Native Code.

3,從執行時期負荷來看 :LLVM Compiler後的結果,能以原生應用程式的方式執行,但Dalvik JIT會跟去Trace-Run Counter結果統計出熱區重新編譯,取得優化後的效能,對處理器的Run-Time負荷來說,LLVM顯然可以帶來更好的改善. 若Dalvik Application把主要的運算都放到JNI .so動態函式庫中,試圖改善Run-Time的效能問題,但卻會因為.so是有平台相依性的,而必須要針對所有的平台都提供一份專屬的.so.

4,從記憶體需求的角度來看:統計編譯後的結果,Clang把C/C++程式碼編譯為 LLVM IR之後透過LLVM Compiler轉譯為目標平台Assembly後所產生的執行檔大小,甚至可以比起直接透過GCC編譯的結果更佳,而Dalvik應用程式,在經過JIT後大小會膨脹 (一般來說為 4-8倍),並且相關的JAR Framework載入後,若也有相關的熱區,也會需要經由JIT技術來加以即時編譯優化,並儲存到JIT Cache中,相較於LLVM技術則無需有這段額外的記憶體成本在.

5,從儲存空間的需求來看: 一般的Dalvik Application APK需要有兩份儲存空間一個是DEX所在的.apk,一個是ODEX 儲存在dalvik-cache中.而LLVM Application並無這樣的必要.

6,從系統安全性的角度來看:LLVM支援指標/Inline Assembly,這是在Java世界中所不允許的,也因為支援指標,甚至是函式指標,可讓LLVM在效能的提升上得到很好的改善,但卻也隱藏了潛在的安全問題.

如下圖所示,為一個Dalvik應用程式在執行時相對於Dalvik 虛擬機與.so動態函式庫的示意圖,我們可以看到 Dalvik應用程式主要還是基於 ByteCode Based的JAR Framework,或是可直接透過JNI介面去呼叫外部的.so動態函式庫,以便得到接近原生碼的執行效能.

接下來,可以參考下圖為透過LLVM Interpreter 執行BitCode應用程式的示意圖,可以看到除了LLVM BitCode應用程式以外,其他外部函式的呼叫都會直接對應到原生的.so動態函式庫.

到這段落,各位以該對於Dalvik/LLVM應用程式在Run-Time上的差異有所了解了,接下來筆者將介紹另一個LLVM延伸的重要應用Native Client(Nacl) 與 Portable Native Client (PnaCl).

Native Client(Nacl) and Portable Native Client (PNaCl)

Google是在約2008開始進行Native Client的開發工作,並在2009年初舉辦Google Native Client Security/Hacking比賽 ,可參考網頁:http://www.zdnet.com/blog/google/hack-googles-native-client-and-get-8192/1295,比賽結果可以在這看到https://developers.google.com/native-client/community/security-contest/,並在Google 瀏覽器Chrome 10之後加入對Native Client的支援.

Native Client是類似微軟早期在Internet Explorer上支援的 ActiveX OCX元件的想法,讓網頁應用程式可以用處理器原生碼在支援這技術的瀏覽器直接執行. 參考Native Client網頁說明,簡單來說目標就是 "seamlessly execute native compiled code inside the browser",也就是可以 "在瀏覽器上無縫執行編譯後的機械碼 ". 目前Native Client編譯後的NaCl Executable (*.NEXE) 檔案格式,會根據目標平台編譯,例如筆者所使用的Windows 7 64bits電腦執行環境,所編譯出的NEXE檔案中的機械碼就會是是用於x86_64環境執行的程式碼,也就是說在開發Native Client時,所產生的NEXE檔案是沒有辦法直接跨到其它平台執行的.

基於Native Client SDK,一個Native Client技術的NEXE執行檔案可以透過如下i686-nacl-gcc 編譯指令編譯出來,如果透過i686-nacl-objdump 去觀察編譯後的結果,可以注意到每個函式的起點都必須是32bytes Alignment的記憶體位址.

i686-nacl-gcc -o hello_loda_x86_32.nexe hello_loda.c -m32 -O0 -g -pthread -O0 -g -Wno-long-long -Wall -lppapi -ldl

參考網頁https://developers.google.com/native-client/overview,Native Client,Native Client支援Software Fault Isolation (SFI),用以檢查所下載機械碼安全性的SandBox大約會讓帶來5%的Overhead.但由於Native Client是以機械碼的方式載入到使用者瀏覽器中執行,因此包括處理器的暫存器與支援inline assembly的寫法,都會比起透過Java Applet+Just-In-Time Compiler 或是透過Flash Action Script在瀏覽器中支援應用程式的方式來的更有安全性的疑慮. 舉個例子來說,這表示如果Native Client的Security SandBox如果沒有防守好的話,就有機會讓一個你在瀏覽網頁過程中所執行的Web Application讀取到你電腦上的檔案資料,或是有機會對將其他的惡意代碼寫入到你的電腦中,讓使用者電腦在不預期的狀況下,被第三方的應用程式給植入.

由於Native Client本身機制是產生出x86 32bits 與 64bits的機械碼,目前也不支援x86以外的平台,因此Google也在2010年時進行新的PNacl (發音為Pinnacle)技術開發,各位可以參考Google的’PNaCl Portable Native Client Executables’文件,如果要讓使用者根據不同平台的差異(X86-32/64 bits,Java,ARM,MIPS,PowerPC….etc)自行編譯出相關的執行檔案進行驗證無誤後發佈產品,這背後會有相當的難度,也因此,Google基於LLVM BitCode的特性開發了PNacl的技術,可參考筆者從文件’PNaCl Portable Native Client Executables’所截出的下圖,PNaCl的想法是開發者產出的是BitCode的檔案格式 (非原本Native Client的X86 32/64 bits ISA指令集),在網頁瀏覽的過程中,由使用者下載包含該BitCode內容的PNaCl檔案格式,透過LLC (LLVM Compiler)技術,動態的在目標平台上把BitCode轉譯為目標平台上的可執行機械碼,隨後成為一個NaCl執行檔案.

基於這樣的設計,等於可以延續Native Client計有的基礎,又可以讓產生機械碼的動作不是在開發者開發階段就要去面對不同平台差異而去產生,開發者所需面對的只有LLVM的BitCode,並且只要基於BitCode的環境驗證無誤下,就可以透過目前LLVM的優勢把BitCode重新編譯為目標平台上的機械碼,如此就可以延續目前Native Client的基礎,但又可以真正的達到跨所有處理器平台的目的.

下圖同樣為Google的’PNaCl Portable Native Client Executables’文件中的截圖,可以看到PNaCl的概念上,是透過LLVM BitCode達成跨平台的目的,在基於NaCl SandBox技術確保Native Client 執行環境的安全性.

Portable Native Client官方網頁為http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client , 基於PNaCl所產生的執行檔為PEXE (原本的Native Client為NEXE),使用LLVM編譯器的好處是,開發者可以用C/C++語言開發,然後基於LLVM可以讓NACL應用程式在Browser上運作時,效率接近直接用C/C++語言針對該平台編譯的結果,而且最重要的是又可以用同一套LLVM產生中間碼(IL)的結果相容於所有的處理器平台.

Native Client定義跟Web Browser (例如目前Google的Chromium) 之間的介面為Pepper,可用以讓Native Client據此實作成為Browser Plug-in. Pepper介面是從Mozilla的NPAPI而來,新版的Native Client Pepper v2介面則重新在NPAPI基礎增加新的API介面.有關Pepper API的說明可以參考網頁http://code.google.com/p/ppapi/wiki/Concepts .

參考目前Native Client的文件,基於安全性的考量Native Client在施行上會有以下的限制存在

1,不支持Hardware Exception.

2, 不支持產生新的Process/Subprocess

3,不支持Raw TCP/UDP Sockets (會額外提供WebSockets 供TCP與UDP Peer-to-Perr Connection.)

4,不支持同步(Synchronous) Blocking I/O

5,不支持對可使用記憶體的查詢

6,可以使用Inline Assembly,但必需要通過Native Client Validator (ncval) 工具的查核

7,跟Native Client所 Plug-in進Browser介面的Pepper API呼叫必須從應用的Main Thread而來.

Google Native Client的相關資訊可以參考

Google Code Project	http://code.google.com/p/nativeclient/
Native Client SDK	https://developers.google.com/native-client/?hl=zh-TW
Download Native Client SDK	https://developers.google.com/native-client/sdk/download?hl=zh-TW
Test Run	https://developers.google.com/native-client/devguide/devcycle/running?hl=zh-TW
Distribute	https://developers.google.com/native-client/devguide/distributing?hl=zh-TW
Getting Start	https://developers.google.com/chrome/web-store/docs/get_started_simple?hl=zh-TW#step4

目前為止我們知道LLVM技術將有機會更廣泛的應用到瀏覽器技術上,與我們生活更緊密的結合,既然知道到LLVM本身的認識是可以把BitCode透過LLI (LLVM Interpreter)以直譯方式執行,或是透過LLC (LLVM Compiler)轉譯為不同平台上的機械碼,相對的把C/C++這些主要開發語言轉譯為BitCode的前端編譯器就變得很重要了,下一段落就讓我們實際操練Clang與LLVM的執行環境.

編譯第一個LLVM程式

接下來讓我們嘗試編譯一個基於BitCode檔案格式的LLVM程式,首先如下範例程式

#include

int main()

{

printf("LLVM Test\n");

return 0;

}

透過clang -S -emit-llvm test.c -o test.llvm 進行編譯,可以產生 LLVM的Assembly Code,如下所示

; ModuleID = ‘test.c’

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128″

target triple = "x86_64-unknown-linux-gnu"

@gCount = global i32 0, align 4

@.str = private unnamed_addr constant [11 x i8] c"LLVM Test\0A\00″, align 1

define i32 @main() nounwind uwtable {

%1 = alloca i32, align 4

%i = alloca i32, align 4

store i32 0, i32* %1

%2 = call i32 (i8*, …)* @printf(i8* getelementptr inbounds ([11 x i8]* @.str, i32 0, i32 0))

ret i32 0

}

declare i32 @printf(i8*, …)

有關LLVM Assembly Code格式的介紹可以參考http://llvm.org/docs/LangRef.html .

可以透過 clang -c -emit-llvm test.c -o test.bc,產生LLVM BitCode格式的檔案,並且可以透過lli執行所產生的 BitCode檔案,如下所示

[root@localhost test]# lli test.bc

LLVM Test

再來可以透過llvm-dis 反組譯 test.bc為test.ll

[root@localhost test]# llvm-dis test.bc

如下為test.ll內容

[root@localhost test]# more test.ll

; ModuleID = ‘test.bc’

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128″

target triple = "x86_64-unknown-linux-gnu"

@gCount = global i32 0, align 4

@.str = private unnamed_addr constant [11 x i8] c"LLVM Test\0A\00″, align 1

define i32 @main() nounwind uwtable {

%1 = alloca i32, align 4

%i = alloca i32, align 4

store i32 0, i32* %1

%2 = call i32 (i8*, …)* @printf(i8* getelementptr inbounds ([11 x i8]* @.str, i32 0, i32 0))

ret i32 0

}

declare i32 @printf(i8*, …)

並可透過llvm-as test.ll 重新把test.ll編譯為test.bc.

[root@localhost test]# llvm-as test.ll

[root@localhost test]# ls -l test.bc

-rw-r–r–. 1 root root 656 Apr 10 22:49 test.bc

[root@localhost test]# date

Tue Apr 10 22:49:22 CST 2012

[root@localhost test]#

接下來讓我們以LLVM 把兩個BitCode檔案進行Link,以驗證LLVM的運作行為

首先 testA.c如下所示

#include

long funcB();

int main()

{

int X=funcB();

printf("X:%xh\n",X);

return 0;

}

而 testB.c如下所示

#include

long funcB()

{

return 0×9999999;

}

先把 testA.c與testB個別編譯為 testA.bc與testB.bc 兩個BitCode檔案格式,再透過llvm-link把這兩個BitCode檔案Link成一個test.bc檔案,再透過lli 執行該BitCode test.bc檔案.

[root@localhost test]# clang -c -emit-llvm testA.c -o testA.bc

[root@localhost test]# clang -c -emit-llvm testB.c -o testB.bc

[root@localhost test]# llvm-link testA.bc testB.bc -o test.bc

[root@localhost test]# lli test.bc

X:9999999h

[root@localhost test]#

如下所示,也可以先把 testB.bc先Archive 成一個libTestB.a 的靜態連結函式庫,並透過llvm-nm檢視該函式數所提供的Symbol,最後再透過llvm-ld把 testA.nc跟靜態函式庫libTestB.a 進行連結成Native執行檔案的動作,最後就可以透過 ./test驗證最終執行結果是否符合預期.

[root@localhost test]# llvm-ar rucs libTestB.a testB.bc

[root@localhost test]# llvm-nm libTestB.a

T funcB

[root@localhost test]# llvm-ld testA.bc -o test -lTestB

[root@localhost test]# date

Tue Apr 10 22:57:42 CST 2012

[root@localhost test]# ls -l test

-rwxr-xr-x. 1 root root 66 Apr 10 22:57 test

[root@localhost test]# ./test

X:9999999h =>符合預期.

[root@localhost test]#

在實際操練LLVM有關的工具指令後,接下來就是介紹LLVM 反組譯與BitCode檔案格式.

LLVM Assembly Language 與 程式碼反組譯

有關LLVM Assembly Language的支援列表筆者另外整理在http://loda.hala01.com/llvm-assembly-language/ ,供參考.

LLVM的Identifiers可以區分為Global全域開頭為’@'的Identifiers(包括函式與全域變數)與Local區域開頭為’%'的Identifiers,如前面的例子,所有的變數會以其命名作為字串但加上@或%表示其為全域變數(例如:@gX)或是區域變數(例如:%Y).參考’ LLVM Language Reference Manual’文件可接受的字元包括 ‘ [%@][a-zA-Z$._][a-zA-Z$._0-9]*’,如果有遇到不在這範圍內的字元,就會透過16進位的方式儲存,同樣以前述的例子來說,函式main的字串會以 ‘ main:%d\0A\00′方式儲存,長度為9bytes,其中\0A代表0x0A的16進位字元,而\00則代表0×00的字串結尾字元.

沒有在程式設計階段被命名的變數,就會以上述像是%11, @22,%33或@44這類數字形式方式來命名.

常數Constants的部份,筆者說明列舉如下所示

常數型態	說明
Boolean	i1(a single-bit integer), 會以’true’ 與 ‘false’ 代表長度為1bit的整數值
Integer	通常為i32 (a 32-bit integer),可以用來表示負值,長度可為i1(1bit), i2(2bits), i3(3bits), … i8 (8bits), … i16 (16bits), … i32 (32bits), … i64 (64bits), …
Floating point	通常為half(16-bit floating point value),float(32-bit floating point value)或double(64-bit floating point value),表示的方式可以為10或16進位浮點數(double 0x432ff973cafa8000),或指數符號（例如1.23456e+2）
Null pointer	為Pointer Type,會以 ‘null’ 字串表示Null Pointer Constant
Structure	結構常數的組成會以{}括號來定義前後範圍,並以逗號’,'分隔前後的組成變數,每個組成變數都會包括它的形態(i32,float,i32,double…etc),例如像是"{ i32 4, float 17.0, i32 @G }",其中’i32* @G ‘表示這個變數儲存的是全域變數 ‘@G’ 的位址,可用於透過存取這個結構時,再藉由這個變數去存取全域變數’@G’.
Array	Array的組成會以[]方括號來定義前後範圍,並以逗號’,'分隔前後的變數值,每個變數都會包括它的形態,例如像是 "[ i32 42, i32 11, i32 74 ]",Array中常數的型態與變數個數,都需要跟原本所宣告的形態一致,例如像是’[11 x i32]‘(Array of 11 32-bit integer values)或’[4 x i8]‘ (Array of 4 8-bit integer values).
Vector	Vector的組成會以<>的小於/大於括號來定義前後範圍, 並以逗號’,'分隔前後的變數值,每個變數都會包括它的形態,例如像是 "< i32 42, i32 11, i32 74, i32 100 >",Vector中常數的型態與變數個數,都需要跟原本所宣告的形態一致
Zero initialization	字串“zeroinitializer’ 可用以進行初始化值為零的任何型態(Type),通常應用在像是大型的Array,可以讓相關的變數初始化為Zero.
Metadata node	A metadata node is a structure-like constant with?metadata type. For example: "metadata !{ i32 0, metadata !"test" }". Unlike other constants that are meant to be interpreted as part of the instruction stream, metadata is a place to attach additional information such as debug info.

而在變數的部分,當在程式設計階段,給定一個全域變數常數值時,這個全域變數所包含的常數內容,就可以在執行時期的任意時間點被參考與使用,可參考如下兩個全域32 bits Integer變數,與一個全域大小為2*32bits Array的宣告,初值的給予.

@X = global i32 17

@Y = global i32 42

@Z = global [2 x i32*] [ i32* @X, i32* @Y ]

在初值的部份,執行可以設定初值為’Undefined Values’,定義為Undefined Values的變數就表示應用程式並不在意該值的初始化內容,指定的方式可以為

i32 undef

store i32 undef, i32 *%1

筆者以如下程式碼作為例子,來進行編譯後的LLVM BitCode檔案格式解析與對反組譯BitCode Assembly的比對.

#include

unsigned long long gW=10;

long gX;

unsigned int gY=30;

short gZ;

unsigned char gC=50;

short FuncBC(int vA)

{

int Y;

Y=((gC+gW+gX)*vA)+40;

Y*=gX+20;

printf("FuncBC:%d\n",Y);

return Y;

}

static unsigned long FuncA(int vA,int vB)

{

int Y;

gX=vA+vB;

gZ=gC+vB;

Y=gC*(gX+gY+gZ)+10;

Y*=gX+30;

gZ=FuncBC(Y);

printf("FuncA:%d\n",gZ);

return Y;

}

int main()

{

int Y=99;

int i;

for(i=0;i<99999;i++)

{

Y++;

}

Y=FuncA(Y,30);

printf("main:%d\n",Y);

return 0;

}

編譯這段範例程式

clang -c -emit-llvm test.c -o test.bc

進行反組譯

llvm-dis test.bc

進行BitCode檔案格式分析.

llvm-bcanalyzer -dump test.bc

首先從反組譯的程式碼來看,5個全域變數轉成BitCode後的內容如下所示

C中的變數宣告	BitCode產生的變數宣告
unsigned long long gW=10;	@gW = global i64 10, align 8
long gX;	@gX = common global i64 0, align 8
unsigned int gY=30;	@gY = global i32 30, align 4
short gZ;	@gZ = common global i16 0, align 2
unsigned char gC=50;	@gC = global i8 50, align 1

可以知道,long長度為 64bits,int長度為32bits,short長度為16bits而char長度為8bits.預設的變數為unsigned,若屬於signed的變數則會加上common.沒有給予初值的全域變數預設值為0.

如下所示,定義為static function的話會加上internal,外部函式會以declare方式宣告原型,內部函式的定義會透過define,每個函式的函式參數會以型別跟參數名稱依序定義在函式參數中.

C中的函式宣告	BitCode產生的函式宣告
使用到外部呼叫printf 函式	declare i32 @printf(i8*, …)
int main()	define i32 @main() nounwind uwtable
static unsigned long FuncA(int vA,int vB)	define internal i64 @FuncA(i32 %vA, i32 %vB) nounwind uwtable
short FuncBC(int vA)	define signext i16 @FuncBC(i32 %vA) nounwind uwtable

而以函式名稱的宣告來看,在這範例中筆者有宣告如下三個函式

short FuncBC(int vA)

static unsigned long FuncA(int vA,int vB)

int main()

在編譯為 BitCode後,會依據這三個函式名稱的長度,例如main為 ‘ main:%d\0A\00′,長度為9. (main:%d 長度為 7 bytes, 加上 0x0A 跟 0×00 各 1byte就為 9 bytes.)

@.str = private unnamed_addr constant [11 x i8] c"FuncBC:%d\0A\00″, align 1

@.str2 = private unnamed_addr constant [10 x i8] c"FuncA:%d\0A\00″, align 1

@.str1 = private unnamed_addr constant [9 x i8] c"main:%d\0A\00″, align 1

提到LLVM Assembly,最值得參閱的文件為’ LLVM Language Reference Manual’,可參考的網頁位置在http://llvm.org/docs/LangRef.html . LLVM Assembly目標在於成為一個 ‘Universal IR’,也就是可以滿足讓各種程式語言對應到的Assembly Code,不管開發者使用的是C/C++,Java,Python …等等,都可以透過LLVM的Front-End前端編譯器(例如 Clang)把這些開發的Source Code轉譯為IR Assembly,以便讓LLVM本身可以把所產生的IR程式碼重新編譯到最後所要執行的處理器平台上(像是 x86,ARM或MIPS..等).

如下所示,可以先從C與編譯後的BitCode反組譯內容來做為這段落的起點

C Code

BitCode反組譯的結果

short FuncBC(int vA)

{

int Y;

Y=((gC+gW+gX)*vA)+40;

Y*=gX+20;

printf("FuncBC:%d\n",Y);

return Y;

}

define signext i16 @FuncBC(i32 %vA) nounwind uwtable {

%1 = alloca i32, align 4

%Y = alloca i32, align 4

store i32 %vA, i32* %1, align 4

%2 = load i8* @gC, align 1

%3 = zext i8 %2 to i64

%4 = load i64* @gW, align 8

%5 = add i64 %3, %4

%6 = load i64* @gX, align 8

%7 = add i64 %5, %6

%8 = load i32* %1, align 4

%9 = sext i32 %8 to i64

%10 = mul i64 %7, %9

%11 = add i64 %10, 40

%12 = trunc i64 %11 to i32

store i32 %12, i32* %Y, align 4

%13 = load i64* @gX, align 8

%14 = add nsw i64 %13, 20

%15 = load i32* %Y, align 4

%16 = sext i32 %15 to i64

%17 = mul nsw i64 %16, %14

%18 = trunc i64 %17 to i32

store i32 %18, i32* %Y, align 4

%19 = load i32* %Y, align 4

%20 = call i32 (i8*, …)* @printf(i8* getelementptr inbounds ([11 x i8]* @.str, i32 0, i32 0), i32 %19)

%21 = load i32* %Y, align 4

%22 = trunc i32 %21 to i16

ret i16 %22

}

基於SSA的概念,我們可以把C語言與BitCode程式碼對應如下所示

C Code	BitCode反組譯的結果
short FuncBC(int vA)	define signext i16 @FuncBC(i32 %vA) nounwind uwtable
int Y;	%1 = alloca i32, align 4 //宣告 int Y %Y = alloca i32, align 4
Y=((gC+gW+gX)*vA)+40	//把 vA儲存到 %1 store i32 %vA, i32* %1, align 4 //把 gC 儲存到 %2,並Extend為i64到%3 %2 = load i8* @gC, align 1 %3 = zext i8 %2 to i64 //把gW儲存到%4,讓%3加%4等於%5 %4 = load i64* @gW, align 8 %5 = add i64 %3, %4 //把gX儲存到 %6 %6 = load i64* @gX, align 8 //讓%6加%5等於%7 %7 = add i64 %5, %6 //讓vA等於%1儲存到%8,並Extend為i64到%9 %8 = load i32* %1, align 4 %9 = sext i32 %8 to i64 //讓%7與%9相乘把結果儲存到%10 %10 = mul i64 %7, %9 //讓%10結果加上40,並儲存到%11 %11 = add i64 %10, 40 //Truncate %11到i32 bits,結果為%12 %12 = trunc i64 %11 to i32 //最後把結果((gC+gW+gX)vA)+40儲存在 Y store i32 %12, i32 %Y, align 4
Y*=gX+20;	//把 gX放到 %13 %13 = load i64* @gX, align 8 //對 %13 加上20 然後儲存到%14 %14 = add nsw i64 %13, 20 //把 Y值儲存到%15 %15 = load i32* %Y, align 4 //Extend %15到i64後儲存到%16 %16 = sext i32 %15 to i64 //把%14跟%16相乘後儲存到%17 %17 = mul nsw i64 %16, %14 //把%17的相乘結果Truncate 後除存在%18 %18 = trunc i64 %17 to i32 //把%18儲存在 Y值 store i32 %18, i32* %Y, align 4
printf("FuncBC:%d\n",Y);	//把Y值儲存在%19 %19 = load i32* %Y, align 4 //呼叫外部函式 printf,並把 %19 當做 %d 的參數 %20 = call i32 (i8, …) @printf(i8* getelementptr inbounds ([11 x i8]* @.str, i32 0, i32 0), i32 %19)
return Y;	//把最後Y值結果Truncate 後除存在%22 %21 = load i32* %Y, align 4 %22 = trunc i32 %21 to i16 //以%22作為最後Y值的返回結果 ret i16 %22

原始資料編碼 (Encoding Primitive)

BitStream的封裝會以最少的Bit數來呈現每個有意義的Byte數值,BitStream會把這些原始資料數值以Unsigned Integer 數值的方式編碼,主要的編碼方式包括固定長度整數 (Fixed Width Integer),可變長度整數 (Variable Width Integer),字元編碼(6-bit characters)或32bits方式編碼(Word Alignment)

固定長度整數 (Fixed Width Integer): 例如假設一個8 bits整數,如果要呈現1這個數字,就會以0b00000001的方式來表示. 通常固定長度整數會用來處理習知的數值,最經典的例子就是Boolean 整數,就不會用 32bits來表示,而會以固定長度整數 1bit來代表一個Boolean.

可變長度整數 (Variable Width Integer):可變長度整數,以VBR4來說,就是會以4bits為一組的方式呈現一個VBR欄位,其中最高Bit為0表示該VBR4的4bits組合尚未到結尾,若VBR4最高Bit為1表示該VBR4的數值已經結束.例如: 6 這數字二進位編碼為 0b0110,若用VBR4編碼為0b1110.或像是以8這數字二進位編碼來說為0b1000,若用VBR4編碼則為0b10010000,以每4Bits的VBR4解碼回來看就是把0b1001 最高bit忽略後 << 3 + 0b0000 也就會等於 0b1000. 以’LLVM Bitcode File Format’文件中的例子來說,0x1B ( =27) 來說,原本的二進位呈現方式為0b00011011,以可變長度整數方式來編碼的話,會以每三個bits一組來呈現,以這個例子來說就是 0b011 跟 0b011, 低位址的0b011 由於後面還有0b011要接續在一起,所以他的最高bit 會為0,表示還有接續的3bits內容,而最後的0b011 的最高bit會為1,表示已經到了結尾. 更直接一點來看就是把0x1B=27=0b00011011分拆成 24 + 3 也就是以 0b10110011 的可變長度整數來呈現,Decode回來的方式就是 0b0011 最高bit為0,表示其後還有數值,目前值為3,而0b1011最高bit為1,表示目前數值已經到結尾,目前值為24 (0b011 << 3),所以 0b10110011解碼後的結果為 0x1B=27.

字元編碼(6-bit characters):6-bit characters encode common characters into a fixed 6-bit field. They represent the following characters with the following 6-bit values:

‘a’ .. ‘z’ — 0 .. 25

‘A’ .. ‘Z’ — 26 .. 51

’0′ .. ’9′ — 52 .. 61

‘.’ — 62

‘_’ — 63

This encoding is only suitable for encoding characters and strings that consist only of the above characters. It is completely incapable of encoding characters not in the set.

32bits方式編碼(Word Alignment):Occasionally, it is useful to emit zero bits until the bitstream is a multiple of 32 bits. This ensures that the bit position in the stream can be represented as a multiple of 32-bit words.

LLVM Bitcode File Format/BitStream Nested Block

有關LLVM Bitcode格式的說明可以參考網頁http://llvm.org/docs/BitCodeFormat.html ,而LLVM也提供一個方便解析LLVM BitCode檔案格式的工具 llvm-bcanalyzer,可用以讓開發者檢視LLVM BitCode檔案格式與對應欄位在編碼後的狀況.

LLVM的BitCode就像是Sun JVM HotSpot或是Google Android Dalvik VM ByteCode的角色一樣,都是提供一個中介的程式編碼IR(Intermediary Representation),再透過可以把這些IR程式碼格式編譯成為優化後的Native機械碼的方式,提供就像是Java JIT一樣可以跨平台但又考慮到不同處理器差異,可藉此提供接近原生程式碼編譯器(例如:GCC)的編譯效能,藉此提供一個高效率的編譯器與編譯後的指令集組合方案.

BitCode總共包含兩個部分,一個是BitStream Container Format,一個是被編碼在Container中的LLVM IR指令集編碼. BitStream Container Format就像是XML的資料結構描述方式,其中包括 Tags與Nested Structures,主要差異在於BitStream Container 為binary方式的編碼儲存,並且支援在這檔案中透過縮寫(Abbreviations)的方式來儲存相關的資料項目名稱,藉此縮小檔案的儲存空間.LLVM IR檔案中會嵌入(embedded ) Wrapper Structure讓LLVM 檔案可以被嵌入額外的資料訊息.

一個標準的BitCode檔案格式,檔案開頭前兩個Bytes會是’ 0×42, 0×43′ (=BC),接下來的兩個Bytes為 Application-Specific Magic Number,以筆者自己所編譯的BitCode檔案來說這兩個值為 ’0xC0,0xDE’,一般的BitCode識別只需要判斷前面兩個Bytes,對特定的應用程式識別來說,則需要判斷完整的四個Bytes.

透過工具llvm-bcanalyzer Dump BitCode檔案時,如果該區塊內容為空,會看到如下的區塊名稱宣告與結尾

若該區塊中有包括相關描述內容,則可看到如下的區塊名稱宣告與結尾

….

每個區塊的描述都會以 <…> 的括號來區隔,並且對該區塊而言,會以 ‘/’ 作為一個區塊的結束,BitStream中的Block可以包括Nested 巢狀的內容結構,每一個Block都會包括一個依據內容屬性而訂定的特定ID.如下為以 Nested方式呈現的LLVM Block資料內容

=>最一層的Block,其中包括其它第一層以後的內容

=>第二層的Block,直接以 ‘/’ 收尾

=>第二層的Block,其中包括其它第二層以後的內容

=>第三層的Block,直接以 ‘/’ 收尾

=>第二層的Block,直接以 ‘/’ 收尾

由於這些Block的定義在未來是可以根據需求擴充的,也因此在BitCode Format中會把Block 0定義為 Block Information區塊 (BLOCKINFO),用以儲存描述目前BitCode檔案中其他Block相關背景資訊的MetaData.

BitCode檔案格式內的MODULE_BLOCK區塊,是LLVM BitCode檔案格式Nested Block區塊巢狀架構最外層的Block, 檢視BitCoe Block架構與內容最好的方式就是透過指令 ‘ llvm-bcanalyzer -dump ‘,就可以把BitCode檔案格式所包含的Block資訊秀出,如下例子

[root@localhost test]# llvm-bcanalyzer -dump test.bc

如下圖所示,為LLVM BitCode檔案格式中不同區塊描述時,Nested Block的示意圖,我們可以看到最外層為MODULE_BLOCK,其下依序包括FUNCTION_BLOCK,METADATA_BLOCK…etc,在Block之中還可以在包括其他的描述Block.

Block ID 0-7預設給BitCode所定義的標準Block區塊.Blokc ID 8 以後為應用程式所特定使用的ID,像是Block ID 12為用以呈現函式實作本體(Function Body)的LLVM IR(Intermediary Representation)內容.

LLVM IR is defined with the following blocks

Block ID	說明
0	BLOCKINFO主要用以儲存描述其它Block區塊資訊的MetaData,根據文件的定義主要包括,SETBID(Code 1,[SETBID (#1), blockid]),用來表示目前描述的資訊是哪個Block ID,在BLOCKINFO中根據所要描述的Block個數,就可以有多筆SETBID宣告. DEFINE_ABBREV([DEFINE_ABBREV, ...])在BLOCKINFO中主要用以表示目前所描述Block Id的縮寫定義.BLOCKNAME (Code 2,[BLOCKNAME, ...name...])是非必要的欄位,用以記錄Block的名稱字串.SETRECORDNAME (Code 3,[SETRECORDNAME, RecordID, ...name...])是非必要欄位,會以第一個參數作為Record ID,其它部分則為這筆Record的名稱字串. 如下為筆者所舉範例的 BLOCKINFO_BLOCK Summary內容, Block ID #0 ( BLOCKINFO_BLOCK): Num Instances: 1 Total Size: 637b/79.62B/19W Percent of file: 11.7096% Num SubBlocks: 0 Num Abbrevs: 0 Num Records: 0
1 — 7	Block IDs 1-7 保留,用以作為未來的擴充之用.
8	MODULE_BLOCK (=FIRST_APPLICATION_BLOCKID ) 這是BitCode檔案格式中最外層的Block,在這Block內會包括整個模組內其它Block的描述內容. 根據目前的定義,MODULE_BLOCK可以包括以下的Sub BLOCK區塊內容. 1,BLOCKINFO 2,PARAMATTR_BLOCK 3,TYPE_BLOCK 4,TYPE_SYMTAB_BLOCK 5,VALUE_SYMTAB_BLOCK 6,CONSTANTS_BLOCK 7,FUNCTION_BLOCK 8,METADATA_BLOCK 如下為筆者所舉範例的 MODULE_BLOCK Summary內容, Block ID #8 (MODULE_BLOCK): Num Instances: 1 Total Size: 2544b/318.00B/79W Percent of file: 46.7647% Num SubBlocks: 7 Num Abbrevs: 1 Num Records: 6 Percent Abbrevs: 0.0000% Record Histogram: Count # Bits % Abv Record Kind 3 225 FUNCTION 1 69 GLOBALVAR 1 1761 DATALAYOUT 1 303 TRIPLE 除了Sub Block外, MODULE_BLOCK主要包括以下資訊內容, [VERSION, version#] : VERSION (Code 1) 用以表示目前所支援的格式版本 [TRIPLE, ...string...]: TRIPLE (Code 2) 用以儲存Target Triple Specification 字串字元.如下為筆者環境的例子 [DATALAYOUT, ...string...]: DATALAYOUT (Code 3)用以儲存 target datalayout Specification 字串字元.如下為筆者環境的例子 [ASM, ...string...]: ASM (Code 4)用以儲存個別的BitCode Assembly區塊,不同的Assembly區塊會以0x0A NewLine來區隔開來. [SECTIONNAME, ...string...]: SECTIONNAME (Code 5)用以儲存不同Section的名稱字串.每一個Section名稱都會對應到一筆 SECTIONNAME資料. 其它包括[DEPLIB, ...string...] (Code 6),[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal] (Code 7),[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc] (Code 8),[ALIAS, alias type, aliasee val#, linkage, visibility] (Code 9),[PURGEVALS, numvals] (Code 10),[GCNAME, ...string...] (Code 11) 都是MODULE_BLOCK中所包括的資訊,筆者在此就不一一說明,有興趣的開發者可以自行參與技術文件.
9	PARAMATTR_BLOCK (Id=9)包含一個用以描述每個Function 參數Parameters屬性的Table.在這表格中的Entry會被FUNCTION區塊的每個Parameters欄位所參考.或是被FUNCTION區塊中的INST_INVOKE與INST_CALL的ATTR欄位所參考. 每筆在PARAMATTR_BLOCK 欄位中的資料,都會是唯一的 PARAMATTR_BLOCK中的資料格式如下 [ENTRY, paramidx0, attr0, paramidx1, attr1...] 筆者舉手中BitCode的 PARAMATTR_BLOCK為例,內容如下所示如下為筆者所舉範例的 PARAMATTR_BLOCK Summary內容, Block ID #9 (PARAMATTR_BLOCK): Num Instances: 1 Total Size: 189b/23.62B/5W Percent of file: 3.4743% Num SubBlocks: 0 Num Abbrevs: 0 Num Records: 1 Percent Abbrevs: 0.0000% Record Histogram: Count # Bits % Abv Record Kind 1 111 ENTRY
10	TYPE_BLOCK (ID=10) 包括了一個在這模組中所使用的Type Table列表,用以表示在這BitCode模組中所參考到的形態.除了NUMENTRY外的資料會產生一個單一型態Type的Entry記錄,包括指令集,常數,MetaData,Type Symbol Table Entry,或其他Type操作單元資料. 每筆在TYPE_BLOCK中的資料都會確保是唯一的. 筆者舉手中BitCode的 TYPE_BLOCK為例,內容如下所示 ……………..
11	CONSTANTS_BLOCK 主要用以儲存在這模組內或所包含的函式所使用到的常數資料, 如下為筆者所舉範例的 CONSTANTS_BLOCK Summary內容, Block ID #11 (CONSTANTS_BLOCK): Num Instances: 2 Total Size: 454b/56.75B/14W Percent of file: 8.3456% Average Size: 227.00/28.38B/7W Tot/Avg SubBlocks: 0/0.000000e+00 Tot/Avg Abbrevs: 4/2.000000e+00 Tot/Avg Records: 7/3.500000e+00 Percent Abbrevs: 71.4286% Record Histogram: Count # Bits % Abv Record Kind 3 24 100.00 SETTYPE 1 52 CE_INBOUNDS_GEP 1 52 100.00 CSTRING 1 12 100.00 INTEGER 1 16 NULL
12	FUNCTION_BLOCK,主要用以描述Function的本體. 如下為筆者所舉範例的 FUNCTION_BLOCK Summary內容, Block ID #12 (FUNCTION_BLOCK): Num Instances: 1 Total Size: 418b/52.25B/13W Percent of file: 7.6838% Num SubBlocks: 2 Num Abbrevs: 0 Num Records: 10 Percent Abbrevs: 30.0000% Record Histogram: Count # Bits % Abv Record Kind 2 92 INST_CALL 2 80 INST_STORE 2 80 INST_ALLOCA 1 15 100.00 INST_LOAD 1 10 100.00 INST_RET 1 18 100.00 INST_CAST 1 22 DECLAREBLOCKS
13	TYPE_SYMTAB_BLOCK,主要用以描述Type Symbol Table.
14	VALUE_SYMTAB_BLOCK,主要用以描述數值的Symbol Table 如下為筆者所舉範例的 VALUE_SYMTAB_BLOCK Summary內容, Block ID #14 (VALUE_SYMTAB): Num Instances: 2 Total Size: 338b/42.25B/10W Percent of file: 6.2132% Average Size: 169.00/21.12B/5W Tot/Avg SubBlocks: 0/0.000000e+00 Tot/Avg Abbrevs: 0/0.000000e+00 Tot/Avg Records: 5/2.500000e+00 Percent Abbrevs: 100.0000% Record Histogram: Count # Bits % Abv Record Kind 5 210 100.00 ENTRY
15	METADATA_BLOCK,主要用以描述MetaData項目. 如下為筆者所舉範例的 METADATA_BLOCK Summary內容, Block ID #15 (METADATA_BLOCK): Num Instances: 1 Total Size: 285b/35.62B/8W Percent of file: 5.2390% Num SubBlocks: 0 Num Abbrevs: 0 Num Records: 3 Percent Abbrevs: 0.0000% Record Histogram: Count # Bits % Abv Record Kind 3 195 METADATA_KIND
16	METADATA_ATTACHMENT,主要用以記錄跟函式指令數值有關的MetaData資料.
17	TYPE_BLOCK_ID 如下為筆者所舉範例的 TYPE_BLOCK_ID Summary內容, Block ID #17 (TYPE_BLOCK_ID): Num Instances: 1 Total Size: 541b/67.62B/16W Percent of file: 9.9449% Num SubBlocks: 0 Num Abbrevs: 6 Num Records: 15 Percent Abbrevs: 66.6667% Record Histogram: Count # Bits % Abv Record Kind 6 48 100.00 POINTER 3 49 100.00 FUNCTION 3 78 INTEGER 1 16 100.00 ARRAY 1 16 VOID 1 22 NUMENTRY

基於Nested Block的架構,可以支援有從屬繼承關係的資料屬性或內容,並且可以在Block結構分析時,可以先在其上的Block Id判斷這是否為應該要處理的資料內容,而節省檔案結構分析所需的時間,例如Block ID 3的Nested Block範圍內還有Block ID 13與8,若Block ID 3是目前檔案分析所不需要參考的內容,就可以直接往其後不在Block ID 3內的Block來做分析處理,對系統運作效率上可以得到改善.

LLVM Calling Convention

Calling Convention是每一個語言在處理函式呼叫時,暫存器要如何配置與返回值要如何處理的重要原則,而一個函式呼叫Caller/Callee雙方要能順利執行,也都必須要支持一致的Calling Convention行為,而LLVM基於一個要達成跨平台高執行效率的角色,自然在Call Convention的技術支援上,也該有值得我們深入關注的部份,目前筆者所理解的LLVM主要支援以下的Calling Convention機制,

1,C Calling Convention(CCC):當函式呼叫沒有指定Calling Convention時,預設就會支援這個C Calling Convention模式.會把函式參數由右而左推到Stack中,而被呼叫端則依序透過Stack把函式參數取出. This calling convention supports varargs function calls and tolerates some mismatch in the declared prototype and implemented declaration of the function (as does normal C).

2,Fast Calling Convention (FastCC):顧名思義,這是一個會盡可能讓呼叫很快速的Calling Convention機制,在函式呼叫過程中所傳遞的函式參數會以處理器暫存器來傳遞,並無需考慮特定的 specified ABI (Application Binary Interface)標準.This calling convention does not support varargs and requires the prototype of all callees to exactly match the prototype of the function definition.

3,Cold Calling Convention: 這是一個讓不是很常被執行的函式,可以在呼叫端有效率的執行呼叫.主要的差異在於在一個函式呼叫的熱區中,有關的參數與數值都會儲存在處理器的暫存器中,如果為了一個非熱區的函式還要把這些暫存器備份到相對速度比較慢的外部記憶體,如此則會對執行效率產生影響.This calling convention does not support varargs and requires the prototype of all callees to exactly match the prototype of the function definition.

4,GHC Convetion (cc10, Glasgow Haskell Compiler): 這是一個由Glasgow Haskell編譯器所支援的Calling Convention.函式參數的傳遞主要透過處理器暫存器進行,並會Disable被呼叫端對處理器暫存器的保存與回復動作,這種呼叫方式主要應用在對執行效能有較高要求的函式呼叫中.如同 Fast Calling Convention一樣, GHC Calling Convention也支持Tail Call的Calling Convention.

在函式呼叫效能的改善上,LLVM也支援Tail Call機制,例如在x86上可讓Caller與Callee在呼叫時共用同樣的Stack Frame,例如FuncA->FuncB->FuncC的呼叫,基於Tail Call機制,可以減少其中透過 call 與重新Push Stack的成本,讓FuncA->FuncB->FuncC可以透過 Jmp與共用 Stack方式,而在FuncC結束時,也可以直接返回到FuncA讓函式呼叫的效率提高,LLVM的Tail Call支援是有平台限制的,且必須Caller與Callee的函式宣告為Fast Calling Convention或是 GHC Convention型態.

結語

法拉第曾說,“ 人心是偏向於錯誤的,人會在自己強烈需要的事情上,欺騙自己.即使尋找印證，也要符合自己的欲望“ ,筆者在整理本文時雖盡可能確保資料的正確性,然若有所遺漏也歡迎各位指正.

LLVM要介紹與說明的細節非常多,在這篇文章中筆者只選擇自己感興趣的LLVM技術加以探究,限於篇幅也難以透過一篇文章就把這麼精采的技術項目說明完畢,對LLVM Dig-in越深,也越加覺得這技術在未來發展上的潛力無窮. 隨著Google在未來把PNaCl應用到瀏覽器中,Apple也會把LLVM技術紮根於Mac OS X上,可預見的未來LLVM技術將會更加普及,LLVM不但支援跨平台,還兼顧到執行效率與所耗資源不高的特性,對於現今手機或消費性電子的軟體執行效能改善,將會有相當的助益.

People who looked at this item also looked at…

晶片業的獵食者AMD：恢復海盜的心態

loda — Sun, 20 May 2012 16:30:33 +0000

晶片業的獵食者AMD：恢復海盜的心態

http://tech.sina.com.cn/it/2012-05-17/15157124345.shtml

福布斯中文網

有人穿著短褲前來，有人穿著T恤前來，人人都帶著問題。去年8月底，超微半導體公司(AMD)在得州奧斯丁園區的全體工作人員在公司禮堂集合。在經歷了挫折連連、痛苦不堪的5年之後，這家晶片製造商的董事會解雇了前任首席執行官，然後花了半年時間尋找接任者。這一天，新任首席執行官羅瑞德(Rory Read)前來向員工們發表演說。對他而言，這絕對是一群難對付的聽眾。
但羅瑞德很快就摸清了聽眾的脾性。儘管得州正是30多度的大熱天，但他仍然西裝革履，髮型一絲不苟，顯得非常精神，看起來就像剛從標著“大公司首席執行官”的盒子裡走出來似的。
AMD公司是從聯想集團(Lenovo)把羅瑞德引誘過來的。聯想集團是AMD公司最大的客戶之一，羅瑞德在那裡工作時就曾觀察到AMD總是搬石頭砸自己的腳，在生產和管理上發生過一系列失誤。AMD曾是英特爾(Intel)最大的競爭對手，當年千方百計想在不斷變化的電腦和移動設備市場站穩腳跟。
據參加過去年那次會議的前AMD員工透露，當時羅瑞德對聽眾們說：“你們艱苦奮鬥才有了今天的成就。AMD人是海盜。我們需要恢復海盜的心態。”
AMD人迫切需要鼓舞人心的領導者，羅瑞德的話正中他們的下懷。當天晚些時候，有人給羅瑞德買了頂海盜帽。一名前AMD員工說：“當時人們就像著了魔似的。”
已經有好長一段時間沒人能這樣形容AMD了。
AMD公司40年的歷史交織著輝煌的技術、錯失的機會、滑稽的行銷噱頭和高風險的法律訴訟。該公司的創始人桑德斯(JerrySanders)是個傳奇人物，曾指導過蘋果公司(Apple)的創始人約伯斯(SteveJobs)。AMD從一家模仿競爭對手的PC晶片製造商轉變成為一家有相當實力的企業，技術出色到能迫使英特爾改變產品設計。
然而最重要的是，AMD公司為了跟上規模更大的競爭對手的步伐而瘋狂努力，結果卻反受其害。不久前，AMD搞砸了一項初步協定——給設備市場最有吸引力的客戶蘋果公司提供處理器。
羅瑞德的工作是確保AMD不會搞砸新的產品線，其中包括替索尼公司(Sony)仍未公佈的新遊戲機秘密研發圖形晶片，讓這個曾經生氣勃勃的公司擺脫數年來的沮喪情緒。
許多投資者已經拋棄了這家公司。過去5年中，AMD股價的跌幅超過了82%，從40.54美元跌到了7.25美元。但是，在將AMD旗下的不斷貶值的晶圓廠作為耗損劃銷掉之後，這家亟待修繕的企業看上去露出了希望的曙光。該公司去年的年收入為66億美元，而現金流就達到5.24億美元。去年11月的裁員中，1400名員工被辭退，此舉可為該公司在2012年省下2億美元。
塞利格曼投資公司(SeligmanInvestments)的投資組合經理佩魯利(SangeethPeruri)購買了AMD流通股的3.56%，他說：“還會跌多少？10%？我認為即使股價漲到20或30美元也不足為奇。”
懷疑論者看到AMD公司正在被三星(微博)電子(Samsung)和高通(微博)公司(Qualcomm)功率強大的智慧手機和平板處理器以及英特爾日益強勁的PC和伺服器處理器左右夾攻。但現年50歲的羅瑞德卻看到該行業正接近“拐點”，這可能會傷害英特爾尖端的處理器設計和先進製造能力的緊密整合。
AMD公司的銷售額僅為英特爾的1/8，企業領導者敢這樣直言不諱，可謂膽大包天。就算桑德斯也從未如此大膽地暗示，英特爾的工廠可能某一天會成為障礙。桑德斯曾說：“好漢就得有晶圓廠。”
但是，在和英特爾在微處理器業務上纏鬥多年，以及後來和英偉達(Nvidia)在圖形晶片業務上多年鏖戰之後，AMD公司如今迎來了一位經歷過PC市場大戰的老將，終於擁有了一個不僅能讓其生存下去、更可能令其茁壯成長的戰略。
故事的最新篇章實際上始自於邁耶(DirkMeyer)，這位元工程師設計的Hammer微處理器曾在21世紀初給AMD公司帶來了極大成功。他在桑德斯的繼任者魯毅智(HectorRuiz)手下奮鬥多年後，終於在2008年7月被任命為首席執行官。新官上任後他很快放了幾把火。
首先，他結束了與英特爾曠日持久的反壟斷糾紛，雙方達成和解，AMD獲得了12.5億美元補償。接著，他將AMD的數位電視業務以1.93億美元的價格賣給了博通公司(Broadcom)。然後，他又將移動圖形業務以6，500萬美元的價格賣給了高通公司。
真正的大動作發生在2009年3月，邁耶剝離了AMD資本密集型的晶片工廠，將11億美元債務轉移到名為全球晶圓(GlobalFoundries)的新公司。阿布達比的兩個投資機構在新的合資企業中持有股份，作為交易的一部分，AMD從這些機構處獲得8.25億美元現金。
可惜邁耶挽救AMD的瘋狂努力，並未留給該公司多少追逐新機遇的時間。桑德斯說：“邁耶在挖土逃出深洞。我認為他明白，如果掉在深洞裡，得停止挖掘——假使AMD分心去從事智慧手機等新的活動，那麼洞會變得更深。”
與此同時，新麻煩出現了。2010年11月，微軟(Microsoft)向包括AMD在內的合作夥伴公佈了一個計畫，提供一個新版本的Windows，該版本相容使用英國設計公司安謀國際科技(ARMholdings)的ARM技術的晶片。英偉達、德州儀器(TexasInstruments)和高通公司等生產基於ARM技術的處理器的企業因此得到了機會，可以將產品從移動設備擴展到基於Windows系統的PC和平板電腦。
AMD努力打造自己的無晶圓廠新模式，同時試圖快速研發出將CPU和GPU合二為一的“融聚”(fusion)處理器。從表面上看這個想法是有前途的。代號為“大草原”(Llano)的筆記型電腦處理器引起了蘋果公司的密切關注，該公司原本計畫在2011年年中升級推出新版超輕型MacBookAir。
但是，據一名AMD前雇員說，該公司未能按時將能運行的“大草原”早期樣品提交給蘋果公司。幾位前AMD員工對於當時AMD究竟研發到何種程度持不同的意見。有人說：“我們當時有了早期樣品。”但“大草原”問題太多。AMD最終搞丟了這筆生意。
AMD前雇員說，該公司為蘋果公司的新版電視機上盒推薦名為“布拉索斯”(Brazos)的低成本、低功耗處理器。蘋果沒上鉤，但其他很多廠商對此感興趣。和“大草原”一樣，該處理器在單矽片上整合了CPU和GPU；不同之處在於，AMD可以使用老工藝成本低廉地快速製造。
“布拉索斯”使基於英特爾晶片的廉價上網本的銷量大幅下跌。如今AMD將其描述為史上賣得最快的平臺。一名前雇員說：“如果當初‘布拉索斯’被扼殺了，AMD早就完了。”
在2011年1月，在英偉達宣佈將為摩托羅拉(Motorola)和LG公司的手機提供基於ARM技術的晶片幾天後，AMD公司董事會聯繫了邁耶，不久後邁耶就離職了。
1月20日，AMD董事長克拉夫林(BruceClaflin)在德克薩斯州沃思堡市(FortWorth，Tex。)的凱悅酒店(HyattHotel)向正在休假的AMD經理們宣佈了這個消息。首席財務官塞弗特(ThomasSeifert)擔任臨時首席執行官，但30天內不得作任何決策。有些人在會上哭了。塞弗特說：“邁耶走了，我很難過。我感到其他人也很難過。”
邁耶下臺後第31天，AMD開始檢討公司的戰略。討論結果是決定不製造智慧手機晶片，因為那耗費的時間和金錢超過公司的能力。AMD的董事會最終決定求助於羅瑞德——這位曾在IBM(微博)公司工作過23年的資深人士在2006年6月被任命為聯想集團總裁，自那時之後，聯想集團在全球PC市場的份額，從2009年初的6.6%提高到了2011年第2季度的12.1%。
對曾與羅瑞德共事的人來說，他最出名的是能嫺熟地與數位打交道，以及用逗樂的天賦激勵同事。他在IBM公司時曾組織在晚上乘碰碰車打籃球，以此犒勞團隊，在開車搶球的過程中他開懷大笑。
在聯想集團時，為了讓說不同語言的全球員工明白自己的商業策略，他像拳擊手一樣舉起雙拳，以此闡明集團的戰略：一隻拳頭攻擊新市場，另一隻保護現有業務。前聯想集團首席執行官阿梅裡奧(WilliamAmelio)說：“他能用令人信服的方式闡述明天會比今天更好，成功就像擺在我們面前的一條上坡道。”
AMD在PC和伺服器市場與英特爾對抗期間，曾錯過一些機會，羅瑞德正在重新尋找這些機會。去年10月，他聘請了新的首席技術官——曾在蘋果公司和IBM公司工作的業界老將佩珀馬斯特(MarkPapermaster)。佩珀馬斯特採取的第一項措施，是讓AMD在設計CPU和GPU時，某些元件可以更容易地改用其他公司設計的技術。佩珀馬斯稱之為“左右逢迎的計算”。
這個信號明確地顯示，AMD正在探索將x86處理器內核改為ARM等技術的想法。這也開闢了製造更多“嵌入式”處理器的機會，譬如用於汽車和醫療設備的晶片，在這些領域裡，AMD可以調整自己的產品線，出擊英特爾不屑一顧的利基市場。
羅瑞德將AMD的遊戲機晶片專案作為榜樣。微軟在Xbox遊戲機內使用了AMD的圖形技術。另一個與索尼公司合作的尚未公佈的專案也正在進行中，可能會取代曾為PS3遊戲機提供晶片的英偉達。索尼公司拒絕對此發表評論。
最激進的變革可能是：羅瑞德說，AMD可以為客戶定制元件，從而鎖定供應商。前AMD雇員說，以往AMD與英特爾競爭，為整個PC行業提供晶片時，可不願採用定制的做法。
然而，短期內重要的是羅瑞德別把事情搞砸。原先雄心勃勃地列入2012年計畫的10核和20核伺服器晶片已被取消，取而代之的是將在今年晚些時候推出的低功耗處理器“本州”(Hondo)。AMD得讓自己能更容易地兌現諾言。
如果說這是個縮水的戰略，那麼它是AMD有足夠資源實現的，畢竟一系列新湧現出來的對手在威脅著AMD和英特爾。三星電子和安謀國際科技已經在奧斯丁建立了設計中心並挖角AMD員工，為進軍由英特爾統治的伺服器處理器市場做準備。
羅瑞德尚未將注意力從英特爾身上移開。羅瑞德說，當年IBM公司憑藉對大型機業務的壟斷所獲得的利潤，使其可以進行其他公司無力進行的投資；同樣，英特爾對PC處理器市場的控制，能讓該公司支付得起其他公司無法負擔的工廠。
羅瑞德說：“利潤曾經可以負擔得起整個成本結構？但那一切已成為過去。我們不能基於一個可能會改變的商業模式，被牽著鼻子繞著一項資產基礎走。”
未來幾年處理器市場的走勢並不明朗。羅瑞德說：“我們必須向前看，得成為獵食者。我們得掃視大草原，尋找機會。”有蘋果公司、三星電子、高通公司、英偉達和德州儀器在市場上，AMD決不能只把眼睛盯在英特爾身上。

People who looked at this item also looked at…

[笑話] 給程式設計師的笑話

loda — Sun, 20 May 2012 16:30:18 +0000

http://disp.cc/b/115-3xkZ

—1
"想要成為程式設計師，應該從哪一種語言開始學起好呢？"

"英語。"

—2
"爸爸，為什麼大象的鼻子這麼長呢？"

"那是規格啊。"

—3
一天有二十四小時，但是所謂的"今天之內"，指的是到明天早上上班為止。

—4
寫一個程式有兩種方式：

第一種是把程式碼寫的很簡單、很明顯不容易有缺陷。

第二種是把程式碼寫得很複雜，讓人看不出有明顯的缺陷。

—5
對客戶來說只有兩種東西不用錢：白開水、還有追加規格。

—6
世界上可以分成10種人，懂二進位的人，以及不懂二進位的人。

—7
對著一個程式大發脾氣："是誰寫了這麼奇怪的程式碼！"

旁人："那是你去年寫的喔。"

—8
"你好，我是全型空白，我現在在你的程式碼裡面。"
"你好，我是\，我現在在你程式碼的註解裡面。"
"你好，我是－，我也不曉得為什麼我會在這個參數前面"
"你好，我是=，我現在在你程式碼的if判斷式裡面。"(推文哽 XD)

—9
老婆："下班後買十個包子回來，如果看到賣西瓜的就買一個。"
老公："好。" (下班後帶著一個包子回家)
老婆："為什麼只有一個包子？"
老公："因為我看到賣西瓜的。"

—10
女孩："我警告你，你再不停手我就要叫警察了喔。"
程式設計師："警告不重要啦，不是錯誤就好。"

—11
"為什麼程式設計師常常不會分萬聖節跟聖誕節？"
"喔，因為OCT 31 = DEC 25啊。"

—12
程式異常在期限還有一個月的時候稱做Bug，在期限還剩三天的時候則稱為規格限制

—13
不懂電腦的操作者發現Bug的頻率經常比QA工程師還高，

缺點是他們通常沒有辦法重現這個Bug。

People who looked at this item also looked at…

Oracle v. Google – What’s the Deal With the Java Specification License?

loda — Sun, 13 May 2012 04:45:56 +0000

http://www.groklaw.net/article.php?story=2012041812230622

The opening statements having been made, and it is worth a look at some of the slides presented by each of the parties regarding the use of the Java API specification (i.e., the narrative telling you what needs to be in an API implementation) and the claims of each party. There is a clear disconnect between what Oracle claims and the practices that Sun and now Oracle follow when it comes to the Java API specifications, and it shows up graphically when one looks at the following slides and then looks at the actual Java API specification license. Let’s start by looking at the Oracle slides.
On Oracle slide 33 Oracle asserts that one must have a license to "provide class libraries based on Java API designs." Of course, this is already a bit ambiguous because they don’t say what kind of license you actually need, just that you need to have some form of license. You will also note that they love to now use the term "designs" instead of "specifications." That clearly is intended to boost their asserting that there is creative expression protected by copyright in those specifications.

People who looked at this item also looked at…

HP大中華區總裁 / 孫振耀退休感言

loda — Sun, 13 May 2012 04:45:11 +0000

HP大中華區總裁 / 孫振耀退休感言

http://blog.klgsh.kl.edu.tw/lifetype12/post/5/1057

HP大中華區總裁 / 孫振耀退休感言
如果有機會看見了這篇文章，而沒有認真讀完它，那麼絕對會是你的一筆很大的損失！關於人生的思考的文章我看過不少，但像這篇文章那樣能真真切切的說出自己的肺腑之言的確實不多。我想最有價值的交流不在於談話的內容本身，而在於交流者對於內容的思考。內容是不變的，而思想卻會閃光！我們最難遇見的也就是這種閃光的東西……

一、關於工作與生活
　　
　　我有個有趣的觀察，外企公司多的是25-35歲的白領，40歲以上的員工很少，二三十歲的外企員工是意氣風發的，但外企公司40歲附近的經理人是很尷尬的。我見過的40歲附近的外企經理人大多在一直跳槽，最後大多跳到民企，比方說，唐駿。外企員工的成功很大程度上是公司的成功，並非個人的成功，西門子的確比國美大，但並不代表西門子中國經理比國美的老闆強，甚至可以說差得很遠。而進外企的人往往並不能很早理解這一點，把自己的成功90％歸功於自己的能力，實際上，外企公司隨便換個中國區總經理並不會給業績帶來什麼了不起的影響。好了問題來了，當這些經理人40多歲了，他們的薪資要求變得很高，而他們的才能其實又不是那麼出眾，作為外企公司的老闆，你會怎麼選擇？有的是只要不高薪水的，要出位的精明強幹精力沖沛的年輕人，有的是，為什麼還要用你？
　　
　　從上面這個例子，其實可以看到我們的工作軌跡，二三十歲的時候，生活的壓力還比較小，身體還比較好，上面的父母身體還好，下面又沒有孩子，不用還房貸，也沒有孩子要上大學，當個外企小白領還是很光鮮的，掙得不多也夠花了。但是人終歸要結婚生子，終歸會老，到了40歲，父母老了，要看病要吃藥，要有人看護，自己要還房貸，要過基本體面的生活，要養小孩……那個時候需要掙多少錢才夠花才重要。所以，看待工作，眼光要放遠一點，一時的誰高誰低並不能說明什麼。
　　
　　從這個角度上來說，我不太贊成過於關注第一份工作的薪水，更沒有必要攀比第一份工作的薪水，這在剛剛出校園的學生中間是很常見的。正常人大概要工作 35年，這好比是一場馬拉松比賽，和真正的馬拉松比賽不同的是，這次比賽沒有職業選手，每個人都只有一次機會。要知到，有很多人甚至堅持不到終點，大多數人最後是走到終點的，只有少數人是跑過終點的，因此在剛開始的時候，去搶領先的位置並沒有太大的意義。剛進社會的時候如果進500強公司，大概能拿到3k -6k/月的工資，有些特別技術的人才可能可以到8k/月，可問題是，5年以後拿多少？估計5k-10k了不起了。起點雖然高，但增幅有限，而且，後面的年輕人追趕的壓力越來越大。
　　
　　我前兩天問我的一個銷售，你會的這些東西一個新人2年就都學會了，但新人所要求的薪水卻只是你的一半，到時候，你怎麼辦？
　　職業生涯就像一場體育比賽，有初賽、復賽、決賽。初賽的時候大家都剛剛進社會，大多數都是實力一般的人，這時候努力一點認真一點很快就能讓人脫穎而出，於是有的人二十多歲做了經理，有的人遲些也終於贏得了初賽，三十多歲成了經理。然後是復賽，能參加復賽的都是贏得初賽的，每個人都有些能耐，在聰明才智上都不成問題，這個時候再想要勝出就不那麼容易了，單靠一點點努力和認真還不夠，要有很強的堅忍精神，要懂得靠團隊的力量，要懂得收服人心，要有長遠的眼光……
　　看上去贏得復賽並不容易，但，還不是那麼難。因為這個世界的規律就是給人一點成功的同時、讓人驕傲自滿，剛剛贏得初賽的人往往不知道自己贏得的僅僅是初賽，有了一點小小的成績大多數人都會驕傲自滿起來，認為自己已經懂得了全部，不需要再努力再學習了，他們會認為之所以不能再進一步已經不是自己的原因了。雖然他們仍然不好對付，但是他們沒有耐性，沒有容人的度量，更沒有清晰長遠的目光。就像一隻憤怒的鬥牛，雖然猛烈，最終是會敗的，而贏得復賽的人則象鬥牛士一樣，不急不躁，跟隨著自己的節拍，慢慢耗盡對手的耐心和體力。贏得了復賽以後，大約已經是一位很了不起的職業經理人了，當上了中小公司的總經理，大公司的副總經理，主管著每年幾千萬乃至幾億的生意。
　　
　　最終的決賽來了，說實話我自己都還沒有贏得決賽，因此對於決賽的決勝因素也只能憑自己的猜測而已，這個時候的輸贏或許就像武俠小說�寫得那樣，大家都是高手，只能等待對方犯錯了，要想輕易擊敗對手是不可能的，除了使上渾身解數，還需要一點運氣和時間。世界的規律依然發揮著作用，贏得復賽的人已經不只是驕傲自滿了，他們往往剛愎自用，聽不進去別人的話，有些人的脾氣變得暴躁，心情變得浮躁，身體變得糟糕，他們最大的敵人就是他們自己，在決賽中要做的只是不被自己擊敗，等著別人被自己擊敗。這和體育比賽是一樣的，最後高手之間的比賽，就看誰失誤少誰就贏得了決賽。

二、根源
　　你工作快樂麼？你的工作好麼？
　　有沒有覺得幹了一段時間以後工作很不開心？有沒有覺得自己入錯了行？有沒有覺得自己沒有得到應有的待遇？有沒有覺得工作像一團亂麻每天上班都是一種痛苦？有沒有很想換個工作？有沒有覺得其實現在的公司並沒有當初想像得那麼好？有沒有覺得這份工作是當初因為生存壓力而找的，實在不適合自己？你從工作中得到你想要得到的了麼？你每天開心麼？
　　天涯上憤怒的人很多，你有沒有想過，你為什麼不快樂？你為什麼憤怒？
　　其實，你不快樂的根源，是因為你不知道要什麼！你不知道要什麼，所以你不知道去追求什麼，你不知道追求什麼，所以你什麼也得不到。
　　我總覺得，職業生涯首先要關注的是自己，自己想要什麼？大多數人大概沒想過這個問題，唯一的想法只是——我想要一份工作，我想要一份不錯的薪水，我知道所有人對於薪水的渴望，可是，你想每隔幾年重來一次找工作的過程麼？你想每年都在這種對於工作和薪水的焦急不安中度過麼？不想的話，就好好想清楚。飲鴆止渴，不能因為口渴就拼命喝毒藥。越是焦急，越是覺得自己需要一份工作，越饑不擇食，越想不清楚，越容易失敗，你的經歷越來越差，下一份工作的人看著你的簡歷就皺眉頭。於是你越喝越渴，越渴越喝，陷入惡性循環。最終只能哀歎世事不公或者生不逢時，只能到天涯上來發洩一把，在失敗者的共鳴當中尋求一點心理平衡罷了。大多數人都有生存壓力，我也是，有生存壓力就會有很多焦慮，積極的人會從焦慮中得到動力，而消極的人則會因為焦慮而迷失方向。所有人都必須在壓力下做出選擇，這就是世道，你喜歡也罷不喜歡也罷。
　　
　　一般我們處理的事情分為重要的事情和緊急的事情，如果不做重要的事情就會常常去做緊急的事情。比如鍛煉身體保持健康是重要的事情，而看病則是緊急的事情。如果不鍛煉身體保持健康，就會常常為了病痛煩惱。又比如防火是重要的事情，而救火是緊急的事情，如果不注意防火，就要常常救火。找工作也是如此，想好自己究竟要什麼是重要的事情，找工作是緊急的事情，如果不想好，就會常常要找工作。往往緊急的事情給人的壓力比較大，迫使人們去趕緊做，相對來說重要的事情反而沒有那麼大的壓力，大多數人做事情都是以壓力為導向的，壓力之下，總覺得非要先做緊急的事情，結果就是永遠到處救火，永遠沒有停歇的時候。（很多人的工作也像是救火隊一樣忙碌痛苦，也是因為工作中沒有做好重要的事情。）那些說自己活在水深火熱為了生存顧不上那麼多的朋友，今天找工作困難是當初你們沒有做重要的事情，是結果不是原因。如果今天你們還是因為急於要找一份工作而不去思考，那麼或許將來要繼續承受痛苦找工作的結果。
　　我始終覺得我要說的話題，沉重了點，需要很多思考，遠比唐笑打武警的話題來的枯燥乏味，但是，天下沒有輕鬆的成功，成功，要付代價。請先忘記一切的生存壓力，想想這輩子你最想要的是什麼？所以，最要緊的事情，先想好自己想要什麼。

三、什麼是好工作
　　當初微軟有個唐駿，很多大學�的年輕人覺得這才是他們嚮往的職業生涯，我在清華bbs�發的帖子被這些學子們所不屑，那個時候學生們只想出國或者去外企，不過如今看來，我還是對的，唐駿去了盛大，陳天橋創立的盛大，一家民營公司。一個高學歷的海歸在500強的公司�拿高薪水，這大約是很多年輕人的夢想，問題是，每年畢業的大學生都在做這個夢，好的職位卻只有500個。
　　人都是要面子的，也是喜歡攀比的，即使在工作上也喜歡攀比，不管那是不是自己想要的。大家認為外企公司很好，可是好在哪里呢？好吧，他們在比較好的寫字樓，這是你想要的麼？他們出差住比較好的酒店，這是你想要的麼？別人會羡慕一份外企公司的工作，這是你想要的麼？那一切都是給別人看的，你幹嗎要活得那麼辛苦給別人看？另一方面，他們薪水福利一般，並沒有特別了不起，他們的晉升機會比較少，很難做到很高階的主管，他們雖然厭惡常常加班，卻不敢不加班，因為“你不幹有得是人幹”，大部分情況下會找個臺灣人香港人新加坡人來管你，而這些人又往往有些莫名其妙的優越感。你想清楚了麼？500強一定好麼？找工作究竟是考慮你想要什麼，還是考慮別人想看什麼？
　　我的大學同學們大多數都到美國了，甚至畢業這麼多年了，還有人最近到國外去了。出國真的有那麼好麼？我的大學同學們，大多數還是在博士、博士後、訪問學者地掙扎著，至今只有一個正經在一個美國大學�拿到個正式的教職。國內的教授很難當麼？我有幾個表親也去了國外了，他們的父母獨自在國內，沒有人照顧，有好幾次人在家�昏倒都沒人知道，出國，真的這麼光彩麼？就像有人說的“很多事情就像看A片，看的人覺得很爽，做的人未必。”
　　人總想找到那個最好的，可是，什麼是最好的？你覺得是最好的那個，是因為你的確瞭解，還是因為別人說他是最好的？即使他對於別人是最好的，對於你也一定是最好的麼？
　　對於自己想要什麼，自己要最清楚，別人的意見並不是那麼重要。很多人總是常常被別人的意見所影響，親戚的意見，朋友的意見，同事的意見……問題是，你究竟是要過誰的一生？人的一生不是父母一生的續集，也不是兒女一生的前傳，更不是朋友一生的外篇，只有你自己對自己的一生負責，別人無法也負不起這個責任。自己做的決定，至少到最後，自己沒什麼可後悔。對於大多數正常智力的人來說，所做的決定沒有大的對錯，無論怎麼樣的選擇，都是可以嘗試的。比如你沒有考自己上的那個學校，沒有入現在這個行業，這輩子就過不下去了？就會很失敗？不見得。
　　我想，好工作，應該是適合你的工作，具體點說，應該是能給你帶來你想要的東西的工作，你或許應該以此來衡量你的工作究竟好不好，而不是拿公司的大小，規模，外企還是國企，是不是有名，是不是上市公司來衡量。小公司，未必不是好公司，賺錢多的工作，也未必是好工作。你還是要先弄清楚你想要什麼，如果你不清楚你想要什麼，你就永遠也不會找到好工作，因為你永遠只看到你得不到的東西，你得到的，都是你不想要的。
　　可能，最好的，已經在你的身邊，只是，你還沒有學會珍惜。人們總是盯著得不到的東西，而忽視了那些已經得到的東西。

四、普通人
　　我發現中國人的勵志和國外的勵志存在非常大的不同，中國的勵志比較鼓勵人立下大志願，臥薪嚐膽，有朝一日成富成貴。而國外的勵志比較鼓勵人勇敢面對現實生活，面對普通人的困境，雖然結果也是成富成貴，但起點不一樣，相對來說，我覺得後者在操作上更現實，而前者則需要用999個失敗者來堆砌一個成功者的故事。
　　我們都是普通人，普通人的意思就是，概率這件事是很準的。因此，我們不會買彩票中500萬，我們不會成為比爾蓋茨或者李嘉誠，我們不會坐飛機掉下來，我們當中很少的人會創業成功，我們之中有30％的人會離婚，我們之中大部分人會活過65歲……
　　所以請你在想自己要什麼的時候，要得“現實”一點，你說我想要做李嘉誠，抱歉，我幫不上你。成為比爾蓋茨或者李嘉誠這種人，是靠命的，看我寫的這篇文章絕對不會讓你成為他們，即使你成為了他們，也絕對不是我這篇文章的功勞。“王侯將相甯有種乎”但真正當皇帝的只有一個人，王侯將相，人也不多。目標定得高些對於喜歡挑戰的人來說有好處，但對於大多數普通人來說，反而比較容易灰心沮喪，很容易就放棄了。
　　回過頭來說，李嘉誠比你有錢大致50萬倍，他比你更快樂麼？或許。有沒有比你快樂50萬倍，一定沒有。他比你最多也就快樂一兩倍，甚至有可能還不如你快樂。尋找自己想要的東西不是和別人比賽，比誰要得更多更高，比誰的目標更遠大。雖然成為李嘉誠這個目標很宏大，但你並不見得會從這個目標以及追求目標的過程當中獲得快樂，而且基本上你也做不到。你必須聽聽你內心的聲音，尋找真正能夠使你獲得快樂的東西，那才是你想要的東西。
　　你想要的東西，或者我們把它稱之為目標，目標其實並沒有高低之分，你不需要因為自己的目標沒有別人遠大而不好意思，達到自己的目標其實就是成功，成功有大有小，快樂卻是一樣的。我們追逐成功，其實追逐的是成功帶來的快樂，而非成功本身。職業生涯的道路上，我們常常會被攀比的心態蒙住眼睛，忘記了追求的究竟是什麼，忘記了是什麼能使我們更快樂。
　　社會上一夜暴富的新聞很多，這些消息，總會在我們的心�面掀起很多漣漪，漣漪多了就變成驚濤駭浪，心�的驚濤駭浪除了打翻承載你目標的小船，並不會使得你也一夜暴富。“只見賊吃肉，不見賊挨揍。”我們這些普通人既沒有當賊的勇氣，又缺乏當賊的狠辣絕決，雖然羡慕吃肉，卻更害怕挨揍，偶爾看到幾個沒挨揍的賊就按奈不住，或者心思活動，或者大感不公，真要叫去做賊，卻也不敢。
　　我還是過普通人的日子，要普通人的快樂，至少，晚上睡得著覺。

五、跳槽與積累
　　首先要說明，工作是一件需要理智的事情，所以不要在工作上耍個性，天涯上或許會有人覺得你很有個性而叫好，煤氣公司電話公司不會因為覺得你很有個性而免了你的帳單。當你很帥地炒掉了你的老闆，當你很酷地挖苦了一番招聘的HR，帳單還是要照付，只是你賺錢的時間更少了，除了你自己，沒人受損失。
　　我並不反對跳槽，但跳槽決不是解決問題的辦法，而且頻繁跳槽的後果是讓人覺得沒有忠誠度可言，而且不能安心工作。現在很多人從網上找工作，很多找工作的網站常常給人出些餿主意，要知道他們是盈利性企業，當然要從自身盈利的角度來考慮，大家越是頻繁跳槽頻繁找工作他們越是生意興隆，所以鼓動人們跳槽是他們的工作。所以他們會常常告訴你，你拿的薪水少了，你享受的福利待遇差了，又是“薪情快報”又是“讚歎自由奔放的靈魂”。至於是否會因此讓你不能安心，你跳了槽是否解決問題，是否更加開心，那個，他們管不著。
　　要跳槽肯定是有問題，一般來說問題發生了，躲是躲不開的，很多人跳槽是因為這樣或者那樣的不開心，如果這種不開心，在現在這個公司不能解決，那麼在下一個公司多半也解決不掉。你必須相信，90%的情況下，你所在的公司並沒有那麼爛，你認為不錯的公司也沒有那麼好。就像圍城�說的，“城�的人拼命想衝出來，而城外的人拼命想衝進去。”每個公司都有每個公司的問題，沒有問題的公司是不存在的。換個環境你都不知道會碰到什麼問題，與其如此，不如就在當下把問題解決掉。很多問題當你真的想要去解決的時候，或許並沒有那麼難。有的時候你覺得問題無法解決，事實上，那只是“你覺得”。
　　人生的曲線應該是曲折向上的，偶爾會遇到低谷但大趨勢總歸是曲折向上的，而不是象脈衝波一樣每每回到起點，我見過不少面試者，30多歲了，四五份工作經歷，每次多則3年，少則1年，30多歲的時候回到起點從一個初級職位開始幹起，拿基本初級的薪水，和20多歲的年輕人一起競爭，不覺得有點辛苦麼？這種日子好過麼？
　　我非常不贊成在一個行業超過3年以後換行業，基本上，35歲以前我們的生存資本靠打拼，35歲以生存的資本靠的就是積累，這種積累包括人際關係，經驗，人脈，口碑……如果常常更換行業，代表幾年的積累付之東流，一切從頭開始，如果換了兩次行業，35歲的時候大概只有5年以下的積累，而一個沒有換過行業的人至少有了10年的積累，誰會佔優勢？工作到2-3年的時候，很多人覺得工作不順利，好像到了一個瓶頸，心情煩悶，就想辭職，乃至換一個行業，覺得這樣所有一切煩惱都可以拋開，會好很多。其實這樣做只是讓你從頭開始，到了時候還是會發生和原來行業一樣的困難，熬過去就向上跨了一大步，要知道每個人都會經歷這個過程，每個人的職業生涯中都會碰到幾個瓶頸，你熬過去了而別人沒有熬過去你就領先了。跑長跑的人會知道，開始的時候很輕鬆，但是很快會有第一次的難受，但過了這一段又能跑很長一段，接下來會碰到第二次的難受，堅持過了以後又能跑一段，如此往復，難受一次比一次厲害，直到堅持不下去了。大多數人第一次就堅持不了了，一些人能堅持到第二次，第三次雖然大家都堅持不住了，可是跑到這�的人也沒幾個了，這點資本足夠你安穩活這一輩子了。
　　一份工作到兩三年的時候，大部分人都會變成熟手，這個時候往往會陷入不斷的重複，有很多人會覺得厭倦，有些人會覺得自己已經搞懂了一切，從而懶得去尋求進步了。很多時候的跳槽是因為覺得失去興趣了，覺得自己已經完成比賽了。其實這個時候比賽才剛剛開始，工作兩三年的人，無論是客戶關係，人脈，手下，和領導的關係，在業內的名氣……還都是遠遠不夠的，但稍有成績的人總是會自我感覺良好的，每個人都覺得自己跟客戶關係鐵得要命，覺得自己在業界的口碑好得很。其實可以肯定地說，一定不是，這個時候，還是要拿出前兩年的幹勁來，穩紮穩打，積累才剛剛開始。
　　你足夠瞭解你的客戶嗎？你知道他最大的煩惱是什麼嗎？你足夠瞭解你的老闆麼？你知道他最大的煩惱是什麼嗎？你足夠瞭解你的手下麼？你知道他最大的煩惱是什麼嗎？如果你不知道，你憑什麼覺得自己已經積累夠了？如果你都不瞭解，你怎麼能讓他們幫你的忙，做你想讓他們做的事情？如果他們不做你想讓他們做的事情，你又何來的成功？

六、等待
　　這是個浮躁的人們最不喜歡的話題，本來不想說這個話題，因為會引起太多的爭論，而我又無意和人爭論這些，但是考慮到對於職業生涯的長久規劃，這是一個躲避不了的話題，還是決定寫一寫，不愛看的請離開吧。
　　並不是每次穿紅燈都會被汽車撞，並不是每個罪犯都會被抓到，並不是每個錯誤都會被懲罰，並不是每個貪官都會被槍斃，並不是你的每一份努力都會得到回報，並不是你的每一次堅持都會有人看到，並不是你每一點付出都能得到公正的回報，並不是你的每一個善意都能被理解……這個，就是世道。好吧，世道不夠好，可是，你有推翻世道的勇氣麼？如果沒有，你有更好的解決辦法麼？有很多時候，人需要一點耐心，一點信心。每個人總會輪到幾次不公平的事情，而通常，安心等待是最好的辦法。
　　有很多時候我們需要等待，需要耐得住寂寞，等待屬於你的那一刻。周潤發等待過，劉德華等待過，周星馳等待過，王菲等待過，張藝謀也等待過……看到了他們如今的功成名就的人，你可曾看到當初他們的等待和耐心？你可曾看到金馬獎影帝在街邊擺地攤？你可曾看到德雲社一群人在劇場�給一位觀眾說相聲？你可曾看到周星馳的角色甚至連一句臺詞都沒有？每一個成功者都有一段低沉苦悶的日子，我幾乎能想像得出來他們借酒澆愁的樣子，我也能想像得出他們為了生存而掙扎的窘迫。在他們一生最中燦爛美好的日子�，他們渴望成功，但卻兩手空空，一如現在的你。沒有人保證他們將來一定會成功，而他們的選擇是耐住寂寞。如果當時的他們總念叨著“成功只是屬於特權階級的”，你覺得他們今天會怎樣？
　　曾經我也不明白有些人為什麼並不比我有能力卻要坐在我的頭上，年紀比我大就一定要當我的領導麼？為什麼有些爛人不需要努力就能賺錢？為什麼剛剛改革開放的時候的人能那麼容易賺錢，而輪到我們的時候，什麼事情都要正規化了？有一天我突然想，我還在上學的時候他們就在社會�掙扎奮鬥了，他們在社會上奮鬥積累了十幾二十年，我們新人來了，他們有的我都想要，我這不是在要公平，我這是在要搶劫。因為我要得太急，因為我忍不住寂寞。二十多歲的男人，沒有錢，沒有事業，卻有蓬勃的欲望。
　　
　　人總是會遇到挫折的，人總是會有低潮的，人總是會有不被人理解的時候的，人總是有要低聲下氣的時候，這些時候恰恰是人生最關鍵的時候，因為大家都會碰到挫折，而大多數人過不了這個門檻，你能過，你就成功了。在這樣的時刻，我們需要耐心等待，滿懷信心地去等待，相信，生活不會放棄你，機會總會來的。至少，你還年輕，你沒有坐牢，沒有生治不了的病，沒有欠還不起的債。比你不幸的人遠遠多過比你幸運的人，你還怕什麼？路要一步步走，雖然到達終點的那一步很激動人心，但大部分的腳步是平凡甚至枯燥的，但沒有這些腳步，或者耐不住這些平凡枯燥，你終歸是無法迎來最後的那些激動人心。
　　逆境，是上帝幫你淘汰競爭者的地方。要知道，你不好受，別人也不好受，你堅持不下去了，別人也一樣，千萬不要告訴別人你堅持不住了，那只能讓別人獲得堅持的信心，讓競爭者看著你微笑的面孔，失去信心，退出比賽。勝利屬於那些有耐心的人。
　　在最絕望的時候，我會去看電影《The Pursuit of Happyness》《JerryMaguire》，讓自己重新鼓起勇氣，因為，無論什麼時候，我們總還是有希望。當所有的人離開的時候，我不失去希望，我不放棄。每天下班坐在車�，我喜歡哼著《隱形的翅膀》看著窗外，我知道，我在靜靜等待，等待屬於我的那一刻。
　　原貼�伊吉網友的話我很喜歡，抄錄在這�：
　　每個人都希望，自己是獨一無二的特殊者
　　含著金匙出生、投胎到好家庭、工作安排到電力局拿1w月薪這樣的小概率事件，當然最好輪到自己
　　紅軍長征兩萬五、打成右派反革命、胼手胝足犧牲尊嚴去奮鬥，最好留給祖輩父輩和別人
　　自然，不是每個吃過苦的人都會得到回報。但是，任何時代，每一個既得利益者身後，都有他的祖輩父輩奮鬥掙扎乃至流血付出生命的身影，羡慕別人有個好爸爸，沒什麼不可以，問題是，你的下一代，會有一個好爸爸嗎？
　　至於問到為什麼不能有同樣的贏面概率？我只能問：為什麼物種競爭中，人和猴子不能有同樣的贏面概率？物競天擇。猴子的靈魂不一定比你卑微，但你身後有幾十萬年的類人猿進化積澱。

七、入對行跟對人
　　在中國，大概很少有人是一份職業做到底的，雖然如此，第一份工作還是有些需要注意的地方，有兩件事情格外重要，第一件是”入行”，第二件事情是”跟人”。第一份工作對人最大的影響就是入行，現代的職業分工已經很細，我們基本上只能在一個行業�成為專家，不可能在多個行業�成為專家。很多案例也證明即使一個人在一個行業非常成功，到另外一個行業，往往完全不是那麼回事情，“你想改變世界，還是想賣一輩子汽水？”是賈伯斯邀請百事可樂總裁約翰·斯考利加盟蘋果時所說的話，結果這位在百事非常成功的約翰，到了蘋果表現平平。其實沒有哪個行業特別好，也沒有哪個行業特別差，或許有報導說哪個行業的平均薪資比較高，但是他們沒說的是，那個行業的平均壓力也比較大。看上去很美的行業一旦進入才發現很多地方其實並不那麼完美，只是外人看不見。
　　說實話，我自己都沒有發大財，所以我的建議只是讓人快樂工作的建議，不是如何發大財的建議，我們只討論一般普通打工者的情況。我認為選擇什麼行業並沒有太大關係，看問題不能只看眼前。比如，從前年開始，國家開始整頓醫療行業，很多醫藥公司開不下去，很多醫藥行業的銷售開始轉行。其實醫藥行業的不景氣是針對所有公司的，並非針對一家公司，大家的日子都不好過，這個時候跑掉是非常不划算的，大多數正規的醫藥公司即使不做新生意撐個兩三年總是能撐的，大多數醫藥銷售靠工資撐個兩三年也是可以撐的，國家不可能永遠捏著醫藥行業不放的，兩三年以後光景總歸還會好起來的，那個時候別人都跑了而你沒跑，那時的日子應該會好過很多。有的時候覺得自己這個行業不行了，問題是，再不行的行業，做得人少了也變成了好行業，當大家都覺得不好的時候，往往卻是最好的時候。大家都覺得金融行業好，金融行業門檻高不說，有多少人削尖腦袋要鑽進去，競爭激烈，進去以後還要時時提防，一個疏忽，就被後來的人給擠掉了，壓力巨大，又如何談得上快樂？也就未必是“好”工作了。
　　太陽能這個東西至今還不能進入實際應用的階段，但是中國已經有7家和太陽能有關的公司在紐交所上市了，國美、蘇寧永樂其實是貿易型企業，也能上市，魯泰紡織連續10年利潤增長超過50%，賣茶的一茶一座，賣衣服的海瀾之家都能上市……其實選什麼行業真的不重要，關鍵是怎麼做。事情都是人做出來的，關鍵是人。
　　有一點是需要記住的，這個世界上，有史以來直到我們能夠預見得到的未來，成功的人總是少數，有錢的人總是少數，大多數人是一般的，普通的，不太成功的。因此，大多數人的做法和看法，往往都不是距離成功最近的做法和看法。因此大多數人說好的東西不見得好，大多數人說不好的東西不見得不好。大多數人都去炒股的時候說明跌只是時間問題，大家越是熱情高漲的時候，跌的日子越近。大多數人買房子的時候，房價不會漲，而房價漲的差不多的時候，大多數人才開始買房子。不會有這樣一件事情讓大家都變成功，發了財，歷史上不曾有過，將來也不會發生。有些東西即使一時運氣好得到了，還是會在別的時候別的地方失去的。
　　
　　年輕人在職業生涯的剛開始，尤其要注意的是，要做對的事情，不要讓自己今後幾十年的人生總是提心吊膽，更不值得為了一份工作賠上自己的青春年華。我的公司是個不行賄的公司，以前很多人不理解，甚至自己的員工也不理解，不過如今，我們是同行中最大的企業，客戶樂意和我們打交道，尤其是在國家打擊腐敗的時候，每個人都知道我們做生意不給錢的名聲，都敢於和我們做生意。而勇於給錢的公司，不是倒了，就是跑了，要不就是每天睡不好覺，人還是要看長遠一點。很多時候，看起來最近的路，其實是最遠的路，看起來最遠的路，其實是最近的路。
　　跟對人是說，入行後要跟個好領導好老師，剛進社會的人做事情往往沒有經驗，需要有人言傳身教。對於一個人的發展來說，一個好領導是非常重要的。所謂“好”的標準，不是他讓你少幹活多拿錢，而是以下三個。
　　首先，好領導要有寬廣的心胸，如果一個領導每天都會發脾氣，那幾乎可以肯定他不是個心胸寬廣的人，能發脾氣的時候卻不發脾氣的領導，多半是非常厲害的領導。中國人當領導最大的毛病是容忍不了能力比自己強的人，所以常常可以看到的一個現象是，領導很有能力，手下一群庸才或者手下一群閒人。如果看到這樣的環境，還是不要去的好。
　　其次，領導要願意從下屬的角度來思考問題，這一點其實是從面試的時候就能發現的，如果這位領導總是從自己的角度來考慮問題，幾乎不聽你說什麼，這就危險了。從下屬的角度來考慮問題並不代表同意下屬的說法，但他必須瞭解下屬的立場，下屬為什麼要這麼想，然後他才有辦法說服你，只關心自己怎麼想的領導往往難以獲得下屬的信服。
　　第三，領導敢於承擔責任，如果出了問題就把責任往下推，有了功勞就往自己身上攬，這樣的領導不跟也罷。選擇領導，要選擇關鍵時刻能抗得住的領導，能夠為下屬的錯誤買單的領導，因為這是他作為領導的責任。
　　有可能，你碰不到好領導，因為，中國的領導往往是屁股決定腦袋的領導，因為他坐領導的位置，所以他的話就比較有道理，這是傳統觀念官本位的誤區，可能有大量的這種無知無能的領導，只是，這對於你其實是好事，如果將來有一天你要超過他，你希望他比較聰明還是比較笨？相對來說這樣的領導其實不難搞定，只是你要把自己的身段放下來而已。多認識一些人，多和比自己強的人打交道，同樣能找到好的老師，不要和一群同樣鬱悶的人一起控訴社會，控訴老闆，這幫不上你，只會讓你更消極。和那些比你強的人打交道，看他們是怎麼想的，怎麼做的，學習他們，然後跟更強的人打交道。

八、選擇
　　我們每天做的最多的事情，其實是選擇，因此在談職業生涯的時候不得不提到這個話題。
　　我始終認為，在很大的範圍內，我們究竟會成為一個什麼樣的人，決定權在我們自己，每天我們都在做各種各樣的選擇，我可以不去寫這篇文章，去別人的帖子拍拍磚頭，也可以寫下這些文字，幫助別人的同時也整理自己的思路，我可以多注意下格式讓別人易於閱讀，也可以寫成一堆，我可以就這樣發上來，也可以在發以前再看幾遍，你可以選擇不刮鬍子就去面試，也可以選擇出門前照照鏡子……每天，每一刻我們都在做這樣那樣的決定，我們可以漫不經心，也可以多花些心思，成千上萬的小選擇累計起來，就決定了最終我們是個什麼樣的人。
　　從某種意義上來說我們的未來不是別人給的，是我們自己選擇的，很多人會說我命苦啊，沒得選擇阿，如果你認為“去微軟還是去IBM”“上清華還是上北大”“當銷售副總還是當廠長”這種才叫選擇的話，的確你沒有什麼選擇，大多數人都沒有什麼選擇。但每天你都可以選擇是否為客戶服務更周到一些，是否對同事更耐心一些，是否把工作做得更細緻一些，是否把情況瞭解得更清楚一些，是否把不清楚的問題再弄清楚一些……你也可以選擇在是否在痛苦中繼續堅持，是否拋棄掉自己的那些負面的想法，是否原諒一個人的錯誤，是否相信我在這�寫下的這些話，是否不要再犯同樣的錯誤……生活每天都在給你選擇的機會，每天都在給你改變自己人生的機會，你可以選擇賴在地上撒潑打滾，也可以選擇咬牙站起來。你永遠都有選擇。有些選擇不是立杆見影的，需要累積，比如農民可以選擇自己常常去澆地，也可以選擇讓老天去澆地，誠然你今天澆水下去苗不見得今天馬上就長出來，但常常澆水，大部分苗終究會長出來的，如果你不澆，收成一定很糟糕。
　　每天生活都在給你機會，他不會給你一疊現金也不會拱手送你個好工作，但實際上，他還是在給你機會。我的家庭是一個普通的家庭，沒有任何了不起的社會關係，我的父親在大學畢業以後就被分配到了邊疆，那個小縣城只有一條馬路，他們那一代人其實比我們更有理由抱怨，他們什麼也沒得到，年輕的時候文化大革命，書都沒得讀，支援邊疆插隊落戶，等到老了，卻要給年輕人機會了。他有足夠的理由象成千上萬那樣的青年一樣坐在那�抱怨生不逢時，怨氣沖天。然而在分配到邊疆的十年之後，國家恢復招研究生，他考回了原來的學校。研究生畢業，他被分配到了安徽一家小單位�，又是3年以後，國家第一屆招收博士生，他又考回了原來的學校，成為中國第一代博士，那時的他比現在的我年紀還大。生活並沒有放棄他，他也沒有放棄生活。10年的等待，他做了他自己的選擇，他沒有放棄，他沒有破罐子破摔，所以時機到來的時候，他改變了自己的人生。你最終會成為什麼樣的人，就決定在你的每個小小的選擇之間。
　　你選擇相信什麼？你選擇和誰交朋友？你選擇做什麼？你選擇怎麼做？……我們面臨太多的選擇，而這些選擇當中，意識形態層面的選擇又遠比客觀條件的選擇來得重要得多，比如選擇做什麼產品其實並不那麼重要，而選擇怎麼做才重要。選擇用什麼人並不重要，而選擇怎麼帶這些人才重要。大多數時候選擇客觀條件並不要緊，大多數關於客觀條件的選擇並沒有對錯之分，要緊的是選擇怎麼做。一個大學生畢業了，他要去微軟也好，他要賣豬肉也好，他要創業也好，他要做遊戲代練也好，只要不犯法，不害人，都沒有什麼關係，要緊的是，選擇了以後，怎麼把事情做好。
　　除了這些，你還可以選擇時間和環境，比如，你可以選擇把這輩子最大的困難放在最有體力最有精力的時候，也可以走一步看一步，等到了40歲再說，只是到了40多歲，那正是一輩子最脆弱的時候，上有老下有小，如果在那個時候碰上了職業危機，實在是一件很苦惱的事情。與其如此不如在20多歲30多歲的時候吃點苦，好讓自己脆弱的時候活得從容一些。你可以選擇在溫室裏成長，也可以選擇到野外磨礪，你可以選擇在辦公室吹冷氣的工作，也可以選擇40度的酷熱下，去見你的客戶，只是，這一切最終會累積起來，引導你到你應得的未來。
　　我不敢說所有的事情你都有得選擇，但是絕大部分事情你有選擇，只是往往你不把這當作一種選擇。認真對待每一次選擇，才會有比較好的未來。

九、選擇職業
　　職業的選擇，總的來說，無非就是銷售、市場、客服、物流、行政、人事、財務、技術、管理幾個大類，有個有趣的現象就是，500強的CEO當中最多的是銷售出身，第二多的人是財務出身，這兩者加起來大概超過95％。現代IT行業也有技術出身成為老闆的，但實際上，後來他們還是從事了很多銷售和市場的工作，並且表現出色，公司才獲得了成功，完全靠技術能力成為公司老闆的，幾乎沒有。這是有原因的，因為銷售就是一門跟人打交道的學問，而管理其實也是跟人打交道的學問，這兩者之中有很多相通的東西，他們的共同目標就是“讓別人去做某件特定的事情。”而財務則是從數字的層面瞭解生意的本質，從宏觀上看待生意的本質，對於一個生意是否掙錢，是否可以正常運作有著最深刻的認識。
　　公司小的時候是銷售主導公司，而公司大的時候是財務主導公司，銷售的局限性在於只看人情不看數位，財務的局限性在於只看數位不看人情。公司初期，運營成本低，有訂單就活得下去，跟客戶也沒有什麼談判的條件，別人肯給生意做已經謝天謝地了，這個時候訂單壓倒一切，客戶的要求壓倒一切，所以當然要顧人情。公司大了以後，一切都要規範化，免得因為不規範引起一些不必要的風險，同時運營成本也變高，必須提高利潤率，把有限的資金放到最有產出的地方。對於上市公司來說，股東才不管你客戶是不是最近出國，最近是不是那個省又在搞嚴打，到了時候就要把業績拿出來，拿不出來就拋股票，這個時候就是數字壓倒一切。
　　前兩天聽到有人說一句話覺得很有道理，開始的時候我們想“能做什麼？”，等到公司做大了有規模了，我們想“不能做什麼。”很多人在工作中覺得為什麼領導這麼保守，這也不行那也不行，錯過很多機會。很多時候是因為，你還年輕，你想的是“能做什麼”，而作為公司領導要考慮的方面很多，他比較關心“不能做什麼”。
　　我並非鼓吹大家都去做銷售或者財務，究竟選擇什麼樣的職業，和你究竟要選擇什麼樣的人生有關係，有些人就喜歡下班按時回家，看看書聽聽音樂，那也挺好，但就不適合找個銷售的工作了，否則會是折磨自己。有些人就喜歡出風頭，喜歡成為一群人的中心，如果選擇做財務工作，大概也幹不久，因為一般老闆不喜歡財務太積極，也不喜歡財務話太多。先想好自己要過怎樣的人生，再決定要找什麼樣的職業。有很多的不快樂，其實是源自不滿足，而不滿足，很多時候是源自於心不定，而心不定則是因為不清楚究竟自己要什麼，不清楚要什麼的結果就是什麼都想要，結果什麼都沒得到。
　　我想，我們還是因為生活而工作，不是因為工作而生活，生活是最要緊的，工作只是生活中的一部分。我總是覺得生活的各方方面都是相互影響的，如果生活本身一團亂麻，工作也不會順利。所以要有娛樂、要有社交、要鍛煉身體，要有和睦的家庭……最要緊的，要開心，我的兩個銷售找我聊天，一肚子苦水，我問他們， 2年以前，你什麼都沒有，工資不高，沒有客戶關係，沒有業績，處於被開的邊緣，現在的你比那時條件好了很多，為什麼現在卻更加不開心了？如果你做得越好越不開心，那你為什麼還要工作？首先的首先，人還是要讓自己高興起來，讓自己心態好起來，這種發自內心的改變會讓你更有耐心，更有信心，更有氣質，更能包容……否則，看看鏡子裏的你，你滿意麼？
　　有人會說，你說得容易，我每天加班，不加班老闆就會把我炒掉，每天累得要死，哪有時間娛樂、社交、鍛煉？那是人們把目標設定太高的緣故，如果你還在動不動就會被老闆炒掉的邊緣，那麼你當然不能設立太高的目標，難道你還想每天去打高爾夫？你沒時間去健身房鍛練身體，但是上下班的時候多走幾步可以吧，有樓梯的時候走走樓梯不走電梯可以吧？辦公的間隙扭扭脖子拉拉肩膀做做俯臥撐可以吧？誰規定鍛煉就一定要拿出每天2個小時去健身房？你沒時間社交，每月參加郊遊一次可以吧，週末去參加個什麼音樂班，繪畫班之類的可以吧，去嘗試認識一些同行，和他們找機會交流交流可以吧？開始的時候總是有些難的，但邁出這一步就會向良性迴圈的方向發展。而每天工作得很苦悶，剩下的時間用來咀嚼苦悶，只會陷入惡性循環，讓生活更加糟糕。

　雖然離開惠普僅有十五天，但感覺上惠普已經離我很遠。我的心思更多放在規劃自己第二階段的人生，這並非代表我對惠普沒有任何眷戀，主要還是想以此驅動自己往前走。
　　萬科王石登珠穆朗瑪峰的體驗給我很多啟發，雖然在出發時攜帶大量的物資，但是登頂的過程中，必須不斷減輕負荷，最終只有一個氧氣瓶和他登上峰頂。登山如此，漫長的人生又何嘗不是。
　　我宣佈退休後，接到同事朋友同學的祝賀。大部分人都認為我能夠在這樣的職位上及年齡選擇退休，是一種勇氣，也是一種福氣。
　　還有一部分人懷疑我只是借此機會換個工作，當然還有一些人說我在HP做不下去了，趁此機會離開。
　　我多年來已經習慣別人對我的說三道四，但對於好友，我還是挺關心大家是否真正理解我的想法，這也是寫這篇文章的目的。
　　由於受我父親早逝的影響，我很早就下定決心，要在有生之年實現自己的願望，我不要像我父親一樣，為家庭生活忙碌一輩子，臨終前感傷，懊惱自己有很多沒有實現的理想。
　　一本雜誌的文章提到我們在生前就應該思考自己的墓誌銘，因為那代表你自己對完美人生的定義，我們應該盡可能在有生之年去實現它。
　　我希望我的墓誌銘上除了與家人及好友有關的內容外，是這樣寫著：
　　1.這個人曾經服務於一家全球最大的IT公司（HP）25年，和她一起經歷過數次重大的變革，看著她從以電子儀表為主要的業務變革成全球最大的IT公司。
　　2.這個人曾經在全球發展最快的國家（中國）工作16年，並擔任HP中國區總裁7年，見證及經歷過中國改革開放的關鍵最新突破階段，與中國一起成長。
　　3.這個人熱愛飛行，曾經是一個有執照的飛行員，累積飛行時數超過X小時，曾經在X個機場起降過。
　　4.這個人曾經獲得管理碩士學位，在領導管理上特別關注中國企業的組織行為及績效，並且在這個領域上獲得中國企業界的認可。
　　我費時25年才總結1和2兩項成果，我不知還要費時多久才能達成3和4的願望，特別是第4個願望需要經歷學術的訓練，才能將我的經驗總結成知識。
　　否則我的經驗將無法有效影響及傳授他人。因此重新進入學校學習，拿一個管理學位是有必要的，更何況這是我一個非常重要的願望。
　　另一方面，我25年的時間都花在運營(operation)的領域，兢兢業業的做好職業人士的工作，它是一份好工作，特別是在HP，這份工作也幫助我建立財務的基礎，支持家庭的發展。
　　但是我不想終其一生，都陷入在運營的領域，我想像企業家一樣，有機會靠一些點子(ideas)賺錢，雖然風險很高，但是值得一試，即使失敗，也不枉走一回，這也是第4個願望其中的一部份。
　　Carly Fiorina曾經對我說過“這個世界上有好想法的人很多，但有能力去實現的人很少”，2007年5月21日在北大演講時，有人問起那些書對我影響較大，我想對我人生觀有影響的其中一本書叫“TriggerPoint”，它的主要觀點是：人生最需要的不是規劃，而是在適當的時機掌握機會，採取行動。
　　我這些願望在我心中已經醞釀一段很長的時間，開始的時候，也許一年想個一兩次，過了也就忘掉，但逐漸的，這個心中的聲音，愈來愈大，出現的頻率也愈來愈高，當它幾乎每一個星期都會來與我對話時，我知道時機已經成熟。
　　但和任何人一樣，要丟掉自己現在所擁有的，所熟悉的環境及穩定的收入，轉到一條自己未曾經歷過，存在未知風險的道路，需要絕大的勇氣，家人的支持和好友的鼓勵。有捨才有得，真是知易行難，我很高興自己終於跨出了第一步。
　　我要感謝HP的EER提前退休優惠政策，它是其中一個關鍵的TriggerPoints,另一個關鍵因素是在去年五六月發生的事。
　　當時我家老大從大學畢業，老二從高中畢業，在他們繼續工作及求學前，這是一個黃金時段，讓我們全家可以相聚一段較長的時間，我為此很早就計畫休一個長假，帶著他們到各地遊玩。
但這個計畫因為工作上一件重要的事情（Mark Hurd訪華）不得不取消。這個事件刺激了我必須嚴肅的去對待那心中的聲音，我會不會繼續不斷的錯失很多關鍵的機會?
　　我已經年過50，我會不會走向和我父親一樣的道路？人事部老總Charles跟我說，很多人在所有對他有利的星星都排成一列時，還是錯失時機。
　　我知道原因，因為割捨及改變對人是多麼的困難，我相信大部分的人都有自己人生的理想，但我也相信很多人最終只是把這些理想當成是幻想，然後不斷的為自己尋找不能實現的藉口，南非前總統曼德拉曾經說過，“與改變世界相比，改變自己更困難”，真是一針見血。
　　什麼是快樂及有意義的人生？我相信每一個人的定義都不一樣，對我來說，能實現我墓誌銘上的內容就是我的定義。
　　在中國惠普總裁的位置上固然可以吸引很多的關注及眼球，但是我太太及較親近的好友，都知道那不是我追求的，那只是為扮演好這個角色必須盡力做好的地方。
　　做一個沒有名片的人士，雖然只有十多天的時間，但我發現我的腦袋裏已經空出很多空間及能量，讓我可以靜心的為我ChapterII的新生活做細緻的調研及規劃。
　　我預訂以兩年的時間來完成轉軌的準備工作，並且花多點時間與家人共處。這兩年的時間我希望拿到飛行執照，拿到管理有關的碩士學位，提升英文的水準，建立新的網路，多認識不同行業的人，保持與大陸的聯繫。希望兩年後，我可以順利回到大陸去實現我第四個願望。
　　毫不意外，在生活上，我發現很多需要調整的地方。
　　二十多年來，我生活的步調及節奏，幾乎完全被公司及工作所左右，不斷湧出的deadline及任務驅動我每天的安排，一旦離開這樣的環境，第一個需要調整的就是要依靠自己的自律及意志力來驅動每天的活動，睡覺睡到自然醒的態度絕對不正確，放鬆自己，不給事情設定目標及時間表，或者對錯失時間目標無所謂，也不正確，沒有年度，季度，月及周計畫也不正確。
　　擔任高層經理多年，已經養成交待事情的習慣，自己的時間主要花在思考，決策及追蹤專案的進展情況，更多是依靠一個龐大的團隊來執行具體的事項及秘書來處理很多協調及繁瑣的事情。
　　到美國後，很多事情需要打800號電話聯繫，但這些電話很忙，常讓你在waitingline上等待很長的時間，當我在等待時，我可以體會以前秘書工作辛苦的地方，但同時也提醒我自己，在這個階段要改變態度，培養更大的耐性及自己動手做的能力。
　　生活的內容也要做出很大的調整，多出時間鍛煉身體，多出時間關注家人，多出時間關注朋友，多出時間體驗不同的休閒活動及飛行，一步步的，希望生活逐步調整到我所期望的軌道上，期待這兩年的生活既充實又充滿樂趣及意義。
　　第一個快樂的體驗就是準備及參加大兒子的訂婚禮，那種全心投入，不需擔憂工作數位的感覺真好。同時我也租好了公寓，買好了傢俱及車子，陪家人在週末的時候到Reno及Lake Tahoe玩了一趟，Lake Tahoe我去了多次，但這次的體驗有所不同，我從心裏欣賞到它的美麗。
　　但同時我也在加緊調研的工作，為申請大學及飛行學校做準備，這段時間也和在矽谷的朋友及一些風險投資公司見面，瞭解不同的產業。
　　我的人生觀是“完美的演出來自充分的準備”，“勇於改變自己，適應不斷變化的環境，機會將不斷出現”，“快樂及有意義的人生來自於實現自己心中的願望，而非外在的掌聲”。
　　我離開時，有兩位好朋友送給我兩個不同的祝語，Baron的是“多年功過化煙塵”，楊華的是“莫春者，風乎舞雩，詠而歸”，它們分別代表了我離開惠普及走向未來的心情。
　　我總結人生有三個階段，一個階段是為現實找一份工作，一個階段是為現實，但可以選擇一份自己願意投入的工作，一個階段是為理想去做一些事情。
　　我珍惜我的福氣，感激HP及同事、好朋友給我的支持，鼓勵及協助，這篇文字化我心聲的文章與好友分享。

People who looked at this item also looked at…

[笑話] 給程式設計師的笑話

loda — Sun, 13 May 2012 04:45:02 +0000

http://www.ptt.cc/bbs/joke/M.1335492618.A.C08.html

From PTT
1.程式設計師給系統工程師:

這個專案無法完成，它必須要大幅度更改規格，而我們團隊中沒有人
了解關於這個程式的規格，也沒有人懂得這個應用程式使用的語言。
依我個人的看法，公司絕對不該接下這個專案。

2.系統工程師給組長:

這個專案需要規格的更改，目前我們的工作人員缺乏此種經驗，
使用的語言也還不熟悉，若要接下，則必須接受適當的研習。
依我個人的看法，我們還沒有十足的準備接下這個專案。

3.組長給專案經理:

這個專案必須在系統內更改規格，而我們對此種案件還沒有十足的相關經驗，
並且公司中大多數的人尚未接受過必需的研習。
依我個人的看法，必須花上比平常多的時間才有可能完成。

4.專案經理給部門主管:

這個專案需要將規格重新建構，而我們之中一部份人有經驗，
一部份人了解使用的語言，因此我想只要讓不懂的向懂的人學習就行了。
依我個人的看法，這個專案雖然有隱憂但是必須接下。

5.部門主管給總經理:

這個專案是一個可以向業界展示我們更改系統規格實力的機會。
我們具備足以讓專案成功的能力和人材，其中幾人已經自行完成了研習。
依我個人的看法，無論如何都不該錯過這個專案。

6.總經理給客戶:

我們是處理此種專案的專家，從前早已經歷過非常多數來自其他
大客戶的類似專案，以經驗來說完全多過於其他公司，請一定要讓我們接下。
依我個人的看法，我們絕對能在期限之內完成這個專案。

程式設計師:
……………

People who looked at this item also looked at…

我最喜歡的10條程式設計語錄

loda — Sun, 13 May 2012 04:44:52 +0000

我最喜歡的10條程式設計語錄

http://blog.jobbole.com/18399/

來源：伯樂線上
從去年開通@程式師的那些事開始，陸陸續續發佈了一些#程式設計語錄#。今天也在國外程式師 Senthil Kumar 的博客看到了他最喜歡的10條程式設計語錄。其中大部分已經分享過，現再次綜合分享給大家。
（提示：正如廣為流傳的經典段子，有些經典語錄有多個版本，作者署名都不一樣。從下文就可以看出來。英文原文我保留了 Senthil Kumar 的。中文版本後面的作者署名是我當時所看到的署名。）
09. If debugging is the process of removing software bugs, then programming must be the process of putting them in. – Edsger Dijkstra
如果偵錯工具是移除臭蟲（軟體缺陷）的過程，那編寫程式就是把臭蟲放進來的過程。—— 迪傑斯特拉
08. The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. – Tom Cargill
軟體發展的時間通常是這樣的：一開始的90%開發工作用掉了整個計畫90%的時間，剩下的10%同樣需要整個計畫90%的時間，而最終發佈前的修改也是如此。—— N.J. Rubenking
Writing the first 90 percent of a computer program takes 90 percent of the time. The remaining ten percent also takes 90 percent of the time and the final touches also take 90 percent of the time. ~N.J. Rubenking

07. “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.”- C.A.R. Hoare
設計軟體有兩種方法：一種是簡單到明顯沒有缺陷，另一種複雜到缺陷不那麼明顯。—— 托尼•霍爾
06. Measuring programming progress by lines of code is like measuring aircraft building progress by weight. – Bill Gates
用代碼行數來衡量程式的開發進度，就好比用重量來衡量飛機的製造進度。—— 比爾•蓋茨
05. “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” – Martin Golding
在編寫代碼的時候，你要經常想著，那個最終維護你代碼的人可能將是一個有暴力傾向的瘋子，並且他還知道你住在哪裡。—— 裡克•奧斯本
補充：關於這條語錄，StackOverflow 上也有個討論帖，給出的答案可能是 John Woods。

04. “The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.” – Seymour Cray
程式師的問題是，你無法知道他在做什麼，直到為時已晚。—— 西摩•克雷

03. Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. – Rick Cook
今日之程式設計，已是竭力要建立更大更反白癡程式的軟體工程師，和正塑造更大更優質白癡的現實世界之間的比賽。目前來看，現實世界贏了。—— Rick Cook

02. “Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.” – Larry Wall
你們大部分人都熟悉程式師的美德。當然了，是這三種：懶惰、急躁、傲慢。—— 拉裡•沃爾（Perl 語言之父）

01. “Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday’s code.” – Christopher Thompson
有的時候寧願付錢讓你週一在床上待著，也不想讓你用這周剩下的時間去調試你在週一所寫的代碼。 —— 丹•所羅門

00. Walking on water and developing software from a specification are easy if both are frozen. – Edward V Berard
在水中行走，和根據一份需求開發軟體一樣，如果它們都“凍”住了，那就容易了。—— 愛德華•貝拉爾德

英文原文：Senthil Kumar 編譯：伯樂線上 – 黃利民

People who looked at this item also looked at…

Type ‘Zerg Rush’ Into Google for a Pleasant Surprise

loda — Sun, 13 May 2012 03:17:50 +0000

https://www.google.com/#hl=zh-TW&site=&source=hp&q=zerg rush

by Todd Wasserman

http://mashable.com/2012/04/27/zerg-rush-google/

Google is giving us another reason to goof off on a Friday with an Easter egg related to the popular game StarCraft.

If you type “Zerg Rush” into Google, the “O’s” in Google take over the page. If you double click, your cursor turns into a plus sign. Click on the O’s and you wipe them out. Google then tabulates your score and, in a social media twist, lets you post your score on Google+.

For the uninitiated, Zergs are an alien race of insectoids in Blizzard Entertainment’s StarCraft. In the game you “rush” them by amassing your battle units and blitz them.

Google’s motivation for this latest Easter egg is unclear, except perhaps as a way to migrate more users to Google+.

People who looked at this item also looked at…

Open Sourcers Drop Software Religion for Common Sense

loda — Sat, 21 Apr 2012 17:48:47 +0000

Open Sourcers Drop Software Religion for Common Sense

http://digg.com/newsbar/Opensource/open_sourcers_drop_software_religion_for_common_sense

Olson helped build the open source Berkeley DB database in the early 90s — before the Linux boom — and as the CEO of Sleepycat Software, he turned the database into a successful business using something very similar to the GPL, the free software license that was so essential to the rise of Linux. The GPL — or GNU General Public license — said that if someone modified free software and distributed the code with a larger product, they would have to contribute their work back to the community.
But in 2009, Olson founded Cloudera — the first outfit to commercialize Hadoop, the open source data-crunching platform based on Google’s software infrastructure — and he dropped the GPL in favor of the Apache license, a license that doesn’t require contributions back to the community. You might think that such licenses would stunt the growth of the open source world. But Olson believes the opposite is true.
The open source zealots don’t agree. But Olson is by no means the only one backing the Apache license. According to some statistics, the world’s open source projects are gradually moving away from restrictive licenses such as the GPL and towards more permissive licenses such as the Apache, and many open source watchers — including longtime pundit Matt Asay and Steven O’Grady, an analyst with developer-minded research firm RedMonk — agree that this shift will ultimately bring open source to a much wider audience.
“The business-side of open source has moved towards the Apache license model…and Mike Olson was out in front of everyone on that,” says Asay, who for many years downplayed the importance of the Apache license. “He was the guy, behind the scenes, constantly calling B.S. on all of us who believed in the GPL.”
The main forces behind this movement are the giants of the web, including Facebook and Twitter, which have a very different attitude towards open source than traditional software companies. But as these big names release more and more projects under permissive licenses, they’ve spawned a new breed of open source vendor, such as Cloudera, that’s potentially much more attractive to the world’s businesses because it avoids the GPL and other restrictive licenses.
Rightly or wrongly, many businesses are afraid of the GPL, worried it will force them to give up their proprietary code. But with the Apache license, that fear goes away. For Olson and others, this not only encourages the adoption of open source tools, it’s a better way for companies like Cloudera to actually make money from free software.
Apache Rising
Restrictive licenses such as the GPL are still the most widely used — by far — according to Black Duck Software, a company that tracks the use of free software licenses. But now that the free software movement has matured — and the web has changed the economics of the movement — Black Duck’s stats indicate that the GPL’s influence is waning in a favor of more permissive licenses such as the Apache.
According to the company’s numbers, the percentage of projects using the GPL dropped from 70 percent in June 2008 to about 57 percent today, while the Apache and the MIT — another permissive license — have risen to 5 and 11 percent respectively.
Brett Smith — the license compliance engineer at the Free Software Foundation, the not-for-profit that spawned the GPL — argues that stats like Black Duck’s are misleading. “It’s been hard to really figure out what those numbers really mean because they come from data that’s not fully published,” he says. “It’s hard to tell what really going on.” But others — such a Redmonk’s Steven O’Grady and Paula Hunter, executive director of the OuterCurve Foundation, a Microsoft-backed open source advocate — say they’re seeing the same trend that Black Duck sees. (Black Duck declined to be interviewed for this story).
What’s clear is that over the last few years, many of the highest profile open source projects have chosen the Apache license, including “cloud computing” platforms such as Hadoop, OpenStack, Cassandra, and CloudFoundry. Node.js, another of-the-moment cloud platform, uses the MIT License. And even the big-name mobile platforms have joined the crowd. Google’s Android mobile OS used the Apache license, and just this week, HP announced its schedule for open sourcing Palm’s webOS platform under the Apache.
It’s no coincidence that many of these projects grew out of the big web companies. “They have a very different attitude towards open source than we’ve seen in the past,” says Steven O’Grady. “They don’t value code in the same way. These companies are taking code that would have been proprietary five or six years ago — that would have been seen as differentiating code — and just releasing it. They don’t necessarily want or need the protections of a restrictive license.”
Companies such as Facebook and Yahoo — the companies that bootstrapped Hadoop — aren’t in the business of selling software. But that’s only part of the explanation. They built their operations using open source software they pulled from the community, so they’re happy to give back to others without requiring something in return. But at the same time, they realize that others feel the same way. They know a return will come anyway.
O’Grady points to Twitter as another prime example, with projects such as the open source database FlockDB and the open source web developer toolkit Bootstrap. Then there’s Rackspace with OpenStack, a platform for serving up virtual computing resources a la Amazon Web Services.
But the trend doesn’t stop there. Myriad businesses have sprung up around these open source projects, hoping to help the rest of the world adopt the software — and make some money in the process. Facebook’s open source Cassandra database spawned the Texas-based DataStax. Hadoop gave rise to not only to Cloudera but a Yahoo spinoff dubbed Hortonworks. Rackspace formed its own services division around OpenStack. And Joyent, the steward of Node.js, is selling software and services to companies using the open source development platform. Mike Olson is by no means alone.
The Poison and the Antidote
When Olson was at Sleepycat, Berkeley DB carried a “strong copyleft” license based on the GPL. You could use Berkeley DB for free, but if you did, you might have to pay the cost with your own code. For many companies, it was an unsettling proposition. Though they wanted Berkeley DB, they didn’t want to let go of software they’d spent years developing. But Sleepycat offered a loophole. If you paid Olson and company some money, they would give you a separate license that let you keep your own code. It’s a technique known as dual-licensing.
“The GPL was kind of the poison, and we would sell you the antidote. If you preferred not to infect your source code with the GPL, you could buy a different license,” Olson says. “This was reasonably successful for us, but we were never going to be a $100 million-a-year company. Our commercial transaction with our customers was founded on a threat: ‘Either you give me some money or I’m going to infect your intellectual property.’ That’s not a real good place to start a business conversation.”
In using the Apache license, Cloudera completely changes the dynamic. In essence, you can use the free code however you like — without contributing any of your own code back to the community. Cloudera makes its money by selling support and additional proprietary software that works in tandem with Hadoop. It’s a strategy bridges the gap between free software and un-free software.
“Open source is a really important part of what we do. About half of our engineering spend goes to the open source [Hadoop] project,” Olson says. “But it’s important to differentiate ourselves from the rest of the market, to have a reason for customers to come uniquely to us.”
Some people call Cloudera an “open core” company. The core of the project is open source, and the for-pay software that Cloudera offers around it is not. But the name doesn’t come up as often as it once did. “Open core” developed a negative connotation among the community because it implied a lack of openness.
Mike Olson doesn’t care what you call it. “Whatever you call it,” he says, “it works.”
Open Source Pragmatism
The still private Cloudera says very little about it finances, but its list of customers includes such as names as Groupon, Rackspace, and Samsung, and according to Olson, it has made inroads beyond the tech world, on Wall Street and with biomedical outfits. A big part of the company’s success, he says, is the Apache license. He understands why people like Free Software Foundation founder Richard Stallman back the GPL — and, yes, the GPL was very good to Olson for many years. But these are new times.
“I don’t believe that a political or religious conviction is the sound basis for a business,” he says. “If you talk to some of the early free software folks, it was all about rights and responsibilities — and I understand why Richard focused on that stuff — but if you want to build a business, you have to focus on customers and markets and commercial opportunity. The GPL gives you some ways to monetize what you do. But there are other collaborative licenses that give you more.”
The advantage is that the Apache is less threatening to potential customers. “If you want software to be used, you want an Apache license,” says Mark Radcliffe, a partner with international law firm DLA Piper who specializes in open source software. “There’s very little legal complexity for people to deal with.” And once you have the users, Olson, there are more ways of making money.
That lack of complexity is another reason so many web companies choose the Apache license when open sourcing their code. “The trend is driven in large part by companies that want to integrate open source development into their fundamental open source project strategy, but don’t want that headaches that arise from the GPL,” Radcliffe says. In other words, they don’t have to worry about giving up the code they don’t want to give up.
The overarching theme is that open source software is mixing freely with proprietary code. That’s what the Apache license allows. Olson sees it as the future, pointing to giants such as Oracle and IBM that have built successful businesses around open source software projects. “I think that successful open source businesses will look a lot more like IBM or Oracle than Red Hat or MySQL or Sleepycat,” he says.
And he believes that even without licenses such as the GPL in place, companies will continue to contribute to open source projects because they now understand how valuable this can be. “As the industry has matured, I think that people have internalized the value of collaboration,” he says. “You don’t need to browbeat them.”
Facebook and Yahoo and Twitter have taught the world. And so has Mike Olson.

開源者的信仰正在崩塌

http://www.ylmf.net/soft/news/observed/2012032633439.html

來源：CSDN
GPL 協定的自由軟體分享規定對於一些個人和企業是一種約束，這讓許多開發者或者公司開始轉向使用Apache授權合約，Apache 授權合約允許人們使用、修改開原始程式碼，但沒有要求使用者必須公開分享自己的原始程式碼。這讓許多開源運動支持者開始質疑，開源者的信仰是不是已經改變?
leepycat 軟體公司CEO Mike Olson 作為開源運動的先驅，卻不是一個開源軟體狂熱分子。他對開源運動有自己的理解，並作出了與眾不同的舉動。
　　早在90年代Linux還未盛行時，Olson 在建立開源軟體 Berkeley DB 資料庫過程中作出了不小的貢獻。而作為 Sleepycat 軟體公司的CEO，他利用一個類似於GPL的協議——對於Linux發展非常重要的自由軟體協定，將這個資料庫成功轉入商業化。GPL 協議規定：如果你完善了某個自由軟體並將它的代碼應用在一個大型軟體產品中，那麼你需要將你的這個產品再共用給自由軟體使用者。
　　在2009年，Olson 建立了Cloudera——第一個利用 Hadoop 牟利的組織，基於穀歌軟體基礎結構的開來源資料運算平臺——他用Apache授權合約替代了GPL。Apache 許可證不要求使用者必須將軟體再次共用給大眾。你可能會覺得這樣的授權合約一定會阻礙開源世界的發展，但 Olson 認為存在這樣的不一樣的聲音是很有必要的。
　　Olson 絕不僅僅是唯一一個支持Apache授權合約的。據一組統計資料顯示，當今世界上許多開源項目都在從有約束性的授權合約(比如GPL協議)陣營中轉投寬鬆的授權合約(如Apache授權合約)陣營。並且，許多開源運動關注者——包括長期關注的專家 Matt Asay 和一名來自 RedMonk 對開發有興趣的研究員 Steven O’Grady，都認為這樣的改變將會給開源世界帶來更好的發展，會有更多的人加入開源陣營。
　　“商業化的開源專案都開始向Apache授權合約模式轉變，而 Olson 只是走在了這些人的前面，”多年來一直輕視Apache授權合約重要性的 Asay 指出，“他就是在幕後一直嘲笑我們這些GPL支持者的傢伙。”
　　這場運動最大的力量來自于互聯網巨頭，包括 Facebook 和 Twitter，他們相對于傳統的軟體公司對開源有著非常不一樣的態度。但隨著這些巨頭以及他們的項目源源不斷加入到支援寬鬆授權合約的陣營中來，產生了一大批利用開源獲利的公司，如Cloudera，他們避開了GPL以及其他的約束性授權合約，很可能吸引商業公司的注意。
　　相對於Apache授權合約，許多公司都擔心GPL協定，擔心GPL協定會讓他們公佈自己的私有代碼。但是在Apache授權合約內，這種擔心就沒有必要。對於 Olson 以及其他人來說，這不僅僅是鼓勵他們使用開源工具，也是非常有利於Cloudera 這樣的公司從自由軟體中賺錢的。
　　Apache 授權合約受到青睞
　　Black Duck Software 一直在跟蹤調查自由軟體授權合約，根據其統計，約束性授權合約例如GPL仍然被廣泛的使用。但現在，自由軟體運動逐漸成熟，而且互聯網改變了這場運動的經濟狀況，Black Duck 的統計表明，GPL 的影響力相對於許多如Apache這樣的寬鬆類授權合約來說正在逐漸下降。
　　有資料顯示，GPL 協定的專案使用率正在由 2008 年的 70% 下降到現在的 57%，而Apache以及 MIT(另一個寬鬆型的授權合約)的使用率則分別由5% 上升至 11%。
　　Free Software Foundation，由GPL產生的非營利性公司，它的一名授權合約服從工程師 Brett Smith 認為像 Black Duck 公司的統計資料具有誤導性。“他們所得到的資料不是完全公開的，所以通過那些資料計算出來的數位無法表明什麼”，他說，“以後GPL或者其他授權合約如何發展很難預料的。”但其他人，如 Redmonk 的 Steven O’Grady 和 OuterCurve Foundation 的執行董事 Paula Hunter，一名微軟後端開發開源的提倡者，他們認為他們看的東西發展趨勢是和 Black Duck 公司看到的一樣。(Black Duck declined to be interviewed for this story).
　　很明顯的，最近幾年很多開源項目都姿態鮮明地選擇了Apache授權合約，包括雲計算平臺如 Hadoop、OpenStack、Cassandra 以及 CloudFoundry。另外，Node.js 遵循的是 MIT 授權合約。甚至一些著名的移動平臺也加入了這一陣營，比如安卓手機作業系統就支援Apache授權合約，惠普之前則公佈了開源的 Palm’s webOS 平臺加入Apache授權合約陣營的時間表。
　　巧合的是，許多項目都是來自大的互聯網公司。“相對於我們以前所看到的，他們對待開源有截然不同的態度” Steven O’Grady 說，“他們不再像以前那樣重視代碼了。這些公司在五六年前將代碼視作私有——他們認為這些代碼是與眾不同的——但現在卻公開了。”
　　包括 Facebook 以及 Yahoo 在內的通過 Hadoop 引導的公司，他們不以出售軟體為主要業務。但那只是部分的情況。他們通過利用別人的開源軟體建立業務運營，所以他們也願意把這些再分享給別人而不索取回報。但同時，他們知道其他人也是這麼想的，所以他們知道，無論怎樣，回報最終還是會到來的。
　　O’Grady 認為 Twitter 是另一個很好的例子，他們的專案是開來源資料庫 FlockDB 以及開發者工具包 Bootstrap。還有 Rackspace，他們的 OpenStack 是一個提供虛擬計算資源的亞馬遜互聯網服務平臺。
　　這樣的趨勢不會停止，在開源項目周邊，有無數企業如雨後春筍般出現，它們希望説明世界各地採用該軟體，然後從中牟利。Facebook 的資料庫 Cassandra 催生了 Texas-based DataStax、Hadoop 催生的不僅僅有Cloudera 還有雅虎的子公司 Hortonworks、Rackspace 圍繞 OpenStack 建立了自己的服務部門，還有 Node.js 的管理員 Joyent，利用開源開發平臺售賣軟體以及為一些公司做服務。所以說，Mike Olson 並不是個例。

GPL 協議是否是毒藥?
　　在 Olson 還在 Sleepycat 的時候，Berkeley DB 基於GPL協議獲得了一個“強有力的非營利性版權”。你可以免費使用 Berkeley DB，但是如果你用了，你可能不得不用你自己的代碼來付出代價。對於很多公司來說，這是令他們非常不安的一個規定。雖然他們想要用 Berkeley DB，但是他們不想放棄自己多年開發的軟體。但 Sleepycat 提供了一個空子讓他們來鑽，如果你支付給 Olson 和他的公司一些費用，他們就能給你提供不同的授權合約來允許你持有你自己的代碼不公開。它被稱之為雙重授權合約的技巧。
　　“GPL 協議是一種毒藥，而我們能夠賣給你解藥。如果你不希望你的原始程式碼受到GPL協議的影響，你可以購買一份不同的授權合約。”Olson 說，“這對我們來說，相當成功，但是我們永遠沒法成為一個年收入上億的公司。我們的商業交易建立在我們的顧客被威脅的基礎上：‘除非你給我錢，否則將危及你的智慧財產權’，那不是開始商業行為的好方式。”
　　而在Apache授權合約下，Cloudera 完全改變了狀態。本質上，你可以以你喜歡的任何形式使用自由代碼——不需要貢獻任何你自己的代碼給其他共用者。而Cloudera 則利用出售支持以及增加串聯 Hadoop 的私有軟體進行賺錢。這起到了在自由軟體與非自由軟體間搭建橋樑的作用!
　　“開源是我們所做的工作中很重要的一部分。我們有一半的工程師都工作在(Hadoop)開源專案上。”Olson 指出，“但更重要的是，我們需要將自己和其他市場區分開來，這樣可以讓用戶有充分的理由認為我們是特別的。”
　　有些人稱Cloudera 是一個“開放核心(open core)”公司。項目的核心是開源的，而Cloudera 所提供的周邊的付費軟體則不是開源的。但這個名字並不是一開始就有的，“開放核心(open core)”在公眾的嘴裡是一個否定的詞語，因為它在暗指Cloudera 是偽開源的。
　　Mike Olson 不關心別人怎麼稱呼Cloudera，只要能帶來利益，人們怎麼稱呼它都無所謂。
　　開源的實用主義
　　神秘的Cloudera 很少談到他們的收入，但他們的客戶名單上卻不一般，他們擁有包括 Groupon、Rackspace 以及 Samsung 這樣的大客戶。對於 Olson 來說，Cloudera 的發展已經超出科技領域沖進華爾街和生物醫學領域了。這個公司成功最重要的部分，Olson 說，就是Apache授權合約。他理解人們為什麼喜歡 Free Software Foundation 創始人 Richard Matthew Stallman 創建GPL協議，並且，在很多年前，GPL 對 Olson 來說也是好東西，但現在，這是新的時代了。

“我不相信政治或者宗教信仰會是穩妥的商業基礎，”Olson 講到，“如果你和早期的一些自由軟體者聊天，所有的內容都是關於權利和責任的——我明白為什麼 Richard 對那東西感興趣——但如果你作為一名商人，你必須抓住用戶、市場以及商業機會。GPL 確實能夠給你賺錢的機會，但是還有其它的合作的授權合約能夠讓你賺的更多。”
　　Apache 的優點是很少會帶給潛在客戶威脅。“如果你希望軟體被使用，你需要一個Apache授權合約，”國際法律公司 DLA Piper 的合作夥伴 Mark Radcliffe，一個專攻開源軟體的傢伙如是說，“在與之打交道的過程中，很少會遇到複雜的法律問題。”並且，一旦你有了用戶，例如 Olson，那將會有大把的機會賺錢。
　　當開源他們的原始程式碼時，很少遭遇複雜法律問題是許多互聯網公司選擇Apache授權合約的另一個原因。“將開源發展融入他們基本開源項目戰略的原因有很多，發展趨勢只重要的一方面，但你們不要擔心這種情況會發生在GPL那裡。”Radcliffe 講到。換句話說，他們不用擔心要開放自己不想開放的那些代碼。
　　最重要的宗旨是基於Apache許可證下，開原始程式碼與私有代碼自由混合是被允許的。Olson 認為這是未來的發展趨勢，而像 Oracle 以及 IBM 這樣的巨頭已經圍繞開源軟體專案建立了成功的商業模式。“我想，開源商業化的成功將會更像 IBM 或 Oracle 多一些，像 Red Hat、MySQL 或者 Sleepycat 少一些。”
　　他認為，即使沒有類似GPL這樣的協議存在，這些公司也將會繼續促進開源項目的發展，因為他們現在開始意識到這些項目能帶來的利益是可觀的。“隨著行業的逐漸成熟，我想人們已經認識到相互協作的價值，”他說，“你們不需要去嚇唬或者逼迫他們。”
　　只是，這樣的“開源”還是不是開源者最初所信仰的“開源”?

People who looked at this item also looked at…

IC設計業風起雲湧,大陸業者來勢洶洶　小心豬羊變色

loda — Sat, 21 Apr 2012 17:48:33 +0000

IC設計業風起雲湧,大陸業者來勢洶洶　小心豬羊變色

http://tw.naipo.com/Portals/1/web_tw/Knowledge_Center/Industry_Economy/publish-4.htm

北美智權

李淑蓮／編輯部

IC設計業的發展長久以來都集中在美國及台灣2個地區，其他地區雖有零星業者，但以產值來說並不具備產業規模；不然就是像日本或韓國一樣，以IDM（整合元件大廠， Integrated Device Manufacturer）形式出現。然而，自2007年起，中國大陸的IC設計業已悄然成形，而且在5年內產值以倍數成長，於2010年已成為繼美國及台灣之後排名第三的IC設計業基地，全球市占率約7％。在快速成長的情況下，其與台灣IC設計業的產值差距也漸漸拉近，從2005年的5.84倍縮短至2010的2.48倍，對台灣業者造成相當大的威脅。尤其是把市場主力放在中國大陸的台灣業者，必須密切注意大陸IC設計業者的發展動向，以提早作好產品差異化的市場區隔準備。

由產業情報研究所（Market Intelligence & Consulting Institute, MIC）統計的2011年全球及台灣10大IC設計公司的排名已於今年1月陸續出爐，雖然在年初各大廠仍未正式公布去年的營收數字前，MIC提出的營收數據只為預估值，但由於各廠商營收有一段差距，故對排名影響不大。表一及表二分別為全球及台灣IC設計公司2011年的排名，而表三則是中國大陸於2010年排名前十大的IC設計業者。從3個表格中，有幾個值得注意的現象：

（1）從全球10大IC設計公司的排名不難看出2011年行動電話晶片呈大幅度成長，雖然排名第7的聯發科2011年營收比前一年度減少了11.7%，但其主要競爭對手，同樣具備2G、3G、4G行動電話解決方案的Qualcomm（高通）及Broadcom（博通），則呈現高度成長，尤其是Qualcomm，其年成長率更逼近40%。

（2）就台灣的10大IC設計公司的產品分佈來看，很明顯的是顯示器驅動IC（Display Driver IC）占最大的比例，在前10大IC設計公司中，包括聯詠、奇景、奕力、瑞鼎等4家業者的主要產品就是顯示器驅動IC，4家業者總營收便占了10大IC設計業者的1/4強，因此顯示器驅動IC是去年台灣IC設計業的火紅產品已無容置疑。

（3）在中國大陸的部分，其IC設計業仍屬起步階段，故除產值偏低外，其年成長率也是相對偏高。近年來，在中國政府扶植本土通訊產業的政策下，中興、華為及大唐．．．等大陸通訊設備商除了在本土市場占有一席之地外，也逐漸走上國際舞台。在下游終端產品的帶動下，大陸的網通及行動通訊晶片發展相當迅速，像華為旗下的海思半導體，亦即大陸10大IC設計公司的榜首廠商，其2010年的年成長率便達13%。至於第2位生產行動電話基頻晶片的展訊，成長率更是高達247%。

表三．2010年中國IC設計業前10大廠商營收及成長率

註：據MIC原始資料顯示，無錫華潤矽科之2010年營收為44.2億人民幣，但經筆者求證後，已修改為6.2億人民幣。

顯示器驅動IC需求夯　觸控、OLED、3D具潛力

雖然去年因為市場供過於求，單價下滑的影響，全球面板產業整體虧損超過4,000億新台幣；然而，顯示器驅動IC卻有不錯的市場表現。面板產業整體虧損主要是因為去年液晶電視、顯示器、筆記型電腦等產品的市場需求不佳，導致供過於求及平均銷售單價（ASP）持續下滑；然而，顯示器產品的另一項關鍵零組件驅動IC（Driver IC）卻表現亮麗，像今年新上榜10大的奕力，就是一舉從排名16攀升至第9位的顯示器驅動IC業者。顯示器驅動IC亮眼的表現主要是歸功於智慧型手機及平板電腦市場去年的大幅成長，足以支撐整體產業的成長動能。

環視全球IC設計公司，顯示器驅動IC的廠商似乎都集中在台灣，在全球市場競爭業者的部分，主要是韓國Samsung（三星）及日本的（Renesas）瑞薩，但Renesas 在今年3月份已正式退出大尺寸顯示器驅動IC的市場，其大尺寸LCD客戶包括友達、Sharp （夏普）及Hitachi（日立）等，都會被台灣廠商瓜分，所以台灣顯示器驅動IC業者在2012年的市占率應可望提升。如果單從市場面來看，今年從第2季開始驅動IC的市場動能相當暢旺，因此奇景及奕力都在第2季紛紛調高財測。此外，聯詠在主要客戶宏達電的One系列手機帶動下，對市場也是相當樂觀。

就技術面而言，顯示器驅動IC的應用大概可劃分以下幾個類別：TFT-LCD、MSTN、CSTN、LTPS、PDP、OLED、Touch、3D，而台灣業者目前大都集中在TFT-LCD面板用的驅動IC，不過，就顯示器市場發展趨勢來看，觸控、OLED及3D會是很重要的未來技術發展趨勢，台灣的顯示器驅動IC業者也很清楚，像奕力本身就預測觸控IC於2012年會佔其營收比重逾10%；然而，技術研發及專利佈局上能否跟上市場腳步是很重要的關鍵。

表四是2011年台灣十大IC設計公司主要產品及專利競爭力一覽表，其中綠色的部分是顯示器驅動IC的供應商。由於顯示器驅動IC並不是聯發科及晨星業務的主力，因此在目前看起來這兩家業者也沒有特別針對OLED及LTPS此兩項顯示技術作專利佈局；然而，聯詠及奇景此2家專業驅動IC業者，則是觸控、OLED、3D及LTPS 等4大前瞻顯示技術領域均有著墨。可預見未來驅動IC雖然市場需求暢旺，但隨著越來越多業者（特別是台灣業者）加入戰場，價格競爭是在所難免的，如果要提升在市場上的競爭力，除了必須著重以上提到的前瞻性技術研發外，也可以注意功能整合的趨勢。像在中小尺寸面板產品的部分，已經有越來越多的源極（Source IC）和閘極驅動IC（Gate IC）整合成1顆系統單晶片（System on Chip, SoC）；而特別應用在智慧型手機及平板電腦的驅動IC為了提升面板解析度及增加影像資料傳輸速度，及同時支援即時的觸控面板功能，也會在晶片中內建SRAM，這些都是值得注意的整合趨勢。

表四．2011年台灣十大IC設計公司主要產品及專利競爭力一覽
排名	公司	主要產品	美國專利數	臺灣專利數	中國專利數
１	聯發科技 MediaTek	無線寬頻、行動通訊、數位多媒體晶片	1,159 （自Analog Device, Inc.取得之專利數為 34 ）	2,856 （觸控：18）（OLED：０）（三維：21）（低溫多晶矽：0）	1,967
	雷凌／Ralink （被聯發科併購）	有線及無線寬頻通訊網路設備	59	249	119
	Coresonic AB （被聯發科併購）	DSP	2
２	晨星半導體 MSTAR	液晶電視SoC解決方案	164	632 （觸控：19）（OLED：０）（三維：12）（低溫多晶矽：0）	539
３	聯詠 Novatek	顯示器驅動IC（以LCD為主，也有AMOLED、LED 應用面板）及SoC	288	1,026 （觸控：34）（OLED：4）（三維：10）（低溫多晶矽：13）	392
４	群聯 PHISON	NAND Flash控制晶片	117	330	392
５	瑞昱 Realtek	通訊IC	643	1742	647
６	奇景 Himax	面板驅動IC	465	1172 （觸控：19）（OLED：4）（三維：15）（低溫多晶矽：6）	512
７	立錡 Richtek	電源管理IC	193	565	208
８	創意 Global Unichip	IC設計服務、SOC	7	335	10
９	奕力 ILITEK	TFT-LCD面板驅動IC、電容式觸控IC	0	50 （觸控：0）（OLED：2）（三維：0）（低溫多晶矽：0）	33
１０	瑞鼎 Raydium	顯示器驅動IC	22	157 （觸控：22）（OLED：0）（三維：0）（低溫多晶矽：0）	118

資料來源：USPTO、TIPO、SIPO，製表：李淑蓮 2012年4月12日
註：美國及中國專利之數量為公告之數量，即已獲得核准之專利數；台灣專利數則為已公開之專利數。

高通、海思夾殺聯發科　大陸業者來勢洶洶不容忽視

台灣IC設計公司的龍頭聯發科技2011年之營收為914億新台幣，與前一年度相比衰退25％（註：此為聯發科財報資料之數據，與表一MIC之預估值略有出入），衰退的主因除了來自行動電話市場被大陸晶片業者搶食外，也因主要競爭對手Qualcomm帶頭削價競爭而導致ASP（平均銷售單價）嚴重下滑。

其實從競爭廠商去年及前年的業績成長中就不難看出端倪：Qualcomm 2011年成長了38.5%、海思及展訊2010年業績分別成長了13％及247％，此消彼長的趨勢相當明顯。過往在2G時代聯發科在行動電話市場的市占率很高，但隨著世代交替，2G已慢慢走入歷史；加上2G的專利很多都已過了專利保護期，所有業者均可生產，早已失去了市場利基。為了迎合市場需求之改變，聯發科在最近幾年也已全力在3G衝刺，但其在3G市場所面臨的競爭遠比在2G時期大很多。

聯發科於今年2月舉行的2011年第4季法說會中分析了公司各產品線之營收比重，分別是（1）手機占60%~65%、（2）光儲存占10%~15%、（3）數位家庭占15%~20%、及（4）網通產品7%~10%。從數據中可以明顯看出手機晶片的營業額占其營業比重是頗高的。另一方面，Qualcomm在3G及智慧型手機的龍頭地位已無法動搖，全球一線行動電話大廠幾乎都採用Qualcomm的解決方案，但Qualcomm為了進一步搶攻市場，不惜削價競爭，以延攬大陸二、三線手機及平板電腦廠商成為其客戶，導致聯發科也不得不跟著降價來迎戰。不過，雖然降價導致ASP下滑，但聯發科在出貨量的預估上卻很樂觀。去年第4季聯發科智慧型手機晶片之出貨量為600萬顆、預測2012年智慧型手機出貨量可達5,000萬顆，比之前預估的3,000萬顆大幅調升。這除了是由於對一般功能手機（Feature Phone）轉換到智慧型手機（Smart Phone）的趨勢樂觀之外，聯發科對他們一些雙核心、低功耗的新晶片產品也具有很大的信心。

其實除了Qualcomm外，大陸業者也是來勢洶洶。表五是大陸主要行動通訊IC設計公司之產品及專利競爭力的介紹，每家都來頭不小。其中海思半導體是大陸通訊大廠華為的關係企業，前身是華為內部的ASIC設計中心。華為一直希望能培養自己的晶片供應商，而市場上也有傳聞華為希望能藉由海思來「去高通化」。即替換產品中Qualcomm的WCDMA晶片，轉而採用海思生產的WCDMA晶片。據來自iSuppli的數據顯示，2009年中國市場的WCDMA數據卡出貨量約5000萬，其中華為一家的出貨量就超過3000萬，且幾乎全部採用Qualcomm的晶片；除了數據卡，下一步也可能會延伸至智慧型手機市場。雖然即便海思自行生產也要付Qualcomm權利金，但還是比向Qualcomm採購來得便宜，而且可以充份掌握貨源；另一方面海思也相當積極的研發自有解決方案。

表五．大陸行動通訊IC設計公司主要產品及專利競爭力一覽
公司	主要產品	美國專利數	中國專利數
海思半導體／HiSilicon （華爲之關係企業，前身為華爲ASIC設計中心）	無線網路、固定網路、數位媒體等領域的晶片及解決方案	0 （2004年以深圳市海思半導体有限公司名稱註冊前，專利均是以華爲名義申請）	12 （2004年以深圳市海思半導体有限公司名稱註冊前，專利均是以華爲名義申請）
展訊通信／Spreadtrum （美國NASDAQ上市公司）	行動通訊晶片	35 （其中11筆為收購美國射頻晶片公司Quorum Systems, Inc.獲得）	504
北京中電華大電子／CEC Huada Electronic Design （前身為北京集成电路设计中心）	Smart Card晶片、RFID晶片、WLAN晶片	0	172
聯芯科技／LEADCORE （大唐電信集團的關係企業）	行動通訊晶片	0	173

資料來源：USPTO、SIPO，製表：李淑蓮 2012年4月12日
註：美國及中國專利之數量均為公告之數量，即已獲得核准之專利數。

至於展訊通信則是在美國NASDAQ上市的大陸業者，目前已成功打入韓國大廠Samsung （三星）的供應鏈，Samsung去年9月在大陸推出的 GALAXY S II就採用了展訊的基頻及RF晶片。除此之外，展訊在2007年就成為了大陸通訊大廠中興通訊在TD-SCDMA領域的策略合作伙伴。在大陸市場TD的领域，本土廠商大唐集團既有做系統設備的大唐電信，又有做手機終端的大唐移動，對其發展相當有利，但反觀競爭對手中興通訊，之前是仰賴大唐移動及ADI提供的TD手機解決方案，情況相對不利，因此中興選擇和展訊合作；但對於從ADI收購專利企圖切入大陸TD市場的聯發科而言，卻不是好消息。此外，大陸晶片業者聯芯科技是大唐電信的關係企業，因此也不用擔心產品出路。

從以上市場發展狀況來看，聯發科在往後除了要面臨Qualcomm的市場競爭外，大陸後起的晶片業者也不容忽視。因目前聯發科有不少營收是來自大陸二、三線廠商，甚至是白牌廠商，所以除了要以高品質及差品差異化來作市場區隔外，也必須設法與一線大廠建立策略聯盟合作關係，才能讓市場地位更穩固。

People who looked at this item also looked at…

52RD與華強研究所聯合發佈3月2G晶片出貨資料

loda — Sat, 21 Apr 2012 17:47:45 +0000

52RD與華強研究所聯合發佈3月2G晶片出貨資料

http://www.52rd.com/S_TXT/2012_4/TXT34997.HTM

我愛研發網　
　2012年4月11日，華強電子研究所，半導體應用聯盟及52RD聯合發佈中國手機市場2G功能手機（Feature Phone）晶片出貨量統計。在經歷了連續幾月的衰減之後，2月份2G功能手機晶片出貨開始復蘇，3月晶片出貨量繼續增長，恢復到2011年約7，000萬/月的水準。

資料顯示，聯發科MTK出貨3900萬片，展訊出貨1500萬片，晨星與銳迪科出貨700萬片，四家主要的2G功能手機晶片共出貨6800萬片，較比2月份5200萬的出貨量上漲幅度超過30%；將2、3月的出貨與12月、1月對比，可以發現2、3月的出貨比之前上漲較多，尤其展訊、晨星和銳迪科，2月的出貨比2月的出貨上漲幅度深圳超過了100%，聯發科2月的出貨也較比1月稍有提高。
　　不過，由於3月出貨量較大，以及4月上半月的清明節和復活節影響出貨，預計4月份的出貨量會略有下降。另外，由於5月後市場2G手機市場進入淡季，因此後續前景並不明朗。艾為電子副總焦建堂點評說“3月2G可能漲了30%，主要集中在大公司出口海外！未來幾月海外2G不會下滑，大而不破音訊和大屏可能是亮點。3月形成一定庫存，需要消化，4月的銷量肯定會受到影響而下降。未來需要注意關注2G的3大平臺的變化。”

在3G智慧機大潮的衝擊下，2G功能機銷量一路下跌，隨之引起了2G功能機晶片的銷量跌滯，而在連續消沉之後，2、3月份略有回轉。華強電子產業研究所高級分析師劉輝稱，雖然3月市場總體出貨不錯，但出貨量進一步向那些面向海外市場的大公司集中，例如沃特沃德、輝燁和鴻宇等，其中輝燁在4月的出貨量超過了400萬。而由於國內市場正迅速轉入智慧手機加之國內2G市場處在清理庫存階段，因此面向國內2G市場的中小公司生意慘澹。產品形態方面，2G產品迅速向老人機和類智慧手機兩極分化，類智慧占總體2G量超過20%，預計未來將增長至30%左右。；劉輝同時表示，受到清明節和復活節放假影響4月出貨，5月後前景不明。輝燁通訊董事長翁偉民也表示：“4月總體會放緩很多，特別是上半月，節日多，要等下半月才會開始回暖。”
　　平臺方面，MTK穩守2G的市場份額，RDA的出貨量增長至700萬，但因為RDA將在Q2進行平臺切換，因此出貨量將持平，隨著RDA推出覆蓋從超低端到類智慧的8853系列，RDA、展訊和Mstar將在第三季度進行激烈的競爭。另外，臺灣另一家晶片公司MDV將在第二季度以超低價進入已經血腥的2G晶片市場，競爭將會變得更加慘烈。（Joyce Dong）

People who looked at this item also looked at…

10 hard truths developers must learn to accept

loda — Fri, 13 Apr 2012 16:10:00 +0000

10 hard truths developers must learn to accept

http://www.infoworld.com/d/application-development/10-hard-truths-developers-must-learn-accept-189620?page=0,0

From scope creep to bitrot to users with minds all their own, programming offers an array of bitter pills to swallow
By Peter Wayner | InfoWorld
Print|
On most days, programming is a rewarding experience, with no problem too challenging to solve. Perseverance, intuition, the right tool — they all come together seamlessly to produce elegant, beautiful code.
But then a botched deployment, yet another feature request, or a poorly documented update with crippling dependencies comes crashing headlong into the dream.
[ Find out which 11 programming trends are on the rise, verse yourself in the 12 programming mistakes to avoid, and test your programming smarts with our programming IQ tests: Round 1and Round 2 and Hello, world: Programming languages quiz. | Keep up on key application development insights with the Fatal Exception blog and Developer World newsletter. ]
Sure, we might wish our every effort had enduring impact, that the services our apps rely on would be rock-solid, that we would get the respect we deserve, if only from those who should know better. But the cold, harsh realities of programming get in the way.
That doesn’t mean the effort isn’t worth it. But it does mean we have some hard truths to face. Here are 10 aspects of programming developers must learn to live with.
Developer hard truth No. 1: It’s all just if-then-else statements
Language designers argue about closures, typing, and amazing abstractions, but in the end, it’s just clever packaging wrapped around good, old if-then-else statements.
That’s pretty much all the hardware offers. Yes, there are op codes for moving data in and out of memory and op codes for arithmetic, but the rest is branch or not branch based on some comparison.
Folks who dabble in artificial intelligence put a more mysterious cloak around these if-then-else statements, but at the end of the day, the clever statistical recommendation engine is going to choose the largest or smallest value from some matrix of numbers. It will perform calculations, then skim through the list, saying, "If this greater, else if this greater, else if this greater," until it derives its decision.
Developer hard truth No. 2: Most of the Web is just data stored in tables
For the past 20 years, the word "Internet" has tingled with the promise of fabulous wealth, better friendships, cheaper products, faster communication, and everything but a cure for cancer. Yet at its core, most of the Internet is a bunch of data stored in tables.
Match.com? A table of potential dates with columns filled with hair color, religion, and favorite dessert. eBay? It’s a table of deals with a column set to record the highest bid. Blogs? One table with one row for every cranky complaint. You name it; it’s a table.
We like to believe that the Internet is a mystic wizard with divine wisdom, but it’s closer to Bob Cratchit, the clerk from Charles Dickens’ "A Christmas Carol," recording data in big accounting books filled with columns. It’s an automated file clerk, not the invention of an electronic Gandalf or Dumbledore.

We see this in our programming languages. Ruby on Rails, one of the most popular comets to cross the Web, is a thin veneer over a database. Specify a global variable and Rails creates a column for you because it knows it’s all about building a table in a database.
Oh, and the big, big innovation that’s coming 20 years into the game is the realization that we don’t always need to fill up every column of the table. That’s NoSQL for you. It may try to pretend to be something other than a table, but it’s really a more enlightened table that accepts holes.
Developer hard truth No. 3: Users have minds of their own
You might think that the event listener you created for your program and labeled "save" has something to do with storing a copy of the program’s state to disk. In reality, users will see it as a magic button that will fix all of the mistakes in their ruined document, or a chance to add to their 401(k), something to click to open up the heavens and lead to life eternal.
In other words, we might like to think we’ve created the perfect machine, but the users beat us every time. For every bulletproof design we create to eliminate the chance of failure, they come up with one combination of clicks to send the machine crashing without storing anything on disk. For every elegant design, they find a way to swipe or click everything into oblivion.
There are moments when users can be charming, but for the most part, they are quirky and unpredictable — and can be very demanding. Programmers can try to guess how and where these peculiarities will arise when users are confronted with the end result of code, but they’ll probably fail. Most users aren’t programmers, and asking a programmer to think like the average user is like asking a cat to think like a dog.
This goes beyond simple cases of user stupidity. No matter how clever your invention or elegant your code, it still has to catch on. Predicting that users will not balk at a 140-character limit for expressing ire and desires is no easy business.
Developer hard truth No. 4: Most of what you code will never be used
Somehow it feels good to know that your new software can speak XML, CSV, and Aramaic. Excuse me; our implementation team would like to know if this can decode Mayan hieroglyphics because we might need that by the end of 2012. If it doesn’t have that feature, we’ll be OK, but it will be so much easier to get the purchase order signed if you could provide that. Thanks.
The users, of course, could care less. They want one button and even that one button can confuse them. The wonderful code you wrote to support the other N-1 buttons might get executed when the QA team comes through, but beyond that, there is no guarantee the sprints and all-nighters will have been anything more than busywork and bureaucracy.
Programmers don’t even get the same boost as artists, who can always count on selling a few copies of their work to their parents and relatives. Our parents won’t come through and run the extra code on the feature that just had to be implemented because someone in a brainstorm thought it would be a game changer.

Developer hard truth No. 5: Scope creep is inevitable
One manager I know told me his secret was to always smile and tell his team he loved what they were doing, even if it was terrible. Then on the way out the door, he would say, "Oh, one more thing." That thing was often a real curveball that upended the project and sent everyone back to redesigning the application.
Scope creep is almost a direct consequence of the structure of projects. The managers do all of the hard work with spreadsheets before it begins. They concoct big dreams and build economic models to justify the investment.
All the hard work ends once they bring in the developers. Suddenly the managers have nothing to do but fret. Is that button in the right space? Should the log-in page look different? And fretting leads to ideas and ideas lead to requests for changes.
They love to use phrases like "while you’re mucking around in there" or "while you’ve got the hood up." This is what happens to projects, and it’s been happening for years. After all, even Ada Lovelace’s analytical engine, considered by most to be the first computer program, endured its own form of scope creep, born of nearly a year spent augmenting notes.
Developer hard truth No. 6: No one understands you — especially the boss
There are two kinds of programmers: those who work for bosses who can’t program and don’t know how hard it can be to make your code compile, and those who work for former programmers who’ve forgotten how hard it can be to make your code compile.
Your boss will never understand you or your work. It’s understandable when the liberal arts major in business development gets an idea that you can’t solve without a clairvoyant computer chip. They couldn’t know better.
But the boss who has forgotten? That’s understandable, too. Even the best programmer forgets the API for a library after a month or two. Imagine going two or three years without flipping the bits. And then remember that when they went to school, the classes were about Java, not JavaScript. Even Ruby seems so yesterday.
This truth has one advantage: If the boss understood how to solve the problem, the boss would have stayed late one night and solved it. Hiring you and communicating with you is always more time consuming than doing it.
Developer hard truth No. 7: Privacy is a pain
We want our services to protect our users and their information. But we also want the sites to be simple to operate and responsive. The click depth — the number of clicks it takes to get to our destination — should be as shallow as possible.
The problem is that privacy means asking a few questions before letting someone dig deeper. Giving people control over the proliferation of information means adding more buttons to define what happens.
Privacy also means responsibility. If the user doesn’t want the server to know what’s going on, the user better take responsibility because the server is going to have trouble reading the user’s mind. Responsibility is a hassle and that means that privacy is a hassle.
Privacy can drive us into impossible logical binds. There are two competing desires: One is to be left alone, and the other is to be sent a marvelous message. One desire offers the blissful peace with no interruptions, and the other can bring an invitation or a love letter, a job offer, a dinner party, or just a free offer from your favorite store.

Alas, you can’t have one without the other. Fighting distractions will also drive off the party invitations. Hiding your email address means that the one person who wants to find you will be pulling out their hair looking for a way to contact you. In most cases, they’ll simply move on.
Developer hard truth No. 8: Trust isn’t cheap
The promise of Web 2.0 sounded wonderful. Just link your code to someone else’s and magic happens. Your code calls theirs, theirs calls yours, and the instructions dance together like Fred and Ginger.
If only it were that easy. First, you have to fill out all these forms before they let you use their code. In most cases, your lawyers will have a fit because the forms require you to sign away everything. What do you get in return? Hand-waving about how your code will maybe get a response from their code some of the time. Just trust us.
Who could blame them, really? You could be a spammer, a weirdo, or a thief who wants to leverage Web 2.0 power to work a scam. They have to trust you, too.
And the user gets to trust both of you. Privacy? Sure. Everyone promises to use the best practices and the highest-powered encryption software while sharing your information with everyone under the sun. Don’t worry.
The end result is often more work than you want to invest in a promise that kinda, sorta delivers.
Developer hard truth No. 9: Bitrot happens
When you start, you can grab the latest versions of the libraries and everything works for a week or two. Then version 1.0.2 of library A comes along, but it won’t work with the latest version of library B because A’s programmers have been stuck on the previous big release. Then the programmers working on C release some new feature that your boss really wants you to tap. Naturally it only works with version 1.0.2.
When houses and boats rot, they fall apart in one consistent way. When code rots, it falls apart in odd and complex ways. If you really want C, you have to give up B. If you choose B, you’ll have to tell your boss that C isn’t a real option.
This example used only three libraries. Real projects use a dozen or more, and the problems grow exponentially. To make matters worse, the rot doesn’t always present itself immediately. Sometimes it seems like the problem is only in one unimportant corner that can be coded around. But often this tiny incompatibility festers and the termites eat their way through everything until it all collapses.
The presence of bitrot is made all the more amazing by the fact that computer code doesn’t wear out. There are no moving parts, no friction, no oxidation, and no carbon chains acting as bait for microbes. Our code is an eternal statement that should be just as good in 100 years as it was on the day it was written. Yet it isn’t.
The only bright spots are the emulators that allow us to run that old Commodore 64 or Atari code again and again. They’re wonderful museums that keep code running forever — as long as you fight the bitrot in the emulator.
Developer hard truth No. 10: The walled garden will flourish
For all the talk about the importance of openness, there’s more and more evidence that only a small part of the marketplace wants it. To make things worse, they’re often not as willing to pay for the extra privilege. The free software advocates want free as in speech and free as in beer. Few are willing to pay much for it.
That may be why the biggest adopters of Linux and BSD come wrapped in proprietary code. Devices like TiVo may have Linux buried inside, but the interface that makes them great isn’t open. The same goes for the Mac.

The companies that ship Linux boxes, however, have trouble competing against Windows boxes. Why pay about the same price for Linux when you can buy a Windows machine and install Linux alongside?
Walled gardens flourish when people will pay more for what’s inside, and we’re seeing more and more examples of cases when the people will pay the price of admission. Mac laptops may cost two to three times as much as a commodity PC, yet the stores are packed to the limit imposed by the fire code.
The walls are getting thicker. At the launch of the third iPad, Apple bragged about shipping millions and millions of post-PC devices. Deep inside an iPhone is an open source operating system, but only a tiny percentage of customers even know this. Until people know and care about this features, walled gardens will thrive.

讓你程式設計得到昇華：開發者需知的十個真理

http://sd.csdn.net/a/20120406/2804285.html

【CSDN編譯】程式設計是一種有益的體驗方式，當遇到挑戰時，我們會不斷尋求新的解決方法。也許你會認為將毅力、直覺、適宜的工具三個組合在一起即可編寫出優雅、完美的代碼。然而，隨之而來的拙劣的部署或另一種功能需求亦或者是沉重的依賴關係會產生不良的反覆運算更新，等等這些突發狀況會摧毀了你最初的夢想。我們希望每次的努力付出能夠有著深遠的影響，希望我們的應用程式所依賴的伺服器如同磐石一樣，然而程式設計的獲取方式卻是殘酷的。這並不意味著你所有的努力都是有價值的。相反，我們應該學會如何面對這些殘酷的事實。一起看下文中羅列出的10條實踐真理，或許能為你的工作帶來一絲幫助。
1. 如果這一切只是if-then-else語句
開發者往往會因封存（closures）、位元組（typing）和抽象化(amazing abstractions)而爭論不休，最終會選擇 old if-then-else statements，這幾乎是所有開發者的需求，包括輸入輸出記憶體移動資料的操作代碼和演算法操作代碼。剩下的便是將分支或非分支兩者之間進行比較。
圍繞if-then-else statements，開發者們開始為其添加一些奇妙的虛偽的外表，但在最後，聰明的統計推薦引擎會在矩陣的陣列清單中選出的最大值或是最小值，該引擎通過執行計算流覽所有的列表，直到你作出最後選擇，否則它會一直提示你“這是最大值嗎，這是最大值嗎？”
2. 大多數Web網頁將資料存儲在表單中
在過去的20年裡，互聯網世界帶來了神話般的財富，更好的友誼，更便宜的產品，更快的通信等等。究其核心，大部分互聯網將資料存儲在表單中。
Match.com？表單裡包含著各種資訊，比如頭髮顏色，宗教信仰和鍾愛的食品。eBay？這個列表收集了最高價的項目列表。Blogs？字裡行間記錄了每一個投訴。OK，我們將其命名為table。我們有理由相信互相網是一個神秘的且充滿智慧的地兒，它是一個自動化的檔檔“辦事員”。
從程式設計語言來看，Ruby on Rails這個貫穿Web開發最流行的語言之一，是一個資料庫框架。你只需要指定一個全域的變數和Rails就可為你創建一個列表，因為它熟悉所有創建表單的資料庫表。
還有一個， NoSQL非關聯式的資料庫。現今的電腦體系結構在資料存儲方面要求具備龐大的水準擴展性，而NoSQL致力於改變這一現狀。目前Google的BigTable和Amazon 的Dynamo使用的就是NoSQL型資料庫。
3. 用戶有自己的主見
如果你想為語言和labeled“save”創建event listener監聽事件，將程式拷貝到磁片上。在現實中，用戶會期待看到一個神奇的按鈕，在自己損壞的檔中修復所有的錯誤或添加到401(k)中，點擊打開並永遠保存下來。
或許，用戶還會這樣想，我們創造了一個完美的機器，每當用戶打開時，每一個設計都是萬無一失的，避免出現任何一個故障。他們設想可以點擊發送並未存儲在磁片上的資料。所有這些完美的設計，他們想通過一種方式來點擊任何被他們所遺忘的東西。
有時，使用者是通情達理的，但在大多數情況下，他們是非常苛刻的，行為較為古怪。程式師嘗試著去猜測他們的想法，當以最終的代碼結果呈現在用戶面前時，他們會是怎樣的？結果還是失敗了。因為大多數用戶不是程式師，他們要求程式師像普通用戶的那樣思考問題就如同要求一隻貓像一隻狗那樣思考一樣，這根本就不符合邏輯思維。
不管你如何發明智慧的或設計出優雅的代碼，用戶不會按照你的想法來看待問題。因為他們不會用140個字元限制來表達他們的憤怒和欲望。
4. 部分代碼永遠不會被使用
你的工具是否支援XML，CSV，Aramaic。我們的操作團隊能否解析瑪雅象形文字，也許在2012年年底有這方面的需求，如果不具備該功能，ok，如果你能提供此項功能，將會獲得更多的專案訂單。
當然，用戶不用關心太多，他們只想要一個按鈕，這個按鈕甚至可以把他們混淆了。這個完美的代碼當你在編譯時能夠支援N-1按鈕，在QA團隊中能夠很好的被執行。
程式師不像藝術家，他們可以指望自己的父母或者親戚能為其帶來某些業績，而我們的父母不會通過執行代碼來測試性能。
5. 項目發生變化不可避免
一位經理人曾告訴我有關他的秘密，他總是面帶微笑並告知他的團隊，他很熱愛他們所作的事情即便是有危險的，在他走出門的那一刻，他會說“哦，還有一件事”。那個弧線球部分覆蓋了該專案，並要求大家重新設計應用程式。意思說作為一名管理者首先你得肯定團隊的工作能力。
專案範圍的擴張程度直接體現了這個專案結構的最終成果。經理人總是使出全身解數來清算報表，首先他們構思出一個偉大的夢想，建立一個經濟結構模型來證明他們需要多少投資預算。
開發者們辛勤付出後，將勞動成果呈現在經理人面前，你的經理人什麼也沒做反而擔心：這個按鈕是在正確的位置嗎？日誌頁面看起來有什麼不同之處？即便是輕微的意見，它也改變了我們最初的需求，不是嗎？
6. 沒人理解你——尤其是老闆
有兩種程式師：一個是按照老闆指定的計畫進行工作，沒有任何計畫，也不知道如何努力編寫代碼；另一種是以程式師方式全身心的投入工作，努力編寫出色的代碼。
你的老闆永遠不會理解你或者你的工作，他們關注的是當業務發展遇到瓶頸時刻時你能否給出一個出色的解決方案，而不是你解決了電腦晶片等某種問題。
如果你的老闆知道如何解決問題，他會留下來並將問題解決。因為他知道與你交流，刨根問底要比實際操作花費的時間要多的多。
7. 隱私權是一種痛苦
我們希望我們的服務能夠保護使用者以及他們的資訊（隱私問題），同時又希望網站能夠簡潔易操作，我們希望能用最少的點擊數來達到使用者想要的目的。
隱私意味著你要多挖掘幾個問題，這樣才能確保控制資訊擴散，然而這樣也就意味著我們需要有更多的點擊數。隱私也體現出一種責任，如果用戶不希望伺服器知道他們過多的隱私，而伺服器又無法讀取用戶的想法，怎麼辦呢？所以說，責任是一種麻煩，隱私也是件麻煩事。
當然，它也有有利的一面，比如說根據你的喜好，網站可以自動提供連結，讓你隨心所欲買到自己喜歡的物品，當你有需求時可以為你提供幫助。
8. 與他人建立信任
Web 2.0的誕生，豐富了人們的生活，這種新的互聯網方式，通過網路應用 (Web Applications）促進網路上人與人間的資訊交換和協同合作，其模式更加以使用者為中心。因此，你只需將代碼連結給某人，就會有奇跡發生了，你的代碼會被調用。
首先，在別人使用你的代碼前，請先填好這些協定，在多數情況下，該協定會要求你放棄一切，那麼你會得到什麼回報呢？其次，和使用者建立信任，在基於該協定下每個人都會承諾最佳的實踐方法和最高的加密軟體來分享你的資訊。因此，不用擔心你的代碼會被竊取。
最終的結果會比你預期的要好的多，比如會給你提供更多的工作。期待好運降臨吧。
9. 當代碼遭遇腐爛
當你啟動任務時，你可以獲取最新版本庫，利用這些庫來工作一至兩周，那麼將誕生library1.0.2版本，當然你不會使用library B最新版本，因為使用A版本的程式師已經更新了新版本，這時你的老闆還會要求你在C版本的基礎上開發出一些新的功能，當然只適用於1.0.2.版本。
打個比方，當房子和船要腐爛時，他們會以統一的方式腐爛。很多團隊都有這個問題，一個專案的代碼本來開始設計得好好的，一段時間以後，代碼就會變得難以理解，難以維護，難以修改。為什麼呢？因為代碼的腐爛都是由於沒有深入理解的情況下修改別人的代碼導致的。如何防止代碼腐爛？參見這裡。
如果你想要C，那麼必要放棄B。如果你選擇B，那麼你就必需要告訴你的老闆C是不正確的選擇。
我們以3個庫為例，但在實際項目中會有十幾個甚至更多的選項，問題也會隨之成倍的增長。更糟糕的是，腐爛不會立即呈現。有時隱藏在某個角落裡，看起來是個不起眼的問題，時間久了就會感染到整個代碼。正是這細小的不相容的代碼會毀掉整個系統。
我們應該讓代碼像諺語一樣即使是在100年後依然完整無缺。
10. 開源世界茁壯成長
越來越多的資料表明開源的重要性，目前，開源只有一小部分市場，極少部分人願意將代碼貢獻給開源社區。
這也許就是Linux和BSD代碼的最大貢獻者們轉為封閉私有代碼的原因。像TiVo這樣的設備也許會使用Linux作為內核，但絢麗的交互介面卻不是開源的，Mac也同樣如此。
近日，Linux boxes與Windows boxes之間的競爭陷入了困局。很多人都在質疑：花一樣的錢，既然能夠買到一個可以安裝Linux的Windows機器，為什麼還去買Linux呢？Mac筆記本的價格是普通PC的2至3倍等等這種案例很多越多。然而只有極少部分人知道，iPhone也是一款開源作業系統。
我想，只有人們不斷的去關注開源哪怕只是細微的性能部分，開源世界才會茁壯成長。

People who looked at this item also looked at…

費傑：產品經理心態解說—開放的心態

loda — Fri, 13 Apr 2012 16:09:59 +0000

費傑：產品經理心態解說—開放的心態

http://www.52rd.com/Blog/Detail_RD.Blog_yweixue_30293.html

大家做產品的，都知道產品經理需要具備“溝通、執行、決斷、學習”等能力。過了一段快速的技能成長期後，慢慢的再往後，其實你會發現，當你試圖再想提高這些所謂的能力時，越來越難了。 yixieshi
　　很多人到後面幾乎覺得自己到頂了，其實這個現象背後的真正原因是：“心態不長、心智不長”。說的白一點，練千斤力的後面註定也就是一武夫，大凡大家都是內練一口氣，外練經、骨、皮。千斤力-取決於你的肌肉和骨骼，力取之力歇。而氣、力的結合則是無窮無盡。 yixieshi
　　五年以後，我明顯得感覺到很多產品經理、很多職業道路上的人，慢慢的出現了2級分化的現象。很多人在挑戰自己，很多人還活在自己的世界裡稱王稱霸。所以人與人的分水嶺除了周圍的資源差異以外，更大的在於一個人“心態”了。互聯網的一些事
　　所以，很多時候我們越來越難，其實是因為我們一直苦練絕技，但欠修佛法。修行修心，回歸到事物本源，萬事萬物折射的還是你的對待人生、對待生活的態度。最近“開放”一詞一直縈繞耳邊，故，今天也談談。 yixieshi
　　近半年來，我一直回顧我以前，在很多事情上顯得心態不是很開放。 yixieshi
　　第一個事，我會發現我不懂得欣賞別人，我不太喜歡公司往我們的部分，插一個比我能力強的產品經理。我比較敏感，我無形中會覺得沒有安全感。我甚至會想：“他會不會把我的飯碗搶掉?”，也甚至會想：“是不是老大們，覺得我做產品不行，對我不重要了?”，另外我可能對這個人還會產生妒忌、排斥。有了這些心態以後，自然磨合的過程有一些想法，有一些難過的。
互聯網的一些事
　　第二個事，我會發現我很難接受別人的觀點，不管是同事、朋友、家人對我的建議還是批評、觀點，我都不太喜歡聽，我都覺得是對的。特別是我作為產品經理，設計的一些東西，誰說我做的不好，我就跟誰紅著臉急。我心裡就認為是對的，誰也不要跟我唧唧歪歪。我很在乎別人說我啥，其實往往越在乎的。越顯得自己放不開。一些事
　　第三個事，只喜歡自己喜歡的人在一起交流，認為我們是一派，他們是一派，不想和他們交流。特別是碰到掛著使用者體驗設計牌子的產品經理，覺得自己是做大系統、大產品的，對此不屑一顧，並且從心裡面把他們鄙視到底。不能很開放的和很多交流，不和做市場的人交流、也不和做運營的人交流、不和技術做交流，我甚至不知道我當時沉浸的“享受”，是一個真正產品經理的“成就感”麼?現在看來肯定不是的，那肯定是偏激的。 yixieshi
　　第四個事，我的視野不想開闊，我只關注互聯網、產品經理，我天天看這個網站、那個網站、互聯網的新聞、產品經理的新聞，那會覺得我這輩子就是它了，我關注這些就夠了。可是我慢慢的發現，互聯網不是孤立的互聯網，產品經理不是一個詞可以定義的產品經理，你想要做的好就得要關注經濟，關注行業的轉移和衍升，產品經理只會說理論、喊口號，不僅很初級，而且在公司裡肯定活不下去。一些事
　　第五個事，我覺得我不夠開放。大家混圈子嘛，誰要是在我產品經理QQ群裡把人拉出去，我肯定把他T掉，然後發誓和他老死不相往來，08年還是09年那會，確實幹過幾次這樣的事情。另外不夠開放也顯得不夠信任別人，很多時候非要把自己當監工，拿別人幹活，自己非要盯著，要不睡不著覺啊!(新少林寺臺詞)，
一些事
　　其實仔細想想，因為我不夠開放，做事情多多少少做的很差水，也不知道這一路過來周圍的這麼多人居然是如此的包容我，有點慚愧。所以路寬路窄都是人自己走的，取決於你的心態，你對待事物、對待人生、對待生活的態度。 yixieshi
　　心態不開放的人，我想大概有以下這些特徵：互聯網的一些事
　　1)無知—不知道，還不知道什麼是開放，還是不開放的地步; 互聯網的一些事
　　2)自我—在自己的世界，固守自己世界裡的很多東西; 互聯網的一些事
　　3)小肚—把大肚能容，容天下事當口號來喊，生活中根本不是那麼回事;
一些事
　　4)固執—不知道對錯，總認為自己對的，不太接受新鮮事物、新的理論、觀點 yixieshi
　　5)浮躁—不夠誠懇、不能敞開心扉互聯網的一些事
　　最近在上海金茂大廈搞了一次沙龍，場地是新浪支持的，沙龍結束，我回到杭州很多朋友就給我回饋很好，他們說：“恩，很不錯，通過這麼樣的一次活動，讓我們開闊了很多眼界，我聽A說的時候，我發現他的思路是我不曾有的，我覺得我也可以往這方面靠一下，我聽B說的時候，雖然他這方面說的一般，但那麼方面我覺得我現有的知識還不錯，我找到了我的努力方面”，也有朋友跟我說：“今天挺高興的，雖然沒聽到什麼乾貨，但我認識了這麼多人，互通有無，還找到幾個合得來的朋友，後面還有深入交流的機會，真的挺好”，似乎看起來大家都挺有收穫的。互聯網的一些事
　　但也幾個朋友開罵：“媽的，搞什麼沙龍，嘉賓又不是最高端的，分享的乾貨也不是最幹的，我大老遠跑過來你們場地也沒有搞搞好好的。“也有不理解的問：”為啥要走ucdchina的老路?“我淡淡一笑，其實我覺得大家自所以這麼說，都是因為真誠，真誠的把想法回饋出來，我覺得挺好的。但可以很明顯的看出，大家的心態、角度是不一樣的。正如我上面自己舉的例子一樣，大家都有這麼一個不自知的過程。等你走過了，你就明白了。一些事
　　開放的心態是啥?其實很簡單，開放的心態就是：你老老實實的把架子放下、把虛榮、面子、浮躁放下，撣掉你心扉上的灰，將心靈的窗戶打開。老老實實的讓外面更多新鮮的空氣流進來，帶動你迴圈更多的血液。 yixieshi
　　把心打開，把心靈的窗戶打開，讓你走出思維的一畝三分地，看得更遠一些，交換的資訊更多一點，知道學到的得更多一點，看一些事情更平淡、更理性一些。這樣你才會接受更多的建議和批評，這樣你會擁有更多、更堅信更堅定。一些事
　　不知道做產品經理的各位，大家的心態開放麼?

People who looked at this item also looked at…

會見比爾•蓋茨——改變開源軟體的人

loda — Fri, 13 Apr 2012 16:09:54 +0000

會見比爾•蓋茨——改變開源軟體的人

http://www.enet.com.cn/article/2012/0210/A20120210965084.shtml

來源：CNbeta
【文章摘要】“就個人而言，我認為微軟在開源歷史上的序幕已經拉開。但我們需要看到他們對於開源更多的貢獻，以確認他們是開源的朋友。”
　　微軟的改變，很大一部分是因為世界改變了。“沒有什麼比一個垂死之人的想法更有力量了”Ramji引用了維克多•雨果的話。但隨後，他用了一個很貼切的說法“雲服務就像是開源巧克力上的花生醬。”“就個人而言，我認為微軟在開源歷史上的序幕已經拉開。但我們需要看到他們對於開源更多的貢獻，以確認他們是開源的朋友。”
　　會見比爾•蓋茨——改變開源軟體的人
會議是在比爾•蓋茨從微軟退休的前一個星期進行的，話題是關於開源軟體。

　　那是2008年的夏天，多年來，開源社區一直把微軟視作頭號公敵。7年前，微軟CEO史蒂夫•鮑默爾曾把Linux比作“惡性腫瘤”，之前一個夏天，微軟的首席法律顧問Brad Smith和授權行政官Horacio Gutierrez告訴《財富》雜誌，說Linux侵犯了他們235項專利，這意味著，在不久的將來，所有使用開源系統的大型公司將被收取特許權使用費。

　　但與此同時，微軟也意識到了自由軟體運動是多麼強大，公司想探索出新的方法，能與開源社區裡日益增長的開發者和諧相處。兩年來，Sam Ramji作為微軟開源戰略的負責人，每隔三個月就要會見比爾•蓋茨和其他高管，並同微軟的幾個工程師組成的小團隊一起向他們展示合成的各種開源技術。

　　那個下午卻與以往不同。在公司首席法律顧問中心Smith和Gutierrez的邀請下，Ramji、蓋茨、首席軟體架構師Ray Oizzie和其他一些人坐在一起，探討微軟是否應該真正開始使用開源軟體。Ramji和Oizzie持有相同的看法，即堅持認為微軟應當擁抱開源，Gutierrez也提供了一個法律框架使得這個提議成為可能。但是其它高管都強烈的質疑了這個想法。

　　這個時候，比爾•蓋茨站起來。

　　他走到白板前，畫了一個圖表，從版權到代碼貢獻再到專利，一一展示了這個提議的可操作性，接著他說（毫不含糊其詞）公司必須走出這一步。

　　對於Ramiji（他在微軟擔任首席開源戰略師逾三年半時間）來說，比爾•蓋茨站起來的一刻，就是微軟與自由軟體的關係轉危為安的時刻。“開源社區的人或者任何一個高科技產業的人對他在這些問題上幾乎沒有信任——即真正理解開源，知道它為什麼如此重要，它如何可以成為一個競爭優勢，或者，為什麼當競爭對手開始使用它的時候，你也必須要。但是他真的理解了，在那一刻，他告訴了我們所有人。”　

　　從外界看來，微軟和開源的關係確實轉危為安了。公司目前在它的Windows Azure（是由微軟所發展的一套雲端運算作業系統，用來提供雲端線上服務所需要的作業系統與基礎儲存和管理的平臺，是微軟雲端連算的核心組成元件之一）上增設了兩個開源平臺，並且，微軟也確實為一些項目提供了開原始程式碼。這些都不是小的開源專案，而是一些大牌項目，像Node.js和Hadoop。這在以前是不可能發生的事情。

　　微軟的改變，Sam Ramji和雇傭他的Bill Hilf 功不可沒，更不用說比爾•蓋茨了。這個改變也反映了高科技領域裡的大動作。隨著越來越多的應用從當地資料中心轉移到“雲端”服務，像亞馬遜網路服務（Amazon Web Services），當然，還有Microsoft Azure上面，軟體經濟也發生了轉向。過去，人們通過向微軟這樣的軟體供應商購買軟體，然後安裝在自己的設備上。現在，人們變成向線上服務支付費用了。通過在Azure上面提供開源軟體，微軟有了清晰的路子來掙錢。

　　“有了Azure，我們從計算、儲存和寬頻上掙錢”Hilf說，他現在負責Azure。“我們想盡全力提供盡可能多的各種類型的應用和系統，這樣就可以説明飛輪運轉起來……我們沒有把Azure上面的Node.js當做一個公益性的東西，我們將它視作一個推動業務的方式。”

“這個星球上的第一個宇航員”

　　Bill Hilf是一個用Linux的傢伙。在本世紀初，作為IBM的高級架構師，他曾使用Linux和其它一些開源軟體建立了公司的基礎設施，最終被藍色巨人（IBM公司的綽號,因其產品皆取藍色故）挖掘出來，以監督公司的所有開源策略。在90年代末，IBM曾下巨大賭注在Linux上，作為一種與微軟爭奪世界的方式。然後，在2004年，Hilf接到了他死對頭的電話。

　　“微軟打來電話，然後說：‘我們對這開源的東西不懂，需要一個懂的人’”Hilf回憶道，“我就像這個星球上的第一個宇航員那樣。”

　　他的主要任務，至少在最初階段，就是教別人。“我花費了很多時間，僅僅是讓他們知道開源的過程是怎樣的：開源是怎樣工作的？社區軟體在互聯網上如何工作？開源協議有什麼作用？那些人真的是免費工作的嗎？”但同時，他也幫著在微軟內部建立了一個開源實驗室，他和他的同伴在運行Windows軟體的匯接機（tandem machines）編譯和運行Linux系統。對於一個長期渴望避開Samba項目（一個開源方面的項目，使得Windows桌面可以同Linux檔案伺服器進行互動，而不僅僅是和Windows伺服器進行互動）的公司來說，這是一個非常重大的承諾。

　　“微軟打來電話說，我們對開源的東西不懂，需要一個懂的人。我就像這個星球上的第一個宇航員那樣。”

　　與此同時，Hilf的實驗室將探索出新的微軟專案，擴充已有的開源項目。在工作進行到即將收尾的階段，他開始接觸開源社區裡的成員。“我們想要瞭解可以跟開源的合作方式，不僅僅是學習它是如何工作以及看看我們能否與它相容，更重要的是尋找到我們真正能夠追求開源的那些領域。”他說。

　　這些想法，Hilf說，使得微軟參與了Node.js和Hadoop項目。去年，微軟不僅宣佈將引入Node和Hadoop（兩個都是Linux技術）專案，還宣佈其將為開源社區貢獻代碼。

　　“我們有一個專業的團隊為這個專案工作，我們做的是實際工程的工作”Hilf說，“然後，我們正在做這項工作，並讓讓它們在開源的許可下進行，通過像Github（一個分散式的版本控制系統，最初由Linus Torvalds編寫，用作Linux內核代碼的管理）進行分發。這在六年前是根本不可能的事情。”

　　這個秋天，微軟甚至為Samba貢獻了代碼。“幾年前，從微軟的編碼器提交一個補丁都是令人難以置信的事情，但戰鬥大多已經過去，時代已經改變” Christopher Hertel和他的Samba專案組同事一同寫到。

　　“許多人甚至都沒有察覺到這個貢獻源。這就是四十年左右的時間裡，事情所經歷的改變……但我們把它看作是一個里程碑，想藉以此感謝這個補丁和我們所見證的改變。”

　　在一個公司發展到最好的時候，被嚇壞了

　　這是一條漫漫長路。在2006年的時候，當Hilf把Sam Ramji招至門下接管微軟的開源專案的時候，公司和自由軟體的關係仍舊很緊張。一年之後，Brad Smith 和Horacio Gutierrez在《財富》頁面上對Linux社區造成了明顯的威脅。而當Ramji被雇傭到微軟去負責他們的開源專案的時候，如他自己幾年後所承認的那樣，他當時對自己的角色感到懷疑——並且感到有點害怕。

　　有起必有伏。但是Ramji與比爾•蓋茨的會見意味著大變化最終還是發生了。會議召開後不久，微軟就收購了一家名為Powerset的公司，這家公司是一家語義搜索公司，是最早在Hadoop上運行網路服務的公司之一。很快，微軟就允許Powerset的工程師繼續向開源項目提供代碼。不久，這項在海量伺服器上運算資料的語義搜索服務繼續在Hadoop上面運行。在某種程度上，這個專案放棄了這項技術並且把服務轉至微軟軟體上，至少，主要的開源貢獻源之一離開了公司。但Powerset至少在正確的方向上邁出了一步。

　　接下來的一年，Ramji和他的團隊開發了一個類似于亞馬遜那樣的雲服務，用的全是開源軟體，像Zend、OpenNebula、Eucalyptus、OpenScale和Hadoop等。“我們就像一個β中隊”Ramji回憶道，“我們就像來測試大家的一個突擊隊，我們會說，你以為你很前衛嗎？給我們這些聰明的Linux傢伙兩個星期的時間，讓我們來告訴你開源能做什麼。”

　　對於Ramji來說，這個項目在微軟的智囊團裡面引起了“深不適”。公司已經使用專有技術建立了Azure（代號是紅狗）。但對Ramji而言，深不適卻是件好事情。“微軟在發展到最好的時候，被嚇壞了”他說，“但這恰恰是這個公司的靈魂，這是一個以危機為導向的公司。”

　　微軟變成了穀歌

　　Ramji在2009年離開了微軟，參與建立一個叫Apigee的項目，按照他所說的，這個項目是為了處理今天相當於早期開源運動所要處理的問題：即通過應用程式設計發展介面或API來整合世界的網路服務。但他在雷德蒙德（美國華盛頓州城市，微軟總部）留下了一個標誌，即這樣的開源雲項目已經達到了預期。

　　“我覺得我們所建立的那個團隊是我合作過的最好的一個團隊”Ramji說，“我們真的有這樣的信仰和使命，即我們必須讓世界走進來。在這個世界上，如果我們閉門造車，我們可能贏得了微軟迷的喝彩，但我們必將停滯不前。”我們的團隊正是帶著這樣的信仰，影響了整個公司。

　　Azure仍然在微軟專有的軟體上面運行。但讓大家感到驚喜的是，這項服務給開發者提供了大量的開源工具，使他們能夠用來開發自己的應用，這些開源工具不僅僅包括像Node和Hadoop這樣的開源軟體，還有像Java和PHP這樣的開來源語言。公司甚至宣稱，將來他們將允許開發者在這項服務上面運行Linux。

　　Ramji承認，微軟的改變，很大一部分是因為世界改變了。“沒有什麼比一個垂死之人的想法更有力量了”Ramji引用了維克多•雨果的話。但隨後，他用了一個很貼切的說法“雲服務就像是開源巧克力上的花生醬。”

　　“就個人而言，我認為微軟在開源歷史上的序幕已經拉開。但我們需要看到他們對於開源更多的貢獻，以確認他們是開源的朋友。”

　　但是微軟作為開源的敵人是一段很長的歷史，很多人都對它是否真的改變了態度表示懷疑。“就個人而言，我認為微軟在開源歷史上的序幕已經拉開。” Ron Schnell說道，他是開源的一個長期使用者，在技術委員會負責監督微軟在2001年輸掉反壟斷大案之後與美國政府達成的協議，“但我們需要看到他們對於開源更多的貢獻，以確認他們是開源的朋友。”

　　最後，Schnell說，一切都是為了金錢。“開源解決方案一般不看財務狀況表。問題是，雲計算可預見的成功將會大量減少對Windows這樣的桌面作業系統的需要，微軟還能像以前那樣看到巨大的利潤嗎？”這就是問題所在。但是在雲計算上的動作將毫無疑問地使得用開源軟體來製作一份充滿誘惑的財務狀況表變得更加簡單。很顯然，微軟深諳這個道理。

　　多年來，稱讚穀歌是開源的一個朋友而批評微軟跟自由軟體保持距離是件極其容易的事。同樣作為網路服務商，穀歌跟微軟處在不同的位置上，穀歌是靠銷售打包代碼達到今天的高度。今天，微軟同樣成了一個網路公司。它在許多地方越來越像穀歌。

　　是的，微軟正向一些出售運行著android系統（一個基於Linux的作業系統）設備的公司收取特許權使用費。這表明微軟在世界上的位置變得複雜起來。雖然它正向網路靠近，但它仍然更像是一個靠賣軟體來掙錢的公司——而且依然熱衷於保護這種方式。但這些戰鬥通常不是看起來那樣。安卓（Android）並不是一個完全意義上的穀歌項目。

　　世界並不是非白即黑。更不是軟體的天下。不是每個人都意識到了這一點，但起碼比爾•蓋茨意識到了。微軟更加意識到了。

Loda's blog

ARM的商業模式是如何煉成的？

People who looked at this item also looked at…

Related items

中國出產拇指大小的Android 4.0電腦 售價500元人民幣

People who looked at this item also looked at…

Related items

LLVM (Low Level Virtual Machine) 筆記

People who looked at this item also looked at…

Related items

晶片業的獵食者AMD：恢復海盜的心態

People who looked at this item also looked at…

Related items

[笑話] 給程式設計師的笑話

People who looked at this item also looked at…

Related items

Oracle v. Google – What’s the Deal With the Java Specification License?

People who looked at this item also looked at…

Related items

HP大中華區總裁 / 孫振耀 退休感言

People who looked at this item also looked at…

Related items

[笑話] 給程式設計師的笑話

People who looked at this item also looked at…

Related items

我最喜歡的10條程式設計語錄

People who looked at this item also looked at…

Related items

Type ‘Zerg Rush’ Into Google for a Pleasant Surprise

People who looked at this item also looked at…

Related items

Open Sourcers Drop Software Religion for Common Sense

People who looked at this item also looked at…

Related items

IC設計業風起雲湧,大陸業者來勢洶洶 小心豬羊變色

People who looked at this item also looked at…

Related items

52RD與華強研究所聯合發佈3月2G晶片出貨資料

People who looked at this item also looked at…

Related items

10 hard truths developers must learn to accept

People who looked at this item also looked at…

Related items

費傑 ：產品經理心態解說—開放的心態

People who looked at this item also looked at…

Related items

會見比爾•蓋茨——改變開源軟體的人

People who looked at this item also looked at…

Related items

中國出產拇指大小的Android 4.0電腦售價500元人民幣

HP大中華區總裁 / 孫振耀退休感言

IC設計業風起雲湧,大陸業者來勢洶洶　小心豬羊變色

費傑：產品經理心態解說—開放的心態