给编辑的信
关于 Phil Hughes 在 12 月刊《LJ》上发表的文章,请帮助进一步推动 Arena 的开发。Netscape 臃肿、缓慢,而且是我们唯一的选择。我现在几乎所有的浏览都使用 Lynx,因为 Netscape 在我的系统上太慢了。Arena 运行良好,但无法处理表单,而表单是网络浏览器最实用的功能之一。像很多人一样,我对背景图案和增强字体不感兴趣。我想要轻松访问信息,而 Netscape 或当前的 Arena 都无法做到这一点。
—Peter McArthur peterm@3rdplanet.com
Linux Journal 有一个姊妹出版物名为 WEBsmith™,其编辑 Jon Gross 最近参与了一个万维网会议。我们请他回应:
我(和许多其他人)同意您对目前可用的浏览器选择现状的总结。12 月,我在波士顿参加了第四届国际万维网会议,我们一群人开始交谈,并决定是时候启动一个免费浏览器项目了,该项目以 Linux 社区为蓝本,旨在解决这个问题。我们在“公开”之前正在整理一个稍微有凝聚力的框架,但我们非常感谢您的投入。Linux 社区可以为这个项目提供很多东西,我认为我们绝对可以制造出更好的捕鼠器。邮件列表已经建立。请访问 www.base.com/gordoni/web/www4-bof.html 获取更多信息。
—Websmith 杂志编辑,Jonathan Gross
Eric Goebelbecker 的《chmod 命令》(LJ #21)是对类 Unix 操作系统有时违反直觉的文件和目录权限的出色介绍。然而,在结尾附近,有一个关于“粘滞位”的错误陈述。这个位实际上在 Linux 系统上有一个非常重要但晦涩的用途。
粘滞位在早期 Unix 系统中得名,那时还没有按需分页虚拟内存。如果可执行文件的粘滞位被设置,程序退出后,其文本段的副本将保存在系统的交换区中,即它会“粘滞”在那里以供下次使用。此功能用于使经常运行的程序加载速度更快一些。粘滞位的这种含义不再特别相关。
尽管它不是 POSIX 规范的一部分,但最近的 System V 和 Berkeley Unix 系统为粘滞位定义了一个新的含义。如果目录的粘滞位被设置,则目录中的文件只能由文件所有者、目录所有者或 root 删除。这为 /tmp 等目录提供了额外的安全措施。当然,Linux 支持这个有用的功能。例如,在我的系统上
$ ls -ld /tmp drwxrwxrwt 3 root root 1024 Jan 1 09:49 /tmp $ ls -l /tmp -rw------- 1 roman users 0 Jan 1 09:49 bar -rw------- 1 root root 0 Jan 1 09:47 foo $ rm /tmp/bar $ rm /tmp/foo rm: /tmp/foo: Operation not permitted
如果没有粘滞位,我本可以从 /tmp 中删除 root 的文件。
—Bill Roman roman@songdog.eskimo.com
我非常有兴趣地阅读了您去年 8 月关于 LISP-Stat 的文章,并且刚刚开始试用它。一个不一致之处:文章声称“dld”库是必不可少的。这不是真的;如果您从头开始构建 Lisp-Stat,它将使用现在标准的“dlopen”方法进行动态加载(基于 ld.so 库),如果它存在的话。事实上,“dld”似乎不再适用于当前的“a.out”样式静态库,更不用说 ELF 库了。
我使用 gcc 2.7.0 为 ELF 编译了它,一切都运行良好。编译时间相当长(在配备 20M 内存的 486-33 上大约需要一个小时),尤其是在大量代码是用 LISP 编写的情况下。所有的书本示例都完美运行。这是回顾长期遗忘的统计学知识的好方法。
您在展示 Linux 的有趣应用方面做得非常出色。请继续保持出色的工作!
—Rod Hallsworth rhallsw@synapse.net
在撰写这篇文章时,dld 是必需的。当时,ELF 仍然有些实验性,由于我们不知道它何时会被认为是普遍稳定的,因此我们选择不将文章建立在它会在文章撰写和阅读之间变得稳定的假设之上。我们从那时起开始建议人们在合理的情况下切换到 ELF,因为它现在被认为是稳定的,并且应用程序仅以 ELF 形式提供的时间将会到来(并且显然已经到来,在某种程度上)。感谢您指出它在 ELF 下构建没有问题。
我发现 Python 示例基本上毫无价值,因为存在错误。第 21 页列出的程序的第 6 行应为
uid = `posix.getuid()`
请注意 (`) 而不是 (')。
最大的问题是第 23 页列出的 StackingThings 程序的格式。Python 对缩进 非常 敏感。尝试格式化程序以适应列宽“严重破坏了它”。
撇开之前的评论不谈,我发现 Python 文章令人愉快,并且我对您的出版物非常满意。继续保持良好的工作。
—Joe Kirby kirby@utk.edu
“反引号”实际上是 Courier 字体中的左单引号字符,这并非最佳选择,但我们很难找到更好的替代品。如果您非常非常仔细地看,您会发现“反引号”底部比顶部宽,“引号”顶部比底部宽。我们同意您不应该仔细看才能看到差异,我们正在努力寻找解决方案。
我们的制作团队确实破坏了 StackingThings 示例中的缩进,我们对此表示歉意。《LJ》的制作团队通常在使内容适应方面做得非常好,但这次出现了一些明显的失误...
StackingThings 示例的正确版本可以从我们的 WWW 服务器 www.ssc.com/lj/issue21/index.html 获取。