CH3&CH10 modification

Ch1-3-SystemSoftware.tex

@@ -1,7 +1,7 @@
 % !TEX root =  main.tex
 
 
-\section{系统软件内涵与知识体系}
+\section{概述}
 系统软件\index{系统软件}是驱动下层计算资源有效运转、为上层应用提供共性支撑的软件，主要包括操作系统、编译系统、中间件和数据库管理系统。其中，操作系统\index{操作系统}负责管理计算系统软硬件资源、操纵程序运行，为应用软件提供公用支撑；编译系统（又称编译器）负责将源语言编写的源程序翻译为等价的可运行目标程序；中间件将系统软件的概念扩展到网络环境，为分布式应用软件部署、运行和管理提供支撑；数据库管理系统旨在统一管理和维护数据库中的数据，是组织、存储、存取、控制和维护数据的软件。
 
 与面向特定领域、解决特定问题的应用软件不同，系统软件是运行于计算“系统”层面上的软件。此处的“系统”有两层含义：
@@ -11,7 +11,7 @@
 	\item 系统软件是驱动计算系统有效运转的控制器/协调者。系统软件一方面与计算系统中各类硬件资源直接交互，管理、调度和使用这些资源，使得之可以高效协同；另一方面系统软件也直接操纵管控上层应用的运行，从而达到提高程序装载和调度的自动化程度、提高资源利用率等目标。例如，操作系统可以通过批处理、分时共享等方法来实现计算系统作业任务切换，因此早期也被称为“监督程序”（Supervisory Program）或“控制程序”\cite{bullynck2018operating}。
 \end{itemize}
 
-系统软件并不是与计算机一起诞生的，它的出现有内因和外因两个方面。早期的计算机（如ENIAC）编程采用接线和开关等手工操作方式，并没有系统软件的概念。即使在存储程序计算机出现之后，系统软件也并未马上出现，应用直接在裸机上运行。但是，将应用与硬件祼机直接绑定，无论是编程难度、应用管理/切换效率还是底层资源利用率都十分低下。特别是早期CPU速度和I/O速度之间的巨大差异，基于时分复用的“虚拟化”成为客观需求，推动了系统软件、尤其是操作系统的快速发展。系统软件出现的外因则是软件复杂性增长所导致的分工细化，特别是上个世纪50-60年代，面向底层硬件资源的系统程序设计（System Programming）和面向领域的应用程序设计（Application Programming）的分化，以及系统程序员和应用程序员的分工，直接推动了系统软件这一概念的广泛接受。
+系统软件并不是与计算机一起诞生的，它的出现有内因和外因两个方面。早期的计算机（如ENIAC）编程采用接线和开关等手工操作方式，并没有系统软件的概念。即使在存储程序计算机出现之后，除了汇编器等带有系统软件思想的工具外，操作系统等主流系统软件并未马上出现，应用仍是直接在裸机上运行。但是，人们很快认识到，将应用与硬件祼机直接绑定，无论是编程效率、应用管理/切换效率还是底层资源利用率都十分低下。特别是早期CPU速度和I/O速度之间的巨大差异，基于时分复用的“虚拟化”成为客观需求，推动了系统软件、尤其是操作系统的快速发展。系统软件出现的外因则是软件复杂性增长所导致的分工细化，特别是上个世纪50-60年代，面向底层硬件资源的系统程序设计（System Programming）和面向领域的应用程序设计（Application Programming）的分化，以及系统程序员和应用程序员的分工，直接推动了系统软件这一概念的广泛接受。
 
 \section{操作系统}
 从功能定位的角度而言，操作系统\index{操作系统}是负责管理硬件资源、控制程序运行、改善人机界面和为应用提供支持的系统软件，是计算机软件生态链的基础核心。在一个计算系统中，操作系统向下是最靠近硬件的一层软件，它通过调用硬件驱动程序、固件等方式实现对硬件的管理；向上屏蔽硬件细节，为应用软件提供功能更为完善、灵活可编程的“虚拟机”，并通过事件循环等实现对各类应用软件的运行管理。因此，操作系统兼具“承上启下”和“管家”两类作用。由于操作系统的特殊地位，其发展与上层应用需求和底层硬件形态的演化都有着密切联系。从最初与硬件和应用场景高度绑定，到之后逐渐独立于硬件，操作系统向上提供的服务越来越多、向下针对硬件的抽象程度越来越高，其内涵和外延不断拓宽，并在积累一段时间后产生质变，呈现出主机计算、个人计算、互联网和移动计算等明显阶段性特点（图\ref{fig:3-1}）。
@@ -23,14 +23,14 @@
 		\label{fig:3-1}}
 \end{figure}
 
-\subsection{操作系统的出现（20世纪50年代）}
+\subsection{单道批处理操作系统}
 早期的存储程序计算机并没有操作系统，需由用户或专门操作人员（Operator）管理计算任务，包括装入打孔卡片或纸带、通过包含开关和指示灯的控制面板来了解状态、在出错时进行必要干预等。这一方式可以满足早期少量科学计算的需要。但是随着计算机应用领域从传统科学计算领域向国防、政府、商业等通用领域拓展，计算任务及相关的数据量迅速增长，手工管理成为了制约计算机利用效率的瓶颈问题。用软件来代替操作人员实现计算任务自动管理（包括载入和执行），这是操作系统最早出现的动因之一，并直接催生了第一代的批处理操作系统\index{批处理操作系统}。由于其强调替代人进行监管，这一时期的操作系统雏形多被冠以“控制程序/例程”（Control Program/Routine）、“管程”（Monitor）、“监督例程”（Supervisory Routine）等名称。典型实例是通用汽车与北美航空于1956年基于IBM 704所开发的GM-NAA IO系统\cite{patrick1987general}，其核心的管程可以从磁带上自动顺序读入和批量执行应用程序。该系统通常被认为是第一个成熟的商用操作系统，在20世纪50年代末被移植到多个巨型机上。
 
 操作系统出现的另一个背景是20世纪 50年代计算机技术的革新，特别是磁芯内存、磁带等大容量高速存储技术的应用，以及从早期打孔卡片发展而来的“文件”等抽象的出现，使得专业化的大型软件成为可能，软件开发作为一个独立行业开始从硬件设计制造中分离出来。人们针对“如何提高软件开发的效率”这一问题进行初步探索，催生了Fortran等高级语言的出现，也在这一过程中积累了大量工具、编译器、可重用例程和库等。由于软件开发与运行密切相关，因此在这一时期，许多操作系统与编程系统并未严格区分，典型实例包括MIT的CSSR（Comprehensive System of Service Routines）\cite{Bennington:1956:LLU:1455410.1455416}、ERA 1103（UNIVAC 1103A）计算机所配备的“集成计算系统”\cite{Bauer:1956:ICS:320831.320836}等。这类系统通常具备运行时批处理功能，但更强调对开发的支持，其核心是一系列可重用库和辅助工具（Utility Tool）。这也是今天操作系统“沉淀共性问题解决方案”能力的来源。
 
-虽然第一代操作系统以批处理模式为主，但由于指挥控制、工业自动化等领域对计算机的迫切需求，早期人们即在实时（或者至少能够在线处理的）操作系统方面开展了实践。典型案例是上个世纪50年代美国军方半自动地面防空系统（Semi Automatic Ground Environment，SAGE）项目，这一系统通过多个主机实现了雷达数据的实时汇聚、处理和态势生成，其操作系统能够实现计算和I/O操作过程的交叠，在部份文献中被认为是首个实时操作系统\index{实时操作系统}。
+虽然第一代操作系统以批处理模式为主，但由于指挥控制、工业自动化等领域对计算机的迫切需求，早期人们即在实时（或者至少能够在线处理的）操作系统方面开展了实践。典型案例是上个世纪50年代美国军方半自动地面防空系统（Semi Automatic Ground Environment，SAGE）项目\footnote{https://en.wikipedia.org/wiki/Semi-Automatic\_Ground\_Environment}，这一系统通过多个主机实现了雷达数据的实时汇聚、处理和态势生成，其操作系统能够实现计算和I/O操作过程的交叠，在部份文献中被认为是首个实时操作系统\index{实时操作系统}。
 
-\subsection{主机计算时代的操作系统（50年代-70年代）}
+\subsection{多道和分时主机操作系统}
 在大型主机时代，操作系统的发展主要围绕提高计算资源的利用率和提高操作系统的抽象能力两条主线展开：
 
 \begin{enumerate}[(1)]
@@ -53,7 +53,7 @@
 	
 \end{enumerate}
 
-\subsection{计算机普及时代的操作系统（70年代-21世纪初）}
+\subsection{个人/嵌入式操作系统}
 20世纪70年代集成电路技术的高速发展推动了微处理器的出现，使得计算技术由“旧时王谢堂前燕，飞入寻常百姓家”，具体表现为：一方面，个人计算机迅速普及，产品和技术快速发展，使得能“兼容”多种软硬件的操作系统成为主流，而且用户的非专业化使得图形用户界面成为主流操作系统的内嵌能力；另一方面，由于工业控制、航空航天、武器装备等领域微处理器的应用，嵌入和实时操作系统作为操作系统的一个分支开始登上历史舞台。此外，这一时期的开源操作系统对本领域后续发展产生了深远影响。
 
 \begin{enumerate}[(1)]
@@ -61,37 +61,22 @@
 	
 	70年代中期Intel发布8080 CPU以后，Digital Research发布了最早的微型计算机操作系统CP/M-80，它由基本输入输出系统（Basic Input/Output System，BIOS）、基本磁盘操作系统和控制台命令处理程序组成。其中，基本输入输出系统的引入，实现了操作系统其它模块与低层具体硬件的解耦，显著提高了操作系统的适用性和上层应用的可移植性。这种操作系统与具体硬件解耦的思想拓展了System/360大型机时代所提出的“兼容”概念，被后来的微软MS-DOS（Microsoft Disk Operating System）等操作系统所延续，直接为个人计算机软硬件生态链的快速发展奠定了基础。
 	
-	在个人计算时代，操作系统的另一个重要进展是图形用户界面的加入。早在1973年，Xerox即推出了支持可视化操作的Alto计算机，并于1981年发布了集成完整图形化桌面的操作系统Xerox 8010 Star；1984年Apple发布了具有图形用户界面的个人计算机Lisa；1985年微软公司发布了Windows系列操作系统。图形用户界面的发展极大地促进了个人计算机的普及：由于个人计算机面对的不是专业用户，易用性成为了操作系统的瓶颈问题，因此基于窗口和鼠标的直观操作取代了繁琐晦涩的命令行界面。
+	在个人计算时代，操作系统的另一个重要进展是图形用户界面的加入。早在1973年，Xerox即推出了支持可视化操作的Alto计算机，并于1981年发布了集成完整图形化桌面的操作系统Xerox 8010 Star；1984年Apple发布了具有图形用户界面的个人计算机Lisa；1985年微软公司发布了Windows系列操作系统。图形用户界面的发展极大地促进了个人计算机的普及：由于个人计算机面对的不是专业用户，易用性成为了操作系统的瓶颈问题，因此基于窗口和鼠标的直观操作取代了繁琐晦涩的命令行界面。在此基础上，浏览器、音/视频播放器等一些常用软件开始被打包内置到操作系统中，拓展了操作系统“沉淀共性问题解决方案”这一角色的内涵，也即不仅提供运行库供上层应用调用，也能直接支撑用户使用计算机完成常用功能。
 	
 	此外，90年代初Linux\index{Linux}操作系统以开源软件形式出现，对操作系统技术、产品、产业乃至于相关法律政策、社会文化等都产生了重大影响。开源作为一种群智汇聚、群体协作的有效方式，一方面可以有效推动操作系统产品的发展，应对操作系统自身的复杂性；另一方面，一个操作系统能否被广泛接受也取决于其生态链的完善程度，而开源则为生态链构建提供了一种基于众包的新模式。
 	
 	\item 嵌入和实时操作系统
 	
-	20世纪70年代单片机出现是计算机发展史上的重要事件之一，它使得在各类设备中“嵌入”计算机成为可能，可被视为最早的“信息物理融合”（Cyber-Physical）尝试。针对嵌入式设备，80年代现代意义上强调轻量级的嵌入式操作系统\index{嵌入式操作系统}开始出现，此类操作系统需要在资源受限环境下运行，并且由于其与物理世界直接交互，往往需要提供对实时性（时间可预测性）的保证。首个商业嵌入式实时操作系统内核VTRX32于1981年发布，后续涌现出了vxWorks、uCOS、QNX等一系列被广泛应用的嵌入实时操作系统产品。	
+	20世纪70年代单片机出现是计算机发展史上的重要事件之一，它使得在各类设备中“嵌入”计算机成为可能，可被视为最早的“信息物理融合”（Cyber-Physical）尝试。80年代，强调轻量级的嵌入式操作系统\index{嵌入式操作系统}开始出现，此类操作系统需要在资源受限环境下运行，并且由于其与物理世界直接交互，往往需要提供对实时性（时间可预测性）的保证。首个商业嵌入式实时操作系统内核VTRX32于1981年发布，后续涌现出了vxWorks、uCOS、QNX等一系列被广泛应用的嵌入实时操作系统产品。
 	
 \end{enumerate}
 
-\subsection{互联网和移动计算时代的操作系统（21世纪初-）}
+\subsection{移动操作系统}
 进入21世纪，新型计算模式不断出现，计算技术表现出向两极发展的趋势：一方面以“云”为核心，强调通过资源集约化和按需服务方式，推动信息技术实现社会化和专业化；另一方面以“端”为核心，强调信息技术的普适化，使得计算服务如同水、电、空气一样随时随地可以获取而又不可见。需要指出的是，“云”和“端”二者并非割裂的，而是优势互补，正在通过“云+端”等形式共同推动着计算技术的新一轮革命。
 
-\begin{enumerate}[(1)]
-	\item 云计算操作系统
-	
-	近年来，作为服务化思想的集大成者，云计算模式被广泛接受，云计算操作系统的概念开始出现。云计算操作系统\index{云计算操作系统}是指架构于云计算数据中心各类硬件资源之上，实现“基础设施即服务”、“平台即服务”等目标的系统软件，其典型代表包括Google AppEngine、Microsoft Azure等。此类操作系统具有如下一些特征：
-	
-	\begin{itemize}
-		\item 在资源的管控方面，此类操作系统的核心是大型主机时代即已出现的虚拟化技术，但将其应用场景拓展到了数据中心甚至多数据中心级别的，通过虚拟化实现海量计算、网络、存储资源的细粒度管理，进而实现资源的有效聚合和弹性扩展。例如，互联网虚拟计算环境 iVCE\cite{Lu:2013:IVC:2388122.2388238}通过资源的“自主协同、按需聚合”，将静态统一视图的资源组织模式扩展为相对稳定视图、按需可伸缩的资源组织模式，从而实现面向互联网计算的高效管控。
-		\item 在应用软件的执行管控维度上，此类操作系统面向云服务这类大规模分布计算软件，提供了任务调度与执行、负载均衡、安全管控、在线监控和升级演化、分布式数据存储访问等一系列基础设施和相应能力。这些能力以的服务化方式提供，用户无需像传统系统软件那样自行安装、部署和维护。部分“平台即服务”基础设施还内建了编译系统和调测试环境，支持云端开发和编译构建。
-		\item 在可用性方面，此类操作系统需要 7×24小时持续提供基础服务，是支撑整个信息空间持续运行的核心基础设施。其突出表现为一旦发生故障，会产生较大的社会经济影响。例如，有文献指出如果一个主要的云平台宕机3－6天，美国经济会产生30亿－150亿美元的损失\footnote{``Cloud Down: Impacts on the US economy,''  https://www.lloyds.com/~/media/files/news-and-insight/risk-insight/2018/cloud-down/aircyberlloydspublic2018final.pdf}。
-	\end{itemize}
-	
-	\item 智能终端操作系统
-	
-	当前，已经广泛商用的移动操作系统\index{移动操作系统}是“端”操作系统的典型代表。近年来，移动计算、特别是智能手机的出现，推动了移动操作系统的快速发展，典型实例包括Google的Android和Apple的iOS。此类操作系统在架构上与个人计算机操作系统并无本质区别，但更强调对移动和手持环境的支持，包括移动网络接入、各类传感器数据获取、电池管理、触摸屏交互等。与个人计算时代类似，操作系统在移动计算软硬件生态链中同样具有核心基础地位，特别是操作系统内置应用商店的出现和广泛接受，在降低用户查找、获取和安装应用程序难度的同时，也形成了较完善的商业模型，极大推动了以操作系统为核心的软件生态链的成长。移动操作系统当前还表现出了与桌面系统一体化的发展趋势，通过统一桌面和移动操作系统及其生态，将有利于操作系统更好地发展与维护。例如，谷歌继移动操作系统Android和轻量级桌面操作系统ChromeOS之后，正在研制跨平台的Fuchsia操作系统。
+当前，“云”上的系统软件形态主要以“平台即服务”基础设施等形式出现，它们运行于经典操作系统（如Linux）之上，可被视为中间件技术的发展（参见\ref{internet-middleware}节）。“端”操作系统的代表则是已经广泛商用的移动操作系统\index{移动操作系统}，典型实例包括Google的Android和Apple的iOS。此类操作系统在架构上与个人计算机操作系统并无本质区别，但更强调对移动和手持环境的支持，包括移动网络接入、各类传感器数据获取、电池管理、触摸屏交互等。与个人计算时代类似，操作系统在移动计算软硬件生态链中同样具有核心基础地位，特别是操作系统内置应用商店的出现，在降低用户查找、获取和安装应用程序难度的同时，也形成了较完善的商业模型，极大推动了以操作系统为核心的软件生态链的成长。移动操作系统当前还表现出了与桌面系统一体化的发展趋势，通过统一桌面和移动操作系统及其生态，将有利于操作系统更好地发展与维护。例如，谷歌继移动操作系统Android和轻量级桌面操作系统ChromeOS之后，正在研制跨平台的Fuchsia操作系统。
 
-	近年来，以Android Things、Ubuntu Core、Mbed和华为“鸿蒙”等为代表的物联网操作系统\index{物联网操作系统}正在成为操作系统领域新的热点。此类操作系统在嵌入式操作系统基础上，一方面强调对“连接”、以及建立在连接基础上的分布计算甚至“云-端”融合的支持，从而有力支撑“万物互联”的目标；另一方面强调对异构物理网设备能力的统一抽象，从而屏蔽物联网设备的碎片化特征，为提升物联网的可管理性和可维护性、构建物联网良好生态环境奠定基础
-	
-\end{enumerate}
+近年来，以Android Things、Ubuntu Core、Mbed和华为“鸿蒙”等为代表的物联网操作系统\index{物联网操作系统}正在成为操作系统领域新的热点。此类操作系统在嵌入式操作系统基础上，一方面强调对“连接”、以及建立在连接基础上的分布计算甚至“云-端”融合的支持，从而有力支撑“万物互联”的目标；另一方面强调对异构物理网设备能力的统一抽象，从而屏蔽物联网设备的碎片化特征，为提升物联网的可管理性和可维护性、构建物联网良好生态环境奠定基础。
 
 \section{编译系统}
 编译系统\index{编译系统}是将源语言（例如高级程序设计语言）编写的代码翻译为等价的、高效的、能被计算机或虚拟机执行的目标代码（例如机器语言）的系统软件。编译系统的诞生早于操作系统，但如前节所述，由于软件开发与运行的密切相关性，在计算机发展早期，通常并不严格区分操作系统（Operating System）和编程系统（Programming System），仅仅是后者更强调其对开发的支持，内置了编译能力、开发辅助工具和可重用例程/库等。随着程序设计语言的变迁、特别是高级语言的出现，编译系统逐渐成为系统软件的一个主要分支，其内涵和外延随语言和计算机体系结构的发展而不断扩展（图\ref{fig:3-2}）。
@@ -102,20 +87,23 @@
 	\caption{编译系统发展历程
 		\label{fig:3-2}}
 \end{figure}
+
+\subsection{从汇编器到高级程序编译器}
+
 作为机器体系结构抽象的符号化语言，汇编语言的目标是提高编程效率和质量。然而，计算机能读懂的只有机器指令，此时需要一个能够将汇编指令转换成机器指令的翻译程序。1947年伦敦大学伯贝克学院的Kathleen Booth为ARC2计算机开发了第一个汇编语言及其机器汇编器。之后不久，开始出现带有支持代码“库”的计算机，预先记录在打孔卡片和磁带上的支持代码库能够在装载器（Loader）的支持下与用户程序进行连接，从而支持输入输出等操作。这就是编译系统这种系统软件类型最早的雏形。
 
 虽然汇编语言相对于机器语言提高了程序的可读性，但编写、阅读和理解汇编语言的难度依然较高。20世纪50年代初，Grace Hopper在UNIVAC I上首次使用了“编译器”（Compiler）一词。在她所实现的编译器雏形中，磁带上的每段例程由一个数字代码标识，用户输入一组数字代码，来使得计算机依次加载这些例程。Grace Hopper工作证明了高级语言（数字代码）向机器语言（磁带上例程中所包含机器指令序列）映射的可行性。在此基础上，更为激进的“自动编程”（Automatic Programming）的概念\cite{hopper1953influence}被提出，希望能够采用接近于人类自然语言的语言编写程序，依据这些程序自动生成可执行的机器代码，从而显著提高程序开发效率和质量、便于程序的理解阅读和维护。在这一思想的驱动下，上个世纪50年代出现了第一个高级程序设计语言——为IBM 704大型机设计的Fortran语言\cite{Backus:1978:HFI:960118.808380}。1957年发布的Fortran编译器则是第一个功能比较完备的高级程序语言编译器。它也是第一个具备优化能力的编译器，引入了循环优化、寄存器分配等技术，使编译器翻译的机器代码能够与当时人工编写的汇编程序性能相当。
 
-\subsection{程序设计语言驱动的编译系统发展（60年代-90年代）}
+\subsection{面向程序设计语言的编译系统}
 在高级程序设计语言出现以后，程序设计方法学和程序设计语言飞速发展，诸如结构化程序设计\index{结构化程序设计}、面向对象程序设计\index{面向对象程序设计}、函数式程序设计\index{函数式程序设计}、逻辑程序设计\index{逻辑程序设计}等方法和语言百花齐放，直接推动了编译技术和编译系统的发展。
 
-20世纪50年代末，COBOL（Common Business-Oriented Language）语言诞生\cite{Sammet:1978:EHC:960118.808378}。与Fortran主要面向科学计算不同，COBOL是用于商务数据处理的语言，也是第一个跨平台的高级程序设计语言。1960年，由不同编译器编译的同一COBOL程序成功在UNIVAC II和RCA 501机上运行，表明了。70年代初，美国Bell实验室以开发了B语言和B语言编译器，并用B语言编写了第一个UNIX操作系统内核。在B语言基础上，Bell实验室经过进一步改进完善后发布了C语言及其编译器。
+20世纪50年代末，COBOL（Common Business-Oriented Language）语言诞生\cite{Sammet:1978:EHC:960118.808378}。与Fortran主要面向科学和工程计算不同，COBOL是用于商务数据处理的语言，也是第一个跨平台的高级程序设计语言。1960年，由不同编译器编译的同一COBOL程序成功在UNIVAC II和RCA 501机上运行，表明了。70年代初，美国Bell实验室以开发了B语言和B语言编译器，并用B语言编写了第一个UNIX操作系统内核。在B语言基础上，Bell实验室经过进一步改进完善后发布了C语言及其编译器。
 
-相对于Fortran和 C等命令式高级语言，面向对象语言也在这一时期得到发展。20世纪 60年代的SIMULA67语言\cite{Dahl:1968:FSL:800166.805258}引入了类和对象的概念，被认为是世界上第一个面向对象语言。70年代出现的Smalltalk语言支持类的动态创建和修改。受到C和SIMULA67语言的影响，Bell实验室在八十年代开发了C++，随后开发了支持C++的Cfront编译器。20世纪90年代，随着C++等语言的流行，面向对象语言成为主流的编程语言，重要标志是GCC编译器（GNU Compiler Collection）走向成熟，以及Java面向对象语言和编译器的发布。这一时期互联网的发展也促进了编程语言及其编译/解释执行系统的发展，例如出现了互联网开发、在运行时检查类型甚至改变程序结构的动态语言（如PHP、Ruby等）。
+相对于Fortran和C等命令式高级语言，面向对象语言也在这一时期得到发展。20世纪60年代的SIMULA67语言\cite{Dahl:1968:FSL:800166.805258}引入了类和对象的概念，被认为是世界上第一个面向对象语言。70年代出现的Smalltalk语言支持类的动态创建和修改。受到C和SIMULA67语言的影响，Bell实验室在八十年代开发了C++，随后开发了支持C++的Cfront编译器。20世纪90年代，随着C++等语言的流行，面向对象语言成为主流的编程语言，重要标志是GCC编译器（GNU Compiler Collection）走向成熟，以及Java面向对象语言和编译器的发布。这一时期互联网的发展也促进了编程语言及其编译/解释执行系统的发展，例如出现了互联网开发、在运行时检查类型甚至改变程序结构的动态语言（如PHP、Ruby等）。
 
 60-70年代，编译系统的基础理论和相关技术也开始成熟。20世纪50年代，Noam Chomsky通过研究自然语言结构提出Chomsky文法类型，其中上下文无关文法成为现今几乎所有程序设计语言的语法\cite{chomsky1956three}。60年代至80年代，用于上下文无关文法识别的有效算法逐步发展为编译原理的标准部分，同时科学家们着眼研究编译器的自动构造，典型实例包括为UNIX操作系统研制的词法分析器生成工具Lex和语法分析器生成工具Yacc。编译系统中的代码优化研究也起步于这一阶段，包括与处理器体系结构无关的优化（如循环变换、常量传播、公共表达式删除）以及与处理器体系结构相关的优化（如寄存器分配、指令调度），后者与当时精简指令集、超标量、超长指令字等体系结构技术的发展密不可分。
 
-\subsection{多核/众核架构驱动的编译系统发展（21世纪-）}
+\subsection{针对多核/众核架构优化的编译系统}
 提高处理器性能是计算机领域长期追求的目标。随着处理器功耗、散热和设计复杂度等原因，在单核处理器上提高时钟频率的方法已无法继续提高处理器性能。因此，学术界和工业界开始改变策略，通过增加处理器核心数目来扩展性能。2001年，第一款商用非嵌入式多核处理器IBM POWER4发布，计算机体系结构发展进入多核时代。然而，增加处理器核数并不必然带来应用性能的提升，需要充分挖掘应用中的并行性以利用处理器的多核特性。在编译系统中挖掘并行性，具有对程序员透明、有可能在机器指令层面发挥硬件潜力等特点，因此当前的主流编译器（如GNU GCC、Intel ICC、IBM XLC和Oracle Compiler）均提供了对多核心的支持和优化。
 
 与多核处理器通常仅集成几个处理单元不同，众核处理器在同一处理器内部集成了大量同构处理单元。例如，GPU（Graphics Processing Unit）在一个芯片上集成数百甚至数千个“小而简单”的核心，通过使用大量线程并发提高性能，特别适合用于加速大规模并行应用。近年来，众核处理器在高性能计算、人工智能等领域发展迅速，其编译优化技术也随着体系结构的不断升级而进步，包括针对GPU不同存储层次的优化、程序并行度的自动调优、通信优化、针对宽向量的自动向量化等。
@@ -132,7 +120,7 @@
 		\label{fig:3-3}}
 \end{figure}
 
-\subsection{中间件的出现（20世纪60年代中后期-80年代）}
+\subsection{早期的中间件}
 中间件的出现是软件系统应用场景快速拓展的结果。随着计算技术的发展，上层应用在适应新场景过程中对系统软件不断提出新的要求，而作为底层支撑的经典操作系统能力相对稳定固化，很难快速跟上这些变化，二者之间的差距决定了中间件存在的合理性。在1968年北大西洋公约组织的软件工程报告中，“中间件”一词被首次使用\cite{buxton1970software}，代指弥补底层操作系统（当时称“服务例程/控制程序”）通用能力和上层应用特化需求之间鸿沟的中间层软件（图\ref{fig:3-4}）。1972年Jenkin等撰文指出，“随着一些系统变得空前复杂，标准的操作系统需要扩展或修改，推动了‘中间件’这一名词出现”\cite{jenkins1972developments}。
 
 \begin{figure}[htbp]
@@ -146,25 +134,35 @@
 
 为了应对上述挑战，人们早期围绕两种思路展开了探索。一是以Amobea\cite{Tanenbaum:1990:EAD:96267.96281}等分布式操作系统为代表的方法，核心是将单机操作系统的概念放大到网络环境，实现对网络软硬件资源的严格管控，例如文献\cite{Tanenbaum:1985:DOS:6041.6074}指出“分布式操作系统对用户而言与单机操作系统无二，只是运行在多个独立处理器上。它的核心概念是透明性”。但是，网络资源具有分布自治、高度异构、持续演化等特点，其软件很难通过严格的以自顶向下的方法精确设计出来，而更多的是通过互联互通方式成长式构造出来的。后一种思路在1976年的ARPANET RFC707中即以“允许调用远程进程所实现的任意命令或函数”的“请求-响应”协议形式出现\footnote{IETF, ``RFC 707 - High-level framework for network-based resource sharing,'' 1977}。Birrel和Nelson等于1984年实现了首个远程过程调用（Remote Procedure Call，RPC）\index{远程过程调用}框架\cite{Birrell:1984:IRP:2080.357392}，标志着现代意义中间件的诞生。
 
-\subsection{企业计算时代的中间件（80年代-21世纪初）}
-如前所述，最早出现的中间件是面向过程中间件\index{面向过程中间件}。早期的Sun RPC、开源软件基金会的DCE（Distrbuted Computing Environment）等都是具有代表性的此类中间件，聚焦于尽量实现“调用远程过程像调用本地过程一样简单”。相对于过程，“对象”提供了更贴近现实世界的抽象。面向对象中间件\index{面向对象中间件}出现于上个世纪80年代初，例如华盛顿大学1980年启动的Eden项目\cite{Black:1985:SDA:323627.323646}即以在网络计算环境中应用面向对象技术为目标，提出了分布式Ejects（Eden objects）的概念、编程模型和相应支撑平台。OMG于1990年发布CORBA 1.0是具有里程碑意义的面向对象中间件标准，直接推动了面向对象中间件的成熟和高速发展，对后续SUN公司的Java/RMI、微软公司的DCOM等技术体系有着直接和深远的影响。
+\subsection{面向内联网的中间件}
+中间件在诞生之后的很长一段时间内，都以企业或组织内部的内联网（Intranet）为运行环境，为明确边界范围的域内资源互联互通提供系统软件支撑。如前所述，最早被广泛接受的此类中间件是面向过程中间件\index{面向过程中间件}。它们聚焦于尽量实现“调用远程过程像调用本地过程一样简单”，早期的Sun RPC、开源软件基金会的DCE（Distrbuted Computing Environment）和今天的Google gRPC、Apache Thrift等都是典型实例。
+
+相对于过程，“对象”提供了更贴近现实世界的抽象。面向对象中间件\index{面向对象中间件}出现于上个世纪80年代初，例如华盛顿大学1980年启动的Eden项目\cite{Black:1985:SDA:323627.323646}即以在网络计算环境中应用面向对象技术为目标，提出了分布式Ejects（Eden objects）的概念、编程模型和相应支撑平台。OMG于1990年发布CORBA 1.0是具有里程碑意义的面向对象中间件标准，直接推动了面向对象中间件的成熟和高速发展，对后续SUN公司的Java/RMI、微软公司的DCOM等技术体系有着直接和深远的影响。
 
 分别发布于1998年和2000年的EJB（Enterprise JavaBean）和CCM（CORBA Component Model）推动了面向构件中间件\index{面向构件中间件}的出现。面向构件中间件又被称构件容器或构件化应用服务器，它是以构件为基本单元的分布式软件的运行平台。构件技术一方面强调通过大粒度、具有规范接口的软件单元来组装软件系统，另一方面由于构件具有规范的功能和管理接口，因此运行时可以对分布式系统进行灵活管理操纵，包括生命周期管理、交互关系管理甚至动态更新演化等。
 
 除了上述支撑不同应用程序模型的通用中间件外，部份中间件关注的是分布式软件的一些特化场景，其典型代表是消息中间件\index{消息中间件}和事务处理中间件\index{事务处理中间件}：（1）在分布计算实践的初期，人们就已发现紧耦合、同步的过程调用并不能满足所有应用场合，支持异步交互和松耦合通信的分布式应用消息机制的研究和实践开始被重视，诸如Field、InformationBus等消息中间件平台开始出现。上个世纪90年代，IBM MQSeries等消息中间件产品被大量使用，消息中间件技术走向成熟。（2）在大型主机时代，IBM的CICS（Customer Information Control System）系统就已提供了跨计算结点事务支持。针对美国电话公司需要的联机事务处理能力，AT\&T贝尔实验室于上个世纪80年代初发布了跨平台的Tuxedo事务处理中间件，相关研究与实践对后续X/Open组织的分布式事务处理规范、OMG组织的对象事务服务规范等产生了较大影响\cite{Emmerich:2008:IRD:13487689.13487692}。
 
-\subsection{互联网计算时代的中间件（90年代末-）}
+\subsection{面向互联网的中间件}\label{internet-middleware}
 20世纪90年代中后期， 互联网进入高速发展阶段。互联网资源具有开放动态、成长自治的特点，但人们同时又希望软件能够持续在线、高度可用，二者之间的矛盾催生了“服务”的概念。从2000年左右W3C组织所制定一系列Web Service标准开始，“服务”\index{服务}一词即被用来抽象可通过网络按需访问、无需关心实现细节的能力。以此为核心，面向服务体系结构通过服务化封装和“服务提供者-消费者”之间的动态发现，解决开放动态与持续在线之间的矛盾。
 
 作为互联网时代的产物，服务化思想首先推动了中间件技术外延的拓展。Apache Tomcat、IBM WebSphere等Web服务中间件以支撑面向服务体系结构为目标，封装了服务注册、服务发现、服务访问等共性基础设施；以企业服务总线（Enterprise Service Bus，ESB）\index{企业服务总线}为代表的服务集成中间件通过服务封装、服务组合、服务协同等技术实现自治子系统之间的通信，进而实现复杂业务系统跨域集成；微服务\index{微服务}则聚焦单个业务系统内部，通过系统内部组件的彻底服务化，实现开发阶段“分而治之”和运行阶段的灵活应变，这一思路催生了Spring Cloud等微服务框架。
 
-互联网软件按需提供服务的特点也促使了中间件本身向持续运行的平台形式的转型，其典型代表是网格计算中间件、P2P中间件以及云计算“平台即服务”（PaaS）基础设施等。“平台即服务”在“基础设施即服务”（IaaS）的基础上提供包括中间件和数据库在内的一系列软件栈，为云端分布式应用提供服务化的、可按需使用的运行托管环境。在某种程度上，“平台即服务”可视为中间件技术在云计算环境下的集成和延续。
+近年来，作为服务化思想的集大成者，云计算模式被广泛接受。如同工业革命让水、电、交通等成为公共服务一样，云计算正在通过后端资源集约化和前端按需服务方式，推动信息技术实现社会化和专业化，使得信息服务成为公共基础设施。这一趋势推动着中间件概念内涵和外延的发展，新一代“平台即服务”（Platform as a Service, PaaS）软件基础设施成为了各大云服务提供商的核心竞争力所在。它为云端分布式应用提供服务化的、可按需使用的运行托管环境，集成了从分布式调用、数据库访问到服务治理在内的一系列软件栈，其典型代表包括Google AppEngine、Microsoft Azure、Amazon EC2等。与传统中间件相比，它们具有如下一些显著特征：
 
-\subsection{信息物理融合时代的中间件发展（21世纪初-）}
+\begin{itemize}
+	\item 在资源的管控方面，此类平台的核心是大型主机时代即已出现的虚拟化技术，但将其应用场景拓展到了数据中心甚至多数据中心级别的，通过虚拟化实现海量计算、网络、存储资源的细粒度管理，进而实现资源的有效聚合和弹性扩展。例如，互联网虚拟计算环境 iVCE\cite{Lu:2013:IVC:2388122.2388238}通过资源的“自主协同、按需聚合”，将静态统一视图的资源组织模式扩展为相对稳定视图、按需可伸缩的资源组织模式，从而实现面向互联网计算的高效管控。
+	\item 在应用软件的执行管控维度上，此类平台面向云服务这类大规模分布计算软件，提供了任务调度与执行、负载均衡、安全管控、在线监控和升级演化、分布式数据存储访问等一系列基础设施和相应能力。这些能力以的服务化方式提供，用户无需像传统系统软件那自行安装、部署和维护。部分“平台即服务”基础设施还内建了编译系统和调测试环境，支持云端开发和编译构建。
+	\item 在可用性方面，此类平台需要7×24小时持续提供基础服务，是支撑整个信息空间持续运行的核心基础设施，突出表现为一旦发生故障，会产生较大的社会经济影响。例如，有文献指出如果一个主要的云平台宕机3－6天，美国经济会产生30亿－150亿美元的损失\footnote{``Cloud Down: Impacts on the US economy,''  https://www.lloyds.com/\~/media/files/news-and-insight/risk-insight/2018/cloud-down/aircyberlloydspublic2018final.pdf}。
+\end{itemize}
+
+\subsection{人机物融合中间件}\label{blockchain-history}
 计算技术的网络化和普适化推动了信息与物理空间的持续融合，出现了各类可以感知/作用于物理世界的大规模网络软件，中间件技术随之在不断发展。自上个世纪末以来，随着相关硬件技术的逐渐成型，中间件领域针对嵌入式传感器和移动设备等载体，开始关注对物理空间情境（Context）数据的处理，出现了普适计算中间件、传感器网络中间件、情境感知中间件等一系列新型中间件。近年来快速发展的物联网中间件\index{物联网中间件}（IoT Middleware）在上述中间件概念的基础上，进一步针对“万物互联”的大规模异构环境进行了拓展，其核心关注点是在资源受限、高度异构、规模庞大、网络动态变化条件下，如何实现互联互通互操作，并且不违反各种时空约束特性，满足物联网应用对海量传感器数据或事件实时处理的需求。
 
 除了感知物理世界外，随着信息物理融合系统的成熟，近年来中间件领域开始关注如何联接能够直接“作用”于物理世界的计算设备，其突出代表是无人系统/机器人中间件。针对无人系统计算环境高度异构、资源受限、常态失效、实时性要求高等特点，从2000年左右的Player等中间件开始，包括Miro、CLARAty、OpenRTM-aist、Pyra、Orca、MARIE等在内的一系列实践推动了无人系统中间件技术的发展，并直接为今天广泛使用的机器人“元级操作系统”ROS（Robot Operating System）奠定了理论和技术基础。
 
+此外，从早期的P2P中间件到今天的区块链平台，分布自治中间件突出体现了“社会-技术”系统的思想，具有人机融合的特点。此类中间件通过信息空间内的机制设计激励人的自主协同，通过软件基础设施及平台支撑社会价值交换。以区块链为例，2009年比特币网络上线并连续无故障运行，2010年“比特币披萨日”第一次用于购买实物，2013年塞浦露斯金融危机中成功得到高度关注。从软件角度而言，此时的比特币仍然只是一个独立于国家货币体系的分布式应用，而2014年发布的以太坊则摆脱了电子货币的桎梏：作为建立于区块链技术之上的应用平台，以太坊的“区块”可以记录各类数据，而Solidity语言描述的智能合约能够实现各种场景下的复杂应用逻辑。这标志着区块链从应用层技术向支持分布式共识的系统软件部件的转变。后续超级帐本、联盟链等技术/系统的发展，更进一步将参与方从个人扩展到组织，在金融、物流、社会治理等领域形成了一系列极具前景的新型应用模式。
+
 \section{数据库管理系统}
 数据库\index{数据库}是长期存储在计算机内有组织、可共享的大量数据的集合，数据库管理系统旨在统一管理和维护数据库中的数据，是组织、存储、存取、控制和维护数据的软件。从本质上而言，数据库管理系统\index{数据库管理系统}把逻辑数据转换成为计算机中具体的物理数据，从而使得用户可以访问、检索和维护数据，而不必顾及这些数据在计算机中的布局和物理位置。
 
@@ -177,33 +175,33 @@
 	\label{fig:3-5}}
 \end{figure}
 
-\subsection{数据库管理系统的出现（20世纪60年代-70年代初）}
+\subsection{层次和网状数据库}
 20世纪50年代前期，计算机被主要用于科学计算，数据仅被认为是“计算”的产品或附属品，通常存储在被称为“文件”的打孔卡片（早期）或外设数据单元上。随着计算机应用领域向商业、金融、政府等通用领域扩展，文件作为数据存储的主要设施，已经无法满足对各类应用中数据项之间的复杂关系进行管理的需求，主要表现在以下几个方面：文件内部数据组织往往是面向单一应用的，不同应用共享同一个文件结构效率较低；文件之间的数据是独立的，无法表达两个文件的数据所存在内在逻辑关系；文件的组织方式单一，难以满足不同的访问模式对数据高效率访问的需求。
 
 在上述背景下，为了提供系统化、高效的数据组织与访问功能，专门的数据库管理系统开始出现。60年代初通用电气在其生产信息和控制系统（MIACS）中设计了“集成数据存储”（Integrated Data Store），被认为是首个支持直接访问的数据库管理系统\cite{Bachman:2009:OID:1674526.1674536}，并直接为CODASYL组织后续制定的网状数据库标准奠定了基础。1968年，IBM发布了运行于System/360主机的层次数据库管理系统IMS（Information Management System）。上述两个具有里程碑意义的产品分别代表了数据库管理系统的两种早期数据模型，也即数据是按照网状的“图”还是层次化的“树”来组织。其中，层次模型由于其每一个节点最多只有一个父节点，因此可以采用有效的手段（例如按照树遍历的顺序）来存储数据，而网状模型可以将图分解为一组“基本层次联系”的集合，其本质上可以用“树”结构来表达和存储数据。
 
-\subsection{关系数据库的高速发展（70年代-90年代）}
-220世纪70年代是关系数据库\index{关系数据库}形成并实现产品化的年代，主要的代表人物就是IBM的埃德加·科德（Edgar F. Codd）。1970年，科德发表题为“大型共享数据库的关系模型”的论文\cite{Codd:1970:RMD:362384.362685}，文中提出了数据库的关系模型。由于关系模型简单明了、具有坚实的数学理论基础，操作语言是描述性的，无需像层次网状模型那样，需要描述存取路径（既先访问哪个数据再访问哪个数据）这样的细节，给提高信息系统开发的生产率提供了极大的空间，所以一经提出就受到了学术界和产业界的高度重视和广泛响应。尽管一开始产业界还充斥了对关系数据库系统性能的怀疑，但科德所开发的System R系统证明其性能可以有保障。这一结论极大地推动了关系数据库技术的发展，关系数据库产品开始涌现，包括IBM公司在System R系统基础上推出的DB2产品、ORACLE公司的同名数据库产品，以及80年代初出现的、针对个人电脑设计的dBase等。由于科德杰出的贡献，1981年的图灵奖授予了这位“关系数据库之父”
+\subsection{关系数据库}
+20世纪70年代是关系数据库\index{关系数据库}形成并实现产品化的年代，主要的代表人物就是IBM的埃德加·科德（Edgar F. Codd）。1970年，科德发表题为“大型共享数据库的关系模型”的论文\cite{Codd:1970:RMD:362384.362685}，文中提出了数据库的关系模型。由于关系模型简单明了、具有坚实的数学理论基础，操作语言是描述性的，无需像层次网状模型那样，需要描述存取路径（既先访问哪个数据再访问哪个数据）这样的细节，给提高信息系统开发的生产率提供了极大的空间，所以一经提出就受到了学术界和产业界的高度重视和广泛响应。尽管一开始产业界还充斥了对关系数据库系统性能的怀疑，但科德所开发的System R系统证明其性能可以有保障。这一结论极大地推动了关系数据库技术的发展，关系数据库产品开始涌现，包括IBM公司在System R系统基础上推出的DB2产品、ORACLE公司的同名数据库产品，以及80年代初出现的、针对个人电脑设计的dBase等。由于科德杰出的贡献，1981年的图灵奖授予了这位“关系数据库之父”
 
 20世纪80年代，关系数据库迅速取代层次和网状数据库占领市场，描述型的关系库数据语言（SQL语言）、完善数据正确性确保的机制、逐渐发展的开发工具和软件生态在实践中显著提高了生产率。数据库研究工作重心也围绕关系数据库展开，包括查询优化和事务管理等方面：（1）查询优化。关系数据库语言是基于集合的描述性语言（如70年代初出现的SQL语言），其查询的结果也是一个集合。如何将一个SQL语句转换为可以执行的程序（类似程序自动生成器），而且要在所有可能的执行计划（程序）中选择出一个效率足够好的加以执行，是这一阶段工作重点之一。（2）事务管理。事务管理提供对并发事务的调度控制和故障恢复，确保数据库系统的正确运行。詹姆斯·尼古拉·格雷（James Gray）在相关研究方面发挥了十分关键的作用，为数据库管理系统成熟并顺利进入市场做出了重要的贡献。他的成就汇聚成一部厚厚的专著《Transaction Processing: Concepts and Techniques》\cite{Gray:1992:TPC:573304}，他个人也众望所归获得了1998年度的图灵奖。
 
 在这一时代，对于数据库管理系统做出重要贡献的还有迈克尔·斯通布雷克（Michael Stonebraker）。他在加州大学伯克利分校计算机科学系任教的29 年中，领导开发了关系数据库系统Ingres、对象–关系数据库系统Postgres、联邦数据库系统Mariposa等，同时创立了多家数据库公司。他在“One size does not fit all”的思想指导下，开发了一系列的“专用”关系数据库产品，例如流数据管理系统、内存数据库管理系统、列存储关系数据库系统、科学数据库管理系统等。因“对现代数据库系统底层的概念与实践所做出的基础性贡献”，他于2015年获得了图灵奖。
 
-\subsection{数据仓库系统的出现和发展（90年代-）}
+\subsection{数据仓库系统}
 数据仓库\index{数据仓库}可看作是关系数据库的一个自然延伸。随着数据库技术的普及应用，越来越多的数据被存储在数据库中，除了支持业务处理以外，如何让这些数据发挥更大的作用，就是一个亟待解决的问题。特别是对于联机分析处理类应用，如何让复杂分析能高效地执行，需要有特殊的数据组织模式，推动了数据仓库系统的出现。
 
 星型模型是最常用的数据仓库的数据组织模型。所谓星型模型也称多维模型，就是选定一些属性作为分析的维度，另一些属性作为分析的对象。维属性通常根据值的包含关系会形成一个层次，例如时间属性可以根据年月周日形成一个层次，地区属性也可以形成街道-区-市这样的层次。为了实现快速分析，可以预先计算出不同层次上的统计结果，从而获得快速联机分析的性能。在实现方式上，数据仓库可以用关系数据库实现（Relational OLAP），分别用事实表和维表来存储统计结果和维度结构，也可以用特别的数据模型（CUBE）来实现，列存储的技术也在这个过程中被提出和应用。同时，支持联机分析处理的前端工具的发展，也使得普通用户可以方便地使用数据仓库
 
-\subsection{大数据时代数据库管理系统的发展（21世纪初-）}
+\subsection{大数据时代的数据库管理系统}
 关系数据库成熟并广泛应用后，数据库领域一度走入一段迷茫期，被关系模型的“完美”所陶醉。进入21世纪，互联网的高速发展使得数据规模越来越庞大，传统关系数据库的弊端开始凸显：在搜索引擎、流媒体等拥有海量非结构化数据的领域，传统的关系数据模型并不完全适用，而关系型数据库所承诺的原子性、一致性、隔离性、持久性等ACID特性在这些领域有可能不需要严苛保证，不必要的开销和有限的可扩展性导致数据存储和管理效率低下。在这一背景下，NoSQL数据库\index{NoSQL数据库}开始出现，其重要的里程碑事件是Google所发布的Bigtable\cite{Chang:2008:BDS:1365815.1365816}及根据其理念所开发的开源HBase数据库。与关系数据库不同，NoSQL数据库不再采用严苛的关系模型，转而使用更为灵活的键值对结构、文档模型、图模型等。同时，NoSQL数据库可能不提供严格的一致性保证，并且通常在设计时即考虑了水平可扩展能力（即通过增加计算节点来扩充处理能力），因此可以达到比关系型数据库更高容量和性能。
 
 随着实践的深入，人们发现NoSQL并非解决大数据时代数据管理问题的“银弹”。一方面，无论从应用程序继承的角度还是提高生产率的角度，SQL语言都是不可或缺的工具，因此继承和汲取SQL的优点（如在上层提供SQL查询引擎）逐渐成为NoSQL数据库的共识，NoSQL一词的含义也从“非SQL”被修正为“不仅仅是SQL”（Not Only SQL）。另一方面，许多联机事务处理业务在应对海量数据同时仍需要采用关系模型，并保证原子性、一致性、隔离性、持久性等特性。因此，能够提供与NoSQL数据库类似的扩展性能、但仍具备关系数据库能力的NewSQL数据库\index{NewSQL数据库}近年来得到了快速发展，其典型代表包括Google全球级分布数据库Spanner\cite{Corbett:2013:SGG:2518037.2491245}和开源领域的CockroachDB、TiDB等。
 
-\section{结束语}
+\section{本章小结}
 系统软件将计算系统的概念从硬件扩展到了软件层面上，它为上层应用提供了一个可以使用各类资源能力、但又无需关注底层细节的软件平台。历经六十余年的发展，系统软件已经形成操作系统、编译系统、中间件和数据库管理系统等典型形态，已经成为了计算机软硬件生态链的核心，对信息产业乃至人类社会产生了较大影响，在促进经济发展和文明进步中发挥了重要作用。在这一过程中，系统软件表现出了如下一些发展规律：
 
 \begin{itemize}
-	\item 硬件技术和应用场景变迁是发展的核心动力。系统软件具有“承上启下”的特点，无论是形态还是机理的发展都受到硬件和应用两方面的驱动。例如，在贝尔定律支持下，计算设备约每10年一次换代，设备和用户增加10倍，成为新的蓝海、催生新型应用，间次推动操作系统换代并形成新的生态，使得操作系统每隔20年左右迎来一次跨越式发展的机遇期（参见图\ref{fig:3-1}）。另一个典型案例是编译系统：近年来高性能计算、智能计算方面的应用需求，以及GPU等新型硬件的出现，成为了编译系统近年来发展的主要动力。
+	\item 硬件技术和应用场景变迁是发展的核心动力。系统软件具有“承上启下”的特点，无论是形态还是机理的发展都受到硬件和应用两方面的驱动。例如，如贝尔定律所述，计算设备约每10年一次换代，设备和用户增加10倍，成为新的蓝海、催生新型应用，间次推动操作系统换代并形成新的生态，使得操作系统每隔20年左右迎来一次跨越式发展的机遇期（参见图\ref{fig:3-1}）。另一个典型案例是编译系统：近年来高性能计算、智能计算方面的应用需求，以及GPU等新型硬件的出现，成为了编译系统近年来发展的主要动力。
 	\item 构建“抽象”和实现平台化是发展的重要主题。本质而言，系统软件负责向应用提供运行支撑、网络交互、数据管理等不同维度上的“抽象”（或者说虚拟机），并将这一“抽象”以尽可能高效方式绑定到硬件裸机，充分发挥硬件潜力。例如，过去数十年中，操作系统形成了一系列诸如文件、进程/线程、内存页、Socket等的概念，并由这些概念实体共同组成了应用可见的“抽象”（或者说虚拟机）。同时，沉淀共性、进而实现平台化也是系统软件发展的重要主题，一方面可以避免应用去重新“造每一个轮子”，另一方面也为软件生态奠定基础。
-	\item 技术螺旋上升与交叉融合是发展的主要特征。与应用软件的快速更新不同，系统软件具有相对稳定性，很多核心技术表现出了螺旋上升的接入点。例如，虚拟化技术早在60年代IBM实验性操作系统CP-40和其后商用化的CP-67、VM/370中得到完整实现，而云计算时代虚拟化技术“复兴”过程中的挑战则主要来自于数据中心环境资源集约化的需求。另一方面，系统软件发展经历了从无到有、进而形成多个分支的过程。“分久必合”，近年来分支之间表现出相互融合趋势，中间件与操作系统就是一个典型案例（参见\ref{middleware}节）。
+	\item 技术螺旋上升与交叉融合是发展的主要特征。与应用软件的快速更新不同，系统软件具有相对稳定性，很多核心技术表现出了螺旋上升的特点。例如，虚拟化技术早在60年代IBM实验性操作系统CP-40和其后商用化的CP-67、VM/370中得到完整实现，而云计算时代虚拟化技术“复兴”过程中的挑战则主要来自于数据中心环境资源集约化的需求。另一方面，系统软件发展经历了从无到有、进而形成多个分支的过程。“分久必合”，近年来分支之间表现出相互融合趋势，中间件与操作系统就是一个典型案例（参见\ref{middleware}节）。
 \end{itemize}

Ch2-5-OperatingSystem.tex

@@ -1,15 +1,16 @@
 % !TEX root =  main.tex
 
-操作系统负责管理软硬件资源、操纵程序运行，为应用软件提供公共支撑，是“软件作为基础设施”的集中体现。过去，操作系统是信息空间的基础设施，起到以平台化方式向下管理各类资源、向上支撑应用运行的作用；未来，在信息物理持续融合趋势的推动下，操作系统管理资源将向各类物理资源扩展，甚至向其他具有“数字孪生”特性的经济、社会和生产生活资源扩展。这一趋势是“软件定义”思想发展的必然结果：随着计算系统正在突破单机、数据中心等封闭环境的限制，操作系统的资源虚拟化、功能可编程能力进一步拓展，从控制管理单个计算机系统资源进一步延伸为连接协调多个结点组成的复杂计算系统，为信息空间、物理空间乃至整个社会提供“软件定义”手段，推动着诸如面向网构软件的操作系统\cite{mei2016internetwareos}、智能家居操作系统、智慧城市操作系统等“泛在操作系统”（Ubiquitous Operating System）\index{泛在操作系统}成为现实\cite{mei2018toward}。
+操作系统负责管理软硬件资源、操纵程序运行，为应用软件提供公共支撑，是“软件作为基础设施”的集中体现。过去，操作系统是信息空间的基础设施，起到以平台化方式向下管理各类资源、向上支撑应用运行的作用；未来，在信息物理持续融合趋势的推动下，操作系统管理资源将向各类物理资源扩展，甚至向其他具有“数字孪生”特性的经济、社会和生产生活资源扩展。这一趋势是“软件定义”思想发展的必然结果：随着计算系统正在突破单机、数据中心等封闭环境的限制，操作系统的资源虚拟化、功能可编程能力进一步拓展，从控制管理单个计算机系统资源进一步延伸为连接协调多个节点组成的复杂计算系统，为信息空间、物理空间乃至整个社会提供“软件定义”手段，推动着诸如面向网构软件的操作系统\cite{mei2016internetwareos}、智能家居操作系统、智慧城市操作系统等“泛在操作系统”（Ubiquitous Operating System）\index{泛在操作系统}成为现实\cite{mei2018toward}。
 
 与此同时，操作系统的外延、或者说“操作系统应该是什么形态”这一问题也在随着技术和应用的发展而不断扩展演化。例如，在人机物融合互联这一大背景下，中间件正在表现出加速融合到操作系统中的趋势：早在上个世纪的90年代初，美国华盛顿大学的MOSES（Meta Operating System and Entity Shell）项目即使用了“元级操作系统”的概念来描述分布环境下“位于本地操作系统之上、应用之下的一层软件”；早期的普适计算中间件Gaia\cite{Roman:2002:GMP:643550.643558}等已在文献中混用“元级操作系统”和“中间件”概念，而今天广泛应用的ROS（Robot Operating System）\cite{quigley2009ros}更是继承了网络计算中间件的核心思想。换言之，操作系统正在以海纳百川的方式沉淀各类具有软件定义特征的基础设施，这也是本章标题“操作系统与运行平台”的由来。
 
 基于上述内涵和外延两个方面的观察，本章将从平台架构、方法机制、安全隐私等方面列出操作系统与运行平台的重大挑战问题，并阐述本领域的研究趋势和内容。
 
 \section{重大挑战问题}
-互联网革命正在进入下半场，“万物互联”时代正在到来，人机物融合的泛在应用场景推动着操作系统和运行平台的新一轮变革，带来体系结构、资源管理、应用支撑、首先，在所管控资源高度异构、涵盖人-机-物三元空间的条件下，未来的操作系统和运行平台需要什么样的架构（§\ref{os-architecture}）；其次，从向下管理泛在资源的角度，需要以及什么样的资源虚拟化和调度机制（§\ref{os-scheduling}）；再次，从向上支撑应用运行的角度，应当如何支撑上层应用的持续适应和演化（§\ref{os-evolution}）；最后，在人与物加入到操作系统管理对象中之后，基础设施层的安全与隐私保护风险如何应对（§\ref{os-security}）。
+互联网革命正在进入下半场，“万物互联”时代正在到来，人机物融合的泛在应用场景推动着操作系统和运行平台的新一轮变革，带来体系结构、资源管理、应用支撑、安全隐私等方面的挑战。首先，在所管控资源高度异构、涵盖人-机-物三元空间的条件下，未来的操作系统和运行平台需要什么样的架构（§\ref{os-architecture}）；其次，从向下管理泛在资源的角度，需要什么样的资源虚拟化和调度机制（§\ref{os-scheduling}）；再次，从资源聚合和应用协同支撑的角度，在网络环境下如何实现从“精确控制”到“连接协调”的变迁（§\ref{os-connection}）；第四，从向上支撑应用运行的角度，应当如何支撑上层应用持续适应和演化（§\ref{os-evolution}）；最后，在人与物加入到操作系统管理对象中之后，基础设施层的安全与隐私保护风险如何应对（§\ref{os-security}）。
+
 \subsection{支持软件定义的新型运行平台架构}\label{os-architecture}
-“软件定义”的提法最早可追溯到上个世纪90年代所提出的软件定义无线电（Software-defined Radio）\cite{tuttlebee1999software}概念。在软件定义的无线电设备中，传统由晶体管、集成电路等实现的信号处理部件（如滤波器、调制/解调器等）被软件所代替，在大幅简化硬件设计同时，获得“功能可编程”的显著收益――设备能力可以按需扩增或裁剪，从而快速适应技术体制和市场需求的变化。
+“软件定义”的提法最早可追溯到上个世纪90年代所提出的软件定义无线电（Software-defined Radio）\cite{tuttlebee1999software}概念。在软件定义的无线电设备中，一部分传统由晶体管、集成电路等实现的信号处理部件（如滤波器、调制/解调器等）被软件所代替，在简化硬件设计同时，获得“功能可编程”的显著收益——设备能力可以按需扩增或裁剪，从而快速适应技术体制和市场需求的变化。
 
 进入21世纪，随着云计算等新型计算范型的出现，人们对计算系统的灵活性、可管理性和资源利用率的追求日益提高，“软件定义”一词被引入到计算技术领域。以 “软件定义网络”（Software-defined Network）\index{软件定义网络} 为例，与传统网络互联能力由硬件/固件所决定不同，软件定义网络强调将整个网络自底向上划分为数据、控制和应用三个平面。其中，控制平面向下操纵和协调数据平面上设备（如交换机）的行为，向上提供尽可能与硬件无关的抽象（编程接口）、支撑应用平面运行。控制平面不仅具备“功能可编程”能力，也具备了“资源虚拟化”能力，也即能够对数据平面资源进行高效管理、封装与抽象。“软件定义”内涵的这一升华深受操作系统思想的影响。例如，首个开源的软件定义网络控制器NOX（Network Operating System）在其文献\cite{Gude:2008:NTO:1384609.1384625}中指出，“现代操作系统通过提供对资源和信息高层抽象的可控访问…使得程序可以在各种计算硬件上安全和高效执行复杂任务”，NOX就是将操作系统思想拓展到了网络设备管理中。
 \begin{figure}[htbp]
@@ -18,18 +19,20 @@
 		\centering
 		\includegraphics[width=0.4\linewidth,height=2.5cm]{fig2-5/tos.png}
 	}\    
-	\subfigure[软件定义网络$\lbrack$x$\rbrack$]{
+	\subfigure[软件定义网络]{
 		\centering
 		\includegraphics[width=0.5\linewidth, height=2.5cm]{fig2-5/sdn.png}
 }
 \caption{操作系统与软件定义网络架构的类比}
 \end{figure}
 
-将操作系统“功能可编程”、“资源虚拟化”的思想拓展到存储、安全、数据中心等具体领域，我们就得到了软件定义存储、软件定义安全、软件定义的数据中心等概念。进一步，随着操作系统由计算机软硬件之间的桥梁、人与计算机之间的桥梁拓展到云边端、人机物之间的桥梁，其定位将由单个计算机“管家”演化为支撑“软件定义一切”的运行平台。传统操作系统架构面向的是信息空间内孤立计算结点，这一沿用数十年的架构将面临如下两个方面的挑战：
+将操作系统“功能可编程”、“资源虚拟化”的思想拓展到存储、安全、数据中心等具体领域，我们就得到了软件定义存储、软件定义安全、软件定义的数据中心等概念。进一步，随着操作系统由计算机软硬件之间的桥梁、人与计算机之间的桥梁拓展到云边端、人机物之间的桥梁，其定位将由单个计算机“管家”演化为支撑“软件定义一切”的运行平台。传统操作系统架构面向的是信息空间内孤立计算节点，主要关注基于一般硬件的通用场景。这一沿用数十年的架构将面临如下三个方面的挑战：
 \begin{itemize}
-	\item 从“精确控制”到“连接协调”的挑战。未来的人机物融合系统将是大规模、网络化的计算系统，虽然每个节点上仍将运行传统的节点操作系统，在节点内部通过对资源实施严格精确控制来达到资源虚拟化、功能可编程的目的，但这种精确控制机制很难直接应用到网络层面。事实上，这种简单放大的思路在30年前的Amobea等分布式操作系统实践中就已经证明很难奏效（参见本书第一部分\ref{middleware}节）。根本原因在于网络化系统具有开放和复杂系统的特征，其所涉及的实体往往跨越多个管理域，系统边界也随时间演化而不断发生变化，很难构建静态不变的控制中心，或是明确稳定的自顶向下层次化结构。在这种场景下，更为妥当的方式将是 “连接协调”，即通过按需聚合和动态协同来打破不同节点之间的壁垒，统一管理并优化利用计算、数据甚至物理世界各种资源。从“精确控制”到“连接协调”的方式的这一转变，将从根本上动摇现有操作系统的架构，并催生新一代、运行于节点操作系统之上的网络操作系统。在这一过程中，区块链、"云-端”融合、5G通信等新一代分布计算支撑技术将发挥重要的使能作用。例如，在其所适合的场景下，区块链可望实现信息共享从集中式架构到去中心化架构的变迁，其应用将突破传统的金融领域，沉淀为泛化运行平台的组成部分之一，支持多种类型应用的能力有效提升。
-	\item 计算、通信、控制三元融合场景的挑战。今天广泛使用的Windows、Linux等操作系统在架构上深受首个现代意义上操作系统－－Unix的影响。它们运行于单一计算结点范围内，内部大致可划分为资源管理、系统调用、人机接口等层次。这种架构针对信息空间内部的孤立计算结点设计，很难支撑泛在化、智能化、网络化的新型应用场景。具体而言，在计算维度上，单一的本地计算将向云边端一体化计算、人机物协作计算、智能和机器学习计算等新型场景变迁；在通信维度上，5G等新型网络的出现使得网络时延和吞吐量得到极大改善，可望触发移动和嵌入式操作系统的新一轮革命；在控制维度上，物联网、机器人等与物理世界紧密融合的计算设备涌现，使得“功能可编程”将突破信息空间范畴，需要在操作系统架构设计层面上考虑物理空间约束和对物理空间的影响。
+	\item 新型硬件对经典操作系统架构的挑战。近年来，处理器、存储器件、网络互联设备等硬件技术快速发展，众核处理器、FPGA/GPU加速硬件、非易失内存、远程直接数据存取（RDMA）网络等一系列高性能、具有新架构和新特征的新型硬件不断涌现，并逐渐成为主流技术。一个典型案例是面向人工智能等特定领域的“CPU + xPU\footnote{如图形处理器GPU、张量处理器TPU、神经网络处理器NPU等}“体系结构，在高性能计算机及移动异构片上系统中均得到较广泛应用。如何充分发挥新型硬件的潜力，是经典操作系统架构设计所面临的重大挑战。以内核设计为例，传统操作系统主要有宏内核和微内核两种模式：以Unix/Linux为代表的宏内核操作系统在架构上已经趋于稳定，新的改进主要来自对新的硬件、新的抽象和新型外设的支持，这种不断打”补丁“的方式导致系统不堪重负，而宏内核天然的一体性也导致通过定制裁剪来适应异构硬件的方法代价高昂；现有微内核操作系统主要考虑受约束场景的需求，缺乏对大型计算密集任务场景的扩展性支持，也缺少完善的用户态环境。
+	\item 从单一节点到大规模开放环境的挑战。可以预见，随着人机物融合、特别是“软件定义一切”的付诸实践，未来操作系统将具有两种形态：一方面，在新型硬件技术和新型应用场景的共同驱动下，今天我们所熟知的、以单一计算节点为作用空间的经典操作系统（以下称节点操作系统）将继续发展，实现节点尺度上的资源虚拟化和功能可编程；另一方面，操作系统的作用空间将突破单一节点的束缚，新一代操作系统将运行于经典操作系统之上，实现网络环境下异构资源聚合和优化管理，支撑各种类型、更大尺度上的分布式应用，实现计算、数据甚至物理世界各类异构资源的调控。后者将极大的扩展现有操作系统概念的内涵与外延，由于系统边界的开放性、体系结构的分布性、运行环境的动态性、涉及资源的高度异构性，其架构将很难沿用传统操作系统自顶向下、精确控制的模型（详见\ref{os-connection}节）。
+	\item 计算、通信、控制三元融合场景的挑战。今天广泛使用的Windows、Linux等操作系统在架构上深受首个现代意义上操作系统－－Unix的影响。它们运行于单一计算节点范围内，内部大致可划分为资源管理、系统调用、人机接口等层次。这种架构针对信息空间内部的孤立计算节点设计，很难支撑泛在化、智能化、网络化的新型应用场景。具体而言，在计算维度上，单一的本地计算将向云边端一体化计算、人机物协作计算、智能和机器学习计算等新型场景变迁；在通信维度上，5G等无线通信技术的出现使得网络时延和吞吐量得到极大改善，可望触发移动和嵌入式操作系统的新一轮革命；在控制维度上，物联网、机器人等与物理世界紧密融合的计算设备涌现，使得“功能可编程”将突破信息空间范畴，需要在操作系统架构设计层面上考虑物理空间约束和对物理空间的影响。
 \end{itemize}
+
 \subsection{泛在资源的高效虚拟化和灵活调度}\label{os-scheduling}
 文献\cite{mei2018toward}给出了“泛在操作系统”的概念，指出未来的操作系统不仅仅是IT操作系统，也将成为物理世界和虚拟世界的操作系统，在今天已经初露端倪的机器人操作系统、车辆操作系统、物联网操作系统等基础上，校园操作系统、城市操作系统、家庭操作系统等可望在将来成为现实。在这一背景下，操作系统的核心功能――资源虚拟化和调度的实现机制面临一系列挑战（图\ref{fig2}）。
 
@@ -40,38 +43,44 @@
 	\label{fig2}
 \end{figure}
 
-首先，如何为人机物融合计算中的各类新型异构资源建立抽象，是未来操作系统需要解决的核心问题。本质上，操作系统和运行平台负责向应用提供“抽象”，并将这些“抽象”绑定到硬件祼机。数十年来，这一领域已经积累了诸如进程、线程、文件、内存页等一系列重要抽象机制，为现代操作系统奠定了基石。但是，未来操作系统所管理的资源将跨越人、机、物三元空间，涵盖物理资源、计算资源、数据资源等多种类型，现有抽象远远不能满足需求。因此，需要探索符合新型资源特点、切合其特性的抽象机制，并突破在单一计算结点、有一定边界的分布式系统、跨域开放式系统等不同尺度上维护这些抽象的方法机理。
+首先，高性能处理器、新型存储器件、高速网络互联设备等快速发展，使得经典的计算资源虚拟化和调度机制面临挑战。例如，多核和多芯片计算机系统中非一致性内存访问架构使得传统基于页的虚存系统面临挑战；目前已有的设备模拟、设备半虚拟化、设备直通、单根虚拟化（SR-IOV）等技术尚不能完全扩展到 GPU、张量处理器等人工智能新型加速器，或者是效率和灵活性还需要进一步提升；非易失性内存的应用使得内存中的某些数据不再需要存储到硬盘，内存和持久存储走向融合，对传统类文件系统架构带来挑战；100G及以上以太网链路在大规模数据中心的普及，网络进入纳秒级时延，带宽增长速度超越CPU处理能力增长速度，操作系统网络协议栈面临挑战；等等。
 
-其次，在操作系统支持下，物理资源将呈现物理与数字二像性，如何将信息空间内的抽象与物理空间内的实体绑定，并持续保持和校正二者之间的一致性，是操作系统泛在化以后产生的新问题。一方面，需要利用预建立物理模型、传感器实时数据、较大时空尺度上的运行历史等数据，集成多物理量、多尺度、多概率的仿真过程，实现物理资源到信息空间中实体的正向映射，以及“因果关联”的虚拟实体到物理资源的映射；另一方面，即使建立了相应的“数字孪生”关系，也要考虑物理域和社会域资源在管理和调度过程中的特有属性，例如动作的非精确性和动态性、固有的噪声等。
+其次，如何为人机物融合计算中的各类新型异构资源建立抽象，是未来操作系统需要解决的核心问题。本质上，操作系统和运行平台负责向应用提供“抽象”，并将这些“抽象”绑定到硬件祼机。数十年来，这一领域已经积累了诸如进程、线程、文件、内存页等一系列重要抽象机制，为现代操作系统奠定了基石。但是，未来操作系统所管理的资源将跨越人、机、物三元空间，涵盖物理资源、计算资源、数据资源等多种类型，现有抽象远远不能满足需求。因此，需要探索符合新型资源特点、切合其特性的抽象机制，并突破在单一计算节点、有一定边界的分布式系统、跨域开放式系统等不同尺度上维护这些抽象的方法机理。
 
-再次，如何使打破信息-物理世界间以及不同节点间的壁垒，按需聚合各类资源，是实现泛在资源优化利用的关键。如前节所述，未来的计算系统在微观尺度上仍将运行我们今天所熟悉的节点级操作系统，而在整个系统的宏观尺度上，资源管理模型将从“精确控制”向“连接协调”转变。虽然这一理念在中间件、网构软件等领域已经有了初步实践，但一系列实现机制层面上的开放问题仍有待解决，包括需要何种模型来协调跨域资源及其能力、如何在动态环境下维持相对稳定的“功能可编程”抽象、如何有效管理调度各种冲突及涌现现象等。
+再次，在操作系统支持下，物理资源将呈现物理与数字二像性，如何将信息空间内的抽象与物理空间内的实体绑定，并持续保持和校正二者之间的一致性，是操作系统泛在化以后产生的新问题。一方面，需要利用物理模型、传感器实时数据、较大时空尺度上的运行历史等数据，集成多物理量、多尺度、多概率的仿真过程，实现物理资源到信息空间中实体的正向映射，以及“因果关联”的虚拟实体到物理资源的映射；另一方面，即使建立了相应的“数字孪生”关系，也要考虑物理域和社会域资源在管理和调度过程中的特有属性，例如动作的非精确性和动态性、固有的噪声等。
 
-最后，需要深入理解未来泛在计算场景下应用模式的共性特征，为上层应用的“软件定义”提供适当的、相对稳定的编程接口。可以预见，未来泛在计算场景至少包括数据规模巨大、强调按需能力获取的“云-边”效用计算，资源需求动态变化、不确定性很强的智能计算，移动性强、承载设备多、续航要求高、迭代快的智慧城市、工业互联网等领域的协作计算，人与物相互驱动、相互协同的人机物统一计算等。这些泛在应用模式很多都处在探索阶段，需要理解和凝练应用模式的共性特征，进而通过编程接口支撑上层应用灵活实施软件定义。
+最后，需要深入理解未来泛在计算场景下应用模式的共性特征，为上层应用提供适当的、相对稳定的“功能可编程”接口。可以预见，未来泛在计算场景至少包括数据规模巨大、强调按需能力获取的“云-边”效用计算，资源需求动态变化、不确定性很强的智能计算，移动性强、承载设备多、续航要求高、迭代快的智慧城市、工业互联网等领域的协作计算，人与物相互驱动、相互协同的人机物统一计算等。这些泛在应用模式很多都处在探索阶段，需要理解和凝练应用模式的共性特征，进而通过编程接口支撑上层应用灵活实施软件定义。
 
-\subsection{复杂软件系统持续适应演化的共性支撑}\label{os-evolution}
+\subsection{基于连接协调的资源聚合与应用协同}\label{os-connection}
+
+未来的人机物融合系统将是大规模、网络化的计算系统，虽然每个节点上的节点操作系统仍通过自顶向下、精确控制的模型来达到资源虚拟化、功能可编程的目的，但这种机制很难放大到网络层面、特别是大规模网络化系统。事实上，简单放大的思路在30年前的Amobea等分布式操作系统实践中就已经尝试过，并被证明很难奏效（参见\ref{middleware}节）。根本原因在于大规模网络化的系统具有开放复杂系统的特征：1）需求和环境开放性，突出表现在此类系统通常是在不断适应需求和环境变化的过程中逐步成长演化而成的，这一过程在时间尺度上可能长达数年甚至数十年；2）行为开放性，突出表现在此类系统中存在大量非线性相互作用和涌现现象，整体的行为很难简单地通过成员系统行为来进行刻画和预测；3）边界开放性，突出表现在系统往往依赖于大量外部软件实体，自身构成不具有明确、封闭的边界，同时人（社会组织）、物理世界和软件系统边界模糊化。这些开放性将直接映射到操作系统和运行平台层面，使得要“虚拟化”的资源和“可编程”的功能都具有明显的开放性，导致很难构建出自顶向下、精确控制的模型。
+
+因此，在开放的网络化环境下，更为妥当的资源管理和应用协同方式将是 “连接协调”，即通过按需聚合和动态协同来打破不同节点之间的壁垒，统一管理并优化利用计算、数据甚至物理世界各种资源，支持应用实体的分布式自主协同。换言之，操作系统将成为通过软件定义管理复杂计算系统的“元”级系统，面向单个计算机系统的“控制”功能则逐渐转移到面向多个计算机系统“连接协调”功能。这将动摇现代操作系统构造和运行的很多基本假设。虽然相关理念在中间件领域和网构软件等范型中已有了初步实践，但一系列共性机理层面上的问题仍有待解决，包括需要何种模型来协调跨域资源及其能力、如何在动态环境下维持相对稳定的“功能可编程”抽象、如何支撑软件实体通过扁平化架构达成共识、如何有效管理调度各种冲突及涌现现象等。
+
+在机理突破基础上，“连接协调”需要何种类型的基础设施支撑，是操作系统领域另一重要挑战。近年来，以区块链\index{区块链}为代表的分布式共识\index{分布式共识}技术，特别是区块链从应用系统向运行平台蜕变的发展历程（参见\ref{blockchain-history}节），为这一方面的实践提供了一个可借鉴案例——区块链可以在相对开放环境下，通过扁平化架构和“连接协调”机制，在多种类型大规模分布式系统中构建群体的共同认知。例如，IBM的面向区块链的分布式操作系统Hyperledger Fabric\cite{Androulaki:2018:HFD:3190508.3190538}可以利用区块链来支撑分布式应用运行，并且通过模块化的共识协议灵活适应不同的应用场景和信任模型。但是，当前区块链的实际部署仍集中在金融、物流等少数领域，要使其能够为更多应用领域赋能，一系列问题仍有待解决，包括共识算法效率以及如何在效率和扩展性、安全性之间权衡、如何实现不同区块链之间的互操作、如何在形成共识同时保护隐私、如何在开放环境下实现有效监管等。更进一步，如何“来自区块链、超越区块链”，借鉴区块链思想，为未来大规模网络化系统共同认知、协同决策、行为实施等环节实现连接协调提供手段支撑，是操作系统和运行平台领域需要探索的方向。
+
+\subsection{复杂软件系统适应演化的共性支撑}\label{os-evolution}
 近年来，以人机物融合系统为背景，有研究者提出了信息产业的“昆虫纲悖论”：一方面，未来物联网设备和应用场景将会像昆虫一样繁多，带来空前巨大的市场；另一方面，由于每种场景都存在其个性化需求和特点，针对场景所开发的软件系统将缺乏可拷贝性，导致边际成本显著提高，反过来制约产业的发展。要打破这一悖论，关键在于软件系统不能静态绑定到特定场景，而应当具备灵活适应场景的能力，在其生命周期内能够持续演化来应对环境和用户需求的变化。
 
-软件适应\index{软件适应}能力将成为未来人机物融合软件系统的基本属性，而操作系统在支撑软件适应演化活动方面具有天然优势：从可计算性的角度而言，操作系统与下层硬件裸机一起组成了能够“操纵”应用软件执行的通用图灵机实现，这一“操纵”能力使得操作系统有可能驱动应用软件的适应和演化；从计算反射（Reflection）实现的角度而言，操作系统和运行平台是应用软件执行的“元层容器”，对于上层应用具有计算反射能力，例如获知上层应用和环境状态、维护系统化反映上层应用环境和状态的模型、对上层应用实施调整操作等。因此，操作系统和运行平台是驱动计算节点动态感知、自主学习、在线演化的理想载体，但这一地位也同时对平台设计实现提出了一系列挑战。
+软件适应\index{软件适应}能力将成为未来人机物融合软件系统的基本属性，而操作系统在支撑软件适应演化活动方面具有天然优势：从可计算性的角度而言，操作系统与下层硬件裸机一起组成了能够“操纵”应用软件执行的通用图灵机实现，这一“操纵”能力使得操作系统有可能驱动应用软件的适应和演化；从计算反射（Reflection）实现的角度而言，操作系统和运行平台是应用软件执行的“元层容器”，对于上层应用具有反射能力，例如获知上层应用和环境状态、维护系统化反映上层应用环境和状态的模型、对上层应用实施调整操作等。因此，操作系统和运行平台是驱动计算节点动态感知、自主学习、在线演化的理想载体，但这也同时对平台设计实现提出了一系列挑战。
+
 \begin{itemize}
-	\item 操作系统及其上应用的自主适应与学习赋能。从“网络就是计算机”到“场景就是计算机”，其蕴含的理念从计算资源聚合进一步拓展到了多样化人机物融合场景下的资源按需定制。要实现“场景就是计算机”，关键在于操作系统和其上应用需要具备主动适应新场景和场景变化的能力，包括：操作系统本身和其上应用都具有柔性体系结构，节点本身可以动态调整，节点与节点这间连接关系可以按需变化，并且携带有指导这些变化的元层数据；在操作系统和运行平台内部构建“感知－理解－调整”回路，能够捕获和理解环境及运行状态，进而据此进行应用配置生成、主动部署、参数和连接关系在线调整等操作；具有从过去的适应和演化动作及效果中持续学习的能力，从而突破预定义场景和决策规则的约束，使得操作系统及其上应用在适应场景和用户需求变化的维度上能够表现出一定的“智能”。
+	\item 操作系统及其上应用的自主适应与学习赋能。从计算资源聚合到多样化人机物融合场景下的资源按需定制，关键在于操作系统和其上应用需要具备主动适应新场景和场景变化的能力，包括：操作系统本身和其上应用都具有柔性体系结构，节点本身可以动态调整，节点与节点这间连接关系可以按需变化，并且携带有指导这些变化的元层数据；在操作系统和运行平台内部构建“感知－理解－调整”回路，能够捕获和理解环境及运行状态，进而据此进行应用配置生成、主动部署、参数和连接关系在线调整等操作；具有从过去的适应和演化动作及效果中持续学习的能力，从而突破预定义场景和决策规则的约束，使得操作系统及其上应用在适应场景和用户需求变化的维度上能够表现出一定的“智能”。
 	\item 大规模复杂软件系统\index{复杂软件系统}的演化规律及其运行支撑。人机物融合场景下，许多软件系统已经达到了空前的规模。例如，互联网的前身ARPANET仅连接了4个节点，而2018年移动社交应用微信的月活跃用户数达到了10.8亿。规模上的量变引起质变，此类系统具有与单个节点或小规模分布式系统不同的演化规律，带来了一系列挑战性问题：软件系统规模巨大，其海量状态数据之间存在着千丝万缕的联系，如何“去粗取精、去伪存真”，提取能够作为适应演化依据的运行态势数据；系统中的节点通过“连接”形成了一个复杂网络，如何基于复杂网络中的交互掌握软件体系结构和运行大势；在由大量自治软件单元所组成的软件系统中，适应性演化动作往往发生在单元、子系统、系统等多个尺度上，如何在群体层面上形成恰当的适应性演化行为，以及不同层次上的适应性演化如何相互影响；等等。
-	\item “人在回路中”的软件系统演化决策。软件是“由人开发，为人开发”的产品，人在软件生命周期各个阶段所发挥的作用不可替代，人是软件产品需求的提出者，也是需求落地实施的开发者，同时也是软件终端的使用者以及运行时的维护和升级者。因此，未来人机物融合软件系统适应性演化决策应当是软件和人相结合的方式，除了现有的规则、策略、机器学习等自动化方法外，“人在回路中”是其重要的特点，主要表现为两种形态：操作系统和运行平台集成DevOps工具链，来有效支持人来发挥作用；软件系统从平台层所累积的人的行为数据、特别是群体行为数据中进行主动学习，从而不断提升其演化决策能力。
-	\item“信息-物理-社会”空间的协同持续演化。复杂软件系统是典型的“社会-技术-物理”系统，软件将与其所在的社会和物理环境紧密融合在一起，相互作用、相互影响。这与传统的、完全在信息空间运行的软件有着质的区别。具体到基础性的、“操纵计算系统执行”的操作系统和运行平台层面，需要有能力支撑上层应用与物理世界和人类社会长期性的共同进化。这将显著扩展现有操作系统的内涵，带来一组极具挑战性的开放问题，例如：物理空间变化的频率远高于信息空间变化的频率，如何高效地支撑上层软件适应物理空间的变化；利用人工智能算法来进行演化决策，一旦决策错误可能会直接在物理空间造成严重后果，操作系统和运行平台应当提供什么样的监督、审计和补偿机制；等等。
+	\item “人在回路中”的软件系统演化决策。软件是“由人开发，为人开发”的产品，人在软件生命周期各个阶段所发挥的作用不可替代，人是软件产品需求的提出者，也是需求落地实施的开发者，同时也是软件终端的使用者以及运行时的维护和升级者。因此，未来人机物融合软件系统适应性演化决策应当是软件和人相结合的方式，除了现有的规则、策略、机器学习等自动化方法外，“人在回路中”是其重要的特点，主要表现为三种形态：操作系统和运行平台集成DevOps工具链，来有效支持人作为“指导者”（Oracle）来发挥作用；软件系统从平台层所累积的人的行为数据、特别是群体行为数据中进行主动学习，从而不断提升其演化决策能力；人与软件实体协同工作，在宏观尺度上通过人的行为演化驱动软件演化，实现行为涌现和人机协同演化。
+	\item“信息-物理-社会”空间的协同持续演化。未来软件将与其所在的社会和物理环境紧密融合在一起，相互作用、相互影响。这与传统的、完全在信息空间运行的软件有着质的区别。具体到基础性的、“操纵计算系统执行”的操作系统和运行平台层面，需要有能力支撑上层应用与物理世界和人类社会长期性的共同进化。这将显著扩展现有操作系统的内涵，带来一组极具挑战性的开放问题，例如：物理空间变化的频率远高于信息空间变化的频率，如何高效地支撑上层软件适应物理空间的变化；利用人工智能算法来进行演化决策，一旦决策错误可能会直接在物理空间造成严重后果，操作系统和运行平台应当提供什么样的监督、审计和补偿机制；等等。
 \end{itemize}
 
 \subsection{人机物融合过程中的安全与隐私保护}\label{os-security}
 
 数十年来，“魔高一尺，道高一丈”，主流操作系统不断围绕系统用户认证、访问控制、数据安全、漏洞攻击缓解等方面进行安全增强。然而，安全与隐私保护是一种伴生技术，新的安全问题伴随新计算模式的涌现而不断产生。未来，随着5G通讯、移动互联、云计算与物联网的应用普及，人机物将广泛互联，在网络虚拟世界与现实世界的行为将实现虚实深度融合，导致信息系统的安全防御边界愈加模糊，面临的安全威胁在种类和数量上都将激增，用户隐私保护的难度显著增加。在未来人机物融合的过程中，作为信息空间与物理空间乃至整个社会进行统一信息处理的载体，操作系统及运行平台在安全和隐私保护方面的需求将面临一系列挑战：
 
-首先，需要在大规模松耦合交互场景下建立虚实融合的信任关系。在未来人机物深度融合的时代，将会有大量物理设备与应用软件接入到运行平台，以数字身份作为运行主体在系统中发挥作用。随着越来越多的现实世界行为被迁移到网络虚拟空间进行处理，在数字世界中如何对纷繁芜杂的虚拟社会关系进行准确刻画并实施严格管理，是构筑未来安全可信数字空间的所必须要面对的挑战。在此基础上，要建立数字身份的信任关系，还需要在平台层面上对数字实体在虚拟世界的行为进行全面、如实地记录，为准确刻画数字世界实体间的信任关系提供有力依据。并且，由于现实社会中主体之间关系的大规模、松耦合特性，原有的集中式管理方式对人机物融合系统的实体管理将无法适用，需要实现管理的弱中心化，基于众包、基于区块链等新型信任关系构建方法已在操作系统领域崭露头角。例如，IBM的面向区块链的分布式操作系统Hyperledger Fabric\cite{Androulaki:2018:HFD:3190508.3190538}可以利用区块链来支撑分布式应用运行，并且通过模块化的共识协议来使得系统可以灵活适应不同的应用场景和信任模型。
-
-其次，需要实现人机物融合场景下的严苛安全和隐私保护需求。人机物融合场景下计算节点众多、数据传输分散，诸如边缘计算等以“计算尽可能靠近数据的源头”为基本理念的计算模式将走向前台。而这些新的计算模式由于其服务模式的复杂性、实时性，数据的多源异构性、感知性以及终端的资源受限特性，传统数据安全和隐私保护机制将很难高效应用。同时，由于移动终端的资源一般都比较有限，其所能承载的数据存储计算能力和安全算法执行能力也有一定的局限性。如何将传统的隐私保护方案与边缘计算环境中边缘数据处理特性相结合，从数据隐私、位置隐私、身份隐私等多个方面入手研究相应的保护方案，是未来操作系统安全与隐私保护领域面临的重要挑战。同时，为了支撑广泛、大规模的人机物融合和互联，需要突破现有操作系统安全和隐私保护的被动防御机制、打破“信任篱笆”，强化安全与隐私保护的主动性与支配性，在利益与风险之间权衡，既关注更强、更灵活的隐私保护，又支持网络资源共享和互联互通。
+首先，需要在大规模松耦合交互场景下建立虚实融合的信任关系。在未来人机物深度融合的时代，将会有大量物理设备与应用软件接入到运行平台，以数字身份作为运行主体在系统中发挥作用。随着越来越多的现实世界行为被迁移到网络虚拟空间进行处理，在数字世界中如何对纷繁芜杂的虚拟社会关系进行准确刻画并实施严格管理，是构筑未来安全可信数字空间的所必须要面对的挑战。在此基础上，要建立数字身份的信任关系，还需要在平台层面上对数字实体在虚拟世界的行为进行全面、如实地记录，为准确刻画数字世界实体间的信任关系提供有力依据。并且，由于现实社会中主体之间关系的大规模、松耦合特性，原有的集中式管理方式对人机物融合系统的实体管理将无法适用，需要实现管理的弱中心化，基于区块链等新型分布式信任关系构建方法已在操作系统领域崭露头角。
 
+其次，需要实现人机物融合场景下的严苛安全和隐私保护需求。人机物融合场景下计算节点众多、数据传输分散，诸如边缘计算等以“计算尽可能靠近数据的源头”为基本理念的计算模式将走向前台。而这些新的计算模式由于其服务模式的复杂性、实时性，数据的多源异构性、感知性以及终端的资源受限特性，传统数据安全和隐私保护机制将很难高效应用。同时，由于移动终端的资源一般都比较有限，其所能承载的数据存储计算能力和安全算法执行能力也有一定的局限性。如何将传统的隐私保护方案与边缘计算环境中边缘数据处理特性相结合，从数据隐私、位置隐私、身份隐私等多个方面入手研究相应的保护方案，并沉淀为软件基础设施，是未来操作系统安全与隐私保护领域面临的重要挑战。同时，为了支撑广泛、大规模的人机物融合和互联，需要突破现有操作系统安全和隐私保护的被动防御机制、打破“信任篱笆”，强化安全与隐私保护的主动性与支配性，在利益与风险之间权衡，既关注更强、更灵活的隐私保护，又支持网络资源共享和互联互通。
 
 \section{主要研究内容}
-如本章伊始所述，未来操作系统将具有两种形态：一方面，在新型硬件技术和新型应用场景的共同驱动下，今天我们所熟知的、以单一计算节点为作用空间的操作系统（以下称节点操作系统）将继续快速发展；另一方面，随着人机物融合、特别是“软件定义一切”付诸实践，诸如“泛在操作系统”等新一代操作系统将出现，它们运行于经典操作系统之上，通过“连接协调”实现网络环境下人机物异构资源聚合和优化管理，支撑各种类型、不同尺度的泛在应用。
-
-本节将围绕未来操作系统的上述两种形态，阐述操作系统和运行平台的研究趋势与内容。其中，§\ref{os-research1}-§\ref{os-research3}聚焦节点操作系统，§\ref{os-research4}-§\ref{os-research7}聚焦新一代操作系统，§\ref{os-research8}和§\ref{os-research9}则分别重点阐述与软件适应和演化、操作系统生态链构建相关的问题（图\ref{fig3}）。
+如本章伊始所述，未来操作系统将具有节点操作系统和以网络为核心的新一代操作系统两种形态。前者是对今天经典操作系统的继承与发展，后者以“泛在操作系统”\cite{mei2018toward}等为代表，运行于经典操作系统之上，通过“连接协调”实现网络环境下人机物异构资源聚合和优化管理，支撑各种类型、不同尺度的泛在应用。本节将围绕未来操作系统的上述两种形态，阐述操作系统和运行平台的研究趋势与内容。其中，§\ref{os-research1}-§\ref{os-research3}聚焦节点操作系统，§\ref{os-research4}-§\ref{os-research8}聚焦新一代操作系统，§\ref{os-research9}和§\ref{os-research10}则分别重点阐述与软件适应和演化、操作系统生态链构建相关的问题（图\ref{fig3}）。
 
 \begin{figure}[htbp]
 	\centering
@@ -81,7 +90,7 @@
 \end{figure}
 
 \subsection{新型硬件资源管理和调度技术}\label{os-research1}
-过去60年中，大型主机、个人计算机、手持移动设备、物联网设备等不同类型计算设备的出现，推动着经典操作系统技术的持续变革。近年来，处理器、存储器件、网络互联设备等硬件技术快速发展，众核处理器、FPGA/GPU加速硬件、非易失内存、远程直接数据存取（RDMA）网络等一系列高性能、具有新架构和新特征的新型硬件不断涌现，并逐渐成为主流技术。作为计算系统的“管家”，如何充分适应新型硬件特点并充分发挥其潜能，是操作系统理论和技术的重要研究内容。例如，大规模分布式异构计算以及移动异构片上系统，对Linux等多线程共享存储的单内核结构提出挑战；多核和多芯片计算机系统中非一致性内存访问架构使得传统基于页的虚存系统面临挑战；非易失性内存的应用使得内存中的某些数据不再需要存储到硬盘，在为操作系统带来性能优化空间的同时，对传统类POSIX文件系统架构带来挑战；目前已有的设备模拟、设备半虚拟化、设备直通、单根虚拟化（SR-IOV）等技术尚不能完全扩展到GPU、张量处理器等人工智能新型加速器，或者是效率和灵活性还需要进一步提升； 100G及以上以太网链路在大规模数据中心的普及，网络带宽增长速度超越CPU处理能力增长速度，传统的操作系统网络协议栈面临挑战；等等。
+近年来，计算机硬件技术发展迅速，并且表现出向“上”（高性能）、“下”（轻量级）两端拓展的趋势。作为计算系统的“管家”，如何充分适应新型硬件特点并充分发挥其潜能，是操作系统理论和技术的重要研究方向，研究内容包括：新型基础内核架构将汲取宏/微等不同类型内核的长处，研究实现适合多样化应用场景和新型硬件特点、易于裁剪定制的新一代操作系统内核架构；异构资源融合支撑着重针对”CPU+xPU“硬件体系结构，解决异构编程模型、同步和通信机制、访存效率的优化等问题，实现高效易用的异构资源使用模式；面向极端硬件和应用的轻量级虚拟化机制，将结合硬件虚拟化支持研究轻量级虚拟化的实现与虚拟化资源管理机制，满足大规模虚拟化管理以及极端硬件（如FPGA/GPU加速硬件、TB级内存、非易失性存储器等）条件下的虚拟化需求；应用场景支撑能力主要研究智能计算、边缘计算以及云边端融合应用场景下的基础系统共性支撑环境，为在节点粒度上为新一代人机物整合应用实现可编程的资源和能力抽象。
 
 \subsection{面向特定应用领域的优化技术}\label{os-research2}
 当前，运行于单一计算节点的操作系统架构已经趋于稳定，但移动计算、物联网等特定应用领域的快速发展，推动着相应操作系统实现优化技术的突破。一方面，移动计算已经是主流的计算模式之一，智能移动终端的操作系统当前已经形成了较为成熟的产业生态。但是，移动计算与边缘计算、人工智能等新兴领域的交叉融合，推动着其架构和实现机理的不断拓展，相应操作系统也表现出向低功耗、强交互、智能化和高安全发展的趋势，研究内容包括轻量级操作系统体系结构、多场景自适应电源管理优化、资源受限环境下的深度学习适配优化、多种生物特征认证增强等。另一方面，随着物联网等设备的普及，针对嵌入式计算中安全关键、任务关键、非关键等任务混合运行及其安全隔离问题，围绕任务确定性调度、系统实时响应、任务间高效通信、操作系统内核验证等技术展开研究，满足嵌入式计算在复杂环境中对系统实时性、安全性、可靠性的严酷要求。
@@ -89,27 +98,30 @@
 \subsection{软硬协同的安全攻防对抗技术}\label{os-research3}
 如何结合处理器和硬件平台的特点，设计新型安全高效的操作系统结构，是未来操作系统技术的另一主要研究内容。当前，基于CPU的可信计算空间隔离和基于TPM芯片的可信计算技术为可信软件执行提供了硬件级的执行验证，这些技术都从操作系统底层提供了有力的可信执行支持。未来操作系统安全研究将发展软硬协同的操作系统安全攻防对抗模式，变被动响应为主动防护，夯实信息系统的安全基础。具体而言，需要突破软硬件高效协同的安全体系结构设计、安全防护模型和方法、跨域交互机理及优化方法和基于模糊测试的内核安全性测试等关键技术，结合硬件平台提供的多层次特权防护、资源分区隔离等安全能力，解决软硬协同的高安全操作系统设计中的核心问题。
 
-\subsection{面向新型架构的资源虚拟化技术}\label{os-research4}
-以“函数即服务”（FaaS）为代表的无服务器计算等计算模式和边缘计算等新型应用模式给传统操作系统和虚拟化架构带来了挑战。首先，虚拟化技术需要能够在支持多租户隔离的前提下实现高密度的资源虚拟化。以在边缘计算场景为例，与集中式云数据中心不同，可能需要在边缘的十几个服务器上分别支持数千种不同的服务，当前已有的基于容器的轻量级虚拟化技术尚不能完全满足。其次，在无服务器计算和边缘计算等场景中，应用对资源的需求是高度动态变化的，这给虚拟化的性能提出了苛刻要求，需要探索新的轻量级虚拟化架构和优化机制。再次，部分云计算应用开始出现向微服务应用发展的趋势。这意味着软件体系结构进一步地解耦，单个镜像上运行的业务更加专一。因此，当前提出了 Unikernel等机制来大幅度精简冗余模块来提高虚拟机的启动速度，但虚拟化场景下的适用性和成熟度还需要进一步提升。最后，计算资源之外的其它资源（如GPU、存储、网络等）专用虚拟化技术需要进一步探索。
+\subsection{面向分布应用的资源虚拟化技术}\label{os-research4}
+虚拟化技术不仅仅能够在单台计算机上实现资源的有效隔离，更重要的是在分布计算环境下能够实现大量资源的细粒度管理，为弹性可伸缩的资源聚合奠定基础，这也是为什么云计算高度依赖虚拟化技术的原因。当前“函数即服务”（FaaS，Function as a Service）、边缘计算等新型分布计算应用模式正在涌现，操作系统在资源 虚拟化方面需要突破一系列理论和实践问题。首先，虚拟化技术需要能够在支持多租户隔离的前提下实现高密度的资源虚拟化。以在边缘计算场景为例，与集中式云数据中心不同，可能需要在边缘的十几个服务器上分别支持数千种不同的服务，当前已有的基于容器的轻量级虚拟化技术尚不能完全满足。其次，在无服务器计算和边缘计算等场景中，应用对资源的需求是高度动态变化的，这给虚拟化的性能提出了苛刻要求，需要探索新的轻量级虚拟化架构和优化机制。再次，部分云计算应用开始出现向微服务应用发展的趋势。这意味着软件体系结构进一步地解耦，单个镜像上运行的业务更加专一。当前提出了 Unikernel等机制来大幅度精简冗余模块来提高虚拟机的启动速度，但虚拟化场景下的适用性和成熟度还需要进一步提升。最后，在分布环境下，计算资源之外的其它资源（如网络等）专用虚拟化技术需要进一步探索。
 
-\subsection{跨结点的资源高效按需聚合技术}\label{os-research5}
-“计算的泛在化”意味着操作系统和运行平台的作用范围突破了传统单一计算结点范畴，需要在广域环境内调度各类资源，为上层软件提供相对稳定的抽象。在计算系统规模持续增长的情况下，需要突破海量虚拟机资源的高效管理、虚拟机间通信优化、自适应的虚拟机在线迁移及动态部署、共生虚拟机间共享内存的弹性管理及优化、虚拟机访存效率优化等技术，实现跨结点的高效分布式计算资源调度。另一方面，网络操作系统中往往没有明确、固化的控制中心或层次结构，跨结点的“资源虚拟化”和“能力可编程”主要依靠“连接协调”、通过自底向上的方式来实现。如何借鉴社会系统、经济系统、生物系统等复杂系统机理，实现上述目标，也是此类操作系统面临的挑战。
+\subsection{跨节点的资源高效按需聚合技术}\label{os-research5}
+“计算的泛在化”意味着操作系统和运行平台的作用范围突破了传统单一计算节点范畴，需要在广域环境内调度各类资源，为上层软件提供相对稳定的抽象。在计算系统规模持续增长的情况下，需要突破海量虚拟机资源的高效管理、虚拟机间通信优化、自适应的虚拟机在线迁移及动态部署、共生虚拟机间共享内存的弹性管理及优化、虚拟机访存效率优化等技术，实现跨节点的高效分布式计算资源调度。另一方面，网络操作系统中往往没有明确、固化的控制中心或层次结构，跨节点的“资源虚拟化”和“能力可编程”主要依靠“连接协调”、通过自底向上的方式来实现。如何借鉴社会系统、经济系统、生物系统等复杂系统机理，实现上述目标，也是此类操作系统面临的挑战。
 
-在跨结点的资源按需聚合方面，未来的一个重要应用模式是“云-边-端”\index{“云-边-端”}协同模式。因此，需要面向现代网络化信息支撑体系的发展趋势，探索以资源虚拟化、服务云化、前后融合为基本特征的“云-边-端”协同操作系统柔性结构设计与优化技术，研究“云-边-端”高效资源协同调度框架、基于云边端协同和多目标优化的任务调度技术等。
+在跨节点的资源按需聚合方面，未来的一个重要应用模式是“云-边-端”\index{“云-边-端”}协同模式。因此，需要面向现代网络化信息支撑体系的发展趋势，探索以资源虚拟化、服务云化、前后融合为基本特征的“云-边-端”协同操作系统柔性结构设计与优化技术，研究“云-边-端”高效资源协同调度框架、基于云边端协同和多目标优化的任务调度技术等。
 
 \subsection{多租户条件下的主动防御技术}\label{os-research6}
 多租户将是未来运行平台的主流应用形态之一。更多的服务被整合在单一平台上，这些服务中可能包括了来自不同租户的不同安全等级的信息，必须根据用户需求对应用系统的硬件、软件、数据、网络、存储等不同层面资源实现安全隔离。同时，为了提高资源利用效率，运行平台根据资源使用情况进行动态调度，这种动态变化的环境将显著增大了安全隔离的难度。为了提高服务运行性能，以Docker为代表的轻量级虚拟化容器技术也被广泛应用，相对于虚拟机的强隔离性，容器技术则是以弱隔离性换取性能的提高。在应用虚拟化技术的过程中，隔离性与性能之间的取舍、动态变化下虚拟计算资源的安全复用、Hypervisor（虚拟机监视器）层的虚拟机监管、虚拟机逃逸防护等都成为必须要面对的挑战。同时，虚拟化技术还需要对软件定义网络在数据中心内部的网络安全管理提供支持，通过虚拟网关等技术对虚拟化数据流进行安全监控，这些虚拟设备能否安全使用都将对系统安全性产生深刻的影响。
 
-\subsection{物理和社会资源的抽象和管控技术}\label{os-research7}
+\subsection{规模化应用中的群体共识形成技术}\label{os-research7}
+以区块链为代表的共识机制将成为新一代操作系统和运行平台的组件之一，为分布式和去中心化应用形成群体共识提供支撑。要实现这一目标，需要从如下一些方面开展研究：区块链技术本身具有可扩展性、去中心化和安全性三者不可兼得的“三元悖论”难题，在区块链成为运行平台组件后，需要针对应用场景特点突破侧重点不同的共识算法，进而通过定制机制实现场景特化的三元平衡寻优；区块链技术在渗透至不同场景后，为了支持价值在不同行业与场景之间流动，支持不同行业与场景群体之间的协作交互，实现区块链的互操作性势在必行，需要针对公证人、侧链、原子交换、分布式私钥控制等为代表的跨链技术深入展开研究；为了保证共识形成，区块链中事务信息需要通过网络传播给大范围节点，需要不断完善链内数据产生、验证、存储和使用整个过程中的隐私保护机制；区块链的匿名性给网络监管机构带来了极大的挑战和威胁，当前对公有链的监管尚无有力技术手段，而如何在保护隐私的前提下实现监管，也是当前联盟链面临的重大挑战；最后，需要深入研究在应用层如何充分发挥区块链的优势和潜力，针对可信计算、共同认知、自主协同等不同场景探索其适用范围。
+
+\subsection{物理和社会资源的抽象和管控技术}\label{os-research8}
 操作系统 “资源虚拟化”的能力来自于其对资源的抽象、封装和调度。传统操作系统针对信息空间内部的资源，已经建立了进程/线程、内存页/虚拟内存、文件等相对稳定的抽象实体。未来，在人机物融合系统中，如何表达和管理各类高度异构、动态变化的物理和社会资源，是操作系统领域的开放问题。其中一个核心问题是：在认知、物理和信息空间三者之间，如何刻画、检验、保持、校正多模型结构之间定性与定量一致性，进而实现具有“数字孪生”的物理和社会空间资源的调度和管理。此外，未来操作系统的编程接口不仅涉及到计算资源的“软件定义”，可能包括各种可传感物体对象、智能无人系统等各类物理资源，甚至向其他具有“数字孪生”特性的经济、社会和生产生活资源，其接口形式、接口实现机理等都是开放的问题。
 
-\subsection{运行平台支持的软件持续演化技术}\label{os-research8}
-适应和演化是未来人机物融合软件的基本特征，其实现机制牵涉到两个层面。首先，未来人机物融合软件的运行平台自身应当是可以是柔性设计、可以持续演化的。其次，操作系统和运行平台是能够支撑上层应用适应和演化的天然基础设施，但由于在线演化的需求是在“软件作为基础设施”过程中逐渐显现的，其实现机理也是目前操作系统和运行平台领域研究相对薄弱的环节，需要从运行状态把握、群体智能决策调整、宏观和微观演化效果评估等角度开展研究。相关研究内容已经在\ref{os-evolution}节中给出，本节不再赘述。
+\subsection{运行平台支持的软件持续演化技术}\label{os-research9}
+适应和演化是未来人机物融合软件的基本特征，其实现机制牵涉到两个层面。首先，未来人机物融合软件的运行平台自身应当是柔性设计、可以持续演化的。其次，操作系统和运行平台是能够支撑上层应用适应和演化的天然基础设施，应当为其提供相应支撑。由于在线演化的需求是在“软件作为基础设施”过程中逐渐显现的，其实现机理也是目前操作系统和运行平台领域研究相对薄弱的环节，需要从态势评估、演化决策、效果评估、人机物协同演化等多个角度开展研究。首先，作为支撑复杂软件系统运行的“元层容器”，操作系统和运行平台有可能采集到各个软件实体的运行状态和环境状态，基于大数据的软件系统态势评估需要从中“去粗取精、去伪存真”，提取出能够作为适应和演化依据的运行态势。其次，为了支撑软件根据环境和状态变化自主做出在线调整和演化的决策，操作系统和运行平台需要提供什么样的支撑，以及在这一过程中如何支持“人在回路中”发挥作用，这一问题仍有待深入探索。再次，由大量自治软件单元所组成的复杂软件系统中，适应性演化动作往往发生在单元、子系统、系统等多个尺度上，需要在”元层“对各个尺度上的演化效果进行评估，必要时进行多个尺度上的演化调整。最后，如\ref{os-evolution}节所述，新一代操作系统需要有能力支撑“信息-物理-社会”空间的协同持续演化，相关机理和实现机制亟待突破。
 
-\subsection{基于开源和众包的生态构建技术}\label{os-research9}
-随着互联网的深入发展和广泛应用，操作系统和运行平台的研发出现了新的特点，其中开源和众包对操作系统的发展产生了深远影响。它们一方面改变了操作系统产业的商业模式，服务化成为趋势，操作系统厂商如苹果、微软纷纷从销售产品获利转型为提供服务获利的模式；另一方面促进了面向行业或应用场景需求的专用操作系统的发展，降低了操作系统研发定制的门槛，使得更多的厂商可以参与到操作系统生态链构建中来。但是，开源和众包模式的引入，也为操作系统的开发带来了一系列问题。例如，在使用开源资源时，如指导思想和方法不当，可能导致在产品中包含若干“黑盒子”，引入代码不可控、产品升级被动等风险；产品如过度依赖开源，发展途径就会被开源主导，创新的空间将被大幅约束；等等。如何在操作系统生态链构建过程中最大限度发挥开源和众包的长处，是需要深入研究的问题，相关的研究方向包括操作系统代码来源链的建模和分析、开源许可证的合规性及冲突分析、多来源缺陷数据的定性与定量统计分析等。
+\subsection{基于开源和众包的操作系统生态链构建技术}\label{os-research10}
+开源和众包对操作系统及其上生态链的发展已经产生深远影响。如何在操作系统生态链构建过程中，最大限度扬长避短，发挥开源和众包的优势，是需要深入研究的问题。首先，在使用开源资源时，如指导思想和方法不当，可能导致在产品中包含若干“黑盒子”，引入代码不可控、产品升级被动等风险，因此，需要研究操作系统代码来源链的建模和分析方法，以及多来源和开源/闭源混源代码缺陷的定位和溯源方法。其次，开源的优势之一是可以促进面向行业或应用场景需求的专用操作系统的发展，在严格遵循开源许可证的前提下，实现操作系统的快速定制。这可能会对操作系统的可剪裁性产生深远影响，甚至催生未来新的商业模式。再次，如何在技术、平台和机制设计层面上驱动开源社区的群智汇聚，丰富和完善操作系统及其上软件生态链，也是未来系统软件领域的重要研究内容。
 
 \section{本章小结}
-无论是今天还是未来，操作系统都是“软件作为基础设施”的集中体现，也是“软件定义一切”能力的基石。在计算泛在化背景下，未来的操作系统将突破当前单机操作系统这一狭义形式，向支撑人机物融合、具有“资源虚拟化”和“功能可编程”特点的泛化运行平台过渡。受这一趋势所推动，一系列重大挑战性问题涌现，包括支持软件定义的新型运行平台架构、泛在资源的高效虚拟化和调度方法、软件系统持续适应演化的支撑机制、人机物融合过程中的安全与隐私问题等。本节对上述挑战的概念内涵、产生背景和展开后的具体问题进行了详细阐述，并在此基础上结合操作系统和运行平台领域当前研究热点，从未来操作系统的不同形态角度，对领域研究内容进行了梳理。
+无论是今天还是未来，操作系统都是“软件作为基础设施”的集中体现，也是“软件定义一切”能力的基石。在计算泛在化背景下，未来的操作系统将突破当前单机操作系统这一狭义形式，向支撑人机物融合、具有“资源虚拟化”和“功能可编程”特点的泛化运行平台过渡。受这一趋势所推动，一系列重大挑战性问题涌现，包括支持软件定义的新型运行平台架构、泛在资源的高效虚拟化和调度方法、软件系统持续适应演化的支撑机制、人机物融合过程中的安全与隐私问题等。本节对上述挑战的概念内涵、产生背景和展开后的具体问题进行了详细阐述，并在此基础上结合操作系统和运行平台领域当前研究热点，从未来操作系统的不同形态角度，对领域研究方向及内容进行了梳理。