mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-18 02:00:18 +08:00
cinlen_0x05
GitHub
commit
1cd6afcf67
@ -1,5 +1,4 @@
|
||||
|
||||
在 Linux 中使用 gnome-screenshot 获取屏幕快照的综合指南
|
||||
史上最全的使用 gnome-screenshot 获取屏幕快照指南
|
||||
============================================================
|
||||
|
||||
在应用市场中有好几种屏幕截图工具，但其中大多数都是基于 GUI 的。如果你花时间在 linux 命令行上工作，而且正在寻找一款优秀的功能丰富的基于命令行的屏幕截图工具，你可能会想尝试 [gnome-screenshot][17]。在本教程中，我将使用易于理解的例子来解释这个实用程序。
|
||||
@ -14,11 +13,15 @@ Gnome-screenshot 是一款 GNOME 工具，顾名思义，它是一款用来对
|
||||
|
||||
Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出于某些原因需要重新安装这款软件程序，你可以使用下面的命令来进行安装：
|
||||
|
||||
> sudo apt-get install gnome-screeshot
|
||||
```
|
||||
sudo apt-get install gnome-screeshot
|
||||
```
|
||||
|
||||
一旦软件安装完成后，你可以使用下面的命令来启动它：
|
||||
|
||||
> gnome-screenshot
|
||||
```
|
||||
gnome-screenshot
|
||||
```
|
||||
|
||||
### Gnome-screenshot 用法/特点
|
||||
|
||||
@ -32,9 +35,11 @@ Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出
|
||||
|
||||
#### 捕获当前活动窗口
|
||||
|
||||
如何你需要的话，你可以使用 -w 选项限制到只对当前活动窗口截图。
|
||||
如何你需要的话，你可以使用 `-w` 选项限制到只对当前活动窗口截图。
|
||||
|
||||
> gnome-screenshot -w
|
||||
```
|
||||
gnome-screenshot -w
|
||||
```
|
||||
|
||||
[
|
||||
|
||||
@ -42,15 +47,19 @@ Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出
|
||||
|
||||
#### 窗口边框
|
||||
|
||||
默认情况下，这个程序会将它捕获的窗口的边框包含在内，尽管还有一个明确的命令行选项 -b 可以启用此功能（以防你在某处想使用它）。以下是如何使用这个程序的：
|
||||
默认情况下，这个程序会将它捕获的窗口的边框包含在内，尽管还有一个明确的命令行选项 `-b` 可以启用此功能（以防你在某处想使用它）。以下是如何使用这个程序的：
|
||||
|
||||
> gnome-screenshot -wb
|
||||
```
|
||||
gnome-screenshot -wb
|
||||
```
|
||||
|
||||
当然，你需要同时使用 -w 选项和 -b 选项，以便捕获的是当前活动的窗口（否则，-b 将没有作用）。
|
||||
当然，你需要同时使用 `-w` 选项和 `-b` 选项，以便捕获的是当前活动的窗口（否则，`-b` 将没有作用）。
|
||||
|
||||
更重要的是，如果你需要的话，你也可以移除窗口的边框。可以使用 -B 选项来完成。下面是你可以如何使用这个选项的一个例子:
|
||||
更重要的是，如果你需要的话，你也可以移除窗口的边框。可以使用 `-B` 选项来完成。下面是你可以如何使用这个选项的一个例子：
|
||||
|
||||
> gnome-screenshot -wB
|
||||
```
|
||||
gnome-screenshot -wB
|
||||
```
|
||||
|
||||
下面是例子的截图：
|
||||
|
||||
@ -60,15 +69,19 @@ Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出
|
||||
|
||||
#### 添加效果到窗口边框
|
||||
|
||||
在 gnome-screenshot 工具的帮助下，您还可以向窗口边框添加各种效果。这可以使用 --border-effect 选项来做到。
|
||||
在 gnome-screenshot 工具的帮助下，您还可以向窗口边框添加各种效果。这可以使用 `--border-effect` 选项来做到。
|
||||
|
||||
你可以添加这款程序所提供的任何效果，比如 'shdow' 效果（在窗口添加阴影）、'bordor' 效果（在屏幕截图周围添加矩形区域）和 'vintage' 效果（使截图略微淡化，着色并在其周围添加矩形区域）。
|
||||
你可以添加这款程序所提供的任何效果，比如 `shadow` 效果（在窗口添加阴影）、`bordor` 效果（在屏幕截图周围添加矩形区域）和 `vintage` 效果（使截图略微淡化，着色并在其周围添加矩形区域）。
|
||||
|
||||
> gnome-screenshot --border-effect=[EFFECT]
|
||||
```
|
||||
gnome-screenshot --border-effect=[EFFECT]
|
||||
```
|
||||
|
||||
例如，运行下面的命令添加 shadow 效果：
|
||||
|
||||
> gnome-screenshot –border-effect=shadow
|
||||
```
|
||||
gnome-screenshot –border-effect=shadow
|
||||
```
|
||||
|
||||
以下是 shadow 效果的示例快照：
|
||||
|
||||
@ -80,11 +93,13 @@ Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出
|
||||
|
||||
#### 对特定区域的截图
|
||||
|
||||
如何你需要，你还可以使用 gnome-screenshot 程序对你电脑屏幕的某一特定区域进行截图。这可以通过使用 -a 选项来完成。
|
||||
如何你需要，你还可以使用 gnome-screenshot 程序对你电脑屏幕的某一特定区域进行截图。这可以通过使用 `-a` 选项来完成。
|
||||
|
||||
> gnome-screenshot -a
|
||||
```
|
||||
gnome-screenshot -a
|
||||
```
|
||||
|
||||
当上面的命令被运行后，你的鼠标指针将会变成'+'这个符号。在这种模式下，你可以按住鼠标左键移动鼠标来对某个特定区域截图。
|
||||
当上面的命令被运行后，你的鼠标指针将会变成 '+' 这个符号。在这种模式下，你可以按住鼠标左键移动鼠标来对某个特定区域截图。
|
||||
|
||||
这是一个示例截图，裁剪了我的终端窗口的一小部分。
|
||||
|
||||
@ -94,9 +109,11 @@ Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出
|
||||
|
||||
#### 在截图中包含鼠标指针
|
||||
|
||||
默认情况下，每当你使用这个工具截图的时候，截的图中并不会包含鼠标指针。然而，这个程序是可以让你把指针包括进去的，你可以使用 -p 命令行选项做到。
|
||||
默认情况下，每当你使用这个工具截图的时候，截的图中并不会包含鼠标指针。然而，这个程序是可以让你把指针包括进去的，你可以使用 `-p` 命令行选项做到。
|
||||
|
||||
> gnome-screenshot -p
|
||||
```
|
||||
gnome-screenshot -p
|
||||
```
|
||||
|
||||
这是一个示例截图:
|
||||
|
||||
@ -106,13 +123,17 @@ Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出
|
||||
|
||||
#### 延时截图
|
||||
|
||||
截图时你还可以引入时间延迟。要做到这，你不得不给 --delay 选项赋予一个以秒为单位的值。
|
||||
截图时你还可以引入时间延迟。要做到这，你不需要给 `--delay` 选项赋予一个以秒为单位的值。
|
||||
|
||||
> gnome-screenshot –delay=[SECONDS]
|
||||
```
|
||||
gnome-screenshot –delay=[SECONDS]
|
||||
```
|
||||
|
||||
例如：
|
||||
|
||||
> gnome-screenshot --delay=5
|
||||
```
|
||||
gnome-screenshot --delay=5
|
||||
```
|
||||
|
||||
示例截图如下：
|
||||
|
||||
@ -122,9 +143,11 @@ Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出
|
||||
|
||||
#### 以交互模式运行这个工具
|
||||
|
||||
这个工具还允许你使用一个单独的 -i 选项来访问其所有功能。使用这个命令行选项，用户可以在运行这个命令时使用这个工具的一个或多个功能。
|
||||
这个工具还允许你使用一个单独的 `-i` 选项来访问其所有功能。使用这个命令行选项，用户可以在运行这个命令时使用这个工具的一个或多个功能。
|
||||
|
||||
> gnome-screenshot -i
|
||||
```
|
||||
gnome-screenshot -i
|
||||
```
|
||||
|
||||
示例截图如下：
|
||||
|
||||
@ -132,17 +155,21 @@ Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出
|
||||
|
||||
][25]
|
||||
|
||||
你可以从上面的截图中看到，-i 选项提供了对很多功能的访问，比如截取整个屏幕、截取当前窗口、选择一个区域进行截图、延时选项和特效选项等都在交互模式里。
|
||||
你可以从上面的截图中看到，`-i` 选项提供了对很多功能的访问，比如截取整个屏幕、截取当前窗口、选择一个区域进行截图、延时选项和特效选项等都在交互模式里。
|
||||
|
||||
#### 直接保存你的截图
|
||||
|
||||
如果你需要的话，你可以直接将你截的图片从终端中保存到你当前的工作目录，这意味着，在这个程序运行后，它并不要求你为截取的图片输入一个文件名。这个功能可以使用 --file 命令行选项来获取，很明显，需要给它传递一个文件名。
|
||||
如果你需要的话，你可以直接将你截的图片从终端中保存到你当前的工作目录，这意味着，在这个程序运行后，它并不要求你为截取的图片输入一个文件名。这个功能可以使用 `--file` 命令行选项来获取，很明显，需要给它传递一个文件名。
|
||||
|
||||
> gnome-screenshot –file=[FILENAME]
|
||||
```
|
||||
gnome-screenshot –file=[FILENAME]
|
||||
```
|
||||
|
||||
例如：
|
||||
|
||||
> gnome-screenshot --file=ashish
|
||||
```
|
||||
gnome-screenshot --file=ashish
|
||||
```
|
||||
|
||||
示例截图如下：
|
||||
|
||||
@ -152,9 +179,11 @@ Ubuntu 系统上已经预安装了 gnome-screeshot 工具，但是如果你出
|
||||
|
||||
#### 复制到剪切板
|
||||
|
||||
gnome-screenshot 也允许你把你截的图复制到剪切板。这可以通过使用 -c 命令行选项做到。
|
||||
gnome-screenshot 也允许你把你截的图复制到剪切板。这可以通过使用 `-c` 命令行选项做到。
|
||||
|
||||
> gnome-screenshot -c
|
||||
```
|
||||
gnome-screenshot -c
|
||||
```
|
||||
|
||||
[
|
||||
|
||||
@ -164,43 +193,51 @@ gnome-screenshot 也允许你把你截的图复制到剪切板。这可以通过
|
||||
|
||||
#### 多显示器情形下的截图
|
||||
|
||||
如果有多个显示器连接到你的系统，你想对某一个进行截图，那么你可以使用 --then 命令行选项。需要给这个选项一个显示器设备 ID 的值（需要被截图的显示器的ID）。
|
||||
|
||||
> gnome-screenshot --display=[DISPLAY]
|
||||
如果有多个显示器连接到你的系统，你想对某一个进行截图，那么你可以使用 `--then` 命令行选项。需要给这个选项一个显示器设备 ID 的值（需要被截图的显示器的 ID）。
|
||||
|
||||
```
|
||||
gnome-screenshot --display=[DISPLAY]
|
||||
```
|
||||
例如：
|
||||
|
||||
> gnome-screenshot --display=VGA-0
|
||||
```
|
||||
gnome-screenshot --display=VGA-0
|
||||
```
|
||||
|
||||
在上面的例子中，VAG-0 是我正试图对其进行截图的显示器的 ID。为了找到你想对其进行截图的显示器的 ID，你可以使用下面的命令：
|
||||
|
||||
> xrandr --query
|
||||
```
|
||||
xrandr --query
|
||||
```
|
||||
|
||||
为了让你明白一些，在我的例子中这个命令产生了下面的输出：
|
||||
|
||||
>**$ xrandr --query**
|
||||
```
|
||||
$ xrandr --query
|
||||
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
|
||||
**VGA-0** connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
|
||||
VGA-0 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
|
||||
1366x768 59.8*+
|
||||
1024x768 75.1 75.0 60.0
|
||||
832x624 74.6
|
||||
800x600 75.0 60.3 56.2
|
||||
640x480 75.0 60.0
|
||||
720x400 70.1
|
||||
**HDMI-0** disconnected (normal left inverted right x axis y axis)
|
||||
|
||||
HDMI-0 disconnected (normal left inverted right x axis y axis)
|
||||
```
|
||||
|
||||
#### 自动化屏幕截图过程
|
||||
|
||||
正如我们之前讨论的，-a 命令行选项可以帮助我们对屏幕的某一个特定区域进行截图。然而，我们不得不用鼠标手动选取这个区域。如果你想的话，你可以使用 gnome-screenshot 来自动化完成这个过程，但是在那种情形下，你将不得不使用一个名为 xdotol 的工具，它可以模仿敲打键盘甚至是点击鼠标这些事件。
|
||||
正如我们之前讨论的，`-a` 命令行选项可以帮助我们对屏幕的某一个特定区域进行截图。然而，我们需要用鼠标手动选取这个区域。如果你想的话，你可以使用 gnome-screenshot 来自动化完成这个过程，但是在那种情形下，你将需要使用一个名为 `xdotol` 的工具，它可以模仿敲打键盘甚至是点击鼠标这些事件。
|
||||
|
||||
例如：
|
||||
|
||||
> (gnome-screenshot -a &); sleep 0.1 && xdotool mousemove 100 100 mousedown 1 mousemove 400 400 mouseup 1
|
||||
```
|
||||
(gnome-screenshot -a &); sleep 0.1 && xdotool mousemove 100 100 mousedown 1 mousemove 400 400 mouseup 1
|
||||
```
|
||||
|
||||
mousemove 子命令自动把鼠标指针定位到明确的X坐标和Y坐标的位置（上面例子中是 100 和 100）。mousedown 子命令触发一个与点击执行相同操作的事件（因为我们想左击，所以我们使用了参数1），然而 mouseup 子命令触发一个执行用户释放鼠标按钮的任务的事件。
|
||||
`mousemove` 子命令自动把鼠标指针定位到明确的 `X` 坐标和 `Y` 坐标的位置（上面例子中是 100 和 100）。`mousedown` 子命令触发一个与点击执行相同操作的事件（因为我们想左击，所以我们使用了参数 1），然而 `mouseup` 子命令触发一个执行用户释放鼠标按钮的任务的事件。
|
||||
|
||||
所以总而言之，上面所示的 xdotool 命令做了一项本来不得不使用鼠标手动执行对同一区域进行截图的工作。特别说明，该命令把鼠标指针定位到屏幕上坐标为 100，100 的位置并选择封闭区域，直到指针到达屏幕上坐标为 400，400 的位置。所选择的区域随之被 gnome-screenshot 捕获。
|
||||
所以总而言之，上面所示的 `xdotool` 命令做了一项本来需要使用鼠标手动执行对同一区域进行截图的工作。特别说明，该命令把鼠标指针定位到屏幕上坐标为 `100,100` 的位置并选择封闭区域，直到指针到达屏幕上坐标为 `400,400` 的位置。所选择的区域随之被 gnome-screenshot 捕获。
|
||||
|
||||
这是上述命令的截图：
|
||||
|
||||
@ -214,13 +251,15 @@ mousemove 子命令自动把鼠标指针定位到明确的X坐标和Y坐标的
|
||||
|
||||
][29]
|
||||
|
||||
想获取更多关于 xdotool 的信息，[请到这来][30]。
|
||||
想获取更多关于 `xdotool` 的信息，[请到这来][30]。
|
||||
|
||||
#### 获取帮助
|
||||
|
||||
如果你有疑问或者你正面临一个与该命令行的其中某个选项有关的问题，那么你可以使用 --help、-？ 或者 -h 选项来获取相关信息。
|
||||
|
||||
> gnome-screenshot -h
|
||||
```
|
||||
gnome-screenshot -h
|
||||
```
|
||||
|
||||
### 总结
|
||||
|
||||
@ -1,15 +1,15 @@
|
||||
pyDash — 一个基于 web 的 Linux 性能监测工具
|
||||
pyDash：一个基于 web 的 Linux 性能监测工具
|
||||
============================================================
|
||||
|
||||
**pyDash** 是一个轻量且[基于 web 的 Linux 性能监测工具][1]，它是用 **Python** 和 [Django][2] 加上 **Chart.js** 来写的。经测试，在下面这些主流 Linux 发行版上可运行：CentOS、Fedora、Ubuntu、Debian、Raspbian 以及 Pidora 。
|
||||
`pyDash` 是一个轻量且[基于 web 的 Linux 性能监测工具][1]，它是用 Python 和 [Django][2] 加上 Chart.js 来写的。经测试，在下面这些主流 Linux 发行版上可运行：CentOS、Fedora、Ubuntu、Debian、Raspbian 以及 Pidora 。
|
||||
|
||||
你可以使用这个工具来监视你的 Linux 个人电脑/服务器资源，比如 CPU、内存、网络统计，包括在线用户的进程以及更多。仪表盘是完全使用主要的 Python 版本提供的 Python 库开发的，因此它的依赖关系很少，你不需要安装许多包或库来运行它。
|
||||
你可以使用这个工具来监视你的 Linux 个人电脑/服务器资源，比如 CPU、内存、网络统计，包括在线用户的进程以及更多。仪表盘完全由主要的 Python 发行版本所提供的 Python 库开发，因此它的依赖关系很少，你不需要安装许多包或库来运行它。
|
||||
|
||||
在这篇文章中，我将展示如果安装 **pyDash** 来监测 Linux 服务器性能。
|
||||
在这篇文章中，我将展示如何安装 `pyDash` 来监测 Linux 服务器性能。
|
||||
|
||||
#### 如何在 Linux 系统下安装 pyDash
|
||||
### 如何在 Linux 系统下安装 pyDash
|
||||
|
||||
１、首先，像下面这样安装需要的软件包 **git** 和 **Python pip**：
|
||||
1、首先，像下面这样安装需要的软件包 `git` 和 `Python pip`：
|
||||
|
||||
```
|
||||
-------------- 在 Debian/Ubuntu 上 --------------
|
||||
@ -21,7 +21,7 @@ $ sudo apt-get install git python-pip
|
||||
# dnf install git python-pip
|
||||
```
|
||||
|
||||
２、如果安装好了 git 和 Python pip，那么接下来，像下面这样安装 **virtualenv**，它有助于处理针对 Python 项目的依赖关系：
|
||||
2、如果安装好了 git 和 Python pip，那么接下来，像下面这样安装 `virtualenv`，它有助于处理针对 Python 项目的依赖关系：
|
||||
|
||||
```
|
||||
# pip install virtualenv
|
||||
@ -29,14 +29,14 @@ $ sudo apt-get install git python-pip
|
||||
$ sudo pip install virtualenv
|
||||
```
|
||||
|
||||
３、现在，像下面这样使用 git 命令，把 pyDash 仓库克隆到 home 目录中：
|
||||
3、现在，像下面这样使用 `git` 命令，把 pyDash 仓库克隆到 home 目录中：
|
||||
|
||||
```
|
||||
# git clone https://github.com/k3oni/pydash.git
|
||||
# cd pydash
|
||||
```
|
||||
|
||||
４、下一步，使用下面的 **virtualenv** 命令为项目创建一个叫做 **pydashtest** 虚拟环境：
|
||||
4、下一步，使用下面的 `virtualenv` 命令为项目创建一个叫做 `pydashtest` 虚拟环境：
|
||||
|
||||
```
|
||||
$ virtualenv pydashtest #give a name for your virtual environment like pydashtest
|
||||
@ -47,9 +47,9 @@ $ virtualenv pydashtest #give a name for your virtual environment like pydashtes
|
||||
|
||||
*创建虚拟环境*
|
||||
|
||||
重要：请注意，上面的屏幕截图中，虚拟环境的 bin 目录被高亮显示，你的可能和这不一样，取决于你把 pyDash 目录克隆到什么位置。
|
||||
重要：请注意，上面的屏幕截图中，虚拟环境的 `bin` 目录被高亮显示，你的可能和这不一样，取决于你把 pyDash 目录克隆到什么位置。
|
||||
|
||||
５、创建好虚拟环境（**pydashtest**）以后，你需要在使用前像下面这样激活它：
|
||||
5、创建好虚拟环境（`pydashtest`）以后，你需要在使用前像下面这样激活它：
|
||||
|
||||
```
|
||||
$ source /home/aaronkilik/pydash/pydashtest/bin/activate
|
||||
@ -60,16 +60,16 @@ $ source /home/aaronkilik/pydash/pydashtest/bin/activate
|
||||
|
||||
*激活虚拟环境*
|
||||
|
||||
从上面的屏幕截图中，你可以注意到，提示字符串 1（**PS1**）已经发生改变，这表明虚拟环境已经被激活，而且可以开始使用。
|
||||
从上面的屏幕截图中，你可以注意到，提示字符串 1（`PS1`）已经发生改变，这表明虚拟环境已经被激活，而且可以开始使用。
|
||||
|
||||
６、现在，安装 pydash 项目 requirements；如何你好奇的话，可以使用 [cat 命令][5]查看 **requirements.txt** 的内容，然后像下面所示那样进行安装：
|
||||
6、现在，安装 pydash 项目 requirements；如何你好奇的话，可以使用 [cat 命令][5]查看 `requirements.txt` 的内容，然后像下面所示那样进行安装：
|
||||
|
||||
```
|
||||
$ cat requirements.txt
|
||||
$ pip install -r requirements.txt
|
||||
```
|
||||
|
||||
７、现在，进入 `pydash` 目录，里面包含一个名为 `settings.py` 的文件，也可直接运行下面的命令打开这个文件，然后把 `SECRET_KEY` 改为一个特定值：
|
||||
7、现在，进入 `pydash` 目录，里面包含一个名为 `settings.py` 的文件，也可直接运行下面的命令打开这个文件，然后把 `SECRET_KEY` 改为一个特定值：
|
||||
|
||||
```
|
||||
$ vi pydash/settings.py
|
||||
@ -82,7 +82,7 @@ $ vi pydash/settings.py
|
||||
|
||||
保存文件然后退出。
|
||||
|
||||
８、之后，运行下面的命令来创建一个项目数据库和安装 Django 的身份验证系统，并创建一个项目的超级用户：
|
||||
8、之后，运行下面的命令来创建一个项目数据库和安装 Django 的身份验证系统，并创建一个项目的超级用户：
|
||||
|
||||
```
|
||||
$ python manage.py syncdb
|
||||
@ -103,13 +103,13 @@ Password (again): ############
|
||||
|
||||
*创建项目数据库*
|
||||
|
||||
９、这个时候，一切都设置好了，然后，运行下面的命令来启用 Django 开发服务器：
|
||||
9、这个时候，一切都设置好了，然后，运行下面的命令来启用 Django 开发服务器：
|
||||
|
||||
```
|
||||
$ python manage.py runserver
|
||||
```
|
||||
|
||||
１０、接下来，打开你的 web 浏览器，输入网址：**http://127.0.0.1:8000/** 进入 web 控制台登录界面，输入你在第 8 步中创建数据库和安装 Django 身份验证系统时创建的超级用户名和密码，然后点击登录。
|
||||
10、接下来，打开你的 web 浏览器，输入网址：`http://127.0.0.1:8000/` 进入 web 控制台登录界面，输入你在第 8 步中创建数据库和安装 Django 身份验证系统时创建的超级用户名和密码，然后点击登录。
|
||||
|
||||
[
|
||||
|
||||
@ -117,7 +117,7 @@ $ python manage.py runserver
|
||||
|
||||
*pyDash 登录界面*
|
||||
|
||||
１１、登录到 pydash 主页面以后，你将会可以看到监测系统的基本信息，包括 CPU、内存和硬盘使用量以及系统平均负载。
|
||||
11、登录到 pydash 主页面以后，你将会可以看到监测系统的基本信息，包括 CPU、内存和硬盘使用量以及系统平均负载。
|
||||
|
||||
向下滚动便可查看更多部分的信息。
|
||||
|
||||
@ -127,7 +127,7 @@ $ python manage.py runserver
|
||||
|
||||
*pydash 服务器性能概述*
|
||||
|
||||
１２、下一个屏幕截图显示的是一段 pydash 的跟踪界面，包括 IP 地址、互联网流量、硬盘读/写、在线用户以及 netstats 。
|
||||
12、下一个屏幕截图显示的是一段 pydash 的跟踪界面，包括 IP 地址、互联网流量、硬盘读/写、在线用户以及 netstats 。
|
||||
|
||||
[
|
||||
|
||||
@ -135,7 +135,7 @@ $ python manage.py runserver
|
||||
|
||||
*pyDash 网络概述*
|
||||
|
||||
１３、下一个 pydash 主页面的截图显示了一部分系统中被监视的活跃进程。
|
||||
13、下一个 pydash 主页面的截图显示了一部分系统中被监视的活跃进程。
|
||||
|
||||
|
||||
[
|
||||
@ -160,7 +160,7 @@ $ python manage.py runserver
|
||||
|
||||
via: http://www.tecmint.com/pydash-a-web-based-linux-performance-monitoring-tool/
|
||||
|
||||
作者：[Ravi Saive ][a]
|
||||
作者：[Ravi Saive][a]
|
||||
译者：[ucasFL](https://github.com/ucasFL)
|
||||
校对：[jasminepeng](https://github.com/jasminepeng)
|
||||
|
||||
@ -1,3 +1,4 @@
|
||||
＋＋＋＋翻译中＋＋＋＋＋＋
|
||||
How to set up a Continuous Integration server for Android development (Ubuntu + Jenkins + SonarQube)
|
||||
============================================================
|
||||
|
||||
|
||||
@ -1,69 +0,0 @@
|
||||
＋＋＋
|
||||
＋＋翻译中
|
||||
+++++
|
||||
The 6 unwritten rules of open source development
|
||||
============================================================
|
||||
|
||||
> Do you want to be a successful and valued member of an open source project? Follow these unwritten rules
|
||||
|
||||
|
||||
|
||||
|
||||
>_Matt Hicks is vice president of software engineering at Red Hat and one of the founding members of the Red Hat OpenShift team. He has spent 15 years in software engineering with a variety of roles in development, operations, architecture, and management._
|
||||
|
||||
The sports world is rife with unwritten rules. These are the behaviors and rituals that are observed but rarely documented in an official capacity. For example, in baseball, unwritten rules range from not stealing bases when well ahead to never giving up an intentional walk when there’s a runner on first. To outsiders, these are esoteric, perhaps even nonsensical guidelines, but they are followed by every player who wants to be a valued teammate and respected opponent.
|
||||
|
||||
Software development, particularly _open source_ software development, also has an invisible rulebook. As in other team sports, these rules can have a significant impact on how an open source community treats a developer, especially newcomers.
|
||||
|
||||
|
||||
### Walk before you run
|
||||
|
||||
Before interacting with any community, open source or otherwise, you need to do your homework. For prospective open source contributors, this means understanding the community’s mission and learning where you can help from the onset. Everyone wants to contribute code, but far fewer developers are ready, willing, and able to do the grunt work: testing patches, reviewing code, sifting through documentation and correcting errors, and all of those other generally undesirable tasks that are required for a healthy community.
|
||||
|
||||
Why do this when you can start cranking out beautiful lines of code? It’s about trust and, more important, showing that you care about the community as a whole and not developing only the features that you care about.
|
||||
|
||||
|
||||
### Make an impact, not a crater
|
||||
|
||||
As you build up your reputation with a given open source community, it’s important to develop a broad understanding of the project and the code base. Don’t stop at the mission statement; dive into the project itself and understand what makes it tick outside of your own area of expertise. Beyond broadening your own understanding as a developer, this helps you gain insight into how your code contributions could impact the larger project, not only your little piece of the pie.
|
||||
|
||||
For example, maybe you want to create a revision to a networking module. You build it and test it, and it looks good, so you send it off to the community for more testing. As it turns out, this module breaks a security setting or causes a major storage incident when deployed in a certain manner -- issues that could have been remedied had you looked at the code base as a whole rather than your piece alone. Showing that you have a broad understanding of how various parts of the project interact with others -- and developing your patches to make an impact, not a crater -- will go a long way toward making your contributions appreciated.
|
||||
|
||||
### Patch bombing is not OK
|
||||
|
||||
Your work is not over when your code is submitted. There will be discussion about the change and a lot of QA and testing yet to be done if accepted. You want to make sure you are putting in the time and effort to understand how you can move your code and patches forward without them becoming a burden on other members.
|
||||
|
||||
### Help others before helping yourself
|
||||
|
||||
Open source communities aren’t a dog-eat-dog world; they’re about putting the value of the project before individual contributions and individual success. If you want to increase your odds of being seen as a valued member of the community (and get your code accepted), help others with their efforts. If you know about networking, review networking modules -- apply your expertise to make the whole code base better. It’s no surprise that top reviewers often correlate to top contributors. The more you help, the more valued you are.
|
||||
|
||||
### Address the edge
|
||||
|
||||
As a developer, you’re likely looking to contribute to an open source project to address a particular pain point. Maybe your preferred operating system isn’t supported or you desperately want to modernize the security technology used by the community. The best way to introduce changes, especially more aggressive ones, is to make them impossible to refuse. Know enough about the code base to think through every edge case. Add capabilities without breaking existing functionality. Pour your energy into the completeness of your feature, not only the submission.
|
||||
|
||||
### Don’t give up
|
||||
|
||||
Open source communities have plenty of fly-by-night members, but with commitment comes credibility. Don’t merely walk away when a patch is rejected. Find out why it was rejected, make those fixes, and try again. As you work on your patch, keep up with changes to the code base and make sure your patch remains mergeable as the project evolves. Don’t leave it to others to patch up your patch. As the author, take the burden on yourself and keep other community members free to do the same with their work.
|
||||
|
||||
These unwritten rules might seem simple, but too many open source contributors don’t follow them. Developers who do so will not only succeed in advancing a project for themselves; they will help to advance open source in general.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.infoworld.com/article/3156776/open-source-tools/the-6-unwritten-rules-of-open-source-development.html
|
||||
|
||||
作者：[Matt Hicks][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.infoworld.com/blog/new-tech-forum/
|
||||
[1]:https://twitter.com/intent/tweet?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html&via=infoworld&text=The+6+unwritten+rules+of+open+source+development
|
||||
[2]:https://www.facebook.com/sharer/sharer.php?u=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html
|
||||
[3]:http://www.linkedin.com/shareArticle?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html&title=The+6+unwritten+rules+of+open+source+development
|
||||
[4]:https://plus.google.com/share?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html
|
||||
[5]:http://reddit.com/submit?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html&title=The+6+unwritten+rules+of+open+source+development
|
||||
[6]:http://www.stumbleupon.com/submit?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html
|
||||
[7]:http://www.infoworld.com/article/3156776/open-source-tools/the-6-unwritten-rules-of-open-source-development.html#email
|
||||
[8]:http://www.infoworld.com/article/3152565/linux/5-rock-solid-linux-distros-for-developers.html#tk.ifw-infsb
|
||||
[9]:http://www.infoworld.com/newsletters/signup.html#tk.ifw-infsb
|
||||
@ -0,0 +1,61 @@
|
||||
六个开源开发的＂潜规则＂
|
||||
============================================================
|
||||
|
||||
你想成为开源项目中得意满满,功成名就的那个人吗,那就要遵守下面的＂潜规则＂
|
||||
|
||||
|
||||
|
||||
|
||||
Matt Hicks 是 Red Hat软件工程的副主席，也是 Red Hat 开源合作团队的奠基成员之一．他历时十五年，在软件工程中担任多种职务：开发，运行，架构，管理．
|
||||
|
||||
正如体育界不成文的规定一样，这些规则基本上不会在官方文档上，正式记录．比如说，在棒球运动中，从井口跑法时不要偷球，到有人第一时候不要放弃全力疾走．对于圈外人来讲，这些东西很难懂，甚至觉得没什么意义．但是对于那些想成为 MVP 的队员来说，这些都是理所应当的．
|
||||
|
||||
软件开发，特别是开源软件开发中,也有一套不成文的规定．和其他团队运动一样，这些规定很大程度上决定了开源社区如何看待一名开发者，特别是小白．
|
||||
|
||||
运行之前先调试
|
||||
|
||||
在与社区互动前，开放源代码，或者其他什么的，你需要做一下基本工作．对于有眼界的开源贡献者，这意味这你需要理解社区的目标，从头学习．人人都想贡献源代码，但是只有少量的人做过准备，并且乐意，有能力完成这项艰苦卓绝的工作：测试补丁，检查代码，写文档，校正错误．所有的这些不受待见的任务在一个健康的社区中都需要有人去完成．
|
||||
|
||||
为什么要在优雅地码代码前做这些呢？这是一种信任，更重要的是，不要只关注自己开发的功能，而是要关注整个社区的动向
|
||||
|
||||
填坑而不是挖坑
|
||||
|
||||
当你在特定的社区中建立起自己的声望，那么很有必要去深入理解项目，和基础代码．不要在任务状态上停留，要去钻研项目本身，理解那些超出你擅长范围之外的知识．不要只把自己的理解局限于开发者．这样你会获得一种洞察力，让你的代码有更大的影响，而不只是你那一亩三分地．
|
||||
|
||||
打个比方，你已经完成了一个网络模块的测试版本．你测试了一下，觉得不错．然后你把它开放到社区，想要更多的人测试．结果发现，如果将它运行在特定的管理器中，它有可能损害安全设置，还可能导致主存泄露．这个问题本可以在基础代码阶段就被解决，而不需要单独测试时候才发现．这说明，你要对项目各个部分如何与其他人协作交互有比较深的理解．让你的补丁填坑而不是挖坑．这样你朝成为社区大牛的目标上又前进了一大步．
|
||||
|
||||
不要投放代码炸弹
|
||||
|
||||
代码提交完毕你的工作还没结束．你还要想一想以后的改变，和常见的问答，测试也没有完成．你要确保你可以准时提交，努力去理解如何在不影响社区其他成员的情况下，运行和修复代码．
|
||||
|
||||
助己前先助人
|
||||
开源社区不是自相残杀的世界，我们更看重项目的价值而非个体的贡献和成功．如果你想给自己加分，让自己成为更厉害的社区成员，那就努力帮助别人．如果你熟悉网络部分，那就审查网络模块，用你的专业技能让整个代码更加优雅．很简单的道理，顶级的审查者经常和顶级的贡献者打交道．你帮助的越多，你就越有价值
|
||||
|
||||
作为一个开发者，你很可能需要开源项目中解决一个你十分头痛的技术点．可能你更想运行在一个目前还不支持的系统，你超想改革社区目前使用的安全技术．想要引进新技术，特别是比较有争议的技术，最好的办法就是让人无法拒绝它．你需要透彻地了解底层代码，考虑每一个微小的优势．在不影响已实现功能的前提下增加新功能．不仅要在计划上下功夫，还要在特性的完善上下功夫．
|
||||
|
||||
不要放弃
|
||||
|
||||
开源社区也有多不靠谱的成员，所以提交中可靠性高的才能被采用．不要只是因为提交被上游拒绝就离开社区．找出原因，修正错误，然后再试一试．当你开发时候，要和基础代码保持一致，确保即使项目进化你的代码仍然可用．不要把你的代码留给别人修复，要自己修复．这样可以在社区形成良好的风气，每个人都自己改．
|
||||
|
||||
这些＂潜规则＂看上去很简单，但是还是有许多开源项目的贡献者并没有遵守．成功的开发者不仅可以成功地为自己完成项目，还可以帮助开源社区．
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.infoworld.com/article/3156776/open-source-tools/the-6-unwritten-rules-of-open-source-development.html
|
||||
|
||||
作者：[Matt Hicks][a]
|
||||
译者：[Taylor1024](https://github.com/Taylor1024)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.infoworld.com/blog/new-tech-forum/
|
||||
[1]:https://twitter.com/intent/tweet?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html&via=infoworld&text=The+6+unwritten+rules+of+open+source+development
|
||||
[2]:https://www.facebook.com/sharer/sharer.php?u=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html
|
||||
[3]:http://www.linkedin.com/shareArticle?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html&title=The+6+unwritten+rules+of+open+source+development
|
||||
[4]:https://plus.google.com/share?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html
|
||||
[5]:http://reddit.com/submit?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html&title=The+6+unwritten+rules+of+open+source+development
|
||||
[6]:http://www.stumbleupon.com/submit?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html
|
||||
[7]:http://www.infoworld.com/article/3156776/open-source-tools/the-6-unwritten-rules-of-open-source-development.html#email
|
||||
[8]:http://www.infoworld.com/article/3152565/linux/5-rock-solid-linux-distros-for-developers.html#tk.ifw-infsb
|
||||
[9]:http://www.infoworld.com/newsletters/signup.html#tk.ifw-infsb
|
||||
Loading…
Reference in New Issue
Block a user