WEB开发网
开发学院软件开发Shell 一本 Linux 开发人员的必备书籍 阅读

一本 Linux 开发人员的必备书籍

 2009-06-30 04:11:00 来源:WEB开发网   
核心提示:不只适用于管理员在本专栏中向您推荐 Practice 有两个理由,首先,一本 Linux 开发人员的必备书籍,本书隐含着一些我打算详细说明的好处:也就是说,它不仅适用于管理,您会在自己的网络中发现许多弱点和“压力点”,如果您想探究更多细节,而且适用于开发,其次

  不只适用于管理员
  在本专栏中向您推荐 Practice 有两个理由。首先,本书隐含着一些我打算详细说明的好处:也就是说,它不仅适用于管理,而且适用于开发。
  
  其次,本专栏的未来部分将引用本部分中提到的几个参考资料。Expect 是上一个专栏的主题,它和 Practice 都会在未来部分中出现,并且,在开始阅读未来部分之前,最好先透彻地理解它们。
  
  Practice 与同类书籍有什么不同
  最近十年的大部分时间里,UNIX 系统管理员的两本标准参考书籍是 Nemeth 等人编写的 UNIX System Administration Handbook 以及紧随其后由 Aeleen Frisch 编写的 Essential System Administration。假设打印机队列出现了错误状态,那么您可以明智地希望选择这两本中的任何一本,并从中找到解决问题的命令。最近还出现了几本良莠不齐的书籍,它们专门讨论 Linux 系统管理。
  
  Practice 不象这些书籍。它不仅对这些书籍进行了补充,而且在某种程度上取代了它们。大多数管理书籍中充斥着代码;它们有 sendmail.cf 示例、大量 shell 脚本、top 的命令行参数说明等等。Practice 所针对的知识主体要略微更抽象些,和 Mark Burgess 编写的 Principles of Network and System Administration 大体相同。 Practice 的要点是将作为日常琐碎工作的“如何”管理的问题提升为专业实践的“为什么”问题。
  
  Practice 这样做时基本上不引用特定程序或产品。实际上,它甚至不把自己绑死在某一操作系统系列上;其思想都能很好地应用于 MacOS、UNIX、Windows 或其它企业操作系统。
  
  一本关于管理的书籍却没有任何管理示例,对于您来说,这是否看上去很极端?对 Practice 的评价也很极端;大多数读者得出的结论是他们要么对它爱不释手,要么不喜欢它,甚至不愿意把它作为赠品来接受。我显然是前一个阵营中的。根本上,Practice 的所有理论都很实用。
  
  例如,第 19 章是关于电子邮件的,当出现邮件循环、队列分裂,或者需要过滤垃圾邮件、限制收件箱大小、归档流量或使样板文件负责声明时,它不会给您任何直接帮助。但是,它用简单的语言展示了可靠性、可伸缩性、可管理性等思想,必须保留它们使任何特殊任务有价值。
  
  作者(还有我)怎能将一本没有为解决任何特定问题提供处方的书叫做“实用的”呢?要点在于,如果您所知道的都是处方,那么一旦离开处方起作用的小领域,您就束手无策了。Practice 假设您有找到处方的方法。它所承担的任务是,用更深刻的理解补充这些处方,这样您就能应付更一般或前所未知的新情况。并且,Practice 总是在每一章中强调自动化、忠实于标准、良好的文档和清晰的沟通,作为搞好管理的基础。
  
  这个侧重点导致了 Practice 与关于系统管理的早期书籍的又一个差异。关于管理的传统书籍已经变成了“参考大全”,多少有点百科全书的味道:当您想得到一个有关 IP 分配问题的解决方案时,就查找讨论该主题的章节。相比之下,Practice 的许多读者所做的是直接通读本书 — 这本书是故事体的,“类似于小说”。他们学习本书以获得对所有管理原则的连贯理解,然后转到本书的网站(请参阅下面参考资料中的“EverythingSysadmin”)获取到特定“如何做(how-to)”的链接。
  
  这或许是趋势的一部分。我觉得将来对充斥了代码和“手册”的“紫皮书”(Nemeth 的书的“戏称”)的需求会越来越少。越来越多的人希望在线得到此类信息。但是,我们仍然需要书面表述的信息是 Practice 中所包含的基于实际经验的说明、分析和建议。
  
  对于服务器编程的暗示
  那么,对于开发服务器端应用程序的读者而言,“服务器诊所”的意义何在呢?首先,Practice 是一本好书。它具有的概括信息正适合您的工作需要(服务器有什么不同?如何使策略制度化?部署涉及什么?如何管理您自己的事业)。还有,如果理解了管理员是如何思考的(或应该如何思考),则您可以更好地完成工作。
  
  此外,Limoncelli 和 Hogan 用来管理的特定方法还强调了有利于程序员的主题。他们显式地标注了管理的设计和支持的六个要素:简单、清晰、通用、自动化、沟通和“基础优先”。程序员至少和管理员一样需要这些要素。
  
  Limoncelli 看来要在 make 文件上倾注他毕生的精力。他将版本控制用于书籍本身的文本,或者更确切地说,是用于他和 Hogan 用来生成文本的“宏”。关键不在于 make 是一种伟大的语言;它不是。然而,它是一种用于管理更改和确保再现性的已证实的技术。作为程序员,很多挑战是要应付不断的更改:新的协议、应用程序编程接口(API)、客户需求、硬件约束等。通过自动化和通用化使您自己掌握所有这些可变性。关于这一点,Practice 有正确的态度,并足以来教您。
  
  在回答我向他们的提问时,Limoncelli 和 Hogan 提供了本书以外的关于考虑服务器的几个技巧。前者强调:“服务器编程之所以不同,是因为更改管理成为了需求”。他还喜欢将服务和服务器区分开来:“任何有支票簿的白痴都可以买服务器,但运行成功的服务却需要高度智慧”。
  
  那些口号激发了本月家庭作业的灵感。许多商店监控着服务器,当服务器出问题时,使用连接到寻呼服务系统和其它通报器的警报。但您真正想要的,是一系列服务;服务器只是实现该目的一个手段。在学习 Practice 之后,自然会得出的结论是要构建服务监视器。尽管已出现了几种商业监视器,并且许多组织使用“自产”版本,但是还没遇到过令我满意的。
  
  让我们概述一下它的工作原理:给定一个 /etc/service 风格的分配表(100.1.2.3 和 100.1.2.5 应该提供 HTTP 服务,而 100.1.2.6 提供 SMTP),监视器检查受监控的主机上的所有端口。如果没有打开其它端口,则它确保提供已定义的服务。结果被记录到日志(Practice 展现了对日志记录价值的良好理解),并且分配表在修订控制(版本控制是 Hogan 和 Limoncelli 的另一个好习惯)下受维护。这样做,结果肯定会令您吃惊。您会在自己的网络中发现许多弱点和“压力点”。如果您想探究更多细节,我邀请您参加本专栏的论坛(单击本文顶部或底部的讨论是另一种访问论坛的方法)。

Tags:一本 Linux 开发

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接