讀<王垠:一種新的操做系統設計>

十年前的你和十年前的我

對於以前的文章,我很高興你能看到,而且在你的博客中對以前的文章作了相應的修訂和擴充(雖然我以爲這只是這些觀點變得愈來愈離譜)!

你以爲這是十年前你的思想(言外之意是這些言論是陳舊的,迂腐的,你想的比任何人都高遠),可是要說經歷,或許我徹底跟你相反, 總的來講:我以爲你或許是從實用主義成長爲理想主義,而我,則從理想主義退化成實用主義!

若是要給本身貼標籤,我以爲是一個Java程序員,過去很長一段時間裏我習慣用Java的思惟去思考問題,對於底層的實際的東西老是充滿不屑;

幾年前,在我徹底不瞭解"計算機是怎麼一回事兒"的時候,就開始幻想你文章寫的那些不切實際的東西! 我甚至跟朋友討論過如何將Java虛擬機改"裝成一個操做系統",個人想法是面向用戶的,是面向如何讓用戶更簡單的跟計算機交流的,我認爲Java程序員不須要負責底層東西,好比在分佈式環境下,程序員不須要關心計算被具體安排到哪些節點運行,不須要知道在哪一個地方存儲,什麼時候被同步到外存,不須要出現錯誤以後手動恢復...,不須要擔憂除業務以外的任何問題!環境提供這樣的能力,就像進程調度同樣,任務被在合適的時間的指派到空閒的節點,數據自動的被同步到合適的存儲....

堂而皇之的總結一下其核心"哲學"是:咱們是主人,計算機是僕人,只須要對他下命令;咱們是上帝,能夠簡單的控制一切!

這是我犯過的錯誤,因此看到你的"11條設計"就特別有感觸,在別人身上看到本身人性的弱點與以前犯過的錯誤,讓我感到恐懼與不適,因而我決定給你寫第一封郵件!向你說明至少在目前環境下有些問題的解決在於計算機理論的革新,在現有的情鏡下討論這些問題是沒有意義的!

我粗略的看了一下你關於"計算機語言"的幾篇文章和論述,我以爲還不錯,但也都只是停留在表層,用到的也只是你所謂教科書上的"陳詞濫調",沒有實際你所謂的哲學層次的昇華,我看的是你的博客,我沒看過你的論文,甚至沒看過你的英文博客,因此我原諒你了,可是,關於操做系統的那一片,讓我有種"不吃煙火食"的感受,以爲這不是一個懂操做系統的人寫出來的!至少這不是一個搞了多年學術的人寫的文章(固然,我不知道你是否搞過學術研究,我只是那麼以爲!)至少至少..任何一個嚴謹的學者或者將本身標榜爲學者的人都不會拿這樣一篇文章管他稱爲一種"設計"的!

事實上在此以前,我並無聽過你的大名,後來在社區中聽到你在10年寫了幾篇關於Linux的文章引發了很大的反響,我對L&(or)W的爭論並不感興趣!對"工具",我不會融入我的情感!我認爲習慣用什麼就用什麼,適合用什麼就用什麼,喜歡用什麼就用什麼!固然若是別人願意或者須要我也會樂意推薦給他!

但我對此(引發轟動這個事件)是有見解的,我以爲"這個社會缺少包容!"!幸福的西朝鮮49年之後,"美"這個概念就被政治化了!革掉一切非主流的命是這個社會的常規思惟!

在這個世界上會有不少奇奇怪怪的人,他們的奇奇怪怪的想法不被人承認和接受甚至受到打壓.多元化的世界纔是一個美麗的世界,思想和觀念的碰撞纔會創造新的價值!瘋不瘋是相對,在"瘋子"眼裏,他或許有本身的一套世界觀,在他眼裏是合理的,別人看不透是由於他沒有達到這個境界!(尼采就是個瘋子,或許他一開始就是個瘋子!)

因此,首先我並不否認你的任何觀點,我相信以及我也認可我對操做系統的觀點是很是狹隘和陳舊的!

我不是個宿命論者,我以爲一切事情均可能發生(包括以上我也提過我曾和你有同樣理想主義的想法!)!我沒對任何東西作出任何評價,不對任何人喜歡或者厭惡的事情品頭論足是一種美德! 但就技術水平而言,我認爲是一個能夠探討的範疇!

就這兩篇文章而言:我跟你討論的是你設計的"可行性"!我但願你在現實的基礎上給出一個明確的指導或解決問題的方案!而不是天花亂墜的描述美好的願景!而後將它視爲一種設計洋洋得意!

剛開始我準備對你的11條設計逐一批判,找出他們不切實際的地方!後來我以爲這11條設計中有不少思想和概念是重合的,因此我總結了一下,雖然不是很徹底(也不知對你觀點的總結是否到位),但這七條內容幾乎應該囊括了大多數你提出的概念!

因爲沒有太多的時間,我決定找出幾個點來簡單論述(以前的文章就是這樣來的)!而這第二篇文章是以前觀點的簡單補充(雖然我以爲仍是羅裏吧嗦,沒有把問題講到點上!),而後提出幾個實際須要解決的問題!

若是可能,在以後的第三篇中,我將會跟你討論"上帝語言"的可行性和我在構建一種編程語言的過程當中碰到的實際問題和困難!而後會對你提出的11條操做系統的設計逐一提出批判和疑問!

固然其中邏輯和某些概念上有意或者無心的錯誤和混淆,但願獲得諒解!

@Brin想寫程序  對我說:"計算機語言就是完美的操做系統這句話沒問題。 若是你從代數系統，羣，圖靈機，機器碼，彙編，操做系統，計算機語言，數據庫。一路看上來就明白了。"

而我認爲:問題不在於操做系統概念的的定義,而是在於哪些問題須要在什麼層次解決!好比:計算機硬件負責提供基本計算能力和存儲等資源;操做系統負責管理他們;而某種計算機語言負責提供相對友好的用戶接口,用戶程序負責解決實際問題!(這是一個嚴謹合理且禁得起考驗的層次分類!界定操做系統的邊界,分清楚操做系統應該作什麼,不該該作什麼是首要解決的問題,而不是爲了其餘緣由必須迂腐的給操做系統下一個定義!!)

在我看來有些概念不該該是操做系統要考慮的,更不是計算機硬件要考慮的!

進程和函數續

把這兩個概念放在一塊兒論述讓我本身感受有點尷尬和可笑,其實個人論述主要是這一點:去除"進程"這個概念,你必需要用另一種機制代替它!

數學意義上的"函數"是個一一對應的概念:y=f(x),給定X的值,Y就必定.然而計算機語言意義上的函數卻不是,他能夠是一對多的關係(多數狀況下仍是上下文相關的), y的值並不固定,能夠簡單的將它分爲(能夠細分):

• 不受環境影響和不影響環境的數學意義上的函數:

1. int fun(int x){

2.    return x+1;

3. }

• 影響環境或者受環境影響(或者二者都是)的函數:

1. 操做了"靜態"或者"環境變量"或者"某些共享數據"的函數和一些隨機函數(受到環境中隨機數發生器的影響)就是這種;

因而咱們是否能夠這麼認爲:計算機語意下的函數在不一樣時間調用,產生的結果是不可預料(或者說隨機的)?

把計算機意義的"函數"轉化成數學意義的函數

若是是這樣的論述,我以爲時間這個維度就必須被考慮進去;

把這個函數變成一個數學上一一對應的函數應該是這樣: y=f(x,time)

time表示時間對函數的影響,其中time固定,環境就固定,若是保證x的值固定,獲得的輸出y必然也是固定的,因而在數學意義上他是個簡單的二元函數;

進程簡單的利用時間分片和某種優先級機制(好比固定優先級,競爭...)進行調度,咱們只須要簡單的在外面同步進程就能讓time參數固定,或者按照咱們的預料,這樣就能"保證y是預料之中的"!

去掉了"進程,任務"和調度機制,讓time隨機,事情就變得不可預料;爲此,必須使用另一種機制保證time的肯定性;

個人問題是:在你的設計中,這種機制是什麼?如何控制time對函數的影響?是讓用戶本身同步設置time的值?你所謂的微小函數之間是如何並行運行的?若是在無限計算能力的CPU上,微小函數執行不須要時間的假設下,這或許是可行的!若是讓全部的函數都串行執行變成早期的單任務系統,"或許"也是可行的!

• 注:以上論述或許有些囉嗦,也或許仍是沒有闡述明白!現有的進程機制並非最完美,可是在沒有最完美的方案以前,次完美的方案就是最完美的!我以爲若是你解決了這樣的問題纔有資格說你超越了Unix哲學!

結構化參數問題與可行性的懷疑

結構化參數有必然的好處,可是其"適用性"將獲得不少限制,不一樣語言之間的調用必然存在"調用規約"的問題,不一樣系統之間必然存在"編碼解碼","協議"和"加密",的需求,甚至不一樣機型存在"大端序-小端序"這樣的歷史問題也須要系統進行容恰;在保證上帝語言的前提下某些問題或許能夠獲得解決,但畢竟存在諸多歷史限制,(歷史問題也是須要解決問題的)!

多數現代系統都選用了"不解釋,不爭辯,忽略"的粗暴手法,其思想是"系統不負責這些問題的處理,你有須要你本身實現解碼編碼的過程,你能夠把數據解析成任何東西賦予任何語意"!無語意的二進制數據是最能知足的需求的,具體對二進制數據的解析,是用戶程序的事情,也應該是用戶程序的事情,系統包辦的可能性爲0!

現實中結構化數據傳遞的方法:

現實中結構化數據的傳遞方案其核心思想概括一下無非就是 "元數據"和"規約"(我認爲元數據和規約的本質和思想是同樣的,因此在此不作區別!)咱們能夠認爲某種編碼規範是元數據(規約),某種格式是元數據,數據庫表的定義是元數據,類型的定義是一種元數據等等;

其核心流程也無非是根據"規約限制"和"元數據"對序列化後的數據進行"從新構建"!

• 這樣的方法適用在任何場景的前提是"元數據"是可計算的!元數據是能夠的遞歸定義或者通俗的說是"可用算法描述的"! 我感性的認爲"元數據"並非一個遞歸集合,他的形式取決於他出現的場景!取決於創造他的人的心情!取決於政治和商業利益!

  對於以上論述個人結論是:除非你給出元數據是一個遞歸集合的證實,或者拋棄使用元數據另闢蹊徑找尋另外一種方案(好比,使用一種可計算的超元數據做爲規範去描述數據!)再或者你用人工智能讓計算機本身就能理解數據的定義,不須要任何東西去描述數據!不然普世的結構化方案不存在的!

• 通用化方案必然存在諸多限制和性能損耗:受限於物理硬件和傳輸,結構化的數據在不一樣的節點傳輸數據的時候須要將結構化的數據序列化,舉個例子(不知道是否合適):好比使用Java RMI的遠程過程調用,對象被序列化,而後傳輸,而後反序列化; 首先對象之間的依賴關係在內存中構成一個圖,這必然存在不少迴環(對象相互引用的問題,直觀的問題是形成程序死循環),確實是有辦法檢測這些環的,可是無疑是有性能消耗的!像這樣的問題這在操做系統級別上是不能夠忍受的(至少我認爲是)!將解析交給用戶的好處是,用戶本身按照需求指定"最優方案"!

  我一貫這麼認爲:通用的必然不是最好的!這個世界上必然不會存在一條定理適用於任何場景(對於計算機而言,越底層的東西越應該具體化)!