Jason Baker 发布的文章

这个世界上有两种 Linux 用户:敢于冒险的和态度谨慎的。

其中一类用户总是本能的去尝试任何能够戳中其痛点的新选择。他们尝试过不计其数的窗口管理器、系统发行版和几乎所有能找到的桌面插件。

另一类用户找到他们喜欢的东西后,会一直使用下去。他们往往喜欢所使用的系统发行版的默认配置。最先熟练掌握的文本编辑器会成为他们最钟爱的那一个。

作为一个使用桌面版和服务器版十五年之久的 Linux 用户,比起第一类来,我无疑属于第二类用户。我更倾向于使用现成的东西,如此一来,很多时候我就可以通过文档和示例方便地找到我所需要的使用案例。如果我决定选择使用非费标准的东西,这个切换过程一定会基于细致的研究,并且前提是来自好基友的大力推荐。

但这并不意味着我不喜欢尝试新事物并且查漏补失。所以最近一段时间,在我不假思索的使用了 bash shell 多年之后,决定尝试一下另外四个 shell 工具:ksh、tcsh、zsh 和 fish。这四个 shell 都可以通过我所用的 Fedora 系统的默认库轻松安装,并且他们可能已经内置在你所使用的系统发行版当中了。

这里对它们每个选择都稍作介绍,并且阐述下它适合做为你的下一个 Linux 命令行解释器的原因所在。

bash

首先,我们回顾一下最为熟悉的一个。 GNU Bash,又名 Bourne Again Shell,它是我这些年使用过的众多 Linux 发行版的默认选择。它最初发布于 1989 年,并且轻松成长为 Linux 世界中使用最广泛的 shell,甚至常见于其他一些类 Unix 系统当中。

Bash 是一个广受赞誉的 shell,当你通过互联网寻找各种事情解决方法所需的文档时,总能够无一例外的发现这些文档都默认你使用的是 bash shell。但 bash 也有一些缺点存在,如果你写过 Bash 脚本就会发现我们写的代码总是得比真正所需要的多那么几行。这并不是说有什么事情是它做不到的,而是说它读写起来并不总是那么直观,至少是不够优雅。

如上所述,基于其巨大的安装量,并且考虑到各类专业和非专业系统管理员已经适应了它的使用方式和独特之处,至少在将来一段时间内,bash 或许会一直存在。

ksh

KornShell,或许你对这个名字并不熟悉,但是你一定知道它的调用命令 ksh。这个替代性的 shell 于 80 年代起源于贝尔实验室,由 David Korn 所写。虽然最初是一个专有软件,但是后期版本是在 Eclipse Public 许可下发布的。

ksh 的拥趸们列出了他们觉得其优越的诸多理由,包括更好的循环语法,清晰的管道退出代码,处理重复命令和关联数组的更简单的方式。它能够模拟 vi 和 emacs 的许多行为,所以如果你是一个重度文本编辑器患者,它值得你一试。最后,我发现它虽然在高级脚本方面拥有不同的体验,但在基本输入方面与 bash 如出一辙。

tcsh

tcsh 衍生于 csh(Berkely Unix C shell),并且可以追溯到早期的 Unix 和计算机时代开始。

tcsh 最大的卖点在于它的脚本语言,对于熟悉 C 语言编程的人来说,看起来会非常亲切。tcsh 的脚本编写有人喜欢,有人憎恶。但是它也有其他的技术特色,包括可以为 aliases 添加参数,各种可能迎合你偏好的默认行为,包括 tab 自动完成和将 tab 完成的工作记录下来以备后查。

tcsh 以 BSD 许可发布。

zsh

zsh 是另外一个与 bash 和 ksh 有着相似之处的 shell。诞生于 90 年代初,zsh 支持众多有用的新技术,包括拼写纠正、主题化、可命名的目录快捷键,在多个终端中共享同一个命令历史信息和各种相对于原来的 bash 的轻微调整。

虽然部分需要遵照 GPL 许可,但 zsh 的代码和二进制文件可以在一个类似 MIT 许可证的许可下进行分发; 你可以在 actual license 中查看细节。

fish

之前我访问了 fish 的主页,当看到 “好了,这是一个为 90 后而生的命令行 shell” 这条略带调侃的介绍时(fish 完成于 2005 年),我就意识到我会爱上这个交互友好的 shell 的。

fish 的作者提供了若干切换过来的理由,这些理由有点小幽默并且能戳中笑点,不过还真是那么回事。这些特性包括自动建议(“注意, Netscape Navigator 4.0 来了”,LCTT 译注:NN4 是一个重要版本。),支持“惊人”的 256 色 VGA 调色,不过也有真正有用的特性,包括根据你机器上的 man 页面自动补全命令,清除脚本和基于 web 界面的配置方式。

fish 的许可主要基于 GPLv2,但有些部分是在其他许可下的。你可以查看资源库来了解完整信息

如果你想要寻找关于每个选择确切不同之处的详尽纲要,这个网站应该可以帮到你。

我的立场到底是怎样的呢?好吧,最终我应该还是会重新投入 bash 的怀抱,因为对于大多数时间都在使用命令行交互的人来说,切换过程对于编写高级的脚本能带来的好处微乎其微,并且我已经习惯于使用 bash 了。

但是我很庆幸做出了敞开大门并且尝试新选择的决定。我知道门外还有许许多多其他的东西。你尝试过哪些 shell,更中意哪一个?请在评论里告诉我们。


via: https://opensource.com/business/16/3/top-linux-shells

作者:Jason Baker 译者:mr-ping 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

生活充满了bug。

无论怎样小心计划,无论花多少时间去设计,在执行阶段实际执行时,任何工程都会有未知的问题。也无妨。也许对于任何一个组织的最佳弹性衡量不是他们如何一切都按计划运行地处理事情,而是,当出现磕磕碰碰时他们如何驾驭。

对任何一个项目管理流程来说,特别是在软件开发领域,都需要一个关键工具——问题跟踪管理系统。其基本功能很简单:可以对bug进行查看、追踪,并以协作的方式解决bug,有了它,我们更容易跟随整个过程的进展。除了基本功能,还有很多专注于满足特定需求的选项及功能,使用场景不仅限于软件开发。你可能已经熟悉某些托管版本的工具,像 GitHub Issues或者Launchpad,其中一些工具已经有了自己的开源社区。

接下来,这四个bug问题跟踪管理软件的极佳备选,全部开源、易于下载,自己就可以部署。先说好,我们可能没有办法在这里列出每一个问题跟踪工具;相反,我们列出这四个,原因基于是其丰富的功能和项目背后的社区规模。当然,肯定还有其他类似软件,如果你喜欢的没有列在这里,如果你有一个好的理由,一定要让我们知道,在下面的评论中使它脱颖而出吧。

Redmine

Redmine 是一个很流行的追踪管理工具,基于Ruby on Rails构建,可以追溯到2006年。很多方面类似于Trac(另一个我们的最爱),Redmine可以管理多个项目,整合了多种版本控制系统。除了基本问题追踪,Redmine也提供论坛,wiki,时间跟踪工具,同时,它还具有生成 甘特图表 Gantt charts 和日历的能力,用来跟踪项目的进展。

Redmine的设置相当灵活,支持多种数据库后端和几十种语言,还是可定制的,可以向 问题 issue 、用户、工程等添加自定义字段。通过社区创建的插件和主题它可以进一步定制。

如果你想试一试,一个在线演示可提供使用。Redmine采用GPL版本2许可证;开源代码可以在工程的svn仓库或在GitHub镜像上找到。

Bugzilla

Bugzilla是另一个流行的具备问题跟踪能力的开发工具。从名字您可能已经猜到了,Bugzilla最初是Mozilla基金会创建的,用来跟踪当时称为网景通信套件中的bug。为了更好的可读性,它从原来的Tcl移植到Perl,Bugzilla是一个比较老,但却广泛采用的问题跟踪系统,它被用在许多著名的开源项目如GNOME、KDE,以及Linux内核本身。

从通知到重复bug检测再到搜索共享,Bugzilla拥有许多高级工具,是一个功能更丰富的选项。Bugzilla拥有一套高级搜索系统以及全面的报表工具,具有生成图表和自动化按计划生成报告的能力。像Redmine一样,Bugzilla是可扩展和可定制的,除了字段本身,还能针对bug创建自定义工作流。它也支持多种后端数据库,和自带的多语言支持。

Bugzilla采用Mozilla公共许可证,你可以读取他们的未来路线图还有在官网尝试一个示例服务

Trac

Trac自称是基于web的极简主义软件工程管理软件,这里请不要混淆极简主义与缺乏功能。

由python编写的Trac,将其漏洞跟踪能力与它的wiki系统和版本控制系统轻度整合。项目管理能力突出,如生成里程碑和路线图,一个可定制的报表系统,大事记,支持多资源库,内置的垃圾邮件过滤,还可以使用很多通用语言。如其他我们已经看到的漏洞追踪软件,有很多插件可进一步扩展其基本特性。

Trac以改进的BSD许可协议开源,虽然更老的版本发布在GPL下。你可以在一个自托管仓库预览Trac的源码或者查看他们的路线图对未来的规划。

Mantis

Mantis是这次合集中我们将看到的最后一个工具,基于PHP,且有16年历史。作为另一个支持多种不同版本控制系统和事件驱动通知系统的bug跟踪管理软件,Mantis有一个与其他工具类似的功能设置。虽然它不本身包含wiki,但它整合了很多流行的wiki平台且本地化到多种语言。

Mantis使用GPL版本2开源许可证书;你可以在GitHub浏览他的源代码或查看自托管路线图对未来的规划。一个示例,你可以查看他们的内部漏洞跟踪

正如我们指出的,这四个不是唯一的选项。想要探索更多?Apache BloodhoundFossilThe Bug Genie,还有很多可替换品都有自己的忠实追随者,每个都有不同的优点和缺点。另外,一些工具在我们项目管理摘要有问题跟踪功能。所以,哪个是你首选的跟踪和碾压bug的工具?


via: https://opensource.com/business/16/2/top-issue-support-and-bug-tracking-tools

作者:Jason Baker 译者:wyangsun 校对:Mr小眼儿

本文由 LCTT 原创翻译,Linux中国 荣誉推出

回顾这周的 OpenStack 峰会,我仍然回味着开源云生态系统的浩瀚无垠,有那么多需要了解的项目及概念才能获得成功。不过我们很幸运,因为有许多资源让我们跟随着项目的脚步。除了官方文档外,我们还有许多来自第三方提供的培训和认证、个人分享,以及许多社区贡献的学习资源。

为了让我们保持获得最新消息,每个月我们将会整合发布 OpenStack 社区的最新教程、指导和小贴士等。下面是我们过去几个月最棒的发布分享。

  • 首先,如果你正在寻找一个靠谱实惠的 OpenStack 测试实验室, Intel NUC 是最值得考虑的平台。麻雀虽小,五脏俱全,通过指导文章,可以很轻松的按照教程在 NUC 上使用 TripleO 部署 OpenStack ,并且还可以轻松避开一些常见的古怪问题。
  • 当你已经运行的一段时间 OpenStack 后,你会发现在你的云系统上许多组件生成了大量日志。其中一些是可以安全删除的,而你需要一个管理这些日志的方案。参考在部署生产 9 个月后使用 Celiometer 管理日志的一些思考
  • 对于 OpenStack 基础设施项目的新手,想要提交补丁到 OpenStack 是相当困难的。入口在哪里,测试怎么做,我的提交步骤是怎么样的?可以通过 Arie Bregman 的这篇博客文章快速了解整个提交过程。
  • 突发计算节点失效,不知道是硬件还是软件问题。不过好消息是 OpenStack 提供了一套非常简单的迁移计划可以让你迁移当机节点到别的主机。然而,迁移过程中使用的命令令许多人感到困惑。可以通过这篇文章来理解 migrate 和 evacuate 命令的不同。
  • 网络功能虚拟化技术需要 OpenStack 之外的一些功能,而用户可能不熟悉它们。例如, SR-IOV 和 PCI 直通是最大限度地提高物理硬件性能的方式。可以学习部署步骤以使 OpenStack 的性能最大化。

这些文章基本涵盖了本月(译者注: 4 月)推送,如果你还需要更多文章,可以检索过去推送的 OpenStack 文献来获取更多资源。如果有你认为我们应该推荐的新教程,请在评论中告诉我们,谢谢。


via: https://opensource.com/business/16/4/master-openstack-new-tutorials

作者:Jason Baker 译者:VicYu/Vic020 校对:PurlingNayuki

本文由 LCTT 原创翻译,Linux中国 荣誉推出

无论你承认与否,email并没有消亡。对那些对命令行至死不渝的 Linux 高级用户而言,离开 shell 转而使用传统的桌面或网页版邮件客户端并不适应。归根结底,命令行最善于处理文件,特别是文本文件,能使效率倍增。

幸运的是,也有不少的命令行邮件客户端,而它们的用户大都乐于帮助你入门并回答你使用中遇到的问题。但别说我没警告过你:一旦你完全掌握了其中一个客户端,你会发现很难回到基于图形界面的客户端!

要安装下述四个客户端中的任何一个是非常容易的;主要的 Linux 发行版的软件仓库中都提供此类软件,并可通过包管理器进行安装。你也可以在其它的操作系统中寻找并安装这类客户端,但我并未尝试过也没有相关的经验。

Mutt

许多终端爱好者都听说过甚至熟悉 Mutt 和 Alpine, 他们已经存在多年。让我们先看看 Mutt。

Mutt 支持许多你所期望 email 系统支持的功能:会话,颜色区分,支持多语言,同时还有很多设置选项。它支持 POP3 和 IMAP 这两个主要的邮件传输协议,以及许多邮箱格式。自从1995年诞生以来, Mutt 就拥有了一个活跃的开发社区,但最近几年,新版本更多的关注于修复问题和安全更新而非提供新功能。这对大多数 Mutt 用户而言并无大碍,他们钟爱这样的界面,并支持此项目的口号:“所有邮件客户端都很烂,只是这个烂的没那么彻底。”

Alpine

Alpine 是另一款知名的终端邮件客户端,它由华盛顿大学开发,设计初衷是作为一个开源的、支持 unicode 的 Pine (也来自华盛顿大学)的替代版本。

Alpine 不仅容易上手,还为高级用户提供了很多特性,它支持很多协议 —— IMAP, LDAP, NNTP, POP, SMTP 等,同时也支持不同的邮箱格式。Alpine 内置了一款名为 Pico 的可独立使用的简易文本编辑工具,但你也可以使用你常用的文本编辑器: vi, Emacs等。

尽管 Alpine 的升级并不频繁,不过有个名为 re-alpine 的分支为不同的开发者提供了开发此项目的机会。

Alpine 支持在屏幕上显示上下文帮助,但一些用户会喜欢 Mutt 式的独立说明手册,不过它们两个的文档都很完善。用户可以同时尝试 Mutt 和 Alpine,并由个人喜好作出决定,也可以尝试以下的几个新选择。

Sup

Sup 是我们列表中能被称为“大容量邮件客户端”的二者之一。自称“为邮件较多的人设计的命令行客户端”,Sup 的目标是提供一个支持层次化设计并允许为会话添加标签进行简单整理的界面。

由于采用 Ruby 编写,Sup 能提供十分快速的搜索并能自动管理联系人列表,同时还允许自定义插件。对于使用 Gmail 作为网页邮件客户端的人们,这些功能都是耳熟能详的,这就使得 Sup 成为一种比较现代的命令行邮件管理方式。

Notmuch

"Sup? Notmuch." Notmuch 作为 Sup 的回应,最初只是重写了 Sup 的一小部分来提高性能。最终,这个项目逐渐变大并成为了一个独立的邮件客户端。

Notmuch 是一款相当精简的软件。它并不能独立的收发邮件,启用 Notmuch 的快速搜索功能的代码实际上是设计成一个程序可以调用的独立库。但这样的模块化设计也使得你能使用你最爱的工具进行写信,发信和收信,集中精力做好一件事情并有效浏览和管理你的邮件。

这个列表并不完整,还有很多 email 客户端,它们或许才是你的最佳选择。你喜欢什么客户端呢?


via: http://opensource.com/life/15/8/top-4-open-source-command-line-email-clients

作者:Jason Baker 译者:KevinSJ 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出