mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
Merge remote-tracking branch 'upstream/master'
This commit is contained in:
Yinux
commit
e7ab56c561
144
published/20160815 How to manage binary blobs with Git.md
Normal file
144
published/20160815 How to manage binary blobs with Git.md
Normal file
@ -0,0 +1,144 @@
|
||||
Git 系列（七）：使用 Git 管理二进制大对象
|
||||
=====================
|
||||
|
||||
通过这系列的前六篇文章，我们已经学会使用 Git 来对文本文件进行版本控制的管理。我们不禁要问，还有二进制文件呢，也可进行进行版本控制吗？答案是肯定的，Git 已经有了可以处理像多媒体文件这样的二进制大对象块（blob）的扩展。因此，今天我们会学习使用 Git 来管理所谓的二进制资产。
|
||||
|
||||
似乎大家都认可的事就是 Git 对于大的二进制对象文件支持得不好。要记住，二进制大对象与大文本文件是不同的。虽然 Git 对大型的文本文件版本控制毫无问题，但是对于不透明的二进制文件起不了多大作用，只能把它当作一个大的实体黑盒来提交。
|
||||
|
||||
设想这样的场景，有一个另人兴奋的第一人称解密游戏，您正在为它制作复杂的 3D 建模，源文件是以二进制格式保存的，最后生成一个 1GB 大小的的文件。您提交过一次，在 Git 源仓库历史中有一个 1GB 大小的新增提交。随后，您修改了下模型人物的头发造型，然后提交更新，因为 Git 并不能把头发从头部及模型中其余的部分离开来，所以您只能又提交 1GB 的量。接着，您改变了模型的眼睛颜色，提交这部分更新：又是 GB 级的提交量。对一个模型的一些微小修改，就会导致三个 GB 级的提交量。对于想对一个游戏所有资源进行版本控制这样的规模，这是个严重的问题。
|
||||
|
||||
不同的是如 `.obj` 这种格式的文本文件，和其它类型文件一样，都是一个提交就存储所有更新修改状态，不同的是 `.obj` 文件是一系列描述模型的纯文本行。如果您修改了该模型并保存回 `.obj` 文件，Git 可以逐行读取这两个文件，然后创建一个差异版本，得到一个相当小的提交。模型越精细，提交就越小，这就是标准的 Git 用例。虽然文件本身很大，但 Git 使用覆盖或稀疏存储的方法来构建当前数据使用状态的完整描述。
|
||||
|
||||
然而，不是所有的都是纯文本的，但都要使用 Git，所以需要解决方案，并且已经出现几个了。
|
||||
|
||||
[OSTree](https://ostree.readthedocs.io/en/latest/) 开始是作为 GNOME 项目出现的，旨在管理操作系统的二进制文件。它不适用于这里，所以我直接跳过。
|
||||
|
||||
[Git 大文件存储](https://git-lfs.github.com/)（LFS） 是放在 GitHub 上的一个开源项目，是从 git-media 项目中分支出来的。[git-media](https://github.com/alebedev/git-media) 和 [git-annex](https://git-annex.branchable.com/walkthrough/) 是 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 的一些开发工具包）。安装说明在[其网站](https://github.com/alebedev/git-media)上。想使用 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 seth@example.com:/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 seth@example.com:/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][a]
|
||||
译者：[runningwater](https://github.com/runningwater)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
@ -0,0 +1,80 @@
|
||||
安卓编年史（9）：安卓 1.6 Donut——CDMA 支持将安卓带给了各个运营商
|
||||
================================================================================
|
||||
|
||||
|
||||
*新版安卓市场——黑色比重减少，白色和绿色增多。
|
||||
[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][a] / Ron 是 Ars Technica 的评论编缉，专注于安卓系统和谷歌产品。他总是在追寻新鲜事物，还喜欢拆解事物看看它们到底是怎么运作的。
|
||||
[@RonAmadeo][t]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/9/
|
||||
|
||||
译者：[alim0x](https://github.com/alim0x) 校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://arstechnica.com/author/ronamadeo
|
||||
[t]:https://twitter.com/RonAmadeo
|
||||
@ -1,3 +1,6 @@
|
||||
|
||||
### rusking translating
|
||||
|
||||
# Forget Technical Debt —Here'sHowtoBuild Technical Wealth
|
||||
|
||||
[Andrea Goulet][58] and her business partner sat in her living room, casually reviewing their strategic plan, when an episode of This Old House came on television. It was one of those moments where ideas collide to create something new. They’d been looking for a way to communicate their value proposition — cleaning up legacy code and technical debt for other companies. And here they were, face to face with the perfect analogy.
|
||||
|
||||
@ -0,0 +1,92 @@
|
||||
The history of Android
|
||||
================================================================================
|
||||
|
||||
>Follow the endless iterations from Android 0.5 to Android 7 and beyond.
|
||||
|
||||
### Android Wear
|
||||
|
||||
* [
|
||||
|
||||
][1]
|
||||
* [
|
||||
|
||||
][2]
|
||||
* [
|
||||
|
||||
][3]
|
||||
* [
|
||||
|
||||
][4]
|
||||
* [
|
||||
|
||||
][5]
|
||||
* [
|
||||
|
||||
][6]
|
||||
|
||||
June 2014 saw Android tackle a new form factor: smartwatches. Google launched "[Android Wear][10]" at Google I/O 2014 with the intention of putting a tiny computer on your wrist. Designing for [a 1.6-inch screens][11] meant having to rethink the entire interface from the ground up, so Google stripped down Android 4.4 KitKat and created a tiny smartwatch OS. Android Wear devices weren't standalone computers. They depended on an Android smartphone running the Android Wear companion app for connectivity, authentication, and app data.
|
||||
|
||||
Android Wear smartwatches were mostly notification machines. With new APIs built into Android 4.3 and up, any notification your phone received would also be shown on the watch—no app support required. The notification action buttons were shipped to the watch as well, giving users a small way to interact with notifications from the watch. Dismissing a notification on the watch would clear it from the phone, allowing users to manage notifications without having to whip out another device. There was also a voice command system and a microphone included in every watch, allowing users to just lift their wrist to wake the watch, say "OK Google," and then issue a command. You could reply-by-voice to messages, too. There was even an app drawer for native watch apps.
|
||||
|
||||
The home screen, of course, showed the time and allowed users to swap home screen looks with tons of different watch styles. The interface used a card motif for notifications. A vertically-scrolling list of notifications would pile up on the watch, included some Google Now cards showing the weather or traffic into. Swiping to the left would dismiss a notification, and swiping to the right would bring up the action buttons one at a time. Tapping on the home screen would bring up the voice command system, and from there you could activate the settings or app drawer. There wasn't much to the initial Android Wear home screen other than that.
|
||||
|
||||
Only 720,000 Android Wear devices shipped in 2014, and since then we haven't seen much growth from the software or hardware. Today, smartphone sales are [falling year-over-year][12], and even after the release of the [Apple Watch][13], no one is really sure what they want their little wrist computers to do. It's apparently going to take until 2017 before Android Wear 2.0 hits the market. Since the Moto 360 brought round devices to the market, we haven't seen much new from hardware vendors.
|
||||
|
||||
### Android 5.0 Lollipop—The most important Android release ever
|
||||
|
||||
|
||||
|
||||
In November 2014, Google launched [Android 5.0 Lollipop][14]. Lots of OS updates get called "the biggest release ever," but that cliche actually holds true for Android 5.0 Lollipop. For starters, it changed the way Android was released. With this version of Android, Google started the "Developer Preview" program, which saw the new OS released in beta form months before the release. With the code name and version number now used as marketing tools, the final name was kept secret during the beta and referred to only by letter. At Google I/O 2014, Google announced the "Android L Developer Preview."
|
||||
|
||||
### FURTHER READING
|
||||
|
||||
[Android 5.0 Lollipop, thoroughly reviewed][7]
|
||||
|
||||
Giving developers (and the rest of the world) four months to wrap their head around this release was definitely needed. Android L contained wide-ranging changes that debuted in this OS and are still being felt today. Lollipop introduced Material Design, which was used a guideline to revamp every single interface of Android. A new runtime called "ART" represented a complete overhaul of the engine that powers Android apps. Google's "OK Google" voice command system was upgraded to work on any screen, and on some devices it could even work when the phone was asleep. Multi-user was brought from tablets to phones. Lollipop also laid the foundation for Android for Work, an enterprise-focused dual persona feature.
|
||||
|
||||
#### Material Design gives Android (and all of Google) an identity
|
||||
|
||||
When Matias Duarte took to the I/O stage and announced Material Design, he unveiled a unified design blueprint for not just Android, but all of Google and the third-party app ecosystem. The idea was that the Android, iOS, Chrome OS, and Web versions of a Google app should all look the same and that all Google products should have consistent iconography, fonts, and behavior. They didn't necessarily need identical layouts across screen sizes, but Material Design offered building blocks with consistent behavior that could be rearranged based on the screen size.
|
||||
|
||||
Duarte and his team had experimented with a "Tron" aesthetic in Honeycomb, and a "Card" motif in Jelly Bean, but Material Design finally represented a cohesive design system for all of Google. Material Design went beyond UI guidelines and became an identity for Google as a company.
|
||||
|
||||
The primary metaphor for Material Design is "paper and ink." All UI surfaces were sheets of "paper" that floated above a bottom surface. Shadows were used to provide hierarchy to the interface—each layer of the UI occupied a position in Z space and casted a shadow on the elements below it. This was a clear evolution of the "Card" style used in Google Now on Android 4.1\. "Ink" was used to refer to the bold splashes of color that Google recommended to developers for important items in the UI. These concepts also referenced real world things, which went against the anti-skeuomorphic "flat at any cost" trend that was brought about by things like Windows 8 and iOS 7.
|
||||
|
||||
Anination was a big focus, too, with the idea that nothing should "pop" onto the screen. Components should slide in, shrink, or grow. The "paper" surfaces didn't quite work like real world paper, either they could shrink, expand, merge, and grow. To make the animation system work with image assets, shadows weren't baked into the UI widgets the way they were in previous versions—Google actually created a real-time, 3D shadowing system so that shadows would be correctly rendered during these animations and transitions.
|
||||
|
||||
|
||||
|
||||
<figcaption class="caption" style="box-sizing: inherit; position: relative; margin-top: -6px;">An exaggerated side view of Lollipop's layered interface and the shadows it creates.[Google I/O 2014 - Material design principles][8]</figcaption>
|
||||
|
||||
To bring Material Design to the rest of Google and the app ecosystem, Google created and still maintains [a cohesive set of design guidelines][15] describing how everything should work. There are DOs and DON'Ts, keylines, baseline grids, color swatches, stock iconography, fonts, libraries, layout suggestions, and more. Google even started regularly holding [design-focused conferences][16]to hear from and educate designers, and the company founded the [Material Design awards][17]. Shortly after the launch of Material Design, Duarte left the Android team and became VP of Material Design at Google, creating a whole design-focused division of the company.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/27/
|
||||
|
||||
作者：[RON AMADEO][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://arstechnica.com/author/ronamadeo
|
||||
[1]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/27/#
|
||||
[2]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/27/#
|
||||
[3]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/27/#
|
||||
[4]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/27/#
|
||||
[5]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/27/#
|
||||
[6]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/27/#
|
||||
[7]:http://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/
|
||||
[8]:https://www.youtube.com/watch?v=isYZXwaP3Q4
|
||||
[9]:http://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/
|
||||
[10]:http://arstechnica.com/gadgets/2014/06/android-wear-review/
|
||||
[11]:http://arstechnica.com/gadgets/2014/06/reviewing-android-wears-first-watches-sometimes-promising-often-frustrating/
|
||||
[12]:http://www.businesswire.com/news/home/20161024005145/en/Smartwatch-Market-Declines-51.6-Quarter-Platforms-Vendors
|
||||
[13]:http://arstechnica.com/apple/2015/05/review-the-absolutely-optional-apple-watch-and-watch-os-1-0/
|
||||
[14]:http://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/
|
||||
[15]:https://design.google.com/resources/
|
||||
[16]:https://design.google.com/events/
|
||||
[17]:https://design.google.com/articles/material-design-awards/
|
||||
|
||||
|
||||
@ -0,0 +1,117 @@
|
||||
The history of Android
|
||||
================================================================================
|
||||
|
||||
>Follow the endless iterations from Android 0.5 to Android 7 and beyond.
|
||||
|
||||
#### ART—The Android Runtime provides a platform for the future
|
||||
|
||||
There aren't too many components that can trace their lineage all the way back to Android 1.0, but in 2014 one of them was Dalvik, the runtime that powers Android apps. Dalvik was originally designed for single-core, low-performance devices, and it prioritized storage and memory usage over performance. Over the years, Google bolted on more and more upgrades to Dalvik, like JIT support, concurrent garbage collection, and multi-process support. But with the advent of multi-core phones that were many times faster than the T-Mobile G1, upgrades could only take Android so far.
|
||||
|
||||
The solution was to replace Dalvik with ART, the Android RunTime, a new app engine written from the ground up for modern smartphone hardware. ART brought an emphasis on performance and UI smoothness. ART brought a switch from JIT (Just-in-time) compilation to AOT (Ahead-of-time) compilation. JIT would compile an app every time it was run, saving storage space since compiled code was never written to disk, but instead it took up more CPU and RAM. AOT would save the compiled code to disk, making app start faster and reducing memory usage. Rather than shipping precompiled code, ART would compile code on the device as part of installation, giving the compiler access to device-specific optimizations. ART also brought support for 64-bit which, in addition to more addressable memory, brings better performance from the 64-bit instruction set (particularly in media and cryptography apps).
|
||||
|
||||
The best part was this change brought these performance improvements and 64-bit support to every java Android app. ART generates code for every java app, thus any improvements to ART automatically come to these apps. ART was also written with future upgrades in mind, so it would be able to evolve along with Android.
|
||||
|
||||
#### A system-wide interface refresh
|
||||
|
||||
|
||||
* [
|
||||
|
||||
][1]
|
||||
* [
|
||||
|
||||
][2]
|
||||
* [
|
||||
|
||||
][3]
|
||||
* [
|
||||
|
||||
][4]
|
||||
* [
|
||||
|
||||
][5]
|
||||
* [
|
||||
|
||||
][6]
|
||||
* [
|
||||
|
||||
][7]
|
||||
* [
|
||||
|
||||
][8]
|
||||
|
||||
Material Design brought a complete overhaul to nearly every interface in Android. For starters, the entire core System UI was changed. Android got a revamped set of buttons that look a bit like a PlayStation controller: triangle, circle, and square buttons now represented back, home, and recent apps, respectively. The status bar was all new thanks to a set of redesigned icons.
|
||||
|
||||
Recent apps got a big revamp, switching from a vertical list of small thumbnails to a cascading view of large, almost fullscreen thumbnails. It also got a new name (which didn't really stick) called "Overview." This definitely seems like something that was inspired by Chrome's tab switcher in past versions.
|
||||
|
||||
Chrome's tab switcher was gone in this release, by the way. In an attempt to put Web apps on even ground with installed apps, Chrome tabs were merged into the Overview list. That's right: the list of recent "apps" now showed recently opened apps mixed in with recently opened websites. In Lollipop, the recent apps list also took a "document centric" approach, meaning apps could put more than one listing into the recent apps list. For instance if you opened two documents in Google Docs, both would be shown in recent apps, allowing you to easily switch between them rather than having to switch back and forth via the app's file list.
|
||||
|
||||
The notification panel was all new. Google brought the "card" motif to the notification panel, storing each item in its own rectangle. Individual notifications changed from a dark background to a white one with better typography and round icons. These new notifications came to the lock screen, changing it from a mostly-useless interstitial screen to a very useful "here's what happened while your were gone" screen.
|
||||
|
||||
Full screen notifications for calls and alarms were banished, replaced with a "heads up" notification that would pop into the top part of the screen. Heads-up notifications also came to "high-priority" app notifications, which were originally intended for IM messages. It was up to developers to decide what was a high-priority notification though, and after developers realized this would make their notifications more noticeable, everyone started forcing them on users. Later versions of Android would fix this by giving users control over the "high-priority" setting.
|
||||
|
||||
Google also added a separate-but-similarly-named "priority" notification system to Lollipop. "Priority" notification was a mode in-between completely silent and "beep for everything" allowing users to flag certain people and apps as "important." Priority mode would only beep for these important people. In the UI, this took the form of a set of notification priority controls attached to the volume popup and a new settings screen for priority notifications. And whenever you were in priority mode, there was a little star in the status bar.
|
||||
|
||||
Quick Settings got a huge series of improvements The controls were now a panel _above_ the notification panel, so that it could be opened with a "double swipe down" gesture. The first pull down would open the notification panel, and the second pull down gesture would shrink the notification panel and open Quick Settings. The layout of the Quick Settings controls changed, dumping the tile layout for a series of buttons floating on a single panel. The top was a very handy brightness slider, followed by buttons for connectivity, auto rotate, the flashlight, GPS, and Chromecast.
|
||||
|
||||
There were also actual in-line panels now in the Quick Settings. It would display Wi-Fi access points, Bluetooth device, and data usage right in the main interface.
|
||||
|
||||
|
||||
* [
|
||||
|
||||
][9]
|
||||
* [
|
||||
|
||||
][10]
|
||||
* [
|
||||
|
||||
][11]
|
||||
* [
|
||||
|
||||
][12]
|
||||
* [
|
||||
|
||||
][13]
|
||||
* [
|
||||
|
||||
][14]
|
||||
* [
|
||||
|
||||
][15]
|
||||
|
||||
The Material Design revamp gave nearly every app a new icon and brought a brighter, white background to the app drawer. There were lots of changes to the default apps loadout. Say "hello" to the new apps: Contacts, Docs, Fit, Messenger, Photos, Play Newsstand, Sheets, and Slides. Say "goodbye" to the dead apps: Gallery, G+ Photos, People, Play Magazines, Email, and Quickoffice.
|
||||
|
||||
Many of these new apps came from Google Drive, which split up from a monolithic app into an app for each product. There was now Drive, Docs, Sheets, and Slides, all from the Drive team. Drive is also responsible for the death of Quickoffice, which was consumed by the Drive team. In the "Google can never make up its mind" category: "People" got renamed back to "Contacts" again, and an SMS app called "Messenger" was reinstated at the behest of cellular carriers. (Those carriers did _not_ like Google Hangouts taking over SMS duties.) We got one genuinely new service: Google Fit, a fitness tracking app that worked on Android phones and Android Wear watches. There was also a revamp of Play Magazines to include websites, so it changes names to "Play Newsstand."
|
||||
|
||||
There were more cases of proprietary Google apps taking over for AOSP.
|
||||
|
||||
* "G+ Photos" became "Google Photos" and took over default picture duties from the AOSP Gallery, which became a dead app. The name change to "Google Photos" was in preparation for Photos being [pulled out of Google+][16] and launching as a standalone service. The Google Photos launch would happen about six months after the launch of Lollipop—for now, this is just the Google+ app spawning a new icon and interface.
|
||||
* Gmail took over POP3, IMAP, and Exchange e-mail duties from the "Email" app. Despite being dead Email still had an app icon, which was a fake—it only displayed a message that told users to setup all e-mail accounts in the Gmail app.
|
||||
* The "People" to "Contacts" change was actually to "Google Contacts" another AOSP replacement app.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/
|
||||
|
||||
作者：[RON AMADEO][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://arstechnica.com/author/ronamadeo/
|
||||
[1]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[2]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[3]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[4]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[5]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[6]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[7]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[8]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[9]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[10]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[11]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[12]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[13]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[14]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[15]:http://arstechnica.com/gadgets/2016/10/building-android-a-40000-word-history-of-googles-mobile-os/28/#
|
||||
[16]:http://arstechnica.com/gadgets/2015/05/google-photos-leaves-google-launches-as-a-standalone-service/
|
||||
@ -1,233 +0,0 @@
|
||||
OneNewLife translating
|
||||
|
||||
Apache Vs Nginx Vs Node.js And What It Means About The Performance Of WordPress Vs Ghost
|
||||
============================================================
|
||||
|
||||
|
||||
|
||||
Ultimate battle of the giants: can the rising star Node.js prevail against the titans Apache and Nginx?
|
||||
|
||||
|
||||
Just like you, I too have read the various kinds of opinions / facts which are scattered all over the Internet throughout all sorts of sources, some of which I consider reliable, while others, perhaps shady or doubtful.
|
||||
|
||||
Many of the sources I read were quite contradicting, ahm – did someone say StackOverflow?[1][2], others showed a clear yet surprising results[3] thus having a crucial role in pushing me towards running my own tests and experiments.
|
||||
|
||||
At first, I did some thought experiments thinking I may avoid all the hassle of building and running physical tests of my own – I was drowning deep in those before I even knew it.
|
||||
|
||||
Nonetheless, looking backwards on it, it seem that my initial thoughts were quite accurate after all and have been reaffirmed by my tests; a fact which reminds me of what I learned back in school regarding Einstein and his photoelectric effect experiments where he faced a wave–particle duality and initially concluded that the experiments were affected by his state of mind, that is, when he expected the result would be a wave then so it was and vice versa.
|
||||
|
||||
That said, I’m pretty sure my results won’t prove to be a duality anytime in the near future, although my own state of mind probably did had an effect, to some extents, on them.
|
||||
|
||||
### About The Comparison
|
||||
|
||||
One of the sources I read came up with a revolutionary way, in my view, to deal with the natural subjectiveness and personal biases an author may have.
|
||||
|
||||
A way which I decided to embrace as-well, thus I declare the following in advance:
|
||||
|
||||
Developers spend many years honing their craft. Those who reach higher levels usually make their own choice based on a host of factors. It’s subjective; you’ll promote and defend your technology decision.
|
||||
|
||||
That said, the point of this comparison is not to become another “use whatever suits you, buddy” article. I will make recommendations based on my own experience, requirements and biases. You’ll agree with some points and disagree with others; that’s great — your comments will help others make an informed choice.
|
||||
|
||||
And thank you to Craig Buckler of [SitePoint][2] for re-enlightening me regarding the purpose of comparisons – a purpose I tend re-forgetting as I’m trying to please all visitors.
|
||||
|
||||
### About The Tests
|
||||
|
||||
All test were ran locally on an:
|
||||
|
||||
* Intel core i7-2600k machine of 4 cores and 8 threads.
|
||||
* **[Gentoo Linux][1]** is the operating system used to run the tests.
|
||||
|
||||
The tool used for benchmarking: ApacheBench, Version 2.3 <$Revision: 1748469 $>.
|
||||
|
||||
The tests included a series of benchmarks, starting from 1,000 to 10,000 requests and a concurrency of 100 to 1,000 – the results were quite surprising.
|
||||
|
||||
In addition, stress test to measure server function under high load was also issued.
|
||||
|
||||
As for the content, the main focus was about a static file containing a number of Lorem Ipsum verses with headings and an image.
|
||||
|
||||
[
|
||||
|
||||
][3]
|
||||
|
||||
Lorem Ipsum and ApacheBenchmark
|
||||
|
||||
The reason I decided to focus on static files is because they remove all sorts of rendering factors that may have an effect on the tests, such as: the speed of a programming language interpreter, how well is an interpreter integrated with the server, etc…
|
||||
|
||||
Also, based on my own experience, a substantial part of the average page load time is usually being spent on static content such as images for example, therefore in order to see which server could save us the most of that precious time it seem more realistic to focus on that part.
|
||||
|
||||
That aside, I also wanted to test a more real case scenario where I benchmarked each server upon running a dynamic page of different CMSs (more details about that later on).
|
||||
|
||||
### The Servers
|
||||
|
||||
As I’m running Gentoo Linux, you could say that either one of my HTTP servers is starting from an optimized state to begin with, since I built them using only the use-flags I actually needed. I.e there shouldn’t be any unnecessary code or module loading or running in the background while I ran my tests.
|
||||
|
||||
[
|
||||
|
||||
][4]
|
||||
|
||||
Apache vs Nginx vs Node.js use-flags
|
||||
|
||||
### 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 was configured with “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 included various tweaks, among them: “sendfile on”, “tcp_nopush on” and “tcp_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`
|
||||
|
||||
The Node.js server used in the static tests was custom built from scratch, tailor made to be as lightweight and fast as possible – no external modules (outside of Node’s core) were used.
|
||||
|
||||
### The Results
|
||||
|
||||
Click on the images to enlarge:
|
||||
|
||||
[
|
||||
|
||||
][5]
|
||||
|
||||
Apache vs Nginx vs Node: performance under requests load (per 100 concurrent users)
|
||||
|
||||
[
|
||||
|
||||
][6]
|
||||
|
||||
Apache vs Nginx vs Node: performance under concurrent users load (per 1,000 requests)
|
||||
|
||||
### Stress Testing
|
||||
|
||||
[
|
||||
|
||||
][7]
|
||||
|
||||
Apache vs Nginx vs Node: time to complete 100,000 requests with concurrency of 1,000
|
||||
|
||||
### What Can We Learn From The Results?
|
||||
|
||||
Judging by the results above, it appears that Nginx can complete the highest amount of requests in the least amount of time, in other words, **Nginx** is the fastest HTTP server.
|
||||
|
||||
Another thing we can learn, which is quite surprising as a matter of fact, is that Node.js can be faster than Nginx and Apache in some cases, given the right amount of concurrent users and requests.
|
||||
|
||||
To those who wonder, the answer is NO, when the number of requests was raised during the concurrency test then Nginx would return to a leading position.
|
||||
|
||||
Unlike Apache and Nginx, Node.js, especially clustered Node, seem to be indifferent to the number of concurrent users hitting it. As the chart shows, clustered Node keeps a straight line at around 0.1 seconds while both Apache and Nginx suffer a variation of about 0.2 seconds.
|
||||
|
||||
A conclusion that can be drawn based on the above statistics is that the smaller the site is the less it matters which server it uses. However, as the site grows larger audience, the more apparent the impact an HTTP server has.
|
||||
|
||||
At the bottom line, when it comes to the raw speed of each server, as it’s depicted by the stress test, my sense is that the most crucial factor behind the performance is not some special algorithm but what it comes down to is actually the programming language each server is running.
|
||||
|
||||
As both Apache and Nginx are using C language – which is AOT (Ahead Of Time) compiled language, Node.js on the other hand is using JavaScript – which is an interpreted / JIT (Just In Time) compiled language. This means there’s additional work for the Node.js server on its way to execute a program.
|
||||
|
||||
This sense I base not only upon the results above but also upon further results, which you’ll see below, where I got pretty much the same performance parity even when using an optimized Node.js server built with the popular Express framework.
|
||||
|
||||
### The Bigger Picture
|
||||
|
||||
At the end of the day, an HTTP server is quite useless without the content it serves. Therefore when looking to compare web servers, a vital part we must take into account is the content we wish to run on top of it.
|
||||
|
||||
Although other function exists as well, the most widely popular use done with an HTTP server is running a website. Hence, to see the real life implications of each server’s performance I decided to compare WordPress – the most widely used CMS (Content Management System) in the world, with Ghost – a rising star with a gimmick of using JavaScript at its core.
|
||||
|
||||
Will a Ghost web-page based on JavaScript alone be able to outperform a WordPress page running on top of PHP and Apache / Nginx?
|
||||
|
||||
That’s an interesting question since Ghost has the advantage of using a single, coherent tool for its actions – no additional layers needed, whereas WordPress needs to rely on the integration between Apache / Nginx and PHP, an integration which might incur significant performance drawbacks.
|
||||
|
||||
Adding to that, there’s also a significant performance difference between PHP and Node.js in favor of the latter, which I’ll briefly talk about below, things might come out a bit differently than initially seemed.
|
||||
|
||||
### PHP Vs Node.js
|
||||
|
||||
In order to compare WordPress and Ghost we must first consider an essential component which affects both.
|
||||
|
||||
Essentially, WordPress is a PHP based CMS while Ghost is Node.js (JavaScript) based. Unlike PHP, Node.js enjoys the following advantages:
|
||||
|
||||
* Non-blocking I/O
|
||||
* Event driven
|
||||
* Modern, less legacy code encumbered
|
||||
|
||||
Since there are plenty of comparisons out there explaining and demonstrating Node.js raw speed over PHP (including PHP 7) I shall not elaborate further on the subject, Google it, I implore you.
|
||||
|
||||
So, given that Node.js outperforms PHP in general, will it be significant enough to make a Node.js website faster than Apache / Nginx with PHP?
|
||||
|
||||
### WordPress Vs Ghost
|
||||
|
||||
When comparing WordPress to Ghost some would say it’s like comparing apples to oranges and for the most part I’ll agree, as WordPress is a fully fledged CMS while Ghost is basically just a blogging platform at the moment.
|
||||
|
||||
However, the two still share many overlapping areas where both can be used to publish thoughts to the world.
|
||||
|
||||
Given that premise, how can we compare the 2 while one runs on totally different code base than the other, including themes and core features.
|
||||
|
||||
Indeed, a scientific lab-conditioned test would be hard to devise. However, in this comparison I’m interested in a more real life case scenario, where WordPress gets to keep its theme and so does Ghost. Thus, the goal here is to have both platform’s web-pages similar in size as possible and let PHP and Node.js do their magic behind the scenes.
|
||||
|
||||
Since the results were measured against different criteria and most importantly not exact same sizes, it wouldn’t be fair to display them side by side in a chart. Hence a table is used instead:
|
||||
|
||||
[
|
||||
|
||||
][8]
|
||||
|
||||
Node vs Nginx vs Apache running WordPress & Ghost. Top 2 rows are WordPress, bottom 2 are Ghost
|
||||
|
||||
As you can see, despite the fact Ghost (Node.js) is loading a smaller sized page (you’d be surprised how much difference can 1kB make) it still remains slower than both WordPress with Nginx and with Apache.
|
||||
|
||||
Also, does preempting every Node server hit with Nginx proxy that serves as a load balancer actually contributes or detracts from performance?
|
||||
|
||||
Well, according to the table above, if it has any effect at all then it is a detracting one – which is a reasonable outcome as adding another layer should make things slower. However, the numbers above shows it just might be negligible.
|
||||
|
||||
But the most important thing the table above shows us is that even though Node.js is faster than PHP, the role an HTTP server has, may surpass the importance of what type of programming language a certain web platform uses.
|
||||
|
||||
Of course, on the other hand, if the page loaded was a lot more reliant on server-side script serving, then the results would of wind up a bit different, I suspect.
|
||||
|
||||
At the end of it, if a web platform really wants to beat WordPress at its own game, performance-wise that is, the conclusion rising from this comparison is it’ll have to have some sort of customized tool a-la PHP-FPM, that will communicate with JavaScript directly (instead of running it as a server) thus it could fully harness JS power to reach a better performance.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://iwf1.com/apache-vs-nginx-vs-node-js-and-what-it-means-about-the-performance-of-wordpress-vs-ghost/
|
||||
|
||||
作者：[Liron][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://iwf1.com/tag/linux
|
||||
[1]:http://iwf1.com/5-reasons-use-gentoo-linux/
|
||||
[2]:https://www.sitepoint.com/sitepoint-smackdown-php-vs-node-js/
|
||||
[3]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/Lorem-Ipsum-and-ApacheBenchmark.jpg
|
||||
[4]:http://iwf1.com/wordpress/wp-content/uploads/2016/10/Apache-vs-Nginx-vs-Node.js-use-flags.jpg
|
||||
[5]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/requests.jpg
|
||||
[6]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/concurrency.jpg
|
||||
[7]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/stress.jpg
|
||||
[8]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/Node-vs-Nginx-vs-Apache-comparison-table.jpg
|
||||
@ -1,88 +1,95 @@
|
||||
几个小窍门帮你管理项目的问题追踪器
|
||||
管理项目问题追踪器的几个小窍门
|
||||
==============================================
|
||||
|
||||
|
||||
***图片来源:*** opensource.com
|
||||
|
||||
对于大多数开源项目来讲，问题追踪系统是至关重要的。虽然市面上有非常多的开源工具提供了这样的功能，但是大量项目还是选择了GitHub自带的问题追踪器（Issue Tracker）。
|
||||
对于大多数开源项目来讲，问题追踪系统是至关重要的。虽然有非常多的开源工具提供了这样的功能，大量项目还是选择了 GitHub 自带的问题追踪器（Issue Tracker）。
|
||||
|
||||
它结构简单，因此其他人可以非常轻松地参与进来，但这才刚刚开始。
|
||||
|
||||
如果没有适当的处理，你的代码仓库会挤满重复的问题单、模糊不明的特性需求单、混淆不清的bug报告单。项目维护者会被大量的组织内协调工作压得喘不过气来，新的贡献者也搞不清楚项目当前的重点工作是什么。
|
||||
如果没有适当的处理，你的储存库（repository）会变得很庞大，挤满重复的问题单、模糊不明的特性需求单、含混的 bug 报告单。项目维护者会被大量工作压得喘不过气来，新的贡献者也搞不清楚项目当前的工作重点是什么。
|
||||
|
||||
接下来，我们一起研究下，如何玩转GitHub的问题单。
|
||||
接下来，我们一起研究下，如何玩转 GitHub 的问题单。
|
||||
|
||||
### 问题单就是用户的故事
|
||||
|
||||
我的团队曾经和开源专家[Jono Bacon][1]做过一次对话，他是[The Art of Community][2]的作者、GitHub的战略顾问和前社区总监。他告诉我们，高质量的问题单是项目成功的关键。尽管有些人把问题单仅仅看作是一堆难题的列表，但是他认为这个难题列表是我们必须要时刻关注、完善管理并进行分类的。他还认为，给问题单打上标签的做法，会令人意想不到的提升我们对代码和社区的了解程度，也让我们更清楚问题的关键点在哪里。
|
||||
我的团队曾经和开源专家 [Jono Bacon][1] 做过一次对话，他是 [The Art of Community][2] 的作者、GitHub 的战略顾问和前社区总监。他告诉我们，高质量的问题单是项目成功的关键。有些人把问题单仅仅看作是一堆你不得不去处理的问题列表，但是如果这些问题单管理完善，进行了分类并打上标签，会令人意想不到的提升我们对代码和社区的了解程度，也让我们更清楚问题的关键点在哪里。
|
||||
|
||||
“在提交问题单时，用户不太会有耐心或者有兴趣把问题的细节描述清楚。在这种情况下，你应当努力花最短的时间，尽量多的获取有用的信息。”，Jono Bacon说。
|
||||
|
||||
“在提交问题单时，用户不太会有耐心或者有兴趣把问题的细节描述清楚。在这种情况下，你应当努力花最短的时间，尽量多的获取有用的信息。”，Jono Bacon 说。
|
||||
|
||||
统一的问题单模板可以大大减轻项目维护者的负担，尤其是开源项目的维护者。我们发现，让用户讲故事的方法总是可以把问题描述的非常清楚。用户讲故事时需要说明“是谁，做了什么，为什么而做”，也就是：我是【何种用户】，为了【达到何种目的】，我要【做何种操作】。
|
||||
|
||||
实际操作起来，大概是这样的：
|
||||
|
||||
>我是一名顾客，我想付钱，所以我想创建个账户。
|
||||
>我是一名**顾客**，我想**购买东西**，所以我想**创建个账户**。
|
||||
|
||||
我们建议，问题单的标题始终使用这样的用户故事形式。你可以设置[问题单模板][3]来保证这点。
|
||||
我们建议，问题单的标题始终使用这样的用户故事形式。你可以设置[问题单模板][3]来保证一致性。
|
||||
|
||||
|
||||
> 问题单模板让特性需求单保持统一的形式
|
||||
|
||||
|
||||
*问题单模板让特性需求单保持统一的形式*
|
||||
|
||||
这个做法的核心点在于，问题单要清晰的呈现给它涉及的每一个人：它要尽量简单的指明受众（或者说用户），操作（或者说任务），和输出（或者说目标）。不过，不需要过分拘泥于这个模板，只要能把故事里的是什么事情或者是什么原因说清楚，就达到目的了。
|
||||
|
||||
这个做法的核心点在于，问题单要被清晰的呈现给它涉及的每一个人：它要尽量简单的指明受众（或者说用户），操作（或者说任务），和收益（或者说目标）。你不需要拘泥于这个具体的模板，只要能把故事里的是什么事情或者是什么原因搞清楚，就达到目的了。
|
||||
|
||||
### 高质量的问题单
|
||||
|
||||
问题单的质量是参差不齐的，这一点任何一个开源软件的贡献者或维护者都能证实。具有良好格式的问题单所应具备的素质在[The Agile Samurai][4]有过概述。
|
||||
问题单的质量是参差不齐的，这一点任何一个开源软件的贡献者或维护者都能证实。在[《The Agile Samurai》][4]中概述过一个良好的问题单所应具备的素质。
|
||||
|
||||
问题单需要满足如下条件：
|
||||
好的问题单尽量满足如下条件：
|
||||
|
||||
- 客户价值所在
|
||||
- 避免使用术语或晦涩的文字，就算不是专家也能看懂
|
||||
- 可以切分，也就是说我们可以一小步一小步的对最终价值进行交付
|
||||
- 尽量跟其他问题单没有瓜葛，这会降低我们在问题范围上的灵活性
|
||||
- 可以切分，也就是说我们可以逐步解决问题
|
||||
- 尽量跟其他问题单没有瓜葛，依赖其它问题会降低处理的灵活性
|
||||
- 可以协商，也就说我们有好几种办法达到目标
|
||||
- 问题足够小，可以非常容易的评估出所需时间和资源
|
||||
- 可衡量，我们可以对结果进行测试
|
||||
|
||||
### 那其他的呢? 要有约束
|
||||
### 不满足的问题单呢? 要有约束
|
||||
|
||||
如果一个问题单很难衡量，或者很难在短时间内完成，你也一样有办法搞定它。有些人把这种办法叫做”约束“。
|
||||
如果一个问题单很难衡量，或者很难在短时间内完成，你也一样有办法搞定它。有些人把这种办法叫做“约束”（constraints）。
|
||||
|
||||
例如，”这个软件要快“，这种问题单是不符合我们的故事模板的，而且是没办法协商的。多快才是快呢？这种模糊的需求没有达到”好问题单“的标准，但是如果你把一些概念进一步定义一下，例如”每个页面都需要在0.5秒内加载完“，那我们就能更轻松的解决它了。我们可以把”约束“看作是成功的标尺，或者是里程碑。每个团队都应该定期的对”约束“进行测试。
|
||||
例如，“这个产品要快”，这种问题单不符合故事模板，而且是没办法协商的。多快才是快呢？这种模糊的需求没有达到“好问题单”的标准，但是如果你进一步定义一下，例如“每个页面都需要在0.5秒内加载完”，那我们就能更轻松地解决它了。我们可以把“约束”看作是成功的标尺，或者要实现的里程碑。每个团队都应该定期的对“约束”进行测试。
|
||||
|
||||
### 问题单里面有什么？
|
||||
|
||||
敏捷方法中，用户的故事里通常要包含验收指标或者标准。如果是在GitHub里，建议大家使用markdown的清单来概述完成这个问题单需要完成的任务。优先级越高的问题单应当包含更多的细节。
|
||||
敏捷方法中，用户的故事里通常要包含验收指标或者标准。在 GitHub 里，建议大家使用 markdown 的清单来概括解决这个问题单需要完成的任务。优先级越高的问题单应当包含更多的细节。
|
||||
|
||||
比如说，你打算提交一个问题单，关于网站的新版主页的。那这个问题单的子任务列表可能就是这样的：
|
||||
比如说，你打算提交一个关于新版网站主页的问题单。那这个问题单的子任务列表可能就是这样的：
|
||||
|
||||
|
||||
>使用markdown的清单把复杂问题拆分成多个部分
|
||||
|
||||
在必要的情况下，你还可以链接到其他问题单，那些问题单每个都是一个要完成的任务。（GitHub里做这个挺方便的）
|
||||
*使用 markdown 的清单把复杂问题拆分成多个部分*
|
||||
|
||||
将特性进行细粒度的拆分，这样更轻松的跟踪整体的进度和测试，要能更高频的发布有价值的代码。
|
||||
在必要的情况下，你还可以链接到其他问题单，以进一步明确任务。（GitHub 里做这个挺方便的）
|
||||
|
||||
一旦以问题单的形式收到数据，我们还可以用API更深入的了解软件的健康度。
|
||||
将特性定义的越细化，越容易跟踪进度、测试，最终能更高效的发布有价值的代码。
|
||||
|
||||
”在统计问题单的类型和趋势时，GitHub的API可以发挥巨大作用“，Bacon告诉我们，”如果再做些数据挖掘工作，你就能发现代码里的问题点，谁是社区的活跃成员，或者其他有用的信息。“
|
||||
以问题单的形式收到到问题所在后，还可以用 API 更深入的了解软件的健康度。
|
||||
|
||||
有些问题单管理工具提供了API，通过API可以增加额外的信息，比如预估时间或者历史进度。
|
||||
“在统计问题单的类型和趋势时，GitHub API 可以发挥巨大作用”，Bacon告诉我们，“如果再做些数据挖掘工作，你就能发现代码里的问题点，社区里的活跃成员，或者其他有用的信息。”
|
||||
|
||||
### 让大伙都上车
|
||||
有些问题单管理工具提供的 API 可以提高额外信息，比如预估时间或者历史进度。
|
||||
|
||||
### 团队协同一致
|
||||
团队决定使用某种问题单模板后，如何让所有人都照做？存储库里的 ReadMe.md 其实也可以是你们项目的 “How-to” 文档。这个文档应描述清楚这个项目是做什么的（最好是用可以搜索的语言），以及其他贡献者应当如何参与进来（比如提交需求单、bug 报告、建议，或者直接贡献代码）。
|
||||
|
||||
一旦你的团队决定使用某种问题单模板，你要想办法让所有人都按照模板来。代码仓库里的ReadMe.md其实也可以是项目的”How-to“文档。这个文档会描述清除这个项目是做什么的（最好是用可以搜索的语言），并且解释其他贡献者应当如何参与进来（比如提交需求单、bug报告、建议，或者直接贡献代码）
|
||||
|
||||
|
||||
>为新来的合作者在ReadMe文件里增加清晰的说明
|
||||
|
||||
ReadMe文件是提供”问题单指引“的完美场所。如果你希望特性需求单遵循”用户讲故事“的格式，那就把格式写在ReadMe里。如果你使用某种跟踪工具来管理待办事项，那就标记在ReadMe里，这样别人也能看到。
|
||||
*在 ReadMe 文件里增加清晰的说明，供新合作者参考*
|
||||
|
||||
”问题单模板，合理的标签，如何提交问题单的文档，确保问题单被分类，所有的问题单都及时做出回复，这些对于开源项目都至关重要“，Bacon说。
|
||||
ReadMe 文件是提供“问题单指引”的完美场所。如果希望特性需求单遵循“用户讲故事”的格式，那就把格式写在 ReadMe 里。如果使用某种跟踪工具来管理待办事项，那就标记在 ReadMe 里，这样别人也能看到。
|
||||
|
||||
记住一点：这不是为了完成工作而做的工作。这时让其他人更轻松的发现、了解、融入你的社区而设立的规则。
|
||||
“问题单模板、合理的标签、提交问题单的指导文档、确保问题单被分类并及时回应，这些对于开源项目都至关重要”，Bacon 说。
|
||||
|
||||
"关注社区的成长，不仅要关注参与开发者的的数量增长，也要关注那些在问题单上帮助我们的人，他们让问题单更加明确、保持更新，这是活跃沟通和高效解决问题的力量源泉"，Bacon说。
|
||||
记住一点：这不是为了完成工作而做的工作。这是让其他人更轻松的发现、了解、融入你的社区而设立的规则。
|
||||
|
||||
"关注社区的成长，不仅要关注参与开发者的的数量增长，也要关注那些在问题单上帮助我们的人，他们让问题单更加明确、保持更新，这是活跃沟通和高效解决问题的力量源泉"，Bacon 说。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -90,7 +97,7 @@ via: https://opensource.com/life/16/7/how-take-your-projects-github-issues-good-
|
||||
|
||||
作者：[Matt Butler][a]
|
||||
译者：[echoma](https://github.com/echoma)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[jasminepeng](https://github.com/jasminepeng)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
@ -1,75 +0,0 @@
|
||||
安卓编年史
|
||||
================================================================================
|
||||
|
||||
新版安卓市场——黑色比重减少，白色和绿色增多。
|
||||
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][a] / Ron是Ars Technica的评论编缉，专注于安卓系统和谷歌产品。他总是在追寻新鲜事物，还喜欢拆解事物看看它们到底是怎么运作的。
|
||||
[@RonAmadeo][t]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://arstechnica.com/gadgets/2014/06/building-android-a-40000-word-history-of-googles-mobile-os/9/
|
||||
|
||||
译者：[alim0x](https://github.com/alim0x) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://arstechnica.com/author/ronamadeo
|
||||
[t]:https://twitter.com/RonAmadeo
|
||||
@ -1,144 +0,0 @@
|
||||
第七部分 - 使用 Git 管理二进制大对象
|
||||
=====================
|
||||
|
||||
|
||||
通过这系列的前六篇文章，我们已经学会使用 Git 来对文本文件进行版本控制的管理。不禁要问，还有二进制文件呢，也可进行进行版本控制吗？答案是肯定的，Git 已经有了扩展可以处理像多媒体文件这样的二进制大对象块。因此，今天我们会学习使用 Git 来管理所谓的二进制资产。
|
||||
|
||||
似乎大家都认可的事就是 Git 对于大的二进制对象文件支持得不好。要记住，二进制大对象与大文本文件是不同的。虽然 Git 对大型的文本文件版本控制毫无问题，但是对于不透明的二进制文件起不了多大作用，只能把它当作一个大的实体黑盒来提交。
|
||||
|
||||
设想这样的场景，有一个另人兴奋的第一人称解密游戏，您正在为它制作复杂的 3D 建模，源文件是以二进制格式保存的，最后生成一个 1G 大小的的文件。您提交过一次，在 Git 源仓库历史中有一个 1G 大小的新增提交。随后，您修改了下模型人物的头发造型，然后提交更新，因为 Git 并不能把头发和头部及模型中其余的部分离开来，所以您仅仅只能又提交 1G 的量。接着，您改变了模型的眼睛颜色，提交这部分更新：又是 G 字节的提交量。对一个模型的一些微小修改，就会导致三个 G 字节的量提交。对于想对一个游戏所有资源进行版本控制这样的级别，这是个严重的问题。
|
||||
|
||||
对比如 .obj 这种格式的文本文件，和其它模块文件一样，都是一个提交就存储所有更新修改状态，不同的是 .obj 文件是一系列描述模型生成目标的纯文本行。如果您修改了模型并保存出成为 .obj 文件，Git 可以逐行读取这两个文件，然后创建一个差异版本，得到一个相当小的提交。模块越精致，提交就越小，这就是精典的 Git 用例。虽然文件本身很大，但 Git 使用覆盖或稀疏存储的方法来构建当前数据使用状态的完整图案。
|
||||
|
||||
然而，不是所有的都是纯文本的，但都要使用 Git。所以需要解决方案，其实有几个已经浮现了。
|
||||
|
||||
[OSTree](https://ostree.readthedocs.io/en/latest/) 是GNOME 项目用的，旨在管理操作系统的二进制文件。它不适用于这里，所以我直接跳过。
|
||||
|
||||
[Git 大文件存储](https://git-lfs.github.com/)(LFS) 是在 GitHub 上的一个开源项目，是从 git-media 项目中分支出来的。[git-media](https://github.com/alebedev/git-media) 和 [git-annex](https://git-annex.branchable.com/walkthrough/) 是 Git 对于管理大文件的扩展。它们是对同一问题的两种不同的解决方案，各有优点。虽然它们都不是官方的项目，但在我看来，都是独一无二的，体现在：
|
||||
|
||||
* git-media 是一个集中模式，有一个公共资源的存储库。您可以告诉告诉 git-media 大文件需要存储的位置，是在硬盘驱动器、服务器还是在云存储服务器，项目中的每个用户都将该位置视为大型资产的中心主位置。
|
||||
* git-annex 更侧重于分布模式。用户各自创建存储库，每个存储库都有一个存储大文件的本地目录 .git/annex。annexes 会定期同步，只要有需要，每个用户都可以访问到所有的资源。除非是特别配置，否则 git-annex 优先使用本地存储，再使用外部存储。
|
||||
|
||||
基于这些选项，我已经在生产中使用了 git-media 和 git-annex，那么下面会向你们概述其工作原理。
|
||||
|
||||
|
||||
## git-media
|
||||
|
||||
|
||||
git-media 使用的是 Ruby 语言，所以首先要安装 gem(译者注：Gem是基于Ruby的一些开发工具包)。安装说明在[网站](https://github.com/alebedev/git-media)上。想使用 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 的每个存储库中，设置一个属性以将刚刚创建的过滤器合并到要您想分类的介质的文件类型里。别被这种术语混淆。一个更好的术语是“资产”，因为“媒体”通常的意思是音频、视频和照片,但您可能很容易的也会将 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
|
||||
```
|
||||
|
||||
当您对这些类型的文件分级时，文件会被复制到 .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 的生命周期和普通的一样，可以把它当成普通文件和 blobs 文件一样对待，一样进行 commit 操作。操作流程中唯一的不同就是，在某些时候，您应该将您的资产库（er、media 等）同步到共享存储库中。
|
||||
|
||||
当要为团队发布资源或备份资料时，请使用如下命令：
|
||||
|
||||
```
|
||||
$ git media sync
|
||||
```
|
||||
|
||||
使用 git-media 时, 要使发变更的版本（例如，一个已经美声过的音频文件，或者一个已经完成的遮罩绘画，或者一个已经被颜色分级的视频文件）来替换一个文件，您必须明确的告诉 Git 要更新操作。这将覆盖 git-media 的默认设置，如果远程已经存在此文件，就不会重新复制一份文件：
|
||||
|
||||
```
|
||||
$ git update-index --really-refresh
|
||||
```
|
||||
|
||||
当您团队的其他成员(或是您本人，在其它机器上）克隆本仓库时，如果没有在 .git/config 中把 autodownload 选择设置为 true 的话，默认是不会下载资源的。但 git-media 的一个同步命令可解决所有问题。
|
||||
|
||||
## git-annex
|
||||
|
||||
git-annex 的处理流程略微的有些不同，默认是使用本地仓库的，但基本的思想都一样。您可以从分布的仓库中安装 git-annex，或者根据需要从网站上下载安装。与git-media 一样，任何使用 git-annex 的用户都必须在其机器上安装上。
|
||||
|
||||
其初始化设置比 git-media 都简单。运行如下命令，其中替换成您的路径，就可以在您的服务器上创建好裸存储库：
|
||||
|
||||
```
|
||||
$ git init --bare --shared /opt/jupiter.git
|
||||
```
|
||||
|
||||
然后克隆到本地计算机，把它标记为 git-annex 的初始路径：
|
||||
|
||||
```
|
||||
$ git clone seth@example.com:/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.flacadd 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-annexTo seth@example.com:/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][a]
|
||||
译者：[runningwater](https://github.com/runningwater)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
@ -0,0 +1,234 @@
|
||||
OneNewLife translated
|
||||
|
||||
Apache、Nginx 与 Node.js 之争 —— WordPress 与 Ghost 的性能大对决
|
||||
============================================================
|
||||
|
||||
|
||||
|
||||
巨强之间的终极对决：崛起的新星 Node.js 能否战胜巨人 Apache 和 Nginx？
|
||||
|
||||
我和你一样，都阅读过大量散布在互联网各处的意见或事实，其中有一些我认为是可靠的，而其它的可能是谣传，让人难以置信。
|
||||
|
||||
我读过的许多信息是相当矛盾的，有人深信 StackOverflow，而其他人展示了一个清晰的令人惊讶的结果，这在推动我自己去做测试来验证结论的过程中扮演了重要的角色。
|
||||
|
||||
起初，我做了一些思想准备，认为我可以避免自己进行测试来校验结论的麻烦——在我沉浸在这种想法之前我甚至已经知道会这样。
|
||||
|
||||
尽管如此，往后看的时候，似乎我最初的想法是相当准确的，并且已经再次重申我的测试。这个事实让我想起了当年我在学校学到的爱因斯坦和他的光电效应的实验，他面临着一个光的波粒二重性的问题，最初的结论是实验受到他的心理状态的影响，即当他期望结果是一个波的时候结果就会是一个波，反之亦然。
|
||||
|
||||
也就是说，我坚信我的结果不会在不久的将来被证明是一个二重性，虽然我的心理状态可能在某种程度上对他们有影响。
|
||||
|
||||
### 关于比较
|
||||
|
||||
在我看来，我阅读的一个来源给作者处理自然现象和个人偏见带来了一种革命性的方式。
|
||||
|
||||
这同时也是一种我决定接受的方式，因此我提前声明以下内容：
|
||||
|
||||
开发者花了很多年来磨练他们的工艺。那些达到更高水平的人通常参考很多因素来做出自己的抉择。这是主观的；你将会推崇和捍卫你的技术决策。
|
||||
|
||||
也就是说，这个比较点不会成为另一篇“兄弟，使用任何适合你的东西”的文章。我将会根据我的自身经验、要求和偏见提出建议。你会同意一些观点，反对他人；这是很好的——你的意见会帮助别人做出明智的选择。
|
||||
|
||||
感谢 Craig Buckler 的 [建站观点][2]，这重新启发了我比较的意义——尝试重新忘记自我，并试图让所有的读者心悦诚服。
|
||||
|
||||
### 关于测试
|
||||
|
||||
所有的测试都在本地运行：
|
||||
|
||||
* 英特尔酷睿 i7-2600k，四核心八线程的机器
|
||||
* **[Gentoo Linux][1]** 是用于测试的操作系统
|
||||
|
||||
用于基准测试的工具：ApacheBench，2.3 版（次版本：1748469）
|
||||
|
||||
测试包括一系列基准，从 1000 到 10000 个请求以及从 100 到 1000 个的并发请求——结果相当令人惊讶。
|
||||
|
||||
此外，我还进行了在高负载下测量服务器功能的压力测试。
|
||||
|
||||
至于内容，主要是一个包含一些 Lorem Ipsum 的标题和一张图片静态文件。
|
||||
|
||||
[
|
||||
][3]
|
||||
|
||||
Lorem Ipsum 和 ApacheBenchmark
|
||||
|
||||
我决定专注于静态文件的原因是因为它们删除了可能对测试产生影响的各种渲染因素，例如：编程语言解释器的速度、解释器与服务器的集成程度等等。
|
||||
|
||||
此外，基于我的自身经验，平均网页加载时间的很大一部分通常用于静态内容，例如图片，因此关注哪个服务器可以节省我们加载静态内容的时间是比较现实的。
|
||||
|
||||
除此之外，我还想测试一个更加真实的案例，案例中我在运行不同 CMS 的动态页面（稍后将详细介绍）时对服务器进行基准测试。
|
||||
|
||||
### 服务器
|
||||
|
||||
正如我用的是 Gentoo Linux，你可以说我的 HTTP 服务器在一开始就已经经过优化了，因为我在构建系统的时候只使用了我实际需要的东西。也就是说，当我运行我的测试的时候，不应该在后台运行任何不必要的代码或加载没用的模块。
|
||||
|
||||
[
|
||||
][4]
|
||||
|
||||
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 on`、`tcp_nopush on` 和 `tcp_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 核心模块除外）。
|
||||
|
||||
### 测试结果
|
||||
|
||||
点击图片以放大：
|
||||
|
||||
[
|
||||
][5]
|
||||
|
||||
Apache、Nginx 与 Node 的对比：请求负载的性能（每 100 位并发用户
|
||||
|
||||
[
|
||||
][6]
|
||||
|
||||
Apache、Nginx 与 Node 的对比：用户负载能力（每 1000 个请求）
|
||||
|
||||
### 压力测试
|
||||
|
||||
[
|
||||
][7]
|
||||
|
||||
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 框架。
|
||||
|
||||
### The Bigger Picture
|
||||
|
||||
一天就这么过去了，如果没有服务的内容，HTTP 服务器是没什么用的。因此，在比较 web 服务器的时候，我们必须考虑的一个重要的部分就是我们希望在上面运行的内容。
|
||||
|
||||
虽然其它功能也存在，但是 HTTP 服务器最广泛的使用就是运行网站。因此，为了看到每台服务器的性能对现实生活的影响，我决定比较一下 WordPress ——世界上使用最广泛的 CMS（内容管理系统）和 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 在幕后斗智斗勇。
|
||||
|
||||
由于结果是根据不同的标准进行测量的，最重要的是尺度不一样，因此在图表中并排显示它们是不公平的。因此，我改为使用表：
|
||||
|
||||
[
|
||||
][8]
|
||||
|
||||
Node、Nginx、Apache 以及运行 WordPress 和 Ghost 的比较。前两行是 WordPress，底部的两行是 Ghost
|
||||
|
||||
正如你所见，尽管事实上 Ghost（Node.js）正在加载一个更小的页面（你可能会惊讶 1 字节可以产生这么大的差异），它仍然比同时使用 Nginx 和 Apache 的 WordPress 要慢。
|
||||
|
||||
此外，抢占每个 Node 服务器使用 Nginx 代理作为负载均衡器实际上会提升还是降低性能？
|
||||
|
||||
那么，根据上面的表格，如果说它产生什么效果的话，它造成了减益的效果——这是一个合理的结果，因为额外封装一层理所当然会使其变得更慢。当然，上面的数字也表明这可以忽略不计。
|
||||
|
||||
但是上表中最重要的一点是，即使 Node.js 比 PHP 快，HTTP 服务器的作用也可能超过某个 web 平台使用的编程语言的重要性。
|
||||
|
||||
当然，另一方面，如果加载的页面更多地依赖于服务器端的脚本服务，那么我怀疑结果可能会有点不同。
|
||||
|
||||
最后，如果一个 web 平台真的想在自己的天地里击败 WordPress，从这个比较中得出的结论就是，要想性能占优，必须要定制一些像 PHP-FPM 的工具，它将直接与 JavaScript 通信（而不是作为服务器来运行），因此它可以完全利用 JS 的力量来达到更好的性能。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://iwf1.com/apache-vs-nginx-vs-node-js-and-what-it-means-about-the-performance-of-wordpress-vs-ghost/
|
||||
|
||||
作者：[Liron][a]
|
||||
译者：[OneNewLife](https://github.com/OneNewLife)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://iwf1.com/tag/linux
|
||||
[1]:http://iwf1.com/5-reasons-use-gentoo-linux/
|
||||
[2]:https://www.sitepoint.com/sitepoint-smackdown-php-vs-node-js/
|
||||
[3]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/Lorem-Ipsum-and-ApacheBenchmark.jpg
|
||||
[4]:http://iwf1.com/wordpress/wp-content/uploads/2016/10/Apache-vs-Nginx-vs-Node.js-use-flags.jpg
|
||||
[5]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/requests.jpg
|
||||
[6]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/concurrency.jpg
|
||||
[7]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/stress.jpg
|
||||
[8]:http://iwf1.com/wordpress/wp-content/uploads/2016/11/Node-vs-Nginx-vs-Apache-comparison-table.jpg
|
||||
@ -0,0 +1,100 @@
|
||||
4 Useful Way to Know Plugged USB Device Name in Linux
|
||||
在Linux系统里识别USB设备名字的4种方法
|
||||
============================================================
|
||||
|
||||
对于初学者来说，在Linux系统里你必须掌握的技术之一就是识别出插入系统里的各种设备。这也许是你的系统硬盘，外部的存储设备或者是可移动设备，比如USB设备或SD闪存卡等。
|
||||
|
||||
现如今，使用USB设备来传输文件是十分常见的事，对于那些喜欢使用命令行的新手来说，当你需要格式化USB设备时，学会使用不同的方法来识别USB设备名是非常重要的。
|
||||
|
||||
如果你插入一个设备到你的系统中，尤其是在桌面环境下，比如USB设备，它会自动挂载到一个指定目录,正常情况下是在/media/username/device-label目录下，之后你就可以进入到该目录下访问那些文件了。然而，在服务器上就不是这么回事了，你必须手动挂载这个设备，并且指定一个挂载点。
|
||||
|
||||
Linux系统使用/dev目录下特定的设备文件来标识插入的设备。你会发现该目录下的某些文件，包括/dev/sda或者/dev/sha表示你的第一个主设备，每个分区使用一个数字来表示，比如/dev/sda1或/dev/sha1表示主设备的第一个分区等等。
|
||||
|
||||
```
|
||||
$ ls /dev/sda*
|
||||
```
|
||||
[
|
||||
|
||||
][3]
|
||||
|
||||
列出Linux系统下所有的设备名
|
||||
|
||||
现在咱们来使用下面一些特殊的命令行工具找出设备名：
|
||||
|
||||
### 使用df命令来找出插入的USB设备名
|
||||
|
||||
查看插入你系统里的每一个设备及对应的挂载点，你可以使用下图中的df命令检查Linux系统磁盘空间使用情况：
|
||||
|
||||
```
|
||||
$ df -h
|
||||
```
|
||||
[
|
||||
|
||||
][5]
|
||||
|
||||
使用df命令查找USB设备名
|
||||
|
||||
### 使用lsblk命令查找USB设备名
|
||||
|
||||
你也可以使用下面的lsblk命令（列出块设备）来列出插入你系统里的所有块设备：
|
||||
|
||||
```
|
||||
$ lsblk
|
||||
```
|
||||
[
|
||||
|
||||
][7]
|
||||
|
||||
列出Linux系统里的块设备
|
||||
|
||||
### 使用fdisk工具识别USB设备名
|
||||
|
||||
fdisk是一个功能强大的工具，用于查看你系统中的所有分区表，包括所有的USB设备，使用root权限执行如下命令：
|
||||
```
|
||||
$ sudo fdisk -l
|
||||
```
|
||||
[
|
||||
|
||||
][9]
|
||||
|
||||
列出块设备的分区表
|
||||
|
||||
### 使用dmesg命令来识别出USB设备名
|
||||
|
||||
dmesg是一个重要的用于打印或者控制内核环形缓冲区的命令。环形缓冲区是一种数据结构，它存放着内核操作数据的信息。
|
||||
|
||||
运行如下的命令来查看内核操作信息，它同时也会打印出USB设备的信息：
|
||||
|
||||
```
|
||||
$ dmesg
|
||||
```
|
||||
[
|
||||
|
||||
][11]
|
||||
|
||||
dmesg – 打印USB设备名
|
||||
|
||||
以上就是这篇文章中提及到的所有命令，我们在命令行下使用不同的方法来找出USB设备名。你也可以跟大家分享下实现这个目的的其它方法，或者如果你对这篇文章有什么想法也可以在下面跟大家交流下。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/find-usb-device-name-in-linux
|
||||
|
||||
作者：[Aaron Kili ][a]
|
||||
译者：[rusking](https://github.com/rusking)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/aaronkili/
|
||||
[1]:http://www.tecmint.com/tag/linux-tricks/
|
||||
[2]:http://www.tecmint.com/mount-filesystem-in-linux/
|
||||
[3]:http://www.tecmint.com/wp-content/uploads/2016/10/List-All-Linux-Device-Names.png
|
||||
[4]:http://www.tecmint.com/how-to-check-disk-space-in-linux/
|
||||
[5]:http://www.tecmint.com/wp-content/uploads/2016/10/Find-USB-Device-Name.png
|
||||
[6]:http://www.tecmint.com/commands-to-collect-system-and-hardware-information-in-linux/
|
||||
[7]:http://www.tecmint.com/wp-content/uploads/2016/10/List-Linux-Block-Devices.png
|
||||
[8]:http://www.tecmint.com/fdisk-commands-to-manage-linux-disk-partitions/
|
||||
[9]:http://www.tecmint.com/wp-content/uploads/2016/10/List-Partition-Table.png
|
||||
[10]:http://www.tecmint.com/dmesg-commands/
|
||||
[11]:http://www.tecmint.com/wp-content/uploads/2016/10/dmesg-shows-kernel-information.png
|
||||
Loading…
Reference in New Issue
Block a user