有个梨UGlee
2019-11-23 20:07:00 发布
网上翻了半个下午的Plan 9。
除了官方的文档和Paper之外资料非常少，不过还是能找到一点；Youtube上有个10年前的视频简介；用户在一个完全灰色背景的窗口上点鼠标右键，在context menu里选择new，然后用鼠标画了一个矩形区域，之后这个矩形区域就变成了Terminal，出现了命令提示符。
在一个局域网内，如果有一些预定的Global name，比如source是另一个服务器；写下命令9fs source，就会在本地文件节点上mount目标服务器的namespace。
在Plan9里最核心的抽象，仍然是everything is a file；它走得更远一步，称之为everything really is a file，意思是在传统unix里的socket, pipe, device file, ioctl这些不象file，或者说象在file上打补丁，不是in-band传输（指read/write），而是side-band或者out-of-band（例如ioctl），都被统一了。
这个大一统的协议，叫做9P，是Plan9的最核心和唯一的接口抽象。Windows Server，鼠标键盘设备，文件服务器，都使用这个统一抽象；而且，在Plan 9上并不需要TTY（事实上也没有）。
----
9P在这样一些意义上类似HTTP，包括authentication，extension，都是in-band的传输的，例如HTTP的authentication是在header里的token或者等同的东西。
9P的实现不考虑client cache，这是和NFS或者CIFS的巨大差异，但是和HTTP非常类似，HTTP作为FS角度来实现的话，client cache也非常难做。
这个问题本身没有好的解法，例如两个客户端如果同时打开一个samba的文件，象二进制的Word格式文件，实际上是filesystem in file；如果client cache，存在一种情况是client vfs层向应用程序报告写入成功了，但是实际上这个修改无法commit因为服务器端的版本可能已经被另一个客户端修改了。
本质上这是一个资源粒度问题，HTTP server在设计上规避这个问题的办法是设计更细粒度的资源，这会污染客户端应用开发者的逻辑，它必须对数据持久层做一个可自发变动的假设而且必须应对细粒度的自发变化。
换句话说，9P在设计实现简单上，比传统nfs要更好和更加通用，但是性能不行；在细粒度化上，file system不能说不是对资源的好抽象，因为http也可以用hierarchy表述资源，但这样做的结果是违反了everything is a file的假设的，因为file就是一个原子化的资源，并没有sub file, sub sub file之类的办法细分；如果你把一个file拆成很多folder来做，那传统unix的各种stdio pipe就没那么通用了。
----
传统文件系统和HTTP RESTFUL还有一个非常重要的差异，就是资源标识是server分配还是client分配；创建一个文件要给文件名是client分配，这在RESTFUL角度看是不可理喻的，HTTP POST不是幂等操作，但是server保证标识唯一是解决冲突的特别好的办法。如果你做过文件系统同步功能就会知道这种client决定identity的文件系统设计，是fundamentally flawed，后患无穷。
----
9P仍然有在使用，最常见的一个例子是Windows的Linux子系统，使用9P把Host的文件系统映射到Linux中。为什么微软会选择9P，应该算是对它的设计简单，易于实现，以及广泛适用性的一个肯定吧。
----
Plan 9带来了很多好的设计思路，比如今天大家在BSD和Linux里看到的/proc文件系统。比如BSD的rfork和Linux的clone，比如Linux里因为容器流行而广为人知的private namespace (cgroups)，当然最最重要的，是Plan 9带来的UTF8，让所有的操作系统和计算平台都受益了。
----
那么到底，everything really is a file的抽象，是过去还是未来呢？仍然是留给开发者们思考的话题。早期的操作系统开发者更喜欢grep, awk这样的工具，如果系统坚持everything really is a file的设计，这些工具都可以重用。
但是在开发的另一端，程序员们几乎无一例外的在书写自己的grep/awk，因为他们需要结构化的数据，数据关系的表述，所以网络服务使用xml或者json吐出数据，或者干脆是用SQL实现数据访问。
在这两者之间的设计还有一种，就是象USB协议栈或者蓝牙那样定义应用层的profile，这样A生产商生产的血糖仪可以被B服务商的应用读取，算是对互操作性（interoperatability）的一个回答。但迄今为止，在应用开发领域能够这样定义成标准profile的数据结构还是太少了，例如几乎每个web服务商都有自己的user account定义，这些都是业务导向的，投资人并不会在意在这里投入。
----
而科学家们没有考虑赚钱的问题，他们是在用科学思维考虑系统应该如何重用。
Plan 9就是这样一个科学家们设计的系统。
2019-11-23 20:07:00 发布
网上翻了半个下午的Plan 9。
除了官方的文档和Paper之外资料非常少，不过还是能找到一点；Youtube上有个10年前的视频简介；用户在一个完全灰色背景的窗口上点鼠标右键，在context menu里选择new，然后用鼠标画了一个矩形区域，之后这个矩形区域就变成了Terminal，出现了命令提示符。
在一个局域网内，如果有一些预定的Global name，比如source是另一个服务器；写下命令9fs source，就会在本地文件节点上mount目标服务器的namespace。
在Plan9里最核心的抽象，仍然是everything is a file；它走得更远一步，称之为everything really is a file，意思是在传统unix里的socket, pipe, device file, ioctl这些不象file，或者说象在file上打补丁，不是in-band传输（指read/write），而是side-band或者out-of-band（例如ioctl），都被统一了。
这个大一统的协议，叫做9P，是Plan9的最核心和唯一的接口抽象。Windows Server，鼠标键盘设备，文件服务器，都使用这个统一抽象；而且，在Plan 9上并不需要TTY（事实上也没有）。
----
9P在这样一些意义上类似HTTP，包括authentication，extension，都是in-band的传输的，例如HTTP的authentication是在header里的token或者等同的东西。
9P的实现不考虑client cache，这是和NFS或者CIFS的巨大差异，但是和HTTP非常类似，HTTP作为FS角度来实现的话，client cache也非常难做。
这个问题本身没有好的解法，例如两个客户端如果同时打开一个samba的文件，象二进制的Word格式文件，实际上是filesystem in file；如果client cache，存在一种情况是client vfs层向应用程序报告写入成功了，但是实际上这个修改无法commit因为服务器端的版本可能已经被另一个客户端修改了。
本质上这是一个资源粒度问题，HTTP server在设计上规避这个问题的办法是设计更细粒度的资源，这会污染客户端应用开发者的逻辑，它必须对数据持久层做一个可自发变动的假设而且必须应对细粒度的自发变化。
换句话说，9P在设计实现简单上，比传统nfs要更好和更加通用，但是性能不行；在细粒度化上，file system不能说不是对资源的好抽象，因为http也可以用hierarchy表述资源，但这样做的结果是违反了everything is a file的假设的，因为file就是一个原子化的资源，并没有sub file, sub sub file之类的办法细分；如果你把一个file拆成很多folder来做，那传统unix的各种stdio pipe就没那么通用了。
----
传统文件系统和HTTP RESTFUL还有一个非常重要的差异，就是资源标识是server分配还是client分配；创建一个文件要给文件名是client分配，这在RESTFUL角度看是不可理喻的，HTTP POST不是幂等操作，但是server保证标识唯一是解决冲突的特别好的办法。如果你做过文件系统同步功能就会知道这种client决定identity的文件系统设计，是fundamentally flawed，后患无穷。
----
9P仍然有在使用，最常见的一个例子是Windows的Linux子系统，使用9P把Host的文件系统映射到Linux中。为什么微软会选择9P，应该算是对它的设计简单，易于实现，以及广泛适用性的一个肯定吧。
----
Plan 9带来了很多好的设计思路，比如今天大家在BSD和Linux里看到的/proc文件系统。比如BSD的rfork和Linux的clone，比如Linux里因为容器流行而广为人知的private namespace (cgroups)，当然最最重要的，是Plan 9带来的UTF8，让所有的操作系统和计算平台都受益了。
----
那么到底，everything really is a file的抽象，是过去还是未来呢？仍然是留给开发者们思考的话题。早期的操作系统开发者更喜欢grep, awk这样的工具，如果系统坚持everything really is a file的设计，这些工具都可以重用。
但是在开发的另一端，程序员们几乎无一例外的在书写自己的grep/awk，因为他们需要结构化的数据，数据关系的表述，所以网络服务使用xml或者json吐出数据，或者干脆是用SQL实现数据访问。
在这两者之间的设计还有一种，就是象USB协议栈或者蓝牙那样定义应用层的profile，这样A生产商生产的血糖仪可以被B服务商的应用读取，算是对互操作性（interoperatability）的一个回答。但迄今为止，在应用开发领域能够这样定义成标准profile的数据结构还是太少了，例如几乎每个web服务商都有自己的user account定义，这些都是业务导向的，投资人并不会在意在这里投入。
----
而科学家们没有考虑赚钱的问题，他们是在用科学思维考虑系统应该如何重用。
Plan 9就是这样一个科学家们设计的系统。