如何評價 Midori（Operating System）？

01-12

Midori was a research/incubation project to explore ways of innovating throughout Microsoft』s software stack. This spanned all aspects, including the programming language, compilers, OS, its services, applications, and the overall programming models. We had a heavy bias towards cloud, concurrency, and safety. The project included novel 「cultural」 approaches too, being 100% developers and very code-focused, looking more like the Microsoft of today and hopefully tomorrow, than it did the Microsoft of 8 years ago when the project began.

Joe Duffy - Blogging about Midori

外行冒昧答一發。Midori的前身是研究項目Singularity, 從Joe Duffy的文章來看，基本設計還是一樣的。Singularity: Rethinking the Software Stack - Microsoft Research 這篇文章應該還是了解 Midori的很好的切入點。一句話描述的話，它就是一個建立在managed語言之上的操作系統，拋開各種陳年假定，提出了新的隔離和並發模型，以及新的進程間通訊方式的一個操作系統。

這篇文章對我有特殊意義。我看到這篇文章的時候畢業不久在互聯網後台搬磚研究C10K之類的問題 —— 現在大家都玩C100K了。這篇文章，正如標題，帶我去想一個更本質，卻又並不複雜的問題 —— 如果我們拋開所有歷史包袱、既定事實，在現代硬體上重新設計一個軟體技術體系，它應該是怎樣的？這個問題本身為我打開了一個全新的世(nao)界(dong)。

比如，現在你在一個用戶態C程序上要一段內存, 你至少得經過三層抽象：首先malloc會用一坨迷之策略在一個虛擬的連續地址空間給你分配一段地址，你去訪問這個地址，可能會觸發缺頁中斷，然後操作系統通過另一坨迷之策略給你找一個可用的物理內存頁，然後改你的頁表做虛存地址到物理地址映射。然後！你的指令到了CPU，MMU才根據頁表把你指令中的地址轉成物理內存地址去訪問內存。雖然經過無數先烈的重重優化，這裡的overhead還可以輕鬆佔到整個運行時的10%以上，當然更恐怖的是你永遠都說不準這個overhead — it all depends.

但是為什麼要搞這麼複雜？是因為要在多道程序環境給每個程序相互隔離的空間，不管怎麼亂搞都不會搞掛別人。要連續地址空間是因為FORTRAN這些古老的語言假定連續內存空間，很多環境下甚至沒有動態內存分配這麼先進的東西。然而現在就算我們就算寫C程序很多時候也都依賴malloc對連續空間的假定沒那麼強（well棧還是要的，越界後果還是嚴重的），而更多的時候我們在這層層抽象之上，再跑了一個VM, 然後用自帶內存安全的語言，想想都覺得傻。

Singularity的一個起始點就是：如果從底層開始就是一個安全的managed語言構建系統，我們能刪除很多這些抽象層和迷之策略，managed或者GC並不意味著又一層overhead, 反而，你會得到更簡單，更安全可靠，也更快的軟體系統。首先，你不需要很複雜的虛存管理，所有應用可以跑在一個地址空間上，由類型系統和運行時提供隔離。它也意味著上下文切換的成本非常低，你可以跟erlang一樣做超級多並發輕進程。單一地址空間和GC可以讓你很放心地零拷貝在進程間或與內核/驅動傳遞數據 —— 傳統系統里很多的 CPU 都耗在 copy one buffer to another 和為之服務的 encode / decode 上，在這裡你都不需要了。就像Joe Duffy在blog里說的，這樣做出來的系統很多時候比傳統的所謂native系統要快。

我覺得這樣的文章和系統，就算最後沒有推廣實用，也還是極有啟發性的。在那以後，我會去關注各種OS研究項目的腦洞。在各種項目中，我都會下意識地注意整個技術棧各層的設計假設，也常常發現這種因為過時的設計假設和沒事加一層抽象的習慣導致的不合理設計，常常去 rethink the stack. 我會少很多自我限定，比如會直接忽略有runtime有GC就不能做系統編程之類的bs.

我們處在一個很奇怪的時代。不管是最新的手機還是最強大的後台集群，跑著的系統都是一個40多年前的UNIX的復刻+擴展版，還支持那個時代的API. 我們當然都不是在用 UNIX 的方式去用系統了，我們不會去fork進程然後用pipe通信，而是發明了各種各樣不見得就更好的並發和通訊方式 —— 然而內核還是要支持像fork這種超級tricky的系統調用。經典的系統體系早已崩塌，我們要麼在廢墟上架無數層抽象，要麼像epoll一樣在內核上打洞，而未曾建立一個新的系統體系，這有點像羅馬帝國崩潰後的中世紀。

Singularity / Midori 就是建立這樣的新體系的嘗試。Joe Duffy Midori 系列的每一篇文章都值得反覆讀，在每一個設計點上，在提出解決方案前，他總結了現有設計的思路和背景，分析根本問題所在，我認為每一篇都做到了 "rethinking the software stack". 我不完全同意某些具體的設計結論，但這樣的思考是無價的。

Midori 的意義在於證明了在 memory、type、concurrency safe 基礎之上構建系統和應用是可行的，性能和安全並不是對立的。Midori 很難用成功或者失敗來評價。

Midori 的很多思考和實踐在其他一些項目中得到了體現：

比如開源的分散式 Actor 模型：https://github.com/dotnet/orleans/。Midori 的前身是 Singularity，而 Singularity 的創始人之一又提出了 Orleans 的構思。很多前 Midori 團隊成員都加入了 Orleans 項目。Orleans 的非同步和並發模型受到了 Midori 的很大啟發。

可以看看這篇文章，講述了 Orleans 和 Midori 的故事：Orleans and Midori

謝邀。最近正在拜讀Joe Duffy菊苣的這個系列文章。

不過看起來M#似乎很好玩的樣子。

坐等培神在less is more專欄更新。

一個註定失敗的，但是工程師知道失敗也想干幾年的 project.

我曾經以為我是第一個想到這個做法的人。可是調查之後發現，很多人早就已經做出了類似的系統。Lisp Machine 似乎是其中最接近的一個。Oberon 是另外一個。IBM System/38 是類似系統裡面最老的一個。最近一些年出現的還有微軟的 Singularity，另外還有人試圖把 JVM 和 Erlang VM 直接放到硬體上執行。

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

1.不開源

2.沒用過

3.沒視頻

4.沒圖片

5.就連新聞都很少。。。。

你說如何評價？就憑那零星的新聞和博客介紹來捕風捉影嗎？

在夢中！

如果真的用心做肯定可以成，但是別放腦殘的想法和設計就是了。

另外我想說的是，其實在伺服器界，急需一個新的簡單點的操作系統來代替不堪重負的linux。。。

足夠簡單，足夠安全（簡單自然攻擊面也是極少的，簡單效率也不會太低的），

足夠跑一兩個簡單簡潔高效的服務端編程語言。

一定會火。。。！