另外 Adium 其实是个非常好的开发群体，非常 active & helpful，只是项目庞大到了这样，bug tracker 里的 ticket 一多，开发者自己也很难保证代码结构足够好了。

因为最近开始使用 MSN 群 (1, 2)，但我使用的 MSN 客户端 Adium 并不能将群内发言人的身份显示出来，只能全部统一显示为群本身的名称。

其实这是 Adium 所使用的 IM 协议支持库 libpurple 在支持 MSN 协议上固有的缺陷 — 不过也不算特别严重的缺陷，因为 Windows 版本的 MSN 也只在 Windows Live Messenger 8 以上才支持，而 Mac OS X 下的 Microsoft Messenger 干脆到现在也不支持。

所以，要修复这个问题，必须从 libpurple 上打主意，然而，因为 libpurple 编译不便 (后面我会解释为什么这么说)，Adium 本身的代码仓库中只提供了编译好的 libpurple framework，编译这个 framework 的步骤则是分离出来的，要单独用 Utilities/dep-build-scripts 下面的脚本来完成。

可是问题变得越来越 tricky 了：为了编译 libpurple 的代码，必须下载整个 pidgin 的代码，但 pidgin 的代码又是用臭名卓著的 Monotone 来管理的，这直接导致下载当前代码的步骤就变得复杂无比，更不用说后面的编译了。

这还没有完，崩溃的是，Adium 虽然其他协议的支持都是直接从 libpurple 来的，但偏偏 MSN 协议最近改用了从 libpurple 中 fork 出来的 msn-pecan 项目，而 msn-pecan 又是用 git 来管理代码的……

这么一来，为了修改 MSN 协议支持并编译出 Adium，我们必须至少涉及三套版本管理系统 (Subversion, Monotone 和 git)，把 Adium 提供的一堆错综复杂的脚本找出来，让它先给 libpurple 打上 Adium 自己的 patch，然后分 ARCH 来生成 configure 并分别配置编译，最后合并成 Universal Binary 再 copy 回 Adium 的 Frameworks 目录去… 到这里我还没开始改一行代码呢！

虽然这个问题最终得到了解决，我提交的 patch 也将合并到 msn-pecan 官方的代码中去，可是这个经历仍然让我觉得颇有体会：

从 F/OSS 项目的贡献者来讲，要成功的参与项目，就必须掌握好常用的版本管理工具并了解基本的编译手段，才有机会参与到真正的代码修改中去。

而从 F/OSS 项目的发起和维护者来讲，要创造一个成功的项目，应该：

1. 避免使用怪异的版本管理工具
2. 编译步骤简单再简单，尽可能分解为可以单独执行调试的步骤，尽可能减少会在编译时出现的问题

哦对了，如果有愿意试用我修改后的 build 请在这儿 (21M, SHA1 = 16af86b349e49b35f836ed1492b52a3fe7d5d061) 下载。

首先，要安装 x264 编码库，mplayer 需要这个库才能加上 H. 264 编码支持:

$ git clone git://git.videolan.org/x264.git
$ cd x264
$ ./configure
$ make && sudo make install

注意 x264 库需要 yasm 汇编器，MacPorts 下可以用 sudo port install yasm 安装。

然后编译 mplayer (包括 mencoder)。

$ svn co svn://svn.mplayerhq.hu/mplayer/trunk mplayer
$ cd mplayer
$ ./configure # 注意输出中是否有 "Checking for x264 ... yes" 字样
$ make && sudo make install

然后就可以调用 MEncoder 了:

$ mencoder input.fmt -o output.fmt -ovc x264 -oac copy -x264encopts \
    bframes=4:b_pyramid:weight_b:pass=1:psnr:bitrate=1500:turbo=1

其中 input.fmt, output.fmt 分别是输入和输出文件，其调用格式见 MEncoder 的文档，而后面 -x264encopts 的参数制定的是 x264 编码参数，这是影响编码质量和速度的地方，文档中也有专门一节详细说明，这里选取的是一个中等偏上的效果。

• Spore 是个 Cider port，不是真正的 native Mac Game — 今年的 Neverwinter Nights 2 Mac 版给我的印象很糟
• 从 Creature Creator 来看，Spore 的角色太卡通太塑料了，让人提不起兴趣
• Diablo 3 完全没有令我失望…

现在 Mac 下真是只有 Blizzard 一家还在认真做游戏了.. 其他所有的厂商基本上都是用 Cider 来糊弄一下，Apple 是不是应该直接把每年的 ADA Best Mac OS X Game 发给 Crossover？

今天有空来试了一下解决这个问题。首先，打开 System Preferences 里的 Print & Fax，尝试添加打印机，结果发现 Windows 这里通过浏览工作组找不到打印机所在的那台计算机:

怎么办呢，开始 google，找了一圈发现原来需要 Custom Toolbar 才能找到上图中那个 Advanced，提供原来 10.4 里 Printer Setup Utility 的功能，通过直接输入 IP 的方式来配置 Samba 共享的打印机。

因为头一次用，还专门用 smbclient //IP/PrinterName 试了一下确实可以连接。

另外打印的时候还是需要输入密码的，不过对于没有设置密码的共享，可以选 Guest。

配置好了，选择打印但是打印机还是没反应，怀疑是驱动不对，原先选的是 Generic PostScript 打印机的 PPD，可是 HP 压根没有提供给 LaserJet 1020 的官方 Mac 驱动… google 了一下，找到一个很不错的解决方案：foo2zjs — 这是一套开源的驱动，给 Linux 和 Mac OS X 提供了一些缺失的打印机支持，注意网上还能找到许多相关的讨论，和另一套 1022 的驱动据说也能用，可是似乎对于共享打印机不起作用。

按要求依次把驱动和其依赖的包装上之后，在 Driver 里选择 HP LaserJet 1020 Foomatic，终于成功打印，太感动了。

其中 Tamarin 和 SqurirrelFish 代表了浏览器 JavaScript 引擎性能的提高 — Tamarin 虽然现在还不明显，因为它的 JIT 还在 tracing 优化阶段，SqurirrelFish 甚至还完全没用 JIT。不过这两者正式进入市场至少要到 2009 年 Mozilla 3 平台的初步发布和 Safari 4 随 Snow Leopard 一起发布时。

Processing.js 和 ContextFree.js 则代表了 Web-based Processing 创作的新方向，Processing 和 NodeBox 的成功充分说明了在简单技术上提供更有效的表达方式会给图形生成带来多大的改进，现在能在 Web 上直接实时呈现这些优美的图形，毫无疑问 Flash, Silverlight 等将更不受欢迎了。

Parchment 则是一个非常漂亮的 Z-Machine 在 Web 上的呈现，适合 Text Adventure 爱好者们。

近来，两个新出现的 JavaScript 框架得到了许多关注: SproutCore 与 Objective-J。表面上，它们共同的特点就是大量使用了 HTML5 特性来改善用户体验，达到类似桌面应用的效果，然而从底层分析，它们其实代表了两种对富 JavaScript Web 应用的开发方式的革命。

为什么说是“两种”呢？虽然 SproutCore 是一套几乎完全由 Apple 工程师开发的框架 — 其设计目的就是给 MobileMe 提供类似桌面应用的效果 — 但其设计思维是 Web 化的，是和现下流行的服务器端开发框架一脉相承的。从我的观点看来，SproutCore 是受 Ruby on Rails 影响严重的一套框架，其提供的工具大多用 ruby 编写，创建的目录结构都带着 Rails 的痕迹 — 甚至开发人员也是典型的 TextMate 用户。

而 Objective-J 虽然也主要是由前 Apple 工程师领导开发，可是这些工程师却是不折不扣的 Objective-C/Cocoa 狂热爱好者，他们在 280slides 表现出来的是典型的 Keynote 风格，其代码组织则是典型的 NeXTSTEP 风格。

所以，可以想见的是，SproutCore 的设计思维更容易为大众接受，而 Objective-J 很可能始终保持小众 — 甚至我都很怀疑它到底会不会发布…

It is true that some people have voiced the opinion that the iPhone SDK should have been based on languages other than Objective-C. However, it is important to note that none of these people have ever shipped an application written in Objective-C.

这固然是有道理的：倾向使用 Obj-C 以外其他语言来开发 Cocoa 应用的绝大部分人根本不了解 Obj-C (比如 John Grubber，充其量只能算是个 Perl 爱好者，还不能算程序员)。

但 Aaron 自己的视角何尝不也是带着偏见的呢？在他说下面这段话时：

It is difficult to explain how the NIB file (and a few other scary ideas) create leverage. It is that leverage that enables one guy in his basement to compete with a team of engineers at Microsoft or Adobe. It is like I showed a chain saw to a early American colonist, and he said, “Can I cut down the tree without starting the engine? I don’t like the noise. Maybe I can just bang it against the tree?”

不知道他自己有没有考虑过：他自己是否曾经尝试过用编码的方法 (Programmatically) 而不是用 Interface Builder 来构建一个完整的程序界面，如果没有，他又怎么能理解编码构建界面的优势呢？

我个人并不排斥 NIB，但关键的问题是，我相信一个完整的项目中每个元素的“可查找性 (grepability)”都是很重要的，如果能将所有的元素都用文本的方式表达，就大大方便了查找和更新，而不管是 NIB 还是 XIB，都做不到这一点。

所以说，要完全不带偏见，中立的评论一个东西，真是很难。

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers. – Dave Hyatt

如何编写高效的 CSS？Mozilla Developer Center 有这么一篇文章值得一读：Writing Efficient CSS。

借用 Helvetica 中 Massimo Vignelli 的这句话。

只是有的时候总是会有一种要被 ugliness 击倒的感觉。

登录 phpMyAdmin, 找到数据库中 wp_posts, wp_comments 和 wp_links 三个表，点 Export，选择 Add “DROP TABLE”，这样导入的时候可以自动删除以前的表。

下载下来之后，用下面的命令转换:

iconv -c -f gb18030 -t utf-8 wp_posts.sql > wp_posts.utf-8.sql

其他依次类推。然后在 phpMyAdmin 中选择 SQL，选择 wp_{posts,comments,links}.utf-8.sql 这三个文件依次 Execute 即可。

iPhone (或 iPod Touch) 是一台配备着 128MB RAM、4 到 32 GB 闪存的 667MHz 计算机 (尽管只跑在 412 MHz 上)。软件方面，它运行的是一套裁剪过的 Mac OS X，包括 Darwin 内核上基于 FreeBSD 的用户空间程序，作为其标准组件。虽然部分人可能会奇怪怎么有人会把它作为 Unix 工作站来使，但就我和其他许多人的看法，不拿它来做 Unix 工作站才是值得奇怪的。

BSD 子系统

所以给这台设备头一个安装的包是“BSD Subsystem (子系统)”也就没什么奇怪的了：这是一套标准的 Unix 实用工具，让习惯了 Unix 的开发者感到宾至如归。从 grep, sed 到 vim, pico，这套软件包提供了深夜编程活动的基础。

不幸的是，要真以这样的方式用过一会儿，你肯定会因为这些关键工具配置和编译时的缺漏而感到恼火。尽管完成到现在这样也是件好事，但对 Unix 实用工具的编译打包不应该仅仅停留在“它能安装成功”，而更应该延续到“它能正常工作”。下面是我不得不处理的一些问题:

• bash - 命令在输入完之前就会被截短并执行
• chmod/chown - 总以“memory exhausted (内存耗尽)”作为退出消息
• nc/ping - 无法解析某些域名，并声称 “Unknown server error (未知的服务器错误)”
• netstat - 无法提供任何本地 socket 的有用信息
• passwd - 损坏 BSD 的 /etc/passwd 文件，使 1.1.3 的 SpringBoard 崩溃
• screen - 无法通过 terminfo 找到 “linux” 这样常见的终端类型
• vim - 没有语法高亮，退格键会导致编辑器崩溃

所有这些问题中，仅有 chmod 和 chown 的问题在公开的“BSD Subsystem”包中被修复了，这还是因为 Apple 的 1.1.3 更新带来的巨大压力 (要求所有的软件以 mobile 用户而不是 root 运行，所以必须修改文件的权限，有些程序必须 setuid 为 root)。

然而这些问题只要有人愿意花时间都是很容易解决的，却始终停留在目前这样的状况下，导致工作效率低到了可怜的程度。比如我到现在在 vim 里按下退格键之前还要犹豫一下下，就是因为用了那个损坏的版本开发了几个月所带来的后遗症。所以总得有人来改进吧。

CoreOS - iPhone Unix

剩下这些问题的一部分已经由一名叫 core 的 iPhone hacker 解决了。在他网站的 Unix Tools 部分一直提供了这些改进版本的程序，比如 chmod 和 chown (不过他提供的 passwd 还是坏的)。而在 Network Tools 部分他一直致力于改进 wget 和 ping 等有问题的工具。

可是要安装 core 这些改进过的版本必须分别手工找到、下载并安装修改过的文件：这些工作做一回还好，但三四次 jackbreak 之后再做就肯定觉得非常麻烦了。而人们不一定总是从 core 那儿获得更新，导致实际分发的二进制程序会有区别，因而跟踪起它们的行为来也就分外困难。

最后的一个原因是，core 总是没有时间把他如何神奇地修改这些软件代码的过程写下来，也没有把它用来编译的命令贴在网站上，所以别人没法知道这些问题是怎么被修正的，要修正其他类似的情况是也无法借助他的工作。

一套开放的替代品

为了缓解这些问题的困扰，我决定开始一个名叫 Telesphoreo 的项目，目的是以合作的、开放源代码的方式，给 iPhone 创建一套基于 GNU 和 BSD 的用户空间程序集。这个项目的名字来自于一个古希腊词汇，意思是“使果实成熟”，这正是我对 Apple 这个现有产品的想法：作为电话它是合格了，但要作为个人工作站它还远远不够。当然，要创建这样一个发行，还得使用正确的工具。

为了发行软件，我选择了 Debian 的 APT 系统，这是我在少量修改以配合 Apple 的网络设置后移植到这个平台的。为了方便大量用户的迁移，我还花时间用 UIKit 写了一个 APT 的图形界面，名叫 Cydia (Cydia pomonella 是苹果蠹蛾的学名，而苹果蠹蛾……就是我们常认为的苹果蛀虫，我觉得这个名字挺合适的)。

为令这个项目能够自举 (bootstrap)，我先是移植好了百余软件，从 bash 到 xeyes 的所有东西，包括一系列的支持库和脚本语言 (包括比 Installer 提供版本功能更强的 Ruby 和 Python)。所有为编译所作的代码修改，以及编译整个项目的脚本，都通过 subversion 库 提供。

虽然不是所有的东西都能正常工作，但我已经完成的部分肯定比原来 BSD Subsystem 提供的有了很大进步，也只在很少情况下会比 core 所提供的版本要糟 (不过这个情况很快会解决，因为 core 已经准备将他的更改贡献进来)。如果确实遇到了问题，我建议人们在项目的 Trac 上提交缺陷报告。

如果谁希望出来担任某个现有软件包的维护者，或者提供其他新程序的移植，请加入邮件列表 (译注: 邮件列表还未建立，请通过 IRC 联系作者)。尽管现在是这个新发行版唯一的维护者，我当然不希望一直这样 (既因为缺少对很多领域软件的经验，也因为本就不可能一个人把所有事情做完)。

安装过程

从用户的角度讲，只要将 http://apptapp.saurik.com/ 加入 Installer 的源 (source) 中，然后从它的“System”分类中安装“Cydia Packager”就可以了。你应该在安装前暂时禁用设备的自动锁定 (auto-lock) 功能，因为这个安装过程可能会花上好几分钟。

在安装过程中，下面这些操作会依次进行:

移除 BSD 子系统的旧文件

要替代 BSD 子系统，就得先把它删了，不幸的是在 Installer 里它是不能删除的，所以 Cydia 包管理器只好直接删除所有它安装的文件。不必大惊小怪，就算你非得要回 BSD 子系统，也完全可以用 Installer 来“Reinstall (重装)”它一遍。

重组文件系统以提供足够的空间

为了使升级 iPhone 固件时不会丢失个人数据，Apple 将 iPhone 的存储空间划为两个分区，分别挂载在 / 和 /private/var (它被符号链接到 /var)。前一个分区只有 300MB，所有 Apple 的软件都放在这里。可惜的是第三方软件也必须安装在这里。

为了缓解空间不足的问题，如果安装 Cydia 时发现你在另一个分区 (也就是 4-32GB 里那剩下的部分) 有足够的空间，并确信这些文件并未被 BossTool 这样的工具移动过，就会将你所有的 Applications (应用程序), Wallpapers (墙纸), Fonts (字体), Ringtones (铃声) 和 Shared data (共享数据) 通通移动到那个较大的分区中，原来那个就多出了 150MB 的空间。

安装 Cydia 和 Telesphoreo 基本包

这一步完成后会占用大约 35MB 的空间，并提供了一套常规的 Telesphoreo 子集，以供安装更多的软件包，或者升级已经安装好的部分，又或是执行一些核心的管理操作如运行终端，另外这套子集还能支持现有应用程序对旧有 BSD 子系统的依赖 (我自己、还有许多测试者们一道，给这些依赖库开了一张清单)。

上述的这三个步骤都完成了之后，以后 Cydia 自身和所有的 Telesphoreo 更新都将通过 Cydia/APT 进行，因此你不妨时常打开 Cydia 刷新来源信息看看有没有什么最新的软件。关于更新的更多信息会在下面的使用说明一节介绍。

如果过程中出现了什么错误，你可以提交一个 bug 报告 (要先注册并登录这个站点) 或者来 irc.saurik.com 的 #iphone 频道报告，我平日都在这个频道上边，就算我哪天要出门也至少会查看一次上面信息，又或者是直接给我发邮件请求帮助。(请只在前两个办法不合适的情况下才发邮件，因为前两个都能让其他看到的人帮上你的忙，以节省大家的时间。)

“伪” BSD 子系统

要注意：Telesphoreo 本身不依赖 BSD 子系统，所以如果你目前没装，也没有任何理由在装 Telesphoreo 之前装上 BSD 子系统，而更重要的是，安装过了 Telesphoreo 之后，如果你再尝试安装 BSD 子系统，则会损坏装好的 Telesphoreo (它会用就软件替换你的新系统)。而且，你还应该避免 BSD 子系统的升级 (upgrade)，因为其实这和重装没什么区别，同样会把 Telesphoreo 中关键的组件替换成旧的。

如果你刚刚 jailbreak 完自己的 iPhone/iPod Touch，不必安装 BSD Subsystem，装 Cydia Packager 就够了。如果某个包要用到 Cydia Packager 缺省没有提供的功能，你完全可以以后用 Cydia 装上。

这样和 BSD 子系统包的基本冲突进一步导致了两个需要用户了解的问题：第一个是 BSD 子系统日后的更新都会列在 Installer 的 Updates 中，所以用户有可能会误装这些有问题的旧软件；第二个则是有些软件会在安装前要求 BSD 子系统已被安装，否则它们自己的安装就不能继续。

希望 BSD 子系统会逐渐退休，而那些对它有需求的包则会在未来数月内更新为更聪明一点的检查 (比如判断自己需要的具体是哪些文件)。与此同时，Telesphoreo 也提供了了一个叫做“伪” BSD 子系统的变通方法，它和真正的 BSD Subsystem 的 bundle identifier (Mac OS X 用来甄别软件包的标识符) 一致，但本身不包含任何文件。只要装上了这个包，那些要求 BSD Subsystem 存在才肯安装的应用程序就能顺利装上，还能抑制 Installer 偶尔出现的那些——让你更新 BSD Subsystem 的请求。

虽然我会尽量保持伪 BSD 子系统的版本号和原始那个包的版本号对应，但可能还是会慢上几天，所以 Installer 可能会提示你有 BSD 子系统的更新。你必须避免更新，稍等几天，新的伪造版本就会出现，Installer 的更新提示也就自然会消除了。

Cydia 的使用

一般说来，Cydia 用起来和 Installer 差不多，都是为了让人们快速装上新软件的。主界面由底部的一排按钮组成，让你在下列几个页面间切换。

特色 (Featured)

这个页面是在 Cydia 一启动就显示的，其实是一个包含 Cydia 和 Telesphoreo 使用的相关新闻的站点，还列出了近来一些有趣软件包。虽然目前它只有唯一的页面，不过会迅速成为程序中的一个浏览窗口，让你访问到软件包相关的站点和更详细的信息。

安装 (Install)

在这里你可以按目录的形式浏览未装的软件包，或依分类序、或依字典序。(目前软件包的分类名称还比较混乱，所以如果见到某些怪异的分类，请稍作适应。)

更新 (Changes)

一般你会关心的两件事是：“我已经安装的软件包有没有更新”和“最近更新过的软件里有没有我想装的”。这个页面里就把这两种情况组织到一起了：已装软件的更新显示在上部，其他所有未装软件则按更新时间逆序列在下方。

这第二种使用方式类似 Installer 的“Recent Packages”分类，不过有两点重要的改变。第一，你可以回滚到任意时间点，而不仅仅是查看最近几天的更新。之所以支持这个功能，是因为只有 Installer 的死硬 fans 才会频繁地保持几天一次地查看最近更新，否则就有可能漏掉一些重要的新特性。

第二，一个包只在你第一次看到它之后才被算作被“加入”了，而不是按照它本身加入软件仓库的时间算。这一点也很重要，只要你添加了一个新的软件源，那它的库里所有的包都该被认为是“新”的。这样的定义还能避免每次软件库管理者修改包定义时又把它们推回列表的前头：只有没见过的包才能算是“新”的。

卸载 (Uninstall) 或管理 (Manage)

更为普通一点的 Cydia 使用是找出你已经装过的软件，然后或者重新配置或者重新安装。“Uninstall”界面就是为了这些情况设计的，之所以这么命名是因为 Telesphoreo 目前没用到 APT 的配置 (configuration) 系统，而 Cydia 当然也就不支持。如果这个界面以后有了更多的功能，可能会被改名为“Manage”以更好的表达其特点。

搜索 (Search)

最后一点，你经常会听说某个软件包但不确定它具体叫什么名字，又或者是你希望通过包描述中的信息找到特定功能的软件。这时就要用到“Search”了。只要输入一个字符串它就能依软件包的标识、名称或者描述将匹配的结果列出。

最后还有个放在顶部的界面元素：一个让 Cydia 与所有来源进行本地 APT 数据库同步的刷新按钮。另外顶部还显示了上次同步的时间。我希望以后这个更新的过程能被精简掉：当用户不用 Cydia 的时候同步可以自动在后台进行。如果实现，顶部这栏就完全可以去掉了。

管理来源 (Manage Sources)

Installer 中存在而 Cydia 里没有 (因为 Search 占用了空间) 的一个界面是“Sources”。虽然还没实现出来，但我们的计划是让你在 iPhone 的 Settings 程序里选择这些来源，而不必塞在 Cydia 的界面里。这种交互方式和 Apple 的 MobileMail 比较类似，其中你的帐号也是偶尔在 Settings 里设置了但通常都在 Mail 里访问的。

目前 APT 在 /etc/apt/sources.list 里维护了一个软件来源列表，你可以通过修改它来添加新的来源 (在管理来源的功能实现之前)。还有一个叫做 /etc/apt/sources.list.d 目录用来存放单独的 .list 文件，这样每个都可以简单地通过诸如 Installer 包的形式来安装卸载。

作为过渡，所有屏幕的左上角都有一个带圈的小 i，表示目前缺少的这个功能，并允许通过它你临时把来源添加到 APT 的配置文件中。(如果这带来了什么不便，我很抱歉。)

为何不用 Installer？

我完全能理解的一个质疑是，为何选用 Debian APT 并开发 Cydia，而不是直接用 Installer 来管理所有 Telesphoreo 中的软件包。考虑到 Installer 已经是 iPhone 上经典的软件分发方式：它是几乎所有自动 jailbreak 方式安装的第一个，也是唯一一个软件，并有大量的软件仓库支持，这些仓库一起提供了大量的软件包。

不幸的是，Installer 并非开源软件，就算有这么个许诺，也完全看不到任何相关的发布计划或者其他兑现的方式。Cydia 的源代码则已经提供了出来而其他项目 (比如 MxTube) 也正因此受益。我们也希望 Cydia 能借助开放源代码的优点，迅速得到第三方的补丁或者贡献。

所以一旦考虑到 Telesphoreo 开放的特质，我们实在找不到还用 Installer 作为其安装程序的理由。不过即便如此，这一点还一直是本项目争议最大之处：很多人都来问我，为什么非得创建一个“新”的应用程序分发系统 (APT 的移植) 而不是直接用现成的广泛存在的 Installer。而且，他们对于以后开源的许诺也被用作不要分散 iPhone 开发者精力的理由之一。

我觉得最好的回答是提供看问题的另一个角度：Cydia/APT 和 Installer 并不冲突。我在自己的 iPhone 上这两个程序都会用，也有大量用 Installer 装上的软件。目前为止也没有听说任何要求安装 BSD 子系统的程序因此出现什么兼容性问题，也没有任何理由这么怀疑。最后一点是：完全没有人——包括软件打包的人员和用户——被强制去用 Cydia 来替代 Installer。

我觉得一个关键的问题是人们觉得觉得 Installer 实现了他们以前未曾见过的功能：从许多来源、以单一界面提供了简便地程序安装管理。虽然在 Mac OS X 和 Windows 这两个 iPhone 用户集中的平台上都没有什么这方面的经验，但包管理的概念可一点也不新：几乎所有的 Linux 和 BSD 发行版都依赖着它。再说 Mac OS X 和 Windows 上还有 Fink 这样的第三方软件提供类似的功能 (顺便说一句，Fink 正好也是基于 APT 的)。

因此我专门写了一篇对包管理方式的快速剖析 (译注: 中文版见 AppTapp 的打包问题)，并解释了一些这类系统的复杂情形。这篇文章还包括我个人作为软件打包者在使用 Installer 时遇到的挫折，希望它能阐明高级软件包管理中会遇到的那些问题，以及尝试开发 Telesphoreo 这样一个雄心勃勃的计划意义何在。

总结性评论

尽管有这些问题，我还是相信 Telesphoreo 和 Cydia 对 iPhone 社群会有很大的帮助。就算有人不同意其中某个具体实现上的选择，将关于移植应用程序和库的信息收集到一起也能方便我们把更多高质量的软件带到这个平台上。希望能如我所愿吧。