致编辑的信
我是 LJ 的订阅者,事实上,我拥有每一期。 我很犹豫说这个,因为它听起来像很多废话,但我一直对 LJ 以如此快的速度推出高质量文章印象深刻。 作为一名 Unix 应用程序程序员,我阅读了几份期刊,我发现你们务实的方法令人耳目一新,与 DDJ 的文章相比。 然而,我写信(如果这种交流方式可以这样称呼的话)是为了要求改进 LJ。 您的编辑人员能否认真考虑收录有关 FreeBSD 的文章? 尤其是因为它对 Linux 的销售没有威胁。 此外,我认为这将增加您的销量,至少在我认识的一些程序员中是这样。
LJ 早期进行的一项非正式调查表明,FreeBSD 社区对一本专门介绍 FreeBSD 的杂志不感兴趣,而 SSC 正在考虑出版这样的杂志。 (也许情况已经改变?)
至于在 Linux Journal 的页面中给予 FreeBSD 时间,我们确实有一些正在研究的想法。 然而,就目前而言,我们有比我们可以印刷的更多的关于 Linux 的材料。
LJ 96 年 7 月刊介绍了新的 Korn shell (ksh93)。 没有提及(并且不广为人知)的是,对商业支持不感兴趣的用户可以免费获得 Linux、Sun 等二进制文件(src 不可用)。 这不仅包括 ksh 二进制文件,还包括共享库和 Tcl/Tk 的 Tksh 扩展。 只需查看 URL www.research.att.com/orgs/ssr/book/reuse。 顺便说一句,URL 指向的书籍(Practical Reusable Unix Software, Krishnamurthy, Wiley 1995)是一座金矿,描述并提供了诸如 dot 工具等瑰宝的源代码。 Dot 是一种有向图布局工具,现在我离不开它了。 推荐。
—Alexandre Valente Sousa avs@daimi.aau.dk
Mike Loukides 和 Andy Oram 在他们的“了解 gdb”文章(96 年 9 月)中指出,gdb 能够在“只有少数工作站”上设置硬件观察点。 i386(及更高版本)不仅具有这些功能,而且当前版本的 Linux (1.2.1+) 和 gdb (4.14+) 也能够使用此功能。
386 最多支持四个同时硬件观察点,当内存位置被“访问”(读取或写入)时,这些观察点可以触发。 在 Linux gdb 中,这些是 “rwatch” 和 “awatch” 命令。 这两个命令都接受要观察的表达式。 正如作者指出的那样,此功能非常适合观察正在神秘地被破坏的内存位置。 硬件观察点的优点是您的程序全速运行,而不是缓慢地单步执行。
处理这些观察点的一个棘手之处是,如果程序控制转移到表达式的范围之外,它们会自动禁用。 例如,如果 “i” 是一个自动变量(一个 “局部” 变量),那么当调用子例程时,“i” 的含义就会丢失。 解决方法是观察原始内存位置
(gdb) print &i $1 = (int *) 0xbffffd2c (gdb) awatch *((int *) 0xbffffd2c) Hardware access(read/write) / watchpoint 3: *(int *) 3221224748 (gdb) cont Continuing. Hardware access(read/write) / watchpoint 3: *(int *) 3221224748 123 *foo = 0; (gdb)
—Andy Vaught andy@maxwell.la.asu.edu
我简直不敢相信——不是一本,不是两本,而是三本 (!) Linux Journal 在我周三的邮箱里。
我不知道该如何感谢您,在过去的几天里,我消磨了快乐的时光。 我花了几个小时只是看广告。
自从 Byte 杂志的旧时代以来,我不记得如此享受一本杂志的广告了。
—Dwight Johnson djohnson@olympus.net
Bonjour,
感谢您非常高效的 dtree [文章]。
作为一名匿名订阅者,我鼓励 [您] 继续这样做:就目前而言,坚持技术特性是维持 Linux 运动的最佳手段。
Merci beaucoup.
Cordialement,
—J-F Bardou
我刚刚购买了一本 1996 年 9 月刊的 Linux Journal。 我非常失望的是,您在评论文章中排除了任何关于错误的信息。 依靠口口相传? 那我为什么要花 4.00 美元买你们这本愚蠢的杂志!! 我知道你们不想冒犯任何潜在的广告商,但这太荒谬了。 除非你们愿意报道这些软件包的真实情况,否则你们的杂志没有任何价值。
—Tim Gawne tgawne@icare.opt.uab.edu
我刚刚读完你们在 7 月份的 Linux Journal 上关于 Texas OODB 的文章。
您没有提到的一个免费系统是 Exodus(来自现在著名的 OO7 基准测试与 Object Store 的惨败)。 我已经使用 Exodus 大约两年了,它的 E (C++ 扩展) 用于持久性。 它非常出色。
我从它的存档 (cs.uws.edu) 中注意到,最新版本的 E 已被删除(基于 gcc-2.5.8),可能是因为该版本中的几个错误(我遇到了这些错误并且已经修复)。 稳定版本基于 gcc-2.3.3。
我已经完成了 E-2.5.8 到 Solaris 2.4 & 5 的移植,并且应该很快将其与修复程序一起发布回存档。
顺便说一句,Exodus 确实在 Linux 下运行,并且确实支持一个非常广泛的多用户、多服务器缓存系统,称为 “sm”。 sm 还支持两阶段提交和检查点。
我同意 OODB 速度差异——它们使像 “Manacle” 这样的系统看起来像恐龙一样。
—Stephen Dennis dennis@rover.research.canon.com.au
我想向您介绍一下以色列 Linux 用户组的最新情况。 首先,我们现在有了自己的域名。 官方网站是 www.linux.org.il,并且一个全面的 sunsite 镜像 FTP 站点正在建设中。 我们还在考虑成为一个官方的非营利组织,这对于读者来说可能很有趣。 订阅我们的邮件列表可以在 www.linux.org.il/Linux-il-sub.html 完成,或者通过发送邮件到 majordomo@linux.org.il,主题行留空,正文包含 “subscribe linux-il [address]”。
最后,我只是想请求,因文章而发送给您的任何反馈和评论也转发给我。 我会确保整个小组收到它们。
—Shay Rojansky roji@cs.huji.ac.il
感谢那里的所有人提供了一个关于 Linux 的精彩信息和广告来源。 我每个月都会收到很多杂志,但我在报摊上买到的 LJ 副本(直到现在)是我最喜欢的。 继续保持良好的工作! (如果 LJ 有任何技术就业机会,我很乐意了解一下。)
我想尽可能多地了解预计的过刊可用性。 我想获得每期仍然可用的期刊中的一本,所以知道先订购哪一本会有所帮助。 我不想因为等待太久而错过一本。
提前感谢。
—Walter Seefeld wseefeld@memphisonline.com
我写信是为了祝贺你们又出版了一期精彩的 Linux Journal。 你们的杂志是我现在唯一一本从头到尾阅读的杂志。 以下是我想提出的一些意见和评论
请转达给 Michael Johnson,他在启动 LJ 方面做得非常出色。 我一直很喜欢他的技术文章,我祝愿他在 Red Hat 的新职位上一切顺利。
我认为你们从新手到“不太新手”的文章的组合在各期之间略有不同,但总的来说,对我来说是合适的。
我认为你们的 “什么是 Linux” 部分应该更突出地强调 FSF、BSD、MIT 和其他人的贡献。 虽然他们的软件不是为了支持 Linux 项目而编写的(但现在是这样),但如果没有他们,Linux 将会逊色得多(提供这种认可并不会以任何方式贬低 Linux)。
请继续尽可能多地刊登关于 Linux 下编程工具介绍的文章。 “了解 gdb” 文章就是此类文章的一个很好的例子。
我喜欢你们对 Linus Torvalds 的采访。 看到更多这方面的文章会非常有趣。 我建议你们采访更多的 Linux 杰出人物,如 Alan Cox、Werner Almesberger、Matt Welsh、Lars Wirzenius、Remy Card、Rick Faith、Leonard Zubkoff、Bjorne Ekwall、Al Longyear、Donald Becker 以及其他许多人,恕不一一列举。
我也很有兴趣更多地了解像 Phil Hughes、Mark Bolzern、Erik Troan 等 Linux 企业家。
当我在谈论采访的话题时,对 Linux 发行版评论文章的一个很好的补充将是关于发行版创始人的简短传记。 (我对 Debian 项目、它的理念和它的贡献者特别着迷。)
对 Richard Stallman、Larry Wall 等 Unix 杰出人物的采访也将非常有启发意义。
一篇关于 Linux 在实时应用程序中的应用的文章会很有趣。 有许多小组正在研究这个问题,也许你可以说服他们的协调员贡献一两篇文章。
一篇调查免费和非免费数据库软件的文章将非常有用。
好吧,对于一封信来说,这已经足够多的意见和建议了! 继续保持良好的工作!
—Nick Busigin nick@xwing.org
我认为你们在关于 2.0 的文章和 Crow 先生关于模块的文章中对模块的处理完全是错误的。 你们只关注节省内存。 Crow 先生甚至进一步解释说,对于永久使用的驱动程序,最好将它们编译到内核中,因为当它们页对齐时,每个模块会损失 2K——此外,由于 kerneld,您会损失十二页。
让我先回答这个问题。 如果您加载了 20 个模块(一个不切实际的数字),您会损失 40K——加上 kerneld,您仍然低于 100K。 好吧,有什么问题吗? 这是 Linux,而不是臭名昭著的 DOS。 我们没有 640K 障碍,100K 不会造成明显的速度差异(除非您只有 4MB 的 RAM,但这在今天很少见)。
考虑一下使用 1.2 的初学者:他必须从几十张引导盘中选择一张能够支持他的硬件的引导盘。 尽管如此,内核还是有太多不必要的驱动程序,以至于它太大了 1MB(这将在速度上产生重要影响)。 尽管如此庞大,但这个内核缺少他想要的东西,比如声音支持。 因此,我们的初学者(仍然几乎无法复制文件)面临着编译新内核的任务。 众所周知,这并不难,但这会产生不良影响:Linux 获得了“仅限黑客”操作系统的声誉——你不能把它交给一个没有一些计算机经验的人。
现在考虑一下(未来)2.0 发行版:只有一个引导映像(好吧,也许是六个左右,如果你想针对奔腾进行优化)。 所有驱动程序都是模块。 在安装时,用户回答一些关于他的硬件的问题,安装程序为 “永久模块” 构建 kerneld 和 /etc/rc.d/conf.modules 的配置文件。 用户重新启动,他就运行起来了。
您的内核可能 稍微 欠佳,但重新编译不再是必需的。 这意味着在 Linux 中处理驱动程序比编辑 CONFIG.SYS 或 AUTOEXEC.BAT 容易得多。 加上新的软件包管理器、一些配置工具和一个好的文件管理器——稍微指导一下,我现在有希望将我 15 岁的侄女从邪恶帝国的魔爪中解救出来。
—Jean Francois Martinez jfm@sidney.remcomp.fr