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

緣起

王垠大大寫了一篇關於要設計一個超越Unix哲學的操做系統的博客!!而後就花了一個晚上無聊的給他發了一封郵件!

博客: http://www.yinwang.org/blog-cn/2013/04/14/os-design/

-------------郵件內容以下----------------

簡單的概述

首先

看了一篇你的<一種新的操做系統設計>的文章!有一些簡單的想法!但願能夠與你交流一下! 只限於技術性探討,沒有其餘意思和目的!言辭不當之處請諒解!同時水平有限有不當之處能夠批評!(另外我看了你的Ydiff,若是之後有機會也能夠聊聊)

文章是Markdown的,複製到郵件中或許會變形,若是看着不方即可以把原文檔發給你!

我不理解你是如何理解"操做系統"這個概念的,也不明白你所謂的超越「Unix 哲學」是什麼含義(可是你既然提到了Unix我就暫且認爲你想要要的是運行於硬件的操做系統)。 可是我以爲你關於操做系統的理解徹底是基於用戶層面的.能夠看出你是個理想主義者,但願系統按照本身想要的方式作事情!

你所說的11條操做系統的設想,是徹底不靠譜的.有的甚至背離的"經典操做系統"的概念的,或者你設想的根本不能算一個操做系統而是架設在操做系統上的一層殼!(就像Hadoop同樣是一個分佈式'組織系統'),只不過Hadoop只解決了分佈式計算(MapReduce)和分佈式存儲(HDFS),而你想要的更多,但也只是停留在操控層面的,你只是但願屏蔽一些底層的東西,讓業務層面的變得更簡單,或者看起來更簡單(事實上不是每一個人的思惟方式都和你同樣的,有些人認爲面向對象的思惟方式更天然,而有的人不是,一個完美主義者或者理想主義者老是試圖找到一條普世的理論去闡釋這個世界,因而有了"弦論",在科學界一是一,二是二的二元論斷是很是值得推崇的,可是面對人性,面對需求你或許應該思考更多,愛因斯坦說上帝不玩骰子,然而他最終仍是接受(至少是默許)了量子論,bash已經很好用了,卻還有人鼓搗出各類各樣的shell.)!

關於你文章對操做系統理解的總結:

• 通訊是結構化的

• 一切都是用"超語言"定義的函數,全部的函數的規範是一元的

• 一切(系統自己,"函數程序",用戶Shell程序)都用超語言實現,超語言不能有指針運算

• 用"對象數據庫"取代關係數據庫

• 不須要文件系統

• 用戶透明與"無限"

• 爲了不數據移動產生的IO開銷,優先自動遷移進程!

標題很差說

• 你的設計思路對操做系統沒有任何現實意義,更多的是空中樓閣,水中月!是沒有任何現實基礎的"美好瞎想"!

• 你的文章中只有推翻,而沒有建設!你只是說這個不要,那個不要(不要進程,不要文件系統,不要關係數據庫...),而沒有提供實際的能夠取代他們的真正有意義的方案!

• 你的思惟方式不是在設計一種操做系統,而是在設計一種編程語言!

• 按照你的理論:Python或者Java就是一個完美的操做系統!它幾乎知足你要的一切!

• 超語言(上帝語言)的概念很吸引人,但這絕對是錯誤的!正如我上面所說人性和需求是複雜的,是動態的,是多變的,哪怕你提供是諸如"英語"同樣的通用語言也會有不少人須要添加一個"中文翻譯器"!徹底不用翻譯的意思就是你得要求全部人都遵循和接受你的思惟方式!固然或許你會說這種超語言知足一切人的需求,擁有一切易用的特性!好吧,若是真的有上帝語言能夠跟任何人溝通,我想仍是會有不少人願意嘗試的!

• 你徹底沒有理解操做系統是什麼,他扮演什麼角色具體要處理哪些工做!你所要求的都只是操做系統的外延,而不是操做系統的內涵!你博客的文章標題或許變成<我須要這樣一套分佈式管理系統>或者<一種新編程語言的設計>更加合適!

• 就如今計算機的體系結構而言沒有指針運算是不現實的,就架構而言現實機器大可能是基於寄存器的,討論基於堆棧的虛擬機對於設計和實現操做系統沒有意義,事實上不管那種機型,想要快速隨機的訪問特定位置的數據間接尋址是一個很是不錯的工具,除非你徹底拋棄"間接尋址"!或許你在"語法解析"這種邏輯層面不須要這種特性,但系統層面的間接尋址是必須的,除非你設計一套新基於更高理論水平和哲學層次的硬件!

• 把系統看做爲一個"僕人",只要對他下命令他就能按照你想要的方式爲你作任何事情(這或許是你的終極目標或者是你目標的一種更爲極端的表述)!只想用高級語言的特性而忽略計算機體系結構設想出來的東西根本就不能算做"典型意義上的操做系統"!按照你的方式我徹底能夠這樣設計一個操做系統:只要我告訴他我想作什麼,計算機就能夠爲我作任何事情,好比去廚房作個番茄炒蛋!他就傻乎乎的跑去買番茄和雞蛋而後...這樣的設計豈不是更完美?

• 我以爲你多是作"語法分析"的!或許對各類語言的"哲學思想"有獨到的看法,可是把這種思想或者更高層次的抽象帶到"操做系統"的設計上就是很大職業病!爲此你須要推翻現代計算機的體系結構,從新設計和研究可計算理論,不切實際的泛泛而論只會讓我看到你的幼稚與任性,露臉與現眼只差一步!

• 若是你但願你作的是驚世駭俗,前五百年後五百年都未曾有和超越的東西.請先不要將它叫作"操做系統",或者跟"Unix哲學"比較!若是必須這樣作,請先搞搞清楚什麼事操做系統和Unix哲學!

個人一些相對現實與醜陋(沒有那麼理想化,不少甚至是迂腐)的見解

我理解的操做系統

• 最原始的需求:若是將計算機看做一堆冷冰冰的電子元件操做系統的角色就是"驅動,它將這堆冷冰冰的器件合理的組織起來,讓他們構成一個系統團結起來工做;要知道程序是直接能夠跑在機器上的,不須要任何系統的,可是這意味着你就必須面對這一堆冷冰冰的電子元件了!

• 咱們要的更多:儘管硬件系統變愈來愈複雜,若是將計算機的計算能力,內存空間,外存空間等看做資源,然而這部分資源終究仍是有限的;操做系統的目標是如何更有效的使用和管理這些資源!就由於資源有限因此才須要管理,才須要操做系統,固然你所設想的"無限空間",不須要"文件系統"這種概念徹底是背離的!

基於以上兩點,如今多數真正的操做系統是面向"硬件"的,如何高效的利用硬件是他們的重點!(宏內核與微內核的爭論在這一點上看起來像是對立的,事實上確實是這樣麼?我以爲,孜孜不倦的挖掘計算機的潛力是每一個系統開發者的目標與樂趣所在)

程序,進程與函數

什麼是程序什麼是進程?去掉進程的概念是否是意味着你須要用別的方法代替?函數嗎?事實上他們徹底不是一回事兒,進程概念的存在是爲了讓程序看起來是並行執行的(仍是以上這一點,爲了更有效的利用CPU資源)!

函數呢? 函數是一種"可計算模型"的表示方法(你徹底能夠用圖靈機,lambda演算,寄存器模型,或者遞歸來代替,由於他們的本質是同樣的)!

你只是用函數描述了計算方法,而進程是有時間考量的,可計算理論中並無"時間"這個維度!你拋棄了進程,就勢必要在函數的定義一個時間維度,在你的觀念裏函數是一切,它能夠作任何事情!現實意義上的計算機更多的是基於寄存器模型和遞歸模型的,編譯器大多數只是將函數表述翻譯成寄存器表述或者遞歸表述,這個過程是一一對應的,他們都是靜態的,編譯器在這個過程沒法給他附上時間維度.編譯器不作,操做系統也不作,也就意味着程序員得在代碼中加入控制調度的代碼,好吧咱們回到了最原始的時代了.(固然除非你假設CPU的計算能力是無限的,任何函數都是能夠並行執行的,函數的執行是不須要時間的,函數之間的依賴關係是不存在的...就另當別論了)

"「系統調用」，只不過是調用另一個函數,"對於你的輕蔑傲慢的語氣我真的不想吐槽!事實上系統調用還真是調用另一個函數,對於不少微內核系統雖然其實現是"基於消息"的,可是其外在依然表現爲"過程調用"形式,對於被調用資源的實現也依然是個函數! 我不知道你是如何理解函數這個概念的,"任何可計算的問題都能用可計算模型(好比函數)來表示,而可計算模型以外的則是不可計算的",這或許看起來像句廢話,但他確實證實你所說的,可計算的一切均可以是函數,可是僅此而已,沒有任何外延了,如何安排計算,如何調度計算,可計算理論並無給出任何有意義的說明;

固然實際問題要複雜的多,除了時間問題,還有你提到的權限問題等!

關於關係數據庫與文件系統

系統不須要 SQL，不須要關係式數據庫。

我須要強調一點:關係數據庫並不只僅是一個數據存儲方案,也是一個數據"計算方案"(不少人用他是否是由於存儲方便,事實上它存儲不方便也限制多多,諸如數據必須是結構化的,對於樹形的或者圖形結構的數據還須要扁平化)! 數據存儲的方案有不少,你能夠直接將數據按必定的格式排版放到一個文件,可使用鍵值模型存儲簡單的數據,或者將數據保存爲特定通用格式(好比JSON,XML),或者有不少基於樹形結構的文檔數據庫.基於圖論的圖形數據庫(Neo4j)和狗屎的對象數據,固然也包括基於關係模型的關係數據庫!(或許有一天有人會來個大一統,可是誰取代誰的說法顯然是不靠譜的),他們各有各的優缺點,而關係數據庫更是基於嚴謹成熟的關係數據理論構建的,他的數據結構簡單,運算簡介高效,不明白爲何有人會討厭SQL,事實上他是最簡潔方便直觀的工具,他隱藏了不少計算細節,甚至你只須要告訴他我須要什麼(而不是如何作),他就能很好的爲你提供服務!

若是一切都是對象,隨意的構造數據,存取無疑是最方便的),但構建在對象之上的算法就必須本身實現(這將會是災難),相比於本身在對象之上實現算法,"構造結構化數據"顯然更簡單(或者機械化),基於成熟的關係數據理論也可讓你避免不少錯誤!我想這也是關係數據庫佔統治地位的主要緣由!

對於文件系統,理解有不少種,基於磁盤的文件系統和構建於文件系統之上的"文件系統"!操做系統意義上的是前者,然後者大多數是是一些"虛擬文件系統",網絡文件系統,或者分佈式文件系統!後者更接近於"文件管理系統",他沒有解決數據如何存儲在物理介質上的問題,主要面向業務,提供"文件系統透明"這一律念!操做系統設計提出"不要文件系統"和"金三胖不要姑父"同樣荒唐!

解碼是必須的

解碼(解析)是一個"理解數據"的過程!

你能夠把任何數據看做一個"有特定語意的對象",做爲人很容易憑直覺和經驗認定12345是數字,abcde是字母!但對於計算機他只是一塊放在特定位置的"沒有特定意義"的"數據",咱們使用數據就必須對其賦予必定的含義,知道他是什麼,如何組織!計算機不會下意識的知道12345是數字,而abcde是字母!理解數據必須存在,哪怕是一個結構化的數據,要使用它你就必須理解他,同時要讓計算機理解他!(事實上你在判斷12345是數字以前已經對他作了解碼了)

因此個人結論是:解碼是必須的!不是全部事情都是理所應當的, 或許向你這樣的人思惟速度很是快,有些問題你憑直覺和經驗就得出告終論!以致於你甚至意識不到你對問題作出了思考!可是理性是必然存在的!

 

那麼這個問題就變成了"誰來解碼"!

目前而言能夠有下面幾個選擇:

• 計算機本身(硬件系統和操做系統)

  事實上計算機有必定的解析數據的能力 就馮諾依曼體系結構的計算機而言,它要求程序按照特定的指令系統被編碼存放,這種規範的是一個有限的集合!無限延伸讓他處理任何的數據是不可能的(好比你給計算機一個Torrent文件他或許只是個文本,但讓計算機知道接下來要作什麼是不可能的,不可能任何系統都安裝了這個解碼器,由於不是全部人都須要的,你必須許更具特定的需求本身安裝Bencode/Bdecode)!更高層次的解析(理解)須要具體問題具體處理,除非你顛覆現有的體系結構從新設計基於更高理論水平和哲學層次的可計算模型. 把全部的東西交給系統來處是不切實際且沒有必要的(若是特定場景或許能夠),因此你或許應該把這些事情交給下面的選項來作!

• 編譯器(或者解釋器) 當咱們編譯一個C的結構體的時候,編譯器提供了編碼和解碼,它根據語法定義的數據的寬度獲得特定偏移,將數據按照特定偏移排布在特定的位置這是一個編碼的過程,計算機根據本身的指令系統的定義和規範對編碼的數據進行加載和運算,這是一個解碼的過程!從函數式編譯到寄存器模型亦是一個翻譯的過程,這個翻譯過程爲了讓不一樣系統之間相互交流編碼和解碼是不可避免的!

• 程序庫

  咱們很容易的使用已有的庫去解析JSON,XML,讓他們變成你所謂的對象,應爲你或許以爲在用戶層面上使用對象的概念會更簡單!

• 用戶(程序員): 對前無古人的個性化數據賦予必定的語意,用戶必須制定特定的格式或者協議,而後手動編寫相應的代碼實現編碼與解析!然而這是大多數創造力的來源!若是你作創造性的工做,我想這會是大多數狀況!

關於如何解決分佈式問題

你提到的移動"計算"優於"移動數據",這在大多數狀況下是正確,包括Hadoop這種系統也是那麼作的,這並沒有新意!

然而事實上分佈式問題的核心在於調度,在於如何抽象成一個分佈式計算模型來一勞永逸的解決任何可分佈式計算的問題,在這裏還要明確一點有不少問題是不可分佈式計算的,就是由於存在這種問題,構建一勞永逸的模型就幾乎成爲不可能的至少是有代價的事情,MapReduce或許是一個很不錯的模型,但在特定的情景下依然會顯得力不從心,同時無可避免的引入了無關代碼去分解問題(只是將這個過程模式化了),不少狀況下特定的業務邏輯下,這種方案並非最高效的.

而Java和其餘一些分佈式方案並非真正意義上的"分佈式模型",他並無解決任何"問題分解"和"調度"的問題,程序員仍然須要根據本身的業務需求分解簡化問題,決定哪些問題在哪些節點運行,什麼時候運行!

不須要顯式的使用特定的方法就能讓系統跟安排進程執行同樣自動的分佈這些計算和數據到不一樣的節點的通用系統我沒見過(或許還真有)!