mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
cinlen_0x05
GitHub
commit
adb4997dfa
@ -1,96 +1,92 @@
|
||||
translating by xllc
|
||||
|
||||
ps_mem – A Simple Python Script To Report Core Memory Usage Accurately In Linux
|
||||
ps_mem：一个用于精确报告 Linux 核心内存用量的简单 Python 脚本
|
||||
============================================================
|
||||
|
||||
[ps_mem][2] is a simple python script which help us to get core memory usage accurately for a program in Linux. There are many utilities available in Linux to see memory usage such as free, vmstat, smem & top, etc,. but this utility bit different compare with others since its showing core memory usage accurately.
|
||||
[ps_mem][2] 是一个可以帮助我们精确获取 Linux 中各个程序核心内存使用情况的简单 python 脚本。虽然在 Linux 上有很多可用于查看内存使用情况的工具，比如 `free`、`vmstat`、`smem`、`top` 等，但这个工具和其它的区别在于其精确显示核心内存使用情况。
|
||||
|
||||
It’s calculating the sum of private & sum of shared memory against a program and giving total used RAM in more appropriate way, definitely it will help everyone to understand which program eating more RAM in system.
|
||||
它会分别计算一个程序私有内存总量和共享内存总量，并以更准确的方式给出了总的内存使用量。很明显的，它将帮助大家知道系统中哪个程序正在占用更多的内存。
|
||||
|
||||
You can install the ps_mem utility in many ways, through package manager, pip and directly method (by running the ps_mem.py script). Make a note, it’s requires root privilege.
|
||||
你可以通过包管理器、`pip` 、或直接运行 `ps_mem.py` 脚本等多种方式来安装 `ps_mem` 工具。需要注意的是：需要有 root 权限。
|
||||
|
||||
Also read the below suggested memory utilities.
|
||||
另外，推荐阅读以下内存工具：
|
||||
|
||||
Suggested Read : [free – A Standard Command to Check Memory Usage Statistics (Free & Used) in Linux][3]
|
||||
- [free – 一个在 Linux 上查看内存用量统计（可用和已用）的标准工具][3]
|
||||
- [smem – Linux 内存报告/统计工具][4]
|
||||
- [vmstat – 一个好用的用于虚拟内存统计的标准工具][5]
|
||||
|
||||
Suggested Read : [smem – Linux Memory Reporting/Statistics Tool][4]
|
||||
### 通过包管理器安装 ps_mem
|
||||
|
||||
Suggested Read : [vmstat – A Standard Nifty Tool to Report Virtual Memory Statistics][5]
|
||||
基于 RHEL 的系统默认仓库就包含 ps_mem 工具，所以我们可以简单地通过包管理器进行安装。
|
||||
|
||||
#### Install ps_mem Via Package Manager
|
||||
|
||||
RHEL based system has the ps_mem utility in default repository, so we can easily install it through package manager.
|
||||
|
||||
For RHEL/CentOS, use [yum Package Manager][6] to install ps_mem package.
|
||||
对于 RHEL/CentOS ，使用 [yum 包管理器][6] 安装 `ps_mem` 包：
|
||||
|
||||
```
|
||||
$ sudo yum install ps_mem
|
||||
```
|
||||
|
||||
For Fedora, use [dnf Package Manager][7] to install ps_mem package.
|
||||
对于Fedora ，使用 [dnf 包管理器][7] 安装 ps_mem 包：
|
||||
|
||||
```
|
||||
$ sudo dnf install ps_mem
|
||||
```
|
||||
|
||||
For Arch Linux, use [pacman Package Manager][8] to install ps_mem package.
|
||||
对于 Arch Linux ，使用 [pacman 包管理器][8] 安装 ps_mem 包：
|
||||
|
||||
```
|
||||
$ sudo pacman -S ps_mem
|
||||
```
|
||||
|
||||
#### Install ps_mem Via Pip
|
||||
#### 通过 pip 安装 ps_mem
|
||||
|
||||
pip is a recommended tool for installing Python packages in Linux. Use pip command instead of package manager to get latest build. Make sure you should have install pip package on your system in order to use the pip package. If no, use distribution package manager and install `python-pip` package.
|
||||
`pip` 是在 Linux 上推荐使用的一种安装 Python 包的工具。可以使用 `pip` 命令而不是包管理器去获取最新的版本。使用 `pip` 包前，请确保你的系统上已安装过 `pip` 包。否则，先使用发行版本的包管理器安装 `python-pip` 包。
|
||||
|
||||
For Debian based systems.
|
||||
对于基于 Debian 的系统：
|
||||
|
||||
```
|
||||
$ sudo apt-get install python-pip
|
||||
```
|
||||
|
||||
For RHEL/CentOS based systems.
|
||||
对于基于 RHEL/CentOS 的系统：
|
||||
|
||||
```
|
||||
$ sudo yum install python-pip
|
||||
```
|
||||
|
||||
For Fedora
|
||||
对于 Fedora
|
||||
|
||||
```
|
||||
$ sudo dnf install python-pip
|
||||
```
|
||||
|
||||
For openSUSE
|
||||
对于 openSUSE
|
||||
|
||||
```
|
||||
$ sudo zypper install python-pip
|
||||
```
|
||||
|
||||
For Arch Linux based systems
|
||||
对于基于 Arch Linux 的系统：
|
||||
|
||||
```
|
||||
$ sudo pacman -S python-pip
|
||||
```
|
||||
|
||||
Finally run the pip tool to install ps_mem on Linux.
|
||||
最后，在 Linux 上运行 `pip` 工具安装 `ps_mem` ：
|
||||
|
||||
```
|
||||
$ sudo pip install ps_mem
|
||||
```
|
||||
|
||||
#### Run ps_mem.py script directly
|
||||
### 直接运行 ps_mem.py 脚本
|
||||
|
||||
Alternatively we can run the `ps_mem.ph` script directly by downloading the file from developer github page.
|
||||
我们也可以从开发者 github 页面下载文件，并直接运行 `ps_mem.py` 脚本。
|
||||
|
||||
```
|
||||
$ git clone https://github.com/pixelb/ps_mem.git && cd ps_mem
|
||||
$ sudo python ps_mem.py
|
||||
```
|
||||
|
||||
#### ps_mem Usage
|
||||
### ps_mem 使用方法
|
||||
|
||||
Just run the `ps_mem` without any option to get core memory usage accurately for per program.
|
||||
不带任何参数直接运行 `ps_mem` 以精确获取每个程序的的核心内存使用情况。
|
||||
|
||||
```
|
||||
$ sudo ps_mem
|
||||
@ -158,7 +154,7 @@ $ sudo ps_mem
|
||||
=================================
|
||||
```
|
||||
|
||||
To print an output with full path.
|
||||
输出中打印出全路径：
|
||||
|
||||
```
|
||||
$ sudo ps_mem -s
|
||||
@ -211,7 +207,7 @@ $ sudo ps_mem -s
|
||||
=================================
|
||||
```
|
||||
|
||||
Only show memory usage PIDs in the specified list
|
||||
只显示特定的 PID 列表的内存使用情况：
|
||||
|
||||
```
|
||||
$ sudo ps_mem -p 2886,4386
|
||||
@ -224,13 +220,13 @@ $ sudo ps_mem -p 2886,4386
|
||||
=================================
|
||||
```
|
||||
|
||||
To print process memory in every N seconds. The following command reports memory usage in every 2 seconds.
|
||||
每 N 秒打印进程内存。以下命令每 2 秒报告一次内存使用情况：
|
||||
|
||||
```
|
||||
$ sudo ps_mem w 2
|
||||
```
|
||||
|
||||
To show only total memory.
|
||||
只显示内存总量：
|
||||
|
||||
```
|
||||
$ sudo ps_mem -t
|
||||
@ -241,9 +237,9 @@ $ sudo ps_mem -t
|
||||
|
||||
via: http://www.2daygeek.com/ps_mem-report-core-memory-usage-accurately-in-linux/
|
||||
|
||||
作者：[ 2DAYGEEK ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
作者：[2DAYGEEK][a]
|
||||
译者：[xllc](https://github.com/xllc)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,63 @@
|
||||
Linus Torvalds 说 Linux 仍然惊讶和激励着他
|
||||
============================================================
|
||||
|
||||
|
||||
|
||||
> Linus Torvalds 和 VMware 开源负责人 Dirk Hohndel 上周在中国 LinuxCon 上进行了一次“炉边聊天”。
|
||||
|
||||
周一，Linus Torvalds 首次来到中国参加[在北京召开的 LinuxCon + ContainerCon + CloudOpen][3]。在近 2000 名观众面前，Linus Torvalds 和 VMware 开源负责人 Dirk Hohndel 进行了进行了一次“炉边聊天”，谈及是什么在惊讶和激励着他，以及有志的开源开发者们该如何上手。下面是他们谈话中的一些亮点。
|
||||
|
||||
### Linux 开发中有什么令人惊讶的事情?
|
||||
|
||||
> “我觉得有趣的是我认为已经稳定的代码仍然在不断的得到改进，有些东西我们已经很多年没有碰了，然后有人来改进了它们，或者在我以为根本就不会有人用的东西上提交了 Bug 报告。我们有了新的硬件，开发了新的功能，但是 25 年后，我们仍然有老的、非常基础的东西，并且人们依然在关心和改善着它们。”
|
||||
|
||||
### 什么在激励着他
|
||||
|
||||
> “我真的很喜欢我正在做的事情。我喜欢醒来时有一个在技术上有趣而富有挑战性并且不太紧张的工作，因此我可以长时间的为此工作；或者做一些我感觉我正在做一个真正有影响的事情，做一些不仅仅是对我来说有意义的事情。
|
||||
|
||||
> “我偶尔在工作中休息一下，例如我在 Git 上工作两到三周的时候就开始休息了。但是每次休息的时间比较长我都会感到无聊厌倦。当我出去潜水一周，就想着要回来，我从没有感觉我需要一个更长的假期。”
|
||||
|
||||
（LCTT 译注：此处“在 Git 上工作” 是指 Linus 在 Git 版本仓库里面开发 Linux 内核，而非开发 Git 软件——事实上，Linus 在早期开发完 Git 的原型之后，主要的 Git 开发已经有别人接手了，虽然他被称之为 Git 之父。而“潜水”是真的指潜水运动，Linus 喜好玩潜水运动。）
|
||||
|
||||
### Linux 的未来领导力
|
||||
|
||||
> “我们的工作进程不会只是 25 年，我们仍然有非常强大的维护团队。我们常常抱怨我们没有足够的维护者 - 这是真的，我们只有数十名顶级维护者做日常合并的工作，这对于一个开源项目来说是一个非常强大的团队。而且随着这些顶级维护者慢慢变老变胖，我们不断有新人进来。一个新人成长为一个顶级维护者需要几年的时间，因此我不觉得我们应该为 Linux 的下一个 20 年担心。”
|
||||
|
||||
### Linux 会被替代吗？
|
||||
|
||||
> “或许会有一些新的项目将来会并且表明他们比我们做的更好，但是我不担心这个。有很多非常成功的 Linux 的分支（fork），人们不会把它们看作是分支是因为他们很和谐。如果有人想要改变一切并且让内核变得更好，我的感觉是，干吧，证明你自己。我可能觉得那是一个坏主意，但是你可以证明我是错的。”
|
||||
|
||||
（LCTT 译注：此处所说的分支，应该是指类似 Android、AGL 等 Linux 分支并没有分裂 Linux 生态，而是彼此补充。）
|
||||
|
||||
### 对 Git 的想法
|
||||
|
||||
> “我对 Git 的广泛传播感到非常的惊讶。显然我非常高兴，它验证了我对分布式开发的看法。然而那时，已经有如此之多的源码版本控制工具，很难再去推出一个新的版本控制系统。我预计它主要限于内核开发 - 因为它是针对我们所做的。”
|
||||
|
||||
> “在刚开始的三到四年里，关于 Git 的抱怨是它如此的与众不同，难以使用。大约五年前，事情发生了改变。有足够多的项目和开发者开始使用 Git ，它变得不再与众不同；人们习惯于使用 Git 。他们开始利用这种开发模式，使用 Git 的安全感，意味着任何东西都不会损坏或者丢失。”
|
||||
|
||||
> “在某些方面，Git 比 Linux 更为人所知。Linux 常常被隐藏起来，例如安卓手机就运行在 Linux 之上，但是你并不知道。但是使用 Git 时，你确切地知道你在使用 Git 。”
|
||||
|
||||
### 分支 Linux
|
||||
|
||||
> “当我坐下来开始写 Git ，一个首要的原则就是你应该能 fork 并且在此基础上做你自己的事情。如果你有友好的 fork（能证明我错了，并且能够改进内核），在这种情况下，人们可以回来说我们实际上改进了内核，这没有什么不好的感觉。我会采纳你的改进并且将其合并进来。这就是为什么你应该鼓励 fork 。你也想让良好的回馈变得很简单。”
|
||||
|
||||
### 开源开发者应该如何开始
|
||||
|
||||
> “于我而言，我总是自我激励，知道自己想要做什么，我从来没有被告知要去做什么。我不确定我的例子是否适合人们效仿。如果你是一个新手程序员，你可以从成千上万的开源项目中找到你所感兴趣的，你可以长期关注这个项目，去了解它的代码，以至于你可以在某个部分的代码上可以成为专家，不需要是整个项目。没有人是整个内核的专家，但是你可以很好地了解其中的一个领域。”
|
||||
|
||||
> “如果你能成为社区的一份子，能提交补丁，那将不仅仅是编程，而是有开源社会方面的意义。你作为一个程序员提升了你自己并且和外界联系了起来。你基本上可以向外展示 - 我做了这些改进，我有能力在我的社区或者工作上走得更远。你不得不花费一定的时间来学习一个项目，但是你将有一个巨大的上升空间 - 不仅仅是从职业方面，而且在你的生活中有一个惊人的项目。”
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/blog/event/lc3-china/20176/6/linus-torvalds-explains-how-linux-still-surprises-and-motivates-him
|
||||
|
||||
作者：[Linux 基金会][a]
|
||||
译者：[rieonke](https://github.com/rieonke)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/lfadmin
|
||||
[1]:https://www.linux.com/licenses/category/linux-foundation
|
||||
[2]:https://www.linux.com/files/images/linus-torvalds-lc3jpg
|
||||
[3]:https://www.lfasiallc.com/linuxcon-containercon-cloudopen-china
|
||||
@ -1,30 +1,28 @@
|
||||
如何在 LaTex 中创建文档
|
||||
如何以 LaTex 创建文档
|
||||
============================================================
|
||||
|
||||
### 学习以 LaTex 文本标记语言排版文档
|
||||
> 学习以 LaTex 文本标记语言排版文档
|
||||
|
||||
|
||||
图片来自 : opensource.com
|
||||
|
||||
LaTeX（读作 `lay-tech` ）是使用纯文本创建文档的方法，使用与 HTML/CSS 或 Markdown 类似的标记标签进行风格化。 LaTeX 最常用于为学术界（如学术期刊）创建文档。 在 LaTeX 中，作者不必直接对文档进行风格化，就像在 Microsoft Word，LibreOffice Writer 或 Apple Pages 等文字处理程序中一样； 而是用纯文本编写代码，这些代码必须经过编译才能生成 PDF 文档。
|
||||
|
||||
LaTeX（读作_lay-tech_）是使用纯文本创建文档的方法，使用与 HTML/CSS 或 Markdown 类似的标记标签进行风格化。 LaTeX 最常用于为学术界（如学术期刊）创建文档。 在 LaTeX 中，作者不必直接对文档进行风格化，例如 Microsoft Word，LibreOffice Writer 或 Apple Page s等文字处理程序； 而是用纯文本编写代码，这些代码必须被编译才能生成 PDF 文档。
|
||||
|
||||
### [intro.png][1]
|
||||
r
|
||||
|
||||
|
||||
### 起步
|
||||
|
||||
要想使用 LaTex 来书写文档，首先你必须要安装一个 LaTex 编辑器。我用的是一款免费且开源，同时在学术界也是大受欢迎的软件叫做 [TexStudio][8], 它可以运行在 Windows、Unix/Linux、BSD 和 Mac OS X 上。同时你还需要安装一个 **Tex** 排版系统的发行版。因为我斗士在 MacOS 上书写文档，所以我使用的发行版本是 [MacTex or BasicTex][9]。对于 Windows 用户你可以使用[MiKTex][10]，而且 Linux 用户也可以在 repository 中找到它。
|
||||
要想使用 LaTex 来书写文档，首先你必须要安装一个 LaTex 编辑器。我用的是一款自由开源软件（FOSS），其在学术界也是大受欢迎，叫做 [TexStudio][8]，它可以运行在 Windows、Unix/Linux、BSD 和 Mac OS X 上。同时你还需要安装一个 **Tex** 排版系统的分发版。因为我都是在 MacOS 上书写文档，所以我使用的分发版是 [MacTex 或 BasicTex][9]。对于 Windows 用户你可以使用 [MiKTex][10]，而且 Linux 用户也可以在软件库中找到它。
|
||||
|
||||
当你完成了 TexStudio 和 LaTex 发行版的下载，你就可以开始对你的文档进行排版了。
|
||||
当你完成了 TexStudio 和某个 LaTex 的分发版的下载，你就可以开始对你的文档进行排版了。
|
||||
|
||||
### 创建你的第一个文档
|
||||
|
||||
在这个简短的教程里，我们会创建一个简单的文章包括一个大标题、一个子标题和两个段落。
|
||||
在这个简短的教程里，我们会创建一个简单的文章，包括一个大标题、一个子标题和两个段落。
|
||||
|
||||
在启动 TexStudio后，保存一份新的文档。 （我将其保存为 **helloworld.tex** ，因为我正在编写本教程的 Hello，World！文档。这是编程的一个传统。）接下来，你需要在你的 **.txt** 文件顶部添加一些样板代码用于指定文档的类型和大小。 这与 HTML5 w文件中使用的样板代码类似。
|
||||
在启动 TexStudio 后，保存一份新的文档。 （我将其保存为 `helloworld.tex` ，因为我正在编写本教程的 Hello，World！文档。这是编程的一个传统。）接下来，你需要在你的 `.tex` 文件顶部添加一些样板代码用于指定文档的类型和大小。 这与 HTML5 文件中使用的样板代码类似。
|
||||
|
||||
我的代码（下方）将会把页面大小设置为 A4，文本大小设置为 12 pt 。 你可以直接把这些代码放入 TexStudio，并指定你自己的页面大小，字体大小，名称，标题和其他详细信息进行编辑：
|
||||
我的代码（如下方）将会把页面大小设置为 A4，文本大小设置为 12pt 。 你可以直接把这些代码放入 TexStudio，并指定你自己的页面大小、字体大小、名称、标题和其他详细信息进行编辑：
|
||||
|
||||
```
|
||||
\documentclass[a4paper,12pt]{article}
|
||||
@ -41,33 +39,27 @@ content will go here
|
||||
|
||||
接下来，点击那个大的绿色箭头来编译该文档。就是下方截图中的中间的那个按钮。
|
||||
|
||||
### [compile.png][2]
|
||||
|
||||
|
||||
|
||||
如果这期间发生了什么错误，它将显示在底部的对话框里。
|
||||
|
||||
在你编译了这个文档之后，你可以看到它就像一个 PDF 一样显示在程序的 WYSIWYG (所见即所得) 预览区域中。记住一旦你修改了代码就必须重新编译，就像我们在 C++ 中编程一样。
|
||||
在你编译了这个文档之后，你可以看到它就像一个 PDF 一样显示在程序的 WYSIWYG （所见即所得）预览区域中。记住一旦你修改了代码就必须重新编译，就像我们在 C++ 中编程一样。
|
||||
|
||||
通过点击 **Tools > Commands > View PDF** 可以来预览你的文档，如下截图所示。
|
||||
|
||||
### [view_as_pdf.png][3]
|
||||
|
||||
|
||||
|
||||
PDF 的输出将会显示在右侧，就像这样：
|
||||
|
||||
### [pdf_output.png][4]
|
||||
|
||||
|
||||
|
||||
现在你可以添加一个段落。首先先通过 **\section{}** 命令来写一个子标题。在命令的大括号中输入你的子标题；我写的是 **Introduction**.
|
||||
现在你可以添加一个段落。首先先通过 `\section{}` 命令来写一个子标题。在命令的大括号中输入你的子标题；我写的是 `Introduction`。
|
||||
|
||||
```
|
||||
\section{Introduction}
|
||||
```
|
||||
|
||||
现在你已经给你的段落标记了一个子标题，是时候来写一个段落了。在这个例子中，我使用了 Lipsum [lorem ipsum 生成器][11]。要创建一个段落，要使用 **\paragraph{}** 命令， 将你的文本插入到 **\maketitle** 和 **\end{document}** 之间的的 **\paragraph{}** 大括号下方，而不是中间。
|
||||
现在你已经给你的段落标记了一个子标题，是时候来写一个段落了。在这个例子中，我使用了 Lipsum 的 [lorem ipsum 生成器][11]。要创建一个段落，要使用 `\paragraph{}` 命令， 将你的文本插入到 `\maketitle` 和 `\end{document}` 之间的 `\paragraph{}` 大括号下方，而不是中间。
|
||||
|
||||
以下就是我创建的段落的代码：
|
||||
|
||||
@ -85,8 +77,6 @@ Mauris efficitur vitae ex id egestas. Vestibulum ligula felis, pulvinar a posuer
|
||||
|
||||
这是一个我已经完成的文档及其相应的代码：
|
||||
|
||||
### [finished_document.png][5]
|
||||
|
||||
|
||||
|
||||
本教程所有的代码如下所示：
|
||||
@ -112,7 +102,9 @@ Mauris efficitur vitae ex id egestas. Vestibulum ligula felis, pulvinar a posuer
|
||||
|
||||
### 更多
|
||||
|
||||
在 LaTeX 撰写的数以千计的优秀资源中，大多数大学制作的指南是可索引的，同时也可以在 Google 搜索中找到。 [普林斯顿大学 University][12] 提供了一个很好的扩展教程，为了更深入的了解，普林斯顿大学的导师 Donald Knuth 提供了 [The TexBook][13]，这是关于 LaTeX 的最好的教程。
|
||||
在 LaTeX 撰写的数以千计的优秀资源中，大多数大学制作的指南是可索引的，同时也可以在 Google 搜索中找到。 [普林斯顿大学][12] 提供了一个很好的扩展教程，为了更深入的了解，普林斯顿大学的导师 Donald Knuth 提供了 [The TexBook][13]，这是关于 LaTeX 的最好的教程。
|
||||
|
||||
（题图 : opensource.com）
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -125,9 +117,9 @@ Aaron Cocker - 一名在英国上大学的计算机学士。我是一个有抱
|
||||
|
||||
via: https://opensource.com/article/17/6/introduction-latex
|
||||
|
||||
作者：[ Aaron Cocker][a]
|
||||
作者：[Aaron Cocker][a]
|
||||
译者：[chenxinlong](https://github.com/chenxinlong)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,67 +0,0 @@
|
||||
translating------geekpi
|
||||
|
||||
7 ways to discuss legal matters with an open community
|
||||
============================================================
|
||||
|
||||
> Are your organization's lawyers ready to engage an open community? Don't let them make these mistakes.
|
||||
|
||||
|
||||
|
||||
>Image by : opensource.com
|
||||
|
||||
Having watched a fair number of people attempt to engage both the [Open Source Initiative's licensing evaluation community][3] and the [Apache Software Foundation's legal affairs committee][4], I'd like to offer some hints and tips for succeeding when it's _your_ turn to conduct a legal discussion with an open community.
|
||||
|
||||
### No proxies
|
||||
|
||||
First and foremost, make sure the person conducting the conversation is both _qualified_ and _empowered_ . Don't send proxies; they simply frustrate the community, who quickly work out that your representative is always playing the second-hand car salesman and going to the back room to ask for a deal. Obviously, legal discussions will involve a team at your company, probably involving product management, engineering and in-house counsel. But the representative needs to be able to hold the conversation themselves and not keep delivering cut paste quotes from anonymous personae behind the curtain.
|
||||
|
||||
### Multilaterality
|
||||
|
||||
An open source community reaches a hard-won consensus on the certainties they need in order to collaborate safely. That consensus gets embodied in their governance and especially in the open source license they use. So when you come with a new proposal, it's not like a normal business deal. Those are bilateral negotiations, trading the freedoms of the two parties to create a peace treaty that's an optimal compromise. In this discussion you are just one of many, many parties, and you need to explain why your proposal is good for everyone. Negotiating multilateral change is inherently slow, so don't come with a deadline. And whatever you do, don't suggest changes to the open source license!
|
||||
|
||||
### Study first
|
||||
|
||||
The existing consensus and process exists for a reason. You should understand the reason for each element, preferably along with the history of how it arose, before suggesting changes to it. That way you can couch your proposals in the context of further evolution, and you can avoid being schooled in community history (something that wastes community bandwidth and reduces your chances of effectiveness). Read back through the mailing list and ask your developer colleagues for history and context.
|
||||
|
||||
### Transparency
|
||||
|
||||
Open source developers use a process of iterative, incremental change. Even if a big change is needed, it will almost always be delivered as a sequence of smaller, well-explained or self-evidently correct changes so that everyone can follow along and buy in to the improvement. The same is true of your proposed change. Don't show up with a new contributor agreement or a modified license and expect everyone to trust that you're experts so it must all be good. You need to provide a "red-line" (the legal document equivalent of a diff), document each change, and provide a justification that admits any community impact and justifies it. If you need a thing to be _just so_ for your own benefit, admit it rather than hoping no one will notice.
|
||||
|
||||
### Humility
|
||||
|
||||
So you are a hot-shot lawyer and you think only programmers use the mailing list. It's clear to you that they'll lack the experience to have a discussion, so you either send a proxy you think is their equal, dumb it all down, or propose having a one-on-one discussion with the community's chosen lawyer. I'm sorry to say that you are so, so wrong on all counts. Since the community's policy is a multilateral consensus, there is a really good chance they know why they settled on what they have now. There will be some people on the list with excellent domain-specific knowledge, likely to be better than yours. And that one-on-one thing is the ultimate insult, like asking if there is an adult you can speak with.
|
||||
|
||||
### Don't back-channel
|
||||
|
||||
There may well be a leadership body of some kind. Maybe you know the boss at the company where the VP Legal works. Perhaps you know the community's General Counsel. While asking for hints on how to navigate the process may be acceptable in some circumstances, trying to conduct a back-channel discussion or negotiation with the expectation of influencing or even determining the outcome can blow back badly. You may eventually be invited for a one-on-one discussion, but you should never demand or expect it.
|
||||
|
||||
### Become a member
|
||||
|
||||
If you do everything right, chances are that the community will respect you for it. Stick around. Build your reputation as a calm, wise contributor. Help others when they show up and make the mistakes you made (or avoided!) As a trusted participant in the "$-legal" mailing list community, you are a real asset to both the project and your employer. Keep contributing and some projects will eventually offer you a role in their governance process.
|
||||
|
||||
_An earlier version of this article [originally appeared][1] at Meshed Insights._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Simon Phipps - Computer industry and open source veteran Simon Phipps started Public Software, a European host for open source projects, and volunteers as a director at The Document Foundation. His posts are sponsored by Patreon patrons - become one if you'd like to see more!
|
||||
|
||||
------------
|
||||
|
||||
via: https://opensource.com/open-organization/17/3/legal-matters-community
|
||||
|
||||
作者：[ Simon Phipps][a]
|
||||
译者：[译者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/simonphipps
|
||||
[1]:https://meshedinsights.com/2017/02/28/engaging-communities-on-legal-matters-7-tips/
|
||||
[2]:https://opensource.com/open-organization/17/3/legal-matters-community?rate=gSFbyOzBTIipXOdeeL-GVIT1BYoC4f61FKZJ7KRg3d0
|
||||
[3]:https://opensource.org/approval
|
||||
[4]:https://www.apache.org/legal/
|
||||
[5]:https://opensource.com/user/12532/feed
|
||||
[6]:https://opensource.com/open-organization/17/3/legal-matters-community#comments
|
||||
[7]:https://opensource.com/users/simonphipps
|
||||
@ -1,58 +0,0 @@
|
||||
Linus Torvalds Explains How Linux Still Surprises and Motivates Him
|
||||
============================================================
|
||||
|
||||
|
||||
Linux Torvalds spoke with Dirk Hohndel in one of their famous “fireside chats” this week at LinuxCon China.[The Linux Foundation][1]
|
||||
|
||||
Linus Torvalds took to the stage in China for the first time Monday at [LinuxCon + ContainerCon + CloudOpen China in Beijing][3]. In front of a crowd of nearly 2,000, Torvalds spoke with VMware Head of Open Source Dirk Hohndel in one of their famous “fireside chats” about what motivates and surprises him and how aspiring open source developers can get started. Here are some highlights of their talk.
|
||||
|
||||
**What’s surprising about Linux development**
|
||||
|
||||
“What I find interesting is code that I thought was stable continually gets improved. There are things we haven’t touched for many years, then someone comes along and improves them or makes bug reports in something I thought no one used. We have new hardware, new features that are developed, but after 25 years, we still have old, very basic things that people care about and still improve.”
|
||||
|
||||
**What motivates him**
|
||||
|
||||
“I really like what I’m doing. I like waking up and having a job that is technically interesting and challenging without being too stressful so I can do it for long stretches; something where I feel I am making a real difference and doing something meaningful not just for me.”
|
||||
|
||||
“I occasionally have taken breaks from my job. The 2-3 weeks I worked on Git to get that started for example. But every time I take a longer break, I get bored. When I go diving for a week, I look forward to getting back. I never had the feeling that I need to take a longer break.”
|
||||
|
||||
**The future of Linux leadership**
|
||||
|
||||
“Our processes have not only worked for 25 years, we still have a very strong maintainer group. We complain that we don’t have enough maintainers – which is true, we only have tens of top maintainers who do the daily work of merging stuff. That’s a strong team for an open source project. And as these maintainers get older and fatter, we have new people coming in. It takes years to go from a new developer to a top maintainer, so I don’t feel that we should necessarily worry about the process and Linux for the next 20 years.”
|
||||
|
||||
**Will Linux be replaced**
|
||||
|
||||
“Maybe some new aggressive project will come along and show they can do what we do better, but I don’t worry about that. There have been lots of very successful forks of Linux. What makes people not think of them as forks is that they are harmonious. If someone says they want to do this and change everything and make the kernel so much better, my feeling is do it, prove yourself. I may think it’s a bad idea, but you can prove me wrong.”
|
||||
|
||||
**Thoughts on Git**
|
||||
|
||||
“I’m very surprised about how widely Git has spread. I’m pleased obviously, and it validates my notion of doing distributed development. At the same time, looking at most source control versions, it tends to be a huge slog and difficult to introduce a new software control version. I expected it to be limited mostly to the kernel -- as it’s tailored to what we do.”
|
||||
|
||||
“For the first 3 to 4 years, the complaint about Git was it was so different and hard to use. About 5 years ago something changed. Enough projects and developers had started using Git that it wasn’t different anymore; it was what people were used to. They started taking advantage of the development model and the feeling of security that using Git meant nothing would be corrupted or lost.”
|
||||
|
||||
“In certain circles, Git is more well known than Linux. Linux is often hidden – on an Android phone you’re running Linux, but you don’t think about it. With Git, you know you are using Git.”
|
||||
|
||||
**Forking Linux**
|
||||
|
||||
“When I sat down and wrote Git, a prime principle was that you should be able to fork and go off on your own and do something on your own. If you have forks that are friendly -- the type that prove me wrong and do something interesting that improves the kernel -- in that situation, someone can come back and say they actually improved the kernel and there are no bad feelings. I’ll take your improved code and merge it back. That’s why you should encourage forks. You also want to make it easy to take back the good ones.”
|
||||
|
||||
**How to get started as an open source developer**
|
||||
|
||||
“For me, I was always self-motivated and knew what I wanted to do. I was never told what I should look at doing. I’m not sure my example is the right thing for people to follow. There are a ton of open source projects and, if you are a beginning programmer, find something you’re interested in that you can follow for more than just a few weeks. Get to know the code so well that you get to the point where you are an expert on a code piece. It doesn’t need to be the whole project. No one is an expert on the whole kernel, but you can know an area well.
|
||||
|
||||
If you can be part of a community and set up patches, it’s not just about the coding, but about the social aspect of open source. You make connections and improve yourself as a programmer. You are basically showing off – I made these improvements, I’m capable of going far in my community or job. You’ll have to spend a certain amount of time to learn a project, but there’s a huge upside -- not just from a career aspect, but having an amazing project in your life.”
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/blog/event/lc3-china/20176/6/linus-torvalds-explains-how-linux-still-surprises-and-motivates-him
|
||||
|
||||
作者：[ THE LINUX FOUNDATION][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/lfadmin
|
||||
[1]:https://www.linux.com/licenses/category/linux-foundation
|
||||
[2]:https://www.linux.com/files/images/linus-torvalds-lc3jpg
|
||||
[3]:https://www.lfasiallc.com/linuxcon-containercon-cloudopen-china
|
||||
@ -1,3 +1,5 @@
|
||||
zhousiyu325 翻译中......
|
||||
|
||||
NMAP OS Detection
|
||||
===================
|
||||
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
translating---geekpi
|
||||
|
||||
Automatically Create/Remove And Mount Swap File In Linux Using Shell Script
|
||||
============================================================
|
||||
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
Translating by cycoe
|
||||
|
||||
Installing Fedora 26 Beta on a MacBook Air
|
||||
======================
|
||||
|
||||
|
||||
@ -1,3 +1,4 @@
|
||||
wcnnbdk1 translating
|
||||
How To kill An Inactive OR Idle SSH Sessions
|
||||
============================================================
|
||||
|
||||
|
||||
@ -0,0 +1,65 @@
|
||||
与开放社区讨论法律事宜的 7 种方式
|
||||
============================================================
|
||||
|
||||
> 你的组织的律师准备好参加开放社区了么？不要让他们犯这些错。
|
||||
|
||||
|
||||
|
||||
>图片提供： opensource.com
|
||||
|
||||
我注意到有相当多的人尝试同时参与[开源倡议的许可评估社区] [3]以及[ Apache 软件基金会的法律事务委员会][4]，我想提供一些成功的提示和技巧在当轮到_你_与开放社区进行法律讨论时。
|
||||
|
||||
### 不要代理人
|
||||
|
||||
首先要确保进行谈话的人员既有_资格_，又有_授权_。不要用代理人，这只会让社区沮丧，他们很快会发现你的代表总是扮演二手车推销员的角色并且到后面的房间要求交易。显然，法律讨论将涉及公司的一个团队，可能涉及产品管理、工程和内部咨询。 但代表们需要能够自己进行谈话，不要总是引用幕后匿名人物的话。
|
||||
|
||||
### 多边主义
|
||||
|
||||
一个开源社区就安全合作所需的确定性达成了难得一致的共识。这种共识体现在其治理中，尤其是在他们使用的开源许可证中。所以当你提出一个新的提案时，这不是一个正常的商业交易。这些是双边谈判，交换双方的自由创造一个最佳妥协的和平条约。在这个讨论中，你只是许多方面之一，你需要解释为什么你的提案对所有人都有好处。谈判多边变化本质上是缓慢的，所以不要设置最后期限。无论你做什么，不要建议对开源许可证进行更改！
|
||||
|
||||
### 首先学习
|
||||
|
||||
现有的共识和过程存在一个原因。你应该了解每个元素的原因，最好连同其发生的历史一起了解，然后再提出修改。这样，你可以在进一步发展的背景下表达你的提案，这样你可以避免在社区历史中受教育（浪费社区资源，降低你机会的有效性）。回看邮件列表，并向开发人员询问历史和来龙去脉。
|
||||
|
||||
### 透明
|
||||
|
||||
开源开发人员使用一个迭代、增量修改的过程。即使需要大的变化，它几乎总是用一系列更小，更好的解释或不言而喻的正确变化来实现的，这样每个人都可以跟进并支持。你提出的更改也是如此。不要出现新的贡献者协议或者修改过的许可证，并期望每个人都相信你是专家，所以一切都是好的。你需要提供一根“红线”（相当于法律文件的差异），记录每个变化，并提供一个承认任何社区影响的里有并为其辩护。如果你_只是_为了你自己的利益需要一个东西，承认它，而不是希望没有人会注意到。
|
||||
|
||||
### 谦逊
|
||||
|
||||
你是一个炙手可热的律师，你认为只有程序员使用邮件列表。很明显，对你而言他们缺乏讨论的经验，所以你排了一个你认为是同等的代理人，简化这一切，或者提出与社区选择的律师进行一对一的讨论。 我很抱歉地说你做的都是错的。由于社区的政策是多边协商一致的，所以他们很有可能知道他们现在的决定。名单上的一些人将具有优秀的领域知识，可能会比你的更好。而且一对一这件事是终极的羞辱，就像询问是否有一个成年人可以与你说话。
|
||||
|
||||
### 不要后台渠道
|
||||
|
||||
有可能是某种领导机构。也许你认识在公司法务工作的 VP。也许你认识社区的总法律顾问。虽然在某些情况下，询问如何操控流程的提示可能是可以接受的，但试图影响甚至决定结果的方式进行后台渠道讨论或协商, 那么结果会很糟糕。你最终可能会被邀请进行一对一的讨论, 但你不应该要求或期待。
|
||||
|
||||
### 成为一个成员
|
||||
|
||||
如果你一切都做得正确，那么社区就有可能尊重你。坚持这些。作为一名冷静、机智的贡献者建立你的声誉。当人们犯你犯过的错误（或者已避免的）时，帮助他们。作为邮件列表社区的值得信赖的参与者，你是项目和雇主的真正资产。继续贡献，一些项目最终会在它们的治理中为你提供一个角色。
|
||||
|
||||
_这个文章的早期版本[最初发表][1]在 Meshed Insights 中。_
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Simon Phipps - 计算机行业和开源老手 Simon Phipps 上线了 Public Software，一个欧洲的开源项目托管，Document Foundation 的志愿者总监。他的帖子由 Patreon 赞助者赞助 - 如果你想要看更多，成为其中一个！
|
||||
|
||||
------------
|
||||
|
||||
via: https://opensource.com/open-organization/17/3/legal-matters-community
|
||||
|
||||
作者：[ Simon Phipps][a]
|
||||
译者：[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/simonphipps
|
||||
[1]:https://meshedinsights.com/2017/02/28/engaging-communities-on-legal-matters-7-tips/
|
||||
[2]:https://opensource.com/open-organization/17/3/legal-matters-community?rate=gSFbyOzBTIipXOdeeL-GVIT1BYoC4f61FKZJ7KRg3d0
|
||||
[3]:https://opensource.org/approval
|
||||
[4]:https://www.apache.org/legal/
|
||||
[5]:https://opensource.com/user/12532/feed
|
||||
[6]:https://opensource.com/open-organization/17/3/legal-matters-community#comments
|
||||
[7]:https://opensource.com/users/simonphipps
|
||||
Loading…
Reference in New Issue
Block a user