新一代操作系统的构想

当一堆机器通过puppet、pssh这样的软件在管理的时候,你真想,如果它们共同运行一个操作系统,由那个操作系统统一替你协调这些机器该多好,而这个操作系统不能是openstack那种以机器(运行Linux、Windows这样的操作系统的环境)为单位的,而应该是以我的“程序”为单位的。软件架构,不能太过离散。

日志、定时器事件、用户、安装包……为什么不统一规划呢?以前的OS是面向单机的,现在的OS是面向群集的,这可能就是Elastos该出手的地方。

 | 973 views | 0 comments | 2 flags | 

GlobalPlatform 和 TEE

http://blog.sina.com.cn/s/blog_a9303fd90101ji11.html

 

GlobalPlatform is a cross industry, non-profit association which identifies, develops and publishes specifications that promote the secure and interoperable deployment and management of multiple applications on secure chip technology.

我的理解是: GP(GlobalPlatform) 是一个指定TEE标准的organization.

TEE (Trusted Execution Environment ):

TEE is a secure area that resides in the main processor of a smart phone (or any mobile device) and ensures that sensitive data is stored, processed and protected in a trusted environment. The TEE’s ability to offer safe execution of authorized security software, known as ‘trusted applications’, enables it to provide end-to-end security by enforcing protection, confidentiality, integrity and data access rights.

这个网址对TEE 有概述:

http://www.globalplatform.org/mediaguidetee.asp

TEE 具体标准:

GlobalPlatform has already worked to standardize the management of applications on SEs and also has extensive experience in the TEE through the development and delivery of three different specifications:

  1. TEE Client API Specification v1.0 outlines the communication between applications running in a rich OS and trusted applications residing in the TEE.
  2. TEE Systems Architecture v1.0 explains the hardware and software architectures behind the TEE.
  3. TEE Internal API Specification v1.0 specifies how to develop trusted applications.

All specifications can be downloaded from the GlobalPlatform Device Specifications webpages.

 

 | 28 views | 0 comments | 0 flags | 

【转】征集华人操作系统项目列表

http://blog.csdn.net/DanceFire/article/details/729385

也许大部分人都知道Windows,可能相当一部分人知道Linux,甚至知道Linux和Windows的纷争。但是提到华人制作的操作系统时恐怕就知之甚少了。能提起名字的,恐怕只有中科院的红旗、国防科技大学的银河麒麟。但是,华人制作的操作系统就只有这么几个商业化的或者科研计划的操作系统么?

其实远不是这样。在民间,已经有大量的操作系统人才在积蓄着自己的力量,已经有优秀的作品发布了出来,这里面既包括了Magic Linux、RelaxBSD这类比较成熟完善的系统,也包括了那些刚刚起步还只有简单命令行的实验性操作系统。他们的努力不应该被埋没。

为了让大家知道我们国家还有这么多各式各样的操作系统项目在进行着,我打算建立一个华人操作系统项目的列表,并一直维护这个列表。我知道有很多对操作系统很执着的华人,有些人已经建立了自己的操作系统项目,但是由于没有办法引起关注,时间长了,也就慢慢的失去了兴趣。这些人为中国操作系统事业所做的努力是值得大家敬佩的。因此我希望能通过这个列表,让所有想做操作系统的或许能够通过这个列表而找到伙伴,也希望能够通过这个列表让一些刚刚起步的操作系统项目受到关注。谨以此来支持我们国家的操作系统事业吧。

我无法收集到所有的项目,所以希望大家能够帮我提供收集这些项目。无论是官方的,还是民间的;无论是开源的,还是闭源的;无论是过去热闹过,现在没有动静的,还是到现在为止依然火爆的;无论是完全原创的,还是在别人基础上改造的。只要是华人在努力做的,现在依旧可以从网上找到的,我都会收集到这个列表中。

而且,如果有可能,我也愿意收集这些作品,在我的网站上作镜像。好吧,不多说了,只要你知道的,又没有存在于我的列表中的,就给我写email或者留言吧。我会确认后,添加到列表中的。最好能够告诉我,操作系统项目的名字,作者(人或组织),网站链接或email. Dancefire#gmail。

对了,如果有研究操作系统的组织,也可以告诉我,我也会把这些华人研究操作系统的组织列于此。

介绍文字及图片大部分是来源于原作者或者原网站上的描述,其版权归原创作者所有。

:将主题改为《征集华人操作系统项目列表》,以图广泛收集华语社区中优秀的操作系统项目,而不仅仅局限于大陆,欢迎台湾、香港、澳门等华语社区的朋友提供由华人主导的操作系统项目信息。谢谢了。详见(http://blog.csdn.net/DanceFire/archive/2006/07/28/991620.aspx)


 

华人操作系统项目列表 (已收录46个操作系统项目)

 

操作系统名称

简介

ANOS

http://larryli.51.net/anos/

ANOS 是一个操作系统(AN Operating System)。一个尽可能简单的 i386 操作系统,或者说仅仅只是一个系统。不需要其他东东就可以在电脑中运行的程序。


ANOS 本身不是为了作为一个实用的 OS 而存在,而是为了作为一个 OS 演示而存在。尽可能简单的展示一个操作系统的具体代码就是 ANOS 的目的。虽然 Minix 还有 Linux 0.01/0.11 同样为我们提供这样的演示。但是 Minix 基于微内核以及完成很多额外工作(这是一个实用的系统所必须的),其代码还是相当庞大的。至于 Linux 初始版本,当然是研究一个小系统的好例子,但其代码有点混乱(很强的黑客风格)。而其他的小 OS 不是未完成就是有着这样那样的弊端。
弊端其中之一就是,我们当前多半使用的是 Win32 系统,而这些小 OS 很少是在 Win32 平台下开发的。仅仅靠阅读代码也无法了解 OS 的,所以研究起这些 OS 来缺少一个实际动手的机会。往往大家只是构筑一个研究用的平台就烦的撒手不干了。
所以,ANOS 选用 Win32 下 MinGW GNU C 编译器和 NASM 汇编器以及 QEMU 模拟器来进行开发。同时,ANOS 会根据进度发布一个 OS 在不同阶段的源代码包,展示 OS 开发中状态。并且尽可能的提供足够的文档资料以及代码注释。方便大家自己动手参与进 ANOS 的代码,了解 OS。

APEC OS

http://blog.csdn.net/cloud_apex/

Apex的ORIGlN版本(第一个版本)将不考虑PCI的编程.1.支持线程
2.内存寻址4G
3.支持ATA2
4.图形界面
Bean’s Operating System

http://www.beanos.org

The Beans’ Operating System is an Open Source project aimed at building a “simple and complete” operating system on x86 architecture, for fun of the guys who are interested in low level programming. the purpose of this project is researching and practising, only the “basic but correct” code is to be expected. Therefore, the kernel would never copy or port any other source code of famous open source OS. but the drivers may limitedly refer to some code from experimental OS which has already given up its copyright.

The source code of   beans’ is written by C and Assemble languages.

Beans’OS is developed under the GNU General Public License. There is a copy of GPL in the source code package.

NOTE: The applications that use kernel services or libs using system calls are not a part of this project and the copy right of them belongs to their author.

Kernel of Beans’OS ,some user spaces lib and applications are built and tested in the linux environment. and to be written into a floppy image, the floppy image is bootable, can be tested in a real PC with x86 CPU using a real floppy. as well as the virtual machines using the image.

Chinx
中文GUI操作系统

http://gro.clinux.org/projects/chinx/
http://www.vchelp.net/copathway/project_view.asp?prj_id=1286

初期基于Linux0.11内核,使用MiniGUI作为默认GUI,后期可以考虑向Windows和Linux兼容,改写内核;我们的操作系统争取能运行Windows和Linux两种系统的应用程序

cnix

http://cnix.gro.clinux.org/

cnix是一个小型的OS(如果可以称作为OS的话:),是一个运行在i386体系结构上 的、保护模式下的OS。就目前以及将来很长一段时间来说,cnix都是一个为了学习目的而搭建的,一个试验性质的操作系统。用来实验一些新想法,新技术,同时,我们希望通过这个项目,学习到OS是怎么样开发起来的大致框架和基本技术,了解底层软件的编写方法和OS的细节!

COSIX 64

http://www.cs2c.com.cn/

康柏公司向中软总公司提供Tru64 UNIX的源代码,并为中文64位UNIX提供全面的技术支持和市场推广支持。中软总公司以康柏Tru64UNIX为技术基础,开发并增强该系统对中文、因特网等各类应用的支持能力,以推出适于中国市场的64位UNIX操作系统—-COSIX64。COSIX64系统将与康柏Tru64 UNIX完全二进制兼容,所有运行于康柏Tru64 UNIX上的应用软件都可以在COSIX64上运行。

DeltaOS

http://www.coretek.com.cn/

DeltaOS®是一个实时操作系统,这个实时操作系统可以嵌入到以32位中央处理器为核心的各种电子设备中;作为应用程序运行的支撑环境,DeltaOS®所提供的各种机制可以使电子设备中的应用程序在多任务环境下运行,同时满足开发人员在开发电子设备时的基本需求,比如:实时响应外部事件、存储管理以及联网需求等。科银京成提供了一套完备的开发工具LambdaTOOL®,使DeltaOS®上的应用程序开发过程变得简单、高效。

DeltaOS®的组成

DeltaOS由内核DeltaCORE、文件系统DeltaFILE和网络协议DeltaNET组成。

内核-DeltaCORE

DeltaCORE可以使应用程序以多任务的形式运行;任务之间可以进行通信和同步;DeltaCORE提供的各种机制可以保证应用程序能够及时截获外部事件并作出响应。

在应用程序编程接口方面,除了科银京成自己的API以外,DeltaCORE还支持另外两种API,他们是:

  • POSIX API
  • VxWorks API。

网络-DeltaNET

DeltaNET是一个网络协议,它可以使电子设备以TCP/IP协议的形式与其他设备进行通讯,它也可以使一个电子设备成为全球网-因特网的一部

文件-DeltaFILE

DeltaFILE可以使应用程序以文件的形式管理电子设备中巨大的存储空间,这些存储空间可能是内部存储器RAM、外部存储器硬盘或软盘、也可能是新型存储设备-闪存等。

DeltaOS的发展历程

 

经过产业化发展,科银京成开发出能够适应嵌入式应用开发的比较完整的产品系列。产品系列命名为“道系统” DeltaSystem,并获国家863重大软件专项支持 。主要包括嵌入式实时操作系统 DeltaOS 、嵌入式集成开发工具 LambdaTOOL 、嵌入式应用组件和测试工具 GammaRay 。

DeltaOS 包括嵌入式实时内核 DeltaCORE ,嵌入式 TCP/IP 系统 DeltaNET ,嵌入式文件系统 DeltaFILE 。 DeltaOS 设计开发时参考了比较著名的嵌入式实时操作系统 RTEMS 、 PSOS 、 VxWorks 、 VRTX 等。 DeltaOS产品发展的里程碑:

  • 2000 年 4 月,推出DeltaCORE1.1、DeltaNET1.1、DeltaFILE1.0
  • 2001 年 4 月,推出DeltaCORE2.0、DeltaFILE1.1
  • 2002 年12月,推出DeltaCORE2.1、DeltaFILE2.0、DeltaNET1.2
  • 2003 年 1 月,推出 DeltaCORE v2.1 、 LambdaTOOL v2.1
  • 2004 年 1 月,推出 DeltaCORE v2.2 、 LambdaTOOL v2.2

DOOLOO RTOS

http://blog.chinaunix.net/article.php?articleId=59068&blogId=11037 [简介链接]

DOOLOO RTOS是一款实时操作系统,由uKernel(实时内核),BSP(Board Support Package,板级支持包),Kernel Services(核心服务层)3大块组成。

实时内核uKernel采用100%标准C语言编写而成,包括:
- 任务调度:支持多任务调度,采用了基于优先级抢占的任务调度算法,支持256个优先级(0 – 255,255由空闲任务使用,一般不用),对相同优先级的任务使用基于时间片的轮转调度策略。
- 任务同步机制:信号量和基于优先级继承的互斥锁,可以有效的防止任务的优先级翻转。
- 任务间通信机制:拥有丰富的任务间通信机制,消息队列,邮箱及异步信号。每种通信机制都配备获取等待时间,保证实时性。
- 中断处理:中断处理支持嵌套方式的中断处理方式。
- 内存管理:支持静态内存管理及堆式真正意义上的动态内存管理。
- 设备管理:实现了按名称访问的设备管理子系统,涵盖了字符设备,块设备,MTD设备及网卡设备的驱动接口。

BSP板级支持包包含了和底层硬件相关的部分,由汇编和标准C编写而成的,当移植到新的平台时,只需要把底层BSP重新实现或移植即可。从目前的工作量来看,移植到一个全新的平台需要约一个月的时间。目前BSP支持:
- x86保护模式
- ARM7TDMI(s3c4510,s3c44b0, ep7312等)

Kernel Service(核心服务层)主要是提供对应用程序上层的内核服务,包括了近百个标准C、POSIX接口函数。

EdenOS

http://edenos.diy.myrice.com/

EdenOS是一个完全32位的PC操作系统,需要386以上的机器. 它内核短小,启动速度极快, 即使从软盘启动也只需要1秒钟左右.启动后运行于保护模式下,现在已经完成了32位的显示,键盘,软驱,硬盘等驱动,可以用命令自由的显示32位线性内存,进行I/O测试,读写软盘数据,观看硬盘结构等.现在已经实现多任务测试,正在开发内存管理模块。


Eden使用VC7.1作为主编译工具(以前使用VC6.0),用Tasm5.0编译少量的16位/32位汇编代码,并用自己的链接程序blink链接,生成可执行代码.所以为Eden开发程序非常简单,只要能使用VC就可以。

elastos 和欣操作系统

http://www.elastos.com.cn/

“和欣”操作系统是由科泰世纪开发的具有完全自主知识产权的32位嵌入式操作系统 。

操作系统基于微内核,具有多进程、多线程、抢占式、基于线程的多优先级任务调度等特性。提供FAT兼容的文件系统,可以从软盘、硬盘、FLASH ROM启动,也可以通过网络启动。

操作系统提供的功能模块全部基于CAR构件技术,因此是可拆卸的构件,应用系统可以按照需要剪裁组装,或在运行时动态加载必要的构件。

从传统的操作系统体系结构的角度来看,和欣操作系统可以看成是由微内核、构件支持模块、系统服务器组成的。

ENIX = Easy UNIX!

XForce操作系统内核简介

作者:Flysky(esxgx)

XForce内核是我的第三个C的作品,这个作品采用了GCC+NASM混编的形式,具体的结构如下:
初始化 NASM汇编 ->关于保护模式的初始化
内核 GCC+AT&T汇编 ->各种模块
在我们的计划之中还有内核的可插入模块支持.
另外,这个内核基于UNIX V7标准(POSIX太庞大),目前进度为:
进程管理 第二版 [更改为线程调度为基础]
内存管理 第四版 [完全的高速分配和释放,10000000次分配和释放30秒时间]
文件系统 正在开发中
中断管理 第二版 [全部完成!]

Everest

http://www.linux-ren.org/modules/projects1/index.php?id=4
http://www.linux-ren.org/modules/everestblog/
http://cvs.linux-ren.org/

Everest项目是以Linux人社区为依托,采用社区开发方式,以开源软件推广普及和提高为宗旨的Linux社区版本开发项目。

项目的目标是提供一款最新、最酷、最快,轻量级、模块化的Linux操作系统;并以此为平台,探索各种Linux前沿技术,开发出更多具有影响力和生命力的软件项目;回馈国际社区,促进国人与开源社区的交流,使国人在开源社区中能发挥更重要的作用。我们希望Everest项目能够成为中国人在开源领域里未来的创新技术的发源地。

项目名字Everest是“珠穆朗玛”的英文单词,蕴涵了我们攀登开源技术高峰的理想和目标。其Logo既是白雪皑皑的雄伟珠峰,又是三个“人”字的叠加,源于“三人为众”的含义。我们希望国内开源社区的力量能在此平台下得到更好的凝聚和发挥,在国际开源社区占有一席之地。

Everest版本将朝以下五个目标努力:

  • 最新:采用开源社区项目的最新稳定版本,并通过整系统更新技术保证您的系统“与社区俱进”。
  • 最酷:集成社区最前沿技术实现,并作为试验床,开发各种创新技术,让您的系统“与众不同”。
  • 最快:没有最快,只有更快,开发团队将在Everest平台使用所有的系统优化手段,保证系统能够以更高的效率运行
  • 轻量级:永远采用一张光盘系统安装的发布规模,Get one CD, Get the world。随着开发工作的深入,体积将继续不断的缩小。
  • 模块化:整个操作系统将被清晰的分割成独立的模块,让您随心所欲的定制自己的操作系统,最终实现在线定制个性化操作系统。


Everest采用完全开放和自由的社区方式,整个开发流程以及开发过程中产生的所有资源和代码,包括CVS代码库、Bugzilla库、RPM和 SRPM库,将彻底对外开放并实时更新,开发者可以得到最新的CVS代码。

Everest开发路线图为:每两个月发布一个snapshot(快照)版,每6个月发布一个正式Release版。我们将通过在线升级功能保证您正在使用的系统是时时更新的。快速的开发周期将使社区用户能够尽早地体验到各种正在开发中的创新技术,并提出反馈和意见。

在项目成立之初Everest即得到了各大商业公司的支持,得到了社区开发者和爱好者的参与。我们希望有越来越多的自由开发者和爱好者能够加入到 Everest项目中来,贡献自己的力量。

让我们共同努力,打造国内最开放、最前沿的社区Linux发行版本,迎接更加美好的明天。

ExOS
(E-mean OS)

http://www.xemean.net/exos/

  运行于i386平台的简单的32位操作系统模型(目前还不能称为操作系统),目标是:一个完整系统内核、具有图形用户界面、简单易用并且能安装在USB闪存上的小型操作系统。    大概是2003年国庆假期,我以Emu8086这个软件所带的Micro OS为原型写了自己的第一个“操作系统”,引导程序将指定扇区的“内核”读入内存,然后交给内核运行,当时我高兴万分。

   与大部分操作系统项目不同的是,我的“Write your own operating system”之旅完全从零开始,从引导程序到内核的实现花了相当长的一段时间,我的基础是相当差的,所以第一个版本只是简单的扇区读取,以及显示一些字符,再就是通过BIOS 16号中断提供输入服务——这是一个16位的系统模型;在这个基础上,我写了0.0.2及0.0.3,这都是16位的系统模型,它们的出现只是越来越像一个实模式的操作系统;出于有一个自己的操作系统的欲望,再次花了相当长的时间钻研保护模式并经过几次实验以及其它代码的参考之后,ExOS终于工作在保护模式下了。

Fairysky

http://www.fairysky.org/

1. Fairysky是一个还没有完成的操作系统软件:-)。我们称我们的小组为Fairysky组。
2. Fairysky将是一个类unix系统,原型来自于Linux。
3. 制作Fairysky的不是一个人,而是很多人,这是一个典型的网上合作开发项目。
4. Fairysky是一个符合GNU GPL协议的自由软件。
GOS 操作系统

http://www.play2nd.com

GOS 是什么?
这是一个中国人自己开发的操作系统,名称是暂定的。这是个以图形工作界面为主的多任务操作系统。 虽然目前还很不成熟,甚至我们还不确定她在您的计算机上是否能安装和运行,但是我们坚信它的前途是光明的,我们也希望您能拥有同样的信念。 对于这个系统,我们主要期望的目标为实用、易用、安全和高效。 欢迎您进入我们的论坛,发表您的意见,看法,批评。您的支持和鞭策是我们最大的动力。

是否开源?
我认为,对于绝大部分的最终用户,开源是没有很大必要的。因为,最终用户的目标是使用计算机。就好像一位拥有汽车的用户, 不需要非常详细的了解汽车的每一个零件是如何工作的。他更加关心的是这辆汽车是不是安全、舒适、快速而且方便驾驶的。 中国需要自己的操作系统,但是中国不需要每个人都做操作系统,对于那些对系统开发有深入了解的人员,我们非常期待您能加入我们的开发组织来共同开发这个系统, 但是,这是正规的开发而不是无组织无纪律的开发。对于其他应用程序开发人员,我们非常愿意与您合作,提供例如如何高效而方便的开发 GOS 应用程序所需要的技术信息。

中国人的信念
我相信,中国人是善良、聪明、勤劳而且勇敢的。以前是,现在是,将来也必定是。
操作系统开发和计算机芯片开发,曾经是多少中国人的梦想。 对于硬件,如今,龙芯 2E 已经研制成功了, 计划中的龙芯 2F 也在研制当中了。 对于软件,中国也有很多的操作系统开发组织正在辛勤的耕耘着,他们正在积蓄着爆发的力量。 相信不久的将来,我们就可以使用中国人生产的计算机和操作系统了。

最后一句话
少发呆,多思考,少争论,多讨论,少说话,多做事。

Hiweed Linux

http://linux.hiweed.com/

Hiweed-Debian GNU/Linux桌面版基于Debian GNU/Linux,适合中国的Debian新手和老手使用。Hiweed桌面是一份已经配置好的中文桌面,包括fcitx中文输入法,stardict词典,zhcon中文终端,ttf-simsun字体等等。Hiweed的目标是:免去新手的痛苦,节省老手的时间。

Hopen嵌入式操作系统

http://www.hopen.com.cn/

中科院女娲计划的产物。

Hopen OS是凯思集团昊鹏公司自主研制开发的嵌入式操作系统,由一个体积很小的内核及一些可以根据需要进行定制的系统模块组成。其核心Hopen Kernel一般为20KB左右大小,占用空间小,并具有实时、多任务、多线程的系统特征。

Jicama OS

http://blog.csdn.net/jicamaos

这是一个同时支持32位和64位CPU的操作系统,支持图形界面。

JK (Just the Kernel)

http://jserv.sayya.org/
http://jserv.sayya.org/kernel/jk-0.0.0.tgz

JK (Just the Kernel) is the first operating system kernel written by Jim Huang, derived from RJK, a kernel for The Free Java OS Project with more extensibility and well portibility targeted to be a light-weight kernel, self-contained, including the JVM image and any needed modules as an implementation of all the required functions of the Kernel Interface. Jim Huang released JK in 2001, but he dropped out its development because he got interested in Java VM internals, and he went to Kaffe.org as one of the developers. The latest version of JK is 0.0.0

Kingmos
巨果嵌入式操作系统

http://www.mlg.com.cn

巨果·Kingmos嵌入式实时操作系统是运行在32位CPU上的抢先多进程/多线程嵌入式实时操作系统。其内核(Kernel)采用微内核设计思想和方法,提供最基本的核心功能:任务/线程的管理;中断管理;内存管理(包含虚拟内存,硬件必须有MMU);系统调用管理等。可裁剪的内核,内核大小约30KB~230KB。系统服务功能(由服务进程提供)采用Client/Server模型进行构建。

Kylin
银河麒麟服务器
操作系统

http://www.kylin.org.cn/

按照麒麟帮助文档中描述的,银河麒麟操作系统是针对未来的主流网络服务和高性能计算服务的需求,参照国际主流标准,参考Darwin、FreeBSD、Linux和其它商用操作系统,借鉴UNIX操作系统和微内核操作系统的设计思想,设计并实现具有自主版权的、可支持多种CPU芯片和多种计算机体系结构的、具有高性能、高可用性与高安全性的、并与Linux应用和设备驱动二进制兼容的中文服务器操作系统。

银河麒麟操作系统2.0版(Kylin 2.0) 是国防科技大学计算机学院推出的具有自主知识产权的服务器操作系统。KYLIN 2.0操作系统在全面继承先前KYLIN 2.0-alpha版和KYLIN 2.0-beta版的整体特征的基础上,进一步优化和升级了操作系统核心,并全面改进了LSB兼容性、安全性、网络性能、系统配置和用户使用环境等方面。KYLIN 2.0将更适合于网络服务器系统、电子政务平台、安全信息服务器等用途。

Lava-X OS

http://lee.lava8.com

LavaX-OS是以LavaX虚拟机为核心的跨平台操作系统。
您现在所见到的是LavaX-OS的GBA版本。
LavaX由李杰(LeeSoft)发明并拥有全部版权。
了解更多关于LavaX的情况,请到以下网址:
http://lee.lava8.com

LavaX-OS之GBA版本为版权软件,您可以免费使用,您也可以自由传播,但不得修改系统的任何部分,也不得删除RomDisk中System文件夹中的任何文件和本文件。您也不得将本系统或其中的一部分用于商业行为,违者将受到法律范围内的全面制裁。

LearnOS

http://writeos.com/

这是一个模拟DOS的引导程序,它还仅仅是一个引导程序,只有512字节.

在这个引导程序里,我们初步实现了DOS的界面,模拟实现的,而且实现了DOS下的两个命令–cls和reboot.

这是一个简陋的实现,真正的实现不可能全放在引导程序里做.引导程序的功能就应该是引导.但我们这里只一个演示,至少我在看到自己模拟的DOS环境下是很兴奋的.能更大的引起你对系统开发的兴趣,这才是你学习它的最大动力.

它还没有实现退格键功能.还没有实现大小写通用,各种功能键都没有处理.但这并不影响他现在做了为一演示代码.

我们下一步要做的是Fat12格式的兼容,尽管我们可以像教程中写的那样规定我们自己的格式.但那样只会使我的们幼小的系统更孤立.

Lingix 操作系统

http://lingix.gro.clinux.org/

华中师大陈斌发起的作品

Linux 兼容内核

http://linux.insigma.com.cn/

这可不是单纯的Linux内核哦,这是浙大网新毛德操发起的一个在内核级别进行Windows和Linux兼容的尝试。试图在内核中同时支持Linux和Windows程序。他们是这样介绍自己的:

  我们的目的是要把Linux的内核扩充成一个既支持Linux应用、也支持Windows应用,既支持Linux设备驱动、也支持Windows设备驱动的兼容内核;使用户可以直接在Linux上高效运行Windows应用,而无需使用Windows操作系统。

  我们之所以要开发这么一个兼容内核,是为了提高桌面Linux的市场竞争力,为广大用户多提供一种选择,让更多的人用得起计算机;而并非有意向微软叫板,也不带任何情绪化的因素。

  我们这个项目是由浙大网新科技有限公司投资和主持的开源项目,我们将遵守GPL规定,公开那些按规定应予公开的源代码。我们欢迎世界各地的广大网友与爱好者的参与,形成一个Linux兼容内核的开源社区。这种参与既可以体现为代码、方案、信息等方面的贡献,也可以体现为给同伴以鼓励、为项目而呐喊。

Magic Linux

http://www.magiclinux.org/

一个由国内民间制作的Linux发布,非常不错,不比那些商业公司的差哦。而且又非常有特色的MagicInstaller。它是这么介绍自己的:
Magic 是针对其他发行版本存在的各种问题而专门为华语用户开发的桌面版(不是服务器版),你感觉其他发行版本你最难受的地方都有哪些?Magic 就是用来解决这些问题的。建议安装 Magic 试试就明白了。

MenuetOS

http://www.xemean.net/menuet/

MenuetOS是一个为x86(IBM兼容)计算机开发的业余操作系统,它是一款完全由汇编语言(32位)写成的迷你操作系统,因此它更小、更快,并且系统本身用应用程序占用很少的系统资源。

  项目最初是芬兰人 Ville Turjanmaa(赫尔辛基大学) 利用业余时间开发完成。现在世界各地都有 MenuetOS 的开发者,他们正在不断完善这个操作系统。

   这个项目目前由 Jarek Pelczar(jarekp3[@]wp[.]pl) 接管。项目的中文版由站长 E-mean X. 开发。

  MenuetOS 并不像现在流行的 Linux 及其它如 FreeBSD、Minix 一样是一个类 Unix 的操作系统,它完全由32位汇编语言编写的系统。Menuet 及其应用程序不基于当前任何一款流行的操作系统而运作,主要是为在开发过程中避免复杂的编程及各种不可预料的 Bug。

  尽管Menuet是完全用 32位汇编写成的,但它的系统程序构架并不完全是为汇编语言而保留,它的接口实际上可用于任何程序设计语言。尽管如此,系统开发的目的还是为更简化 Asm程序设计而设计,系统下 GUI编程尤其体现这一点。

NeoShine Linux
中标普华 Linux

http://www.cs2c.com.cn/

原中软COSIX、中软LINUX业务及团队以及唐舟OFFICE业务及团队均整体进入中标软件。它的前身应该是COSIX Linux。合并后,中标软件发布了自己的中标普华Linux,并有了一个新的名字NeoShine Linux。

Orz Microkernel

http://blog.linux.org.tw/~jserv/archives/001865.html
http://jserv.sayya.org/kernel/OrzMicrokernel-v0rz.tar.bz2

Orz Microkernel is a tiny microkernel written in 80386 Protected Mode Assembly with message-based design. Orz Microkernel is inspired by Minix[1].

Orz Microkernel is licensed under BSD-like license. See the file “LICENSE.txt” for details.

Additionally, Orz Microkernel includes a complete operating system environment, which provides a small bootloader, disk utility, shell, and sample programs (“Hello World” and floppy dumper). All of them require NASM[2] to get built, and it is recommended to use qemu[3] for testing. Refer to the script file “run.sh” to know how to launch the distribution.

[1] http://www.minix.org/
[2] http://sourceforge.net/projects/nasm
[3] http://fabrice.bellard.free.fr/qemu/

os-z
指尖操作系统

http://os-z.com/

指尖操作系统

基于IA32开发,安装最小内存为16M,
V0.1预览版是软盘安装版本,要有1.44软驱做A驱启动盘.

当前完成

  • VESA2.0显示
  • 支持最大4G内存
  • 软驱驱动
  • 硬盘驱动 ATA LAB
  • FAT32文件读取
  • COM,PS2鼠标驱动
  • 键盘驱动
  • 中文系统
  • ….

Paradox CORE

http://gro.clinux.org/projects/smartos/

The project smartos has been shutdown, and this project is on to replace the smartos project.
In Paradox CORE, we are dedicated to implement a cross-platform, micro kernel, which support basic functions as follows:

driver module;

kernel module(our definition is the supplementary function libraries to the kernel API system);

application and dynamic linking libraries(to be implemented in linux executable linkable format);

By Paradox, we are not going to implement another linux, but to intergrant all of the new operating system design methods in one, the main purpose is in the hope to make something useful.

We are currently working on the x86 platform, but soon we are moving to the ARM architectures whether with MMU or not.

Welcome anyone who have interests in kernel developping whether for study purpose or professional purpose to help us to make the elegance of it. Developer and testers are need and such information can be acquired by viewing our joblists.

Pagoda Object-oriented OS

http://gro.clinux.org/projects/pagoda/

一个面向对象的操作系统
Peter Operating System

http://pos.petersoft.com/

What is Peter Operating System?

Peter Operating System (POS in short) is my os research project, started in year two in university 1998.

What platform does it run on?

It runs on any IA32 system, with PS2 mouse and keyboard, support IDE harddisk.

Who is the author?

My name is Peter Cheung, from Hong Kong. You can reach me at mcheung63@hotmail.com

What is the latest version?

The current stable version is 2005.

Goal:

1) Provide a POSIX standard C/C++ library.
2) A graphic library
3) Have a beautiful GUI.
4) Network support
5) Dynamic adjust the kernel: slice duration, number of process, switch the paging algorithm during OS running.

Download:

http://pos.petersoft.com/downloadpage.php

PGOS

http://gro.clinux.org/projects/pgos/

PGOS是一套专门为小型嵌入式系统准备的开源RTOS。PGOS的目标是最终设计成一个开放源代码的,可移植的,可配置的,拥有快速的执行能力与强大的外围模块配套的RTOS。

PowerOS

http://www.dengwengang.com/poweros2002/

PowerOS(F)2002 是一个具有独立16位系统内核的磁盘操作系统.它是一个便携的操作
系统,只需用一张软盘就可以随时把它带走,也可以随时在386或P4的电脑上启动而无需重
复安装.它拥有自己的文件系统和内核,只对软盘进行管理,尽管功能不是很强,但是很灵活
而且由于文件系统的隔离,不容易感染病毒,也不容易传播病毒.而它主要是个人使用而设
计的.

启明 OS

http://qimingos.51.net/

作者是这样介绍它的:

“这是我在高中时就开始计划的一个梦想!那个时候我对于操作系统技术还不是太懂,甚至是根本不懂!那时候我的想法是这样的:开发一个小的多任务图形界面的中文操作系统!完全兼容linux,部分兼容windows。

现在看来着只能是一个幻想了!因为已经不在是那个只会空想的我了。随着我对操作系统的理解,想法也越来越实际,我现在的想法是:

首先,这不是一个有实用价值的操作系统,虽然我一直往这方面努力!

其次,这个操作系统不会在兼容性方面下工夫了!因为开发这个操作系统本身已经很困难了!不过,如果可能我还会在这个方面努力的!

还有,就是这个操作系统是开源的!大家可以自由的使用里面的代码(不过要注明来源,而且要在声明部分写明!呵呵!毕竟这是我的心血啊!相信大家会理解的!)”

Redflag Linux
红旗 Linux

http://www.redflag-linux.com/

红旗数据中心服务器5.0 以 Asianux 2.0 和Linux 2.6.9内核为基础,提供了一个稳定安全的高性能计算平台。他具有独特的系统诊断和恢复功能、易用的图形界面和智能管理工具集,可作为32位或64位数据中心或者网络应用服务器,创造连续高效的业务价值。

RelaxBSD

http://www.relaxbsd.org/

Relax 2.0 Beta Login

RelaxBSD是国内一些对FreeBSD情有独钟的爱好者制作的中文FreeBSD的LiveCD项目。

Q:为何取名为RelaxBSD?
A:relax有“轻松、放松”之意,即让大家轻松地享受BSD所带来的乐趣,给BSD入门者带来一个轻松入门的平台;给移动办公者带来一个轻松的工作平台;也给不同层次的朋友带来一个休闲、娱乐的平台。

RelaxBSD 1.0 代号为hope

Q:RelaxBSD是如何发布的?
A:RelaxBSD是一个基于FreeBSD(
http://www.freebsd.org) 的LiveCD,一部分代码来自于 FreeSBIE (http://www.freesbie.org),BSDinstaller来自于 http://www.bsdinstaller.org,所有RelaxBSD所作的代码均以BSD License发布。其它大多数软件都通过FreeBSD ports 安装。

RS-RTOS起源

RS-RTOS项目是面向强实时嵌入式应用领域的操作系统,RS-RTOS源自工业级的嵌入式实时内核RS-KERNEL,RS-KERNEL最初被设计用于工业电机控制,十分强调系统实时性,平稳流畅的处理能力。基于RS-KERNEL产品成功应用,RS-KERNEL于2004年对外公布第一版 V1.00,成为具备工业级品质的开源项目。RS-KERNEL最初版本以R&S命名,由作者阮海深(Haishen Ruan)负责维护,随着应用领域的扩展,R&S也不断的推出更新版本,从R&S1.11到R&S1.20,R&S经历了一次重要的结构调整,吸收了国际多个实时操作系统优秀特性。发展到V1.21,R&S已经具备了相当完整的内核功能,而作为纯内核研究的 R&S项目也走到了尽头,凤凰涅磐,一个新的名字RS-RTOS将延续R&S的血脉,原R&S被正式定名为RS-KERNEL,而RS-RTOS也承载更高更广阔的目标…这个目标将由我们的组织RSGuru、由所有有执着追求,热爱生活的朋友共同完成。

RS-RTOS内容

RS -RTOS是一个工业级嵌入式操作系统计划,包含RS-KERNEL(内核),RS-NET(网络),RS-GUI(图形),RS-FS(文件系统), RS-DRIVER(驱动)几个模块,与面向消费电子嵌入式操作系统不同,RS-RTOS面向工业,汽车等对实时性,稳定性,剪裁能力,功耗要求严格的应用领域。RS-RTOS是一个深度嵌入式操作系统,要求RS-RTOS具备灵活的架构,优秀的裁减能力,以适应多变的应用环境,因而RS-RTOS比通用和消费类嵌入式操作更具挑战性,其困难不是来自于代码规模,而是代码实现的效率,结构的重用性,组件抽象,切分能力,RS-RTOS核心模块RS- KERNEL已经在这些方面上做了深入细致的工作,为RS-RTOS奠定了基础。目前,RS-RTOS将开展的以下几个研究方向:

  • 移植,驱动
  • NET网络系统
  • GUI图形系统
  • FS文件系统
  • 文档,应用平台


RS-RTOS特性

RS-KERNEL:

  1. 最大支持255个任务管理,可以满足绝大多数应用需要;
  2. 基于占先式任务调度,具备强实时性特点;
  3. 所有内核函数调用与服务执行的时间是确定的;
  4. 内核层次清晰,可移植性非常强;
  5. 高度可裁剪特性,最小配置目标系统大小在1KB左右;
  6. 精简的内核结构,占用非常少的硬件资源,RAM占用几十字节~500KB;
  7. 针对处理器位宽与配置,生成经过精心优化的代码,代码效率高,运行平稳流畅;
  8. 提供丰富的系统服务,包括中断管理、定时器、信号量、互斥锁、邮箱、事件、消息队列、内存管理、设备管理等。

RT-Thread

http://www.rt-thread.com/

RT-Thread是延续DOOLOO RTOS的下一代微内核嵌入式实时操作系统,被设计成一个宽范围可用的系统:从资源极度紧张的小型系统,到一个带内存管理单元,网络功能的基本计算单元。
内核大小 < 32k,256优先级调度算法,以线程为单位进行调度;支持semaphore,mutex,event/fast event,mailbox,messagequeue,timer等内核对象;实时内核中的对象操作都是时间可预计的(除了event)


当前支持ARM(lumit4510开发板,skyeye)
代码遵循GPL许可证,可以在Google Group中获得:
http://groups.google.com/group/rtthread

SGOS
(Simple Graphic Operating System for PC)

http://sgos.xxsyzx.com


SGOS是一个运行于PC上的多任务图形操作系统,
最近已经开始了GUI开发计划

作者叫黄冠,他是这样介绍自己和这个操作系统项目的:

“我是一名高中生,但也是一名程序员。大约在一年前,我也搞起了对OS的研究,并且编写了一个很小型的hello world在裸机上运行之后,我便很开心,认为一切原来是这么简单,就决心去开发一个国产的操作系统。

2006年4月,我生日那天,在日记本里写下了2006年计划,主要是编写一个32位多任务操作系统,并且可以运行简单的程序。一直一来,我碰到过很多问题,甚至是我一窍不通的硬件问题,但经过不断四方搜索资料,终于也给解决了。我没想到会那么快,到了今天,已经做成了一个具备基本功能的操作系统内核,支持fat文件系统,支持内存分页,支持多进程并发执行,支持图形显示,更可喜的是,能够运行Windows上编译的dll和exe文件。为此,我的目标已经定了下来,我很有自信地说:”我要打造一个兼容Win32的国产操作系统!”

由于我是一个出生在贫困山区的孩子,很多时候得不到自己想要的一些东西,而且几乎什么都靠自己去争取。我能所用的,也只有身前的这台Pentium III的机子。但我感觉到,感觉到我有能力可以克服许多困难。

2007年,这是我的系统SGOS(Simple Graphic Operating System for PC)发展的黄金时期。在这年,我的目标是:完成GDI、GUI、Network,移植c标准库,移植gnu的编译器,最后做成一个简单的桌面。估计2008年的计划是逐步兼容Win32的应用程序了。”


这是“启明OS”的一个前期版本。启明OS的目标太大所以就现写了这个。它是一个实模式的操作系统模型。具有内存管理、一个小小的shell、不完整的文件系统和图形界面系统。以后的版本会更加的完善一些。


Tinix

http://blog.csdn.net/forrestyu/
http://blog.sina.com.cn/u/1210311393
http://forrestyu.bokee.com/1725196.html

Tinix是随于渊所著的《自己动手写操作系统》这本书中所附带的一个实验教学性质的操作系统。这本书讲述了很多其他操作系统书所不讲述的实际操作的问题。Tinix并不是一个完善的系统,仅仅是为了配合这本书的讲述,而写成的系统。

ISBN: 7-121-01577-3

unixlite

http://gro.clinux.org/projects/unixlite/
http://www.unixlite.org/

一个用C++写成的轻量级操作系统

Httpd on UnixLite

UnixLite is a lightweight unix/linux compatible operating system written in c++, it is open source and released under the GNU General Public License.The complete operating system is made up of kernel and applications, just like linux, unixlite is only the kernel. The kernel itself is written from scratch and the most part is written in c++, however, the library used by unixlite comes from uClibc and applicaitons running on unixlite comes from GNU project.

UnixLite kernel implements some frequently used system calls of linux, furthermore, it is binary compatible with linux, and some GNU software have been ported to unixlite.

Currently, the objective of the unixlite project is to design and to implement a small UNIX based architecture operating system for educational purposes. In the future, unixlite maybe targeted at soft-realtime embedded systems. The advantage to have a small but complete UNIX-like operating system, accompanied by a detailed documentation, can as much be a great benefit for students and programmers who want to know how an operating system works.

Compared with the famous educational operating system—Minix, the major difference between unixlite and minix lies in that unixlite support paging while minix not.

Due to the small size(the kernel is made up of about 20000 lines of code) and the object oriented programming using the c++, the kernel becomes more modular and easy to understand. We hope those who are interested in the internals of unix/linux kernel find this site to be of value. We have spent a lot of time on it. If a few people find the site to be useful, our efforts will have been rewarded.

WarmOS

http://www.xujiwei.cn/warmos/

WarmOS是一个用汇编编写的16位实模式操作系统,它包括了一些操作系统应该拥有的基本功
能,支持COM格式文件的执行,提供了一些系统API以供程序员编写程序,并且从内核支持中文
的显示。

目前WarmOS的最新版本为:0.6

by HotHeart
网站:http://www.xujiwei.cn
邮件:vipxjw [at] 163 [.] com

 WYOS

http://www.wyos.net/

这是一个32位的操作系统。它基于x86处理器,运行在保护模式下,采用纯分页的内存管理方式,支持多任务,并支持进程间通讯。支持3.5″软盘、IDE/ATA磁盘、FAT文件系统、PCI设备和其它外设。
该系统开放源代码,在下载中心可以下载全部源代码。

内存管理模块

内存管理采用了纯分页的管理模式。使用队列管理内存的使用和物理内存。分为内核和用户进程两个层次去管理内存的使用。

进程管理模块

采用抢占式多级反馈队列法(我自定的^_^,多级反馈队列和抢占式结合)的调度算法,调度基于x86的硬件调度。提供进程4G独立虚拟空间。支持进程间消息通讯。并预留了事件和互斥量(主要是因为时间问题暂时未实现。)两种进程通讯方式。线程暂时未实现,但是也预留了。

磁盘驱动

正在编写软盘驱动,将来会添加IDE/ATA磁盘驱动。但是会在PCI总线驱动程序完成之后。因为目前IDE/ATA控制器都是基于PCI总线的,虽然兼容ISA总线,但是对于DMA的传输很不方便。
扇区读写算法采用电梯算法。

文件系统

将支持FAT12和FAT32文件系统,在软盘驱动完成后,会紧跟着去实现FAT12。FAT32会在IDE/ATA磁盘驱动完成之后实现。

PCI总线驱动程序

这个驱动并不是很复杂,根据PCI规范来就行了。

输入设备驱动

支持P/S2键盘,有时间会将鼠标也添加进去。

 

色标: [新加系统项目][稍早前加入的项目]


 

操作系统研究组列表

 

 

研究小组名称/研究者名称

备注

操作系统研究小组

http://www.douban.com/group/OperatingSystem/

 

系统计算研究所

http://www.xtrj.org

 

系统地带 OS Zone

http://www.xemean.net/

  “不知道如何来形容这个网站以及我参与的项目,本站从2004年初(农历2003年底)至今,已经一年的光景;网站建设的最初目的是为了建立一个相对全面的操作系统开发资料、开发爱好者交流的平台,因为我发现国内在操作系统开发方面并不很积极,而且要找一个资料比较集中的网站也很困难,能找到的大多数是一些个人主页气息比较浓的站点,我的这个网站希望各位看官及志同道合者能够满意。
一年来,网站得到了很多朋友的好评,本人在此表示感谢;当然,本站存在的不足之处还请各位指教。网站的再次改版权衡了汇编与其它高级语言的比重,比上一个版本有更多的开发资源;网站运行期间,很多朋友给我邮件,给我不少的意见和建议,同时也有一些朋友把自己的资料及翻译文件放到小站上,极大地丰富了本站;各种原因,网站更新速度很慢,还请见谅。
通过网站我大概了解到了国内操作系统开发的情况,是令人乐观的,网站内登记的项目也一直在增加,这些项目不乏优秀之作;但是也有一些项目不存在或者是已经停止开发了,当然,一件事情是由很多因素制约的,这一点希望大家能理解。到小站做客的朋友估计很多是冲着MenuetOS而来,或者从MenuetOS得知本站,很有意思的一点是:很多朋友喜欢我的网页设计风格及版式,而没有多少开发者,有时候我也觉得自己是做网站的而不是写程序的。
开发操作系统可能是为了流芳百世,或者仅只是个人兴趣,为学习计算机底层开发及操作系统原理;不是很难,当然也不容易,贵在坚持。
2005年3月31日本站第二版完成。
谨以此献给所有的操作系统开发爱好者。”

 

 


 

鸣谢

感谢各位朋友提供的华人操作系统项目的信息。可能列出的名字不全,那是我的失误,如果有谁发现缺失了自己,请告知,我会立即补充进去。但是,我对那些列出的和没有列出的朋友都是一样的尊重和感谢。没有大家的支持,我不可能将我的列表完善的。谢谢大家。

Errorter for Hiweed Linux

rocket for elastos 和欣操作系统

writeos for writeos

wkz for OSZone

2949562 for PowerOS 2002

NetMiner for FairySky

tanphei for Kingmos

outwater for Lava-X OS

Bernard Xiong for DeltaOS, DOOLOO RTOS, RT-Thread

Lightning for JK (Just the Kernel)

JamesR for Everest

ted for RS-RTOS

WY.lslrt for WYOS

老齐 for GOS

lalatop for Beans’ Operating System

OS-Z for 指尖操作系统

Jserv for Orz microkernel

 | 147 views | 0 comments | 0 flags | 

分布式计算泛型

http://www.kuqin.com/shuoit/20160331/351425.html

 

泛型定义为一种模式例子或模型。今天和大家共同学习一下分布式计算泛型,分布式计算泛型总共可划分为五大类共九种常见泛型,接下来一一介绍。

一、消息相关

消息相关的泛型包括消息传递泛型和消息系统泛型。

1.消息传递泛型

消息传递是进程之间互相通信的基本途径。两个进程间传递消息,一个为发送者,一个为接收者。发送者发送一条请求消息,该消息被传送到接收者,由接收着处理后返回一条应答消息。

2.消息系统泛型

消息系统泛型或面向对象的中间件(MOM)是在基本的消息传递泛型的基础上扩展来的。该消息系统可以理解成独立与进程间的中介,这样两个互相通信的进程之间就没有了请耦合关系。由发送者发送一条消息,消息被存入消息系统,然后由消息系统转发的对应的接收者,发送者一旦将消息发送出去,就可以执行其他任务了,剩下的转发工作有消息系统完成。

消息系统泛型可以进一步划分为两种子类型:点对点消息泛型和发布/订阅消息泛型。

1)点对点消息泛型

这种泛型是发送者和接收者一一对应的泛型,由发送者发送一条消息到消息系统,消息系统再转发到接收者的消息队列中,消息系统可以提供暂存机制,将消息的发送和接收分离。接收者从自己的消息队列中提取消息,然后加以处理。

2)发布/订阅消息泛型

这种泛型是多对多的泛型,多个订阅者可以有多个订阅,由发送者发送一条消息到消息系统,消息系统根据订阅者的订阅类型和消息类型将该消息转发到每一个订阅该类型消息的订阅者。这种泛型可以提供一个进程向一组进程组播消息。

二、服务器相关

服务器相关的泛型包括客户/服务器泛型和P2P泛型。

3.客户/服务器泛型

客户/服务器泛型由客户端和服务器组成,将非对称角色分配各两个协作进程,客户进程向服务器发起请求,并等待服务器响应,服务器等待来自客户的请求,处理并给出回应。

4.P2P泛型

P2P泛型源于P2P网络(又称为对等计算机网络)。这是一种无中心服务器,依赖用户群交换的互联网体系,每个用户既是一个节点,又充当服务器职责。可以说是没有服务器,也可以说每个用户端都是一台服务器。

三、远程调用相关

远程调用相关的泛型包括远程过程调用泛型、分布式对象泛型和网络服务泛型。

5.远程过程调用泛型

提供了一种能使开发人员可以像编写在单处理器上运行的传统应用程序一样,编写分布式软件系统的泛型。可以采用与本地过程调用类似的思想与概念,以进行进程间通信。

6.分布式对象泛型

分布式对象泛型将面向对象应用到分布式系统中,是面向对象软件开发技术的自然扩展。可以使应用程序访问分布于网络上的各个对象,通过调用对象的方法,应用层序可以获取对服务的访问。

1)远程方法调用

远程方法调用(RMI)是面向对象版本的RPC。进程可以调用对象方法,该对象可以驻留于某远程主机中。

2)对象请求代理

对象请求代理泛型有对象请求者、对象提供者和对象请求代理组成。进程向对象请求代理发出请求,对象请求代理将请求转发到能提供预期服务的对象。

7.网络服务泛型

网络服务泛型有服务请求者、服务提供者(对象)和目录服务三者组成。首先服务提供者将自身注册到网络上的目录服务器上,当服务请求者需要访问服务时,直接与服务器目录联系,如果请求的服务可用,则由目录服务器返回一个该服务的引用或地址,进程利用该引用与所需的服务进行交互。

四、移动代理

8.移动代理泛型

移动代理泛型是一种可移动的程序或对象。一个代理从源主机出发,然后根据其自身携带的执行路线,自动地在网上主机间移动。在每一台主机上代理访问所需的资源或服务,并执行必要的任务来完成使命。

五、云服务

9.云服务泛型

美国国家标准与技术研究院定义了云计算的三种服务模型:IaaS、PaaS和SaaS。

1)基础实施即服务(IaaS)

以服务的形式提供虚拟硬件资源、用户无需购买服务器、网络设备、存储设备,只需通过互联网租赁即可搭建自己的应用系统。

2)平台即服务(PaaS)

提供应用服务引擎,如互联网应用编程接口、运行平台等。用户基于该应用服务引擎可以构建该类应用。

3)软件即服务(SaaS)

用户通过Internet来使用软件,用户不必购买软件,只需按需租赁软件。

 | 116 views | 0 comments | 0 flags | 

操作系统安全规划

•信息安全
–OS所处理的信息不泄漏,表现在信息的处理、存储、传输等过程中
•设备安全
–设备丢失,设备意外连非安全设备,如插入未经授权的SD卡,则不可将信息从安全处复制到非安全处
•计算安全
–当发生程序出错是,导向安全策略,如删除中间计算结果
–基于构件技术,契约式编程,提高计算可靠性
•安全协作
–多个设备间的协作时,产生了分布式计算行为,保证其安全策略的完整性
•安全审计
–对发生的多事件合并得到的信息,如一个访问可得到A,就不可得到B等行为进行动态审计

 | 55 views | 0 comments | 0 flags | 

【转】程序员的鄙视链

http://bbs.csdn.net/topics/391917105

近这几年在世界各地突然吹起了一股全民写程序的风潮,连美国总统欧巴马都在写 JavaScript 了(主页君插播《奥巴马成为首位写程序的美国总统》、《除了奥巴马,巴西总统也写代码》),但是身为一介靠写程序(以及在上班时间胡乱上网)来谋生的 developer(所谓的 developer 就是「软件工程师」的比较潮的说法),想要提醒那些想学习写程序的人一件重要的事:慎选你的第一个程序语言。

在软件工程师(中国叫做「程序员」或「码农」)的圈子里,文人相轻的现象可是非常严重的,在程序设计的各个领域里都有着错综复杂的「鄙视链」。从程序语言、编辑器、平台到 { 是写在 if 的同一行还是下一行,不同阵营的人都习惯鄙视来鄙视去。而其中「你用什么程序语言?」更是大家最热衷的一条鄙视链,所以对于刚踏入程序设计领域的初学者来说,万一程序语言选得不好,可是会一开始就落入鄙视链的底层啊。

软件工程师的鄙视链到底有多惨烈、多残酷呢?

程序语言篇

懂 Functional Programming 的工程师鄙视老是把设计模式挂在嘴边的工程师,老是把设计模式挂在嘴边的工程师鄙视会说「你这样写就不 OO 了啊」的工程师,会说「你这样写就不 OO 了啊」的工程师鄙视会说「蛤?什么面向对象?不是把重复的 code 写成一个 function 就好了吗?」的工程师,会说「蛤?什么面向对象?不是把重复的 code 写成一个 function 就好了吗?」的工程师鄙视把同一段 code 到处复制贴上的工程师,把同一段 code 到处复制贴上的工程师鄙视 PM。

写静态语言的工程师鄙视写动态语言的工程师。

写汇编语言的工程师鄙视写 C 语言的工程师,C 语言工程师鄙视 C++ 工程师,C++ 工程师鄙视 Java 和 C# 工程师,Java 工程师和 C# 工程师则互相鄙视,而 C# 工程师又鄙视 Visual Basic 工程师和会把 C# 念成「C 井」的工程师,会把 C# 念成「C 井」的工程师则鄙视认为 HTML 是一种程序语言的设计师。

用 Python 3 的工程师鄙视还在用 Python 2 的工程师,用 Python 2 的工程师鄙视遇到 UnicodeEncodeError 的工程师。

写 iOS 的工程师鄙视写 Android 的工程师,写 Android 的工程师鄙视写 Windows Phone 的工程师。

有 Swift 一年经验的工程师鄙视有 Objective-C 五年经验的工程师,写 Objective-C 的工程师鄙视用 PhoneGap 包装成 native app 的工程师。

用 React.js 的工程师鄙视用 AngularJS 的工程师,用 AngularJS 的工程师鄙视用 jQuery 的工程师,用 jQuery 的工程师鄙视用 Vanilla JavaScript 的工程师,用 Vanilla JavaScript 的工程师鄙视 IE 的用户。

会用 debugger 的工程师鄙视用 assert 的工程师,用 assert 的工程师鄙视只会 print() 的工程师;用 console.log() 来 debug 的工程师鄙视用 alert() 来 debug 的工程师。

写 Ruby on Rails 的工程师鄙视所有使用其他语言的工程师。

什么?你说 Ruby?Ruby 只是 Ruby on Rails 的一套框架,才不是什么程序语言呢!

所有的工程师都鄙视 PHP 工程师。

工具篇

用 text editor 的工程师鄙视用 IDE 的工程师。

用 Vim 的工程师鄙视用 Emacs 的工程师,用 Emacs 的工程师鄙视用 Vim 的工程师,无论是用 Vim 或 Emacs 的工程师都鄙视所有用其他编辑器的工程师;用 Atom、Notepad++、Sublime Text 的工程师鄙视用 Windows 记事本的工程师。

用 Android Studio 或 IntelliJ IDEA 的工程师鄙视用 Eclipse 的工程师,用 Eclipse 的工程师鄙视用 NetBeans 的工程师。

程序代码用 space 缩排的工程师鄙视用 tab 缩排的工程师,用 tab 缩排的工程师鄙视混用 space 和 tab 来缩排的工程师。

用 Git 或 Mercurial 的工程师鄙视用 Subversion 的工程师,用 Subversion 的工程师鄙视用 Dropbox 来做版本控制的工程师,用 Dropbox 来做版本控制的工程师鄙视根本不知道什么叫做版本控制的工程师。

知道 GitHub 的工程师鄙视不知道 GitHub 的工程师;在 GitHub 有 private repo 的工程师鄙视为了免费的 private repo 而去用 BitBucket 的工程师。

用 Zsh 的工程师鄙视用 Bash 的工程师,用 Bash 的工程师鄙视用 Cygwin 的工程师,用 Cygwin 的工程师鄙视用「命令提示字符」的工程师,用命令提示字符的工程师鄙视用 GUI 接口的工程师。

用 IRC 的工程师鄙视用 HipChat 的工程师,用 HipChat 的工程师鄙视用 Slack 的设计师和 PM。

用 reStructuredText 写文件的工程师鄙视用 Markdown 写文件的工程师,用 Markdown 写文件的工程师鄙视用 HTML 写文件的工程师,用 HTML 写文件的工程师鄙视不写文件的工程师,然后用 LaTeX 写文件的工程师鄙视所有工程师。

用 Nginx 的工程师鄙视用 Apache 的工程师,用 Apache 的工程师鄙视用 IIS 的工程师。

用 Spark 的工程师鄙视用 Hadoop 的工程师,用 Hadoop 的工程师鄙视用 Hadoop 处理只有几 GB 数据的工程师,用 Hadoop 处理只有 1GB 数据的工程师鄙视用 NoSQL 的工程师,用 NoSQL 的工程师鄙视用关系数据库的工程师,用关系数据库的工程师鄙视用 Excel 的 PM。

用 Docker 来部署 server 的工程师鄙视用 Ansible 或 Puppet 来部署 server 的工程师,用 Ansible 或 Puppet 来部署 server 的工程师鄙视用 Fabric 来部署 server 的工程师,用 Fabric 来部署 server 的工程师鄙视手动 SSH 的工程师。

OS 篇

用 Mac OS X 的工程师鄙视用 Linux 的工程师,用 Linux 的工程师鄙视用 Windows 的工程师。

用 Debian 的工程师瞧不起用 Ubuntu 的工程师,用 Ubuntu 的工程师瞧不起用非 LTS 版本的 Ubuntu 的工程师。

硬件篇

用 MacBook Pro Retina 的工程师鄙视用 MacBook Air 的工程师,用 MacBook Air 的工程师鄙视用 ThinkPad 的工程师,然后用 Raspberry Pi 的工程师鄙视用 MacBook Pro Retina 的工程师。

用 Dvorak 键盘的工程师鄙视用 Mac 键盘的工程师,用 Mac 键盘的工程师鄙视用 QWERTY 键盘的工程师,用 QWERTY 键盘的工程师鄙视鄙视不知道 QWERTY 键盘是什么的工程师,不知道 QWERTY 键盘是什么的工程师鄙视用手写板的设计师。

坐 Aeron 椅子的工程师鄙视坐普通办公椅的工程师,坐普通办公椅的工程师鄙视跟他一样做普通办公椅的 PM,然后站着写程序的工程师鄙视坐 Aeron 椅子的工程师。

职场篇

搞硬件的工程师鄙视搞软件的工程师。

写 OS 的工程师鄙视写 Web 的工程师,写 Web 的工程师鄙视写 desktop application 的工程师。

后端工程师鄙视前端工程师。

工程师跟设计师互相鄙视。

信奉 Test-Driven Development 的工程师鄙视先写 code 再补 tests 的工程师,先写 code 再补 tests 的工程师鄙视不写 tests 的工程师,不写 tests 的工程师鄙视又他妈乱改需求的 PM。

没有证照的工程师鄙视考了一堆证照的工程师。

上班穿休闲服的工程师鄙视上班穿西装的工程师,上班穿西装的工程师鄙视上班穿系服的工程师。

如果你看了以上这些惨绝人寰的鄙视链之后,仍然没有击倒你想要学习 coding 的心,那我必须提醒你一件最重要的事:先去交一个女朋友,再来学写程序;因为一旦你成为软件工程师之后,就交不到女朋友了。

 | 70 views | 0 comments | 0 flags | 

Linux容器演变历程与未来发展前景

http://cloud.51cto.com/art/201602/505113.htm

 

Linux容器作为一类操作系统层面的虚拟化技术成果,旨在立足于单一Linux主机交付多套隔离性Linux环境。与虚拟机不同,容器系统并不需要运行特定的访客操作系统。相反,容器共享同一套主机操作系统内核,同时利用访客操作系统的系统库以交付必要的系统功能。由于无需借助于专门的操作系统,因此容器在启动速度上要远远优于虚拟机。

图片来源:Docker有限公司

容器能够利用Namespaces、Apparmor、SELinux配置、chroot以及CGroups等Linux内核功能,从而交付一套类似于虚拟机的隔离性环境。Linux安全模块能够确保来自容器的主机设备与内核访问行为受到妥善管理,从而避免入侵活动的发生。除此之外,容器还能够通过其主机操作系统运行多种不同Linux发行版——只要各类操作系统拥有同样的底层CPU架构要求。

总体而言,容器技术提供了一种立足于各类Linux发行版的容器镜像创建方式,同时利用API进行容器生命周期管理,通过客户端工具实现与该API的交互,进而提供快照以及不同容器主机之间容器实例迁移等能力。

容器技术发展历程

以下为从维基百科以及其它信息源处收集到的容器发展历程总结:

1979年 — chroot

容器技术的概念可以追溯到1979年的UNIX chroot。这是一套“UNIX操作系统”系统,旨在将其root目录及其它子目录变更至文件系统内的新位置,且只接受特定进程的访问。这项功能的设计目的在于为每个进程提供一套隔离化磁盘空间。1982年其被添加至BSD当中。

2000年 — FreeBSD Jails

FreeBSD Jails是由Derrick T. Woolworth于2000年在FreeBSD研发协会中构建而成的早期容器技术之一。这是一套“操作系统”系统,与chroot的定位类似,不过其中包含有其它进程沙箱机制以对文件系统、用户及网络等资源进行隔离。通过这种方式,它能够为每个Jail、定制化软件安装包乃至配置方案等提供一个对应的IP地址。

2001年 — Linux VServer

Linux VServer属于另一种jail机制,其能够被用于保护计算机系统之上各分区资源的安全(包括文件系统、CPU时间、网络地址以及内存等)。每个分区被称为一套安全背景(security context),而其中的虚拟化系统则被称为一套虚拟私有服务器。

2004年 — Solaris容器

Solaris容器诞生之时面向x86与SPARC系统架构,其最初亮相于2004年2月的Solaris 10 Build 51 beta当中,随后于2005年正式登陆Solaris 10的完整版本。Solaris容器相当于将系统资源控制与由分区提供的边界加以结合。各分区立足于单一操作系统实例之内以完全隔离的虚拟服务器形式运行。

2005年 — OpenVZ

OpenVZ与Solaris容器非常相似,且使用安装有补丁的Linux内核以实现虚拟化、隔离能力、资源管理以及检查点交付。每套OpenVZ容器拥有一套隔离化文件系统、用户与用户群组、一套进程树、网络、设备以及IPC对象。

2006年 — Process容器

Process容器于2006年由谷歌公司推出,旨在对一整套进程集合中的资源使用量(包括CPU、内存、磁盘I/O以及网络等等)加以限制、分配与隔离。此后其被更名为Control Groups(即控制组),从而避免其中的“容器”字眼与Linux内核2.6.24中的另一术语出现冲突。这表明了谷歌公司率先重视容器技术的敏锐眼光以及为其做出的突出贡献。

2007年 — Control Groups

正如上文所提及,Control Groups也就是谷歌实现的cgroups,其于2007年被添加至Linux内核当中。

2008年 — LXC

LXC指代的是Linux Containers,其也是第一套完整的Linux容器管理实现方案。其功能通过cgroups以及Linux namespaces实现。LXC通过liblxc库进行交付,并提供可与Python3、Python2、Lua、Go、Ruby以及Haskell等语言相对接的API。相较于其它容器技术,LXC能够在无需任何额外补丁的前提下运行在原版Linux内核之上。目前LXC项目由Canonical有限公司负责赞助及托管。

2011年 — Warden

Warden由CloudFoundry公司于2011年所建立,其利用LXC作为初始阶段,随后又将其替换为自家实现方案。与LXC不同,Warden并不会与Linux紧密耦合。相反,其能够运行在任意能够提供多种隔离环境方式的操作系统之上。Warden以后台进程方式运行并提供API以实现容器管理。感兴趣的朋友可以点击此处与此处了解更多与Warden相关的细节信息(英文原文)。

2013年 — LMCTFY

Lmctfy代表的是“Let Me Contain That For You(帮你实现容器化)”。它其实属于谷歌容器技术堆栈的开源版本,负责提供Linux应用程序容器。谷歌公司在该项目的起步阶段宣称其能够提供值得信赖的性能表现、高资源利用率、共享资源机制、充裕的发展空间以及趋近于零的额外资源消耗。Kubernetes目前所使用的cAdvisor工具最初就来源于lmctfy项目。2013年10月lmctfy的首个版本正式推出,谷歌公司在2015年决定将lmctfy的核心概念与抽象机制转化为libcontainer。在失去了主干之后,如今lmctfy已经失去一切积极的发展势头。

Libcontainer项目最初由Docker公司建立,如今已经被归入开放容器基金会的管辖范畴。

2013年 — Docker

截至2016年1月,Docker是目前最具人气且应用最为广泛的容器管理系统。Docker项目最初是由一家名为dotCloud的平台即服务厂商所打造,其后该公司更名为Docker。与Warden类似,Docker同样在起步阶段使用LXC,而后利用自己的libcontainer库将其替换下来。与其它容器平台不同,Docker引入了一整套与容器管理相关的生态系统。其中包括一套高效的分层式容器镜像模型、一套全局及本地容器注册表、一个精简化REST API以及一套命令行界面等等。在后期发展阶段,Docker公司还构建起一套名为Docker Swarm的容器集群管理解决方案。

2014年 — Rocket

Rocket最初由CoreOS开发而成,专门用于解决部分Docker当中存在的缺陷。CoreOS方面也提到,他们当初的开发目标是在安全性与生产要求满足能力上超越Docker。更重要的是,其基于App Container规范并使其成为一项更为开放的标准。除了Rocket之外,CoreOS还开发出了多种其它与容器相关的产品,且已经被Docker与Kubernetes所使用:CoreOS操作系统、etcd以及flannel。

2016年 — Windows容器

微软公司也已经于2015年采取初步举措,希望将容器支持能力添加到微软Windows Server操作系统当中,而这项旨在帮助Windows应用实现容器化的项目被称为Windows容器(Windows Containers)。其即将随微软的Windows Server 2016一同推出。在这硕方案当中,Docker能够以原生方式在Windows平台上运行容器,而无需运行虚拟机或者多层Docker(早期Docker需要利用Linux虚拟机才能与Windows系统相对接)。

容器之发展愿景

截至目前(2016年1月),整个技术行业已经越来越多地将软件应用程序部署基础由虚拟机转移向容器。之所以出现这种趋势,一大重要原因在于容器能够提供远优于虚拟机的灵活性与使用成本。谷歌公司多年来一直在利用Borg and Omega容器集群管理平台等容器技术以实现各类谷歌应用的规模化运行。更重要的是,谷歌公司还通过实现cgroups以及参与libcontainer项目等方式为容器技术的发展做出了突出贡献。谷歌方面在过去几年当中已经利用容器技术实现了可观的性能提升、资源利用率改善以及整体执行效率优化。就在最近,微软公司这位从未将任何操作系统层级虚拟化机制引入Windows平台的软件巨头亦快速在Windows Server上实现了原生容器支持能力。

Docker、Rocket以及其它容器平台都无法运行在生产环境中的单一主机之上,这是因为它们都存在着单点故障隐患。尽管一整套容器集合能够运行在单一主机上,然而一旦该主机发生故障,所有运行于其上的容器也将全面瘫痪。谷歌公司在这方面抢先一步,凭借从Borg项目中积累到的经验打造出名为Kubernetes的开源容器集群管理系统。Docker公司也针对这一难题开发出了Docker Swarm解决方案。目前,这些解决方案尚处于早期发展阶段,而且可能还需要数月甚至一年才能真正具备完整的功能集,从而以稳定及广泛的方式被引入容器行业的生产环境当中。

微服务则是另一项突破性技术成果,而不仅仅是一套利用容器机制实现自身部署的软件架构。虽然微服务的概念算不上什么新鲜事物,但这种Web服务的轻量化实现机制确实能够提供远超过标准Web服务的启动速度。之所以能够实现这项目标,是因为其将一整套功能单元以打包方式(可能包括单一服务/API方法)整合在一项服务当中,再将服务嵌入一套轻量化Web服务器二进制文件。

考虑到以上背景信息,我们可以预测在未来几年当中,容器技术将逐步取代虚拟机甚至能够在一定程度上彻底占据其适用环境。去年,我曾经帮助多家企业立足于POC层级部署基于容器的解决方案。当时他们几乎还都不想把容器引入生产环境。然而这种状况可能随着容器集群管理系统的逐步成熟而快速得到扭转。

原文标题:The History of Linux Containers from chroot to the Future

【51CTO.com独家译稿,合作站点转载请注明来源】

 | 212 views | 0 comments | 0 flags | 

计算机科学中的最严重错误,造成十亿美元损失

http://blog.jobbole.com/93667/

在 1965 年有人提出了这个计算机科学中最糟糕的错误,该错误比 Windows 的反斜线更加丑陋、比 === 更加怪异、比 PHP 更加常见、比 CORS 更加不幸、比 Java 泛型更加令人失望、比 XMLHttpRequest 更加反复无常、比 C 预处理器更加难以理解、比 MongoDB 更加容易出现碎片问题、比 UTF-16 更加令人遗憾。

“我把 Null 引用称为自己的十亿美元错误。它的发明是在1965 年,那时我用一个面向对象语言( ALGOL W )设计了第一个全面的引用类型系统。我的目的是确保所有引用的使用都是绝对安全的,编译器会自动进行检查。但是我未能抵御住诱惑,加入了Null引用,仅仅是因为实现起来非常容易。它导致了数不清的错误、漏洞和系统崩溃,可能在之后 40 年中造成了十亿美元的损失。近年来,大家开始使用各种程序分析程序,比如微软的 PREfix 和 PREfast 来检查引用,如果存在为非 Null 的风险时就提出警告。更新的程序设计语言比如 Spec# 已经引入了非 Null 引用的声明。这正是我在1965年拒绝的解决方案。” —— 《Null References: The Billion Dollar Mistake》托尼·霍尔(Tony Hoare),图灵奖得主

为纪念 Hoare 先生的 null 错误五十周年,这篇文章将会解释何为 null、为什么它这么可怕以及如何避免。

NULL 怎么了?

简单来说:NULL 是一个不是值的值。那么问题来了。

这个问题已经在有史以来最流行的语言中恶化,而它现在有很多名字:NULL、nil、null、None、Nothing、Nil 和 nullptr。每种语言都有自己的细微差别。

NULL 导致的问题,有一些只涉及某种特定的语言,而另一些则是普遍存在的;少量只是某个问题的不同方面。

NULL…

  1. 颠覆类型
  2. 是凌乱的
  3. 是一个特例
  4. 使 API 变得糟糕
  5. 使错误的语言决策更加恶化
  6. 难以调试
  7. 是不可组合的

1. NULL 颠覆类型

静态类型语言不需要实际去执行程序,就可以检查程序中类型的使用,并且提供一定的程序行为保证。

例如,在 Java 中,如果我编写 x.toUppercase(),编译器会检查 x 的类型。如果 x 是一个String,那么类型检查成功;如果 x 是一个 Socket,那么类型检查失败。

在编写庞大的、复杂的软件时,静态类型检查是一个强大的工具。但是对于 Java,这些很棒的编译时检查存在一个致命缺陷:任何引用都可以是 null,而调用一个 null 对象的方法会产生一个 NullPointerException。所以,

  • toUppercase() 可以被任意 String 对象调用。除非 String 是 null。
  • read() 可以被任意 InputStream 对象调用。除非 InputStream 是 null。
  • toString() 可以被任意 Object 对象调用。除非 Object 是 null。

Java 不是唯一引起这个问题的语言;很多其它的类型系统也有同样的缺点,当然包括 AGOL W 语言。

在这些语言中,NULL 超出了类型检查的范围。它悄悄地越过类型检查,等待运行时,最后一下子释放出一大批错误。NULL 什么也不是,同时又什么都是。

2. NULL 是凌乱的

在很多情况下 null 是没有意义的。不幸的是,如果一种语言允许任何东西为 null,好吧,那么任何东西都可以是 null。

Java 程序员冒着患腕管综合症的风险写下

1
2
if (str == null || str.equals("")) {
}

而在 C# 中添加 String.IsNullOrEmpty 是一个常见的语法

1
2
if (string.IsNullOrEmpty(str)) {
}

真可恶!

每次你写代码,将 null 字符串和空字符串混为一谈时,Guava 团队都要哭了。– Google Guava

说得好。但是当你的类型系统(例如,Java 或者 C#)到处都允许 NULL 时,你就不能可靠地排除 NULL 的可能性,并且不可避免的会在某个地方混淆。

null 无处不在的可能性造成了这样一个问题,Java 8 添加了 @NonNull 标注,尝试着在它的类型系统中以追溯方式解决这个缺陷。

3. NULL 是一个特例

考虑到 NULL 不是一个值却又起到一个值的作用,NULL 自然地成为各种特别处理方法的课题。

指针

例如,请看下面的 C++ 代码:

1
2
3
char c = 'A';
char *myChar = &c;
std::cout << *myChar << std::endl;

myChar 是一个 char *,意味着它是一个指针——即,将一个内存地址保存到一个 char中。编译器会对此进行检验。因此,下面的代码是无效的:

1
2
char *myChar = 123; // compile error
std::cout << *myChar << std::endl;

因为 123 不保证是一个 char 的地址,所以编译失败。无论如何,如果我们将数字改为0(在 C++ 中 0 是 NULL),那么可以编译通过:

1
2
char *myChar = 0;
std::cout << *myChar << std::endl; // runtime error

和 123 一样,NULL 实际上不是一个 char 的地址。但是这次编译器还是允许它编译通过,因为 0(NULL)是一个特例。

字符串

还有另一个特例,即发生在 C 语言中以 NULL 结尾的字符串。这与其它的例子有点不同,因为这里没有指针或者引用。但是不是一个值却又起到一个值的作用这个思想还在,此处以不是一个 char 却起到一个 char 的形式存在。

一个 C 字符串是一连串的字节,并且以 NUL (0) 字节结尾。

C-string

因此,C 字符串的每个字符可以是 256 个字节中的任意一个,除了 0(即 NUL 字符)。这不仅使得字符串长度成为一个线性时间的运算;甚至更糟糕,它意味着 C 字符串不能用于 ASCII 或者扩展的 ASCII。相反,它们只能用于不常用的 ASCIIZ。

单个 NUL 字符的例外已经导致无数的错误:API 的怪异行为、安全漏洞和缓冲区溢出。

NULL 是 C 字符串中最糟糕的错误;更确切地说,以 NUL 结尾的字符串是最昂贵的一字节错误

4. NULL 使 API 变得糟糕

下一个例子,我们将会踏上旅程前往动态类型语言的王国,在那里 NULL 将再一次证明它是一个可怕的错误。

键值存储

假设我们创建一个 Ruby 类充当一个键值存储。这可能是一个缓存、一个用于键值数据库的接口等等。我们将会创建简单通用的 API:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class Store
    ##
    # associate key with value
    #
    def set(key, value)
        ...
    end
    ##
    # get value associated with key, or return nil if there is no such key
    #
    def get(key)
        ...
    end
end

我们可以想象在很多语言中类似的类(Python、JavaScript、Java、C# 等)。

现在假设我们的程序有一个慢的或者占用大量资源的方法,来找到某个人的电话号码——可能通过连通一个网络服务。

为了提高性能,我们将会使用本地存储作为缓存,将一个人名映射到他的电话号码上。

1
2
3
4
store = Store.new()
store.set('Bob', '801-555-5555')
store.get('Bob') # returns '801-555-5555', which is Bob’s number
store.get('Alice') # returns nil, since it does not have Alice

然而,一些人没有电话号码(即他们的电话号码是 nil)。我们仍然会缓存那些信息,所以我们不需要在后面重新填充那些信息。

1
2
3
store = Store.new()
store.set('Ted', nil) # Ted has no phone number
store.get('Ted') # returns nil, since Ted does not have a phone number

但是现在意味着我们的结果模棱两可!它可能表示:

  1. 这个人不存在于缓存中(Alice)
  2. 这个人存在于缓存中,但是没有电话号码(Tom)

一种情形要求昂贵的重新计算,另一种需要即时的答复。但是我们的代码不够精密来区分这两种情况。

在实际的代码中,像这样的情况经常会以复杂且不易察觉的方式出现。因此,简单通用的 API 可以马上变成特例,迷惑了 null 凌乱行为的来源。

用一个 contains() 方法来修补 Store 类可能会有帮助。但是这引入重复的查找,导致降低性能和竞争条件。

双重麻烦

JavaScript 有相同的问题,但是发生在每个单一的对象

如果一个对象的属性不存在,JS 会返回一个值来表示该对象缺少属性。JavaScript 的设计人员已经选择了此值为 null。

然而他们担心的是当属性存在并且该属性被设为 null 的情况。“有才”的是,JavaScript 添加了 undefined 来区分值为 null 的属性和不存在的属性。

但是如果属性存在,并且它的值被设为 undefined,将会怎样?奇怪的是,JavaScript 在这里停住了,没有提供“超级 undefined”。

JavaScript 提出了不仅一种,而是两种形式的 NULL。

5. NULL 使错误的语言决策更加恶化

Java 默默地在引用和主要类型之间转换。加上 null,事情变得更加奇怪。

例如,下面的代码编译不过:

1
int x = null; // compile error

这段代码则编译通过:

1
2
Integer i = null;
int x = i; // runtime error

虽然当该代码运行时会报出 NullPointerException 的错误。

成员方法调用 null 是够糟糕的;当你从未见过该方法被调用时更糟糕。

6. NULL 难以调试

来解释 NULL 是多么的麻烦,C++ 是一个很好的例子。调用成员函数指向一个 NULL 指针不一定会导致程序崩溃。更糟糕的是:它可能会导致程序崩溃。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <iostream>
struct Foo {
    int x;
    void bar() {
        std::cout << "La la la" << std::endl;
    }
    void baz() {
        std::cout << x << std::endl;
    }
};
int main() {
    Foo *foo = NULL;
    foo->bar(); // okay
    foo->baz(); // crash
}

当我用 gcc 编译上述代码时,第一个调用是成功的;第二个则是失败的。

为什么?foo->bar() 在编译时是已知的,所以编译器避免一个运行时虚表查找,并将它转换成一个静态调用,类似 Foo_bar(foo),以此为第一个参数。由于 bar 没有间接引用 NULL 指针,所以它成功运行。但是 baz 有引用 NULL 指针,所以导致一个段错误。

但是解设我们将 bar 变成虚函数。这意味着它的实现可能会被一个子类重写。

1
2
3
...
virtual void bar() {
...

作为一个虚函数,foo->bar() 为 foo 的运行时类型做虚表查找,以防 bar() 被重写。由于foo 是 NULL,现在的程序会在 foo->bar() 这句崩溃,这全都是因为我们把该函数变成虚函数了。

1
2
3
4
5
int main() {
    Foo *foo = NULL;
    foo->bar(); // crash
    foo->baz();
}

NULL 已经使得 main 函数的程序员调试这段代码变得非常困难和不直观。

的确,在 C++ 标准中没有定义引用 NULL,所以技术上我们不应该对发生的任何情况感到惊讶。还有,这是一个非病态的、常见的、十分简单的、真实的例子,这个例子是在实践中 NULL 变化无常的众多例子中的一个。

7. NULL 是不可组合的

程序语言是围绕着可组合性构建的:即将一个抽象应用到另一个抽象的能力。这可能是任何语言、库、框架、模型、API 或者设计模式的一个最重要的特征:正交地使用其它特征的能力。

实际上,可组合性确实是很多这类问题背后的基本问题。例如,Store API 返回 nil 给不存在的值与存储 nil 给不存在的电话号码之间不具有可组合性。

C# 用 Nullable 来处理一些关于 NULL 的问题。你可以在类型中包括可选性(为空性)。

1
2
3
int a = 1;     // integer
int? b = 2;    // optional integer that exists
int? c = null; // optional integer that does not exist

但是这造成一个严重的缺陷,那就是 Nullable 不能应用于任何的 T。它仅仅能应用于非空的 T。例如,它不会使 Store 的问题得到任何改善。

  1. 首先 string 可以是空的;你不能创建一个不可空的 string
  2. 即使 string 是不可空的,以此创建 string?可能吧,但是你仍然无法消除目前情况的歧义。没有 string??

解决方案

NULL 变得如此普遍以至于很多人认为它是有必要的。NULL 在很多低级和高级语言中已经出现很久了,它似乎是必不可少的,像整数运算或者 I/O 一样。

不是这样的!你可以拥有一个不带 NULL 的完整的程序语言。NULL 的问题是一个非数值的值、一个哨兵、一个集中到其它一切的特例。

相反,我们需要一个实体来包含一些信息,这些信息是关于(1)它是否包含一个值和(2)已包含的值,如果存在已包含的值的话。并且这个实体应该可以“包含”任意类型。这是 Haskell 的 Maybe、Java 的 Optional、Swift 的 Optional 等的思想。

例如,在 Scala 中,Some[T] 保存一个 T 类型的值。None 没有值。这两个都是 Option[T]的子类型,这两个子类型可能保存了一个值,也可能没有值。

不熟悉 Maybes/Options 的读者可能会想我们已经把一种没有的形式(NULL)替代为另一种没有的形式(None)。但是这有一个不同点——不易察觉,但是至关重要。

在一种静态类型语言中,你不能通过替代 None 为任意值来绕过类型系统。None 只能用在我们期望一个 Option 出现的地方。可选性显式地表现于类型中。

而在动态类型语言中,你不能混淆 Maybes/Options 和已包含值的用法。

让我们回到先前的 Store,但是这次可能使用 ruby。如果存在一个值,则 Store 类返回带有值的 Some,否则反回 None。对于电话号码,Some 是一个电话号码,None 代表没有电话号码。因此有两级的存在/不存在:外部的 Maybe 表示存在于 Store 中;内部的 Maybe 表示那个名字对应的电话号码。我们已经成功组合了多个 Maybe,这是我们无法用 nil 做到的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
cache = Store.new()
cache.set('Bob', Some('801-555-5555'))
cache.set('Tom', None())
bob_phone = cache.get('Bob')
bob_phone.is_some # true, Bob is in cache
bob_phone.get.is_some # true, Bob has a phone number
bob_phone.get.get # '801-555-5555'
alice_phone = cache.get('Alice')
alice_phone.is_some # false, Alice is not in cache
tom_phone = cache.get('Tom')
tom_phone.is_some # true, Tom is in cache
tom_phone.get.is_some #false, Tom does not have a phone number

本质的区别是不再有 NULL 和其它任何类型之间的联合——静态地类型化或者动态地假设,不再有一个存在的值和不存在的值之间的联合。

使用 Maybes/Options

让我们继续讨论更多没有 NULL 的代码。假设在 Java 8+ 中,我们有一个整数,它可能存在,也可能不存在,并且如果它存在,我们就把它打印出来。

1
2
3
4
Optional<Integer> option = ...
if (option.isPresent()) {
   doubled = System.out.println(option.get());
}

这样很好。但是大多数的 Maybe/Optional 实现,包括 Java,支持一种更好的实用方法:

1
2
option.ifPresent(x -> System.out.println(x));
// or option.ifPresent(System.out::println)

不仅因为这种实用的方法更加简洁,而且它也更加安全。需要记住如果该值不存在,那么 option.get() 会产生一个错误。在早些时候的例子中,get() 受到一个 if 保护。在这个例子中,ifPresent() 完全省却了我们对 get() 的需要。它使得代码明显地没有 bug,而不是没有明显的 bug。

Options 可以被认为是一个最大值为 1 的集合。例如,如果存在值,那么我们可以将该值乘以 2,否则让它空着。

1
option.map(x -> 2 * x)

我们可以可选地执行一个运算,该运算返回一个可选的值,并且使结果趋于“扁平化”。

1
option.flatMap(x -> methodReturningOptional(x))

如果 none 存在,我们可以提供一个默认的值:

1
option.orElseGet(5)

总的来说,Maybe/Option 真正的价值是

  1. 降低关于值存在和不存在的不安全的假设
  2. 更容易安全地操作可选的数据
  3. 显式地声明任何不安全的存在假设(例如,.get() 方法)

不要 NULL!

NULL 是一个可怕的设计缺陷,一种持续不断地、不可估量的痛苦。只有很少语言设法避免它的可怕。

如果你确实选择了一种带 NULL 的语言,那么至少要有意识地在你自己的代码中避免这种不快,并使用等效的 Maybe/Option

常用语言中的 NULL:

“分数”是根据下面的标准来定的:

编辑

评分

对于上述表格的“评分”不要太认真。真正的问题是总结各种语言 NULL 的状态和介绍 NULL 的替代品,并不是为了把常用的语言分等级。

部分语言的信息已经被修正过。出于运行时兼容性的原因,一些语言会有某种 null 指针,但是它们对于语言自身并没有实际的用处。

  • 例子:Haskell 的 Foreign.Ptr.nullPtr 被用于 FFI(Foreign Function Interface),给 Haskell 编组值和从 Haskell 中编组值。
  • 例子:Swift 的 UnsafePointer 必须与 unsafeUnwrap 或者 ! 一起使用。
  • 反例:Scala,尽管习惯性地避免 null,仍然与 Java 一样对待 null,以增强互操作。val x: String = null

什么时候 NULL 是 OK 的?

值得说明的是,当减少 CPU 周期时,一个大小一致的特殊值,像 0 或者 NULL 可以很有用,用代码质量换取性能。当这真正重要的时候,它对于那些低级语言很方便,像 C,但是它真应该离开那里。

真正的问题

NULL 更加常见的问题是哨兵值:这些值与其它值一样,但是有着完全不同的含义。从 indexOf 返回一个整数的索引或者整数 -1 是一个很好的示例。以 NULL 结尾的字符串是另一个例子。这篇文章主要关注 NULL,给出它的普遍性和真实的影响,但是正如 Sauron 仅仅是 Morgoth 的仆人,NULL 也仅仅是基本的哨兵问题的一种形式。

 | 369 views | 0 comments | 0 flags | 

推荐!国外程序员整理的 C++ 资源大全

http://blog.jobbole.com/78901/

关于 C++ 框架、库和资源的一些汇总列表,由 fffaraz 发起和维护。

内容包括:标准库、Web应用框架、人工智能、数据库、图片处理、机器学习、日志、代码分析等。

 

标准库

C++标准库,包括了STL容器,算法和函数等。

 

框架

C++通用框架和库

  • Apache C++ Standard Library:是一系列算法,容器,迭代器和其他基本组件的集合
  • ASL :Adobe源代码库提供了同行的评审和可移植的C++源代码库。
  • Boost :大量通用C++库的集合。
  • BDE :来自于彭博资讯实验室的开发环境。
  • Cinder:提供专业品质创造性编码的开源开发社区。
  • Cxxomfort:轻量级的,只包含头文件的库,将C++ 11的一些新特性移植到C++03中。
  • Dlib:使用契约式编程和现代C++科技设计的通用的跨平台的C++库。
  • EASTL :EA-STL公共部分
  • ffead-cpp :企业应用程序开发框架
  • Folly:由Facebook开发和使用的开源C++库
  • JUCE :包罗万象的C++类库,用于开发跨平台软件
  • libPhenom:用于构建高性能和高度可扩展性系统的事件框架。
  • LibSourcey :用于实时的视频流和高性能网络应用程序的C++11 evented IO
  • LibU : C语言写的多平台工具库
  • Loki :C++库的设计,包括常见的设计模式和习语的实现。
  • MiLi :只含头文件的小型C++库
  • openFrameworks :开发C++工具包,用于创意性编码。
  • Qt :跨平台的应用程序和用户界面框架
  • Reason :跨平台的框架,使开发者能够更容易地使用Java,.Net和Python,同时也满足了他们对C++性能和优势的需求。
  • ROOT :具备所有功能的一系列面向对象的框架,能够非常高效地处理和分析大量的数据,为欧洲原子能研究机构所用。
  • STLport:是STL具有代表性的版本
  • STXXL:用于额外的大型数据集的标准模板库。
  • Ultimate++ :C++跨平台快速应用程序开发框架
  • Windows Template Library:用于开发Windows应用程序和UI组件的C++库
  • Yomm11 :C++11的开放multi-methods.

 

人工智能

  • btsk :游戏行为树启动器工具
  • Evolving Objects:基于模板的,ANSI C++演化计算库,能够帮助你非常快速地编写出自己的随机优化算法。
  • Neu:C++11框架,编程语言集,用于创建人工智能应用程序的多用途软件系统。

 

异步事件循环

  • Boost.Asio:用于网络和底层I/O编程的跨平台的C++库。
  • libev :功能齐全,高性能的时间循环,轻微地仿效libevent,但是不再像libevent一样有局限性,也修复了它的一些bug。
  • libevent :事件通知库
  • libuv :跨平台异步I/O。

 

音频

音频,声音,音乐,数字化音乐库

  • FMOD :易于使用的跨平台的音频引擎和音频内容的游戏创作工具。
  • Maximilian :C++音频和音乐数字信号处理库
  • OpenAL :开源音频库—跨平台的音频API
  • Opus:一个完全开放的,免版税的,高度通用的音频编解码器
  • Speex:免费编解码器,为Opus所废弃
  • Tonic: C++易用和高效的音频合成
  • Vorbis: Ogg Vorbis是一种完全开放的,非专有的,免版税的通用压缩音频格式。

 

生态学

生物信息,基因组学和生物技术

  • libsequence:用于表示和分析群体遗传学数据的C++库。
  • SeqAn:专注于生物数据序列分析的算法和数据结构。
  • Vcflib :用于解析和处理VCF文件的C++库
  • Wham:直接把联想测试应用到BAM文件的基因结构变异。

 

压缩

压缩和归档库

  • bzip2:一个完全免费,免费专利和高质量的数据压缩
  • doboz:能够快速解压缩的压缩库
  • PhysicsFS:对各种归档提供抽象访问的库,主要用于视频游戏,设计灵感部分来自于Quake3的文件子系统。
  • KArchive:用于创建,读写和操作文件档案(例如zip和 tar)的库,它通过QIODevice的一系列子类,使用gzip格式,提供了透明的压缩和解压缩的数据。
  • LZ4 :非常快速的压缩算法
  • LZHAM :无损压缩数据库,压缩比率跟LZMA接近,但是解压缩速度却要快得多。
  • LZMA :7z格式默认和通用的压缩方法。
  • LZMAT :及其快速的实时无损数据压缩库
  • miniz:单一的C源文件,紧缩/膨胀压缩库,使用zlib兼容API,ZIP归档读写,PNG写方式。
  • Minizip:Zlib最新bug修复,支持PKWARE磁盘跨越,AES加密和IO缓冲。
  • Snappy :快速压缩和解压缩
  • ZLib :非常紧凑的数据流压缩库
  • ZZIPlib:提供ZIP归档的读权限。

 

并发性

并发执行和多线程

  • Boost.Compute :用于OpenCL的C++GPU计算库
  • Bolt :针对GPU进行优化的C++模板库
  • C++React :用于C++11的反应性编程库
  • Intel TBB :Intel线程构件块
  • Libclsph:基于OpenCL的GPU加速SPH流体仿真库
  • OpenCL :并行编程的异构系统的开放标准
  • OpenMP:OpenMP API
  • Thrust :类似于C++标准模板库的并行算法库
  • HPX :用于任何规模的并行和分布式应用程序的通用C++运行时系统
  • VexCL :用于OpenCL/CUDA 的C++向量表达式模板库。

 

容器

  • C++ B-tree :基于B树数据结构,实现命令内存容器的模板库
  • Hashmaps: C++中开放寻址哈希表算法的实现

 

密码学

  • Bcrypt :一个跨平台的文件加密工具,加密文件可以移植到所有可支持的操作系统和处理器中。
  • BeeCrypt
  • Botan: C++加密库
  • Crypto++:一个有关加密方案的免费的C++库
  • GnuPG: OpenPGP标准的完整实现
  • GnuTLS :实现了SSL,TLS和DTLS协议的安全通信库
  • Libgcrypt
  • libmcrypt
  • LibreSSL:免费的SSL/TLS协议,属于2014 OpenSSL的一个分支
  • LibTomCrypt:一个非常全面的,模块化的,可移植的加密工具
  • libsodium:基于NaCI的加密库,固执己见,容易使用
  • Nettle 底层的加密库
  • OpenSSL : 一个强大的,商用的,功能齐全的,开放源代码的加密库。
  • Tiny AES128 in C :用C实现的一个小巧,可移植的实现了AES128ESB的加密算法

 

数据库

数据库,SQL服务器,ODBC驱动程序和工具

  • hiberlite :用于Sqlite3的C++对象关系映射
  • Hiredis: 用于Redis数据库的很简单的C客户端库
  • LevelDB: 快速键值存储库
  • LMDB:符合数据库四大基本元素的嵌入键值存储
  • MySQL++:封装了MySql的C API的C++ 包装器
  • RocksDB:来自Facebook的嵌入键值的快速存储
  • SQLite:一个完全嵌入式的,功能齐全的关系数据库,只有几百KB,可以正确包含到你的项目中。

 

调试

调试库, 内存和资源泄露检测,单元测试

  • Boost.Test:Boost测试库
  • Catch:一个很时尚的,C++原生的框架,只包含头文件,用于单元测试,测试驱动开发和行为驱动开发。
  • CppUnit:由JUnit移植过来的C++测试框架
  • CTest:CMake测试驱动程序
  • googletest:谷歌C++测试框架
  • ig-debugheap:用于跟踪内存错误的多平台调试堆
  • libtap:用C语言编写测试
  • MemTrack —用于C++跟踪内存分配
  • microprofile- 跨平台的网络试图分析器
  • minUnit :使用C写的迷你单元测试框架,只使用了两个宏
  • Remotery:用于web视图的单一C文件分析器
  • UnitTest++:轻量级的C++单元测试框架

 

游戏引擎

  • Cocos2d-x :一个跨平台框架,用于构建2D游戏,互动图书,演示和其他图形应用程序。
  • Grit :社区项目,用于构建一个免费的游戏引擎,实现开放的世界3D游戏。
  • Irrlicht :C++语言编写的开源高性能的实时#D引擎
  • Polycode:C++实现的用于创建游戏的开源框架(与Lua绑定)。

 

图形用户界面

  • CEGUI : 很灵活的跨平台GUI库
  • FLTK :快速,轻量级的跨平台的C++GUI工具包。
  • GTK+: 用于创建图形用户界面的跨平台工具包
  • gtkmm :用于受欢迎的GUI库GTK+的官方C++接口。
  • imgui:拥有最小依赖关系的立即模式图形用户界面
  • libRocket :libRocket 是一个C++ HTML/CSS 游戏接口中间件
  • MyGUI :快速,灵活,简单的GUI
  • Ncurses:终端用户界面
  • QCustomPlot :没有更多依赖关系的Qt绘图控件
  • Qwt :用户与技术应用的Qt 控件
  • QwtPlot3D :功能丰富的基于Qt/OpenGL的C++编程库,本质上提供了一群3D控件
  • OtterUI :OtterUI 是用于嵌入式系统和互动娱乐软件的用户界面开发解决方案
  • PDCurses 包含源代码和预编译库的公共图形函数库
  • wxWidgets C++库,允许开发人员使用一个代码库可以为widows, Mac OS X,Linux和其他平台创建应用程序

 

图形

  • bgfx:跨平台的渲染库
  • Cairo:支持多种输出设备的2D图形库
  • Horde3D 一个小型的3D渲染和动画引擎
  • magnum C++11和OpenGL 2D/3D 图形引擎
  • Ogre 3D 用C++编写的一个面向场景,实时,灵活的3D渲染引擎(并非游戏引擎)
  • OpenSceneGraph 具有高性能的开源3D图形工具包
  • Panda3D 用于3D渲染和游戏开发的框架,用Python和C++编写。
  • Skia 用于绘制文字,图形和图像的完整的2D图形库
  • urho3d 跨平台的渲染和游戏引擎。

 

图像处理

  • Boost.GIL:通用图像库
  • CImg :用于图像处理的小型开源C++工具包
  • CxImage :用于加载,保存,显示和转换的图像处理和转换库,可以处理的图片格式包括 BMP, JPEG, GIF, PNG, TIFF, MNG, ICO, PCX, TGA, WMF, WBMP, JBG, J2K。
  • FreeImage :开源库,支持现在多媒体应用所需的通用图片格式和其他格式。
  • GDCM:Grassroots DICOM 库
  • ITK:跨平台的开源图像分析系统
  • Magick++:ImageMagick程序的C++接口
  • MagickWnd:ImageMagick程序的C++接口
  • OpenCV : 开源计算机视觉类库
  • tesseract-ocr:OCR引擎
  • VIGRA :用于图像分析通用C++计算机视觉库
  • VTK :用于3D计算机图形学,图像处理和可视化的开源免费软件系统。

 

国际化

  • gettext :GNU `gettext’
  • IBM ICU:提供Unicode 和全球化支持的C、C++ 和Java库
  • libiconv :用于不同字符编码之间的编码转换库

 

Jason

  • frozen : C/C++的Jason解析生成器
  • Jansson :进行编解码和处理Jason数据的C语言库
  • jbson :C++14中构建和迭代BSON data,和Json 文档的库
  • JeayeSON:非常健全的C++ JSON库,只包含头文件
  • JSON++ : C++ JSON 解析器
  • json-parser:用可移植的ANSI C编写的JSON解析器,占用内存非常少
  • json11 :一个迷你的C++11 JSON库
  • jute :非常简单的C++ JSON解析器
  • ibjson:C语言中的JSON解析和打印库,很容易和任何模型集成。
  • libjson:轻量级的JSON库
  • PicoJSON:C++中JSON解析序列化,只包含头文件
  • qt-json :用于JSON数据和 QVariant层次间的相互解析的简单类
  • QJson:将JSON数据映射到QVariant对象的基于Qt的库
  • RapidJSON: 用于C++的快速JSON 解析生成器,包含SAX和DOM两种风格的API
  • YAJL :C语言中快速流JSON解析库

 

日志

  • Boost.Log :设计非常模块化,并且具有扩展性
  • easyloggingpp:C++日志库,只包含单一的头文件。
  • Log4cpp :一系列C++类库,灵活添加日志到文件,系统日志,IDSA和其他地方。
  • templog:轻量级C++库,可以添加日志到你的C++应用程序中

 

机器学习

  • Caffe :快速的神经网络框架
  • CCV :以C语言为核心的现代计算机视觉库
  • mlpack :可扩展的C++机器学习库
  • OpenCV:开源计算机视觉库
  • Recommender:使用协同过滤进行产品推荐/建议的C语言库。
  • SHOGUN:Shogun 机器学习工具
  • sofia-ml :用于机器学习的快速增量算法套件

 

数学

  • Armadillo :高质量的C++线性代数库,速度和易用性做到了很好的平衡。语法和MatlAB很相似
  • blaze:高性能的C++数学库,用于密集和稀疏算法。
  • ceres-solver :来自谷歌的C++库,用于建模和解决大型复杂非线性最小平方问题。
  • CGal: 高效,可靠的集合算法集合
  • cml :用于游戏和图形的免费C++数学库
  • Eigen :高级C++模板头文件库,包括线性代数,矩阵,向量操作,数值解决和其他相关的算法。
  • GMTL:数学图形模板库是一组广泛实现基本图形的工具。
  • GMP:用于个高精度计算的C/C++库,处理有符号整数,有理数和浮点数。

 

多媒体

  • GStreamer :构建媒体处理组件图形的库
  • LIVE555 Streaming Media :使用开放标准协议(RTP/RTCP, RTSP, SIP) 的多媒体流库
  • libVLC :libVLC (VLC SDK)媒体框架
  • QtAv:基于Qt和FFmpeg的多媒体播放框架,能够帮助你轻而易举地编写出一个播放器
  • SDL :简单直控媒体层
  • SFML :快速,简单的多媒体库

 

网络

  • ACE:C++面向对象网络变成工具包
  • Boost.Asio:用于网络和底层I/O编程的跨平台的C++库
  • Casablanca:C++ REST SDK
  • cpp-netlib:高级网络编程的开源库集合
  • Dyad.c:C语言的异步网络
  • libcurl :多协议文件传输库
  • Mongoose:非常轻量级的网络服务器
  • Muduo :用于Linux多线程服务器的C++非阻塞网络库
  • net_skeleton :C/C++的TCP 客户端/服务器库
  • nope.c :基于C语言的超轻型软件平台,用于可扩展的服务器端和网络应用。 对于C编程人员,可以考虑node.js
  • Onion :C语言HTTP服务器库,其设计为轻量级,易使用。
  • POCO:用于构建网络和基于互联网应用程序的C++类库,可以运行在桌面,服务器,移动和嵌入式系统。
  • RakNet:为游戏开发人员提供的跨平台的开源C++网络引擎。
  • Tuf o :用于Qt之上的C++构建的异步Web框架。
  • WebSocket++ :基于C++/Boost Aiso的websocket 客户端/服务器库
  • ZeroMQ :高速,模块化的异步通信库

 

物理学

动力学仿真引擎

  • Box2D:2D的游戏物理引擎。
  • Bullet :3D的游戏物理引擎。
  • Chipmunk :快速,轻量级的2D游戏物理库
  • LiquidFun:2D的游戏物理引擎
  • ODE :开放动力学引擎-开源,高性能库,模拟刚体动力学。
  • ofxBox2d:Box2D开源框架包装器。
  • Simbody :高性能C++多体动力学/物理库,模拟关节生物力学和机械系统,像车辆,机器人和人体骨骼。

 

机器人学

  • MOOS-IvP :一组开源C++模块,提供机器人平台的自主权,尤其是自主的海洋车辆。
  • MRPT:移动机器人编程工具包
  • PCL :点云库是一个独立的,大规模的开放项目,用于2D/3D图像和点云处理。
  • Robotics Library (RL): 一个独立的C++库,包括机器人动力学,运动规划和控制。
  • RobWork:一组C++库的集合,用于机器人系统的仿真和控制。
  • ROS :机器人操作系统,提供了一些库和工具帮助软件开发人员创建机器人应用程序。

 

科学计算

  • FFTW :用一维或者多维计算DFT的C语言库。
  • GSL:GNU科学库。

 

脚本

  • ChaiScript :用于C++的易于使用的嵌入式脚本语言。
  • Lua :用于配置文件和基本应用程序脚本的小型快速脚本引擎。
  • luacxx:用于创建Lua绑定的C++ 11 API
  • SWIG :一个可以让你的C++代码链接到JavaScript,Perl,PHP,Python,Tcl和Ruby的包装器/接口生成器
  • V7:嵌入式的JavaScript 引擎。
  • V8 :谷歌的快速JavaScript引擎,可以被嵌入到任何C++应用程序中。

 

序列化

  • Cap’n Proto :快速数据交换格式和RPC系统。
  • cereal :C++11 序列化库
  • FlatBuffers :内存高效的序列化库
  • MessagePack :C/C++的高效二进制序列化库,例如 JSON
  • protobuf :协议缓冲,谷歌的数据交换格式。
  • protobuf-c :C语言的协议缓冲实现
  • SimpleBinaryEncoding:用于低延迟应用程序的对二进制格式的应用程序信息的编码和解码。
  • Thrift :高效的跨语言IPC/RPC,用于C++,Java,Python,PHP,C#和其它多种语言中,最初由Twitter开发。

 

视频

  • libvpx :VP8/VP9编码解码SDK
  • FFmpeg :一个完整的,跨平台的解决方案,用于记录,转换视频和音频流。
  • libde265 :开放的h.265视频编解码器的实现。
  • OpenH264:开源H.364 编解码器。
  • Theora :免费开源的视频压缩格式。

 

虚拟机

  • CarpVM:C中有趣的VM,让我们一起来看看这个。
  • MicroPython :旨在实现单片机上Python3.x的实现
  • TinyVM:用纯粹的ANSI C编写的小型,快速,轻量级的虚拟机。

 

Web应用框架

  • Civetweb :提供易于使用,强大的,C/C++嵌入式Web服务器,带有可选的CGI,SSL和Lua支持。
  • CppCMS :免费高性能的Web开发框架(不是 CMS).
  • Crow :一个C++微型web框架(灵感来自于Python Flask)
  • Kore :使用C语言开发的用于web应用程序的超快速和灵活的web服务器/框架。
  • libOnion:轻量级的库,帮助你使用C编程语言创建web服务器。
  • QDjango:使用C++编写的,基于Qt库的web框架,试图效仿Django API,因此得此名。
  • Wt :开发Web应用的C++库。

 

XML

XML就是个垃圾,xml的解析很烦人,对于计算机它也是个灾难。这种糟糕的东西完全没有存在的理由了。-Linus Torvalds

  • Expat :用C语言编写的xml解析库
  • Libxml2 :Gnome的xml C解析器和工具包
  • libxml++ :C++的xml解析器
  • PugiXML :用于C++的,支持XPath的轻量级,简单快速的XML解析器。
  • RapidXml :试图创建最快速的XML解析器,同时保持易用性,可移植性和合理的W3C兼容性。
  • TinyXML :简单小型的C++XML解析器,可以很容易地集成到其它项目中。
  • TinyXML2:简单快速的C++CML解析器,可以很容易集成到其它项目中。
  • TinyXML++:TinyXML的一个全新的接口,使用了C++的许多许多优势,模板,异常和更好的异常处理。
  • Xerces-C++ :用可移植的C++的子集编写的XML验证解析器。

 

多项混杂

一些有用的库或者工具,但是不适合上面的分类,或者还没有分类。

  • C++ Format :C++的小型,安全和快速格式化库
  • casacore :从aips++ 派生的一系列C++核心库
  • cxx-prettyprint:用于C++容器的打印库
  • DynaPDF :易于使用的PDF生成库
  • gcc-poison :帮助开发人员禁止应用程序中的不安全的C/C++函数的简单的头文件。
  • googlemock:编写和使用C++模拟类的库
  • HTTP Parser :C的http请求/响应解析器
  • libcpuid :用于x86 CPU检测盒特征提取的小型C库
  • libevil :许可证管理器
  • libusb:允许移动访问USB设备的通用USB库
  • PCRE:正则表达式C库,灵感来自于Perl中正则表达式的功能。
  • Remote Call Framework :C++的进程间通信框架。
  • Scintilla :开源的代码编辑控件
  • Serial Communication Library :C++语言编写的跨平台,串口库。
  • SDS:C的简单动态字符串库
  • SLDR :超轻的DNS解析器
  • SLRE: 超轻的正则表达式库
  • Stage :移动机器人模拟器
  • VarTypes:C++/Qt4功能丰富,面向对象的管理变量的框架。
  • ZBar:‘条形码扫描器’库,可以扫描照片,图片和视频流中的条形码,并返回结果。
  • CppVerbalExpressions :易于使用的C++正则表达式
  • QtVerbalExpressions:基于C++ VerbalExpressions 库的Qt库
  • PHP-CPP:使用C++来构建PHP扩展的库
  • Better String :C的另一个字符串库,功能更丰富,但是没有缓冲溢出问题,还包含了一个C++包装器。

 

软件

用于创建开发环境的软件

编译器

C/C++编译器列表

  • Clang :由苹果公司开发的
  • GCC:GNU编译器集合
  • Intel C++ Compiler :由英特尔公司开发
  • LLVM :模块化和可重用编译器和工具链技术的集合
  • Microsoft Visual C++ :MSVC,由微软公司开发
  • Open WatCom :Watcom,C,C++和Fortran交叉编译器和工具
  • TCC :轻量级的C语言编译器

 

在线编译器

在线C/C++编译器列表

  • codepad :在线编译器/解释器,一个简单的协作工具
  • CodeTwist:一个简单的在线编译器/解释器,你可以粘贴的C,C++或者Java代码,在线执行并查看结果
  • coliru :在线编译器/shell, 支持各种C++编译器
  • Compiler Explorer:交互式编译器,可以进行汇编输出
  • CompileOnline:Linux上在线编译和执行C++程序
  • Ideone :一个在线编译器和调试工具,允许你在线编译源代码并执行,支持60多种编程语言。

 

调试器

C/C++调试器列表

 

集成开发环境(IDE)

C/C++集成开发环境列表

  • AppCode :构建与JetBrains’ IntelliJ IDEA 平台上的用于Objective-C,C,C++,Java和Java开发的集成开发环境
  • CLion:来自JetBrains的跨平台的C/C++的集成开发环境
  • Code::Blocks :免费C,C++和Fortran的集成开发环境
  • CodeLite :另一个跨平台的免费的C/C++集成开发环境
  • Dev-C++:可移植的C/C++/C++11集成开发环境
  • Eclipse CDT:基于Eclipse平台的功能齐全的C和C++集成开发环境
  • Geany :轻量级的快速,跨平台的集成开发环境。
  • IBM VisualAge :来自IBM的家庭计算机集成开发环境。
  • Irony-mode:由libclang驱动的用于Emacs的C/C++微模式
  • KDevelop:免费开源集成开发环境
  • Microsoft Visual Studio :来自微软的集成开发环境
  • NetBeans :主要用于Java开发的的集成开发环境,也支持其他语言,尤其是PHP,C/C++和HTML5。
  • Qt Creator:跨平台的C++,Javascript和QML集成开发环境,也是Qt SDK的一部分。
  • rtags:C/C++的客户端服务器索引,用于 跟基于clang的emacs的集成
  • Xcode :由苹果公司开发
  • YouCompleteMe:一个用于Vim的根据你敲的代码快速模糊搜索并进行代码补全的引擎。

 

构建系统

  • Bear :用于为clang工具生成编译数据库的工具
  • Biicode:基于文件的简单依赖管理器。
  • CMake :跨平台的免费开源软件用于管理软件使用独立编译的方法进行构建的过程。
  • CPM:基于CMake和Git的C++包管理器
  • FASTBuild:高性能,开源的构建系统,支持高度可扩展性的编译,缓冲和网络分布。
  • Ninja :专注于速度的小型构建系统
  • Scons :使用Python scipt 配置的软件构建工具
  • tundra :高性能的代码构建系统,甚至对于非常大型的软件项目,也能提供最好的增量构建次数。
  • tup:基于文件的构建系统,用于后台监控变化的文件。

 

静态代码分析

提高质量,减少瑕疵的代码分析工具列表

 | 354 views | 0 comments | 0 flags | 

在数学的海洋中飘荡

https://dahuasky.wordpress.com/2009/01/22/%E5%9C%A8%E6%95%B0%E5%AD%A6%E7%9A%84%E6%B5%B7%E6%B4%8B%E4%B8%AD%E9%A3%98%E8%8D%A1/

 

在数学的海洋中飘荡

在过去的一年中,我一直在数学的海洋中游荡,research进展不多,对于数学世界的阅历算是有了一些长进。

为什么要深入数学的世界

作为计算机的学生,我没有任何企图要成为一个数学家。我学习数学的目的,是要想爬上巨人的肩膀,希望站在更高的高度,能把我自己研究的东西看得更深广一些。说起来,我在刚来这个学校的时候,并没有预料到我将会有一个深入数学的旅程。我的导师最初希望我去做的题目,是对appearance和motion建立一个unified的model。这个题目在当今Computer Vision中百花齐放的世界中并没有任何特别的地方。事实上,使用各种Graphical Model把各种东西联合在一起framework,在近年的论文中并不少见。

我不否认现在广泛流行的Graphical Model是对复杂现象建模的有力工具,但是,我认为它不是panacea,并不能取代对于所研究的问题的深入的钻研。如果统计学习包治百病,那么很多“下游”的学科也就没有存在的必要了。事实上,开始的时候,我也是和Vision中很多人一样,想着去做一个Graphical Model——我的导师指出,这样的做法只是重复一些标准的流程,并没有很大的价值。经过很长时间的反复,另外一个路径慢慢被确立下来——我们相信,一个图像是通过大量“原子”的某种空间分布构成的,原子群的运动形成了动态的可视过程。微观意义下的单个原子运动,和宏观意义下的整体分布的变换存在着深刻的联系——这需要我们去发掘。

在深入探索这个题目的过程中,遇到了很多很多的问题,如何描述一个一般的运动过程,如何建立一个稳定并且广泛适用的原子表达,如何刻画微观运动和宏观分布变换的联系,还有很多。在这个过程中,我发现了两个事情:

  • 我原有的数学基础已经远远不能适应我对这些问题的深入研究。
  • 在数学中,有很多思想和工具,是非常适合解决这些问题的,只是没有被很多的应用科学的研究者重视。

于是,我决心开始深入数学这个浩瀚大海,希望在我再次走出来的时候,我已经有了更强大的武器去面对这些问题的挑战。

我的游历并没有结束,我的视野相比于这个博大精深的世界的依旧显得非常狭窄。在这里,我只是说说,在我的眼中,数学如何一步步从初级向高级发展,更高级别的数学对于具体应用究竟有何好处。

 

集合论:现代数学的共同基础

现代数学有数不清的分支,但是,它们都有一个共同的基础——集合论——因为它,数学这个庞大的家族有个共同的语言。集合论中有一些最基本的概念:集合(set),关系(relation),函数(function),等价(equivalence),是在其它数学分支的语言中几乎必然存在的。对于这些简单概念的理解,是进一步学些别的数学的基础。我相信,理工科大学生对于这些都不会陌生。

不过,有一个很重要的东西就不见得那么家喻户晓了——那就是“选择公理”(Axiom of Choice)。这个公理的意思是“任意的一群非空集合,一定可以从每个集合中各拿出一个元素。”——似乎是显然得不能再显然的命题。不过,这个貌似平常的公理却能演绎出一些比较奇怪的结论,比如巴拿赫-塔斯基分球定理——“一个球,能分成五个部分,对它们进行一系列刚性变换(平移旋转)后,能组合成两个一样大小的球”。正因为这些完全有悖常识的结论,导致数学界曾经在相当长时间里对于是否接受它有着激烈争论。现在,主流数学家对于它应该是基本接受的,因为很多数学分支的重要定理都依赖于它。在我们后面要回说到的学科里面,下面的定理依赖于选择公理:

  1. 拓扑学:Baire Category Theorem
  2. 实分析(测度理论):Lebesgue 不可测集的存在性
  3. 泛函分析四个主要定理:Hahn-Banach Extension Theorem, Banach-Steinhaus Theorem (Uniform boundedness principle), Open Mapping Theorem, Closed Graph Theorem

在集合论的基础上,现代数学有两大家族:分析(Analysis)和代数(Algebra)。至于其它的,比如几何和概率论,在古典数学时代,它们是和代数并列的,但是它们的现代版本则基本是建立在分析或者代数的基础上,因此从现代意义说,它们和分析与代数并不是平行的关系。

分析:在极限基础上建立的宏伟大厦

微积分:分析的古典时代——从牛顿到柯西

先说说分析(Analysis)吧,它是从微积分(Caculus)发展起来的——这也是有些微积分教材名字叫“数学分析”的原因。不过,分析的范畴远不只是这些,我们在大学一年级学习的微积分只能算是对古典分析的入门。分析研究的对象很多,包括导数(derivatives),积分(integral),微分方程(differential equation),还有级数(infinite series)——这些基本的概念,在初等的微积分里面都有介绍。如果说有一个思想贯穿其中,那就是极限——这是整个分析(不仅仅是微积分)的灵魂。

一个很多人都听说过的故事,就是牛顿(Newton)和莱布尼茨(Leibniz)关于微积分发明权的争论。事实上,在他们的时代,很多微积分的工具开始运用在科学和工程之中,但是,微积分的基础并没有真正建立。那个长时间一直解释不清楚的“无穷小量”的幽灵,困扰了数学界一百多年的时间——这就是“第二次数学危机”。直到柯西用数列极限的观点重新建立了微积分的基本概念,这门学科才开始有了一个比较坚实的基础。直到今天,整个分析的大厦还是建立在极限的基石之上。

柯西(Cauchy)为分析的发展提供了一种严密的语言,但是他并没有解决微积分的全部问题。在19世纪的时候,分析的世界仍然有着一些挥之不去的乌云。而其中最重要的一个没有解决的是“函数是否可积的问题”。我们在现在的微积分课本中学到的那种通过“无限分割区间,取矩阵面积和的极限”的积分,是大约在1850年由黎曼(Riemann)提出的,叫做黎曼积分。但是,什么函数存在黎曼积分呢(黎曼可积)?数学家们很早就证明了,定义在闭区间内的连续函数是黎曼可积的。可是,这样的结果并不令人满意,工程师们需要对分段连续函数的函数积分。

实分析:在实数理论和测度理论上建立起现代分析

在19世纪中后期,不连续函数的可积性问题一直是分析的重要课题。对于定义在闭区间上的黎曼积分的研究发现,可积性的关键在于“不连续的点足够少”。只有有限处不连续的函数是可积的,可是很多有数学家们构造出很多在无限处不连续的可积函数。显然,在衡量点集大小的时候,有限和无限并不是一种合适的标准。在探讨“点集大小”这个问题的过程中,数学家发现实数轴——这个他们曾经以为已经充分理解的东西——有着许多他们没有想到的特性。在极限思想的支持下,实数理论在这个时候被建立起来,它的标志是对实数完备性进行刻画的几条等价的定理(确界定理,区间套定理,柯西收敛定理,Bolzano-Weierstrass Theorem和Heine-Borel Theorem等等)——这些定理明确表达出实数和有理数的根本区别:完备性(很不严格的说,就是对极限运算封闭)。随着对实数认识的深入,如何测量“点集大小”的问题也取得了突破,勒贝格创造性地把关于集合的代数,和Outer content(就是“外测度”的一个雏形)的概念结合起来,建立了测度理论(Measure Theory),并且进一步建立了以测度为基础的积分——勒贝格(Lebesgue Integral)。在这个新的积分概念的支持下,可积性问题变得一目了然。

上面说到的实数理论,测度理论和勒贝格积分,构成了我们现在称为实分析(Real Analysis)的数学分支,有些书也叫实变函数论。对于应用科学来说,实分析似乎没有古典微积分那么“实用”——很难直接基于它得到什么算法。而且,它要解决的某些“难题”——比如处处不连续的函数,或者处处连续而处处不可微的函数——在工程师的眼中,并不现实。但是,我认为,它并不是一种纯数学概念游戏,它的现实意义在于为许多现代的应用数学分支提供坚实的基础。下面,我仅仅列举几条它的用处:

  1. 黎曼可积的函数空间不是完备的,但是勒贝格可积的函数空间是完备的。简单的说,一个黎曼可积的函数列收敛到的那个函数不一定是黎曼可积的,但是勒贝格可积的函数列必定收敛到一个勒贝格可积的函数。在泛函分析,还有逼近理论中,经常需要讨论“函数的极限”,或者“函数的级数”,如果用黎曼积分的概念,这种讨论几乎不可想像。我们有时看一些paper中提到Lp函数空间,就是基于勒贝格积分。
  2. 勒贝格积分是傅立叶变换(这东西在工程中到处都是)的基础。很多关于信号处理的初等教材,可能绕过了勒贝格积分,直接讲点面对实用的东西而不谈它的数学基础,但是,对于深层次的研究问题——特别是希望在理论中能做一些工作——这并不是总能绕过去。
  3. 在下面,我们还会看到,测度理论是现代概率论的基础。

拓扑学:分析从实数轴推广到一般空间——现代分析的抽象基础

随着实数理论的建立,大家开始把极限和连续推广到更一般的地方的分析。事实上,很多基于实数的概念和定理并不是实数特有的。很多特性可以抽象出来,推广到更一般的空间里面。对于实数轴的推广,促成了点集拓扑学(Point-set Topology)的建立。很多原来只存在于实数中的概念,被提取出来,进行一般性的讨论。在拓扑学里面,有4个C构成了它的核心:

  1. Closed set(闭集合)。在现代的拓扑学的公理化体系中,开集和闭集是最基本的概念。一切从此引申。这两个概念是开区间和闭区间的推广,它们的根本地位,并不是一开始就被认识到的。经过相当长的时间,人们才认识到:开集的概念是连续性的基础,而闭集对极限运算封闭——而极限正是分析的根基。
  2. Continuous function (连续函数)。连续函数在微积分里面有个用epsilon-delta语言给出的定义,在拓扑学中它的定义是“开集的原像是开集的函数”。第二个定义和第一个是等价的,只是用更抽象的语言进行了改写。我个人认为,它的第三个(等价)定义才从根本上揭示连续函数的本质——“连续函数是保持极限运算的函数”——比如y是数列x1, x2, x3, … 的极限, 那么如果 f 是连续函数,那么 f(y) 就是 f(x1), f(x2), f(x3), …的极限。连续函数的重要性,可以从别的分支学科中进行类比。比如群论中,基础的运算是“乘法”,对于群,最重要的映射叫“同态映射”——保持“乘法”的映射。在分析中,基础运算是“极限”,因此连续函数在分析中的地位,和同态映射在代数中的地位是相当的。
  3. Connected set (连通集合)。比它略为窄一点的概念叫(Path connected),就是集合中任意两点都存在连续路径相连——可能是一般人理解的概念。一般意义下的连通概念稍微抽象一些。在我看来,连通性有两个重要的用场:一个是用于证明一般的中值定理(Intermediate Value Theorem),还有就是代数拓扑,拓扑群论和李群论中讨论根本群(Fundamental Group)的阶。
  4. Compact set(紧集)。Compactness似乎在初等微积分里面没有专门出现,不过有几条实数上的定理和它其实是有关系的。比如,“有界数列必然存在收敛子列”——用compactness的语言来说就是——“实数空间中有界闭集是紧的”。它在拓扑学中的一般定义是一个听上去比较抽象的东西——“紧集的任意开覆盖存在有限子覆盖”。这个定义在讨论拓扑学的定理时很方便,它在很多时候能帮助实现从无限到有限的转换。对于分析来说,用得更多的是它的另一种形式——“紧集中的数列必存在收敛子列”——它体现了分析中最重要的“极限”。Compactness在现代分析中运用极广,无法尽述。微积分中的两个重要定理:极值定理(Extreme Value Theory),和一致收敛定理(Uniform Convergence Theorem)就可以借助它推广到一般的形式。

从某种意义上说,点集拓扑学可以看成是关于“极限”的一般理论,它抽象于实数理论,它的概念成为几乎所有现代分析学科的通用语言,也是整个现代分析的根基所在。

微分几何:流形上的分析——在拓扑空间上引入微分结构

拓扑学把极限的概念推广到一般的拓扑空间,但这不是故事的结束,而仅仅是开始。在微积分里面,极限之后我们有微分,求导,积分。这些东西也可以推广到拓扑空间,在拓扑学的基础上建立起来——这就是微分几何。从教学上说,微分几何的教材,有两种不同的类型,一种是建立在古典微机分的基础上的“古典微分几何”,主要是关于二维和三维空间中的一些几何量的计算,比如曲率。还有一种是建立在现代拓扑学的基础上,这里姑且称为“现代微分几何”——它的核心概念就是“流形”(manifold)——就是在拓扑空间的基础上加了一套可以进行微分运算的结构。现代微分几何是一门非常丰富的学科。比如一般流形上的微分的定义就比传统的微分丰富,我自己就见过三种从不同角度给出的等价定义——这一方面让事情变得复杂一些,但是另外一个方面它给了同一个概念的不同理解,往往在解决问题时会引出不同的思路。除了推广微积分的概念以外,还引入了很多新概念:tangent space, cotangent space, push forward, pull back, fibre bundle, flow, immersion, submersion 等等。

近些年,流形在machine learning似乎相当时髦。但是,坦率地说,要弄懂一些基本的流形算法, 甚至“创造”一些流形算法,并不需要多少微分几何的基础。对我的研究来说,微分几何最重要的应用就是建立在它之上的另外一个分支:李群和李代数——这是数学中两大家族分析和代数的一个漂亮的联姻。分析和代数的另外一处重要的结合则是泛函分析,以及在其基础上的调和分析。

 

代数:一个抽象的世界

关于抽象代数

回过头来,再说说另一个大家族——代数。

如果说古典微积分是分析的入门,那么现代代数的入门点则是两个部分:线性代数(linear algebra)和基础的抽象代数(abstract algebra)——据说国内一些教材称之为近世代数。

代数——名称上研究的似乎是数,在我看来,主要研究的是运算规则。一门代数,其实都是从某种具体的运算体系中抽象出一些基本规则,建立一个公理体系,然后在这基础上进行研究。一个集合再加上一套运算规则,就构成一个代数结构。在主要的代数结构中,最简单的是群(Group)——它只有一种符合结合率的可逆运算,通常叫“乘法”。如果,这种运算也符合交换率,那么就叫阿贝尔群(Abelian Group)。如果有两种运算,一种叫加法,满足交换率和结合率,一种叫乘法,满足结合率,它们之间满足分配率,这种丰富一点的结构叫做环(Ring),如果环上的乘法满足交换率,就叫可交换环(Commutative Ring)。如果,一个环的加法和乘法具有了所有的良好性质,那么就成为一个域(Field)。基于域,我们可以建立一种新的结构,能进行加法和数乘,就构成了线性代数(Linear algebra)。

代数的好处在于,它只关心运算规则的演绎,而不管参与运算的对象。只要定义恰当,完全可以让一只猫乘一只狗得到一头猪:-)。基于抽象运算规则得到的所有定理完全可以运用于上面说的猫狗乘法。当然,在实际运用中,我们还是希望用它干点有意义的事情。学过抽象代数的都知道,基于几条最简单的规则,比如结合律,就能导出非常多的重要结论——这些结论可以应用到一切满足这些简单规则的地方——这是代数的威力所在,我们不再需要为每一个具体领域重新建立这么多的定理。

抽象代数有在一些基础定理的基础上,进一步的研究往往分为两个流派:研究有限的离散代数结构(比如有限群和有限域),这部分内容通常用于数论,编码,和整数方程这些地方;另外一个流派是研究连续的代数结构,通常和拓扑与分析联系在一起(比如拓扑群,李群)。我在学习中的focus主要是后者。

线性代数:“线性”的基础地位

对于做Learning, vision, optimization或者statistics的人来说,接触最多的莫过于线性代数——这也是我们在大学低年级就开始学习的。线性代数,包括建立在它基础上的各种学科,最核心的两个概念是向量空间和线性变换。线性变换在线性代数中的地位,和连续函数在分析中的地位,或者同态映射在群论中的地位是一样的——它是保持基础运算(加法和数乘)的映射。

在learning中有这样的一种倾向——鄙视线性算法,标榜非线性。也许在很多场合下面,我们需要非线性来描述复杂的现实世界,但是无论什么时候,线性都是具有根本地位的。没有线性的基础,就不可能存在所谓的非线性推广。我们常用的非线性化的方法包括流形和kernelization,这两者都需要在某个阶段回归线性。流形需要在每个局部建立和线性空间的映射,通过把许多局部线性空间连接起来形成非线性;而kernerlization则是通过置换内积结构把原线性空间“非线性”地映射到另外一个线性空间,再进行线性空间中所能进行的操作。而在分析领域,线性的运算更是无处不在,微分,积分,傅立叶变换,拉普拉斯变换,还有统计中的均值,通通都是线性的。

泛函分析:从有限维向无限维迈进

在大学中学习的线性代数,它的简单主要因为它是在有限维空间进行的,因为有限,我们无须借助于太多的分析手段。但是,有限维空间并不能有效地表达我们的世界——最重要的,函数构成了线性空间,可是它是无限维的。对函数进行的最重要的运算都在无限维空间进行,比如傅立叶变换和小波分析。这表明了,为了研究函数(或者说连续信号),我们需要打破有限维空间的束缚,走入无限维的函数空间——这里面的第一步,就是泛函分析。

泛函分析(Functional Analysis)是研究的是一般的线性空间,包括有限维和无限维,但是很多东西在有限维下显得很trivial,真正的困难往往在无限维的时候出现。在泛函分析中,空间中的元素还是叫向量,但是线性变换通常会叫作“算子”(operator)。除了加法和数乘,这里进一步加入了一些运算,比如加入范数去表达“向量的长度”或者“元素的距离”,这样的空间叫做“赋范线性空间”(normed space),再进一步的,可以加入内积运算,这样的空间叫“内积空间”(Inner product space)。

大家发现,当进入无限维的时间时,很多老的观念不再适用了,一切都需要重新审视。

  1. 所有的有限维空间都是完备的(柯西序列收敛),很多无限维空间却是不完备的(比如闭区间上的连续函数)。在这里,完备的空间有特殊的名称:完备的赋范空间叫巴拿赫空间(Banach space),完备的内积空间叫希尔伯特空间(Hilbert space)。
  2. 在有限维空间中空间和它的对偶空间的是完全同构的,而在无限维空间中,它们存在微妙的差别。
  3. 在有限维空间中,所有线性变换(矩阵)都是有界变换,而在无限维,很多算子是无界的(unbounded),最重要的一个例子是给函数求导。
  4. 在有限维空间中,一切有界闭集都是紧的,比如单位球。而在所有的无限维空间中,单位球都不是紧的——也就是说,可以在单位球内撒入无限个点,而不出现一个极限点。
  5. 在有限维空间中,线性变换(矩阵)的谱相当于全部的特征值,在无限维空间中,算子的谱的结构比这个复杂得多,除了特征值组成的点谱(point spectrum),还有approximate point spectrum和residual spectrum。虽然复杂,但是,也更为有趣。由此形成了一个相当丰富的分支——算子谱论(Spectrum theory)。
  6. 在有限维空间中,任何一点对任何一个子空间总存在投影,而在无限维空间中,这就不一定了,具有这种良好特性的子空间有个专门的名称切比雪夫空间(Chebyshev space)。这个概念是现代逼近理论的基础(approximation theory)。函数空间的逼近理论在Learning中应该有着非常重要的作用,但是现在看到的运用现代逼近理论的文章并不多。

继续往前:巴拿赫代数,调和分析,和李代数

基本的泛函分析继续往前走,有两个重要的方向。第一个是巴拿赫代数(Banach Algebra),它就是在巴拿赫空间(完备的内积空间)的基础上引入乘法(这不同于数乘)。比如矩阵——它除了加法和数乘,还能做乘法——这就构成了一个巴拿赫代数。除此以外,值域完备的有界算子,平方可积函数,都能构成巴拿赫代数。巴拿赫代数是泛函分析的抽象,很多对于有界算子导出的结论,还有算子谱论中的许多定理,它们不仅仅对算子适用,它们其实可以从一般的巴拿赫代数中得到,并且应用在算子以外的地方。巴拿赫代数让你站在更高的高度看待泛函分析中的结论,但是,我对它在实际问题中能比泛函分析能多带来什么东西还有待思考。

最能把泛函分析和实际问题在一起的另一个重要方向是调和分析(Harmonic Analysis)。我在这里列举它的两个个子领域,傅立叶分析和小波分析,我想这已经能说明它的实际价值。它研究的最核心的问题就是怎么用基函数去逼近和构造一个函数。它研究的是函数空间的问题,不可避免的必须以泛函分析为基础。除了傅立叶和小波,调和分析还研究一些很有用的函数空间,比如Hardy space,Sobolev space,这些空间有很多很好的性质,在工程中和物理学中都有很重要的应用。对于vision来说,调和分析在信号的表达,图像的构造,都是非常有用的工具。

当分析和线性代数走在一起,产生了泛函分析和调和分析;当分析和群论走在一起,我们就有了李群(Lie Group)和李代数(Lie Algebra)。它们给连续群上的元素赋予了代数结构。我一直认为这是一门非常漂亮的数学:在一个体系中,拓扑,微分和代数走到了一起。在一定条件下,通过李群和李代数的联系,它让几何变换的结合变成了线性运算,让子群化为线性子空间,这样就为Learning中许多重要的模型和算法的引入到对几何运动的建模创造了必要的条件。因此,我们相信李群和李代数对于vision有着重要意义,只不过学习它的道路可能会很艰辛,在它之前需要学习很多别的数学。

 

现代概率论:在现代分析基础上再生 

最后,再简单说说很多Learning的研究者特别关心的数学分支:概率论。自从Kolmogorov在上世纪30年代把测度引入概率论以来,测度理论就成为现代概率论的基础。在这里,概率定义为测度,随机变量定义为可测函数,条件随机变量定义为可测函数在某个函数空间的投影,均值则是可测函数对于概率测度的积分。值得注意的是,很多的现代观点,开始以泛函分析的思路看待概率论的基础概念,随机变量构成了一个向量空间,而带符号概率测度则构成了它的对偶空间,其中一方施加于对方就形成均值。角度虽然不一样,不过这两种方式殊途同归,形成的基础是等价的。

在现代概率论的基础上,许多传统的分支得到了极大丰富,最有代表性的包括鞅论(Martingale)——由研究赌博引发的理论,现在主要用于金融(这里可以看出赌博和金融的理论联系,:-P),布朗运动(Brownian Motion)——连续随机过程的基础,以及在此基础上建立的随机分析(Stochastic Calculus),包括随机积分(对随机过程的路径进行积分,其中比较有代表性的叫伊藤积分(Ito Integral)),和随机微分方程。对于连续几何运用建立概率模型以及对分布的变换的研究离不开这些方面的知识。

 

终于写完了——也谢谢你把这么长的文章看完,希望其中的一些内容对你是有帮助的。

 | 433 views | 0 comments | 0 flags | 

【转】Linux虚拟地址空间布局

http://www.cnblogs.com/clover-toeic/p/3754433.html

 

在多任务操作系统中,每个进程都运行在属于自己的内存沙盘中。这个沙盘就是虚拟地址空间(Virtual Address Space),在32位模式下它是一个4GB的内存地址块。在Linux系统中, 内核进程和用户进程所占的虚拟内存比例是1:3,而Windows系统为2:2(通过设置Large-Address-Aware Executables标志也可为1:3)。这并不意味着内核使用那么多物理内存,仅表示它可支配这部分地址空间,根据需要将其映射到物理内存。

虚拟地址通过页表(Page Table)映射到物理内存,页表由操作系统维护并被处理器引用。内核空间在页表中拥有较高特权级,因此用户态程序试图访问这些页时会导致一个页错误(page fault)。在Linux中,内核空间是持续存在的,并且在所有进程中都映射到同样的物理内存。内核代码和数据总是可寻址,随时准备处理中断和系统调用。与此相反,用户模式地址空间的映射随进程切换的发生而不断变化。

Linux进程在虚拟内存中的标准内存段布局如下图所示:

其中,用户地址空间中的蓝色条带对应于映射到物理内存的不同内存段,灰白区域表示未映射的部分。这些段只是简单的内存地址范围,与Intel处理器的段没有关系。

上图中Random stack offset和Random mmap offset等随机值意在防止恶意程序。Linux通过对栈、内存映射段、堆的起始地址加上随机偏移量来打乱布局,以免恶意程序通过计算访问栈、库函数等地址。execve(2)负责为进程代码段和数据段建立映射,真正将代码段和数据段的内容读入内存是由系统的缺页异常处理程序按需完成的。另外,execve(2)还会将BSS段清零。

用户进程部分分段存储内容如下表所示(按地址递减顺序):

名称

存储内容

局部变量、函数参数、返回地址等

动态分配的内存

BSS段

未初始化或初值为0的全局变量和静态局部变量

数据段

已初始化且初值非0的全局变量和静态局部变量

代码段

可执行代码、字符串字面值、只读变量

在将应用程序加载到内存空间执行时,操作系统负责代码段、数据段和BSS段的加载,并在内存中为这些段分配空间。栈也由操作系统分配和管理;堆由程序员自己管理,即显式地申请和释放空间。

BSS段、数据段和代码段是可执行程序编译时的分段,运行时还需要栈和堆。

 

以下详细介绍各个分段的含义。

 

1 内核空间

内核总是驻留在内存中,是操作系统的一部分。内核空间为内核保留,不允许应用程序读写该区域的内容或直接调用内核代码定义的函数。

 

2 栈(stack)

栈又称堆栈,由编译器自动分配释放,行为类似数据结构中的栈(先进后出)。堆栈主要有三个用途:

  • 为函数内部声明的非静态局部变量(C语言中称“自动变量”)提供存储空间。
  • 记录函数调用过程相关的维护性信息,称为栈帧(Stack Frame)或过程活动记录(Procedure Activation Record)。它包括函数返回地址,不适合装入寄存器的函数参数及一些寄存器值的保存。除递归调用外,堆栈并非必需。因为编译时可获知局部变量,参数和返回地址所需空间,并将其分配于BSS段。
  • 临时存储区,用于暂存长算术表达式部分计算结果或alloca()函数分配的栈内内存。

持续地重用栈空间有助于使活跃的栈内存保持在CPU缓存中,从而加速访问。进程中的每个线程都有属于自己的栈。向栈中不断压入数据时,若超出其容量就会耗尽栈对应的内存区域,从而触发一个页错误。此时若栈的大小低于堆栈最大值RLIMIT_STACK(通常是8M),则栈会动态增长,程序继续运行。映射的栈区扩展到所需大小后,不再收缩。

Linux中ulimit -s命令可查看和设置堆栈最大值,当程序使用的堆栈超过该值时, 发生栈溢出(Stack Overflow),程序收到一个段错误(Segmentation Fault)。注意,调高堆栈容量可能会增加内存开销和启动时间。

堆栈既可向下增长(向内存低地址)也可向上增长, 这依赖于具体的实现。本文所述堆栈向下增长。

堆栈的大小在运行时由内核动态调整。

 

3 内存映射段(mmap)

此处,内核将硬盘文件的内容直接映射到内存, 任何应用程序都可通过Linux的mmap()系统调用或Windows的CreateFileMapping()/MapViewOfFile()请求这种映射。内存映射是一种方便高效的文件I/O方式, 因而被用于装载动态共享库。用户也可创建匿名内存映射,该映射没有对应的文件, 可用于存放程序数据。在 Linux中,若通过malloc()请求一大块内存,C运行库将创建一个匿名内存映射,而不使用堆内存。”大块” 意味着比阈值 MMAP_THRESHOLD还大,缺省为128KB,可通过mallopt()调整。

该区域用于映射可执行文件用到的动态链接库。在Linux 2.4版本中,若可执行文件依赖共享库,则系统会为这些动态库在从0×40000000开始的地址分配相应空间,并在程序装载时将其载入到该空间。在Linux 2.6内核中,共享库的起始地址被往上移动至更靠近栈区的位置。

从进程地址空间的布局可以看到,在有共享库的情况下,留给堆的可用空间还有两处:一处是从.bss段到0×40000000,约不到1GB的空间;另一处是从共享库到栈之间的空间,约不到2GB。这两块空间大小取决于栈、共享库的大小和数量。这样来看,是否应用程序可申请的最大堆空间只有2GB?事实上,这与Linux内核版本有关。在上面给出的进程地址空间经典布局图中,共享库的装载地址为0×40000000,这实际上是Linux kernel 2.6版本之前的情况了,在2.6版本里,共享库的装载地址已经被挪到靠近栈的位置,即位于0xBFxxxxxx附近,因此,此时的堆范围就不会被共享库分割成2个“碎片”,故kernel 2.6的32位Linux系统中,malloc申请的最大内存理论值在2.9GB左右。

 

4 堆(heap)

堆用于存放进程运行时动态分配的内存段,可动态扩张或缩减。堆中内容是匿名的,不能按名字直接访问,只能通过指针间接访问。当进程调用malloc(C)/new(C++)等函数分配内存时,新分配的内存动态添加到堆上(扩张);当调用free(C)/delete(C++)等函数释放内存时,被释放的内存从堆中剔除(缩减) 。

分配的堆内存是经过字节对齐的空间,以适合原子操作。堆管理器通过链表管理每个申请的内存,由于堆申请和释放是无序的,最终会产生内存碎片。堆内存一般由应用程序分配释放,回收的内存可供重新使用。若程序员不释放,程序结束时操作系统可能会自动回收。

堆的末端由break指针标识,当堆管理器需要更多内存时,可通过系统调用brk()和sbrk()来移动break指针以扩张堆,一般由系统自动调用。

使用堆时经常出现两种问题:1) 释放或改写仍在使用的内存(“内存破坏”);2)未释放不再使用的内存(“内存泄漏”)。当释放次数少于申请次数时,可能已造成内存泄漏。泄漏的内存往往比忘记释放的数据结构更大,因为所分配的内存通常会圆整为下个大于申请数量的2的幂次(如申请212B,会圆整为256B)。

注意,堆不同于数据结构中的”堆”,其行为类似链表。

【扩展阅读】栈和堆的区别

管理方式:栈由编译器自动管理;堆由程序员控制,使用方便,但易产生内存泄露。

生长方向:栈向低地址扩展(即”向下生长”),是连续的内存区域;堆向高地址扩展(即”向上生长”),是不连续的内存区域。这是由于系统用链表来存储空闲内存地址,自然不连续,而链表从低地址向高地址遍历。

空间大小:栈顶地址和栈的最大容量由系统预先规定(通常默认2M或10M);堆的大小则受限于计算机系统中有效的虚拟内存,32位Linux系统中堆内存可达2.9G空间。

存储内容:栈在函数调用时,首先压入主调函数中下条指令(函数调用语句的下条可执行语句)的地址,然后是函数实参,然后是被调函数的局部变量。本次调用结束后,局部变量先出栈,然后是参数,最后栈顶指针指向最开始存的指令地址,程序由该点继续运行下条可执行语句。堆通常在头部用一个字节存放其大小,堆用于存储生存期与函数调用无关的数据,具体内容由程序员安排。

分配方式:栈可静态分配或动态分配。静态分配由编译器完成,如局部变量的分配。动态分配由alloca函数在栈上申请空间,用完后自动释放。堆只能动态分配且手工释放。

分配效率:栈由计算机底层提供支持:分配专门的寄存器存放栈地址,压栈出栈由专门的指令执行,因此效率较高。堆由函数库提供,机制复杂,效率比栈低得多。Windows系统中VirtualAlloc可直接在进程地址空间中分配一块内存,快速且灵活。

分配后系统响应:只要栈剩余空间大于所申请空间,系统将为程序提供内存,否则报告异常提示栈溢出。

操作系统为堆维护一个记录空闲内存地址的链表。当系统收到程序的内存分配申请时,会遍历该链表寻找第一个空间大于所申请空间的堆结点,然后将该结点从空闲结点链表中删除,并将该结点空间分配给程序。若无足够大小的空间(可能由于内存碎片太多),有可能调用系统功能去增加程序数据段的内存空间,以便有机会分到足够大小的内存,然后进行返回。,大多数系统会在该内存空间首地址处记录本次分配的内存大小,供后续的释放函数(如free/delete)正确释放本内存空间。

此外,由于找到的堆结点大小不一定正好等于申请的大小,系统会自动将多余的部分重新放入空闲链表中。

碎片问题:栈不会存在碎片问题,因为栈是先进后出的队列,内存块弹出栈之前,在其上面的后进的栈内容已弹出。而频繁申请释放操作会造成堆内存空间的不连续,从而造成大量碎片,使程序效率降低。

可见,堆容易造成内存碎片;由于没有专门的系统支持,效率很低;由于可能引发用户态和内核态切换,内存申请的代价更为昂贵。所以栈在程序中应用最广泛,函数调用也利用栈来完成,调用过程中的参数、返回地址、栈基指针和局部变量等都采用栈的方式存放。所以,建议尽量使用栈,仅在分配大量或大块内存空间时使用堆。

使用栈和堆时应避免越界发生,否则可能程序崩溃或破坏程序堆、栈结构,产生意想不到的后果。

 

5 BSS段

BSS(Block Started by Symbol)段中通常存放程序中以下符号:

  • 未初始化的全局变量和静态局部变量
  • 初始值为0的全局变量和静态局部变量(依赖于编译器实现)
  • 未定义且初值不为0的符号(该初值即common block的大小)

C语言中,未显式初始化的静态分配变量被初始化为0(算术类型)或空指针(指针类型)。由于程序加载时,BSS会被操作系统清零,所以未赋初值或初值为0的全局变量都在BSS中。BSS段仅为未初始化的静态分配变量预留位置,在目标文件中并不占据空间,这样可减少目标文件体积。但程序运行时需为变量分配内存空间,故目标文件必须记录所有未初始化的静态分配变量大小总和(通过start_bss和end_bss地址写入机器代码)。当加载器(loader)加载程序时,将为BSS段分配的内存初始化为0。在嵌入式软件中,进入main()函数之前BSS段被C运行时系统映射到初始化为全零的内存(效率较高)。

注意,尽管均放置于BSS段,但初值为0的全局变量是强符号,而未初始化的全局变量是弱符号。若其他地方已定义同名的强符号(初值可能非0),则弱符号与之链接时不会引起重定义错误,但运行时的初值可能并非期望值(会被强符号覆盖)。因此,定义全局变量时,若只有本文件使用,则尽量使用static关键字修饰;否则需要为全局变量定义赋初值(哪怕0值),保证该变量为强符号,以便链接时发现变量名冲突,而不是被未知值覆盖。

某些编译器将未初始化的全局变量保存在common段,链接时再将其放入BSS段。在编译阶段可通过-fno-common选项来禁止将未初始化的全局变量放入common段。

此外,由于目标文件不含BSS段,故程序烧入存储器(Flash)后BSS段地址空间内容未知。U-Boot启动过程中将U-Boot的Stage2代码(通常位于lib_xxxx/board.c文件)搬迁(拷贝)到SDRAM空间后必须人为添加清零BSS段的代码,而不可依赖于Stage2代码中变量定义时赋0值。

【扩展阅读】BSS历史

BSS(Block Started by Symbol,以符号开始的块)一词最初是UA-SAP汇编器(United Aircraft Symbolic Assembly Program)中的伪指令,用于为符号预留一块内存空间。该汇编器由美国联合航空公司于20世纪50年代中期为IBM 704大型机所开发。

后来该词被作为关键字引入到了IBM 709和7090/94机型上的标准汇编器FAP(Fortran Assembly Program),用于定义符号并且为该符号预留指定字数的未初始化空间块。

在采用段式内存管理的架构中(如Intel 80×86系统),BSS段通常指用来存放程序中未初始化全局变量的一块内存区域,该段变量只有名称和大小却没有值。程序开始时由系统初始化清零。

BSS段不包含数据,仅维护开始和结束地址,以便内存能在运行时被有效地清零。BSS所需的运行时空间由目标文件记录,但BSS并不占用目标文件内的实际空间,即BSS节段应用程序的二进制映象文件中并不存在。

6 数据段(Data)

数据段通常用于存放程序中已初始化且初值不为0的全局变量和静态局部变量。数据段属于静态内存分配(静态存储区),可读可写。

数据段保存在目标文件中(在嵌入式系统里一般固化在镜像文件中),其内容由程序初始化。例如,对于全局变量int gVar = 10,必须在目标文件数据段中保存10这个数据,然后在程序加载时复制到相应的内存。

数据段与BSS段的区别如下:

1) BSS段不占用物理文件尺寸,但占用内存空间;数据段占用物理文件,也占用内存空间。

对于大型数组如int ar0[10000] = {1, 2, 3, …}和int ar1[10000],ar1放在BSS段,只记录共有10000*4个字节需要初始化为0,而不是像ar0那样记录每个数据1、2、3…,此时BSS为目标文件所节省的磁盘空间相当可观。

2) 当程序读取数据段的数据时,系统会出发缺页故障,从而分配相应的物理内存;当程序读取BSS段的数据时,内核会将其转到一个全零页面,不会发生缺页故障,也不会为其分配相应的物理内存。

运行时数据段和BSS段的整个区段通常称为数据区。某些资料中“数据段”指代数据段 + BSS段 + 堆。

7 代码段(text)

代码段也称正文段或文本段,通常用于存放程序执行代码(即CPU执行的机器指令)。一般C语言执行语句都编译成机器代码保存在代码段。通常代码段是可共享的,因此频繁执行的程序只需要在内存中拥有一份拷贝即可。代码段通常属于只读,以防止其他程序意外地修改其指令(对该段的写操作将导致段错误)。某些架构也允许代码段为可写,即允许修改程序。

代码段指令根据程序设计流程依次执行,对于顺序指令,只会执行一次(每个进程);若有反复,则需使用跳转指令;若进行递归,则需要借助栈来实现。

代码段指令中包括操作码和操作对象(或对象地址引用)。若操作对象是立即数(具体数值),将直接包含在代码中;若是局部数据,将在栈区分配空间,然后引用该数据地址;若位于BSS段和数据段,同样引用该数据地址。

代码段最容易受优化措施影响。

8 保留区

位于虚拟地址空间的最低部分,未赋予物理地址。任何对它的引用都是非法的,用于捕捉使用空指针和小整型值指针引用内存的异常情况。

它并不是一个单一的内存区域,而是对地址空间中受到操作系统保护而禁止用户进程访问的地址区域的总称。大多数操作系统中,极小的地址通常都是不允许访问的,如NULL。C语言将无效指针赋值为0也是出于这种考虑,因为0地址上正常情况下不会存放有效的可访问数据。

在32位X86架构的Linux系统中,用户进程可执行程序一般从虚拟地址空间0×08048000开始加载。该加载地址由ELF文件头决定,可通过自定义链接器脚本覆盖链接器默认配置,进而修改加载地址。0×08048000以下的地址空间通常由C动态链接库、动态加载器ld.so和内核VDSO(内核提供的虚拟共享库)等占用。通过使用mmap系统调用,可访问0×08048000以下的地址空间。

通过cat /proc/self/maps命令查看加载表如下:

【扩展阅读】分段的好处

进程运行过程中,代码指令根据流程依次执行,只需访问一次(当然跳转和递归可能使代码执行多次);而数据(数据段和BSS段)通常需要访问多次,因此单独开辟空间以方便访问和节约空间。具体解释如下:

当程序被装载后,数据和指令分别映射到两个虚存区域。数据区对于进程而言可读写,而指令区对于进程只读。两区的权限可分别设置为可读写和只读。以防止程序指令被有意或无意地改写。

现代CPU具有极为强大的缓存(Cache)体系,程序必须尽量提高缓存命中率。指令区和数据区的分离有利于提高程序的局部性。现代CPU一般数据缓存和指令缓存分离,故程序的指令和数据分开存放有利于提高CPU缓存命中率。

当系统中运行多个该程序的副本时,其指令相同,故内存中只须保存一份该程序的指令部分。若系统中运行数百进程,通过共享指令将节省大量空间(尤其对于有动态链接的系统)。其他只读数据如程序里的图标、图片、文本等资源也可共享。而每个副本进程的数据区域不同,它们是进程私有的。

此外,临时数据及需要再次使用的代码在运行时放入栈区中,生命周期短。全局数据和静态数据可能在整个程序执行过程中都需要访问,因此单独存储管理。堆区由用户自由分配,以便管理。

 | 1,133 views | 0 comments | 0 flags |