有人爱看拳击，有人就不爱看。但如果拳击赛的结果与你的切身利益有着重大关系，那你就不得不关切地去看。
　　
　　在差不多每一次的IT采购过程中，企业的IT决策者都不得不在相互竞争的两种技术中做出选择:押大还是押小?他们力图把这种风险减至最小，并且希望能够有某种备份策略，然而，在一些关键点上还是必须做出抉择:在相互竞争的技术中，谁的TCO最小?哪种技术会长期存在下去?新技术带来的好处能否抵消因为技术迁移而造成的业务中断?
　　
　　本文为在IT采购中必须做出抉择的用户挑选出了7组针锋相对、可能会一决雌雄的技术，并且结合了专家或实践者的点评，希望对用户的抉择提供有益的帮助。
　　　
　　1、Windows VS. Linux
　　　
　　Windows与Linux之间的对抗由来已久，也被很多人所津津乐道，然而真实情况却没有多少戏剧性，两者之间的对抗其实只是在不太重要的场合进行。双方互有输赢。
　　
　　希望观看血拼场面的观众可能要失望了，因为两位格斗者的激烈格斗看来正逐渐演变为一场温文尔雅的表演赛。举例来说，几年前，Windows客户机就可以通过Samba软件从Linux服务器上共享文件，域的集成也在研发之中。
　　
　　在Windows一端，微软SFU(Services for Unix)3.5的发布表明，微软正打算提供与现代Unix系统相似的外观。SFU的NIS(网络信息服务)和NFS(网络文件系统)均已相当完备，其Unix工具集甚至包括了Perl和Korn外壳。事实上，这些工具将随Windows Server 2003 R2正式交付。
　　
　　很多企业并没有把所有的网络服务强制集成在一个平台上，而是可能在一些关键区域部署Linux服务器。任何明智的企业IT经理一般都会根据实际情况在设计新的网络时把Windows和Linux都包容进去。
　　
　　从过去的经验来看，如果一个企业网内已经有几台Linux服务器的话，它们一般都是孤立地处理单一的任务，与Windows所提供的服务很少有关联。而今天，Samba 3已可提供真正与Windows动态目录的集成，更容易配置经过目录认证的Linux Web服务器、FTP服务器、文件服务器，尤其是数据库和网络管理服务。
　　
　　与之相反，微软和动态目录这一端步伐缓慢的改进却没有取得多大进展，虽然动态目录环境与Linux一道工作已经可以提供DNS和DHCP服务，但是其管理却并不容易。
　　
　　至于文件和打印共享服务，则两家互有千秋。对绝大多数情况而言，这两种平台均适用。
　　
　　那么Linux平台选择谁家的产品好呢?Red Hat一直浸淫于企业级应用，但是Novell的SuSE追赶的步伐也相当快。在Linux阵营中，对某个软件商的忠诚度几乎和对微软的反抗程度一样强烈，这往往会使事态变得有些混乱。选择哪家的Linux产品最终通常不得不在ISV这一级别做出。只要你的数据库厂商支持谁家的产品，那么你就应该选择这家的产品。这一点对于微软的产品来说也适用。
　　
　　就产品选择而言有一个好消息，那就是Linux项目的开发现在可以不经许可、在开放社区支持的试验系统上快速进行，然后再迁移到需要许可的、有厂商支持的成熟产品上去。当然，假如企业的系统管理员相当专业，也可以不需要厂商支持的产品，但是对于企业的关键任务系统来说，最好还是选择有厂商支持的产品。
　　
　　说到系统管理员，一般情况下都是找Windows的管理员要比找Linux的管理员容易一些，但是前者专业水平提高的机会却要比后者小很多。而尽管Windows表面上看似乎更容易配置和安装，但实际上要实现动态目录却需要相当完备和成熟的技巧，Windows管理员常常不能胜任。
　　
　　之所以出现这种情况，是因为微软的MCSE认证有些缩水，尽管Windows Server 2003的认证考试要比NT 4或Windows 2000详尽得多。而Red Hat的RHCE(Red Hat认证工程师)则需要通过非常累人的8小时的实际应用考试，通常只有20%的及格率。
　　
　　至于一直在拖累Linux的许可证问题目前已有了明显的减弱征兆，运行成本可能会成为焦点。Linux的TCO究竟比Windows高还是低，要取决于企业的网络和应用，以及管理员的水平。而且还有一个不能回避的问题是，网络如果因为病毒而导致崩溃，这种成本到底应该算到谁的头上。Windows和Linux之间的这场决斗大多数情况下都是在暗中较劲，激烈冲突的场景并不存在，明智的企业应当两边下注——要知道，这场格斗最终只会让企业的网络变得更完善。
　　
　　2、传统软件 VS. 软件服务
　　
　　当LAMP(Linux、Apache、MYSQL、Perl/PHP/Python)中间件的后起之秀Active Grid的CEO 和创始人Peter Yared意识到他需要一个项目管理软件来协调公司的研发业务时，他对微软的Project 2003进行了测试。
　　
　　这个测试没拖多长时间。Yared在其博客上以疑虑的口吻写道:“2003???这程序是不是3年没人修改过了?”而且，其性能和功能也无法满足他的需求。于是Yared便转向了Basecamp，这是一个Web应用，同时还可为目前很流行的Web应用框架Ruby on Rails提供试验场所。结果如何呢?Yared写道:Basecamp“没治了!”
　　
　　近十年来，我们已经体验到了通过Web分发软件的好处:无须安装、平台独立性、不限地点/不限时间的使用，还有与时俱进的更新等。但是其缺陷也同样明显。基于浏览器的应用与传统软件丰富的交互性、瞬时的反应，以及离线使用等显然无法相比。不过现在被称为AJAX(异步JavaScript和XML)技术的复兴已经让前两种缺陷开始消除。基于浏览器的应用由于有了DHTML(动态HTML)也具备了高度动态性能，早已能够与远程XML服务进行自动式交互。这些功能正在逐渐成为事实上的跨浏览器标准，让新一代的Web应用具有了比更多人想象中更丰富、更迅速的交互反应。虽然离线使用仍然是个问题，但网络越来越普遍的连接性已经降低了这个问题的严重程度。
　　
　　把传统软件——需要人工安装和配置——与全新的软件服务模式之间的差别定义为一场决斗是很有意思的。当然，从实际来看，情形可能更为微妙。一个强有力的AJAX类型的应用，比如Google的GMail，虽然不需要传统意义上的安装过程，但它却需要在每次使用时对代码进行更新。那么，正在更新的代码会与缓存中的代码发生冲突吗?我们不清楚。同样地，与Java应用和.Net应用集合相比，动态JavaScript和XML的此类问题也不会少。
　　
　　尽管还没有出现标准的本地存储模式，但各种存储机制还是有的。IE 5引进了一种有限的存储性能，称为“userData特性”;Tibco的通用接口，也是一个强大的AJAX应用，可利用缓存来储存和读取XML文件;BEA的Alchemy项目，旨在对浏览器可使用的XML数据进行格式化，尽管该项目尚未正式推出，但其设想却是合理的。
　　
　　最终，各种方法——包括基于浏览器的应用、异构环境的Java小应用或Flash组件、Java Web Start和.Net ClickOnce按需技术等——都必须提供同样的性能:普遍的覆盖性、丰富的功能、安全的执行，以及对本地存储内容的安全访问。在这四个前沿上展开的这场格斗，目前还看不出谁会胜出。不过2005年AJAX的进展表明，浏览器无可比拟的覆盖性与其毋庸置疑的丰富性可能是相互关联的。
　　
　　当然，我们也看到了旧有的安全问题怎样重新浮出水面，这是我们在Firefox修正版的HTTP客户机功能易受攻击而不得不暂时舍弃它的时候发现的。这里不存在什么新的东西，不存在对于Firefox或者一般说来对于浏览器方式的特殊的安全性。如果我们想把软件作为服务，并确信能够实现这一点，那我们仍必须继续面对交替使用传统的部分受信任的软件和按需下载的软件的问题。