问：你们到底打算如何将所有这些与操作系统联系起来？而且如何在不让整个系统变得缓慢的情况下做到这一点？
答：负责颜色反应的代码可以（而且应该）直接绑定到 /proc，或者绑定到可以为你监视 /proc 的东西。灯或信标的颜色更新应该以每秒四到六次的频率发生，这是最佳的。是的，我做了功课，是的，我真的坐下来做了计算。如此频繁地更新灯或信标的颜色不应该花费太多精力。
设置一个监视 /proc 的 watchdog 进程（而不是直接访问 /proc）可以实现跨网络远程监控其他系统等功能，这是最初 InSight 计划的一部分。
问：这将会占用多少 CPU 时间？
答：如果做得好的话，几乎不占用 CPU 时间——不比在网页上动画一个 GIF 文件花费的 CPU 时间多。但是，我也可以想象，当打开多个窗口，或者桌面上存在许多信标时，CPU 消耗会相应增加。当然，CPU 负担永远不会严重到对机器造成不必要的阻碍。
问：我还没有完全接受这个想法。颜色反应对我来说似乎更像是一种噱头，而不是真正有用的东西。说服我，它不仅仅是花哨的东西。
答：你有多少次遇到应用程序莫名其妙地锁定，没有任何出错的迹象，而没有挖掘进程列表或查看“top”来找出发生了什么？ 你有多少次不得不面对一整个屏幕的进度窗口，所有窗口都有自己的进度指示器？ 有多少次你被烦人且碍眼的弹出窗口告知你何时完成某些事情？ 你有多少次想一眼就知道你正在运行的东西是否表现良好？ 颜色反应桌面元素可以快速而优雅地缓解所有这些问题。
问：GNOME 为什么要将这个想法纳入设计中？
答：有很多原因。 首先，这将使 GNOME 与其竞争对手区分开来，因为它对传统 GUI 进行了创新（更重要的是，新的）改进。 Linux 需要通过解决当代用户在处理 GUI 时通常面临的问题，将自己与所有臃肿、空洞的承诺和其它平台固有的炒作区分开来。 颜色反应是一个有用的想法，相对容易实现，并且只需要最少的系统资源即可完成。 最重要的是，它非常酷。
问：如果最终在一个屏幕上打开了大量窗口，并且由于必须不断更新所有这些小灯而导致系统开始变慢怎么办？
答：一个聪明的程序员会编写负责处理颜色反应的代码，以便这种情况永远不会发生。 如果屏幕上的灯和信标的总数超过已知阈值，则应降低更新它们的频率，以补偿它们对系统造成的负载——简单的负载均衡。
问：颜色反应对用户有什么好处？
答：灯和信标以快速、一目了然的方式提供有关程序状态的信息。 相同的概念也可以应用于整个系统，以提供有关硬件和操作系统状态的类似信息——不仅仅是应用程序状态。发挥你的想象力，你就会开始明白如何将整个概念几乎普遍地应用于任何操作系统/GUI。
问：你是从哪里想到这个主意的？
答：我没有。 这个想法多年来一直在以一种或另一种形式存在，具有不同的预期用途。 我只是坐下来长时间思考了一下，并为完善过程添加了我自己的见解。 我们最初认为我们是第一个（在 InSight 内部）提出这个想法的人，但后来的一些挖掘显示，我们的想法原来是过去十年左右不同人提出的两三个独立想法的略微变体。 在我们的例子中，这个想法的灵感来自 Taco Bell 颜色变化的 Dennis Rodman 杯子。 你可以让他的头发颜色改变以反映饮料的温度。 因此，颜色反应诞生了。