1、图形化≠易用性

很好的例子就是UML。

2、自动化≠易用性

显然自动化的目的是为了易用性，但并不是所有的自动化都能够带来正面效益。以Hibernate为例，一旦自动化的设计超出了普通人的心智模型，往往会带来负面影响。我曾写过一篇批评Hibernate的文章，也引起了很大的争议，我承认只要有足够的时间和足够的细心，存在能够把Hibernate学到精通的人，但在现实的环境中，影响到时间和细心程度的因素实在太多了，有时我们不得不为Hibernate的这种复杂的自动化说埋下的隐患买单。

那么什么才是好的易用性，这个话题又可以谈很多，这里只归纳一条：Simple is Best.

附：UML正日薄西山的13个理由

编者按：UML开发社区最近流失了一批开发者和拥趸，对一种软件设计技术来说，这意味着它正趋于下滑。而且它的发展趋于一个不利的方向：UML已经开始变得官僚化。本文作者罗列13个理由，以此来分析为何UML正日薄西山。

由委员会设计

从长远来看这是导致语言或技术失败的一个主要和常见的原因，CORBA就是最好的例子。

过分注重商业化

试图为一门不够成熟的技术出售工具而且只对工程的管理部门承诺什么，这只能是一种短期有效的方法。有时候人们会认识到这样的成本远大于收益，这也让程序员在本能上非常厌恶。另一些人因为工程管理部门的要求或好奇心而尝试这些工具，但大都使用不超过一个工程就弃用了。

太过激进地想把几乎一切都涵盖起来（UML规范超过800页）

当你试图为一个领域内的每个问题都提供一个解决方案的时候，最终你会发现其实你没有提供任何有效的解决方法。UML试图解决所有与软件开发相关的问题。试图涵盖一切是一个不可能的任务，即使规范有800页，UML也只是覆盖了复杂的软件工程领域的一部分。

背离了开发者的最初目的

作为一名程序员，我喜欢UML为设计通讯等内容而提供的标准化，能够使用一套通用的符号来与其他的程序员或者设计师交流我的想法真的很棒。我想大多数程序 员仍然只是使用类图表，或者在他们写一份文件的序列图时偶尔用一下。然而，UML开始使用那些即便是商务人士都不懂的面向商业的类图表。

概念膨胀

在过去的10-15年里，UML一直试图概括所有流行语言的概念。现实么？

总在追赶新的语言和概念

承接上一点，既然UML承诺全语言的代码生成，就意味着它必须包含每一种特殊的语言架构。

试图成为一门编程语言

由于能够生成全代码，所以实际上UML试图成为一门编程语言，而一种通用的图形编程语言存在很大的问题。在人类历史上，所有语言的手写形式都是从图 形到文本，在捕捉和传递思想方面，字母表证明比图像更具表达力。如果试图用图形描述每个流程，那必须还得使用语言来注释这些图形。图形在形象化人们的思维 和概念方面确实有效，但是在描述细节方面语言更有效。

需要昂贵的工具还是只需要一个文本编辑器

要想真正地UML入门，要求很高，他们需要训练，因为他们不是时时刻刻都在使用最直观的工具。咨询公司会喜欢UML的这一特性，因为这意味着昂贵的培训课程。

缺乏模型清晰度（model clarity）

图形读不懂我听到很多开发者在理解UML图解的设计时发出这样的抱怨，最终不得不通过读代码来理解。

缺乏真正软件设计的问题解决方法

UML规范很多，却没有软件系统常见问题的好的解决方法。随便举个例子：

没有多任务和任务间通信的解决方案；

没有用例（use cases）之间的依赖

假设你在写第一行代码前就知道一切

编写使用手册，然后在此基础上顺利成章地生成代码但这可能无法实现。由于在实践中一切都是动态的，所以UML图表如果要与代码保持一致，它的维护就变得非常麻烦，开发者对此很反感。

对待软件开发就像对待制造业

软件设计不是制造业，软件创作是一种创造性的活动，更加是工艺或者艺术。UML试图标准化和形式化开发者的想象力和才智。

UML工具的目标错误

大部分的UML工具承诺代码生成，然而大多数时候它们都是没用的，因为只是生成了没有逻辑的空的类别本体。而且这很笨重和繁琐，因为开发者必须保持代码和图表的同步。有开发者不得不使用丑陋格式的评论来进行标记。

这些工具的另一个问题是屏幕上呈现的有效图表元素的数量。很多次我查看一个UML图表或者一个复杂的系统，但只能看到一角，根本无法帮助全局的理解。

而且，很多使用UML完成的工程，其最终的代码与最初的UML图表并不一致。

我也不认为代码生成是个好主意，一般来说生成的都是复杂的代码，而大部分工程可能使用库中的公用代码更好。

你怎么看待UML呢？

其他的不说了，就拿最近传言的CN域名必须在公司名下和落实不备案不予解析这两条政策来说，我的这个网站也不知道还能坚持多久，也许明天就会倒下。

http://www.findvps.cn

  AppArch Beta测试期间推出特惠型VPS主机:
  * Xen
  * 512MB内存
  * 25GB RAID1 硬盘空间
  * 1个独立IP
  * 100Mbps网络端口 400GB流量
  * Linux
  168元/月

  推荐联系方式
  我们推荐您提交服务单联系我们，以便我们能高效、安全地处理您的问题。

  其它联系方式
  Email: 售前咨询 sales@apparch.net 技术支持 support@apparch.net
  MSN: apparch@live.cn

基本上vi可分为三种操作状态，分别是命令模式（Command mode）、插入模式（Insert mode）和底线命令模式（Last line mode），各模式的功能区分如下：
1． Comand mode：控制屏幕光标的移动，字符或光标的删除，移动复制某区段及进入Insert mode下，或者到Last line mode。
2． Insert mode：唯有在Insert mode下，才可做文字数据输入，按Esc等可回到Comand mode。
3． Last line mode：将储存文件或离开编辑器，也可设置编辑环境，如寻找字符串、列出行号等。
不过可以把vi简化成两个模式，即是将Last line mode也算入Command mode,把vi分成Command 和Insert mode。

进入编辑状态：i
退出编辑状态：Esc
到第一行：gg
到最後一行：G
到某一行：xxG
到行首：0
到行末：$
复制：yy
贴上：p
复原：u
删整行：dd
删除全部内容：dG
显示行数：:set nu
不显示行数：:set nonu
搜寻：/、再次搜寻：n
储存：:w
离开：:q
储存兼离开：:wq 或 shift+zz
强制离开（不储存）：:q!

1、云计算确实是一个众说纷纭的概念，也许下次把范围限制在云计算基础架构或者具体的虚拟化技术可能更好些。

2、国内已经有不少先行者开始研究、开发云计算服务了，时不我待，这也是最近很少更新博客的原因。

关注云计算的可以加QQ群：87833826

图一：TR引擎平台软件架构图
具体各技术及模块的目的和作用为：
显卡加速用户界面生成程序以及运行引擎 (PowerGT Engine)：组合、构建、并利用显卡硬件加速渲染用户界面的布局元素，能够和其他部分如三维渲染引擎有机结合；
二维角色动画的辅助生成及显示技术（Power2D）：基于基本的骨骼结构模型，结合预制的动画模板生成逼真的物体运动动画序列或过程，可在二维实时渲染中回放；
用户界面及场景集成开发环境(PowerGT Studio)：包括项目管理、图形资源管理、可见即所得的编辑器、发布功能模块的集成开发环境等。能够使非程序员也能有效的利用引擎技术制作严肃游戏的界面及逻辑；
二维场景及角色编辑工具（Power2D Editor）：Power2D技术的编辑工具，生成特定格式的动画文件；
三维渲染引擎(PowerVS)：基于显卡加速的三维模型渲染引擎，支持贴图映射；
三维角色动画辅助生成及显示技术（PChar）：基于基本的骨骼结构模型，结合预制的三维动画模型生成逼真的物体运动动画序列或过程，可在三维实时渲染中回放；
复杂流程及逻辑的脚本解释、运行引擎（PScript）：支持人物、对话、逻辑、流程等模拟脚本的编写及解释，提供相应的接口支持，可以直观、简洁的表达静态、动态的模拟过程；
基础网络通讯协议及开发接口(PComm)：基于Socket和HTTP协议，提供网络化分布式的软件部署，支持动态传输游戏内容和逻辑，能够减少客户端安装大小，可以为用户简化部署成本，同时在商用环境中避免作弊行为；
物理模拟引擎（PPhX）：基本的重力、碰撞、加速、变形的模拟，支持更逼真的环境下的虚拟体验；
通用服务器端模拟引擎技术（PowerServer）：支持链接数据库，动态调度显示资源、三维模型、模拟逻辑以及用户特定的数据等，是网络化运营的服务器核心组件。同时支持服务器硬件以及并行计算能力，可以允许将来的大规模运用。

Robbin和Robin
除了Matz的演讲，Robbin的JavaEye网站架构解密和来自财帮子的Robin Lu的Ruby On Rails Pitfall也是相当精彩，ThoughtWorks咨询师郑晔的企业开发中的Ruby/Rails差强人意，其他的就不说了，具体大家看视频吧 。

网络监管与云计算
Robbin演讲的时候发生了个小插曲，网监打电话来要求删除某个帖子，否则就要拔网线了，国内的互联网环境实在是...最近在考虑云计算在国内的发展，技术不是问题，最大的问题还是在网络监管，在云计算这种模式下一拔网线还不是全瘫痪了。

多语言多平台
大会中反复出现多语言、多平台共同解决问题的例子，看来这已经成为一种趋势，我们所要做的就是用合适的工具做正确的事。

大QA
由于除了Matz以外的嘉宾演讲后没有安排提问时间，在下午演讲结束后举行了大QA环节，也就是把全部嘉宾请上台来接受大家的提问。Matz提到了Ruby 2.0将在一年内发布，由于赶火车，没有结束就匆匆离开了会场。

其中1和2都是虚拟硬件模式，是真正意义上的虚拟化技术，通过虚拟一套完整的硬件，这一套完整的硬件具有超强的兼容能力，在这个虚拟层上可以运行各种不同的操作系统平台。半虚拟化需要修改宿主操作系统的内核，因此比全虚拟化有更好的性能。现在的趋势是vmware在发展半虚拟化的技术，而xen也在发展全虚拟化的技术。而操作系统虚拟化事实上不是真正意义上的虚拟化技术，但由于能够达到类似的功能，也把它归为其中。操作系统虚拟化技术要求虚拟机和宿主服务器上使用同一个操作系统，通过拦截虚拟机的操作来实现隔离，也就是说在windows下只能再虚拟windows，linux下只能再虚拟linux，虚拟安装一个的操作系统仅仅占用200M的空间，其他文件都是使用宿主机上的文件。一般我们把1和2的虚拟化服务器称为vm，把3称为vz。

既然vm和vz都能达到我们的目的，那这两者有什么区别呢？
vm：占用系统资源多，因此成本高，虚拟的操作系统不受主机操作系统的限制，稳定性、安全性高。
vz：占用系统资源少（你想想一个服务器上就算有100个vps也只有一套操作系统，一台服务器上的所有VPS都共享部分操作系统资源），成本低，只可以虚拟和主机的操作系统一样的操作系统，性能好。

一般相同配置的服务器上能能够建立30-40个vps那么只能建立10-20个vm，这也就是相同配置vm往往比vps价格贵一倍的原因。

对vps性能、稳定性影响最大的是内存，下面看看在内存方面两者的区别：
vm：支持虚拟内存（交换分区）
vz：不支持虚拟内存（交换分区），只要一超过就容易死机之类的。

所有的OpenVZ的VPS都不支持虚拟机自己定义虚拟内存，而基于Xen技术的主机可以。OpenVZ系统里面所有的虚拟机共享一个内核，而虚拟内存是需要内核支持的，所以OpenVZ里面的虚拟机都不能再定义虚拟机级别的虚拟内存。OpenVZ可以在母机操作系统里设置的虚拟内存，但在虚拟机看来就是真的内存，加上虚拟机共享资源可以动态调配，所以OpenVZ主机可以超卖。

有种说法：运行同样的程序,如长时间运行sql server，vm需要512M就能稳定了，而vz最少需要1024M才会稳定。为了弥补虚拟内存上的缺陷，vz引入了一个爆炸内存（Burst RAM）的概念，允许短时间内占用超出分配大小的内存。那么这些内存是哪里来的？显然是占用了同一台服务器上其他用户的空闲内存。并不是说vm在内存方面就一定比vz好，vm的虚拟内存理论上可以设的很大（局限于硬盘容量），但会增加对IO的读写，而vps毕竟不是独立的服务器，在这方面有所限制，因此也不宜设得过大。而且虚拟内存毕竟比不上Burst RAM那样真正的内存的速度。

再从商业运营的角度看看两者的区别：
vm：vm的解决方案使得每个vps独立性很好，分配了多少资源就是多少资源，不存在超卖现象。
vz：从前面的Burst RAM就可以看出vz的隔离性并不好，你可以占用同一台机器上其他vps的资源，这也就给服务商浑水摸鱼的机会，往往存在超卖现象，一台服务器本该40个vps，卖到了60、70个，性能（本该是vz的优点）、稳定性都很难保证。另外，安全性上也存在风险。

因此外在因素一样的情况下(配置,价格等)，vm的肯定比vz的好。但一般vm要贵些。服务器以稳定性为主，所以大多数客户会用vm的vps，国外的一些数据中心也同样是这个技术，国内一般是vz！

如果看了上面这段文字后还不是很清楚，我觉得这个用户的体验更生动些：
http://zealy.spaces.live.com/blog/cns!3E882EE246E7E0A5!354.entry
http://zealy.spaces.live.com/Blog/cns!3E882EE246E7E0A5!355.entry

http://www.douban.com/group/vps/

参考资料1：

3种大型邮件系统的比较

关于sendmail/qmail/postfix孰优孰劣，以及部署邮件系统的时候该选哪一个的讨论已经重复了千百次了。但事实往往并不是A好B坏，或B好A坏，必须根据场合和应用的要求来定。但虽然如此，大多数人还是需要一个相对公平的评价，以引导邮件系统的部署。

自己一直很慎重于回答这类问题，以免引发不必要的争论甚至矛盾，但还是必须面对这个问题做一定的分析和比较的，否则很多朋友经常会问“到底用哪个好？”，却拿不出完整的答案。

首先看看三个MTA的历史

Sendmail
毫无疑问，sendmail是最古老的MTA之一。它比qmail和postfix要古老得多。最早它诞生的时候，Internet还没有被标准化，当时主机之间使用的是UUCP技术来交换邮件。它被设计得比较灵活，便于配置和运行于各种类型的机器。

Qmail
qmail是新生一代的MTA代表，它以速度快、体积小、易配置安装等特性而著称。作者D. J. Bernstein(djb)是一个数学教授，富有传奇色彩。djb于1995年开发qmail，1996年发布0.70版，并使用了多种当时比较先进的技术，包括Maildir，与sendmail单个binary不同的模块化设计，权限分离，以及使用了大量由djb编写的配套工具，如daemontools，ucsip-tcp等。qmail迅速成为了Internet上最有名的MTA，使用者众。

Postfix
Postfix作者是Wietse Venema，一名著名的安全专家。最早postfix起源于1996年，当时venema 在美国IBM研究中心负责研究更安全的邮件系统，当时称为Vmailer。后因为商标问题于1998年11月正式更名为Postfix。Postfix以替代sendmail为目的，并提供了一个更安全、更高性能的灵活的体系。它同样也采用模块化设计，使用了大量优秀的技术，以达到安全的目的。由于作者的设计理念独到，经过7，8年时间，Postfix现今已发展成为功能非常丰富，扩展性和安全性强的优秀MTA。

概括的比较
以下的分析主要基于我在CASA上发的一个小文章，对sendmail/qmail/postfix做了一个概括性的比较。
sendmail
sendmai功能非常强大，很多先进功能在sendmail上都最先有实现。sendmail里的Milter技术是一个非常好的框架，目前postfix及qmail仍然没有官方发布的方案比milter要好。但sendmail也有典型的历史问题，只有一个binary程序，需要sid权限，m4配置文件复杂难懂。这些是是阻碍sendmail更好发展的一些客观问题。客观来说，调教得好的sendmail，其性能也是相当不俗的，据一个国外的Unix杂志称，在solaris+内存文件系统+带电池的raid系统下，sendmail能达到惊人的287封/秒的注入速度！目前sendmail比较适合那些老用户，因为他们习惯了sendmail的应用环境和配置。

qmail
qmail体积非常小巧，source的gz包大概只有260多K，是三大MTA中最小的！模块化设计，避免了sid问题，基本功能齐全。配置相对sendmail而言，简单了很多，而且用户非常广泛。而且补丁和插件非常多，例如著名的vpopmail，netqmail，以及qmail-ldap等。但qmail有几个问题，一是djb已经5，6年没有继续开发了，补丁的良莠不齐及版本依赖是非常麻烦的事，这对初学者极为不利。二是功能扩充需要补丁来完成，扩展能力不足。总体上qmail依然是个非常不错的选择。对于希望了解mta原理，或希望修改mta代码的爱好者，qmail是值得推荐的。对于需要建立中小型邮件系统的用户也同样适合。而对于需要丰富功能却不想面对补丁困难，或者需要建立大型的系统，qmail不太合适，需要更丰富的经验和技术。

postfix
postfix如今已经独树一帜，流水线、模块化的设计，兼顾了效率和功能。灵活的配置和扩展，使得配置postfix变得富有趣味。其主要的特点是速度快、稳定，而且配置/功能非常强大，并和sendmail类似，提供了与外部程序对接的API/protocol。尤其是配置部分，可以说是一扫qmail和sendmail的各自缺点。但postfix管理及配置的入门依然需要一定的工夫，必须仔细阅读官方文档。postfix另一个优势是至今依然保持活跃的开发工作，而且稳步发展，适合高流量大负载的系统，扩充能力较强。

大规模应用例子
国内若干个大型email ISP（如163.net/tom.com/163.com及sohu等）过去都使用qmail，后来全部更换成postfix。新浪使用qmail，yahoo使用qmail。但这些已经不是普通的qmail了。

技术层面的分析
这里仅探讨一些典型的技术特点，从这些特点可以看出每个MTA设计的异同，主要讨论的焦点是qmail和postfix。

磁盘I/O
从队列文件的读写来看，qmail处理每一封邮件时，都至少需要建立3个文件，mess, intd, info等。而Postfix使用的是单队列文件设计，因此磁盘I/O的开销要比qmail小得多，如果仅仅从这个方面考虑，postfix的队列是qmail的2-4倍那么快。从我过去的一个qmail vs postfix对比测试中，也可以发现这个问题。

数据同步
如果从MTA对待操作系统的文件是否安全写入磁盘的策略来看，qmail和postfix也是不同的。Postfix使用的是随机写，并且需要写入完成并安全同步到磁盘后才算完成。而qmail的写入则是即刻执行的，因此它将等待数据安全写入磁盘后才返回。对于高流量的系统而言，这将导致性能问题。此外，Postfix的队列对于FreeBSD的softupdate是安全的，而qmail则是不安全的，qmail作者明确警告用户不要使用softupdate，除非是有磁盘后写电池。

扩充能力
sendmail有着非常好的扩充能力，支持众多的特性，功能可谓豪华。包括频率控制到集群支持应有尽有。而milter API则更加使sendmail的灵活性发挥至极，通过milter，用户可以对邮件几乎所有的参数进行控制！但是在存储方面，由于只支持mbox，会有一定的问题。

qmail在系统容量扩展上有着独到的设计，配合qmail-ldap补丁，可以充分利用qmqp及分布存储的优势。现今已有各式各样的qmail扩展方案，最著名的是qmail-ldap。但qmail缺乏类似milter的设计，功能扩展需要各种补丁，而补丁的设计水平参差不齐，配置能力有限。实施起来相对是最复杂的。

Postfix同样有着非常好的容量扩充能力，利用LMTP或transport的/alias的方法，可以分布式的存储邮件，扩充容量。同时postfix的功能扩展也非常强，通过灵活的配置即可实现复杂的功能，这是其最突出的优点之一，是qmail望尘莫及的。此外，类似sendmail的milter，postfix拥有content_filter和policy 两个与外部程序/应用对接的接口，但不如milter那样功能集中和灵活，也没有完整实现qmail的qmqp及类似qmail-ldap的机制。

可配置性
sendmail 使用m4语法，单一的主配置文件（sendmail.cf）是三个mta中最难使用的，但是如果熟悉使用的话却能实现复杂的功能。qmail使用的是大量小配置文本，格式最简单，每个配置一个文件，存放在/var/qmail/control目录里。postfix也使用单一的主配置文件（main.cf），同时还有对应master主服务进程的配置文件master.cf，但使用的是简明易懂的key = value 格式。总体而言，qmail的配置文件较易管理（格式最简单）但配置文件多（10个以上），而postfix的格式简单只有2个配置文件，并配备强大的postconf工具，sendmail的配置文件最复杂。

数据库支持
sendmail通过一些插件/补丁，可以支持mysql/pgsql/oracle等，ldap及小型的dbm/cdb等数据存储格式。qmail默认只支持cdb，需通过补丁才可支持ldap，mysql，pgsql及oracle等。postfix可以支持的数据库应该是最多的，默认就包括了mysql/pgsql/ldap及dbm/cdb和cidr/nis*/btree等一堆。还支持特殊的tcp_table(仅在snapshot里支持)

稳定性/负载能力
sendmail, qmail, postfix都比较稳定。在高负载下，配置不佳或没有打足够补丁的qmail容易被DOS攻击打跨，而postfix在遇到超过配置的限制时会降低处理能力，但系统依然有一定资源可用。

参考资料2：

Sendmail的不足

无论从使用的广泛程度，还是从代码的复杂程度来讲，sendmail都是一个非常优秀的软件。如果使用它来构建网站的电子邮件系统，基本上不必费心，因为几乎所有的Unix的缺省配置中都内置这个软件，只需要设置好操作系统，它就能立即运转起来。然而，Internet用户的要求更为苛刻，纷纷指出sendmail中包含的各个不足之处。

第一个重要的缺点是它的安全性较差，这是因为当其作者Eric Allman最初开始写作这个软件的时候，Internet的用户还很少，因而安全性并不没有得到大家的重视。由于邮件系统需要处理的是外部发送来的各种各样的信息，甚至包含一些恶意数据，然而sendmail在大多数系统中都是以root身份运行，一旦出现问题，就会对系统安全造成严重影响。在这种情况下，要防止出现安全问题，仅仅依赖程序本身是不可取的，应该从系统结构出发，使程序拥有的特殊权限限制到最小。

此外，也是由于其早期的Internet用户数量及邮件数量都相当小，Sendmail的系统结构并不适合较大的负载，对于高负载的邮件系统，需要对Sendmail进行复杂的调整。例如，通常情况下sendmail只启动一个进程顺序向外发送邮件，如果邮件较多时就要花费相当长的时间。

使用Sendmail还会遇到的另一个问题是它的设置相当复杂，对于使用缺省设置来收发电子邮件，问题并不存在。当管理员打算进行一些特殊设置，以便利用Sendmail提供的复杂邮件处理能力时，就不得不面对复杂的宏和正则表达式。虽然现在Sendmail使用了宏预处理程序m4使设置更易于理解一些，但是掌握Sendmail的设置仍然是对系统管理员的一大挑战。

使用Qmail替代Sendmail

为了解决sendmail的安全问题，整个系统结构需要重新设计。基本的原则是将系统划分为不同的模块，有负责接收外部邮件的，有管理缓冲目录中待发送的邮件队列的，有将邮件发送到远程服务器或本地用户的。Qmail就是按照这个原则进行的设计，它由多个不同功能的小程序组成，只有必要的程序才是setuid程序(即以root用户权限执行)，这样就减少了安全隐患，并且由于这些程序都比较简单一些，因此就可以达到较高的安全性。

这种按照Unix思路的模块化设计方法也使得Qmail具备较高的性能，因为如果需要，Qmail可以启动某个模块的多个实例来完成同一个任务，例如启动多个发送程序同时向外发送邮件，这对于提供邮件列表服务的邮件系统是非常有益的。这种方式也使得Qmail要占用较大的网络带宽，如果带宽有限，效果反而不好，但在当前网络性能大幅度提高的情况下，这种方式是非常合适的。

Qmail还提供一些非常有用的特色来增强系统的可靠性，例如，它提出了Maildir格式的邮件存储方式，这使得通过网络文件系统NFS存取邮件成为可能。此外，Qmail还具备一些非常别致的特色，它不仅仅提供了与Sendmail兼容的方式来处理转发、别名等能力，还可以用以Sendmail完全不同的方式来提供这些功能。从它的编译安装方式、提供的扩展功能和源代码的风格，可以看出其作者Dan Bernstein是一个极具个性化的程序员。正因为如此，对于Qmail的某些方面，有着一些争论，例如有些人认为Qmail的安装设置并不易于理解，很容易让人糊涂，而另一些人的看法则相反。基本上这是因为Qmail提供解决问题的方式，和Sendmail不大相同的缘故，这样对那些不太熟悉Sendmail的邮件系统管理员，反而更容易接受Qmail一些。

另一种替换软件:Postfix

Postfix同样也是采用了模块化的方式，但与Qmail不同的是，Postfix使用了一个主控进程进行监控。Postfix在很多方面都考虑到了安全问题，它甚至不向root分发电子邮件，以避免以root身份读写文件或启动外部程序。考虑到它的作者Wietse Venema曾编写了著名的安全软件TcpWrapper，并是SATAN程序的合作人员之一，Postfix的安全性是非常值得信赖的。

同样，Postfix的性能也非常不错，甚至在Qmail作者自己进行的测试中也表明，Postfix的性能和Qmail基本相当。但Postfix占用的内存要大一些，这主要是由于Postfix和Qmail在系统结构上的差异造成的。

与Qmail不同，Postfix更着眼于作为Sendmail的直接替换，使用Postfix替换Sendmail却相当简单，因为Postfix使用的很多文件和Sendmail一致，只需要在配置文件中指明原有Sendmail配置文件的位置就可以了，Postfix甚至还提供了sendmail和mailq程序，以保持兼容性。基本上，可以直接从Sendmail转换为使用Postfix，而不需要额外的设置。Postfix提供的安装配置方式也相当简单，它使用中心化的配置文件和非常易理解的配置指令。

Postfix提供的一些强大的功能主要在于多种数据库表查询方式，例如它支持DB、DBM、passwd文件、正则表达式、MySQL数据库以及LDAP方式的查询，用于支持系统级的别名、虚拟主机等。虽然在Qmail中也能支持这些功能，但没有象Postfix那样统一、简洁。此外，更改Postfix的设置之后，也不需要重新启动整个系统，只需要使用postfix reload就能完全刷新配置，这也避免了丢失邮件的可能性。

事实上，除了Qmail和Postfix之外，还有很多种邮件系统，例如Smail、Exim等，然而毫无疑问Qmail和Postfix是其中最优秀的，也是Sendmail最有力的竞争者。此外，还有一些商业邮件服务器产品，但一般情况下，购买商业邮件服务器软件大部分是冲着其提供的服务或者是附加功能来的，例如群件产品通常带有很多额外功能用于办公环境等。

至于在Sendmail、Postfix和Qmail之间进行选择，基本上依赖于用户自己的偏好。有些人喜欢Qmail提供的复杂特色，而有的人希望对Sendmail的替换能简单一些，也有人不打算更换，而坚持使用Sendmail的最新版本。对于一个熟悉Unix系统而又愿意改善邮件系统性能和安全性的管理员，应该转换为使用Postfix或Qmail，除非对Sendmail非常熟悉而保持了特殊的感情。在Postfix和Qmail之间，它们各自有一批忠心拥护者，选择哪个都是可行的。不管选择哪种邮件系统核心，都需要选择过硬的专业电子邮件系统厂商提供完善的技术支持服务，除非您本身有强大过硬的技术力量，否则，您将面对的是一场恶梦。