mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
cinlen_0x05
GitHub
commit
b75e3eea54
@ -0,0 +1,87 @@
|
||||
开发者的实用 Vim 插件（三）
|
||||
============================================================
|
||||
|
||||
目前为止，在一系列介绍 vim 插件文章中，我们介绍了使用 Pathogen 插件管理包安装基本的 vim 插件，也提及了另外三个插件：[Tagbar、delimitMate](https://linux.cn/article-7901-1.html) 和 [Syntastic](https://linux.cn/article-7909-1.html)。现在，在最后一部分，我们将介绍另一个十分有用的插件 a.vim。
|
||||
|
||||
请注意所有本篇教程所提及的例子、命令和指导，它们已经在 Ubuntu 16.04 测试完毕，vim 使用版本为 vim7.4 （LCTT 译注：Ubuntu 16.04 的默认版本）
|
||||
|
||||
### A.vim
|
||||
|
||||
如果你一直用像 C、C++ 这样的语言进行开发工作，你一定有这样的感触：我特么已经数不清我在头文件和源代码之间切换过多少次了。我想说的是，确实，这个操作十分基本，十分频繁。
|
||||
|
||||
尽管使用基于 GUI（图形界面）的 IDE（集成开发环境）非常容易通过鼠标的双击切换文件，但是如果你是资深 vim 粉，习惯用命令工作就有点尴尬了。但是不要害怕，我有秘籍－－插件 a.vim。它可以让你解决尴尬，专治各种文件切换。
|
||||
|
||||
在我们介绍这个神器用法之前，我必须强调一点：这个插件的安装过程和我们其他篇介绍的不太一样，步骤如下：
|
||||
|
||||
* 首先，你需要下载两个文件（a.vim 和 alternate.txt），你可以在[这里][1]找到它们。
|
||||
* 接下来，创建如下目录：`~/.vim/bundle/avim`、`~/.vim/bundle/avim/doc`、 `~/.vim/bundle/avim/plugin` 和 `~/.vim/bundle/autoload`。
|
||||
* 创建好目录之后，将 `a.vim` 放到 `~/.vim/bundle/avim/plugin` 和 `~/.vim/bundle/autoload`，以及将 `alternate.txt` 放到 `~/.vim/bundle/avim/doc`。
|
||||
|
||||
就是这样，如果上述步骤被你成功完成，你的系统就会安装好这个插件。
|
||||
|
||||
使用这个插件十分简单，你仅仅需要运行这个命令 `:A` 如果目前的文件是源文件（比如 `test.c`），这个神器就会帮你打开 `test.c` 对应的头文件（`test.h`），反之亦然。
|
||||
|
||||
当然咯，不是每个文件对应的头文件都存在。这种情况下，如果那你运行 `:A` 命令，神器就会为你新建一个文件。比如，如果 `test.h` 不存在，那么运行此命令就会帮你创建一个 `test.h`，然后打开它。
|
||||
|
||||
如果你不想要神器开启此功能，你可以在你的家目录的隐藏文件 `.vimrc` 中写入 `g:alternateNonDefaultAlternate` 变量，并且赋给它一个非零值即可。
|
||||
|
||||
还有一种情况也很普遍，你需要打开的文件并非是当前源代码的头文件。比如你目前在 `test.c` 你想打开 `men.h` 这个头文件，那么你可以输入这个命令 `:IH <filename>` ，毋需赘言，你肯定要在后面输入你要打开的的文件名称 `<filename>`。
|
||||
|
||||
目前为止，我们讨论的功能都仅限于你当前文件和要操作的文件都在同一个目录去实现。但是，你也知道，我们还有特殊情况，我是说，许多项目中头文件与对应的源文件并不一定在同一目录下。
|
||||
|
||||
为了搞定这个问题，你要使用这个 `g:alternateSearchPath` 这个变量。官方文档是这么[解释](https://github.com/csliu/a.vim/blob/master/doc/alternate.txt)的：
|
||||
|
||||
> 这个插件可以让用户配置它的搜索源文件和头文件的搜索路径。这个搜索路径可以通过设置 `g:alternateSearchPath` 这个变量的值指定。默认的设定如下：
|
||||
|
||||
> ```
|
||||
> g:alternateSearchPath = 'sfr:../source,sfr:../src,sfr:../include,sfr:../inc'
|
||||
> ```
|
||||
|
||||
> 使用这个代码表示神器将搜索 `../source`、`../src`、`../include` 和 `../inc` 下所有与目标文件相关的文件。 `g:alternateSearchPath` 变量的值由前缀和路径组成，每个单元用逗号隔开。 `sfr` 前缀是指后面的路径是相对于目前文件的，`wdr` 前缀是指目录是相对于目前的工作目录， `abs` 是指路径是绝对路径。如果不指定前缀，那么默认为 `sfr`。
|
||||
|
||||
如果我们前文所提及的特性就能让你觉得很炫酷，那我不得不告诉你，这才哪跟哪。还有一个十分有用的功能是分割 Vim 屏幕，这样你就可以同时看到头文件和相应的源文件。
|
||||
|
||||
哦，还有，你还可以选择垂直或者水平分割。全凭你心意。使用 `:AS` 命令可以水平分割，使用 `:AV` 可以垂直分割。
|
||||
|
||||
[
|
||||
|
||||
][5]
|
||||
|
||||
[
|
||||
|
||||
][6]
|
||||
|
||||
使用 `:A` 命令在已经打开的文件中切换。
|
||||
|
||||
这个插件还可以让你在同一个 Vim 窗口中不同选项卡中打开多个相应的文件，你键入这个命令 `:AT`。
|
||||
|
||||
[
|
||||
|
||||
][7]
|
||||
|
||||
当然，你可以用这些命令 `:AV`、`:AS` 和 `:AT`，也可以使用这些命令 `:IHV`、`:IHS` 和 `:IHT`。
|
||||
|
||||
### 最后
|
||||
|
||||
还有许多和编程相关的 Vim 的插件，我们在这个三篇系列主要讨论的是，如果你为你的软件开发工作安装了合适的插件，你就会明白为什么 vim 被叫做编辑器之神。
|
||||
|
||||
当然，我们在这只关注编程方面，对于那些把 Vim 当做日常文档编辑器的人来说，你也应该了解一些 Vim 的插件，让你的编辑更好，更高效．我们就改日再谈这个问题吧。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.howtoforge.com/tutorial/vim-editor-plugins-for-software-developers-3/
|
||||
|
||||
作者：[Ansh][a]
|
||||
译者：[Taylor1024](https://github.com/Taylor1024)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.howtoforge.com/tutorial/vim-editor-plugins-for-software-developers-3/
|
||||
[1]:http://www.vim.org/scripts/script.php?script_id=31
|
||||
[2]:https://www.howtoforge.com/tutorial/vim-editor-plugins-for-software-developers/
|
||||
[3]:https://www.howtoforge.com/tutorial/vim-editor-plugins-for-software-developers-2-syntastic/
|
||||
[4]:https://github.com/csliu/a.vim/blob/master/doc/alternate.txt
|
||||
[5]:https://www.howtoforge.com/images/vim-editor-plugins-for-software-developers-3/big/vim-ver-split.png
|
||||
[6]:https://www.howtoforge.com/images/vim-editor-plugins-for-software-developers-3/big/vim-hor-split.png
|
||||
[7]:https://www.howtoforge.com/images/vim-editor-plugins-for-software-developers-3/big/vim-tab1.png
|
||||
@ -0,0 +1,166 @@
|
||||
Linux 命令行工具使用小贴士及技巧（二）
|
||||
============================================================
|
||||
|
||||
在本系列的[第一部分][4]中，我们通过讨论 `cd -` 命令的用法，重点介绍了 Linux 中的命令行导航。还讨论了一些其他相关要点/概念。现在进一步讨论，在本文中，我们将讨论如何使用 `pushd` 和 `popd` 命令在 Linux 命令行上获得更快的导航体验。
|
||||
|
||||
在我们开始之前，值得说明的一点是，此后提到的所有指导和命令已经在 Ubuntu 14.04 和 Bash shell（4.3.11）上测试过。
|
||||
|
||||
### pushd 和 popd 命令基础
|
||||
|
||||
为了更好地理解 `pushd` 和 `popd` 命令的作用，让我们先讨论堆栈的概念。想象你厨房案板上有一个空白区域，你想在上面放一套盘子。你会怎么做？很简单，一个接一个地放在上面。
|
||||
|
||||
所以在整个过程的最后，案板上的第一个盘子是盘子中的最后一个，你手中最后一个盘子是盘子堆中的第一个。现在当你需要一个盘子时，你选择在堆的顶部的那个盘子并使用它，然后需要时选择下一个。
|
||||
|
||||
`pushd` 和 `popd` 命令是类似的概念。在 Linux 系统上有一个目录堆栈，你可以堆叠目录路径以供将来使用。你可以使用 `dirs` 命令来在任何时间点快速查看堆栈的内容。
|
||||
|
||||
下面的例子显示了在命令行终端启动后立即在我的系统上使用 dirs 命令的输出：
|
||||
|
||||
```
|
||||
$ dirs
|
||||
~
|
||||
```
|
||||
|
||||
输出中的波浪号（`~`）表示目录堆栈当前仅包含用户的主目录。
|
||||
|
||||
继续下去，使用 `pushd` 和 `popd` 命令来执行存储目录路径并删除它的操作。使用 `pushd` 非常容易 - 只需将要存储在目录堆栈中的路径作为此命令的参数传递。这里有一个例子：
|
||||
|
||||
```
|
||||
pushd /home/himanshu/Downloads/
|
||||
```
|
||||
|
||||
上述命令的作用是，将当前工作目录更改为你作为参数传递的目录，并且还将路径添加到目录堆栈中。为了方便用户，`pushd` 命令在其输出中产生目录堆栈的内容。因此，当运行上面的命令时，产生了以下输出：
|
||||
|
||||
```
|
||||
~/Downloads ~
|
||||
```
|
||||
|
||||
输出显示现在堆栈中有两个目录路径：一个是用户的主目录，还有用户的下载目录。它们的保存顺序是：主目录位于底部，新添加的 `Downloads` 目录位于其上。
|
||||
|
||||
要验证 `pushd` 的输出是正确的，你还可以使用 `dirs` 命令：
|
||||
|
||||
```
|
||||
$ dirs
|
||||
~/Downloads ~
|
||||
```
|
||||
|
||||
因此你可以看到 `dirs` 命令同样产生相同的输出。
|
||||
|
||||
让我们再使用下 `pushd` 命令：
|
||||
|
||||
```
|
||||
$ pushd /usr/lib/; pushd /home/himanshu/Desktop/
|
||||
/usr/lib ~/Downloads ~
|
||||
~/Desktop /usr/lib ~/Downloads ~
|
||||
```
|
||||
|
||||
所以目录堆栈现在包含总共四个目录路径，其中主目录（`~`）在底部，并且用户的桌面目录在顶部。
|
||||
|
||||
一定要记住的是堆栈的头是你当前的目录。这意味着现在我们当前的工作目录是 `~/Desktop`。
|
||||
|
||||
现在，假设你想回到 `/usr/lib` 目录，所以你所要做的就是执行 `popd` 命令：
|
||||
|
||||
```
|
||||
$ popd
|
||||
/usr/lib ~/Downloads ~
|
||||
```
|
||||
|
||||
`popd` 命令不仅会将当前目录切换到 `/usr/lib`，它还会从目录堆栈中删除 `~/Desktop`，这一点可以从命令输出中看出。这样，popd 命令将允许你以相反的顺序浏览这些目录。
|
||||
|
||||
### 一些高级用法
|
||||
|
||||
现在我们已经讨论了 `pushd` 和 `popd` 命令的基础知识，让我们继续讨论与这些命令相关的一些其它细节。首先，这些命令还允许你操作目录堆栈。例如，假设你的目录堆栈看起来像这样：
|
||||
|
||||
```
|
||||
$ dirs
|
||||
~/Desktop /usr/lib ~ ~/Downloads
|
||||
```
|
||||
|
||||
现在，我们的要求是改变堆栈中目录路径的顺序，最上面的元素（`~/Desktop`）放到底部，剩下的每个都向上移动一个位置。这可以使用以下命令实现：
|
||||
|
||||
```
|
||||
pushd +1
|
||||
```
|
||||
|
||||
上面的命令对目录堆栈做的结果：
|
||||
|
||||
```
|
||||
$ dirs
|
||||
/usr/lib ~ ~/Downloads ~/Desktop
|
||||
```
|
||||
|
||||
因此，我们看到目录堆栈中的元素顺序已经改变，并且现在和我们想要的一样。当然，你可以让目录堆栈元素移动任何次数。例如，以下命令会将它们向上移动两次：
|
||||
|
||||
```
|
||||
$ pushd +2
|
||||
~/Downloads ~/Desktop /usr/lib ~
|
||||
```
|
||||
|
||||
你也可以使用负的索引值：
|
||||
|
||||
```
|
||||
$ pushd -1
|
||||
/usr/lib ~ ~/Downloads ~/Desktop
|
||||
```
|
||||
|
||||
相似地，你可以在 `popd` 命令中使用此技术来从目录堆栈删除任何条目，而不用离开当前工作目录。例如，如果要使用 `popd` 从顶部（目前是 `~/Downloads`）删除第三个条目，你可以运行以下命令：
|
||||
|
||||
```
|
||||
popd +2
|
||||
```
|
||||
|
||||
记住堆栈索引的初始值是 `0`，因此我们使用 `2` 来访问第三个条目。
|
||||
|
||||
因此目录堆栈现在包含：
|
||||
|
||||
```
|
||||
$ dirs
|
||||
/usr/lib ~ ~/Desktop
|
||||
```
|
||||
|
||||
确认条目已经被移除了。
|
||||
|
||||
如果由于某些原因，你发现你很难记住元素在目录堆栈中的位置以及它们的索引，你则可以对在 `dirs` 命令中使用 `-v` 选项。这里有一个例子：
|
||||
|
||||
```
|
||||
$ dirs -v
|
||||
0 /usr/lib
|
||||
1 ~
|
||||
2 ~/Desktop
|
||||
```
|
||||
|
||||
你可能已经猜到了，左边的数字是索引，接下来跟的是这个索引对应的目录路径。
|
||||
|
||||
**注意**： 在 `dir` 中使用 `-c` 选项清除目录堆栈。
|
||||
|
||||
现在让我们简要地讨论一下 `popd` 和 `pushd` 命令的实际用法。虽然它们第一眼看起来可能有点复杂，但是这些命令在编写 shell 脚本时会派上用场 - 你不需要记住你从哪里来；只要执行一下 `popd`，你就能回到你来的目录。
|
||||
|
||||
经验丰富的脚本编写者通常以以下方式使用这些命令：
|
||||
|
||||
```
|
||||
popd >/dev/null 2>&1
|
||||
```
|
||||
|
||||
上述命令确保 `popd` 保持静默（不产生任何输出）。同样，你也可以静默 `pushd`。
|
||||
|
||||
`pushd` 和 `popd` 命令也被 Linux 服务器管理员使用，他们通常在几个相同的目录之间移动。 在[这里][5]介绍了一些其他有用的使用场景。
|
||||
|
||||
### 总结
|
||||
|
||||
我同意 `pushd` 和 `popd` 的概念不是很直接。但是，它需要的只是一点练习 - 是的，你需要多实践。花一些时间在这些命令上，你就会开始喜欢它们，特别是当它们提供了方便时。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/
|
||||
|
||||
作者：[Ansh][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[jasminepeng](https://github.com/jasminepeng)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/
|
||||
[1]:https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/#the-basics-of-pushd-and-popd-commands
|
||||
[2]:https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/#some-advanced-points
|
||||
[3]:https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/#conclusion
|
||||
[4]:https://linux.cn/article-8335-1.html
|
||||
[5]:http://unix.stackexchange.com/questions/77077/how-do-i-use-pushd-and-popd-commands
|
||||
132
published/20170125 An executive's guide to containers.md
Normal file
132
published/20170125 An executive's guide to containers.md
Normal file
@ -0,0 +1,132 @@
|
||||
容器实践指南
|
||||
============================================================
|
||||
|
||||
 图片来源：[Maersk Line][1]. [CC SA-BY 4.0][2]
|
||||
|
||||
与互联网领域的领导们关于"容器"的讨论通常被总结如下：
|
||||
|
||||
_作为一名 CxO，我面临杠杆时间术的持续的压力。IT 预算不断减少，我只有有限的资源。然而，交付的工作量却比以往更多。我花费太多的时间致力于解决预算的约束。另外，互联网的格局正在经历一个快速的改变，而且新的技术一直在被引进。我从我最信任的顾问那听来的最新的话题是一个“容器策略”的实现。我想理解：_
|
||||
|
||||
1. _什么是容器？_
|
||||
2. _过渡到容器的企业价值是什么？_
|
||||
3. _为什么我现在应该转移到容器？如果我不采纳会有一些坏处吗？_
|
||||
4. _容器是否已经足够成熟用于企业消费？_
|
||||
5. _我如何让我的企业因使用容器而快速地发展？_
|
||||
|
||||
让我们从最开头开始。
|
||||
|
||||
### 容器
|
||||
|
||||
在过去的 10 年左右，企业已经从物理基础设施转向了虚拟机（VM）。转向 VM 的关键优势是可以减少数据中心的用量。通过在同一个物理机器上运行多个虚拟机，你可以在更少数量的物理机器上安装更多的应用程序。使用容器是另一种更轻量地打包应用程序的方式，而且其交付模式更快。它们是一种在单一的机器里运行多个应用程序进程的奇特方式，无论那个机器是一个虚拟机还是一个物理机。另外，容器在 DevOps 、微服务和云战略场景方面也扮演了重要角色。
|
||||
|
||||
### 容器 vs 虚拟机
|
||||
|
||||
容器和虚拟机在一些方面并不相同。一台虚拟机尽管不是物理机，但是它表现地就像是一台物理机。虚拟机是一个包含所有东西的独立的环境，是一个完整的（来宾）操作系统。在另一方面，容器是一个共享同一个物理机或虚拟机上资源的进程。容器显然更加有趣，因为：
|
||||
|
||||
* 相比较而言，虚拟机要重一些，而容器更轻。因为容器只包括了它们所运行的程序所需要的库。
|
||||
* 虚拟机需要花费几分钟来启动，而容器在几秒钟内就可以启动。
|
||||
* 通常，相当于虚拟机你的基础设施中可以容纳更多的容器。
|
||||
|
||||
|
||||
|
||||
技术已经发展到足以保持这些容器安全、彼此独立，而且正确的设计选择可以保证那些坏掉的容器不会影响运行在同一个机器里的其他容器的性能。实际上，操作系统天生就是被用来构建成优化和运行容器的。
|
||||
|
||||
然而，当你转向容器时，你需要做出正确的选择。你需要做足够的尽职调查，以便你选择合适的技术合作伙伴和能够制作容器的制造商。开源技术起着很关键的作用。开源的 [Docker 项目][5]使得分层格式的容器很容易构建和使用。[开放容器计划][6]（OCI）已经成为被所有主要技术供应商所支持的开源容器标准。如 Red Hat 这样的开源技术提供商提供了为容器而准备的安全的操作系统。例如， Red Hat Enterprise Linux 7.x （包括 Red Hat Enterprise Linux 原子主机）进行了优化以原生地运行容器，同时也提供监控和管理容器的工具。其他的开源项目如来自 Tectonic 的 CoreOS 也正在进入市场。的确，容器正等着被企业所采用。
|
||||
|
||||
### 容器平台
|
||||
|
||||
容器平台让容器成为企业消耗品。在过去这些年中，你可能在你的企业里处理过虚拟机散乱的问题，容器散乱比那要糟糕好几倍。在你的数据中心横跨不同主机运行不同规模的容器，尽管容器故障仍然保证你的应用程序的高可用性，自动化健康检查和基于流入的工作载荷的自动化容器缩放等等，这些是你能期待容器平台应该有的一些关键特性。
|
||||
|
||||
当在一个被定位为容器即服务模型（CaaS）的平台上运行容器时，这些平台的一些其它特性如自动化生成和部署使这个平台成为平台即服务模型（PaaS）。虽然 CaaS 能让你规模化运行容器，但是，PaaS 可以让你利用你的源代码编译、创建容器，为你运行那些容器。另外，这些平台提供了完整操作管理特性，例如，集群的管理和监控、容器的安全缺陷检测，以及安全地运行容器、跟踪日志和度量等等。
|
||||
|
||||
尽管一些技术供应商正在使用他们的专有技术来构建容器平台，但总的来说，企业们正在围绕建立在 [Kubernetes][7]（K8S）的基础上的开源技术而进行标准化。K8S 是一项由 Google 发起的开源项目，现在很多大平台的供应商也支持它。K8S 也是[云端原生计算基金会][8]（CNCF）的一部分，CNCF 正在发展成以云为中心技术的标准体。当你在容器平台上做出选择时，围绕开源流程编排技术的标准化是非常重要的。它基本上允许你移植到不同的容器平台，如果你不喜欢你第一次做的选择的话。K8S 还允许你的容器工作载荷可跨越不同的公有云进行迁移。这些就是为什么我们会看到越来越多的技术公司正在使用 Kubernetes 的原因。
|
||||
|
||||
一些企业正在试图通过拼接几个包括 K8S 在内开源项目来打造他们自己 DIY 的容器平台。这确实是比继续跟随专有技术要更好的一种解决方案，但是要完成这项工作也仍然包含很多需要探讨的地方。然而，一个企业的维护和保持这样的 DIY 平台的能力应该被认真评估。许多企业并不是想做创建 IT 平台的工作，而是他们希望运行自己的主流业务。有很多可行的基于 K8S 的解决方案，比如[红帽 OpenShift 平台容器][9]、[Apprenda][10]、[Deis][11] 和 [Rancher][12]，它们提供一个企业级平台，这些解决方案中的每种都有不同完整程度的功能。
|
||||
|
||||
这些解决方案是由供应商认证和支持。有些方案是完全的开源 PaaS 解决方案，而另外一些可能是 CaaS。根据你的企业的需求，这些解决方案可能是比 DIY 容器平台更好的替代品。
|
||||
|
||||
### 企业的担忧和它们与容器的关系
|
||||
|
||||
今天，几乎每个企业都正在与数字时代转型打交道，这些转型影响包括 DevOps 战略、微服务和云等多个领域。容器在这些领域中的每一个中都起着相当重要的作用。
|
||||
|
||||
### DevOps 策略
|
||||
|
||||
IT 组织被分成运维和应用开发，他们作为两个独立的团队运作，每一队都只有他们自己的一套目标。大多数企业为了将这两个团队联合起来正在朝 DevOps 的方向前进。
|
||||
|
||||
容器在 DevOps 倡议的成功中发挥着重要的作用。在 DevOps 中成功的关键标准之一是增加开发人员在运营中的份额。开发人员不仅应该把代码交给运维人员，而且他们还应该考虑他们的代码是如何在生产环境中运行的。普遍的技术是采用“架构即代码”，而不是提供几页容易出错的安装说明指示，开发团队应该提供像编程时的环境配置。
|
||||
|
||||
这恰恰就是容器可以解决的问题。可以作为容器的模版的容器镜像包括了从基本操作系统到应用程序代码的整个环境堆栈。利用容器，开发人员将不再只是从 Dev 到 QA 再到 Prod 这样生成应用程序；相反，他们将传递一个版本化的容器镜像，这个镜像包括生成的运行程序和它运行需要的环境。容器是包罗万象的，从操作系统库到中间件再到应用程序的所有东西都被整合进一个镜像里面。因此，容器在开发环境运行的方式和它在质量保证环境和生产环境下运行的方式完全一样。容器是 DevOps 成功的重要因素。
|
||||
|
||||
|
||||
|
||||
另外，容器平台正在进一步发展。典型的持续集成和交付（CICD）工具，如 [Jenkins](https://jenkins.io/)，可以作为容器，这个容器能在容器平台本身运行整个 CICD 过程，而不需要额外的基础设施。现在你可以使用 PaaS 平台来生成和运行你的 CICD 管道。
|
||||
|
||||
### 微服务策略
|
||||
|
||||
微服务是今天 IT 领域的另一个热门话题。应用程序是这样被设计的：把应用程序分解为离散化的小的服务，每个服务完成一个小任务。这些服务中的每一个都可以根据合适的技术用不同的编程语言进行编写。它们可以由小团队（双比萨团队）创建和管理，并且可以迅速地改变它们。所有这些要求再次需要用到容器。容器足够小到成为微服务的基础。容器能够支持任何你选择的技术和语言，容器易于创建和运行，并且可以快速地改变。微服务和容器现在已经不分彼此，如果有人说不使用容器来实现微服务，他们将会受到别人奇怪的表情。
|
||||
|
||||
实际情况是，虽然微服务有望让情况变得简单，但是它们的扩张也增加了复杂性。有几个微服务的设计和开发模式将能使它们易于实现。这意味着开发人员现在急需这样一个开发平台，在这个平台下，开发人员可以轻松地部署和组织微服务，而且还能：
|
||||
|
||||
* 以一种语言不可知的方式实现这些微服务设计模式。
|
||||
* 不会因代码侵入而增加代码的复杂性，以便开发人员能将许多模式的代码包括进他们的业务逻辑中。
|
||||
* 足够灵活以便部署在你所选择的基础设施上，并且不会把你捆绑在特定的云上。
|
||||
|
||||
这就是选择一个正确的容器平台所起作用的地方。在具体的基础设施上按照某一特定供应商的方法来实现这些微服务将会把你的应用程序捆绑在那些供应商的平台上。使用类似兼容 OCI 的容器的容器化微服务将可以保证你的微服务能够被运行在任何兼容 OCI 的平台上。
|
||||
|
||||
选择正确的容器平台来运行你的微服务是需要做的另一个重要的决定。今天，有很少的选择和许多的 FUD。如果你作出选择时不足够慎重，其中一些选择会把你带到非标准的、特定供应商的路线上。
|
||||
|
||||
### 云策略
|
||||
|
||||
云战略是 IT 领域的又一个热门话题。无论你是否喜欢，服务化模型都是不可避免的变化。如果你不将其作为 IT 服务进行提供，你的开发团队将可能会找到创建“shadow IT”的方法来访问云。另外，尽管使用云技术将会让你从资本支出转移到运营支出，但是，管理云支出是一个不断的挑战。
|
||||
|
||||
云可以提供虚拟机，在你添加额外的虚拟机之前，你要确认这个云上的 CPU、内存和网络等资源都处于最佳使用状态。容器在这个地方扮演着很重要的角色。因为容器比虚拟机要小得多。并且，如果你的应用程序正运行在容器中，你可以在虚拟机中安装更多的容器，这比在每台虚拟机中运行一个应用程序组件要多很多。
|
||||
|
||||
公有云供应商有很多，其中 Amazon Web Services（AWS）、Microsoft Azure 和 Google Cloud 最受欢迎。另外，你可能想在你的基于 OpenStack 的数据中心里拥有你自己的私有云。这些云环境中的每一个都有它们自己的协议、API 和工具。当你想让你的应用程序在云上运行时，你不会想要让您的应用编排被云供应商所制约，也不会想要维护任何特定云的代码。在你的技术上与特定的云供应商锁定就像在未来几年内向供应商签署空白支票。
|
||||
|
||||
云的可移植性对您的云战略至关重要。你可以编写应用程序，而不用担心它们在哪里运行，容器平台可以将你和特定的云供应商协议隔离开来，从而避免你与一个云供应商锁定。
|
||||
|
||||
### 传统系统
|
||||
|
||||
微服务架构带给开发的优势很多，但并不是每个应用程序都可以重构它们自己，有些只能重构一部分。传统的应用程序被普遍接受，它们需要维护和管理。虽然容器可以实现微服务，但容器不仅仅只是微服务。可以想象，你可以将大型应用程序和微服务作为容器来运行，因此只要你选择正确的容器技术和正确的应用程序平台，就可以将许多（如果不是所有）的传统的应用程序作为容器运行。
|
||||
|
||||
### 总结
|
||||
|
||||
我希望这篇对各种策略和容器的深入剖析有助于你的公司对下一步进行评估。让我在评论里面了解您公司学习到的经验，或者说没能大步向前跨越，他们还需要我再提供一些什么信息。
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Veer Muchandi -- 开源爱好者，容器和PaaS倡导者，喜欢学习和分享。
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/1/container-strategy-for-executives
|
||||
|
||||
作者：[Veer Muchandi][a]
|
||||
译者：[zhousiyu325](https://github.com/zhousiyu)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
|
||||
|
||||
[a]:https://opensource.com/users/veermuchandi
|
||||
[1]:https://www.flickr.com/photos/maerskline/6955071566
|
||||
[2]:https://creativecommons.org/licenses/by-sa/4.0/
|
||||
[3]:https://opensource.com/article/17/1/container-strategy-for-executives?rate=DuiecCOvGMj-GXcdlJsN8xdZJ82yPUX1M3M9ZNkT99A
|
||||
[4]:https://opensource.com/resources/what-are-linux-containers
|
||||
[5]:https://opensource.com/resources/what-docker
|
||||
[6]:https://opensource.com/business/16/8/inside-look-future-linux-containers
|
||||
[7]:https://opensource.com/resources/what-is-kubernetes
|
||||
[8]:https://www.cncf.io/
|
||||
[9]:https://www.openshift.com/container-platform/
|
||||
[10]:https://apprenda.com/
|
||||
[11]:http://deis.io/
|
||||
[12]:http://rancher.com/
|
||||
[13]:https://jenkins.io/
|
||||
[14]:https://opensource.com/resources/what-are-microservices
|
||||
[15]:https://opensource.com/user/92826/feed
|
||||
[16]:https://opensource.com/article/17/1/container-strategy-for-executives#comments
|
||||
[17]:https://opensource.com/users/veermuchandi
|
||||
@ -7,7 +7,7 @@
|
||||
|
||||
啊，一个好的调查，能够以快速、简单、便宜、有效的方式收集朋友、家人、同学、同事、客户、读者和其他人的意见。
|
||||
|
||||
许多人开始使用专有工具，如 SurveyGizmo、Polldaddy、SurveyMonkey 甚至 Google 表单来设置他们的调查。但是如果你想对应用还有收集到的数据有更多的控制，那么你会希望使用开源工具。
|
||||
许多人开始使用专有工具，如 SurveyGizmo、Polldaddy、SurveyMonkey 甚至 Google 表单来设置他们的调查。但是如果你不仅是对这些应用还有你自己收集到的数据有更多的控制，那么你会希望使用开源工具。
|
||||
|
||||
让我们来看看四个开源调查工具，无论需求简单还是复杂，它们都可以满足你的需求。
|
||||
|
||||
@ -23,7 +23,7 @@ LimeSurvey 还允许你使用自己的 JavaScript、照片和视频自定义调
|
||||
|
||||
如果 LimeSurvey 没有为你提供足够的功能，并且对 Java 驱动的 web 程序感兴趣，那么我推荐 [JD Esurvey][5]。它被称为“一个开源的企业调查 web 应用”。它绝对强大，并满足了那些寻找大容量、健壮的调查工具的组织的很多需求。
|
||||
|
||||
使用 JD Esurvey，你可以收集一系列信息，包括 “是/否” 问题的答案以及产品和服务的星级。你甚至可以处理多个部分的问题的答案。JD Esurvey 支持使用平板电脑和智能手机创建和管理调查，你发布的调查也是移动友好的。根据开发者的说法，该程序[残疾人也可使用][6]。
|
||||
使用 JD Esurvey，你可以收集一系列信息，包括 “是/否” 问题的答案以及产品和服务的星级。你甚至可以处理带有多个部分答案的问题。JD Esurvey 支持使用平板电脑和智能手机创建和管理调查，你发布的调查也是移动友好的。根据开发者的说法，该程序[残疾人也可使用][6]。
|
||||
|
||||
要使用它，你可以[在 GitHub 上 fork JD Esurvey][7] 或者[下载并安装][8]程序的预编译版本。
|
||||
|
||||
@ -37,11 +37,11 @@ Quick Survey 只允许你创建问答和多选调查列表。你可以添加问
|
||||
|
||||
### TellForm
|
||||
|
||||
在功能方面，[TellForm][13] 位于 LimeSurvey 和 Quick Survey 之间。它适合那些功能需求超出最小需求，但无需完全功能的人使用。
|
||||
在功能方面，[TellForm][13] 介于 LimeSurvey 和 Quick Survey 之间。它适合那些功能需求超出最小需求，但无需完整功能的人使用。
|
||||
|
||||
除了有 11 种不同类型的调查之外，TellForm 还有很好的分析功能。你可以轻松地自定义调查的外观和感觉，而且程序的界面简单干净。
|
||||
|
||||
如果你想自己托管 TellForm，你可以从[ GitHub 仓库][14]中获取代码。或者，你可以注册[免费托管帐户][15]。
|
||||
如果你想自己托管 TellForm，你可以从 [GitHub 仓库][14]中获取代码。或者，你可以注册[免费托管帐户][15]。
|
||||
|
||||
* * *
|
||||
|
||||
@ -58,7 +58,7 @@ Scott Nesbitt - 作家、编辑、雇佣兵（Soldier of fortune）、豹猫牧
|
||||
|
||||
via: https://opensource.com/article/17/2/tools-online-surveys-polls
|
||||
|
||||
作者：[Scott Nesbitt ][a]
|
||||
作者：[Scott Nesbitt][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[jasminepeng](https://github.com/jasminepeng)
|
||||
|
||||
@ -3,36 +3,35 @@
|
||||
|
||||
几个星期前，我一个朋友问我：“为什么要关心 Go 语言”？ 因为他们知道我热衷于 Go 语言，但他们想知道为什么我认为_其他人_也应该关心。本文包含三个我认为 Go 是重要的编程语言的原因。
|
||||
|
||||
# 安全
|
||||
### 安全
|
||||
|
||||
个人而言，你和我或许完全有能力在 C 中编写程序，既不会泄漏内存，也不会不安全地重复使用内存。然而，整体上，即使有超过[ 40 年][5]的经验，用 C 的程序员也无法可靠地这样做。
|
||||
个人而言，你和我或许完全有能力在 C 中编写程序，既不会泄漏内存，也不会不安全地重复使用内存。然而，整体上，即使有超过 [40 年][5]的经验，用 C 的程序员也无法可靠地这样做。
|
||||
|
||||
尽管静态代码分析、valgrind、tsan 以及 “-Werror” 已经存在了几十年，很少有证据表明这些工具被广泛认可，更不用说广泛采用。总而言之，事实表明，程序员根本无法安全地管理自己的内存。现在是离开 C 的时候了。
|
||||
尽管静态代码分析、valgrind、tsan 以及 “-Werror” 已经存在了几十年，却很少有证据表明这些工具被广泛认可，更不用说广泛采用。总而言之，事实表明，程序员根本无法安全地管理自己的内存。现在是离开 C 的时候了。
|
||||
|
||||
Go 不依赖于程序员直接管理内存，所有内存分配都由语言运行时管理，使用前初始化，必要时检查边界。它肯定不是提供这些安全保障的第一个主流语言，Java（1995）可能是该冠军的竞争者。关键是，世界对不安全的编程语言没有胃口，所以人们默认认为，Go 是内存安全的。
|
||||
Go 不需要程序员直接管理内存，所有内存分配都由语言运行时自行管理，使用前初始化，必要时检查边界。它肯定不是提供这些安全保障的第一个主流语言，Java（1995）可能是该冠军的竞争者。关键是，世界对不安全的编程语言没有胃口，所以人们默认认为，Go 是内存安全的。
|
||||
|
||||
# 开发人员生产力
|
||||
### 开发人员生产力
|
||||
|
||||
从 20 世纪 70 年代末，开发人员时间变得比硬件时间更昂贵了。开发人员的生产力是一个不断扩展的话题，但它归结为这一点：你花了多少时间做有用的工作，又有多少时间等待编译器或者失望地迷失在外部代码库中。
|
||||
从 20 世纪 70 年代末，开发人员的时间变得比硬件所耗费的时间更昂贵了。开发人员的生产力是一个不断扩展的话题，但它归结为这一点：你花了多少时间做有用的工作，又有多少时间等待编译器或者失望地迷失在外部代码库中。
|
||||
|
||||
有个笑话说 Go 是在等待[ C ++ 程序编译][6]时开发的。快速编译是 Go 的一个重要功能，也是吸引新开发人员的关键工具。虽然编译速度仍然是一个[永久的战场][7]，但公平地说，在其他语言中需要几分钟的编译，在 Go 中只需要几秒钟。
|
||||
有个笑话说 Go 是在等待 [C ++ 程序编译][6]时开发的。快速编译是 Go 的一个重要功能，也是吸引新开发人员的关键工具。虽然编译速度仍然是一个[永久的战场][7]，但公平地说，在其他语言中需要几分钟的编译，在 Go 中只需要几秒钟。
|
||||
|
||||
Go 程序员意识到生产力更根本的问题是代码是为了_读而写的_，所以将[代码的阅读行为放在编写之上][8]。Go 通过工具和自定义强制所有代码格式化成特定的样式。这消除了学习项目特定语言子方言时的困难，并有助于发现错误，因为它们_看上去_就是不正确。
|
||||
Go 程序员意识到生产力的更根本的问题是代码是**为了读而写的**，所以将[代码的阅读行为放在编写之上][8]。Go 通过工具和自定义来强制所有代码格式化成特定的样式。这消除了学习项目特定语言的方言时的困难，并有助于发现错误，因为它们**看上去**就是不正确。
|
||||
|
||||
由于专注于分析和机器辅助，Go 开发人员开始采用越来越多的工具来发现常见的编码错误，这种工具从来没有在 C 语言开发者中产生共鸣 - Go 开发人员_希望_工具帮助他们保持代码清洁。
|
||||
由于专注于分析和机器辅助，Go 开发人员开始采用越来越多的工具来发现常见的编码错误，这种工具从来没有在 C 语言开发者中产生共鸣 - Go 开发人员**希望**工具帮助他们保持代码清洁。
|
||||
|
||||
# 并发性
|
||||
### 并发性
|
||||
|
||||
十多年来，芯片设计师一直在警告[免费午餐将会结束][9]。从最低端的手机到最耗电的服务器，硬件的并行性以[更多、更慢、堆 cpu 内核][10]的形式出现，只有_当_你的语言可以利用它们才能实现。因此，并发需要内置到我们编写的要在今天的硬件上运行的软件中。
|
||||
十多年来，芯片设计师一直在警告[免费午餐将会结束][9]。从最低端的手机到最耗电的服务器，硬件的并行性以[更多、更慢、堆砌 cpu 内核][10]的形式出现，但只有**当**你的语言可以利用它们才有意义。因此，并发特性需要内置到我们编写的要在今天的硬件上运行的软件中。
|
||||
|
||||
通过提供一种基于协程的[轻量级并发模型][11]，或者是 Go 中已知的 goroutines，Go 超越了那些暴露操作系统的多进程或多线程并行模型的语言。goroutines 允许程序员避开复杂的回调，而语言运行时确保有足够的线程来保持你的内核的活跃。
|
||||
|
||||
# 总结
|
||||
### 总结
|
||||
|
||||
我给朋友推荐 Go 有三个原因：安全性、生产力和并发性。有些语言可以涵盖一个也有可能是两个方面，但是这三个方面的结合使得 Go 成为主流程序员的绝佳选择。
|
||||
|
||||
|
||||
## 相关文章：
|
||||
### 相关文章：
|
||||
|
||||
1. [为什么 Go 和 Rust 不是竞争对手][1]
|
||||
2. [听听我在 OSCON 上谈 Go 语言性能][2]
|
||||
@ -1,3 +1,5 @@
|
||||
GitFuture is translating
|
||||
|
||||
A beginner's guide to comparing files using visual diff/merge tool Meld on Linux
|
||||
============================================================
|
||||
|
||||
|
||||
@ -1,132 +0,0 @@
|
||||
being translated by zhousiyu325
|
||||
|
||||
An executive's guide to containers
|
||||
============================================================
|
||||
|
||||
|
||||
Image credits : [Maersk Line][1]. [CC SA-BY 4.0][2]
|
||||
|
||||
Discussions with IT leaders about "[containers][4]" can often be summarized as this:
|
||||
|
||||
_As a CxO, I face the constant challenge of doing more with less. IT budgets continue to decrease and I have less resources, yet the amount of work to deliver is greater than ever before. I spend far too many hours dedicated to resolving budgetary constraints. In addition, the IT landscape is undergoing a rapid change and new technologies are being introduced all the time. The latest topic I hear from my trusted advisors is the implementation of a "container strategy." I want to understand:_
|
||||
|
||||
1. _What are containers?_
|
||||
2. _What is the enterprise value to transitioning to containers?_
|
||||
3. _Why should I shift to containers now? Are there disadvantages if we don't adopt?_
|
||||
4. _Are containers mature enough for enterprise consumption?_
|
||||
5. _How do I get my enterprise up to speed with container adoption?_
|
||||
|
||||
Let's start at the beginning.
|
||||
|
||||
### Containers
|
||||
|
||||
In the past 10 years or so, enterprises have moved from physical infrastructure to virtual machines (VMs). The key advantage of moving towards VMs is a reduction in the datacenter footprint. You can fit more applications on a fewer number of physical machines by running multiple VMs on the same physical box. Using containers is another way of packing applications in a much lighter weight and with a much faster delivery model. They are a fancy way of running multiple application processes on a single box, regardless of whether that box is a VM or a physical machine. In addition, containers also play a major role in the context of fulfilling DevOps, microservices, and cloud strategy.
|
||||
|
||||
### Containers versus VMs
|
||||
|
||||
Containers differ from VMs in a few simple ways. A VM, while not a physical machine, behaves just like one. It is an isolated environment that includes everything, starting with a complete (guest) operating system. On the other hand, containers are processes that share the resources on the same machine, which could be physical or virtual. Containers are notably interesting because:
|
||||
|
||||
* VMs are heavy, comparatively. Containers are light because they only include those libraries needed by the applications they run.
|
||||
* VMs take minutes to start up. Containers start up in seconds.
|
||||
* Typically, many more containers fit into your infrastructure than VMs.
|
||||
|
||||
|
||||
|
||||
The technology has evolved enough to keep these containers secure, isolated from each other, and "with right design choices" to make sure that bad containers don't affect the performance of other containers running on the same box. In fact, operating systems are built to optimize and run containers natively.
|
||||
|
||||
Still, you need to make the right choices when moving toward containers. You need to do enough due diligence so you choose the right technology partners and vendors to enable containers. Open source technologies play a key role. The open source [Docker project][5] has made containers with a layering format that is easy to build and use. The [Open Container Initiative][6] (OCI) has become an open source standard for containers supported by all major technology vendors. Open source technology providers like Red Hat make container-ready, secure operating systems available. For example, Red Hat Enterprise Linux 7.x , including Red Hat Enterprise Linux Atomic Host, are optimized to run containers natively and also provide tools to monitor and manage containers. Other open source projects such as CoreOS from Tectonic are also coming into the market. Indeed, containers are ready for adoption by enterprises.
|
||||
|
||||
### Container platforms
|
||||
|
||||
Container platforms make containers enterprise-consumable. You may have dealt with VM sprawl in your enterprises over the past decade, and container sprawl can be many times worse. Running your containers at scale across the various hosts in your datacenter, ensuring high availability for your applications despite container failure, automated health checks, automated scaling of containers based on incoming workloads, etc., are some of the key features you can expect from a container platform.
|
||||
|
||||
While running containers on such a platform is positioned as Container-as-a-Service model (CaaS), some additional features of these platforms, such as build and deployment automation, make this platform a full-fledged Platform-as-a-Service (PaaS). While CaaS can run containers for you at scale, PaaS would take your source code, build it, create containers, and run those containers for you. In addition, these platforms provide complete operations management features, such as management and monitoring of the cluster, detection of security flaws with the containers and run safe containers, tracking logs and metrics, etc.
|
||||
|
||||
While some vendors are using their proprietary technologies to build container platforms, in general, companies are standardizing them around open source technologies built around [Kubernetes][7] (or K8S in short). K8S is an open source project that was started by Google, and many large platform vendors now support it. K8S is also part of [Cloud Native Computing Foundation][8] (CNCF), which is evolving as a standards body for cloud-centric technologies. Standardization around open source orchestration technologies is very important when you make your choices on a container platform. It basically allows you be portable across container platforms if you don't like the choice you made the first time. K8S also allows your container workloads to be portable across different public clouds. These are the reasons why we see more and more technology companies using Kubernetes.
|
||||
|
||||
A few enterprises are trying to build their own DIY container platforms by stitching together several open source projects that include K8S. This is definitely a better solution than going with proprietary technologies, but it also includes lot of plumbing to get it to work. However, an enterprise's ability to sustain and maintain such DIY platforms should be considered seriously. Many enterprises are not in the job of creating IT Platforms, rather they wish to run their mainstream business. There are many K8S-based solutions available, such as [Red Hat's OpenShift Container Platform][9], [Apprenda][10], [Deis][11], [Rancher][12], etc., which provide enterprise-ready versions of a platform, each with different levels of maturity in terms of features they provide.
|
||||
|
||||
These solutions are certified and supported by vendors. Some of these are comprehensive open source PaaS solutions, while others may be CaaS. Based on your enterprise needs, these solutions may serve as better alternatives than a DIY container platform.
|
||||
|
||||
### Enterprise concerns and their relationship to containers
|
||||
|
||||
Today, almost every enterprise is dealing with a digital transformation that impacts multiple areas, including strategies for DevOps, microservices, and the cloud. Containers play a particular role in each of these areas.
|
||||
|
||||
### DevOps strategy
|
||||
|
||||
IT organizations are divided into operations and application development. They operate as two separate teams, and each has its own set of goals. Most of the enterprises are moving in the direction of DevOps to bring these two teams together.
|
||||
|
||||
Containers have a major role to play in the success of DevOps initiatives. One of the key success criteria in DevOps is to increase the developer's stake in operations. Developers should not only hand off code to operations, but also, they should be concerned about how their code runs in the production. The common technique is to treat "infrastructure as code." Rather than provide pages of installation instructions that are error prone, the development team should provide the environment setup as code.
|
||||
|
||||
This is the exact problem that containers solve. Container images, which are templates for containers, include the entire stack, starting from the base operating system through to the application code. With containers, developers would not just build an application artifact (such as a .jar file) from Dev to QA to Prod; instead, they would pass a versioned container image that includes both the built artifact and the environment in which the artifact runs. The container is all inclusive, with everything from operating system libraries to middleware to the application bundled into one image. Therefore, the way the container runs in Development is the same exact way it runs in QA and Production. Containers are essential ingredients for DevOps success.
|
||||
|
||||
|
||||
|
||||
In addition, container platforms are going a step further. Typical Continuous Integration and Delivery (CICD) tools, such as [Jenkins][13], are available as containers that run the entire CICD process on the container platform itself without the need for additional infrastructure. Now, you can use the PaaS platform to build and run your CICD pipelines.
|
||||
|
||||
### Microservices strategy
|
||||
|
||||
[Microservices][14] are another hot topic in IT today. Breaking down applications into discrete, small services, each of which do a small job, pretty well, is how applications are being designed. Each of these microservices could be written in a different language based on the technology suitable. They would be created and managed by small (two-pizza fed) teams and they can be changed fast. All these requirements again allude to containers. Containers are small enough to be the foundation for microservices. Containers can support any technology and language of your choice. They are easy to create and run and can be changed fast. Microservices and containers are considered married now, and if people talk of implementing microservices without using containers, they are often given a strange look.
|
||||
|
||||
The reality is that while microservices promise simplicity, their proliferation also increases complexity. Several microservices design and deployment patterns are coming up to ease their implementation. This means developers are now in need of a platform where they can deploy and orchestrate these microservices with ease and that:
|
||||
|
||||
* Implements these microservices design patterns, in a language agnostic way
|
||||
* Does not increase the complexity of code with code intrusion so that developers have to include a great deal of pattern code into their business logic
|
||||
* Is flexible enough to deploy on the infrastructure of your choice and not does not tie you to particular clouds
|
||||
|
||||
This is where choosing a right container platform comes into play. Implementing these microservices on specific infrastructures in a particular vendor's way will tie your applications to those vendor platforms. Containerizing microservices using standard technologies such as OCI-compliant containers will ensure your microservices can be run on any OCI-compliant platform.
|
||||
|
||||
Choosing the right container platform to run your microservices is another important decision to make. Today there are very few choices and a lot of FUD. Some of these choices would take you down the non-standard, vendor-specific route if you are not diligent enough when making this choice.
|
||||
|
||||
### Cloud strategy
|
||||
|
||||
Cloud strategy is one more hot topic in IT. Whether you like it or not, the "as-a-Service" model is an inevitable change. If you don't provide this as a service from IT, your development teams will probably find ways to create shadow IT to get to the cloud. In addition, while using the cloud will move you from capital expenditure to operating expenditure, managing cloud expenditure is a constant challenge.
|
||||
|
||||
Cloud provides VMs, and you want to make sure that the CPU, memory and network resources on this cloud are used optimally before you spin up additional VMs. Containers play an important role here. Because containers are much smaller than VMs, and if your applications are run in containers, you can fit more containers in VMs than running one application component per VM.
|
||||
|
||||
Public cloud vendors are numerous, with Amazon Web Services (AWS), Microsoft Azure, and Google Cloud being a few of the more popular ones. In addition, you may want your own private cloud in your datacenter based on OpenStack. Each of these cloud environments have their own protocols, APIs, and tools. While you want your applications to run on the cloud, you don't want to make your application orchestration be cloud vendor specific and you don't want to maintain any cloud-specific code. Locking in your technology with a specific cloud vendor is like signing blank checks to the vendor for years to come.
|
||||
|
||||
Portability across the cloud is important to your cloud strategy. You can write your applications without worrying about where they run, and the container platform shields you from specific cloud vendor protocols, preventing you from being locked in with one cloud vendor.
|
||||
|
||||
### Legacy systems
|
||||
|
||||
The pluses brought to development by the microservices architecture are many, but not every application can be refactored into them and some only in part. Traditional applications are here to stay and they need to be maintained and managed. While containers enable microservices, containers are not _just_ microservices. Conceivably, you can run large applications and non-microservices as containers, so as long as you choose the right container technology and the right application platform, you can run many, if not all, legacy applications as containers.
|
||||
|
||||
### Wrapping up
|
||||
|
||||
I hope this deep dive into various strategies and containers helps your company evaluate your next step. Let me know in the comments lessons your company has learned or if they haven't taken the leap, what information they need I haven't provided.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Veer Muchandi - Open source enthusiast. Container and PaaS advocate. Loves to learn and share.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/1/container-strategy-for-executives
|
||||
|
||||
作者：[Veer Muchandi][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/veermuchandi
|
||||
[1]:https://www.flickr.com/photos/maerskline/6955071566
|
||||
[2]:https://creativecommons.org/licenses/by-sa/4.0/
|
||||
[3]:https://opensource.com/article/17/1/container-strategy-for-executives?rate=DuiecCOvGMj-GXcdlJsN8xdZJ82yPUX1M3M9ZNkT99A
|
||||
[4]:https://opensource.com/resources/what-are-linux-containers
|
||||
[5]:https://opensource.com/resources/what-docker
|
||||
[6]:https://opensource.com/business/16/8/inside-look-future-linux-containers
|
||||
[7]:https://opensource.com/resources/what-is-kubernetes
|
||||
[8]:https://www.cncf.io/
|
||||
[9]:https://www.openshift.com/container-platform/
|
||||
[10]:https://apprenda.com/
|
||||
[11]:http://deis.io/
|
||||
[12]:http://rancher.com/
|
||||
[13]:https://jenkins.io/
|
||||
[14]:https://opensource.com/resources/what-are-microservices
|
||||
[15]:https://opensource.com/user/92826/feed
|
||||
[16]:https://opensource.com/article/17/1/container-strategy-for-executives#comments
|
||||
[17]:https://opensource.com/users/veermuchandi
|
||||
@ -1,3 +1,5 @@
|
||||
vim-kakali translating
|
||||
|
||||
How to compare directories with Meld on Linux
|
||||
============================================================
|
||||
|
||||
|
||||
@ -1,89 +0,0 @@
|
||||
vim-kakali translating
|
||||
|
||||
What is Linux VPS Hosting?
|
||||
============================================================
|
||||
|
||||
|
||||
|
||||
|
||||
If you have a site that gets a lot of traffic, or at least, is expected to generate a lot of traffic, then you might want to consider getting a [Linux VPS hosting][6] package. A Linux VPS hosting package is also one of your best options if you want more control over the things that are installed on the server where your website is hosted at. Here are some of the frequently asked questions about Linux VPS hosting, answered.
|
||||
|
||||
### What does Linux VPS stand for?
|
||||
|
||||
Basically, Linux VPS stands for a virtual private server running on a Linux system. A virtual private server is a virtual server hosted on a physical server. A server is virtual if it runs in a host computer’s memory. The host computer, in turn, can run a few other virtual servers.
|
||||
|
||||
### So I have to share a server with other users?
|
||||
|
||||
In most cases, yes. However, this does not mean that you will suffer from downtime or decreased performance. Each virtual server can run its own operating system, and each of these systems can be administered independently of each other. A virtual private server has its own operating system, data, and applications that are separated from all the other systems, applications, and data on the physical host server and the other virtual servers.
|
||||
|
||||
Despite sharing the physical server with other virtual private servers, you can still enjoy the benefits of a more expensive dedicated server without spending a lot of money for the service.
|
||||
|
||||
### What are the benefits of a Linux VPS hosting service?
|
||||
|
||||
There are many benefits when using a Linux VPS hosting service, including ease of use, increased security, and improved reliability at a lower total cost of ownership. However, for most webmasters, programmers, designers, and developers, the true benefit of a Linux VPS is the flexibility. Each virtual private server is isolated with its own operating environment, which means that you can easily and safely install the operating system that you prefer or need—in this case, Linux—as well as remove or add software and applications easily whenever you want to.
|
||||
|
||||
You can also modify the environment of your VPS to suit your performance needs, as well as improve the experience of your site’s users or visitors. Flexibility can be the advantage you need to set you apart from your competitors.
|
||||
|
||||
Note that some Linux VPS providers won’t give you full root access to your Linux VPS, in which case you’ll have limited functionality. Be sure to get a [Linux VPS where you’ll have full access to the VPS][7], so you can modify anything you want.
|
||||
|
||||
### Is Linux VPS hosting for everyone?
|
||||
|
||||
Yes! Even if you run a personal blog dedicated to your interests, you can surely benefit from a Linux VPS hosting package. If you are building and developing a website for a company, you would also enjoy the benefits. Basically, if you are expecting growth and heavy site traffic on your website, then a Linux VPS is for you.
|
||||
|
||||
Individuals and companies that want more flexibility in their customization and development options should definitely go for a Linux VPS, especially those who are looking to get great performance and service without paying for a dedicated server, which could eat up a huge chunk of the site’s operating costs.
|
||||
|
||||
### I don’t know how to work with Linux, can I still use a Linux VPS?
|
||||
|
||||
Of course! If you get a fully managed Linux VPS, your provider will manage the server for you, and most probably, will install and configure anything you want to run on your Linux VPS. If you get a VPS from us, we’ll take care of your server 24/7 and we’ll install, configure and optimize anything for you. All these services are included for free with all our [Managed Linux VPS hosting][8] packages.
|
||||
|
||||
So if you use our hosting services, it means that you get to enjoy the benefits of a Linux VPS, without any knowledge of working with Linux.
|
||||
|
||||
Another option to easy the use of a Linux VPS for beginners is to get a [VPS with cPanel][9], [DirectAdmin][10] or any [other hosting control panel][11]. If you use a control panel, you can manage your server via a GUI, which is a lot easier, especially for beginners. Although, [managing a Linux VPS from the command line][12] is fun and you can learn a lot by doing that.
|
||||
|
||||
### How different is a Linux VPS from a dedicated server?
|
||||
|
||||
As mentioned earlier, a virtual private server is just a virtual partition on a physical host computer. The physical server is divided into several virtual servers, which could diffuse the cost and overhead expenses between the users of the virtual partitions. This is why a Linux VPS is comparatively cheaper than a [dedicated server][13], which, as its name implies, is dedicated to only one user. For a more detailed overview of the differences, check our [Physical Server (dedicated) vs Virtual Server (VPS) comparison][14].
|
||||
|
||||
Aside from being more cost-efficient than dedicated servers, Linux virtual private servers often run on host computers that are more powerful than dedicated servers—performance and capacity are often greater than dedicated servers.
|
||||
|
||||
### I want to move from a shared hosting environment to a Linux VPS, can I do that?
|
||||
|
||||
If you currently use [shared hosting][15], you can easily move to a Linux VPS. One option is to [do it yourself][16], but the migration process can be a bit complicated and is definitely not recommended for beginners. Your best option is to find a host that offers [free website migrations][17] and let them do it for you. You can even move from shared hosting with a control panel to a Linux VPS without a control panel.
|
||||
|
||||
### Any more questions?
|
||||
|
||||
Feel free to leave a comment below.
|
||||
|
||||
If you get a VPS from us, our expert Linux admins will help you with anything you need with your Linux VPS and will answer any questions you have about working with your Linux VPS. Our admins are available 24/7 and will take care of your request immediately.
|
||||
|
||||
PS. If you liked this post please share it with your friends on the social networks using the buttons below or simply leave a reply in the comments section. Thanks.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.rosehosting.com/blog/what-is-linux-vps-hosting/
|
||||
|
||||
作者：[https://www.rosehosting.com ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.rosehosting.com/blog/what-is-linux-vps-hosting/
|
||||
[1]:https://www.rosehosting.com/blog/what-is-linux-vps-hosting/
|
||||
[2]:https://www.rosehosting.com/blog/what-is-linux-vps-hosting/#comments
|
||||
[3]:https://www.rosehosting.com/blog/category/guides/
|
||||
[4]:https://plus.google.com/share?url=https://www.rosehosting.com/blog/what-is-linux-vps-hosting/
|
||||
[5]:http://www.linkedin.com/shareArticle?mini=true&url=https://www.rosehosting.com/blog/what-is-linux-vps-hosting/&title=What%20is%20Linux%20VPS%20Hosting%3F&summary=If%20you%20have%20a%20site%20that%20gets%20a%20lot%20of%20traffic,%20or%20at%20least,%20is%20expected%20to%20generate%20a%20lot%20of%20traffic,%20then%20you%20might%20want%20to%20consider%20getting%20a%20Linux%20VPS%20hosting%20package.%20A%20Linux%20VPS%20hosting%20package%20is%20also%20one%20of%20your%20best%20options%20if%20you%20want%20more%20...
|
||||
[6]:https://www.rosehosting.com/linux-vps-hosting.html
|
||||
[7]:https://www.rosehosting.com/linux-vps-hosting.html
|
||||
[8]:https://www.rosehosting.com/linux-vps-hosting.html
|
||||
[9]:https://www.rosehosting.com/cpanel-hosting.html
|
||||
[10]:https://www.rosehosting.com/directadmin-hosting.html
|
||||
[11]:https://www.rosehosting.com/control-panel-hosting.html
|
||||
[12]:https://www.rosehosting.com/blog/basic-shell-commands-after-putty-ssh-logon/
|
||||
[13]:https://www.rosehosting.com/dedicated-servers.html
|
||||
[14]:https://www.rosehosting.com/blog/physical-server-vs-virtual-server-all-you-need-to-know/
|
||||
[15]:https://www.rosehosting.com/linux-shared-hosting.html
|
||||
[16]:https://www.rosehosting.com/blog/from-shared-to-vps-hosting/
|
||||
[17]:https://www.rosehosting.com/website-migration.html
|
||||
@ -1,114 +0,0 @@
|
||||
GHLandy Translating
|
||||
|
||||
[A formal spec for GitHub Flavored Markdown][8]
|
||||
============================================================
|
||||
|
||||
We are glad we chose Markdown as the markup language for user content at GitHub. It provides a powerful yet straightforward way for users (both technical and non-technical) to write plain text documents that can be rendered richly as HTML.
|
||||
|
||||
Its main limitation, however, is the lack of standarization on the most ambiguous details of the language. Things like how many spaces are needed to indent a line, how many empty lines you need to break between different elements, and a plethora of other trivial corner cases change between implementations: very similar looking Markdown documents can be rendered as wildly different outputs depending on your Markdown parser of choice.
|
||||
|
||||
Five years ago, we started building GitHub’s custom version of Markdown, GFM (GitHub Flavored Markdown) on top of [Sundown][13], a parser which we specifically developed to solve some of the shortcomings of the existing Markdown parsers at the time.
|
||||
|
||||
Today we’re hoping to improve on this situation by releasing a formal specification of the syntax for GitHub Flavored Markdown, and its corresponding reference implementation.
|
||||
|
||||
This formal specification is based on [CommonMark][14], an ambitious project to formally specify the Markdown syntax used by many websites on the internet in a way that reflects its real world usage. CommonMark allows people to continue using Markdown the same way they always have, while offering developers a comprehensive specification and reference implementations to interoperate and display Markdown in a consistent way between platforms.
|
||||
|
||||
#### The Specification
|
||||
|
||||
Taking the CommonMark spec and re-engineering our current user content stack around it is not a trivial endeavour. The main issue we struggled with is that the spec (and hence its reference implementations) focuses strictly on the common subset of Markdown that is supported by the original Perl implementation. This does not include some of the extended features that have been always available on GitHub. Most notably, support for _tables, strikethrough, autolinks and task lists_ are missing.
|
||||
|
||||
In order to fully specify the version of Markdown we use at GitHub (known as GFM), we had to formally define the syntax and semantics of these features, something which we had never done before. We did this on top of the existing CommonMark spec, taking special care to ensure that our extensions are a strict and optional superset of the original specification.
|
||||
|
||||
When reviewing [the GFM spec][15], you can clearly tell which parts are GFM-specific additions because they’re highlighted as such. You can also tell that no parts of the original spec have been modified and therefore should remain fully compliant with all other implementations.
|
||||
|
||||
#### The Implementation
|
||||
|
||||
To ensure that the rendered Markdown in our website is fully compliant with the CommonMark spec, the new backend implementation for GFM parsing on GitHub is based on `cmark`, the reference implementation for CommonMark developed by [John MacFarlane][16] and many other [fantastic contributors][17].
|
||||
|
||||
Just like the spec itself, `cmark` focuses on parsing a strict subset of Markdown, so we had to also implement support for parsing GitHub’s custom extensions on top of the existing parser. You can find these changes on our [fork of `cmark`][18]; in order to track the always-improving upstream project, we continuously rebase our patches on top of the upstream master. Our hope is that once a formal specification for these extensions is settled, this patchset can be used as a base to upstream the changes in the original project.
|
||||
|
||||
Besides implementing the GFM-specific features in our fork of `cmark`, we’ve also contributed many changes of general interest to the upstream. The vast majority of these contributions are focused around performance and security. Our backend renders a massive volume of Markdown documents every day, so our main concern lies in ensuring we’re doing these operations as efficiently as possible, and making sure that it’s not possible to abuse malicious Markdown documents to attack our servers.
|
||||
|
||||
The first Markdown parsers in C had a terrible security history: it was feasible to cause stack overflows (and sometimes even arbitrary code execution) simply by nesting particular Markdown elements sufficiently deep. The `cmark` implementation, just like our earlier parser Sundown, has been designed from scratch to be resistant to these attacks. The parsing algorithms and its AST-based output are thought out to gracefully handle deep recursion and other malicious document formatting.
|
||||
|
||||
The performance side of `cmark` is a tad more rough: we’ve contributed many optimizations upstream based on performance tricks we learnt while implementing Sundown, but despite all these changes, the current version of `cmark` is still not faster than Sundown itself: Our benchmarks show it to be between 20% to 30% slower on most documents.
|
||||
|
||||
The old optimization adage that _“the fastest code is the code that doesn’t run”_ applies here: the fact is that `cmark` just does _more things_ than Sundown ever did. Amongst other functionality, `cmark` is UTF8 aware, has better support for references, cleaner interfaces for extension, and most importantly: it doesn’t _translate_ Markdown into HTML, like Sundown did. It actually generates an AST (Abstract Syntax Tree) out of the source Markdown, which we can transform and eventually render into HTML.
|
||||
|
||||
If you consider the amount of HTML parsing that we had to do with Sundown’s original implementation (particularly regarding finding user mentions and issue references in the documents, inserting task lists, etc), `cmark`’s AST-based approach saves us a tremendous amount of time _and_ complexity in our user content stack. The Markdown AST is an incredibly powerful tool, and well worth the performance cost that `cmark` pays to generate it.
|
||||
|
||||
### The Migration
|
||||
|
||||
Changing our user content stack to be CommonMark compliant is not as simple as switching the library we use to parse Markdown: the fundamental roadblock we encountered here is that the corner cases that CommonMark specifies (and that the original Markdown documentation left ambiguous) could cause some old Markdown content to render in unexpected ways.
|
||||
|
||||
Through synthetic analysis of GitHub’s massive Markdown corpus, we determined that less than 1% of the existing user content would be affected by the new implementation: we gathered these stats by rendering a large set of Markdown documents with both the old (Sundown) and the new (`cmark`, CommonMark compliant) libraries, normalizing the resulting HTML, and diffing their trees.
|
||||
|
||||
1% of documents with minor rendering issues seems like a reasonable tradeoff to swap in a new implementation and reap its benefits, but at GitHub’s scale, 1% is a lot of content, and a lot of affected users. We really don’t want anybody to check back on an old issue and see that a table that was previously rendering as HTML now shows as ASCII – that is bad user experience, even though obviously none of the original content was lost.
|
||||
|
||||
Because of this, we came up with ways to soften the transition. The first thing we did was gathering separate statistics on the two different kinds of Markdown user content we host on the website: comments by the users (such as in Gists, issues, Pull Requests, etc), and Markdown documents inside the Git repositories.
|
||||
|
||||
There is a fundamental difference between these two kinds of content: the user comments are stored in our databases, which means their Markdown syntax can be normalized (e.g. by adding or removing whitespace, fixing the indentation, or inserting missing Markdown specifiers until they render properly). The Markdown documents stored in Git repositories, however, cannot be touched _at all_ , as their contents are hashed as part of Git’s storage model.
|
||||
|
||||
Fortunately, we discovered that the vast majority of user content that was using complex Markdown features were user comments (particularly Issue bodies and Pull Request bodies), while the documents stored in Git repositories were rendering properly with both the old and the new renderer in the overwhelming majority of cases.
|
||||
|
||||
With this in mind, we proceeded to normalize the syntax of the existing user comments, as to make them render identically in both the old and the new implementations.
|
||||
|
||||
Our approach to translation was rather pragmatic: Our old Markdown parser, Sundown, has always acted as a translator more than a parser. Markdown content is fed in, and a set of semantic callbacks convert the original Markdown document into the corresponding markup for the target language (in our use case, this was always HTML5). Based on this design approach, we decided to use the semantic callbacks to make Sundown translate from Markdown to CommonMark-compliant Markdown, instead of HTML.
|
||||
|
||||
More than translation, this was effectively a normalization pass, which we had high confidence in because it was performed by the same parser we’ve been using for the past 5 years, and hence all the existing documents should be parsed cleanly while keeping their original semantic meaning.
|
||||
|
||||
Once we updated Sundown to normalize input documents and sufficiently tested it, we were ready to start the transition process. The first step of the process was flipping the switch on the new `cmark` implementation for all new user content, as to ensure that we had a finite cut-off point to finish the transition at. We actually enabled CommonMark for all **new** user comments in the website several months ago, with barely anybody noticing – this is a testament to the CommonMark team’s fantastic job at formally specifying the Markdown language in a way that is representative of its real world usage.
|
||||
|
||||
In the background, we started a MySQL transition to update in-place the contents of all Markdown user content. After running each comment through the normalization process, and before writing it back to the database, we’d render it with the new implementation and compare the tree to the previous implementation, as to ensure that the resulting HTML output was visually identical and that user data was never destroyed in any circumstances. All in all, less than 1% of the input documents were modified by the normalization process, matching our expectations and again proving that the CommonMark spec really represents the real-world usage of the language.
|
||||
|
||||
The whole process took several days, and the end result was that all the Markdown user content on the website was updated to conform to the new Markdown standard while ensuring that the final rendered output was visually identical to our users.
|
||||
|
||||
#### The Conclusion
|
||||
|
||||
Starting today, we’ve also enabled CommonMark rendering for all the Markdown content stored in Git repositories. As explained earlier, no normalization has been performed on the existing documents, as we expect the overwhelming majority of them to render just fine.
|
||||
|
||||
We are really excited to have all the Markdown content in GitHub conform to a live and pragmatic standard, and to be able to provide our users with a [clear and authoritative reference][19] on how GFM is parsed and rendered.
|
||||
|
||||
We also remain committed to following the CommonMark specification as it irons out any last bugs before a final point release. We hope GitHub.com will be fully conformant to the 1.0 spec as soon as it is released.
|
||||
|
||||
To wrap up, here are some useful links for those willing to learn more about CommonMark or implement it on their own applications:
|
||||
|
||||
* [The CommonMark website][1], with information on the project.
|
||||
* [The CommonMark discussion forum][2], where questions and changes to the specification can be proposed.
|
||||
* [The CommonMark specification][3]
|
||||
* [The reference C Implementation][4]
|
||||
* [Our fork with support for all GFM extensions][5]
|
||||
* [The GFM specification][6], based on the original spec.
|
||||
* [A list of CommonMark implementations in many programming languages][7]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://githubengineering.com/a-formal-spec-for-github-markdown/?imm_mid=0ef032&cmp=em-prog-na-na-newsltr_20170318
|
||||
|
||||
作者：[Yuki Izumi][a][Vicent Martí][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://github.com/kivikakk
|
||||
[b]:https://github.com/vmg
|
||||
[1]:http://commonmark.org/
|
||||
[2]:http://talk.commonmark.org/
|
||||
[3]:http://spec.commonmark.org/
|
||||
[4]:https://github.com/jgm/cmark/
|
||||
[5]:https://github.com/github/cmark/
|
||||
[6]:https://github.github.com/gfm/
|
||||
[7]:https://github.com/jgm/CommonMark/wiki/List-of-CommonMark-Implementations
|
||||
[8]:https://githubengineering.com/a-formal-spec-for-github-markdown/
|
||||
[9]:https://github.com/vmg
|
||||
[10]:https://github.com/vmg
|
||||
[11]:https://github.com/kivikakk
|
||||
[12]:https://github.com/kivikakk
|
||||
[13]:https://github.com/vmg/sundown
|
||||
[14]:http://commonmark.org/
|
||||
[15]:https://github.github.com/gfm/
|
||||
[16]:https://github.com/jgm
|
||||
[17]:https://github.com/jgm/cmark/#authors
|
||||
[18]:https://github.com/github/cmark
|
||||
[19]:https://github.github.com/gfm/
|
||||
@ -1,104 +0,0 @@
|
||||
软件开发者的高效 vim 编辑器插件 第三部分 a.vim
|
||||
|
||||
============================================================
|
||||
|
||||
目前为止，在一系列介绍 vim 插件文章中，我们介绍了使用 Pathogen 插件管理包安装基本的 vim 插件，也提及了另外三个插件 Tagbar,delimitMate 和 Syntastic．现在，在最后一部分，我们将介绍另一个十分有用的插件 a.vim
|
||||
|
||||
|
||||
请注意所有本篇教程所提及的例子,命令，和指导，它们已经在 Ubuntu16.04(注:目前是最新版本)测试完毕，vim 使用版本为 vim7.4(注:Ubuntu16.04的默认版本)
|
||||
|
||||
A.vim
|
||||
|
||||
|
||||
如果你一直用像 C,C++ 这样的语言进行开发工作，你一定有这样的感触：我特么已经数不清我在头文件和源代码之间切换过多少次了．我想说的是，确实，这个操作十分基本，十分频繁．
|
||||
|
||||
尽管使用基于 GUI(图形界面) 的 IDE(集成开发环境) 非常容易通过鼠标的双击切换文件，但是如果你是资深 vim 粉，习惯用命令工作就有点尴尬了．但是不要害怕，我有秘籍－－插件 a.vim．它可以让你解决尴尬，专治各种文件切换．
|
||||
|
||||
|
||||
在我们介绍这个神器用法之前，我必须强调一点：这个插件的安装过程和我们其他篇介绍的不太一样，步骤如下：
|
||||
|
||||
|
||||
* Firstly, you need to download a couple of files (a.vim and alternate.txt), which you can do by heading [here][1].
|
||||
* Next, create the following directories: ~/.`vim/bundle/avim`, ~/.`vim/bundle/avim/doc`, ~/.`vim/bundle/avim/plugin`, and ~/.`vim/bundle/autoload.`
|
||||
* Once the directory creation is done, put a.vim into ~/.vim/bundle/avim/plugin as well as ~/.vim/bundle/autoload, and alternate.txt into ~/.vim/bundle/avim/doc.
|
||||
|
||||
就是这样，如果上述步骤被你成功完成，你的系统就会安装好这个插件
|
||||
|
||||
使用这个插件十分简单，你仅仅需要运行这个命令 :A 如果目前的文件是源文件（比如 test.c），这个神器就会帮你打开 test.c 对应的头文件（test.h），反之亦然．
|
||||
|
||||
|
||||
当然咯，不是每个文件对应的头文件都存在．这种情况下，如果那你运行 :A 命令，神器就会为你新建一个文件．比如，如果
|
||||
test.h 不存在，那么运行此命令就会帮你创建一个 test.h，然后打开它．
|
||||
|
||||
|
||||
如果你不想要神器开启此功能，你可以在你的家目录的隐藏文件夹 .vimrc 中写入 g:alternateNonDefaultAlternate 变量，并且赋给它一个非零值即可．
|
||||
|
||||
|
||||
还有一种情况也很普遍，你需要打开的文件并非是当前源代码的头文件．比如你目前在 test.c 你想打开 men.h 这个头文件，那么你可以输入这个命令 :IH ，毋需赘言，你肯定要在后面输入你要打开的的文件名称
|
||||
|
||||
|
||||
目前为止，我们讨论的功能都仅限于你当前文件和要操作的文件都在同一个目录去实现．但是，你也知道，我们还有特殊情况，我是说，许多项目中头文件与对应的源文件并不一定在同一目录下
|
||||
|
||||
为了搞定这个问题，你要使用这个 g:alternateSearchPath 这个变量．官方文档是这么解释的：
|
||||
|
||||
|
||||
这个插件可以让用户配置它的搜索源文件和头文件的搜索路径．这个搜索路径可以通过设置 g:alternateSearchPath 这个变量的值指定．默认的设定如下：
|
||||
|
||||
```
|
||||
g:alternateSearchPath = 'sfr:../source,sfr:../src,sfr:../include,sfr:../inc'
|
||||
```
|
||||
|
||||
使用这个代码表示神器将搜索../source,../src..,../include 和 ../inc 下所有与目标文件相关的文件． g:alternateSearchPath 变量的值由前缀和路径组成，每个单元用逗号隔开． "sfr" 前缀是指后面的路径是相对于目前文件的, "wdr" 前缀是指目录是相对于目前的工作目录， "abs" 是指路径是绝对路径．如果不指定前缀，那么默认为 "sfr".
|
||||
|
||||
|
||||
如果我们前文所提及的特性就能让你觉得很炫酷，那我不得不告诉你，这才哪跟哪．还有一个十分有用的功能是分割 Vim 屏幕，这样你就可以同时看到头文件和相应的源文件．
|
||||
|
||||
|
||||
o还有，你还可以选择垂直或者水平分割．全凭你心意．使用 :AS 命令可以水平分割，使用 :AV 可以垂直分割
|
||||
|
||||
[
|
||||
|
||||
][5]
|
||||
|
||||
[
|
||||
|
||||
][6]
|
||||
|
||||
使用 :A 命令在已经打开的文件中选择你想要的
|
||||
|
||||
|
||||
r这个插件还可以让你打开多个相应的文件在同一个 Vim 窗口中不同列表中，你键入这个命令 :AT
|
||||
|
||||
|
||||
[
|
||||
|
||||
][7]
|
||||
|
||||
当然，你可以用这些命令 :AV :AS :AT，也可以使用这些命令 :IHV :IHS :IHT
|
||||
|
||||
最后
|
||||
|
||||
还有许多和编程相关的 Vim 的插件，我们在这个第三方系列主要讨论的是，如果你为你的软件开发工作安装了合适的插件，你就会明白为什么 vim 被叫做编辑器之神
|
||||
|
||||
|
||||
当然，我们在这只关注编程方面，对于那些把 Vim 当做日常文档编辑器的人来说，你也应该了解一些 Vim 的插件，让你的编辑更好，更高效．我们就改日再谈这个问题吧．
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.howtoforge.com/tutorial/vim-editor-plugins-for-software-developers-3/
|
||||
|
||||
作者：[Ansh][a]
|
||||
译者：[Taylor1024](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.howtoforge.com/tutorial/vim-editor-plugins-for-software-developers-3/
|
||||
[1]:http://www.vim.org/scripts/script.php?script_id=31
|
||||
[2]:https://www.howtoforge.com/tutorial/vim-editor-plugins-for-software-developers/
|
||||
[3]:https://www.howtoforge.com/tutorial/vim-editor-plugins-for-software-developers-2-syntastic/
|
||||
[4]:https://github.com/csliu/a.vim/blob/master/doc/alternate.txt
|
||||
[5]:https://www.howtoforge.com/images/vim-editor-plugins-for-software-developers-3/big/vim-ver-split.png
|
||||
[6]:https://www.howtoforge.com/images/vim-editor-plugins-for-software-developers-3/big/vim-hor-split.png
|
||||
[7]:https://www.howtoforge.com/images/vim-editor-plugins-for-software-developers-3/big/vim-tab1.png
|
||||
@ -1,138 +0,0 @@
|
||||
Linux 命令行工具使用小贴士及技巧（二）：pushd 和 popd 命令基础
|
||||
============================================================
|
||||
|
||||
在本系列的[第一部分][4]中，我们通过讨论 **cd -** 命令的用法，重点介绍了 Linux 中的命令行导航。还讨论了一些其他相关要点/概念。现在进一步讨论，在本文中，我们将讨论如何使用 pushd 和 popd 命令在 Linux 命令行上获得更快的导航体验。
|
||||
|
||||
在我们开始之前，值得说明的一点是，此后提到的所有指导和命令已经在 Ubuntu 14.04 和 Bash shell（4.3.11）上测试过。
|
||||
|
||||
### pushd 和 popd 命令基础
|
||||
|
||||
为了更好地理解 pushd 和 popd 命令的作用，让我们先讨论堆栈的概念。想象你厨房案板上有一个空白区域，你想在上面放一套盘子。你会怎么做？很简单，一个接一个地放在上面。
|
||||
|
||||
所以在整个过程的最后，案板上的第一个盘子是盘子中的最后一个，你手中最后一个盘子是盘子堆中的第一个。现在当你需要一个盘子时，你选择在堆的顶部的那个盘子并使用它，然后需要时选择下一个。
|
||||
|
||||
pushd 和 popd 命令是类似的概念。在 Linux 系统上有一个目录堆栈，你可以堆叠目录路径以供将来使用。你可以使用 **dirs** 命令来在任何时间点快速查看堆栈的内容。
|
||||
|
||||
下面的例子显示了在命令行终端启动后立即在我的系统上使用 dirs 命令的输出：
|
||||
|
||||
$ dirs
|
||||
~
|
||||
|
||||
输出中的波浪号（〜）表示目录堆栈当前仅包含用户的主目录。
|
||||
|
||||
继续下去，使用 pushd 和 popd 命令来执行存储目录路径并删除它的操作。使用 pushd 非常容易 - 只需将要存储在目录堆栈中的路径作为此命令的参数传递。这里有一个例子：
|
||||
|
||||
pushd /home/himanshu/Downloads/
|
||||
|
||||
上述命令的作用是，将当前工作目录更改为你作为参数传递的目录，并且还将路径添加到目录堆栈中。为了方便用户，pushd 命令在其输出中产生目录堆栈的内容。因此，当运行上面的命令时，产生了以下输出：
|
||||
|
||||
```
|
||||
~/Downloads ~
|
||||
```
|
||||
|
||||
输出显示现在堆栈中有两个目录路径：一个是用户的主目录，还有用户的下载目录。它们的保存顺序是：主目录位于底部，新添加的 Downloads 目录位于其上。
|
||||
|
||||
要验证 pushd 的输出是正确的，你还可以使用 dirs 命令：
|
||||
|
||||
$ dirs
|
||||
~/Downloads ~
|
||||
|
||||
因此你可以看到 dirs 命令同样产生相同的输出。
|
||||
|
||||
让我们再使用下 pushd 命令：
|
||||
|
||||
$ pushd /usr/lib/; pushd /home/himanshu/Desktop/
|
||||
/usr/lib ~/Downloads ~
|
||||
~/Desktop /usr/lib ~/Downloads ~
|
||||
|
||||
所以目录堆栈现在包含总共四个目录路径，其中主目录（〜）在底部，并且用户的桌面目录在顶部。
|
||||
|
||||
一定要记住的是堆栈的头是你当前的目录。这意味着现在我们当前的工作目录是 ~/Desktop。
|
||||
|
||||
现在，假设你想回到 /usr/lib 目录，所以你所要做的就是执行 popd 命令：
|
||||
|
||||
$ popd
|
||||
/usr/lib ~/Downloads ~
|
||||
|
||||
popd 命令不仅会将当前目录切换到 /usr/lib，它还会从目录堆栈中删除 ~/Desktop，这一点可以从命令输出中看出。这样，popd 命令将允许你以相反的顺序浏览这些目录。
|
||||
|
||||
### 一些高级用法
|
||||
|
||||
现在我们已经讨论了 pushd 和 popd 命令的基础知识，让我们继续讨论与这些命令相关的一些其他细节。首先，这些命令还允许你操作目录堆栈。例如，假设你的目录堆栈看起来像这样：
|
||||
|
||||
$ dirs
|
||||
~/Desktop /usr/lib ~ ~/Downloads
|
||||
|
||||
现在，我们的要求是改变堆栈中目录路径的顺序，最上面的元素（~/Desktop）放到底部，剩下的每个都向上移动一个位置。这可以使用以下命令实现：
|
||||
|
||||
pushd +1
|
||||
|
||||
上面的命令对目录堆栈做的结果：
|
||||
|
||||
$ dirs
|
||||
/usr/lib ~ ~/Downloads ~/Desktop
|
||||
|
||||
因此，我们看到目录堆栈中的元素顺序已经改变，并且现在和我们想要的一样。当然，你可以让目录堆栈元素移动任何次数。例如，以下命令会将它们向上移动两次：
|
||||
|
||||
$ pushd +2
|
||||
~/Downloads ~/Desktop /usr/lib ~
|
||||
|
||||
你也可以使用负的索引值：
|
||||
|
||||
$ pushd -1
|
||||
/usr/lib ~ ~/Downloads ~/Desktop
|
||||
|
||||
相似地，你可以在 popd 命令中使用此技术来从目录堆栈删除任何条目，而不用离开当前工作目录。例如，如果要使用 popd 从顶部（目前是 ~/Downloads）删除第三个条目，你可以运行以下命令：
|
||||
|
||||
popd +2
|
||||
|
||||
记住堆栈索引的初始值是 0，因此我们使用 2 来访问第三个条目。
|
||||
|
||||
因此目录堆栈现在包含：
|
||||
|
||||
$ dirs
|
||||
/usr/lib ~ ~/Desktop
|
||||
|
||||
确认条目已经被移除了。
|
||||
|
||||
如果由于某些原因，你发现你很难记住元素在目录堆栈中的位置以及它们的索引，你则可以对在 dirs 命令中使用 -v 选项。这里有一个例子：
|
||||
|
||||
$ dirs -v
|
||||
0 /usr/lib
|
||||
1 ~
|
||||
2 ~/Desktop
|
||||
|
||||
你可能已经猜到了，左边的数字是索引，接下来跟的是这个索引对应的目录路径。
|
||||
|
||||
**注意**： 在 dir 中使用 -c 选项清除目录堆栈。
|
||||
|
||||
现在让我们简要地讨论一下 popd 和 pushd 命令的实际用法。虽然它们第一眼看起来可能有点复杂，但是这些命令在编写 shell 脚本时会派上用场 - 你不需要记住你从哪里来; 只要执行一下 popd，你就能回到你来的目录。
|
||||
|
||||
经验丰富的脚本编写者通常以以下方式使用这些命令：
|
||||
|
||||
`popd >/dev/null 2>&1`
|
||||
|
||||
上述命令确保 popd 保持静默（不产生任何输出）。同样，你也可以静默 pushd。
|
||||
|
||||
pushd 和 popd 命令也被 Linux 服务器管理员使用，他们通常在几个相同的目录之间移动。 在[这里][5]介绍了一些其他有用的使用场景。
|
||||
|
||||
### 总结
|
||||
|
||||
我同意 pushd 和 popd 的概念不是很直接。但是，它需要的只是一点练习 - 是的，你需要多实践。花一些时间在这些命令上，你就会开始喜欢它们，特别是当它们提供了方便时。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/
|
||||
|
||||
作者：[Ansh ][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[jasminepeng](https://github.com/jasminepeng)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/
|
||||
[1]:https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/#the-basics-of-pushd-and-popd-commands
|
||||
[2]:https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/#some-advanced-points
|
||||
[3]:https://www.howtoforge.com/tutorial/linux-command-line-tips-tricks-part-2/#conclusion
|
||||
[4]:https://www.howtoforge.com/tutorial/linux-command-line-navigation-tips-and-tricks-part-1/
|
||||
[5]:http://unix.stackexchange.com/questions/77077/how-do-i-use-pushd-and-popd-commands
|
||||
@ -1,81 +0,0 @@
|
||||
Yoo-4x translating
|
||||
# [CentOS Vs. Ubuntu][5]
|
||||
|
||||
[
|
||||
|
||||
][4]Linux 可以用的选项几乎是"没有限制"的。因为你可以构建它，也可以通过修改已经存在的发行版本或者一个新的 [Linux From Scratch][7] (LFS)。我们的选择选择 Linux 发行版本包括它的用户界面，文件系统，软件包发行版本，新的可选特性甚至包括升级时间和版本支持。
|
||||
这篇文章我们将会它讨论 Linux 的两个大的发现哦每个那么呢没，事实上它将在各自相较更好的特性上对两个发行版本进行区分。
|
||||
|
||||
### CentOS 是什么？
|
||||
|
||||
CentOS ( _企业社区开源系统_ ) 从 Red Hat Enterprise Linux (RHEL) 派生出社区支持的 Linux 派生版本, 与 RHEL 兼容，所以我们也可以说是免费版本的 RHEL。每个版本技术支持长达10年，并且每两年发行一个版本。在一月十四日 Centos 官方宣布加入 Red Hat，同时将会在一个 CentOS 板块与 RHEL 保持独立。
|
||||
|
||||
请阅读 - [如何安装 CentOS？][1]
|
||||
|
||||
### CentOS 的历史和第一个版本
|
||||
|
||||
[CentOS][8] 的第一个版本作为 cAOs 在2004年发行，作为一个基于 RPM（红帽软件包管理系统）并且由社区维护和管理的发行版本。
|
||||
|
||||
它结合 Debian, Red Hat Linux/Fedora and FreeBSD 的多个方面，使它足够稳定以便运行在服务器上和周期为三到五年的集群。它是一个更大的组织（CAOS 基金）的一部分，这个组织有一群开源开发者[1]。
|
||||
|
||||
在2016年四月 TAO Linux —— 被 David Parsley 开发的另一个 RHEL 克隆版本宣布 TAO Linux 将停止开发并加入 CentOS 开发。他迁移到 CentOS 并没有影响他之前的用户（TAO 用户），即它们可以通过 yum update 升级他们的系统而迁移到 CentOS 中来。
|
||||
|
||||
在2014年二月 Red Hat 开始赞助 CentOS 项目, 将所有权和商标转让给了它。
|
||||
|
||||
[[1\.开源软件][9]]
|
||||
|
||||
### CentOS 设计
|
||||
|
||||
CentOS 克隆的是 Red Hat 付费版本(Red Had Enterprise Edition)。RHEL 为其提供源代码, CentOS 将去掉品牌和商标并修改为最终的成品。
|
||||
|
||||
### Ubuntu
|
||||
|
||||
Ubuntu 是一个基于 Debian 的 Linux 系统，目前用在桌面、服务器、智能手机和平板上。 Ubuntu 由 Canonical Ltd 公司开展，该公司在英国成立并由 South African Mark Shuttleworth 资助。
|
||||
|
||||
拓展 - [10 Things To Do After Installing Ubuntu 16.10][2]
|
||||
|
||||
### Ubuntu 设计
|
||||
|
||||
Ubuntu 是一个依靠全世界的开发者贡献的开源发行版本。近年来它的界面越发直观和现代，整个系统已经变得反应快速，更加安全并拥有海量的可供下载的软件资源。
|
||||
|
||||
因为基于[Debian][10]，它支持 .deb 格式的软件包，发布最近了一个更加发安全的软件包系统[snap package format (snappy)][11]。
|
||||
|
||||
这个新的软件包系统允许应用程序交付而不需担心依赖。
|
||||
|
||||
拓展 - [LinuxAndUbuntu Review Of Unity 8 In Ubuntu 16.10][3]
|
||||
|
||||
### CentOS 和 Ubuntu 之间的不同
|
||||
|
||||
* ubuntu基于 Debian 而 CentOS 基于 RHEL;
|
||||
* Ubuntu 使用 .deb 和 .snap 软件包，而 centOS 使用 .rpm 和 flatpak;
|
||||
* Ubuntu 使用 apt 指令来升级 而 centOS 使用同 YUM;
|
||||
* 因为不需要定期升级软件包,所以 CentOS 显得更加稳定。但是这并不意味着 ubuntu 相对不安全;
|
||||
* Ubuntu 有着更丰富的文档并且提供免费技术支持;
|
||||
* Ubuntu 服务器版本对云部署和勇气部署有着更好的支持。
|
||||
|
||||
### 结论
|
||||
|
||||
不管你的选择是什么，**Ubuntu or CentOS** 这两个发行版本都非常棒并且稳定。如果你想拥有短的版本周期你将忠于 ubuntu， 如果你不希望发行版本改变它的软件包太快你将经常使用 CentOS。请在下部留言来告诉我你更喜欢哪个发行版本。|
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxandubuntu.com/home/centos-vs-ubuntu
|
||||
|
||||
作者：[linuxandubuntu.com][a]
|
||||
译者：[Yoo-4x]
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.linuxandubuntu.com/home/centos-vs-ubuntu
|
||||
[1]:http://www.linuxandubuntu.com/home/how-to-install-centos
|
||||
[2]:http://www.linuxandubuntu.com/home/10-things-to-do-after-installing-ubuntu-16-04-xenial-xerus
|
||||
[3]:http://www.linuxandubuntu.com/home/linuxandubuntu-review-of-unity-8-preview-in-ubuntu-1610
|
||||
[4]:http://www.linuxandubuntu.com/home/centos-vs-ubuntu
|
||||
[5]:http://www.linuxandubuntu.com/home/centos-vs-ubuntu
|
||||
[6]:http://www.linuxandubuntu.com/home/centos-vs-ubuntu#comments
|
||||
[7]:http://www.linuxandubuntu.com/home/how-to-create-a-linux-distro
|
||||
[8]:http://www.linuxandubuntu.com/home/10-things-to-do-after-installing-centos
|
||||
[9]:https://en.wikipedia.org/wiki/Open-source_software
|
||||
[10]:https://www.debian.org/
|
||||
[11]:https://en.wikipedia.org/wiki/Snappy_(package_manager)
|
||||
84
translated/tech/20170316 What is Linux VPS Hosting.md
Normal file
84
translated/tech/20170316 What is Linux VPS Hosting.md
Normal file
@ -0,0 +1,84 @@
|
||||
|
||||
什么是 Linux VPS Hosting？
|
||||
============================================================
|
||||
|
||||
|
||||
|
||||
如果你有一个吞吐量很大的网站，或者至少，你想要增加你的网站吞吐量，那么你可以考虑使用 [Linux VPS hosting][6] 包 。你可以把它安装在网站所在的服务器上，如果你想要控制除此之外的很多事情，那么 Linux VPS hosting 包就是最好的选择之一。这里我会回答一些频繁被提及的关于 Linux VPS hosting 的问题。
|
||||
|
||||
|
||||
### Linux VPS 意味着什么？
|
||||
事实上， Linux VPS 就像一个运行在 Linux 系统上的虚拟专属服务器 。虚拟专属服务器是一个在物理服务器上的虚拟服务主机 。这种虚拟专属服务器运行在物理主机的内存里。物理主机可以轮流运行很多其他的虚拟专属服务器 。
|
||||
|
||||
### 我必须和其他用户共享服务器吗？
|
||||
一般是这样的。但这并不意味着下载时间变长或者服务器性能降低。每个虚拟服务器可以运行它自己的操作系统，这些系统之间可以相互独立的进行管理。一个虚拟专属服务器有它自己的操作系统、数据、应用程序；它们都与物理主机和其他虚拟服务器中的操作系统、应用程序、数据相互分离。
|
||||
|
||||
尽管必须和其他虚拟专属服务器共享物理主机，但是你却可以不需花费大价钱得到一个昂贵专用服务器的诸多好处。
|
||||
|
||||
### Linux VPS hosting 的优势是什么？
|
||||
使用 Linux VPS hosting 服务会有很多的优势，包括容易使用、安全性增加以及在更低的总体成本上提高可用性。然而，对于大多数网站管理者、程序员、设计者和开发者来说，使用 Linux VPS hosting 服务的最大的优势是它的灵活性。每个虚拟专属务器都和它自己的操作环境相互隔离，这意味着你可以容易且安全的安装一个你喜欢的或者迫切需要的操作系统，每当你想要安装操作系统的时候，你可以很容易的卸载或者安装软件及应用程序。
|
||||
|
||||
|
||||
你也可以更改你的 VPS 环境以适应你的性能需求，同样也可以提高你的网站用户或访客的体验。灵活性会是你超越对手的主要优势。
|
||||
|
||||
记住，一些 Linux VPS 提供商可能不会给你 root 权限。这样你的服务器性能就会受到限制。要确定你得到的是 [拥有 root 权限的 Linux VPS][7] ，这样你就可以做任何你想做的修改。
|
||||
|
||||
|
||||
### 任何人都可以使用 Linux VPS hosting 吗？
|
||||
当然，你甚至可以运行一个专门的个人兴趣博客，你可以从 Linux VPS hosting 包中受益。如果你为公司搭建开发一个网站，你也会获益匪浅。基本上，如果你想使你的网站更健壮并且增加它的网络吞吐量，那么 Linux VPS 就是为你而生。
|
||||
|
||||
|
||||
个人和企业在进行定制开发的时候都需要很大的灵活行，所以他们肯定会选择 Linux VPS ; 特别是那些正在寻找不使用专用服务器就能得到高性能服务的人们，专用服务器会消耗大量的网站运营成本。
|
||||
|
||||
|
||||
### 不会使用 Linux 也可以使用 Linux VPS 吗？
|
||||
当然，如果 Linux VPS 由你管理，你的 VPS 提供商会为你管理整个服务器。更有可能，他们将会为你安装、配置一切你想要运行在 Linux VPS 上的服务。如果你使用我们的 VPS，我们会全天候的为你看管 7 天，也会安装、配置 、优化一切服务。这些免费的服务都被包括在所有的我们的 [Linux VPS hosting 管理器][8] 包里。
|
||||
|
||||
如果你使用我们的主机服务，你会从 Linux VPS 中获益匪浅，并且不需要任何 Linux 工作经验。
|
||||
|
||||
另一个方面，对于使用 Linux VPS 的新手来说，得到一个 [带有控制面板的 VPS][9]、 [DirectAdmin][10] 或者任何 [其他的主机控制面板][11] 都是很容易的。如果你使用控制面板，就可以通过一个 GUI 管理你的服务器，尤其对于新手，它是很容易使用的。[使用命令行管理 Linux VPS][12] 很有趣，而且你还可以在实践中学到很多。
|
||||
|
||||
### Linux VPS 和专用服务器有什么不同？
|
||||
如前所述，一个虚拟专属服务器仅仅是在物理主机上的一个虚拟分区。物理服务器与很多虚拟服务器相互分离，这些虚拟服务器可以降低多个虚拟分区用户的网站维护成本和开销。这就是 Linux VPS 相比一个 [专用服务器][13] 更加便宜的原因，专用服务器的字面意思就是指只有一个用户专用。想要知道关于更多不同点的细节，可以查看 [物理服务器（专用的）vs 虚拟服务器(VPS) 比较][14]。
|
||||
|
||||
除了比专用服务器有更好的成本效益，Linux 虚拟专属服务器经常运行在主机上，所以它比专用服务器的性能更强大，同时它的容量也比专用服务器更大。
|
||||
|
||||
### 我可以把网站从共享主机环境迁移到到 Linux VPS 上吗？
|
||||
如果你当前使用 [共享主机服务][15]，你可以很容易的迁移到 Linux VPS 上。一种做法就是 [让它自己完成迁移][16]，但是迁移过程很复杂，不建议新手使用。最好的方法是找到一个提供 [免费网站迁移][17] 的主机，然后让它们帮你完成迁移。你还可以从一个带有控制面板的共享主机迁移到一个不带有控制面板的 Linux VPS 。
|
||||
|
||||
### 更多问题？
|
||||
随时在下面留下评论。
|
||||
如果你使用我们提供的 VPS，我们的 Linux 管理专家会帮助你完成需要在你的 Linux VPS 上的一切工作，并且会回答你的一切关于使用 Linux VPS 的问题。我们的管理员会一周全天候在线及时解决你的问题。
|
||||
|
||||
PS. 如果你喜欢这个专栏，请使用下面的按钮把它分享给你的网友，或者你也可以在下面的评论区写下你的答复。谢谢。
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.rosehosting.com/blog/what-is-linux-vps-hosting/
|
||||
|
||||
作者：[https://www.rosehosting.com ][a]
|
||||
译者：[vim-kakali](https://github.com/vim-kakali)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.rosehosting.com/blog/what-is-linux-vps-hosting/
|
||||
[1]:https://www.rosehosting.com/blog/what-is-linux-vps-hosting/
|
||||
[2]:https://www.rosehosting.com/blog/what-is-linux-vps-hosting/#comments
|
||||
[3]:https://www.rosehosting.com/blog/category/guides/
|
||||
[4]:https://plus.google.com/share?url=https://www.rosehosting.com/blog/what-is-linux-vps-hosting/
|
||||
[5]:http://www.linkedin.com/shareArticle?mini=true&url=https://www.rosehosting.com/blog/what-is-linux-vps-hosting/&title=What%20is%20Linux%20VPS%20Hosting%3F&summary=If%20you%20have%20a%20site%20that%20gets%20a%20lot%20of%20traffic,%20or%20at%20least,%20is%20expected%20to%20generate%20a%20lot%20of%20traffic,%20then%20you%20might%20want%20to%20consider%20getting%20a%20Linux%20VPS%20hosting%20package.%20A%20Linux%20VPS%20hosting%20package%20is%20also%20one%20of%20your%20best%20options%20if%20you%20want%20more%20...
|
||||
[6]:https://www.rosehosting.com/linux-vps-hosting.html
|
||||
[7]:https://www.rosehosting.com/linux-vps-hosting.html
|
||||
[8]:https://www.rosehosting.com/linux-vps-hosting.html
|
||||
[9]:https://www.rosehosting.com/cpanel-hosting.html
|
||||
[10]:https://www.rosehosting.com/directadmin-hosting.html
|
||||
[11]:https://www.rosehosting.com/control-panel-hosting.html
|
||||
[12]:https://www.rosehosting.com/blog/basic-shell-commands-after-putty-ssh-logon/
|
||||
[13]:https://www.rosehosting.com/dedicated-servers.html
|
||||
[14]:https://www.rosehosting.com/blog/physical-server-vs-virtual-server-all-you-need-to-know/
|
||||
[15]:https://www.rosehosting.com/linux-shared-hosting.html
|
||||
[16]:https://www.rosehosting.com/blog/from-shared-to-vps-hosting/
|
||||
[17]:https://www.rosehosting.com/website-migration.html
|
||||
@ -0,0 +1,119 @@
|
||||
[GitHub 风味的 Markdown 的正式规范][8]
|
||||
====================
|
||||
|
||||
很庆幸，我们当初选择 Markdown 作为用户在 GitHub 上托管内容的标记语言，它为用户提供了强大且直接的方式 (不管是技术的还是非技术的) 来编写可以很好的渲染成 HTML 的纯文本文档。
|
||||
|
||||
其最主要的限制，就是缺乏在最模糊的语言细节上的标准。比如，使用多少个空格来进行行缩进、两个不同元素之间需要使用多少空行区分、大量繁琐细节往往造成不同实现之间的改变：相似的 Markdown 文档会因为你选用的语法解析器而渲染成大量不同的呈现效果。
|
||||
|
||||
五年前，我们在 [Sundown][13] 的基础之上开始构建 GitHub 自定义版本的 Markdown —— GFM (GitHub 风味的 Markdown)，这是我们特地为解决当时已有的 Markdown 解析器的不足而开发的一款解析器。
|
||||
|
||||
今天，我们希望通过发布 GitHub 风味的 Markdown 的正式语法规范及其相应的参考实现能够改善现状。
|
||||
|
||||
该正式规范基于 [CommonMark][14]，这是一个有野心的项目，旨在通过一个反应现实世界用法的方式来规范目前互联网上绝大多数网站使用的 Markdown 语法。CommonMark 运行人们以他们原有的习惯来使用 Markdown，同时为开发者提供一个综合规范和参考实例，从而实现跨平台的 Markdown 互操作和显示。
|
||||
|
||||
#### 规范
|
||||
|
||||
使用 CommonMark 规范并围绕它来重设我们当前用户内容堆栈并非微不足道。目前，我们纠结的主要问题是该规范 (及其参考实现) 过多关注有原生 Perl 实现支持的 Markdown 通用子集。这还不包括那些 GitHub 上已经在用的扩展特性。最明显的就是缺少 _表格 (tables)、删除线 (strikethrough)、自动链接 (autolinks)_ 和 _任务列表 (task lists)_ 的支持。
|
||||
|
||||
为完全指定 GitHub 的 Markdown 版本 (也成为 GFM)，我必须要要正式定义这些特性的的语法和语意。我们是在现存的 CommonMark 规范中来完成这一项工作的，同时还特意关注以确保我们的扩展处于一个严格模式并且是原有规范的一个超集。
|
||||
|
||||
当评估 [GFM 规范][15] 的时候，你可以清楚的了解那些是 GFM 规范的扩展功能，因为它们都是高亮显示了。并且你也会看到原有规范的所有部分都保存原样，因此，GFM 规范能够与其他任何实现兼容。
|
||||
|
||||
#### 实现
|
||||
|
||||
为确保我们网站中的 Markdown 渲染能够完美兼容 CommonMark 规范，GitHub 的 GFM 解析器的后端实现基于 `cmark`来开发，这是 CommonMark 规范的一个参考实现，由 [John MacFarlane][16] 和 许多其他的 [出色的贡献者][17] 开发完成的。
|
||||
|
||||
就像规范本身那样，`cmark` 是 Markdown 的严格子集解析器，所以我们还必须在现存解析器的基础上完成 GitHub 自定义扩展的解析功能。你可以通过 [`cmark` 的分支][18] 来查看变更记录；为了与跟踪上游项目，我们定义将我们的 patches 变基到上游主线上去。我们希望，这些扩展的正式规范一旦确定，这些 patch 集同样可以应用到原始项目的上游变更中去。
|
||||
|
||||
除了在 `cmark` 分支中实现 GFM 规范特性，我们也同时将许多目标相似的变更贡献到上游。绝大多数的贡献都主要围绕性能和安全。我们的后端每天都需要渲染大量的 Markdown 文档，所以我们主要关注这些操作可以尽可能的高效率完成，同时还要确保那些滥用的恶意 Markdown 文档无法攻击到我们的服务器。
|
||||
|
||||
第一版使用 C 语言编写的解析器存在严重的安全隐患：通过足够深度的特殊 Markdown 元素的嵌套，它可能造成堆栈溢出 (甚至有时候可以运行任意代码)。而 `cmark` 实现就行我们之前设计的解析器 Sundown，为抵御这些攻击而专门进行从零开始设计。其解析算法和基于 AST 的输出主要用以优雅的解决深层递归以及其他的恶意文档格式。
|
||||
|
||||
`cmark` 在性能方面则是有点粗糙：根绝当时构建 Sundown 所了解到的性能技巧，我们向上游贡献了许多最优方案，但除去所有这些变更之外，当前版本的 `cmark` 仍然无法与 Sundown 匹敌：我们的基准测试表明，`cmark` 在绝大多数文档渲染的性能上要比 Sundown 低 20% 到 30%。
|
||||
|
||||
那句古老的优化谚语 _最快的代码就是不需要运行的代码 (the fastest code is the code that doesn’t run)_ 在此处同样适用：实际上，`cmark` 比 Sundown 要进行 _多一些操作_。在其他的功能上，`cmark` 支持 UTF8 字符集，对参考的支持、扩展的接口清理的效果更佳。最重要的是它如同 Sundown 那样，并不会将 Markdown _翻译成_ HTML。它实际上从 Markdown 源码中生成一个 AST (抽象语法树，Abstract Syntax Tree)，然后我们就看将之转换和逐渐渲染成 HTML。
|
||||
|
||||
如果你有想过我们处理 Sundown 的原型实现 (特别是文档中关于查询用户的 mention 和 issue 参考、插入任务列表等) 时的 HTML 语法剖析，你会发现 `cmark` 基于 AST 的方法可以节约大量时间 _和_ 降低我们用户内容堆栈的复杂度。Markdown AST 是一个非常强大的工具，并且值得 `cmark` 生成它所付出的性能成本。
|
||||
|
||||
### 迁移
|
||||
|
||||
变更我们用户的内容堆栈以兼容 CommonMark 规范，并不同于转换我们曾用于解析 Markdown 的库那样容易：目前我们在遇到最根本的障碍就是由于一些不常用语法 (LCTT 译注：原文是 the Corner，作为名词的原意为角落、偏僻处、窘境，这应该是指那些不常用语法)，CommonMark 规范 (以及有歧义的 Markdown 原文) 可能会以一种意想不到的凡是来渲染一些老旧的 Markdown 内容。
|
||||
|
||||
通过综合分析 GitHub 中大量的 Markdown 语料库，我们断定现存的用户内容只有不到 1% 会受到新版本实现的影响：我们是通过同时使用新 (`cmark`，兼容 CommonMark 规范) 旧 (Sundown) 版本的库来渲染大量的 Markdown 文档、标准化 HTML 结果、分析它们的不同点，最后才得到这一个数据的。
|
||||
|
||||
|
||||
只有 1% 的文档存在少量的渲染问题，使得换用新实现并获取其更多出看起来是非常合理的权衡，但是是根据当前 GitHub 的规模，这个 1% 是非常多的内容以及很多的受影响用户。我们真的不想导致任何用户需要重新校对一个老旧的问题、看到先前可以渲染成 HTML 的内容又呈现为 ASCII 码 —— 尽管这明显不会导致任何原始内容的丢失，却是糟糕的用户体验。
|
||||
|
||||
因此，我们相处相应的方法来缓和迁移过程。首先，第一件我们做的事就是收集用户托管在我们网站上的两种不同类型 Markdown 的数据：用户的评论 (比如Gists、issues、PR 等)以及在 git 仓库中的 Markdown 文档。
|
||||
|
||||
这两种内容有着本质上的区别：用户文档存储在我们的数据库中，这意味着他们的 Markdown 语法可以标准化 (比如添加或移除空格、修正缩进或则插入缺失的 Markdown 说明符，直到它们可正常渲染为止)。然而，那些存储在 Git 仓库中的 Markdown 文档则是 _根本_ 无法触及，因为这些内容已经散列成为 Git 存储模型的一部分。
|
||||
|
||||
幸运的是，我们发现绝大多数使用了复杂的 Markdown 特性的用户内容都是用户评论 (特别是 issue 主体和 PR 主体)，而存储于仓库中的文档则大多数情况下都可以使用新旧渲染器下正常进行渲染。
|
||||
|
||||
因此，我们加快了标准化现存用户内容的语法的进程，以便是她们在新旧实现下渲染效果一致。
|
||||
|
||||
我们用以文档转换的方法相当实用：我们那个旧的 Markdown 解析器 Sundown 更多的是扮演着翻译器而非解析器的角色。输入 Markdown 内容之后，一系列的语意回调就会把原始的 Markdown 内容转换为目标语言 (在我们的实际适用中则是 HTML5) 的对应标记。基于这一设计方法，我们决定适用语意回调让 Sumdown 将原始 Markdown 转换为兼容 CommonMark 的 Markdown，而非 HTML。
|
||||
|
||||
除了转换之外，这还是一个高效的标准化过程，并且我们对此信心满满，毕竟完成这一任务的是我们在 5 五年前就使用过的解析器。因此，所有的现存文档在保留其原始语意的情况下都能够进行明确的解析。
|
||||
|
||||
一旦升级 Sundown 来标准化输入文档并充分测试之后，我们就会做好了开启转换进程的准备。最开始的一步，就是在新的 `cmark` 实现上为所有的用户内容进行反置转换，以便确保我们能有一个有限的分界点来进行过渡。我们将为网站上这几个月内所有 **新的** 用户评论启用 CommonMark，这一过程不会引起任何人注意的 —— 他们这是一个关于 CommonMark 团队出色工作的圣约,通过一个最具现实世界用法的方式来正式规范 Markdown 语言.
|
||||
|
||||
在后端，我们开启 MySQL 转换来升级替代用户的 Markdown 内容。在所有的评论进行标准化之后，在将其写回到数据库之前，我们将使用新实现来进行渲染并与旧实现的渲染结果进行对比，以确保 HTML 输出结果视觉可鉴以及用户数据在任何情况下都不被破坏。总而言之，只有不到 1% 的输入文档会受到表彰进程的修改，这符合我们的的期望，同时再次证明 CommonMark 规范能够呈现语言的真实用法。
|
||||
|
||||
整个过程会持续好几天，最后的结果是网站上所有的 Markdown 用户内容会得到全面升级以符合新的 Markdown 标准，同时确保所有的最终渲染输出效果都对用户视觉可辩。
|
||||
|
||||
#### 结论
|
||||
|
||||
从今天 (LCTT 译注：原文发布于 2017 年 3 月 14 日，这里的今天应该是这个日期) 开始， 我们同样为所有存储在 Git 仓库中的 Markdown 内容启动 CommonMark 渲染。正如上文所述，所有的现存文档都不会进行标准化，因为我们所期望中的多数渲染效果都刚刚好。
|
||||
|
||||
能够让在 GitHub 上的所有 Markdown 内容符合一个动态变化且使用的标准，同时还可以为我的用户提供一个关于 GFM 如何进行解析和渲染 [清晰且权威的参考说明][19]，我们是相当激动的。
|
||||
|
||||
我们还将致力于 CommonMark 规范，一直到在它正式发布之前消沉最后一个 bug。我们也希望 GitHub.com 在 1.0 规范发布之后可以进行完美兼容。
|
||||
|
||||
作为结束，以下为想要学习 CommonMark 规范或则自己来编写实现的朋友提供一些有用的链接。
|
||||
|
||||
* [CommonMark 主页][1]，可以了解该项目该多信息
|
||||
* [CommonMark 论坛讨论区][2]，可以提出关于该规范的的问题和更改建议
|
||||
* [CommonMark 规范][3]
|
||||
* [使用 C 语言编写的参考实现][4]
|
||||
* [Our fork with support for all GFM extensions][5]
|
||||
* [GFM 规范][6]，基于原始规范
|
||||
* [使用其他编程语言编写的 CommonMark 实现列表][7]
|
||||
|
||||
-------------------------------
|
||||
|
||||
译者简介：
|
||||
|
||||
[GHLandy](http://GHLandy.com) —— 生活中所有欢乐与苦闷都应藏在心中，有些事儿注定无人知晓，自己也无从说起。
|
||||
|
||||
-------------------------------
|
||||
|
||||
via: https://githubengineering.com/a-formal-spec-for-github-markdown/
|
||||
|
||||
作者：[Yuki Izumi][a][Vicent Martí][b]
|
||||
译者：[GHLandy](https://github.com/GHLandy)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://github.com/kivikakk
|
||||
[b]:https://github.com/vmg
|
||||
[1]:http://commonmark.org/
|
||||
[2]:http://talk.commonmark.org/
|
||||
[3]:http://spec.commonmark.org/
|
||||
[4]:https://github.com/jgm/cmark/
|
||||
[5]:https://github.com/github/cmark/
|
||||
[6]:https://github.github.com/gfm/
|
||||
[7]:https://github.com/jgm/CommonMark/wiki/List-of-CommonMark-Implementations
|
||||
[8]:https://githubengineering.com/a-formal-spec-for-github-markdown/
|
||||
[9]:https://github.com/vmg
|
||||
[10]:https://github.com/vmg
|
||||
[11]:https://github.com/kivikakk
|
||||
[12]:https://github.com/kivikakk
|
||||
[13]:https://github.com/vmg/sundown
|
||||
[14]:http://commonmark.org/
|
||||
[15]:https://github.github.com/gfm/
|
||||
[16]:https://github.com/jgm
|
||||
[17]:https://github.com/jgm/cmark/#authors
|
||||
[18]:https://github.com/github/cmark
|
||||
[19]:https://github.github.com/gfm/
|
||||
Loading…
Reference in New Issue
Block a user