设备即终端 | Device as a Terminal

这并不是什么新的技术，事实上这是一种返璞。甚至这根本不是一个技术，而是一种看待设备的方式。

所谓设备即终端，全名是设备即云的终端，Device as a Terminal of a Cloud. 它的核心思想就是用户的设备将不再是独立的个体，而是访问云的一种手段。用户的计算和数据均可以在云上运行和存储。这样，当用户需要更改设备时，将不需要重新设置设备，数据可以从旧设备迁移到新设备以及为当前设备提供恢复服务。

注意到这里的云并不是某个具体的云，冠词 'a' 也提示了这一点。这个云可以是个人云（就地部署）、私有云（企业内部服务）或者公有云（公共平台服务），这并不重要。

让我们说一些技术细节，或者说技术问题吧。

文件存储和共享

当然我们最关心的自然是文件的存储和共享——我们希望资料不会因为设备的丢失而丢失。我们希望能够在多个设备之间共享文件。

文件存储和设备间的共享是最基础的 DaaT 功能，事实上，你可能已经在用了。OneDrive 是 Windows 10 内嵌的实现；或者你更愿意用百度网盘；或者你在自己的服务器上部署了 ownCloud/nextCloud. 抑或是硬核的 NFS + Kerboros / WebDAV. 具体的实现有很多，当然我们也可以纯粹为了 DaaT 单独再给出一个协议，这取决于实现。

我们更希望这种共享拥有一个更好的性质——设备文件的共享。

设备角色

但并不是所有平台都有设备文件这个东西，也并不是所有设备我们都希望暴露在公网中，哪怕 DaaT 是有认证这个说法的。以及，所谓的云就是别人的电脑，那么这些所谓「别人的电脑」，是否是一个终端呢？

所以，需要为设备划分角色。有些设备，比如手机，是典型的终端角色；而你的服务器则是云的角色。当然，我们可以引入更细化的划分，或者就按照设备类型进行角色安排。

迁移和恢复

现在，我们有了文件共享，有了设备的角色分配，那么对于终端角色，它们作为可替代设备，应该支持迁移和恢复。但是实际上我们会发现恢复本身就是一个十分复杂的过程。

对于计算机而言，其恢复过程还算是比较简单——我们可以跟踪文件的更改，或者为磁盘创建映像；当需要的时候可以回滚到最近的映像。这个技术已经很成熟了。迁移过程要更复杂一些，因为目标平台的组态和映像组态可能并不一致，但我们仍然可以尝试使用自动部署的思路创建映像。

比起计算机（或者说 IBM 兼容平台），手机的恢复和迁移则更要复杂一些。

任何给自己的手机刷过机的同志应该能感受到变砖的绝望和救砖的艰辛。这样一个过程对于不同的手机型号而言都是不同的，对这个过程的自动化的尝试很有可能是徒劳的。

那么，更简单的恢复——用户数据的恢复，可能么？这是可以的，但也是有限的。一是在部分平台上，应用本身不具有读取和写入其他应用的数据的能力；二是部分用户数据的恢复是没有意义甚至是灾难性的，比如一些锁文件、会话文件和数据库文件。要解决这个问题，要么靠某种方法或者平台提供的 API 来指明文件类型，要么通过一些标记指示这些文件不参与备份过程。

如果我们能做到用户数据的恢复，用户数据的迁移似乎并不复杂，因为迁移和对拷有相似之处。但是我们可能会遇到一个很有趣的情况：部分设备的组态应该不同与其他设备，比如一部分电脑使用 Windows 而另一部分使用 Linux; 使用 Linux 的部分则又细分发行版，每个发行版运行的内容并不相同。以及新设备并不是总是优于旧设备的，比如新设备的存储空间要小于旧设备，此时对拷操作就不可用了，用户必须选择要迁移哪些数据。

我们可以换个角度来看问题。恢复和迁移的核心目的是在更换终端之后仍旧能无障碍地访问云，那么用户数据本身就不应该依赖于终端——尽管终端具有存储能力，但是我们应该将其视作云端数据的缓存；当用户更换终端时，只是需要将缓存重新读入终端而已。

分布式计算

虽然说终端上的数据是云端数据的缓存，并不是意味着终端一无是处了。终端的计算能力作为硬件资源仍然是需要利用的。

不过这简直是天马行空。首先一个最基础的问题就是我们并不知道哪些运算资源是可以被利用的、哪些任务是可以分布式运行的，这需要应用程序本身的显式支持。不过好在显然需要进行分布式计算的应用程序，比如渲染、科学计算和仿真都已经有官方或社区提供的分布式计算方案。但是这些方案仍然需要由用户手动部署，而且方式不尽相同。而且大部分的并行运算节点都只运行在 IBM 兼容平台上。

异构计算尚且属于新技术，而且我们也容易了解 ARM 平台的优势在于功耗而不在于计算，但为什么不呢？毕竟我们有 big.LITTLE 这样的架构。当然，目前而言，我们需要先设计多个平台上的统一计算语言，然后再将现有的程序进行移植。工程量巨大。

可用性和易用性

但不是所有终端都是可靠的。既然我们的目标是某种分布式的结构（因为我们考虑的是「云的终端」，而「云就是别人的电脑」，从而使得这个结构成了某种有中心节点的分布式结构），我们就必然面临分布式结构所要面临的问题。首先是云的可用性；另一个是分布式节点的可用性。云的可用性尚可保证，因为一般云会是公网上的某个或某些机器；但分布式节点的不稳定性就太高了。

以及尽管我们有这样的愿景，但是没有用户的支持，只能成为一种内部工具，而不是某种通用的技术标准。一般而言我们希望这种技术是开箱即用的，至少能做到「仅配置一次」。但仅仅文件同步我们就难以实现开箱即用，之后的内容要怎样才能做呢？或许可以以后专门研究这些内容吧。