读者来信

Gnull 和 Voyd

我本以为你们不可能再推出比 Marcel Gagné 的“Linux 烹饪”（有用信息都夹杂在无聊内容中）更令人恼火的专栏了，结果你们又给我们带来了 Gnull 和 Voyd。请给我们技术提示；请去掉那些垃圾玩笑。

—
Patrick Wiseman

如您（及其他人）所愿。技术提示保留；Gnull 和 Voyd 移除。——编者。

!Gnull 和 Voyd

请继续保持出色工作。我很喜欢你们的 /var/opinion 专栏，并且我会继续关注 Reuven Lerner 的优秀专栏。多年来，你们帮助我成为了一名更好的系统管理员，为此我感谢你们。

—
David MacDougall

宽恕

几个月前，我写信给你们说我们必须分手——你们变得太爱聊天，而且观点太多，不符合我的口味。我必须承认，事实证明我是在虚张声势。我太爱你们了，今天，我续订了订阅。

你们的质量确实大幅下降，但最近几个月情况有所好转。不过，更重要的是，你们的起点质量非常高，即使质量有所下降，你们仍然是我唯一的 Linux 出版物。

—
Andy Balaam

分解数字

我饶有兴趣地阅读了“分解数字”[Dave Taylor 的 Shell 工作，LJ，2006 年 12 月]，因为我最近也处理过这个问题。我认为 bc 是一个普遍被忽视但非常强大的 UNIX 实用程序。Taylor 的脚本很好地说明了 bc 的用法，并且在大多数情况下非常有用，但不幸的是，在处理整个范围的二进制前缀时，它的扩展性不好 (en.wikipedia.org/wiki/Binary_prefixes)。

首先，用于查找第一个非零 {kilo|mega|giga}int 的数字测试 -lt 在数字大于 2⁷³-1 时会失败（至少在 bash-3.0-8.2 下运行于内核 2.6.8-24.25-smp 之上）。

其次，为了扩展到处理拍字节、艾字节、泽字节和尧字节，总共必须调用 16 次 bc，每次调用都会产生向系统 shell 调用的开销。

以下是一种替代方案，它更有效地使用 bc，并避免测试对于 shell 来说过大的数字

# total letters
nc=`echo -n $1 | wc -c`

# numeric letters
nn=`echo -n $1 | tr -cd '[0-9]' | wc -c`

if [ -z "$1" -o $nc -ne $nn ] ; then
   echo "Usage:  kmgp <integer>"
   echo "        where  0 <= integer <= (2^100)-1 "
   exit 1
fi

SIprefix=" KMGTPEZY" # kilo, mega, giga, tera, peta,
↪exa, zetta, yotta

# what is the closest power of 1024?
# ( ln(1024)=6.93147180559945309417)
order=`echo "scale=0 ; 1 +
↪l($1)/6.93147180559945309417" | bc -l`

# find the letter associated with this power of 1024
letter=`echo "$SIprefix" | cut -c $order`


if [ $nn -gt 3 ]
then scale=3
else scale=0
fi

value=`echo "scale=$scale ; $1/(1024 ^($order-1))"
↪| bc -l`

echo "$value$letter"

此版本包含两次 bc 调用和一次 cut 调用。对 bc 的调用值得讨论：第一次调用

# what is the closest power of 1024?
# ( ln(1024)=6.93147180559945309417)
order=`echo "scale=0 ; 1 +
↪l($1)/6.93147180559945309417" | bc -l`

通过使用将对数除以 N 的对数与取其 N 次方根相同的事实，确定最接近的 2¹⁰ 的幂。偏移量 1 补偿了 cut 是从 1 开始而不是从 0 开始的事实。请注意，我们正在通过使用 bc -l 加载 bc 的数学库。

第二次调用

value=`echo "scale=$scale ;
↪$1/(1024 ^($order-1))" | bc -l`

除以 1024 的正确阶数幂，并缩放到适当的小数位数。

通过对 400 个任意数字上的两个脚本所用时间进行平均，我发现基于对数的脚本速度快了三倍多。另一方面，如果对大于几百千兆字节的数字不感兴趣，则原始脚本速度更快。

—
John

有组织的压制

你们的 /var/opinion [2007 年 1 月] 关于 GPL 版本 2 和 3 之间的权衡，让我想起一句值得重复的俏皮话：“没有自由这种东西——这只是一个压制是如何组织的问题！”

—
Struan Bartlett

不仅仅是开发者

你们声称“唯一真正因 ROM 上的软件而受到伤害的人是极少数想要在设备上运行修改版软件的黑客”[2007 年 1 月 /var/opinion]。这种说法是错误的。黑客可能是唯一目标受到 直接 不可变嵌入式软件阻碍的人。但是，黑客创建的软件最终会流向哪里？用户，他们对软件的了解不会超过如何将其加载到设备中并利用它提供的任何增强功能。“绝大多数”用户会因对“极少数”有能力的开发者的寒蝉效应而受到伤害，因为他们无法从原本可以开发的软件中获益。

—
Ryan Underwood

观点已采纳。但是，如果源代码是可用的，正如 GPLv2 必须要求的那样，那么开发者可以从中学习并使用它，只是不能在特定设备上使用。——编者。

DocBook XML 和 CSS

David Lynch 2006 年 11 月关于使用 DocBook XML 构建简单网站的文章对我来说很及时。多年来，我一直在用原始 HTML 为我的开源项目编写文档，但最近我“看到了光明”，现在使用 DocBook XML 和 CSS 的组合。但是，我的部署方法与 David 的方法完全不同。我没有依赖框架和浏览器将 XML 转换为 HTML 的能力——并因此带来复杂性——而是简单地离线将 DocBook XML 转换为 HTML，然后将输出上传到我的网站。这是一种更简单的方法，仍然保留了 DocBook 的主要优点。我将其推荐给任何编写软件手册或简单网站，并寻求内容和演示之间清晰分离的人。有关如何完成的示例，请下载 HR-XSL 项目 (hr-xsl.sourceforge.net)，并在 doc 目录中查找。

—
Trevor Harmon

欢乐颂

Jon Hall 在 [Beachhead，2007 年 1 月] 中对专利提出了一些非常站不住脚的论点。首先，争论的焦点不应该是我们是否应该拥有软件专利。争论的焦点应该是软件专利和一般专利如何实施和维护。

虽然我可能需要几年时间才能开发出一个全新的操作系统，但其他人可能只需要几周或几个月。但这并不意味着这个新颖的操作系统不应该被授予专利和保护，以防止大公司窃取它。

你看，要发明某样东西，发明者通常会深入参与该领域或研究。有时，最好的想法会凭空出现。想法本身可能容易或难以实现，可能需要或多或少的时间，但最终重要的是独创性和实用性。

这是每个抱怨专利的人都忽略的一件事。专利是为了保护弱势群体。 而不是相反。今天看起来可能是这样，因为专利法的实施和执行可能并不尽如人意，但最终，专利背后的理念是保护你的发明。

想象一下一个没有版权保护、商标、专利或其他保护独创性和独特性的法律的世界。在很短的时间内，将不会有发明，没有新的音乐或艺术作品。我们将只会一遍又一遍地看到重复和相同的东西。将没有创新的动力。投资于发明根本不是明智的投资。那样的世界将是可怕的。

在某种程度上，这种情况已经在软件开发中发生了。过去推动发明并向大公司施压的小型共享软件开发者现在几乎没有理由进行发明。很难保护发明，如果他们不保护它，就会有更大的人出现并占领他们的市场，或者如果这种情况没有发生，就会发布一个不太好用但免费的版本。为什么要发明？最好是窃取别人的想法，雇用一些廉价劳动力，然后把钱投入到营销而不是研发。

关于 Jon 对音乐和视觉艺术的评论的题外话：想象一下，如果我可以复制欢乐颂，然后在乐曲末尾添加两个音符并声称它是我的。如果我能够比原作曲家（贝多芬）更好、更强烈地推销它，谁能说出最初是谁创作了这首乐曲（假设我生活在同一时期）？

更重要的是，如果这种情况发生在贝多芬身上，他还能再写出一首乐曲而不必担心有人会窃取它吗？他还会写音乐吗？

—
Nebojsa Djogo

Jon “maddog” Hall 回复： 我完全同意“大公司”（或任何其他人）不应该能够窃取你的作品，但我不同意软件专利是确保这种情况不会发生的方式。

早在 1995 年软件专利普遍编入法律之前，版权、合同和许可法就已经应用于软件。早在软件专利普遍可用之前，人们就在保护他们的软件。

关于大小问题——小型软件创作者没有资金在法庭上进行软件专利诉讼。最近 RIM 和 NTP 之间的竞争就是一个例子，其中 NTP 声称的四项专利中有三项被推翻，花费了数百万美元的律师费。第四项可能已被推翻，但 RIM 和 NTP 决定“和解”。从这场惨败中唯一获胜的人是律师。

我没有主张一个没有“版权保护”的世界，只是反对软件专利。我（以及大多数自由软件社区）赞赏版权、商标和商业秘密法对人们独创性的保护。自由软件依赖版权进行许可。

关于贝多芬的场景——贝多芬会起诉你侵犯版权，并且很可能会在法庭上胜诉。但是，他无法阻止你使用三连音或一些其他“创作音乐的过程”。

不幸的是，专利在保护发明方面并非万无一失。亚历山大·格雷厄姆·贝尔和安东尼奥·梅乌奇的争议就是例证 (www.italianhistorical.org/MeucciStory.htm)。

贝多芬所要做的就是将他的交响曲发表在任何公开的、注明日期的文件中（这比专利申请简单且成本更低），它就会受到版权法的保护。

感谢您写信，但我仍然坚持反对软件专利。

在熔炉

Reuven 在Linux Journal 上的专栏是我最喜欢的专栏之一，我一遍又一遍地阅读它，但 2007 年 1 月刊中的专栏是我在Linux Journal 中读过的最好的文章之一。请向 Reuven 表示感谢，感谢他的工作。

—
Stefano Canepa

误解？

我很欣赏 Paul McKenney 的文章，其中解释了实时 Linux 的最新进展[“SMP 和嵌入式实时”，2007 年 1 月]，我特别喜欢图 13 中的“优先级提升”漫画。然而，我对他试图消除关于并行和实时编程的某些“误解”感到有点失望。

例如，在误解 #2 中，我希望了解为什么并行编程不是“令人难以置信的困难”。不幸的是，McKenney 博士的解释只不过是宣称“它真的没有那么难”。在我看到更实质性的论据来消除这个所谓的误解之前，我倾向于相信并行编程实际上非常困难。套用 Edward A. Lee 的话：精神错乱就是一遍又一遍地做同样的事情，并期望结果会有所不同；因此，并行系统的程序员一定是疯了。

此外，在误解 #5 中，McKenney 博士正在传播一个误解，而不是消除一个误解。他指出，随着网站分布在多个服务器上——负载均衡器、防火墙、数据库服务器等等——每个服务器的响应时间必须“牢牢地落入实时领域”。在这里，他将“实时”等同于“非常快”，这是一个非常普遍的误解，它可能应该在他的列表中的第 1 位。事实上，实时系统完全是关于可预测性，而不是速度，它们的设计经常为了可预测性而牺牲性能。然而，McKenney 博士暗示将 Web 服务器移动到实时环境将神奇地缩短它们的响应时间。这根本不是真的。Web 服务器的响应时间仅在过载的情况下才会上升——太多人同时访问它——当这种情况发生时，实时 Web 服务器会像非实时服务器一样容易失败。

我希望任何受到 McKenney 博士文章启发的 Web 管理员都会放下他们手中的 Ingo Molnar 的实时抢占补丁，并忘记实时 Linux。简单地在他们的负载均衡器后面添加另一台服务器将对提高整体响应时间产生更大的影响——并且需要更少的精力！

—
Trevor Harmon

错别字

David Lynch 2007 年 1 月的文章“当硬件变软时如何移植 Linux”中有一个错误。他说 BSP 代表 Broad Support Package。这是不正确的。正确的展开是 Board Support Package。

—
Trevor