Ubunsys 是一个面向 Ubuntu 及其衍生版的基于 Qt 的高级系统工具。高级用户可以使用命令行轻松完成大多数配置。不过为了以防万一某天，你突然不想用命令行了，就可以用 Ubnusys 这个程序来配置你的系统或其衍生系统，如 Linux Mint、Elementary OS 等。Ubunsys 可用来修改系统配置，安装、删除、更新包和旧内核，启用或禁用 sudo 权限，安装主线内核，更新软件安装源，清理垃圾文件，将你的 Ubuntu 系统升级到最新版本等等。以上提到的所有功能都可以通过鼠标点击完成。你不需要再依赖于命令行模式，下面是你能用 Ubunsys 做到的事：

• 安装、删除、更新包
• 更新和升级软件源
• 安装主线内核
• 删除旧的和不再使用的内核
• 系统整体更新
• 将系统升级到下一个可用的版本
• 将系统升级到最新的开发版本
• 清理系统垃圾文件
• 在不输入密码的情况下启用或者禁用 sudo 权限
• 当你在终端输入密码时使 sudo 密码可见
• 启用或禁用系统休眠
• 启用或禁用防火墙
• 打开、备份和导入 sources.list.d 和 sudoers 文件
• 显示或者隐藏启动项
• 启用或禁用登录音效
• 配置双启动
• 启用或禁用锁屏
• 智能系统更新
• 使用脚本管理器更新/一次性执行脚本
• 从 git 执行常规用户安装脚本
• 检查系统完整性和缺失的 GPG 密钥
• 修复网络
• 修复已破损的包
• 还有更多功能在开发中

重要提示： Ubunsys 不适用于 Ubuntu 新手。它很危险并且仍然不是稳定版。它可能会使你的系统崩溃。如果你刚接触 Ubuntu 不久，不要使用。但如果你真的很好奇这个应用能做什么，仔细浏览每一个选项，并确定自己能承担风险。在使用这一应用之前记着备份你自己的重要数据。

安装 Ubunsys

Ubunsys 开发者制作了一个 PPA 来简化安装过程，Ubunsys 现在可以在 Ubuntu 16.04 LTS、 Ubuntu 17.04 64 位版本上使用。

逐条执行下面的命令，将 Ubunsys 的 PPA 添加进去，并安装它。

sudo add-apt-repository ppa:adgellida/ubunsys
sudo apt-get update
sudo apt-get install ubunsys

如果 PPA 无法使用，你可以在发布页面根据你自己当前系统，选择正确的安装包，直接下载并安装 Ubunsys。

用途

一旦安装完成，从菜单栏启动 Ubunsys。下图是 Ubunsys 主界面。

你可以看到，Ubunsys 有四个主要部分，分别是 Packages、Tweaks、System 和 Repair。在每一个标签项下面都有一个或多个子标签项以对应不同的操作。

Packages

这一部分允许你安装、删除和更新包。

Tweaks

在这一部分，我们可以对系统进行多种调整，例如：

• 打开、备份和导入 sources.list.d 和 sudoers 文件；
• 配置双启动；
• 启用或禁用登录音效、防火墙、锁屏、系统休眠、sudo 权限（在不需要密码的情况下）同时你还可以针对某一用户启用或禁用 sudo 权限（在不需要密码的情况下）；
• 在终端中输入密码时可见（禁用星号）。

System

这一部分被进一步分成 3 个部分，每个都是针对某一特定用户类型。

Normal user 这一标签下的选项可以：

• 更新、升级包和软件源
• 清理系统
• 执行常规用户安装脚本

Advanced user 这一标签下的选项可以：

• 清理旧的/无用的内核
• 安装主线内核
• 智能包更新
• 升级系统

Developer 这一部分可以将系统升级到最新的开发版本。

Repair

这是 Ubunsys 的第四个也是最后一个部分。正如名字所示，这一部分能让我们修复我们的系统、网络、缺失的 GPG 密钥，和已经缺失的包。

正如你所见，Ubunsys 可以在几次点击下就能完成诸如系统配置、系统维护和软件维护之类的任务。你不需要一直依赖于终端。Ubunsys 能帮你完成任何高级任务。再次声明，我警告你，这个应用不适合新手，而且它并不稳定。所以当你使用的时候，能会出现 bug 或者系统崩溃。在仔细研究过每一个选项的影响之后再使用它。

谢谢阅读！

参考资源

• Ubunsys GitHub Repository

via: https://www.ostechnix.com/ubunsys-advanced-system-configuration-utility-ubuntu-power-users/

作者：SK 选题：lujun9972 译者：wenwensnow 校对：wxy

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

使用 Linux 中的 dd 工具安全、可靠地制作一个驱动器、分区和文件系统的完整镜像。

这篇文章节选自 Manning 出版社出版的图书 Linux in Action的第 4 章。

你是否正在从一个即将损坏的存储驱动器挽救数据，或者要把本地归档进行远程备份，或者要把一个别处的活动分区做个完整的副本，那么你需要懂得如何安全而可靠的复制驱动器和文件系统。幸运的是，dd 是一个可以使用的简单而又功能强大的镜像复制命令，从现在到未来很长的时间内，也许直到永远都不会出现比 dd 更好的工具了。

对驱动器和分区做个完整的副本

仔细研究后，你会发现你可以使用 dd 做各种任务，但是它最重要的功能是处理磁盘分区。当然，你可以使用 tar 命令或者 scp 命令从一台计算机复制整个文件系统的文件，然后把这些文件原样粘贴在另一台刚刚安装好 Linux 操作系统的计算机中。但是，因为那些文件系统归档不是完整的映像文件，所以在复制文件的过程中需要计算机操作系统的运行作为基础。

另一方面，使用 dd 可以对任何数字信息完美的进行逐个字节的镜像。但是不论何时何地，当你要对分区进行操作时，我要告诉你早期的 Unix 管理员曾开过这样的玩笑：“ dd 的意思是 磁盘毁灭者 disk destroyer ”（LCTT 译注：dd 原意是 磁盘复制 disk dump ）。 在使用 dd 命令的时候，如果你输入了哪怕是一个字母，也可能立即永久性的擦除掉整个磁盘驱动器里的所有重要的数据。因此，一定要注意命令的拼写格式规范。

记住： 在按下回车键执行 dd 命令之前，暂时停下来仔细的认真思考一下。

dd 命令的基本操作

现在你已经得到了适当的提醒，我们将从简单的事情开始。假设你要对代号为 /dev/sda 的整个磁盘数据创建精确的映像，你已经插入了一块空的磁盘驱动器 （理想情况下具有与代号为 /dev/sda 的磁盘驱动器相同的容量）。语法很简单： if= 定义源驱动器，of= 定义你要将数据保存到的文件或位置：

# dd if=/dev/sda of=/dev/sdb

接下来的例子将要对 /dev/sda 驱动器创建一个 .img 的映像文件，然后把该文件保存的你的用户帐号家目录：

# dd if=/dev/sda of=/home/username/sdadisk.img

上面的命令针对整个驱动器创建映像文件，你也可以针对驱动器上的单个分区进行操作。下面的例子针对驱动器的单个分区进行操作，同时使用了一个 bs 参数用于设置单次拷贝的字节数量 （此例中是 4096）。设定 bs 参数值可能会影响 dd 命令的整体操作速度，该参数的理想设置取决于你的硬件配置和其它考虑。

# dd if=/dev/sda2 of=/home/username/partition2.img bs=4096

数据的恢复非常简单：通过颠倒 if 和 of 参数可以有效的完成任务。在此例中，if= 使用你要恢复的映像，of= 使用你想要写入映像的目标驱动器：

# dd if=sdadisk.img of=/dev/sdb

你也可以在一条命令中同时完成创建和拷贝任务。下面的例子中将使用 SSH 从远程驱动器创建一个压缩的映像文件，并把该文件保存到你的本地计算机中：

# ssh [email protected] "dd if=/dev/sda | gzip -1 -" | dd of=backup.gz

你应该经常测试你的归档，确保它们可正常使用。如果它是你创建的启动驱动器，将它粘贴到计算机中，看看它是否能够按预期启动。如果它是普通分区的数据，挂载该分区，确保文件都存在而且可以正常的访问。

使用 dd 擦除磁盘数据

多年以前，我的一个负责政府海外大使馆安全的朋友曾经告诉我，在他当时在任的时候， 政府会给每一个大使馆提供一个官方版的锤子。为什么呢？ 一旦大使馆设施可能被不友善的人员侵占，就会使用这个锤子毁坏所有的硬盘.

为什么要那样做？为什么不是删除数据就好了？你在开玩笑，对吧？所有人都知道从存储设备中删除包含敏感信息的文件实际上并没有真正移除这些数据。除非使用锤子彻底的毁坏这些存储介质，否则，只要有足够的时间和动机, 几乎所有的内容都可以从几乎任何数字存储介质重新获取。

但是，你可以使用 dd 命令让坏人非常难以获得你的旧数据。这个命令需要花费一些时间在 /dev/sda1 分区的每个扇区写入数百万个 0（LCTT 译注：是指 0x0 字节，意即 NUL ，而不是数字 0 ）：

# dd if=/dev/zero of=/dev/sda1

还有更好的方法。通过使用 /dev/urandom 作为源文件，你可以在磁盘上写入随机字符：

# dd if=/dev/urandom of=/dev/sda1

监控 dd 的操作

由于磁盘或磁盘分区的归档可能需要很长的时间，因此你可能需要在命令中添加进度查看器。安装管道查看器（在 Ubuntu 系统上安装命令为 sudo apt install pv），然后把 pv 命令和 dd 命令结合在一起。使用 pv，最终的命令是这样的：

# dd if=/dev/urandom | pv | dd of=/dev/sda1

4,14MB 0:00:05 [ 98kB/s] [      <=>                  ]

想要推迟备份和磁盘管理工作？有了 dd 工具，你不会有太多的借口。它真的非常简单，但是要小心。祝你好运！

via：https://opensource.com/article/18/7/how-use-dd-linux

作者：David Clinton 选题：lujun9972 译者：SunWave 校对：wxy

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

在 GPL v3 许可证颁发 11 周年之际，让我们了解一下它对自由和开源软件的持久贡献。

2017 年，我错过了为 GPL v3（GNU 通用公共许可协议的第三版）发布 10 周年撰写文章的机会。GPL v3 由 自由软件基金会 （ Free Software Foundation ） （FSF）于 2007 年 6 月 29 日正式发布，这一天在技术史上更为人熟知的事件是苹果公司推出了 iPhone 手机。一年之后的现在，我觉得应该对 GPL v3 做一些回顾。对于我来说，许多有关 GPL v3 的有趣内容可以追溯到 11 年之前，我作为积极参与者经历了当时的公共起草过程。

2005 年，经过近十年热衷于自由软件的自我沉浸，但却几乎没有任何开源法律经验可言的我被 Eben Moglen 聘用，加入 软件自由法律中心 （ Software Freedom Law Center ） （SFLC）担任法律顾问。SFLC 当时是 FSF 的外部法律顾问，我的角色被设定为关注 GPL v3 起草过程的初期公共阶段。这个机会把我从以前的并不令我满意的一次职业转变中解救出来。 自由和开源软件 （ Free and Open Source Software ） （FOSS）的法律问题成为我的新专长，我发现这一点很有吸引力，令人满意，并且在智力上有所回报。我在 SFLC 的工作，特别是我在 GPL v3 方面勇闯火线的工作，成为了我的在职培训。

GPL v3 必须被理解为早期 FOSS 时代的产物，其轮廓可能让今天的人难以想象。在 2006 年公共起草过程开始时，Linux 和开源已经不再是早年一些漫不经心的观察者所看到的几乎是同义词的情形了，但两者之间的联系仍然比现在更密切。

Linux 已经对技术行业产生深远影响的反映是，每个人都认为 GPL v2 是主要的开源许可模式。我们看到了开源（和伪开源）商业模式如寒武纪式爆发的最终震荡。一个泡沫化商业炒作包围的开源（对我来说最令人难忘的典型代表是 开源商业会议 （ Open Source Business Conference ）与软件工程专业人士目前对开源开发的接受程度几乎没有相似之处。微软凭借其不断扩大的专利组合以及对 Linux 的竞争性对抗，在 FOSS 社区中普遍被视为一种现实存在的威胁，而 SCO 诉讼已经在 Linux 和 GPL 之间笼罩上了法律风险的阴云，并且没有完全消散。

这种环境必然使得 GPL v3 的起草成为自由软件历史上前所未有的高风险事件。主要的技术公司和顶级律师事务所的律师争先恐后地对该许可协议施加影响，并确信 GPL v3 必将接管并彻底重塑开源业态及所有大量相关的商业投资。

技术社区内存在类似的心态；这在 Linux 内核开发人员于 2006 年 9 月对 GPL v3 的强烈指责中所表达的恐惧里略见一斑。我们这些接近 FSF 的人知道的多一点，但我认为我们假定新的许可协议要么是压倒性的成功，要么是彻底的失败——“成功”意味着将现有的 GPL v2 项目生态系统升级为 GPL v3，尽管也许 Linux 内核会缺席（LCTT 译注：十年过去了，Linux 内核仍旧采用 GPL v2 许可证）。实际的结果是介于两者之间的东西。

我对测量开源许可协议采用程度的尝试没有信心，近年来这种做法通常用于证明 左版 （ Copyleft ） 许可协议失去竞争优势。根据我自己的接近 Linux 和工作于 红帽 （ Red Hat ） 公司的明显有倾向性的经验，表明 GPL v3 作为自 2007 年以来推出项目的可选许可协议，享有适度的受欢迎程度。尽管 2007 年之前存在的大多数 GPL v2 项目以及它们在 2007 年以后的分支，仍然遵循旧许可协议。（GPL v3 的兄弟许可协议 LGPL v3 和 AGPL v3 从未获得过相当程度的普及）大多数现有的 GPL v2 项目（有一些明显的例外，如 Linux 内核和 Busybox）被许可为“GPL v2 或任何更高的版本”。技术界早就决定“GPL v2 或更高版本”是一个政治中立的许可协议选项，它包含了 GPL v2 和 GPL v3。这可以解释为什么 GPL v3 的采用推进得缓慢和有限，特别是在 Linux 社区中。

在 GPL v3 起草过程中，一些人表达了对 Linux 生态系统“ 巴尔干化 （ balkanized ） ”的担忧，无论是因为用户必须了解两个不同的强大左版许可协议的开销，还是因为 GPL v2 / GPL v3 的不兼容。事实证明，这些担忧完全没有根据。在主流服务器和工作站 Linux 堆栈中，这两个许可协议已经和平共存了十年。这其中部分是因为这样的堆栈由强大的左版范畴的单独单元组成（参见我对容器设置中相关问题的讨论）。至于强左版范畴单元内部的不兼容性，在这里，“GPL v2 或更高版本”的普遍性被技术界视为干净利索地解决了理论问题。尽管名义上的“GPL v2 或更高版本”升级为 GPL v3 的情况几乎没有发生过。

我已经说过，我们中间的一些 FOSS 许可协议极客已经提到了假定的左版衰退的问题。早在公共起草过程的开始阶段，GPL v3 已经在批评者那里形成了滥用，并且可以推断，有些人已经在特殊情况下的 GPL v3 不受欢迎与一般意义上的 GPL 或左版失宠之间建立了联系。

我对它的看法有所不同：很大程度上是因为它的复杂性和 巴洛克 （ baroque ） 风格，GPL v3 失去了创建强大的可以广泛地吸引现代个人软件作者和企业许可人的左版许可协议的机会。我相信今天的个人开发者往往更喜欢简短、易懂、简约的许可证，最明显的例子就是 MIT 许可证。

面临开源许可协议选项的一些公司决策者可能很自然地分享这种观点，而其他公司决策者可能认为 GPL v3 的某些部分风险太大（例如专利条款或反锁定要求）或与其商业模式不相容。具有讽刺意味的是，未能吸引这些群体的 GPL v3 的一部分特性是因为有意识地试图使许可协议吸引这些具备相同类型利益的群体。

GPL v3 是如何变得如此巴洛克式的？正如我所说，GPL v3 是较早时期的产物，彼时 FOSS 许可协议被视为项目治理的主要工具。（现在我们倾向于将治理与其他类型的法律或准法律工具联系起来，例如组织非营利组织，围绕项目决策制定规则，行为准则和贡献者协议。）

在其起草过程中，GPL v3 是对 FOSS 许可协议可以作为雄心勃勃的私人监管手段持乐观态度的最高点。对于 GPL v2 来说已经是这样了，但是 GPL v3 通过详细解决一些新的政策问题——软件专利、反规避法律、设备锁定等方式来解决问题。这必然会使 GPL v3 许可协议比 GPL v2 更长、更复杂，因为 FSF 和 SFLC 在第一份 GPL v3 基本原理文件中满怀抱歉地提到了这一点。

但是，起草 GPL v3 过程中的其他一些因素无意中导致许可协议的复杂性增长。代表供应商和商业用户利益的律师从法律和商业角度提供了有用的改进建议，但这些通常采取让措辞简单的条款变成更冗长的形式，在明晰性方面可以说没有明确的改善。对技术社区反馈（通常是识别许可条款的漏洞）的回应也有类似的效果。

GPL v3 起草人也因短期政治危机（2006 年有争议的微软/ Novell 交易）纠缠在一起，导致许可协议的专利部分永久性地增加了新的和不寻常的条件，这在 2007 年之后是毫无用处的, 除了使有良心的专利持有商更难遵守许可证。当然，GPL v3 中的一些复杂性仅仅是为了使合规更容易（特别是对于社区项目开发人员）或者编写 FSF 的解释实践。最后，人们可以对 GPL v3 中使用的语言风格提出质疑，其中大部分语言都具有传统软件许可法律的顽皮模仿或嘲弄；在许多情况下，一种更简单、直接的措辞形式是一种改进。

GPL v3 的复杂性以及在许可协议起草中倾向于简练和简洁的趋势以及明智的许可政策目标，意味着 GPL v3 的实质性文本对后来的 FOSS 法律起草几乎没有直接影响。但是，正如我在 2012 年所惊奇和高兴地看到的那样，MPL 2.0 改编了 GPL v3 的两个部分：GPL v3 终止条款中的 30 天补救和 60 天休眠文本，并保证升级到更高版本许可协议的下游对上游许可人没有新的义务。

GPL v3 补救文本已经产生了重大影响，特别是在过去一年中。随着 FSF 的支持， 软件自由保护组织 （ Software Freedom Conservancy ） 颁布了《 面向社区的 GPL 执行原则 （ Principles of Community-Oriented GPL Enforcement ） 》，该原则要求将 GPL v3 补救机会扩展到 GPL v2 违规行为，Linux 基金会技术顾问委员会发布了一份声明，得到了一百多个 Linux 内核开发人员支持，其中包含了 GPL v3 的补救文本。接下来是以红帽公司为首的一系列企业承诺，将 GPL v3 补救条款扩展到 GPL v2 和 LGPL v2.x 违规，这是一项建议个人开源开发者做出同样承诺的活动。红帽公司的一项声明宣布，从此以后其主导的 GPL v2 和 LGPL v2.x 项目将在项目存储库中直接使用承诺文本。我在最近的博客文章中讨论了这些发展。

关注 GPL v3 的一个持久贡献是改变了对广泛使用的 FOSS 许可协议修订方式的期待。在没有社区评论的参与，也没有努力与主要利益相关者进行磋商的情况下，这些许可协议不能完全进行私下修改。MPL 2.0 以及最近的 EPL 2.0 的起草过程反映了这一新规范。

作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。

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

将用户添加到现有组是 Linux 管理员的常规活动之一。这是一些在大环境中工作的管理员的日常活动。

甚至我会因为业务需求而在我的环境中每天都在进行这样的活动。它是帮助你识别环境中现有组的重要命令之一。

此外，这些命令还可以帮助你识别用户所属的组。所有用户都列在 /etc/passwd 中，组列在 /etc/group 中。

无论我们使用什么命令，都将从这些文件中获取信息。此外，每个命令都有其独特的功能，可帮助用户单独获取所需的信息。

什么是 /etc/passwd？

/etc/passwd 是一个文本文件，其中包含登录 Linux 系统所必需的每个用户信息。它维护有用的用户信息，如用户名、密码、用户 ID、组 ID、用户 ID 信息、家目录和 shell。passwd 每行包含了用户的详细信息，共有如上所述的 7 个字段。

$ grep "daygeek" /etc/passwd
daygeek:x:1000:1000:daygeek,,,:/home/daygeek:/bin/bash

什么是 /etc/group？

/etc/group 是一个文本文件，用于定义用户所属的组。我们可以将多个用户添加到单个组中。它允许用户访问其他用户文件和文件夹，因为 Linux 权限分为三类：用户、组和其他。它维护有关组的有用信息，例如组名、组密码，组 ID（GID）和成员列表。每个都在一个单独的行。组文件每行包含了每个组的详细信息，共有 4 个如上所述字段。

这可以通过使用以下方法来执行。

• groups： 显示一个组的所有成员。
• id： 打印指定用户名的用户和组信息。
• lid： 显示用户的组或组的用户。
• getent： 从 Name Service Switch 库中获取条目。
• grep： 代表“ 全局正则表达式打印 global regular expression print ”，它能打印匹配的模式。

什么是 groups 命令？

groups 命令打印每个给定用户名的主要组和任何补充组的名称。

$ groups daygeek
daygeek : daygeek adm cdrom sudo dip plugdev lpadmin sambashare

如果要检查与当前用户关联的组列表。只需运行 groups 命令，无需带任何用户名。

$ groups
daygeek adm cdrom sudo dip plugdev lpadmin sambashare

什么是 id 命令？

id 代表 “ 身份 identity ”。它打印真实有效的用户和组 ID。打印指定用户或当前用户的用户和组信息。

$ id daygeek
uid=1000(daygeek) gid=1000(daygeek) groups=1000(daygeek),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),118(lpadmin),128(sambashare)

如果要检查与当前用户关联的组列表。只运行 id 命令，无需带任何用户名。

$ id
uid=1000(daygeek) gid=1000(daygeek) groups=1000(daygeek),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),118(lpadmin),128(sambashare)

什么是 lid 命令？

它显示用户的组或组的用户。显示有关包含用户名的组或组名称中包含的用户的信息。此命令需要管理员权限。

$ sudo lid daygeek
 adm(gid=4)
 cdrom(gid=24)
 sudo(gid=27)
 dip(gid=30)
 plugdev(gid=46)
 lpadmin(gid=108)
 daygeek(gid=1000)
 sambashare(gid=124)

什么是 getent 命令？

getent 命令显示 Name Service Switch 库支持的数据库中的条目，它们在 /etc/nsswitch.conf 中配置。

$ getent group | grep daygeek
adm:x:4:syslog,daygeek
cdrom:x:24:daygeek
sudo:x:27:daygeek
dip:x:30:daygeek
plugdev:x:46:daygeek
lpadmin:x:118:daygeek
daygeek:x:1000:
sambashare:x:128:daygeek

如果你只想打印关联的组名称，请在上面的命令中使用 awk。

$ getent group | grep daygeek | awk -F: '{print $1}'
adm
cdrom
sudo
dip
plugdev
lpadmin
daygeek
sambashare

运行以下命令仅打印主群组信息。

$ getent group daygeek
daygeek:x:1000:

什么是 grep 命令？

grep 代表 “ 全局正则表达式打印 global regular expression print ”，它能打印文件匹配的模式。

$ grep "daygeek" /etc/group
adm:x:4:syslog,daygeek
cdrom:x:24:daygeek
sudo:x:27:daygeek
dip:x:30:daygeek
plugdev:x:46:daygeek
lpadmin:x:118:daygeek
daygeek:x:1000:
sambashare:x:128:daygeek

如果你只想打印关联的组名称，请在上面的命令中使用 awk。

$ grep "daygeek" /etc/group | awk -F: '{print $1}'
adm
cdrom
sudo
dip
plugdev
lpadmin
daygeek
sambashare

via: https://www.2daygeek.com/how-to-check-which-groups-a-user-belongs-to-on-linux/

作者：Prakash Subramanian 选题：lujun9972 译者：geekpi 校对：wxy

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

有些人可能会认为 macOS 和 Linux 内核之间存在相似之处，因为它们可以处理类似的命令和类似的软件。有些人甚至认为苹果公司的 macOS 是基于 Linux 的。事实上是，两个内核有着截然不同的历史和特征。今天，我们来看看 macOS 和 Linux 的内核之间的区别。

macOS 内核的历史

我们将从 macOS 内核的历史开始。1985 年，由于与首席执行官 John Sculley 和董事会不和， 史蒂夫·乔布斯 Steve Jobs 离开了苹果公司。然后，他成立了一家名为 NeXT 的新电脑公司。乔布斯希望将一款（带有新操作系统的）新计算机快速推向市场。为了节省时间，NeXT 团队使用了卡耐基梅隆大学的 Mach 内核) 和部分 BSD 代码库来创建 NeXTSTEP 操作系统。

NeXT 从来没有取得过财务上的成功，部分归因于乔布斯花钱的习惯，就像他还在苹果公司一样。与此同时，苹果公司曾多次试图更新其操作系统，甚至与 IBM 合作，但从未成功。1997年，苹果公司以 4.29 亿美元收购了 NeXT。作为交易的一部分，史蒂夫·乔布斯回到了苹果公司，同时 NeXTSTEP 成为了 macOS 和 iOS 的基础。

Linux 内核的历史

与 macOS 内核不同，Linux 的创建并非源于商业尝试。相反，它是由芬兰计算机科学专业学生 林纳斯·托瓦兹 Linus Torvalds 于 1991 年创建的。最初，内核是按照林纳斯自己的计算机的规格编写的，因为他想利用其新的 80386 处理器（的特性）。林纳斯于 1991 年 8 月在 Usenet 上发布了他的新内核代码。很快，他就收到了来自世界各地的代码和功能建议。次年，Orest Zborowski 将 X Window 系统移植到 Linux，使其能够支持图形用户界面。

在过去的 27 年中，Linux 已经慢慢成长并增加了不少功能。这不再是一个学生的小型项目。现在它运行在世界上大多数的计算设备和超级计算机上。不错！

macOS 内核的特性

macOS 内核被官方称为 XNU。这个首字母缩写词代表“XNU is Not Unix”。根据 苹果公司的 Github 页面，XNU 是“将卡耐基梅隆大学开发的 Mach 内核和 FreeBSD 组件整合而成的混合内核，加上用于编写驱动程序的 C++ API”。代码的 BSD 子系统部分“在微内核系统中通常实现为用户空间的服务”。Mach 部分负责底层工作，例如多任务、内存保护、虚拟内存管理、内核调试支持和控制台 I/O。

Linux 内核的特性

虽然 macOS 内核结合了微内核（Mach）和宏内核（BSD）的特性，但 Linux 只是一个宏内核。宏内核负责管理 CPU、内存、进程间通信、设备驱动程序、文件系统和系统服务调用（ LCTT 译注：原文为 system server calls，但结合 Linux 内核的构成，译者认为这里翻译成系统服务调用更合适，即 system service calls）。

用一句话总结 Linux 和 Mac 的区别

macOS 内核（XNU）比 Linux 历史更悠久，并且基于两个更古老一些的代码库的结合；另一方面，Linux 新一些，是从头开始编写的，并且在更多设备上使用。

如果您发现这篇文章很有趣，请花一点时间在社交媒体，黑客新闻或 Reddit 上分享。

via: https://itsfoss.com/mac-linux-difference/

作者：John Paul 选题：lujun9972 译者：stephenxs 校对：wxy

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

你也许用过调速器检查过你的代码，但你知道它们是如何做到的吗？

调试器是大多数（即使不是每个）开发人员在软件工程职业生涯中至少使用过一次的那些软件之一，但是你们中有多少人知道它们到底是如何工作的？我在悉尼 linux.conf.au 2018 的演讲中，将讨论从头开始编写调试器……使用 Rust！

在本文中，术语 调试器 debugger 和 跟踪器 tracer 可以互换。 “ 被跟踪者 Tracee ”是指正在被跟踪器跟踪的进程。

ptrace 系统调用

大多数调试器严重依赖称为 ptrace(2) 的系统调用，其原型如下：

long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data);

这是一个可以操纵进程几乎所有方面的系统调用；但是，在调试器可以连接到一个进程之前，“被跟踪者”必须以请求 PTRACE_TRACEME 调用 ptrace。这告诉 Linux，父进程通过 ptrace 连接到这个进程是合法的。但是……我们如何强制一个进程调用 ptrace？很简单！fork/execve 提供了在 fork 之后但在被跟踪者真正开始使用 execve 之前调用 ptrace 的简单方法。很方便地，fork 还会返回被跟踪者的 pid，这是后面使用 ptrace 所必需的。

现在被跟踪者可以被调试器追踪，重要的变化发生了：

• 每当一个信号被传送到被跟踪者时，它就会停止，并且一个可以被 wait 系列的系统调用捕获的等待事件被传送给跟踪器。
• 每个 execve 系统调用都会导致 SIGTRAP 被传递给被跟踪者。（与之前的项目相结合，这意味着被跟踪者在一个 execve 完全发生之前停止。）

这意味着，一旦我们发出 PTRACE_TRACEME 请求并调用 execve 系统调用来实际在被跟踪者（进程上下文）中启动程序时，被跟踪者将立即停止，因为 execve 会传递一个 SIGTRAP，并且会被跟踪器中的等待事件捕获。我们如何继续？正如人们所期望的那样，ptrace 有大量的请求可以用来告诉被跟踪者可以继续：

• PTRACE_CONT：这是最简单的。 被跟踪者运行，直到它接收到一个信号，此时等待事件被传递给跟踪器。这是最常见的实现真实世界调试器的“继续直至断点”和“永远继续”选项的方式。断点将在下面介绍。
• PTRACE_SYSCALL：与 PTRACE_CONT 非常相似，但在进入系统调用之前以及在系统调用返回到用户空间之前停止。它可以与其他请求（我们将在本文后面介绍）结合使用来监视和修改系统调用的参数或返回值。系统调用追踪程序 strace 很大程度上使用这个请求来获知进程发起了哪些系统调用。
• PTRACE_SINGLESTEP：这个很好理解。如果您之前使用过调试器（你会知道），此请求会执行下一条指令，然后立即停止。

我们可以通过各种各样的请求停止进程，但我们如何获得被调试者的状态？进程的状态大多是通过其寄存器捕获的，所以当然 ptrace 有一个请求来获得（或修改）寄存器：

• PTRACE_GETREGS：这个请求将给出被跟踪者刚刚被停止时的寄存器的状态。
• PTRACE_SETREGS：如果跟踪器之前通过调用 PTRACE_GETREGS 得到了寄存器的值，它可以在参数结构中修改相应寄存器的值，并使用 PTRACE_SETREGS 将寄存器设为新值。
• PTRACE_PEEKUSER 和 PTRACE_POKEUSER：这些允许从被跟踪者的 USER 区读取信息，这里保存了寄存器和其他有用的信息。 这可以用来修改单一寄存器，而避免使用更重的 PTRACE_{GET,SET}REGS 请求。

在调试器仅仅修改寄存器是不够的。调试器有时需要读取一部分内存，甚至对其进行修改。GDB 可以使用 print 得到一个内存位置或变量的值。ptrace 通过下面的方法实现这个功能：

• PTRACE_PEEKTEXT 和 PTRACE_POKETEXT：这些允许读取和写入被跟踪者地址空间中的一个字。当然，使用这个功能时被跟踪者要被暂停。

真实世界的调试器也有类似断点和观察点的功能。 在接下来的部分中，我将深入体系结构对调试器支持的细节。为了清晰和简洁，本文将只考虑 x86。

体系结构的支持

ptrace 很酷，但它是如何工作？ 在前面的部分中，我们已经看到 ptrace 跟信号有很大关系：SIGTRAP 可以在单步跟踪、execve 之前以及系统调用前后被传送。信号可以通过一些方式产生，但我们将研究两个具体的例子，以展示信号可以被调试器用来在给定的位置停止程序（有效地创建一个断点！）：

• 未定义的指令：当一个进程尝试执行一个未定义的指令，CPU 将产生一个异常。此异常通过 CPU 中断处理，内核中相应的中断处理程序被调用。这将导致一个 SIGILL 信号被发送给进程。 这依次导致进程被停止，跟踪器通过一个等待事件被通知，然后它可以决定后面做什么。在 x86 上，指令 ud2 被确保始终是未定义的。
• 调试中断：前面的方法的问题是，ud2 指令需要占用两个字节的机器码。存在一条特殊的单字节指令能够触发一个中断，它是 int $3，机器码是 0xCC。 当该中断发出时，内核向进程发送一个 SIGTRAP，如前所述，跟踪器被通知。

这很好，但如何我们才能胁迫被跟踪者执行这些指令？ 这很简单：利用 ptrace 的 PTRACE_POKETEXT 请求，它可以覆盖内存中的一个字。 调试器将使用 PTRACE_PEEKTEXT 读取该位置原来的值并替换为 0xCC ，然后在其内部状态中记录该处原来的值，以及它是一个断点的事实。 下次被跟踪者执行到该位置时，它将被通过 SIGTRAP 信号自动停止。 然后调试器的最终用户可以决定如何继续（例如，检查寄存器）。

好吧，我们已经讲过了断点，那观察点呢？ 当一个特定的内存位置被读或写，调试器如何停止程序？ 当然你不可能为了能够读或写内存而去把每一个指令都覆盖为 int $3。有一组调试寄存器为了更有效的满足这个目的而被设计出来：

• DR0 到 DR3：这些寄存器中的每个都包含一个地址（内存位置），调试器因为某种原因希望被跟踪者在那些地址那里停止。 其原因以掩码方式被设定在 DR7 寄存器中。
• DR4 和 DR5：这些分别是 DR6 和 DR7 过时的别名。
• DR6：调试状态。包含有关 DR0 到 DR3 中的哪个寄存器导致调试异常被引发的信息。这被 Linux 用来计算与 SIGTRAP 信号一起传递给被跟踪者的信息。
• DR7：调试控制。通过使用这些寄存器中的位，调试器可以控制如何解释 DR0 至 DR3 中指定的地址。位掩码控制监视点的尺寸（监视1、2、4 或 8 个字节）以及是否在执行、读取、写入时引发异常，或在读取或写入时引发异常。

由于调试寄存器是进程的 USER 区域的一部分，调试器可以使用 PTRACE_POKEUSER 将值写入调试寄存器。调试寄存器只与特定进程相关，因此在进程抢占并重新获得 CPU 控制权之前，调试寄存器会被恢复。

冰山一角

我们已经浏览了一个调试器的“冰山”：我们已经介绍了 ptrace，了解了它的一些功能，然后我们看到了 ptrace 是如何实现的。 ptrace 的某些部分可以用软件实现，但其它部分必须用硬件来实现，否则实现代价会非常高甚至无法实现。

当然有很多我们没有涉及。例如“调试器如何知道变量在内存中的位置？”等问题由于空间和时间限制而尚未解答，但我希望你从本文中学到了一些东西；如果它激起你的兴趣，网上有足够的资源可以了解更多。

想要了解更多，请查看 linux.conf.au 中 Levente Kurusa 的演讲 Let's Write a Debugger!，于一月 22-26 日在悉尼举办。

via: https://opensource.com/article/18/1/how-debuggers-really-work

作者：Levente Kurusa 译者：stephenxs 校对：wxy

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