在九月刊的最佳技术支持专栏中，我对其中的两封信特别感兴趣。

John Barnitz 写道，他的上下旋转磁盘有问题。如果他的磁盘是 SCSI 磁盘，在许多情况下（例如，Adaptec 控制器），可以在控制器设置中将其关闭。现代主板上的另一种方法是禁用一些节能设置。

Are Tysland 写了关于 su 和安全性的问题。我试用了一段时间的 sudo，但现在我正在使用 su1（也在 sunsite 上）。使用 sudo，只能允许或禁止用户或指定用户组的命令。使用 su1，您可以控制参数，例如，用户 A 只能挂载 CD，而用户 B 或组 B 可以挂载磁盘。您可以使用此工具控制几乎每个参数和命令。我不相信为 su 用户设立单独的组，因为您必须在使用前切换组。如果您在使用 su 后不切换回来，您可能会遇到问题。

—Martin Fuerstenau，德国比尔姆 tomcat@hannover.sgh-net.de

Ted Kenney 在第 42 期中发表的Grundig 电视通讯文章在第 54 页最后一自然段的最后一句话中包含一个小错误。DPT 没有开始分发由第三方开发的 Linux 驱动程序。他们所做的是开始将 Linux 列为受支持的操作系统，并将他们的网站链接到我的 EATA 网页。（我是 DPT 控制器的 EATA-DMA 驱动程序的作者。）

—Michael Neuffer neuffer@trudi.zdv.Uni-Mainz.DE

我只想说我非常喜欢 R. K. Owen 在 1997 年 7 月的 LJ 上发表的文章（免费）在美国域名注册。按照 Owen 先生精心阐述的步骤，我尝试向 berkeley.ca.us “委托机构” Cliff Frost cliff@ack.berkeley.edu 注册域名。回应完全没有效果，几个月后我仍然没有注册到我请求的域名。

整个美国域名注册系统似乎都在美国邮政服务的水平上运作。（嗯。等等，这不客气了。与这些人相比，美国邮政服务简直是天才。）

例如，今天早上我访问了页面：http://www.isi.edu/us-domain/，并尝试使用基于网络的注册表单，因为伯克利的委托机构没有回应我。点击“基于网络的注册模板”并到达 URL：http://www.isi.edu/cgi-bin/usdomreg/template.pl，我收到了“未找到”消息。

看来 R. K. Owen 使用的加利福尼亚州圣何塞委托机构组织得更好。我希望您的其他读者在使用这篇文章的程序时比我更幸运。

继续从Linux Journal提供好内容。

—Robert Lynch rmlynch@best.com

十月刊很棒，但有一个小错误——我在第 33 页上的电子邮件地址是错误的[使用 Python 进行互联网编程书评]。应该将 djohnson@olympus.net 更改为 dwj@aaronsrod.com。

—Dwight Johnson dwj@aaronsrod.com

现在你们真的做到了——我的意思是第 42 期，1997 年 10 月。

一个外观精美的封面，文章内容丰富，提供了答案和大量相关评论，所有这些只需五美元。我需要花几个小时仔细阅读这东西。Linux Journal 不断改进。继续保持。我甚至可能会有一天订阅。

—John Whipple johnboy@sonic.net

我想纠正回应者的断言，即 Xforms 在 Linux 中不可用于 a.out 格式。[致编辑的信，1997 年 10 月，John Brown，“XForms 文章”]

FTP 站点 ftp://einstein.phys.uwm.edu/pub/xforms/ 包含一个 linux/ 目录，其中有两个子目录，一个包含 ELF 发行版，另一个包含 a.out 发行版。旧版本 0.81 和较新版本 0.86 都以两种格式表示。

此外，测试子目录包含最新的测试版本 (0.87.2)，格式为 a.out 和 ELF，因此驳斥了开发人员将不再支持 a.out 的断言。

—Martin John Bartlett martin@nitram.demon.co.uk

我非常喜欢 Luis A. Fernanades 撰写的题为xmotd：编写自由软件 [1997 年 10 月]的文章。阅读关于程序员为自由软件做出贡献并支持其他用户的文章是一种乐趣。这就是我切换到 Linux 的真正原因。请继续推出这样的文章。

—Steven J. Hill sjhill71@inav.net

LJ 关于 Pgfs 的文章真的很棒——写得很好，内容丰富。[Pgfs：PostGres 文件系统，Brian Bartholomew，1997 年 10 月。] 这是使用我们最喜欢的操作系统解决问题的一个很好的例子。感谢您包含关于不起作用的信息；它和起作用的信息一样有趣。

LJ 很快成为我最喜欢的杂志。

—Eric C. Newton ecn@smart.net

十月刊第 30 页的表 1 根本不是“Alpha 芯片系列摘要”。[Linux 和 Alpha，David Mosberger]

David Mosberger 在 Alpha 文章中表示 gettimeofday() “返回当前实时，分辨率通常为一个计时器滴答（在 Alpha 上约为一毫秒）”，这让我感到惊讶。 gettimeofday() API 允许一微秒的分辨率，而 i386 上的 Linux 为您提供了这一点（得益于以大约一百万赫兹递增的硬件计数器）。快速查看 2.0.29 内核源代码 (arch/*/kernel/time.c) 向我表明，gettimeofday() 在 i386、m68k、mips 和 ppc 上为您提供高分辨率，但在 Alpha 或 SPARC 上则不然。是否有计划解决这种不公平现象？

—James R. Van Zandt jrv@vanzandt.mv.com

不，不是。正确的表格打印在下面。

我认为您提出了三个不同的问题：<\n>1. “典型”分辨率是什么意思？ 2. 具有一微秒的 gettimeofday() 分辨率是否足以满足我想讨论的测量类型？ 3. Linux/Alpha 是否支持比 1 个时钟滴答更精细的分辨率？

答案

1. 对于用户 X 来说，“典型”是用户 X 碰巧拥有的东西，我想。但说真的，传统的 gettimeofday() 实现提供了计时器滴答分辨率。API 显然总是允许高达微秒分辨率，但这与实际实现无关。如果您正在编写可移植程序，则不能依赖 gettimeofday() 返回优于计时器滴答分辨率的结果，因此我声称这是“典型的”。

2. 对于现代 CPU 来说，一微秒的分辨率远远不够。即使在（相对较慢的）200MHz P6 上，这也将对应于 200 个周期，因此不可能测量低级事件，例如一级缓存未命中。即使分辨率足够，也要记住 getimeofday() 通常涉及系统调用。例如，在 200MHz P6 上，执行一对 gettimeofday() 调用似乎需要大约 4 微秒。总而言之，在许多情况下，CPU 周期计数器比 gettimeofday() 更有优势。当然，反过来也是如此。我要说的是，这两种技术目前都有其用武之地。

3. 我不知道。2.1.xx 可能已经做到了这一点，但我还没有机会跟踪最近的内核开发。

—David Mosberger davidm@azstarnet.com

我刚刚阅读了 Phil Hughes 在 LJ 十月刊上的停止印刷。作为智能多端口卡的制造商，Cyclades 一直在关注 I2O。

I2O 已经存在几年了。由于英特尔的坚持，它在今年才开始获得动力。SCO、微软和 Novell 似乎都将支持它。目前，还没有 I2O 的真正实现，标准也才刚刚稳定下来。我怀疑这是否真的会成为现实。标准架构的想法是好的，但 I2O 是一个非常笨重的接口，旨在销售英特尔处理器。

除了您必须付费才能获得规范（不一定是坏事，PCI 也做同样的事情）之外，还有另一个问题。I2O 规范的设计使得 I2O 卡上只能使用一种可能的 CPU：Intel 960RP。此外，只有 Wind River（与 Intel 合作）具有 I2O 消息传递的软件实现。英特尔为每个 960RP 捆绑了 IxWorks（在板内运行 I2O 消息传递的 RTOS）的运行时许可证。

因此，I2O 不是一个“开放”标准。这是英特尔尝试围绕 Intel 960RP 和 Wind River 的 IxWorks 标准化智能 I/O 的尝试。

随着 I2O 获得一些动力，其他硬件公司（PLX 就是其中之一）正在设计符合 I2O 消息传递的 PCI 芯片。但是，选择仍然有限，I2O 的可行性仍有待验证。

Phil 还提到了“开放硬件”倡议。Cyclades 是第一家通过开放硬件产品认证的公司，并且仍然是唯一一家。

—Marcio Saito，Cyclades 公司 marcio@cyclades.com