如何看待 Google 的新操作系统 Fuchsia？ 第1页

当初谷歌Chrome OS出来的时候，你们也是这么说的。

(눈_눈)现在坟头草已经八丈高了

Chrome OS从12年维护到18年，依然只占全球桌面系统的0.3%，相当于Linux的1/7、MacOS的1/32、Windows的1/283

我这人比较直，限定条件过多的“成功”一概不认
何况你家谷歌还是世界顶级IT企业，志向就这么点？
┑(￣_,￣ )┍
强者谁都打得过，他就是王，至少也是A国的王、B领域的王、所有山头的王。
失败者才会用“我在A国B地区C山头300km以下的海拔占据30%势力”自立为王。
——致谷狗们

Android确实可能被替代，但绝不会是“几年之内”，除非安卓彻底停止更新。然而连项目组都跟Android不是同一个，怎么可能现在就停止维护老系统？

而且新系统刚出来，往往比成熟老系统的问题更多，需要至少几年的改进、磨合。难道这几年里谷歌就放弃安卓、不跟ios竞争了？

这货几年后能不能超过Android还是个未知数。人家连java和linux这两个世界上80％程序员的必修课、安卓的两大核心都抛弃了。就算它自称“兼容Android”你们相信它能100％完美兼容吗？

就算谷歌牛逼，能完美兼容安卓APP，能像安卓一样开源吗？

就算谷歌大方，开源了，也鼓励社区开源。但在你没有屌炸天优势的情况下，我干嘛要换成一个彻底抛弃了我的旧知识体系的新系统。

永远别完全相信宣传这种东西。实际情况很可能就是无法完美兼容安卓应用、环境封闭、功能也并不比安卓有明显优势的新系统。

当初你们都说Linux、Android更先进，在电脑上终会取代Windows，到现在我连影子都没见着。严重怀疑他们分不清电脑和电视。

不过打脸最厉害的还是三年前吹uwp那群人。连微软自己都看不下去放弃了uwp和uwp版office，转而研发.net core

安卓4.0时代果粉还跟我说Swift先进，ios应用未来会以Swift为主流开发工具……真当苹果、谷歌发明啥玩意都能成神了？苹果要是开发个智能跳蛋，名为iFuck，你买不买。

很多时候你们认为先进的东西，不一定真的先进。Python的动态变量多先进啊～你看那些几十上百个人维护的项目，哪个敢用动态变量？

谷歌的Aide先进吧？没人玩，烦死人的原生java、linux倒是吃遍天下。

腾讯云的动态磁盘分配、云备份先进吧？

丢文件了，还不如原始的静态磁盘备份呢。

╮（╯＿╰）╭很多老工具为什么不淘汰？

不就是经过时间检验，新工具依然比不过么

你们啊，要是不能像乔布斯一样引领市场趋势，就老老实实跟着市场趋势走。哪天Android真的开始江河日下、新系统蒸蒸日上了，你们再大放厥词满天射卫星也不迟。

别说自动编程、手机编程，就算以后出现口头编程、脑电波编程，你信不信懂STM32、汇编、C++的人依然是抢手货？

先进的系统、工具、技术一直在变化，但笑到最后的永远是老掉牙的。不是因为它老所以笑到最后，而是因为它能笑到最后，所以它会老。

————个人预测————

手机领域，至少5年内Android不会被替代，但是底层代码可能会逐渐被重构，用来解决你们口中的致命伤。

如果Fuchsia能做到配置与Linux无异、开发却方便很多，或许能在涉及人机交互的智能设备（比如智能家居）上取代WinXP、Linux成为自动化、物联网领域快速开发的首选系统，

稳定的内核驱动接口

Google想设计一套稳定的驱动API接口。因为Linux目前不具备这个稳定的内核内部API接口。（Linux内核的外部接口，即system call是稳定的。）所有的驱动必须放到内核里面随着大部队一起被维护。但是问题在于各种移动设备的BSP驱动太多太零碎了，而且过时的很快。内核带着这些垃圾往前走非常麻烦。

Fuchsia希望提供这样一个稳定的驱动接口，让各个厂商根据这个接口自行开发和维护驱动。

进程沙箱

Fuchsia没有传统的“根文件系统”的概念。

在Fuchsia中，路径只是一个形式上的字符串，并不一定对应于磁盘上的一个vnode。在一个进程创建时，会给它提供各种资源，这些资源被赋予各种路径。实际上，我们不应该再把这些资源的路径看成是一个统一的文件系统。路径只是这些资源的标签。进程会有一个表，用来存储从标签（即路径字符串）到资源对象句柄的映射关系。

https:// github.com/fuchsia-mirr or/docs/blob/master/the-book/namespaces.md

有了这样的机制，一个进程在创建时的沙箱可以用任意的方式组装起来。这个组装是必须的，因为进程一开始能访问的资源集合是空的。

一个组装例子：/pkg指向应用组件本身所在的存储区域，可以是一个merkle tree，保证程序不会被篡改。/data指向应用自己的持久存储磁盘文件系统区。/tmp指向临时文件所在的内存文件系统区。

访问控制

在Fuchsia中，不存在ambient authority. 所有的访问权限需要通过object handle获得。比如说，进程拿到了一个目录的handle，那么它才能访问这个目录下面的文件。这些句柄是在创建进程时赋予的。

在传统的操作系统中（包括Windows和Unix），授权是作为一种访问控制机制存在于系统中。在Fuchsia中，授权是作为一种实际的可传递的值（即handle）存在的。

微内核

Fuchsia是纯粹的微内核。内核中主要的抽象只包括进程、虚拟内存和IPC机制。各种文件系统、设备驱动、服务都作为一个进程跑在用户态。

这样的话，读写文件就变成了先跟文件系统进程建立一个channel，然后来回发送消息。一切都天然是异步的。

前景

微软曾经做过一次操作系统方面的全新尝试：Midori项目。2015年时管理层解散了Midori团队。大致的原因有几个：Windows团队的不接受；移植全部Windows功能代价不可接受等等。

但是Fuchsia系统对于Google来说是一个战略性的项目。因为谷歌并没有完全被自己控制的操作系统。Android和Chrome OS的底层都是Linux kernel。Linux kernel社区对于Google来说是不可控的。Google想干点啥经常被拒绝。

而且，由于Fuchsia的内核抽象非常小，完全有可能通过用户空间的抽象层兼容目前的Android, Linux上面的应用。

附：空余时间读了一点Zircon的源码，写了一点笔记贴在这里。不定期更新。

我先举一个例子。MacBook 2016 上的 touch bar，其实并不是作为一个简单的显示设备运行在 macOS 上，而是一个半独立的设备。外界猜测，touch bar 运行在类似 watchOS 上。开发支持 touch bar 的功能的时候，第三方开发者的代码仍然是运行在 macOS 上，只是通过类似 client-server 的方式去驱动 touch bar。

所以那些分析 Fuchsia 是为 VR/AR 特殊优化的理由有什么问题呢？问题就是，如果是这样的理由，Fuchsia 可以作为 VR/AR 的显示子系统的专用系统软件。但是，如果它和通用的 Unix-like 系统差别太大，就不可能担当建立第三方软件生态系统的重任。当 VR/AR 成为通用系统之后，与第三方开发者打交道的一定是和今天的 Unix-like 类似的通用 OS。而对于这类 OS，我看不出来任何在 Linux/BSD 之外另起炉灶的必要。

我同意随着软件复杂度的发展，原来计算机架构的某些假设并不成立。但是不要小看原有架构的弹性。比如说 GPU 的工作方式已经和原来操作系统的设计方式并不相同，但是设计整体架构的时候，只是尽量把适合 GPU 担当的工作分离成为 GPU-driver 和 low-overhead graphics framework。并没有完全替代原有通用 OS 的工作方式。

所以软件业的「另起炉灶」面临两方面的压力。第一，你永远不要小看原有系统的 lossely-couple 的弹性。你可以替换某些单独的模块，但是你并没有那么多精力去替换整个系统。如果你用蛮力去替换整个系统，在竞争中你会被更有效率的对手击败。第二，你永远不要低估挑战整个帮助你建立软件生态的业界的习惯的难度。采取更加稳健策略的对手会在融入业界习惯方面击败你。

RTOS 也是如此。只有火星车、路由器这类不需要建立第三方软件生态的专有设备才是完全运行 RTOS 的。在更通用的设备中，需要 RTOS 担当的部分永远只是一个子系统。（而对于 VR/AR 类应用，我甚至看不出来现有的 GPU 架构有任何不能胜任的地方。我认为对于 VR/AR 系统，最多需要某种特别优化的 GPU-driver。）

我不知道 Google 对 Fuchsia 的具体定位是什么。但是如果它是用来替代通用 OS，那一定会是一个错误。

（但凡这种涉及「另起炉灶」的问题，肯定有一堆莫名其妙就兴奋不已的答案。通常都不能理解兴奋点在哪里。请问把渲染效率和内核架构放到一起说的人到底明白现代硬件渲染是怎么执行的吗？）