好,坏,和阿维

上周二,Apple公布了这一消息Avie Tevanian正在接受新冠军“首席软件技术官”,即Bertrand Serlet担任软件工程高级副总裁该公告还表明,这一变化不仅仅是名义上的,而且Serlet将承担公司大量软件项目日常管理的责任。这个消息可能看起来有点像一次改组,但我认为不是。

Serlet于1989年加入NeXT,从那时起一直在Tevanian(和乔布斯)工作所以这并不是说他突然出现,或者他的晋升会以任何方式表明Apple软件的方向或优先级发生了变化。

但人们可以希望。

Tevanian对Apple软件的管理工作一直是个混合体总的来说,他做了大量的工作但是在他出错的地方,他已经非常错误,闪现了恶意的连胜,这在很大程度上不利于Mac OS X的整体可用性。

好的

Tevanian最大和最深刻的成功是项目管理自1997年承担Apple软件的责任以来,大型项目按计划发布,或者非常接近。

不可否认,Mac OS X的首次亮相比原先陈述的时间长了几年,而且大部分延迟可归因于Tevanian授权的设计选择(下一节将详细介绍这一点。)但它最终确实发布了,这本身就是一项值得注意的成就苹果公司此前曾多次尝试为原始Mac OS创建可行的继任者,而Mac OS X是唯一一款出货的产品。

但Mac OS X成功的一个重要方面是,它不仅仅是出货,它带有明显的动力它在性能和可用性方面变得更好 - 稳定且定期首先是公共测试版,然后是每个发布版本从10.0到10.2(很快,10.3)。

每年一次主要更新时间表是Mac OS X成功的一个重要方面人们普遍认为,Mac OS X并不仅仅是好的,而是它的优点并且越来越好这种看法似乎不仅由Mac社区举办,而且由计算机行业共同举办。

And for all of Tevanian’s widely-noted antipathy towards the traditional Mac OS (once again, see below), it was under his management, post NeXT-merger, that Mac OS 8 through 9.2 shipped, restoring momentum to a platform that had stagnated for years从1998年到2001年,经典的Mac OS与Mac OS X所遵循的每年一次主要更新时间表相同,与20世纪90年代早期到中期的System 7形成鲜明对比。

事实上,从1998年到2001年,Apple正在积极开发两个主要的操作系统,两者都是成功的这是一项重大成就虽然Tevanian和他的NeXT外籍人员肯定花费了大部分时间和精力在Mac OS X上工作,但Tevanian仍然最终负责发布Mac OS 8-9,并且值得称赞即使他的直接角色只不过是把球放在了辉煌的长期Mac工程师的球场上基斯·斯坦滕菲尔德(Mac OS 9项目的领导者),事实仍然是,在Tevanian成为v.p后,传统Mac OS的状态得到了显着改善软件工程。

Mac OS X的当前时间表与业内其他所有桌面操作系统形成鲜明对比最值得注意的是,微软的Windows采用更长,更整体的更新计划XP,它的最后一次重大更新,于2001年底发布,下一次更新,Longhorn,至少要到2005年或2006年才会出现Many people have compared the features of Apple’s Panther (10.3) to Microsoft’s Longhorn, but why? Even if Longhorn does ship in 2005, Apple will likely have shipped two major updates豹在同一时间。

Longhorn肯定比XP的任何单点升级都要好得多,但是在相同的四年或五年期间,哪个系统会有更多改进?

Mac OS X成功的增量更新计划证明了Apple的软件工程管理以及Mac OS X的模块化架构Tevanian当然至少应该获得一些信誉最终结果是每个人都获得了胜利 - 用户可以更快地获得改进的软件,而Apple每年都会获得新的销售和推广。

然而,Tevanian的遗产因Mac OS X的可用性缺陷而受到损害,其中大部分原因都归功于Tevanian几乎不屈不挠地痴迷于推广旧的NeXT技术而不是旧的Apple技术他的技术敏锐性可能是无可争议的,但他的可用性也不容乐观。

这个缺陷的臭名昭着是臭名昭着的技术说明#2034,标题为“Mac OS X编程指南”,如MDJ由Tevanian亲自撰写技术说明#2034是如此煽动性,并且在某些地方如此滑稽的,苹果公司在专业Mac开发人员嘲笑之后撤回了它。

它仍然下降,因此缺乏与它的联系可从以下URL获得技术说明#2033和#2035(“如何使用ATSUI API获取字形轮廓”和“Mac OS X上的ColorSync”):

http://developer.apple.com/technotes/tn/tn2033.html
http://developer.apple.com/technotes/tn/tn2035.html

[更新:我发布了一个PDF archive of Technote #2034]

但#2034在apple.com上无处可见并且有充分的理由技术说明#2034,表面上是一系列关于如何编写更好的Mac OS X软件的指南,实际上只不过是对Mac技术的教条E.g.: Mandating filename extensions in lieu of genuine type and creator metadata for “compatibility”; recommending against using HFS metadata at all, because doing so causes performance issues for UFS disks (no matter that UFS is a vastly inferior disk format); promoting Objective-C as a more portable cross-platform language than C++; and, most laughably, recommending the use of hard-coded pathname APIs for accessing files, rather than more flexible, friendly, and traditional Mac APIs which access files by file ID.

Mac开发人员往往是独立思考者,并断然拒绝了Tevanian的“指南”的规则。

特瓦尼安的决定和法令常常是教条而不是务实例如,决定围绕Mach内核而不是Apple自己的NuKernel构建Mac OS X.The problem, such that it was a “problem”, is that NuKernel was developed at Apple before the NeXT merger; whereas特瓦尼安自己共同创造了马赫他在20世纪80年代中期担任卡内基梅隆大学的研究生。

我并没有声称NuKernel在各方面都是完美的,或者优于Mach我无法做出这样的判断但是从各方面来看,使用NuKernel而不是Mach的想法从未被Tevanian考虑过,无论它可能具有什么优势。(For one, superior power management, a continuing weak spot in Mac OS X.) NuKernel, remember, was designed from the outset as a kernel to power future PowerPC-based Mac operating systems; Mach wasn’t如果Apple使用NuKernel,Mac OS X可能会更快地出货,这当然是可以想象的。

然而,这种内核八卦是猜测在其他领域,Tevanian的决定对Mac OS X的可用性产生了明显的不利影响前面提到的文件扩展名shenanigans或者前面提到的使用基于路径的API来访问文件的警告,这些建议直接导致Apple安装程序在您移动或重命名任何应用程序时无法正常工作,更糟糕的是,臭名昭着的iTunes 2.0安装程序崩溃导致整个卷被删除 - 可能是Apple历史上最严重的错误,而且只需使用传统的Mac OS文件访问API就可以避免这种错误。

简而言之,Tevanian的许多设计决策都没有考虑到Mac用户的最佳利益希望Serlet能够比Tevanian更好地使用可用性,或者如果没有,那么他足够谦虚地将这些决定委托给那些做过的人。

以前: 独立日
下一个: 寻找阿维