2016年11月

巨头之间的终极对决:崛起的新星 Node.js 能否战胜巨人 Apache 和 Nginx?

我和你一样,都阅读过大量散布在互联网各处的意见或事实,其中有一些我认为是可靠的,而其它的可能是谣传,让人难以置信。

我读过的许多信息是相当矛盾的,有人深信 StackOverflow(比如这个另一个),而其他人展示了一个清晰的令人惊讶的结果,这在推动我自己去做测试来验证结论的过程中扮演了重要的角色。

起初,我做了一些思想准备,我认为我可以避免自己进行实际测试来校验结论的麻烦——在我知道这一切之前我一直这样认为。

尽管如此,回顾之前,似乎我最初的想法是相当准确的,并且被我的测试再次印证。这个事实让我想起了当年我在学校学到的爱因斯坦和他的光电效应的实验,他面临着一个光的波粒二重性的问题,最初的结论是实验受到他的心理状态的影响,即当他期望结果是一个波的时候结果就会是一个波,反之亦然。

也就是说,我坚信我的结果不会在不久的将来被证明二重性,虽然我的心理状态可能在某种程度上对它们有影响。

关于比较

上面我读过一份材料具有一种革新的方式,在我看来,需要了解其自然而然的主观性和作者自身的偏见。

我决定采用这种方式,因此,提前声明以下内容:

开发者花了很多年来打磨他们的作品。那些取得了更高成就的人通常参考很多因素来做出自己的抉择,这是主观的做法;你需要推崇和捍卫你的技术决策。

也就是说,这个比较文章的着眼点不会成为另一篇“哥们,使用适合你的东西就好”的口水文章。我将会根据我的自身经验、需求和偏见提出建议。你可能会同意其中一些观点,反对另外一些;这很好——你的意见会帮助别人做出明智的选择。

感谢 SitePoint 的 Craig Buckler ,重新启发了我对比较类文章的看法——尝试重新忘记自我,并试图让所有的读者心悦诚服。

关于测试

所有的测试都在本地运行:

  • 英特尔酷睿 i7-2600k,四核八线程的机器
  • Gentoo Linux 是用于测试的操作系统

用于基准测试的工具:ApacheBench,2.3 <$Revision: 1748469 $>

测试包括一系列基准,从 1000 到 10000 个请求以及从 100 到 1000 个的并发请求——结果相当令人惊讶。

此外,我还进行了在高负载下测量服务器功能的压力测试。

至于内容,主要是一个包含一些 Lorem Ipsum 的标题和一张图片静态文件。

Lorem Ipsum 和 ApacheBenchmark

我决定专注于静态文件的原因是因为它们去除了可能对测试产生影响的各种渲染因素,例如:编程语言解释器的速度、解释器与服务器的集成程度等等。

此外,基于我自身的经验,平均网页加载时间很大一部分通常花费在静态内容上,例如图片,因此关注哪个服务器可以节省我们加载静态内容的时间是比较现实的。

除此之外,我还想测试一个更加真实的案例,案例中我在运行不同 CMS 的动态页面(稍后将详细介绍)时对服务器进行基准测试。

服务器

正如我用的是 Gentoo Linux,你就知道我的 HTTP 服务器在一开始就已经经过优化了,因为我在构建系统的时候只使用了我实际需要的东西。也就是说,当我运行我的测试的时候,不会在后台运行任何不必要的代码或加载没用的模块。

Apache、Nginx 和 Node.js 的使用的配置对比

Apache

$: curl -i http://localhost/index.html

HTTP/1.1 200 OK
Date: Sun, 30 Oct 2016 15:35:44 GMT
Server: Apache
Last-Modified: Sun, 30 Oct 2016 14:13:36 GMT
ETag: "2cf2-54015b280046d"
Accept-Ranges: bytes
Content-Length: 11506
Cache-Control: max-age=600
Expires: Sun, 30 Oct 2016 15:45:44 GMT
Vary: Accept-Encoding
Content-Type: text/html

Apache 配置了 “event mpm”。

Nginx

$: curl -i http://localhost/index.html

HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Sun, 30 Oct 2016 14:17:30 GMT
Content-Type: text/html
Content-Length: 11506
Last-Modified: Sun, 30 Oct 2016 14:13:36 GMT
Connection: keep-alive
Keep-Alive: timeout=20
ETag: "58160010-2cf2"
Accept-Ranges: bytes

Nginx 包括几个调整:sendfile ontcp_nopush ontcp_nodelay on

Node.js

$: curl -i http://127.0.0.1:8080

HTTP/1.1 200 OK
Content-Length: 11506
Etag: 15
Last-Modified: Thu, 27 Oct 2016 14:09:58 GMT
Content-Type: text/html
Date: Sun, 30 Oct 2016 16:39:47 GMT
Connection: keep-alive

在静态测试中使用的 Node.js 服务器是从头定制的,这样可以让它尽可能更加的轻快——没有使用外部模块(Node 核心模块除外)。

测试结果

点击图片以放大:

Apache、Nginx 与 Node 的对比:请求负载的性能(每 100 位并发用户)

Apache、Nginx 与 Node 的对比:用户负载能力(每 1000 个请求)

压力测试

Apache、Nginx 与 Node 的对比:完成 1000 位用户并发的 100000 个请求耗时

我们可以从结果中得到什么?

从以上结果判断,似乎 Nginx 可以在最少的时间内完成最多请求,换句话来说,Nginx 是最快的 HTTP 服务器。

还有一个相当惊人的事实是,在特定的用户并发数和请求数下,Node.js 可以比 Nginx 和 Apache 更快。

但当请求的数量在并发测试中增加的时候,Nginx 将重回领先的位置,这个结果可以让那些陷入 Node.js 的遐想的人清醒一下。

和 Apache、Nginx 不同的是,Node.js 似乎对用户的并发数不太敏感,尤其是在集群节点。如图所示,集群节点在 0.1 秒左右保持一条直线,而 Apache 和 Nginx 都有大约 0.2 秒的波动。

基于上述统计可以得出的结论是:网站比较小,其使用的服务器就无所谓。然而,随着网站的受众越来越多,HTTP 服务器的影响变得愈加明显。

当涉及到每台服务器的原始速度的底线的时候,正如压力测试所描述的,我的感觉是,性能背后最关键的因素不是一些特定的算法,而实际上是运行的每台服务器所用的编程语言。

由于 Apache 和 Nginx 都使用了 C 语言—— AOT 语言(编译型语言),而 Node.js 使用了 JavaScript ——这是一种 JIT 语言(解释型语言)。这意味着 Node.js 在执行程序的过程中还有额外的工作负担。

这意味着我不能仅仅基于上面的结果来下结论,而要做进一步校验,正如你下面看到的结果,当我使用一台经过优化的 Node.js 服务器与流行的 Express 框架时,我得到几乎相同的性能结论。

全面考虑

逝者如斯夫,如果没有服务的内容,HTTP 服务器是没什么用的。因此,在比较 web 服务器的时候,我们必须考虑的一个重要的部分就是我们希望在上面运行的内容。

虽然也有其它的功能,但是 HTTP 服务器最广泛的使用就是运行网站。因此,为了看到每台服务器的性能的实际效果,我决定比较一下世界上使用最广泛的 CMS(内容管理系统)WordPress 和 Ghost —— 内核使用了 JavaScript 的一颗冉冉升起的明星。

基于 JavaScript 的 Ghost 网页能否胜过运行在 PHP 和 Apache / Nginx 上面的 WordPress 页面?

这是一个有趣的问题,因为 Ghost 具有操作工具单一且一致的优点——无需额外的封装,而 WordPress 需要依赖 Apache / Nginx 和 PHP 之间的集成,这可能会导致显著的性能缺陷。

除此之外,PHP 距 Node.js 之间还有一个显著的性能落差,后者更佳,我将在下面简要介绍一下,可能会出现一些与初衷大相径庭的结果。

PHP 与 Node.js 的对决

为了比较 WordPress 和 Ghost,我们必须首先考虑一个影响到两者的基本组件。

基本上,WordPress 是一个基于 PHP 的 CMS,而 Ghost 是基于 Node.js(JavaScript)的。与 PHP 不同,Node.js 有以下优点:

  • 非阻塞的 I/O
  • 事件驱动
  • 更新颖、更少的残旧代码

由于有大量的测评文章解释和演示了 Node.js 的原始速度超过 PHP(包括 PHP 7),我不会再进一步阐述这个主题,请你自行用谷歌搜索相关内容。

因此,考虑到 Node.js 的性能优于 PHP,一个 Node.js 的网站的速度要比 Apache / Nginx 和 PHP 的网站快吗?

WordPress 和 Ghost 对决

当比较 WordPress 和 Ghost 时,有些人会说这就像比较苹果和橘子,大多数情况下我同意这个观点,因为 WordPress 是一个完全成熟的 CMS,而 Ghost 基本上只是一个博客平台。

然而,两者仍然有共同竞争的市场,这两者都可以用于向世界发布你的个人文章。

制定一个前提,我们怎么比较两个完全基于不同的代码来运行的平台,包括风格主题和核心功能。

事实上,一个科学的实验测试条件是很难设计的。然而,在这个测试中我对更接近生活的情景更感兴趣,所以 WordPress 和 Ghost 都将保留其主题。因此,这里的目标是使两个平台的网页大小尽可能相似,让 PHP 和 Node.js 在幕后斗智斗勇。

由于结果是根据不同的标准进行测量的,最重要的是尺度不一样,因此在图表中并排显示它们是不公平的。因此,我改为使用表:

Node、Nginx、Apache 以及运行 WordPress 和 Ghost 的比较。前两行是 WordPress,底部的两行是 Ghost

正如你所见,尽管事实上 Ghost(Node.js)正在加载一个更小的页面(你可能会惊讶 1kb 可以产生这么大的差异),它仍然比同时使用 Nginx 和 Apache 的 WordPress 要慢。

此外,使用 Nginx 代理作为负载均衡器来接管每个 Node 服务器的请求实际上会提升还是降低性能?

那么,根据上面的表格,如果说它产生什么效果的话,它造成了更慢的效果——这是一个合理的结果,因为额外封装一层理所当然会使其变得更慢。当然,上面的数字也表明这点差异可以忽略不计。

但是上表中最重要的一点是,即使 Node.js 比 PHP 快,HTTP 服务器的作用也可能超过某个 web 平台使用的编程语言的重要性。

当然,另一方面,如果加载的页面更多地依赖于服务器端的脚本处理,那么我怀疑结果可能会有点不同。

最后,如果一个 web 平台真的想在这场竞赛里击败 WordPress,从这个比较中得出的结论就是,要想性能占优,必须要定制一些像 PHP-FPM 的工具,它将直接与 JavaScript 通信(而不是作为服务器来运行),因此它可以完全发挥 JavaScript 的力量来达到更好的性能。


via: https://iwf1.com/apache-vs-nginx-vs-node-js-and-what-it-means-about-the-performance-of-wordpress-vs-ghost/

作者:Liron 译者:OneNewLife 校对:wxy

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

(题图来自:deviantart.net

对于大多数开源项目来讲, 问题追踪系统 Issue-tracking system 是至关重要的。虽然有非常多的开源工具提供了这样的功能,但是大量项目还是选择了 GitHub 自带的 问题追踪器 Issue Tracker

它结构简单,可以让其他人可以非常轻松地参与进来,但这才仅仅是开始。

如果没有适当的处理,你的 储存库 repository 会变得很庞大,挤满重复的问题单、模糊不明的特性需求单、含混的 bug 报告单。项目维护者会被大量工作压得喘不过气来,新的贡献者也搞不清楚项目当前的工作重点是什么。

接下来,我们一起研究下,如何玩转 GitHub 的问题单。

问题单就是用户的故事

我的团队曾经和开源专家 Jono Bacon 做过一次对话,他是 《社区艺术》 The Art of Community 一书的作者、一位战略顾问、前 GitHub 社区总监。他告诉我们,高质量的问题单是项目成功的关键。有些人把问题单仅仅看作是一堆你不得不去处理的问题列表,但是如果这些问题单管理完善,进行了分类并打上标签,会令人意想不到的提升我们对代码和社区的了解程度,也让我们更清楚问题的关键点在哪里。

“在提交问题单时,用户不太会有耐心或者有兴趣把问题的细节描述清楚。在这种情况下,你应当努力花最短的时间,尽量多的获取有用的信息。”,Jono Bacon 说。

统一的问题单模板可以大大减轻项目维护者的负担,尤其是开源项目的维护者。我们发现,让用户讲故事的方法总是可以把问题描述的非常清楚。用户讲故事时需要说明“是谁,做了什么,为什么而做”,也就是:我是【何种用户】,为了【达到何种目的】,我要【做何种操作】。

实际操作起来,大概是这样的:

我是一名顾客,我想购买东西,所以我想创建个账户

我们建议,问题单的标题始终使用这样的用户故事形式。你可以设置问题单模板来保证一致性。

问题单模板让特性需求单保持统一的形式

这个做法的核心点在于,问题单要清晰的呈现给它涉及的每一个人:它要尽量简单的指明受众(或者说用户),操作(或者说任务),和输出(或者说目标)。不过,不需要过分拘泥于这个模板,只要能把故事里的是什么事情或者是什么原因说清楚,就达到目的了。

高质量的问题单

问题单的质量是参差不齐的,这一点任何一个开源软件的贡献者或维护者都能证实。在《The Agile Samurai》中概述过一个良好的问题单所应具备的素质。

好的问题单尽量满足如下条件:

  • 客户价值所在
  • 避免使用术语或晦涩的文字,就算不是专家也能看懂
  • 可以切分,也就是说我们可以逐步解决问题
  • 尽量跟其他问题单没有瓜葛,依赖其它问题会降低处理的灵活性
  • 可以协商,也就说我们有好几种办法达到目标
  • 问题足够小,可以非常容易的评估出所需时间和资源
  • 可衡量,我们可以对结果进行测试

不满足上述条件的问题单呢? 要有约束

如果一个问题单很难衡量,或者很难在短时间内完成,你也一样有办法搞定它。有些人把这种办法叫做“约束”(constraints)。

例如,“这个产品要快”,这种问题单不符合故事模板,而且是没办法协商的。多快才是快呢?这种模糊的需求没有达到“好问题单”的标准,但是如果你进一步定义一下,例如“每个页面都需要在 0.5 秒内加载完”,那我们就能更轻松地解决它了。我们可以把“约束”看作是成功的标尺,或者要实现的里程碑。每个团队都应该定期的对“约束”进行测试。

问题单里面有什么?

敏捷方法中,用户故事里通常要包含验收指标或者标准。在 GitHub 里,建议大家使用 markdown 格式的清单来概括解决这个问题单需要完成的任务。优先级越高的问题单应当包含更多的细节。

比如说,你打算提交一个关于新版网站主页的问题单。那这个问题单的子任务列表可能就是这样的:

使用 markdown 的清单把复杂问题拆分成多个部分

在必要的情况下,你还可以链接到其他问题单,以进一步明确任务。(GitHub 里做这个挺方便的)

将特性定义的越细化,越容易跟踪进度、测试,最终能更高效的发布有价值的代码。

以问题单的形式收到到问题所在后,还可以用 API 更深入的了解软件的健康度。

“在统计问题单的类型和趋势时,GitHub API 可以发挥巨大作用”,Bacon 告诉我们,“如果再做些数据挖掘工作,你就能发现代码里的问题点、社区里的活跃成员,或者其他有用的信息。”

有些问题单管理工具提供的 API 可以提高额外信息,比如预估时间或者历史进度。

团队协同一致

团队决定使用某种问题单模板后,如何让所有人都照做?存储库里的 ReadMe.md 其实也可以是你们项目的 “How-to” 文档。这个文档应描述清楚这个项目是做什么的(最好是用可以搜索的语言),以及其他贡献者应当如何参与进来(比如提交需求单、bug 报告、建议,或者直接贡献代码)。

在 ReadMe 文件里增加清晰的说明,供新协作者参考

ReadMe 文件是提供“问题单指引”的完美场所。如果希望特性需求单遵循“用户讲故事”的格式,那就把格式写在 ReadMe 里。如果使用某种跟踪工具来管理待办事项,那就标记在 ReadMe 里,这样别人也能看到。

“问题单模板、合理的标签、提交问题单的指导文档、确保问题单被分类并及时回应,这些对于开源项目都至关重要”,Bacon 说。

记住一点:这不是为了完成工作而做的工作。这是让其他人更轻松的发现、了解、融入你的社区而设立的规则。

"关注社区的成长,不仅要关注参与开发者的的数量增长,也要关注那些在问题单上帮助我们的人,他们让问题单更加明确、保持更新,这是活跃沟通和高效解决问题的力量源泉",Bacon 说。


via: https://opensource.com/life/16/7/how-take-your-projects-github-issues-good-great

作者:Matt Butler 译者:echoma 校对:jasminepeng

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

Android 2.0 Éclair——带动 GPS 产业

41 天——这是从安卓 1.6 到安卓 2.0 所经历的时间。安卓的第一个大的版本号更迭发生在 2009 年 10 月的摩托罗拉 Droid 身上,它是第一部“第二代”安卓设备。相对于 G1 而言,Droid 进行了大幅的硬件升级,拥有巨大的 3.7 英寸(在当时而言),分辨率 854×480 的 LCD 屏幕。它同样带来了更强劲的性能:一个 600Mhz 的德州仪器 TI OMAP Cortex A8 处理器(还是单核),以及 256MB 的内存。

摩托罗拉Droid凝视着你的灵魂。

摩托罗拉 Droid 凝视着你的灵魂。

但 Droid 最重要的部分是围绕它的大型广告活动。Droid 是美国运营商威瑞森 Verizon 的旗舰设备,这个头衔给它从美国最大运营商那里带来了不少收入。威瑞森从卢卡斯影业那获得了单词“droid”的授权,并且开始了“Droid Does”运动——通过广告将设备定位成一个敢于发声、充满突破的(由此也延伸到安卓身上)强力 iPhone 替代品。媒体常常说 T-Mobile G1 想要成为一个“iPhone 杀手”,但是 Droid 走了出来,并拥有了这个称号。

就和 G1 一样,Droid 有个侧滑实体键盘。轨迹球已经不见了,但是还是强制性要求有类似十字方向键的东西,所以摩托罗拉把一个五键十字方向键放在了键盘右侧。Droid 正面按键从实体按键变成了电容式触摸按键,它们只是被印在了玻璃触摸屏上。安卓 2.0 同样最终取消了必须有“呼叫”和“结束”按钮的强制要求。所以连同十字方向键移到键盘那里的变动,正面的按键可以排成漂亮又整洁的一行。所有这些精简结果带来的是有史以来最好看的安卓设备。T-Mobile G1 看起来像是费雪牌的玩具,但摩托罗拉 Droid 看起来像个可以用来削人的工业工具。

安卓2.0和1.6的锁屏和主屏幕。

安卓 2.0 和 1.6 的锁屏和主屏幕。 [Ron Amadeo 供图]

威瑞森的一些差劲的广告活动泄漏了这个软件,原本平静、水汪汪的远景默认壁纸变成了脏兮兮的混凝土。开机动画用了红色脉动的哈儿(HAL 9000)的眼球(LCTT 译注:哈儿是英国小说家亚瑟·克拉克所著《太空漫游》小说中出现的一部拥有强人工智能的超级电脑),每当你收到邮件的时候,默认通知铃声还会高喊“DRRRRROOOOIIIIDDDD”。Éclair 泡芙就像是安卓的忧郁少年阶段。

安卓 2.0 中最先呈现给用户的事情之一就是新的锁屏。滑动解锁是苹果的专利,因此谷歌就采用了来自旋转手机的灵感,使用了弧线解锁手势。把你的手指放在锁定图标上并且向右滑动可以解锁设备,从音量图标向左滑动可以让手机静音。手指的自然移动是圆弧状的,所以这手势感觉比按直线滑动更加自然。

默认主屏幕布局取消了多余的模拟时钟小部件,引入了现如今安卓的一个主要部分:主屏幕顶端的一个搜索栏。短信和安卓市场同样花了大功夫在新布局上。应用抽屉页同样被经过了明显的重新设计。

应用抽屉和“添加到主屏幕”菜单截图。

应用抽屉和“添加到主屏幕”菜单截图。 [Ron Amadeo 供图]

安卓在早期的阶段以极快的步伐开发前进,而安卓团队在考虑界面设计时也从来没有对未来的设备有过真正的规划。摩托罗拉 Droid——拥有 854×480 分辨率的 LCD 显示屏——相对于 320×480 分辨率的 G1 时代设备在分辨率上是个巨大的提升。几乎所有的东西都需要重绘。界面设计的“从头开始”就几乎成为了安卓 2.0 的主要课题。

谷歌借此机会几乎重新设计了安卓的所有图标,从带有等距轴线的卡通风格图标转变为风格更为正式直观的图标。唯一一套没有重绘的图标是状态栏图标,和经过修改的系统其它部分相比显得格格不入。这些图标会从安卓 0.9 一直使用到安卓 2.3。

应用阵容上同样也有一些改变。摄像机被合并到相机中,IM 应用被去除,并增加了两个新的谷歌应用:Car Home,这是一个被设计为在驾驶时使用的带有大按钮的启动器,还有企业日历,除了它支持 Exchange 而不是谷歌日历以外,它和常规的日历没什么不一样。奇怪的是,谷歌还预装了两个第三方应用程序:Facebook 和 Verizon 的 Visual VM 应用 (现在都不能用了)。第二组图片显示的是“添加到主屏幕”菜单,它同样经过了全新的设计。

一个地点页面,显示“导航”选项,导航免责声明,实际的导航画面,以及交通信息。

一个地点页面,显示“导航”选项,导航免责声明,实际的导航画面,以及交通信息。 [Ron Amadeo 供图]

除了新的设计以外,安卓 2.0 最突出的亮点是谷歌地图导航。谷歌更新了地图,以支持免费的逐向导航,配有兴趣点搜索和文本到语音引擎,这使得它可以像一个独立的 GPS 设备一样大声读出街道名称。把 GPS 导航从一个单独的产品变成免费的智能手机功能,这几乎一夜之间摧毁了独立 GPS 市场。TomTom 的股票在安卓 2.0 推出的一周内下跌了近 40%。

但一开始这个导航应用非常难以找到。你必须打开搜索框,键入一个地点或地址,并点击搜索结果。接下来,点击了“导航”按钮后,谷歌会显示一个警告,声明导航正处于 beta 测试阶段,不应该被信任。点击“接受”后,你可以跳上车,一个粗糙的合成语音会引导你到达目的地。菜单按钮背后隐藏着一个选项,可以查看整个路线上的交通状况和突发事件。导航的设计一直徘徊不前。甚至连谷歌地图主界面都在安卓 4.0 时更新了,安卓 2.0 风格的导航部分还是那么放着,这几乎持续到了安卓 4.3 才有所改观。

地图还会显示路线的概览,其中包含你的路线的交通数据。起初数据只是由常规的交通数据提供商授权,但后来,谷歌通过运行谷歌地图的安卓和 iOS 手机收集原始交通数据。这是在移动设备地图竞争中谷歌迈向霸主地位的第一步。毕竟,实时交通流量的监控确实仅仅取决于你有多少数据点来源。现在,伴随着数以亿计的 iOS 和安卓的谷歌地图的用户,谷歌已经成为世界上最好的交通数据提供商。

有了地图导航,安卓终于找到了自己的杀手级应用。谷歌公司那时提供了其他人提供不了的东西。“为什么我应该买这个而不是买个 iPhone?”问题终于有了个答案。谷歌地图也不需要像许多 GPS 设备一样通过 PC 更新。有了云,地图能够始终保持最新状态,所有这些更新都是免费的。唯一的缺点是,你需要一个互联网连接来使用谷歌地图。

精确的地图在苹果地图的惨败中被大大宣传,它已经成为了智能手机的最重要的功能之一,即使没有人真正在它们工作的时候赞赏它们。绘制世界真的只是借助了无数人的力量,今天,谷歌的“地球”部门是公司最大的部门,拥有超过7000 名员工。对于这里的大多数人来说,他们的工作就是驾驶着公司装满了相机的街景车驶过世界上的每一条道路。经过八年的数据收集,谷歌拥有超过五百万英里的 360 度街景视图,谷歌地图成为了公司不可撼动的支柱之一。

Car Home主屏幕,并且因为有空间,加入了一个横版的导航。

Car Home 主屏幕,并且因为有空间,加入了一个横版的导航。 [Ron Amadeo 供图]

随着和谷歌地图导航一起到来的还有“Car Home”,一个大按钮设计的主屏幕,旨在帮助你在驾驶时使用手机。不能定制,每一个按钮只是一个独立应用的快捷方式。摩托罗拉 Droid 和其官方的车载 dock 配件之间有特殊的磁铁,二者接触将自动触发 Car Home。在手机接入 dock 时,按压 Droid 的实体 home 键会打开 Car Home 主屏而不是正常的主屏幕,屏幕上的触摸 Home 键可以打开正常的主屏幕。

Car Home,虽然很有用,但并没有存在多久——它在安卓 3.0 中被去掉了,再也没有回来过。GPS 系统几乎全部用在汽车驾驶时,但它鼓励用户使用如“搜索”这样的功能,它会弹出一个键盘,谷歌的律师可能并不是很喜欢这种功能。随着苹果的 CarPlay和谷歌的开放汽车联盟的到来,车载电脑看到了复苏的希望。这一次,重点更多的是在安全上,政府机构(如美国国家公路交通安全管理局)也在协助着这一方面的发展。


Ron Amadeo / Ron 是 Ars Technica 的评论编缉,专注于安卓系统和谷歌产品。他总是在追寻新鲜事物,还喜欢拆解事物看看它们到底是怎么运作的。 @RonAmadeo


via: http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/10/

译者:alim0x 校对:wxy

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

通过这系列的前六篇文章,我们已经学会使用 Git 来对文本文件进行版本控制的管理。我们不禁要问,还有二进制文件呢,也可进行进行版本控制吗?答案是肯定的,Git 已经有了可以处理像多媒体文件这样的二进制大对象块(blob)的扩展。因此,今天我们会学习使用 Git 来管理所谓的二进制资产。

似乎大家都认可的事就是 Git 对于大的二进制对象文件支持得不好。要记住,二进制大对象与大文本文件是不同的。虽然 Git 对大型的文本文件版本控制毫无问题,但是对于不透明的二进制文件起不了多大作用,只能把它当作一个大的实体黑盒来提交。

设想这样的场景,有一个另人兴奋的第一人称解密游戏,您正在为它制作复杂的 3D 建模,源文件是以二进制格式保存的,最后生成一个 1GB 大小的的文件。您提交过一次,在 Git 源仓库历史中有一个 1GB 大小的新增提交。随后,您修改了下模型人物的头发造型,然后提交更新,因为 Git 并不能把头发从头部及模型中其余的部分离开来,所以您只能又提交 1GB 的量。接着,您改变了模型的眼睛颜色,提交这部分更新:又是 GB 级的提交量。对一个模型的一些微小修改,就会导致三个 GB 级的提交量。对于想对一个游戏所有资源进行版本控制这样的规模,这是个严重的问题。

不同的是如 .obj 这种格式的文本文件,和其它类型文件一样,都是一个提交就存储所有更新修改状态,不同的是 .obj 文件是一系列描述模型的纯文本行。如果您修改了该模型并保存回 .obj 文件,Git 可以逐行读取这两个文件,然后创建一个差异版本,得到一个相当小的提交。模型越精细,提交就越小,这就是标准的 Git 用例。虽然文件本身很大,但 Git 使用覆盖或稀疏存储的方法来构建当前数据使用状态的完整描述。

然而,不是所有的都是纯文本的,但都要使用 Git,所以需要解决方案,并且已经出现几个了。

OSTree 开始是作为 GNOME 项目出现的,旨在管理操作系统的二进制文件。它不适用于这里,所以我直接跳过。

Git 大文件存储(LFS) 是放在 GitHub 上的一个开源项目,是从 git-media 项目中分支出来的。git-mediagit-annex 是 Git 用于管理大文件的扩展。它们是对同一问题的两种不同的解决方案,各有优点。虽然它们都不是官方的项目,但在我看来,每个都有独到之处:

  • git-media 是集中模式,有一个公共资产的存储库。你可以告诉 git-media 大文件需要存储的位置,是在硬盘、服务器还是在云存储服务器,项目中的每个用户都将该位置视为大型文件的中心主存储位置。
  • git-annex 侧重于分布模式。用户各自创建存储库,每个存储库都有一个存储大文件的本地目录 .git/annex。这些 annex 会定期同步,只要有需要,每个用户都可以访问到所有的资源。除非通过 annex-cost 特别配置,否则 git-annex 优先使用本地存储,再使用外部存储。

对于这些,我已经在生产中使用了 git-media 和 git-annex,那么下面会向你们概述其工作原理。

git-media

git-media 是使用 Ruby 语言开发的,所以首先要安装 gem(LCTT 译注:Gem 是基于 Ruby 的一些开发工具包)。安装说明在其网站上。想使用 git-meida 的用户都需要安装它,因为 gem 是跨平台的工具,所以在各平台都适用。

安装完 git-media 后,你需要设置一些 Git 的配置选项。在每台机器上只需要配置一次。

$ git config filter.media.clean "git-media filter-clean"
$ git config filter.media.smudge "git-media filter-smudge"

在要使用 git-media 的每个存储库中,设置一个属性以将刚刚创建的过滤器结合到要您分类为“ 媒体 media ”的文件类型里。别被这种术语混淆。一个更好的术语是“资产”,因为“媒体”通常的意思是音频、视频和照片,但您也可以很容易地将 3D 模型,烘焙和纹理等归类为媒体。

例如:

$ echo "*.mp4 filter=media -crlf" >> .gitattributes
$ echo "*.mkv filter=media -crlf" >> .gitattributes
$ echo "*.wav filter=media -crlf" >> .gitattributes
$ echo "*.flac filter=media -crlf" >> .gitattributes
$ echo "*.kra filter=media -crlf" >> .gitattributes

当您要 暂存 stage 这些类型的文件时,文件会被复制到 .git/media 目录。

假设在服务器已经有了一个 Git 源仓库,最后一步就告诉源仓库“母舰”所在的位置,也就是,当媒体文件被推送给所有用户共享时,媒体文件将会存储的位置。这在仓库的 .git/config 文件中设置,请替换成您的用户名、主机和路径:

[git-media]
transport = scp
autodownload = false #默认为 true,拉取资源
scpuser = seth
scphost = example.com
scppath = /opt/jupiter.git

如果您的服务器上 SSH 设置比较复杂,例如使用了非标准端口或非默认 SSH 密钥文件的路径,请使用 .ssh/config 为主机设置默认配置。

git-media 的使用和普通文件一样,可以把普通文件和 blob 文件一样对待,一样进行 commit 操作。操作流程中唯一的不同就是,在某些时候,您应该将您的资产(或称媒体)同步到共享存储库中。

当要为团队发布资产或自己备份资料时,请使用如下命令:

$ git media sync

要用一个变更后的版本替换 git-media 中的文件时(例如,一个已经美声过的音频文件,或者一个已经完成的遮罩绘画,或者一个已经被颜色分级的视频文件),您必须明确的告诉 Git 更新该媒体。这将覆盖 git-media 不会复制远程已经存在的文件的默认设置:

$ git update-index --really-refresh

当您团队的其他成员(或是您本人,在其它机器上)克隆本仓库时,如果没有在 .git/config 中把 autodownload 选项设置为 true 的话,默认是不会下载资源的。但 git-media 的一个同步命令 git media sync 可解决所有问题。

git-annex

git-annex 的处理流程略微的有些不同,默认是使用本地仓库的,但基本的思想都一样。您可以从你的发行版的软件仓库中安装 git-annex,或者根据需要从该网站上下载安装。与 git-media 一样,任何使用 git-annex 的用户都必须在其机器上安装它。

其初始化设置比 git-media 都简单。运行如下命令,其中替换成您的路径,就可以在您的服务器上创建好裸存储库:

$ git init --bare --shared /opt/jupiter.git

然后克隆到本地计算机,把它标记为 git-annex 的初始路径:

$ git clone [email protected]:/opt/jupiter.clone
Cloning into 'jupiter.clone'... 
warning: You appear to have clonedan empty repository. 
Checking connectivity... done.
$ git annex init "seth workstation" 
init seth workstation ok

不要使用过滤器来区分媒体资源或大文件,您可以使用 git annex 命令来配置归类大文件:

$ git annex add bigblobfile.flac
add bigblobfile.flac
(checksum) ok
(Recording state in Git...)

跟普通文件一样进行提交操作:

$ git commit -m 'added flac source for sound fx'

但是推送操作是不同的,因为 git annex 使用自己的分支来跟踪资产。您首次推送可能需要 -u 选项,具体取决于您如何管理您的存储库:

$ git push -u origin master git-annex
To [email protected]:/opt/jupiter.git
* [new branch] master -> master
* [new branch] git-annex -> git-annex

和 git-media 一样,普通的 git push 命令是不会拷贝资料到服务器的,仅仅只是发送了相关的消息,要真正共享文件,需要运行同步命令:

$ git annex sync --content

如果别人已经提交了共享资源,您需要拉取它们,git annex sync 命令将提示您要在本地检出你本机没有,但在服务器上存在的资源。

git-media 和 git-annex 都非常灵活,都可以使用本地存储库来代替服务器,所以它们也常用于管理私有的本地项目。

Git 是一个非常强大和扩展性非常强的系统应用软件,我们应该毫不犹豫的使用它。现在就开始试试吧!


via: https://opensource.com/life/16/8/how-manage-binary-blobs-git-part-7

作者:Seth Kenlon 译者:runningwater 校对:wxy

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

新版安卓市场——黑色比重减少,白色和绿色增多。

新版安卓市场——黑色比重减少,白色和绿色增多。 [Ron Amadeo 供图]

安卓 1.6 Donut——CDMA 支持将安卓带给了各个运营商

安卓的第四个版本——1.6 甜甜圈——在 2009 年 9 月发布,这时是在纸杯蛋糕面世的 5 个月后。尽管有无数更新,谷歌仍然在给安卓添加基本的功能。甜甜圈带来了对不同屏幕尺寸和 CDMA 的支持,还有一个文本语音转换引擎。

安卓 1.6 是个很好的更新例子,要在今天的话,它将没什么理由作为一个独立更新存在。主要的改进基本上可以总结为新版安卓市场、相机以及 YouTube。从这一年起,像这样的应用已经从系统分离开来,并且谷歌任何时候都能升级它们。然而在完成所有的这些模块化功能工作之前,看起来甚至是一个微小的应用更新似乎都需要完整的系统更新。

另一个重大改进——CDMA 支持——也表明了除了版本号之外,谷歌仍然在忙于将基本功能带到安卓上来。

安卓市场被标注为版本“1.6”,并且得到了一个彻底的改进。原本的全黑设计被抛弃,转向带有绿色高亮的白色应用设计——安卓的设计师很明显使用了安卓吉祥物来获得灵感。

新的市场对谷歌来说一定是个新的应用设计风格。屏幕顶部的五分之一用于显示横幅 logo,表明了这个应用确实是“安卓市场”。在横幅之下是应用、游戏以及下载按钮,一个搜索按钮被安置在横幅的右侧。在导航键下面显示着特色应用的快照,可以在它们之间滑动。再下面是个垂直滚动列表,显示了更多的特色应用。

新的市场设计,展示了:带有截图的应用页面,应用分类页面,应用榜,下载。

新的市场设计,展示了:带有截图的应用页面、应用分类页面、应用排行榜、下载。 [Ron Amadeo 供图]

市场的最大的新增内容是包含应用截图。安卓用户终于可以在安装之前看到应用长什么样子——之前他们只能看到简短的描述和用户评论。你的个人星级评价和评论被放在显著位置,随后是描述,最后是截图。查看截图常常需要一点点滚动来查看——如果你想要找个设计尚佳的应用,那可要费一番功夫了。

点击应用或游戏按钮会打开一个分类列表,就像你在上面第二张图看到的那样。选择一个类别之后,更多的导航显示在了屏幕顶部,用户可以看到“热门付费”、“热门免费”,或在分类里看到各自的“热门新品”应用。尽管这些看起来像是会加载出新页面的按钮,实际上它们仅仅是个笨拙的标签页。每个按钮边有个绿色小灯指示现在哪个标签处于活跃状态。这个界面最赞的地方是应用列表是无穷滚动的(滚动加载)——一旦你到达列表底部的时候,它将加载更多应用。这个特性使得查看应用列表变得轻松,但是你点开任意一个应用再返回的话将会丢失你在列表里的位置——你得从头开始查看。下载部分可以做一些连新的 Google Play 商店都做不到的事:不过是显示一个已购买应用列表而已。

尽管新的市场看起来无疑比旧的好多了,但应用间的一致性更糟糕了。看起来就像是每个应用都是由不同团队制作的,他们之间从没沟通过所有的安卓应用应该有的样子。

相机取景窗,照片回看界面,菜单。

相机取景窗,照片回看界面,菜单。 [Ron Amadeo 供图]

举个例子,相机应用从全屏、精简设计变成一个盒状的边缘带控制的取景窗。在相机应用中,谷歌着手引入拟物化,将应用包装成一个大致复刻了皮革纹经典相机的样子。在相机和摄像机之间切换通过一个缺乏想象力的开关完成,下面是个触摸快门按钮。

点击最近照片快照不再会打开相册,而是一个内建在了相机应用内定制的照片查看器。当你查看照片的时候,皮革质感的控制区从相机操作键变成图片操作键,你可以在这里删除、共享照片,或者把照片设置成壁纸或联系人图像。这里图片之间依然没有滑动操作——切换照片还是要通过照片两侧的箭头按钮完成。

第二张截图展示的是设计师减少对菜单按钮依赖的例子之一,因为安卓团队慢慢开始意识到其在可发现性上的糟糕表现。许多的应用设计者(包括那些在谷歌的)使用菜单作为所有种类的控制和导航元素的集中之处。但大多数用户没想过点击菜单按钮,也从没看到这些指令。

未来版本的安卓的公共主题会将选项从菜单移到主要屏幕上,使得整个系统对用户更加友好。菜单按钮在安卓 4.0 中被完全移除,并且它只在老式应用中被支持。

电池以及文本语音转换引擎设置。

电池以及文本语音转换引擎设置。 [Ron Amadeo 供图]

甜甜圈是第一个持续追踪电池使用量的安卓版本。在“关于手机”菜单里有个选项“电池使用”,它会以百分比的方式显示应用以及硬件功能的电池用量。点击其中一项会打开一个单独的相关状态页面。硬件项目有个按钮可以直接跳转到它们的设置界面,所以,举个例子,如果你觉得显示的电池用量太高你可以更改显示的屏幕超时。

安卓 1.6 同样是第一个支持文本语音转换引擎(TTS)的版本,这意味着系统以及应用能够用机器合成声音来回应你。“语音合成器”选项允许你设置语言,选择语速,以及从安卓市场安装语音数据(慎重)。今天,谷歌在安卓上部署它自己的 TTS 引擎,但是似乎甜甜圈是通过硬编码的方式使用了来自 SVOX 的 TTS 引擎。但 SVOX 的引擎并未部署在甜甜圈上,所以点击“安装语音数据”会链接到安卓市场的一个应用。(甜甜圈的全盛期几年后,这个应用已被撤下。看起来似乎安卓 1.6 再也不能说话了。)

从左到右:新的小部件,搜索栏界面,新清除通知按钮,新相册控件。

从左到右:新的小部件,搜索栏界面,新清除通知按钮,新相册控件。 [Ron Amadeo 供图]

前端小部件部分花了更多的功夫。甜甜圈带来了全新的叫做“电量控制”小部件。它包含了常见耗电功能的开关:Wi-Fi、蓝牙、GPS、同步(同谷歌服务器之间),以及亮度。

搜索小部件同样经过了重新设计,变得更加纤细,并且内置了一个麦克风按钮用于语音搜索。它现在有了些实质界面并且够实时搜索,不仅仅是搜索互联网,还能搜索你的应用和历史。

“清除通知”按钮大幅缩水并且去掉了“通知”字样。在稍晚些的安卓后续版本总它还会缩减成仅仅是个方形按钮。相册继续遵循了把功能从菜单里拿出来的趋势,并且将它们放在用户面前——单张图片查看界面得到了“设置为”、“分享”以及“删除”按钮。


Ron Amadeo / Ron 是 Ars Technica 的评论编缉,专注于安卓系统和谷歌产品。他总是在追寻新鲜事物,还喜欢拆解事物看看它们到底是怎么运作的。 @RonAmadeo


via: http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/9/

译者:alim0x 校对:wxy

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

微软终于承认了开源世界的潜力,尤其是对 Linux 而言,所以,微软正在尝试以各种方式来在开源领域开疆辟土。

最近,在微软的 Channel 9 上的一则名为“改进 Bash on Windows 和 Windows 控制台”的视频节目中,其高级程序经理 Rich Turner 呼吁 Linux 开发人员放弃 Linux ,转到 Windows 10 上来。

他解释说,“(Linux 开发者)可以启动 Windows 10 Insiders 实例,并在其中运行其代码和工具,把网站托管到 Apache 上,并用 Java 代码来访问其 MySQL 数据库。”

他继续补充说,Windows 中的 Linux 子系统将给开发者们提供所有他们在 Linux 开发中必要的工具,而不用丧失 Windows 10 的优势。

“就像在 Linux 中一样构建应用,无论它是用 Go 写的,还是用 Erlang、C,你可以在 Bash on Windows 中试试你要用的任何东西,有 bug 就丢给我们来解决。我们的目标就是构建一个大家都能用的、更高效的产品给大家。”

微软正在致力于改善 Windows 10 上 Linux 子系统,最终目标是让当前 Linux 上的所有开发工具都能兼容地运行在 Windows 10 之中,让所有切换到他们的操作系统的开发者都能够用上。

最近,微软作为白金会员加入了 Linux 基金会,许诺为开源世界的开发做出贡献。这个事情令很多人都很吃惊,特别是其前 CEO 巴尔默还曾经称 Linux 为“癌症”,但是随着新 CEO 萨提亚上任之后,微软的画风大变,这个软件巨人正在逐渐深入到开源生态之中。