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

Merge pull request #24490 from wxy/20220124-Linux-Jargon-Buster--What-are-Upstream-and-Downstream

Browse Source 
TR:sources/tech/20220124 Linux Jargon Buster- What are Upstream and Downstream.md
This commit is contained in:
Xingyu.Wang 2022-01-26 10:50:46 +08:00 committed by GitHub
commit 9a61735835
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 100 additions and 104 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

104
sources/tech/20220124 Linux Jargon Buster- What are Upstream and Downstream.md
View File

@ -1,104 +0,0 @@
[#]: subject: "Linux Jargon Buster: What are Upstream and Downstream?"
[#]: via: "https://itsfoss.com/upstream-and-downstream-linux/"
[#]: author: "Bill Dyer https://itsfoss.com/author/bill/"
[#]: collector: "lujun9972"
[#]: translator: "wxy"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
Linux Jargon Buster: What are Upstream and Downstream?
======
The terms: _upstream_ and _downstream_ are rather ambiguous terms and, I think, not really used by the general public. If you are a Linux user and do not write or maintain software, chances are pretty good that these terms will mean nothing to you, but they can be instructive in how communication between groups within the Linux world works.
The terms are used in networking, programming, kernel, and even in non-computer areas such as supply chains. When we talk about upstream and downstream then, context is important.
In its simplest form, upstream and downstream is the direction of the flow of information.
Since we are all reading this article while we’re connected to the Internet, let’s look at an upstream/downstream example as it applies to Internet Service Providers (ISP). Here, the ISP is concerned with traffic. Upstream traffic is data is coming in from a user from a different ISP. For example, if you have a website that offers a subscription to a newsletter, the information I send, to subscribe, is upstream data.
Downstream traffic is data that is sent from a user to another user at a different ISP, then it is considered as downstream traffic. Using the same subscription example, let’s assume that my request to subscribe is approved and I get a “welcome” note in one email and the latest newsletter in another email. In this case, the data is downstream as it is sent by you (well, probably automated software operating as a representative of you) to me, a user from a different ISP.
Summing up: the thing I need or want (your newsletter) is upstream. The things you provide to me (the welcome note and actual newsletter) come to me, downstream.
Whether data is upstream or downstream is probably unimportant to us as users, but it is important to the server administrators who monitor bandwidth usage, as well as to distributors, and application programmers.
In the Linux world, upstream and downstream have two main contexts. One is concerned with the kernel and the other is concerned with applications. There are others, but I hope that I can get the idea across with these two.
### Upstream and downstream in the context of Linux kernel
![][1]
Linux _is_ the kernel. In creating a distribution (often called a “distro”), Linux distributions initially use the source code from an unmodified kernel. Necessary patches are added and then the kernel is configured. The kernel’s configuration is based upon what features and options the distribution wants to offer. Once decided upon, the kernel is created accordingly.
The original kernel is upstream from the distribution. When the distribution gets the source code, it flows downstream. Once the distribution has the code it stays with the makers of the distribution while work is being done on it. It is still upstream from us, as users, until it is ready for release.
The kernel version that the distribution creates will have patches added and certain features and options enabled. This configuration is determined by the distro builder. This is why there are several flavors of Linux: [Debian][2] vs. [Red Hat][3], for example. The builder of the distro decides on the options to offer to their user base, and compiles the kernel accordingly.
Once that work is completed, it is made ready for release in a repository and we’re allowed to grab a copy. That copy flows downstream to us.
Similarly, if the distributor finds a bug in the kernel, fixes it and then sends the patch to the kernel developers so that they could patch the kernel for everyone downstream. This is called contributing to upstream because here the flow is going upwards to the original source.
### Upstream and downstream in the context of applications
Again, technically, Linux is the kernel, everything else is additional software. The distro builder also adds additional software to their project. In this case, there are several upstreams. A distro can contain any number of applications such as X, KDE, Gnome, and so on.
Let’s imagine that you are using the [nano][4] editor and discover that it isn’t working right so you submit a bug report to the distributor. The programmers working on the distro will look at it and, if they find that they inserted a bug into nano, they will fix it and make a new release available in their repository. If they find that they didn’t make the bug, the distributor will submit a bug report upstream to the nano programmer.
When it comes to things like bug reports, feature requests, etc. it is always best to send them upstream to your distributor since they maintain the kernel and additional applications for the distro you’re using. For example, I use a distro called [Q4OS][5] on a few machines. If I find a bug in a program, I report it to the Q4OS folks. If you happen to be using, say, [Mint][6], you would report it to the Mint project.
If you were to post a problem on a generic Linux board, for example, and you mentioned that you were using Mint, you will surely get a reply that says something like: “This is better handled in a Mint forum.” Using the previous “nano bug” example, it’s possible that the Mint programmers made a change to nano to make it work better in their distro. If they did make a mistake, they would want to know about it and, having made the mistake, they would be the ones to fix it.
Once fixed, the updated program is put into a repository available to you. When you get the update, it comes downstream to you, like so:
* If a distributor makes the fix, the new version is made available in the distro repository
* If the programmer of the application makes the fix, it is sent downstream to the distributors who test the new code. Once it’s found to be working right, it is placed in the repository, to flow downstream to you
### Automatic flow downstream
There was a time, when users had to get their own updates. A user would get the updated source code and compile a new executable. As time went on, utilities like apt were created to allow users to pull updated binaries (executables) from the repositories. The apt program is Debian, but other distros have their own, similar program for this.
Programs like apt take care of the upstream/downstream work. If you ran apt with the upgrade option like so:
`sudo apt upgrade`
it would look (upstream) to the distro repository, find any needed updated packages and pull them (downstream) to your machine and install them.
Some distros take this further. Distro programmers and maintainers are always checking over their product. Often times, an application programmer will make improvements to their program. System libraries are updated frequently, security holes get plugged, and so on. These updates are made available to the distributors who then make the new version available in the distro’s repository.
Rather than have you run apt every day, some distros will alert you to updates that are available and ask if you want them. If you want then, just accept and the updates will be sent downstream to your machine and installed.
### Conclusion
I just remembered a bit of my history, having mentioned Red Hat. Back in 1994 or 1995, they placed a job ad and one of the cool workplace benefits listed was, “all the free peanut M&Ms you could eat and all the free Dr. Pepper you could drink.” I had no doubt that I could do the work, and I applied just for those two benefits alone. I didn’t get a call though.
Oh well. Getting back to the point…
Upstream and downstream is really just the direction of data flow. How far upstream or downstream this data flows depends on who ultimately needs to work on it. Basically, the programmers are upstream and the users are downstream.
Again, as users, we really don’t need to be worried about these terms, but the concepts do help in the development and maintenance of software. By being able to direct the work to the appropriate group, duplicate work is avoided. It also ensures that a standard is maintained. The Chrome browser, for example, might need slight changes made to it in order to work on a certain distro, but it will be Chrome at its core – it will look and act like Chrome.
If you do find a bug with any program in your distro, just report it to your distro’s maintainers, which is usually done through their website. You’ll be sending it upstream to them, but it doesn’t matter whether you remember that you’re sending the report upstream.
--------------------------------------------------------------------------------
via: https://itsfoss.com/upstream-and-downstream-linux/
作者：[Bill Dyer][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://itsfoss.com/author/bill/
[b]: https://github.com/lujun9972
[1]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2022/01/upstream-downstream.png?resize=800%2C450&ssl=1
[2]: https://www.debian.org/
[3]: https://www.redhat.com/
[4]: https://www.nano-editor.org/
[5]: https://q4os.org/
[6]: https://linuxmint.com/

100
translated/tech/20220124 Linux Jargon Buster- What are Upstream and Downstream.md Normal file
View File

@ -0,0 +1,100 @@
[#]: subject: "Linux Jargon Buster: What are Upstream and Downstream?"
[#]: via: "https://itsfoss.com/upstream-and-downstream-linux/"
[#]: author: "Bill Dyer https://itsfoss.com/author/bill/"
[#]: collector: "lujun9972"
[#]: translator: "wxy"
[#]: reviewer: "wxy"
[#]: publisher: " "
[#]: url: " "
Linux 黑话解释：什么是上游和下游？
======
“<ruby>上游<rt>upstream</rt></ruby>” 和 “<ruby>下游<rt>downstream</rt></ruby>”这两个术语是相当模糊的，我认为一般人并不会真正使用它们。如果你只是一个 Linux 用户，并且不编写或维护软件，那么很有可能这些术语对你来说毫无意义，但它们对 Linux 世界中各个社区之间的交流方式有益的。
这些术语被用于网络、编程、内核，甚至在非计算机领域，如供应链。当我们谈论上游和下游的时候，讨论背景是很重要的。
在其最简单的形式中，上游和下游是信息流动的方向。
由于我们都是在连接到互联网的情况下阅读这篇文章的，让我们看看适用于互联网服务提供商（ISP）的上游/下游例子。这里，ISP 关注的是流量。上游流量是指数据是从不同的 ISP 的用户处传来的。例如，如果你有一个提供订阅通讯的网站，我发送的订阅信息就是上游数据。
下游流量是指从一个用户发送到不同 ISP 的另一个用户的数据，它被认为是下游流量。使用同样的订阅例子，假设我的订阅请求被批准，我在一封邮件中收到“欢迎”说明，在又一封邮件中收到最新的新闻简报。在这种情况下，数据是顺流而下的，因为它是由你（好吧，可能是作为代表你进行操作的自动化软件）发送给我，一个来自另外 ISP 的用户。
总结：我需要或想要的东西（你的通讯）是上游的。你提供给我的东西（欢迎词和实际的通讯）是下游的。
数据是在上游还是在下游，对我们用户来说可能并不重要，但对监控带宽使用的服务器管理员，以及<ruby>发行商<rt>distributor</rt></ruby>（发行版的制作者）和程序员来说却很重要。
在 Linux 世界里，上游和下游有两个主要背景。一个是关于内核的，另一个是关于应用程序的。还有其他的，但我希望我可以通过这两个来表达我的想法。
### Linux 内核背景下的上游和下游
![][1]
Linux _就是_ 内核。在创建发行版时，Linux 发行版首先使用未经修改的内核源代码。然后添加必要的补丁，对内核进行配置。内核的配置是基于发行版想要提供的功能和选项。一旦决定了，就相应地创建了内核。
原始内核来自发行版的上游。当发行版得到源代码时，它就流向下游。一旦发行版得到了内核代码，它就会留在发行商那里，同时对它进行改造。它仍然是我们用户的上游，直到它准备好被发布。
发行版创建的内核版本将添加补丁和启用某些功能和选项。这种配置是由发行商决定的。这就是为什么有几种 Linux 流派的原因，例如，[Debian][2] 与 [Red Hat][3]。发行商会决定向他们的用户群提供哪些选项，并相应地编译内核。
一旦这项工作完成，它就会放在一个仓库中准备发布，我们就可以获得一份副本。这个副本向下游流向我们。
同样地，如果发行商发现了内核中的一个错误，修复了它，然后将补丁发送给内核开发者，这样他们就可以为下游的每个人修补内核。这被称为对上游的贡献，因为这里的流量是向上流向原始来源的。
### 在应用程序背景下的上游和下游
同样，从技术上讲，Linux 是内核，其他都是附加软件。发行商也会在他们的项目中加入额外的软件。在这种情况下，有几个上游。一个发行版可以包含任何数量的应用程序，如 X、KDE、Gnome 等等。
让我们想象一下，你在使用 [nano][4] 编辑器时发现它不能正常工作，于是你向发行版提交了一份错误报告。发行商的程序员会查看它，如果发现他们在 nano 中插入了一个错误，他们将修复它并在其仓库中发布一个新版本。如果他们发现不是他们制造了这个错误，发行商将向上游的 nano 程序员提交一份错误报告。
当涉及到像错误报告、功能请求等事情时，最好是将它们发送到上游的发行商那里，因为他们维护着你所使用的发行版的内核和附加应用程序。例如，我在几台机器上使用一个叫做 [Q4OS][5] 的发行版。如果我发现一个程序中的错误，我会把它报告给 Q4OS 的人。如果你碰巧使用的是 [Mint][6]，你会把它报告给 Mint 项目。
比如说，如果你在一个普通的 Linux 论坛上发布一个问题，而你提到你在使用 Mint，你肯定会得到这样的回复。“这个问题最好在 Mint 论坛上处理”。用之前的 nano 错误的例子，有可能是 Mint 的程序员对 nano 进行了修改，使其在他们的发行版中运行得更好。如果他们确实犯了一个错误，他们会想知道这个错误，而且在犯了这个错误之后，他们会是修复它的人。
一旦修复，更新的程序就会被放入你可以使用的仓库。当你得到更新时，它就会顺流而下到你那里，像这样：
* 如果发行商进行了修复，新版本就会在发行仓库中提供。
* 如果该应用程序的程序员进行了修复，它将被发送到测试新代码的发行商那里。一旦发现它工作正常，它就会被放在仓库中，向下游流去。
### 自动流向下游
曾经有一段时间，用户得自己获取更新。用户会得到更新的源代码并编译一个新的可执行文件。随着时间的推移，像 `apt` 这样的工具被创造出来，允许用户从软件库中提取更新的二进制文件（可执行文件）。`apt` 程序是 Debian 的，但其他发行版也有他们自己的用于此用途的类似程序。
像 `apt` 这样的程序负责处理上游/下游的工作。如果你用升级选项运行 `apt`，像这样：
```
sudo apt upgrade
```
它将查看（上游）发行仓库，找到任何需要的更新包，并将它们拉到你的机器上（下游）并安装它们。
有些发行版会更进一步。发行版的程序员和维护者总是在检查他们的产品。很多时候，应用程序的程序员会对他们的程序进行改进。系统库会经常更新，安全漏洞也会被堵上，等等。这些更新会提供给发行商，然后由发行商在发行仓库中提供新的版本。
与其让你每天运行 `apt`，一些发行版会提醒你有可用的更新并询问你是否需要它们。如果你想要，只要接受，更新就会被发送到你的机器上并安装。
### 总结
上游和下游实际上只是数据流的方向。这个数据在上游或下游流动的方式取决于最终需要谁来处理它。基本上，程序员是上游，用户是下游。
同样，作为用户，我们真的不需要关心这些术语，但这些概念确实有助于软件的开发和维护。通过将工作引向适当的小组，避免了重复工作。这也确保了标准的维护。例如，Chrome 浏览器可能需要做一些细微的改变，以便在某个发行版上运行，但它的核心是 Chrome 浏览器，它的外观和行为都不会有大的变化。
如果你发现你的发行版中的任何程序有错误，只需向发行版的维护者报告，这通常是通过他们的网站进行的。你将会把它发送到上游，但你是否记得你在向上游发送报告并不重要。
--------------------------------------------------------------------------------
via: https://itsfoss.com/upstream-and-downstream-linux/
作者：[Bill Dyer][a]
选题：[lujun9972][b]
译者：[wxy](https://github.com/wxy)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://itsfoss.com/author/bill/
[b]: https://github.com/lujun9972
[1]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2022/01/upstream-downstream.png?resize=800%2C450&ssl=1
[2]: https://www.debian.org/
[3]: https://www.redhat.com/
[4]: https://www.nano-editor.org/
[5]: https://q4os.org/
[6]: https://linuxmint.com/