2016年9月

Turtl 是一个安全、开源的 Evernote 替代品，在Linux、Windows、Mac 和 Android 等系统上都能使用。iOS版本仍在开发当中，Firefox 和 Chrome 也有扩展程序可以使用。

这个产品仍在测试阶段，它能够让你把你的笔记（便签编辑器支持 Markdown）、网站书签、密码、文档、图片等单独放在一个隐秘地方。

笔记可以按模块组织起来，支持嵌套，也可以和其他 Turtl 用户分享。

你可以给你的笔记打上标签。Turtl 通过创建时间、最后修改时间或者标签来找你的笔记。

这个是便签编辑器（文件便签）：

那么安全性如何呢？Turtl 会在保存数据之前加密，使用的是一个加密密钥，而密码并不保存在服务器上。只有你和你想要分享的人能获取数据。你可以从这里获得更多关于 Turtl 安全和加密的信息。

更新（感谢 Dimitry！）：根据错误反馈，Turtl 有个严重的安全性问题。Turtl 允许创建多个相同用户名的账号，却只使用密码来区分它们。希望能马上修复这个问题。

Turtl 团队提供了一个托管服务来同步你的记录，它是完全免费的，”除非你的文件足够大，或者你需要更好的服务”，在我写这篇文章的时候这个高级服务还不能用。

并且你也不一定要用这个托管服务，因为就像其桌面应用和手机应用一样，这个自托管服务器也是一个自由、开源的软件，所以你可以自己搭建一个 Turtl 服务器。

Turtl 没有像 Evernote 那么多的功能，但它在它的计划中也有一些新的功能，比如：支持导入/导出文本和Evernote 格式的数据、原生支持 PDF 阅读器、界面锁定等。

不得不提醒的是，每次启动都要输入密码，虽然安全，但有时候实在是麻烦。

下载 Turtl

下载 Turtl 应用（二进制文件支持 Linux （32位/64位）、Windows 64 位、Mac 64位、Android，以及 Chrome 和Firefox 浏览器插件）

更新：Turtl 用了一个新的服务器，注销然后在登录框的下面选择高级设置，把 Turtl 服务器设置为 "https://api.turtlapp.com/v2"（没有引号）。

下载源代码（桌面应用、移动应用和服务器）、反馈问题等，参见 Turtl 的 GitHub 项目站点。

Arch Linux 用户可以通过 AUR 来安装 Turtl。

要在 Linux 上安装，把安装包解压后运行 install.sh，安装之前请确保 ~/.local/share/applications 目录存在，若不存在请自行创建：

mkdir -p ~/.local/share/applications

注意：如果使用 sudo 命令安装，那么只有 root 用户才能使用。所以，要么不用 sudo 命令安装，要么在安装完成后修改权限。你可以参考AUR 软件包的设置来了解如何修改权限。

使用如下命令把 Turtl 安装到 ~/turtl 文件夹下（假定你已经把安装包解压在你的家目录下了）：

~/turtl-*/install.sh ~/turtl

可以使用 ~/.turtl 代替 ~/turtl 把 Turtl 安装到你的家目录的隐藏文件夹下。你也可以用些小技巧把它隐藏起来。

如果 Turtl 没有在你的 Unity Dash 上显示出来，请注销/登录以重启会话。

via: http://www.webupd8.org/2016/08/turtl-secure-open-source-evernote.html

作者：Andrew 译者：chisper 校对：wxy

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

你可能比较熟悉如何用 Github Pages 来分享你的工作，又或许你看过一堂教你建立你的第一个 Github Pages 网站的教程。近期 Github Pages 的改进使得从不同的数据源来发布您的网站更加的方便，其中的来源之一就是你的仓库的 /docs 目录。

文档的质量是一个软件项目健康发展的标志。对于开源项目来说，维护一个可靠而不出错的知识库、详细说明所有的细节是至关重要的。精心策划的文档可以让增加项目的亲切感，提供一步步的指导并促进各种方式的合作可以推动开源软件开发的协作进程。

在 Web 上托管你的文档是一个消耗时间的挑战，而且对于它的发布和维护也没有省事的办法，然而这是并非不可避免的。面对多种不同的发布工具，又是 FTP 服务器，又是数据库，文件以各种不同的方式存放在不同的位置下，而这些都需要你手动来调整。需要说明的是，传统的 Web 发布方式提供了无与伦比的灵活性和性能，但是在许多情况下，这是以牺牲简单易用为代价的。

当作为文档使用时，麻烦更少的方式显然更容易去维护。

GitHub Pages 可以以指定的方式为你的项目创建网站，这使得它天然地适合发布和维护文档。因为 Github Pages 支持 Jekyll，所以你可以使用纯文本或 Markdown 来书写你的文档，从而降低你维护的成本、减少维护时的障碍。Jekyll 还支持许多有用的工具比如变量、模板、以及自动代码高亮等等，它会给你更多的灵活性而不会增加复杂性，这些你在一些笨重的平台是见不到的。

最重要的是，在 Github 上使用 GitHub Pages 意味着你的文档和代码可以使用诸如 Issues 和 Pull Requests 来确保它得到应有的高水平维护，而且因为 GitHub Pages 允许您发布代码库主分支上的 /docs 目录，这样您就可以在同一分支同时维护你的代码库及其文档。

现在开始！

发布你的第一个文档页面只需要短短几分钟。

  1. 在你的仓库的主分支里创建一个 /docs/index.md 文件。
  2. 把你的内容以 Jekyll 格式添加进去，并提交你的修改。

  1. 查看你的仓库的设置分支然后选择主分支 /docs 目录，将其设置为 GitHub Pages 的源 ，点击保存，你就搞定了。

GitHub Pages 将会从你的 /docs 目录中读取内容，转换 index.md 为 HTML。然后把它发布到你的 GitHub Pages 的 URL 上。

这样将会创建并输出一个最基础的 HTML ，而且你可以使用 Jekyll 的自定义模板、CSS 和其他特性。如果想要看所有的可能，你可以看看 GitHub Pages Showcase。

via: https://github.com/blog/2233-publish-your-project-documentation-with-github-pages

作者：loranallensmith 译者：Bestony 校对：wxy

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

JavaScript 和其他编程语言有一个很大的不同，它不像单纯的一个语言，而像一个由众多方言组成大家族。

从 2009 年 CoffeeScript 出现开始，近几年出现了大量基于 JavaScript 语言，或者叫方言，例如 ES6、TypeScript、Elm 等等。它们都有自己的优势，且都可以被完美编译成标准 JavaScript。

所以，继上周的前端框架篇，今天带来 JavaScript 现状之方言篇，看一下大家对于 JavaScript 的方言是怎么选择的。

声明：下面的部分结论来自部分数据，这是在我想要展示完整数据时找到的最好的办法，这便于我分享我的一些想法。

注意：如果你还没有参与这个调查，现在就来参加吧，可以花十分钟完成调查然后再回来看这篇文章。

认知度

首先，我想看一下参与问卷调查的人是否知道下面六种语言：

  • 经典的 JavaScript: 97%
  • ES6: 98%
  • CoffeeScript: 99%
  • TypeScript: 98%
  • Elm: 66%
  • ClojureScript: 77%

你可能觉得 100% 的人都应该知道『经典的 JavaScript 』，我想是有人无法抵抗在一个 JavaScript 调查中投『我从来没有听说过 JavaScript 』这个选项的强大诱惑吧……

几乎所有人都知道 ES6、CoffeeScript 和 TypeScript 这三种语言，比较令我惊讶的是 TypeScript 竟然会稍微落后于 ES6 和 CoffeeScript。

另一方面，Elm 和 ClojureScript 得分就要低得多，当然这也有道理，因为它们跟自己的生态环境绑定的比较紧密，也很难在已有的 App 中进行使用。

兴趣度

接下来，让我们一起看一下，哪一种方言吸引新开发者的能力更强一些：

要注意，该表是统计该语言对从未使用过它们的用户的吸引度，因为只有很少人没有用过经典 JavaScript，所以『经典 JavaScript 』这一列的数值很低。

ES6的数值很有趣：已有很大比例的用户在使用 ES6 了，没有用过的人中的绝大部分（89%）也很想学习它。

TypeScript 和 Elm 的状态差不多：用过的人不多，但感兴趣的比例表现不错，分别是 53% 和 58%。

如果让我预测一下，那我觉得 TypeScript 和 Elm 都很难向普通的 JavaScript 开发者讲明自己的优势。毕竟如果开发者只懂 JavaScript 的话，你很难解释清楚静态类型的好处。

另外，只有很少开发者用过 CoffeeScript，而且很明显几乎没人想去学。我觉得我该写一本 12 卷厚的 CoffeeScript 百科全书了……

满意度

现在是最重要的问题的时间了：有多少开发者用过这些语言，有多少人还想继续使用这些方言呢？

虽然经典 JavaScript 拥有最多的用户量，但就满意度来说 ES6 才是大赢家，而且我想现在已经能安全的说，ES6 可以作为开发 JavaScript App 默认的语言。

TypeScript 和 Elm 有相似的高满意度，都在 85% 上下。然后，只有可怜的 17% 的开发者会考虑继续使用 CoffeeScript。

快乐度

最后一个问题，我问大家在用现在的方式写 JavaScript 时是否感到快乐：

这个问题的答案和上一个问题的满意度想匹配：平均分达到 3.96 分（1 - 5 分），大家在使用 JavaScript 时候确实是快乐的。

不过很难说高分是因为 JavaScript 最近的一些改进造成的呢，还是发现 JavaScript 可能（仅仅是可能）没有大家认为的那么讨厌。总之，JavaScript 令人满意。

总结

如果说上次的赢家是 React 和 Vue，那此次调查的冠军毫无争议是 ES6 了。 ES6 并带来没有开天辟地的变化，但整个社区都还是很认可当前 JavaScript 演进方向的。

我觉得一年之后我们再来一次这样的调查，结果会很有趣。同时也可以关注一下 TypeScript、Elm 还有ClojureScript 有没有继续进步。

个人认为，当前 JavaScript 大家庭百花齐放的现象还只是一个开始，或许几年之后 JavaScript 就会变得非常不同了。

结语 & 敬请期待

对于我这样的调查来说数据越多就意味着数据越准确！越多人参加这个调查，那就越能代表整个 JavaScript 社区。

所以，我十分希望你能帮忙分享这个调查问卷：

另外，如果你想收到我下一个调查结果分析，前往 调查问卷主页 并留下自己的邮箱吧。

via: https://medium.com/@sachagreif/the-state-of-javascript-javascript-flavors-1e02b0bfefb6

作者：Sacha Greif 译者：eriwoon 校对：wxy

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

汽车可不单单是由引擎和华丽外壳组成的，汽车里还有许许多多的计算部件，而 Linux 就在它们里面跑着。

Linux 不只运行在你的服务器和手机（安卓）上。它还运行在你的车里。当然了，没人会因为某个车载系统而去买辆车。但是 Linux 已经为像丰田、日产、捷豹路虎这些大型汽车制造商提供了信息娱乐系统、平视显示以及其 联网汽车 （ connected car ） 的 4G 与 Wi-Fi 系统，而且 Linux 即将登陆福特汽车、马自达、三菱、斯巴鲁。

如今，所有的 Linux 和开源汽车软件的成果都已经在 Linux 基金会的 Automotive Grade Linux （AGL）项目下统一标准化了。

传统软件公司也进入了移动物联网领域。 Movimento、甲骨文、高通、Texas Instruments、UIEvolution 和 VeriSilicon 都已经加入 Automotive Grade Linux（AGL）项目。 AGL 是一个相互协作的开源项目，志在于为联网汽车打造一个基于 Linux 的通用软件栈。

“随着联网汽车技术和信息娱乐系统需求的快速增长，AGL 过去几年中得到了极大的发展，” Linux 基金会汽车总经理 Dan Cauchy 如是说。

Cauchy 又补充道，“我们的会员基础不单单只是迅速壮大，而且通过横跨不同的业界实现了多元化，从半导体和车载软件到 IoT 和连接云服务。这是一个明显的迹象，即联网汽车的革命已经间接影响到许多行业纵向市场。”

这些公司在 AGL 发布了新的 AGL Unified Code Base (UCB) 之后加入了 AGL 项目。这个新的 Linux 发行版基于 AGL 和另外两个汽车开源项目： Tizen 和 GENIVI Alliance 。 UCB 是第二代 Linux 汽车系统。它从底层开始开发，一直到特定的汽车应用软件。它能处理导航、通信、安全、安保和信息娱乐系统。

“汽车行业需要一个标准的开源系统和框架来让汽车制造商和供应商能够快速地将类似智能手机的功能带入到汽车中来。” Cauchy 说。“这个新的发行版将 AGL、Tizen、GENIVI 项目和相关开源代码中的精华部分整合进 AGL Unified Code Base （UCB）中，使得汽车制造商能够利用一个通用平台进行快速创新。 在汽车中采用基于 Linux 的系统来实现所有功能时， AGL 的 UCB 发行版将扮演一个重大的角色。”

他说得对。自从 2016 年 1 月发布以来，已有四个汽车公司和十个新的软件厂商加入了 AGL。Esso，如今的 Exxon， 曾让 “把老虎装入油箱” 这条广告语出了名。我怀疑 “把企鹅装到引擎盖下” 这样的广告语是否也会变得家喻户晓，但是它却道出了事实。 Linux 正在慢慢成为 21 世纪汽车的主要操作系统。

via: http://www.zdnet.com/article/the-linux-in-your-car-movement-gains-momentum/

作者：Steven J. Vaughan-Nichols 译者：XLCYun 校对：wxy

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

一个 Linux 新用户应该知道他或她的进步源自于对 Linux 发行版的使用，而 Linux 发行版有好几种，并以不同的方式管理软件包。

在 Linux 中，包管理器非常重要，知道如何使用多种包管理器可以让你像一个高手一样活得很舒适，从在仓库下载软件、安装软件，到更新软件、处理依赖和删除软件是非常重要的，这也是Linux 系统管理的一个重要部分。

最好的Linux包管理器

成为一个 Linux 高手的一个标志是了解主要的 Linux 发行版如何处理包，在这篇文章中，我们应该看一些你在 Linux 上能找到的最佳的包管理器，

在这里，我们的主要重点是关于一些最佳包管理器的相关信息，但不是如何使用它们，这些留给你亲自发现。但我会提供一些有意义的链接，使用指南或更多。

1. DPKG - Debian 包管理系统 （ Debian Package Management System ）

Dpkg 是 Debian Linux 家族的基础包管理系统，它用于安装、删除、存储和提供.deb包的信息。

这是一个低层面的工具，并且有多个前端工具可以帮助用户从远程的仓库获取包，或处理复杂的包关系的工具，包括如下：

APT ( 高级打包工具 （ Advanced Packaging Tool ） )

这个是一个 dpkg 包管理系统的前端工具，它是一个非常受欢迎的、自由而强大的，有用的命令行包管理器系统。

Debian 及其衍生版，例如 Ubuntu 和 Linux Mint 的用户应该非常熟悉这个包管理工具。

想要了解它是如何工作的，你可以去看看下面这些 HOW TO 指南：

Aptitude 包管理器

这个也是 Debian Linux 家族一个非常出名的命令行前端包管理工具，它工作方式类似 APT ，它们之间有很多可以比较的地方，不过，你应该两个都试试才知道哪个工作的更好。

它最初为 Debian 及其衍生版设计的，但是现在它的功能延伸到 RHEL 家族。你可以参考这个指南了解更多关于 APT 和 Aptitude。

Synaptic 包管理器

Synaptic是一个基于GTK+的APT的可视化包管理器，对于一些不想使用命令行的用户，它非常好用。

2. RPM - 红帽包管理器 （ Red Hat Package Manager ）

这个是红帽创建的 Linux 基本标准（LSB）打包格式和基础包管理系统。基于这个底层系统，有多个前端包管理工具可供你使用，但我们应该只看那些最好的，那就是：

YUM （ 黄狗更新器，修改版 （ Yellowdog Updater, Modified ） ）

这个是一个开源、流行的命令行包管理器，它是用户使用 RPM 的界面（之一）。你可以把它和 Debian Linux 系统中的 APT 进行对比，它和 APT 拥有相同的功能。你可以从这个 HOW TO 指南中的例子更加清晰的理解YUM：

DNF（ 优美的 Yum （ Dandified Yum ） ）

这个也是一个用于基于 RPM 的发行版的包管理器，Fedora 18 引入了它，它是下一代 YUM。

如果你用 Fedora 22 及更新版本，你肯定知道它是默认的包管理器。这里有一些链接，将为你提供更多关于 DNF 的信息和如何使用它。

3. Pacman 包管理器 – Arch Linux

这个是一个流行的、强大而易用的包管理器，它用于 Arch Linux 和其他的一些小众发行版。它提供了一些其他包管理器提供的基本功能，包括安装、自动解决依赖关系、升级、卸载和降级软件。

但是最大的用处是，它为 Arch 用户创建了一个简单易用的包管理方式。你可以阅读 Pacman 概览，它会解释上面提到的一些功能。

4. Zypper 包管理器 – openSUSE

这个是一个使用 libzypp 库制作的用于 OpenSUSE 系统上的命令行包管理器，它的常用功能包括访问仓库、安装包、解决依赖问题和其他功能。

更重要的是，它也可以支持存储库扩展功能，如模式、补丁和产品。新的 OpenSUSE 用户可以参考下面的链接来掌控它。

5. Portage 包管理器 – Gentoo

这个是 Gentoo 的包管理器，当下不怎么流行的一个发行版，但是这并不阻止它成为 Linux 下最好的软件包管理器之一。

Portage 项目的主要目标是创建一个简单、无故障的包管理系统，包含向后兼容、自动化等功能。

如果希望理解的更清晰，可以看下： Portage 项目页。

结束语

正如我在开始时提到的，这个指南的主要意图是给 Linux 用户提供一个最佳软件包管理器的列表，但知道如何使用它们可以通过其后提供的重要的链接，并实际去试试它们。

各个发行版的用户需要学习超出他们的发行版之外的一些东西，才能更好理解上述提到的这些不同的包管理器。

via: http://www.tecmint.com/linux-package-managers/

作者：Ravi Saive 译者：Bestony 校对：wxy

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

不知不觉，LCTT 已经成立三年了，对于我这样已经迈过四张的人来说，愈发的感觉时间过得真快。

这三年来，我们 LCTT 经历了很多事情，有些事情想起来仍恍如昨日。

三年前的这一天，我的一个偶发的想法促使我在 Linux 中国的 QQ 群里面发了一则消息，具体的消息内容已经不可考了，大意是鉴于英文 man 手册的中文翻译太差，想组织一些人来重新翻译。不料发出去之后很快赢得一些有热情、有理想的小伙伴们的响应。于是我匆匆建了一个群，拉了一些人进来，甚至当时连翻译组的名称都没有确定。LCTT （Linux.Cn Translation Team）这个名称都是后来逐步定下来的。

关于 LCTT 的早期发展情况，可以参考 LCTT 2014 年周年总结。

虽然说“翻译 man 手册”这个最初建群的目标因为种种原因搁浅而一直未能重启，但是，这三年来，我们组织了 213 位志愿者翻译了 2155 篇文章，接受了 4263 个 PR，得到了 476 个星。

这三年来，我们经历了 man 项目的流产、 LFS 手册的翻译发布、选题 DeadFire 的离去。得益于 Linux 中国的网站和微博，乃至微信的兴起后的传播，志愿者们的译文传播很广，切实的为国内的开源社区做出了贡献（当然，与此同时，Linux 中国社区也随之更加壮大）。

这些年间，LCTT 来了很多人，也有人慢慢淡出，这里面涌现了不少做出了卓越贡献的人，比如：

  • geekpi，作为整个 LCTT 项目中翻译量最大贡献者，却鲜少在群内说话，偶尔露面，被戏称为“鸡排兄”。
  • GOLinux，紧追“鸡排兄”的第二位强人，嗯，群内大部分人的昵称都是他起的，包括楼上。
  • tinyeyeser，“小眼儿”以翻译风趣幽默著称，是 LCTT 早期初创成员之一。
  • Vito-L，早期成员，LCTT 的多数 Wiki 出自于其手。
  • DeadFire，创始成员，从最开始到其离世，一直负责 LCTT 的所有选题工作。
  • oska874，在接过选题工作的重任后，全面主持 LCTT 的工作。
  • carolinewuyan，承担了相当多的校对工作。
  • alim0x，独立完成了 Android 编年史系列的翻译（多达 26 篇，现在还没发布完）等等。

其它还有 ictlyh、strugglingyouth、FSSlc、zpl1025、runningwater、bazz2、Vic020、dongfengweixiao、jasminepeng、willqian、vizv、ZTinoZ、martin2011qi、felixonmars、su-kaiyao、GHLandy、flsf、H-mudcup、StdioA、crowner、vim-kakali 等等，以及还有很多这里没有提到名字的人，都对 LCTT 做出不可磨灭的贡献。

具体的贡献排行榜，可以看这里。

每年写总结时，我都需要和 gource 以及 ffmpeg 搏斗半天，今年，我又用 gource 重新制作了一份 LCTT 的 GitHub 版本仓库的变迁视频，以飨众人。

本来想写很多，或许 LCTT 和 Linux 中国已经成了我的生活的一部分，竟然不知道该写点什么了，那就此搁笔罢。

另外，为 LCTT 的诸位兄弟姐妹们献上我及管理团队的祝福，也欢迎更多的志愿者加入 LCTT ，传送门在此：

  • 项目网站：https://lctt.github.io/ ，请先访问此处了解情况。
  • “Linux中国”开源社区：https://linux.cn/ ，所有翻译的文章都在这里以及它的同名微博、微信发布。

LCTT 组长 wxy

2016/9/10

  1. 1
  2. ...
  3. 6
  4. 7
  5. 8
  6. 9
  7. 10
  8. 11
  9. 12