2017年9月

像大多数新手一样,我一开始是在 StackOverflow 上搜索 Git 命令,然后把答案复制粘贴,并没有真正理解它们究竟做了什么。

Image credit: XKCD

我曾经想过:“如果有一个最常见的 Git 命令的列表,以及它们的功能是什么,这不是极好的吗?”

多年之后,我编制了这样一个列表,并且给出了一些最佳实践,让新手们甚至中高级开发人员都能从中发现有用的东西。

为了保持实用性,我将这个列表与我过去一周实际使用的 Git 命令进行了比较。

几乎每个开发人员都在使用 Git,当然很可能是 GitHub。但大多数开发者大概有 99% 的时间只是使用这三个命令:

git add --all
git commit -am "<message>"
git push origin master

如果你只是单枪匹马,或者参加一场黑客马拉松或开发一次性的应用时,它工作得很好,但是当稳定性和可维护性开始成为一个优先考虑的事情后,清理提交、坚持分支策略和提交信息的规范性就变得很重要。

我将从常用命令的列表开始,使新手更容易了解 Git 能做什么,然后进入更高级的功能和最佳实践。

经常使用的命令

要想在 仓库 repo 中初始化 Git,你只需输入以下命令即可。如果你没有初始化 Git,则不能在该仓库内运行任何其他的 Git 命令。

git init

如果你在使用 GitHub,而且正在将代码推送到在线存储的 GitHub 仓库中,那么你正在使用的就是 远程 remote 仓库。该远程仓库的默认名称(也称为别名)为 origin。如果你已经从 Github 复制了一个项目,它就有了一个 origin。你可以使用命令 git remote -v 查看该 origin,该命令将列出远程仓库的 URL。

如果你初始化了自己的 Git 仓库,并希望将其与 GitHub 仓库相关联,则必须在 GitHub 上创建一个,复制新仓库提供的 URL,并使用 git remote add origin <URL> 命令,这里使用 GitHub 提供的 URL 替换 <URL>。这样,你就可以添加、提交和推送更改到你的远程仓库了。

最后一条命令用在当你需要更改远程仓库时。如果你从其他人那里复制了一个仓库,并希望将远程仓库从原始所有者更改为你自己的 GitHub 帐户。除了改用 set-url 来更改远程仓库外,流程与 git remote add origin 相同。

git remote -v
git remote add origin <url>
git remote set-url origin <url>

复制仓库最常见的方式是使用 git clone,后跟仓库的 URL。

请记住,远程仓库将连接到克隆仓库原属于的帐户。所以,如果你克隆了一个属于别人的仓库,你将无法推送到 GitHub,除非你使用上面的命令改变了 origin

git clone <url>

你很快就会发现自己正在使用分支。如果你还不理解什么是分支,有许多其他更深入的教程,你应该先阅读它们,再继续下面的操作。(这里是一个教程

命令 git branch 列出了本地机器上的所有分支。如果要创建一个新的分支,可以使用命令 git branch <name>,其中 <name> 表示分支的名字,比如说 master

git checkout <name> 命令可以切换到现有的分支。你也可以使用 git checkout -b 命令创建一个新的分支并立即切换到它。大多数人都使用此命令而不是单独的 branchcheckout 命令。

git branch
git branch <name>
git checkout <name>
git checkout -b <name>

如果你对一个分支进行了一系列的更改,假如说此分支名为 develop,如果想要将该分支合并回主分支(master)上,则使用 git merge <branch> 命令。你需要先检出(checkout)主分支,然后运行 git merge developdevelop 合并到主分支中。

git merge <branch>

如果你正在与多个人进行协作,你会发现有时 GitHub 的仓库上已经更新了,但你的本地却没有做相应的更改。如果是这样,你可以使用 git pull origin <branch> 命令从远程分支中拉取最新的更改。

git pull origin <branch>

如果您好奇地想看到哪些文件已被更改以及哪些内存正在被跟踪,可以使用 git status 命令。如果要查看每个文件的更改,可以使用 git diff 来查看每个文件中更改的行。

git status
git diff --stat

高级命令和最佳实践

很快你会到达一个阶段,这时你希望你的提交看起来整洁一致。你可能还需要调整你的提交记录,使得提交更容易理解或者能还原一个意外的有破坏性的更改。

git log 命令可以输出提交的历史记录。你将使用它来查看提交的历史记录。

你的提交会附带消息和一个哈希值,哈希值是一串包含数字和字母的随机序列。一个哈希值示例如下:c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

假设你推送了一些可能破坏了你应用程序的东西。你最好回退一个提交然后再提交一次正确的,而不是修复它和推送新的东西。

如果你希望及时回退并从之前的提交中检出(checkout)你的应用程序,则可以使用该哈希作为分支名直接执行此操作。这将使你的应用程序与当前版本分离(因为你正在编辑历史记录的版本,而不是当前版本)。

git checkout c3d88eaa1aa4e4d5f

然后,如果你在那个历史分支中做了更改,并且想要再次推送,你必须使用强制推送。

注意:强制推送是危险的,只有在绝对必要的时候才能执行它。它将覆盖你的应用程序的历史记录,你将失去之后版本的任何信息。

git push -f origin master

在其他时候,将所有内容保留在一个提交中是不现实的。也行你想在尝试有潜在风险的操作之前保存当前进度,或者也许你犯了一个错误,但希望在你的版本历史中避免尴尬地留着这个错误。对此,我们有 git rebase

假设你在本地历史记录上有 4 个提交(没有推送到 GitHub),你要回退这是个提交。你的提交记录看起来很乱很拖拉。这时你可以使用 rebase 将所有这些提交合并到一个简单的提交中。

git rebase -i HEAD~4

上面的命令会打开你计算机的默认编辑器(默认为 Vim,除非你将默认修改为其他的),提供了几个你准备如何修改你的提交的选项。它看起来就像下面的代码:

pick 130deo9 oldest commit message
pick 4209fei second oldest commit message
pick 4390gne third oldest commit message
pick bmo0dne newest commit message

为了合并这些提交,我们需要将 pick 选项修改为 fixup(如代码下面的文档所示),以将该提交合并并丢弃该提交消息。请注意,在 Vim 中,你需要按下 ai 才能编辑文本,要保存退出,你需要按下 Esc 键,然后按 shift + z + z。不要问我为什么,它就是这样。

pick 130deo9 oldest commit message
fixup 4209fei second oldest commit message
fixup 4390gne third oldest commit message
fixup bmo0dne newest commit message

这将把你的所有提交合并到一个提交中,提交消息为 oldest commit message

下一步是重命名你的提交消息。这完全是一个建议的操作,但只要你一直遵循一致的模式,都可以做得很好。这里我建议使用 Google 为 Angular.js 提供的提交指南

为了更改提交消息,请使用 amend 标志。

git commit --amend

这也会打开 Vim,文本编辑和保存规则如上所示。为了给出一个良好的提交消息的例子,下面是遵循该指南中规则的提交消息:

feat: add stripe checkout button to payments page

- add stripe checkout button
- write tests for checkout

保持指南中列出的 类型 type 的一个优点是它使编写更改日志更加容易。你还可以在 页脚 footer (再次,在指南中规定的)中包含信息来引用 问题 issue

注意:如果你正在协作一个项目,并将代码推送到了 GitHub,你应该避免重新引用(rebase)并压缩(squash)你的提交。如果你开始在人们的眼皮子底下更改版本历史,那么你可能会遇到难以追踪的错误,从而给每个人都带来麻烦。

Git 有无数的命令,但这里介绍的命令可能是您最初几年编程所需要知道的所有。


Sam Corcos 是 Sightline Maps 的首席开发工程师和联合创始人,Sightline Maps 是最直观的 3D 打印地形图的平台,以及用于构建 Phoenix 和 React 的可扩展生产应用程序的中级高级教程网站 LearnPhoenix.io。使用优惠码:freecodecamp 取得 LearnPhoenix 的20美元。

(题图:GitHub Octodex


via: https://medium.freecodecamp.org/git-cheat-sheet-and-best-practices-c6ce5321f52

作者:Sam Corcos 译者:firmianay 校对:wxy

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

随着 Solaris 团队的彻底完蛋,看起来 Sun 微系统公司最终连块骨头都没剩下。

来自前 Sun 社区的消息表明,一月份的传闻(Oracle 裁员 450 人)成为了现实,上周五,Oracle 裁掉了 Solaris 和 SPARC 团队的核心员工,选择这个时候( 美国劳动节 Labor Day 前的周末)或许是希望这个消息被大众所忽略。

可以肯定,这意味着对于这些产品只会剩下骨架级的维护,特别是, Solaris 12 也取消了。这是一个典型的 Oracle 式的“ 无声结局 silent EOL ”,无论他们怎么声称保证履行对富士通和其它客户的合同条款。

随着该硬件的淘汰,我估计这是最后一个被 Oracle 收购处置的 Sun 资产了。在收购 Sun 微系统公司之后,Oracle 的埃里森对 Sun 的管理毫不留情,而且最大化地利用其手中的机会。那么,Sun 的资产都在 Oracle 手里都有什么遭遇呢?我并不是很关注 Oracle 的业务,但是可以从下列报告中一窥:

  • Java 被称之为“皇冠上的宝石”,但是其买下 Java SE 的真实原因其实是——试图起诉 Google 赔偿 80 亿美金,而且还两次败诉。
  • 埃里森说 Java 是中间件成功的关键,但是现在 Java EE 正准备交给一个开源基金会
  • Oracle 批评 Sun 没能从 Java 上挣到钱(忽略了 1996 - 2000 年 Java 使硬件市场获利的事实)并提出了一个根本不会产生收入的免费模型
  • 他们 拥抱了 NetBeans,而现在它被捐献给了 Apache 基金会。
  • MySQL 安全修复的官僚主义导致一部分社区成员转而和 MySQL 创始人 Monty 创建了 MariaDB 分支,而新分支已经足以支撑起一家公司
  • 埃里森说要重建 Sun 的硬件业务,但是其负责人已经在一个月前离职了,而剩下的员工也属于裁员的一部分。
  • 尽管 Sun 的前老板 McNealy 明白 Solaris 只有开源才能赢得市场,Oracle 表示“你说的没错”,然后把 Solaris 弄死了。其结果就是,上周末的裁员——而这在今年一月份就已经有了传闻。
  • Hudson 处理失当,意味着其 CI 业务只能跟在 CloudBees 从 Hubson 分支而来的 Jenkins 后面。
  • Oracle 放弃了 Sun 的身份管理项目,而现在 Forgerock 用它撑起了一个价值五亿美金的业务,为那些 Oracle 所不在意的客户服务。
  • Oracle 决定 取消 Sun Cloud ,并拆除了 Solaris 中的云服务功能,然后现在是云服务的天下了。
  • Oracle 重命名了 StarOffice,然后宣布了一个云端版本,但是没卵用。感觉该项目将走向末日,遭受到了严厉对待的社区决定另起锅灶去做 LibreOffice。
  • 只有 VirtualBox 看起来还好。

也许这并不是 Sun 失败的真正原因——在开源 Solaris 上花了太长时间,并在 2000 - 2002 年间试图用以市场为主导的方式来替代 Sun 一贯的工程为主导的方式——埃里森指责那些承担力挽狂澜责任的、硕果仅存的领袖们 McNealy、Zander、Tolliver 和他们的团队。埃里森从来没有理解过 Schwartz 所采取的开创性做法,而是在博客中嘲讽取消所有正在进行中的“科学项目”,拆除合作伙伴渠道,溯源开源社区。

与本周 HPE 将放弃的旧产品卖给 Micro Focus ,让其照料这些产品的做法相反,Oracle 的做法更残酷。Oracle 说过它将“重振 Sun 品牌”,但是事实上他们杀死的产品比 Sun 管理层曾经管理过的都要多——毫无疑问,这是“交易的艺术”。今天,和许多前 Sun 同事一样,这件事使我非常悲伤。

(本文由 Patreon 赞助支持, 欢迎你也成为支持者之一!)

根据市场调研机构 Net Applications 的统计,今年 8 月份 Linux 桌面市场份额首次突破了 3%。

Windows 依旧保持在 90% 以上,苹果 MacOS 也略有下滑,占 5.94%,Linux 则自从上个月达到 2.53% 之后,首次突破到了 3.37%。其它操作系统份额可以忽略不计。

根据 Net Applications 的历史数据,Linux 桌面份额是在 2009 年首次突破 1%,2016 年 6 月首次突破 2%,并基本上一直保持住了这个份额。显然从 2% 到 3% 的进度比 1% 到 2% 要快得多。

而据另外一家统计公司 StatCounter 的统计数据,Linux 的份额仅有 1% 多点,如果加上 ChromeOS 刚刚过了 2%。

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

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

2、对于 GNU 许可证的一般了解

2.1 为什么 GPL 允许用户发布其修改版本?

自由软件的一个关键特点是用户可以自由合作。绝对有必要允许希望彼此帮助的用户与其他用户分享他们对错误的修复和改进。

有些人提出了 GPL 的替代方案,需要原作者批准修改版本。只要原作者持续进行维护,这种做法在实践中可能会不错,但是如果作者停止维护(或多或少会)去做别的事情,或并不打算去满足所有用户的需求,这种替代方案就会失败。除了实践上的问题之外,该方案也不允许用户之间互相帮助。

有时候对修改版本的控制,是为了防止用户制作的各种版本之间造成混淆。根据我们的经验,这种混乱不是一个大问题。在 GNU 项目之外出现了许多版本的 Emacs,但用户仍可以将它们区分开。GPL 要求版本创造者将他/她的名字标注其上,以区别于其他版本,并保护其他维护者的声誉。

2.2 GPL 是否要求将修改版本的源代码公开发布?

GPL 不要求您发布修改后的版本或其中的任何一部分。您可以自由地进行修改并私人使用它们,而无需进行发布。这也适用于组织(包括企业);组织可以制作修改版本,在内部使用它,并且绝不将修改版本发布到组织之外。

但是,如果您以某种方式向公众发布修改后的版本,依据 GPL 许可证,GPL 要求您保证程序的用户可以获得修改后源代码。

因此,GPL 给你以某些特定方式发布修改后的程序的授权,而不是以其他方式发布;但是,是否发布修改版本的决定取决于您。

2.3 我可以在同一台电脑上安装一个遵循 GPL 许可证的程序和一个不相关的非自由程序吗?

可以。

2.4 如果我知道某些人有一个遵循 GPL 许可证的程序的副本,我可以要求他们给我一个副本吗?

不可以,GPL 给人们制作和再分发程序副本的授权,倘若有人选择这样做的话。那个人也有权选择不去再分发该程序。

2.5 GPL v2 中的“ 书面文件 written offer 对任何第三方有效”是什么意思? 这是否意味着世界上每个人都可以获得任何遵循 GPL 许可证的程序的源代码?

如果您选择通过书面文件提供源代码,那么任何向您索求源代码的人都有权收到。

如果您对不附带源代码的二进制文件进行商业分发,GPL 要求您必须提供一份书面文件,表明将稍后分发源代码。当用户非商业性地再分发他们从您那里获取的二进制文件时,他们必须传递这份书面文件的副本。这意味着不能直接从您那里获取二进制文件的人,仍然可以收到源代码副本以及该书面文件。

我们要求书面文件对任何第三方有效的原因是,以这种方式间接收到二进制代码的人可以从您那里订购源代码。

2.6 GPL v2 中规定,发布后的修改版本必须“授予…所有第三方许可”。这些第三方是谁?

第 2 节中规定,依据 GPL,您分发的修改版本必须授权给所有第三方。 “所有第三方”当然是指所有人,但这并不要求您为他们任何事情。这仅仅意味着他们依据 GPL 从您那里获得了您的修改版本的许可。

2.7 GPL 允许我出售程序的副本以获利吗?

是的,GPL 允许每个人这样做。销售副本的权利是自由软件定义的一部分。除了一种特殊情况之外,对您可以收取什么样的价格是没有限制的。(这种例外情况是:二进制版本必须附有表明将提供源代码的书面文件。)

2.8 GPL 允许我从我的分发网站收取下载程序的费用吗?

允许。您可以对您分发程序副本收取任何您想收取的费用。如果您通过下载分发二进制文件,则必须提供“等同的访问权限”来让人们下载源代码,因此,下载源代码的费用可能不会超过下载二进制文件的费用。

2.9 GPL 允许我要求任何接收软件的人必须向我支付费用和/或通知我吗?

不允许。实际上,这样的要求会使程序变成非自由软件。如果人们在获得程序副本时必须支付费用,或者他们必须特别通知任何人,那么这个程序就不是自由软件。请参阅自由软件的定义

GPL 是自由软件许可证,因此允许人们使用甚至再分发软件,而不需要向任何人支付费用。

您可以向用户收取费用,以获取您的副本。当他们从别人那里获得副本时,您不能要求人们向您支付费用。

2.10 如果我收费分发遵循 GPL 的软件,我是否还需要向公众免费提供?

不需要。不过,如果有人向您支付费用并获得副本,GPL 给予他们免费或收费向公众发布的自由。例如,有人可以向您支付费用,然后把他的副本放在一个网站上,让公众去获取。

2.11 GPL 允许我根据保密协议分发副本吗?

不允许。GPL 规定,任何从您那里获取副本的人都有权再分发已修改或未修改的副本。您不得在任何更严格的基础上分发作品。

如果有人要求您签署保密协议(NDA),以获取来自 FSF 的遵循 GPL 的软件,请立即通知我们 mailto:[email protected]

如果违规行为涉及其他版权所有者的遵循 GPL 的代码,请通知该版权所有者,就像您对其他任何类型的 GPL 违规行为所做的工作一样。

2.12 GPL 允许我根据保密协议分发程序的修改版或测试版吗?

不可以。GPL 规定,您的修改版本必须具备 GPL 中规定的所有自由。因此,从您那里获取您的版本副本的任何人都有权再分发该版本的副本(已修改或未修改)。您不得在更严格的基础上分发该作品的任何版本。

2.13 GPL 是否允许我根据保密协议开发程序的修改版本?

可以。例如,您可以接受一份合同来开发修改版本,并同意不得发布您的修改版本,直到客户同意才可以发布。这是允许的,因为这种情况下不处于 GPL 协议之下的代码是依据 NDA 分发的。

您还可以依据 GPL 将您的修改版本发布给客户,但须同意不将其发布给其他任何人,除非客户同意。也同样在这种情况下,不处于 GPL 协议之下的代码是以保密协议或任何其他限制条款分发的。

GPL 将给予客户再分发您的版本的权利。在这种情况下,客户可能会选择不行使这项权利,但他确实拥有这项权利。

2.14 为什么 GPL 要求程序的每个副本必须包含 GPL 许可证副本?

作品包含许可证副本至关重要,因此获得程序副本的每个人都可以知道他们的权利是什么。

包括一个指向许可证的 URL,而不是将许可证本身包含在内,这是一种看起来很诱人的做法。但是您不能确定该 URL 在五年或十年后仍然有效。二十年后,我们今天所知道的 URL 们可能已不复存在。

不管网络将发生什么样的变化,确保拥有该程序副本的人员能够继续看到 GPL 许可证的唯一方法是,将许可证的副本包含在该程序中。

2.15 如果作品不是很长,那该怎么办?

如果整个软件包中只有很少的代码——我们使用的基准是不到 300 行,那么您可以使用一个宽松的许可证,而不是像 GNU GPL这样的 Copyleft 许可证(除非代码特别重要)。我们建议这种情况使用 Apache License 2.0

2.16 我是否需要将我对遵循 GPL 的程序所做的修改声明版权?

您不需要对您的修改声明版权。不过,在大多数国家/地区,默认情况下会自动获得版权,因此,如果您不希望修改受到版权限制,您需要将修改明显地放置于公有领域。

无论您是否对您的修改声明版权,依据 GPL,您都必须将修改版本作为整体发布(参见:2.2 GPL 是否要求将修改版本的源代码公开发布?)。

2.17 GPL 对于将某些代码翻译成不同的编程语言是如何规定的?

根据著作权法,翻译工作被认为是一种修改。因此,GPL 对修改版本的规定也适用于翻译版本。

2.18 如果一个程序将公有领域代码与遵循 GPL 的代码相结合,我可以取出公有领域的部分,并作为公有领域代码来使用吗?

您可以这样做,如果您能弄清楚哪个部分是公有领域的部分,并将其与其他部分区分开。如果代码曾经由其开发人员放置在公有领域,那么它就是公有领域代码,无论它现在究竟在哪里。

2.19 我想要因我的作品获得声誉。我想让人们知道我写了什么,如果我使用 GPL,我还能获得声誉吗?

您一定能获得这份作品的声誉。遵循 GPL 发布的程序的一部分是以您自己名义撰写的版权声明(假设您是版权所有者)。GPL 要求所有副本携带恰当的版权声明。

2.20 GPL 允许我添加条款,要求在使用遵循 GPL 的软件或其输出物的研究论文中包含引用或致谢吗?

不可以,根据 GPL 的规定,这是不允许的。虽然我们认识到适当的引用是学术出版物的重要组成部分,但引用不能作为对 GPL 的附加要求。对使用 GPL 软件的研究论文要求包含引用,超出了 GPL v3 第 7(b)条中可接受的附加要求,因此将被视为对 GPL 第 7 节的额外限制。而且版权法也不允许您在软件的输出物中设置这样的要求,无论该软件是依据 GPL 还是其他许可证的条款获得许可。

2.21 为了节省空间,我是否可以省略 GPL 的引言部分,或者省略如何在自己的程序上使用GPL的 指导 instructions 部分吗?

引言和指导是 GNU GPL 的组成部分,不能省略。事实上,GPL 是受版权保护的,其许可证规定只能逐字复制整个 GPL。(您可以使用法律条款制作另一个许可证,但该许可证不再是 GNU GPL。)

引言和指导部分共约 1000 字,不到 GPL 总文字数量的 1/5。除非软件包本身很小,否则引言和指导不会对软件包的大小产生大幅度的改变。在软件包很小的情况下,您可以使用一个简单的 全权 all-permissive 许可证,而不是 GNU GPL。

2.22 两个许可证“兼容”是指什么?

为了将两个程序(或它们的实质部分)组合成一个更大的作品,您需要有以组合方式使用这两个程序的权限。如果两个程序的许可证允许这种使用方式,则它们是兼容的。如果没有办法同时满足这两个许可证,则它们是不兼容的。

对于一些许可证,组合的方式可能会影响它们是否兼容,例如,它们可能允许将两个模块链接在一起,但不允许将其代码合并到一个模块中。

如果您只想在同一个系统中安装两个独立的程序,那么它们的许可证并不是必须兼容的,因为它们没有组合成更大的作品。

2.23 许可证与 GPL 兼容是什么意思?

这意味着其他许可证和 GNU GPL 兼容;在一个更大的程序中,您可以将根据其他许可证发布的代码与根据 GNU GPL 发布的代码进行组合。

所有 GNU GPL 版本都允许进行这种组合;它们还允许分发这些组合,只要该组合在相同的 GNU GPL 版本下发布。其他许可证如果允许这样做,则其与 GPL 兼容。

与 GPL v2 相比,GPL v3 与更多的许可证兼容:它允许您与具有特定类型附加要求(GPL v3 本身不包含)的代码进行组合。GPL v3 第 7 节中有关于此问题的更多信息,包括了允许的附加要求的列表。

2.24 为什么原始的 BSD 许可证与 GPL 不兼容?

因为它规定了 GPL 不包含的具体要求,即对程序广告的要求。GPL v2 第 6 节规定:

您不得对接受者行使本协议授予的权利施加进一步的限制。

GPL v3 在第 10 节中提到类似的内容。广告条款正好提供了这样一个限制,因此与 GPL 不兼容。

修订的 BSD 许可证没有广告条款,从而消除了这个问题。

2.25 “ 聚合 aggregate ”与其他类型的“修改版本”有什么区别?

“聚合”由多个单独的程序组成,分布在同一个 CD-ROM或其他媒介中。GPL 允许您创建和分发聚合,即使其他软件的许可证不是自由许可证或与 GPL 不兼容。唯一的条件是,发布“聚合”所使用的许可证不能禁止用户去行使“聚合”中每个程序对应的许可证所赋予用户的权利。

两个单独的程序还是一个程序有两个部分,区分的界限在哪里?这是一个法律问题,最终由法官决定。我们认为,适当的判断标准取决于通信机制(exec、管道、rpc、共享地址空间内的函数调用等)和通信的语义(哪些信息被互换)。

如果模块们被包含在相同的可执行文件中,则它们肯定是被组合在一个程序中。如果模块们被设计为在共享地址空间中链接在一起运行,那么几乎肯定意味着它们组合成为一个程序。

相比之下,管道、套接字和命令行参数是通常在两个独立程序之间使用的通信机制。所以当它们用于通信时,模块们通常是单独的程序。但是,如果通信的语义足够亲密,交换复杂的内部数据结构,那么也可以视为这两个部分合并成了一个更大的程序。

2.26 为什么 FSF 要求为 FSF拥有版权的程序做出贡献的贡献者将版权 分配 assign 给 FSF?如果我持有 GPL 程序的版权,我也应该这样做吗?如果是,怎么做? (同1.11)

我们的律师告诉我们,为了最大限度地向法院要求违规者强制执行 GPL,我们应该让程序的版权状况尽可能简单。为了做到这一点,我们要求每个贡献者将贡献部分的版权分配给 FSF,或者放弃对贡献部分的版权要求。

我们也要求个人贡献者从雇主那里获得版权放弃声明(如果有的话),以确保雇主不会声称拥有这部分贡献的版权。

当然,如果所有的贡献者把他们的代码放在公共领域,也就没有用之来执行 GPL 许可证的版权了。所以我们鼓励人们为大规模的代码贡献分配版权,只把小规模的修改放在公共领域。

如果您想要在您的程序中执行 GPL,遵循类似的策略可能是一个好主意。如果您需要更多信息,请联系mailto:[email protected]

2.27 如果我使用遵循 GNU GPL 的软件,那么允许我将原始代码修改为新程序,然后在商业上分发和销售新程序吗?

您被允许在商业上出售修改程序的副本,但仅限于在 GNU GPL 的条款之下这么做。因此,例如,您必须依照 GPL 所述,使得程序用户可获取源代码,并且,用户也依照 GPL 所述,被允许再分发和修改程序。

这些要求是将遵循 GPL 的代码包含在您自己的程序中的条件。

2.28 我可以将 GPL 应用于软件以外的其他作品吗? (同1.6)

您可以将 GPL 应用于任何类型的作品,只需明确该作品的“源代码”构成即可。GPL 将“源代码”定义为作品的首选形式,以便在其中进行修改。

不过,对于手册和教科书,或更一般地,任何旨在教授某个主题的作品,我们建议使用 GFDL,而非 GPL。

2.29 我想依据 GPL 授权我的代码,但我也想明确指出,它不能用于军事和/或商业用途。我可以这样做吗?

不可以,因为这两个目标相互矛盾。GNU GPL 被专门设计为防止添加进一步的限制。GPL v3 在第 7 节允许非常有限的一组附加限制,但是用户可以删除任何其他添加的限制。

2.30 我可以依据 GPL 来对硬件进行许可吗?

任何可以受版权保护的 材料 material 都可以依据GPL进行许可。GPL v3 也可以用于受其他类似版权法的法律保护的材料,如半导体掩模。因此,作为一个例子,您可以依据 GPL 发布物理对象的图纸或电路。

在许多情况下,版权不涵盖依照图纸制作的物理硬件。在这种情况下,无论您使用什么许可证,您对图纸的许可都不能对制造或销售物理硬件施加任何控制。当版权不涵盖利用 IC 掩膜等进行硬件制作时,GPL 能以有效的方式处理这种情况。

2.31 将遵循 GPL 的二进制文件 预链接 prelinking 到系统上的各种库,以优化其性能,将被视为修改吗?

不。 预链接 prelinking 是编译过程的一部分;与编译过程所涉及的其他各个方面相比,预链接没有引入更多的许可证要求。如果您被允许将程序链接到各种库,那么也可以预链接到各种库。如果您分发预链接后的目标码,则需要遵循第 6 节的条款。

2.32 LGPL 如何与 Java 配合使用?

详情请参阅这篇文章。LGPL 如同被设计、被预想、被期待的那样去工作。

2.33 为什么你们在 GPL v3 中发明新的术语“ 传播 propagate ”和“ 传递 convey ”?

(译者注:convey 这个词汇在一个 GPL 译本中被翻译为“转发”,此处,我们认为“转发”一词在计算机领域存在一定的歧义,因此,采用“传递”的翻译。)

GPL v2 中使用的“分发”一词来自美国版权法。多年来,我们了解到,一些司法管辖区在自己的版权法中使用了同一个词,但却给出了不同的含义。我们发明了这些新术语,无论在何处对许可证进行解释,都使我们的意图尽可能清楚。这些新术语没有使用在世界上的任何版权法中,我们直接在许可证中提供了它们的定义。

2.34 在GPL v3中的“ 传递 convey ”与GPL v2中的“ 分发 distribute ”意思一样吗?

是的,差不多是一个意思。在执行 GPL v2 的过程中,我们了解到一些司法管辖区在自己的版权法中使用了“分发”这个词,但给出了不同的含义。我们发明了一个新的术语,以使我们的意图清晰,避免这些差异可能引起的任何问题。

2.35 如果我只复制遵循 GPL 的程序并运行它们,而不分发或传递给其他人,许可证对我施加什么要求?

没有要求。GPL 不对此活动附加任何条件。

2.36 GPL v3将“向公众提供”作为 传播 propagate 的一个例子。这是什么意思? 是提供一种可获取的传递形式吗?

“向公众提供”的一个例子是将该软件放在公共网页或FTP服务器上。在您这样做之后,在任何人从您那里真正获取软件之前,可能会需要一段时间,但是由于这种情况可能会立即发生,您也需要能够立即履行 GPL 的义务。因此,我们将“ 传递 convey ”定义为包括这一活动。

2.37 鉴于分发和向公众提供作为传播形式,同样也构成了 GPL v3 中的“ 传递 conveying ”,那么有哪些传播的例子不构成传递吗?

为自己制作软件的副本是不构成“传递”的主要传播形式。您可以依此在多台计算机上安装软件,或进行备份。

2.38 GPL v3 如何让 BitTorrent 分发变得更容易?

因为 GPL v2 是在软件的点对点分发普及之前编写的,所以当您利用这种方式分享代码时,很难满足 GPL v2 的要求。在 BitTorrent 上分发 GPL v2 目标代码时,确保您合规的最佳方法是将所有相应的源代码包含在相同的 种子文件 Torrent 中,但这种方式代价高昂。

GPL v3 以两种方式解决了这个问题。首先,作为该过程的一部分,下载此种子文件并将数据发送给其他人的人不需要做任何事情。因为第 9 节规定:“受保护作品的辅助传播如果仅仅是使用点对点传输来接收副本,不需要接受[本许可证]。”

第二,通过告知接收人在公共网络服务器上哪里可获取,GPL v3 的第 6(e)节旨在给予分发者(最初制作种子文件的人)一种清晰、直观的方式来提供源代码。这样可以确保每个想要获取源代码的人都可以如此获取,而且分发者几乎不用担心。

2.39 什么是 TiVo化 tivoization ? GPL v3 对此如何防止?

一些设备使用可升级的自由软件,但被设计为用户不能修改该软件。有很多不同的方式可以做到这一点;例如,有时硬件校验所安装的软件,如果与预期签名不匹配,则关闭软件。制造商通过提供源代码来遵循GPL v2,但是您仍然无法自由修改您使用的软件。我们称这种做法为 TiVo 化 tivoization

当人们分发包含遵循 GPL v3 软件的“ 用户产品 User Products ”时,第 6 节要求他们为您提供修改该软件所需的信息。“用户产品”是该许可证特别定义的术语;“用户产品”的示例包括便携式音乐播放器、数字录像机和家庭安全系统。

2.40 GPL v3 是否禁止 DRM?

不禁止,您可以使用遵循 GPL v3 发布的代码来开发您喜欢的任何类型的 DRM 技术。不过,如果您这样做,第 3 节规定,系统不会被视为一种有效的技术“保护”措施,这意味着如果有人破坏了 DRM,他也可以自由分发他的软件,不受《美国数字千禧版权法》(DMCA)和类似法律的限制。

像往常一样,GNU GPL 并不限制人们在软件中怎么做,只是阻止他们限制他人。

2.41 GPL v3 是否要求投票人能够修改在投票机中运行的软件?

不要求。企业分发包含遵循 GPL v3 软件的设备,最多只需要为拥有目标代码副本的人提供软件的源代码和安装信息。使用投票机(如同任何其他信息亭一样)的选民不能拥有它,甚至不能暂时拥有,所以选民也不能拥有二进制软件。

不过,请注意,投票是一个非常特殊的情况。仅仅因为计算机中的软件是自由软件,并不意味着您可以信任计算机,并进行投票。我们认为电脑不值得信任,不能被用作投票。投票应在纸上进行。

2.42 GPL v3 是否包含“专利报复条款”?

实际上,是的。第 10 节禁止传递该软件的人向其他被许可人发起专利诉讼。如果有人这样做,第 8 节解释他们将如何丧失许可证权益以及与之伴随的所有专利许可。

2.43 在 GPL v3 和 AGPL v3中,当说到“尽管有本许可证的其他规定”时,是什么意思?

这仅仅意味着以下条款胜过许可证中可能与之冲突的其他任何内容。例如,如果没有该文本,有些人可能声称,您不能将遵循 GPL v3 的代码与遵循 AGPL v3 的代码结合在一起,因为 AGPL 的附加要求将被归类为 GPL v3 第 7 节下的“进一步限制”。该文本明确表示我们的预期解释是正确的,您可以进行组合。

该文本仅解决许可证不同条款之间的冲突。当两个条件之间没有冲突的时候,您必须同时满足它们。这些段落不允许您轻率地忽略许可证的其余部分,它们只是强调了一些非常有限的例外。

2.44 在 AGPL v3 中,怎么才算是“通过计算机网络远程与[软件]进行交互”?

如果程序被明确设计为接受用户请求并通过网络发送响应,则它符合这些标准。属于此类程序的常见示例包括网络和邮件服务器、交互式网络应用程序和在线游戏的服务器。

如果程序没有被明确设计为通过网络与用户进行交互,而是恰好在这样做的环境中运行,那么它不属于此类。例如,仅仅因为用户通过 SSH 或远程 X 会话来运行的应用程序不需要提供源代码。

2.45 GPL v3 中“ you ”的概念如何与 Apache License 2.0 中“ 法律实体 Legal Entity ”的定义相比较?

它们是完全相同的。Apache License 2.0 中“法律实体”的定义在各种法律协议中是非常标准的,因此,如果法院在缺乏明确定义的情况下没有以同样的方式解释该术语,将会令人非常惊讶。我们完全期待他们在看 GPL v3 时也会如此,并考虑到谁有资格作为被许可人。

2.46 在 GPL v3 中,“ 该程序 the Program ”是指什么? 是每个依据 GPL v3 发布的程序?

术语“该程序”是指依据 GPL v3 进行许可的特定作品,由特定被许可人从上游许可人或分发者那里接收。“该程序”是您在 GPL v3 许可的指定情境下接受到的特定软件作品。

“该程序”并不意味着“依据 GPL v3 进行许可的所有作品”;由于一些原因,这种解释没有任何意义。针对那些想要了解更多的人,我们已经发表了对“该程序”一词的分析

2.47 如果某些网络客户端软件依据 AGPL v3 发布,是否必须能够向与之交互的服务器提供源代码?

AGPL v3 需要该程序向“所有通过计算机网络进行远程交互的用户”提供源代码。至于您将程序称为“客户端”还是“服务器”,那无关紧要。您需要询问的问题是,是否存在合理的期望让一个人通过网络远程与该程序交互。

2.48 对于一个运行在代理服务器上的依据 AGPL 进行许可的软件来说,如何向与该软件交互的用户提供源代码书面文件?

对于代理服务器上的软件,您可以通过向此类代理的用户传递消息的常规方法来提供源代码书面文件。例如,Web 代理可以使用登录页。当用户最初开始使用代理时,您可以将他们引导到包含源代码书面文件以及您选择提供的任何其他信息的页面。

AGPL 规定,您必须向“所有用户”提供书面文件。如果您知道某个用户已经被展示过书面文件,对于当前版本的软件,您不必再重复向该用户提供。

通过安装 SLS 1.05 展示了 Linux 内核在这 26 年间走过了多远。

 title=

我第一次安装 Linux 是在 1993 年。那时我跑的是 MS-DOS,但我真的很喜欢学校机房电脑的 Unix 系统,就在那里度过了我大学本科时光。 当我听说了 Linux,一个 Unix 的免费版本,可以在我家的 386 电脑上运行的时候,我立刻就想要试试。我的第一个 Linux 发行版是 Softlanding Linux System (SLS) 1.03,带有 11 级补丁的 0.99 alpha 版本的 Linux 内核。它要求高达 2 MB 的内存,如果你想要编译项目需要 4 MB,运行 X windows 则需要 8 MB。

我认为 Linux 相较于 MS-DOS 世界是一个巨大的进步。 尽管 Linux 缺乏运行在 MS-DOS 上的广泛的应用及游戏,但我发现 Linux 带给我的是巨大的灵活性。不像 MS-DOS ,现在我可以进行真正的多任务,同时运行不止一个程序。并且 Linux 提供了丰富的工具,包括一个 C 语言编译器,让我可以构建自己的项目。

一年后,我升级到了 SLS 1.05,它支持全新的 Linux 内核 1.0。 更重要的,Linux 引入了内核模块。通过内核模块,你不再需要为支持新硬件而编译整个内核;取而代之,只需要从包含 Linux 内核之内的 63 个模块里加载一个就行。在 SLS 1.05 的发行自述文件中包含这些关于模块的注释:

内核的模块化旨在正视减少并最终消除重新编译内核的要求,无论是变更、修改设备驱动或者为了动态访问不常用的驱动。也许更为重要的是,个别工作小组的工作不再影响到内核的正确开发。事实上,这让以二进制发布官方内核现在成为了可能。

在 8 月 25 日,Linux 内核将迎来它的第 26 周年(LCTT 译注:已经过去了 =.= )。为了庆祝,我重新安装了 SLS 1.05 来提醒自己 Linux 1.0 内核是什么样子,去认识 Linux 自二十世纪 90 年代以来走了多远。和我一起踏上 Linux 的怀旧之旅吧!

安装

SLS 是第一个真正的 “发行版”,因为它包含一个安装程序。 尽管安装过程并不像现代发行版一样顺畅。 不能从 CD-ROM 启动安装,我需要从安装软盘启动我的系统,然后从 login 提示中运行安装程序。

 title=

在 SLS 1.05 中引入的一个漂亮的功能是支持彩色的文本模式安装器。当我选择彩色模式时,安装器切换到一个带有黑色文字的亮蓝色背景,不再是我们祖祖辈辈们使用的原始的普通黑白文本。

 title=

SLS 安装器是个简单的东西,文本从屏幕底部滚动而上,显示其做的工作。通过对一些简单的提示的响应,我能够创建一个 Linux 分区,挂载上 ext2 文件系统,并安装 Linux 。 安装包含了 X windows 和开发工具的 SLS 1.05,需要大约 85 MB 的磁盘空间。依照今天的标准这听起来可能不是很多,但在 Linux 1.0 出来的时候,120 MB 的硬件设备才是主流设备。

 title=

 title=

系统级别

当我第一次启动到 Linux 时,让我想起来了一些关于这个早期版本 Linux 系统的事情。首先,Linux 没有占据很多的空间。在启动系统之后运行一些程序来检查的时候,Linux 占用了不到 4 MB 的内存。在一个拥有 16MB 内存的系统中,这就意味着节省了很多内存用来运行程序。

 title=

熟悉的 /proc 元文件系统在 Linux 1.0 就存在了,尽管对比我们今天在现代系统上看到的,它并不能提供许多信息。在 Linux 1.0, /proc 包含一些接口来探测类似 meminfostat 之类的基本系统状态。

 title=

在这个系统上的 /etc 文件目录非常简单。值得一提的是,SLS 1.05 借用了来自 BSD Unixrc 脚本来控制系统启动。 初始化是通过 rc 脚本进行的,由 rc.local 文件来定义本地系统的调整。后来,许多 Linux 发行版采用了来自 Unix System V 的很相似的 init 脚本,后来又是 systemd 初始化系统。

 title=

你能做些什么

随着我的系统的启动运行,接下来就可以使用了了。那么,在这样的早期 Linux 系统上你能做些什么?

让我们从基本的文件管理开始。 每次在你登录的时候,SLS 会让你使用 Softlanding 菜单界面(MESH),这是一个文件管理程序,现代的用户们可能觉得它和 Midnight Commander 很相似。 而二十世纪 90 年代的用户们可能会拿 MESH 与更为接近的 Norton Commander 相比,这个可以说是在 MS-DOS 上最流行的第三方文件管理程序。

 title=")

除了 MESH 之外,在 SLS 1.05 中还少量包含了一些全屏应用程序。你可以找到熟悉的用户工具,包括 Elm 邮件阅读器、GNU Emacs 可编程编辑器,以及古老的 Vim 编辑器。

 title=

 title=

SLS 1.05 甚至包含了一个可以让你在终端玩的俄罗斯方块版本。

 title=

在二十世纪 90 年代,多数住宅的网络接入是通过拨号连接的,所以 SLS 1.05 包含了 Minicom 调制解调器拨号程序。Minicom 提供一个与调制解调器的直接连接,并需要用户通过贺氏调制解调器的 AT 命令来完成一些像是拨号或挂电话这样的基础功能。Minicom 同样支持宏和其他简单功能来使连接你的本地调制解调器池更容易。

 title=

但如果你想要写一篇文档时怎么办? SLS 1.05 的存在要比 LibreOffice 或者 OpenOffice 早很长时间。在二十世纪 90 年代,Linux 还没有这些应用。相反,如果你想要使用一个文字处理器,可能需要引导你的系统进入 MS-DOS,然后运行你喜欢的文字处理器程序,如 WordPerfect 或者共享软件 GalaxyWrite。

但是所有的 Unix 系统都包含一套简单的文本格式化程序,叫做 nroff 和 troff。在 Linux 系统中,他们被合并成 GNU groff 包,而 SLS 1.05 包含了 groff 的一个版本。我在 SLS 1.05 上的一项测试就是用 nroff 生成一个简单的文本文档。

 title=

 title=

运行 X windows

获取安装 X windows 并不特别容易,如 SLS 安装文件承诺的那样:

在你的 PC 上获取安装 X windows 可能会有一些发人深省的体验,主要是因为 PC 的显示卡类型太多。Linux X11 仅支持 VGA 类型的显示卡,但在许多类型的 VGA 中仅有个别的某些类型是完全支持的。SLS 存在两种 X windows 服务器。全彩的 XFree86,支持一些或所有 ET3000、ET400、PVGA1、GVGA、Trident、S3、8514、Accelerated cards、ATI plus 等。

另一个服务器 XF86\_Mono,能够工作在几乎所有的 VGA 卡上,但只提供单色模式。因此,相比于彩色服务器,它会占用更少的内存并拥有更快的速度。当然就是看起来不怎么漂亮。

X windows 的配置信息都堆放在目录 “/usr/X386/lib/X11/”。需要注意的是,“Xconfig” 文件为监视器和显示卡定义了时序。默认情况下,X windows 设置使用彩色服务器,如果彩色服务器出现问题,你可以切换到单色服务器 x386mono,因为它已经支持各种标准的 VGA。本质上,这只是将 /usr/X386/bin/X 链接到它。

只需要编辑 Xconfig 来设置鼠标驱动类型和时序,然后键入 “startx” 即可。

这些听起来令人困惑,但它就是这样。手工配置 X windows 真的可以是一个发人深省的体验。幸好,SLS 1.05 包含了 syssetup 程序来帮你确定系统组件的种类,包括了 X windows 的显示设置。在一些提示过后,经过一些实验和调整,最终我成功启动了 X windows!

 title=

但这是来自于 1994 年的 X windows,它仍然并没有桌面的概念。我可以从 FVWM (一个虚拟窗口管理器)或 TWM (选项卡式的窗口管理器)中选择。TWM 直观地设置提供一个功能简单的图形环境。

 title=

关机

我已经在我的 Linux 寻根之旅沉浸许久,是时候最终回到我的现代桌面上了。最初我跑 Linux 的是一台仅有 8MB 内存和 一个 120MB 硬盘驱动器的 32 位 386 电脑,而我现在的系统已经足够强大了。拥有双核 64 位 Intel Core i5 处理器,4 GB 内存和一个 128 GB 的固态硬盘,我可以在我的运行着 Linux 内核 4.11.11 的系统上做更多事情。那么,在我的 SLS 1.05 的实验结束之后,是时候离开了。

 title=

再见,Linux 1.0。很高兴看到你的茁壮成长。

(题图:图片来源:litlnemo。由 Opnesource.com 修改。CC BY-SA 2.0.


via: https://opensource.com/article/17/8/linux-anniversary

作者:Jim Hall 译者:softpaopao 校对:wxy

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

 title=

一般情况下,常规用途的 Linux 发行版在开机启动时拉起各种相关服务进程,包括许多你可能无需使用的服务,例如 蓝牙 bluetooth 、Avahi、 调制解调管理器 ModemManager 、ppp-dns(LCTT 译注:此处作者笔误 ppp-dns 应该为 pppd-dns) 等服务进程,这些都是什么东西?用于哪里,有何功能?

Systemd 提供了许多很好的工具用于查看系统启动情况,也可以控制在系统启动时运行什么。在这篇文章中,我将说明在 Systemd 类发行版中如何关闭一些令人讨厌的进程。

查看开机启动项

在过去,你能很容易通过查看 /etc/init.d 了解到哪些服务进程会在引导时启动。Systemd 以不同的方式展现,你可以使用如下命令罗列允许开机启动的服务进程。

$ systemctl list-unit-files --type=service | grep enabled
accounts-daemon.service                    enabled
anacron-resume.service                     enabled
anacron.service                            enabled
bluetooth.service                          enabled
brltty.service                             enabled
[...]

在此列表顶部,对我来说,蓝牙服务是冗余项,因为在该电脑上我不需要使用蓝牙功能,故无需运行此服务。下面的命令将停止该服务进程,并且使其开机不启动。

$ sudo systemctl stop bluetooth.service
$ sudo systemctl disable bluetooth.service

你可以通过下面命令确定是否操作成功。

$ systemctl status bluetooth.service
 bluetooth.service - Bluetooth service
  Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled; vendor preset: enabled)
  Active: inactive (dead)
    Docs: man:bluetoothd(8)

停用的服务进程仍然能够被另外一个服务进程启动。如果你真的想在任何情况下系统启动时都不启动该进程,无需卸载该它,只需要把它掩盖起来就可以阻止该进程在任何情况下开机启动。

$ sudo systemctl mask bluetooth.service
 Created symlink from /etc/systemd/system/bluetooth.service to /dev/null.

一旦你对禁用该进程启动而没有出现负面作用感到满意,你也可以选择卸载该程序。

通过执行命令可以获得如下服务列表:

$ systemctl list-unit-files --type=service                       
UNIT FILE                                  STATE   
accounts-daemon.service                    enabled
acpid.service                              disabled
alsa-restore.service                       static    
alsa-utils.service                         masked

你不能启用或禁用静态服务,因为静态服务被其他的进程所依赖,并不意味着它们自己运行。

哪些服务能够禁止?

如何知道你需要哪些服务,而哪些又是可以安全地禁用的呢?它总是依赖于你的个性化需求。

这里举例了几个服务进程的作用。许多服务进程都是发行版特定的,所以你应该看看你的发行版文档(比如通过 google 或 StackOverflow)。

  • accounts-daemon.service 是一个潜在的安全风险。它是 AccountsService 的一部分,AccountsService 允许程序获得或操作用户账户信息。我不认为有好的理由能使我允许这样的后台操作,所以我选择 掩盖 mask 该服务进程。
  • avahi-daemon.service 用于零配置网络发现,使电脑超容易发现网络中打印机或其他的主机,我总是禁用它,别漏掉它。
  • brltty.service 提供布莱叶盲文设备支持,例如布莱叶盲文显示器。
  • debug-shell.service 开放了一个巨大的安全漏洞(该服务提供了一个无密码的 root shell ,用于帮助 调试 systemd 问题),除非你正在使用该服务,否则永远不要启动服务。
  • ModemManager.service 该服务是一个被 dbus 激活的守护进程,用于提供移动 宽频 broadband (2G/3G/4G)接口,如果你没有该接口,无论是内置接口,还是通过如蓝牙配对的电话,以及 USB 适配器,那么你也无需该服务。
  • pppd-dns.service 是一个计算机发展的遗物,如果你使用拨号接入互联网的话,保留它,否则你不需要它。
  • rtkit-daemon.service 听起来很可怕,听起来像是 rootkit。 但是你需要该服务,因为它是一个 实时内核调度器 real-time kernel scheduler
  • whoopsie.service 是 Ubuntu 错误报告服务。它用于收集 Ubuntu 系统崩溃报告,并发送报告到 https://daisy.ubuntu.com 。 你可以放心地禁止其启动,或者永久的卸载它。
  • wpa\_supplicant.service 仅在你使用 Wi-Fi 连接时需要。

系统启动时发生了什么?

Systemd 提供了一些命令帮助调试系统开机启动问题。该命令会重演你的系统启动的所有消息。

$ journalctl -b

-- Logs begin at Mon 2016-05-09 06:18:11 PDT,
end at Mon 2016-05-09 10:17:01 PDT. --
May 16 06:18:11 studio systemd-journal[289]:
Runtime journal (/run/log/journal/) is currently using 8.0M.
Maximum allowed usage is set to 157.2M.
Leaving at least 235.9M free (of currently available 1.5G of space).
Enforced usage limit is thus 157.2M.
[...]

通过命令 journalctl -b -1 可以复审前一次启动,journalctl -b -2 可以复审倒数第 2 次启动,以此类推。

该命令会打印出大量的信息,你可能并不关注所有信息,只是关注其中问题相关部分。为此,系统提供了几个过滤器,用于帮助你锁定目标。让我们以进程号为 1 的进程为例,该进程是所有其它进程的父进程。

$ journalctl _PID=1

May 08 06:18:17 studio systemd[1]: Starting LSB: Raise network interfaces....
May 08 06:18:17 studio systemd[1]: Started LSB: Raise network interfaces..
May 08 06:18:17 studio systemd[1]: Reached target System Initialization.
May 08 06:18:17 studio systemd[1]: Started CUPS Scheduler.
May 08 06:18:17 studio systemd[1]: Listening on D-Bus System Message Bus Socket
May 08 06:18:17 studio systemd[1]: Listening on CUPS Scheduler.
[...]

这些打印消息显示了什么被启动,或者是正在尝试启动。

一个最有用的命令工具之一 systemd-analyze blame,用于帮助查看哪个服务进程启动耗时最长。

$ systemd-analyze blame
         8.708s gpu-manager.service
         8.002s NetworkManager-wait-online.service
         5.791s mysql.service
         2.975s dev-sda3.device
         1.810s alsa-restore.service
         1.806s systemd-logind.service
         1.803s irqbalance.service
         1.800s lm-sensors.service
         1.800s grub-common.service

这个特定的例子没有出现任何异常,但是如果存在系统启动瓶颈,则该命令将能发现它。

你也能通过如下资源了解 Systemd 如何工作:


via: https://www.linux.com/learn/cleaning-your-linux-startup-process

作者:David Both 译者:penghuster 校对:wxy

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