分类 观点 下的文章

Debian 项目组很悲伤地宣布 Debian 社区及项目失去了它的创立者 Ian Murdock。

Debian 只是 Ian 留给世人的一部分遗产,但也是 Ian 最为人所知的遗产之一。

Ian 很小就开始接触电脑。他对电脑从最初的好奇慢慢变得更加熟悉,在9岁的时候就开始经常写代码了。后来在 Krannert 管理学院的时候,有一门必修的编程课;这门课程强化了年轻的 Ian 对电脑的喜爱程度,也让他产生了让某些事情变得更好的想法。

1993年9月, Ian 启动了 Debian 项目;同年的晚些时候,发布了 Debian 的第一个版本。那个时候,Linux 发行版这样的概念还很新颖。正如 Ian 所说,这个想法是受 Linus Torvalds 所启发。Ian 发布 Debian 的目的很简单,他希望这个发行版能体现 Linux 和 GNU 的开源精神。

正是出于这个简单的目的,Ian 在软件世界掀起了一场运动。很多开发者加入 Ian 的项目,以在一个不断进步的世界里做出更好的软件。

正如 Ian 在 Debian 宣言 Debian Manifesto 中所说的那样:“Debian 的设计过程是公开的;这样做的目的是希望保证一流的软件质量,并且能反映和满足用户社区的需求。Debian 可以以模块化的方式进行开发,使得不同背景、不同技能的人都能参与进来。[...] 让不同的人参与也意味着可以在开发过程中博采众长、扬长避短。这样做,也可以让项目满足不同用户的需求而不仅仅是满足开发者的需求。”

他的主要关注点是创建一个 Linux 发行版和一种行正道的社区文化,无论是道义上还是技术上。

Debian 项目不断发布新版本,Debian 关于 软件自由 Software Freedom 的立场过去是、现在仍然是自由和开源世界的标杆。

Debian 0.01 版到 0.90 版在 1993年8月至93年12月之间发布。Ian Murdock写道:

“Debian 0.91 在1994年1月发布;这个版本有一个比较原始的包管理系统。[...] 那个时候,已经有些人加入到 Debian 的开发中来了,但是绝大部分时间还是我来准备发布的版本。0.91是最后一个这样弄出来的版本。”

“1994年的大部分时间花在了 Debian 项目的组织上,也因此,其它参与者能高效地为该项目添砖添瓦; 还有一部分时间花在了dpkg上[...]。”

"Debian 0.93 的第五个版本是在95年的三月份发布的,它也是 Debain 项目的第一个现代版:因为当时有很多开发者参与其中(虽然我记不得到底有多少个了);每个人维护他们自己的软件包;在安装完核心系统之后,当时我们用 dpkg 来管理这些软件包。”

“1995年发布了 Debian 0.93 版的第6个发布版本,这个版本也是 a.out 的最后一个版本(LCTT 译注:在 linux/unix 系统上,通过 gcc、g++ 来编译 C/C++ 程序时,如果没有指定 -o 参数,会默认生成名为 a.out 的目标二进制,这儿说明以前的开发管理相当原始,不是比较规范的那种方式来发布和管理相关的软件包)。当时大约有60多个开发者参与进来维护 0.93R6 的软件包。如果我没记错的话,dselect首先出现在093R6中。”

当他在1996年3月停止积极参与 Debian 项目之时,他表达了对 Debian 093R6 的钟爱;他说 0.93R6 “是我最喜欢的 Debian 版本”,虽然他也承认这有他的个人偏见在里面。

1996年3月,Ian Murdock 退出 Debian 项目的领导,并任命 Bruce Perens 作为 Debin 项目的新的领导人。

行正道这个理念一直影响着 Ian 的工作,包括 Debian 项目和其接下来数年的工作;他总是向着无限可能的明天而努力。

Debian 项目仍将前行,它会成为这个世界上随处可见的 通用操作系统 Universal Operating System 。无论在小的嵌入式设备上,还是庞大的集群系统上,再到空间站上“ 都能见到 Debian 的身影 of course it runs Debian ”。Debian 已被移植到了多种架构和硬件类型上。

Ian 的梦想永存:Debian 由一个强大的社区所缔造;这个社区孕育了新的开发方式,成长理念和好奇心。Debian 社区仍是最活跃的社区;数以千计的开发人员日日夜夜的工作,以为人们提供可靠的安全的操作系统。Debian 点燃了那些希望让世界变得更好的人的兴趣、好奇心与激情。这种影响旷日持久。

我们对 Ian 表示由衷的感谢。

我们在 Debian 的所有网站和和服务中用深色的主页旗帜广告及 logo 上的绶带表达了我们的反应和哀悼。在这段艰苦的时期,Debian 社区的关怀与 Ian 的家人同在。

他的家人希望保护他们的隐私,而我们也很愿意遵从他们的意愿。

在 Debian 社区内或 Linux 社区中的成员,可以将悼词发送至 [email protected] , 这些悼词将会被归档留存。

这个电子邮件地址将会在2016年1月末之前有效。而后 Debian 项目组将会将归档交给 Ian 的家人,若 Ian 的家人愿意,我们将在今年晚些时候公布其内容。


via: https://www.debian.org/News/2016/20160105

译者: hittlle, StdioA 校对: wxy

上周日在汉堡举行的 混沌通讯大会 Chaos Communication congress 上,两位来自德国的 IT 安全公司 ERNW GmbH 的研究人员揭秘了朝鲜的 红星操作系统 Red Star OS 的一些安全细节。

正如我们之前听到的消息那样,朝鲜的红星操作系统基于 Fedora Linux,目前的版本拥有类似 Mac OS 的外观。也许你认为它是一个安全的系统,或许是吧——只是可能和大部分人的标准不同。可能由于红星操作系统是由朝鲜政府所支持开发的,该操作系统在对“安全”方面上做到了一定程度的“可管可控”。

两位来自德国的 IT 安全公司 ERNW GmbH 的研究人员 Florian Grunow 和 Niklaus Schiess 深入研究了该操作系统,检查了其代码和运行方式。这个朝鲜本土制造的操作系统控制了其使用的许多方面,包括加密。这表明了朝鲜政府对西方通过软件进行渗透干预的担心。

他们从一个来自朝鲜境外的网站上下载到了该操作系统的镜像。从演示视频可以看到,操作系统的镜像大概有 2.5G。他们用 VMWare 的虚拟机安装了该操作系统。

他们告诉路透社:“金正日说朝鲜应该开发自己的操作系统,现在他们已经做到了。”由于平壤担心来自西方的干预和间谍活动,所以不是拥抱互联网而是构建了其国家局域网,仅允许访问官方媒体和几个官方许可的几个网站,但是朝鲜民众对此表示情绪稳定。

这一系统已经开发了超过十年,最新的版本大约开发于 2013 年,基于 Fedora Linux,放弃了之前的 Windows XP 风格的界面,而采用了 Mac OS 风格。这可能是来自金正恩的个人偏好,之前有照片显示他附近有一台苹果计算机的样子。

Grunow 说,红星操作系统是“一个大部分代码处于控制之下的完整操作系统”。根据对代码的深入分析,研究人员认为该操作系统基本上是从头构建的,并且包含了防止通过技术手段以绕过限制条件的功能:

“红星操作系统很难被篡改。如果用户对核心功能做了改动,比如试图禁用反病毒检查或防火墙,计算机就会显示一个错误消息或重启。”

开发独立的操作系统,并对代码进行控制,这或许是缘于朝鲜政府对西方通过后门进行渗透的担心。

该操作系统更危险的一个功能是,计算机上和连接的驱动器上的每个文件都会被打上水印。这可以跟踪到具体的人,政府可以据此追查某个文件的传播。Grunow 警告说:

“这绝对侵犯了隐私,它对用户并不透明,会悄悄完成跟踪,即便是你从未打开过的文件也会被追踪。”

但是红星操作系统也解决了一个问题,可以避免地下传播盗版的电影、音乐和文字。在朝鲜,人们通常通过 USB 盘和 microSD 卡来传播非法的文件,这让政府很难跟踪。但是通过红星操作系统,可以跟踪到计算机上和连接的驱动器上的每个文件,这意味着可以追溯到所有的文件。

一位在朝鲜的外国媒体的负责人 Nat Kretchun 说,这反映了平壤意识到了“需要新的监控和安全手段来面对新技术和新信息源”。

研究人员指出,并没有迹象表明朝鲜在所被指责的网络攻击中使用了这种操作系统。Grunow 说,“看起来就像是他们为自己使用而构建的操作系统,给用户提供了基本的应用软件”,包括韩文的文字处理器、日历和编撰乐曲的应用等。

目前还不知道朝鲜有多少计算机运行该操作系统。从去朝鲜的游客那里听到反映说,那里的个人计算机在逐渐增多,但是大多仍旧在使用 Windows XP。

参考信息来源:theguardianbetanews路透社

http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.html

This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference:

This document is also available in PDF format.

The document's metadata is available in BibTeX format.

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

Diomidis Spinellis Publications

© 2015 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

摘要

Unix 操作系统的进化历史,可以从一个版本控制仓库中窥见,时间跨度从 1972 年的 5000 行内核代码开始,到 2015 年成为一个含有 26,000,000 行代码的被广泛使用的系统。该仓库包含 659,000 条提交,和 2306 次合并。仓库部署了被普遍采用的 Git 系统用于储存其代码,并且在时下流行的 GitHub 上建立了存档。它由来自 贝尔实验室 Bell Labs 伯克利大学 Berkeley University ,386BSD 团队所开发的系统软件的 24 个快照综合定制而成,这包括两个老式仓库和一个开源 FreeBSD 系统的仓库。总的来说,可以确认其中的 850 位个人贡献者,更早些时候的一批人主要做基础研究。这些数据可以用于一些经验性的研究,在软件工程,信息系统和软件考古学领域。

1、介绍

Unix 操作系统作为一个主要的工程上的突破而脱颖而出,得益于其模范的设计、大量的技术贡献、它的开发模型及广泛的使用。Unix 编程环境的设计已经被视为一个提供非常简洁、强大而优雅的设计 [1] 。在技术方面,许多对 Unix 有直接贡献的,或者因 Unix 而流行的特性就包括 [2] :用高级语言编写的可移植部署的内核;一个分层式设计的文件系统;兼容的文件,设备,网络和进程间 I/O;管道和过滤架构;虚拟文件系统;和作为普通进程的可由用户选择的不同 shell。很早的时候,就有一个庞大的社区为 Unix 贡献软件 [3] ,[4,pp. 65-72] 。随时间流逝,这个社区不断壮大,并且以现在称为开源软件开发的方式在工作着 [5,pp. 440-442] 。Unix 和其睿智的晚辈们也将 C 和 C++ 编程语言、分析程序和词法分析生成器(yacclex)、文档编制工具(troffeqntbl)、脚本语言(awksedPerl)、TCP/IP 网络、和 配置管理系统 configuration management system SCSSRCSSubversionGit)发扬广大了,同时也形成了现代互联网基础设施和网络的最大的部分。

幸运的是,一些重要的具有历史意义的 Unix 材料已经保存下来了,现在保持对外开放。尽管 Unix 最初是由相对严格的协议发行,但在早期的开发中,很多重要的部分是通过 Unix 的版权拥有者之一(Caldera International) (LCTT 译注:2002年改名为 SCO Group)以一个自由的协议发行。通过将这些部分再结合上由 加州大学伯克利分校 University of California, Berkeley 和 FreeBSD 项目组开发或发布的开源软件,贯穿了从 1972 年六月二十日开始到现在的整个系统的开发。

通过规划和处理这些可用的快照以及或旧或新的配置管理仓库,将这些可用数据的大部分重建到一个新合成的 Git 仓库之中。这个仓库以数字的形式记录了过去44年来最重要的数字时代产物的详细的进化。下列章节描述了该仓库的结构和内容(第2节)、创建方法(第3节)和该如何使用(第4节)。

2、数据概览

这 1GB 的 Unix 历史仓库可以从 GitHub 上克隆 1 。如今 2 ,这个仓库包含来自 850 个贡献者的 659,000 个提交和 2,306 个合并。贡献者有来自 贝尔实验室 Bell Labs 的 23 个员工, 伯克利大学 Berkeley University 计算机系统研究组 Computer Systems Research Group (CSRG)的 158 个人,和 FreeBSD 项目的 660 个成员。

这个仓库的生命始于一个 Epoch 的标签,这里面只包含了证书信息和现在的 README 文件。其后各种各样的标签和分支记录了很多重要的时刻。

  • Research-VX 标签对应来自 贝尔实验室 Bell Labs 六个研究版本。从 Research-V1 (4768 行 PDP-11 汇编代码)开始,到以 Research-V7 (大约 324,000 行代码,1820 个 C 文件)结束。
  • Bell-32V 是第七个版本 Unix 在 DEC/VAX 架构上的移植。
  • BSD-X 标签对应 伯克利大学 Berkeley University 释出的 15 个快照。
  • 386BSD-X 标签对应该系统的两个开源版本,主要是 Lynne 和 William Jolitz 写的适用于 Intel 386 架构的内核代码。
  • FreeBSD-release/X 标签和分支标记了来自 FreeBSD 项目的 116 个发行版。

另外,以 -Snapshot-Development 为后缀的分支,表示该提交由来自一个以时间排序的快照文件序列而合成;而以一个 -VCS-Development 为后缀的标签,标记了有特定发行版出现的历史分支的时刻。

仓库的历史包含从系统开发早期的一些提交,比如下面这些。

commit c9f643f59434f14f774d61ee3856972b8c3905b1
Author: Dennis Ritchie <research!dmr>
Date:   Mon Dec 2 18:18:02 1974 -0500
    Research V5 development
    Work on file usr/sys/dmr/kl.c

两个发布之间的合并代表着系统发生了进化,比如 BSD 3 的开发来自 BSD2 和 Unix 32/V,它在 Git 仓库里正是被表示为带两个父节点的图形节点。

更为重要的是,以这种方式构造的仓库允许 git blame,就是可以给源代码行加上注释,如版本、日期和它们第一次出现相关联的作者,这样可以知道任何代码的起源。比如说,检出 BSD-4 这个标签,并在内核的 pipe.c 文件上运行一下 git blame,就会显示出由 Ken Thompson 写于 1974,1975 和 1979年的代码行,和 Bill Joy 写于 1980 年的。这就可以自动(尽管计算上比较费事)检测出任何时刻出现的代码。

图1:各个重大 Unix 发行版的代码来源

上图所示,现代版本的 Unix(FreeBSD 9)依然有相当部分的来自 BSD 4.3,BSD 4.3 Net/2 和 BSD 2.0 的代码块。有趣的是,这图片显示有部分代码好像没有保留下来,当时激进地要创造一个脱离于伯克利(386BSD 和 FreeBSD 1.0)所释出代码的开源操作系统。FreeBSD 9 中最古老的代码是一个 18 行的队列,在 C 库里面的 timezone.c 文件里,该文件也可以在第七版的 Unix 文件里找到,同样的名字,时间戳是 1979 年一月十日 - 36 年前。

3、数据收集和处理

这个项目的目的是以某种方式巩固从数据方面说明 Unix 的进化,通过将其并入一个现代的版本仓库,帮助人们对系统进化的研究。项目工作包括收录数据,分类并综合到一个单独的 Git 仓库里。

图2:导入 Unix 快照、仓库及其合并

项目以三种数据类型为基础(见图2)。首先,早期发布版本的快照,获取自 Unix 遗产社会归档 Unix Heritage Society archive 3 、包括了 CSRG 全部的源代码归档的 CD-ROM 镜像 4 Oldlinux 网站 5 FreeBSD 归档 6 。 其次,以前的和现在的仓库,即 CSRG SCCS [6] 仓库,FreeBSD 1 CVS 仓库,和现代 FreeBSD 开发的 Git 镜像 7 。前两个都是从和快照相同的来源获得的。

最后,也是最费力的数据源是 初步研究 primary research 。释出的快照并没有提供关于它们的源头和每个文件贡献者的信息。因此,这些信息片段需要通过 初步研究 primary research 验证。至于作者信息主要通过作者的自传,研究论文,内部备忘录和旧文档扫描件;通过阅读并且自动处理源代码和帮助页面补充;通过与那个年代的人用电子邮件交流;在 StackExchange 网站上贴出疑问;查看文件的位置(在早期的内核版本的源代码,分为 usr/sys/dmr/usr/sys/ken 两个位置);从研究论文和帮助手册披露的作者找到源代码,从一个又一个的发行版中获取。(有趣的是,第一和第二的 研究版 Research Edition 帮助页面都有一个 “owner” 部分,列出了作者(比如,Ken)及对应的系统命令、文件、系统调用或库函数。在第四版中这个部分就没了,而在 BSD 发行版中又浮现了 “Author” 部分。)关于作者信息更为详细地写在了项目的文件中,这些文件被用于匹配源代码文件和它们的作者和对应的提交信息。最后,关于源代码库之间的合并信息是获取自 NetBSD 项目所维护的 BSD 家族树 8

作为本项目的一部分而开发的软件和数据文件,现在可以在线获取 9 ,并且,如果有合适的网络环境,CPU 和磁盘资源,可以用来从头构建这样一个仓库。关于主要发行版的作者信息,都存储在本项目的 author-path 目录下的文件里。它们的内容中带有正则表达式的文件路径后面指出了相符的作者。可以指定多个作者。正则表达式是按线性处理的,所以一个文件末尾的匹配一切的表达式可以指定一个发行版的默认作者。为避免重复,一个以 .au 后缀的独立文件专门用于映射作者的 识别号 identifier 和他们的名字及 email。这样一个文件为每个与该系统进化相关的社区都建立了一个: 贝尔实验室 Bell Labs 伯克利大学 Berkeley University ,386BSD 和 FreeBSD。为了真实性的需要,早期 贝尔实验室 Bell Labs 发行版的 emails 都以 UUCP 注释 UUCP notation 方式列出(例如, research!ken)。FreeBSD 作者的识别映射,需要导入早期的 CVS 仓库,通过从如今项目的 Git 仓库里拆解对应的数据构建。总的来说,由 1107 行构成了注释作者信息的文件(828 个规则),并且另有 640 行用于映射作者的识别号到名字。

现在项目的数据源被编码成了一个 168 行的 Makefile。它包括下面的步骤。

Fetching 从远程站点复制和克隆大约 11GB 的镜像、归档和仓库。

Tooling 从 2.9 BSD 中为旧的 PDP-11 归档获取一个归档器,并调整它以在现代的 Unix 版本下编译;编译 4.3 BSD 的 compress 程序来解压 386BSD 发行版,这个程序不再是现代 Unix 系统的组成部分了。

Organizingtarcpio 解压缩包;合并第六个研究版的三个目录;用旧的 PDP-11 归档器解压全部一个 BSD 归档;挂载 CD-ROM 镜像,这样可以作为文件系统处理;合并第 8 和 62 的 386BSD 磁盘镜像为两个独立的文件。

Cleaning 恢复第一个研究版的内核源代码文件,这个可以通过 OCR 从打印件上得到近似其原始状态的的格式;给第七个研究版的源代码文件打补丁;移除发行后被添加进来的元数据和其他文件,为避免得到错误的时间戳信息;修复毁坏的 SCCS 文件;用一个定制的 Perl 脚本移除指定到多个版本的 CVS 符号、删除与现在冲突的 CVS Attr 文件、用 cvs2svn 将 CVS 仓库转换为 Git 仓库,以处理早期的 FreeBSD CVS 仓库。

在仓库 再现 representation 中有一个很有意思的部分就是,如何导入那些快照,并以一种方式联系起来,使得 git blame 可以发挥它的魔力。快照导入到仓库是基于每个文件的时间戳作为一系列的提交实现的。当所有文件导入后,就被用对应发行版的名字给标记了。然后,可以删除那些文件,并开始导入下一个快照。注意 git blame 命令是通过回溯一个仓库的历史来工作的,并使用 启发法 heuristics 来检测文件之间或文件内的代码移动和复制。因此,删除掉的快照间会产生中断,以防止它们之间的代码被追踪。

相反,在下一个快照导入之前,之前快照的所有文件都被移动到了一个隐藏的后备目录里,叫做 .ref(引用)。它们保存在那,直到下个快照的所有文件都被导入了,这时候它们就会被删掉。因为 .ref 目录下的每个文件都精确对应一个原始文件,git blame 可以知道多少源代码通过 .ref 文件从一个版本移到了下一个,而不用显示出 .ref 文件。为了更进一步帮助检测代码起源,同时增加 再现 representation 的真实性,每个发行版都被 再现 represented 为一个有增量文件的分支(-Development)与之前发行版之间的合并。

上世纪 80 年代时期,只有 伯克利大学 Berkeley University 开发的文件的一个子集是用 SCCS 版本控制的。在那个期间,我们的统一仓库里包含了来自 SCCS 的提交和快照的增量文件的导入数据。对于每个发行版,可用最近的时间戳找到该 SCCS 提交,并被标记为一个与发行版增量导入分支的合并。这些合并可以在图2 的中间看到。

将各种数据资源综合到一个仓库的工作,主要是用两个脚本来完成的。一个 780 行的 Perl 脚本(import-dir.pl)可以从一个单独的数据源(快照目录、SCCS 仓库,或者 Git 仓库)中,以 Git fast export 格式导出(真实的或者综合的)提交历史。输出是一个简单的文本格式,Git 工具用这个来导入和导出提交。其他方面,这个脚本以一些东西为参数,如文件到贡献者的映射、贡献者登录名和他们的全名间的映射、哪个导入的提交会被合并、哪些文件要处理和忽略、以及“引用”文件的处理。一个 450 行的 Shell 脚本创建 Git 仓库,并调用带适当参数的 Perl 脚本,来导入 27 个可用的历史数据资源。Shell 脚本也会运行 30 个测试,比较特定标签的仓库和对应的数据源,核对查看的目录中出现的和没出现的,并回溯查看分支树和合并的数量,git blamegit log 的输出。最后,调用 git 作垃圾收集和仓库压缩,从最初的 6GB 降到分发的 1GB 大小。

4、数据使用

该数据可以用于软件工程、信息系统和 软件考古学 software archeology 领域的经验性研究。鉴于它从不间断而独一无二的存在了超过了 40 年,可以供软件进化和跨代更迭参考。从那时以来,处理速度已经成千倍地增长、存储容量扩大了百万倍,该数据同样可以用于软件和硬件技术 交叉进化 co-evolution 的研究。软件开发从研究中心到大学,到开源社区的转移,可以用来研究组织文化对于软件开发的影响。该仓库也可以用于学习著名人物的实际编程,比如 Turing 奖获得者(Dennis Ritchie 和 Ken Thompson)和 IT 产业的大佬(Bill Joy 和 Eric Schmidt)。另一个值得学习的现象是代码的长寿,无论是单行的水平,或是作为那个时代随 Unix 发布的完整的系统(Ingres、 Lisp、 Pascal、 Ratfor、 Snobol、 TMP),和导致代码存活或消亡的因素。最后,因为该数据让 Git 感到了压力,底层的软件仓库存储技术达到了其极限,这会推动版本管理系统领域的工程进度。

图3:Unix 发行版的代码风格进化

图3 根据 36 个主要 Unix 发行版描述了一些有趣的代码统计的趋势线(用 R 语言的局部多项式回归拟合函数生成),验证了代码风格和编程语言的使用在很长的时间尺度上的进化。这种进化是软硬件技术的需求和支持、软件构筑理论,甚至社会力量所驱动的。图片中的日期计算了出现在一个给定发行版中的所有文件的平均日期。正如可以从中看到,在过去的 40 年中,标示符和文件名字的长度已经稳步从 4 到 6 个字符增长到 7 到 11 个字符。我们也可以看到注释数量的少量稳步增加,以及 goto 语句的使用量减少,同时 register 这个类型修饰符的消失。

5、未来的工作

可以做很多事情去提高仓库的正确性和有效性。创建过程以开源代码共享了,通过 GitHub 的 拉取请求 pull request ,可以很容易地贡献更多代码和修复。最有用的社区贡献将使得导入的快照文件的覆盖面增长,以便归属于某个具体的作者。现在,大约 90,000 个文件(在 160,000 总量之外)通过默认规则指定了作者。类似地,大约有 250 个作者(最初 FreeBSD 那些)仅知道其识别号。两个都列在了 build 仓库的 unmatched 目录里,欢迎贡献数据。进一步,BSD SCCS 和 FreeBSD CVS 的提交共享相同的作者和时间戳,这些可以结合成一个单独的 Git 提交。导入 SCCS 文件提交的支持会被添加进来,以便引入仓库对应的元数据。最后,也是最重要的,开源系统的更多分支会添加进来,比如 NetBSD、 OpenBSD、DragonFlyBSD 和 illumos。理想情况下,其他历史上重要的 Unix 发行版,如 System III、System V、 NeXTSTEP 和 SunOS 等的当前版权拥有者,也会在一个允许他们的合作伙伴使用仓库用于研究的协议下释出他们的系统。

鸣谢

本文作者感谢很多付出努力的人们。 Brian W. Kernighan, Doug McIlroy 和 Arnold D. Robbins 在贝尔实验室(Bell Labs)的登录识别号方面提供了帮助。 Clem Cole, Era Erikson, Mary Ann Horton, Kirk McKusick, Jeremy C. Reed, Ingo Schwarze 和 Anatole Shaw 在 BSD 的登录识别号方面提供了帮助。BSD SCCS 的导入代码是基于 H. Merijn Brand 和 Jonathan Gray 的工作。

这次研究由欧盟 ( 欧洲社会基金 European Social Fund,ESF ) 和 希腊国家基金 Greek national funds 通过 国家战略参考框架 National Strategic Reference Framework ,NSRF 的 Operational Program " Education and Lifelong Learning" - Research Funding Program: Thalis - Athens University of Economics and Business - Software Engineering Research Platform ,共同出资赞助。

引用

1 M. D. McIlroy, E. N. Pinson, and B. A. Tague, "UNIX time-sharing system: Foreword," The Bell System Technical Journal, vol. 57, no. 6, pp. 1899-1904, July-August 1978.

2 D. M. Ritchie and K. Thompson, "The UNIX time-sharing system," Bell System Technical Journal, vol. 57, no. 6, pp. 1905-1929, July-August 1978.

3 D. M. Ritchie, "The evolution of the UNIX time-sharing system," AT&T Bell Laboratories Technical Journal, vol. 63, no. 8, pp. 1577-1593, Oct. 1984.

4 P. H. Salus, A Quarter Century of UNIX. Boston, MA: Addison-Wesley, 1994.

5 E. S. Raymond, The Art of Unix Programming. Addison-Wesley, 2003.

6 M. J. Rochkind, "The source code control system," IEEE Transactions on Software Engineering, vol. SE-1, no. 4, pp. 255-265, 1975.

脚注

1 - https://github.com/dspinellis/unix-history-repo

2 - Updates may add or modify material. To ensure replicability the repository's users are encouraged to fork it or archive it.

3 - http://www.tuhs.org/archive_sites.html

4 - https://www.mckusick.com/csrg/

5 - http://www.oldlinux.org/Linux.old/distributions/386BSD

6 - http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/

7 - https://github.com/freebsd/freebsd

8 - http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/misc/bsd-family-tree

9 - https://github.com/dspinellis/unix-history-make


via: http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.html

作者:Diomidis Spinellis译者:wi-cuckoo 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

上周五,IESG( 互联网工程指导委员会 Internet Engineering Steering Group )批准了一个新的互联网标准,为 HTTP 增加了一个新状态码:451 Unavailable For Legal Reasons。还需要一点点工作就会发布为正式的 RFC ,不过现在已经可以用了。

缘起

几年前,英国政府要求 ISP 们对海盗湾的内容进行封挡,Terence Eden 就这个事情写了一个帖子,建议应该有一个不同的状态码来区分禁止访问的原因。这样的话,ISP 们就可以向他们的用户说明为什么这些资源不能访问。有人提议使用数字 451 作为状态码,也有各种其它的建议。

谷歌的 Tim Bray 受此启发,于前几年 HTTP 工作组 HTTP Working Group 提交了一份提案,他(及很多人)认为应该将由于技术原因的不可见与非技术原因的不可见区分开来:

  • 403 状态码,用于描述由于技术原因禁止访问
  • 451 状态码,则用于描述由于国家法律所要求而禁止访问

据说,451 这个数字来源于 Ray Bradbury 的一篇小说《 华氏 451 Fahrenheit 451 》。

发展

最初,对于这份提案,IETF HTTP 工作组的主席 Mark Nottingham 是拒绝的。因为 HTTP 状态码是有限的,虽然说从 400 到 499 有足足一百个位置,但是谁也不知道将来会有什么需求。而当时也没有任何需要让程序/机器来区分禁止访问的这两种情形,所以不应该浪费代码——最多,在 HTTP 首部或页面上呈现具体原因就可以了。

而 Tim 依旧坚持他的提案,并偶尔更新一下提案内容,和关心这件事的人谈论。

有一些站点开始实验性的使用这个状态码,不过这并不足以让 IESG 同意增加新的状态码。但是,随着网络上的审查的越来越多,比如欧盟政府要求 ISP 禁止对盗版内容的访问,而韩国、俄罗斯和其它一些国家会限制某些内容的访问等等,IESG 意识到网站需要能够区分这其中的不同。

此外,还有一些人希望能够自动找到和分类哪些内容是被审查的。这就需要一种机器可读的机制来区分 403 和 451 所代表的不同意义。

451 能做什么和不能做什么

虽然 451 状态码的原意是用于标示出哪些内容是被法律禁止访问的,比如可以用在网络设备上(比如防火墙)或 Web 服务器上。就目前已知的, GithubTwitterFacebookGoogle 都已经开始使用这个状态码来应对各个国家地区的审查要求了。

但是显然,451 状态码并不能标示出所有的被审查的内容,也许有些国家(比如英国)的法律要求不允许使用这个状态码。

本文内容编译自 Mark Nottingham 的博客、维基百科、Solidot 等来源。

据外媒 Softpedia 消息,移动数据领域的初创企业 Wandera 最近的一份调查报告显示,包括加拿大航空、亚航等四家大型航空公司在内的全球十余家航空、铁路、出租、票务等方面的大型公司由于没有部署移动端 HTTPS 访问,导致用户信息存在巨大的泄露风险!这些公司往往都已经在其网站上部署了 HTTPS 服务,但是其提供的针对手机的移动网站和 app 客户端的访问上,却没有相应的也使用 HTTPS 服务。这就导致了它们为每日高达50万用户访问所提供的服务存在着巨大的信息泄露风险。

网上订票惊爆信息泄露风险,你还敢在网上订票吗?

尤其是当用户使用不可靠的公用互联网接入,如咖啡馆、商场的免费 WIFI,通过手机浏览器或 app 客户端访问这些没有采用 HTTPS 的服务时,就存在很大的被截获各种私人敏感信息的风险,比如身份信息、用户名、密码,乃至于信用卡号码等。这些数据泄露风险从何时开始,造成了多大的数据泄露已不可考。报告披露后,已有公司采取技术手段解决了该安全风险。

该调查主要针对欧美国家,并未涉及到中国国内情况。但是据我们对国内的网站、移动网站及 app 客户端的 HTTPS 部署情况的了解,这种风险同样存在,甚至会更严重。

而另一方面,据 CNNIC 调查数据显示,截止至 2015 年上半年,手机支付、手机网购、手机旅行预订用户规模分别达到 2.76 亿、 2.70 亿和 1.68 亿。同样据 CNNIC 数据,超过 40% 的人会使用网吧、公共场所等场所的 WIFI 接入互联网。

综合来看,采用移动客户端进行网上交易,当使用不安全的网络接入时,如果所访问的网站又没有做好必要的安全措施时,就有很大的风险泄露访问者的个人敏感信息。

怎样才能避免这样的风险?难道不能网上订票了吗?

其实,避免这样的安全风险的解决方案已经有了,那就是网站服务商应该向用户提供符合安全标准的 HTTPS 服务,而不是采用老旧的、不安全的 HTTP 服务。这样,即便访问者所处的环境并非十分安全可靠,依旧可以极大地降低用户的风险。

什么是 HTTPS 呢?

HTTPS(全称:Hyper Text Transfer Protocol over Secure Socket Layer),是以安全为目标建立客户浏览器端与服务器端进行数据传输的通道,简单来说就是 HTTP 的安全版。它最初由网景公司创建出来并内置在其浏览器中。

HTTPS 之所以能够做到数据的安全传输,是通过 SSL/TLS 协议完成的。只有通信的双方才具备数据的加解密功能,而数据在中间通道的传输时已经加密。加密算法一般使用 AES 或 RSA 等,并且通过目前的科学分析,不大可能通过计算能力提升而使得正确配置的密码算法得到轻易地破解。

因此我们说,HTTPS是安全的。

为什么越来越多的网站选择 HTTPS?

近年来,重视安全的大厂商都在逐步加快网站部署 HTTPS 的速度。搜索引擎巨头 Google、淘宝天猫、百度等均全站启用 HTTPS,相信在未来,会有越来越多的网站加入全站 HTTPS 化的行列中。

为什么 HTTPS 如此受到青睐? 答案不言而喻,自然是因为 HTTPS 能够给网站带来更多的价值。这些价值主要体现在:

  1. 确保了流量的安全性,被拦截窃听后也无法获取真实信息,避免了隐私数据在网络上外泄的可能。这也是为什么所有的金融、支付类网站强制要求必须为 HTTPS 服务的原因。
  2. 安全性较高的网站往往在搜索引擎同类型中有着较高的排名。
  3. 浏览器的可信标识能够加强普通用户对网站的信任感。

既然 HTTPS 能够对网站带来非常实用的价值,可以预测的是,在安全这个需求越来越受到网民以及网站管理者重视的趋势下,未来 HTTPS 将彻底取代 HTTP,成为网站数据通信的主流方式。

如何部署 HTTPS ?

简单来说,作为网站服务提供方,你首先需要购买被主流浏览器所认可的 CA 颁发的 HTTPS 证书;然后依据你的 Web 服务器的不同,如 apache、nginx ,采用不同的配置,提供监听在 TCP/443 端口 HTTPS 服务;最后,要测试你的 HTTPS 服务是否功能正常、性能是否受到影响、是否影响了用户体验等方面。

具体的技术描述,就不在这里逐一展开了,请根据你的 IT 基础架构进行部署。一般而言,对于小型网站来说, 部署 HTTPS 服务还是比较简单的,但是对于规模较大、业务复杂的网站来说,部署 HTTPS 服务还是一项艰巨的工程。此外,据闻阿里云准备推出进行 HTTPS 服务封装的分布式服务,可以将你的 HTTP 服务无缝地封装成 HTTPS 服务,并且同时提供了服务加速(CDN)、攻击防护(WAF)和流量清洗(DDoS/CC)等功能。

部署了 HTTPS 服务,终于可以放心了?

当你终于部署好了 HTTPS 服务后,看到浏览器地址栏中的绿色标示,是不是感觉成就满满——妈妈再也不用担心我的用户信息被偷走了 :D

HTTPS 绿色标示

但是,且慢,其实你还只是接上了一块短板,还有一块短板依旧在流淌着水呢。

由于 HTTPS 服务对传输的内容进行了加密,理论上说,只有服务器端和客户端才能正确加密和解密数据,因此,你以前所用的基于云的 WAF (Web 应用防火墙)可能不支持 HTTPS,从而没法为你提供对 XSS 、SQL 注入等应用攻击层面的防护能力了。

通常的安全产品不能很好的支持 HTTPS 网站防护。其原因主要有:

  1. 目前的云防护或者是传统安全防护一般都是采用代理的模式。即采用将流量引入到安全防护产品中,通过检测分析,发现异常攻击,然后采取防护措施。但由于 HTTPS 对数据进行了加密,因此防护产品不能在应用层详细的解析出 HTTP 报文内容,自然不能识别攻击与合法流量,从而对威胁攻击束手无策。
  2. 由于涉及到建立连接的握手加解密协商,HTTPS 需要消耗的性能通常是 HTTP 的数倍。一般的防护产品没有搭建大规模防护集群的能力,因此无力做到大流量的 HTTPS 防护。

那好吧,你还可以购买硬件的 WAF 防火墙,但是,当 DDoS/CC 攻击和流量攻击如洪水般涌来时,你的 WAF 和线路能支撑多久?

是不是感觉踩下一块板,又翘起来另外一块?由于部署了 HTTPS ,从而导致原本可以防护应用层面攻击的分布式 WAF 服务反而不能用了?

另外,还有一件可能令你感到悲伤的事情,作为访问量蒸蒸日上的你的网站,采用 CDN 提供分布式的访问支持那简直是一定的,但是,目前支持 HTTPS 的 CDN 服务商还很少。

怎么办?难道使用 HTTPS 服务是个错误吗?

我来告诉你一个完整的解决方案……

以下是广告时间,阿里云云盾高防产品……什么,原来是软文?!

好吧,我们来谈谈技术问题。

本质上来说,云防护产品支持 HTTPS 是可行的,但是这里需要解决几个问题:

  1. 如何透明的解析 HTTPS 流量,并针对流量特征进行分析和处置?
  2. 如何避免升级到 HTTPS 所带来的处理能力降低、性能衰减的问题?

针对此种情况,阿里云云盾高防产品特别推出了支持 HTTPS 的应用层防护功能。其技术原理图如下:

阿里云云盾技术原理

实现的步骤为:

  1. 用户在云盾高防控制台中导入对应域名的证书私钥、配置域名信息。
  2. 客户端与云盾高防进行 SSL 握手协商,协商通过后,使用云盾颁发的证书及公钥加密数据。
  3. 云盾高防进行数据解密,进行安全防护分析后,将合法的流量重新加密传至服务器端,同时阻断掉非法的攻击流量。
  4. 服务器端进行数据解密,实现正常业务。

通过以上方式,在客户业务无任何改造的情况下,云盾帮助用户实现了全链路端到端的数据加密。与此同时,由于进行了数据解密,云盾具备了分析应用层数据的能力,因此具备了转发流量到指定地址,进行细粒度安全防护的能力。包括且不限于:

  1. 高达 300G 的 DDoS 防护能力。
  2. 海量的 CC 攻击防护能力(集群可支持千万级 QPS 的攻击流量清洗)。
  3. Web 应用漏洞攻击的阻断防护能力(包括 SQL 注入、XSS、命令注入、木马 Shell 等通用 Web 攻击形式)。
  4. 提供丰富多样的应用层数据报表,不仅包括安全的详细报表,同时也会覆盖到业务访问的数据情况。
  5. 支持对部署在阿里云之外的主机的安全防护。

当然,如果您对数据隐私安全性要求比较高,可能会比较担心私钥放在云盾上的安全性。针对这种顾虑,也有对应的私钥安全解决方案。

另外,如果您对于自己部署 HTTPS 服务感觉棘手,阿里云云盾也有计划在近期推出 HTTP 直接变身 HTTPS 的服务,支持 HTTP 用户在无需更改自身业务的前提下,升级变为 HTTPS。

更多详情,可以戳戳这个链接看看。

大约一年前,微软宣布开源了 .NET 框架的大部分。当时,Scott Hanselman 使用微软 Power BI 对代码库做了一个漂亮的分析。 现在一年过去了,我想要试试对以下问题做个解答:

微软开源了 .NET 框架的大部分之后,社区参与贡献了多少?

我着眼于以下三个项目做了分析,它们是 .NET 生态系统中最主要部分之一,也是 .NET 基金会内 最活跃/收藏/分支的项目之一:

  • Roslyn – .NET 编译器平台,提供了开源的 C# 和 Visual Basic 编译器,以及丰富的代码分析 API。
  • CoreCLR – .NET Core 运行时环境和底层库(mscorlib),它包括垃圾回收、JIT 编译器、基本的 .NET 数据类型和许多底层类。
  • CoreFX – .NET Core 基础库,包括 collections、文件系统、console、XML、异步以及其它方面的类。

数据来自哪里?

GitHub 自身已经内建了很多漂亮的图表了,你可以看看这一年来每月提交数的图表:

Commits Per Month

还可以看看每月动态

github stats - monthly pulse

但是要回答上面的问题,我需要更多的数据。幸运的是, GitHub 提供了非常全面的 API, 再配合上出色的 Octokit.net 库以及 brilliant LINQPad,我就很容易的得到了我所需的全部数据。如果你想要自己试试这些 API ,这儿有个示例的 LINQPad 脚本

然而,仅仅知道它的每月 “ 问题 issue 数量” 或 “接受的PR( 拉取请求 Pull Request )”并没有太大用处,这并不能告诉我们是谁提交了这些问题或 PR。 幸运的是, GitHub 典型的用户是有分类的,比如下图来自 Roslyn 第 670 号问题 ,我们可以看到是哪种类型的用户提交的备注:“ 拥有者 Owner ”、 “ 协作者 Collaborator ” 或者为空——这就是“社区”成员,比如下面的某人(我觉得)并没有在微软工作。

owner collaborator or community

结果呢?

现在我们可以得到我们所需的数据,也就可以生成结果了。

全部问题 - 按提交者分组

项目拥有者协作者社区全部
Roslyn481186715963944
CoreCLR86298487871
CoreFX3349117351980
全部90130762818

这里你可以看到拥有者和协作者在某些情况下占有主导地位,比如,在 Roslyn 项目中 60% 的问题是他们汇报的。但是在另外的例子中社区非常活跃,特别是在 CoreCLR 项目中社区成员汇报的问题超过了拥有者/协作者之和。造成这种情况的部分原因是项目的不同, CoreCLR 是 .NET 框架中最引人注目的部分,因为它包含了 .NET 开发者日常使用的大部分库,所以并不用对社区提交了很多改进建议和错误修复的事情感到惊奇。 另外, CoreCLR 已经出现了较长时间,社区已经使用了一段时间,也能找到它的一些不足的部分。而 Roslyn 则相对较新一些,还没有被太多的使用过,而且找到一个编译器的 bug 显然会更难。

全部已接受的 PR - 按提交者分组

项目拥有者协作者社区全部
Roslyn46520931182676
CoreCLR3785672011146
CoreFX51614094642389
全部13594069783

但是,如果我们来看一下已接受的 PR ,可以看到在这三个项目中社区的贡献量非常低,仅仅只有 12% 左右。不过,这并不令人吃惊,因为 PR 需要达到相当高的水准才能被接受。如果项目采用这种机制,首先你必须找到一个 “需要解决” up for grabs 的问题,然后如果你要改变 API 就必须通过代码审查,最后你必须在代码审查中符合可比性/性能提升/正确性等。所以,实际上 12% 是个相当不错的结果,接受的 PR 解决了不少的问题,特别是考虑到大部分贡献都是社区成员在工作之余完成的。

更新:关于对“需要解决”的要求,参见 David Kean这个评论,以及这条推来了解更多信息。“需要解决”是一个准则,旨在帮助新手,但是并不是必需的,你可以提交一个解决问题的 PR 而不打上这个标签。

最后,如果你看一下每月的数量(参见下面的两张图,点击放大),很难找到特定的趋势,或者说,社区肯定会随着时间的变化或多或少的做出贡献。不过,你也可以说,过去一年来社区一直在做贡献,而且看起来还会继续贡献下去。这不是仅仅出现在项目刚刚开源后的一次性喷发,而是一整年以来的贡献的持续水平。

每月的问题数 - 按提交者分组

Issues Per Month - By Submitter (Owner, Collaborator or Community)

每月接受的 PR - 按提交者分组

Merged Pull Requests Per Month - By Submitter (Owner, Collaborator or Community)

前 20 的问题标签

最后一件我想对我拥有的这些数据所做的事情是找到那些最流行的问题标签,这可以揭示从三个项目开源以来哪种类型的工作不断出现。

Top 20 Issue Labels

以下是关于这些结果的一些看法: