Android 2.3 Gingerbread——第一次 UI 大变

Gingerbread（姜饼）发布于 2010 年 12 月，这已是 2.2 发布整整七个月之后了。尽管如此，等待是值得的，因为安卓 2.3 整个系统的每个界面几乎都改变了。这是从安卓 0.9 最初的样式以来第一次重大的更新。2.3 开始了一系列持续的改进，试着将安卓从丑陋的小鸭子变成能承载它自己的合适的样子——从美学角度——来对抗 iPhone。

说到苹果，六个月前，它发布了 iPhone 4 和 iOS 4，新增了多任务处理和 Facetime 视频聊天。微软同样也终于重返这场竞赛。微软在 2010 年 11 月发布了 Windows Phone 7，也进入了智能手机时代。

安卓 2.3 在界面设计上投入了很多精力，但是由于缺乏方向或设计文档，许多应用仅仅止步于获得了一个新的定制主题而已。一些应用用了更扁平的暗色主题，一些用了充满渐变、活泼的暗色主题，其他应用则是高对比度的白色和绿色组合。尽管 2.3 并没有做到风格统一，姜饼还是完成了让系统几乎每个部分变得更现代化的任务。这同样是件好事，因为下一个手机版安卓要在将近一年后才到来。

Nexus S，第一部三星制造的 Nexus 手机。

姜饼的首发设备是 Nexus S，谷歌的第二部旗舰设备，并且是第一部由三星生产的 Nexus 设备。尽管今天我们已经习惯了每年都有更新型号的 CPU，那时候可不是这个样子。Nexus S 有个 1GHz Cortex A8 处理器，和 Nexus One是一样的。GPU 从速度来说略微有所变快。Nexus S 稍微比 Nexus One 大一点，拥有 800×480 分辨率的 AMOLED 显示屏。

从参数上来说，Nexus S 看起来只是个平淡无奇的升级，但它确实开了安卓的许多先河。Nexus S 是谷歌第一部没有 MicroSD 卡槽的旗舰，板载 16GB 存储。Nexus One 只有 512MB 存储空间，但它有 MicroSD 卡槽。移除 SD 卡槽为用户简化了存储管理——现在只有一个存储地点了——但是影响了高级用户的扩展能力。它是谷歌第一部带有 NFC 的手机，手机背面的一个特殊芯片能够在和其他 NFC 芯片接触时传输数据。Nexus S 暂时只能读取 NFC 标签，而不能发送数据。

托姜饼中一些升级的福，Nexus S 是第一部不带有硬件十字方向键或轨迹球安卓手机之一。Nexus S 缩减到只有电源、音量以及四个导航键。Nexus S 同时还是如今疯狂的曲面手机的先驱，因为三星给 Nexus S 配备了一块略微有些弯曲的玻璃。

姜饼更改了状态栏和壁纸，并且添加了许多新图标。 [Ron Amadeo 供图]

升级过的“Nexus”动态壁纸作为 Nexus S 的独有功能发布。这个壁纸基本上和 Nexus One 的一样，带有带动画轨迹的光点。在 Nexus S 上，去除了方阵设计，取而代之的是波浪形的蓝/灰色背景。底部 dock 有了直角和彩色图标。

新通知面板和菜单。 [Ron Amadeo 供图]

状态栏自 0.9 的首次登场以来终于得到了重制。状态栏从白色渐变变成纯黑，所有图标重绘成了灰色和绿色。所有东西看起来都更加清爽和现代，这要感谢锐角图标的设计和高分辨率。最奇怪的决定可能是从状态栏时钟移除了时间段显示以及信号强度那令人疑惑的灰色。尽管灰色被用在状态栏的许多图标上，而且上面截图有四格灰色信号，安卓实际上指示的是没有信号。绿色格表示信号强度，灰色格指示的是“空”信号格。

姜饼的状态栏图标同时还作为网络连接的状态指示。如果你的设备连接到了谷歌的服务器，图标会变绿，如果没有谷歌的连接，图标会是白色的。这让你可以在外出时轻松了解你的网络连接状态。

通知面板的设计从安卓 1.5 的设计改进而来。我们看到 UI 部分再次从浅色主题变为暗色主题，有个深灰色顶部，黑色背景以及在灰色底色上的黑色文本。

菜单颜色同样变深了，背景从白色变成了带点透明的黑色。菜单图标和背景的对比并没有它应该有的那么强烈，因为灰色图标的颜色和它们在白色背景上的时候是一样的。要求改变颜色意味着每个开发者都得制作新的图标，所以谷歌在黑色背景上使用了先前就有的灰色。这是系统级别的改变，所以这个新菜单会出现在每个应用中。

姜饼的新键盘，文本选择，边界回弹效果以及新复选框。 [Ron Amadeo 供图]

安卓 2.3 最重要的新增功能就是系统全局文本选择界面，你可以在左侧截图的谷歌搜索栏看到它。长按一个词能使其变为橙色高亮，并且出现可拖拽的小标签，长按高亮部分会弹出剪切、复制和粘贴选项。之前的方法使用的是依赖于十字方向键的控制，但现在有了触摸文本选择，Nexus S 不再需要额外的硬件控件。

左侧截图右半边展示的是新的复选框设计和边界回弹效果。冻酸奶（2.2）的复选框像个灯泡——选中时显示一个绿色的勾，未选中的时候显示灰色的勾。姜饼在选项关闭的时候显示一个空的选框——这显得更有意义。姜饼是第一个拥有滚动到底发光效果的版本。当到达列表底部的时候会有一道橙色的光晕，你越往上拉光晕越明显。列表上拉滚动反弹也许最直观，但那是苹果的专利。

新拨号界面和对话框设计。 [Ron Amadeo 供图]

姜饼里的拨号器受到了稍微多点的照顾。它变得更暗了，并且谷歌终于解决了原本的直角结合的问题，圆角和圆形已经被抛弃了。现在所有的边角都是直角了。所有的拨号按键被替换成了带有奇怪下划线的样式，像是用边角料拼凑的。你永远无法确定是否看到了一个按钮——我们的大脑得想象出按钮形状的剩余部分。

图中的无线网络对话框可以看作是剩下的系统全局性改动的样本。所有的对话框标题从灰色变为黑色，对话框、下拉框以及按钮边缘都变成了直角，各部分色调都变暗了一点。所有的这些全局变化使得姜饼看起来不像原来那样活泼，而是更加地成熟。“到处都是黑色”的外观必然不是最受欢迎的，但它无疑看起来比安卓之前的灰色和米色的配色方案好多了。

新市场，添加了大块的绿色页面顶栏。 [Ron Amadeo 供图]

新版系统带来了“安卓市场 2.0”，虽然它不是姜饼独有的。主要的列表设计和原来一致，但谷歌将屏幕上部三分之一覆盖上了大块的绿色横幅，用来展示热门应用以及导航。这里主要的设计灵感也许是绿色的安卓吉祥物——它们的颜色完美匹配。在系统设计偏向暗色系的时候，霓虹灯般的绿色横幅和白色列表让市场明快得多。

但是，相同的绿色背景图片被用在了不同的手机上，这意味着在低分辨率设备上，绿色横幅看起来更加的大。不少用户抱怨这浪费了屏幕空间，于是随后的更新使得绿色横幅跟随内容向上滚动。在那时，横屏模式更加糟糕——绿色横幅会填满剩下的半个屏幕。

市场的一个带有可折叠描述的应用详情页面，“我的应用”界面，以及 Google Books 界面截图。 [Ron Amadeo 供图]

应用详情页面经过重新设计有了可折叠部分。文本描述只截取前几行展示，向下滑动页面不用再穿过数千行的描述。简短的描述后有一个“更多”按钮可供点击来显示完整的描述。这让用户可以轻松地滑动过列表找到像是截图和“联系开发者”部分，这些部分通常在页面偏下部分。

安卓主屏的其它部分明智地淡化了绿色机器人元素。市场应用的剩余部分绝大多数仅仅只是旧版市场加上新的绿色导航元素。旧有的标签界面升级成了可滑动切换标签。在姜饼右侧截图中，从右向左滑动将会从“热门付费”切换至“热门免费”，这使得导航变得更加方便。

姜饼带来了将会成为 Google Play 内容商店第一位成员的应用：Google Books。这个应用是个基础的电子书阅读器，会将书籍以简单的预览图平铺展示。屏幕顶部的“获取 eBooks”链接会打开浏览器，然后加载一个你可以在上面购买电子书的移动网站。

Google Books 以及市场的“我的应用”页面都是 Action Bar 的早期原型。就像现在的指南中写的，页面有一个带应用图标的固定置顶栏，应用内页面的名称，以及一些控件。这两个应用的布局实际上看起来十分现代，和现在的界面相似。

新版谷歌地图。 [Ron Amadeo 供图]

谷歌地图（再重复一次，这时候的谷歌地图是在安卓市场中的，并且不是这个安卓版本独占的）拥有了另一个操作栏原型，这是一个顶部对齐的控件栏。这个早期版本的操作栏拥有许多试验性功能。功能栏主要被一个搜索框所占据，但是你永远无法向其输入内容。点击搜索框会打开安卓 1.x 版本以来的旧搜索界面，它带有完全不同的操作栏设计体验和活泼的按钮。2.3 版本的顶栏仅仅只是个大号的搜索按钮而已。

从黑变白的新 business 页面。 [Ron Amadeo 供图]

在应用抽屉里和“地点”一起到来的“热门商家”重新设计了界面。不像姜饼的其它部分，它从黑色转换成了白色。谷歌还给它保留了圆角的旧按钮。这个新版本的地图能显示商家的营业时间，并且提供高级搜索选项，比如正在营业或是通过评分或价格限定搜索范围。点评被调整到了商家详情页面，用户可以更容易地对当前商家有个直观感受。而且现在还可以从搜索结果中给某个地点加星，保存起来以后使用。

新 YouTube 设计，神奇的是有点像旧版地图的商家页面的设计。 [Ron Amadeo 供图]

YouTube 应用似乎完全与安卓的其它部分分离开来，就像是设计它的人完全不知道姜饼最终会是什么样子一样。高亮是红色和灰色方案，而不是绿色和橙色，而且不像扁平黑色风格的姜饼，Youtube 有着气泡状的，带有圆角并且大幅使用渐变效果的按钮、标签以及操作栏。尽管如此，新应用还是有一些正确的地方。所有的标签可以水平滑动切换，而且应用终于提供了竖屏观看视频模式。安卓在那个阶段似乎工作不是很一致。就像是有人告诉 Youtube 团队“把它做成黑色的”，然后这就是全部的指导方向一样。唯一一个与其相似的安卓实体就是旧版谷歌地图的商家页面的设计。

尽管有些奇怪的设计，Youtube 应用有着最接近操作栏的顶栏设计。除了顶部操作栏的应用图标和一些按钮，最右侧还有个标着“更多”字样的按钮，点击它可以打开因为过多而无法装进操作栏的选项。在今天，这被称作“更多操作”按钮，它是个标准界面控件。

新 Google Talk，支持语音和视频通话，以及新语音命令界面。 [Ron Amadeo 供图]

姜饼的最后一个更新是安卓 2.3.4，它带来了新版 Google Talk。不像 Nexus One，Nexus S 带有前置摄像头——重新设计的 Google Talk 拥有语音和视频通话功能。好友列表右侧的彩色指示不仅指明在线状态，还显示了语音和视频的可用性。一个点表示仅支持文本信息，一个麦克风表示支持文本信息或语音，一个摄像机表示支持文本信息、语音以及视频。如果可用的话，点击语音或视频图标会立即向好友发起通话。

姜饼是谷歌仍然提供支持的最老的安卓版本。激活一部姜饼设备并放置一会儿会收到大量更新。姜饼会拉取 Google Play 服务，它会带来许多新的 API 支持，并且会升级到最新版本的 Play 商店。打开 Play 商店并点击更新按钮，几乎每个独立谷歌应用都会被替换为更加现代的版本。我们尝试着保持这篇文章讲述的是姜饼发布时的样子，但时至今日还停留在姜饼的用户会被认为有点跟不上时代了。

姜饼如今仍然能够得到支持，因为有数量可观的用户仍然在使用这个有点过时的系统。姜饼仍然存在的意义来自于它极低的系统要求，使得它成为了低端廉价设备的最佳选择。下个版本的安卓对硬件的要求变得更高了。举个例子，安卓 3.0 蜂巢不是开源的，这意味着它只能在谷歌的协助之下移植到一个设备上。同时它还是只为平板设计的，这让姜饼在相当长的一段时间都是最新的手机安卓版本。4.0 冰淇淋三明治是下一个手机版本，但它显著地提高了安卓系统要求，抛弃了低端市场。谷歌现在希望借 4.4 KitKat（奇巧巧克力）重回廉价手机市场，它的系统要求降回了 512MB 内存。时间的推移同样有所帮助——如今，就算是廉价的系统级芯片都能满足安卓 4.0 时代的系统要求。

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

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

译者：alim0x 校对：wxy

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

使用一款安全开源的密码管理器来储存唯一、复杂的密码来保护你数据及账户的安全。

为你使用的每个站点和服务维护一份唯一、复杂的密码是安全专家每年给公众最常提的建议。

然而不管说过多少遍，几乎每周我们都能听到 XX 网站又被黑了的新闻，问题是这些网站的用户们就爱用一些像“12345”或“password”这样的口令来保护他们的账号。

或许用户对经典的密码做了足够的变形，符合了网站所要求的最低的密码规则。但不幸的是，“Pa$$w0rd!”也不是真正意义上的安全密码。从这方面来说，大多数单词、短语及数字的组合或替换对于密码破解工具而言都太容易破解了，密码越短越容易破解。

最棒的密码应该是长长的，任何可能的字符的随机或者伪随机组合，每个使用场景都用不同的密码。但对一个普通人而言怎么可能记住上百甚至上千个他们创建的独立的账户密码呢？简短的答案是：不能。甚至不管是在现实世界或者数码世界不应该明文记录下任何一个密码。

或许最简单地保存这些复杂、唯一密码的方法是使用密码管理器，它提供了一种访问这些强密码的简单方式。虽然像 LastPass 这样商业解决方案很受欢迎，但是还有一些开源方案。另外对于密码，可以审计你的密码管理器的源码也是很重要的，因为它可以确保你的密码被正确地加密，并且没有后门。

所以不用多说，下面有几款你可以考虑的密码管理器。

KeePass

KeePass 是一个 GPLv2 授权的密码管理器，主要设计用于 Windows ，但是同样可以在其它平台运行。KeePass 提供多个强加密选项、便于导出、多用户密钥、高级搜索特性等等。其为桌面用途设计，也有可以直接运行在浏览器中的插件，并且如果你想要在不同的机器间随身携带你的密码，它可以运行在 U 盘中。想要了解更多 KeePass 信息，你可以从在 Ricardo Frydman 的这篇旧贴中找到。

KeePassX，是 KeePass 的 Linux 移植版本，是另一个你可以考虑的项目。KeePassX 与 KeePass 2 密码文件兼容，并且已经被移植到不同的操作系统上。事实上，KeePass 的非官方版本列表覆盖了日常使用的所有系统。

Padlock

Padlock 是一个最近新进的开源密码管理器。目前在 Windows、iOS、Android 上可用，Linux 版本正在开发中，Padlock 被设计成为了一个“极简风”的密码管理器。它的源码以 GPLv3 授权的形式发布在 Github 上。项目同样也正在开发一个云后端，同样是开源的，这对那些厌烦了管理密码文件或者在多台电脑间设置同步的人而言是一个很好的补充。

Passbolt

Passbolt 是另一个相对较新的选择，它有 Firefox 和 Chrome 的插件，支持移动设备，还有正在开发的命令行。它基于 OpenPGP，你可以查看在线的一些功能演示（虽然这需要你安装浏览器插件）。以 AGPLv3 授权发布，你可以在 Github 上查看它的源码或者浏览一下项目的路线图来了解下目前和将来计划的功能。

使用一款你信任的密码管理器以及用复杂的密码并不能代替其他安全预防措施，它也不是万无一失的。但是对于许多用户而言，它是让你的数字生活保持安全的很重要的一部分。这些的确不是唯一的选择。还有一些更老的选择，比如 Clipperz 和 Password Safe，还有我有兴趣想尝试一下的基于 web 的工具 RatticDB。

你会使用哪款密码管理器？为什么呢？

via: https://opensource.com/article/16/12/password-managers

作者：Jason Baker 译者：geekpi 校对：wxy

本文由 LCTT 组织编译，Linux中国 荣誉推出

如果你要换一部手机或升级你的系统，备份你的数据就变得至关重要。我们存储重要数据的位置之一就是我们的短信/彩信，不管是感情价值还是实用价值，备份它们是很有用的。

然而，不像照片、视频或音频文件可以相对容易地传输和备份，备份短信/彩信比较复杂，通常需要使用第三方 app 或服务。

为什么要手动备份

尽管现在有很多不同的 app 能够帮你备份短信/彩信，你可能因为以下原因，考虑自己动手备份它们：

1. app 可能不能在所有的设备和安卓版本上都工作。
2. app 可能把你的备份数据上传到云端， 有破坏你的内容安全的风险。
3. 通过手动备份，你可以完全掌握你的数据通过哪里，走向哪里，备份过程中减少被间谍软件窥视的危险。
4. 手动备份相比其他方法更省时，更省力，更直接。

怎么手动备份短信/彩信？

要手动备份你的短信/彩信，你需要在你的电脑上安装一个叫做 adb 的安卓工具。

现在，需要重点知道的是，安卓把短信/彩信通常存储在一个叫做 mmssms.db 的数据库里。

因为在不同设备上这个数据库的位置可能不相同，而且，其他短信 app 会创建它们自己的数据库，比如 GO SMS 会创建 gommssms.db 数据库， 所以你需要做的第一件事是搜索这些数据库。

打开命令行工具（我使用了 Linux Terminal， 你也可以使用 Windows CMD 或 PowerShell ）并运行以下命令：

注意： 以下是完成该任务的一系列命令，再后面是每个命令用途的解释。

adb root
adb shell
find / -name "*mmssms*"
exit

adb pull /PATH/TO/mmssms.db /PATH/TO/DESTINATION/FOLDER

解释

一开始我们使用 adb root 命令来以 root 模式启动 adb － 这样我们就有了读取系统保护文件的权限。

adb shell 用来进入设备的 shell。

然后， find 命令用来搜索数据库。（在我的例子中，我发现数据库在 /data/data/com.android.providers.telephony/databases/mmssms.db)

建议：如果你的终端输出了太多无关的结果，可以试试使用 find 的参数来精简结果。(具体参数可以搜索引擎查下)

安卓短信/彩信数据库

然后我们使用 exit 命令回退到我们的本地系统目录。

最后，使用 adb pull 把数据库文件复制到我们电脑的一个文件夹里。

现在，当你想要还原短信/彩信时，不管是还原到新的设备还是新的系统版本， 只要再次搜索新系统中短信/彩信的具体位置，并用我们备份的数据库替换它即可。

使用 adb push 来替换它，例如：

adb push ~/Downloads/mmssms.db /data/data/com.android.providers.telephony/databases/mmssms.db

via: https://iwf1.com/how-to-manually-backup-your-sms-mms-messages-on-android/

作者：Liron 译者：willcoderwang 校对：jasminepeng

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

这篇文章针对开发和部署基于 JavaScript 的应用（服务器端的 Node.js 或者客户端）的各种经验水平的开发者，通过本文，你将看到如何把 AWS SDK， Amazon Cognito Identity SDK 嵌入到 JavaScript 中，以及如何使用流行的 webpack 模块打包器。

2016 年 7 月， AWS 推出了 Amazon Cognito 用户库 （ user pool ） ，这个新特性极大的方便了开发者在移动和 Web 应用程序上添加注册和登录功能。为了让开发者更容易在自己的应用程序中实现用户库功能，我们也发布了用于 JavaScript 的 Amazon Cognito Identity SDK。

Amazon Cognito 用户库可以让你在移动和 Web 应用程序上添加用户注册和登录功能更加容易。全托管用户库可以扩展到数以百万计的用户，你可以在每个 AWS 账户下有多重目录。创建一个用户库只需要几分钟的时间，并且你可以决定当一个新用户在你的应用程序或服务上注册时哪些属性（包括地址、邮箱、电话号码以及自定义属性）是强制的，哪些是可选择的。你的应用程序也可以指定所需的密码强度，指定用户需要进行多因素认证（MFA），以及通过电话号码或者邮件地址来验证新用户，从而进一步加强应用程序的安全性。

如果你是首次接触用于 JavaScript 的 Amazon Cognito Identity SDK，那么请先阅读这篇 AWS 文章作为开始。

为什么在 JavaScript 上使用 Asset 及模块捆绑的 Amazon Cogtito Identity SDK

今天，针对移动和桌面的现代 Web 应用程序都能为用户提供安全、快捷、灵敏以及类本地应用的体验。毫无疑问，现代的浏览器功能足够强大，能够肩负起大量可能的功能实现。许多流行的实现很大程度上依赖于 JavaScript 应用程序通过某种形式的 asset 封装和/或模块捆绑进行部署。这使得许多开发人员能够很好的维护自己的 JavaScript 应用程序，并且可以通过使用 script 标签创建一个或多个可以加载到客户端浏览器上的文件。

关于如何实现打包有许多争鸣，包括 Grunt 和 Gulp 这样的 task runner，以及 Browserity 这样的打包器。然而，一个普遍的共识是， asset 打包不仅可以改善加载时间 - 它可以在确保可测试性和健壮性的前提下使你的应用程序模块化。

使用带有 Amazon Cognito Identity SDK 的 webpack 打包 JavaScript

我们接到了许多请求，要求我们提供如何在 webpack 环境下整合用于 JavaScript 的 Amazon Cognito Identity SDK 的更多细节。我们特地要求确保 webpack 正确管理一下第三方的依赖包：

• 用于 BigInteger 计算的 JavaScript BN 库（jsbn）
• jsbn 扩展及包含大多数公共 BigInteger 方法的其它 jsbn 方法（jsbn2）
• Stanford JavaScript Crypto 库（jscl）

通过这些例子，可以看到，下面这些 bower 库都被 bower.json 使用

"aws-cognito-sdk": "https://raw.githubusercontent.com/aws/amazon-cognito-identity-js/master/dist/aws-cognito-sdk.js",
"amazon-cognito-identity": "https://raw.githubusercontent.com/aws/amazon-cognito-identity-js/master/dist/amazon-cognito-identity.min.js",
"sjcl": "https://raw.githubusercontent.com/bitwiseshiftleft/sjcl/master/sjcl.js",
"jsbn": "https://raw.githubusercontent.com/andyperlitch/jsbn/master/index.js",

出于我们前面给出的关于 asset 打包对于开发过程的重要性的原因，除非你的应用程序非常小，否则使用像 webpack 这样的 asset 打包工具几乎总是必须的。当然，还有一个方法是可以通过使用标签简单的处理所有依赖关系。然而，这会污染全局命名空间，而且不能够提供最优的资源管理和加载方式。许多开发者首次使用的是具有标准 babel 加载器的标准 webpack.config.js 文件，像下面展示的这样。

{
  /** test for file ending in js or jsx 
   * exclude node_module and bower_components - we dont want to babel these 
   * use the babel loader 
   * apply the react and es2015 (es6) transformations **/

  test: /\.jsx?$/,
  exclude: /(node_modules|bower_components)/,
  loader: 'babel',
  query: {
    presets: ['react', 'es2015']
  }
}

需要重点记住的是，这个配置没有考虑一些第三方依赖关系，这些被用于 JavaScript 的 Amazon Cognito Identity SDK 所使用的第三方依赖目前没有使用 JavaScript 通用模块定义(UMD)。

UMD 模式试图提供与 RequireJS 和 CommonJS 这些当前最流行的脚本加载器的异步模块定义 [AMD] 的基本兼容。

这是 webpack 所依赖的模式，为了让 webpack 能够工作，我们必须进行一些改变。不做这些改变，你可能会遇到下面这些错误。

amazon-cognito-identity.min.js:19 Uncaught ReferenceError: BigInteger is not defined

这样一个错误可能会在调用 AWSCognito.CognitoIdentityServiceProvider.CognitoUser property authenticateUser 的时候出现。在这个错误例子中，我们可以利用 webpack 的 import 和 export 加载器的能力来解决这个错误。

使用 webpack 加载器

根据 [webpack 文档]，“加载器允许你通过 require() 或 load 来预处理文件。加载器是一种类似其它构建工具中 “tasks” 的工具，它可以提供一个处理前端构建步骤的强大方法。加载器可以把一个文件从一种语言转化成另一种语言，比如把 CoffeeScript 转化成 JavaScript ，或者把图像转换为 data URL。“

为了解决 UMD 的兼容性缺乏的问题，你必须依赖两个具体的加载器， import 和 export 加载器。

使用 export 加载器

在使用用于 JavaScript 的 Amazon Cognito Identity SDK 的情况下，我们需要确保把 theAWSCognito 变量导出到 require /import 它们的模块的变量范围内（针对 ES6）。

{
  test: /aws-cognito-sdk\/index\.js/,
  loader: 'exports?AWSCognito'
}

在由 webpack 创建的捆绑中，使用 export 加载器会有导出模块方法的效果。因此， 在 require 和 import 后，AWSCognito 和 AWS 是可访问的（针对 ES6）。

var AWSCognito = require('aws-cognito-sdk')

/*** EXPORTS from export-loader ***/ 
module.exports = AWSCongito

这儿可以找到更多关于 export 加载器的信息。

使用 import 加载器

import 加载器主要用于把变量注入（import）到另一个模块的变量范围内。当第三方模块需要依赖全局变量的时候， import 加载器非常有用，比如针对 JavaScript 的 Amazon Cognito Identity SDK 需要依赖 BigInteger 或者 sjcl 的时候。

如果你不使用 webpack 加载器，下面这些内容会在一个捆绑中生成。

__webpack_require__(431);       // refers to jsbin
__webpack_require__(432);       // refers to sjcl

因为 jsbin 和 sjcl 都不能 export 任何东西，因此任何依赖于这些模块的调用都会导致一个错误。

为了解决这个问题，我们需要使用下面的 webpack 加载器配置：

{
  test: /amazon-cognito-identity\/index\.js/,
  loader: 'imports?jsbn,BigInteger=>jsbn.BigInteger,sjcl'
},
{
  test: /sjcl\/index\.js/,
  loader: 'imports?sjcl'
}

这个配置把下面的这些内容嵌入到了由 webpack 创建的捆绑中（此时是 bundle.js）。

/*** IMPORTS FROM imports-loader ***/
var jsbn = __webpack_require__(431);
var BigInteger = jsbn.BigInteger;
var sjcl = __webpack_require__(432);

结果，jsbn、BigInteger 和 sjcl 都被从它们各自的模块中导入到了用于 JavaScript 的 Amazon Cognito Identity SDK 中。

有关 import 加载器的更多信息可以在这儿找到。

下一步

我们鼓励你下载用于 JavaScript 的 Amazon Cognito Identity SDK 并开始构建你的应用，并在这篇文章的指导下通过 webpack 能够迅速掌握。

如果你有任何意见或问题，请在下面自由评论，也可以发邮件到 [email protected] 或者在这儿提出问题。

引用

这篇文章引用了下面这些第三方资源：

• webpack - https://webpack.github.io/
• webpack 文件 - http://webpack.github.io/docs/what-is-webpack.html
• webpack export 加载器 - https://github.com/webpack/exports-loader
• webpack import 加载器 - https://github.com/webpack/imports-loader
• 用于 BigInteger 计算的 JavaScript BN 库- http://www-cs-students.stanford.edu/~tjw/jsbn/jsbn.js
• jsbns - http://www-cs-students.stanford.edu/~tjw/jsbn/jsbn2.js
• Stanford JavaScript Crypto 库 - https://github.com/bitwiseshiftleft/sjcl
• RequireJS - http://requirejs.org/
• CommonJS - http://www.commonjs.org/

via: https://mobile.awsblog.com/post/Tx1A84CLMDJ744T/Using-webpack-with-the-Amazon-Cognito-Identity-SDK-for-JavaScript

作者：Marc Teichtahl 译者：ucasFL 校对：wxy

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

最近我开始发力钻研 Python 的新 asyncio 模块。原因是我需要做一些事情，使用事件 IO 会使这些事情工作得更好，炙手可热的 asynio 正好可以用来牛刀小试。从试用的经历来看，该模块比我预想的复杂许多，我现在可以非常肯定地说，我不知道该如何恰当地使用 asyncio。

从 Twisted 框架借鉴一些经验来理解 asynio 并非难事，但是，asyncio 包含众多的元素，我开始动摇，不知道如何将这些孤立的零碎拼图组合成一副完整的图画。我已没有足够的智力提出任何更好的建议，在这里，只想分享我的困惑，求大神指点。

原语

asyncio 通过 协程 coroutines 的帮助来实现异步 IO。最初它是通过 yield 和 yield from 表达式实现的一个库，因为 Python 语言本身演进的缘故，现在它已经变成一个更复杂的怪兽。所以，为了在同一个频道讨论下去，你需要了解如下一些术语：

• 事件循环
• 事件循环策略
• awaitable
• 协程函数
• 老式协程函数
• 协程
• 协程封装
• 生成器 （ generator ）
• future
• 并发的future
• 任务 （ task ）
• 句柄
• 执行器 （ executor ）
• 传输 （ transport ）
• 协议

此外，Python 还新增了一些新的特殊方法：

• __aenter__ 和 __aenter__，用于异步块操作
• __aiter__ 和 __anext__，用于异步迭代器（异步循环和异步推导）。为了更强大些，协议已经改变过一次了。 在 Python 3.5 它返回一个 awaitable（这是个协程）；在 3.6它返回一个新的异步生成器。
• __await__，用于自定义的 awaitable

你还需要了解相当多的内容，文档涵盖了那些部分。尽管如此，我做了一些额外说明以便对其有更好的理解：

事件循环

asyncio 事件循环和你第一眼看上去的略有不同。表面看，每个线程都有一个事件循环，然而事实并非如此。我认为它们应该按照如下的方式工作：

• 如果是主线程，当调用 asyncio.get_event_loop() 时创建一个事件循环。
• 如果是其它线程，当调用 asyncio.get_event_loop() 时返回运行时错误。
• 当前线程可以使用 asyncio.set_event_loop() 在任何时间节点绑定事件循环。该事件循环可由 asyncio.new_evet_loop() 函数创建。
• 事件循环可以在不绑定到当前线程的情况下使用。
• asyncio.get_event_loop() 返回绑定线程的事件循环，而非当前运行的事件循环。

这些行为的组合是超混淆的，主要有以下几个原因。 首先，你需要知道这些函数被委托到全局设置的底层事件循环策略。 默认是将事件循环绑定到线程。 或者，如果需要的话，可以在理论上将事件循环绑定到一个 greenlet 或类似的。 然而，重要的是要知道库代码不控制策略，因此不能推断 asyncio 将适用于线程。

其次，asyncio 不需要通过策略将事件循环绑定到上下文。 事件循环可以单独工作。 但是这正是库代码的第一个问题，因为协同程序或类似的东西并不知道哪个事件循环负责调度它。 这意味着，如果从协程中调用 asyncio.get_event_loop()，你可能没有机会取得事件循环。 这也是所有 API 均采用可选的显式事件循环参数的原因。 举例来说，要弄清楚当前哪个协程正在运行，不能使用如下调用：

def get_task():
    loop = asyncio.get_event_loop()
    try:
        return asyncio.Task.get_current(loop)
    except RuntimeError:
        return None

相反，必须显式地传递事件循环。 这进一步要求你在库代码中显式地遍历事件循环，否则可能发生很奇怪的事情。 我不知道这种设计的思想是什么，但如果不解决这个问题（例如 get_event_loop() 返回实际运行的事件循环），那么唯一有意义的其它方案是明确禁止显式事件循环传递，并要求它绑定到当前上下文（线程等）。

由于事件循环策略不提供当前上下文的标识符，因此库也不可能以任何方式“索引”到当前上下文。 也没有回调函数用来监视这样的上下文的拆除，这进一步限制了实际可以开展的操作。

awaitable 与 协程 coroutine

以我的愚见，Python 最大的设计错误是过度重载迭代器。它们现在不仅用于迭代，而且用于各种类型的协程。 Python 中迭代器最大的设计错误之一是如果 StopIteration 没有被捕获形成的空泡。 这可能导致非常令人沮丧的问题，其中某处的异常可能导致其它地方的生成器或协同程序中止。 这是一个长期存在的问题，基于 Python 的模板引擎如 Jinja 经常面临这种问题。 该模板引擎在内部渲染为生成器，并且当由于某种原因的模板引起 StopIteration 时，渲染就停止在那里。

Python 慢慢认识到了过度重载的教训。 首先在 3.x 版本加入 asyncio 模块，并没有语言级支持。 所以自始至终它不过仅仅是装饰器和生成器而已。 为了实现 yield from 以及其它东西，StopIteration 再次重载。 这导致了令人困惑的行为，像这样：

>>> def foo(n):
...  if n in (0, 1):
...   return [1]
...  for item in range(n):
...   yield item * 2
...
>>> list(foo(0))
[]
>>> list(foo(1))
[]
>>> list(foo(2))
[0, 2]

没有错误，没有警告。只是不是你所期望的行为。 这是因为从一个作为生成器的函数中 return 的值实际上引发了一个带有单个参数的 StopIteration，它不是由迭代器协议捕获的，而只是在协程代码中处理。

在 3.5 和 3.6 有很多改变，因为现在除了生成器我们还有协程对象。除了通过封装生成器来生成协程，没有其它可以直接生成协程的单独对象。它是通过用给函数加 async 前缀来实现。 例如 async def x() 会产生这样的协程。 现在在 3.6，将有单独的异步生成器，它通过触发 AsyncStopIteration 保持其独立性。 此外，对于Python 3.5 和更高版本，导入新的 future 对象（generator_stop），如果代码在迭代步骤中触发 StopIteration，它将引发 RuntimeError。

为什么我提到这一切？ 因为老的实现方式并未真的消失。 生成器仍然具有 send 和 throw 方法以及协程仍然在很大程度上表现为生成器。你需要知道这些东西，它们将在未来伴随你相当长的时间。

为了统一很多这样的重复，现在我们在 Python 中有更多的概念了：

• awaitable：具有__await__方法的对象。 由本地协同程序和旧式协同程序以及一些其它程序实现。
• 协程函数 （ coroutinefunction ） ：返回原生协程的函数。 不要与返回协程的函数混淆。
• 协程 （ coroutine ） : 原生的协程程序。 注意，目前为止，当前文档不认为老式 asyncio 协程是协程程序。 至少 inspect.iscoroutine 不认为它是协程。 尽管它被 future/awaitable 分支接纳。

特别令人困惑的是 asyncio.iscoroutinefunction 和inspect.iscoroutinefunction 正在做不同的事情，这与 inspect.iscoroutine 和 inspect.iscoroutinefunction 情况相同。 值得注意的是，尽管 inspect 在类型检查中不知道有关 asycnio 旧式协程函数的任何信息，但是当您检查 awaitable 状态时它显然知道它们，即使它与 **await** 不一致。

协程封装器 coroutine wrapper

每当你运行 async def ，Python 就会调用一个线程局部的协程封装器。它由 sys.set_coroutine_wrapper 设置，并且它是可以包装这些东西的一个函数。 看起来有点像如下代码：

>>> import sys
>>> sys.set_coroutine_wrapper(lambda x: 42)
>>> async def foo():
...  pass
...
>>> foo()
__main__:1: RuntimeWarning: coroutine 'foo' was never awaited
42

在这种情况下，我从来没有实际调用原始的函数，只是给你一个提示，说明这个函数可以做什么。 目前我只能说它总是线程局部有效，所以，如果替换事件循环策略，你需要搞清楚如何让协程封装器在相同的上下文同步更新。创建的新线程不会从父线程继承那些标识。

这不要与 asyncio 协程封装代码混淆。

awaitable 和 future

有些东西是 awaitable 的。 据我所见，以下概念被认为是 awaitable：

• 原生的协程
• 配置了假的 CO_ITERABLE_COROUTINE 标识的生成器（文中有涉及）
• 具有 __await__ 方法的对象

除了生成器由于历史遗留的原因不使用之外，其它的对象都使用 __await__ 方法。 CO_ITERABLE_COROUTINE 标志来自哪里？它来自一个协程封装器（现在与 sys.set_coroutine_wrapper 有些混淆），即 @asyncio.coroutine。 通过一些间接方法，它使用 types.coroutine（现在与 types.CoroutineType 或 asyncio.coroutine 有些混淆）封装生成器，并通过另外一个标志 CO_ITERABLE_COROUTINE 重新创建内部代码对象。

所以既然我们知道这些东西是什么，那么什么是 future？ 首先，我们需要澄清一件事情：在 Python 3 中，实际上有两种（完全不兼容）的 future 类型：asyncio.futures.Future 和 concurrent.futures.Future。 其中一个出现在另一个之前，但它们都仍然在 asyncio 中使用。 例如，asyncio.run_coroutine_threadsafe() 将调度一个协程到在另一个线程中运行的事件循环，但它返回一个 concurrent.futures.Future 对象，而不是 asyncio.futures.Future 对象。 这是有道理的，因为只有 concurrent.futures.Future 对象是线程安全的。

所以现在我们知道有两个不兼容的 future，我们应该澄清哪个 future 在 asyncio 中。 老实说，我不完全确定差异在哪里，但我打算暂时称之为“最终”。它是一个最终将持有一个值的对象，当还在计算时你可以对最终结果做一些处理。 future 对象的一些变种称为 deferred，还有一些叫做 promise。 我实在难以理解它们真正的区别。

你能用一个 future 对象做什么？ 你可以关联一个准备就绪时将被调用的回调函数，或者你可以关联一个 future 失败时将被触发的回调函数。 此外，你可以 await 它（它实现__await__，因此可等待），此外，future 也可以取消。

那么你怎样才能得到这样的 future 对象？ 通过在 awaitable 对象上调用 asyncio.ensure_future。它会把一个旧版的生成器转变为 future 对象。 然而，如果你阅读文档，你会读到 asyncio.ensure_future 实际上返回一个task（任务）。 那么问题来了，什么是任务？

任务

任务 （ task ） 某种意义上是一个封装了协程的 futur 对象。它的工作方式和 future 类似，但它也有一些额外的方法来提取所包含的协程的当前堆栈。 我们已经见过了在前面提到过的任务，因为它是通过 Task.get_current 确定事件循环当前正在做什么的主要方式。

在如何取消工作方面，任务和 future 也有区别，但这超出了本文的范围。“取消”是它们自己最大的问题。 如果你处于一个协程中，并且知道自己正在运行，你可以通过前面提到的 Task.get_current 获取自己的任务，但这需要你知道自己被派遣在哪个事件循环，该事件循环可能是、也可能不是已绑定的那个线程。

协程不可能知道它与哪个循环一起使用。task 也没有提供该信息的公共 API。 然而，如果你确实可以获得一个任务，你可以访问 task._loop，通过它反指到事件循环。

句柄

除了上面提到的所有一切还有句柄。 句柄是等待执行的不透明对象，不可等待，但可以被取消。 特别是如果你使用 call_soon 或者 call_soon_threadsafe（还有其它一些）调度执行一个调用，你可以获得句柄，然后使用它尽力尝试取消执行，但不能等待实际调用生效。

执行器 Executor

因为你可以有多个事件循环，但这并不意味着每个线程理所当然地应用多个事件循环，最常见的情形还是一个线程一个事件循环。 那么你如何通知另一个事件循环做一些工作？ 你不能到另一个线程的事件循环中执行回调函数并获取结果。 这种情况下，你需要使用执行器。

执行器 Executor 来自 concurrent.futures，它允许你将工作安排到本身未发生事件的线程中。 例如，如果在事件循环中使用 run_in_executor 来调度将在另一个线程中调用的函数。 其返回结果是 asyncio 协程，而不是像 run_coroutine_threadsafe 这样的并发协程。 我还没有足够的心智来弄清楚为什么设计这样的 API，应该如何使用，以及什么时候使用。 文档中建议执行器可以用于构建多进程。

传输和协议

我总是认为传输与协议也凌乱不堪，实际这部分内容基本上是对 Twisted 的逐字拷贝。详情毋庸赘述，请直接阅读相关文档。

如何使用 asyncio

现在我们已经大致了解 asyncio，我发现了一些模式，人们似乎在写 asyncio 代码时使用：

• 将事件循环传递给所有协程。 这似乎是社区中一部分人的做法。 把事件循环信息提供给协程为协程获取自己运行的任务提供了可能性。
• 或者你要求事件循环绑定到线程，这也能达到同样的目的。 理想情况下两者都支持。 可悲的是，社区已经分化。
• 如果想使用上下文数据（如线程本地数据），你可谓是运气不佳。 最流行的变通方法显然是 atlassian 的 aiolocals，它基本上需要你手动传递上下文信息到协程，因为解释器不为此提供支持。 这意味着如果你用一个工具类库生成协程，你将失去上下文。
• 忽略 Python 中的旧式协程。 只使用 3.5 版本中 async def 关键字和协程。 你总可能要用到它们，因为在老版本中，没有异步上下文管理器，这是非常必要的资源管理。
• 学习重新启动事件循环进行善后清理。 这部分功能和我预想的不同，我花了比较长的时间来厘清它的实现。清理操作的最好方式是不断重启事件循环直到没有等待事件。 遗憾的是没有什么通用的模式来处理清理操作，你只能用一些丑陋的临时方案糊口度日。 例如 aiohttp 的 web 支持也做这个模式，所以如果你想要结合两个清理逻辑，你可能需要重新实现它提供的工具助手，因为该助手功能实现后，它彻底破坏了事件循环的设计。 当然，它不是我见过的第一个干这种坏事的库 :(。
• 使用子进程是不明显的。 你需要一个事件循环在主线程中运行，我想它是在监听信号事件，然后分派到其它事件循环。 这需要通过 asyncio.get_child_watcher().attach_loop(...) 通知循环。
• 编写同时支持异步和同步的代码在某种程度上注定要失败。 尝试在同一个对象上支持 with 和 async with 是危险的事情。
• 如果你想给一个协程起个更好的名字，弄清楚为什么它没有被等待，设置 __name__没有帮助。 你需要设置 __qualname__ 而不是打印出错误消息来。
• 有时内部类型交换会使你麻痹。 特别是 asyncio.wait() 函数将确保所有的事情都是 future，这意味着如果你传递协程，你将很难发现你的协程是否已经完成或者正在等待，因为输入对象不再匹配输出对象。 在这种情况下，唯一真正理智的做法是确保前期一切都是 future。

上下文数据

除了疯狂的复杂性和对如何更好地编写 API 缺乏理解，我最大的问题是完全缺乏对上下文本地数据的考虑。这是 Node 社区现在学习的东西。continuation-local-storage 存在，但该实现被接受的太晚。持续本地存储和类似的概念常用于在并发环境中实施安全策略，并且该信息的损坏可能导致严重的安全问题。

事实上，Python 甚至没有任何存储，这令人失望至极。我正在研究这个内容，因为我正在调查如何最好地支持 Sentry's breadcrumbs 的 asyncio，然而我并没有看到一个合理的方式做到这一点。在 asyncio 中没有上下文的概念，没有办法从通用代码中找出您正在使用的事件循环，并且如果没有 monkeypatching（运行环境下的补丁），也无法获取这些信息。

Node 当前正在经历如何找到这个问题的长期解决方案的过程。这个问题不容忽视，因为它在所有生态系统中反复出现过，如 JavaScript、Python 和 .NET 环境。该问题被命名为异步上下文传播，其解决方案有许多名称。在 Go 中，需要使用上下文包，并明确地传递给所有 goroutine（不是一个完美的解决方案，但至少有一个）。.NET 具有本地调用上下文形式的最佳解决方案。它可以是线程上下文，Web 请求上下文或类似的东西，除非被抑制，否则它会自动传播。微软的解决方案是我们的黄金标准。我现在相信，微软在 15 年前已经解决了该问题。

我不知道该生态系统是否还够年轻，还可以添加逻辑调用上下文，可能现在仍然为时未晚。

个人感想

复杂的东西变得越来越复杂。 我没有随意使用 asyncio 的心智。它需要不断地更新所有 Python 语言的变化的知识，这很大程度上使语言本身变得复杂。 令人鼓舞的是，围绕着它的生态系统正在不断发展，只是不知道还需要几年的时间，才能带给开发者愉快和稳定的开发体验。

3.5 版本引入的东西（新的协程对象）非常棒。 特别是这些变化包括引入了一个合理的基础，这些都是我在早期的版本中一直期盼的。在我心中， 通过重载生成器实现协程是一个错误。 关于什么是 asyncio，我难以置喙。 这是一个非常复杂的事情，内部令人眼花缭乱。 我很难理解它工作的所有细节。你什么时候可以传递一个生成器，什么时候它必须是一个真正的协程，future 是什么，任务是什么，事件循环如何工作，这甚至还没有触碰到真正的 IO 部分。

最糟糕的是，asyncio 甚至不是特别快。 David Beazley 演示的它设计的 asyncio 的替代品是原生版本速度的两倍。 asyncio 巨复杂，很难理解，也无法兑现自己在主要特性上的承诺，对于它，我只想说我想静静。我知道，至少我对 asyncio 理解的不够透彻，没有足够的信心对人们如何用它构建代码给出建议。

作者：

Armin Ronacher

软件开发者和开源骨灰， Flask 框架的创造者。

via: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/

作者：Armin Ronacher 译者：firstadream 校对：jasminepeng

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

摘要：Linux 的必备软件有哪些？这将会是一个非常主观的回答，主要取决于你出于什么目的才使用桌面版 Linux。不过有一些必备的 Linux 桌面应用是大部分 Linux 用户都可能会用到的，这里将会列出不管在哪个发行版中你都应该安装的 Linux 桌面应用。

在 Linux 中，所有的一切都有多种可选方案的。首先，你会选择一个发行版，对吧？你可能需要尝试过多个发行版才能选出自己喜欢的风味。你是否还试过很多个音乐播放器？它们还是有很多选择的吧？

但并不是所有的这些应用都一样——有些以简洁为目标，而另一些则可能会提供大量的特性。根据自身的需求选择一款正确的应用也是一件相当困惑和累人的任务。就让我们来使这个过程变得容易一些吧。

Linux 用户最好的自由软件

在这里，我把自己喜欢用的 Linux 必备软件以几个类型列出来。当然不能说这些是最好的，但在我尝试了大量的各类软件之后，最后才得到这个分类列表。所以，非常欢迎你在评论区畅言自己最喜欢的应用。

Web浏览器

Web 浏览器

Google Chrome

Google Chrome 是一个功能完备、性能强悍的 web 浏览器。它具备了非常彪悍的同步功能，同时还提供大量的功能扩展插件。如果那你习惯于 Google 的软件生态，那么 Chrome 绝对是你的不二选择。当然，假如你想要一个开源的解决方案，那么你可以试试 Chromium，Google Chrome 就是基于 Chromium 构建的。

Firefox

如果你并非 Google Chrome 迷，那就试试 Firefox。它有着比较久的历史，也是一个稳定而健壮的 web 浏览器。

Vivaldi

如果说你想尝试新鲜事物并做一些改变，那么，你可以试试 Vivaldi，它为 web 浏览器带来了全新的使用方式，由前 Opera 项目成员基于 Chromium 项目开发。它开源、轻量级，同时不失定制性。尽管它还很年轻，缺少一些特性，但真的让人感觉清爽，可以完成你绝大多数的工作。

推荐阅读：Otter 浏览器给 Opera 粉丝带来希望

下载管理器

下载管理器

Uget

Uget 是我见过最好的下载管理器了。其源码是开放的，同时提供给你在下载浏览器中所想到的一切功能。其中，高级设置选项可以用来更好的管理下载。它支持排队下载和断点下载、支持多连接来下载大体积文件、支持通过不同分类来下载到不同目录等等。

Xdm

Xdm (Xtreme Download Manager，极限下载管理器) 是一款用 Java 开发的功能强大且开源的工具。有着所有下载管理器的必备功能，包括：视频捕获器、智能调度和浏览器集成。

推荐阅读：Linux 下 4 个最佳下载管理器

BitTorrent 客户端

BitTorrent 客户端

Deluge

Deluge 是一个开源的 BitTorrent 客户端，有着漂亮的用户界面。假如你习惯使用 Windows 下的 uTorrent，你就会知道两者有着很多的相似之处。它有大量的配置选项和插件来帮你应付各种下载任务。

Transmission

Transmission 是最轻量级的 Bittorrent 客户端——开源、有着最轻量级的用户界面。在多数的 Linux 发行版中都预装了 Transmission。

推荐阅读：Ubuntu 下五个最好的 BT 客户端

云存储

云存储

Dropbox

Dropbox 是目前最流行云存储服务之一。你注册之后就有 2 GB 的免费空间。Dropbox 提供了一个健壮而简洁的 Linux 客户端。

Mega

Mega 提供了 50 GB 的免费空间，但其最好的一点却非免费空间之大，而是它为你的文件传输提供了点对点加密。它在 Linux 平台上也有一个可靠的客户端，名为 MEGAsync。

推荐阅读：Linux 下最佳免费云服务

即时消息软件

即时消息软件

Pidgin

Pidgin 是一个开源的即时消息客户端，支持多个聊天平台，包括 Facebook、Google Talk、Yahoo，甚至是 IRC。它还可以通过第三方插件来进行扩展，这样可以把很多功能集成到 Pidgin 中去。

Skype

我想，应该所有人都知道 Skype 吧，它是目前最流行的视频聊天平台。近期，它又为 Linux 平台发布了一个全新的桌面客户端。

推荐阅读：Linux 上的最佳消息应用

办公套件

办公套件

LibreOffice

LibreOffice 是 Linux 平台下开发活跃度最高的开源办公套件。它有六大核心模块：Writer (文字处理)、Calc (电子表格)、Impress (文稿演示)、Draw (图像绘制)、Math (数学公式)、Base (数据库)，并且，这些模块都支持多种文件格式。当然，LibreOffice 也是支持第三方扩展的，多数的 Linux 发行版都用它作为默认的办公套件。

WPS Office

如果想要尝试 LibreOffice 之外的办公套件，WPS Office 当然是不容错过的，它支持 Writer (文字处理)、presentation (文稿演示)、spreadsheets (电子表格)。

推荐阅读：微软 Office 办公套件的最佳开源替代品

音乐播放器

音乐播放器

Lollypop

这是一个相对较新的音乐播放器。Lollypop 是开源的，有着非常漂亮的用户界面，提供了非常友好的歌曲管理、播放历史支持、在线电台和派对模式。尽管这是一个很简单的音乐播放器，没有太多的高级特性，但还是值得一试的。

RhythmBox

Rhythmbox 最初是为 Gnome 开发的音乐播放器，但现在已经可以很好的在其他的桌面环境中工作。它可以完成音乐播放器的所有基本任务，包括 CD 转录 & 刻录、播放历史等，而且还支持 iPod。

CMUS

假如你是极简主义派，并深爱着终端界面，那么 cmus 很合适你。就个人而言，我很喜欢并一直在用这个软件。它是类 Unix 平台下一个相当小巧、响应速度快、有着功能强大的控制台音乐播放器，具备了音乐播放器所有基本特性。通过其它的扩展和脚本，你可以使它功能更加丰富。

推荐阅读：在 Ubuntu 14.04 和 Linux Mint 17 安装 Tomahawk 播放器

视频播放器

视频播放器

VLC

VLC 是一个开源的媒体播放器，具有简洁、速度快、轻量级而功能强大等特点。它做到了真正的开箱即用，几乎支持所有你想到的视频格式，而且可以播放在线流媒体。当然，它支持一些非常棒的插件来完成不同的任务，比方说在播放视频时下载对应的字幕。

Kodi

Kodi 是一个功能完备的媒体播放器，开源并流行于其用户群体中。它可以处理本地或者网络存储中的视频、音乐、图片、播客甚至是游戏，你还有使用它来录制 TV。Kodi 可以通过附件和不同的皮肤来自定义。

推荐阅读：Linux 上的 4 种格式转换器

图像编辑器

图像编辑器

GIMP

GIMP 是 Linux 平台下 Photoshop 的替代方案。它是开源的，是一个全功能、专业的图像编辑软件，打包了非常多的工具用来处理各类图像。在此基础上，还有大量的定制选项以及第三方插件可以用于增强用户的使用体验。

Krita

Krita 主要是一个绘图工具，但也可以用来编辑图像。它同样也是开源的，也打包了很多精致且高级的工具。

推荐阅读：Linux 上最佳图像应用

文本编辑器

每个 Linux 发行版都会自带一个文本编辑器。通常，它的功能相对来说比较简单，没有太多的功能，但还是有一些具有增强功能的编辑器。

文本编辑器

Atom

Atom 是一个现代的可魔改的文本编辑器，由 GitHub 进行维护更新。它是完全开源的，为你的文本编辑任务提供了你所想到一切可能性。它做到了真正的开箱即用，你也可以进行自定义，让它变成你所需要的样子。同时，你可以从社区中获取有关它的大量扩展和主题。

Sublime Text

Sublime Text 是主流的文本编辑器之一。尽管它并不免费，但它允许你把软件作为评估使用，而且没有时间限制。Sublime Text 是一个功能丰富和复杂的软件。当然，它还有插件和主题支持。

推荐阅读：Linux 上四个最佳的现代开源代码编辑器

启动器 （ Launcher ）

启动器 (Launcher)

Albert

Albert 的灵感来至于 Alfred (Mac 中的一个高效应用，可以做到一切信手拈来)，但仍在开发中。Albert 反应很快，可扩展、可定制。其目标就是“ 不用思考就使用一切可用资源 （ Access everything with virtually zero effort ） ”。它可以很好的集成到你的 Linux 发行版中，并让你保持高效。

Synapse

Synapse 已有一些历史，是一个简洁的启动器，可以用来搜索和运行应用。它还可以加速各种各样的工作流，比如控制音乐、搜索文件、目录以及书签、运行命令等等。

正如 Abhishek 所说，我们会一直为读者 (比如，你) 更新这个 Linux 必备软件列表。那么，你最喜欢的 Linux 必备软件是什么呢？随时和我们分享，并想我们这个列表提出更多的软件分类。

via: https://itsfoss.com/essential-linux-applications

作者：Munif Tanjim 译者：GHLandy 校对：wxy

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