不需要在一些直观的位置上具有真正的内容；只有开发团队需要这些内容。有些内容对于其他用户来说可能并没有太多意义，所有的 TiVo 软件都位于 /tvbin 和 /tvlib 中，但是很多程序的配置文件都位于 /opt/tivo 中。更传统的 Linux 文件系统的布局应该将这些文件放到 /opt/tivo/bin、/opt/tivo/lib 和 /opt/tivo/etc 中。
来看一下 Tcl 脚本，我注意到它是由 /tvbin/tivosh 解释的。这可能是一个 tcl 解释器。但是稍等一下，它实际上是一个符号链接，链接到一个名为 tivoapp 的程序。很多不同的程序都会链接到 tivoapp 上。它看起来就像是一个包含多个不同程序的统一的二进制文件。为什么要这样编译程序的原因并不非常直观 —— 它可以降低内存的使用，或者可以让系统更难以崩溃。
混合与匹配
非常值得注意的一件事情是 TiVo 具有一个非常松散的 shell 脚本、Tcl 程序和二进制程序的组合。查看一下程序，就可以了解到该程序到底做什么。例如 installNFS 脚本，是使用 bash 编写的，它调用 text2osd 来显示消息。这个脚本中甚至内嵌了一个 Tcl 脚本！
对于开发来说，Linux 的一大魅力就在于它可以自由地混合并适应开发工具的要求，例如 TiVo 就充分说明了这种优点。
系统启动
与任何 Linux 系统一样，TiVo 也会派生 /sbin/init，后者又会查看 /etc/inittab 的内容来确定要执行哪些操作。它所做的第一件事情是运行 /etc/rc.d/rc.sysinit，后者又会运行诸如 StageA_PreKickstart 和 StageG_PostApplication 之类的目录中的文件。它们都是按照顺序来执行的。
每个这种目录中都包含很多的脚本，这些脚本的名字类似于 rc.Sequence_150.CheckForDebug.sh。这些文件与常见的 Linux 系统上的 /etc/rc.d/rc3.d/S12sshd 文件类似。注意 shell 的扩展顺序（例如 rc.Sequence_*.sh）用来确定这些文件的执行顺序。如果一个脚本的名字中包含字符串 .Platform，那么它就只能在所匹配的硬件上运行。
对于供应商来说这是一个很好的设计，因为他们并不需要为每台机器都构建不同的磁盘。.Implementation 和 .Implementer 标记与此类似，它们用来标识只在某些系统上运行的脚本。Stage 目录替换了 rcN.d 目录，后者在 TiVo 系统上已经不存在了。
这种组织方式使查看在启动的每个步骤中到底执行了哪些功能变得相当简单。有趣的是，这些 shell 脚本被引入了父 shell 中，这样，早期的脚本就可以为以后的脚本设置一些环境变量了。
结束语
TiVo 是众多不同 Linux 哲学中一个非常迷人的例子，它还在不断发展，与公司通过向用户销售服务和提供简单健壮的应用程序来赚钱的哲学形成了显著的对比。黑客发现的最有效的很多特性可能是让其他人不能使用完全定制的系统的客户技术支持，同时纳闷它们为何不能工作。
从另外一方面来说，现在已经进行了大量的努力来使得对系统的攻击更加困难。早期的 TiVo 系统通常被修改成 Web 服务器。我正在查看的一个特性正如任何人都了解的一样，不能用来运行新内核；也不可能不经过对硬件（PROM，用来检查对软件的未经授权的修改）的攻击就对系统进行大量的改变。
值得一提的是，尽管 GPL 要求 TiVo 必须公开自己的内核源代码，但是并没有不让它们构建一个不许您做任何更改的运行 Linux 的系统。这种系统有趣的方面在于，了解系统如何来实现自己的功能，以及如何使用各种开源工具和技术来构建一个嵌入式应用程序。
|
