两块250GB的硬盘用得还只有170GB，到底用来装什么了？看了一下，各种媒体文件用掉了100GB，各种软件也七七八八地用掉了120GB。无论如何，资源总要分享才最好。于是动手在自家服务器上做IIS，最新版本的IIS7。加了几个虚拟目录，一切都挺不错的。测试下载了一个RM文件，外网连接速度达到40KB/秒。似乎问题不大了，但突然发现，同样的URL想访问一个RMVB文件，居然报HTTP 404错误——这是很不可思议的，404错误可是文件不存在的错误啊，但它确实存在！如果存在之物被由于某种原因被判定为不存在，那么换言之就此物被取消了其外部性。正如黑洞一般，事件视界至IIS7访问接口处止。那末，什么是存在？
哲学探讨容后，看了一下连接时的错误信息，多少发现了一些可称为线索的东西。好像是什么MIME类型未注册之类的原因，解决方案是手动编辑一个看上去像XML的文件，不过语法很有些演化过头的趋势，特殊符号的使用方式相当矫揉造作。为什么不能提供一个图形化界面的选项呢？有技术含量的事就非要用高技术化的手段完成不成？总之，我暂时放着它没有管它，等过几天看看有没有顺手的工具再说（也许Internet Information Services 7.0 Manager是一个不错的选项，但还未及检视）。
接着，看到了不错的一个消息：IIS7的新FTP部件——FTP7终于发布了RTM版本。没话说，马上下载安装。果然用户体验不错，但很快就发现完全不能外部访问，只能对防火墙规则做了一些修改，方才把这个服务给运行起来了——得亏我还练过。家里的网络已经到了我绝对忍无可忍的地步，似乎从ADSL调制解调器到无线路由到无线网卡到网络连接线统统有问题，软件方面也频频发难，令人搞不懂是DNS服务器（同时也是域控制器和全局编录）还是DHCP服务器（无线路由的固件）还是活动目录出了错。构建一个长期稳定可用的IT基础，尤其是网络基础，是多么不容易啊！
不禁想到我几年前为SONORO搭建的网络服务，居然直到现在还在顽强地、24×7地提供服务。采用的服务器是Windows Server 2003，部署了Service Pack 2，硬件条件很可怜，用的是赛扬的芯片和杂牌的主板（到现在应该还没有升级）。邮件服务器是Exchange Server 2003，部署了Service Pack 2。公司一共有20台左右的客户端，全部使用Windows XP专业版，部署了Service Pack 2，而且分布在数个不同的城市。现在想想，那套服务器软件是多么成熟啊。
但总要进步的，Windows Server 2008来了，Exchange Server 2007来了，IIS的新版本来了，Windows Vista也来了。升级，还是不升级？这是一个问题。新版本带来新体验，这一点确实能够从细节到体会出来。比如，在IIS脚本出错的时候，它不会像先前的版本那样不问青红皂白地把详细的调用堆栈信息dump出来，而是只向特定Group的用户dump这些信息，而对外部用户则只是给出简单的错误描述。但是，新技术为了实现更多的选项、更精细的控制，一定会提出更多的概念来让用户理解，而原先的简单模型已经分裂了。如果这种情况下没有提供一系列体面的默认值，新技术就带来了明显的学习和适应成本。Windows Vista现在已经变得相当不错，尤其是在Service Pack 1发布以后。但是若说它完全可用，容我直言，怕还需时日。我已经在《电脑报》上撰文指出Windows Vista是一个过渡性产品的命运。我们不断地追逐新技术，但实际上，可能已然可用的旧技术才是真正的解决之道。它们应该总有退役的一天，但是在它们仍然能用并且好用的时候，也许我们不应该太过激进。其实，过快的升级不仅让用户不知所措，对于开发者而言怕也是苦不堪言。在FTP7的说明文档中，我们看到了下面一段无奈的告白：
Why two FTP servers? The IIS team ran out of time. The one available with Windows Vista or Windows Server 2008 is essentially the same FTP service from IIS 6.0. When you select the FTP service to install in IIS 7.0, you are actually setting up the previous IIS 6.0 Manager, in addition to the compatibility tools necessary to run it on Windows Vista or Windows Server 2008.
何必匆匆至此？现在局面难免有些混乱了，哪个FTP服务是自带的？如果已经使用了老旧的FTP服务（那个使用了相当晦涩的所谓元数据库的过时结构，很容易出错而且出错时简直让人一筹莫展），如何把累积性的数据导入新服务？这些事情不知会给微软的支持部门带来多少浪费的口舌。再举一例就是Exchange Server 2007居然不支持Server 2008（就是Exchange Server 2007 Service Pack 1想支持也很费劲，至少我现在还没有一次搞定它，但在Windows Server 2003上装Exchange Server 2003是没有任何问题的），这同样也明显是发布日期迫使开发人员不得不精简了一些必须完成的开发任务。如果研发部门在开发方面都对时间的捉襟见肘，那么对测试工作的彻底性又如何保证？长此以往，肯定会影响核心层面的软件质量。
新技术，对用户和开发者来讲都很难。生活本应该更惬意，不是吗？让我们珍惜已经有的，已经位于舒适区间的，这样不好吗？当心不要陷入技术方面的老鼠赛跑困境，这比金融和财务方面赛跑的老鼠怕是只有更傻的份儿。
发表回复