mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge branch 'master' of https://github.com/LCTT/TranslateProject
Merge from LCTT.
This commit is contained in:
runningwater
commit
1f84a54230
@ -0,0 +1,162 @@
|
||||
网络与安全方面的最佳开源软件
|
||||
================================================================================
|
||||
InfoWorld 在部署、运营和保障网络安全领域精选出了年度开源工具获奖者。
|
||||
|
||||
|
||||
|
||||
### 最佳开源网络和安全软件 ###
|
||||
|
||||
[BIND](https://en.wikipedia.org/wiki/BIND), [Sendmail](https://en.wikipedia.org/wiki/Sendmail), [OpenSSH](https://en.wikipedia.org/wiki/OpenSSH), [Cacti](https://en.wikipedia.org/wiki/Cactus), [Nagios](https://en.wikipedia.org/wiki/Nagios), [Snort](https://en.wikipedia.org/wiki/Snort_%28software%29) -- 这些为了网络而生的开源软件，好些家伙们老而弥坚。今年在这个范畴的最佳选择中，你会发现中坚、支柱、新人和新贵云集，他们正在完善网络管理，安全监控，漏洞评估，[rootkit](https://en.wikipedia.org/wiki/Rootkit) 检测，以及很多方面。
|
||||
|
||||
|
||||
|
||||
### Icinga 2 ###
|
||||
|
||||
Icinga 起先只是系统监控应用 Nagios 的一个衍生分支。[Icinga 2][1] 经历了完全的重写，为用户带来了时尚的界面、对多数据库的支持，以及一个集成了众多扩展的 API。凭借着开箱即用的负载均衡、通知和配置文件，Icinga 2 缩短了在复杂环境下安装的时间。Icinga 2 原生支持 [Graphite](https://github.com/graphite-project/graphite-web)（系统监控应用），轻松为管理员呈现实时性能图表。不过真的让 Icinga 今年重新火起来的原因是 Icinga Web 2 的发布，那是一个支持可拖放定制的 仪表盘 和一些流式监控工具的前端图形界面系统。
|
||||
|
||||
管理员可以查看、过滤、并按优先顺序排列发现的问题，同时可以跟踪已经采取的动作。一个新的矩阵视图使管理员能够在单一页面上查看主机和服务。你可以通过查看特定时间段的事件或筛选事件类型来了解哪些事件需要立即关注。虽然 Icinga Web 2 有着全新界面和更为强劲的性能，不过对于传统版 Icinga 和 Web 版 Icinga 的所有常用命令还是照旧支持的。这意味着学习新版工具不耗费额外的时间。
|
||||
|
||||
-- Fahmida Rashid
|
||||
|
||||
|
||||
|
||||
### Zenoss Core ###
|
||||
|
||||
这是另一个强大的开源软件，[Zenoss Core][2] 为网络管理员提供了一个完整的、一站式解决方案来跟踪和管理所有的应用程序、服务器、存储、网络组件、虚拟化工具、以及企业基础架构的其他元素。管理员可以确保硬件的运行效率并利用 ZenPacks 中模块化设计的插件来扩展功能。
|
||||
|
||||
在2015年二月发布的 Zenoss Core 5 保留了已经很强大的工具，并进一步改进以增强用户界面和扩展 仪表盘。基于 Web 的控制台和 仪表盘 可以高度可定制并动态调整，而现在的新版本还能让管理员混搭多个组件图表到一个图表中。想来这应该是一个更好的根源分析和因果分析的工具。
|
||||
|
||||
Portlets 为网络映射、设备问题、守护进程、产品状态、监视列表和事件视图等等提供了深入的分析。而且新版 HTML5 图表可以从工具导出。Zenoss 的控制中心支持带外管理并且可监控所有 Zenoss 组件。Zenoss Core 现在拥有一些新工具，用于在线备份和恢复、快照和回滚以及多主机部署等方面。更重要的是，凭借对 Docker 的全面支持，部署起来更快了。
|
||||
|
||||
-- Fahmida Rashid
|
||||
|
||||
|
||||
|
||||
### OpenNMS ###
|
||||
|
||||
作为一个非常灵活的网络管理解决方案，[OpenNMS][3] 可以处理任何网络管理任务，无论是设备管理、应用性能监控、库存控制，或事件管理。凭借对 IPv6 的支持、强大的警报系统和记录用户脚本来测试 Web 应用程序的能力，OpenNMS 拥有网络管理员和测试人员需要的一切。OpenNMS 现在变得像一款移动版 仪表盘，称之为 OpenNMS Compass，可让网络专家随时，甚至在外出时都可以监视他们的网络。
|
||||
|
||||
该应用程序的 IOS 版本，可从 [iTunes App Store][4] 上获取，可以显示故障、节点和告警。下一个版本将提供更多的事件细节、资源图表、以及关于 IP 和 SNMP 接口的信息。安卓版可从 [Google Play][5] 上获取，可在 仪表盘 上显示网络可用性，故障和告警，以及可以确认、提升或清除告警。移动客户端与 OpenNMS Horizon 1.12 或更高版本以及 OpenNMS Meridian 2015.1.0 或更高版本兼容。
|
||||
|
||||
-- Fahmida Rashid
|
||||
|
||||
|
||||
|
||||
### Security Onion ###
|
||||
|
||||
如同一个洋葱，网络安全监控是由许多层组成。没有任何一个单一的工具可以让你洞察每一次攻击，为你显示对你的公司网络中的每一次侦查或是会话的足迹。[Security Onion][6] 在一个简单易用的 Ubuntu 发行版中打包了许多久经考验的工具，可以让你看到谁留在你的网络里，并帮助你隔离这些坏家伙。
|
||||
|
||||
无论你是采取主动式的网络安全监测还是追查可能的攻击，Security Onion 都可以帮助你。Onion 由传感器、服务器和显示层组成，结合了基于网络和基于主机的入侵检测，全面的网络数据包捕获，并提供了所有类型的日志以供检查和分析。
|
||||
|
||||
这是一个众星云集的的网络安全工具链，包括用于网络抓包的 [Netsniff-NG](http://www.netsniff-ng.org/)、基于规则的网络入侵检测系统 Snort 和 [Suricata](https://en.wikipedia.org/wiki/Suricata_%28software%29)，基于分析的网络监控系统 Bro，基于主机的入侵检测系统 OSSEC 和用于显示、分析和日志管理的 Sguil、Squert、Snorby 和 ELSA （企业日志搜索和归档（Enterprise Log Search and Archive））。它是一个经过精挑细选的工具集，所有的这些全被打包进一个向导式的安装程序并有完整的文档支持，可以帮助你尽可能快地上手监控。
|
||||
|
||||
-- Victor R. Garza
|
||||
|
||||
|
||||
|
||||
### Kali Linux ###
|
||||
|
||||
[Kali Linux][7] 背后的团队今年为这个流行的安全 Linux 发行版发布了新版本，使其更快，更全能。Kali 采用全新 4.0 版的内核，改进了对硬件和无线驱动程序的支持，并且界面更为流畅。最常用的工具都可从屏幕的侧边栏上轻松找到。而最大的改变是 Kali Linux 现在是一个滚动发行版，具有持续不断的软件更新。Kali 的核心系统是基于 Debian Jessie，而且该团队会不断地从 Debian 测试版拉取最新的软件包，并持续的在上面添加 Kali 风格的新特性。
|
||||
|
||||
该发行版仍然配备了很多的渗透测试，漏洞分析，安全审查，网络应用分析，无线网络评估，逆向工程，和漏洞利用工具。现在该发行版具有上游版本检测系统，当有个别工具可更新时系统会自动通知用户。该发行版还提过了一系列 ARM 设备的镜像，包括树莓派、[Chromebook](https://en.wikipedia.org/wiki/Chromebook) 和 [Odroid](https://en.wikipedia.org/wiki/ODROID)，同时也更新了 Android 设备上运行的 [NetHunter](https://www.kali.org/kali-linux-nethunter/) 渗透测试平台。还有其他的变化：Metasploit 的社区版/专业版不再包括在内，因为 Kali 2.0 还没有 [Rapid7 的官方支持][8]。
|
||||
|
||||
-- Fahmida Rashid
|
||||
|
||||
|
||||
|
||||
### OpenVAS ###
|
||||
|
||||
开放式漏洞评估系统（Open Vulnerability Assessment System） [OpenVAS][9]，是一个整合多种服务和工具来提供漏洞扫描和漏洞管理的软件框架。该扫描器可以使用每周更新一次的网络漏洞测试数据，或者你也可以使用商业服务的数据。该软件框架包括一个命令行界面（以使其可以用脚本调用）和一个带 SSL 安全机制的基于 [Greenbone 安全助手][10] 的浏览器界面。OpenVAS 提供了用于附加功能的各种插件。扫描可以预定运行或按需运行。
|
||||
|
||||
可通过单一的主控来控制多个安装好 OpenVAS 的系统，这使其成为了一个可扩展的企业漏洞评估工具。该项目兼容的标准使其可以将扫描结果和配置存储在 SQL 数据库中，这样它们可以容易地被外部报告工具访问。客户端工具通过基于 XML 的无状态 OpenVAS 管理协议访问 OpenVAS 管理器，所以安全管理员可以扩展该框架的功能。该软件能以软件包或源代码的方式安装在 Windows 或 Linux 上运行，或者作为一个虚拟应用下载。
|
||||
|
||||
-- Matt Sarrel
|
||||
|
||||
|
||||
|
||||
### OWASP ###
|
||||
|
||||
[OWASP][11]（开放式 Web 应用程序安全项目（Open Web Application Security Project））是一个专注于提高软件安全性的在全球各地拥有分会的非营利组织。这个社区性的组织提供测试工具、文档、培训和几乎任何你可以想象到的开发安全软件相关的软件安全评估和最佳实践。有一些 OWASP 项目已成为很多安全从业者工具箱中的重要组件：
|
||||
|
||||
[ZAP][12]（ZED 攻击代理项目（Zed Attack Proxy Project））是一个在 Web 应用程序中寻找漏洞的渗透测试工具。ZAP 的设计目标之一是使之易于使用，以便于那些并非安全领域专家的开发人员和测试人员能便于使用。ZAP 提供了自动扫描和一套手动测试工具集。
|
||||
|
||||
[Xenotix XSS Exploit Framework][13] 是一个先进的跨站点脚本漏洞检测和漏洞利用框架，该框架通过在浏览器引擎内执行扫描以获取真实的结果。Xenotix 扫描模块使用了三个智能模糊器（ intelligent fuzzers），使其可以运行近 5000 种不同的 XSS 有效载荷。它有个 API 可以让安全管理员扩展和定制漏洞测试工具包。
|
||||
|
||||
[O-Saft][14]（OWASP SSL 高级审查工具（OWASP SSL advanced forensic tool））是一个查看 SSL 证书详细信息和测试 SSL 连接的 SSL 审计工具。这个命令行工具可以在线或离线运行来评估 SSL ，比如算法和配置是否安全。O-Saft 内置提供了常见漏洞的检查，你可以容易地通过编写脚本来扩展这些功能。在 2015 年 5 月加入了一个简单的图形用户界面作为可选的下载项。
|
||||
|
||||
[OWTF][15]（攻击性 Web 测试框架（Offensive Web Testing Framework））是一个遵循 OWASP 测试指南和 NIST 和 PTES 标准的自动化测试工具。该框架同时支持 Web 用户界面和命令行，用于探测 Web 和应用服务器的常见漏洞，如配置失当和软件未打补丁。
|
||||
|
||||
-- Matt Sarrel
|
||||
|
||||
|
||||
|
||||
### BeEF ###
|
||||
|
||||
Web 浏览器已经成为用于针对客户端的攻击中最常见的载体。[BeEF][15] （浏览器漏洞利用框架项目（Browser Exploitation Framework Project）），是一种广泛使用的用以评估 Web 浏览器安全性的渗透工具。BeEF 通过浏览器来启动客户端攻击，帮助你暴露出客户端系统的安全弱点。BeEF 建立了一个恶意网站，安全管理员用想要测试的浏览器访问该网站。然后 BeEF 发送命令来攻击 Web 浏览器并使用命令在客户端机器上植入软件。随后管理员就可以把客户端机器看作不设防般发动攻击了。
|
||||
|
||||
BeEF 自带键盘记录器、端口扫描器和 Web 代理这样的常用模块，此外你可以编写你自己的模块或直接将命令发送到被控制的测试机上。BeEF 带有少量的演示网页来帮你快速入门，使得编写更多的网页和攻击模块变得非常简单，让你可以因地适宜的自定义你的测试。BeEF 是一个非常有价值的评估浏览器和终端安全、学习如何发起基于浏览器攻击的测试工具。可以使用它来向你的用户综合演示，那些恶意软件通常是如何感染客户端设备的。
|
||||
|
||||
-- Matt Sarrel
|
||||
|
||||
|
||||
|
||||
### Unhide ###
|
||||
|
||||
[Unhide][16] 是一个用于定位开放的 TCP/UDP 端口和隐藏在 UNIX、Linux 和 Windows 上的进程的审查工具。隐藏的端口和进程可能是由于运行 Rootkit 或 LKM（可加载的内核模块（loadable kernel module）） 导致的。Rootkit 可能很难找到并移除，因为它们就是专门针对隐蔽性而设计的，可以在操作系统和用户前隐藏自己。一个 Rootkit 可以使用 LKM 隐藏其进程或冒充其他进程，让它在机器上运行很长一段时间而不被发现。而 Unhide 则可以使管理员们确信他们的系统是干净的。
|
||||
|
||||
Unhide 实际上是两个单独的脚本：一个用于进程，一个用于端口。该工具查询正在运行的进程、线程和开放的端口并将这些信息与系统中注册的活动比较，报告之间的差异。Unhide 和 WinUnhide 是非常轻量级的脚本，可以运行命令行而产生文本输出。它们不算优美，但是极为有用。Unhide 也包括在 [Rootkit Hunter][17] 项目中。
|
||||
|
||||
-- Matt Sarrel
|
||||
|
||||
|
||||
|
||||
### 查看更多的开源软件优胜者 ###
|
||||
|
||||
InfoWorld 网站的 2015 年最佳开源奖由下至上表扬了 100 多个开源项目。通过以下链接可以查看更多开源软件中的翘楚：
|
||||
|
||||
[2015 Bossie 评选：最佳开源应用程序][18]
|
||||
|
||||
[2015 Bossie 评选：最佳开源应用程序开发工具][19]
|
||||
|
||||
[2015 Bossie 评选：最佳开源大数据工具][20]
|
||||
|
||||
[2015 Bossie 评选：最佳开源数据中心和云计算软件][21]
|
||||
|
||||
[2015 Bossie 评选：最佳开源桌面和移动端软件][22]
|
||||
|
||||
[2015 Bossie 评选：最佳开源网络和安全软件][23]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.infoworld.com/article/2982962/open-source-tools/bossie-awards-2015-the-best-open-source-networking-and-security-software.html
|
||||
|
||||
作者：[InfoWorld staff][a]
|
||||
译者：[robot527](https://github.com/robot527)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.infoworld.com/author/InfoWorld-staff/
|
||||
[1]:https://www.icinga.org/icinga/icinga-2/
|
||||
[2]:http://www.zenoss.com/
|
||||
[3]:http://www.opennms.org/
|
||||
[4]:https://itunes.apple.com/us/app/opennms-compass/id968875097?mt=8
|
||||
[5]:https://play.google.com/store/apps/details?id=com.opennms.compass&hl=en
|
||||
[6]:http://blog.securityonion.net/p/securityonion.html
|
||||
[7]:https://www.kali.org/
|
||||
[8]:https://community.rapid7.com/community/metasploit/blog/2015/08/12/metasploit-on-kali-linux-20
|
||||
[9]:http://www.openvas.org/
|
||||
[10]:http://www.greenbone.net/
|
||||
[11]:https://www.owasp.org/index.php/Main_Page
|
||||
[12]:https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
|
||||
[13]:https://www.owasp.org/index.php/O-Saft
|
||||
[14]:https://www.owasp.org/index.php/OWASP_OWTF
|
||||
[15]:http://www.beefproject.com/
|
||||
[16]:http://www.unhide-forensics.info/
|
||||
[17]:http://www.rootkit.nl/projects/rootkit_hunter.html
|
||||
[18]:http://www.infoworld.com/article/2982622/bossie-awards-2015-the-best-open-source-applications.html
|
||||
[19]:http://www.infoworld.com/article/2982920/bossie-awards-2015-the-best-open-source-application-development-tools.html
|
||||
[20]:http://www.infoworld.com/article/2982429/bossie-awards-2015-the-best-open-source-big-data-tools.html
|
||||
[21]:http://www.infoworld.com/article/2982923/bossie-awards-2015-the-best-open-source-data-center-and-cloud-software.html
|
||||
[22]:http://www.infoworld.com/article/2982630/bossie-awards-2015-the-best-open-source-desktop-and-mobile-software.html
|
||||
[23]:http://www.infoworld.com/article/2982962/bossie-awards-2015-the-best-open-source-networking-and-security-software.html
|
||||
65
published/20151204 Review EXT4 vs. Btrfs vs. XFS.md
Normal file
65
published/20151204 Review EXT4 vs. Btrfs vs. XFS.md
Normal file
@ -0,0 +1,65 @@
|
||||
如何选择文件系统：EXT4、Btrfs 和 XFS
|
||||
================================================================================
|
||||
|
||||
|
||||
老实说，人们最不曾思考的问题之一是他们的个人电脑中使用了什么文件系统。Windows 和 Mac OS X 用户更没有理由去考虑，因为对于他们的操作系统，只有一种选择，那就是 NTFS 和 HFS+。相反，对于 Linux 系统而言，有很多种文件系统可以选择，现在默认的是广泛采用的 ext4。然而，现在也有改用一种称为 btrfs 文件系统的趋势。那是什么使得 btrfs 更优秀，其它的文件系统又是什么，什么时候我们又能看到 Linux 发行版作出改变呢？
|
||||
|
||||
首先让我们对文件系统以及它们真正干什么有个总体的认识，然后我们再对一些有名的文件系统做详细的比较。
|
||||
|
||||
### 文件系统是干什么的？ ###
|
||||
|
||||
如果你不清楚文件系统是干什么的，一句话总结起来也非常简单。文件系统主要用于控制所有程序在不使用数据时如何存储数据、如何访问数据以及有什么其它信息（元数据）和数据本身相关，等等。听起来要编程实现并不是轻而易举的事情，实际上也确实如此。文件系统一直在改进，包括了更多的功能、更高效地完成它需要做的事情。总而言之，它是所有计算机的基本需求、但并不像听起来那么简单。
|
||||
|
||||
### 为什么要分区？ ###
|
||||
|
||||
由于每个操作系统都能创建或者删除分区，很多人对分区都有模糊的认识。Linux 操作系统即便使用标准安装过程，在同一块磁盘上仍使用多个分区，这看起来很奇怪，因此需要一些解释。拥有不同分区的一个主要目的就是为了在灾难发生时能获得更好的数据安全性。
|
||||
|
||||
通过将硬盘划分为分区，数据会被分隔以及重组。当事故发生的时候，只有存储在被损坏分区上的数据会被破坏，很大可能上其它分区的数据能得以保留。这个原因可以追溯到 Linux 操作系统还没有日志文件系统、任何电力故障都有可能导致灾难发生的时候。
|
||||
|
||||
使用分区也考虑到了安全和健壮性原因，因此操作系统部分损坏并不意味着整个计算机就有风险或者会受到破坏。这也是当前采用分区的一个最重要因素。举个例子，用户创建了一些会填满磁盘的脚本、程序或者 web 应用，如果该磁盘只有一个大的分区，如果磁盘满了那么整个系统就不能工作。如果用户把数据保存在不同的分区，那么就只有那个分区会受到影响，而系统分区或者其它数据分区仍能正常运行。
|
||||
|
||||
记住，拥有一个日志文件系统只能在掉电或者和存储设备意外断开连接时提供数据安全性，并不能在文件系统出现坏块或者发生逻辑错误时保护数据。对于这种情况，用户可以采用廉价磁盘冗余阵列（RAID：Redundant Array of Inexpensive Disks）的方案。
|
||||
|
||||
### 为什么要切换文件系统？ ###
|
||||
|
||||
ext4 文件系统由 ext3 文件系统改进而来，而后者又是从 ext2 文件系统改进而来。虽然 ext4 文件系统已经非常稳定，是过去几年中绝大部分发行版的默认选择，但它是基于陈旧的代码开发而来。另外， Linux 操作系统用户也需要很多 ext4 文件系统本身不提供的新功能。虽然通过某些软件能满足这种需求，但性能会受到影响，在文件系统层次做到这些能获得更好的性能。
|
||||
|
||||
### Ext4 文件系统 ###
|
||||
|
||||
ext4 还有一些明显的限制。最大文件大小是 16 tebibytes（大概是 17.6 terabytes），这比普通用户当前能买到的硬盘还要大的多。使用 ext4 能创建的最大卷/分区是 1 exbibyte（大概是 1,152,921.5 terabytes）。通过使用多种技巧， ext4 比 ext3 有很大的速度提升。类似一些最先进的文件系统，它是一个日志文件系统，意味着它会对文件在磁盘中的位置以及任何其它对磁盘的更改做记录。纵观它的所有功能，它还不支持透明压缩、重复数据删除或者透明加密。技术上支持了快照，但该功能还处于实验性阶段。
|
||||
|
||||
### Btrfs 文件系统 ###
|
||||
|
||||
btrfs 有很多不同的叫法，例如 Better FS、Butter FS 或者 B-Tree FS。它是一个几乎完全从头开发的文件系统。btrfs 出现的原因是它的开发者起初希望扩展文件系统的功能使得它包括快照、池化（pooling）、校验以及其它一些功能。虽然和 ext4 无关，它也希望能保留 ext4 中能使消费者和企业受益的功能，并整合额外的能使每个人，尤其是企业受益的功能。对于使用大型软件以及大规模数据库的企业，让多种不同的硬盘看起来一致的文件系统能使他们受益并且使数据整合变得更加简单。删除重复数据能降低数据实际使用的空间，当需要镜像一个单一而巨大的文件系统时使用 btrfs 也能使数据镜像变得简单。
|
||||
|
||||
用户当然可以继续选择创建多个分区从而无需镜像任何东西。考虑到这种情况，btrfs 能横跨多种硬盘，和 ext4 相比，它能支持 16 倍以上的磁盘空间。btrfs 文件系统一个分区最大是 16 exbibytes，最大的文件大小也是 16 exbibytes。
|
||||
|
||||
### XFS 文件系统 ###
|
||||
|
||||
XFS 文件系统是扩展文件系统（extent file system）的一个扩展。XFS 是 64 位高性能日志文件系统。对 XFS 的支持大概在 2002 年合并到了 Linux 内核，到了 2009 年，红帽企业版 Linux 5.4 也支持了 XFS 文件系统。对于 64 位文件系统，XFS 支持最大文件系统大小为 8 exbibytes。XFS 文件系统有一些缺陷，例如它不能压缩，删除大量文件时性能低下。目前RHEL 7.0 文件系统默认使用 XFS。
|
||||
|
||||
### 总结 ###
|
||||
|
||||
不幸的是，还不知道 btrfs 什么时候能到来。官方说，其下一代文件系统仍然被归类为“不稳定”，但是如果用户下载最新版本的 Ubuntu，就可以选择安装到 btrfs 分区上。什么时候 btrfs 会被归类到 “稳定” 仍然是个谜， 直到真的认为它“稳定”之前，用户也不应该期望 Ubuntu 会默认采用 btrfs。有报道说 Fedora 18 会用 btrfs 作为它的默认文件系统，因为到了发布它的时候，应该有了 btrfs 文件系统校验器。由于还没有实现所有的功能，另外和 ext4 相比性能上也比较缓慢，btrfs 还有很多的工作要做。
|
||||
|
||||
那么，究竟使用哪个更好呢？尽管性能几乎相同，但 ext4 还是赢家。为什么呢？答案在于易用性以及广泛性。对于桌面或者工作站， ext4 仍然是一个很好的文件系统。由于它是默认提供的文件系统，用户可以在上面安装操作系统。同时， ext4 支持最大 1 exabytes 的卷和 16 terabytes 的文件，因此考虑到大小，它也还有很大的进步空间。
|
||||
|
||||
btrfs 能提供更大的高达 16 exabytes 的卷以及更好的容错，但是，到现在为止，它感觉更像是一个附加的文件系统，而部署一个集成到 Linux 操作系统的文件系统。比如，尽管 btrfs 支持不同的发行版，使用 btrfs 格式化硬盘之前先要有 btrfs-tools 工具，这意味着安装 Linux 操作系统的时候它并不是一个可选项，即便不同发行版之间会有所不同。
|
||||
|
||||
尽管传输速率非常重要，评价一个文件系统除了文件传输速度之外还有很多因素。btrfs 有很多好用的功能，例如写复制（Copy-on-Write）、扩展校验、快照、清洗、自修复数据、冗余删除以及其它保证数据完整性的功能。和 ZFS 相比 btrfs 缺少 RAID-Z 功能，因此对于 btrfs， RAID 还处于实验性阶段。对于单纯的数据存储，和 ext4 相比 btrfs 似乎更加优秀，但时间会验证一切。
|
||||
|
||||
迄今为止，对于桌面系统而言，ext4 似乎是一个更好的选择，因为它是默认的文件系统，传输文件时也比 btrfs 更快。btrfs 当然值得尝试、但要在桌面 Linux 上完全取代 ext4 可能还需要一些时间。数据场和大存储池会揭示关于 ext4、XCF 以及 btrfs 不同的场景和差异。
|
||||
|
||||
如果你有不同或者其它的观点，在下面的评论框中告诉我们吧。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.unixmen.com/review-ext4-vs-btrfs-vs-xfs/
|
||||
|
||||
作者：[M.el Khamlichi][a]
|
||||
译者：[ictlyh](http://mutouxiaogui.cn/blog/)
|
||||
校对：[Caroline](https://github.com/carolinewuyan)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.unixmen.com/author/pirat9/
|
||||
@ -1,14 +1,16 @@
|
||||
Linux最大版本4.1.18 LTS发布，带来大量修改
|
||||
Linux 4.1 系列的最大版本 4.1.18 LTS发布，带来大量修改
|
||||
=================================================================================
|
||||
（LCTT 译注：这是一则过期的消息，但是为了披露更新内容，还是发布出来给大家参考）
|
||||
|
||||
**著名的内核维护者Greg Kroah-Hartman貌似正在度假中，因为Sasha Levin有幸在今天，2016年2月16日，的早些时候来[宣布](http://lkml.iu.edu/hypermail/linux/kernel/1602.2/00520.html)，第十八个Linux内核维护版本Linux Kernel 4.1 LTS通用版本正式发布。**
|
||||
**著名的内核维护者Greg Kroah-Hartman貌似正在度假中，因为Sasha Levin2016年2月16日的早些时候来[宣布](http://lkml.iu.edu/hypermail/linux/kernel/1602.2/00520.html)，第十八个Linux内核维护版本Linux Kernel 4.1 LTS通用版本正式发布。**
|
||||
|
||||
作为长期支持的内核分支，Linux 4.1将再多几年接收到更新和补丁，而今天的维护构建版本也证明一点，就是内核开发者们正致力于统保持该系列在所有使用该版本的GNU/Linux操作系统上稳定和可靠。Linux Kernel 4.1.18 LTS是一个大规模发行版，它带来了总计达228个文件修改，这些修改包含了多达5304个插入修改和1128个删除修改。
|
||||
作为长期支持的内核分支，Linux 4.1还会在几年内得到更新和补丁，而今天的维护构建版本也证明一点，就是内核开发者们正致力于保持该系列在所有使用该版本的GNU/Linux操作系统上稳定和可靠。Linux Kernel 4.1.18 LTS是一个大的发布版本，它带来了总计达228个文件修改，这些修改包含了多达5304个插入修改和1128个删除修改。
|
||||
|
||||
Linux Kernel 4.1.18 LTS更新了什么呢？好吧，首先是对ARM，ARM64（AArch64），MIPS，PA-RISC，m32r，PowerPC（PPC），s390以及x86等硬件架构的改进。此外，还有对Btrfs，CIFS，NFS，XFS，OCFS2，OverlayFS以及UDF文件系统的加强。对网络堆栈的修复，尤其是对mac80211的修复。同时，还有多核心、加密和mm等方面的改进和对声音的更新。
|
||||
|
||||
“我宣布4.1.18内核正式发布，所有4.1内核系列的用户都应当升级。”Sasha Levin说，“更新的4.1.y git树可以在这里找到：git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.1.y，并且可以在常规kernel.org git网站浏览器：http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary 进行浏览。”
|
||||
## 大量驱动被更新
|
||||
“我宣布4.1.18内核正式发布，所有4.1内核系列的用户都应当升级。”Sasha Levin说，“更新的4.1.y git树可以在这里找到：git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.1.y，并且可以在 kernel.org 的 git 网站上浏览：http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary 进行浏览。”
|
||||
|
||||
### 大量驱动被更新
|
||||
|
||||
除了架构、文件系统、声音、网络、加密、mm和核心内核方面的改进之外，Linux Kernel 4.1.18 LTS更新了各个驱动，以提供更好的硬件支持，特别是像蓝牙、DMA、EDAC、GPU（主要是Radeon和Intel i915）、无限带宽技术、IOMMU、IRQ芯片、MD、MMC、DVB、网络（主要是无线）、PCI、SCSI、USB、散热、暂存和Virtio等此类东西。
|
||||
|
||||
@ -18,9 +20,9 @@ Linux Kernel 4.1.18 LTS更新了什么呢？好吧，首先是对ARM，ARM64（A
|
||||
|
||||
via: http://news.softpedia.com/news/linux-kernel-4-1-18-lts-is-the-biggest-in-the-series-with-hundreds-of-changes-500500.shtml
|
||||
|
||||
作者：[Marius Nestor ][a]
|
||||
作者：[Marius Nestor][a]
|
||||
译者：[GOLinux](https://github.com/GOLinux)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
alim0x translating
|
||||
|
||||
The history of Android
|
||||
================================================================================
|
||||
|
||||
@ -56,4 +58,4 @@ via: http://arstechnica.com/gadgets/2014/06/building-android-a-40000-word-histor
|
||||
[2]:http://arstechnica.com/information-technology/2013/05/hands-on-with-hangouts-googles-new-text-and-video-chat-architecture/
|
||||
[3]:https://developer.android.com/design/patterns/navigation-drawer.html
|
||||
[a]:http://arstechnica.com/author/ronamadeo
|
||||
[t]:https://twitter.com/RonAmadeo
|
||||
[t]:https://twitter.com/RonAmadeo
|
||||
|
||||
@ -1,89 +1,90 @@
|
||||
【Translating by cposture 2016-03-01】
|
||||
* * *
|
||||
|
||||
# GCC-Inline-Assembly-HOWTO
|
||||
# GCC 内联汇编 HOWTO
|
||||
|
||||
v0.1, 01 March 2003.
|
||||
* * *
|
||||
|
||||
_This HOWTO explains the use and usage of the inline assembly feature provided by GCC. There are only two prerequisites for reading this article, and that’s obviously a basic knowledge of x86 assembly language and C._
|
||||
_本 HOWTO 文档将讲解 GCC 提供的内联汇编特性的用途和用法。对于阅读这篇文章，这里只有两个前提要求，很明显，就是 x86 汇编语言和 C 语言的基本认识。_
|
||||
|
||||
* * *
|
||||
|
||||
## 1. Introduction.
|
||||
## 1. 简介
|
||||
|
||||
## 1.1 Copyright and License.
|
||||
## 1.1 版权许可
|
||||
|
||||
Copyright (C)2003 Sandeep S.
|
||||
|
||||
This document is free; you can redistribute and/or modify this under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
|
||||
本文档自由共享；你可以重新发布它，并且/或者在遵循自由软件基金会发布的 GNU 通用公共许可证下修改它；或者该许可证的版本 2 ，或者（按照你的需求）更晚的版本。
|
||||
|
||||
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
|
||||
发布这篇文档是希望它能够帮助别人，但是没有任何保证；甚至不包括可售性和适用于任何特定目的的保证。关于更详细的信息，可以查看 GNU 通用许可证。
|
||||
|
||||
## 1.2 Feedback and Corrections.
|
||||
## 1.2 反馈校正
|
||||
|
||||
Kindly forward feedback and criticism to [Sandeep.S](mailto:busybox@sancharnet.in). I will be indebted to anybody who points out errors and inaccuracies in this document; I shall rectify them as soon as I am informed.
|
||||
请将反馈和批评一起提交给 [Sandeep.S](mailto:busybox@sancharnet.in) 。我将感谢任何一个指出本文档中错误和不准确之处的人；一被告知，我会马上改正它们。
|
||||
|
||||
## 1.3 Acknowledgments.
|
||||
## 1.3 致谢
|
||||
|
||||
I express my sincere appreciation to GNU people for providing such a great feature. Thanks to Mr.Pramode C E for all the helps he did. Thanks to friends at the Govt Engineering College, Trichur for their moral-support and cooperation, especially to Nisha Kurur and Sakeeb S. Thanks to my dear teachers at Govt Engineering College, Trichur for their cooperation.
|
||||
我对提供如此棒的特性的 GNU 人们表示真诚的感谢。感谢 Mr.Pramode C E 所做的所有帮助。感谢在 Govt Engineering College 和 Trichur 的朋友们的精神支持和合作，尤其是 Nisha Kurur 和 Sakeeb S 。 感谢在 Gvot Engineering College 和 Trichur 的老师们的合作。
|
||||
|
||||
Additionally, thanks to Phillip, Brennan Underwood and colin@nyx.net; Many things here are shamelessly stolen from their works.
|
||||
另外，感谢 Phillip , Brennan Underwood 和 colin@nyx.net ；这里的许多东西都厚颜地直接取自他们的工作成果。
|
||||
|
||||
* * *
|
||||
|
||||
## 2. Overview of the whole thing.
|
||||
## 2. 概览
|
||||
|
||||
We are here to learn about GCC inline assembly. What this inline stands for?
|
||||
在这里，我们将学习 GCC 内联汇编。这内联表示的是什么呢？
|
||||
|
||||
We can instruct the compiler to insert the code of a function into the code of its callers, to the point where actually the call is to be made. Such functions are inline functions. Sounds similar to a Macro? Indeed there are similarities.
|
||||
我们可以要求编译器将一个函数的代码插入到调用者代码中函数被实际调用的地方。这样的函数就是内联函数。这听起来和宏差不多？这两者确实有相似之处。
|
||||
|
||||
What is the benefit of inline functions?
|
||||
内联函数的优点是什么呢？
|
||||
|
||||
This method of inlining reduces the function-call overhead. And if any of the actual argument values are constant, their known values may permit simplifications at compile time so that not all of the inline function’s code needs to be included. The effect on code size is less predictable, it depends on the particular case. To declare an inline function, we’ve to use the keyword `inline` in its declaration.
|
||||
这种内联方法可以减少函数调用开销。同时如果所有实参的值为常量，它们的已知值可以在编译期允许简化，因此并非所有的内联函数代码都需要被包含。代码大小的影响是不可预测的，这取决于特定的情况。为了声明一个内联函数，我们必须在函数声明中使用 `inline` 关键字。
|
||||
|
||||
Now we are in a position to guess what is inline assembly. Its just some assembly routines written as inline functions. They are handy, speedy and very much useful in system programming. Our main focus is to study the basic format and usage of (GCC) inline assembly functions. To declare inline assembly functions, we use the keyword `asm`.
|
||||
现在我们正处于一个猜测内联汇编到底是什么的点上。它只不过是一些写为内联函数的汇编程序。在系统编程上，它们方便、快速并且极其有用。我们主要集中学习（GCC）内联汇编函数的基本格式和用法。为了声明内联汇编函数，我们使用 `asm` 关键词。
|
||||
|
||||
Inline assembly is important primarily because of its ability to operate and make its output visible on C variables. Because of this capability, "asm" works as an interface between the assembly instructions and the "C" program that contains it.
|
||||
内联汇编之所以重要，主要是因为它可以操作并且使其输出通过 C 变量显示出来。正是因为此能力， "asm" 可以用作汇编指令和包含它的 C 程序之间的接口。
|
||||
|
||||
* * *
|
||||
|
||||
## 3. GCC Assembler Syntax.
|
||||
## 3. GCC 汇编语法
|
||||
|
||||
GCC, the GNU C Compiler for Linux, uses **AT&T**/**UNIX** assembly syntax. Here we’ll be using AT&T syntax for assembly coding. Don’t worry if you are not familiar with AT&T syntax, I will teach you. This is quite different from Intel syntax. I shall give the major differences.
|
||||
GCC , Linux上的 GNU C 编译器，使用 **AT&T** / **UNIX** 汇编语法。在这里，我们将使用 AT&T 语法 进行汇编编码。如果你对 AT&T 语法不熟悉的话，请不要紧张，我会教你的。AT&T 语法和 Intel 语法的差别很大。我会给出主要的区别。
|
||||
|
||||
1. Source-Destination Ordering.
|
||||
1. 源操作数和目的操作数顺序
|
||||
|
||||
The direction of the operands in AT&T syntax is opposite to that of Intel. In Intel syntax the first operand is the destination, and the second operand is the source whereas in AT&T syntax the first operand is the source and the second operand is the destination. ie,
|
||||
AT&T 语法的操作数方向和 Intel 语法的刚好相反。在Intel 语法中，第一操作数为目的操作数，第二操作数为源操作数，然而在 AT&T 语法中，第一操作数为源操作数，第二操作数为目的操作数。也就是说，
|
||||
|
||||
"Op-code dst src" in Intel syntax changes to
|
||||
Intel 语法中的 "Op-code dst src" 变为
|
||||
|
||||
AT&T 语法中的 "Op-code src dst"。
|
||||
|
||||
"Op-code src dst" in AT&T syntax.
|
||||
2. 寄存器命名
|
||||
|
||||
2. Register Naming.
|
||||
寄存器名称有 % 前缀，即如果必须使用 eax，它应该用作 %eax。
|
||||
|
||||
Register names are prefixed by % ie, if eax is to be used, write %eax.
|
||||
3. 立即数
|
||||
|
||||
3. Immediate Operand.
|
||||
AT&T 立即数以 ’$’ 为前缀。静态 "C" 变量 也使用 ’$’ 前缀。在 Intel 语法中，十六进制常量以 ’h’ 为后缀，然而AT&T不使用这种语法，这里我们给常量添加前缀 ’0x’。所以，对于十六进制，我们首先看到一个 ’$’，然后是 ’0x’，最后才是常量。
|
||||
|
||||
AT&T immediate operands are preceded by ’$’. For static "C" variables also prefix a ’$’. In Intel syntax, for hexadecimal constants an ’h’ is suffixed, instead of that, here we prefix ’0x’ to the constant. So, for hexadecimals, we first see a ’$’, then ’0x’ and finally the constants.
|
||||
4. 操作数大小
|
||||
|
||||
4. Operand Size.
|
||||
在 AT&T 语法中，存储器操作数的大小取决于操作码名字的最后一个字符。操作码后缀 ’b’ 、’w’、’l’分别指明了字节（byte）（8位）、字（word）（16位）、长型（long）（32位）存储器引用。Intel 语法通过给存储器操作数添加’byte ptr’、 ’word ptr’ 和 ’dword ptr’前缀来实现这一功能。
|
||||
|
||||
In AT&T syntax the size of memory operands is determined from the last character of the op-code name. Op-code suffixes of ’b’, ’w’, and ’l’ specify byte(8-bit), word(16-bit), and long(32-bit) memory references. Intel syntax accomplishes this by prefixing memory operands (not the op-codes) with ’byte ptr’, ’word ptr’, and ’dword ptr’.
|
||||
因此，Intel的 "mov al, byte ptr foo" 在 AT&T 语法中为 "movb foo, %al"。
|
||||
|
||||
Thus, Intel "mov al, byte ptr foo" is "movb foo, %al" in AT&T syntax.
|
||||
5. 存储器操作数
|
||||
|
||||
在 Intel 语法中，基址寄存器包含在 ’[’ 和 ’]’ 中，然而在 AT&T 中，它们变为 ’(’ 和 ’)’。另外，在 Intel 语法中， 间接内存引用为
|
||||
|
||||
5. Memory Operands.
|
||||
section:[base + index*scale + disp], 在 AT&T中变为
|
||||
|
||||
In Intel syntax the base register is enclosed in ’[’ and ’]’ where as in AT&T they change to ’(’ and ’)’. Additionally, in Intel syntax an indirect memory reference is like
|
||||
section:disp(base, index, scale)。
|
||||
|
||||
section:[base + index*scale + disp], which changes to
|
||||
需要牢记的一点是，当一个常量用于 disp 或 scale，不能添加’$’前缀。
|
||||
|
||||
section:disp(base, index, scale) in AT&T.
|
||||
|
||||
One point to bear in mind is that, when a constant is used for disp/scale, ’$’ shouldn’t be prefixed.
|
||||
|
||||
Now we saw some of the major differences between Intel syntax and AT&T syntax. I’ve wrote only a few of them. For a complete information, refer to GNU Assembler documentations. Now we’ll look at some examples for better understanding.
|
||||
现在我们看到了 Intel 语法和 AT&T 语法之间的一些主要差别。我仅仅写了它们差别的一部分而已。关于更完整的信息，请参考 GNU 汇编文档。现在为了更好地理解，我们可以看一些示例。
|
||||
|
||||
> `
|
||||
>
|
||||
@ -107,29 +108,29 @@ Now we saw some of the major differences between Intel syntax and AT&T syntax. I
|
||||
|
||||
* * *
|
||||
|
||||
## 4. Basic Inline.
|
||||
## 4. 基本内联
|
||||
|
||||
The format of basic inline assembly is very much straight forward. Its basic form is
|
||||
基本内联汇编的格式非常直接了当。它的基本格式为
|
||||
|
||||
`asm("assembly code");`
|
||||
`asm("汇编代码");`
|
||||
|
||||
Example.
|
||||
示例
|
||||
|
||||
> `
|
||||
>
|
||||
> * * *
|
||||
>
|
||||
> <pre>asm("movl %ecx %eax"); /* moves the contents of ecx to eax */
|
||||
> __asm__("movb %bh (%eax)"); /*moves the byte from bh to the memory pointed by eax */
|
||||
> <pre>asm("movl %ecx %eax"); /* 将 ecx 寄存器的内容移至 eax */
|
||||
> __asm__("movb %bh (%eax)"); /* 将 bh 的一个字节数据 移至 eax 寄存器指向的内存 */
|
||||
> </pre>
|
||||
>
|
||||
> * * *
|
||||
>
|
||||
> `
|
||||
|
||||
You might have noticed that here I’ve used `asm` and `__asm__`. Both are valid. We can use `__asm__` if the keyword `asm` conflicts with something in our program. If we have more than one instructions, we write one per line in double quotes, and also suffix a ’\n’ and ’\t’ to the instruction. This is because gcc sends each instruction as a string to **as**(GAS) and by using the newline/tab we send correctly formatted lines to the assembler.
|
||||
你可能注意到了这里我使用了 `asm ` 和 `__asm__`。这两者都是有效的。如果关键词 `asm` 和我们程序的一些标识符冲突了，我们可以使用 `__asm__`。如果我们的指令多余一条，我们可以写成一行，并用括号括起，也可以为每条指令添加 ’\n’ 和 ’\t’ 后缀。这是因为gcc将每一条当作字符串发送给 **as**（GAS）（ GAS 即 GNU 汇编器 ——译者注），并且通过使用换行符/制表符发送正确地格式化行给汇编器。
|
||||
|
||||
Example.
|
||||
示例
|
||||
|
||||
> `
|
||||
>
|
||||
@ -145,22 +146,22 @@ Example.
|
||||
>
|
||||
> `
|
||||
|
||||
If in our code we touch (ie, change the contents) some registers and return from asm without fixing those changes, something bad is going to happen. This is because GCC have no idea about the changes in the register contents and this leads us to trouble, especially when compiler makes some optimizations. It will suppose that some register contains the value of some variable that we might have changed without informing GCC, and it continues like nothing happened. What we can do is either use those instructions having no side effects or fix things when we quit or wait for something to crash. This is where we want some extended functionality. Extended asm provides us with that functionality.
|
||||
如果在代码中，我们涉及到一些寄存器（即改变其内容），但在没有固定这些变化的情况下从汇编中返回，这将会导致一些不好的事情。这是因为 GCC 并不知道寄存器内容的变化，这会导致问题，特别是当编译器做了某些优化。在没有告知 GCC 的情况下，它将会假设一些寄存器存储了我们可能已经改变的变量的值，它会像什么事都没发生一样继续运行（什么事都没发生一样是指GCC不会假设寄存器装入的值是有效的，当退出改变了寄存器值的内联汇编后，寄存器的值不会保存到相应的变量或内存空间 ——译者注）。我们所可以做的是使用这些没有副作用的指令，或者当我们退出时固定这些寄存器，或者等待程序崩溃。这是为什么我们需要一些扩展功能。扩展汇编正好给我们提供了那样的功能。
|
||||
|
||||
* * *
|
||||
|
||||
## 5. Extended Asm.
|
||||
## 5. 扩展汇编
|
||||
|
||||
In basic inline assembly, we had only instructions. In extended assembly, we can also specify the operands. It allows us to specify the input registers, output registers and a list of clobbered registers. It is not mandatory to specify the registers to use, we can leave that head ache to GCC and that probably fit into GCC’s optimization scheme better. Anyway the basic format is:
|
||||
在基本内联汇编中，我们只有指令。然而在扩展汇编中，我们可以同时指定操作数。它允许我们指定输入寄存器、输出寄存器以及修饰寄存器列表。GCC 不强制用户必须指定使用的寄存器。我们可以把头疼的事留给 GCC ，这可能可以更好地适应 GCC 的优化。不管怎樣，基本格式为：
|
||||
|
||||
> `
|
||||
>
|
||||
> * * *
|
||||
>
|
||||
> <pre> asm ( assembler template
|
||||
> : output operands /* optional */
|
||||
> : input operands /* optional */
|
||||
> : list of clobbered registers /* optional */
|
||||
> <pre> asm ( 汇编程序模板
|
||||
> : 输出操作数 /* 可选的 */
|
||||
> : 输入操作数 /* 可选的 */
|
||||
> : 修饰寄存器列表 /* 可选的 */
|
||||
> );
|
||||
> </pre>
|
||||
>
|
||||
@ -168,11 +169,11 @@ In basic inline assembly, we had only instructions. In extended assembly, we can
|
||||
>
|
||||
> `
|
||||
|
||||
The assembler template consists of assembly instructions. Each operand is described by an operand-constraint string followed by the C expression in parentheses. A colon separates the assembler template from the first output operand and another separates the last output operand from the first input, if any. Commas separate the operands within each group. The total number of operands is limited to ten or to the maximum number of operands in any instruction pattern in the machine description, whichever is greater.
|
||||
汇编程序模板由汇编指令组成.每一个操作数由一个操作数约束字符串所描述，其后紧接一个括弧括起的 C 表达式。冒号用于将汇编程序模板和第一个输出操作数分开，另一个（冒号）用于将最后一个输出操作数和第一个输入操作数分开，如果存在的话。逗号用于分离每一个组内的操作数。总操作数的数目限制在10个，或者机器描述中的任何指令格式中的最大操作数数目，以较大者为准。
|
||||
|
||||
If there are no output operands but there are input operands, you must place two consecutive colons surrounding the place where the output operands would go.
|
||||
如果没有输出操作数但存在输入操作数，你必须将两个连续的冒号放置于输出操作数原本会放置的地方周围。
|
||||
|
||||
Example:
|
||||
示例：
|
||||
|
||||
> `
|
||||
>
|
||||
@ -181,7 +182,7 @@ Example:
|
||||
> <pre> asm ("cld\n\t"
|
||||
> "rep\n\t"
|
||||
> "stosl"
|
||||
> : /* no output registers */
|
||||
> : /* 无输出寄存器 */
|
||||
> : "c" (count), "a" (fill_value), "D" (dest)
|
||||
> : "%ecx", "%edi"
|
||||
> );
|
||||
@ -191,7 +192,7 @@ Example:
|
||||
>
|
||||
> `
|
||||
|
||||
Now, what does this code do? The above inline fills the `fill_value` `count` times to the location pointed to by the register `edi`. It also says to gcc that, the contents of registers `eax` and `edi` are no longer valid. Let us see one more example to make things more clearer.
|
||||
现在，这段代码是干什么的？以上的内联汇编是将 `fill_value` 值 连续 `count` 次 拷贝到 寄存器 `edi` 所指位置（每执行stosl一次，寄存器 edi 的值会递增或递减，这取决于是否设置了 direction 标志，因此以上代码实则初始化一个内存块 ——译者注）。 它也告诉 gcc 寄存器 `ecx` 和 `edi` 一直无效（原文为 eax ，但代码修饰寄存器列表中为 ecx，因此这可能为作者的纰漏 ——译者注）。为了使扩展汇编更加清晰，让我们再看一个示例。
|
||||
|
||||
> `
|
||||
>
|
||||
@ -201,9 +202,9 @@ Now, what does this code do? The above inline fills the `fill_value` `count`
|
||||
> int a=10, b;
|
||||
> asm ("movl %1, %%eax;
|
||||
> movl %%eax, %0;"
|
||||
> :"=r"(b) /* output */
|
||||
> :"r"(a) /* input */
|
||||
> :"%eax" /* clobbered register */
|
||||
> :"=r"(b) /* 输出 */
|
||||
> :"r"(a) /* 输入 */
|
||||
> :"%eax" /* 修饰寄存器 */
|
||||
> );
|
||||
> </pre>
|
||||
>
|
||||
@ -211,36 +212,36 @@ Now, what does this code do? The above inline fills the `fill_value` `count`
|
||||
>
|
||||
> `
|
||||
|
||||
Here what we did is we made the value of ’b’ equal to that of ’a’ using assembly instructions. Some points of interest are:
|
||||
这里我们所做的是使用汇编指令使 ’b’ 变量的值等于 ’a’ 变量的值。一些有意思的地方是：
|
||||
|
||||
* "b" is the output operand, referred to by %0 and "a" is the input operand, referred to by %1.
|
||||
* "r" is a constraint on the operands. We’ll see constraints in detail later. For the time being, "r" says to GCC to use any register for storing the operands. output operand constraint should have a constraint modifier "=". And this modifier says that it is the output operand and is write-only.
|
||||
* There are two %’s prefixed to the register name. This helps GCC to distinguish between the operands and registers. operands have a single % as prefix.
|
||||
* The clobbered register %eax after the third colon tells GCC that the value of %eax is to be modified inside "asm", so GCC won’t use this register to store any other value.
|
||||
* "b" 为输出操作数，用 %0 引用，并且 "a" 为输入操作数，用 %1 引用。
|
||||
* "r" 为操作数约束。之后我们会更详细地了解约束（字符串）。目前，"r" 告诉 GCC 可以使用任一寄存器存储操作数。输出操作数约束应该有一个约束修饰符 "=" 。这修饰符表明它是一个只读的输出操作数。
|
||||
* 寄存器名字以两个%为前缀。这有利于 GCC 区分操作数和寄存器。操作数以一个 % 为前缀。
|
||||
* 第三个冒号之后的修饰寄存器 %eax 告诉 GCC %eax的值将会在 "asm" 内部被修改，所以 GCC 将不会使用此寄存器存储任何其他值。
|
||||
|
||||
When the execution of "asm" is complete, "b" will reflect the updated value, as it is specified as an output operand. In other words, the change made to "b" inside "asm" is supposed to be reflected outside the "asm".
|
||||
当 "asm" 执行完毕， "b" 变量会映射到更新的值，因为它被指定为输出操作数。换句话说， "asm" 内 "b" 变量的修改 应该会被映射到 "asm" 外部。
|
||||
|
||||
Now we may look each field in detail.
|
||||
现在，我们可以更详细地看看每一个域。
|
||||
|
||||
## 5.1 Assembler Template.
|
||||
## 5.1 汇编程序模板
|
||||
|
||||
The assembler template contains the set of assembly instructions that gets inserted inside the C program. The format is like: either each instruction should be enclosed within double quotes, or the entire group of instructions should be within double quotes. Each instruction should also end with a delimiter. The valid delimiters are newline(\n) and semicolon(;). ’\n’ may be followed by a tab(\t). We know the reason of newline/tab, right?. Operands corresponding to the C expressions are represented by %0, %1 ... etc.
|
||||
汇编程序模板包含了被插入到 C 程序的汇编指令集。其格式为：每条指令用双引号圈起，或者整个指令组用双引号圈起。同时每条指令应以分界符结尾。有效的分界符有换行符（\n）和逗号（;）。’\n’ 可以紧随一个制表符（\t）。我们应该都明白使用换行符或制表符的原因了吧？和 C 表达式对应的操作数使用 %0、%1 ... 等等表示。
|
||||
|
||||
## 5.2 Operands.
|
||||
## 5.2 操作数
|
||||
|
||||
C expressions serve as operands for the assembly instructions inside "asm". Each operand is written as first an operand constraint in double quotes. For output operands, there’ll be a constraint modifier also within the quotes and then follows the C expression which stands for the operand. ie,
|
||||
C 表达式用作 "asm" 内的汇编指令操作数。作为第一双引号内的操作数约束，写下每一操作数。对于输出操作数，在引号内还有一个约束修饰符，其后紧随一个用于表示操作数的 C 表达式。即，
|
||||
|
||||
"constraint" (C expression) is the general form. For output operands an additional modifier will be there. Constraints are primarily used to decide the addressing modes for operands. They are also used in specifying the registers to be used.
|
||||
"约束字符串"(C 表达式)，它是一个通用格式。对于输出操作数，还有一个额外的修饰符。约束字符串主要用于决定操作数的寻找方式，同时也用于指定使用的寄存器。
|
||||
|
||||
If we use more than one operand, they are separated by comma.
|
||||
如果我们使用的操作数多于一个，那么每一个操作数用逗号隔开。
|
||||
|
||||
In the assembler template, each operand is referenced by numbers. Numbering is done as follows. If there are a total of n operands (both input and output inclusive), then the first output operand is numbered 0, continuing in increasing order, and the last input operand is numbered n-1\. The maximum number of operands is as we saw in the previous section.
|
||||
在汇编程序模板，每个操作数用数字引用。编号方式如下。如果总共有 n 个操作数（包括输入和输出操作数），那么第一个输出操作数编号为 0 ，逐项递增，并且最后一个输入操作数编号为 n - 1 。操作数的最大数目为前一节我们所看到的那样。
|
||||
|
||||
Output operand expressions must be lvalues. The input operands are not restricted like this. They may be expressions. The extended asm feature is most often used for machine instructions the compiler itself does not know as existing ;-). If the output expression cannot be directly addressed (for example, it is a bit-field), our constraint must allow a register. In that case, GCC will use the register as the output of the asm, and then store that register contents into the output.
|
||||
输出操作数表达式必须为左值。输入操作数的要求不像这样严格。它们可以为表达式。扩展汇编特性常常用于编译器自己不知道其存在的机器指令 ;-)。如果输出表达式无法直接寻址（例如，它是一个位域），我们的约束字符串必须给定一个寄存器。在这种情况下，GCC 将会使用该寄存器作为汇编的输出，然后存储该寄存器的内容到输出。
|
||||
|
||||
As stated above, ordinary output operands must be write-only; GCC will assume that the values in these operands before the instruction are dead and need not be generated. Extended asm also supports input-output or read-write operands.
|
||||
正如前面所陈述的一样，普通的输出操作数必须为只写的； GCC 将会假设指令前的操作数值是死的，并且不需要被（提前）生成。扩展汇编也支持输入-输出或者读-写操作数。
|
||||
|
||||
So now we concentrate on some examples. We want to multiply a number by 5\. For that we use the instruction `lea`.
|
||||
所以现在我们来关注一些示例。我们想要求一个数的5次方结果。为了计算该值，我们使用 `lea` 指令。
|
||||
|
||||
> `
|
||||
>
|
||||
@ -256,7 +257,7 @@ So now we concentrate on some examples. We want to multiply a number by 5\. For
|
||||
>
|
||||
> `
|
||||
|
||||
Here our input is in ’x’. We didn’t specify the register to be used. GCC will choose some register for input, one for output and does what we desired. If we want the input and output to reside in the same register, we can instruct GCC to do so. Here we use those types of read-write operands. By specifying proper constraints, here we do it.
|
||||
这里我们的输入为x。我们不指定使用的寄存器。 GCC 将会选择一些输入寄存器，一个输出寄存器，并且做我们期望的事。如果我们想要输入和输出存在于同一个寄存器里，我们可以要求 GCC 这样做。这里我们使用那些读-写操作数类型。这里我们通过指定合适的约束来实现它。
|
||||
|
||||
> `
|
||||
>
|
||||
@ -272,7 +273,7 @@ Here our input is in ’x’. We didn’t specify the register to be used. GCC w
|
||||
>
|
||||
> `
|
||||
|
||||
Now the input and output operands are in the same register. But we don’t know which register. Now if we want to specify that also, there is a way.
|
||||
现在输出和输出操作数位于同一个寄存器。但是我们无法得知是哪一个寄存器。现在假如我们也想要指定操作数所在的寄存器，这里有一种方法。
|
||||
|
||||
> `
|
||||
>
|
||||
@ -288,17 +289,17 @@ Now the input and output operands are in the same register. But we don’t know
|
||||
>
|
||||
> `
|
||||
|
||||
In all the three examples above, we didn’t put any register to the clobber list. why? In the first two examples, GCC decides the registers and it knows what changes happen. In the last one, we don’t have to put `ecx` on the c lobberlist, gcc knows it goes into x. Therefore, since it can know the value of `ecx`, it isn’t considered clobbered.
|
||||
在以上三个示例中，我们并没有添加任何寄存器到修饰寄存器里，为什么？在头两个示例， GCC 决定了寄存器并且它知道发生了什么改变。在最后一个示例，我们不必将 'ecx' 添加到修饰寄存器列表（原文修饰寄存器列表拼写有错，这里已修正 ——译者注）， gcc 知道它表示x。因此，因为它可以知道 `ecx` 的值，它就不被当作修饰的（寄存器）了。
|
||||
|
||||
## 5.3 Clobber List.
|
||||
## 5.3 修饰寄存器列表
|
||||
|
||||
Some instructions clobber some hardware registers. We have to list those registers in the clobber-list, ie the field after the third ’**:**’ in the asm function. This is to inform gcc that we will use and modify them ourselves. So gcc will not assume that the values it loads into these registers will be valid. We shoudn’t list the input and output registers in this list. Because, gcc knows that "asm" uses them (because they are specified explicitly as constraints). If the instructions use any other registers, implicitly or explicitly (and the registers are not present either in input or in the output constraint list), then those registers have to be specified in the clobbered list.
|
||||
一些指令会破坏一些硬件寄存器。我们不得不在修饰寄存器中列出这些寄存器，即汇编函数内第三个 ’**:**’ 之后的域。这可以通知 gcc 我们将会自己使用和修改这些寄存器。所以 gcc 将不会假设存入这些寄存器的值是有效的。我们不用在这个列表里列出输入输出寄存器。因为 gcc 知道 "asm" 使用了它们（因为它们被显式地指定为约束了）。如果指令隐式或显式地使用了任何其他寄存器，（并且寄存器不能出现在输出或者输出约束列表里），那么不得不在修饰寄存器列表中指定这些寄存器。
|
||||
|
||||
If our instruction can alter the condition code register, we have to add "cc" to the list of clobbered registers.
|
||||
如果我们的指令可以修改状态寄存器，我们必须将 "cc" 添加进修饰寄存器列表。
|
||||
|
||||
If our instruction modifies memory in an unpredictable fashion, add "memory" to the list of clobbered registers. This will cause GCC to not keep memory values cached in registers across the assembler instruction. We also have to add the **volatile** keyword if the memory affected is not listed in the inputs or outputs of the asm.
|
||||
如果我们的指令以不可预测的方式修改了内存，那么需要将 "memory" 添加进修饰寄存器列表。这可以使 GCC 不会在汇编指令间保持缓存于寄存器的内存值。如果被影响的内存不在汇编的输入或输出列表中，我们也必须添加 **volatile** 关键词。
|
||||
|
||||
We can read and write the clobbered registers as many times as we like. Consider the example of multiple instructions in a template; it assumes the subroutine _foo accepts arguments in registers `eax` and `ecx`.
|
||||
我们可以按我们的需求多次读写修饰寄存器。考虑一个模板内的多指令示例；它假设子例程 _foo 接受寄存器 `eax` 和 `ecx` 里的参数。
|
||||
|
||||
> `
|
||||
>
|
||||
@ -319,35 +320,36 @@ We can read and write the clobbered registers as many times as we like. Consider
|
||||
|
||||
## 5.4 Volatile ...?
|
||||
|
||||
If you are familiar with kernel sources or some beautiful code like that, you must have seen many functions declared as `volatile` or `__volatile__` which follows an `asm` or `__asm__`. I mentioned earlier about the keywords `asm` and `__asm__`. So what is this `volatile`?
|
||||
如果你熟悉内核源码或者其他像内核源码一样漂亮的代码，你一定见过许多声明为 `volatile` 或者 `__volatile__`的函数，其跟着一个 `asm` 或者 `__asm__`。我之前提过关键词 `asm` 和 `__asm__`。那么什么是 `volatile`呢？
|
||||
|
||||
If our assembly statement must execute where we put it, (i.e. must not be moved out of a loop as an optimization), put the keyword `volatile` after asm and before the ()’s. So to keep it from moving, deleting and all, we declare it as
|
||||
如果我们的汇编语句必须在我们放置它的地方执行（即，不能作为一种优化被移出循环语句），将关键词 `volatile` 放置在 asm 后面，()的前面。因为为了防止它被移动、删除或者其他操作，我们将其声明为
|
||||
|
||||
`asm volatile ( ... : ... : ... : ...);`
|
||||
|
||||
Use `__volatile__` when we have to be verymuch careful.
|
||||
当我们必须非常谨慎时，请使用 `__volatile__`。
|
||||
|
||||
If our assembly is just for doing some calculations and doesn’t have any side effects, it’s better not to use the keyword `volatile`. Avoiding it helps gcc in optimizing the code and making it more beautiful.
|
||||
如果我们的汇编只是用于一些计算并且没有任何副作用，不使用 `volatile` 关键词会更好。不使用 `volatile` 可以帮助 gcc 优化代码并使代码更漂亮。
|
||||
|
||||
In the section `Some Useful Recipes`, I have provided many examples for inline asm functions. There we can see the clobber-list in detail.
|
||||
|
||||
在 `Some Useful Recipes` 一节中，我提供了多个内联汇编函数的例子。这儿我们详细查看修饰寄存器列表。
|
||||
|
||||
* * *
|
||||
|
||||
## 6. More about constraints.
|
||||
## 6. 更多关于约束
|
||||
|
||||
By this time, you might have understood that constraints have got a lot to do with inline assembly. But we’ve said little about constraints. Constraints can say whether an operand may be in a register, and which kinds of register; whether the operand can be a memory reference, and which kinds of address; whether the operand may be an immediate constant, and which possible values (ie range of values) it may have.... etc.
|
||||
到这个时候，你可能已经了解到约束和内联汇编有很大的关联。但我们很少说到约束。约束用于表明一个操作数是否可以位于寄存器和位于哪个寄存器；是否操作数可以为一个内存引用和哪种地址；是否操作数可以为一个立即数和为哪一个可能的值（即值的范围）。它可以有...等等。
|
||||
|
||||
## 6.1 Commonly used constraints.
|
||||
## 6.1 常用约束
|
||||
|
||||
There are a number of constraints of which only a few are used frequently. We’ll have a look at those constraints.
|
||||
在许多约束中，只有小部分是常用的。我们将看看这些约束。
|
||||
|
||||
1. **Register operand constraint(r)**
|
||||
1. **寄存器操作数约束（r）**
|
||||
|
||||
When operands are specified using this constraint, they get stored in General Purpose Registers(GPR). Take the following example:
|
||||
当使用这种约束指定操作数时，它们存储在通用寄存器（GPR）中。请看下面示例：
|
||||
|
||||
`asm ("movl %%eax, %0\n" :"=r"(myval));`
|
||||
|
||||
Here the variable myval is kept in a register, the value in register `eax` is copied onto that register, and the value of `myval` is updated into the memory from this register. When the "r" constraint is specified, gcc may keep the variable in any of the available GPRs. To specify the register, you must directly specify the register names by using specific register constraints. They are:
|
||||
这里，变量 myval 保存在寄存器中，寄存器 eax 的值被复制到该寄存器中，并且myval的值从寄存器更新到了内存。当指定 "r" 约束时， gcc 可以将变量保存在任何可用的 GPR 中。为了指定寄存器，你必须使用特定寄存器约束直接地指定寄存器的名字。它们为：
|
||||
|
||||
> `
|
||||
>
|
||||
@ -365,57 +367,58 @@ There are a number of constraints of which only a few are used frequently. We’
|
||||
>
|
||||
> `
|
||||
|
||||
2. **Memory operand constraint(m)**
|
||||
2. **内存操作数约束（m）**
|
||||
|
||||
When the operands are in the memory, any operations performed on them will occur directly in the memory location, as opposed to register constraints, which first store the value in a register to be modified and then write it back to the memory location. But register constraints are usually used only when they are absolutely necessary for an instruction or they significantly speed up the process. Memory constraints can be used most efficiently in cases where a C variable needs to be updated inside "asm" and you really don’t want to use a register to hold its value. For example, the value of idtr is stored in the memory location loc:
|
||||
当操作数位于内存时，任何对它们的操作将直接发生在内存位置，这与寄存器约束相反，后者首先将值存储在要修改的寄存器中，然后将它写回到内存位置。但寄存器约束通常用于一个指令必须使用它们或者它们可以大大提高进程速度的地方。当需要在 "asm" 内更新一个 C 变量，而又不想使用寄存器去保存它的只，使用内存最为有效。例如， idtr 的值存储于内存位置：
|
||||
|
||||
`asm("sidt %0\n" : :"m"(loc));`
|
||||
|
||||
3. **Matching(Digit) constraints**
|
||||
3. **匹配（数字）约束**
|
||||
|
||||
In some cases, a single variable may serve as both the input and the output operand. Such cases may be specified in "asm" by using matching constraints.
|
||||
在某些情况下，一个变量可能既充当输入操作数，也充当输出操作数。可以通过使用匹配约束在 "asm" 中指定这种情况。
|
||||
|
||||
`asm ("incl %0" :"=a"(var):"0"(var));`
|
||||
|
||||
We saw similar examples in operands subsection also. In this example for matching constraints, the register %eax is used as both the input and the output variable. var input is read to %eax and updated %eax is stored in var again after increment. "0" here specifies the same constraint as the 0th output variable. That is, it specifies that the output instance of var should be stored in %eax only. This constraint can be used:
|
||||
在操作数子节中，我们也看到了一些类似的示例。在这个匹配约束的示例中，寄存器 "%eax" 既用作输入变量，也用作输出变量。 var 输入被读进 %eax ，并且更新的 %eax 再次被存储进 var。这里的 "0" 用于指定与第0个输出变量相同的约束。也就是，它指定 var 输出实例应只被存储在 "%eax" 中。该约束可用于：
|
||||
|
||||
* In cases where input is read from a variable or the variable is modified and modification is written back to the same variable.
|
||||
* In cases where separate instances of input and output operands are not necessary.
|
||||
* 在输入从变量读取或变量修改后，修改被写回同一变量的情况
|
||||
* 在不需要将输入操作数实例和输出操作数实例分开的情况
|
||||
|
||||
The most important effect of using matching restraints is that they lead to the efficient use of available registers.
|
||||
使用匹配约束最重要的意义在于它们可以导致有效地使用可用寄存器。
|
||||
|
||||
Some other constraints used are:
|
||||
其他一些约束：
|
||||
|
||||
1. "m" : A memory operand is allowed, with any kind of address that the machine supports in general.
|
||||
2. "o" : A memory operand is allowed, but only if the address is offsettable. ie, adding a small offset to the address gives a valid address.
|
||||
1. "m" : 允许一个内存操作数使用机器普遍支持的任一种地址。
|
||||
2. "o" : 允许一个内存操作数，但只有当地址是可偏移的。即，该地址加上一个小的偏移量可以得到一个地址。
|
||||
3. "V" : A memory operand that is not offsettable. In other words, anything that would fit the `m’ constraint but not the `o’constraint.
|
||||
4. "i" : An immediate integer operand (one with constant value) is allowed. This includes symbolic constants whose values will be known only at assembly time.
|
||||
5. "n" : An immediate integer operand with a known numeric value is allowed. Many systems cannot support assembly-time constants for operands less than a word wide. Constraints for these operands should use ’n’ rather than ’i’.
|
||||
6. "g" : Any register, memory or immediate integer operand is allowed, except for registers that are not general registers.
|
||||
4. "i" : 允许一个（带有常量）的立即整形操作数。这包括其值仅在汇编时期知道的符号常量。
|
||||
5. "n" : 允许一个带有已知数字的立即整形操作数。许多系统不支持汇编时期的常量，因为操作数少于一个字宽。对于此种操作数，约束应该使用 'n' 而不是'i'。
|
||||
6. "g" : 允许任一寄存器、内存或者立即整形操作数，不包括通用寄存器之外的寄存器。
|
||||
|
||||
Following constraints are x86 specific.
|
||||
|
||||
1. "r" : Register operand constraint, look table given above.
|
||||
2. "q" : Registers a, b, c or d.
|
||||
3. "I" : Constant in range 0 to 31 (for 32-bit shifts).
|
||||
4. "J" : Constant in range 0 to 63 (for 64-bit shifts).
|
||||
5. "K" : 0xff.
|
||||
6. "L" : 0xffff.
|
||||
7. "M" : 0, 1, 2, or 3 (shifts for lea instruction).
|
||||
8. "N" : Constant in range 0 to 255 (for out instruction).
|
||||
9. "f" : Floating point register
|
||||
10. "t" : First (top of stack) floating point register
|
||||
11. "u" : Second floating point register
|
||||
12. "A" : Specifies the `a’ or `d’ registers. This is primarily useful for 64-bit integer values intended to be returned with the `d’ register holding the most significant bits and the `a’ register holding the least significant bits.
|
||||
以下约束为x86特有。
|
||||
|
||||
## 6.2 Constraint Modifiers.
|
||||
1. "r" : 寄存器操作数约束，查看上面给定的表格。
|
||||
2. "q" : 寄存器 a、b、c 或者 d。
|
||||
3. "I" : 范围从 0 到 31 的常量（对于 32 位移位）。
|
||||
4. "J" : 范围从 0 到 63 的常量（对于 64 位移位）。
|
||||
5. "K" : 0xff。
|
||||
6. "L" : 0xffff。
|
||||
7. "M" : 0, 1, 2, or 3 （lea 指令的移位）。
|
||||
8. "N" : 范围从 0 到 255 的常量（对于 out 指令）。
|
||||
9. "f" : 浮点寄存器
|
||||
10. "t" : 第一个（栈顶）浮点寄存器
|
||||
11. "u" : 第二个浮点寄存器
|
||||
12. "A" : 指定 `a` 或 `d` 寄存器。这主要用于想要返回 64 位整形数，使用 `d` 寄存器保存最高有效位和 `a` 寄存器保存最低有效位。
|
||||
|
||||
While using constraints, for more precise control over the effects of constraints, GCC provides us with constraint modifiers. Mostly used constraint modifiers are
|
||||
## 6.2 约束修饰符
|
||||
|
||||
1. "=" : Means that this operand is write-only for this instruction; the previous value is discarded and replaced by output data.
|
||||
2. "&" : Means that this operand is an earlyclobber operand, which is modified before the instruction is finished using the input operands. Therefore, this operand may not lie in a register that is used as an input operand or as part of any memory address. An input operand can be tied to an earlyclobber operand if its only use as an input occurs before the early result is written.
|
||||
当使用约束时，对于更精确的控制超越了约束作用的需求，GCC 给我们提供了约束修饰符。最常用的约束修饰符为：
|
||||
|
||||
The list and explanation of constraints is by no means complete. Examples can give a better understanding of the use and usage of inline asm. In the next section we’ll see some examples, there we’ll find more about clobber-lists and constraints.
|
||||
1. "=" : 意味着对于这条指令，操作数为只写的；旧值会被忽略并被输出数据所替换。
|
||||
2. "&" : 意味着这个操作数为一个早期的改动操作数，其在该指令完成前通过使用输入操作数被修改了。因此，这个操作数不可以位于一个被用作输出操作数或任何内存地址部分的寄存器。如果在旧值被写入之前它仅用作输入而已，一个输入操作数可以为一个早期改动操作数。
|
||||
|
||||
约束的列表和解释是决不完整的。示例可以给我们一个关于内联汇编的用途和用法的更好的理解。在下一节，我们会看到一些示例，在那里我们会发现更多关于修饰寄存器列表的东西。
|
||||
|
||||
* * *
|
||||
|
||||
@ -563,7 +566,6 @@ Now we have covered the basic theory about GCC inline assembly, now we shall con
|
||||
>
|
||||
> * * *
|
||||
>
|
||||
> <pre>#define _syscall3(type,name,type1,arg1,type2,arg2,type3,arg3) \
|
||||
> type name(type1 arg1,type2 arg2,type3 arg3) \
|
||||
> { \
|
||||
> long __res; \
|
||||
|
||||
@ -1,3 +1,4 @@
|
||||
[Translating by cposture 2016-03-12]
|
||||
Best Cloud Services For Linux To Replace Copy
|
||||
===============================================
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
翻译中；by 
|
||||
翻译中；by ![zky001]
|
||||
Top 5 open source command shells for Linux
|
||||
===============================================
|
||||
|
||||
|
||||
@ -1,164 +0,0 @@
|
||||
Martin
|
||||
|
||||
2015 Bossie 评选：最佳开源网络和安全软件
|
||||
================================================================================
|
||||
InfoWorld 在建设网络，运营网络和保障网络安全领域精选出了年度开源工具获奖者。
|
||||
|
||||
|
||||
|
||||
### 最佳开源网络和安全软件 ###
|
||||
|
||||
[BIND](https://en.wikipedia.org/wiki/BIND), [Sendmail](https://en.wikipedia.org/wiki/Sendmail), [OpenSSH](https://en.wikipedia.org/wiki/OpenSSH), [Cacti](https://en.wikipedia.org/wiki/Cactus), [Nagios](https://en.wikipedia.org/wiki/Nagios), [Snort](https://en.wikipedia.org/wiki/Snort_%28software%29) -- 这些为了网络而发明的开源软件，许多老家伙和好东西依然强劲。今年在我们这个范畴的最佳选择中，你会发现中坚支柱，新人，和新贵正在完善网络管理，安全监控，漏洞评估，[rootkit](https://en.wikipedia.org/wiki/Rootkit) 检测，以及更多。
|
||||
|
||||
|
||||
|
||||
### Icinga 2 ###
|
||||
|
||||
Icinga 起先只是系统监控应用 Nagios 的一个分叉。为了给用户一个时尚的界面，对多个数据库的支持，以及一个集成众多扩展的 API，[Icinga 2][1] 被完全重写。凭借开箱即用的负载均衡、通知和配置，Icinga 2 缩短了在复杂环境下的安装时间。Icinga 2 原生支持 [Graphite](https://github.com/graphite-project/graphite-web)（系统监控应用），轻松为管理员呈现实时性能图表。但是 Icinga 今年很火是因为它发布了一个支持可拖放可定制 dashboard 和一些流式监控工具的前端图形界面系统 Icinga Web 2。
|
||||
|
||||
管理员可以查看，过滤，并把问题按优先顺序排好，同时保持跟踪已经进行的动作。一个新的矩阵视图使管理员能够在一个页面上查看主机和服务。您可以查看一个特定时间段的事件或筛选了的事件来了解哪些需要立即关注。Icinga Web 2 能够拥有一个全新界面和更为强劲的性能，然而传统版 Icinga 和 Web 版 Icinga 的所有常用命令仍然可用。这意味着学习新版工具不耗费额外的时间。
|
||||
|
||||
-- Fahmida Rashid
|
||||
|
||||
|
||||
|
||||
### Zenoss Core ###
|
||||
|
||||
另一个强大的开源软件，[Zenoss Core][2] 为网络管理员提供了一个完整的，一站式解决方案来跟踪和管理所有的应用程序、服务器、存储，网络组件、虚拟化工具、以及企业基础架构的其他元素。管理员可以确保硬件的运行效率并利用模块化设计的插件来扩展 ZenPacks 的功能。
|
||||
|
||||
Zenoss Core 5，在今年二月发布，作为已经很强大的工具，并进一步改进以增强用户界面和扩展 dashboard。基于 Web 的控制台和 dashboard 已经是高度可定制的和动态调整的，现在新版本可让管理员混搭多个组件图表到一个图表。可把它作为一种更好的根源分析和因果分析的工具。
|
||||
|
||||
Portlets 为网络映射、设备问题、守护进程、产品状态、监视列表和事件视图等等提供深入的分析。而且新的 HTML5 图表可以从工具导出。Zenoss 的控制中心支持带外管理并且可监控所有 Zenoss 组件。Zenoss Core 拥有在线备份和恢复、快照和回滚和多主机部署的新工具。更重要的是，凭借对 Docker 的全面支持，部署起来更快了。
|
||||
|
||||
-- Fahmida Rashid
|
||||
|
||||
|
||||
|
||||
### OpenNMS ###
|
||||
|
||||
一个非常灵活的网络管理解决方案，[OpenNMS][3] 可以处理任何网络管理任务，无论是设备管理，应用性能监控，库存控制，或事件管理。凭借对 IPv6 的支持，强大的警报系统，和记录用户脚本来测试 Web 应用程序的能力，OpenNMS 拥有网络管理员和测试人员需要的一切。OpenNMS 现在变得像一款移动 dashboard，堪称 OpenNMS 指南针，可让网络专家随时，甚至当他们外出时都可以监视他们的网络。
|
||||
|
||||
该应用程序的 IOS 版本，可从 [iTunes App Store][4] 上获取，显示故障、节点和告警。下一个版本将提供更多的事件细节、资源图表、以及关于 IP 和 SNMP 接口的信息。安卓版可从 [Google Play][5] 上获取，可在仪表板上显示网络可用性，故障和告警，以及确认、提升或清除告警的能力。移动客户端与 OpenNMS Horizon 1.12 或更高版本以及 OpenNMS Meridian 2015.1.0 或更高版本兼容。
|
||||
|
||||
-- Fahmida Rashid
|
||||
|
||||
|
||||
|
||||
### Security Onion ###
|
||||
|
||||
如同一个洋葱，网络安全监控是由许多层组成。没有单一的工具会使你洞察在你公司网络中的每次攻击，或者显示每一次侦查或文本会话给你。[Security Onion][6] 打包了许多经过验证的工具成为一个便于使用的 Ubuntu 发行版，这会让你看到谁留在你的网络里，并帮助你隔离坏家伙。
|
||||
|
||||
无论你是采取主动式的网络安全监测还是追查可能的攻击，Security Onion 都可以帮助你。由传感器、服务器和显示层组成，Onion 结合了基于网络和基于主机的入侵检测，全面的网络数据包捕获，并提供了所有的各种日志进行检查和分析。
|
||||
|
||||
众星云集的的网络安全工具链，包括用于网络抓包的 [Netsniff-NG](http://www.netsniff-ng.org/)、基于规则的网络入侵检测系统 Snort 和 [Suricata](https://en.wikipedia.org/wiki/Suricata_%28software%29)，基于分析的网络监控系统 Bro，基于主机的入侵检测系统 OSSEC 和用于显示、分析和日志管理的 Sguil、Squert、Snorby 和 ELSA （企业日志搜索和归档）。它是一个经过精挑细选的工具集，全被打包进一个向导驱动式的安装程序并有完整的文档支持，可以帮助你尽可能快地进行监控。
|
||||
|
||||
-- Victor R. Garza
|
||||
|
||||
|
||||
|
||||
Kali Linux
|
||||
|
||||
[Kali Linux][7] 背后的团队修改了今年流行的安全 Linux 发行版，使其更快，更全能。Kali 采用全新 4.0 版的内核 ，改进了对硬件和无线驱动程序的支持，以及一个更流畅的界面。最流行的工具都可从屏幕的侧边栏上轻松访问。最大的改变？Kali Linux 现在是一个滚动发行版，具有连续的软件更新。Kali 的核心系统是基于 Debian Jessie 发行版，而且该团队会不断地从 Debian 测试版 pull 程序包，同时持续在上面添加新的 Kali 风格的特性。
|
||||
|
||||
该发行版仍然配备满了渗透测试，漏洞分析，安全审查，网络应用分析，无线网络评估，逆向工程，和漏洞利用工具。现在该发行版具有新版本检测系统，当有个别工具可更新时系统会自动通知用户。该发行版还具有一系列设备的 ARM 映像，包括树莓派、[Chromebook](https://en.wikipedia.org/wiki/Chromebook) 和 [Odroid](https://en.wikipedia.org/wiki/ODROID)，也可更新在 Android 设备上运行的 [NetHunter](https://www.kali.org/kali-linux-nethunter/) 渗透测试平台。还有其他的变化：Metasploit 的社区版/专业版不再包括在内，因为 Kali 2.0 还没有 [Rapid7 的官方支持][8]。
|
||||
|
||||
-- Fahmida Rashid
|
||||
|
||||
|
||||
|
||||
### OpenVAS ###
|
||||
|
||||
[OpenVAS][9]，开源漏洞评估系统，是一种整合多种服务和工具来提供漏洞扫描和漏洞管理的软件框架。该扫描器与每周一次的网络漏洞测试数据配合，或者您可以使用商业数据。该软件框架包括一个命令行界面（所以它可以用脚本运行）和一个带 SSL 安全机制的基于 [Greenbone 安全助手][10] 的浏览器界面。OpenVAS 提供了用于附加功能的各种插件。扫描可以预定运行或按需运行。
|
||||
|
||||
可通过单一的主控来控制多个 OpenVAS 的安装，使得它成为一个可扩展的企业漏洞评估工具。该项目与兼容这样的标准：扫描结果和配置存储在 SQL 数据库中，在那里他们可以容易地被外部报告工具访问。客户端工具通过基于 XML 的无状态 OpenVAS 管理协议访问 OpenVAS 管理器，所以安全管理员可以扩展该框架的功能。该软件能以包或源代码的方式安装在 Windows 或 Linux 上运行，或者作为一个虚拟设备被下载。
|
||||
|
||||
-- Matt Sarrel
|
||||
|
||||
|
||||
|
||||
### OWASP ###
|
||||
|
||||
[OWASP][11]，开放的 Web 应用安全项目，是专注于提高软件安全性的全球协会的非营利组织。社区性组织提供测试工具、文档、培训和几乎任何你可以想象的评估软件安全和开发安全软件相关的最佳实践。有几个 OWASP 项目已成为很多安全从业者的工具箱中有价值的组件：
|
||||
|
||||
[ZAP][12]，ZED 攻击代理项目，是一个在 Web 应用程序中寻找漏洞的渗透测试工具。ZAP 的设计目标之一是使之易于使用，以便于开发人员和非安全专家的测试人员可以受益于使用它。ZAP 提供了自动扫描器和一套手动测试工具。
|
||||
|
||||
[Xenotix XSS Exploit Framework][13] 是一款运行浏览器引擎内的扫描来获得实际结果的先进的跨站脚本漏洞检测和漏洞利用框架。Xenotix 扫描器模块采用三个智能的 fuzzer，它可以运行近 5000 个不同的XSS有效载荷。一个 API 可以让安全管理员扩展和定制开发工具包。
|
||||
|
||||
[O-Saft][14]，OWASP SSL 高级审查工具，一个查看 SSL 证书详细信息和测试 SSL 连接的 SSL 审计工具。这个命令行工具可以在线或离线运行来评估 SSL 安全性，比如密码和配置。O-Saft 提供了常见漏洞的内置检查，你可以容易地通过编写脚本来扩展这些功能。在 2015 年 5 月加入了一个简单的图形用户界面作为可选的下载项。
|
||||
|
||||
[OWTF][15]，攻击性的 Web 测试框架，一个遵循 OWASP 测试指南和 NIST 和 PTES 标准的自动化测试工具。该框架使用一个 Web 用户界面和一个命令行，它探测 Web 和应用服务器常见漏洞，如配置不当和未打补丁的软件。
|
||||
|
||||
-- Matt Sarrel
|
||||
|
||||
|
||||
|
||||
### BeEF ###
|
||||
|
||||
Web 浏览器已经成为用于针对客户端的攻击中最常见的载体。[BeEF][15] 浏览器漏洞利用框架项目，是一种广泛使用的用以评估 Web 浏览器安全性的渗透工具。BeEF 帮助你揭露客户端系统的安全弱点，通过启动浏览器来进行客户端攻击。BeEF 建立了一个恶意网站，安全管理员用想要测试的浏览器访问该网站。然后 BeEF 发送命令来攻击 Web 浏览器并使用命令在客户端机器上植入软件。如果他们是僵尸机 ，管理员可以对客户端机器发动攻击。
|
||||
|
||||
BeEF 自带像键盘记录器，一个端口扫描器，和 Web 代理这样的常用模块，此外你可以编写你自己的模块或直接将命令发送到僵尸测试机。BeEF 带有少量的演示网页来帮你快速入门使得编写额外的网页和攻击模块很简单，因此你可以自定义测试你的环境。BeEF 是一个评估浏览器和终端安全、学习如何发起基于浏览器的攻击的宝贵的测试工具。可使用它来展示恶意软件通常如何感染客户端设备的演示给你的用户。
|
||||
|
||||
-- Matt Sarrel
|
||||
|
||||
|
||||
|
||||
### Unhide ###
|
||||
|
||||
[Unhide][16] 是一个定位开放的 TCP/UDP 端口和隐藏在 UNIX、Linux 和 Windows 上的进程的审查工具。隐藏的端口和进程可以是 rootkit 或 LKM（可加载的内核模块）activity 的结果。rootkit 可能很难找到并移除，因为它们被设计成隐蔽的，对操作系统和用户隐藏自己。一个 rootkit 可以使用内核模块隐藏其进程或冒充其他进程，让它在机器上运行很长一段时间而不被发现。Unhide 可以保证管理员需要的干净系统。
|
||||
|
||||
Unhide 实际上是两个单独的脚本：一个用于进程，一个用于端口。该工具查询正在运行的进程、线程和开放的端口并将这些信息与系统中注册的活动比较，报告之间的差异。Unhide 和 WinUnhide 是在运行命令行产生文本输出的非常轻量级的脚本。它们不算优美，但是极为有用。Unhide 还列入了 [Rootkit Hunter][17] 项目中。
|
||||
|
||||
-- Matt Sarrel
|
||||
|
||||
|
||||
|
||||
查看更多的开源软件优胜者
|
||||
|
||||
InfoWorld 网站的 2014 年最佳开源奖从堆栈底部到顶部庆祝了 100 多个开源项目。以下链接指向更多开源软件优胜者：
|
||||
|
||||
[2015 Bossie 评选：最佳开源应用程序][18]
|
||||
|
||||
[2015 Bossie 评选：最佳开源应用程序开发工具][19]
|
||||
|
||||
[2015 Bossie 评选：最佳开源大数据工具][20]
|
||||
|
||||
[2015 Bossie 评选：最佳开源数据中心和云计算软件][21]
|
||||
|
||||
[2015 Bossie 评选：最佳开源桌面和移动端软件][22]
|
||||
|
||||
[2015 Bossie 评选：最佳开源网络和安全软件][23]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.infoworld.com/article/2982962/open-source-tools/bossie-awards-2015-the-best-open-source-networking-and-security-software.html
|
||||
|
||||
作者：[InfoWorld staff][a]
|
||||
译者：[robot527](https://github.com/robot527)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.infoworld.com/author/InfoWorld-staff/
|
||||
[1]:https://www.icinga.org/icinga/icinga-2/
|
||||
[2]:http://www.zenoss.com/
|
||||
[3]:http://www.opennms.org/
|
||||
[4]:https://itunes.apple.com/us/app/opennms-compass/id968875097?mt=8
|
||||
[5]:https://play.google.com/store/apps/details?id=com.opennms.compass&hl=en
|
||||
[6]:http://blog.securityonion.net/p/securityonion.html
|
||||
[7]:https://www.kali.org/
|
||||
[8]:https://community.rapid7.com/community/metasploit/blog/2015/08/12/metasploit-on-kali-linux-20
|
||||
[9]:http://www.openvas.org/
|
||||
[10]:http://www.greenbone.net/
|
||||
[11]:https://www.owasp.org/index.php/Main_Page
|
||||
[12]:https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
|
||||
[13]:https://www.owasp.org/index.php/O-Saft
|
||||
[14]:https://www.owasp.org/index.php/OWASP_OWTF
|
||||
[15]:http://www.beefproject.com/
|
||||
[16]:http://www.unhide-forensics.info/
|
||||
[17]:http://www.rootkit.nl/projects/rootkit_hunter.html
|
||||
[18]:http://www.infoworld.com/article/2982622/bossie-awards-2015-the-best-open-source-applications.html
|
||||
[19]:http://www.infoworld.com/article/2982920/bossie-awards-2015-the-best-open-source-application-development-tools.html
|
||||
[20]:http://www.infoworld.com/article/2982429/bossie-awards-2015-the-best-open-source-big-data-tools.html
|
||||
[21]:http://www.infoworld.com/article/2982923/bossie-awards-2015-the-best-open-source-data-center-and-cloud-software.html
|
||||
[22]:http://www.infoworld.com/article/2982630/bossie-awards-2015-the-best-open-source-desktop-and-mobile-software.html
|
||||
[23]:http://www.infoworld.com/article/2982962/bossie-awards-2015-the-best-open-source-networking-and-security-software.html
|
||||
@ -1,65 +0,0 @@
|
||||
EXT4，Btrfs和XFS 文件系统之点评
|
||||
================================================================================
|
||||
|
||||
|
||||
老实说，人们最不曾考虑的问题之一是他们的个人电脑中使用了什么文件系统。Windows 和 Mac OS X 用户更没有理由去考虑，因为对于他们的操作系统，只有一种选择，那就是 NTFS 和 HFS+。相反，对于 Linux 系统而言，有很多种文件系统可以选择，现在默认的是广泛采用的 ext4。然而，现在也有改用一种称为 btrfs 文件系统的趋势。那是什么使得 btrfs更优秀，其它的文件系统又是什么，什么时候我们又能看到 Linux 发行版作出改变呢？
|
||||
|
||||
首先让我们对文件系统以及它们真正干什么有个总体的认识，然后我们再对一些有名的文件系统做详细的比较。
|
||||
|
||||
### 文件系统是干什么的？ ###
|
||||
|
||||
如果你不清楚文件系统是干什么的，一句话总结起来也非常简单。文件系统主要用于控制所有程序不再使用数据时如何存储数据、如何访问数据以及有什么其它信息（元数据）和数据本身相关，等等。听起来要编程实现并不是轻而易举的事情，实际上也确实如此。文件系统一直在改进，包括更多的功能、更高效地完成它需要做的事情。总而言之，它是所有计算机的基本需求、但并不像听起来那么简单。
|
||||
|
||||
### 为什么要分区？ ###
|
||||
|
||||
由于每个操作系统都能创建或者删除分区，很多人对分区都有模糊的认识。Linux 操作系统在同一块磁盘上即便使用标准安装过程，仍可以使用多个分区，这看起来很奇怪，因此需要一些解释。拥有不同分区的一个主要目的就是为了在灾难发生时能获得更好的数据安全性。
|
||||
|
||||
通过将硬盘划分为分区，数据会被分隔以及重组。当事故发生的时候，只有存储在被损坏分区的数据会被破坏，很大可能上其它分区的数据能得以保留。这个原因可以追溯到 Linux 操作系统还没有日志文件系统，任何电力故障都有可能导致灾难发生的时候。
|
||||
|
||||
使用分区也考虑到了安全和健壮性原因，因此操作系统部分损坏并不意味着整个计算机就有风险或者会受到破坏。这也是当前采用分区的一个最重要因素。举个例子，用户创建了一些会填满磁盘的脚本、程序或者 web 应用，如果该磁盘只有一个大的分区，如果磁盘满了那么整个系统就不能工作。如果用户把数据保存在不同的分区，那么就只有那个分区会受到影响，而系统分区或者其它数据分区仍能正常运行。
|
||||
|
||||
记住，拥有一个日志文件系统只能在掉电或者和存储设备意外断开连接时提供数据安全性，并不能在文件系统出现坏块或者发生逻辑错误时保护数据。对于这种情况，用户可以采用廉价磁盘冗余阵列（RAID：Redundant Array of Inexpensive Disks）的方案。
|
||||
|
||||
### 为什么要改变文件系统？ ###
|
||||
|
||||
ext4 文件系统由 ext3 文件系统改进而来，而后者又是从 ext2 文件系统改进而来。虽然 ext4 文件系统已经非常稳定，是过去几年中绝大部分发行版的默认选择，但它是基于陈旧的代码开发而来。另外， Linux 操作系统用户也需要很多 ext4 文件系统本身不提供的新功能。虽然通过某些软件能满足这种需求，但性能会受到影响，在文件系统层次做到这些能获得更好的性能。
|
||||
|
||||
### Ext4 文件系统 ###
|
||||
|
||||
ext4 还有一些明显的限值。最大文件大小是 16tebibytes（大概是 17.6 terabytes），这比普通用户当前能买到的硬盘还要大的多。使用 ext4 能创建的最大卷/分区是 1 exbibyte（大概是 1,152,921.5 terabytes）。通过使用多种技巧， ext4 比 ext3 有很大的速度提升。类似一些最先进的文件系统，它是一个日志文件系统，意味着它会对文件在磁盘中的位置以及任何其它对磁盘的更改做记录。纵观它的所有功能，它还不支持透明压缩、重复数据删除或者透明加密。技术上支持了快照，但该功能还处于实验性阶段。
|
||||
|
||||
### Btrfs 文件系统 ###
|
||||
|
||||
btrfs 有很多不同的发音，例如 Better FS、Butter FS 或者 B-Tree FS。它是一个几乎完全从头开发的文件系统。btrfs 存在的原因是它的开发者期初希望扩展文件系统的功能使得它包括快照、池化、校验以及其它一些功能。虽然和 ext4 无关，它也希望能保留 ext4 中能使消费者和商家受益的功能，并整合额外的能使每个人，尤其是企业受益的功能。对于使用大型软件以及大规模数据库的企业，对于多种不同的硬盘看起来一致的文件系统能使他们受益并且使数据整合变得更加简单。删除重复数据能降低数据实际使用的空间，当需要镜像一个单一和广泛文件系统时使用 btrfs 也能使数据镜像变得简单。
|
||||
|
||||
用户当然可以继续选择创建多个分区从而无需镜像任何东西。考虑到这种情况，btrfs 能横跨多种硬盘，和 ext4 相比，它能支持 16 倍以上的驱动空间。btrfs 文件系统一个分区最大是 16 exbibytes，最大的文件大小也是 16 exbibytes。
|
||||
|
||||
### XFS 文件系统 ###
|
||||
|
||||
XFS 文件系统是扩展文件系统（extent file system）的扩展。XFS 是 64 位高性能日志文件系统。对 XFS 的支持大概在 2002 年合并到了 Linux 内核，到了 2009 年，红帽企业版 Linux 5.4 也支持了 XFS 文件系统。对于 64 位文件系统，XFS 支持最大文件系统大小为 8 exbibytes。XFS 文件系统有一些缺陷，例如它不能压缩，删除大量文件时性能低下。目前RHEL 7.0 文件系统默认使用 XFS。
|
||||
|
||||
### 总后总结 ###
|
||||
|
||||
不幸的是，还不知道 btrfs 什么时候能到来。官方说，下一代文件系统仍然被归类为“不稳定”，但是如果用户下载最新版本的 Ubuntu，就可以选择安装到 btrfs 分区上。什么时候 btrfs 会被归类到 “稳定” 仍然是个谜， 直到真的认为它“稳定”之前，用户也不应该期望 Ubuntu 会默认采用 btrfs。有报道说 Fedora 18 会用 btrfs 作为它的默认文件系统，因为到了发布它的时候，应该有了 btrfs 文件系统校验器。由于还没有实现所有的功能，另外和 ext4 相比性能上也比较缓慢，btrfs 还有很多的工作要做。
|
||||
|
||||
那么，究竟使用哪个更好呢？尽管性能几乎相同，但 ext4 还是赢家。为什么呢？答案在于易用性以及广泛性。对于桌面或者工作站， ext4 仍然是一个很好的文件系统。由于默认提供，用户可以在上面安装操作系统。同时， ext4 支持最大 1 exabytes 的卷和 16 terabytes 的文件，因此考虑到大小，它也还有很大的进步空间。
|
||||
|
||||
btrfs 能提供更大的高达 16 exabytes 的卷以及更好的容错，但是，到现在为止，它感觉更像是一个附加文件系统，而没有集成到 Linux 操作系统。比如，尽管 btrfs 支持不同的发行版，使用 btrfs 格式化硬盘之前先要有 btrfs-tools 工具，这意味着安装 Linux 操作系统的时候它并不是一个可选项，即便不同发行版之间会有差异。
|
||||
|
||||
尽管传输速率非常重要，评价一个文件系统出了文件传输速度之外还有很多因素。btrfs 有很多好用的功能，例如写复制、扩展校验、快照、清洗、自修复数据、冗余删除以及其它保证数据完整性的功能。和 ZFS 相比 btrfs 缺少 RAID-Z 功能，因此对于 btrfs， RAID 还处于实验性阶段。对于单纯的数据存储，和 ext4 相比 btrfs 似乎更加优秀，但时间会验证一切。
|
||||
|
||||
迄今为止，对于桌面系统而言，ext4 似乎是一个更好的选择，因为它是默认的文件系统，传输文件时也比 btrfs 更快。btrfs 当然值得尝试、但要在桌面 Linux 上完全取代 ext4 可能还需要一些时间。数据场和大存储池会揭示关于 ext4、XCF 以及 btrfs 不同的故事和差异。
|
||||
|
||||
如果你有不同或者其它的观点，在下面的评论框中告诉我们吧。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.unixmen.com/review-ext4-vs-btrfs-vs-xfs/
|
||||
|
||||
作者：[M.el Khamlichi][a]
|
||||
译者：[ictlyh](http://mutouxiaogui.cn/blog/)
|
||||
校对：[Caroline](https://github.com/carolinewuyan)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.unixmen.com/author/pirat9/
|
||||
@ -0,0 +1,164 @@
|
||||
5个最受喜爱的开源Django包
|
||||
================================================================================
|
||||
|
||||
|
||||
图片来源：Opensource.com
|
||||
|
||||
_Jacob Kaplan-Moss和Frank Wiles也参与了本文的写作。_
|
||||
|
||||
Django围绕“[可重用应用][1]”观点建立：自我包含了提供可重复使用特性的包。你可以将这些可重用应用组装起来，在加上适用于你的网站的特定代码，来搭建你自己的网站。Django具有一个丰富多样的、由可供你使用的可重用应用组建起来的生态系统——PyPI列出了[超过8000个 Django 应用][2]——可你该如何知道哪些是最好的呢？
|
||||
|
||||
为了节省你的时间，我们总结了五个最受喜爱的 Django 应用。它们是：
|
||||
- [Cookiecutter][3]: 建立 Django 网站的最佳方式。
|
||||
- [Whitenoise][4]: 最棒的静态资源服务器。
|
||||
- [Django Rest Framework][5]: 使用 Django 开发 REST API 的最佳方式。
|
||||
- [Wagtail][6]: 基于 Django 的最佳内容管理系统。
|
||||
- [django-allauth][7]: 提供社交账户登录的最佳应用（如 Twitter, Facebook, GitHub 等）。
|
||||
|
||||
我们同样推荐你查看 [Django Packages][8]，一个可重用 Django 应用的目录。Django Packages 将 Django 应用组织成“表格”，你可以在功能相似的不同应用之间进行比较并做出选择。你可以查看每个包中提供的特性，和使用统计情况。（比如：这是[ REST 工具的表格][9]，也许可以帮助你理解我们为何推荐 Django REST Framework.
|
||||
|
||||
## 为什么你应该相信我们？
|
||||
|
||||
我们使用 Django 的时间比几乎其他人都长。在 Django 发布之前，我们当中的两个人（Frank 和 Jacob）在 [Lawrence Journal-World][10] （Django 的发源地）工作（事实上他们两人推动了 Django 开源发布的进程）。我们在过去的八年当中运行着一个咨询公司，来建议公司使用 Django 去将事情做到最好。
|
||||
|
||||
所以，我们见证了Django项目和社群的完整历史，我们见证了流行软件包的兴起和没落。在我们三个中，我们可能私下试用了8000个应用中的一半以上，或者我们知道谁试用过这些。我们对如何使应用变得坚实可靠有着深刻的理解，并且我们对给予这些应用持久力量的来源也有不错的理解。
|
||||
|
||||
## 建立Django网站的最佳方式：[Cookiecutter][3]
|
||||
|
||||
建立一个新项目或应用总是有些痛苦。你可以用Django内建的 `startproject`。不过，如果你像我们一样，你可能会对你的办事方式很挑剔。Cookiecutter 为你提供了一个快捷简单的方式来构建易于使用的项目或应用模板，从而解决了这个问题。一个简单的例子：键入 `pip install cookiecutter`，然后在命令行中运行以下命令：
|
||||
|
||||
```bash
|
||||
$ cookiecutter https://github.com/marcofucci/cookiecutter-simple-django
|
||||
```
|
||||
|
||||
接下来你需要回答几个简单的问题，比如你的项目名称、目录、作者名字、E-Mail和其他几个关于配置的小问题。这些能够帮你补充项目相关的细节。我们使用最最原始的 "_foo_" 作为我们的目录名称。所以 cokkiecutter 在子目录 "_foo_" 下建立了一个简单的 Django 项目。
|
||||
|
||||
如果你在"_foo_"项目中闲逛，你会看见你刚刚选择的其它设置已通过模板，连同子目录一同嵌入到文件当中。这个“模板”在我们刚刚在执行 `cookiecutter` 命令时输入的 Github 仓库 URL 中定义。这个样例工程使用了一个 Github 远程仓库作为模板；不过你也可以使用本地的模板，这在建立非重用项目时非常有用。
|
||||
|
||||
我们认为 cookiecutter 是一个极棒的 Django 包，但是，事实上其实它在面对纯 Python 甚至非 Python 相关需求时也极为有用。你能够将所有文件依你所愿精确摆放在任何位置上，使得 cookiecutter 成为了一个简化工作流程的极佳工具。
|
||||
|
||||
## 最棒的静态资源服务器：[Whitenoise][4]
|
||||
|
||||
多年来，托管网站的静态资源——图片、Javascript、CSS——都是一件很痛苦的事情。Django 内建的 [django.views.static.serve][11] 视图，就像Django文章所述的那样，“在生产环境中不可靠，所以只应为开发环境的提供辅助功能。”但使用一个“真正的” Web 服务器，如 NGINX 或者借助 CDN 来托管媒体资源，配置起来会相当困难。
|
||||
|
||||
Whitenoice 很简洁地解决了这个问题。它可以像在开发环境那样轻易地在生产环境中设置静态服务器，并且针对生产环境进行了加固和优化。它的设置方法极为简单：
|
||||
|
||||
1. 确保你在使用 Django 的 [contrib.staticfiles][12] 应用，并确认你在配置文件中正确设置了 `STATIC_ROOT` 变量。
|
||||
|
||||
2. 在 `wsgi.py` 文件中启用 Whitenoise:
|
||||
|
||||
```python
|
||||
from django.core.wsgi import get_wsgi_application
|
||||
from whitenoise.django import DjangoWhiteNoise
|
||||
|
||||
application = get_wsgi_application()
|
||||
application = DjangoWhiteNoise(application)
|
||||
```
|
||||
|
||||
配置它真的就这么简单！对于大型应用，你可能想要使用一个专用的媒体服务器和/或一个 CDN，但对于大多数小型或中型 Django 网站，Whitenoise 已经足够强大。
|
||||
|
||||
如需查看更多关于 Whitenoise 的信息，[请查看文档][13]。
|
||||
|
||||
## 开发REST API的最佳工具：[Django REST Framework][5]
|
||||
|
||||
REST API 正在迅速成为现代 Web 应用的标准功能。与一个 API 进行简短的会话，你只需使用 JSON 而不是 HTML，当然你可以只用 Django 做到这些。你可以制作自己的视图，设置合适的 `Content-Type`, 然后返回 JSON 而不是渲染后的 HTML 响应。这是在像 [Django Rest Framework][14]（下称DRF）这样的API框架发布之前，大多数人所做的。
|
||||
|
||||
如果你对 Django 的视图类很熟悉，你会觉得使用DRF构建REST API与使用它们很相似，不过 DRF 只针对特定 API 使用场景而设计。在一般 API 设计中，你会用到它的不少代码，所以我们强调了一些 DRF 的特性来使你更快地接受它，而不是去看一份让你兴奋的示例代码：
|
||||
|
||||
* 可自动预览的 API 可以使你的开发和人工测试轻而易举。你可以查看 DRF 的[示例代码][15]。你可以查看 API 响应，并且它支持 POST/PUT/DELETE 类型的操作，不需要你做任何事。
|
||||
|
||||
|
||||
* 认证方式易于迁移，如OAuth, Basic Auth, 或API Tokens.
|
||||
* 内建请求速度限制。
|
||||
* 当与 [django-rest-swagger][16] 结合时，API文档几乎可以自动生成。
|
||||
* 第三方库拥有广泛的生态。
|
||||
|
||||
当然你可以不依赖 DRF 来构建 API，但我们无法推测你不开始使用 DRF 的原因。就算你不使用 DRF 的全部特性，使用一个成熟的视图库来构建你自己的 API 也会使你的 API 更加一致、完全，更能提高你的开发速度。如果你还没有开始使用 DRF, 你应该找点时间去体验一下。
|
||||
|
||||
## 以 Django 为基础的最佳 CMS：[Wagtail][6]
|
||||
|
||||
Wagtail是当下Django CMS（内容管理系统）世界中最受人青睐的应用，并且它的热门有足够的理由。就想大多数的 CMS 一样，它具有极佳的灵活性，可以通过简单的 Django 模型来定义不同类型的页面及其内容。使用它，你可以从零开始，在几个小时而不是几天之内来和建造一个基本可以运行的内容管理系统。举一个小例子，为你公司的员工定义一个页面类型可以像下面一样简单：
|
||||
|
||||
```python
|
||||
from wagtail.wagtailcore.models import Page
|
||||
from wagtail.wagtailcore.fields import RichTextField
|
||||
from wagtail.wagtailadmin.edit_handlers import FieldPanel, MultiFieldPanel
|
||||
from wagtail.wagtailimages.edit_handlers import ImageChooserPanel
|
||||
|
||||
class StaffPage(Page):
|
||||
name = models.CharField(max_length=100)
|
||||
hire_date = models.DateField()
|
||||
bio = models.RichTextField()
|
||||
email = models.EmailField()
|
||||
headshot = models.ForeignKey('wagtailimages.Image', null=True, blank=True)
|
||||
content_panels = Page.content_panels + [
|
||||
FieldPanel('name'),
|
||||
FieldPanel('hire_date'),
|
||||
FieldPanel('email'),
|
||||
FieldPanel('bio',classname="full"),
|
||||
ImageChoosePanel('headshot'),
|
||||
]
|
||||
```
|
||||
|
||||
然而，Wagtail 真正出彩的地方在于它的灵活性及其易于使用的现代化管理页面。你可以控制不同类型的页面在哪网站的哪些区域可以访问，为页面添加复杂的附加逻辑，还可以极为方便地取得标准的适应/审批工作流。在大多数 CMS 系统中，你会在开发时在某些点上遇到困难。而使用 Wagtail 时，我们经过不懈努力找到了一个突破口，使得让我们轻易地开发出一套简洁稳定的系统，使得程序完全依照我们的想法运行。如果你对此感兴趣，我们写了一篇[深入理解 Wagtail][17].
|
||||
|
||||
## 提供社交账户登录的最佳工具：[django-allauth][7]
|
||||
|
||||
django-allauth 是一个能够解决你的注册和认证需求的、可重用的Django应用。无论你需要构建本地注册系统还是社交账户注册系统，django-allauth 都能够帮你做到。
|
||||
|
||||
这个应用支持多种认证体系，比如用户名或电子邮件。一旦用户注册成功，它可以提供从零到电子邮件认证的多种账户验证的策略。同时，它也支持多种社交账户和电子邮件账户关联。它还支持可插拔的注册表单，可让用户在注册时回答一些附加问题。
|
||||
|
||||
django-allauth 支持多于 20 种认证提供者，包括 Facebook, Github, Google 和 Twitter。如果你发现了一个它不支持的社交网站，那很有可能有一款第三方插件提供该网站的接入支持。这个项目还支持自定义后台开发，可以支持自定义的认证方式。
|
||||
|
||||
django-allauth 易于配置，且有[完善的文档][18]。该项目通过了很多测试，所以你可以相信它的所有部件都会正常运作。
|
||||
|
||||
你有最喜爱的 Django 包吗？请在评论中告诉我们。
|
||||
|
||||
## 关于作者
|
||||
|
||||
|
||||
|
||||
Jeff Triplett
|
||||
|
||||
劳伦斯，堪萨斯州
|
||||
<http://www.jefftriplett.com/>
|
||||
|
||||
我在 2007 年搬到了堪萨斯州的劳伦斯，在 Django 的发源地—— Lawrence Journal-World 工作。我现在在劳伦斯市的 [Revolution Systems (Revsys)][19] 工作，做一位开发者兼顾问。
|
||||
|
||||
我是[北美 Django 运动基金会(DEFNA)][20]的联合创始人，2015 和 2016 年 [DjangoCon US][21] 的会议主席，而且我在 Django 的发源地劳伦斯参与组织了 [Django Birthday][22] 来庆祝 Django 的 10 岁生日。
|
||||
|
||||
我是当地越野跑小组的成员，我喜欢篮球，我还喜欢梦见自己随着一道气流游遍美国。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/business/15/12/5-favorite-open-source-django-packages
|
||||
|
||||
作者：[Jeff Triplett][a]
|
||||
译者：[StdioA](https://github.com/StdioA)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/jefftriplett
|
||||
[1]:https://docs.djangoproject.com/en/1.8/intro/reusable-apps/
|
||||
[2]:https://pypi.python.org/pypi?:action=browse&c=523
|
||||
[3]:https://github.com/audreyr/cookiecutter
|
||||
[4]:http://whitenoise.evans.io/en/latest/base.html
|
||||
[5]:http://www.django-rest-framework.org/
|
||||
[6]:https://wagtail.io/
|
||||
[7]:http://www.intenct.nl/projects/django-allauth/
|
||||
[8]:https://www.djangopackages.com/
|
||||
[9]:https://www.djangopackages.com/grids/g/rest/
|
||||
[10]:http://www2.ljworld.com/news/2015/jul/09/happy-birthday-django/
|
||||
[11]:https://docs.djangoproject.com/en/1.8/ref/views/#django.views.static.serve
|
||||
[12]:https://docs.djangoproject.com/en/1.8/ref/contrib/staticfiles/
|
||||
[13]:http://whitenoise.evans.io/en/latest/index.html
|
||||
[14]:http://www.django-rest-framework.org/
|
||||
[15]:http://restframework.herokuapp.com/
|
||||
[16]:http://django-rest-swagger.readthedocs.org/en/latest/index.html
|
||||
[17]:https://opensource.com/business/15/5/wagtail-cms
|
||||
[18]:http://django-allauth.readthedocs.org/en/latest/
|
||||
[19]:http://www.revsys.com/
|
||||
[20]:http://defna.org/
|
||||
[21]:https://2015.djangocon.us/
|
||||
[22]:https://djangobirthday.com/
|
||||
Loading…
Reference in New Issue
Block a user