蚊章汇 - 2016年9月
type: channel
link: https://linuxcn.bwsl.wang/2016/09/
description: Linux中国社区镜像站，没有大保镖。
items: 科学音频处理（二）：如何使用 Octave 对音频文件进行基本数学信号处理
items: Linux 发行版们应该禁用 IPv4 映射的 IPv6 地址吗？
items: AWS 和 GCP 的 Spark 技术哪家强？
items: 在 Ubuntu 16.04 上安装和使用服务器监控报警系统 Shinken
items: 你该选择 openSUSE 的五大理由
items: 关于“Linux中国” RSS 的一个调查问卷，如果你在用，请来看看
items: Mozilla 将封杀沃通和 StartSSL 一年内新签发的所有证书
items: 5 个值得了解的 Linux 服务器发行版
items: 是时候合并 LibreOffice 和 OpenOffice 了
items: 漫游 HTTP/2

科学音频处理（二）：如何使用 Octave 对音频文件进行基本数学信号处理
type: item
date: 2016-09-30T22:26:20+08:00
description: 在前一篇的指导教程中，我们看到了读、写以及重放音频文件的简单步骤，我们甚至看到如何从一个周期函数比如余弦函数合成一个音频文件。在这篇指导教程中，我们将会看到如何对信号进行叠加和倍乘（调整），并应用一些基本的数学函数看看它们对原始信号的影响。信号叠加两个信号 S1（t）和 S2（t）相加形成一个新的信号 R(t)，这个信号在任何瞬间的值等于构成它的两个信号在那个时刻的值之和。就像下面这样：R(t) = S1(t) + S2(t) 我们将用 Octave 重新产生两个信号的和并通过图表看达到的效果。首先，我们生成两个不同频率的信号，看一看它们的叠加信号是什么样的。第一步：产生两个不同频率的信号（oog 文件）>> sig1='cos440.ogg'; %creating the audio file @440 Hz >> sig2='cos880.ogg'; %creating the audio file @880 Hz >> fs=44100; %generating the parameters values (Period, sampling frequency and angular frequency) >> t=0:1/fs:0.02; >> w1=2*pi*440*t; >> w2=2*pi*880*t; >> audiowrite(sig1,cos(w1),fs); %writing the function cos(w) on the files created >> audiowrite(sig2,cos(w2),fs); 然后我们绘制出两个信号的图像。信号 1 的图像（440 赫兹）>> [y1, fs] = audioread(sig1); >> plot(y1) 信号 2 的图像（880 赫兹）>> [y2, fs] = audioread(sig2); >> plot(y2) 第二步：把两个信号叠加现在我们展示一下前面步骤中产生的两个信号的和。>> sumres=y1+y2; >> plot(sumres) 叠加信号的图像Octaver 中的效果在 Octaver 中，这个效果产生的声音是独特的，因为它可以仿真音乐家弹奏的低八度或者高八度音符（取决于内部程序设计），仿真音符和原始音符成对，也就是两个音符发出相同的声音。第三步：把两个真实的信号相加（比如两首音乐歌曲）为了实现这个目的，我们使用 格列高利圣咏 （ Gregorian Chants ） 中的两首歌曲（声音采样）。 圣母颂曲 （ Avemaria Track ） 首先，我们看一下圣母颂曲并绘出它的图像：>> [y1,fs]=audioread('avemaria_.ogg'); >> plot(y1) 赞美诗曲 （ Hymnus Track ） 现在我们看一下赞美诗曲并绘出它的图像。>> [y2,fs]=audioread('hymnus.ogg'); >> plot(y2) 圣母颂曲 + 赞美诗曲>> y='avehymnus.ogg'; >> audiowrite(y, y1+y2, fs); >> [y, fs]=audioread('avehymnus.ogg'); >> plot(y) 结果，从音频的角度来看，两个声音信号混合在了一起。两个信号的乘积对于求两个信号的乘积，我们可以使用类似求和的方法。我们使用之前生成的相同文件。R(t) = S1(t) * S2(t) >> sig1='cos440.ogg'; %creating the audio file @440 Hz >> sig2='cos880.ogg'; %creating the audio file @880 Hz >> product='prod.ogg'; %creating the audio file for product >> fs=44100; %generating the parameters values (Period, sampling frequency and angular frequency) >> t=0:1/fs:0.02; >> w1=2*pi*440*t; >> w2=2*pi*880*t; >> audiowrite(sig1, cos(w1), fs); %writing the function cos(w) on the files created >> audiowrite(sig2, cos(w2), fs);>> [y1,fs]=audioread(sig1);>> [y2,fs]=audioread(sig2); >> audiowrite(product, y1.*y2, fs); %performing t…

Linux 发行版们应该禁用 IPv4 映射的 IPv6 地址吗？
type: item
date: 2016-09-30T21:55:00+08:00
description: 从各方面来看，互联网向 IPv6 的过渡是件很缓慢的事情。不过在最近几年，可能是由于 IPv4 地址资源的枯竭，IPv6 的使用处于上升态势。相应的，开发者也有兴趣确保软件能在 IPv4 和 IPv6 下工作。但是，正如近期 OpenBSD 邮件列表中的讨论所关注的，一个使得向 IPv6 转换更加轻松的机制设计同时也可能导致网络更不安全——并且 Linux 发行版们的默认配置可能并不安全。地址映射IPv6 在很多方面看起来可能很像 IPv4，但它是一个不同地址空间的不同的协议。服务器程序想要接受使用二者之中任意一个协议的连接，必须给两个不同的地址族分别打开一个套接字——IPv4 的 AF_INET 和 IPv6 的 AF_INET6。特别是一个程序希望在主机上的使用两种地址协议的任意接口都接受连接的话，需要创建一个绑定到全零通配符地址（0.0.0.0）的 AF_INET 套接字和一个绑定到 IPv6 等效地址（写作 ::）的 AF_INET6 套接字。它必须在两个套接字上都监听连接——或者有人会这么认为。多年前，在 RFC 3493，IETF 指定了一个机制，程序可以使用一个单独的 IPv6 套接字工作在两个协议之上。有了一个启用这个行为的套接字，程序只需要绑定到 :: 地址从而在所有接口上接受使用这两个协议的连接。当创建了一个 IPv4 连接到该绑定端口，源地址会像 RFC 2373 中描述的那样映射到 IPv6。所以，举个例子，一个使用了这个模式的程序会将一个 192.168.1.1 的传入连接看作来自 ::ffff:192.168.1.1（这个混合的写法就是这种地址的通常写法）。程序也能通过相同的映射方法打开一个到 IPv4 地址的连接。RFC 要求默认实现这个行为，所以大多数系统这么做了。不过也有些例外，OpenBSD 就是其中之一；在那里，希望在两种协议下工作的程序能做的只能是创建两个独立的套接字。但一个在 Linux 中打开两个套接字的程序会遇到麻烦：IPv4 和 IPv6 套接字都会尝试绑定到 IPv4 地址，所以不论是哪个，后者都会失败。换句话说，一个绑定到 :: 指定端口的套接字的程序会同时绑定到那个端口上的 IPv6 的 :: 和 IPv4 的 0.0.0.0 地址。如果程序之后尝试绑定一个 IPv4 套接字到 0.0.0.0 的相同端口上时，这个操作会失败，因为这个端口已经被绑定了。当然有个办法可以解决这个问题；程序可以调用 setsockopt() 来打开 IPV6_V6ONLY 选项。一个打开两个套接字并且设置了 IPV6_V6ONLY 的程序应该可以在所有的系统间移植。读者们可能对不是每个程序都能正确处理这一问题没那么震惊。事实证明，这些程序的其中之一是 网络时间协议 （ Network Time Protocol ） 的 OpenNTPD 实现。Brent Cook 最近给上游 OpenNTPD 源码提交了一个小补丁，添加了必要的 setsockopt() 调用，它也被提交到了 OpenBSD 中了。不过那个补丁看起来不大可能被接受，最可能的原因是因为 OpenBSD 式的理由（LCTT 译注：如前文提到的，OpenBSD 并不受这个问题的影响）。安全担忧正如上文所提到，OpenBSD 根本不支持 IPv4 映射的 IPv6 套接字。即使一个程序试着通过将 IPV6_V6ONLY 选项设置为 0 来显式地启用地址映射，它的作者也会感到沮丧，因为这个设置在 OpenBSD 系统中无效。这个决定背后的原因是这个映射带来了一些安全隐忧。攻击打开的接口的攻击类型有很多种，但它们最后都会回到规定的两个途径到达相同的端口，每个端口都有它自己的控制规则。任何给定的服务器系统可能都设置了防火墙规则，描述端口的允许访问权限。也许还会有适当的机制，比如 TCP wrappers 或一个基于 BPF 的过滤器，或一个网络上的路由器可以做连接状态协议过滤。结果可能是导致防火墙保护和潜在的所有类型的混乱连接之间的缺口造成同一 IPv4 地址可以通过两个不同的协议到达。如果地址映射是在网络边界完成的，情况甚至会变得更加复杂；参看这个 2003 年的 RFC 草案，它描述了如果映射地址在主机之间传播，一些随之而来的其它攻击场景。改变系统和软件正确地处理 IPv4 映射的 IPv6 地址当然可以实现。但那增加了系统的整体复杂度，并且可以确定这个改动没有实际地完整实现到它应该实现的范围内。如同 Theo de Raadt 说的：有时候人们将一个糟糕的想法放进了 RFC。之后他们发现这个想法是不可能的就将它丢回垃圾箱了。结果就是概念变得如此复杂，每个人都得在管理和编码方面是个全职专家。我们也根本不清楚这些全职专家有多少在实际配置使用…

AWS 和 GCP 的 Spark 技术哪家强？
type: item
date: 2016-09-30T16:49:00+08:00
description: Tianhui Michael Li 和 Ariel M’ndange-Pfupfu 将在今年 10 月 10、12 和 14 号组织一个在线经验分享课程：Spark 分布式计算入门。该课程的内容包括创建端到端的运行应用程序和精通 Spark 关键工具。毋庸置疑，云计算将会在未来数据科学领域扮演至关重要的角色。弹性，可扩展性和按需分配的计算能力作为云计算的重要资源，直接导致云服务提供商集体火拼。其中最大的两股势力正是亚马逊网络服务（AWS) 和谷歌云平台（GCP)。本文依据构建时间和运营成本对 AWS 和 GCP 的 Spark 工作负载作一个简短比较。实验由我们的学生在 数据孵化器 （ The Data Incubator ） 进行， 数据孵化器 （ The Data Incubator ） 是一个大数据培训组织，专门为公司招聘顶尖数据科学家并为公司职员培训最新的大数据科学技能。尽管 Spark 效率惊人，分布式工作负载的时间和成本亦然可以大到不能忽略不计。因此我们一直努力寻求更高效的技术，以便我们的学生能够学习到最好和最快的工具。提交 Spark 任务到云Spark 是一个类 MapReduce 但是比 MapReduce 更灵活、更抽象的并行计算框架。Spark 提供 Python 和 Java 编程接口，但它更愿意用户使用原生的 Scala 语言进行应用程序开发。Scala 可以把应用程序和依赖文件打包在一个 JAR 文件从而使 Spark 任务提交变得简单。通常情况下，Sprark 结合 HDFS 应用于分布式数据存储，而与 YARN 协同工作则应用于集群管理；这种堪称完美的配合使得 Spark 非常适用于 AWS 的弹性 MapReduce （EMR）集群和 GCP 的 Dataproc 集群。这两种集群都已有 HDFS 和 YARN 预配置，不需要额外进行配置。配置云服务通过命令行比通过网页界面管理数据、集群和任务具有更高的可扩展性。对 AWS 而言，这意味着客户需要安装 CLI。客户必须获得证书并为每个 EC2 实例创建独立的密钥对。除此之外，客户还需要为 EMR 用户和 EMR 本身创建角色（基本权限），主要是准入许可规则，从而使 EMR 用户获得足够多的权限（通常在 CLI 运行 aws emr create-default-roles 就可以）。相比而言，GCP 的处理流程更加直接。如果客户选择安装 Google Cloud SDK 并且使用其 Google 账号登录，那么客户即刻可以使用 GCP 的几乎所有功能而无需其他任何配置。唯一需要提醒的是不要忘记通过 API 管理器启用计算引擎、Dataproc 和云存储 JSON 的 API。当你安装你的喜好设置好之后，有趣的事情就发生了！比如可以通过aws s3 cp或者gsutil cp命令拷贝客户的数据到云端。再比如客户可以创建自己的输入、输出或者任何其他需要的 bucket，如此，运行一个应用就像创建一个集群或者提交 JAR 文件一样简单。请确定日志存放的地方，毕竟在云环境下跟踪问题或者调试 bug 有点诡异。一分钱一分货谈及成本，Google 的服务在以下几个方面更有优势。首先，购买计算能力的原始成本更低。4 个 vCPU 和 15G RAM 的 Google 计算引擎服务（GCE）每小时只需 0.20 美元，如果运行 Dataproc，每小时也只需区区 0.24 美元。相比之下，同等的云配置，AWS EMR 则需要每小时 0.336 美元。其次，计费方式。AWS 按小时计费，即使客户只使用 15 分钟也要付足 1 小时的费用。GCP 按分钟计费，最低计费 10 分钟。在诸多用户案例中，资费方式的不同直接导致成本的巨大差异。两种云服务都有其他多种定价机制。客户可以使用 AWS 的 Sport Instance 或 GCP 的 Preemptible Instance 来竞价它们的空闲云计算能力。这些服务比专有的、按需服务便宜，缺点是不能保证随时有可用的云资源提供服务。在 GCP 上，如果客户长时间（每月的 25% 至 100%）使用服务，可以获取更多折扣。在 AWS 上预付费或者一次购买大批量服务可以节省不少费用。底线是，如果你是一个超级用户，并且使用云计算已经成为一种常态，那么最好深入研究云计算，自己算计好成本。最后，新手在 GCP 上体验云服务的费用较低。新手只需 300 美元信用担保，就可以免费试用 60 天 GCP 提供的全部云服务。AWS 只免费提供特定服务的特定试用层级，如果运行 Spark 任务，需要付费。这意味着初次体验 Spark，GCP 具有更多选择，也少了精打细算和讨价还价的烦恼。性能比拼我们通过实验检测一个典型 Spark 工…

在 Ubuntu 16.04 上安装和使用服务器监控报警系统 Shinken
type: item
date: 2016-09-29T22:09:58+08:00
description: Shinken 是一个用 Python 实现的开源的主机和网络监控框架，并与 Nagios like 兼容，它可以运行在所有支持 Python 程序的操作系统上，比如说 Linux、Unix 和 Windows。Shinken 是 Jean Gabes 为了验证一个新的 Nagios 架构思路而编写，但是这个想法被 Nagios 的作者拒绝后成为了一个独立的网络系统监视软件，并保持了与 Nagios 的兼容。在这篇教程中，我将会描述如何从源代码编译安装 Shinken 和向监视系统中添加一台 Linux 主机。我将会以 Ubuntu 16.04 Xenial Xerus 操作系统来作为 Shinken 服务器和所监控的主机。第一步 安装 Shinken 服务器Shinken 是一个 Python 框架，我们可以通过 pip 安装或者从源码来安装它，在这一步中，我们将用源代码编译安装 Shinken。在我们开始安装 Shinken 之前还需要完成几个步骤。安装一些新的 Python 软件包并创建一个名为 shinken 的系统用户：sudo apt-get install python-setuptools python-pip python-pycurl useradd -m -s /bin/bash shinken 从 GitHub 仓库下载 Shinken 源代码：git clone https://github.com/naparuba/shinken.git cd shinken/ 然后用以下命令安装 Shinken：git checkout 2.4.3 python setup.py install 然后，为了得到更好的效果，我们还需要从 Ubuntu 软件库中安装 python-cherrypy3 软件包：sudo apt-get install python-cherrypy3 到这里，Shinken 已经成功安装，接下来我们将 Shinken 添加到系统启动项并且启动它：update-rc.d shinken defaults systemctl start shinken 第二步 安装 Shinken Webui2Webui2 是 Shinken 的 Web 界面（在 shinken.io 可以找到）。最简单的安装 Shinken webui2 的方法是使用shinken CLI 命令（必须作为 shinken 用户执行）。切换到 shinken 用户：su - shinken 初始化 shiken 配置文件，下面的命令将会创建一个新的配置文件 .shinken.ini ：shinken --init 接下来用 shinken CLI 命令来安装 webui2：shinken install webui2 至此 webui2 已经安装好，但是我们还需要安装 MongoDB 和用 pip 来安装另一个 Python 软件包。在 root 下运行如下命令：sudo apt-get install mongodb pip install pymongo>=3.0.3 requests arrow bottle==0.12.8 接下来，切换到 shinken 目录下并且通过编辑 broker-master.cfg 文件来添加这个新的 webui2 模块：cd /etc/shinken/brokers/ vim broker-master.cfg 在第 40 行添加一个模块选项：modules webui2 保存文件并且退出编辑器。现在进入 contacts 目录下编辑 admin.cfg 来进行管理配置。cd /etc/shinken/contacts/ vim admin.cfg 按照如下修改：contact_name admin # Username 'admin' password yourpass # Pass 'mypass' 保存和退出。第三步 安装 Nagios 插件和 Shinken 软件包在这一步中，我们将安装 Nagios 插件和一些 Perl 模块。然后从 shinken.io 安装其他的软件包来实现监视。安装 Nagios 插件和安装 Perl 模块所需要的 cpanminus：sudo apt-get install nagios-plugins* cpanminus 用 cpanm 命令来安装 Perl 模块。cpanm Net::SNMP cpanm Time::HiRes cpanm DBI 现在我们创建一个 utils.pm 文件的链接到 shinken 的目录，并且为 Log_File_Health 创建了一个新的日志目录 。chmod u+s /usr/lib/nagios/pl…

你该选择 openSUSE 的五大理由
type: item
date: 2016-09-29T04:54:00+08:00
description: 多数的的桌面 Linux 用户都会选择三种发行版本：Debian/Ubuntu、Fedora 或者 Arch Linux。但是今天，我将给出你需要使用 openSUSE 的五大理由。相比其他的 Linux 发行版，我总能在 openSUSE 上看到一些令人耳目一新的东西。我说不太好，但它总是如此的闪亮和个性鲜明。这绿色的大蜥蜴是看起来如此的令人惊叹！但这并不是 openSUSE 即便不是最好也是要比其它发行版更好的原因！请别误解我。我在各种场合用过许多不同的 Linux 发行版，同时也很敬佩在这些发行版背后默默工作的开发者，是他们让计算变成一件快乐的事情。但是 openSUSE 一直让人感觉，嗯，令人崇敬——你是不是也这样觉得？openSUSE 比其他 Linux 发行版要好的五大理由你是不是认为我在说 openSUSE 是最好的 Linux 发行版？不，我并不是要表达这个意思。其实没有任何一个 Linux 发行版是最好的。它真的可以满足你寻找 “灵魂伴侣” 的需求。但在这里，我准备给大家说说，openSUSE 比其他发行版做得要好的五件事。如下：1 社区规则openSUSE 是一个典型的社区驱动型项目。我经常看到很多用户在升级后抱怨开发人员改变了他们喜欢的发行版。但在 openSUSE 不是这样，openSUSE 是纯社区驱动的项目，并且任何时候都朝着用户所希望的方向发展。2 系统的健壮性另外一个是操作系统的集成程度。我可以在同一个 openSUSE 系统上安装所有的最好的 Linux 桌面环境，而在 Ubuntu 上则因为系统的稳定性，坚决不允许用户这样做。而这恰好体现了一个系统的健壮程度。因此，对于那些喜欢自己动手完成每一件事的用户，openSUSE 还是很诱人的。3 易于安装软件在 Linux 的世界里有很多非常好用的包管理工具。从 Debian 的 apt-get 到 Fedora 的 DNF，它们无不吸引着用户，而且在这些发行版成为流行版本的过程中扮演着重要角色。openSUSE 同样有一个将软件传递到桌面的好方法。software.opensuse.org 是一个 Web 界面，你可以用它从仓库中获取安装软件。你所需要做的就是打开这个链接 (当然，是在 openSUSE 系统上)，在搜索框中输入你想要的软件，点击“直接安装”即可。就是这么简单，不是吗？听起来就像是在使用 Google 商店一样，是吗？4 YAST毫不夸张的说，YaST (LCTT 译注: YaST 是 openSUSE 和 SUSE Linux 企业版的安装和配置工具) 绝对是世界上有史以来操作系统上最好的控制中心。并且毫无疑问地，你可以使用它来操控系统上的一切：网络、软件升级以及所有的基础设置等。无论是 openSUSE 的个人版或是 SUSE Linux 企业版，你都能在 YaST 的强力支撑下，轻松的完成安装。总之，一个工具，方便而无所不能。5 开箱即用的极致体验SUSE 的团队是 Linux 内核中最大的贡献者团体之一。他们辛勤的努力也意味着，他们有足够的经验来应付不同的硬件条件。有着良好的硬件支持，一定会有很棒的开箱即用的体验。6 他们做了一些搞笑视频等等，不是说好了是五个理由吗？怎么多了一个！但因为 Abhishek 逼着我加进来，因为他们做的 Linux 的搞笑视频才使 openSUSE 成为了最好的发行版。开了个玩笑，不过还是看看 Uptime Funk，你将会知道为什么 SUSE 是最酷的 Linux 。LEAP 还是 TUMBLEWEED？该用哪一个！如果你现在想要使用 openSUSE 了，让我来告诉你，这两个 openSUSE 版本：LEAP 和 TUMBLEWEED。哪一个更合适你一点。尽管两者都提供了相似的体验和相似的环境，但还是需要你自行决定安装那个版本到你硬盘上。OPENSUSE : LEAPopenSUSE Leap 是一个普通的大众版本，基本上每八个月更新一次。目前最新的版本是 openSUSE 42.1。它所有的软件都是稳定版，给用户提供最顺畅的体验。对于家庭用户、办公和商业用户，是再合适不过的了。它合适那些想要一个稳定系统，而不必事事亲为，可以让他们安心工作的用户。只要进行正确的设置之后，你就不必担心其他事情，然后专心投入工作就好。同时，我也强烈建议图书馆和学校使用 Leap。OPENSUSE: TUMBLEWEEDTumbleweed version of openSUSE 是滚动式更新的版本。它定期更新系统中所使用的软件集的最新版本。对于想要使用最新软件以及想向 openSUSE 做出贡献的开发者和高级用户来说，这个版本绝对值得一试。需要指出的是，Tumbleweed 并不是 Leap 的 beta 和…

关于“Linux中国” RSS 的一个调查问卷，如果你在用，请来看看
type: item
date: 2016-09-28T19:11:00+08:00
description: 各位 “Linux 中国”的朋友们，无论你是在用电脑还是手机，无论你是用浏览器访问“Linux 中国”的网站还是用微信接收推送，抑或者你就是用 RSS 阅读软件一直订阅我们的频道的。那么这里有一个小小的调查，希望得到您的反馈。不长，一分钟就行。1、我不知道有这个东西1.1、我不会去订阅 RSS1.2、告诉我 RSS 地址在哪里，我去订阅2、我已经订阅了“Linux 中国”的 RSS2.1、RSS 订阅中有标题和摘要就行了，感兴趣我会点击链接的2.2、RSS 订阅还是要全文的，毕竟我不喜欢再打开浏览器请在下面发表您的评论即可。更新：本来发此文是考虑将现有的 RSS 从全文方式改为摘要方式——倒不是为了引流，而是为了规避部分恶意爬虫。不过没有想到得到了大家这么多的回复，而且使用 RSS 的人要比我预想中的多得多。虽然大家有不少人提到了有标题和摘要就可以了，不过也还有更多的人提到要全文，那就保持不变吧，还是全文好了~最后，谢谢大家的关注和回复，如有任何建议，请随时反馈给我们。更新2：增加了一个专门提供摘要方式的 RSS ：https://linux.cn/rss-digest.xml 大家可以试试（页面左上角也有链接）。如发现有不足之处，敬请提出。

Mozilla 将封杀沃通和 StartSSL 一年内新签发的所有证书
type: item
date: 2016-09-28T16:29:00+08:00
description: Firefox 浏览器背后的 Mozilla 基金会正在考虑对沃通（WoSign）及被其秘密收购的 StartCom（著名的 StartSSL 即其旗下产品）这两个 CA 一年内新签发的所有 SSL 证书进行封杀。Mozilla 的工程师是在对这两个 CA 签发了一系列可疑的 SSL SHA-1 证书进行调查之后，宣布了这个禁令。这两家 CA 试图规避 SHA-1 停用政策该问题主要是因为各大主要浏览器厂商共同决定从 2016 年 1 月 1 日开始就停止接受采用陈旧的 SHA-1 签名算法的证书。而 Mozilla 指责沃通今年还在签发 SHA-1 签名的证书，并将签发日期倒填成去年 12 月份。虽然 Mozilla 也允许一些其它的 CA 在 2016 年 1 月 1 日之后继续签发 SHA-1 证书，比如说赛门铁克，但是他们仅允许那些通过了复杂的审批流程的 CA 这样做，而显然沃通没有得到同意。沃通秘密收购了 StartCom此外，沃通似乎在否认其收购了以色列 CA 公司 StartCom。Mozilla 说，沃通已经于 2015 年 11 月 1 日百分百地收购了 StartCom。而另一方面，据奇虎 360 称，它共计持有 84% 的沃通股份。但是这些信息沃通此前都予以否认或拒绝发表意见。此外，在 Mozilla 披露的技术细节中显示，StartCom 已经开始使用沃通的基础架构来签发新的证书了。而且，StartCom 也和沃通一样在 2016 年采用了倒填日期的手段来签发 SHA-1 证书。Mozilla 的安全工程师也展示了这种违例的案例细节。Mozilla 的调查发现，一个和 GeoTrust CA 合作了多年的付费处理机构 Tyro 突然在 6 月中旬使用 StartCom 部署了一个 SHA-1 签名的证书，而此前该机构从未和 StartCom 有过合作。该证书看起来是在 2015 年 12 月 20 日签发的，而在同一个日期 StartCom 签发大量的 SHA-1 证书。Mozlla 发现这些证书部署于 2016 年中，这很不正常，这显然是采用倒填日期来规避 SHA-1 停用的策略。这些问题以及其它的更多问题让 Mozilla 决定在至少一年内不再信任沃通和 StartCom 的 SSL 证书。或许会永久封杀Mozilla 说这个临时封杀仅针对这两个公司最新签发的证书，不影响已经分发给他们的客户的证书。如果这两个公司在一年的封杀后没有通过一系列的检查，Mozilla 将准备封杀这两个公司的所有证书。“许多人都在盯着 Web PKI 安全体系，如果发现了这样的倒填（不管是什么原因），Mozilla 会立即永久地取消对沃通和 StartCom 根证书的信任。”该报告中说。此外，Chrome 和其它产品的对它们的封杀也在计划中。“其它的浏览器厂商和根证书存储运营者也会做出他们自己的决定，我们在这个文档中摆出了这些信息，以便他们了解我们做出这个决定的原因，并可以据此做出他们的决定。”Mozilla 说。

5 个值得了解的 Linux 服务器发行版
type: item
date: 2016-09-28T03:55:39+08:00
description: 你在 Distrowatch.com 上看到列出的将近 300 个 Linux 发行版本中，几乎任何一个发行版都可以被用来作为服务器系统。下面是一些相对于其他发行版而言比较突出的一些发行版。你在 Distrowatch.com 上看到列出的将近 300 个 Linux 发行版本中，几乎任何一个发行版都可以被用来作为服务器系统，在 Linux 发展的早期，给用户提供的一直是“全能”发行版，例如 Slackware、Debian 和 Gentoo 可以为家庭和企业作为服务器完成繁重的工作。那或许对业余爱好者是不错的，但是它对于专业人员来说也有好多不必要的地方。首先，这里有一些发行版可以作为文件和应用服务器，给工作站提供常见外围设备的共享，提供网页服务和其它我们希望服务器做的任何工作，不管是在云端、在数据中心或者在服务器机架上，除此之外没有别的用途。下面是 5 个最常用的 Linux 发行版的简单总结，而且每一个发行版都可以满足小型企业的需求。Red Hat Enterprise Linux（RHEL）这或许是最有名的 Linux 服务器发行版了。RHEL 以它在高要求的至关重要的任务上坚如磐石的稳定性而出名，例如运行着纽约证券交易系统。红帽也提供了业内最佳的服务支持。那么红帽 Linux 的缺点都有什么呢？ 尽管红帽以提供首屈一指的客户服务和支持而出名，但是它的支持订阅费用并不便宜。有人可能会指出，这的确物有所值。确实有便宜的 RHEL 第三方服务，但是你或许应该在这么做之前做一些研究。CentOS任何喜欢 RHEL，但是又不想给红帽付费来获得支持的人都应该了解一下 CentOS，它基本上是红帽企业版 Linux 的一个分支。尽管这个项目 2004 年左右才开始，但它在 2014 年得到了红帽的官方支持，而它现在雇佣可这个项目的大多数开发者，这意味着安全补丁和漏洞修复提交到红帽不久后就会在 CentOS 上可用。如果你想要部署 CentOS，你将需要有 Linux 技能的员工，因为没有了技术支持，你基本上只能靠自己。有一个好消息是 CentOS 社区提供了十分丰富的资源，例如邮件列表、Web 论坛和聊天室，所以对那些寻找帮助的人来说，社区帮助还是有的。Ubuntu Server当许多年前 Canonical 宣布它将要推出一个服务器版本的 Ubuntu 的时候，你可能会听到过嘲笑者的声音。然而嘲笑很快变成了惊奇，Ubuntu Server 迅速地站稳了脚跟。部分原因是因为其来自 Debian 派生的基因，Debian 长久以来就是一个备受喜爱的 Linux 服务器发行版，Ubuntu 通过提供一般人可以支付的起的技术支持费用、优秀的硬件支持、开发工具和很多亮点填补了这个市场空隙。那么 Ubuntu Server 有多么受欢迎呢？最近的数据表明它正在成为在 OpenStack 和 Amazon Elastic Compute Cloud 上部署最多的操作系统。在那里 Ubuntu Server 超过了位居第二的 Amazon Linux 的 Amazon Machine Image 一大截，而且让第三位 Windows 处于尘封的地位。另外一个调查显示 Ubuntu Server 是使用最多的 Linux web 服务器。SUSE Linux Enterprise Server（SLES）这个源自德国的发行版在欧洲有很大的用户群，而且在本世纪初由 Novell 公司引起的 PR 问题出现之前，它一直都是大西洋这边的排名第一服务器发行版。在那段漫长的时期之后，SUSE 在美国获得了发展，而且它的使用或许加速了惠普企业公司将它作为 Linux 首选合作伙伴。SLES 稳定而且易于维护，这正是很久以来对于一个好的 Linux 发行版所期待的东西。付费的 7*24 小时快速响应技术支持可以供你选择，使得这发行版很适合关键任务的部署。ClearOS基于 RHEL，之所以这里要包括 ClearOS 是因为它对于每个人来说都足够简单，甚至是没有专业知识的人都可以去配置它。它定位于服务中小型企业，它也可以被家庭用户用来作为娱乐服务器，为了简单易用我们可以基于 Web 界面进行管理，它是以“构建你的 IT 基础设施应该像在智能手机上下载 app 一样简单”为前提来定制的。最新的 7.2 发行版本，包括了一些可能并不“轻量级”的功能，例如对微软 Hyper-V 技术的 VM 支持，支持 XFS 和 BTRFS 文件系统，也支持 LVM 和 IPv6。这些新特性在免费版本或者在并不算贵的带着各种支持选项的专业版中都是可用的。via: http://windowsitpro.com/industry/five-linux-server-distros-wo…

是时候合并 LibreOffice 和 OpenOffice 了
type: item
date: 2016-09-27T23:24:52+08:00
description: 先说下 OpenOffice。可能你已经无数次地看到说 Apache OpenOffice 即将结束。上一个稳定版本是 4.1.2 （发布于 2015 年 10 月），而最近的一个严重安全漏洞用了一个月才打上补丁。编码人员的缺乏使得开发如爬行前进一般。然后，可能是最糟糕的消息了：这个项目建议用户切换到 MS Office（或 LibreOffice)。丧钟为谁而鸣？丧钟为你而鸣，OpenOffice。我想说些可能会惹恼一些人的话。你准备好了吗？OpenOffice 的终止对开源和用户来说都将是件好事。让我解释一下。一个分支统治所有当 LibreOffice 从 OpenOffice 分支出来后，我们看到了另一个情况：分支不只在原始基础上进行改进，而且大幅超越了它。LibreOffice 一举成功。所有之前预装 OpenOffice 的 Linux 发行版都迁移到了这个新项目。LibreOffice 从起跑线突然冲出，并迅速迈出了一大步。更新以极快的速度发布，改善内容丰富而重要。不久后，OpenOffice 就被开源社区丢在了脑后。当 2011 年 Oracle 决定终止这个项目并把代码捐赠给 Apache 项目时，这种情况自然更加恶化了。从此 OpenOffice 艰难前进，然后把我们就看到了现在这种局面：一个生机勃勃的 LibreOffice 和一个艰难的、缓慢的 OpenOffice。但我认为在这个相当昏暗的隧道末尾有一丝曙光。合并他们这听起来可能很疯狂，但我认为是时候把 LibreOffice 和 OpenOffice 合二为一了。是的，我知道很可能有政治考虑和自尊意识，但我认为合并成一个会更好。合并的好处很多。我首先能想到的是：把 MS Office 过滤器整合起来：OpenOffice 在更好地导入某些 MS Office 文件上功能很强（而众所周知 LibreOffice 正在改进，但时好时坏）LibreOffice 有更多开发者：尽管 OpenOffice 的开发者数量不多，但也无疑会增加到合并后的项目。结束混乱：很多用户以为 OpenOffice 和 LibreOffice 是同一个东西。有些甚至不知道 LibreOffice 存在。这将终结那些混乱。合并他们的用户量：OpenOffice 和 LibreOffice 各自拥有大量用户。联合后，他们将是个巨大的力量。宝贵机遇OpenOffice 的终止实际上会成为整个开源办公套件行业的一个宝贵机遇。为什么？我想表明有些东西我认为已经需要很久了。如果 OpenOffice 和 LibreOffice 集中他们的力量，比较他们的代码并合并，他们之后就可以做一些更必要的改进工作，不仅是整体的内部工作，也包括界面。我们得面对现实，LibreOffice 和（相关的） OpenOffice 的用户界面都是过时的。当我安装 LibreOffice 5.2.1.2 时，工具栏绝对是个灾难（见下图）。LibreOffice 默认工具栏显示尽管我支持和关心（并且日常使用）LibreOffice，但事实已经再清楚不过了，界面需要完全重写。我们正在使用的是 90 年代末/ 2000 年初的复古界面，它必须得改变了。当新用户第一次打开 LibreOffice 时，他们会被淹没在大量按钮、图标和工具栏中。Ubuntu Unity 的平视显示（Head up Display，简称 HUD）帮助解决了这个问题，但那并不适用于其它桌面和发行版。当然，有经验的用户知道在哪里找什么（甚至定制工具栏以满足特殊的需要），但对新用户或普通用户，那种界面是个噩梦。现在是做出改变的一个好时机。引入 OpenOffice 最后残留的开发者并让他们加入到改善界面的战斗中。借助于整合 OpenOffice 额外的导入过滤器和现代化的界面，LibreOffice 终能在家庭和办公桌面上都引起一些轰动。这会真的发生吗？这需要发生。但是会发生吗？我不知道。但即使掌权者决定用户界面并不需要重组（这会是个失误），合并 OpenOffice 仍是前进的一大步。合并两者将带来开发的更专注，更好的推广，公众更少的困惑。我知道这可能看起来有悖于开源的核心精神，但合并 LibreOffice 和 OpenOffice 将能联合两者的力量，而且可能会摆脱弱点。在我看来，这是双赢的。via: http://www.techrepublic.com/article/its-time-to-make-libreoffice-and-openoffice-one-again/作者：Jack Wallen 译者：bianjp 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出

漫游 HTTP/2
type: item
date: 2016-09-27T06:20:00+08:00
description: 自从我写了上一篇博文之后，就再也找不到空闲时间写文章了。今天我终于可以抽出时间写一些关于 HTTP 的东西。我认为每一个 web 开发者都应该对这个支撑了整个 Web 世界的 HTTP 协议有所了解，这样才能帮助你更好的完成开发任务。在这篇文章中，我将讨论什么是 HTTP，它是怎么产生的，它的地位，以及我们应该怎么使用它。HTTP 是什么首先我们要明白 HTTP 是什么。HTTP 是一个基于 TCP/IP 的应用层通信协议，它是客户端和服务端在互联网互相通讯的标准。它定义了内容是如何通过互联网进行请求和传输的。HTTP 是在应用层中抽象出的一个标准，使得主机（客户端和服务端）之间的通信得以通过 TCP/IP 来进行请求和响应。TCP 默认使用的端口是 80，当然也可以使用其它端口，比如 HTTPS 使用的就是 443 端口。HTTP/0.9 - 单行协议 (1991)HTTP 最早的规范可以追溯到 1991 年，那时候的版本是 HTTP/0.9，该版本极其简单，只有一个叫做 GET的请求方式。如果客户端要访问服务端上的一个页面，只需要如下非常简单的请求：GET /index.html 服务端对应的返回类似如下：(response body) (connection closed) 就这么简单，服务端捕获到请求后立马返回 HTML 并且关闭连接，在这之中没有 头信息 （ headers ） 仅支持 GET 这一种请求方法必须返回 HTML如同你所看到的，当时的 HTTP 协议只是一块基础的垫脚石。HTTP/1.0 - 1996在 1996 年，新版本的 HTTP 对比之前的版本有了极大的改进，同时也被命名为 HTTP/1.0。与 HTTP/0.9 只能返回 HTML 不同的是，HTTP/1.0 支持处理多种返回的格式，比如图片、视频、文本或者其他格式的文件。它还增加了更多的请求方法（如 POST 和 HEAD），请求和响应的格式也相应做了改变，两者都增加了头信息；引入了状态码来定义返回的特征；引入了字符集支持；支持 多段类型 （ multi-part ） 、用户验证信息、缓存、内容编码格式等等。一个简单的 HTTP/1.0 请求大概是这样的：GET / HTTP/1.0 Host: kamranahmed.info User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) Accept: */* 正如你所看到的，在请求中附带了客户端中的一些个人信息、响应类型要求等内容。这些是在 HTTP/0.9 无法实现的，因为那时候没有头信息。一个对上述请求的响应例子如下所示：HTTP/1.0 200 OK Content-Type: text/plain Content-Length: 137582 Expires: Thu, 05 Dec 1997 16:00:00 GMT Last-Modified: Wed, 5 August 1996 15:55:28 GMT Server: Apache 0.84 (response body) (connection closed) 从 HTTP/1.0 （HTTP 后面跟的是版本号）早期开始，在状态码 200 之后就附带一个原因短语（你可以用来描述状态码）。在这个较新一点的版本中，请求和响应的头信息仍然必须是 ASCII 编码，但是响应的内容可以是任意类型，如图片、视频、HTML、文本或其他类型，服务器可以返回任意内容给客户端。所以这之后，HTTP 中的“ 超文本 （ Hyper Text ） ”成了名不副实。 HMTP （ 超媒体传输协议 （ Hypermedia transfer protocol ） ）可能会更有意义，但是我猜我们还是会一直沿用这个名字。HTTP/1.0 的一个主要缺点就是它不能在一个连接内拥有多个请求。这意味着，当客户端需要从服务器获取东西时，必须建立一个新的 TCP 连接，并且处理完单个请求后连接即被关闭。需要下一个东西时，你必须重新建立一个新的连接。这样的坏处在哪呢？假设你要访问一个有 10 张图片，5 个 样式表 （ stylesheet ） 和 5 个 JavaScript 的总计 20 个文件才能完整展示的一个页面。由于一个连接在处理完成一次请求后即被关闭，所以将有 20 个单独的连接，每一个文件都将通过各自对应的连接单独处理。当连接数量变得庞大的时候就会面临严重的性能问题，因为 TCP 启动需要经过三次握手，才能缓慢开始。三次握手三次握手是一个简单的模型，所有的 TCP 连接在传输应用数据之前都需要在三次握手中传输一系列数据包。SYN - 客户端选取一个随机数，我们称为 x，然后发送给服务器。SY…