Google Fuchsia初探
這幾天我花了一點時間簡單看了一些Fuchsia的代碼，對這個系統有了一個初步的了解。也歡迎在狗家的朋友批評指正。
Fuchsia是Google內部孵化出來的一套新的全部開源操作系統。你能在google的代碼倉庫看到所有的代碼，
https://cs.opensource.google/fuchsia/fuchsia
這個系統有點屬于備胎轉正的意思，在Google內部前前后后開發了大概有6年多了，如果再考慮到以前的little kernel的積累，這個系統開發的時間更長。
這套系統是一套完全不基于Linux開發的系統，從它的能力和目標來看，他的目標是統一從高端嵌入式設備，手機，手表，汽車，平板電腦，臺式電腦的大一統操作系統。
這里面有個假設就是將來的硬件設備主要是ARM64架構或者x86架構，我覺得這個假設沒有問題。從代碼倉庫的代碼來看系統支持兩種架構即 ARM64 和X86，代碼從2014年開始，就在開發了。
ARM端
因為系統支持的ARM64，這么來講，一些低端的老的ARMv7指令集的CPU， 新操作系統不會支持的。 這就非常明確了，這套系統嵌入式系統的定位時中高端的嵌入式設備。
們公開支持的第一個設備nest hub，就是用了 Cortex-A53架構的。
PC端：
因為系統支持x86, 也就是說它將來能跑在所有的桌面電腦上，不僅僅是chromebook了。這個直接是對著微軟的存量桌面系統去的。
代碼中寫的ACPI模塊表明他們對桌面系統的支持是非常廣泛的。
平臺：
從支持的平臺來看現在公開支持的有 如下幾個平臺
不過在2018年前后，Fuchsia還支持過Raspberry PI 3 但是后來Google 又移除了這個平臺，我不清楚google這么做的目的是什么？
不過又愛好者，在把Fuchsia 往Raspberry Pi 4b上搬，去年還搞了一個pull request向主分支提交，但是現在的狀態是abandoned的狀態，不知道為啥。
這個愛好者代碼倉庫在
https://github.com/dahliaOS/zircon-rpi
看了一下往rpi4上移植 Fuchsia 難度沒有那么大。
安全性：
這個代碼系統非常龐大和完整，kernel這塊的完成度非常非常高。后面是一些安全機制改進，性能改進，大范圍測試，回收dump，再分析改進的過程。
比如他們現在的內核安全機制方面，還沒有采用 KASLR， kernel address space layout randomization，不過從注釋里看到，他們已經把它看成一個todo item了。
還有不少安全隱患沒有去修，比如 null page的問題，ASLR問題，簽名問題等等。所以大概還需要一段時間的打磨才可以。
系統層
由于整個工業界已經在linux和anroid上面投入了大量的資源。所以面對Fuchsia需要能夠兼容這些legacy的程序。
由于Android和linux之間的深度綁定，你無法只想僅僅支持Android而又把linux給扔掉。舉個例子來講，假設你搞了一個用android app給外置的單反進行美顏的app（功能夠怪的，為了說明起見）那么，你的android app包含了兩個部分，一個是Android java code部分。一部分是NDK部分，你給你那個奇怪的單反寫的特殊linux驅動。
然后你發布的時候，是將驅動和apk一起發出去的。
然后你說我的底層內核改了，改成其他內核了。那么解決方案又幾個：
要求開發者重寫針對新內核的驅動。重新發布。
在新os中搞個linux的虛擬機。然后相當于Android運行在虛擬機里面。
搞個ABI 二進制兼容的子系統。
重寫，重寫的錢誰來掏，肯定沒人愿意好好的給你重寫一個用的好好的app的。現在銀行還有用Cobol的呢。
現在看到的方案是 Starnix方案
https://fuchsia-review.googlesource.com/c/fuchsia/+/485181/7/docs/contribute/governance/rfcs/0082_starnix.md#19
This document proposes a mechanism for running unmodified Linux programs on
Fuchsia. The programs are run in a userspace process whose system interface is
compatible with the Linux ABI. Rather than using the Linux kernel to implement
this interface, we will implement the interface in a Fuchsia userspace program,
called `starnix`. Largely, `starnix` will serve as a compatibility layer,
translating requests from the Linux client program to the appropriate Fuchsia
subsystem. Many of these subsystems will need to be elaborated in order to
support all the functionality implied by the Linux system interface.
簡而言之就是 在用戶態實現一個linux的ABI，類似于Windows 里面的Posix Subsystem， OS/2 subsystem。
UI層
Google采用的是flutter框架，這個框架是未來。我建議小白學python + flutter就夠混了。連我這種老幫菜，現在也開始學用flutter了。
為啥？
因為用flutter寫的代碼，可以同時運行在Android和IOS上，還可以用了開發網站前端。還是native的code！這個就非常厲害了。把原來微軟的WPF 這套理念，發揚光大了。
Flutter作為Fuchsia主要的UI框架好處是顯而易見的：
大量的代碼可以重用。比如你現在為Android開發的flutter代碼可以無縫遷移到Fuchsia上作為原生程序來運行。
大量的開發人員社區。
因為flutter能夠有效解決跨平臺，性能，完整性方面。在短期內就積聚了一大批的開發人員，生態社區完善。一旦Fuchsia 大規模商用，開發者不會是個大問題。
為什么Google要另起爐灶？
Google沒有公開的評論，但是Google的動機還是很容易理解的：
從技術角度來看：
linux的內核是單體內核，但是Google的判斷是，將來的IoT世界需要的是微內核。這點跟service領域的微服務化有點異曲同工之妙。代價都是性能可能會有一定的損失，但是帶來了整體系統的穩健性。
比如Windows臭名昭著的藍屏，一個很重要的原因是，第三方硬件廠商寫的驅動程序很爛，很多程序就在內核態運行，然后，一出問題，系統就藍屏，直接搞得大家很尷尬。設想在一個自動澆灌系統，一個控制系統，一個溫度，濕度，光照的傳感器，假設這些驅動 是一幫sb寫的，經常有bug，而且經常更新。現在的情況就會把人搞死。一出問題，系統就會重啟。而且經常需要系統停機更新。這在IoT領域是非常不好的。
所以，Google的判斷就是微內核。
這是fuchsia的內核的架構示意圖
在技術上，Google還想放棄JAVA，畢竟JAVA是Oracle的兒子。Oracle又不思進取。
從商業上看
想在iot 領域，復制Android的成功。
Android的成功為Google帶來的巨大收益。而后面十幾年未來在各種各樣的IoT領域。所以能夠在IoT領域里面搞出一個事實標準。那么可以給Google帶來巨大的收益。
想在desktop領域，干死Windows。
Google搞這些，在旁邊瑟瑟發抖的不是華為，而是微軟。在疫情期間，Chromebook的增長遠遠高于Windows的系統。
微軟的操作系統部門，如果不做大的調整，基本上會在這場大戰中落敗。
結語
我們在非常高的層面看了一下Google Fushsia的架構和可能的roadmap。
他們的內核就是那個Zicorn。能做多少事情？不能做什么事情？怎么做的，非常清楚。
另外Android的程序，linux的驅動模塊在系統里跑起來是怎么跑的，什么原理，也基本上比較清楚。 他的應用程序開發是怎么開發的，原理是什么也很清楚。
我們通篇說了Fuchsia 但是沒有比較鴻蒙，我只能從幾張大的歷史框圖來做個比較。
這是2019年的roadmp
這個應該還是現狀
這應該還是未來
還遠沒有到Fuchsia OS這種一個微內核的成熟度。即便如此，根據 Fuchsia的成熟度，Fuchsia 到大規模使用，至少還需要3-5年時間。。。
給鴻蒙的幾點建議：
1. 擴大統一戰線
Fuchsia的針對的是中高端的嵌入式設備，低端的嵌入式設備，Fushsia看不上。這塊完全是一個機會，低端不代表落后，代表低成本。所以，完全可以不用放棄對中低端arm 平臺的支持。
可以擴大統一戰線，把自己的隊伍搞得多多的。
可以以看看同樣的國產實時操作系統RT-Thread, 怎樣悶聲在江湖里坐穩自己位置的。
| |
| |
這就是群眾，這就是市場，這就是需求
2. 加快開源社區的建設
讓更多的廠商，開發人員上車。
現在Fuchsia是完全開源的，而且已經開始邀請開源社區向其貢獻代碼了。
這對于很多獨立開發者或者設備制造商來講，肯定會有考慮，如果早上車了。那就是投入成本。隨著投入的增加，以后除非有真的難以忍受的bug或者法律法規問題，否則不太會跳車的。現在這方面，現在已經比Fuchsia晚了。
再看看，大家對開源社區的建設進行時
這是fuchsia 主分支上 commit的活躍度，今天是周末，過去26小時內的commit情況
相對比的 open harmonyos 到現在為止，快9個月了，一共才468個commit ，這個活躍度，實在不敢恭維
你可以說大部隊在開發 harmonyos2，那我們對比一下只針對IoT領域的國產操作系統RT-Thread,他們總共有11727個commit，RT-Thread 僅僅5月份一個月就 150個commit！
在開源社區方面，不要說打敗fuchsia了，打敗RT-Thread還有點距離。
3.腳踏實地，培養這個社群需要大量的開發人員
Fuchsia的OS開發了快6年了，不少主創開發人員都干了快20年內核了。
我們可以簡單估算一下，要搞出一套真正的跨平臺系統。這是一個浩大的工程，需要海量的工程師，在5年內趕上Fuchsia的生態系統。光合格開發，測試人員，至少需要2萬人以上（這都是那種跳出來隨便隨隨便便年薪30萬以上的那種人才）。
所以，一方面需要培養大量的年輕人才。如果是國家意志。那么現在從大學開始就要培養大量相關專業人才。
另外一方面，為那些腳踏實地安心干活的人員提供合適的空間。比如Fuchsia中留下開發者名字的主創人員，有一個是Travis Geiselbrecht，這個家伙
Zircon內核 tech leader
這個家伙44歲了，還是一個IC，level在Google內部是L6。但是它能在 OS這個領域里面深耕20多年。沒有35歲的危機，沒有那么多事情。
而國內現在有個非常不好的趨勢，就是年齡歧視，很多地方對35歲當不上領導的員工就優化。這是一種非常有害的行為。我也希望，在國家攻關統一操作系統的時候，能夠認真培養人才，尊重人才。拿出鄧總的勇氣，不管是白貓還是黑貓，不管是小貓還是老貓，逮到老鼠才是好貓。
好多年沒有看這些底層代碼了，翻了翻，感概萬千。
如非特殊情況，這個話題over了。
