document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-06 23:50:16 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
Xingyu Wang 2020-04-23 11:46:49 +08:00
commit 9a95b8f363
7 changed files with 404 additions and 297 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
translated/tech/20200408 Create web tutorials with Reveal.js and Git.md → published/20200408 Create web tutorials with Reveal.js and Git.md
View File

@ -1,8 +1,8 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: reviewer: (wxy)
[#]: publisher: (wxy)
[#]: url: (https://linux.cn/article-12139-1.html)
[#]: subject: (Create web tutorials with Reveal.js and Git)
[#]: via: (https://opensource.com/article/20/4/create-web-tutorial-git)
[#]: author: (Eric D. Schabell https://opensource.com/users/eschabell)
@ -10,9 +10,9 @@
使用 Reveal.js 和 Git 创建网页教程
======
> 通过这个简单的工作流程创建的研讨会幻灯片，可以在任何浏览器、设备和平台上一致地查看。
> 通过这个简单的工作流程创建的研讨会幻灯片，可以在任何浏览器、设备和平台上获得一致的查看效果。
![Person reading a book and digital copy][1]
![](https://img.linux.net.cn/data/attachment/album/202004/23/094800ohkpbjd3zbj0dj0d.jpg)
无论你是学习者还是教师，你可能都会认识到采用幻灯片放映来传播知识的在线<ruby>研讨会<rt>workshop</rt></ruby>的价值。如果你曾经偶然看到过这样一个逐页、逐章设置的井井有条的教程，你可能会想知道创建这样的一个网站有多难。
@ -20,9 +20,9 @@
### 介绍
当我开始将学习内容放到网上置时，体验并不是很好。我想要的是一种可重复的、一致的、易于维护的东西，因为我的内容会随着我的教学技术而进步。
当我开始将学习内容放到网上置时，体验并不是很好。我想要的是一种可重复的、一致的、易于维护的东西，因为我的内容会随着我教学的技术发展而变化。
我尝试了许多交付模型，从 [Asciidoctor][2] 这样的低级代码生成器到在单个 PDF 文件中放置教程。全都不能让我满意。当我举办现场的在座研讨会时，我喜欢使用幻灯片放映，因此我想知道我是否可以为自己的在线的，自定进度的研讨会体验做同样的事情。
我尝试了许多交付模型，从 [Asciidoctor][2] 这样的低级代码生成器到在单个 PDF 文件中放置教程。全都不能让我满意。当我举办现场的在座研讨会时，我喜欢使用幻灯片放映，因此我想知道我是否可以为我自己的在线的，自定进度的研讨会体验做同样的事情。
经过一番挖掘，我为创建无痛的研讨会网站打下了基础。当时我已经在使用一个演示文稿生成框架，这对我来说是很有帮助的，因为这个框架可以产生对网站友好的格式（HTML）。
@ -33,13 +33,13 @@
* 研讨会的想法（这是你的问题，我帮不了你）
* 用于研讨会幻灯片的 Reveal.js
* GitLab 项目仓库
* 你最喜欢的 HTML 代码编辑器
* 你常用的 HTML 代码编辑器
* Web 浏览器
* 在你的机器上安装好 Git
如果这个列表看起来令人望而生畏，那么有一个快速入门的方法，不需要把所有的东西一个个都拉到一起。你可以用我的模板项目来给你提供幻灯片和项目设置的入门教程。
本文假设你熟悉 Git 和托管在 Git 平台（如 GitLab）上的项目。如果你需要指导或教程，请查看我们的[Git 入门系列][3]。
本文假设你熟悉 Git 和在 Git 平台（如 GitLab）上托管项目。如果你需要指导或教程，请查看我们的[Git 入门系列][3]。
首先，将模板项目克隆到本地机器上。
@ -49,7 +49,7 @@ $ git clone https://gitlab.com/eschabell/beginners-guide-automated-workshops.git
为此设置一个新的 GitLab 项目，导入模板项目作为初始导入。
研讨会网站有一些重要的文件。在**根目录**下，你会发现一个名为 `.gitlab-ci.yml` 的文件，当你向主分支提交修改时（即合并拉取请求到 `master` 分支），这个文件会作为触发器。它可以触发将 `slides` 目录的全部内容复制到 GitLab 项目的 `website` 文件夹中。
研讨会网站有一些重要的文件。在**根目录**下，你会发现一个名为 `.gitlab-ci.yml` 的文件，当你向主分支提交修改时（即将拉取请求合并到 `master` 分支），这个文件会作为触发器。它可以触发将 `slides` 目录的全部内容复制到 GitLab 项目的 `website` 文件夹中。
我把它托管在我的 GitLab 账户中，名为 `beginners-guide-automated-workshops`。当它部署完毕后，你可以在浏览器中通过导航到下列地址查看 `slides` 目录的内容:
@ -79,7 +79,7 @@ https://[YOUR_USERNAME].gitlab.io/[YOUR_PROJECT_NAME]
* `images` 目录
* `index.html`文件
在你喜欢的 HTML/CSS 编辑器中打开每一个文件，然后进行下面描述的修改。你用哪个编辑器并不重要，我更喜欢 [RubyMine IDE][5]，因为它能在本地浏览器中提供页面预览。这对我在将内容推送到研讨会网站之前测试内容时很有帮助。
在你常用的 HTML/CSS 编辑器中打开每一个文件，然后进行下面描述的修改。你用哪个编辑器并不重要，我更喜欢 [RubyMine IDE][5]，因为它能在本地浏览器中提供页面预览。这对我在将内容推送到研讨会网站之前测试内容时很有帮助。
#### default.css 文件
@ -91,7 +91,7 @@ https://[YOUR_USERNAME].gitlab.io/[YOUR_PROJECT_NAME]
font-family: "Red Hat Display", "Overpass", san-serif;
```
如果你使用的是非标准字体类型，则必须在以下行中将其导入（与 Overpass 字体类型相同）：
如果你使用的是非标准字体类型，则必须在以下行中将其导入（Overpass 字体类型就是这样做的）：
```
@import url('SOME_URL');
@ -105,7 +105,7 @@ background: url("…/…/images/backgrounds/basic.png")
要设置一个默认背景，只需将这一行指向你要使用的图片。
#### images 目录
#### images 目录
顾名思义，`images` 目录是用来存储你想在研讨会幻灯片上使用的图片。例如，我通常会把展示研讨会主题进展的截图放在我的个人幻灯片上。
@ -131,7 +131,6 @@ background: url("…/…/images/backgrounds/basic.png")
现在继续到 `body` 部分。你会注意到它被分成了许多 `section` 标签。`body` 的开头包含了一个注释，说明你正在为每个标有 `section` 的打开和关闭的标签创建幻灯片。
```
<body>
<div class="reveal">
@ -156,9 +155,9 @@ background: url("…/…/images/backgrounds/basic.png")
</section>
```
这张幻灯片有两个区域，用 `div` 标签划分。用空格隔开了标题和作者。
这张幻灯片有两个区域，用 `div` 标签分隔。用空格隔开了标题和作者。
如果你有一定的 HTML 使用知识，可以尝试各种东西来开发你的研讨会。你使用浏览器预览结果的时候真的很方便。有些 IDE 提供了本地查看修改，但你也可以打开 `index.html` 文件查看你的修改，然后再推送到资源库中。
如果你有一定的 HTML 使用知识，可以尝试各种东西来开发你的研讨会。使用浏览器预览结果的时候真的很方便。有些 IDE 提供了本地查看修改，但你也可以打开 `index.html` 文件查看你的修改，然后再推送到资源库中。
一旦你对你的研讨会感到满意，推送你的修改，然后等待它们通过持续集成管道。它们将像模板项目一样被托管在 <https://eschabell.gitlab.io/beginners-guide-automated-workshops>。
@ -166,7 +165,7 @@ background: url("…/…/images/backgrounds/basic.png")
要了解更多关于这个工作流程可以做什么，请查看下面的示例研讨会和托管了研讨会集合的网站。所有这些都是基于本文中描述的工作流程。
研讨会的例子：
研讨会例子：
* [Red Hat Process Automation Manage workshop][6]
* [JBoss Travel Agency BPM Suite online workshop][7]
@ -177,7 +176,7 @@ background: url("…/…/images/backgrounds/basic.png")
* [Application development in the cloud workshop][9]
* [Portfolio architecture: Workshops for creating impactful architectural diagrams][10]
我希望这本新手指南和模板研讨会项目能让你看到，在开发和维护工作室网站的过程中，可以轻松、无痛地完成。我也希望这个工作流程能让你的研讨会受众几乎在任何设备上都能完全访问你的内容，这样他们就能从你分享的知识中学习到你的知识。
我希望这本新手指南和模板研讨会项目能让你看到，在开发和维护研讨会网站的过程中，可以轻松、无痛地完成。我也希望这个工作流程能让你的研讨会受众几乎在任何设备上都能完全访问你的内容，这样他们就能从你分享的知识中学习到你的知识。
--------------------------------------------------------------------------------
@ -186,7 +185,7 @@ via: https://opensource.com/article/20/4/create-web-tutorial-git
作者：[Eric D. Schabell][a]
选题：[lujun9972][b]
译者：[wxy](https://github.com/wxy)
校对：[校对者ID](https://github.com/校对者ID)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

98
sources/tech/20190712 What is Silverblue.md
View File

@ -1,98 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (What is Silverblue?)
[#]: via: (https://fedoramagazine.org/what-is-silverblue/)
[#]: author: (Tomáš Popela https://fedoramagazine.org/author/tpopela/)
What is Silverblue?
======
![][1]
Fedora Silverblue is becoming more and more popular inside and outside the Fedora world. So based on feedback from the community, here are answers to some interesting questions about the project. If you do have any other Silverblue related questions, please leave it in the comments section and we will try to answer them in a future article.
### What is Silverblue?
Silverblue is a codename for the new generation of the desktop operating system, previously known as Atomic Workstation. The operating system is delivered in images that are created by utilizing the _[rpm-ostree][2]_ [project][2]. The main benefits of the system are speed, security, atomic updates and immutability.
### What does “Silverblue” actually mean?
“Team Silverblue” or “Silverblue” in short doesn’t have any hidden meaning. It was chosen after roughly two months when the project, previously known as Atomic Workstation was rebranded. There were over 150 words or word combinations reviewed in the process. In the end _Silverblue_ was chosen because it had an available domain as well as the social network accounts. One could think of it as a new take on Fedora’s blue branding, and could be used in phrases like “Go, Team Silverblue!” or “Want to join the team and improve Silverblue?”.
### What is ostree?
[OSTree or libostree is a project][3] that combines a “git-like” model for committing and downloading bootable filesystem trees, together with a layer to deploy them and manage the bootloader configuration. OSTree is used by rpm-ostree, a hybrid package/image based system that Silverblue uses. It atomically replicates a base OS and allows the user to “layer” the traditional RPM on top of the base OS if needed.
### Why use Silverblue?
Because it allows you to concentrate on your work and not on the operating system you’re running. It’s more robust as the updates of the system are atomic. The only thing you need to do is to restart into the new image. Also, if there’s anything wrong with the currently booted image, you can easily reboot/rollback to the previous working one, if available. If it isn’t, you can download and boot any other image that was generated in the past, using the _ostree_ command.
Another advantage is the possibility of an easy switch between branches (or, in an old context, Fedora releases). You can easily try the _[Rawhide][4]_ or _[updates-testing][5]_ branch and then return back to the one that contains the current stable release. Also, you should consider Silverblue if you want to try something new and unusual.
### What are the benefits of an immutable OS?
One of the main benefits is security. The base operating system is mounted as read-only, and thus cannot be modified by malicious software. The only way to alter the system is through the _rpm-ostree_ utility.
Another benefit is robustness. It’s nearly impossible for a regular user to get the OS to the state when it doesn’t boot or doesn’t work properly after accidentally or unintentionally removing some system library. Try to think about these kind of experiences from your past, and imagine how Silverblue could help you there.
### How does one manage applications and packages in Silverblue?
For graphical user interface applications, [Flatpak][6] is recommended, if the application is available as a flatpak. Users can choose between Flatpaks from either Fedora and built from Fedora packages and in Fedora-owned infrastructure, or Flathub that currently has a wider offering. Users can install them easily through GNOME Software, which already supports Fedora Silverblue.
One of the first things users find out is there is no _dnf_ preinstalled in the OS. The main reason is that it wouldn’t work on Silverblue — and part of its functionality was replaced by the _rpm-ostree_ command. Users can overlay the traditional packages by using the _rpm-ostree install PACKAGE_. But it should only be used when there is no other way. This is because when the new system images are pulled from the repository, the system image must be rebuilt every time it is altered to accommodate the layered packages, or packages that were removed from the base OS or replaced with a different version.
Fedora Silverblue comes with the default set of GUI applications that are part of the base OS. The team is working on porting them to Flatpaks so they can be distributed that way. As a benefit, the base OS will become smaller and easier to maintain and test, and users can modify their default installation more easily. If you want to look at how it’s done or help, take a look at the official [documentation][7].
### What is Toolbox?
[_Toolbox_][8] is a project to make containers easily consumable for regular users. It does that by using _podman_’s rootless containers. _Toolbox_ lets you easily and quickly create a container with a regular Fedora installation that you can play with or develop on, separated from your OS.
### Is there any Silverblue roadmap?
Formally there isn’t any, as we’re focusing on problems we discover during our testing and from community feedback. We’re currently using Fedora’s [Taiga][9] to do our planning.
### What’s the release life cycle of the Silverblue?
It’s the same as regular Fedora Workstation. A new release comes every 6 months and is supported for 13 months. The team plans to release updates for the OS bi-weekly (or longer) instead of daily as they currently do. That way the updates can be more thoroughly tested by QA and community volunteers before they are sent to the rest of the users.
### What is the future of the immutable OS?
From our point of view the future of the desktop involves the immutable OS. It’s safest for the user, and Android, ChromeOS, and the last macOS Catalina all use this method under the hood. For the Linux desktop there are still problems with some third party software that expects to write to the OS. HP printer drivers are a good example.
Another issue is how parts of the system are distributed and installed. Fonts are a good example. Currently in Fedora they’re distributed in RPM packages. If you want to use them, you have to overlay them and then restart to the newly created image that contains them.
### What is the future of standard Workstation?
There is a possibility that the Silverblue will replace the regular Workstation. But there’s still a long way to go for Silverblue to provide the same functionality and user experience as the Workstation. In the meantime both desktop offerings will be delivered at the same time.
### How does Atomic Workstation or Fedora CoreOS relate to any of this?
Atomic Workstation was the name of the project before it was renamed to Fedora Silverblue.
Fedora CoreOS is a different, but similar project. It shares some fundamental technologies with Silverblue, such as _rpm-ostree_, _toolbox_ and others. Nevertheless, CoreOS is a more minimal, container-focused and automatically updating OS.
--------------------------------------------------------------------------------
via: https://fedoramagazine.org/what-is-silverblue/
作者：[Tomáš Popela][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://fedoramagazine.org/author/tpopela/
[b]: https://github.com/lujun9972
[1]: https://fedoramagazine.org/wp-content/uploads/2019/07/what-is-fedora-silverblue-816x345.jpg
[2]: https://rpm-ostree.readthedocs.io/en/latest/
[3]: https://ostree.readthedocs.io/en/latest/
[4]: https://fedoraproject.org/wiki/Releases/Rawhide
[5]: https://fedoraproject.org/wiki/QA:Updates_Testing
[6]: https://flatpak.org/
[7]: https://docs.fedoraproject.org/en-US/flatpak/tutorial/
[8]: https://github.com/debarshiray/toolbox
[9]: https://teams.fedoraproject.org/project/silverblue/

179
sources/tech/20200416 How to package Python applications for Linux.md
View File

@ -1,179 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How to package Python applications for Linux)
[#]: via: (https://opensource.com/article/20/4/package-python-applications-linux)
[#]: author: (Moshe Zadka https://opensource.com/users/moshez)
How to package Python applications for Linux
======
Learn how to use dh_virtualenv to make your Python applications
installable as .deb packages.
![Python in a tree][1]
One way to make Python applications installable on Debian-based operating systems (such as Debian or [Elementary OS][2]) is by using the [dh_virtualenv][3] tool. It builds a **.deb** package that wraps a Python virtual environment around an application and deploys it upon installing.
In this article, I will explain how to use it with the example of building a package containing the [HTTPie][4] tool to test HTTP APIs from the command line without having to activate a virtual environment.
### Packaging with dh_virtualenv
First, you need to install the tools that dh_virtualenv needs. dh_virtualenv's [documentation][5] provides all of the installation options. On my Debian-based system, I entered:
```
`apt-get install dh-virtualenv devscripts`
```
While the [devscripts][6] package is not required, it will simplify doing the subsequent operations.
Now, create a directory to keep the sources. Since this is a local, unofficial, packaging of HTTPie, I called it **myhttp**. Next, let's create some files inside **myhttp** to provide metadata to the Debian build system.
First, create the **debian/control** file:
```
Source: myhttp
Section: python
Priority: extra
Maintainer: Jan Doe &lt;[jandoe@example.org][7]&gt;
Build-Depends: debhelper (&gt;= 9), python3.7, dh-virtualenv (&gt;= 0.8)
Standards-Version: 3.9.5
Package: myhttp
Architecture: any
Pre-Depends: dpkg (&gt;= 1.16.1), python3.7, ${misc:Pre-Depends}
Depends: ${misc:Depends}
Description: http client
 Useful for doing stuff
```
So what is all this information about? As the [Debian documentation][8] puts it:
> "Lines 1–7 are the control information for the source package. Lines 9–13 are the control information for the binary package."
Here's my take:
* the **section** value is mostly meaningless for our case, but needs to be there. It's meaningful to provide information to the guided UI installer, which is not relevant for this package.
* The extra **Priority** value is the right priority for 3rd party packages like this one.
* It is highly recommended to put real contact details in the **Maintainer** field. It does not have to be your personal e-mail, though -- "Infrastructure Team &lt;[infra-team-list@company.example.com][9]&gt;", for example, if the package is maintained by the team and you would like issues to be sent to the team's mail alias.
* The **build-depends** field indicates that you need debhelper, python, and dh-virtualenv to build the package: the package build process will make sure those dependencies are installed at package build time.
* The **standards version** is mostly for human consumption. It indicates which guide you are following. This guide is based on the official documentation of dh-virtualenv, which is based on the 3.9.5 guide from Debian. It is almost always the best choice to name the binary package and the source package the same.
* The **Architecture** field should be **Any** because a virtual environment might include some architecture-specific files: otherwise, the field would be better chosen as **all**.
* Keep the **pre-depends** list as-is: pre-depends is a pretty strict form of dependencies, and it is rare that you need anything more than the minimum suggested here. The dependencies are usually calculated accurately by the build system, so there is no reason to specify them manually.
* If your package is mostly for internal use, then the **Description** might only specify minimal information and a link to the company wiki; otherwise, more details might be useful.
Then create the **debian/compat** file, which [exists mostly for historical purposes][10]:
```
`$ echo "9" > debian/compat`
```
Next, create the changelog to tell package users what has changed since the last release. The easiest way is to use **dch --create** to create a template and then fill in the values.
Filled in, it looks like:
```
myhttp (2.0.0-1) stable; urgency=medium
  * Initial release.
 -- Jan Doe &lt;[jandoe@example.org][7]&gt;  Fri, 27 Mar 2020 01:09:22 +0000
```
Now you need to tell the tool to install HTTPie, but which version?
Create a **requirements.in** file that has loose versions:
```
`httpie`
```
In general, the loose requirements file will only contain direct dependencies of your project and will specify minimum versions if needed. It is not always necessary to specify the minimum versions: the tools are usually biased towards tightening the dependencies towards "latest version possible". In the case where your Debian package corresponds to one internal Python package, a common case in internal applications, the loose requirements file will look similar: just one line with the name of the package.
Then use **pip-compile** (which is available by installing the PyPI package **pip-tools**):
```
`$ pip-compile requirements.in > requirements.txt`
```
This will produce a strict dependency file called **requirements.txt**:
```
#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile requirements.in
#
certifi==2019.11.28       # via requests
chardet==3.0.4            # via requests
httpie==2.0.0             # via -r requirements.in
idna==2.9                 # via requests
pygments==2.6.1           # via httpie
requests==2.23.0          # via httpie
urllib3==1.25.8           # via requests
```
Finally, write a **debian/rules** file for creating the package. Since dh_virtualenv does all the hard work, the rules file is simple:
```
#!/usr/bin/make -f
%:
        dh $@ --with python-virtualenv --python /usr/bin/python3.7
```
Be sure to specify the Python interpreter. By default, it will use the interpreter in **/usr/bin/python**, which is Python 2, but you should use a [supported version of Python][11].
The writing is finished; all that's left is to build the package:
```
`$ debuild -b -us -uc`
```
This will produce a file in the parent directory with a name like **myhttp_2.0.0-1_amd64.deb**. This file can be installed on any compatible operating system.
In general, it's best to build Debian packages that are intended for a specific platform, such as Debian 10.0, on the same platform.
You can store this Debian package in a repository and install it on all relevant systems with, for example, [Ansible][12].
### Conclusion
Packaging applications for Debian-based operating systems is a multi-step process. Using dh_virtualenv will make the process straightforward.
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/4/package-python-applications-linux
作者：[Moshe Zadka][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/moshez
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/life-python.jpg?itok=F2PYP2wT (Python in a tree)
[2]: https://opensource.com/article/19/12/pantheon-linux-desktop
[3]: https://dh-virtualenv.readthedocs.io/en/latest/
[4]: https://opensource.com/article/19/8/getting-started-httpie
[5]: https://dh-virtualenv.readthedocs.io/en/1.1/tutorial.html
[6]: http://man.he.net/man1/devscripts
[7]: mailto:jandoe@example.org
[8]: https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control
[9]: mailto:infra-team-list@company.example.com
[10]: https://www.debian.org/doc/manuals/maint-guide/dother.en.html#compat
[11]: https://opensource.com/article/19/11/end-of-life-python-2
[12]: https://opensource.com/resources/what-ansible

2
sources/tech/20200422 How to Check the Available Network Interfaces, Associated IP Addresses, MAC Addresses, and Interface Speed on Linux.md
View File

@ -1,5 +1,5 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )

110
sources/tech/20200423 Difference Between YUM and RPM Package Manager.md Normal file
View File

@ -0,0 +1,110 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Difference Between YUM and RPM Package Manager)
[#]: via: (https://www.2daygeek.com/comparison-difference-between-yum-vs-rpm/)
[#]: author: (Magesh Maruthamuthu https://www.2daygeek.com/author/magesh/)
Difference Between YUM and RPM Package Manager
======
Package managers play a key role in the Linux system.
It allows you to install, update, view, search and delete software packages to suit your needs.
Each of the distributions has their own set of package managers and use them based on your Linux distributions.
RPM is one of the oldest traditional package managers, designed to work on Red Hat-based systems such as Red Hat Enterprise Linux (RHEL), CentOS, Fedora and openSUSE (which is based on suse Enterprise Linux).
But when it comes to dependency resolution and package update (full system update/upgrade), there is an prominent limitation for RPM package manager.
If you want to know the **[difference between yum and dnf package manager][1]** go to the following article.
This means that yum can download and install all required dependencies automatically, but rpm will tell you to install a list of dependencies, and then you have to manually install them.
This is practically impossible and time consuming when you want to install a group of packages using the **[rpm command][2]**.
That’s where the **[YUM Package Manager][3]** comes in handy and solve both problems.
### What’s RPM?
RPM refers to RPM Package Manager (formerly known as Red Hat Package Manager) is a powerful, command-line package management tool developed for the Red Hat operating system.
It is now used as a core component in many Linux distributions such as Centos, Fedora, Oracle Linux, openSUSE and Mageia.
RPM Package Manager allows you to install, upgrade, delete, query and verify packages on RPM-based Linux systems.
RPM files comes with the `.rpm` extension. The RPM package consists of an archive file, that contains libraries and dependencies for a specific package, that do not conflict with other packages installed on your system.
There are many front-end tools available on Linux to install the RPM package that make the installation process more efficiently compared to the RPM tool, especially for handling dependencies.
If you want to know more about the front-end package manager of Linux distributions, go to the link below.
* **[List of Front-ent Command-line Package Manager for Linux][4]**
If you would like GUI package manager for Linux, go to the link below.
* **[List of GUI Package Manager for Linux][5]**
### What’s YUM?
Yum is a free and open-source command-line package-management application for Linux operating systems that uses the RPM Package Manager.
Yum is a front-end tool for rpm that automatically solves dependencies for packages.
It installs RPM software packages from distribution official repositories and other third-party repositories.
Yum allows you to install, update, search and remove packages from your system.
If you want to keep your system up-to-date, you can enable automatic updates via yum-cron.
Also, it allows you to exclude a package or packages from the yum update if you need to.
Yum is installed by default and you do not need to install it.
S.No | RPM | YUM
---|---|---
1 | Red Hat introduced RPM in 1997. | Yellowdog UPdater (YUP) was developed in 1999-2001 and YUM replaced the original YUP utility in 2003.
2 | RPM stands for RPM Package manager (formally known as Red Hat package manager) | YUM stands for Yellowdog Updater Modified.
3 | The RPM File Naming Convention is as follows.
httpd-2.4.6-92.el7.x86_64.rpm
httpd - Name of the actual package
2.4.6 - Version of package release
92 - Subversion of package release
el7 - Red Hat Version
x86_64 - Hardware architecture
rpm - File extension | It uses the rpm database in the backend.
4 | It doesn't resolve dependencies, you must install them manually. | It automatically resolves dependencies and install them simultaneously (any package will be installed with its dependencies).
5 | This allows you to install multiple versions of the package at once | This does not allow and shows that the package is already installed.
6 | When installing a package using the RPM command you must provide the exact location of the ".rpm" package. | You can install any package available in the repository, but you only need to know the package name.
7 | RPM is not dependent on YUM | It is a frontend tool that uses the RPM package manager on the backend to manage packages.
8 | It is difficult to manage RPM in terms of package installation | YUM is the easiest way to manage RPM packages.
9 | RPM doesn't allow you to upgrade the entire system to the latest available version | YUM allows you to upgrade your system to the latest available version (minor version upgrade, for example, 7.0 to 7.x)
10 | RPM doesn't allow you to automatically update/upgrade packages installed on your system | YUM allows you to automatically update/upgrade the updates available on your system.
11 | It doesn't use the online repository to perform any actions. | It relies entirely on the online repository to do all the work.
12 | RPM is a package format and it is a low-level package manager that does basic things. | This is a top-level front-end package manager that can do everything you need.
--------------------------------------------------------------------------------
via: https://www.2daygeek.com/comparison-difference-between-yum-vs-rpm/
作者：[Magesh Maruthamuthu][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://www.2daygeek.com/author/magesh/
[b]: https://github.com/lujun9972
[1]: https://www.2daygeek.com/comparison-difference-between-dnf-vs-yum/
[2]: https://www.2daygeek.com/linux-rpm-command-examples-manage-packages-fedora-centos-rhel-systems/
[3]: https://www.2daygeek.com/linux-yum-command-examples-manage-packages-rhel-centos-systems/
[4]: https://www.2daygeek.com/list-of-command-line-package-manager-for-linux/
[5]: https://www.2daygeek.com/list-of-graphical-frontend-tool-for-linux-package-manager/

98
translated/tech/20190712 What is Silverblue.md Normal file
View File

@ -0,0 +1,98 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (What is Silverblue?)
[#]: via: (https://fedoramagazine.org/what-is-silverblue/)
[#]: author: (Tomáš Popela https://fedoramagazine.org/author/tpopela/)
何谓 Silverblue？
======
![][1]
Fedora Silverblue 在 Fedora 世界内外越来越受欢迎。因此，根据社区的反馈，以下是关于这个项目的一些有趣问题的答案。如果你有任何其他与 Silverblue 相关的问题，请在评论区留言，我们会在未来的文章中回答。
### 何谓 Silverblue？
Silverblue 是新一代桌面操作系统的代号，之前被称为 Atomic Workstation。该操作系统是通过利用 [rpm-ostree 项目][2]创建的映像来交付的。这种系统的主要优点是速度、安全性、原子更新和不变性。
### “Silverblue”到底是什么意思？
“Team Silverblue” 或简称 “Silverblue”，没有任何隐藏的含义。该项目以前被称为 Atomic Workstation，大约两个月后更名时选中了这个名字。在这个过程中，审查过 150 多个单词或单词组合。最终选择了 “Silverblue”，因为它有一个可用的域名以及社交网络账号。人们可以把它看成是 Fedora 的蓝色品牌的一个新的品牌形象，可以用在诸如“加油，Silverblue 团队！”或“想加入该团队，改进 Silverblue 吗？”这样的短语中。
### 何谓 ostree？
[OSTree 或 libostree 是一个项目][3]，它结合了一个类似 Git 的提交和下载可引导文件系统树的模型，以及用于部署它们和管理引导加载程序配置的层。OSTree 被 rpm-ostree 所使用，这是 Silverblue 使用的一个基于包/镜像的混合系统。它原子化地复制了一个基础操作系统，并允许用户在需要时在基础操作系统之上 "分层 "传统的 RPM。
### 为何使用 Silverblue？
因为它可以让你专注于你的工作，而不是你正在运行的操作系统。因为系统的更新是原子式的，所以它更稳健。你唯一需要做的事情就是重新启动到新的镜像中。此外，如果当前启动的镜像有什么问题，你可以很容易地重启/回滚到之前可以工作的镜像，如果有的话。如果没有，你可以使用 `ostree` 命令下载并启动过去生成的任何其他镜像。
另一个好处是可以在不同的分支（或者用旧的语境说就是 Fedora 版本）之间轻松切换。你可以轻松地尝试 [Rawhide][4] 或 [updates-testing][5] 分支，然后返回到包含当前稳定版本的分支。另外，如果你想尝试一些新奇的东西，也可以考虑试试 Silverblue。
### 不可变的操作系统有什么好处？
其中一个主要的好处是安全。基础操作系统是以只读的形式挂载的，因此不能被恶意软件修改。唯一可以改变系统的方法是通过 `rpm-ostree` 实用程序。
另一个好处是健壮性。普通用户几乎不可能在不小心或无意中删除了一些系统库后，让操作系统恢复到不启动或无法正常工作的状态。试着想想你过去的这些经历，就可以明白 Silverblue 如何帮助你。
### 如何在 Silverblue 中管理应用程序和包？
对于图形化用户界面的应用程序，建议使用 [Flatpak][6]，如果应用程序是以 Flatpak 的形式提供的话。用户可以选择来自 Fedora 的 Flatpak，和从 Fedora 包及 Fedora 自己的基础架构中构建的 Flatpak，或者目前有更广泛的交付的 Flathub。用户可以通过已经支持 Fedora Silverblue 的 GNOME “软件”轻松安装它们。
用户首先发现的一件事就是操作系统中没有预装 `dnf`。主要原因是它不能在 Silverblue 上工作 —— 它的部分功能被 `rpm-ostree` 命令所取代。用户可以通过使用 `rpm-ostree install PACKAGE` 来层叠传统的软件包。但只有在没有其他方法的情况下，才应该使用这种方式。这是因为从存储库中提取新的系统镜像时，每次更改系统镜像时都必须重新构建系统镜像，以容纳分层的包或从基础操作系统中删除或替换为其他版本的包。
Fedora Silverblue 自带的默认 GUI 应用程序集是基础操作系统的一部分。团队正在努力将它们移植到 Flatpak 上，这样它们就可以通过这种方式分发。其中一个好处是，基础操作系统将变得更小，更容易维护和测试，用户可以更容易修改他们的默认安装环境。如果你想看一下它是怎么做的，或者有什么帮助，可以看看官方的 [文档][7]。
### 什么是 Toolbox？
[Toolbox][8] 是一个让普通用户可以轻松使用容器的项目。它通过使用 podman 的无 root 容器来实现。Toolbox 可以让你在常规的 Fedora 安装中轻松、快速地创建一个容器，你可以在这个容器上折腾或开发，而与你的操作系统分离。
### Silverblue 有路线图吗？
形式上没有，因为我们正在关注在测试过程中发现的问题和社区的反馈。我们目前正在使用 Fedora 的 [Taiga][9] 来进行规划。
### Silverblue 的发布周期是多少？
它和普通的 Fedora Workstation 是一样的。每 6 个月发布一次新版本，支持期为 13 个月。团队计划每两周（或更长时间）发布一次更新，而不是像现在这样每天发布一次。这样一来，更新可以在发送给其他用户之前，由 QA 和社区志愿者进行更彻底的测试。
### 不可变操作系统的未来前景如何？
从我们的角度来看，桌面的未来涉及到了不可变的操作系统。这对用户来说是最安全的，Android、ChromeOS、ChromeOS、最近的 macOS Catalina 全都在底层采用了这种方式。而对于 Linux 桌面来说，一些第三方软件期望写到操作系统的问题还是存在的。HP 打印机驱动程序就是一个很好的例子。
另一个问题是系统中的部分软件如何分发和安装。字体就是一个很好的例子。目前在 Fedora 中，它们是以 RPM 包的形式分发的。如果你想使用它们，你必须层叠它们，然后重新启动到新创建的包含它们的镜像中。
### 标准版 Workstation 的前景如何？
Silverblue 有可能会取代普通的Workstation版本。但 Silverblue 要提供与Workstation版本相同的功能和用户体验，还有很长的路要走。在此期间，这两款桌面产品将同时推出。
### Atomic Workstation或 Fedora CoreOS 与这些有什么关系？
Atomic Workstation 是在更名为 Fedora Silverblue 之前的项目名称。
Fedora CoreOS 是一个不同但相似的项目。它与 Silverblue 共享一些基本技术，如 `rpm-ostree`、`toolbox` 等。尽管如此，CoreOS 是一个更简约、专注于容器、自动更新的操作系统。
--------------------------------------------------------------------------------
via: https://fedoramagazine.org/what-is-silverblue/
作者：[Tomáš Popela][a]
选题：[lujun9972][b]
译者：[wxy](https://github.com/wxy)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://fedoramagazine.org/author/tpopela/
[b]: https://github.com/lujun9972
[1]: https://fedoramagazine.org/wp-content/uploads/2019/07/what-is-fedora-silverblue-816x345.jpg
[2]: https://rpm-ostree.readthedocs.io/en/latest/
[3]: https://ostree.readthedocs.io/en/latest/
[4]: https://fedoraproject.org/wiki/Releases/Rawhide
[5]: https://fedoraproject.org/wiki/QA:Updates_Testing
[6]: https://flatpak.org/
[7]: https://docs.fedoraproject.org/en-US/flatpak/tutorial/
[8]: https://github.com/debarshiray/toolbox
[9]: https://teams.fedoraproject.org/project/silverblue/

177
translated/tech/20200416 How to package Python applications for Linux.md Normal file
View File

@ -0,0 +1,177 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How to package Python applications for Linux)
[#]: via: (https://opensource.com/article/20/4/package-python-applications-linux)
[#]: author: (Moshe Zadka https://opensource.com/users/moshez)
如何为 Linux 打包 Python 应用
======
了解如何使用 dh_virtualenv 来让你的 Python 应用可作为 .deb 包安装。
![Python in a tree][1]
一种让 Python 应用可在基于 Debian 的操作系统（例如 Debian 或 [Elementary OS][2]）上安装的方法是使用 [dh_virtualenv][3] 工具。它会构建一个封装了 Python 虚拟环境的 **.deb** 包，并在安装时进行部署。
在本文中，我将以构建包含 [HTTPie][4] 工具的包为例，说明如何无需激活虚拟环境即可从命令行测试 HTTP API。
### 使用 dh_virtualenv 打包
首先，你需要安装 dh_virtualenv 所需的工具。dh_virtualenv 的[文档][5]提供了所有安装选项。在基于 Debian 的系统上，我输入：
```
`apt-get install dh-virtualenv devscripts`
```
尽管不需要 [devscripts][6] 包，但它将简化后续操作。
现在，创建一个目录来保存源码。由于这是 HTTPie 的本地非官方打包，因此我将其称为 **myhttp**。 接下来，让我们在 **myhttp** 内创建一些文件以向 Debian 构建系统提供元数据。
首先，创建 **debian/control** 文件：
```
Source: myhttp
Section: python
Priority: extra
Maintainer: Jan Doe &lt;[jandoe@example.org][7]&gt;
Build-Depends: debhelper (&gt;= 9), python3.7, dh-virtualenv (&gt;= 0.8)
Standards-Version: 3.9.5
Package: myhttp
Architecture: any
Pre-Depends: dpkg (&gt;= 1.16.1), python3.7, ${misc:Pre-Depends}
Depends: ${misc:Depends}
Description: http client
 Useful for doing stuff
```
那么这些是什么信息呢？ [Debian 文档][8]指出：
>“第 1–7 行是源码包的控制信息。第 9–13 行是二进制包的控制信息。”
以下是我使用的：
* **section** 的值对于我们来说大多没有意义，但需要存在。它对提供 UI 安装程序信息是有意义的，这与此包无关。
* 额外的 **Priority** 值是像这样的第三方包的正确优先级。
* 强烈建议在 **Maintainer** 字段中填写正确的联系人信息。但是，如果包由团队维护，并且你希望将问题发送到团队的邮件别名，例如 “Infrastructure Team &lt;[infra-team-list@company.example.com][9]&gt;”，那这不一定是你的个人邮箱。
* **build-depends** 字段标识你需要 debhelper、python 和 dh-virtualenv 来构建包：包生成过程将确保这些依赖项在包构建时安装。
* **standards version** 字段主要给人看。它表明你遵循的指南。本指南基于 dh-virtualenv 的官方文档，它是基于 Debian 的 3.9.5 指南。最好一直将源码包和二进制包命名相同。
* **Architecture** 字段应为 **Any**，因为除非虚拟环境可能包含一些特定于体系结构的文件。否则，最好选择该字段为 **any**。
* 保持 Pre-Depends 列表为当前的样式：预依赖是一种非常严格的依赖关系形式，你很少会需要比建议的最小依赖更多的依赖项。依赖项通常由构建系统准确计算，因此没有理由手动指定它们。
* 如果你的包主要用于内部，那么 **Description** 字段只需要最少的信息或者指向公司 wiki 的链接，不然详细信息更有用。
然后创建 **debian/compat** 文件，它[主要出于历史目的而存在][10]：
```
`$ echo "9" > debian/compat`
```
接下来，创建更新日志以告知包用户自上一发行版以来发生了什么变化。最简单的方法是使用 **dch --create** 创建模板，然后填写值。
填写后，它看起来像：
```
myhttp (2.0.0-1) stable; urgency=medium
  * Initial release.
 -- Jan Doe &lt;[jandoe@example.org][7]&gt;  Fri, 27 Mar 2020 01:09:22 +0000
```
现在你需要告诉工具安装 HTTPie，但是哪个版本？
创建一个宽松版本的 **requirements.in** 文件：
```
`httpie`
```
通常，宽松的需求文件将仅包含项目的直接依赖项，并在需要时指定最低版本。 不一定总是需要指定最低版本：这些工具通常偏向于将依赖关系转化为“可能的最新版本”。如果你的 Debian 包与一个内部 Python 包相对应，这是内部应用中的一种常见情况，那么宽松的需求文件看起来将很相似：仅包含包名的一行。
然后使用 **pip-compile**（可通过安装 PyPI 包 **pip-tools** 获得）：
```
`$ pip-compile requirements.in > requirements.txt`
```
这会生成一个严格的依赖文件，名为 **requirements.txt**：
```
#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile requirements.in
#
certifi==2019.11.28       # via requests
chardet==3.0.4            # via requests
httpie==2.0.0             # via -r requirements.in
idna==2.9                 # via requests
pygments==2.6.1           # via httpie
requests==2.23.0          # via httpie
urllib3==1.25.8           # via requests
```
最后，写一个 **debian/rules** 文件来创建包。因为 dh_virtualenv 会处理所有困难的事，因此规则文件很简单：
```
#!/usr/bin/make -f
%:
        dh $@ --with python-virtualenv --python /usr/bin/python3.7
```
确保指定 Python 解释器。默认它会使用 **/usr/bin/python**，这是 Python2，但是你应该使用一个[受支持的 Python 版本][11]
完成了，接下来就是构建包：
```
`$ debuild -b -us -uc`
```
这会在父目录生成一个类似 **myhttp_2.0.0-1_amd64.deb** 的文件。该文件可在任何兼容的系统上安装。
通常，最好在同一平台上构建用于特定平台（例如 Debian 10.0）的 Debian 包。
你可以将此 Debian 包保存在存仓库中，并使用例如 [Ansible][12] 的工具将其安装在所有相关系统上。
### 总结
给基于 Debian 的系统的打包应用是一个有多个步骤的过程。使用 dh_virtualenv 将使过程变得简单。
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/4/package-python-applications-linux
作者：[Moshe Zadka][a]
选题：[lujun9972][b]
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/moshez
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/life-python.jpg?itok=F2PYP2wT (Python in a tree)
[2]: https://opensource.com/article/19/12/pantheon-linux-desktop
[3]: https://dh-virtualenv.readthedocs.io/en/latest/
[4]: https://opensource.com/article/19/8/getting-started-httpie
[5]: https://dh-virtualenv.readthedocs.io/en/1.1/tutorial.html
[6]: http://man.he.net/man1/devscripts
[7]: mailto:jandoe@example.org
[8]: https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control
[9]: mailto:infra-team-list@company.example.com
[10]: https://www.debian.org/doc/manuals/maint-guide/dother.en.html#compat
[11]: https://opensource.com/article/19/11/end-of-life-python-2
[12]: https://opensource.com/resources/what-ansible