编程现在已经变成最受欢迎的职业之一，不像以前，编制软件只局限于少数几种编程语言。现在，我们有很多种编程语言可以选择。随着跨平台支持的增多，大多数编程语言都可以被用于多种任务。如果，你还没有学会编程，让我们看一下在 2018 年你可能会学习的编程语言有哪些。

Python

毫无疑问， Python 现在已经统治着编程市场。它发起于 1991 年，自从 YouTube 开始使用它之后，Python 已经真正的成为著名编程语言。Python 可以被用于各类领域，比如，Web 开发、游戏开发、脚本、科学研究、以及大多数你能想到的领域。它是跨平台的，并且运行在一个解释程序中。Python 的语法非常简单，因为它使用缩进代替花括号来对代码块进行分组，因此，代码非常清晰。

示例：

print("Hello world!")

Kotlin

虽然 Java 自它诞生以来从没有被超越过，但是，至少在 Android 编程方面，Kotlin 在正打破这种局面。Kotlin 是较新的一个编程语言，它被 Google 官方支持用于 Android 应用编程。它是 Java 的替代者，并且可以与 java 代码无缝衔接。代码大幅减少并且更加清晰。因此，在 2018 年，Kotlin 将是最值的去学习的编程语言。

示例

class Greeter(val name: String) {
  fun greet() {
     println("Hello, $name")
  }
}

// String Interpolation to cut down ceremony.

fun main(args: Array) {
  Greeter(args[0]).greet()
}

C/C++

这可能是他们在中学和大学里教的第一个编程语言。C 是比较老的编程语言之一，由于它的代码运行速度快而且简单，它到现在仍然一直被使用。虽然它的学习难度比较大，但是，一旦你掌握了它，你就可以做任何语言能做的事情。你可能不会用它去做高级的网站或者软件，但是，C 是嵌入式设备的首选编程语言。随着物联网的普及，C 将被再次广泛的使用，对于 C++，它被广泛用于一些大型软件。

示例

#include <stdio.h>

Int main()
{
   printf("Hello world");
   return 0;
}

PHP

关于 PHP 即将消亡的话题，因特网上正在疯传，但是，我没有看到一个为什么不去学习 PHP 的理由，它是服务器端脚本语言中比较优秀的一个，它的语法结构非常简单。一半以上的因特网都运行在 PHP 上。Wordpress，这个最流行的内容管理系统是用 PHP 写的。因为，这个语言流行的时间已经超过 20 年了，它已经有了足够多的库。在这些库中，你总能找到一个是适合你的工作的。

示例

echo "Hello world!";

Javascript

关于 Javascript，我说些什么呢？这是目前最为需要的语言。Javascript 主要用于网站动态生成页面。但是，现在 JavaScript 已经演进到可以做更多的事情。整个前后端框架都可以用 JavaScript 构建。Hybrid 应用是用 HTML+JS 写的，它被用于构建任何移动端的平台。使用 Javascript 的 nodejs 甚至被用于服务器端的脚本。

示例

document.write("Hello world!");

SQL

SQL 是关系型数据库管理系统（RDBMS）的查询语言，它用于从数据库中获取数据。SQL 的主要实现或多或少都是非常相似的。数据库用途非常广泛。你读的这篇文章它就保存在我们网站的数据库中。因此，学会它是非常有用的。

示例

SELECT * FROM TABLENAME

结论

因为这些语言都是在 2018 年比较值得去学习的。我并没有包括像 asp.net 这样的 语言，因为，它要求你学习它们的整个平台。Java 也没有推荐，因为有大量的开发者已经开始迁到 Kotlin。所有提到的语言的市场需求都非常大，并且它们都很流行。它们也都有非常好的社区支持。我希望你喜欢这篇文章。如果你认为我遗漏了任何一个非常受人欢迎的语言，请在下面的评论区告诉我。

via: http://www.linuxandubuntu.com/home/best-programming-languages-to-learn-in-2018

作者：LinuxAndUbuntu 译者：qhwdw 校对：wxy

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

最近我不得不给我的手机下载更新包，但是当我开始下载的时候，我发现安装包过于庞大。大约有 1.5 GB。

考虑到这个下载速度至少需要花费 1 至 1.5 小时来下载，并且说实话我并没有这么多时间。现在我下载速度可能会很慢，但是我的 ISP 有 Google Peering （Google 对等操作）。这意味着我可以在所有的 Google 产品中获得一个惊人的速度，例如Google Drive, YouTube 和 PlayStore。

所以我找到一个网络服务叫做 savetodrive。这个网站可以从网页上直接保存文件到你的 Google Drive 文件夹之中。之后你就可以从你的 Google Drive 上面下载它，这样的下载速度会快很多。

现在让我们来看看如何操作。

第一步

获得文件的下载链接，将它复制到你的剪贴板。

第二步

前往链接 savetodrive 并且点击相应位置以验证身份。

这将会请求获得使用你 Google Drive 的权限，点击 “Allow”。

第三步

你将会再一次看到下面的页面，此时仅仅需要输入下载链接在链接框中，并且点击 “Upload”。

你将会开始看到上传进度条，可以看到上传速度达到了 48 Mbps，所以上传我这个 1.5 GB 的文件需要 30 至 35 秒。一旦这里完成了，进入你的 Google Drive 你就可以看到刚才上传的文件。

这里的文件中，文件名开头是 miui 的就是我刚才上传的，现在我可以用一个很快的速度下载下来。

可以看到我的下载速度大概是 5 Mbps ，所以我下载这个文件只需要 5 到 6 分钟。

所以就是这样的，我经常用这样的方法下载文件，最令人惊讶的是，这个服务是完全免费的。

via: http://www.theitstuff.com/save-files-directly-google-drive-download-10-times-faster

作者：Rishabh Kandari 译者：Drshu 校对：wxy

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

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
2. 对于 GNU 许可证的一般了解
3. 在您的程序中使用 GNU 许可证
4. 依据GNU许可证分发程序
5. 在编写其他程序时采用依据 GNU 许可证发布的程序
6. 将作品与依据 GNU 许可证发布的代码相结合
7. 关于违反 GNU 许可证的问题

4 依据GNU许可证分发程序

4.1 我可以仅用二进制形式发布一个遵循 GPL 的程序的修改版本吗？

不可以。GPL 的要旨是所有修改版本必须是自由软件——这意味着修改版本的源代码必须可供用户使用。

4.2 我从网上下载了二进制文件。如果我分发该副本，我必须也要获取源代码并分发？

是的。一般规则是，如果您分发二进制文件，则还必须分发完整的相应源代码。您收到索取源代码书面文件的例外情况非常有限。

4.3 我想通过物理媒体分发二进制文件，但不附带源代码。我可以通过 FTP 提供源代码吗？

GPL v3 允许这种行为；有关详细信息，请参阅条款 6（b）。依据 GPL v2，您可以径自通过 FTP 提供源代码，大多数用户将从那里获得。然而，如果他们中的任何人宁愿通过邮件获取以物理媒体承载的源代码，那么您需要为之提供。

如果您通过 FTP 分发二进制文件，则应通过 FTP 分发源代码。

4.4 我的朋友获取了一个遵循 GPL 的二进制文件和承诺提供源代码的书面文件，并为我提供了副本。我可以自己使用这个书面文件来获取源代码吗？

是的，你可以。该书面文件必须对拥有其所相伴的二进制文件的所有人开放。这就是为什么 GPL 说你的朋友必须给你一份这个书面文件的副本以及这个二进制文件的副本，所以你可以使用该书面文件索取源代码。

4.5 我可以将二进制文件放在我的互联网服务器上，并将源代码放在不同的网站上吗？

可以。第 6（d）条允许这样做。但是，您必须提供明确指示，以利于人们依次来获取源代码，并且必须注意，只要你的目标代码还在分发，就要确保源代码仍然可用。

4.6 我想以二进制形式分发一个遵循 GPL 的程序的扩展版本，是否分发原始版本的源代码就足够了？

不可以，您必须提供与二进制文件对应的源代码。对应的源代码意味着用户可以从中重建相同的二进制文件。

自由软件的一部分理念是用户应该可以访问他们使用的程序的源代码。使用您的版本的用户应该可以访问您的版本的源代码。

GPL 的一个主要目标是建立自由世界，确保对自由程序的改进本身是自由的。如果您发布一个改进版本的遵循 GPL 的程序，您必须依据 GPL 发布改进的源代码。

4.7 我想分发二进制文件，但不太方便分发完整的源代码。我是否可以向用户提供来自与该二进制文件对应的“标准”版本的diff？

这是一个很好的想法，但是这种提供源代码的方法并没有真正做到这一点。

一年之后想要获取源代码的用户可能无法从当时的其他站点获取正确的版本。标准分发站点可能有一个较新的版本，但相同的diff 可能无法与该版本一起使用。

所以你需要为二进制文件提供完整的源代码，而不仅仅是 diff。

4.8 我可以在网络服务器上发布二进制文件，但是仅向索取的用户发送源代码吗？

如果您在网络服务器上提供二进制对象代码，则必须在网络服务器上提供对应源代码。执行此操作的最简单方法是将它们发布在同一台服务器上，但如果需要，您可以提供从其它服务器甚至版本控制系统获取源代码的说明。不管你做什么，源代码都应该像目标代码一样容易访问。这些全部在 GPL v3 的第 6（d）节中进行了具体说明。

您提供的源代码必须完全对应于二进制文件。特别是，您必须确保它们是相同版本的程序——不是旧版本，也不是新版本。

4.9 如何确保每个下载二进制文件的用户都能获得源代码？

你不必确定这一点。只要您使源代码和二进制文件可用，以便用户可以看到可用的内容并获取所需的内容，那么您已经完成了所需的操作。是否下载源代码取决于用户。

我们对再分发者的要求旨在确保用户可以获得源代码，而不是强迫用户即使在不需要的情况下也要下载源代码。

4.10 GPL 要求我提供可以构建成与我正在分发的二进制文件的精确哈希值相匹配的二进制文件的源代码吗？

完全对应的源代码意味着二进制文件依赖该源代码生成，但这并不意味着您的工具必须能够创建一个与您正在分发的二进制文件的精确哈希值相同的二进制文件。在某些情况下，可能（几乎）不可能使用正在分发的二进制文件的精确哈希值从源代码构建二进制文件——考虑以下示例：系统可能会将时间戳放在二进制文件中；或者程序可能是针对不同的（甚至未发行的）编译器版本构建的。

4.11 我是否可以发布一个遵循某许可证的程序，该许可证表示您可以依据 GPL 分发修改后的版本，但是您不能分发遵循 GPL 的原始版本？

不可以，这样的许可证是自相矛盾的。我们来看看它对用户的影响。

假设我从原始版本（称为版本 A）开始，添加一些代码（让我们假设它是 1000 行），并依据 GPL 发布修改版本（称为 B 版本）。GPL 说任何人都可以再次更改 B 版本，并依据 GPL 发布修改结果。我（或其他人）可以删除那 1000 行代码，生成与版本 A 代码相同的但遵循 GPL 的 C 版本。

通过在许可证中明确表示我不允许删除版本 B 中的那些行，重制成与遵循 GPL 的 A 版本相同的东西，您可以尝试阻止该路径。但实际上许可证表示现在我不能完全以 GPL 允许的所有方式使用版本 B。换句话说，许可证实际上不允许用户发布诸如遵循 GPL 的 B 版本这样的修改版本。

4.12 我刚刚发现一家公司有一份 GPL 程序的副本，获取该副本需支付费用。他们会因为不能在互联网上提供副本而违反 GPL 吗？

不会，GPL 不要求任何人使用互联网进行分发。它也不要求任何人特意去再分发程序。而且（一个特殊情况之外），即使有人决定再分发该程序，GPL 也不会要求他必须特意向您或其他人分发副本。

GPL 要求的是，如果他愿意，他必须有权将副本分发给你。一旦版权所有者将程序的副本分发给某人，如果某人认为合适，那么该人可以将程序再分发给您或任何其他人。

4.13 一家公司正在网站上运行一个 GPL 程序的修改版本。GPL 规定他们是否必须发布修改后的源代码？

GPL 允许任何人进行修改并使用修改版本，而无需将其分发给他人。（这里所说的）这家公司的做法是一个特例。 因此，公司不必发布修改后的源代码。

人们必须能够自由地对程序进行修改并自用，而无需发布这些修改。然而，将程序放在服务器上以供公众访问很难说是“自用”，因此要求在这种特殊情况下发布源代码是合法的。希望解决这个问题的开发人员可以为其程序适用 GNU Affero GPL，该许可证专门为网络服务器使用场景而设计。

4.14 在一个组织或公司中制作和使用多个副本构成“分发”吗？

不构成，在这种情况下，组织只是为自己制作副本。因此，公司或其他组织可以开发修改后的版本，并通过自己的设施安装该版本，但不得允许员工向外发布该修改版本。

但是，当组织将副本转移给其他组织或个人时，即构成分发。特别是，向承包商提供副本以便在场外使用，构成了分发。

4.15 如果有人窃取包含 GPL 程序的 CD，GPL 是否授予小偷再分发该版本的权利？

如果该版本已经在其他地方被发布，那么依据 GPL，这个小偷可能确实有权利制作副本并将其再分发，但是如果小偷因为窃取 CD 而被监禁，那么他们可能必须等到释放才能这样做。

如果相关版本未被公开发布并被公司视为其商业秘密，则根据其他情况，发布该版本可能会违反商业秘密法。GPL 对此没有进行改变。如果公司试图发布其版本，并仍将其视为商业秘密，则会违反 GPL，但如果公司尚未发布此版本，则不会发生此类违规。

4.16 如果一家公司将副本作为商业秘密分发会构成违规吗？

如果该公司向您分发副本并声称是商业秘密，则该公司违反了 GPL，必须停止分发。请注意这与上述盗窃案有何不同；该公司没有故意在副本被盗后分发副本，所以在这种情况下，该公司没有违反 GPL。

4.17 我在使用 GPL 程序的源代码时是否具有 “合理使用” （ fair use ） 权限？

是的，您有。“合理使用”是在没有任何特别许可的情况下允许的使用。 由于您不需要开发人员的许可来进行这种使用，无论开发人员在许可证或其他地方对此怎么说，您都可以执行此操作，无论该许可证是 GNU GPL 还是其他自由软件许可证。

但是，请注意，没有全世界范围普适的合理使用原则；什么样的用途被认为“合理”因国而异。

4.18 将副本移至控股的附属公司会构成分发吗？

副本移至/移自附属公司是否构成“分发”需要根据恰当管辖区的版权法依据个案确定。GPL 没有也不能逾越当地法律。美国版权法关于这一点的规定并不完全清楚，但似乎并不将此视为分发。

如果在某些国家，这被视为分发，而附属公司必须得到再分发程序的权利，这不会有实际的区别。附属公司由母公司控制；无论有没有权利，除非母公司决定这样做，否则附属公司不会再分发该程序。

4.19 软件安装程序可以要求用户通过点击来同意 GPL 协议吗？如果我获得一些遵循 GPL 的软件，我必须同意什么吗？

一些软件安装系统有一个地方要求您点击或以其他方式表示同意 GPL 的条款。这不是必须的，也不是禁止的。无论是否点击， GPL 的规则保持不变。

只是同意 GPL 不要求您承担任何义务。仅使用依据 GPL 进行许可的软件，您不需要同意任何事项。只有您修改或分发软件时，您才有义务。如果点击同意 GPL 真的打扰了你，没有任何东西能阻止你修改该 GPL 软件把这个步骤删除掉。

4.20 我想将 GPL 软件与某种安装软件捆绑在一起。该安装程序是否需要具有与 GPL 兼容的许可证？

不需要。安装程序及其安装的文件是单独的作品。因此，GPL 的条款不适用于安装软件。

4.21 GPL 软件的一些分发者要求将我囊括在其伞式的最终用户许可协议（EULA）中或作为下载过程的一部分，以“代表和保证”我位于美国，或者我打算依据相关出口管制法律分发软件。为什么他们这样做，是否违反了分发者在 GPL 下的义务？

这不违反 GPL。那些分发者（几乎都是销售自由软件分发版本和相关服务的商业企业）正在努力降低自己的法律风险，而不是控制您的行为。如果分发者故意将软件出口到某些国家或将软件提供给可能会进行这种出口行为的第三方，美国的出口管制法可能会要求分发者承担责任。分发者通过向客户和被分发软件的其他人要求做出这些声明，一旦被监管机构问及他们是否知道其分发的软件流至何方，分发者可以借此保护自己。分发者并不限制您可以用软件做什么，只是避免他们对您所做的任何事情负责。因为分发者没有对软件施加额外的限制，所以他们不违反 GPL v3 的第 10 节或 GPL v2 的第 6 节。

自由软件基金会（FSF）反对将美国出口管制法律适用于自由软件。这些法律不仅与软件自由的总体目标不符，而且达不到合理的政府目的，因为目前几乎每个国家都可以使用自由软件并且应该一直都能使用，包括没有出口管制法律的国家以及参与美国领导的贸易禁运的国家。所以没有一个国家的政府实际上被美国的出口管制法律剥夺了使用自由软件的权利，就我们而言，不管其政府的政策如何，每个国家的公民都不应该被剥夺使用自由软件的权利。自由软件基金会发布的所有 GPL 软件的副本可以通过我们获得，而不对您居住地点或您打算做什么进行任何限制。同时，自由软件基金会理解位于美国的商业分发者遵守美国法律的愿望。他们有权选择将自由软件的特定副本分发给谁；该权利的行使不违反 GPL，除非他们增加超出 GPL 许可的合同限制。

4.22 GPL v3 第 6 节的开头说，如果我也符合第 6 节的条件，我可以“按照第 4 节和第 5 节的规定”，以目标代码的形式传递其覆盖的作品。这是什么意思？

这意味着您传递源代码的所有权限和条件也适用于传递目标代码：您可以收取费用，您必须保持版权声明不变，等等。

4.23 我公司拥有很多专利。多年来，我们遵循“GPL 第 2 版或更新版本”的项目提供了代码，项目本身已按相同的条款进行了分发。如果用户决定将项目代码（包含我公司的贡献）适用 GPL v3，那意味着我已经自动向该用户授予 GPL v3 中的明确专利许可？

不是，当您 传递 （ convey ） 遵循 GPL 的软件时，您必须遵守该许可证特定版本的条款和条件。当您这样做时，该版本定义了您拥有的义务。如果用户也可以选择使用更新版本的 GPL，那仅仅是他们拥有的额外权限——它不需要您满足 GPL 更新版本条款的要求。

不要因为答案是 NO 就认为可以用你的专利来威胁社区（LCTT 译注：感谢“西米宜家”的指正）。在许多国家，根据 GPL v2 分发软件为接收人提供了隐含的专利许可，以行使 GPL 中的权利。即使没有，任何考虑强制执行专利的人都是社区的敌人，我们将捍卫自己免受这种攻击。

4.24 如果我分发了一个遵循 GPL v3 的程序，我可以提供一个一旦用户修改程序则无效的保修吗？

可以。就像用户一旦修改设备中的软件就不需要保证设备安全一样，您不需要提供涵盖所有可能通过遵循 GPL v3 的软件进行的活动的保修。

4.25 如果我给公司同事一份遵循 GPL v3 的程序的副本，是否构成了我将该副本 “传递” （ convey ） 给该同事？

只要您在公司的工作中使用软件，而不是个人使用该软件，那么答案是否定的。副本属于公司，不属于您或同事。这种复制是 传播 （ propagation ） 而不是 传递 （ convey ） ，因为公司没有将副本提供给他人。

4.26 如果我通过链接至版本控制系统（例如 CVS 或 Subversion）中的源代码存储库方式提供源代码，而在 FTP 服务器上提供二进制文件，这种做法符合 GPL v3 吗？

只要源码签出过程不会变得繁重或存在其他限制，这是可以接受的。任何可以下载目标代码的人也应该可以使用公开的自由软件客户端从版本控制系统中签出源代码。应向用户提供清晰方便的说明，说明如何获取其下载的确切目标代码的源代码——毕竟，他们可能不一定需要最新的开发代码。

4.27 在 用户产品 （ User Product ） 中传递遵循 GPL v3 的软件的用户，是否可以使用远程认证来防止用户修改该软件？

不可以。当软件在用户产品中传递时，必须与源文件一起提供的“安装信息”的定义中明确表示：“该信息必须足以确保修改的目标代码的继续运行在任何情况下都不会仅仅因为修改过而被阻止或干扰。“如果设备以某种方式使用远程认证，则安装信息必须为您修改的软件报告自身的合法性提供一些方法。

4.28 GPL v3 中的“通过网络进行通信的规则和协议”是什么意思？

这是指可以通过网络发送的流量规则。例如，如果每天可以发送到服务器的请求数量或者您可以在某处上传的文件大小有限制，如果不遵守这些限制，则可能会拒绝您对这些资源的访问。

这些规则不包括任何与网络上传播的数据无关的内容。例如，如果网络上的服务器将用户消息发送到您的设备，则您对网络的访问无法被拒绝，因为您修改了该软件以使其不显示消息。

4.29 依据 GPL v3 提供安装信息的分发者不需要为产品提供“支持服务”。 所谓的“支持服务”具体是指哪些？

这其中包括设备制造商提供的帮助您安装、使用或排除故障的服务。如果设备依赖于访问 Web 服务或类似技术才能正常运行，则通常仍然可以使用修改版本，但须符合第 6 节中关于访问网络的条款。

译者介绍：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

在 fleetster， 我们搭建了自己的 Gitlab 实例，而且我们大量使用了 Gitlab CI。我们的设计师和测试人员也都在用它，也很喜欢用它，它的那些高级功能特别棒。

Gitlab CI 是一个功能非常强大的持续集成系统，有很多不同的功能，而且每次发布都会增加新的功能。它的技术文档也很丰富，但是对那些要在已经配置好的 Gitlab 上使用它的用户来说，它缺乏一个一般性介绍。设计师或者测试人员是无需知道如何通过 Kubernetes 来实现自动伸缩，也无需知道“镜像”和“服务”之间的不同的。

但是，他仍然需要知道什么是“管道”，知道如何查看部署到一个“环境”中的分支。因此，在本文中，我会尽可能覆盖更多的功能，重点放在最终用户应该如何使用它们上；在过去的几个月里，我向我们团队中的某些人包括开发者讲解了这些功能：不是所有人都知道 持续集成 Continuous Integration （CI）是个什么东西，也不是所有人都用过 Gitlab CI。

如果你想了解为什么持续集成那么重要，我建议阅读一下 这篇文章，至于为什么要选择 Gitlab CI 呢，你可以去看看 Gitlab.com 上的说明。

简介

开发者保存更改代码的动作叫做一次 提交 commit 。然后他可以将这次提交 推送 push 到 Gitlab 上，这样可以其他开发者就可以 复查 review 这些代码了。

Gitlab CI 配置好后，Gitlab 也能对这个提交做出一些处理。该处理的工作由一个 运行器 runner 来执行的。所谓运行器基本上就是一台服务器（也可以是其他的东西，比如你的 PC 机，但我们可以简单称其为服务器）。这台服务器执行 .gitlab-ci.yml 文件中指令，并将执行结果返回给 Gitlab 本身，然后在 Gitlab 的图形化界面上显示出来。

开发者完成一项新功能的开发或完成一个 bug 的修复后（这些动作通常包含了多次的提交），就可以发起一个 合并请求 merge request ，团队其他成员则可以在这个合并请求中对代码及其实现进行 评论 comment 。

我们随后会看到，由于 Gitlab CI 提供的两大特性， 环境 environment 与 制品 artifact ，使得设计者和测试人员也能（而且真的需要）参与到这个过程中来，提供反馈以及改进意见。

管道 pipeline

每个推送到 Gitlab 的提交都会产生一个与该提交关联的 管道 pipeline 。若一次推送包含了多个提交，则管道与最后那个提交相关联。管道就是一个分成不同 阶段 stage 的 作业 job 的集合。

同一阶段的所有作业会并发执行（在有足够运行器的前提下），而下一阶段则只会在上一阶段所有作业都运行并返回成功后才会开始。

只要有一个作业失败了，整个管道就失败了。不过我们后面会看到，这其中有一个例外：若某个作业被标注成了手工运行，那么即使失败了也不会让整个管道失败。

阶段则只是对批量的作业的一个逻辑上的划分，若前一个阶段执行失败了，则后一个执行也没什么意义了。比如我们可能有一个 构建 build 阶段和一个 部署 deploy 阶段，在构建阶段运行所有用于构建应用的作业，而在部署阶段，会部署构建出来的应用程序。而部署一个构建失败的东西是没有什么意义的，不是吗？

同一阶段的作业之间不能有依赖关系，但它们可以依赖于前一阶段的作业运行结果。

让我们来看一下 Gitlab 是如何展示阶段与阶段状态的相关信息的。

作业 job

作业就是运行器要执行的指令集合。你可以实时地看到作业的输出结果，这样开发者就能知道作业为什么失败了。

作业可以是自动执行的，也就是当推送提交后自动开始执行，也可以手工执行。手工作业必须由某个人手工触发。手工作业也有其独特的作用，比如，实现自动化部署，但只有在有人手工授权的情况下才能开始部署。这是限制哪些人可以运行作业的一种方式，这样只有信赖的人才能进行部署，以继续前面的实例。

作业也可以建构出 制品 artifacts 来以供用户下载，比如可以构建出一个 APK 让你来下载，然后在你的设备中进行测试; 通过这种方式，设计者和测试人员都可以下载应用并进行测试，而无需开发人员的帮助。

除了生成制品外，作业也可以部署环境，通常这个环境可以通过 URL 访问，让用户来测试对应的提交。

做作业状态与阶段状态是一样的：实际上，阶段的状态就是继承自作业的。

制品 Artifacts

如前所述，作业能够生成制品供用户下载来测试。这个制品可以是任何东西，比如 Windows 上的应用程序，PC 生成的图片，甚至 Android 上的 APK。

那么，假设你是个设计师，被分配了一个合并请求：你需要验证新设计的实现！

要该怎么做呢？

你需要打开该合并请求，下载这个制品，如下图所示。

每个管道从所有作业中搜集所有的制品，而且一个作业中可以有多个制品。当你点击下载按钮时，会有一个下拉框让你选择下载哪个制品。检查之后你就可以评论这个合并请求了。

你也可以从没有合并请求的管道中下载制品 ;-)

我之所以关注合并请求是因为通常这正是测试人员、设计师和相关人员开始工作的地方。

但是这并不意味着合并请求和管道就是绑死在一起的：虽然它们结合的很好，但两者之间并没有什么关系。

环境 environment

类似的，作业可以将某些东西部署到外部服务器上去，以便你可以通过合并请求本身访问这些内容。

如你所见， 环境 environment 有一个名字和一个链接。只需点击链接你就能够转至你的应用的部署版本上去了（当前，前提是配置是正确的）。

Gitlab 还有其他一些很酷的环境相关的特性，比如 监控 monitoring ，你可以通过点击环境的名字来查看。

总结

这是对 Gitlab CI 中某些功能的一个简单介绍：它非常强大，使用得当的话，可以让整个团队使用一个工具完成从计划到部署的工具。由于每个月都会推出很多新功能，因此请时刻关注 Gitlab 博客。

若想知道如何对它进行设置或想了解它的高级功能，请参阅它的文档。

在 fleetster，我们不仅用它来跑测试，而且用它来自动生成各种版本的软件，并自动发布到测试环境中去。我们也自动化了其他工作（构建应用并将之发布到 Play Store 中等其它工作）。

说起来，你是否想和我以及其他很多超棒的人一起在一个年轻而又富有活力的办公室中工作呢？ 看看 fleetster 的这些招聘职位 吧！

赞美 Gitlab 团队 (和其他在空闲时间提供帮助的人)，他们的工作太棒了！

若对本文有任何问题或回馈，请给我发邮件：[email protected] 或者发推给我：-) 你可以建议我增加内容，或者以更清晰的方式重写内容(英文不是我的母语)。

那么，再见吧，

R.

P.S：如果你觉得本文有用，而且希望我们写出其他文章的话，请问您是否愿意帮我买杯啤酒给我 让我进入 鲍尔默峰值？

via: https://rpadovani.com/introduction-gitlab-ci

作者：Riccardo 译者：lujun9972 校对：wxy

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

Linux 系统为文件压缩提供了许多选择，关键是选择一个最适合你的。

如果你对可用于 Linux 系统的文件压缩命令或选项有任何疑问，你也许应该看一下 apropos compress 这个命令的输出。如果你有机会这么做，你会惊异于有如此多的的命令来进行压缩文件和解压缩文件；此外还有许多命令来进行压缩文件的比较、检验，并且能够在压缩文件中的内容中进行搜索，甚至能够把压缩文件从一个格式变成另外一种格式（如，将 .z 格式变为 .gz 格式 ）。

你可以看到只是适用于 bzip2 压缩的全部条目就有这么多。加上 zip、gzip 和 xz 在内，你会有非常多的选择。

$ apropos compress | grep ^bz
    bzcat (1)            - decompresses files to stdout
    bzcmp (1)            - compare bzip2 compressed files
    bzdiff (1)           - compare bzip2 compressed files
    bzegrep (1)          - search possibly bzip2 compressed files for a regular expression
    bzexe (1)            - compress executable files in place
    bzfgrep (1)          - search possibly bzip2 compressed files for a regular expression
    bzgrep (1)           - search possibly bzip2 compressed files for a regular expression
    bzip2 (1)            - a block-sorting file compressor, v1.0.6
    bzless (1)           - file perusal filter for crt viewing of bzip2 compressed text
    bzmore (1)           - file perusal filter for crt viewing of bzip2 compressed text   

在我的 Ubuntu 系统上 ，apropos compress 命令的返回中列出了 60 条以上的命令。

压缩算法

压缩并没有普适的方案，某些压缩工具是有损压缩，例如一些压缩用于减少 mp3 文件大小，而能够使聆听者有接近原声的音乐感受。但是在 Linux 命令行上压缩或归档用户文件所使用的算法必须能够精确地重新恢复为原始数据。换句话说，它们必须是无损的。

这是如何做到的？让我们假设在一行上有 300 个相同的字符可以被压缩成像 “300x” 这样的字符串，但是这种算法对大多数文件没有很大的用处，因为文件中不可能包含长的相同字符序列比完全随机的序列更多。 压缩算法要复杂得多，从 Unix 早期压缩首次被引入以来，它就越来越复杂了。

在 Linux 系统上的压缩命令

在 Linux 系统上最常用的文件压缩命令包括 zip、gzip、bzip2、xz。 所有这些压缩命令都以类似的方式工作，但是你需要权衡有多少文件要压缩（节省多少空间）、压缩花费的时间、压缩文件在其他你需要使用的系统上的兼容性。

有时压缩一个文件并不会花费很多时间和精力。在下面的例子中，被压缩的文件实际上比原始文件要大。这并不是一个常见情况，但是有可能发生——尤其是在文件内容达到一定程度的随机性。

$ time zip bigfile.zip bigfile
    adding: bigfile (default 0% )
real    0m0.055s
user    0m0.000s
sys     0m0.016s 
$ ls -l bigfile*
-rw-r--r-- 1 root root   0 12月 20 22:36 bigfile
-rw------- 1 root root 164 12月 20 22:41 bigfile.zip

注意该文件压缩后的版本（bigfile.zip）比原始文件（bigfile）要大。如果压缩增加了文件的大小或者减少很少的比例，也许唯一的好处就是便于在线备份。如果你在压缩文件后看到了下面的信息，你不会从压缩中得到什么受益。

 ( defalted 1% )

文件内容在文件压缩的过程中有很重要的作用。在上面文件大小增加的例子中是因为文件内容过于随机。压缩一个文件内容只包含 0 的文件，你会有一个相当震惊的压缩比。在如此极端的情况下，三个常用的压缩工具都有非常棒的效果。

-rw-rw-r-- 1 shs shs 10485760 Dec 8 12:31 zeroes.txt
-rw-rw-r-- 1 shs shs 49 Dec 8 17:28 zeroes.txt.bz2
-rw-rw-r-- 1 shs shs 10219 Dec 8 17:28 zeroes.txt.gz
-rw-rw-r-- 1 shs shs 1660 Dec 8 12:31 zeroes.txt.xz
-rw-rw-r-- 1 shs shs 10360 Dec 8 12:24 zeroes.zip

令人印象深刻的是，你不太可能看到超过 1000 万字节而压缩到少于 50 字节的文件, 因为基本上不可能有这样的文件。

在更真实的情况下 ，大小差异总体上是不同的，但是差别并不显著，比如对于确实不太大的 jpg 图片文件来说。

-rw-r--r-- 1 shs shs 13522 Dec 11 18:58 image.jpg
-rw-r--r-- 1 shs shs 13875 Dec 11 18:58 image.jpg.bz2
-rw-r--r-- 1 shs shs 13441 Dec 11 18:58 image.jpg.gz
-rw-r--r-- 1 shs shs 13508 Dec 11 18:58 image.jpg.xz
-rw-r--r-- 1 shs shs 13581 Dec 11 18:58 image.jpg.zip

在对大的文本文件同样进行压缩时 ，你会看到显著的不同。

$ ls -l textfile*
    -rw-rw-r-- 1 shs shs 8740836 Dec 11 18:41 textfile
    -rw-rw-r-- 1 shs shs 1519807 Dec 11 18:41 textfile.bz2
    -rw-rw-r-- 1 shs shs 1977669 Dec 11 18:41 textfile.gz
    -rw-rw-r-- 1 shs shs 1024700 Dec 11 18:41 textfile.xz
    -rw-rw-r-- 1 shs shs 1977808 Dec 11 18:41 textfile.zip

在这种情况下 ，xz 相较于其他压缩命令有效的减小了文件大小，对于第二的 bzip2 命令也是如此。

查看压缩文件

这些以 more 结尾的命令（bzmore 等等）能够让你查看压缩文件的内容而不需要解压文件。

bzmore (1) - file perusal filter for crt viewing of bzip2 compressed text
lzmore (1) - view xz or lzma compressed (text) files
xzmore (1) - view xz or lzma compressed (text) files
zmore (1) - file perusal filter for crt viewing of compressed text

为了解压缩文件内容显示给你，这些命令做了大量的计算。但在另一方面，它们不会把解压缩后的文件留在你系统上，它们只是即时解压需要的部分。

$ xzmore textfile.xz | head -1
    Here is the agenda for tomorrow's staff meeting:       

比较压缩文件

有几个压缩工具箱包含一个差异命令（例如 ：xzdiff），那些工具会把这些工作交给 cmp 和 diff 来进行比较，而不是做特定算法的比较。例如，xzdiff 命令比较 bz2 类型的文件和比较 xz 类型的文件一样简单 。

如何选择最好的 Linux 压缩工具

如何选择压缩工具取决于你工作。在一些情况下，选择取决于你所压缩的数据内容。在更多的情况下，取决你组织内的惯例，除非你对磁盘空间有着很高的敏感度。下面是一般性建议：

zip 对于需要分享给或者在 Windows 系统下使用的文件最适合。

gzip 或许对你要在 Unix/Linux 系统下使用的文件是最好的。虽然 bzip2 已经接近普及，但 gzip 看起来仍将长期存在。

bzip2 使用了和 gzip 不同的算法，并且会产生比 gzip 更小的文件，但是它们需要花费更长的时间进行压缩。

xz 通常可以提供最好的压缩率，但是也会花费相当长的时间。它比其他工具更新一些，可能在你工作的系统上还不存在。

注意

在压缩文件时，你有很多选择，而在极少的情况下，并不能有效节省磁盘存储空间。

via: https://www.networkworld.com/article/3240938/linux/how-to-squeeze-the-most-out-of-linux-file-compression.html

作者：Sandra Henry-Stocker 译者：singledo 校对：wxy

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

本书被《连线》杂志列为 2017 年出版的最有价值的科技书籍之一。

私有制的时代看起来似乎结束了，在这里我将不仅仅讨论那些由我们中的许多人引入到我们的家庭与生活的设备和软件，我也将讨论这些设备与应用依赖的平台与服务。

尽管我们使用的许多服务是免费的，但我们对它们并没有任何控制权。本质上讲，这些企业确实控制着我们所看到的、听到的以及阅读到的内容。不仅如此，许多企业还在改变工作的本质。他们正使用封闭的平台来助长由全职工作到零工经济的转变，这种方式提供极少的安全性与确定性。

这项行动对于网络以及每一个使用与依赖网络的人产生了广泛的影响。仅仅二十多年前的对开放互联网的想象正在逐渐消逝，并迅速地被一块难以穿透的幕帘所取代。

一种逐渐流行的补救办法就是建立 平台合作社 platform cooperatives ， 即由他们的用户所拥有的电子化平台。正如这本书《Ours to Hack and to Own》所阐述的，平台合作社背后的观点与开源有许多相同的根源。

学者 Trebor Scholz 和作家 Nathan Schneider 已经收集了 40 篇论文，探讨平台合作社作为普通人可使用的工具的增长及需求，以提升开放性并对闭源系统的不透明性及各种限制予以还击。

何处适合开源

任何平台合作社核心及接近核心的部分依赖于开源；不仅开源技术是必要的，构成开源开放性、透明性、协同合作以及共享的准则与理念同样不可或缺。

在这本书的介绍中，Trebor Scholz 指出：

与斯诺登时代的互联网黑盒子系统相反，这些平台需要使它们的数据流透明来辨别自身。他们需要展示客户与员工的数据在哪里存储，数据出售给了谁以及数据用于何种目的。

正是对开源如此重要的透明性，促使平台合作社如此吸引人，并在目前大量已有平台之中成为令人耳目一新的变化。

开源软件在《Ours to Hack and to Own》所分享的平台合作社的构想中必然充当着重要角色。开源软件能够为群体建立助推合作社的技术基础设施提供快速而不算昂贵的途径。

Mickey Metts 在论文中这样形容， “邂逅你的友邻技术伙伴。" Metts 为一家名为 Agaric 的企业工作，这家企业使用 Drupal 为团体及小型企业建立他们不能自行完成的平台。除此以外, Metts 还鼓励任何想要建立并运营自己的企业的公司或合作社的人接受自由开源软件。为什么呢？因为它是高质量的、并不昂贵的、可定制的，并且你能够与由乐于助人而又热情的人们组成的大型社区产生联系。

不总是开源的，但开源总在

这本书里不是所有的论文都关注或提及开源的；但是，开源方式的关键元素——合作、社区、开放治理以及电子自由化——总是在其间若隐若现。

事实上正如《Ours to Hack and to Own》中许多论文所讨论的，建立一个更加开放、基于平常人的经济与社会区块，平台合作社会变得非常重要。用 Douglas Rushkoff 的话讲，那会是类似 Creative Commons 的组织“对共享知识资源的私有化”的补偿。它们也如 Barcelona 的 CTO Francesca Bria 所描述的那样，是“通过确保市民数据安全性、隐私性和权利的系统”来运营他们自己的“分布式通用数据基础架构”的城市。

最后的思考

如果你在寻找改变互联网以及我们工作的方式的蓝图，《Ours to Hack and to Own》并不是你要寻找的。这本书与其说是用户指南，不如说是一种宣言。如书中所说，《Ours to Hack and to Own》让我们略微了解如果我们将开源方式准则应用于社会及更加广泛的世界我们能够做的事。

作者简介:

Scott Nesbitt ——作家、编辑、雇佣兵、 虎猫牛仔 Ocelot wrangle 、丈夫与父亲、博客写手、陶器收藏家。Scott 正是做这样的一些事情。他还是大量写关于开源软件文章与博客的长期开源用户。你可以在 Twitter、Github 上找到他。

via: https://opensource.com/article/17/1/review-book-ours-to-hack-and-own

作者：Scott Nesbitt 译者：darsh8 校对：wxy

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