mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
kaiyao
commit
f98cf41d24
@ -1,12 +1,12 @@
|
||||
Linux 截屏软件 Shutter 更新了新图标，修复了漏洞
|
||||
Linux 截屏软件 Shutter
|
||||
================================================================================
|
||||
|
||||
|
||||
**[Shutter][1]，是一款Linux平台下最受欢迎的截屏软件。最近的更新中，该软件修复了若干bug，并且使用了新的应用图标。**
|
||||
**[Shutter][1]，是一款Linux平台下广受欢迎的截屏软件。最近的更新中，该软件修复了若干bug，并且使用了新的应用图标。**
|
||||
|
||||
这款开源并且功能强大的截屏工具可以让你选择桌面的任意区域、指定应用窗口或者整个屏幕区域来进行截屏。此外，你还可以添加注释、文本或者特效。
|
||||
|
||||
0.91版本修复了若干明显的bug，包括在Ubuntu 14.04中缩略图无法正常地在应用切换栏中显示的问题。由于'imm.io'在今年早期停止服务，所以此次更新还取消了将截图上传到Pixlr图像服务的选项。
|
||||
0.91版本修复了若干明显的bug，包括在Ubuntu 14.04中缩略图无法正常地在应用切换栏中显示的问题。由于'imm.io'在今年早期停止了服务，所以此次更新还取消了将截图上传到Pixlr图像服务的选项。
|
||||
|
||||
最后，这次更新突出了由 Lucas Romero Di Benedetto 精心设计的相机快门式应用图标。
|
||||
|
||||
@ -2,9 +2,9 @@
|
||||
================================================================================
|
||||
[NeoBundle][1] 是一个 [Vim][2] 的插件管理器，以 [Vundle][3] 为基础（Vundle 是一个基于 [Pathogen][4] 的 Vim 插件管理器）。在之前的文章中，我[非常不推荐使用 Neobundle][5]，原因是它当时还处于高速开发阶段（LCTT：意味着不稳定、变数大），并且当时它的英文文档很少。现在，已经过了一年多了，这两个问题都早已不再是问题。
|
||||
|
||||
我们为什么要使用插件管理器？Vim 支持大量插件，但是由于它没有严格定义框架，插件的文件可以胡乱分布在不同目录下，导致用户管理起来会很困难（LCTT：当然，前提是你有很多插件，还有点小小的强迫症，觉得理一理这些插件心里会舒服点）。而一款插件管理器能让管理变得简单许多。Pathogen, Vundle 和 NeoBundle 的工作就是为不同插件建立一个目录，然后将这些目录扔到 ~/.vim/bundle 目录下。这个文件整理方法可以让你方便彻底地删除插件，使用 'rm -rf <插件目录>' 或直接 'Ctrl + Del' 组合键把插件所在的目录删除就可以了，绝对绿色环保无残留。同时，这种方法还能最大程度避免插件与插件之间的不兼容性。
|
||||
我们为什么要使用插件管理器？Vim 支持大量插件，但是由于它没有严格定义框架，插件的文件可以胡乱分布在不同目录下，导致用户管理起来会很困难（LCTT：当然，前提是你有很多插件，还有点小小的强迫症，觉得理一理这些插件心里会舒服点）。而一款插件管理器能让管理变得简单许多。Pathogen, Vundle 和 NeoBundle 的工作就是为不同插件建立一个目录，然后将这些目录扔到 ~/.vim/bundle 目录下。这个文件整理方法可以让你方便彻底地删除插件，使用 'rm -rf <插件目录>' 或直接在文件管理器里面把插件所在的目录删除就可以了，绝对绿色环保无残留。同时，这种方法还能最大程度避免插件与插件之间的不兼容性。
|
||||
|
||||
NeoBundle 是一个基于 Vundle 的项目，如同 Vundle，它们都可以安装和升级插件。然而 NeoBundle 的说明文件上明确指出：“NeoBundle 不是一个稳定的插件管理器，如果你想要一个稳定的，请选择 Vundle”。最新的 release-note 上也有警“可能会造成兼容性问题”——这是一个开发者写的注解，说明这个管理器还不能让人放心使用。
|
||||
NeoBundle 是一个基于 Vundle 的项目，如同 Vundle，它们都可以安装和升级插件。然而 NeoBundle 的说明文件上明确指出：“NeoBundle 不是一个稳定的插件管理器，如果你想要一个稳定的，请选择 Vundle”。最新的 release-note 上也有警告“可能会造成兼容性问题”——这是一个开发者写的注解，说明这个管理器还不能让人放心使用。
|
||||
|
||||
所以，我们为什么要使用 NeoBundle？它都不能保证稳定运行！好吧，它还是有可取之处的。Vundle 只支持 [Git][6] 这种版本控制系统，而 NeoBundle 可以支持 [Subversion][7] 和 [Mercurial][8]。另一个原因是如果你不想插件升级时破坏你的 Vim 生态环境，你可以锁住 NeoBundle，让它只使用某个插件的固定版本。
|
||||
|
||||
@ -12,11 +12,11 @@ NeoBundle 是一个基于 Vundle 的项目，如同 Vundle，它们都可以安
|
||||
|
||||
### 安装并初始化 NeoBundle ###
|
||||
|
||||
NeoBundle 依赖 Vim 7.2.051 或更高版本，依赖 git，依赖 [cURL][12]（用于下载文件）。你可以手动下载 NeoBundle，也可以使用 cURL 下载它在 GitHub 上的库。在你的 home 目录下使用如下命令，可以将 NeoBundle 插件下载到 .vim/bundle/neobundle.vim 目录里，然后 NeoBundle 就能管理它自己了。
|
||||
NeoBundle 支持 Vim 7.2.051 或更高版本，需要 git 和 [cURL][12]（用于下载文件）。你可以手动下载 NeoBundle，也可以使用 cURL 下载它在 GitHub 上的库。在你的 home 目录下使用如下命令，可以将 NeoBundle 插件下载到 .vim/bundle/neobundle.vim 目录里，然后 NeoBundle 就能管理它自己了。
|
||||
|
||||
curl https://raw.githubusercontent.com/Shougo/neobundle.vim/master/bin/install.sh | sh
|
||||
|
||||
你还需要修改 .vimrc 文件。NeoBundle 的 GitHub 主页提供一个 .vimrc 范本，使用这个范本后，NeoBundle 会为你下载5个插件。如果不需要它们，你可以使用下面的最小配置：
|
||||
你还需要修改 .vimrc 文件。NeoBundle 的 GitHub 主页提供一个 .vimrc 范本，但是直接使用这个范本，NeoBundle 需要你安装5个可能不需要插件。如果不需要它们，你可以使用下面的最小配置：
|
||||
|
||||
if has('vim_starting')
|
||||
set nocompatible
|
||||
@ -40,17 +40,17 @@ NeoBundle 依赖 Vim 7.2.051 或更高版本，依赖 git，依赖 [cURL][12]（
|
||||
|
||||
NeoBundle 'tpope/vim-abolish'
|
||||
|
||||
再介绍一个小技巧：你可以为插件指定一个分支或版本号。什么意思？NeoBundle 只会关注这个插件的某个分支或版本的更新，而忽略其他更新。如果你使用的某个插件处于高速开发过程，你就可以使用这个技巧，避免用到有 bug 的插件版本。举个例子：
|
||||
再介绍一个小技巧：你可以为插件指定一个分支或版本号。什么意思？NeoBundle 只会使用这个插件的某个分支或版本，而忽略其版本更新。如果你使用的某个插件处于高速开发过程，你就可以使用这个技巧，避免用到有 bug 的插件版本。举个例子：
|
||||
|
||||
NeoBundle 'Shougo/vimshell', { 'rev' : '3787e5' }
|
||||
|
||||
还有一个技巧：在 .vimtc 文件内添加一行关于“NeoBundleCheck”的属性。NeoBundle 会检查被卸载的插件，并提示你安装它们。你也可以使用命令“:NeoBundleInstall”（LCTT：这是要在 Vim 编辑器的命令模式下输入）来安装或升级插件。
|
||||
还有一个技巧：在 .vimtc 文件内添加一行关于“NeoBundleCheck”的属性。NeoBundle 会根据配置检查没安装的插件，并提示你安装它们。你也可以使用命令“:NeoBundleInstall”（LCTT：这是要在 Vim 编辑器的命令模式下输入）来安装或升级插件。
|
||||
|
||||
### NeoBundle 用法 ###
|
||||
|
||||
很多 NeoBundle 命令用起来和 Vundle 类似，但命令的名字不一样。下面是 NeoBundle 命令的用法：
|
||||
|
||||
- `:NeoBundleUpdate`：安装或升级插件，如果你手动把一个插件的目录删除了，这个命令会重新安装这个插件。在这个命令后面加上插件名称，就只升级一个插件；不加参数，会将所有己安装但没被记录在案的插件给记录下来。“:NeoBundleInstall”命令效果相同。
|
||||
- `:NeoBundleUpdate`：安装或升级插件，如果你手动把一个插件的目录删除了，这个命令会重新安装这个插件。在这个命令后面加上插件名称，就只升级一个插件；不加参数，会将所有己安装但没被记录在案的插件给记录下来。`:NeoBundleInstall` 命令效果相同。
|
||||
- `:NeoBundle {REPOSITORY URI} [[REVISION}] [,OPTIONS}]]`：将一个插件锁定到固定版本，防止胡乱升级。
|
||||
- `:NeoBundleList`：列出所有未初始化的插件。
|
||||
- `:NeoBundleClean`：进入交互界面，删除插件。
|
||||
@ -59,7 +59,7 @@ NeoBundle 依赖 Vim 7.2.051 或更高版本，依赖 git，依赖 [cURL][12]（
|
||||
|
||||
### 是否使用 NeoBundle，自己决定 ###
|
||||
|
||||
NeoBundle 是强大的工具，正处于高速开发状态。任何处于这种状态的项目，都会被帖上“有前途”和“不稳定”两个标签，看你自己怎么选。如果你想要最新的稳定版本的插件，NeoBundle 可以让 Vundle 和 Pathogen 永远保持在老界面。
|
||||
NeoBundle 是强大的工具，正处于高速开发状态。任何处于这种状态的项目，都会被帖上“有前途”和“不稳定”两个标签，看你自己怎么选。如果你想要最新的稳定版本的插件，NeoBundle 能够把 Vundle 和 Pathogen 甩出几条街。
|
||||
|
||||
然而在线帮助文档已经给出警告，它不是个稳定的产品，不及时更新版本可能造成一些插件运行出错。最后，你需要在 .vimrc 文件为你的 Neoundle 和其他插件指定一个稳定的版本。记住这警告，然后你可以在使用这些尖端技术产品时游刃有余。
|
||||
|
||||
@ -67,7 +67,7 @@ NeoBundle 是强大的工具，正处于高速开发状态。任何处于这种
|
||||
|
||||
via: http://www.openlogic.com/wazi/bid/348084/Managing-Vim-extensions-with-NeoBundle
|
||||
|
||||
译者：[bazz2](https://github.com/bazz2) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
译者：[bazz2](https://github.com/bazz2) 校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,97 @@
|
||||
Linux 目录导航技巧
|
||||
================================================================================
|
||||
|
||||
目录当行是命令行系统的基础概念.虽然不是什么难以理解的东西，但是知道一些技巧能够丰富你的经验并且提高工作效率.在这篇文章中,我们会讨论这些小技巧。
|
||||
|
||||
### 我们已经知道的东西 ###
|
||||
|
||||
在开始高级技巧之前，有一些必须知道的基本命令：
|
||||
|
||||
- ‘pwd’显示当前目录
|
||||
- ‘cd’ 改变当前目录
|
||||
- ‘cd’ 跟两个点(cd ..)能返回父目录
|
||||
- ‘cd’ 跟着相对目录就能直接切换当相对目录下
|
||||
- ‘cd’ 跟着绝对目录就能切换到绝对目录下
|
||||
|
||||
### 高阶技巧 ###
|
||||
|
||||
这节将介绍几个技巧方便你进行目录的切换
|
||||
|
||||
### 从任何地方回到home目录 ###
|
||||
|
||||
虽然使用‘cd /home/<你的主目录>’, 不是什么大麻烦, 但是有一种方法直接打‘cd’ 就能回到你的主目录.
|
||||
|
||||
例子：
|
||||
|
||||
$ pwd
|
||||
/usr/include/netipx
|
||||
$ cd
|
||||
$ pwd
|
||||
/home/himanshu
|
||||
|
||||
所以无论你在哪个目录下，都能这么干，然后回到home目录。
|
||||
|
||||
**注意**- 如果要切换到某个其它的指定用户的目录下, 就使用 ‘cd ~user_name'
|
||||
|
||||
### 用cd - 在目录间切换 ###
|
||||
|
||||
假设你的当前工作目录是这样的：
|
||||
|
||||
$ pwd
|
||||
/home/himanshu/practice
|
||||
|
||||
如果你想切换到 **/usr/bin/X11**， 然后又想回到之前的目录。 你会怎么做? 最直接的 :
|
||||
|
||||
$ cd /usr/bin/X11
|
||||
$ cd /home/himanshu/practice/
|
||||
|
||||
虽然这样行得通，但是要记住这些复杂的目录就太笨了。这种情况下使用 ‘cd -’ 命令就行.
|
||||
|
||||
使用 ‘cd -’的第一步和上面的例子是一样的, 你可以 cd 到你想要切换到的<路径>下，但是回到之前的目录用 ‘cd -’就可以。
|
||||
|
||||
$ cd /usr/bin/X11
|
||||
$ cd -
|
||||
/home/himanshu/practice
|
||||
$ pwd
|
||||
/home/himanshu/practice
|
||||
|
||||
如果你想再次回到刚刚访问的目录(在这个例子中是/usr/bin/X11)，再使用'cd -'就可以。但是这个命令只会记住上一次访问的目录，这是一个缺点。
|
||||
|
||||
### 用 pushd 和 popd 来切换目录 ###
|
||||
|
||||
|
||||
|
||||
如果你对'cd -'非常了解了的话，你会发现这个命令只能帮助你在两个目录之间移动，但是很多场景下需要在很多目录之间切换。比如你要从A切换到B再到C然后又想回到A。
|
||||
|
||||
一般来说，你需要打出A的完整路径，但是如果这个路径非常复杂，将是非常烦人的一件事，特别是在你的切换非常频繁的话。
|
||||
|
||||
一些场景下可以使用 ‘pushd’ 还有 ‘popd’ 命令。 ‘pushd’ 将一个目录存到内存中,‘popd’ 将目录从内存中去除，并且转换到那个目录下。
|
||||
|
||||
例如：
|
||||
|
||||
$ pushd .
|
||||
/usr/include/netipx /usr/include/netipx
|
||||
$ cd /etc/hp/
|
||||
$ cd /home/himanshu/practice/
|
||||
$ cd /media/
|
||||
$ popd
|
||||
/usr/include/netipx
|
||||
$ pwd
|
||||
/usr/include/netipx
|
||||
|
||||
使用‘pushd’ 命令存储当前的工作目录 (用 .表示)， 然后切换到各种各样的目录去。为了返回之前的目录，只要使用 ‘popd’命令就行了。
|
||||
|
||||
（LCTT译注：显然，pushd和popd 是堆栈式操作，你可以push多个目录，然后逐一pop出来，自己试试吧。）
|
||||
（LCTT译注：我们之前介绍的[autojump][1]，更加智能，不过需要安装一下。）
|
||||
|
||||
**注意**- 你也可以使用不带参数的 ‘pushd’ 来切换到之前存储的目录, 但是不会像 ‘popd’ 一样去除这个目录。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://linoxide.com/linux-command/directory-navigations-tips-tricks/
|
||||
|
||||
译者：[ggaaooppeenngg](https://github.com/ggaaooppeenngg) 校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://linux.cn/article-3401-1.html
|
||||
@ -1,19 +1,27 @@
|
||||
Ubuntu 14.04 LTS: 定制 Unity
|
||||
Ubuntu 14.04 LTS: 定制 Unity
|
||||
================================================================================
|
||||
虽然Unity桌面管理器自从伴随 Ubuntu 11.01首次发布以来表现出了强劲的性能，并在可用性上迈进了一大步，但是有人对自定义其外观和行为所带的限制感到反感。我们马上就去看看如何自定义Unity，让你重拾自己掌控桌面的感觉。
|
||||
虽然Unity桌面管理器自从伴随 Ubuntu 11.01首次发布以来表现出了强劲的性能，并在可用性上迈进了一大步，但是有人对自定义其外观和行为所带的限制感到反感。我们现在来看看如何自定义Unity，让你重拾自己掌控桌面的感觉。
|
||||
|
||||
### Unity中的可用定制项目 ###
|
||||
|
||||
在ubuntu 14.04中，Unity 有一些以前没有的可定制项。登入你的 Unity，进入“设置”并选择“显示”，你将看到以下画面：
|
||||
|
||||
|
||||
|
||||
Ubuntu 14.04 LTS 显示和 Unity 设置
|
||||
|
||||
你看到的大多数项目相比Ubuntu 11.01 中所采用的都是新的，而且一些相比较最近的Ubuntu 版本Ubuntu13.10也是新的。从Ubuntu13.10开始，Ubuntu加入了可以改变菜单栏和标题栏大小的新特性。
|
||||
Unity中所特有的一个特性是我们能够打开或者关闭的“粘性边缘”功能，它能让你的鼠标停止在多显示器组的每个屏幕的边缘，它使光标暂时停在边缘，仿佛是鼠标卡住了一样，我们可以选择关闭它。
|
||||
你看到的大多数项目相比 Ubuntu 11.01 而言都是新的，而且一些相比较上一个版本的 Ubuntu13.10 也是新的。从Ubuntu13.10开始，Ubuntu加入了可以改变菜单栏和标题栏大小的新特性。
|
||||
|
||||
Unity中所特有的一个特性是我们能够打开或者关闭的“粘性边缘”功能，它能让你的鼠标停止在多显示器组的每个屏幕的边缘，它使光标暂时停在边缘，仿佛是鼠标卡住了一样，我们可以选择关闭它。（LCTT译注，其实我觉得挺有用的，可以避免无意中切换到其他工作桌面，不要关闭）
|
||||
|
||||
在“设置”中选择“外观”选项，可以看到如下画面。
|
||||
|
||||
|
||||
Ubuntu 14.04 LTS 显示和Unity设置
|
||||
这里我们可以看到对于 Unity 启动器栏被要求最多的选项-能够改变启动器大小的特性。虽然在Ubuntu 11.10及以后的各种版本中可以通过多种方法实现这个特性，但将其放入外观设置中使其显得更加正式。我喜欢它能将启动器图标缩小直至16号的功能（我们接下来所要谈论的工具仅能支持最小调至24号）。
|
||||
|
||||
Ubuntu 14.04 LTS 显示和Unity设置
|
||||
|
||||
这里我们可以看到一个人们最渴望在 Unity 启动器栏中包含的功能-能够改变启动器大小。虽然在Ubuntu 11.10及以后的各种版本中可以通过多种方法实现这个特性，但将其放入外观设置中使其显得更加正式。我喜欢它能将启动器图标缩小直至16的功能（我们接下来所要讲到的工具仅能支持最小调至24）。
|
||||
|
||||
### Unity Tweak Tool-强大! ###
|
||||
|
||||
在Unity首次伴随Ubuntu 11.10发布的几天之内这款工具就跟着出现了，只是你得大费周折去自己把它安装好而且在Unity升级时它可能会损坏。
|
||||
@ -25,21 +33,26 @@ Unity中所特有的一个特性是我们能够打开或者关闭的“粘性边
|
||||
安装好，启动后你将看到如下画面：
|
||||
|
||||
|
||||
正式的Unity Tweak Tool
|
||||
|
||||
这款工具集中大量的Unity桌面定制项目于一体。这些定制项大多能通过默认的Unity设置，命令行操作或者是编辑有时候很难寻找的配置文件来实现。
|
||||
正式的Unity Tweak Tool
|
||||
|
||||
这款工具它集大量Unity桌面定制项目于一体。这些定制项大多能通过默认的Unity设置，命令行操作或者是即使是编辑有时候也很难寻找到的配置文件来实现。
|
||||
|
||||
我们可以改变启动器栏，网页小程序和面板的行为，可以在Unity菜单中搜索等等。所有的都通过着一个工具来实现。花些时间去挖掘适合你的选项-Unity Tweak Tool-学习它，和它一起生活，爱上它（如果你使用Unity，这是起码的）
|
||||
|
||||
### 结尾的一些想法 ###
|
||||
|
||||
Ubuntu 14.04 LTS 越来越向成为Linux Desktop迈进，（Canonical，对不起，你还是Linux），Linux Desktop不仅可以作为非正式的Linux使用者（的确有这样的事）的选择，也适用于骨灰级linux专家。
|
||||
那现在相比较于不借助工具，公共程序或是进行在随后的更新中可能损坏的配置文件编辑的Unity桌面我们就拥有了更多的控制权，Unity桌面性能强劲可靠，又通过Unity Tweak Tool加入一些风味元素，使得它的外观也酷极了!!!请给我们你的想法或者点击链接发表你对Unity桌面的评论，我们将有兴趣知道你是如何使用Ubuntu 14.04 LTS 的。
|
||||
Ubuntu 14.04 LTS 越来越被人们视作Linux上的典型的Desktop，（对不起，Canonical，你还没有摆脱Linux身份），Linux Desktop不仅可以作为偶尔使用Linux的那些人（的确有这样的事）的选择，也适用于骨灰级linux专家。
|
||||
|
||||
比之前没有工具，功能可以定制，或是通过配置文件修改定制但是有可能被之后个更新所破坏，现在对于Unity桌面我们就拥有了更多的控制权。Unity桌面性能强劲可靠，又通过Unity Tweak Tool加入一些特色元素，使得它的外观也酷极了!!!
|
||||
|
||||
请给我们你的想法或者点击链接发表你对Unity桌面的评论，我们将有兴趣知道你是如何使用Ubuntu 14.04 LTS 的。
|
||||
|
||||
|
||||
----------
|
||||
|
||||
#### Terrence T. Cox ####
|
||||
|
||||
开发者，Linux倡导者，开源爱好者。 进入这个技术领域很久，被认为经验丰富，但从未感到厌倦。
|
||||
[Twitter][1]
|
||||
|
||||
@ -47,7 +60,7 @@ Ubuntu 14.04 LTS 越来越向成为Linux Desktop迈进，（Canonical，对不
|
||||
|
||||
via: https://linuxacademy.com/blog/linux/ubuntu-14-04-lts-customizing-unity/
|
||||
|
||||
译者：[Love-xuan](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
译者：[Love-xuan](https://github.com/Love-xuan) 校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,32 @@
|
||||
Git 2.0.2 Version Control System Now Available for Download
|
||||
================================================================================
|
||||
|
||||
|
||||
**Git 2.0.2, a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency, has been officially released.**
|
||||
|
||||
The new Git 2.0.x branch continues the trend of large releases, integrating a big number of changes and fixes. This latest update may be just a maintenance one, but it does feature some interesting modifications.
|
||||
|
||||
According to the developers, the documentation for the "git submodule sync" mentions that the subcommand can take the "--recursive" option, the mishandling of patterns in .gitignore that had trailing SPs quoted with backslashes has been corrected, and the Recent updates to "git repack" no longer duplicate objects that are in the packfiles marked with .keep flag by mistake.
|
||||
|
||||
Also, "git clone -b brefs/tags/bar" no longer thinks that git follows a single tag, even though it was a name of the branch, "%G" (nothing after G) is an invalid pretty format specifier and now the parser knows that it's garbage, the code used to avoid adding the same alternate object store twice has been fixed, and a couple of other fixes have been implemented.
|
||||
|
||||
For a complete list of changes, check out the [changelog][1].
|
||||
|
||||
Download Git 2.0.2:
|
||||
|
||||
- [tar.gz][1][sources] [4.70 MB]
|
||||
- [Debian/Ubuntu DEB ALL][2][ubuntu_deb] [0 KB]
|
||||
- [Red Hat/Fedora/Mandriva/openSUSE RPM noarch][3][rh_rpm] [0 KB]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://news.softpedia.com/news/Git-2-0-2-Version-Control-System-Now-Available-for-Download-451147.shtml
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:https://github.com/git/git/blob/master/Documentation/RelNotes/2.0.2.txt
|
||||
[2]:https://github.com/git/git/archive/v2.0.2.tar.gz
|
||||
[3]:http://git-scm.com/download/linux
|
||||
[4]:http://git-scm.com/download/linux
|
||||
@ -0,0 +1,46 @@
|
||||
OpenMorrowind 0.31.0 RPG Remake Is Already Looking Great
|
||||
================================================================================
|
||||
|
||||
|
||||
**OpenMW, an open source implementation of The Elder Scrolls 3: Morrowind game engine and functionality, is now at version 0.31.0 and packs lots of new features.**
|
||||
|
||||
OpenMW, or OpenMorrowind, is a project that aims to bring one of best role-playing games ever created into the open source world, but not by simple porting. The makers of this title have been working non-stop in the last months and it seems that the game is really starting to take shape.
|
||||
|
||||
Half a year ago, players couldn't do much in OpenMW, but now a lot of features have been integrated, and it's almost playable if you don't expect too much. Even with all the changes in place, the version number indicates that the development is moving rather slowly and numerous problems still remain. It will take a long time until the game reaches a stable version, but when it gets there, it's going to be an awesome RPG.
|
||||
|
||||
“The OpenMW team is proud to announce the release of version 0.31.0! This release includes implementation of many smaller features that have been sorely missing, as well fixes for a ridiculous amount of bugs. Many thanks to our developers for their relentless attention to detail. Some optimization has made it into this release, let us know if you see any increased performance,” reads the announcement on the official website.
|
||||
|
||||
A number of important changes have been made and lots of new stuff has been added. For example, a periodic cleanup/refill has been added, precipitation and weather particles are now ready in the engine, the dialog has been merged, saving missing creature state is now working properly, the murder crime has been implemented, a number of sneak skill enhancements have been added, and animated main menu support has been implemented.
|
||||
|
||||
Also, the clouds and weather have been modified to better match vanilla Morrowind, the background tracks are no longer repeating, the dead body collision behavior has been improved, and lots of other fixes have been implemented.
|
||||
|
||||
A complete list of changes and new features can be found in the official [announcement][1]. Users must legally own and install the game before they can use OpenMW – as it is intended – to play Morrowind.
|
||||
|
||||
Download OpenMW 0.31.0:
|
||||
|
||||
- [tar.gz][2][sources] [3.20 MB]
|
||||
- [tar.gz (64-bit)][3][binary] [33.40 MB]
|
||||
- [tar.gz (32-bit)][4][binary] [33.10 MB]
|
||||
- [Ubuntu PPA Repository][5][ubuntu_deb] [0 KB]
|
||||
- [Arch Linux Package][6][binary] [0 KB]
|
||||
- [Debian PPA Repository][7][debian_deb] [0 KB]
|
||||
|
||||
OpenMW aims to be a full-featured reimplementation of the Morrowind engine capable to work natively on all supported platforms and to support all existing content, including Tribunal, Bloodmoon, and all user-created mods.
|
||||
|
||||
Keep in mind that this is not a stable version and bugs might still appear.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://news.softpedia.com/news/OpenMorrowind-0-31-0-RPG-Remake-Is-Already-Looking-Great-451120.shtml
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:https://openmw.org/2014/openmw-0-31-0/
|
||||
[2]:https://github.com/OpenMW/openmw/archive/openmw-0.31.0.tar.gz
|
||||
[3]:https://github.com/OpenMW/openmw/releases/download/openmw-0.31.0/openmw-0.31.0-Linux-64Bit.tar.gz
|
||||
[4]:https://github.com/OpenMW/openmw/releases/download/openmw-0.31.0/openmw-0.31.0-Linux.tar.gz
|
||||
[5]:https://launchpad.net/~openmw/+archive/openmw
|
||||
[6]:https://aur.archlinux.org/packages/?O=0&K=openmw
|
||||
[7]:http://forum.openmw.org/viewtopic.php?f=20&t=1298
|
||||
@ -0,0 +1,37 @@
|
||||
Time to Upgrade: Ubuntu 13.10 Support Ends Today
|
||||
================================================================================
|
||||
|
||||
|
||||
**It’s had a fair old run, but after 9 months basking in the sun today marks the end of official support for Ubuntu 13.10 ‘Saucy Salamander’.**
|
||||
|
||||
> Despite the name ‘Saucy’, the changes on offer were rather bland
|
||||
|
||||
Those still running it should look at upgrading to the most recent stable release, Ubuntu 14.04 LTS. Launched back in April, it will be supported with updates on the desktop all the way until mid-April 2019.
|
||||
|
||||
Support for the server version of Ubuntu 13.10 also formally ends today.
|
||||
|
||||
### Saucy Loses Flavour ###
|
||||
|
||||
Ubuntu 13.10 came out last October with Canonical pledging to provide a full 9 months of ongoing security and bug fixes on the desktop. As of July 17 these updates will cease and no further updates or backported packages will be provided.
|
||||
|
||||
Canonical’s [recommended upgrade path][1] is to 14.04, a transition that can be handled directly on the desktop itself through the Software Updater application or via the command line through the ‘`do-release-upgrade`‘ command.
|
||||
|
||||
Saucy in name, but bland in nature, 13.10 is far from being one of Ubuntu’s more remarkable releases — [as evidenced by many of the online reviews at the time][2].
|
||||
|
||||
It was, however, notable for inflicting(注：这个单词原文有删除线) introducing Smart Scopes to the Unity Dash, adding a keyboard indicator for faster language layout switching, and being the first release to integrate `Ubuntu One Single Sign-on` into the installation experience.
|
||||
|
||||
For a natty visual rundown of all that debuted with it you can watch the compilation video below.
|
||||
|
||||
Youtobe 视频地址：[http://www.youtube.com/embed/1EiRQ-znEcI?feature=oembed][3]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.omgubuntu.co.uk/2014/07/ubuntu-13-10-support-ends-today
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:https://help.ubuntu.com/community/TrustyUpgrades
|
||||
[2]:http://www.omgubuntu.co.uk/2013/10/ubuntu-13-10-press-reaction
|
||||
[3]:http://www.youtube.com/embed/1EiRQ-znEcI?feature=oembed
|
||||
@ -1,59 +0,0 @@
|
||||
zpl1025
|
||||
Joy of Programming: Fail Fast!
|
||||
================================================================================
|
||||
|
||||
|
||||
> When a problem occurs in the software, it should fail immediately, in an easily noticeable way. This “fail fast” behaviour is desirable, and we’ll discuss this important concept in this column.
|
||||
|
||||
At first, a “fail fast” might appear to be a bad practice affecting reliability — why should a system crash (or fail), when it can continue execution? For this, we need to understand that fail fast is very relevant in the context of Heisenbugs.
|
||||
|
||||
Consider Bohrbugs, which always crash for a given input, for example, with a null-pointer access. These bugs are easier to test, reproduce and fix. Now, all experienced programmers would have faced situations where the bug that caused the crash just disappears when the software is restarted. No matter how much time and effort is spent to reproduce the problem, the bug eludes us. These bugs are known as Heisenbugs.
|
||||
|
||||
The effort required to find, fix and test Heisenbugs is an order of magnitude more than the effort required for Bohrbugs. One strategy to avoid Heisenbugs is to turn them into Bohrbugs. How? By anticipating the possible cases in which Heisenbugs can arise, and trying to make them Bohrbugs. Yes, it is not easy, and it is also not always possible, but let us look at a specific example where it is useful.
|
||||
|
||||
Concurrent programming is one paradigm where Heisenbugs are common. Our example is a concurrency-related issue in Java. While iterating over a Java collection, we are supposed to modify the collection only through the Iterator methods, such as the remove() method. During iteration, if another thread attempts to modify that underlying collection (because of a programming mistake), the underlying collection will get corrupted (i.e., result in an incorrect state).
|
||||
|
||||
Such an incorrect state can lead to an eventual failure — or if we are fortunate (actually, unfortunate!), the program continues execution without crashing, but gives the wrong results. It is difficult to reproduce and fix these bugs, because such programming mistakes are non-deterministic. In other words, it is a Heisenbug.
|
||||
|
||||
Fortunately, the Java Iterators try to detect such concurrent modifications, and if found, will throw a `ConcurrentModificationException`, instead of failing late — and that too, silently. In other words, the Java Iterators follow the “fail fast” approach.
|
||||
|
||||
What if a `ConcurrentModificationException` is observed in production software? As the Javadoc for this exception observes, it “
should be used only to detect bugs.” In other words, `ConcurrentModificationExceptions` are supposed to be found and fixed during software development, and should not leak to production code.
|
||||
|
||||
Well, if production software does get this exception, it is certainly a bug in the software, and should be reported to the developer and fixed. At least, we know that there was an attempt for concurrent modification of the underlying data structure, and that’s why the software failed (instead of getting wrong results from the software, or failing later with some other symptoms, for which it is not feasible to trace the root cause).
|
||||
|
||||
The “fail-safe” approach is meant for developing robust code. A very good example of writing fail-safe code is using assertions. Unfortunately, there is a lot of unnecessary controversy surrounding the use of asserts. The main criticism is this: the checks are enabled in the development version, and disabled in release versions.
|
||||
|
||||
However, this criticism is wrong: asserts are never meant to replace the defensive checks that should be put in place in the release version of the software. For example, asserts should not be used to check if the argument passed to a function is null or not. Instead, an if condition should be used to check if the argument is passed correctly, or else an exception, or a premature return, should be performed, as appropriate to the context. However, asserts can be used to do additional checks for assumptions that are made in the code, which are supposed to hold true. For example, a condition that checks that the stack is not empty after a push operation is performed on it (i.e., checking for “invariants”).
|
||||
|
||||
So, fail fast, be assertive, and you’re on the way to developing more robust code.
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via:http://www.opensourceforu.com/2011/12/joy-of-programming-fail-fast/
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:
|
||||
[2]:
|
||||
[3]:
|
||||
[4]:
|
||||
[5]:
|
||||
[6]:
|
||||
[7]:
|
||||
[8]:
|
||||
[9]:
|
||||
[10]:
|
||||
[11]:
|
||||
[12]:
|
||||
[13]:
|
||||
[14]:
|
||||
[15]:
|
||||
[16]:
|
||||
[17]:
|
||||
[18]:
|
||||
[19]:
|
||||
[20]:
|
||||
@ -1,92 +0,0 @@
|
||||
nd0104 is translate
|
||||
How to check RPM package dependencies on Fedora, CentOS or RHEL
|
||||
================================================================================
|
||||
A typical RPM package on Red Hat-based systems requires all its dependent packages be installed to function properly. For end users, the complexity of such RPM dependency is hidden by package managers (e.g., yum or DNF) during package install/upgrade/removal process. However, if you are a sysadmin or a RPM maintainer, you need to be well-versed in RPM dependencies to maintain run-time environment for the system or roll out up-to-date RPM specs.
|
||||
|
||||
In this tutorial, I am going to show **how to check RPM package dependencies**. Depending on whether a package is installed or not, there are several ways to identify its RPM dependencies.
|
||||
|
||||
### Method One ###
|
||||
|
||||
One way to find out RPM dependencies for a particular package is to use rpm command. The following command lists all dependent packages for a target package.
|
||||
|
||||
$ rpm -qR <package-name>
|
||||
|
||||
|
||||
|
||||
Note that this command will work only if the target package is already **installed**. If you want to check package dependencies for any **uninstalled** package, you first need to download the RPM package locally (no need to install it).
|
||||
|
||||
To download a RPM package without installing it, use a command-line utility called `yumdownloader`. Install yumdownloader as follows.
|
||||
|
||||
$ sudo yum install yum-utils
|
||||
|
||||
Now let's check RPM depenencies of a uninstalled package (e.g., tcpdump). First download the package in the current folder with yumdownloader:
|
||||
|
||||
$ yumdownloader --destdir=. tcpdump
|
||||
|
||||
Then use rpm command with "-qpR" options to list dependencies of the downloaded package.
|
||||
|
||||
# rpm -qpR tcpdump-4.4.0-2.fc19.i686.rpm
|
||||
|
||||
### Method Two ###
|
||||
|
||||
You can also get a list of dependencies for a RPM package using repoquery tool. repoquery works whether or not a target package is installed. This tool is included in yum-utils package.
|
||||
|
||||
$ sudo yum install yum-utils
|
||||
|
||||
To show all required packages for a particular package:
|
||||
|
||||
$ repoquery --requires --resolve <package-name>
|
||||
|
||||
|
||||
|
||||
For repoquery to work, your computer needs network connectivity since repoquery pulls information from Yum repositories.
|
||||
|
||||
### Method Three ###
|
||||
|
||||
The third method to show RPM package dependencies is to use rpmreaper tool. Originally this tool is developed to clean up unnecessary packages and their dependencies on RPM-based systems. rpmreaper has an ncurses-based intuitive interface for browsing installed packages and their dependency trees.
|
||||
|
||||
To install rpmrepater, use yum command. On CentOS, you need to [set up EPEL repo][1] first.
|
||||
|
||||
$ sudo yum install rpmreaper
|
||||
|
||||
To browser RPM dependency trees, simply run:
|
||||
|
||||
$ rpmreaper
|
||||
|
||||
|
||||
|
||||
The rpmrepater interface will show you a list of all installed packages. You can navigate the list using up/down arrow keys. Press "r" on a highlighted package to show its dependencies. You can expand the whole dependency tree by recursively pressing "r" keys on individual dependent packages. The "L" flag indicates that a given package is a "leaf", meaning that no other package depends on this package. The "o" flag implies that a given package is in the middle of dependency chain. Pressing "b" on such a package will show you what other packages require the highlighted package.
|
||||
|
||||
### Method Four ###
|
||||
|
||||
Another way to show package dependencies on RPM-based systems is to use rpmdep which is a command-line tool for generating a full package dependency graph of any installed RPM package. The tool analyzes RPM dependencies, and produce partially ordered package lists from topological sorting. The output of this tool can be fed into dotty graph visualization tool to generate a dependency graph image.
|
||||
|
||||
To install rpmdep and dotty on Fedora:
|
||||
|
||||
$ sudo yum install rpmorphan graphviz
|
||||
|
||||
To install the same tools on CentOS:
|
||||
|
||||
$ wget http://downloads.sourceforge.net/project/rpmorphan/rpmorphan/1.14/rpmorphan-1.14-1.noarch.rpm
|
||||
$ sudo rpm -ivh rpmorphan-1.14-1.noarch.rpm
|
||||
$ sudo yum install graphviz
|
||||
|
||||
To generate and plot a dependency graph of a particular installed package (e.g., gzip):
|
||||
|
||||
$ rpmdep.pl -dot gzip.dot gzip
|
||||
$ dot -Tpng -o output.png gzip.dot
|
||||
|
||||
|
||||
|
||||
So far in this tutorial, I demonstrate several ways to check what other packages a given RPM package relies on. If you want to know more about .deb package dependencies for Debian-based systems, you can refer to [this guide][2] instead.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://xmodulo.com/2014/07/check-rpm-package-dependencies-fedora-centos-rhel.html
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://xmodulo.com/2013/03/how-to-set-up-epel-repository-on-centos.html
|
||||
[2]:http://xmodulo.com/2013/07/how-to-check-package-dependencies-on-ubuntu-or-debian.html
|
||||
@ -1,184 +0,0 @@
|
||||
Vic020
|
||||
|
||||
Install “Android 4.4 KitKat” to Run Favourite Games and Applications in Linux
|
||||
================================================================================
|
||||
**Android (x86)** is a project which aims to port Android system to Intel x86 processors to let users install it easily on any computer, the way they do this is by taking android source code, patching it to work on Intel x86 processors and some laptops and tablets.
|
||||
|
||||
|
||||
Install Android 4.4 KitKat in Linux
|
||||
|
||||
A few days ago, the project released “Android KitKat 4.4 RC2”, and today we will explain how to install it on VirtualBox, there is a problem that the mouse pointer doesn’t work in android in VirtualBox, but you may use this guide to install it beside other systems as a main system and the mouse should work I guess, otherwise we’ll use the keyboard.
|
||||
|
||||
### Step 1: Install VirtualBox in Linux ###
|
||||
|
||||
**1.** VirtualBox is available to install easily via official repositories in most Linux distributions, to install it on Ubuntu run.
|
||||
|
||||
$ sudo apt-get install virtualbox
|
||||
|
||||
For other Linux distributions like **RHEL, CentOS and Fedora**, use the following article to install Virtualbox.
|
||||
|
||||
- [Install VirtualBox in RHEL, CentOS and Fedora][1]
|
||||
|
||||
### Step 2: Download and Install Android 4.4 KitKat in Virtualbox ###
|
||||
|
||||
**2.** This is an easy step, just download **Android 4.4 x86 Kit Kat** file from the [androud Sourceforge.net][2] project.
|
||||
|
||||
**3.** To install **Android 4.4 kitkat** on VirtualBox, you need first to boot from the .iso image that you downloaded, to do so, open **VirtualBox**, Click on new to create a new virtual machine, and choose the settings as follow.
|
||||
|
||||
|
||||
Create New Virtual Machine
|
||||
|
||||
**4.** Then it will ask you to choose a Memory size for the machine, Android 4.4 kitkat needs 1GB of RAM to work perfectly, but I will choose 512MB since I only have 1GB of RAM on my computer.
|
||||
|
||||
|
||||
Set Memory to New Machine
|
||||
|
||||
**5.** Now select “Create a virtual hard drive now” to create a new one.
|
||||
|
||||
|
||||
Create Virtual Hard Drive
|
||||
|
||||
**6.** It will now ask you for the type of the new virtual hard drive, select **VDI**.
|
||||
|
||||
|
||||
Select Hard Drive Type
|
||||
|
||||
|
||||
Select Storage Type
|
||||
|
||||
**7.** Now choose the size of the virtual hard drive, you may choose any size you want, no less than **4GB** so the system can be installed correctly beside any future apps that you want to install.
|
||||
|
||||
|
||||
Set Size for Virtual Drive
|
||||
|
||||
**8.** Now that’s your first virtual machine is created, now to boot from the **.iso** file that you downloaded, select the virtual machine from the list on the left, click on **Settings**, and go for “**storage**”, do as follow and select the **.iso** image of **android 4.4 kitkat RC2**.
|
||||
|
||||
|
||||
Select Android KitKat ISO
|
||||
|
||||
**9.** Click on **OK**, and start the machine to boot the .iso image, choose “**Installation**” to start installing the system on the virtual machine.
|
||||
|
||||
|
||||
Select to Install Android Kit Kat
|
||||
|
||||
**10.** Please select a partition to install Android-x86.
|
||||
|
||||
|
||||
Select Partition Drive
|
||||
|
||||
**11.** Now you will be prompted **cfdisk** which is a partitioning tool that we will use to create a new hard drive, so we can install android 4.4 on it, Click on “**New**”.
|
||||
|
||||
|
||||
Create New Partition
|
||||
|
||||
**12.** Choose “**Primary**” as partition type.
|
||||
|
||||
|
||||
Choose Primary Partition
|
||||
|
||||
**13.** Next, select the size of the partition.
|
||||
|
||||
|
||||
Select Size of Partition
|
||||
|
||||
**14.** Now, we have to make the new hard drive bootable in order to be able to write changes to the disk, click on “**Bootable**” to give the bootable flag to the new partition, you won’t notice any changes in fact but the bootable flag will be given to that partition.
|
||||
|
||||
|
||||
Make Partition Bootable
|
||||
|
||||
**15.** After that, click on “**Write**” to write the changes to the hard drive.
|
||||
|
||||
|
||||
Apply Changes to Partition
|
||||
|
||||
**16.** It will ask you if you are sure, write “**yes**” and click on **Enter**.
|
||||
|
||||
|
||||
Confirm Partition Changes
|
||||
|
||||
**17.** Now that’s our new hard drive is created, now click on **Quit** and you will see something like this, select the partition that you created before in order to install android on it and hit **Enter**.
|
||||
|
||||
|
||||
Choose Partition to Install Android
|
||||
|
||||
**18.** Choose “**ext3**” as a filesystem for the hard drive and format.
|
||||
|
||||
|
||||
Select Ext3 Partition Type
|
||||
|
||||
|
||||
Format Partition
|
||||
|
||||
**19.** You will be asked now if you want to install GRUB bootloader, of course you will select **Yes**, because if you don’t, you won’t be able to boot the new system, so choose “**Yes**” and hit **Enter**.
|
||||
|
||||
|
||||
Install Boot Loader GRUB
|
||||
|
||||
**20.** Finally, you will be asked if you want to make the **/system** partition writeable, choose Yes, it will help in a lot of things later after you install the system.
|
||||
|
||||
|
||||
Make Partition Writeable
|
||||
|
||||
**21.** The installer will start it’s mission… after the installer finishes the job, choose Reboot, in my test, the “Run-Android x86” didn’t work for me, so you have to reboot.
|
||||
|
||||
|
||||
Android Kit Kat Installation
|
||||
|
||||
**22.** Now that’s we installed **Android 4.4 KitKat RC2** on our hard drive, the problem is now that VirtualBox will keep loading the **.iso** image file instead of booting from the virtual hard drive, so to fix this problem, go to **Settings**, under “**storage**” select the **.iso** file and remove it from the booting menu.
|
||||
|
||||
|
||||
Remove Android Kit Kat Image
|
||||
|
||||
**23.** Now you can start the virtual machine with the installed android system.
|
||||
|
||||
|
||||
Start Android Kit Kat System
|
||||
|
||||
|
||||
Android Splash Screen
|
||||
|
||||
**24.** Now you will start a wizard to configure some things before you start using **Android**. You will see a screen like this, Now the problem is, that the Mouse doesn’t work in **android 4.4 KitKat**, that means that we’ll be using our skills in keyboard, first choose the **language** you want using the **Up** and **Down** keys in the keyboard, and to go the next step, hit the **Right** arrow key and click **Enter**.
|
||||
|
||||
|
||||
Android Welcome Screen
|
||||
|
||||
|
||||
Select WiFi Network
|
||||
|
||||
|
||||
Create Android Google Account
|
||||
|
||||
|
||||
Sign in Google Account
|
||||
|
||||
|
||||
Set Date and Time
|
||||
|
||||
|
||||
Enter Your Details
|
||||
|
||||
|
||||
Android 4.4 Kit Kat Home Screen
|
||||
|
||||
Installing **Android x86** will be good for you if you don’t have a smartphone and you want to use the **Play Store** apps easily, have you ever tried to install android x86? What was the results? Do you think that android may become a “**real operation system**” targeting PCs in the feature?
|
||||
|
||||
----------
|
||||
|
||||
|
||||
|
||||
[Hanny Helal][3]
|
||||
|
||||
A Linux & Foss user since 2010, working on many projects in the field of Free Software.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/install-android-kitkat-in-linux/
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://www.tecmint.com/install-virtualbox-on-redhat-centos-fedora/
|
||||
[2]:http://sourceforge.net/projects/android-x86/
|
||||
[3]:http://www.tecmint.com/
|
||||
@ -0,0 +1,55 @@
|
||||
Display Song Lyrics On Desktop In Ubuntu 14.04
|
||||
================================================================================
|
||||
|
||||
|
||||
Apart from free streaming music, what I like the most in [Spotify][1] is its lyrics plugin. At times I don’t understand all of the words of the song, specially if it’s rap. [TuneWiki][2] plugin comes handy in this case. While TuneWiki has plugins for Windows Media Player and iTune, what options do we have on desktop Linux?
|
||||
|
||||
If you have been using desktop Linux for sometime, you might have heard of [OSD Lyrics][3]. It is a small application that **displays song lyrics on the desktop**. You can use it with several audio players such as Rythmbox, [Banshee][4], [Clementine][5] etc.
|
||||
|
||||
### Install OSD Lyrics in Ubuntu 14.04 and Linux Mint 17 ###
|
||||
|
||||
OSD Lyrics was actively maintained through its official PPA about 2 years back. There is no development anymore. While the PPA is no longer usable, the executables (.deb) can be downloaded from the website. Though these executables are originally for Ubuntu 12.04 Precise Pangolin, these files work very well in Ubuntu 14.04 also. Let’s see **how to install OSD Lyrics in Ubuntu 14.04 and Linux Mint 17**.
|
||||
|
||||
Go to the [download page of OSD Lyrics][6]. Get the .deb files depending upon [whether you are using 32 bit or 64 bit Ubuntu][7]. You will find the files on the top.
|
||||
|
||||
|
||||
|
||||
Once downloaded, just double click on it to install it via Ubuntu Software Center. Alternatively, you can [use Gdebi to quickly install .deb packages][8].
|
||||
|
||||
### How to display lyrics in Ubuntu and Linux Mint using OSD Lyrics ###
|
||||
|
||||
Once installed, you can run OSD Lyrics from the Unity Dash:
|
||||
|
||||
|
||||
|
||||
On the first run, it will detect the existing players which are compatible with OSD Lyrics. You can set a default player which will be opened automatically each time you start OSD Lyrics.
|
||||
|
||||
|
||||
|
||||
One thing to note is that unlike [Shazam][9] etc, OSD Lyrics doesn’t find the lyrics from the audio, rather it uses the information linked to the music files such as name, album, artist etc. So make sure that you have music files from “respectable sources” or keep the file information correct and updated.
|
||||
|
||||
If it recognizes the music files, it will display the lyrics on the desktop in Karaoke format:
|
||||
|
||||
|
||||
|
||||
There are plenty of configuration options available with OSD Lyrics. You can change the font, size behavior of the lyrics display among many other things.
|
||||
|
||||
How do you like OSD Lyrics? Do you use some other Lyrics plugin? Do share your views with rest of us.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://itsfoss.com/display-song-lyrics-desktop-ubuntu-1404/
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://itsfoss.com/install-spotify-ubuntu-1404/
|
||||
[2]:http://www.tunewiki.com/
|
||||
[3]:https://code.google.com/p/osd-lyrics
|
||||
[4]:http://banshee.fm/
|
||||
[5]:https://www.clementine-player.org/
|
||||
[6]:https://code.google.com/p/osd-lyrics/downloads/list
|
||||
[7]:http://itsfoss.com/how-to-know-ubuntu-unity-version/
|
||||
[8]:http://itsfoss.com/install-deb-files-easily-and-quickly-in-ubuntu-12-10-quick-tip/
|
||||
[9]:http://www.shazam.com/
|
||||
@ -0,0 +1,76 @@
|
||||
Linux Kernel Testing and Debugging
|
||||
================================================================================
|
||||
### Linux Kernel Testing Philosophy ###
|
||||
|
||||
Testing is an integral and important part of any software development cycle, open or closed, and Linux kernel is no exception to that. Developer testing, integration testing, regression, and stress testing have different individual goals, however from 1000 feet up, the end goal is the same, to ensure the software continues to work as it did before adding a new body of code, and the new features work as designed.
|
||||
|
||||
Ensuring software is stable without regressions before the release, helps avoid debugging and fixing customer and user found bugs after the release. It costs more in time and effort to debug and fix a customer found problem. Hence, testing is very important in the case of any software, not just the Linux kernel. Unlike closed and proprietary operating systems, the development process is open and is not locked down. This process is its strength as well as weakness. With several developers continuing to add new features, and fixing bugs, continuous integration and testing is vital to ensure the kernel continues to work on existing hardware as new hardware support and features get added. In the open source development, developers and users share the testing responsibility. This is another important difference between a closed development model and an open one.
|
||||
|
||||
Almost all Linux kernel developers, if not all, are very active Linux users themselves. There is no requirement that testers should be developers, however, users and developers that are not familiar with the new code could be more effective at testing a new piece of code than the original author of that code. In other words, developer testing serves as an important step in verifying the functionality, however, developer testing alone is not sufficient to find interactions with other code, features, and unintended regressions on configurations and/or hardware, developer didn't anticipate and didn't have the opportunity and resources to test. Hence, users play a very important role in the Linux Kernel development process.
|
||||
|
||||
So now that we understand the importance of continuous integration testing, we will go into the details of testing itself. Before we talk about testing, I would like to walk through the development process itself to help understand how it works and how the changes funnel into the mainline kernel.
|
||||
|
||||
3000+ kernel developers from around the world contribute to the Linux kernel. It is a 24hours, seven days a week, and 365 days of continuous development process that results in a new release once every 2+ months and several stable and extended stable releases. New development and current release integration cycles run in parallel.
|
||||
|
||||
For further reading on the development process, please refer to [Greg Kroah-Hartman's presentation on the Linux Kernel Development][1].
|
||||
|
||||
It is my intent that this guide should be useful to a beginner as well as an experienced contributor and/or individuals interested in getting involved in the Linux kernel development. Experienced developers can chose to skip sections that go over basic testing and debugging.
|
||||
|
||||
This paper will discuss how to test and debug Linux kernel, tools, scripts and debug mechanisms that aid in regression and integration testing. In addition, this paper will go into details on how to use git bisect to isolate a patch that introduced a bug, and what to test before sending patches to the Linux Kernel Mailing List. I will use Linux PM as an example target area for the testing and debugging discussion. Even though this paper is Linux Kernel testing focused, the importance of testing is applicable to any software project.
|
||||
|
||||
### Configuring Development and Test System ###
|
||||
|
||||
Let's get started. First order of business is finding a development system that suits your needs. x86-64 systems are a good choice for a basic development system, unless there is a need for a specific architecture and/or configuration.
|
||||
|
||||
The second step is to install distribution of your preference. I prefer Ubuntu, hence this document will have the details on how to configure a kernel development system running Ubuntu distribution. Please follow [How to Ubuntu][2] for installing the Ubuntu release of your choice.
|
||||
|
||||
On development and test systems, it is a good idea to ensure there is ample space for kernels in the boot partition. Choosing whole disk install or setting aside 3 GB disk space for the boot partition is recommended.
|
||||
|
||||
Once the distribution is installed and the system is ready for development packages, enable root account and also enable sudo for your user account. The system might already have the build-essential package which is what you need to build Linux kernels on an x86_64 system. If build-essential is not already installed, run the following command to install it:
|
||||
|
||||
sudo apt-get install build-essential
|
||||
|
||||
At this point, you may install the following packages as well, so the system is ready for cross-compiling Linux kernels. Note that ncurses-dev is a required package to run make menuconfig.
|
||||
|
||||
sudo apt-get install binutils-multiarch
|
||||
|
||||
sudo apt-get install ncurses-dev
|
||||
|
||||
sudo apt-get install alien
|
||||
|
||||
Now let's install a few tools every Linux kernel developer need in his/her tool chest.
|
||||
|
||||
sudo apt-get install git
|
||||
|
||||
sudo apt-get install cscope
|
||||
|
||||
sudo apt-get install meld
|
||||
|
||||
sudo apt-get install gitk
|
||||
|
||||
If you would like to get the system configured for cross-compiling other supported architectures non-natively on your x86-64 system, please follow: [Cross-compiling Linux kernel on x86 64][3].
|
||||
|
||||
The Stable Kernel
|
||||
|
||||
Start by cloning the stable kernel git, building and installing the latest stable kernel. You can find information on the latest stable and mainline releases at [The Linux Kernel Archive][4].
|
||||
|
||||
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
|
||||
|
||||
The above step will create a new directory named linux-stable and populate it with the sources.
|
||||
|
||||
You can also download just the Linux Kernel source tar-ball instead of cloning the git, and then unpack the tar-ball.
|
||||
|
||||
tar xvf linux-3.x.y.tar.xz
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,0
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://events.linuxfoundation.org/images/stories/pdf/als2012_gregkh.pdf
|
||||
[2]:http://howtoubuntu.org/
|
||||
[3]:http://linuxdriverproject.org/mediawiki/index.php/Cross-compiling_Linux_kernel_on_x86_64
|
||||
[4]:https://www.kernel.org/
|
||||
107
sources/tech/20140718 Linux Kernel Testing and Debugging 2.md
Normal file
107
sources/tech/20140718 Linux Kernel Testing and Debugging 2.md
Normal file
@ -0,0 +1,107 @@
|
||||
Linux Kernel Testing and Debugging
|
||||
================================================================================
|
||||
### Compiling and Installing Stable Kernel ###
|
||||
|
||||
If you cloned the stable git:
|
||||
|
||||
cd linux-stable
|
||||
|
||||
git checkout linux-3.x.y
|
||||
|
||||
or if you are using the tar-ball:
|
||||
|
||||
cd linux-3.x.y
|
||||
|
||||
Starting out with the distribution configuration file is the safest approach for the very first kernel install on any system. You can do so by copying the configuration for your current kernel from /boot.
|
||||
|
||||
cp /boot/config-3.x.y-z-generic .config
|
||||
|
||||
Run the following command to generate kernel configuration file based on the current configuration. You will be prompted to tune the configuration to enable new features and drivers that have been added since the Ubuntu snapshot the kernel from the mainline.
|
||||
|
||||
make oldconfig
|
||||
|
||||
Once this step is complete, it is time to compile the kernel:
|
||||
|
||||
make all
|
||||
|
||||
Once the kernel compilation is complete, install the new kernel:
|
||||
|
||||
sudo "make modules_install install"
|
||||
|
||||
The above command will install the new kernel and run update-grub to add the new kernel to the grub menu. Now it is time to reboot the system to boot the newly installed kernel. Before we do that, let's save logs from the current kernel to compare and look for regressions and new errors, if any:
|
||||
|
||||
dmesg -t > dmesg_current
|
||||
|
||||
dmesg -t -k > dmesg_kernel
|
||||
|
||||
dmesg -t -l emerg > dmesg_current_emerg
|
||||
|
||||
dmesg -t -l alert > dmesg_current_alert
|
||||
|
||||
dmesg -t -l crit > dmesg_current_alert
|
||||
|
||||
dmesg -t -l err > dmesg_current_err
|
||||
|
||||
dmesg -t -l warn > dmesg_current_warn
|
||||
|
||||
In general, dmesg should be clean with no emerg, alert, crit, and err level messages. If you see any of these, it might indicate some hardware and/or kernel problem.
|
||||
|
||||
A couple more important steps before trying out the newly installed kernel. There is no guarantee that the new kernel will boot. As a safe guard, please ensure that there is at least one good kernel installed. Change the default grub configuration file /etc/default/grub:
|
||||
|
||||
Enable printing early boot messages to vga using earlyprink=vga kernel boot option:
|
||||
|
||||
GRUB_CMDLINE_LINUX="earlyprink=vga"
|
||||
|
||||
Increase the GRUB_TIMEOUT value to 10 - 15 seconds, so grub pauses in menu allowing time to choose kernel to be boot:
|
||||
|
||||
Uncomment GRUB_TIMEOUT and set it to 10: GRUB_TIMEOUT=10
|
||||
Comment out GRUB_HIDDEN_TIMEOUT and GRUB_HIDDEN_TIMEOUT_QUIET
|
||||
|
||||
Run update-grub to update the grun configuration in /boot
|
||||
|
||||
sudo update-grub
|
||||
|
||||
Now restart the system. Once the new kernel comes up, compare the saved dmesg from the old kernel with the new one and see if there are any regressions. If the newly installed kernel fails to boot, you will have to boot a good kernel and then investigate why the new kernel failed to boot.
|
||||
|
||||
### Living in The Fast Lane ###
|
||||
|
||||
If you like driving in the fast lane and have the need for speed, clone the mainline kernel git or better yet the linux-next git. Booting and testing mainline and linux-next helps find and fix problems before the kernel is released.
|
||||
|
||||
Mainline:
|
||||
|
||||
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
|
||||
|
||||
linux-next:
|
||||
|
||||
git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
|
||||
|
||||
Compiling and installing mainline and linux-next kernels is exactly same as the stable kernel. Please follow the instructions from previous sections.
|
||||
|
||||
### Applying Patches ###
|
||||
|
||||
Linux kernel patch files are text files that contain the differences from the original source to the new. Each Linux patch is a self-contained change to the code that stands on its own, unless explicitly made part of a patch series. New patches are applied as follows:
|
||||
|
||||
patch -p1 < file.patch
|
||||
|
||||
git apply --index file.patch
|
||||
|
||||
Either one will work, however, when a patch adds a new file and if it is applied using the patch command, git doesn't know about the new files and they will be treated as untracked files. "git diff" will not show the files in its output and "git status" will show the files as untracked.
|
||||
|
||||
For the most part, there are no issues with building and installing kernels, however, "git reset --hard" will not remove the newly added files and a subsequent git pull will fail. A couple of ways to tell git about the new files and have it track them, there by avoiding the above issues:
|
||||
|
||||
|
||||
Option 1:
|
||||
|
||||
> When a patch that adds new files is applied using the patch command, run "git clean" to remove untracked files, before running "git reset --hard". For example, git clean -dfx will force remove untracked directories and files, ignoring any standard ignore rules specified in the .gitignore file. You could include -q option to run git clean in quiet mode, if you don't care to know which files are removed.
|
||||
|
||||
Option 2:
|
||||
|
||||
> An alternate approach is to tell git to track the newly added files by running "git apply --index file.patch". This will result in git applying the patch and adding the result to the index. Once this is done, git diff will show the newly added files in its output and git status will report the status correctly tagging these files as newly created files.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,1
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
125
sources/tech/20140718 Linux Kernel Testing and Debugging 3.md
Normal file
125
sources/tech/20140718 Linux Kernel Testing and Debugging 3.md
Normal file
@ -0,0 +1,125 @@
|
||||
Linux Kernel Testing and Debugging
|
||||
================================================================================
|
||||
### Basic Testing ###
|
||||
|
||||
Once a new kernel is installed, the next step is try to boot it and see what happens. Once the new kernel is up and running, check dmesg for any regressions. Run a few usage tests:
|
||||
|
||||
- Is networking (wifi or wired) functional?
|
||||
- Does ssh work?
|
||||
- Run rsync of a large file over ssh
|
||||
- Run git clone and git pull
|
||||
- Start web browser
|
||||
- Read email
|
||||
- Download files: ftp, wget etc.
|
||||
- Play audio/video files
|
||||
- Connect new USB devices mouse, usb stick etc.
|
||||
|
||||
|
||||
### Examine Kernel Logs ###
|
||||
|
||||
Checking for regressions in dmesg is a good way to identify problems, if any, introduced by the new code. As a general rule, there should be no new crit, alert, and emerg level messages in dmesg. There should be no new err level messages. Pay close attention to any new warn level messages as well. lease note that new warn messages aren't as bad. New code at times adds new warning messages which are just warnings.
|
||||
|
||||
- dmesg -t -l emerg
|
||||
- dmesg -t -l crit
|
||||
- dmesg -t -l alert
|
||||
- dmesg -t -l err
|
||||
- dmesg -t -l warn
|
||||
- dmesg -t -k
|
||||
- dmesg -t
|
||||
|
||||
The following script runs the above dmesg commands and saves the output for comparing with older release dmesg files. It then runs diff commands against the older release dmesg files. Old release is a required input parameter. If one is not supplied, it will simply generate dmesg files and exit. Regressions indicate newly introduced bugs and/or bugs that escaped patch testing and integration testing in linux git trees prior to including the patch in a release. Are there any stack traces resulting from WARN_ON in the dmesg? These are serious problems that require further investigation.
|
||||
|
||||
- [**dmesg regression check script**][1]
|
||||
|
||||
### Stress Testing ###
|
||||
|
||||
Running 3 to 4 kernel compiles in parallel is a good overall stress test. Download a few Linux kernel gits, stable, linux-next etc.. Run timed compiles in parallel. Compare times with old runs of this test for regressions in performance. Longer compile times could be indicators of performance regression in one of the kernel modules. Performance problems are hard to debug. First step is to detect them. Running several compiles in parallel is a good overall stress test that could be used as a performance regression test and overall kernel regression test, as it exercises various kernel modules like memory, file-systems, dma, and drivers.
|
||||
|
||||
time make all
|
||||
|
||||
### Kernel Testing Tools ###
|
||||
|
||||
There are several tests under tools/testing that are included in the Linux kernel git. There is a good mix of automated and functional tests.
|
||||
ktest suite
|
||||
|
||||
ktest is an automated test suite that can test builds, installs, and kernel boots. It can also run cross-compile tests provided the system has cross-compilers installed. ktest depends on flex and bison tools. Please consult the ktest documentation in tools/testing/ktest for details on how to run ktest. It is left to the reader as a self-study. A few resources that go into detail on how to run ktest:
|
||||
|
||||
- [**ktest-eLinux.org**][2]
|
||||
|
||||
### tools/testing/selftests ###
|
||||
|
||||
Let's start with selftests. Kernel sources include a set of self-tests which test various sub-systems. As of this writing, breakpoints, cpu-hotplug, efivarfs, ipc, kcmp, memory-hotplug, mqueue, net, powerpc, ptrace, rcutorture, timers, and vm sub-systems have self-tests. In addition to these, user memory self-tests test user memory to kernel memory copies via test_user_copy module. The following is on how to run these self-tests:
|
||||
|
||||
Compile tests:
|
||||
|
||||
make -C tools/testing/selftests
|
||||
|
||||
Run all tests: (running some tests needs root access, login as root and run)
|
||||
|
||||
make -C tools/testing/selftests run_tests
|
||||
|
||||
Run only tests targeted for a single sub-system:
|
||||
|
||||
make -C tools/testing/selftests TARGETS=vm run_tests
|
||||
|
||||
### tools/testing/fault-injection ###
|
||||
|
||||
Another test suite under tools/testing is fault-injection. failcmd.sh script runs a command to inject slab and page allocation failures. This type of testing helps validate how well kernel can recover from faults. This test should be run as root. The following is a quick summary of currently implemented fault injection capabilities. The list keeps growing as new fault injection capabilities get added. Please refer to the Documentation/fault-injection/fault-injection.txt for the latest.
|
||||
|
||||
failslab (default option)
|
||||
|
||||
injects slab allocation failures. kmalloc(), kmem_cache_alloc(), ...
|
||||
|
||||
fail_page_alloc
|
||||
|
||||
injects page allocation failures. alloc_pages(), get_free_pages(), ...
|
||||
|
||||
fail_make_request
|
||||
|
||||
injects disk IO errors on devices permitted by setting, /sys/block//make-it-fail or /sys/block///make-it-fail. (generic_make_request())
|
||||
|
||||
fail_mmc_request
|
||||
|
||||
injects MMC data errors on devices permitted by setting debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request
|
||||
|
||||
The capabilities and behavior of fault-injection can be configured. fault-inject-debugfs kernel module provides some debugfs entries for runtime. Ability to specify the error probability rate for faults, the interval between fault injection are just a couple of examples of the configuration choices fault-injection test supports. Please refer to the Documentation/fault-injection/fault-injection.txt for details. Boot options can be used to inject faults during early boot before debugfs becomes available. The following boot options are supported:
|
||||
|
||||
- failslab=
|
||||
- fail_page_alloc=
|
||||
- fail_make_request=
|
||||
- mmc_core.fail_request=[interval],[probability],[space],[times]
|
||||
|
||||
The fault-injection infrastructure provides interfaces to add new fault-injection capabilities. The following is a brief outline of the steps involved in adding a new capability. Please refer to the above mentioned document for details:
|
||||
|
||||
define the fault attributes using DECLARE_FAULT_INJECTION(name);
|
||||
|
||||
> Please see the definition of struct fault_attr in fault-inject.h for details.
|
||||
|
||||
add a boot option to configure fault attributes
|
||||
|
||||
> This can be done using helper function setup_fault_attr(attr, str); Adding a boot option is necessary to enable the fault injection capability during early boot time.
|
||||
|
||||
add debugfs entries
|
||||
|
||||
> Use the helper function fault_create_debugfs_attr(name, parent, attr); to add new debugfs entries for this new capability.
|
||||
|
||||
add module parameters
|
||||
|
||||
> Adding module parameters to configure the fault attributes is a good option, when the scope of the new fault capability is limited to a single kernel module.
|
||||
|
||||
add a hook to insert failures
|
||||
|
||||
> should_fail(attr, size); Upon should_fail() returning true, client code should inject a failure.
|
||||
|
||||
Applications using this fault-injection infrastructure can target a specific kernel module to inject slab and page allocation failures to limit the testing scope if need be.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,2
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://linuxdriverproject.org/mediawiki/index.php/Dmesg_regression_check_script
|
||||
[2]:http://elinux.org/Ktest#Git_Bisect_type
|
||||
143
sources/tech/20140718 Linux Kernel Testing and Debugging 4.md
Normal file
143
sources/tech/20140718 Linux Kernel Testing and Debugging 4.md
Normal file
@ -0,0 +1,143 @@
|
||||
Linux Kernel Testing and Debugging
|
||||
================================================================================
|
||||
### Auto Testing Tools ###
|
||||
|
||||
There are several automated testing tools and test infrastructures that you can chose from based on your specific testing needs. This section is intended to be a brief overview and not a detailed guide on how to use each of these.
|
||||
|
||||
#### [AuToTest][1] ####
|
||||
|
||||
> Autotest is a framework for fully automated testing. It is designed primarily to test the Linux kernel, though it is useful for many other functions such as qualifying new hardware. It is an open source project under the GPL. Autotest works in server-client mode. Autotest server can be configured to initiate, run, and monitor tests on several target systems running the autotest client. Autotest client can be run manually on a target system or via the server. Using this framework, new test cases can be added. Please [Autotest White Paper][2] for more information.
|
||||
|
||||
#### Linaro Automated Validation Architecture ####
|
||||
|
||||
> LAVA-Test Automated Testing Framework is a framework to help with automated installation and executions of tests. For example, running LTP in LAVA framework can be accomplished with a few commands. Running lava-test tool to install LTP will automatically install any dependencies, download the source for the recent release of LTP, compile it, and install the binaries in a self-contained area so that they can be removed easily when user runs uninstall. At this point running lava-test run with ltp test option will execute LTP tests and save results with an unique id that includes the test name, time/date stamp of the test execution. These results are saved for future reference. This is a good feature to find regressions, if any, between test runs. Summary of commands to run as an example:
|
||||
|
||||
Show a list of tests supported by lava-test:
|
||||
|
||||
lava-test list-tests
|
||||
|
||||
Install a new test:
|
||||
|
||||
lava-test install ltp
|
||||
|
||||
Run the test:
|
||||
|
||||
lava-test run ltp
|
||||
|
||||
Check results:
|
||||
|
||||
lava-test results show ltp-timestamp.0
|
||||
|
||||
Remove tests:
|
||||
|
||||
lava-test uninstall ltp
|
||||
|
||||
### Kernel Debug Features ###
|
||||
|
||||
Linux kernel includes several debugging features such as kmemcheck and kmemleak.
|
||||
|
||||
#### kmemcheck ####
|
||||
|
||||
> kmemcheck is a dynamic checking tool that detects and warns about some uses of uninitialized memory. It serves the same function as Valgrind's memcheck which is a userspace memory checker, where as kmemcheck checks kernel memory. CONFIG_KMEMCHECK kernel configuration option enables the kmemcheck debugging feature. Please read the Documentation/kmemcheck.txt for information on how to configure and use this feature, and how to interpret the reported results.
|
||||
|
||||
#### kmemleak ####
|
||||
|
||||
> kmemleak can be used to detect possible kernel memory leaks in a way similar to a tracing garbage collector. The difference between the tracing garbage collector and kmemleak is that the latter doesn't free orphan objects, instead it reports them in /sys/kernel/debug/kmemleak. A similar method of reporting and not freeing is used by the Valgrind's memcheck --leak-check to detect memory leaks in user-space applications. CONFIG_DEBUG_KMEMLEAK kernel configuration option enables the kmemleak debugging feature. Please read the Documentation/kmemleak.txt for information on how to configure and use this feature, and how to interpret the reported results.
|
||||
|
||||
### Kernel Debug Interfaces ###
|
||||
|
||||
Linux kernel has support for static and dynamic debugging via configuration options, debug APIs, interfaces, and frameworks. Let's learn more about each of these starting with the static options.
|
||||
|
||||
### Debug Configuration Options - Static ###
|
||||
|
||||
Linux kernel core and several Linux kernel modules, if not all, include kernel configuration options to debug. Several of these static debug options can be enabled at compile time. Debug messages are logged in dmesg buffer.
|
||||
|
||||
### Debug APIs ###
|
||||
|
||||
An example of Debug APIs is DMA-debug which is desiged for debugging driver dma api usage errors. When enabled, it keeps track of dma mappings per device, detects unmap attempts on addresses that aren't mapped, and missing mapping error checks in driver code after dma map attempts. CONFIG_HAVE_DMA_API_DEBUG and CONFIG_DMA_API_DEBUG kernel configuration options enable this feature on architectures that provide the support. With the CONFIG_DMA_API_DEBUG option enabled, the Debug-dma interfaces are called from DMA API. For example, when a driver calls dma_map_page() to map a dma buffer, dma_map_page() will call debug_dma_map_page() to start tracking the buffer until it gets released via dma_unmap_page() at a later time. For further reading on [Detecting silent data corruptions and memory leaks using DMA Debug API ][3]
|
||||
|
||||
### Dynamic Debug ###
|
||||
|
||||
Dynamic debug feature allows dynamically enabling/disabling pr_debug(), dev_dbg(), print_hex_dump_debug(), print_hex_dump_bytes() per-callsite. What this means is, a specific debug message can be enabled at run-time to learn more about a problem that is observed. This is great because, there is no need to re-compile the kernel with debug options enabled, then install the new kernel, only to find that the problem is no longer reproduciable. Once CONFIG_DYNAMIC_DEBUG is enabled in the kernel, dynamic debug feature enables a fine grain enable/disable of debug messages. /sys/kernel/debug/dynamic_debug/control is used to specify which pr_* messages are enabled. A quick summary of how to enable dynamic debug per call level, per module level is as follows:
|
||||
|
||||
Enable pr_debug() in kernel/power/suspend.c at line 340:
|
||||
|
||||
echo 'file suspend.c line 340 +p' > /sys/kernel/debug/dynamic_debug/control
|
||||
|
||||
Enable dynamic debug feature in a module at module load time
|
||||
|
||||
> Pass in dyndbg="plmft" to modprobe at the time module is being loaded.
|
||||
|
||||
Enable dynamic debug feature in a module to persist across reboots
|
||||
|
||||
> create or change modname.conf file in /etc/modprobe.d/ to add dyndbg="plmft" option. However for drivers that get loaded from initramfs, changing modname.conf is insufficient for the dynamic debug feature to persist across reboot. For such drivers, change grub to pass in module.dyndbg="+plmft" as a module option as a kernel boot parameter.
|
||||
|
||||
dynamic_debug.verbose=1 kernel boot option increases the verbosity of dynamic debug messages. Please consult the Documentation/dynamic-debug-howto.txt for more information on this feature.
|
||||
|
||||
### Tracepoints ###
|
||||
|
||||
So far we talked about various static and dynamic debug features. Both static debug options and debug hooks such as the DMA Debug API are either enabled or disabled at compile time. Both of these options require a new kernel to be compiled and installed. The dynamic debug feature eliminates the need for a recompile, however the debug code is compiled in with a conditional variable that controls whether or not the debug message gets printed. It helps that the messages can be enabled at run-time, however, the conditional code is executed at run-time to determine if the message needs to be printed. Tracepoint code on the otherhand can be triggered to be included at run-time only when the tracepoint is enabled. In other words, tracepoint code is different in that, it is inactive unless it is enabled. When it is enabled, code is modified to include the tracepoint code. It doesn't add any conditional logic overhead to determine whether or not to generate a trace message.
|
||||
|
||||
Please read [Tips on how to implement good tracepoint code][4] for more insight into how tracing works.
|
||||
|
||||
### Tracepoint mechanism ###
|
||||
|
||||
The tracepoints use jump-labels which is a code modification of a branch.
|
||||
|
||||
When it is disabled, the code path looks like:
|
||||
|
||||
[ code ]
|
||||
nop
|
||||
back:
|
||||
[ code ]
|
||||
return;
|
||||
tracepoint:
|
||||
[ tracepoint code ]
|
||||
jmp back;
|
||||
|
||||
When it is enabled, the code path looks like: (notice how the tracepoint code appears in the code path below)
|
||||
|
||||
[ code ]
|
||||
jmp tracepoint
|
||||
back:
|
||||
[ code ]
|
||||
return;
|
||||
tracepoint:
|
||||
[ tracepoint code ]
|
||||
jmp back;
|
||||
|
||||
### Linux PM Sub-system Testing ###
|
||||
|
||||
Using debug, dynamic debug, and tracing, let's run a few suspend to disk PM tests. When system is suspended, kernel creates hibernation image on disk, suspends and uses the image to restore the systerm state at resume time.
|
||||
|
||||
Enable logging time it takes to suspend and resume each device
|
||||
|
||||
echo 1 > /sys/power/pm_print_times
|
||||
|
||||
Run suspend to disk test in reboot mode
|
||||
|
||||
echo reboot > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
Run suspend to disk test in shutdown mode - same as reboot, except requires powering on to resume
|
||||
|
||||
echo shutdown > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
Run suspend to disk test in platform mode - more extensive and tests BIOS suspend and resume paths e.g: ACPI methods will be invoked. This is the recommended mode for hibernation so BIOS is informed and aware of suspend/resume action.
|
||||
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via:http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,3
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://autotest.github.io/
|
||||
[2]:https://github.com/autotest/autotest/wiki/WhitePaper
|
||||
[3]:http://events.linuxfoundation.org/sites/events/files/slides/Shuah_Khan_dma_map_error.pdf
|
||||
[4]:http://www.linuxjournal.com/content/july-2013-linux-kernel-news
|
||||
@ -0,0 +1,90 @@
|
||||
Linux Kernel Testing and Debugging
|
||||
================================================================================
|
||||
### Linux PM Sub-system Testing in Simulation Mode ###
|
||||
|
||||
The Linux PM sub-system provides five PM test modes to test hibernation in a simulated mode. These modes allow exercising the hibernation code in various layers of the kernel without actually suspending the system. This is useful when there is a concern that suspend might not work on a specific platform and help detect errors in a simulation similar to simulating flying a plane, so to speak.
|
||||
|
||||
freezer - test the freezing of processes
|
||||
|
||||
echo freezer > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
devices - test the freezing of processes and suspending of devices
|
||||
|
||||
echo devices > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
platform - test the freezing of processes, suspending of devices and platform global control methods(*)
|
||||
|
||||
echo platform > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
processors - test the freezing of processes, suspending of devices, platform global control methods(*) and the disabling of non-boot CPUs
|
||||
|
||||
echo processors > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
core - test the freezing of processes, suspending of devices, platform global control methods, the disabling of non-boot CPUs and suspending of platform/system devices. Note: this mode is tested on ACPI systems.
|
||||
|
||||
echo core > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
### Linux PM Sub-system Trace Events ###
|
||||
|
||||
PM sub-system supports several tracepoints and trace events that can be enabled to trigger during run-time. I will give an overview on how to enable couple of these trace events and where to find the trace information they generate:
|
||||
|
||||
Enabling PM events at run-time:
|
||||
|
||||
cd /sys/kernel/debug/tracing/events/power
|
||||
echo 1 > cpu_frequency/enable
|
||||
cat /sys/kernel/debug/tracing/set_event
|
||||
less /sys/kernel/debug/tracing/trace
|
||||
|
||||
Enabling events at boot-time kernel trace parameter with a kernel boot option:
|
||||
|
||||
trace_event=cpu_frequency
|
||||
|
||||
For more information on Linux PM testing, please consult the Documentation/power/basic-pm-debugging.txt and other documents in the same directory.
|
||||
|
||||
### git bisect ###
|
||||
|
||||
git bisect is an invaluable and powerful tool to isolate an offending commit. I will go over very basic git bisect steps.
|
||||
|
||||
This is how the process works:
|
||||
|
||||
git bisect start
|
||||
git bisect bad # Current version is bad
|
||||
git bisect good v3.14-rc6 # last good version
|
||||
|
||||
Once, one bad and one good version are specified, git bisect will start bisecting by pulling in commits between the good version and the bad. Once a set of commits are pulled in, compile the kernel, install, test, and tag the version good or bad. This process repeats until the selected commits are tested and tagged as good or bad. There can be several kernel versions to test. When the last version is tested, git bisect will flag a commit that is bad. The following useful git-bisect command can aid in using git-bisect process:
|
||||
|
||||
See step by step bisect progress
|
||||
|
||||
git bisect log
|
||||
|
||||
Reset git bisect can be used in case of mistakes in tagging, save git log output and replay prior to reset
|
||||
|
||||
git bisect reset
|
||||
|
||||
Replay a git-bisect log
|
||||
|
||||
git bisect replay git_log_output
|
||||
|
||||
git bisect can be run on a section of kernel source tree if the problem is clearly in that area. For example, when debugging a problem in radeon driver, running git bisect on drivers/drm/radeon will limit the scope of bisect to just the commits to drivers/drm/radeon driver.
|
||||
|
||||
Start git bisect on a section of a kernel tree
|
||||
|
||||
git bisect start drivers/drm/radeon
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,4
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
138
sources/tech/20140718 Linux Kernel Testing and Debugging 6.md
Normal file
138
sources/tech/20140718 Linux Kernel Testing and Debugging 6.md
Normal file
@ -0,0 +1,138 @@
|
||||
Linux Kernel Testing and Debugging
|
||||
================================================================================
|
||||
### Linux Kernel Patch Testing ###
|
||||
|
||||
Are you try your hands on writing a kernel patch? This section will go over how to test a new patch before sending it to the Linux mailing list. Further more, we will also talk about how to send it.
|
||||
Once the code is ready, compile it. Save the make output to a file to see if the new code introduced any new warnings. Address warnings, if any. Once the code compiles cleanly, install the compiled kernel and boot test. If it boots successfully, make sure there are no new errors in the dmesg, comparing it with the previous kernel dmesg. Run a few usage and stress tests. Please refer to the testing content we discussed earlier in this paper. If the patch is for fixing a specific bug, make sure the patch indeed fixes the bug. If the patch fixes the problem, make sure, other module regression tests pass. Identify regression tests for the patched module and run them. When a patch touches other architectures, cross-compile build testing is recommended. Please check the following in the source git as a reference to identify tests.
|
||||
|
||||
- linux_git/Documentation
|
||||
- linux_git/tools/testing
|
||||
- Cross-compiling reference: [Cross-compiling Linux Kernels on x86_64: A tutorial on How to Get Started][1]
|
||||
|
||||
Once you are satisfied with the patch testing, it is time to commit the change and generate the patch. Make sure the commit message describes the change made very clearly. It is important that the maintainer and other developers can understand what this change is all about. Once patch is ready, run scripts/checkpatch.pl on the generated patch. Address checkpatch errors and/or warnings, if any. Regenerate and repeat until the patch passes the checkpatch test. Unless the checkpatch errors are minor whitespace type, re-test the patch. Apply the patch to another instance of the kernel git to make sure patch applies cleanly.
|
||||
|
||||
Now you are ready to send the patch. Please run the scripts/get_maintainer.pl to identify whom the patch should be sent to. Please remember that the patch needs to be sent as a plain text, not as an attachment. Please make sure your email client can send plain text messages. Email the patch to yourself to test your client settings. Run checkpatch and apply the received patch. If these two steps pass, then you are ready to send the patch to the Linux Kernel Mailing List. git send-email is the safest way to send patches to avoid email client complications. Please make sure your .gitconfig includes sendemail with a valid smtpserver. Please consult git manpage for details.
|
||||
|
||||
Please refer to the following documentation in the kernel sources for rules and guidelines on sending patches:
|
||||
|
||||
- linux_git/Documentation/applying-patches.txt
|
||||
- linux_git/Documentation/SubmitChecklist
|
||||
- linux_git/Documentation/SubmittingDrivers
|
||||
- linux_git/Documentation/SubmittingPatches
|
||||
- linux_git/Documentation/stable_kernel_rules.txt
|
||||
- linux_git/Documentation/stable_api_nonsense.txt
|
||||
|
||||
The following is a list of additional testing guides and resources:
|
||||
|
||||
- [USB Testing on Linux][2]
|
||||
- [Linux Kernel Tester's Guide Chapter2][3]
|
||||
- [Linux Kernel Tester's Guide][4]
|
||||
- [Testing resources at eLinux.org][5]
|
||||
- [eLinux Debugging Portal][6]
|
||||
|
||||
### Kernel test suites and projects ###
|
||||
|
||||
In addition to the testing resources we discussed so far, there are projects both open source and initiated by hardware vendors that are worth a mention. Each of these projects focus on specific areas of the kernel and in some cases a specific space such as, embedded or enterprise where the kernel is used. We will look at a few in this section.
|
||||
|
||||
[Linux Test Project][7] (LTP) test suite is a collection of tools to test reliability, robustness, and stability of Linux kernel and related features. This test suite can be customized by adding new tests and the LTP project welcomes contributions. runltp script tests the following sub-systems by default:
|
||||
|
||||
- filesystem stress tests
|
||||
- disk I/O tests
|
||||
- memory management stress tests
|
||||
- ipc stress
|
||||
- scheduler tests
|
||||
- commands functional verification tests
|
||||
- system call functional verification tests
|
||||
|
||||
[**LTP-DDT**][8] is an LTP based test application wth a reduced focus to test embedded device drivers.
|
||||
|
||||
[**Linux Driver Verification**][9] project's goals are to improve the quality of Linux device drivers, develop an integrated platform for device drivers verification, and adopt latest research outcome to enhance quality of verification tools.
|
||||
|
||||
### Compliance Testing ###
|
||||
|
||||
If you ever had to port applications from one Unix variant to another, you would understand the importance of the [Linux Standard Base (LSB)][10] and LSB compliance test suite. The LSB is a Linux Foundation workgroup created to reduce the costs of supporting Linux platform, by reducing the differences between various Linux distributions and ensuring application portability between distributions. If anything, divergence in the Unix world taught us that it is vital to avoid it in the Linux world. This is exactly the reason why you can take an rpm convert it to deb and install and run it, and how sweet is that.
|
||||
|
||||
### Static Analysis and Tools ###
|
||||
|
||||
Static analysis tools analyze the code without executing it, hence the name static analysis. There are a couple of static analysis tools that are sepcifically written for analyzing the Linux kernel code base. Sparse is a static type-checking program written specifically for the Linux kernel, by Linus Torvalds. Sparse is a semantic parser. It creates a sematic prase tree to validate C semantics. It performs lazy type evaluation. Kernel build system has support for sparse and provides a make option to compile the kernel with sparse checking enabled.
|
||||
|
||||
Run sparse on all kernel C files that would get re-compiled:
|
||||
|
||||
make C=1 allmodconfig
|
||||
|
||||
Run sparse on all kernel C files even when they don't need a re-compile:
|
||||
|
||||
make C=2 allmodconfig
|
||||
|
||||
Sparse resources:
|
||||
|
||||
- [Sparse Archive][11]
|
||||
- [Sparse How To][12]
|
||||
|
||||
Smatch analyzes source to detect programming logic errors. It can detect logic errors such as, attempts to unlock already unlocked spinlock. It is actively used to detect logic errors in the Linux kernel sources.
|
||||
|
||||
Run smatch on Linux kernel:
|
||||
|
||||
make CHECK="~/path/to/smatch/smatch -p=kernel" C=1 bzImage modules | tee warns.txt
|
||||
|
||||
Please follow instructions on how to get smatch from smatch git repo and compile. Smatch is work in progress, instructions keep changing.
|
||||
|
||||
- [**Smatch**][12]
|
||||
|
||||
So what do we do about all of these semantic and logic problems found by Sparse and Smatch? Some of these problems are isolated to a routine and/or a module which can be fixed easily. However, some of these semantic issues are global in nature due to cut and paste of code. In some cases when interfaces get obsoleted or changed slightly, a mass change to update several source files becomes necessary. This is where Coccinelle comes in to rescue. Coccinelle is a program matching and transformation engine which provides the language SmPL (Semantic Patch Language) for specifying desired matches and transformations in C code. Coccinelle was initially targeted towards performing collateral evolutions in Linux.
|
||||
|
||||
For example, foo(int) interfaces changes to foo(int, char \*) with an optional second input parameter which can be a null. All usages of foo() will need to be updated to the new convention, which will be a very laborious task. Using Cocinelle, this task becomes easier with a script that looks for all instances of foo(parameter1) and replacing them with foo(parameter1, NULL). Once this task is done, all instances of foo() can be examined to see if passing in NULL value for parameter2 is a good assumption. For more information on Cocinelle and how it is used in fixing problems in various projects including the Linux kernel, please refer to the project page: [**Cocinelle**][13]
|
||||
|
||||
### References ###
|
||||
|
||||
We covered a lot of ground in this paper. I leave you with a few references for further reading on the topics we discussed.
|
||||
|
||||
- [KernelHacking][14]
|
||||
- [kernel Documentation][15]
|
||||
- [Linux Device Drivers, Third Edition][16]
|
||||
- [Dynamic Event Tracing in Linux Kernel][17]
|
||||
- [Kernel Testing: Tool and Techniques][18]
|
||||
|
||||
### Acknowledgements ###
|
||||
|
||||
I would like to thank Khalid Aziz, Oracle for his review, proof reading, and valuable suggestions for improvement. My special thanks to Mauro Chehab, Samsung and Guy Martin, Samsung for their review and feedback at various stages of writing this paper. I would like to extend my thanks to Greg Kroah-Hartman, Linux Foundation for his review. My special thanks to Ibrahim Haddad, Samsung for his support and encouragement without which, I would probably have never set out to write this paper in the first place.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
|
||||
Author:[Shuah Khan][a]
|
||||
|
||||
Shuah Khan is a Senior Linux Kernel Developer at Samsung's Open Source Group.
|
||||
She is a Linux Kernel Contributor who focuses on IOMMU, DMA, Linux Power
|
||||
Management, and PCIe, in addition to helping with stable release kernel
|
||||
maintenance testing and bug fixes. Shuah has several years of Unix kernel
|
||||
development experience. She has also contributed to OpenHPI, and LLDP projects.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,5
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://events.linuxfoundation.org/sites/events/files/slides/Shuah_Khan_cross_compile_linux.pdf
|
||||
[2]:http://www.linux-usb.org/usbtest/
|
||||
[3]:http://kernelnewbies.org/Linux_Kernel_Tester%27s_Guide_Chapter2
|
||||
[4]:http://www.kerneltravel.net/downloads/tester_guide.pdf
|
||||
[5]:http://elinux.org/Test_Systems
|
||||
[6]:http://elinux.org/Debugging_Portal
|
||||
[7]:http://ltp.sourceforge.net/documentation/how-to/ltp.php
|
||||
[8]:http://processors.wiki.ti.com/index.php/LTP-DDT
|
||||
[9]:http://linuxtesting.org/project/ldv
|
||||
[10]:http://www.linuxfoundation.org/collaborate/workgroups/lsb
|
||||
[11]:http://codemonkey.org.uk/projects/git-snapshots/sparse/
|
||||
[12]:http://smatch.sourceforge.net/
|
||||
[13]:http://coccinelle.lip6.fr/
|
||||
[14]:http://kernelnewbies.org/KernelHacking
|
||||
[15]:http://kernelnewbies.org/Documents
|
||||
[16]:http://lwn.net/Kernel/LDD3/
|
||||
[17]:http://events.linuxfoundation.org/slides/lfcs2010_hiramatsu.pdf
|
||||
[18]:http://events.linuxfoundation.org/images/stories/slides/elc2013_porter.pdf
|
||||
[a]:http://www.linuxjournal.com/users/shuah-khan
|
||||
@ -0,0 +1,57 @@
|
||||
Need Microsoft Office on Ubuntu? Install the Official Web Apps
|
||||
================================================================================
|
||||
|
||||
|
||||
**It’s not everyone’s cup of joe, but Microsoft Office and its family of finicky file formats are a mainstay of many working and educational environments — for better or worse.**
|
||||
|
||||
Reading, editing and saving to these proprietary formats is sort of possible on Ubuntu using the [LibreOffice suite of apps][1]. Writer, Calc and Impress all boast varying degrees of Microsoft Office file interoperability, though in my own real world experience (thankfully brief) it’s not perfect.
|
||||
|
||||
For the times you can’t go without using Office file formats (as ideological as most of us are about open standards, we shouldn’t be blind to practicalities) but you’ve no desire to purchase a full MS Office licence to run through WINE, the official set of Microsoft Office Online web apps are the perfect answer.
|
||||
|
||||
### Install Microsoft Office Online Apps in Ubuntu ###
|
||||
|
||||
To make accessing these online versions easier from the Ubuntu desktop, the ‘Linux Web Apps project’ has created a small, unofficial installer that adds web app shortcuts (“glorified bookmarks”) to your application launcher.
|
||||
|
||||
|
||||
|
||||
These are nothing more fancy than shortcuts to the respective Microsoft web app that opens in your default system browser. Sound nifty? You get application shortcuts for:
|
||||
|
||||
- Word
|
||||
- Excel
|
||||
- PowerPoint
|
||||
- Outlook
|
||||
- OneDrive
|
||||
- Calendar
|
||||
- OneNote
|
||||
- People
|
||||
|
||||
The package also creates a new application category housing the links, letting you view the shortcuts separately from other applications as well as under the regular “office” apps directory.
|
||||
|
||||
Are these essential? Not really. Are they useful? Depends on your workflow. But is it nice to have the option? For sure.
|
||||
|
||||
You can grab the .deb installer containing the links from the link below and is suitable for Ubuntu 14.04 LTS and later.
|
||||
|
||||
- [Download Microsoft Office Web Apps (.deb)][2]
|
||||
|
||||
### Other Alternatives ###
|
||||
|
||||
|
||||
|
||||
A similar alternative is to [install the official Office Online web applications from the Chrome Web Store][3], then add the app launcher to Linux. This will still create launchable shortcuts for them in the Dash, but ones that can be set to open in their own window frames and forgo the need to install any third-party packages.
|
||||
|
||||
Similarly, Google recently folded in full Office capabilities (thanks to its purchase of QuickOffice) [into its own Docs, Slides and Sheets applications][4], retired the QuickOffice Android application and rebranded the companion Chrome extension.
|
||||
|
||||
If you’re a heavy Google Drive/Docs user, this may be the better solution for you.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.omgubuntu.co.uk/2014/07/run-microsoft-office-web-apps-ubuntu-desktop
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://www.libreoffice.org/
|
||||
[2]:https://docs.google.com/file/d/0ByQnaVw7riBQMjNCUFh4ZlM4Y0E/edit?usp=sharing
|
||||
[3]:http://www.omgchrome.com/microsoft-brings-office-online-chrome-web-store/
|
||||
[4]:http://www.omgchrome.com/quickoffice-chrome-extension-gets-name-change/
|
||||
58
translated/talk/20140626 Joy of Programming--Fail Fast.md
Normal file
58
translated/talk/20140626 Joy of Programming--Fail Fast.md
Normal file
@ -0,0 +1,58 @@
|
||||
编程的乐趣：快速出错！
|
||||
================================================================================
|
||||
|
||||
|
||||
> 当软件出现问题的时候，它应该以一种能引起注意的方式马上终止。这种“快速出错”的方式值得借鉴，我们会在这期专栏里谈谈这个重要的概念。
|
||||
|
||||
一开始，“快速出错”看上去是一种会影响可靠性的不好的实践－为什么一个系统在还可以继续运行的时候要崩溃（或者说终止）？对于这个，我们需要理解，快速出错是和Heisenbugs（对于不能复现bug的一种称呼）紧密联系在一起的。
|
||||
|
||||
考虑一下Bohrbugs（对于能够重现的bug的一种称呼），它们在给定输入的时候总是会出现，比如，访问空指针。这类问题很容易测试，复现并修复。如今，所有有经验的程序员应该都面对过这样的情形，导致崩溃的bug在重启软件后不再出现了。不管花多少时间或努力去重现问题，那个bug就是跟我们捉迷藏。这种bug被称为Heisenbugs。
|
||||
|
||||
花在寻找，修复和测试Heisenbugs上的努力比起Bohrbugs来说，要高出一个数量级。一种避免Heisenbugs的策略是将它们转化为Bohrbugs。怎么做呢？预测可能导致Heisenbugs的因素，然后尝试将它们变成Bohrbugs。是的，这并不简单，而且也并不是一定就能成功，但是让我们来看一个能产生效果的特殊例子。
|
||||
|
||||
并发编程是Heisenbugs经常出现的一个典范。我们的例子就是一个Java里和并发相关的问题。在遍历一个Java集合的时候，一般要求只能通过Iterator的方法，比如remove()方法。而当遍历的时候，如果有另一个线程尝试修改底层集合（因为编程时留下的错误），那么底层集合就可能会被破坏（例如，导致不正确的状态）。
|
||||
|
||||
类似这种不正确的状态会导致不确定的错误－假如我们幸运的话（实际上，这很不幸！），程序可以继续执行而不会崩溃，但是却给出错误的结果。这种bug很难重现和修复，因为这一类的程序错误都是不确定的。换句话说，这是个Heisenbug。
|
||||
|
||||
幸运的是，Java Iterators会尝试侦测这种并发修改，在发现了以后，会丢出异常`ConcurrentModificationException`，而不是等到最后再出错－那样也是没有任何迹象的。换句话说，Java Iterators也遵从了“快速出错”的方法。
|
||||
|
||||
如果异常`ConcurrentModificationException`在正式软件中发生了呢？根据在Javadoc里对这个异常的说明，它“只应该用于侦测bug”。换句话说，`ConcurrentModificationException`只应该在开发阶段监听和修复，而不应该泄漏到正式代码中。
|
||||
|
||||
好吧，如果正式软件确实发生了这个异常，那它当然是软件中的bug，应当报告给开发者并修复。至少，我们能够知道发生了一次底层数据结构的并发修改，而这是软件出错的原因（而不是让软件产生错误的结果，或是以其他现象延后出错，这样就很难跟踪到根本原因）。
|
||||
|
||||
“安全出错”的方法意味着开发健壮的代码。一个很好的编写安全出错代码的例子就是使用断言。很可惜的是，关于断言的使用有大量不必要的公开争论。其中主要的批评点是：它在开发版本中使用，而在发布版中却被关掉的。
|
||||
|
||||
不管怎么样，这个批评是错误的：从来没有说用断言来替代应该放到发布版软件中的防御式检查代码。例如，断言不应该用来检查传递给函数的参数是否为空。相应的，应该用一个if语句来检查这个参数是否正确，否则的话抛出异常，或是提前返回，来适合上下文。然而，断言一般用于额外检查代码中所做出的假设，它们应该为真才正常。例如，用一个语句来检查在进行了入栈操作后，栈应该不是空的（例如，对“不变量”的检查）。
|
||||
|
||||
所以，快速出错，随时中断，那么你已经走在开发更加健壮代码的道路上了。
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via:http://www.opensourceforu.com/2011/12/joy-of-programming-fail-fast/
|
||||
|
||||
译者：[zpl1025](https://github.com/zpl1025) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:
|
||||
[2]:
|
||||
[3]:
|
||||
[4]:
|
||||
[5]:
|
||||
[6]:
|
||||
[7]:
|
||||
[8]:
|
||||
[9]:
|
||||
[10]:
|
||||
[11]:
|
||||
[12]:
|
||||
[13]:
|
||||
[14]:
|
||||
[15]:
|
||||
[16]:
|
||||
[17]:
|
||||
[18]:
|
||||
[19]:
|
||||
[20]:
|
||||
@ -1,94 +0,0 @@
|
||||
Linux 高级目录导航技巧
|
||||
================================================================================
|
||||
|
||||
目录当行是命令行系统的基础概念.虽然不是什么难以理解的东西,但是知道一些技巧能够丰富你的经验并且提高工作效率.在这篇文章中,我们会讨论这些小技巧.
|
||||
|
||||
### 我们已经知道的东西 ###
|
||||
|
||||
在开始高级技巧之前,有一些必须知道的基本命令:
|
||||
|
||||
- ‘pwd’显示当前目录
|
||||
- ‘cd’ 改变当前目录
|
||||
- ‘cd’ 跟两个点(cd ..)能返回父目录
|
||||
- ‘cd’ 跟着相对目录就能直接切换当相对目录下
|
||||
- ‘cd’ 跟着绝对目录就能切换到绝对目录下
|
||||
|
||||
### 高阶技巧 ###
|
||||
|
||||
这节将介绍几个技巧方便你进行目录的切换
|
||||
|
||||
### 从任何地方回到home目录 ###
|
||||
|
||||
虽然使用‘cd /home/<your-home-directory-name>’, 不是什么大麻烦, 但是有一种方法直接打‘cd’ 就能回到home目录.
|
||||
|
||||
Here is an example :
|
||||
|
||||
$ pwd
|
||||
/usr/include/netipx
|
||||
$ cd
|
||||
$ pwd
|
||||
/home/himanshu
|
||||
|
||||
所以无论你在哪个目录下,都能这么干然后回到home目录.
|
||||
|
||||
**注意**- 如果要切换到确定用户的目录下, 就使用 ‘cd ~user_name'
|
||||
|
||||
### 用cd在目录间切换 - ###
|
||||
|
||||
假设你的工作目录是这样的:
|
||||
|
||||
$ pwd
|
||||
/home/himanshu/practice
|
||||
|
||||
如果你想切换到 **/usr/bin/X11**, 然后又想回到之前的目录. 你会怎么做? 最直接的 :
|
||||
|
||||
$ cd /usr/bin/X11
|
||||
$ cd /home/himanshu/practice/
|
||||
|
||||
虽然这样行得通,但是要记住这些复杂的目录是个大困难.这种情况下使用 ‘cd -’ 命令就行.
|
||||
|
||||
使用 ‘cd -’的第一步和上面的例子是一样的, 你可以 cd 到你想要切换到的<path>下 , 但是回到之前的目录用 ‘cd -’就可以.
|
||||
|
||||
$ cd /usr/bin/X11
|
||||
$ cd -
|
||||
/home/himanshu/practice
|
||||
$ pwd
|
||||
/home/himanshu/practice
|
||||
|
||||
如果你想回到最后访问的目录(在这个例子中是/usr/bin/X11),也使用'cd -'就可以.但是这个命令只会记住最后访问的目录,这是一个缺点.
|
||||
|
||||
### 用 pushd 和 popd 来切换目录 ###
|
||||
|
||||
|
||||
|
||||
|
||||
如果你对'cd -'非常了解了的话,你会发现这个命令只能帮助你在两个目录之间移动,但是很多场景下需要在很多目录之间切换.比如你要从A切换到B再到C然后又想回到A.
|
||||
|
||||
一般来说,你需要打出A的完整路劲,但是如果这个路径非常复杂,将是非常烦人的一件事,热别是你的切换非常频繁的话.
|
||||
|
||||
一些场景下可以使用 ‘pushd’ 还有 ‘popd’ 命令. The ‘pushd’ 将一个目录存到内存中,‘popd’ 将目录从内存中去除,并且转换到那个目录下.
|
||||
|
||||
例如 :
|
||||
|
||||
$ pushd .
|
||||
/usr/include/netipx /usr/include/netipx
|
||||
$ cd /etc/hp/
|
||||
$ cd /home/himanshu/practice/
|
||||
$ cd /media/
|
||||
$ popd
|
||||
/usr/include/netipx
|
||||
$ pwd
|
||||
/usr/include/netipx
|
||||
|
||||
使用‘pushd’ 命令存储当前的工作目录 (用 .表示), 然后切换到各种各样的目录去. 为了返回之前的目录 ,只要使用 ‘popd’命令就行了.
|
||||
使用
|
||||
|
||||
**注意**- 你也可以使用 ‘pushd’ 来切换到之前存储的目录, 但是不会像 ‘popd’ 一样去除这个目录.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://linoxide.com/linux-command/directory-navigations-tips-tricks/
|
||||
|
||||
译者：[ggaaooppeenngg](https://github.com/ggaaooppeenngg) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
@ -0,0 +1,111 @@
|
||||
How to check RPM package dependencies on Fedora, CentOS or RHEL
|
||||
教你如何在Fedora,CentOS,RHEL中检查RPM包的依赖性
|
||||
================================================================================
|
||||
A typical RPM package on Red Hat-based systems requires all its dependent packages be installed to function properly.
|
||||
For end users, the complexity of such RPM dependency is hidden by package managers (e.g., yum or DNF) during package install/upgrade/removal process. However, if you are a sysadmin or a RPM maintainer, you need to be well-versed in RPM dependencies to maintain run-time environment for the system or roll out up-to-date RPM specs.
|
||||
我们都知道，在基于红帽的Linux系统中，一个RPM包，需要把先将它依赖的其他包安装好才能正常的工作。对于终端用户，RPM的安装、更新、删除中存在的依赖关系已经被工具透明化了（如 yum或 DNF等)。但如果你是系统管理员或者RPM包的管理员，你需要对RPM包中存在的依赖关系以及时更新、删除适当的包来保证系统的正常运行。
|
||||
In this tutorial, I am going to show **how to check RPM package dependencies**. Depending on whether a package is installed or not, there are several ways to identify its RPM dependencies.
|
||||
在本教程中，我将教大家**如何检查RPM包的依赖关系**无论这个包是否已经安装进操作系统中，我们都有一些办法来检查它们的依赖性。
|
||||
### Method One ###
|
||||
### 方法一 ###
|
||||
One way to find out RPM dependencies for a particular package is to use rpm command. The following command lists all dependent packages for a target package.
|
||||
使用RPM命令可以列出目标包所依赖的所有包，如下：
|
||||
$ rpm -qR <package-name>
|
||||
|
||||
|
||||
|
||||
Note that this command will work only if the target package is already **installed**. If you want to check package dependencies for any **uninstalled** package, you first need to download the RPM package locally (no need to install it).
|
||||
注意，这种方法只适用于**已安装**的包。如果你需要检查一个**未安装**包的依赖关系，你需要把这个包先下载到本地来。
|
||||
To download a RPM package without installing it, use a command-line utility called `yumdownloader`. Install yumdownloader as follows.
|
||||
对于已在本地但未安装的包，可以使用叫做'yumdownloader'的工具，下面我们先安装yumdownloader：
|
||||
$ sudo yum install yum-utils
|
||||
|
||||
Now let's check RPM depenencies of a uninstalled package (e.g., tcpdump). First download the package in the current folder with yumdownloader:
|
||||
现在我们来检查一个未安装的RPM包的依赖关系(本列使用 tcpdump)。首先，我们使用yumdownloader把tcpdump的RPM包下载下来
|
||||
$ yumdownloader --destdir=. tcpdump
|
||||
|
||||
Then use rpm command with "-qpR" options to list dependencies of the downloaded package.
|
||||
然后再使用 "-qpR"参数显示该包的依赖关系。
|
||||
# rpm -qpR tcpdump-4.4.0-2.fc19.i686.rpm
|
||||
|
||||
### Method Two ###
|
||||
### 方法二 ###
|
||||
You can also get a list of dependencies for a RPM package using repoquery tool. repoquery works whether or not a target package is installed. This tool is included in yum-utils package.
|
||||
你可以使用repoquery工具来罗列包的依赖关系，这个工具包含在yum-utils中。
|
||||
$ sudo yum install yum-utils
|
||||
|
||||
To show all required packages for a particular package:
|
||||
显示目标包所依赖的包：
|
||||
$ repoquery --requires --resolve <package-name>
|
||||
|
||||
|
||||
|
||||
For repoquery to work, your computer needs network connectivity since repoquery pulls information from Yum repositories.
|
||||
为让repoquery正常的工作，需要保持网络的畅通，应为repoquery需要在Yum库中查找信息。
|
||||
### Method Three ###
|
||||
### 方法三 ###
|
||||
The third method to show RPM package dependencies is to use rpmreaper tool.
|
||||
Originally this tool is developed to clean up unnecessary packages and their dependencies on RPM-based systems.
|
||||
rpmreaper has an ncurses-based intuitive interface for browsing installed packages and their dependency trees.
|
||||
第三个方法是使用rpmreaper工具。这个工具本来是用作清理系统中无用以及它们所依赖的包，rpmreaper有很直观的界面来展示已安装的包和它们依赖关系的树形图。
|
||||
To install rpmrepater, use yum command. On CentOS, you need to [set up EPEL repo][1] first.
|
||||
安装rpmrepater，在CentOS中，你需要先[设置好EPEL库][1]
|
||||
$ sudo yum install rpmreaper
|
||||
|
||||
To browser RPM dependency trees, simply run:
|
||||
只需运行rpmreaper就可以看到RPM包的依赖关系：
|
||||
$ rpmreaper
|
||||
|
||||
|
||||
|
||||
The rpmrepater interface will show you a list of all installed packages. You can navigate the list using up/down arrow keys.
|
||||
Press "r" on a highlighted package to show its dependencies.
|
||||
You can expand the whole dependency tree by recursively pressing "r" keys on individual dependent packages.
|
||||
The "L" flag indicates that a given package is a "leaf", meaning that no other package depends on this package.
|
||||
The "o" flag implies that a given package is in the middle of dependency chain.
|
||||
Pressing "b" on such a package will show you what other packages require the highlighted package.
|
||||
rpmrepater会向用户显示已安装包的列表，你可以使用上/下箭头来滚动屏幕。
|
||||
你可以在指定包上使用"r"键来显示其依赖关系，循环在指定包上按下"r"键可以展示出余下的信息。
|
||||
"L"标志的意思是说这个包是一片“孤叶”，意思说说没有任何包依赖它。
|
||||
"o"标志是说这个包是整个依赖链的中间部分。
|
||||
按下"b"键会显示其他依赖于该包的其他包。
|
||||
### Method Four ###
|
||||
### 方法四 ###
|
||||
Another way to show package dependencies on RPM-based systems
|
||||
is to use rpmdep which is a command-line tool for generating a full package dependency graph of
|
||||
any installed RPM package. The tool analyzes RPM dependencies, and produce partially ordered package lists from
|
||||
topological sorting. The output of this tool can be fed into dotty graph visualization tool
|
||||
to generate a dependency graph image.
|
||||
还有一个办法是使用rpmdep工具，rpmdep是一个命令行工具，可以显示已安装包的完整包依赖关系图。该工具会分析RPM包的依赖性，从完整的排完序
|
||||
的拓扑图中摘取部分包的信息，形成列表展示给用户。该工具的输出结果可以直接使用到Dotty（可视化展示工具）中去。
|
||||
To install rpmdep and dotty on Fedora:
|
||||
在Fedora中安装rpmdep和dotty：
|
||||
$ sudo yum install rpmorphan graphviz
|
||||
|
||||
To install the same tools on CentOS:
|
||||
在CentOs中安装：
|
||||
$ wget http://downloads.sourceforge.net/project/rpmorphan/rpmorphan/1.14/rpmorphan-1.14-1.noarch.rpm
|
||||
$ sudo rpm -ivh rpmorphan-1.14-1.noarch.rpm
|
||||
$ sudo yum install graphviz
|
||||
|
||||
To generate and plot a dependency graph of a particular installed package (e.g., gzip):
|
||||
生成包依赖的拓扑关系图：
|
||||
$ rpmdep.pl -dot gzip.dot gzip
|
||||
$ dot -Tpng -o output.png gzip.dot
|
||||
|
||||
|
||||
|
||||
So far in this tutorial, I demonstrate several ways to check what other packages a given RPM package relies on.
|
||||
If you want to know more about .deb package dependencies for Debian-based systems,
|
||||
you can refer to [this guide][2] instead.
|
||||
教程到这个地方，我们用到了几种办法来检查包的依赖关系。如果您想知道如何在居于Debian的系统中检查.deb的包依赖关系，请阅读另外一篇[文档][2]
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://xmodulo.com/2014/07/check-rpm-package-dependencies-fedora-centos-rhel.html
|
||||
|
||||
译者：[nd0104](https://github.com/nd0104) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://xmodulo.com/2013/03/how-to-set-up-epel-repository-on-centos.html
|
||||
[2]:http://xmodulo.com/2013/07/how-to-check-package-dependencies-on-ubuntu-or-debian.html
|
||||
@ -0,0 +1,182 @@
|
||||
装X指南--在Linux上装个Android 4.4玩玩
|
||||
================================================================================
|
||||
**Android (x86)**项目致力于移植Android系统到X86处理器上，使用户可以更容易的在任何电脑上安装Android。他们通过使用android源码，增加补丁来使Android能够在X86处理器下工作，不单只是笔记本电脑和平板电脑。
|
||||
|
||||
|
||||
在Linux安装Android 4.4 KitKat
|
||||
|
||||
几天前，项目组发布了最新的“Android KitKat 4.4 RC2”，下面，我将说明如何在VirtualBox上的安装过程，不过有一个小问题，安装完成Android后鼠标指针不工作了，我猜，如果你根据本教程将它安装成主系统，这个鼠标应该可以工作，否则我们只能使用键盘了。
|
||||
|
||||
### 阶段 1: 在linux上安装VirtualBox ###
|
||||
|
||||
**1.** 大多数的Linux发行版中，官方源都有VirtualBox，例如在Ubuntu中安装
|
||||
|
||||
$ sudo apt-get install virtualbox
|
||||
|
||||
其他的Linux发行版，像**RHEL, CentOS and Fedora**,请参考下面文章来安装VirtualBox
|
||||
|
||||
- [Install VirtualBox in RHEL, CentOS and Fedora][1]
|
||||
|
||||
### 阶段 2: 下载并在VirtualBox中安装Android 4.4 kitkat ###
|
||||
|
||||
**2.** 这步挺简单的，只是需要去[androud Sourceforge.net][2]项目下载 **Android 4.4 x86 Kit Kat**文件
|
||||
|
||||
**3.** 为了安装**Android 4.4 kitkat**，首先，你需要引导刚刚下载.iso文件，启动 **VirtualBox**,创建一个新的虚拟机，然后跟着下面图片设置：
|
||||
|
||||
|
||||
创建新的虚拟设备
|
||||
|
||||
**4.** 接下来，它会询问你新设备的内存大小，Android 4.4 kikat需要1G内存才能完美运行，但是由于我的电脑只有1G内存，我只能选择512MB。
|
||||
|
||||
|
||||
设置内存
|
||||
|
||||
**5.** 选择“现在创建虚拟硬盘”（“Create a virtual hard drive now”）创建一个新的硬盘
|
||||
|
||||
|
||||
创建虚拟硬盘
|
||||
|
||||
**6.** 它现在会询问你新虚拟硬盘的类型，选择**VDI**
|
||||
|
||||
|
||||
选择硬盘驱动类型
|
||||
|
||||
|
||||
选择存储方式
|
||||
|
||||
**7.** 现在设置虚拟硬盘大小，你可以设置任何大小，但是除了未来安装Apps的空间，至少系统正确地安装需要**4G**。
|
||||
|
||||
|
||||
设置虚拟硬盘大小
|
||||
|
||||
**8.** 现在你的新虚拟设备创建好了，可以引导下载的**.iso**文件了，右键刚刚创建的虚拟机，**设置** -> **存储** ，如下图，设置**android 4.4 kitkat RC2**的镜像文件。
|
||||
|
||||
|
||||
选择Android KitKat ISO
|
||||
|
||||
**9.** Click on **OK**, and start the machine to boot the .iso image, choose “**Installation**” to start installing the system on the virtual machine.
|
||||
|
||||
|
||||
选择 Install Android Kit Kat
|
||||
|
||||
**10.** 请选择一个分区来安装Android-x86
|
||||
|
||||
|
||||
选择 Partition Drive
|
||||
|
||||
**11.** 如下图，你可以看见cfdisk界面，cfdisk是一个分区工具，我们将要使用它来创建一个新的硬盘分区，用来安装Android 4.4，现在，点击 “**New**”
|
||||
|
||||
|
||||
创建新分区
|
||||
|
||||
**12.** 选择“**Primary**”作为分区类型
|
||||
|
||||
|
||||
选择主分区
|
||||
|
||||
**13.** 接下来，设置分区大小
|
||||
|
||||
|
||||
设置分区大小
|
||||
|
||||
**14.** 现在我们必须给硬盘创建新的引导使其能够写入新的分区表，点击“**Bootable**”给引导标记新的分区，你不会注意到有任何变化，但是引导标记将会自己给选中分区。
|
||||
|
||||
|
||||
制作分区引导
|
||||
|
||||
**15.** 完成之后，点击“**Write**”对硬盘写入新的分区。
|
||||
|
||||
|
||||
应用新分区
|
||||
|
||||
**16.** 它会询问你是否确认，输入“**yes**”并点击**Enter**
|
||||
|
||||
|
||||
确认分区改变
|
||||
|
||||
**17.** 现在我们的新硬盘已经创建，点击 **Quit** 你就可以看来类似下图的显示，选中刚刚创建的用来安装Android 的分区，点击**Enter**
|
||||
|
||||
|
||||
选择分区安装Android
|
||||
|
||||
**18.** 选择“**ext3**”作为硬盘文件系统并格式化
|
||||
|
||||
|
||||
选择Ext3分区类型
|
||||
|
||||
|
||||
格式化分区
|
||||
|
||||
**19.** 它将会询问你时候需要安装GRUB启动器，当然选择**Yes**，如果不这样，你将不能启动新系统，所以选择**Yes**并点击**Enter**
|
||||
|
||||
|
||||
安装引导加载器 GRUB
|
||||
|
||||
**20.** 最后，它会问你**/system**分区是否能写入，选择yes，它会在安装完系统后帮助你减少很多麻烦
|
||||
|
||||
|
||||
使分区能写入
|
||||
|
||||
**21.** 安装将会开始它的任务，安装器结束工作后，选择重启，在我做测试的时候，“Run-Android x86”不起作用，所以你不得不重启。
|
||||
|
||||
|
||||
Android Kit kat 安装完成
|
||||
|
||||
**22.** 我们已经安装完成**Android 4.4 KitKat RC2**，问题是VirtualBox将会继续引导**.iso**镜像文件而不是虚拟设备，所以为了修正这个问题，**设置** -> **存储** ->移除iso文件
|
||||
|
||||
|
||||
移除Android Kit Kat 镜像
|
||||
|
||||
**23.** 你可以启动你的虚拟设备，运行你的Android系统了
|
||||
|
||||
|
||||
启动Android Kit Kat 系统
|
||||
|
||||
|
||||
Android标志界面
|
||||
|
||||
**24.** 使用**Android**之前，你需要完成一个向导来配置一些事。你会看见如下屏幕，现在问题是，鼠标不能在**android 4.4 kitkat**工作，这意味着我们需要展示我们键盘的高超技巧了。首先，选择语言，你需要使用键盘**上**键和**下**键，到下一步，需要使用**右**键移动光标，选择**Enter**
|
||||
|
||||
|
||||
Android 欢迎界面
|
||||
|
||||
|
||||
选择WiFi网络
|
||||
|
||||
|
||||
创建Android Google账户
|
||||
|
||||
|
||||
注册Google账户
|
||||
|
||||
|
||||
设置日期和时间
|
||||
|
||||
|
||||
输入你的信息
|
||||
|
||||
|
||||
Android 4.4 Kit Kat 主界面
|
||||
|
||||
|
||||
安装 **Android x86**好处颇多，如果你没有智能手机而又想早点使用**Play Store**apps，怎么不试试安装android x86呢？结果怎样？你有想过android可以成为一个针对桌面功能的**实时操作系统**？
|
||||
|
||||
----------
|
||||
|
||||
|
||||
|
||||
[Hanny Helal][3]
|
||||
|
||||
2010年，成为Linux和自由软件用户，已为自由软件贡献多个项目
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/install-android-kitkat-in-linux/
|
||||
|
||||
译者：[Vic___](http://www.vicyu.net) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://www.tecmint.com/install-virtualbox-on-redhat-centos-fedora/
|
||||
[2]:http://sourceforge.net/projects/android-x86/
|
||||
[3]:http://www.tecmint.com/
|
||||
Loading…
Reference in New Issue
Block a user