对于某些人来说寻找系统的彩蛋是非常有意义的事情，自Android 2.3 Gingerbread之中Google就开始加入了各种丰富有趣的彩蛋。不过根据最新发布的Android 4.1 Jelly Bean的最大彩蛋：Android版本的命名方式。首先我们来看看下面版本有没有什么规律，想必大家一眼就看到了这其实是按照字母排列来对系统版本进行命名，

• Cupcake
• Donut
• Eclair
• FroYo
• Gingerbread
• Honeycomb
• Ice Cream Sandwich
• Jelly Bean

对此我们可以很容易的猜想到接下来的版本是什么，很有可能就是“Kandy Cane”，不过就不知道Google是怎么想的啦 。

下面是Kristóf Kovács收集的28个Unix/Linux下的28个命令行下的工具（原文链接），有一些是大家熟悉的，有一些是非常有用的，有一些是不为人知的。这些工具都非常不错，希望每个人都知道。本篇文章还在Hacker News上被讨论，你可以过去看看。我以作者的原文中加入了官网链接和一些说明。

查看网络流量的一个工具

官方网站：  Simple Linux Utility for Resource Management

vim & emacs

真正程序员的代码编辑器。

screen, dtach, tmux, byobu

你是不是经常需要 SSH 或者 telent 远程登录到 Linux 服务器？你是不是经常为一些长时间运行的任务而头疼，比如系统备份、ftp 传输等等。通常情况下我们都是为每一个这样的任务开一个远程终端窗口，因为他们执行的时间太长了。必须等待它执行完毕，在此期间可不能关掉窗口或者断开连 接，否则这个任务就会被杀掉，一切半途而废了。

Screen是 一个可以在多个进程之间多路复用一个物理终端的窗口管理器。Screen中有会话的概念，用户可以在一个screen会话中创建多个screen窗口，在 每一个screen窗口中就像操作一个真实的telnet/SSH连接窗口那样。请参看IBM DeveloperWorks的这篇文章《使用 screen 管理你的远程会话》

dtach 是用来模拟screen的detach的功能的小工具，其可以让你随意地attach到各种会话上 。下图为dtach+dvtm的样子。

tmux是一个优秀的终端复用软件，类似GNU Screen， 但来自于OpenBSD，采用BSD授权。使用它最直观的好处就是，通过一个终端登录远程主机并运行tmux后，在其中可以开启多个控制台而无需再“浪 费”多余的终端来连接这台远程主机；当然其功能远不止于此。与screen相比的优点：可以横向和纵向分割窗口，且窗格可以自由移动和调整大小。可在多个 缓冲区进行复制和粘贴，支持跨窗口搜索；非正常断线后不需重新detach；……  有人说——与tmux相比，screen简直弱爆了。

multitail

MultiTail是个用来实现同时监控多个文档、类似tail命令的功能的软件。他和tail的区别就是他会在控制台中打开多个窗口，这样使同时监控多个日志文档成为可能。他还可以看log文件的统计，合并log文件，过滤log文件，分屏，……。

官网：http://www.vanheusden.com/multitail/

tpp

终端下的PPT，要是在某某大会上用这个演示PPT，就太TMD的Geek了。

官网：http://www.ngolde.de/tpp.html

xargs & parallel

Executes tasks from input (even multithread).

xargs 是一个比较古老的命令，有简单的并行功能，这个不说了。对于GNU parallel ( online manpage )来说，它不仅能够处理本机上多执行绪，还能分散至远端电脑协助处理。而使用GNU parallel前，要先确定本机有安装GNU parallel / ssh / rsync，远端电脑也要安装ssh。

duplicity & rsyncrypto

Duplicity是使用rsync算法加密的高效率备份软件，Duplicity支持目录加密生产和格式上传到远程或本地文件服务器。

rsyncrypto 就是 rsync + encryption。对于rsync的算法可参看酷壳的rsync核心算法。

Encrypting backup tools.

nethack & slash’em

NetHack（Wiki），20年历史的古老电脑游戏。没有声音，没有漂亮的界面，不过这个游戏真的很有意思。网上有个家伙说：如果你一生只做一件事情，那么玩NetHack。 这句话很惹眼，但也让人觉得这个游戏很复杂不容易上手。其实，这个游戏很虽然很复杂，却容易上手。虽然玩通关很难，但上手很容易。NetHack上有许多 复杂的规则，”the DevTeam thinks of everything”（开发团队想到了所有的事情)。各种各样的怪物，各种各样的武器….，有许多spoilers文件来说明其规则。除了每次开始随机 生成的地图，每次玩游戏，你也都会碰到奇怪的事情: 因为喝了一种药水，变成了机器人;因为踢坏了商店的门被要求高价赔偿;你的狗为你偷来了商店的东西….. 这有点象人生，你不能完全了解这个世界，但你仍然可以选择自己的面对方式。

网上有许多文章所这是最好的电脑游戏或最好的电脑游戏之一。也许是因为它开放的源代码让人赞赏，古老的历史让人宽容，复杂的规则让人敬畏。虽然它不是当前流行的游戏，但它比任何一个当前流行的游戏都更有可能再经受20年的考验。

Slash’EM 也是一个基于NetHack的经典游戏。

lftp

利用lftp命令行ftp工具进行网站数据的增量备份，镜像，就像使用rsync一样。

ack

ack是一个perl脚本，是grep的一个可选替换品。其可以对匹配字符有高亮显示。是为程序员专门设计的，默认递归搜索，省提供多种文件类型供选。

calcurse & remind + wyrd

calcurse是一个命令行下的日历和日程软件。remind + wyrd也很类似。关于日历，我不得不提一个Linux的Cycle日历，也是一个神器，呵呵。

newsbeuter & rsstail

newsbeuter 和 rsstail 是命令行下RSS的阅读工具。

powertop

做个环保的程序员，看看自己的电脑里哪些程序费电。PowerTOP 是一个让 Intel 平台的笔记本电脑节省电源的 Linux 工具。此工具由 Intel 公司发布。它可以帮助用户找出那些耗电量大的程序，通过修复或者关闭那些应用程序或进程，从而为用户节省电源。

ttyrec & ipbt

ttyrec 是一个 tty 控制台录制程序，其所录制的数据文件可以使用与之配套的 ttyplay 播放。不管是你在 tty 中的各种操作，还是在 tty 中耳熟能详的软件，都可进行录制。

ipbt 是一个用来回放 ttyrec 所录制的控制台输入过程的工具。

与此类似的还有Shelr 和 termrec 

rsync

通过SSH进行文件同步的经典工具（核心算法）

mtr

MTR – traceroute 2.0，其是把 traceroute 和 ping 集成在一块的一个小工具 用于诊断网络。

socat & netpipes

socat是一个多功能的网络工具，名字来由是” Socket CAT”，可以看作是netcat的N倍加强版。

netpipes 和socat一样，主要是用来在命令行来进行socket操作的命令，这样你就可以在Shell脚本下行进socket网络通讯了。

iftop & iptraf

iftop和iptraf可以用来查看当前网络链接的一些流量情况。

siege & tsung

Siege是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。

Tsung 是一个压力测试工具，可以测试包括HTTP, WebDAV, PostgreSQL, MySQL, LDAP, and XMPP/Jabber等服务器。针对 HTTP 测试，Tsung 支持 HTTP 1.0/1.1 ，包含一个代理模式的会话记录、支持 GET、POST 和 PUT 以及 DELETE 方法，支持 Cookie 和基本的 WWW 认证，同时还支持 SSL。

参看：十个免费的Web压力测试工具

ledger

ledger 一个命令行下记帐的小工具。

taskwarrior

TaskWarrior 是一个基于命令行的 TODO 列表管理工具。主要功能包括：标签、彩色表格输出、报表和图形、大量的命令、底层API、多用户文件锁等功能。

curl

cURL是 一个利用URL语法在命令行下工作的文件传输工具，1997年首次发行。它支持文件上传和下载，所以是综合传输工具，但按传统，习惯称cURL为下载工 具。cURL还包含了用于程序开发的libcurl。cURL支援的通訊協定有FTP、FTPS、HTTP、HTTPS、TFTP、SFTP、 Gopher、SCP、Telnet、DICT、FILE、LDAP、LDAPS、IMAP、POP3、SMTP和RTSP。

rtorrent & aria2

rTorrent 是一个非常简洁、优秀、非常轻量的BT客户端. 它使用了 ncurses 库以 C++ 编写, 因此它完全基于文本并在终端中运行. 将 rTorrent 用在安装有 GNU Screen 和 Secure Shell 的低端系统上作为远程的 BT 客户端是非常理想的。

aria2 是 Linux 下一个不错的高速下载工具。由于它具有分段下载引擎，所以支持从多个地址或者从一个地址的多个连接来下载同一个文件。这样自然就大大加快了文件的下载速 度。aria2 也具有断点续传功能，这使你随时能够恢复已经中断的文件下载。除了支持一般的 http(s) 和 ftp 协议外，aria2 还支持 BitTorrent 协议。这意味着，你也可以使用 aria2 来下载 torrent 文件。

ttytter & earthquake

TTYtter 是一个Perl写的命令行上发Twitter的工具，可以进行所有其他平台客户端能进行的事情，当然，支持中文。脚本控、CLI控、终端控、Perl控的最愛。

Earthquake也是一个命令行上的Twitter客户端。

vifm & ranger

Vifm 基于ncurses的文件管理器，DOS风格，用键盘操作。

Ranger用 Python 完成，默认为使用 Vim 风格的按键绑定，比如 hjkl（上下左右），dd（剪切），yy（复制）等等。功能很全，扩展/可配置性也非常不错。类似MacOS X下Finder（文件管理器）的多列文件管理方式。支持多标签页。实时预览文本文件和目录。

cowsay & sl

cowsay  不说了，如下所示，哈哈哈。还有xcowsay，你可以自己搜一搜。

Linux开发者、文件系统 ReiserFS 作者 Hans Reiser 因谋杀妻子而在2008年被判入狱15年，他的两个孩子目前在俄罗斯与外祖母生活在一起，他们分别为11岁和12岁，至今仍没从父亲杀死母亲的震惊中缓过来。他们现在向父亲提起法律诉讼，寻求赔偿1520万美元。代表 Reiser孩子的Arturo Gonzalez表示，许多人相信Hans Reiser在俄罗斯或美国还有财产。他说，Reiser在其工作的项目上可能拥有知识产权。

http://linux.solidot.org/linux/12/07/10/107222.shtml

老板要在每个bug报告上加上“谁的责任”项，我如何能让他相信这不是个好主意？

看到这样标题，我的第一反应就是反对老板这样做。作为开发人员，我最讨厌有人指着我的鼻子说：这是你的责任，你写的代码出了问题。我通常会争辩，有时会恼羞成怒。但如何能用充分的论据来证明这样做法是不合适的呢？我还真没有系统的考虑过。所以，当看到有这样的一个讨论时，我马上就被吸引住了，群众的力量是巨大的，群众的思想放光芒，我从讨论中学到了不少知识，有了这些论据，当日后不可避免的遇到指责时，至少心里能找到不少安慰。下面先看看这个伟大讨论的发起人对自己遇到的问题的描述吧：

在最近的制度改革中，老板要在我们的bug跟踪单模板中加入“谁的责任”项，他认为这样能提高程序员的责任感（跟踪单上已 经有地方指明bug是属于哪个功能/用例的）。我认为这样会打击程序员的士气，导致人们相互指责，而且对于一些由于需求问题而被当成bug的情况无法填 写。

有没有其它的能反驳这种做法的有效方法？有谁知道哪里有关于这方面问题的文章可参考的？我希望能拿这些给团队的同事和老板看。我认为这种文化是不可接受的，希望能在实施前阻止它。任何建议我都十分感激。

有网友一针见血的指出这样做的弊端，就是：

如果有人认为“谁的责任”项要填的是自己的名字，他就不会报告这个bug。这个会导致团队的bug数减少。

对这样一个问题，我最欣赏的回答是下面一条：

对于这样的做法，我首先要做的是问你的老板他这样做究竟想解决什么问题。有很多显然更好的方法能解决他想解决的问题。

对于一个事情，真的需要有一个人站出来承担责任吗？如果是这样，那你的老板可能在其它什么地方出了问题。一个好的工作流程是需要多人共同参与的，在 软件正式发布前，它需要经过分析人员，开发人员，代码审查人员，测试人员。如果你们没有经过所有的这些步骤，那么严格按照这些步骤开发将是解决你的老板的 问题的最好方案。如果你们已经是按照这个流程去做了，那么，哪个个人应该为此承担责任呢？也许谁都不应该，也许应该谴责的是这些历史遗留的代码。

让人们背后议论、相互指责会引起很不好的后果，千万不要随意给人涂黑点，一旦做了就很难挽回。这样做解决不了任何问题。很少有人会故意的大意犯错误。你的老板应该自我反思，看看问题究竟是出在什么方面，看看如何能让这种错误不再发生。

这样做了后，你就能清楚的看出，如果有人在不断的犯错，这很可能是完全不同另外一个问题。

但是指stackexchange网站上最受欢迎的回答却是下面一个：

告诉他，这外行人对内行人所说的问题根源的外行叫法(如果没有专门的项来描述这个，一般会使用注释来替代)。

你可以在网上搜一下软件bug根源分析等内容，你能搜到丰富的资料来证明你的观点1, 2, 3, 4, …。

… 一个软件bug的根源通常不是在某个单个的开发人员身上(填写此项时特别要注意这点)…

这清楚的说明了为什么“问题根源”是专业的，而“谁的责任”是外行的。能说明个人责任当然很好，但有时候问题的根源会产生在开发团队“外部”。

告诉你的老板，如果需要指明一个承担责任的人，“问题根源”项应该写成这样：“编码错误由鲍勃提交，版本号是1234，吉姆在代码审查中疏漏了此错误，审查号是567”。“问题根源”项的目的就是要记录这样的内容，包括一些在开发团队之外的原因。

例如，如果一个bug是由于硬件引起的(受到谴责的应该是开发团队外的购买/测试硬件的那个人)，用“问题根源”就能很好的描述这个问题，而“谁的责任”就会导致问题跟踪线索中断。

对于其它的开发团队之外的人导致的错误也能这样记录 —— 测试错误，需求变更，管理决策问题等。比如，如果管理部门决定不投入资金制备灾难应急硬件设备，在数据中心停电宕机事件上填写“哪个程序员的责任”将毫无意义。

你遇到过这样的事情吗？你对此有何见解？