This commit is contained in:
dingbo 2019-10-07 21:36:19 +08:00
parent cfecc5a502
commit 23d5120eec
11 changed files with 74 additions and 54 deletions

View File

@ -1,7 +1,7 @@
% !TEX root = main.tex
\section{系统软件概述}
系统软件是驱动下层计算资源有效运转、为上层应用提供共性支撑的软件,主要包括操作系统、编译系统、中间件和数据库管理系统。其中,操作系统负责管理计算系统软硬件资源、操纵程序运行,为应用软件提供公用支撑;编译系统(又称编译器)负责将源语言编写的源程序翻译为等价的可运行目标程序;中间件将系统软件的概念扩展到网络环境,为分布式应用软件部署、运行和管理提供支撑;数据库管理系统旨在统一管理和维护数据库中的数据,是存储、组织、联接、变换和加载数据的软件。
系统软件是驱动下层计算资源有效运转、为上层应用提供共性支撑的软件,主要包括操作系统、编译系统、中间件和数据库管理系统。其中,操作系统负责管理计算系统软硬件资源、操纵程序运行,为应用软件提供公用支撑;编译系统(又称编译器)负责将源语言编写的源程序翻译为等价的可运行目标程序;中间件将系统软件的概念扩展到网络环境,为分布式应用软件部署、运行和管理提供支撑;数据库管理系统旨在统一管理和维护数据库中的数据,是组织、存储、存取、控制和维护数据的软件。
与面向特定领域、解决特定问题的应用软件不同,系统软件是运行于计算“系统”层面上的软件。此处的“系统”有两层含义:
@ -9,10 +9,11 @@
\item 系统软件将计算系统的概念从硬件扩展到了软件层面。通过将底层硬件资源进行适当地抽象和封装,系统软件为上层应用提供了一个软件平台(也可以称为“虚拟机”),使得上层应用软件可以方便使用各类资源能力,无需关注底层细节。这一平台承担了共性的资源管理功能,屏蔽了异构性和细节,使得计算系统易于使用、易于编程。系统软件作为平台化基础设施,同时也封装了许多共性问题的解决方案,以避免应用软件去“重复发明轮子”。
\item 系统软件是驱动计算系统有效运转的控制器/协调者。系统软件一方面与计算系统中各类硬件资源直接交互管理、调度和使用这些资源使得之可以高效协同另一方面系统软件也直接操纵管控上层应用的运行从而达到提高程序装载和调度的自动化程度、提高资源利用率等目标。例如操作系统可以通过批处理、分时共享等方法来实现计算系统作业任务切换因此早期也被称为“监督例程”Supervisory Program或“控制程序”[1]。
\end{itemize}
系统软件并不是与计算机一起诞生的它的出现有内因和外因两个方面。早期的计算机如ENIAC编程采用接线和开关等手工操作方式并没有系统软件的概念。即使在存储程序计算机出现之后系统软件也并未马上出现应用直接在裸机上运行。但是将应用与硬件祼机直接绑定无论是运行效率、编程难度还是场景复用能力都十分低下。系统软件通过维护一个“虚拟机”来解决这一问题它一方面通过对资源和应用的操纵控制承担起计算机硬件资源管理功能另一方面也通过封装与抽象使得应用软件更加易于编码实现和加载运行。系统软件出现的外因则是软件复杂性增长所导致的分工细化特别是上个世纪50-60年代面向底层硬件资源的系统程序设计System Programming和面向领域的应用程序设计Application Programming的分化以及系统程序员和应用程序员的分工直接推动了系统软件这一概念的广泛接受。
系统软件并不是与计算机一起诞生的它的出现有内因和外因两个方面。早期的计算机如ENIAC编程采用接线和开关等手工操作方式并没有系统软件的概念。即使在存储程序计算机出现之后系统软件也并未马上出现应用直接在裸机上运行。但是将应用与硬件祼机直接绑定无论是编程难度、应用管理/切换效率还是底层资源利用率都十分低下。特别是早期CPU速度和I/O速度之间的巨大差异基于时分复用的“虚拟化”成为客观需求推动了系统软件、尤其是操作系统的快速发展。系统软件出现的外因则是软件复杂性增长所导致的分工细化特别是上个世纪50-60年代面向底层硬件资源的系统程序设计System Programming和面向领域的应用程序设计Application Programming的分化以及系统程序员和应用程序员的分工直接推动了系统软件这一概念的广泛接受。
\section{操作系统}
从功能定位的角度而言,操作系统是负责管理硬件资源、控制程序运行、改善人机界面和为应用提供支持的系统软件,是计算机软件生态链的基础核心。在一个计算系统中,操作系统向下是最靠近硬件的一层软件,它通过调用硬件驱动程序、固件等方式实现对硬件的管理;向上屏蔽硬件细节,为应用软件提供功能更为完善、灵活可编程的“虚拟机”,并通过事件循环等实现对各类应用软件的运行管理。因此,操作系统兼具“承上启下”和“管家”两类作用。由于操作系统的特殊地位,其发展与上层应用需求和底层硬件形态的演化都有着密切联系。从最初与硬件和应用场景高度绑定,到之后逐渐独立于硬件,操作系统向上提供的服务越来越多、向下针对硬件的抽象程度越来越高,其内涵和外延不断拓宽,并在积累一段时间后产生质变,表现出大约每隔20年一次的跨越式发展的周期律“主机-个人计算-互联网和移动计算”,\ref{fig:3-1})。
从功能定位的角度而言,操作系统是负责管理硬件资源、控制程序运行、改善人机界面和为应用提供支持的系统软件,是计算机软件生态链的基础核心。在一个计算系统中,操作系统向下是最靠近硬件的一层软件,它通过调用硬件驱动程序、固件等方式实现对硬件的管理;向上屏蔽硬件细节,为应用软件提供功能更为完善、灵活可编程的“虚拟机”,并通过事件循环等实现对各类应用软件的运行管理。因此,操作系统兼具“承上启下”和“管家”两类作用。由于操作系统的特殊地位,其发展与上层应用需求和底层硬件形态的演化都有着密切联系。从最初与硬件和应用场景高度绑定,到之后逐渐独立于硬件,操作系统向上提供的服务越来越多、向下针对硬件的抽象程度越来越高,其内涵和外延不断拓宽,并在积累一段时间后产生质变,呈现出主机计算、个人计算、互联网和移动计算等明显阶段性特点(\ref{fig:3-1})。
\begin{figure}[htbp]
\centering
@ -83,12 +84,14 @@
\item 智能终端操作系统
移动操作系统是“端”操作系统的典型代表。近年来移动计算、特别是智能手机的出现推动了移动操作系统的快速发展典型实例包括Google的Android和Apple的iOS。此类操作系统在架构上与个人计算机操作系统并无本质区别但更强调对移动和手持环境的支持包括移动网络接入、各类传感器数据获取、电池管理、触摸屏交互等。与个人计算时代类似操作系统在移动计算软硬件生态链中同样具有核心基础地位特别是操作系统内置应用商店的出现在降低用户查找、获取和安装应用程序难度的同时也形成了较完善的商业模型。移动操作系统当前还表现出了与桌面系统一体化的发展趋势通过统一桌面和移动操作系统及其生态将有利于操作系统更好地发展与维护。例如谷歌继移动操作系统Android和轻量级桌面系统ChromeOS之后正在研制跨平台的Fuchsia操作系统。此外随着万物互联时代的到来以华为“鸿蒙”等为代表的轻量级、面向分布式环境、强调“联接”的物联网操作系统也正在逐步走向成熟。
移动操作系统是“端”操作系统的典型代表。近年来移动计算、特别是智能手机的出现推动了移动操作系统的快速发展典型实例包括Google的Android和Apple的iOS。此类操作系统在架构上与个人计算机操作系统并无本质区别但更强调对移动和手持环境的支持包括移动网络接入、各类传感器数据获取、电池管理、触摸屏交互等。与个人计算时代类似操作系统在移动计算软硬件生态链中同样具有核心基础地位特别是操作系统内置应用商店的出现和广泛接受在降低用户查找、获取和安装应用程序难度的同时也形成了较完善的商业模型极大推动了以操作系统为核心的软件生态链的成长。移动操作系统当前还表现出了与桌面系统一体化的发展趋势通过统一桌面和移动操作系统及其生态将有利于操作系统更好地发展与维护。例如谷歌继移动操作系统Android和轻量级桌面操作系统ChromeOS之后正在研制跨平台的Fuchsia操作系统。
近年来以Android Things、Ubuntu Core、Mbed和华为“鸿蒙”等为代表的物联网操作系统正在成为操作系统领域新的热点。此类操作系统在嵌入式操作系统基础上一方面强调对“连接”、以及建立在连接基础上的分布计算甚至“云-端”融合的支持,从而有力支撑“万物互联”的目标;另一方面强调对异构物理网设备能力的统一抽象,从而屏蔽物联网设备的碎片化特征,为提升物联网的可管理性和可维护性、构建物联网良好生态环境奠定基础
\end{enumerate}
\section{编译系统}
编译系统是将源语言(例如高级程序设计语言)编写的代码翻译为等价的、高效的、能被计算机或虚拟机执行的目标代码(例如机器语言)的系统软件。如前节所述,由于软件开发与运行的密切相关性,在计算机发展早期通常并不严格区分操作系统Operating System和编程系统Programming System只是后者更强调其对开发的支持,包括编译能力、开发辅助工具和可重用例程/库等。其后,编译系统逐渐被从操作系统中独立出来,并随着计算机体系结构和程序设计语言的变迁而不断扩展其内涵和外延(图\ref{fig:3-2})。
编译系统是将源语言(例如高级程序设计语言)编写的代码翻译为等价的、高效的、能被计算机或虚拟机执行的目标代码(例如机器语言)的系统软件。编译系统的诞生早于操作系统,但如前节所述由于软件开发与运行的密切相关性在计算机发展早期通常并不严格区分操作系统Operating System和编程系统Programming System仅仅是后者更强调其对开发的支持,内置了编译能力、开发辅助工具和可重用例程/库等。随着程序设计语言的变迁、特别是高级语言的出现,编译系统逐渐成为系统软件的一个主要分支,其内涵和外延随语言和计算机体系结构的发展而不断扩展(图\ref{fig:3-2})。
\begin{figure}[htbp]
\centering
@ -103,7 +106,7 @@
\subsection{程序设计语言驱动的编译系统发展60年代-90年代}
在高级程序设计语言出现以后,程序设计方法学和程序设计语言飞速发展,诸如结构化程序设计、面向对象程序设计、函数式程序设计、逻辑程序设计等方法和语言百花齐放,直接推动了编译技术和编译系统的发展。
20世纪50年代末COBOLCommon Business-Oriented Language语言诞生[19]。与Fortran主要面向科学计算不同COBOL是用于商务数据处理的语言也是第一个跨平台的高级程序设计语言。1960年COBAL编译器编译的COBOL程序成功在UNIVAC II和RCA 501机上运行。70年代初美国Bell实验室以开发了B语言和B语言编译器并用B语言编写了第一个UNIX操作系统内核。在B语言基础上Bell实验室经过进一步改进完善后发布了C语言及其编译器。
20世纪50年代末COBOLCommon Business-Oriented Language语言诞生[19]。与Fortran主要面向科学计算不同COBOL是用于商务数据处理的语言也是第一个跨平台的高级程序设计语言。1960年由不同编译器编译的同一COBOL程序成功在UNIVAC II和RCA 501机上运行,表明了。70年代初美国Bell实验室以开发了B语言和B语言编译器并用B语言编写了第一个UNIX操作系统内核。在B语言基础上Bell实验室经过进一步改进完善后发布了C语言及其编译器。
相对于Fortran和 C等命令式高级语言面向对象语言也在这一时期得到发展。20世纪 60年代的SIMULA67语言[20]引入了类和对象的概念被认为是世界上第一个面向对象语言。70年代出现的Smalltalk语言支持类的动态创建和修改。受到C和SIMULA67语言的影响Bell实验室在八十年代开发了C++随后开发了支持C++的Cfront编译器。20世纪90年代随着C++等语言的流行面向对象语言成为主流的编程语言重要标志是GCC编译器GNU Compiler Collection走向成熟以及Java面向对象语言和编译器的发布。这一时期互联网的发展也促进了编程语言及其编译/解释执行系统的发展例如出现了互联网开发、在运行时检查类型甚至改变程序结构的动态语言如PHP、Ruby等
@ -114,7 +117,7 @@
与多核处理器通常仅集成几个处理单元不同众核处理器在同一处理器内部集成了大量同构处理单元。例如GPUGraphics Processing Unit在一个芯片上集成数百甚至数千个“小而简单”的核心通过使用大量线程并发提高性能特别适合用于加速大规模并行应用。近年来众核处理器在高性能计算、人工智能等领域发展迅速其编译优化技术也随着体系结构的不断升级而进步包括针对GPU不同存储层次的优化、程序并行度的自动调优、通信优化、针对宽向量的自动向量化等。
多核和众核处理器都在不断向前发展聚合两类处理器的异构计算平台获得了工业界和学术界的重视。2007年首个针对异构计算平台的通用编程模型OpenCL出现各硬件厂商纷纷提供了OpenCL编译、运行时和驱动支持使OpenCL代码能够运行在不同类型和不同厂商的硬件平台上。此外OpenMP 4.0标准也引入了异构计算支持。目前,异构计算平台已成功运用到从超级计算机到移动设备的不同层次计算机系统中。为了提高异构计算平台的性能,研究人员在负载均衡、数据通信延迟隐藏、同步等方面展开了研究。
多核和众核处理器都在不断向前发展聚合两类处理器的异构计算平台获得了工业界和学术界的重视。2007年首个针对异构计算平台的通用编程模型OpenCL出现各硬件厂商纷纷提供了OpenCL编译、运行时和驱动支持使OpenCL代码能够运行在不同类型和不同厂商的硬件平台上。此外OpenMP 4.0标准也引入了异构计算支持。目前,异构计算平台已成功运用到从超级计算机到移动设备的不同层次计算机系统中。
\section{中间件}
“中间件Middleware”本义是指位于操作系统之上、应用软件之下的一层中间软件提供操作系统所不具备、但上层应用又迫切需要的系统软件功能。由于在过去很长一段时间内经典操作系统并未充分考虑分布式应用支撑问题因此狭义的、或者说现代意义上的“中间件”往往特指网络计算中间件也即支持分布式应用的部署、运行和管理的软件[23]。今天,随着应用软件和操作系统的发展,中间件一词含义也在不断演化(图\ref{fig:3-3}),并表现出沉淀和融入到操作系统中的趋势。
@ -131,7 +134,7 @@
\begin{figure}[htbp]
\centering
\includegraphics[width=0.80\textwidth]{fig1-3/3-4.png}
\includegraphics[width=0.40\textwidth]{fig1-3/3-4.png}
\caption{NATO软件工程报告中的倒金字塔软件结构[24]
\label{fig:3-4}}
\end{figure}
@ -160,7 +163,7 @@
除了感知物理世界外,随着信息物理融合系统的成熟,近年来中间件领域开始关注如何联接能够直接“作用”于物理世界的计算设备,其突出代表是无人系统/机器人中间件。针对无人系统计算环境高度异构、资源受限、常态失效、实时性要求高等特点从2000年左右的Player等中间件开始包括Miro、CLARAty、OpenRTM-aist、Pyra、Orca、MARIE等在内的一系列实践推动了无人系统中间件技术的发展并直接为今天广泛使用的机器人“元级操作系统”ROSRobot Operating System奠定了理论和技术基础[34]。
\section{数据库管理系统}
数据库是长期存储在计算机内有组织、可共享的大量数据的集合,数据库管理系统旨在统一管理和维护数据库中的数据,是存储、组织、联接、变换和加载数据的软件。从本质上而言,数据库管理系统把逻辑数据转换成为计算机中具体的物理数据,从而使得用户可以访问、检索和维护数据,而不必顾及这些数据在计算机中的布局和物理位置。
数据库是长期存储在计算机内有组织、可共享的大量数据的集合,数据库管理系统旨在统一管理和维护数据库中的数据,是组织、存储、存取、控制和维护数据的软件。从本质上而言,数据库管理系统把逻辑数据转换成为计算机中具体的物理数据,从而使得用户可以访问、检索和维护数据,而不必顾及这些数据在计算机中的布局和物理位置。
数据库管理系统的发展历史可以按照其支撑的应用特征来划分(图\ref{fig:3-5}[35]。第一代系统主要是支持数据的存储与访问数据的组织以层次和网状模型为代表。第二代系统主要围绕联机事务处理Online Transaction ProcessingOLTP应用展开在关系模型和存储技术的基础上重点发展了事务处理、查询优化等能力。第三代系统主要围绕联机分析处理Online Analysis ProcessingOLAP应用展开重点在于提出高效支持联机分析处理复杂查询的新型数据组织技术。第四代系统主要围绕大数据应用展开重点在分布式可扩展、异地多备份高可用架构、多数据模型支持、以及多应用负载类型支持等特性。
@ -177,13 +180,11 @@
在上述背景下为了提供系统化、高效的数据组织与访问功能专门的数据库管理系统开始出现。60年代初通用电气在其生产信息和控制系统MIACS中设计了“集成数据存储”Integrated Data Store被认为是首个支持直接访问的数据库管理系统并直接为CODASYL组织后续制定的网状数据库标准奠定了基础。1968年IBM发布了运行于System/360主机的层次数据库管理系统IMSInformation Management System。上述两个具有里程碑意义的产品分别代表了数据库管理系统的两种早期数据模型也即数据是按照网状的“图”还是层次化的“树”来组织。其中层次模型由于其每一个节点最多只有一个父节点因此可以采用有效的手段例如按照树遍历的顺序来存储数据而网状模型可以将图分解为一组“基本层次联系”的集合其本质上可以用“树”结构来表达和存储数据。
\subsection{关系数据库的高速发展70年代-90年代}
20世纪70年代是关系数据库形成并实现产品化的年代主要的代表人物就是IBM的埃德加·科德Edgar F. Codd。1970年科德发表题为“大型共享数据库的关系模型”的论文[36]文中提出了数据库的关系模型。由于关系模型简单明了、具有坚实的数学理论基础操作语言是描述性的无需像层次网状模型那样需要描述存取路径既先访问哪个数据再访问哪个数据这样的细节给提高信息系统开发的生产率提供了极大的空间所以一经提出就受到了学术界和产业界的高度重视和广泛响应。尽管一开始产业界还充斥了对关系数据库系统性能的怀疑但科德所开发的System R系统证明其性能可以有保障。这一结论极大地推动了关系数据库技术的发展关系数据库产品开始涌现例如IBM公司自己在System R系统基础上推出的DB2产品和ORACLE公司的同名数据库产品。
220世纪70年代是关系数据库形成并实现产品化的年代主要的代表人物就是IBM的埃德加·科德Edgar F. Codd。1970年科德发表题为“大型共享数据库的关系模型”的论文[36]文中提出了数据库的关系模型。由于关系模型简单明了、具有坚实的数学理论基础操作语言是描述性的无需像层次网状模型那样需要描述存取路径既先访问哪个数据再访问哪个数据这样的细节给提高信息系统开发的生产率提供了极大的空间所以一经提出就受到了学术界和产业界的高度重视和广泛响应。尽管一开始产业界还充斥了对关系数据库系统性能的怀疑但科德所开发的System R系统证明其性能可以有保障。这一结论极大地推动了关系数据库技术的发展关系数据库产品开始涌现包括IBM公司在System R系统基础上推出的DB2产品、ORACLE公司的同名数据库产品以及80年代初出现的、针对个人电脑设计的dBase等。由于科德杰出的贡献1981年的图灵奖授予了这位“关系数据库之父”
20世纪80年代关系数据库迅速取代层次和网状数据库占领市场。数据库研究工作重心也围绕关系数据库展开。在这一阶段描述型的关系库数据语言SQL语言、完善数据正确性确保的机制、逐渐发展的开发工具和软件生态推动了上述挑战的解决在实践中显著提高了生产率。由于科德杰出的贡献1981年的图灵奖授予了这位“关系数据库之父”。
具体而言这一阶段的研究和实践核心围绕查询优化和事务管理等展开1查询优化。关系数据库语言是基于集合的描述性语言如70年代初出现的SQL语言其查询的结果也是一个集合。如何将一个SQL语句转换为可以执行的程序类似程序自动生成器而且要在所有可能的执行计划程序中选择出一个效率足够好的加以执行是这一阶段工作重点之一。2事务管理。事务管理提供对并发事务的调度控制和故障恢复确保数据库系统的正确运行。詹姆斯·尼古拉·格雷James Gray在相关研究方面发挥了十分关键的作用为数据库管理系统成熟并顺利进入市场做出了重要的贡献。他的成就汇聚成一部厚厚的专著《Transaction Processing: Concepts and Techniques》[37]他也众望所归获得了1998年度的图灵奖。
20世纪80年代关系数据库迅速取代层次和网状数据库占领市场描述型的关系库数据语言SQL语言、完善数据正确性确保的机制、逐渐发展的开发工具和软件生态在实践中显著提高了生产率。数据库研究工作重心也围绕关系数据库展开包括查询优化和事务管理等方面1查询优化。关系数据库语言是基于集合的描述性语言如70年代初出现的SQL语言其查询的结果也是一个集合。如何将一个SQL语句转换为可以执行的程序类似程序自动生成器而且要在所有可能的执行计划程序中选择出一个效率足够好的加以执行是这一阶段工作重点之一。2事务管理。事务管理提供对并发事务的调度控制和故障恢复确保数据库系统的正确运行。詹姆斯·尼古拉·格雷James Gray在相关研究方面发挥了十分关键的作用为数据库管理系统成熟并顺利进入市场做出了重要的贡献。他的成就汇聚成一部厚厚的专著《Transaction Processing: Concepts and Techniques》[37]他个人也众望所归获得了1998年度的图灵奖。
在这一时代对于数据库管理系统做出重要贡献的还有迈克尔·斯通布雷克Michael Stonebraker。他在加州大学伯克利分校计算机科学系任教的29 年中领导开发了关系数据库系统Ingres、对象关系数据库系统Postgres、联邦数据库系统Mariposa等同时创立了多家数据库公司。他在“One size does not fit all”的思想指导下开发了一系列的“专用”关系数据库产品例如流数据管理系统、内存数据库管理系统、列存储关系数据库系统、科学数据库管理系统等。因“对现代数据库系统底层的概念与实践所做出的基础性贡献”他于2015年获得了图灵奖。
在这一时代对于数据库管理系统做出重要贡献的还有迈克尔·斯通布雷克Michael Stonebraker。他在加州大学伯克利分校计算机科学系任教的29 年中领导开发了关系数据库系统Ingres、对象关系数据库系统Postgres、联邦数据库系统Mariposa等同时创立了多家数据库公司。他在“One size does not fit all”的思想指导下开发了一系列的“专用”关系数据库产品例如流数据管理系统、内存数据库管理系统、列存储关系数据库系统、科学数据库管理系统等。因“对现代数据库系统底层的概念与实践所做出的基础性贡献”他于2015年获得了图灵奖。
\subsection{数据仓库系统的出现和发展90年代-}
数据仓库可看作是关系数据库的一个自然延伸。随着数据库技术的普及应用,越来越多的数据被存储在数据库中,除了支持业务处理以外,如何让这些数据发挥更大的作用,就是一个亟待解决的问题。特别是对于联机分析处理类应用,如何让复杂分析能高效地执行,需要有特殊的数据组织模式,推动了数据仓库系统的出现。
@ -195,13 +196,13 @@
随着实践的深入人们发现NoSQL并非解决大数据时代数据管理问题的“银弹”。一方面无论从应用程序继承的角度还是提高生产率的角度SQL语言都是不可或缺的工具因此继承和汲取SQL的优点如在上层提供SQL查询引擎逐渐成为NoSQL数据库的共识NoSQL一词的含义也从“非SQL”被修正为“不仅仅是SQL”Not Only SQL。另一方面许多联机事务处理业务在应对海量数据同时仍需要采用关系模型并保证原子性、一致性、隔离性、持久性等特性。因此能够提供与NoSQL数据库类似的扩展性能、但仍具备关系数据库能力的NewSQL数据库近年来得到了快速发展其典型代表包括Google全球级分布数据库Spanner和开源领域的CockroachDB、TiDB等。
\section{总结与展望}
\section{总结}
系统软件将计算系统的概念从硬件扩展到了软件层面上,它为上层应用提供了一个可以使用各类资源能力、但又无需关注底层细节的软件平台。历经六十余年的发展,系统软件已经形成操作系统、编译系统、中间件和数据库管理系统等典型形态,已经成为了计算机软硬件生态链的核心,对信息产业乃至人类社会产生了较大影响,在促进经济发展和文明进步中发挥了重要作用。在这一过程中,系统软件表现出了如下一些发展规律:
\begin{itemize}
\item 场景驱动发展。本质而言系统软件负责向应用提供“抽象”或者说虚拟机并将这一“抽象”绑定硬件祼机。因此应用场景的变迁持续推动着系统软件的发展典型案例是操作系统的发展所呈现的“20年周期”在贝尔定律支持下计算设备约每10年一次换代设备和用户增加10倍成为新的蓝海、催生新型应用间次推动操作系统换代并形成新的生态使得操作系统每隔20年左右迎来一次跨越式发展的机遇期。
\item 技术螺旋上升。与应用软件的快速更新不同系统软件技术具有相对稳定性并且每一次跨越式发展都是在继承的基础上提升新场景下的能力。例如虚拟化技术早在60年代IBM实验性操作系统CP-40和其后商用化的CP-67、VM/370中得到完整实现而云计算时代虚拟化技术“复兴”过程中的挑战则主要来自于数据中心环境资源集约化的需求
\item 分支交叉融合。系统软件并非是计算机与生俱来的,其发展经历了从无到有、进而形成多个分支的过程。“分久必合”,近年来分支之间表现出相互融合趋势,系统软件整体在向平台化和体系化拓展。例如,操作系统的概念正在进一步泛化,中间件这一分支目前表现出向操作系统融合的趋势,而在许多语境下云计算操作系统已经涵盖了系统软件四个主流分支
\item 硬件技术和应用场景变迁是发展的核心动力。系统软件具有“承上启下”的特点,无论是形态还是机理的发展都受到硬件和应用两方面的驱动。例如,在贝尔定律支持下计算设备约每10年一次换代设备和用户增加10倍成为新的蓝海、催生新型应用间次推动操作系统换代并形成新的生态使得操作系统每隔20年左右迎来一次跨越式发展的机遇期(参见图\ref{fig:3-1}。另一个典型案例是编译系统近年来高性能计算、智能计算方面的应用需求以及GPU等新型硬件的出现成为了编译系统近年来发展的主要动力
\item 构建“抽象”和实现平台化是重要主题。本质而言,系统软件负责向应用提供运行支撑、网络交互、数据管理等不同维度上的“抽象”(或者说虚拟机),并将这一“抽象”以尽可能高效方式绑定到硬件祼机,充分发挥硬件潜力。例如,过去数十年中,操作系统形成了一系列诸如文件、进程/线程、内存页、Socket等的概念并由这些概念实体共同组成了应用可见的“抽象”或者说虚拟机。同时沉淀共性、进而实现平台化也是系统软件发展的重要主题一方面可以避免应用去重新“造每一个轮子”另一方面也为软件生态奠定基础
\item 技术螺旋上升与交叉融合是发展的主要特征。与应用软件的快速更新不同系统软件具有相对稳定性很多核心技术表现出了螺旋上升的接入点。例如虚拟化技术早在60年代IBM实验性操作系统CP-40和其后商用化的CP-67、VM/370中得到完整实现而云计算时代虚拟化技术“复兴”过程中的挑战则主要来自于数据中心环境资源集约化的需求。另一方面系统软件发展经历了从无到有、进而形成多个分支的过程。“分久必合”,近年来分支之间表现出相互融合趋势,中间件与操作系统就是一个典型案例参见§3.4节)
\end{itemize}
今天,“软件定义一切”、“软件成为社会基础设施”正在成为软件学科发展的主流方向,这一趋势推动着系统软件的进一步发展,通过支撑软件系统与社会/物理系统协同演化、联接人机物多个维度、成为泛在基础设施等形式获得新的活力。

View File

@ -1,9 +1,10 @@
操作系统负责管理软硬件资源、操纵程序运行,为应用软件提供公共支撑,是“软件作为基础设施”的集中体现。过去,操作系统是信息空间的基础设施,起到以平台化方式向下管理各类资源、向上支撑应用运行的作用;未来,在信息物理持续融合趋势的推动下,操作系统管理资源将向各类物理资源扩展,甚至向其他具有“数字孪生”特性的经济、社会和生产生活资源扩展。这一趋势是“软件定义”思想发展的必然结果:随着计算系统正在突破单机、数据中心等封闭环境的限制,操作系统的资源虚拟化、功能可编程能力进一步拓展,从控制管理单个计算机系统资源进一步延伸为连接协调多个结点组成的复杂计算系统,为信息空间、物理空间乃至整个社会提供“软件定义”手段,推动着诸如网构软件操作系统、智能家居操作系统、智慧城市操作系统等“普适操作系统”Ubiquitous Operating System成为现实$^{[1]}$
操作系统负责管理软硬件资源、操纵程序运行,为应用软件提供公共支撑,是“软件作为基础设施”的集中体现。过去,操作系统是信息空间的基础设施,起到以平台化方式向下管理各类资源、向上支撑应用运行的作用;未来,在信息物理持续融合趋势的推动下,操作系统管理资源将向各类物理资源扩展,甚至向其他具有“数字孪生”特性的经济、社会和生产生活资源扩展。这一趋势是“软件定义”思想发展的必然结果:随着计算系统正在突破单机、数据中心等封闭环境的限制,操作系统的资源虚拟化、功能可编程能力进一步拓展,从控制管理单个计算机系统资源进一步延伸为连接协调多个结点组成的复杂计算系统,为信息空间、物理空间乃至整个社会提供“软件定义”手段,推动着诸如网构软件操作系统、智能家居操作系统、智慧城市操作系统等“泛在操作系统”Ubiquitous Operating System成为现实$^{[1]}$
与此同时操作系统的外延、或者说“操作系统应该是什么形态”这一问题也在随着技术和应用的发展而不断扩展演化。例如在人机物融合互联这一大背景下中间件正在表现出加速融合到操作系统中的趋势早在上个世纪的90年代初美国华盛顿大学的MOSESMeta Operating System and Entity Shell项目即使用了“元级操作系统”的概念来描述分布环境下“位于本地操作系统之上、应用之下的一层软件”$^{[2]}$早期的普适计算中间件Gaia $^{[3]}$等已在文献中混用“元级操作系统”和“中间件”概念而今天广泛应用的ROSRobot Operating System$^{[4]}$更是继承了网络中间件的核心思想。换言之,操作系统正在以海纳百川的方式沉淀各类具有软件定义特征的基础设施,这也是本章标题“操作系统与运行平台”的由来。
基于上述内涵和外延两个方面的观察,本章将从平台架构、方法机制、安全隐私、生态链构建等方面列出操作系统与运行平台的重大挑战问题,并阐述本领域的研究趋势和内容。
基于上述内涵和外延两个方面的观察,本章将从平台架构、方法机制、安全隐私等方面列出操作系统与运行平台的重大挑战问题,并阐述本领域的研究趋势和内容。
\section{重大挑战问题}
互联网革命正在进入下半场,“万物互联”时代正在到来,人机物融合的泛在应用场景推动着操作系统和运行平台的新一轮变革,带来体系结构、资源管理、应用支撑、首先,在所管控资源高度异构、涵盖人-机-物三元空间的条件下未来的操作系统和运行平台需要什么样的架构§5.1.1其次从向下管理泛在资源的角度需要以及什么样的资源虚拟化和调度机制§5.1.2再次从向上支撑应用运行的角度应当如何支撑上层应用的持续适应和演化§5.1.3最后在人与物加入到操作系统管理对象中之后基础设施层的安全与隐私保护风险如何应对§5.1.4)。
\subsection{支持软件定义的新型运行平台架构}
@ -23,75 +24,93 @@
\caption{操作系统与软件定义网络架构的类比}
\end{figure}
将操作系统“功能可编程”、“资源虚拟化”的思想拓展到存储、安全、数据中心等具体领域,我们就得到了软件定义存储、软件定义安全、软件定义的数据中心等概念。进一步,随着操作系统由计算机软硬件之间的桥梁、人与计算机之间的桥梁拓展到云边端、人机物之间的桥梁,其定位将由单个计算机“管家”演化为支撑“软件定义一切”的运行平台。传统操作系统架构面向的是信息空间内孤立计算结点,这一沿用数十年的架构将面临如下两个方面的挑战
将操作系统“功能可编程”、“资源虚拟化”的思想拓展到存储、安全、数据中心等具体领域,我们就得到了软件定义存储、软件定义安全、软件定义的数据中心等概念。进一步,随着操作系统由计算机软硬件之间的桥梁、人与计算机之间的桥梁拓展到云边端、人机物之间的桥梁,其定位将由单个计算机“管家”演化为支撑“软件定义一切”的运行平台。传统操作系统架构面向的是信息空间内孤立计算结点,这一沿用数十年的架构将面临如下两个方面的挑战
\begin{itemize}
\item 从“精确控制”到“连接协调”的挑战。未来的人机物融合系统将是大规模、网络化的计算系统虽然每个节点上仍将运行传统的节点操作系统在节点内部通过对资源实施严格精确控制来达到资源虚拟化、功能可编程的目的但这种精确控制机制很难直接应用到网络层面。事实上这种简单放大的思路在30年前的Amobea等分布式操作系统实践中就已经证明很难奏效参见本书历史篇§3.4“中间件”一节)。根本原因在于网络化系统具有开放和复杂系统的特征,其所涉及的实体往往跨越多个管理域,系统边界也随时间演化而不断发生变化,很难构建静态不变的控制中心,或是明确稳定的自顶向下层次化结构。在这种场景下,更为妥当的方式将是 “连接协调”,即通过按需聚合和动态协同来打破不同节点之间的壁垒,统一管理并优化利用计算、数据甚至物理世界各种资源。从“精确控制”到“连接协调”的方式的这一转变,将从根本上动摇现有操作系统的架构,并催生新一代、运行于节点操作系统之上的网络操作系统。
\item 从“精确控制”到“连接协调”的挑战。未来的人机物融合系统将是大规模、网络化的计算系统虽然每个节点上仍将运行传统的节点操作系统在节点内部通过对资源实施严格精确控制来达到资源虚拟化、功能可编程的目的但这种精确控制机制很难直接应用到网络层面。事实上这种简单放大的思路在30年前的Amobea等分布式操作系统实践中就已经证明很难奏效参见本书第一部分§3.4“中间件”一节)。根本原因在于网络化系统具有开放和复杂系统的特征,其所涉及的实体往往跨越多个管理域,系统边界也随时间演化而不断发生变化,很难构建静态不变的控制中心,或是明确稳定的自顶向下层次化结构。在这种场景下,更为妥当的方式将是 “连接协调”,即通过按需聚合和动态协同来打破不同节点之间的壁垒,统一管理并优化利用计算、数据甚至物理世界各种资源。从“精确控制”到“连接协调”的方式的这一转变,将从根本上动摇现有操作系统的架构,并催生新一代、运行于节点操作系统之上的网络操作系统。
\item 计算、通信、控制三元融合场景的挑战。今天广泛使用的Windows、Linux等操作系统在架构上深受首个现代意义上操作系统Unix的影响。它们运行于单一计算结点范围内内部大致可划分为资源管理、系统调用、人机接口等层次。这种架构针对信息空间内部的孤立计算结点设计很难支撑泛在化、智能化、网络化的新型应用场景。具体而言在计算维度上单一的本地计算将向云边端一体化计算、人机物协作计算、智能和机器学习计算等新型场景变迁在通信维度上5G等新型网络的出现使得网络时延和吞吐量得到极大改善可望触发移动和嵌入式操作系统的新一轮革命在控制维度上物联网、机器人等与物理世界紧密融合的计算设备涌现使得“功能可编程”将突破信息空间范畴需要在操作系统架构设计层面上考虑物理空间约束和对物理空间的影响。
\end{itemize}
\subsection{泛在资源的高效虚拟化和灵活调度}
文献$^{[1]}$给出了“普适操作系统”的概念指出未来的操作系统不仅仅是IT操作系统也将成为物理世界和虚拟世界的操作系统在今天已经初露端倪的机器人操作系统、车辆操作系统、物联网操作系统等基础上校园操作系统、城市操作系统、家庭操作系统等可望在将来成为现实。在这一背景下操作系统的核心功能――资源虚拟化和调度的实现机制面临一系列挑战\ref{fig2})。
首先高性能处理器、新型存储器件、高速网络互联设备等快速发展使得经典的计算资源虚拟化和调度机制面临挑战。例如多核和多芯片计算机系统中非一致性内存访问架构使得传统基于页的虚存系统面临挑战张量处理器等人工智能新型加速器的出现亟待相应细粒度的虚拟化技术支持非易失性内存的应用使得内存中的某些数据不再需要存储到硬盘对传统类文件系统架构带来挑战大规模分布式异构计算以及移动异构片上系统对Linux等多线程共享存储的单内核结构提出挑战100G及以上以太网链路在大规模数据中心的普及网络带宽增长速度超越CPU处理能力增长速度操作系统网络协议栈面临挑战等等。
\begin{figure}[htbp]
\centering
\includegraphics[width=\linewidth]{fig2-5/mmm.png}
\includegraphics[width=0.7\linewidth]{fig2-5/mmm.png}
\caption{人机物融合新型资源的虚拟化和调度所面临挑战}
\label{fig2}
\end{figure}
其次,如何为人机物融合计算中的各类新型异构资源建立抽象,是未来操作系统需要解决的核心问题。本质上,操作系统和运行平台负责向应用提供“抽象”,并将这些“抽象”绑定到硬件祼机。数十年来,这一领域已经积累了诸如进程、线程、文件、内存页等一系列重要抽象机制,为现代操作系统奠定了基石。但是,未来操作系统所管理的资源将跨越人、机、物三元空间,涵盖物理资源、计算资源、数据资源等多种类型,现有抽象远远不能满足需求。因此,需要探索符合新型资源特点、切合其特性的抽象机制,并突破在单一计算结点、有一定边界的分布式系统、跨域开放式系统等不同尺度上维护这些抽象的方法机理。
首先,如何为人机物融合计算中的各类新型异构资源建立抽象,是未来操作系统需要解决的核心问题。本质上,操作系统和运行平台负责向应用提供“抽象”,并将这些“抽象”绑定到硬件祼机。数十年来,这一领域已经积累了诸如进程、线程、文件、内存页等一系列重要抽象机制,为现代操作系统奠定了基石。但是,未来操作系统所管理的资源将跨越人、机、物三元空间,涵盖物理资源、计算资源、数据资源等多种类型,现有抽象远远不能满足需求。因此,需要探索符合新型资源特点、切合其特性的抽象机制,并突破在单一计算结点、有一定边界的分布式系统、跨域开放式系统等不同尺度上维护这些抽象的方法机理。
次,在操作系统支持下,物理资源将呈现物理与数字二像性,如何将信息空间内的抽象与物理空间内的实体绑定,并持续保持和校正二者之间的一致性,是操作系统泛在化以后产生的新问题。一方面,需要利用预建立物理模型、传感器实时数据、较大时空尺度上的运行历史等数据,集成多物理量、多尺度、多概率的仿真过程,实现物理资源到信息空间中实体的正向映射,以及“因果关联”的虚拟实体到物理资源的映射;另一方面,即使建立了相应的“数字孪生”关系,也要考虑物理域和社会域资源在管理和调度过程中的特有属性,例如动作的非精确性和动态性、固有的噪声等。
次,在操作系统支持下,物理资源将呈现物理与数字二像性,如何将信息空间内的抽象与物理空间内的实体绑定,并持续保持和校正二者之间的一致性,是操作系统泛在化以后产生的新问题。一方面,需要利用预建立物理模型、传感器实时数据、较大时空尺度上的运行历史等数据,集成多物理量、多尺度、多概率的仿真过程,实现物理资源到信息空间中实体的正向映射,以及“因果关联”的虚拟实体到物理资源的映射;另一方面,即使建立了相应的“数字孪生”关系,也要考虑物理域和社会域资源在管理和调度过程中的特有属性,例如动作的非精确性和动态性、固有的噪声等。
第四,如何使打破信息-物理世界间以及不同节点间的壁垒,按需聚合各类资源,是实现泛在资源优化利用的关键。如前节所述,未来的计算系统在微观尺度上仍将运行我们今天所熟悉的节点级操作系统,而在整个系统的宏观尺度上,资源管理模型将从“精确控制”向“连接协调”转变。虽然这一理念在中间件、网构软件等领域已经有了初步实践,但一系列实现机制层面上的开放问题仍有待解决,包括需要何种模型来协调跨域资源及其能力、如何在动态环境下维持相对稳定的“功能可编程”抽象、如何有效管理调度各种冲突及涌现现象等。
再次,如何使打破信息-物理世界间以及不同节点间的壁垒,按需聚合各类资源,是实现泛在资源优化利用的关键。如前节所述,未来的计算系统在微观尺度上仍将运行我们今天所熟悉的节点级操作系统,而在整个系统的宏观尺度上,资源管理模型将从“精确控制”向“连接协调”转变。虽然这一理念在中间件、网构软件等领域已经有了初步实践,但一系列实现机制层面上的开放问题仍有待解决,包括需要何种模型来协调跨域资源及其能力、如何在动态环境下维持相对稳定的“功能可编程”抽象、如何有效管理调度各种冲突及涌现现象等。
最后,需要深入理解未来泛在计算场景下应用模式的共性特征,为上层应用的“软件定义”提供适当的、相对稳定的编程接口。可以预见,未来泛在计算场景至少包括数据规模巨大、强调按需能力获取的“云-边”效用计算,资源需求动态变化、不确定性很强的智能计算,移动性强、承载设备多、续航要求高、迭代快的智慧城市、工业互联网等领域的协作计算,人与物相互驱动、相互协同的人机物统一计算等。这些泛在应用模式很多都处在探索阶段,需要理解和凝练应用模式的共性特征,进而通过编程接口支撑上层应用灵活实施软件定义。
第五,需要深入理解未来泛在计算场景下应用模式的共性特征,为上层应用的“软件定义”提供适当的、相对稳定的编程接口。可以预见,未来泛在计算场景至少包括数据规模巨大、强调按需能力获取的“云-边”效用计算,资源需求动态变化、不确定性很强的智能计算,移动性强、承载设备多、续航要求高、迭代快的智慧城市、工业互联网等领域的协作计算,人与物相互驱动、相互协同的人机物统一计算等。这些泛在应用模式很多都处在探索阶段,需要理解和凝练应用模式的共性特征,进而通过编程接口支撑上层应用灵活实施软件定义。
\subsection{复杂软件系统持续适应演化的共性支撑}
近年来,以人机物融合系统为背景,有研究者提出了信息产业的“昆虫纲悖论”:一方面,未来物联网设备和应用场景将会像昆虫一样繁多,带来空前巨大的市场;另一方面,由于每种场景都存在其个性化需求和特点,针对场景所开发的软件系统将缺乏可拷贝性,导致边际成本显著提高,反过来制约产业的发展。要打破这一悖论,关键在于软件系统不能静态绑定到特定场景,而应当具备灵活适应场景的能力,在其生命周期内能够持续演化来应对环境和用户需求的变化。
软件适应能力将成为未来人机物融合软件系统的基本属性,而操作系统在支撑软件适应演化活动方面具有天然优势:从可计算性的角度而言,操作系统与下层硬件裸机一起组成了能够“操纵”应用软件执行的通用图灵机实现,这一“操纵”能力使得操作系统有可能驱动应用软件的适应和演化;从计算反射$^{[10]}$实现的角度而言,操作系统和运行平台是应用软件执行的“元层容器”,对于上层应用具有计算反射能力,例如获知上层应用和环境状态、维护系统化反映上层应用环境和状态的模型、对上层应用实施调整操作等。因此,操作系统和运行平台是驱动计算节点动态感知、自主学习、在线演化的理想载体,但这一地位也同时对平台设计实现提出了一系列挑战。
\begin{itemize}
\item 操作系统及其上应用的自主适应与学习赋能。从“网络就是计算机”到“场景就是计算机”,其蕴含的理念从计算资源聚合进一步拓展到了多样化人机物融合场景下的资源按需定制。要实现“场景就是计算机”,关键在于操作系统和其上应用需要具备主动适应新场景和场景变化的能力,包括:操作系统本身和其上应用都具有柔性体系结构,节点本身可以动态调整,节点与节点这间连接关系可以按需变化,并且携带有指导这些变化的元层数据;在操作系统和运行平台内部构建“感知-理解-调整”回路,能够捕获和理解环境及运行状态,进而据此进行应用配置生成、主动部署、参数和连接关系在线调整等操作;具有从过去的适应和演化动作及效果中持续学习的能力,从而突破预定义场景和决策规则的约束,使得操作系统及其上应用在适应场景和用户需求变化的维度上能够表现出一定的“智能”。
\item 大规模复杂软件系统的演化规律及其支撑机制。人机物融合场景下许多软件系统已经达到了空前的规模。例如互联网的前身ARPANET仅连接了4个节点而2018年移动社交应用微信的月活跃用户数达到了10.8亿。规模上的量变引起质变,此类系统表现出了“系统之系统”、信息物理融合系统和“社会-技术”系统的特点,具有与单个节点或小规模分布式系统不同的演化规律,包括:复杂软件系统规模巨大,其海量状态数据之间存在着千丝万缕的联系,如何“去粗取精、去伪存真”,提取能够作为适应演化依据的运行态势数据;复杂软件系统中的节点通过“连接”形成了一个复杂网络,如何基于复杂网络中的交互掌握软件架构和运行大势;在由大量自治软件单元所组成的复杂软件系统中,适应性演化动作往往发生在单元、子系统、系统等多个尺度上,如何在群体层面上形成恰当的适应性演化行为,以及不同层次上的适应性演化如何相互影响;等等。
\item “人在回路中”的软件系统演化决策。软件是“由人开发,为人开发”的产品,人在软件生命周期各个阶段所发挥的作用不可替代,人是软件产品需求的提出者,也是需求落地实施的开发者,同时也是软件终端的使用者以及运行时的维护和升级者。因此,未来人机物融合软件系统适应性演化决策应当是软件和人相结合的方式,除了现有的规则、策略、机器学习等自动化方法外,“人在回路中”是其重要的特点,操作系统和运行平台如何通过集成DevOps工具和平台来有效支持人来发挥作用、同时又通过人工智能相关技术减少人主动干预的负担是未来要解决的重要挑战
\item “信息-物理-社会”空间的协同持续演化。复杂软件系统是典型的“社会-技术-物理”系统,软件将与其所在的社会和物理环境紧密融合在一起,相互作用、相互影响。这与传统的、完全在信息空间运行的软件有着质的区别。具体到基础性的、“操纵计算系统执行”的操作系统和运行平台层面,需要有能力支撑上层应用与物理世界和人类社会长期性的共同进化。这将显著扩展现有操作系统的内涵,带来一组极具挑战性的开放问题,例如:物理空间变化的频率远高于信息空间变化的频率,如何高效适应物理空间的变化;利用人工智能算法来进行演化决策,一旦决策错误可能会直接在物理空间造成严重后果,其中的技术、法律甚至伦理问题如何解决;等等。
\item 大规模复杂软件系统的演化规律及其运行支撑。人机物融合场景下许多软件系统已经达到了空前的规模。例如互联网的前身ARPANET仅连接了4个节点而2018年移动社交应用微信的月活跃用户数达到了10.8亿。规模上的量变引起质变,此类系统具有与单个节点或小规模分布式系统不同的演化规律,带来了一系列挑战性问题:软件系统规模巨大,其海量状态数据之间存在着千丝万缕的联系,如何“去粗取精、去伪存真”,提取能够作为适应演化依据的运行态势数据;系统中的节点通过“连接”形成了一个复杂网络,如何基于复杂网络中的交互掌握软件架构和运行大势;在由大量自治软件单元所组成的软件系统中,适应性演化动作往往发生在单元、子系统、系统等多个尺度上,如何在群体层面上形成恰当的适应性演化行为,以及不同层次上的适应性演化如何相互影响;等等。
\item “人在回路中”的软件系统演化决策。软件是“由人开发,为人开发”的产品,人在软件生命周期各个阶段所发挥的作用不可替代,人是软件产品需求的提出者,也是需求落地实施的开发者,同时也是软件终端的使用者以及运行时的维护和升级者。因此,未来人机物融合软件系统适应性演化决策应当是软件和人相结合的方式,除了现有的规则、策略、机器学习等自动化方法外,“人在回路中”是其重要的特点,主要表现为两种形态操作系统和运行平台集成DevOps工具链来有效支持人来发挥作用软件系统从平台层所累积的人的行为数据、特别是群体行为数据中进行主动学习从而不断提升其演化决策能力
\item“信息-物理-社会”空间的协同持续演化。复杂软件系统是典型的“社会-技术-物理”系统,软件将与其所在的社会和物理环境紧密融合在一起,相互作用、相互影响。这与传统的、完全在信息空间运行的软件有着质的区别。具体到基础性的、“操纵计算系统执行”的操作系统和运行平台层面,需要有能力支撑上层应用与物理世界和人类社会长期性的共同进化。这将显著扩展现有操作系统的内涵,带来一组极具挑战性的开放问题,例如:物理空间变化的频率远高于信息空间变化的频率,如何高效地支撑上层软件适应物理空间的变化;利用人工智能算法来进行演化决策,一旦决策错误可能会直接在物理空间造成严重后果,操作系统和运行平台应当提供什么样的监督、审计和补偿机制;等等。
\end{itemize}
\subsection{人机物融合过程中的安全与隐私保护}
数十年来“魔高一尺道高一丈”主流操作系统不断围绕系统用户认证、访问控制、数据安全、漏洞攻击缓解等方面进行安全增强。然而安全与隐私保护是一种伴生技术新的安全问题伴随新计算模式的涌现而不断产生。未来随着5G通讯、移动互联、云计算与物联网的应用普及人机物将广泛互联在网络虚拟世界与现实世界的行为将实现虚实深度融合导致信息系统的安全防御边界愈加模糊面临的安全威胁在种类和数量上都将激增用户隐私保护的难度显著增加。在未来人机物融合的过程中作为信息空间与物理空间乃至整个社会进行统一信息处理的载体操作系统及运行平台在安全和隐私保护方面的需求将面临一系列挑战
首先需要在大规模松耦合交互场景下建立虚实融合的信任关系。在未来人机物深度融合的时代将会有大量物理设备与应用软件接入到运行平台以数字身份作为运行主体在系统中发挥作用。随着越来越多的现实世界行为被迁移到网络虚拟空间进行处理在数字世界中如何对纷繁芜杂的虚拟社会关系进行准确刻画并实施严格管理是构筑未来安全可信数字空间的所必须要面对的挑战。在此基础上要建立数字身份的信任关系还需要在平台层面上对数字实体在虚拟世界的行为进行全面、如实地记录为准确刻画数字世界实体间的信任关系提供有力依据。并且由于现实社会中主体之间关系的大规模、松耦合特性原有的集中式管理方式对人机物融合系统的实体管理将无法适用需要实现管理的弱中心化基于众包、基于区块链等新型信任关系构建方法已在操作系统领域崭露头角。例如IBM的面向区块链的分布式操作系统Hyperledger Fabric可以利用区块链来支撑分布式应用运行并且通过模块化的共识协议来使得系统可以灵活适应不同的应用场景和信任模型。
其次,需要实现人机物融合场景下的严苛安全和隐私保护需求。人机物融合场景下计算节点众多、数据传输分散,诸如边缘计算等以“计算尽可能靠近数据的源头”为基本理念的计算模式将走向前台。而这些新的计算模式由于其服务模式的复杂性、实时性,数据的多源异构性、感知性以及终端的资源受限特性,传统数据安全和隐私保护机制将很难高效应用。同时,由于移动终端的资源一般都比较有限,其所能承载的数据存储计算能力和安全算法执行能力也有一定的局限性。如何将传统的隐私保护方案与边缘计算环境中边缘数据处理特性相结合,从数据隐私、位置隐私、身份隐私等多个方面入手研究相应的保护方案,是未来操作系统安全与隐私保护领域面临的重要挑战。同时,为了支撑广泛、大规模的人机物融合和互联,需要突破现有操作系统安全和隐私保护的被动防御机制、打破“信任篱笆”,强化安全与隐私保护的主动性与支配性,在利益与风险之间权衡,既关注更强、更灵活的隐私保护,又支持网络资源共享和互联互通。
\section{研究内容}
如5.1.1节所述未来操作系统分成两种类型节点操作系统和网络操作系统。前者是今天操作系统的后续者在有明确边界的节点范围内实现资源虚拟化和功能可编程后者运行于节点操作系统之上实现网络环境下人机物异构资源聚合和优化管理支撑各种类型、不同尺度的泛在应用。本节将以这一分类为依据分别阐述节点操作系统§2.1-§2.3和网络操作系统§2.4-§2.6的研究内容并在§2.7、§2.8、§2.9和§2.10中专门阐述物理和社会资源管理、操作系统和应用的适应和演化、操作系统生态链构建相关研究问题。
\subsection{支持泛在应用和新型硬件的节点操作系统}
节点操作系统是未来操作系统生态中的基石。过去60年中大型主机、个人计算机、实时嵌入设备、手持移动设备、可穿戴和物联网设备等不同类型计算节点的出现以及相应应用场景的普及持续推动着节点操作系统技术的发展。针对未来人机物融合环境中网络资源、存储资源、数据资源、计算资源、传感资源等海量异构资源节点操作系统将进一步探索以“软件定义”的方式实现资源的虚拟化和柔性调度的方法机制通过编程接口支撑各类泛在化、网络化和智能化应用。另一方面新型应用对算力和存储性能等多方面的要求导致新型异构硬件的不断出现和演化如图形处理器、张量处理器、非易失性内存、远程直接内存访问等。操作系统自身需要适应这些新型硬件发展进而研究异构计算、内存计算等新型运行平台架构实现技术架构升级和软硬件之间的深度融合优化设计。
如§5.1.1节所述,未来操作系统将具有两种形态:一方面,在新型硬件技术和新型应用场景的共同驱动下,今天我们所熟知的、以单一计算节点为作用空间的操作系统(以下称节点操作系统)将继续快速发展;另一方面,随着人机物融合、特别是“软件定义一切”付诸实践,诸如“泛在操作系统”等新一代操作系统将出现,它们运行于经典操作系统之上,通过“连接协调”实现网络环境下人机物异构资源聚合和优化管理,支撑各种类型、不同尺度的泛在应用。
此外如何依托云计算等后台支持构建跨终端、体系化的操作系统平台使得用户在不同平台上获得一致化的用户体验和设备自由切换能力也是泛在计算的重要使能机制。典型案例是谷歌继移动操作系统Android和轻量级桌面系统ChromeOS之后正在研制的跨平台Fuchsia操作系统其目标是能够覆盖嵌入式、终端、平板和桌面等所有平台。
\subsection{面向特定应用领域的节点操作系统优化技术}
特定领域的节点操作系统实现技术将进一步突破。一方面,针对复杂环境对智能终端的高可靠、低功耗、强交互、智能化和高安全等方面的迫切需求,突破高可靠终端操作系统体系结构、多场景自适应的电源管理优化技术、多种生物特征认证增强技术、资源受限环境下的深度学习适配优化技术,构建具备高可靠、低功耗、强交互、智能化和高安全能力的新一代智能终端操作系统。另一方面,针对嵌入式计算中安全关键、任务关键、非关键等任务混合运行及其安全隔离问题,研究混合任务确定性调度、混合系统实时响应、混合任务间高效通信机制等技术,形成具有确定性保障能力的嵌入式混合关键任务操作系统保障机制,满足嵌入式计算在复杂环境中对系统实时性、安全性、可靠性的严酷要求。
\subsection{软硬件结合的节点操作系统安全防护技术}
如何结合处理器和硬件平台的特点设计新型安全高效的操作系统结构是节点操作系统技术另一主要研究内容。当前基于CPU的可信计算空间隔离和基于TPM芯片的可信计算技术为可信软件执行提供了硬件级的执行验证这些技术都从操作系统底层提供了有力的可信执行支持未来操作系统安全研究将利用这些先进技术来降低漏洞给应用带来的安全风险发展软硬协同的操作系统安全攻防对抗模式变被动响应为主动防护夯实信息系统的安全基础。具体而言需要突破软硬件高效协同的安全体系结构设计、安全防护模型和方法、跨域交互机理及优化方法和基于模糊测试的内核安全性测试等关键技术结合硬件平台提供的多层次特权防护、资源分区隔离等安全能力解决软硬协同的高安全操作系统设计中的核心问题。
\subsection{面向新型应用和部署模式的资源虚拟化技术}
随着云原生应用架构的不断发展和应用以“函数即服务”FaaS为代表的无服务器计算Serverless等计算模式和边缘计算等应用模式给传统操作系统和虚拟化架构带来了挑战。首先虚拟化技术需要能够在支持多租户隔离的前提下实现高密度的资源虚拟化。以在边缘计算场景为例与集中式云数据中心不同可能需要在边缘的十几个服务器上分别支持数千种不同的服务当前已有的基于容器的轻量级虚拟化技术尚不能完全满足。其次在无服务器计算和边缘计算等场景中应用对资源的需求是高度动态变化的这给虚拟化的性能提出了苛刻要求需要探索新的轻量级虚拟化架构和优化机制。再次部分云计算应用开始出现向微服务应用发展的趋势。这意味着软件架构进一步地解耦单个镜像上运行的业务更加专一。因此当前提出了 Unikernel等机制来大幅度精简冗余模块来提高虚拟机的启动速度但虚拟化场景下的适用性和成熟度还需要进一步提升。最后计算资源之外的其它资源如GPU、存储、网络等专用虚拟化技术需要进一步探索。
\subsection{网络环境下跨结点的资源高效按需聚合技术}
“计算的泛在化”意味着操作系统和运行平台的作用范围突破了传统单一计算结点范畴,需要在广域环境和广义的计算空间内调度各类资源,为上层软件提供相对稳定的抽象,这是未来操作系统和运行平台所面临的重大挑战,而资源聚合及统一管理优化是网络操作系统实现这一目标的手段。在计算系统规模持续增长的情况下,需要突破海量虚拟机资源的高效管理、虚拟机间通信优化、自适应的虚拟机在线迁移及动态部署、共生虚拟机间共享内存的弹性管理及优化、虚拟机访存效率优化等技术,实现跨结点的高效分布式资源调度。另一方面,网络操作系统中往往没有明确、固化的控制中心或层次结构,跨结点的“资源虚拟化”和“能力可编程”主要依靠“连接协调”、通过自底向上的方式来实现。如何借鉴社会系统、经济系统、生物系统等复杂系统机理,实现上述目标,也是此类操作系统面临的挑战。
本节将围绕未来操作系统的上述两种形态阐述操作系统和运行平台的研究趋势与内容。其中§5.2.1-§5.2.3节聚焦节点操作系统§5.2.4-§5.2.7节聚焦新一代操作系统§5.2.8和§5.2.9则分别重点阐述与软件适应和演化、操作系统生态链构建相关的问题(图\ref{fig3})。
在跨结点的资源按需聚合方面,未来的一个重要应用模式是“云-边-端”协同模式。因此,需要面向现代网络化信息支撑体系的发展趋势,探索以资源虚拟化、服务云化、前后融合为基本特征的“云-边-端”协同操作系统柔性结构设计与优化技术。研究“云-边-端”高效资源协同调度框架、基于云边端协同和多目标优化的任务调度技术等,解决复杂环境给软硬件资源管理带来的挑战。
\subsection{虚拟化和多租户条件下的主动防御技术}
其次需要抵御虚拟化和多租户等新型运行支撑技术带来的安全风险。未来更多的服务被整合在单一运行平台上这些服务中可能包括了来自不同租户的不同安全等级的信息必须根据用户需求对应用系统的硬件、软件、数据、网络、存储等不同层面资源实现安全隔离。同时为了提高资源利用效率运行平台根据资源使用情况进行动态调度这种动态变化的环境将显著增大了安全隔离的难度。目前主要通过底层的虚拟机监控器Hypervisor来负责实现虚拟机的隔离为用户提供自底向上的虚拟化软硬件运行环境具备较强的隔离性。而为了提高服务运行性能以Docker为代表的轻量级虚拟化容器技术也被广泛应用相对于虚拟机的强隔离性容器技术则是以弱隔离性换取性能的提高。在应用虚拟化技术的过程中隔离性与性能之间的取舍、动态变化下虚拟计算资源的安全复用、Hypervisor层的虚拟机监管、虚拟机逃逸防护等都成为必须要面对的挑战。同时虚拟化技术还需要对软件定义网络在数据中心内部的网络安全管理提供支持通过虚拟网关等技术对虚拟化数据流进行安全监控这些虚拟设备能否安全使用都将对系统安全性产生深刻的影响。
\subsection{物理和社会空间资源的抽象和管控技术}
操作系统的“资源虚拟化”能力来自于其对资源的抽象、封装和调度的能力。传统操作系统针对的是信息空间内部的资源 ,而如何表达和管理各类高度异构、动态变化的物理和社会空间资源,是未来泛在化操作系统需要应对的问题。在此基础上,在认知、物理和信息空间三者之间,如何刻画、检验、保持、校正多模型结构之间定性与定量一致性,进而实现具有“数字孪生”的物理和社会空间资源的调度和管理,是未来操作系统重要研究内容之一。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.9\linewidth]{fig2-5/cnt.png}
\caption{操作系统和运行平台的研究内容}
\label{fig3}
\end{figure}
此外,未来操作系统的编程接口不仅涉及到计算资源的“软件定义”,可能包括各种可传感物体对象、智能无人系统等各类物理资源,甚至向其他具有“数字孪生”特性的经济、社会和生产生活资源,其接口形式、接口实现机理等都是开放的问题。
\subsection{人机物融合的操作系统架构演进技术}
面向未来“人-机-物”融合环境中网络资源、存储资源、数据资源、计算资源、传感资源等海量异构资源,以“软件定义”的方式实现资源的虚拟化和柔性调度,通过编程接口支撑中心式的云计算和分布式的分散计算模式以及各类智能应用。适应人工智能芯片、非易失性存储等硬件发展,研究异构计算、内存计算等新型系统软件架构,实现技术架构升级和软硬件之间的深度融合优化设计。
\subsection{运行平台支持的软件在线适应与演化技术}
操作系统和运行平台是能够支撑上层应用适应和演化的天然基础设施但由于在线演化的需求是在“软件作为基础设施”过程中逐渐显现的其实现机理也是目前操作系统和运行平台领域研究相对薄弱的环节需要从运行状态把握、群体智能决策调整、宏观和微观演化效果评估等角度开展研究。相关研究内容已经在重大挑战性问题的5.1.3节中给出,本节不再赘述。
\subsection{基于开源和众包的操作系统生态构建技术}
\subsection{新型硬件资源管理和调度技术}
过去60年中大型主机、个人计算机、手持移动设备、物联网设备等不同类型计算设备的出现推动着经典操作系统技术的持续变革。近年来处理器、存储器件、网络互联设备等硬件技术快速发展众核处理器、FPGA/GPU加速硬件、非易失内存、远程直接数据存取RDMA网络等一系列高性能、具有新架构和新特征的新型硬件不断涌现并逐渐成为主流技术。作为计算系统的“管家”如何充分适应新型硬件特点并充分发挥其潜能是操作系统理论和技术的重要研究内容。例如大规模分布式异构计算以及移动异构片上系统对Linux等多线程共享存储的单内核结构提出挑战多核和多芯片计算机系统中非一致性内存访问架构使得传统基于页的虚存系统面临挑战非易失性内存的应用使得内存中的某些数据不再需要存储到硬盘在为操作系统带来性能优化空间的同时对传统类POSIX文件系统架构带来挑战目前已有的设备模拟、设备半虚拟化、设备直通、单根虚拟化SR-IOV等技术尚不能完全扩展到GPU、张量处理器等人工智能新型加速器或者是效率和灵活性还需要进一步提升 100G及以上以太网链路在大规模数据中心的普及网络带宽增长速度超越CPU处理能力增长速度传统的操作系统网络协议栈面临挑战等等。
\subsection{面向特定应用领域的优化技术}
当前,运行于单一计算节点的操作系统架构已经趋于稳定,但移动计算、物联网等特定应用领域的快速发展,推动着相应操作系统实现优化技术的突破。一方面,移动计算已经是主流的计算模式之一,智能移动终端的操作系统当前已经形成了较为成熟的产业生态。但是,移动计算与边缘计算、人工智能等新兴领域的交叉融合,推动着其架构和实现机理的不断拓展,相应操作系统也表现出向低功耗、强交互、智能化和高安全发展的趋势,研究内容包括轻量级操作系统体系结构、多场景自适应电源管理优化、资源受限环境下的深度学习适配优化、多种生物特征认证增强等。另一方面,随着物联网等设备的普及,针对嵌入式计算中安全关键、任务关键、非关键等任务混合运行及其安全隔离问题,围绕任务确定性调度、系统实时响应、任务间高效通信、操作系统内核验证等技术展开研究,满足嵌入式计算在复杂环境中对系统实时性、安全性、可靠性的严酷要求。
\subsection{软硬协同的安全攻防对抗技术}
如何结合处理器和硬件平台的特点设计新型安全高效的操作系统结构是未来操作系统技术的另一主要研究内容。当前基于CPU的可信计算空间隔离和基于TPM芯片的可信计算技术为可信软件执行提供了硬件级的执行验证这些技术都从操作系统底层提供了有力的可信执行支持。未来操作系统安全研究将发展软硬协同的操作系统安全攻防对抗模式变被动响应为主动防护夯实信息系统的安全基础。具体而言需要突破软硬件高效协同的安全体系结构设计、安全防护模型和方法、跨域交互机理及优化方法和基于模糊测试的内核安全性测试等关键技术结合硬件平台提供的多层次特权防护、资源分区隔离等安全能力解决软硬协同的高安全操作系统设计中的核心问题。
\subsection{面向新型架构的资源虚拟化技术}
以“函数即服务”FaaS为代表的无服务器计算等计算模式和边缘计算等新型应用模式给传统操作系统和虚拟化架构带来了挑战。首先虚拟化技术需要能够在支持多租户隔离的前提下实现高密度的资源虚拟化。以在边缘计算场景为例与集中式云数据中心不同可能需要在边缘的十几个服务器上分别支持数千种不同的服务当前已有的基于容器的轻量级虚拟化技术尚不能完全满足。其次在无服务器计算和边缘计算等场景中应用对资源的需求是高度动态变化的这给虚拟化的性能提出了苛刻要求需要探索新的轻量级虚拟化架构和优化机制。再次部分云计算应用开始出现向微服务应用发展的趋势。这意味着软件架构进一步地解耦单个镜像上运行的业务更加专一。因此当前提出了 Unikernel等机制来大幅度精简冗余模块来提高虚拟机的启动速度但虚拟化场景下的适用性和成熟度还需要进一步提升。最后计算资源之外的其它资源如GPU、存储、网络等专用虚拟化技术需要进一步探索。
\subsection{跨结点的资源高效按需聚合技术}
“计算的泛在化”意味着操作系统和运行平台的作用范围突破了传统单一计算结点范畴,需要在广域环境内调度各类资源,为上层软件提供相对稳定的抽象。在计算系统规模持续增长的情况下,需要突破海量虚拟机资源的高效管理、虚拟机间通信优化、自适应的虚拟机在线迁移及动态部署、共生虚拟机间共享内存的弹性管理及优化、虚拟机访存效率优化等技术,实现跨结点的高效分布式计算资源调度。另一方面,网络操作系统中往往没有明确、固化的控制中心或层次结构,跨结点的“资源虚拟化”和“能力可编程”主要依靠“连接协调”、通过自底向上的方式来实现。如何借鉴社会系统、经济系统、生物系统等复杂系统机理,实现上述目标,也是此类操作系统面临的挑战。
在跨结点的资源按需聚合方面,未来的一个重要应用模式是“云-边-端”协同模式。因此,需要面向现代网络化信息支撑体系的发展趋势,探索以资源虚拟化、服务云化、前后融合为基本特征的“云-边-端”协同操作系统柔性结构设计与优化技术,研究“云-边-端”高效资源协同调度框架、基于云边端协同和多目标优化的任务调度技术等。
\subsection{多租户条件下的主动防御技术}
多租户将是未来运行平台的主流应用形态之一。更多的服务被整合在单一平台上这些服务中可能包括了来自不同租户的不同安全等级的信息必须根据用户需求对应用系统的硬件、软件、数据、网络、存储等不同层面资源实现安全隔离。同时为了提高资源利用效率运行平台根据资源使用情况进行动态调度这种动态变化的环境将显著增大了安全隔离的难度。为了提高服务运行性能以Docker为代表的轻量级虚拟化容器技术也被广泛应用相对于虚拟机的强隔离性容器技术则是以弱隔离性换取性能的提高。在应用虚拟化技术的过程中隔离性与性能之间的取舍、动态变化下虚拟计算资源的安全复用、Hypervisor层的虚拟机监管、虚拟机逃逸防护等都成为必须要面对的挑战。同时虚拟化技术还需要对软件定义网络在数据中心内部的网络安全管理提供支持通过虚拟网关等技术对虚拟化数据流进行安全监控这些虚拟设备能否安全使用都将对系统安全性产生深刻的影响。
\subsection{物理和社会资源的抽象和管控技术}
操作系统 “资源虚拟化”的能力来自于其对资源的抽象、封装和调度。传统操作系统针对信息空间内部的资源,已经建立了进程/线程、内存页/虚拟内存、文件等相对稳定的抽象实体。未来,在人机物融合系统中,如何表达和管理各类高度异构、动态变化的物理和社会资源,是操作系统领域的开放问题。其中一个核心问题是:在认知、物理和信息空间三者之间,如何刻画、检验、保持、校正多模型结构之间定性与定量一致性,进而实现具有“数字孪生”的物理和社会空间资源的调度和管理。此外,未来操作系统的编程接口不仅涉及到计算资源的“软件定义”,可能包括各种可传感物体对象、智能无人系统等各类物理资源,甚至向其他具有“数字孪生”特性的经济、社会和生产生活资源,其接口形式、接口实现机理等都是开放的问题。
\subsection{运行平台支持的软件持续演化技术}
适应和演化是未来人机物融合软件的基本特征其实现机制牵涉到两个层面。首先未来人机物融合软件的运行平台自身应当是可以是柔性设计、可以持续演化的。其次操作系统和运行平台是能够支撑上层应用适应和演化的天然基础设施但由于在线演化的需求是在“软件作为基础设施”过程中逐渐显现的其实现机理也是目前操作系统和运行平台领域研究相对薄弱的环节需要从运行状态把握、群体智能决策调整、宏观和微观演化效果评估等角度开展研究。相关研究内容已经在重大挑战性问题的5.1.3节中给出,本节不再赘述。
\subsection{基于众包和开源的生态构建技术}
随着互联网的深入发展和广泛应用,操作系统和运行平台的研发出现了新的特点,其中开源和众包对操作系统的发展产生了深远影响。它们一方面改变了操作系统产业的商业模式,服务化成为趋势,操作系统厂商如苹果、微软纷纷从销售产品获利转型为提供服务获利的模式;另一方面促进了面向行业或应用场景需求的专用操作系统的发展,降低了操作系统研发定制的门槛,使得更多的厂商可以参与到操作系统生态链构建中来。但是,开源和众包模式的引入,也为操作系统的开发带来了一系列问题。例如,在使用开源资源时,如指导思想和方法不当,可能导致在产品中包含若干“黑盒子”,引入代码不可控、产品升级被动等风险;产品如过度依赖开源,发展途径就会被开源主导,创新的空间将被大幅约束;等等。如何在操作系统生态链构建过程中最大限度发挥开源和众包的长处,是需要深入研究的问题,相关的研究方向包括操作系统代码来源链的建模和分析、开源许可证的合规性及冲突分析、多来源缺陷数据的定性与定量统计分析等。
\section{结束语}
无论是今天还是未来,操作系统都是“软件作为基础设施”的集中体现,也是“软件定义一切”能力的基石。在计算泛在化背景下,未来的操作系统将突破当前单机操作系统这一狭义形式,向支撑人机物融合、具有“资源虚拟化”和“功能可编程”特点的泛化运行平台过渡。受这一趋势所推动,一系列重大挑战性问题涌现,包括支持软件定义的新型运行平台架构、泛在资源的高效虚拟化和调度方法、软件系统持续适应演化的支撑机制、人机物融合过程中的安全与隐私问题等。本节对上述挑战的概念内涵、产生背景和展开后的具体问题进行了详细阐述,并在此基础上结合操作系统和运行平台领域当前研究热点,从未来的节点操作系统、网络操作系统等角度,对领域研究内容进行了梳理。
\section{参考文献}
[1] Mei, H., and Guo, Y.: Toward ubiquitous operating systems: A software-defined perspective, Computer, 2018, 51, (1), pp. 50-56

Binary file not shown.

Before

Width:  |  Height:  |  Size: 49 KiB

After

Width:  |  Height:  |  Size: 291 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 252 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 53 KiB

After

Width:  |  Height:  |  Size: 251 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 43 KiB

After

Width:  |  Height:  |  Size: 234 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 35 KiB

After

Width:  |  Height:  |  Size: 250 KiB

BIN
fig2-5/cnt.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 258 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 81 KiB

After

Width:  |  Height:  |  Size: 250 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 45 KiB

After

Width:  |  Height:  |  Size: 114 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 96 KiB