Preface
前言
Unix is not so much an operating system as an oral history.
--
<author>NealStephenson</author>
Unix，与其说是操作系统，不如说是口述历史。
--
<author>NealStephenson</author>
There is a vast difference between knowledge and expertise. Knowledge lets you deduce the right thing to do; expertise makes the right thing a reflex, hardly requiring conscious thought at all.
知识和专家经验有很大的区别。根据知识，可以推断出该做的正确的事；从专家经验出发，可以反射般地得到正确的事，几乎不需要有意识的思考。
This book has a lot of knowledge in it, but it is mainly about expertise. It is going to try to teach you the things about Unix development that Unix experts know, but aren’t aware that they know. It is therefore less about technicalia and more about shared culture than most Unix books — both explicit and implicit culture, both conscious and unconscious traditions. It is not a ‘how-to’ book, it is a ‘why-to’ book.
本书中有许多知识，但主要还是关于专家经验的。本书试图教会你与Unix开发相关的事情——Unix专家知道他们，但却没有意识到他们已经知道。从而，与大多数Unix书籍不同，本书涉及的技术细节较少，谈得比较多的是共同的文化——外在或内在的文化、自觉或不自觉的传统。这不是一本讲“怎样做”的书，而是讲“为什么”的书。
The why-to has great practical importance, because far too much software is poorly designed. Much of it suffers from bloat, is exceedingly hard to maintain, and is too difficult to port to new platforms or extend in ways the original programmers didn’t anticipate. These problems are symptoms of bad design. We hope that readers of this book will learn something of what Unix has to teach about good design.
“为什么”在实践中非常重要，这是因为太多的软件都设计得很糟糕。大多数软件体积臃肿，其维护极为艰巨；要把他们移植到新平台、或者以原先开发人员没有预见到的方式进行扩展，更是举步维艰。我们希望本书的读者学到一些关于良好设计的东西，这正是Unix可以教会我们的。
This book is divided into four parts: Context, Design, Tools, and Community. The first part(Context) is philosophy and history, to help provide foundation and motivation for what follows. The second part (Design) unfolds the principles of the Unix philosophy into more specific advice about design and implementation. The third part (Tools) focuses on the software Unix provides for helping you solve problems. The fourth part (Community) is about the human-to-human transactions and agreements that make the Unix culture so effective at what it does.
本书分为四部分：背景、设计、工具和社区。第一部分（背景）是哲学和历史，描述了后续部分的基础和动机。第二部分（设计）揭示了Unix哲学的原理，阐述了关于设计与实现的更为明确的建议。第三部分（工具）关注Unix提供的、有助于你解决问题的各种软件。第四部分（社区）讲述人与人之间的沟通和协作，这种沟通与协作使得Unix文化在其所作所为上给人印象深刻。
Because this is a book about shared culture, I never planned to write it alone. You will notice that the text includes guest appearances by prominent Unix developers, the shapers of the Unix tradition. The book went through an extended public review process during which I invited these luminaries to comment on and argue with the text. Rather than submerging the results of that review process in the final version, these guests were encouraged to speak with their own voices, amplifying and developing and even disagreeing with the main line of the text.
因为这是一本关于共同文化的书，我从未打算独自写完它。你会注意到书中包括了客串表演，客串嘉宾是杰出的Unix开发人员，他们是Unix传统的塑造者。本书经过长期而公开的评审，评审期间，我邀请这些学识渊博的人来评价和讨论书中的文字。不过，最终版本中，评审过程的成果并没有被湮没；客串嘉宾们受到鼓励，鼓励他们表达自己的观点——补充、展开其观点，甚至是用与正文主线有分歧的方式来表达他们的观点。
In this book, when I use the editorial ‘we’ it is not to pretend omniscience but to reflect the fact that it attempts to articulate the expertise of an entire community.
书中，当我使用社论般的“我们”的时候，并不是要装做无所不知，这只不过是反映了一个事实：本书试图清晰地表达社区整体的专家经验。
Because this book is aimed at transmitting culture, it includes much more in the way of history and folklore and asides than is normal for a technical book. Enjoy; these things, too, are part of your education as a Unix programmer. No single one of the historical details is vital, but the gestalt of them all is important. We think it makes a more interesting story this way. More importantly, understanding where Unix came from and how it got the way it is will help you develop an intuitive feel for the Unix style.
因为本书旨在传播文化，与技术书籍相比，书中有更多的历史、传说和旁白。欣赏吧；这些内容，也是你作为Unix程序员应该受到的教育的一部分。任何单独的历史事件都不重要，但他们的“格”（gestalt, 结构或形态，其构成因素并不是各组成部分间的简单相加，而是一种完整的结构或形式——译者注）却是重要的。我们认为，这样处理会使故事有趣许多。更重要的是，理解Unix来自何处、又怎么走上了现在的道路，将有助于你培养对Unix风格的直觉。
For the same reason, we refuse to write as if history is over. You will find an unusually large number of references to the time of writing in this book. We do not wish to pretend that current practice reflects some sort of timeless and perfectly logical outcome of preordained destiny. References to time of writing are meant as an alert to the reader two or three or five years hence that the associated statements of fact may have become dated and should be double-checked.
基于同样的原因，我们拒绝这样的写法，即，似乎历史已经完结。你将发现数量多得异乎寻常的参考文献，在本书写作的时候这些参考文献都是最新的。我们不打算声称本书反映了某种永恒的、逻辑完美的成果，这是已经命中注定的成果。写作时的参考文献意在警醒读者，两年、三年或五年后，相关的陈述可能会过时，需要进行反复检查。
Other things this book is not is neither a C tutorial, nor a guide to the Unix commands and API. It is not a reference for sed or Yacc or Perl or Python. It’s not a network programming primer, nor an exhaustive guide to the mysteries of X. It’s not a tour of Unix’s internals and architecture, either. Other books cover these specifics better, and this book points you at them as appropriate.
此外，这本书既不是C教程，也不是Unix命令及API的指南。它不是sed、Yacc、Perl或Python的参考手册。它不是一本网络编程的入门读物，也不是详尽的X秘技指南。它同样不是Unix的内部构成和体系结构的漫游。对这些主题，其他书籍有更好的叙述，在恰当的地方我们将指出应该参考哪些书籍。
Beyond all these technical specifics, the Unix culture has an unwritten engineering tradition that has developed over literally millions of man-years[1] of skilled effort. This book is written in the belief that understanding that tradition, and adding its design patterns to your toolkit, will help you become a better programmer and designer.
在所有这些技术细节之上，Unix文化有个不成文的工程传统，这是经由熟练技术人员数百万人年[1]的努力而形成的传统。写作本书，是相信一旦你理解了Unix工程传统、掌握了它的设计模式，将有助于你成为更出色的程序员和设计师。
Cultures consist of people, and the traditional way to learn Unix culture is from other people and through the folklore, by osmosis. This book is not a substitute for person-to-person acculturation, but it can help accelerate the process by allowing you to tap the experience of others.
文化由人组成，学习Unix文化的习惯方法是：从其他人那里、从传说中，潜移默化地学习。本书不能替代人与人之间直接的文化传承，但是，本书使你能够利用他人的经验，从而可以加速这一过程。
! Who Should Read This Book
！谁应该读这本书
You should read this book if you are an experienced Unix programmer who is often in the position of either educating novice programmers or debating partisans of other operating systems, and you find it hard to articulate the benefits of the Unix approach.
你应该阅读本书，如果你是有经验的Unix程序员，你常常需要教导新手，或者与其他操作系统的党徒争辩，但是你发现很难清晰地表达出Unix途径的好处。
You should read this book if you are a C, C++, or Java programmer with experience on other operating systems and you are about to start a Unix-based project.
你应该阅读本书，如果你是C、C++或Java程序员，有其他操作系统的经验，并且打算着手基于Unix的项目。
You should read this book if you are a Unix user with novice-level up to middle-level skills in the operating system, but little development experience, and want to learn how to design software effectively under Unix.
你应该阅读本书，如果你是Unix用户，具有初级到中级的操作系统应用技能，但很少有开发经验，你想学习在Unix下怎样有效地设计软件。
You should read this book if you are a non-Unix programmer who has figured out that the Unix tradition might have something to teach you. We believe you’re right, and that the Unix philosophy can be exported to other operating systems. So we will pay more attention to non-Unix environments (especially Microsoft operating systems) than is usual in a Unix book; and when tools and case studies are portable, we say so.
你应该阅读本书，如果你是非Unix程序员，但推测Unix传统可能教会你些什么。你是对的，Unix哲学可以向其他操作系统传播。因此，与通常的Unix书籍相比较，我们对非Unix环境（尤其是Mircrosoft操作系统）的着墨稍多；一旦工具和案例研究是可移植的，我们将指出来。
You should read this book if you are an application architect considering platforms or implementation strategies for a major general-market or vertical application. It will help you understand the strengths of Unix as a development platform, and of the Unix tradition of open source as a development method.
你应该阅读本书，如果你是应用架构师，对于主要通用市场或特定领域的纵向应用软件，你在考虑软件的平台或实施策略。本书将有助于你理解Unix作为开发平台的力量、理解开源作为开发方式的Unix传统的力量。
You should not read this book if what you are looking for is the details of C coding or how to use the Unix kernel API. There are many good books on these topics; Advanced Programming in the Unix Environment [Stevens92] is classic among explorations of the Unix API, and The Practice of Programming [Kernighan-Pike99] is recommended reading for all C programmers (indeed for all programmers in any language).
你不必阅读本书，如果你寻找的是C编程的细节或如何使用Unix内核API的话。关于这些主题，有很多好书；比如：《Unix环境高级编程》（Advanced Programming in the Unix Environment）[Stevens92]就是探索Unix API的经典，还有推荐所有C程序员阅读的《程序设计实践》（The Practice of Programming）[Kernighan-Pike99]（实际上，推荐所有程序员阅读，无论他使用何种语言）。
! How to Use This Book
！如何使用本书
This book is both practical and philosophical. Some parts are aphoristic and general, others will examine specific case studies in Unix development. We will precede or follow general principles and aphorisms with examples that illustrate them: examples drawn not from toy demonstration programs but rather from real working code that is in use every day.
本书既是实践性的也是思想性的。部分内容是箴言式的、概要性的，其余部分将分析Unix开发中的具体案例。在普遍规律、箴言的之前或之后，我们将给出解释性的例子：例子不是来自玩具般的演示程序，而是来自每天都在使用的、真实的运行代码。
We have deliberately avoided filling the book with lots of code or specification-file examples, even though in many places this might have made it easier to write (and in some places perhaps easier to read!). Most books about programming give too many low-level details and examples, but fail at giving the reader a high-level feel for what is really going on. In this book, we prefer to err in the opposite direction.
有意地，我们避免在书中塞入大量代码或说明文档般的例子，虽然在很多地方这可以使得下笔更为容易（在一些地方，或许会使得阅读更加容易！）。大多数关于程序设计的书，给出了太多低层次的细节和例子，但在给予读者什么是实际进行的高层次感受这方面，却失败了。本书中，我们宁愿犯相反的错误。
Therefore, while you will often be invited to read code and specification files, relatively few are actually included in the book. Instead, we point you at examples on the Web.
因此，虽然书中经常鼓励你阅读代码和说明文档，实际给出的代码和文档却相对较少。作为替代，我们给出了例子的网址。
Absorbing these examples will help solidify the principles you learn into semi-instinctive working knowledge. Ideally, you should read this book near the console of a running Unix system, with a Web browser handy. Any Unix will do, but the software case studies are more likely to be preinstalled and immediately available for inspection on a Linux system. The pointers in the book are invitations to browse and experiment. Introduction of these pointers is paced so that wandering off to explore for a while won’t break up exposition that has to be continuous.
消化这些例子，这将有助于巩固你学到的原理，使他们成为近似于本能的应用知识。理想情况下，你应该在靠近控制台的地方阅读本书，控制台运行着Unix系统，Web浏览器已准备好。任何Unix都可以，在Linux系统上，软件研究案例很可能已经预先安装好了，马上就能查看使用。书中的链接是要鼓励你进行浏览和实验。这些链接被放置在恰当的地方，你可以离开正文去探索一会，而又不会中断那些需要保持连续的说明。
Note: while we have made every effort to cite URLs that should remain stable and usable, there is no way we can guarantee this. If you find that a cited link has gone stale, use common sense and do a phrase search with your favorite Web search engine. Where possible we suggest ways to do this near the URLs we cite.
注意：尽管我们已尽最大努力，只引用那些将继续稳定的、可用的URL，但我们不能保证这一点。如果发现某个引用的链接已经失效，根据你的常识，用你最喜欢的Web搜索引擎进行短语搜索吧。只要可能，我们就将在引用的URL旁边提出搜索建议。
Most abbreviations used in this book are expanded at first use. For convenience, we have also provided a glossary in an appendix.
本书所使用的大部分缩写词，在第一次使用时都将给出全称。为方便起见，我们在附录中还提供了术语表。
References are usually by author name. Numbered footnotes are for URLs that would intrude on the text or that we suspect might be perishable; also for asides, war stories, and jokes.[2]
参考文献通常以作者姓名的形式给出。带编号的脚注，用于不合适进入正文的URL，或者用于那些我们怀疑可能将要失效的URL；带编号的脚注还用于旁白、论战故事和玩笑[2]。
To make this book more accessible to less technical readers, we invited some non-programmers to read it and identify terms that seemed both obscure and necessary to the flow of exposition. We also use footnotes for definitions of elementary terms that an experienced programmer is unlikely to need.
对于技术性不那么强的读者，为了使本书更易于理解，我们邀请了一些非程序员阅读本书，标识出那些看上去晦涩但又是阐述所必须的术语。我们同样使用脚注来定义基本术语，有经验的程序员可能不需要这些定义。
Some famous papers and a few books by Unix’s early developers have mined this territory before. Kernighan & Pike’s The Unix Programming Environment [Kernighan-Pike84] stands out among these and is rightly considered a classic. But today it shows its age a bit; it doesn’t cover the Internet, and the World Wide Web or the new wave of interpreted languages like Perl, Tcl, and Python.
一些著名的论文、Unix早期开发者写的一些书籍，之前已经探索过此领域。Kernighan & Pike的《Unix编程环境》[Kernighan-Pike84]就是其中出色的一本，堪称经典。但今天它显得有一些陈旧了；它没有涉及Internet、World Wide Web，也没有谈到诸如Perl、Tcl 和Python这样的解释型语言的新浪潮。
About halfway into the composition of this book, we learned of Mike Gancarz’s The Unix Philosophy[Gancarz]. This book is excellent within its range, but did not attempt to cover the full spectrum of topics we felt needed to be addressed. Nevertheless we are grateful to the author for the reminder that the very simplest Unix design patterns have been the most persistent and successful ones.
大致在本书写作的中途，我们见到了Mike Gancarz的The Unix Philosophy [Gancarz]。这本书在其讨论范围内非常优秀，不过它没有尝试覆盖我们觉得需要提及的全部话题。然而，我们要感谢作者的提醒：最简单的Unix设计模式就是最持久的、最成功的模式。
The Pragmatic Programmer [Hunt-Thomas] is a witty and wise disquisition on good design practice pitched at a slightly different level of the software-design craft (more about coding, less about higher-level partitioning of problems) than this book. The authors’ philosophy is an outgrowth of Unix experience, and it is an excellent complement to this book.
《程序员修炼之道》（The Pragmatic Programmer）[Hunt-Thomas]是诙谐而机智的、关于良好设计实践的专题研究；与本书相比较，在软件设计工艺的层次上，它的定位略有不同（更多地讨论编码，较少关注高层次的问题)。其作者的思想观点是Unix经验的产物，《程序员修炼之道》是本书极好的补充读物。
The Practice of Programming [Kernighan-Pike99] covers some of the same ground as The Pragmatic Programmer from a position deep within the Unix tradition.
《程序设计实践》[Kernighan-Pike99]从Unix传统的比较深入的位置上，讨论了一些与《程序员修炼之道》处于同一层面的问题。
Finally (and with admitted intent to provoke) we recommend Zen Flesh, Zen Bones [Reps-Senzaki], an important collection of Zen Buddhist primary sources. References to Zen are scattered throughout this book. They are included because Zen provides a vocabulary for addressing some ideas that turn out to be very important for software design but are otherwise very difficult to hold in the mind. Readers with religious attachments are invited to consider Zen not as a religion but as a therapeutic form of mental discipline —which, in its purest non-theistic forms, is exactly what Zen is.
最后，（承认是有意挑起争论，）我们推荐Zen Flesh, Zen Bones [Reps-Senzaki]，一本重要的关于佛教禅宗起源的集子。关于禅的参考文献散布在这本书中。推荐它，是因为在讨论一些概念时——已经表明，这些概念对于软件设计非常重要——禅提供了相应的词汇，否则的话，很难在头脑中把握这些概念。有宗教信仰的读者，不应该把禅视为宗教，而应把它看作是一种心智训练的有效形式——从最纯粹的无神论意义上讲，这就是禅。
! Conventions Used in This Book
The term “UNIX” is technically and legally a trademark of The Open Group, and should formally be used only for operating systems which are certified to have passed The Open Group’s elaborate standards-conformance tests. In this book we use “Unix” in the looser sense widely current among programmers, to refer to any operating system (whether formally Unix-branded or not) that is either genetically descended from Bell Labs’s ancestral Unix code or written in close imitation of its descendants. In particular, Linux (from which we draw most of our examples) is a Unix under this definition.
术语“UNIX”是技术上、法律上的商标，隶属于开源组织（Open Group），只应当正式地用于那些已通过开源组织详尽的标准一致性测试认证的操作系统。本书中，我们以一种含义上比较不严谨、但已被程序员广为接受的方式来使用“Unix”，指的是任何这样的操作系统（无论是否正式贴上了Unix标签），它或者是贝尔实验室始祖Unix代码的遗传后裔、或者在很大程度上模仿了这些遗传后裔。特别指出，在这个定义下，Linux（我们的大部分例子都来自于Linux）就是Unix。
This book employs the Unix manual page convention of tagging Unix facilities with a following manual section in parentheses, usually on first introduction when we want to emphasize that this is a Unix command. Thus, for example, read “munger(1)” as “the ‘munger’ program, which will be documented in section 1 (user tools) of the Unix manual pages, if it’s present on your system.”Section 2 is C system calls, section 3 is C library calls, section 5 is file formats and protocols, section 8 is system administration tools. Other sections vary among Unixes but are not cited in this book. For more, type man 1 man at your Unix shell prompt (older System V Unixes may require man -s 1 man).
本书使用Unix手册分页惯例，在Unix工具名的后面跟一个圆括号，括号内是手册中的相应小节，在第一次介绍命令时，如果我们想要强调这是Unix命令，我们通常就会使用这样的方式。例如，把“munger(1)”理解为“munger程序，相应文档在Unix手册第1小节（用户工具），如果你的系统上有munger的话”。第2小节是C系统调用，第3小节是C库函数调用，第5小节是文件格式和协议，第8小节是系统管理工具。其他小节在Unix系统中各不相同，但在本书中不会被引用到。要显示更多信息，在你Unix的shell提示符下键入man 1 man（对于较老的System V Unix系统，可能要键入man -s 1 man）。
Sometimes we mention a Unix application (such as Emacs), without a manual-section suffix and capitalized. This is a clue that the name actually represents a well-established family of Unix programs with essentially the same function, and we are discussing generic properties of all of them. Emacs, for example, includes xemacs.
时不时地，我们在提及某个Unix应用（比如，Emacs）时，没有给出手册-小节后缀，而且还大写其首字母。这是在暗示，提到的名字实际上代表了已被广泛接受的一类Unix程序，本质上他们具有相同的功能，而我们讨论的是其共同特性。例如，Emacs就包括了xemacs。
At various points later in this book we refer to ‘old school’ and ‘new school’ methods. As with rap music, new-school starts about 1990. In this context, it’s associated with the rise of scripting languages, GUIs, open-source Unixes, and the Web. Old-school refers to the pre-1990 (and especially pre-1985) world of expensive (shared) computers, proprietary Unixes, scripting in shell, and C everywhere. This difference is worth pointing out because cheaper and less memory-constrained machines have wrought some significant changes on the Unix programming style.
本书后面的很多地方，我们会谈到老流派（old school）和新流派（new school）方法。类似于RAP音乐，新流派起始于1990年左右。在这样的时间背景下，新流派与脚本语言、GUI、开源Unix和Web的兴起联系在了一起。老流派指的是1990年以前（尤其是1985年以前）的世界，这是属于昂贵（共享）计算机、专属Unix、shell脚本以及无处不在的C的世界。指出新老流派的区别是有意义的，因为更便宜、较少受到内存约束的计算机，已经致使Unix程序设计风格产生了某些重大变化。
A lot of books on programming rely on toy examples constructed specifically to prove a point. This one won’t. Our case studies will be real, pre-existing pieces of software that are in production use every day. Here are some of the major ones:
很多程序设计的书籍，依靠的是专为证明某一观点而构建的玩具例子。本书则不是这样。我们的研究案例都是软件真实的、已经存在的片断，这些软件每天都在生产环境中使用。下面是一些比较重要的例子：
cdrtools/xcdroast:
These two separate projects are usually used together. The cdrtools package is a set of CLI tools for writing CD-ROMs; Web search for “cdrtools”. The xcdroast application is a GUI front end for cdrtools; see the xcdroast project site [http://www.xcdroast.org/].
cdrtools/xcdroast：
这是两个单独的工程，但通常在一起使用。cdrtools工具包是一组用于光盘刻录的CLI工具；用cdrtools进行Web搜索吧。xcdroast应用是cdrtools的GUI前端；请参阅xcdroast工程站点 [http://www.xcdroast.org/]。
fetchmail:
The fetchmail program retrieves mail from remote-mail servers using the POP3 or IMAP post-office protocols. See the fetchmail home page [http://www.catb.org/~esr/fetchmail] (or search for “fetchmail” on the Web).
fetchmail：
fetchmail程序使用POP3或IMAP邮局协议，从远程邮件服务器上获取邮件。请参阅fetchmail的主页 [http://www.catb.org/~esr/fetchmail]（或者在Web上搜索fetchmail）。
GIMP:
The GIMP (GNU Image Manipulation Program) is a full-featured paint, draw, and image-manipulation program that can edit a huge variety of graphical formats in sophisticated ways. Sources are avail-able from the GIMP home page [http://www.gimp.org/] (or search for "GIMP" on the Web).
GIMP:
GIMP（GNU Image Manipulation Program，GNU图像处理程序）是功能齐全的绘图和图像处理程序，能够以完善的方式编辑种类繁多的图形格式。源代码可以从GIMP主页 [http://www.gimp.org/]（或者在Web上搜索GIMP）获取。
mutt:
The mutt mail user agent is the current best-of-breed among text-based Unix electronic mail agents, with notably good support for MIME (Multipurpose Internet Mail Extensions) and the use of privacy aids such as PGP (Pretty Good Privacy) and GPG (GNU Privacy Guard). Source code and executable binaries are available at the Mutt project site [http://www.mutt.org].
mutt：
mutt邮件用户代理，是当前最好的基于文本的Unix电子邮件代理，对MIME（Multipurpose Internet Mail Extensions，多用途互联网邮件扩展）有很好的支持，并且使用了诸如PGP（Pretty Good Privacy）、GPG（GNU Privacy Guard）这样的个人隐私辅助工具。源码和可执行二进制代码可以在Mutt工程站点上找到 [http://www.mutt.org]。
xmlto:
The xmlto command renders DocBook and other XML documents in various output formats, including HTML and text and PostScript. For sources and documentation, see the xmlto project site [http://cyberelk.net/tim/xmlto/].
xmlto：
xmlto命令，把DocBook和其他XML文档转换为各种输出格式，输出格式包括HTML、纯文本和PostScript。源码和文档，见xmlto工程网站 [http://cyberelk.net/tim/xmlto/]。
To minimize the amount of code the user needs to read to understand the examples, we have tried to choose case studies that can be used more than once, ideally to illustrate several different design principles and practices. For this same reason, many of the examples are from my projects. No claim that these are the best possible ones is implied, merely that I find them sufficiently familiar to be useful for multiple expository purposes.
要理解例子，读者需要阅读一定数量的源代码；为了最小化源代码的阅读量，我们试图选择那些能够被多次使用的研究案例，理想情况下，例子应该能够用来说明几种不同的设计原则和实践。出于这个目的，很多例子出自我的工程。这不是在暗示他们是最好的例子，我只不过是更熟悉他们，而且他们能用于多种解释性用途。
The guest contributors (Ken Arnold, Steven M. Bellovin, Stuart Feldman, Jim Gettys, Steve Johnson, Brian Kernighan, David Korn, Mike Lesk, Doug McIlroy, Marshall Kirk McKusick, Keith Packard, Henry Spencer, and Ken Thompson) added a great deal of value to this book. Doug McIlroy, in particular, went far beyond the call of duty in the thoroughness of his critique and the depth of his contributions, displaying the same care and dedication to excellence which he brought to managing the original Unix research group thirty years ago.
客串撰稿嘉宾（Ken Arnold、Steven M. Bellovin、Stuart Feldman、Jim Gettys、 Steve Johnson、Brian Kernighan、 David Korn、Mike Lesk、Doug McIlroy、 Marshall Kirk McKusick、Keith Packard、Henry Spencer以及Ken Thompson）极大地提升了本书的价值。特别是Doug McIlroy，在其评论的广度和所撰写文字的深度上面，远远超越了客串性质，展示出的关爱和追求卓越的奉献精神，与他三十年前管理最早期的Unix研究小组时所呈现的完全一样。
Special thanks go to Rob Landley and to my wife Catherine Raymond, both of whom delivered intensive line-by-line critiques of manuscript drafts. Rob’s insightful and attentive commentary actually inspired more than one entire chapter in the final manuscript, and he had a lot to do with its present organization and range; if he had written all the text he pushed me to improve, I would have to call him a co-author. Cathy was my test audience representing non-technical readers; to the extent this book is accessible to people who aren’t already programmers, that’s largely her doing.
特别感谢Rob Landley和我妻子Catherine Raymond，他们对草稿进行了逐行逐字的推敲。Rob见解深刻的、周密的评注，实际上激发了最终稿中超过一整章的内容，本书现在的组织和范围也与他关系颇大；对于那些他逼迫我改进的文字，如果他亲自动手的话，我将不得不称他为合著者。Cathy是我的测试对象，代表着非技术读者；非程序员也能阅读本书，本书能够达到这样的程度，很大程度上要归功于Cathy的工作。
This book benefited from discussions with many other people over the five years it took me to write it. Mark M. Miller helped me achieve enlightenment about threads. John Cowan supplied some insights about interface design patterns and drafted the case studies of wily and VM/CMS, and Jef Raskin showed me where the Rule of Least Surprise comes from. The UIUC System Architecture Group contributed useful feedback on early chapters. The sections on What Unix Gets Wrong and Flexibility in Depth were directly inspired by their review. Russell J. Nelson contributed the material on Bernstein chaining in Chapter 7. Jay Maynard contributed most of the material in the MVS case study in Chapter 3. Les Hatton provided many helpful comments on the Languages chapter and motivated the portion of Chapter 4 on Optimal Module Size. David A. Wheeler contributed many perceptive criticisms and some case-study material, especially in the Design part. Russ Cox helped develop the survey of Plan 9. Dennis Ritchie corrected me on some historical points about C.
在写作本书五年多的时间里，我同很多人进行的讨论，使得本书受益匪浅。Mark M. Miller帮助我深入理解线程。John Cowan提供了关于接口设计模式的一些深刻见解，他还草拟了wily和VM/CMS的研究案例，而Jef Raskin则告诉我“最少惊讶规则”（Rule of Least Surprise）出自哪里。对本书前几章，依利诺伊大学（UIUC）系统架构组提供了有用的反馈。“Unix什么地方做错了”（What Unix Gets Wrong）小节、“深度弹性”（Flexibility in Depth）小节，直接从他们评审中得到启发。Russell J. Nelson为第7章Bernstein链提供了资料。Jay Maynard为第3章MVS案例研究提供了大部分资料。对于“语言”这一章，Les Hatton提供了有益的评注，并促成了第4章关于“最佳模块大小”部分的写作。David A. Wheeler给出了很多敏锐的批评，提供了一些案例研究材料，尤其是在“设计”部分。Russ Cox帮助设计了Plan 9调查问卷。关于C的历史，Dennis Ritchie纠正了我的一些错误。
Hundreds of Unix programmers, far too many to list here, contributed advice and comments during the book’s public review period between January and June of 2003. As always, I found the process of open peer review over the Web both intensely challenging and intensely rewarding. Also as always, responsibility for any errors in the resulting work remains my own.
数百名Unix程序员，这里无法一一列出他们的姓名，在本书2003年1月至6月的公开评审期间，贡献了大量的建议和评注。一如既往地，我发现通过Web进行的公开的同行评审过程，充满了激烈的挑战，但回报也是丰厚的。还是同往常那样，书中有任何错误的话，责任在我。
The expository style and some of the concerns of this book have been influenced by the design patterns movement; indeed, I flirted with the idea of titling the book Unix Design Patterns. I didn’t, because I disagree with some of the implicit central dogmas of the movement and don’t feel the need to use all its formal apparatus or accept its cultural baggage. Nevertheless, my approach has certainly been influenced by Christopher Alexander’s work[3] (especially The Timeless Way of Building and A Pattern Language, and I owe the Gang of Four and other members of their school a large debt of gratitude for showing me how it is possible to use Alexander’s insights to talk about software design at a high level without merely uttering vague and useless generalities. Interested readers should see Design Patterns: Elements of Reusable Object-Oriented Software [GangOfFour] for an introduction to design patterns.
本书的叙述风格和一些观点，受到了设计模式运动的影响；实际上，我考虑过把本书叫做《Unix设计模式》的想法。不过我没有，因为我不赞同设计模式运动暗含的一些核心教条，不觉得有必要使用它的形式化方法，也不接受它的文化信仰。然而，我使用的方法的确受到了Christopher Alexander工作的影响[3]（尤其是《建筑的永恒之道》、《建筑模式语言》），我从“四人帮”（the Gang of Four）以及从他们学派的其他成员那里获益良多，他们向我表明：在高层次上讨论软件设计时如何使用Alexander的思想，避免模糊的、没有价值的泛泛讨论。对于设计模式导论，有兴趣的读者应该阅读《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）[GangOfFour]。
The title of this book is, of course, a reference to Donald Knuth’s The Art of Computer Programming. While not specifically associated with the Unix tradition, Knuth has been an influence on us all.
本书的标题，当然，是参考了Donald Knuth的《计算机程序设计艺术》。尽管和Unix传统没有什么特殊关系，Knuth还是影响了我们大家。
Editors with vision and imagination aren’t as common as they should be. Mark Taub is one; he saw merit in a stalled project and skillfully nudged me into finishing it. Copy editors with a good ear for prose style and enough ability to improve writing that isn’t like theirs are even less common, but Mary Lou Nohr makes that grade. Jerry Votta seized on my concept for the cover and made it look better than I had imagined. The whole crew at Prentice-Hall gets high marks for making the editorial and production process as painless as possible, and for cheerfully accommodating my control-freak tendencies not just over the text but deep into the details of the book’s visual design, art, and marketing.
具有远见和想像力的编辑，并没有像期望的那样常见。Mark Taub就是其中之一；他看到了这个一度停顿项目的价值，很技巧地推促我完成它。这样的文字编辑——十分留意写作风格、具有足够能力改善与他们自己写作风格不同的文字——就更不常见，但Mary Lou Nohr就是。Jerry Votta把握了我对封面的设想，使得封面看上去比我想象的还要好。我给Prentice-Hall的全体员工打了高分，他们使编辑和生产过程尽可能平稳，他们令人愉快地接纳了我的控制偏执趋向，这可是不仅要控制文字，还要深入到书籍外观设计、插图和市场营销的控制趋向。
Part I. Context
第一部分 背景
Chapter 1. Philosophy
第一章 哲学
Philosophy Matters
Those who do not understand Unix are condemned to reinvent it, poorly.
--
<author>HenrySpencer</author>
Usenet signature, November 1987
哲学有重大关系
谴责那些不懂Unix的人，叫他们拙劣地重新发明它。
--
<author>HenrySpencer</author>
Usenet签名，1987年11月
This is a book about Unix programming, but in it we’re going to toss around the words ‘culture’, ‘art’, and ‘philosophy’ a lot. If you are not a programmer, or you are a programmer who has had little contact with the Unix world, this may seem strange. But Unix has a culture; it has a distinctive art of programming; and it carries with it a powerful design philosophy. Understanding these traditions will help you build better software, even if you’re developing for a non-Unix platform.
这是一本关于Unix编程设计的书，但书中我们将多次谈论“文化”、“艺术”和“哲学”。如果你不是程序员，或者你是几乎不触及Unix世界的程序员，这看上去有点奇怪。但是，Unix有一个文化，有与众不同的程序设计艺术，Unix还承载着强大的设计哲学。理解这些传统将有助于你打造更好的软件，即使你现在是为非Unix平台开发软件。
Every branch of engineering and design has technical cultures. In most kinds of engineering, the unwritten traditions of the field are parts of a working practitioner’s education as important as (and, as experience grows, often more important than) the official handbooks and textbooks. Senior engineers develop huge bodies of implicit knowledge, which they pass to their juniors by (as Zen Buddhists put it) “a special transmission, outside the scriptures”.
每一个工程和设计的学科都有其技术文化。在绝大多数工程领域中，作为从业人员所受教育的一部分，学科内未成文的传统与正式的手册、教科书同样重要；随着经验的积累，未成文的传统常常显得更加重要。资深工程师们积累了庞大的未明言的知识体系，这些都将传授给他们的晚辈，传授的方式是（像禅宗说的那样）“教外别传”。
（译者注：对菩提达摩开创的禅宗，基本要点归结为四句：
| 教外别传 | A special transmission outside the scriptures; |
| 不立文字 | Depending not on words and letters; |
| 直指人心 | Pointing directly to the human mind; |
| 明性成佛。 | Seeing into one's nature, one becomes a Buddha. |
译注结束）
Software engineering is generally an exception to this rule; technology has changed so rapidly, software environments have come and gone so quickly, that technical cultures have been weak and ephemeral. There are, however, exceptions to this exception. A very few software technologies have proved durable enough to evolve strong technical cultures, distinctive arts, and an associated design philosophy transmitted across generations of engineers.
总的说来，软件工程是上述规律的例外；技术更迭迅速，软件环境来去频繁，技术文化变得微弱而短暂。然而，这个例外也有例外。有很少几种软件技术的持久性已得到证实，足以发展出强健的技术文化、与众不同的艺术，以及工程师们代代相传的相关设计思想。
The Unix culture is one of these. The Internet culture is another — or, in the twenty-first century, arguably the same one. The two have grown increasingly difficult to separate since the early 1980s, and in this book we won’t try particularly hard.
Unix文化就是其中之一，而另外一个是Internet文化——也许，在21世纪，可以论证它们就是同一种文化。从上世纪80年代早期开始，这两种文化越来越难以区分，本书中我们不打算刻意区分它们。
！Unix的持久性
Unix was born in 1969 and has been in continuous production use ever since. That’s several geologic eras by computer-industry standards — older than the PC or workstations or microprocessors or even video display terminals, and contemporaneous with the first semiconductor memories. Of all production timesharing systems today, only IBM’s VM/CMS can claim to have existed longer, and Unix machines have provided hundreds of thousands of times more service hours; indeed, Unix has probably supported more computing than all other timesharing systems put together.
Unix诞生于1969年，此后，就一直用于生产性用途。从计算机工业标准意义上看，那是好几个“地质代”以前——比PC、工作站、微处理器甚至比视频显示终端还要古老，与第一块半导体存储器处于同一时期。在今天所有的生产性分时系统中，只有IBM的VM/CMS能够声称存在的时间更长，但Unix机器提供的服务时间是IBM VM/CMS的数万倍；实际上，Unix支持的计算，可能比所有其他分时系统加在一起还要多。
Unix has found use on a wider variety of machines than any other operating system can claim. From supercomputers to handhelds and embedded networking hardware, through workstations and servers and PCs and minicomputers, Unix has probably seen more architectures and more odd hardware than any three other operating systems combined.
就操作系统使用的机器类型而言，使用Unix的机器类型要远远多于其他操作系统。大到超级计算机，小到手持设备、嵌入式网络硬件，中间则是工作站、服务器、PC以及小型计算机；Unix见过的体系结构和古怪硬件，可能比任何三种其他操作加起来还要多。
Unix has supported a mind-bogglingly wide spectrum of uses. No other operating system has shone simultaneously as a research vehicle, a friendly host for technical custom applications, a platform for commercial-off-the-shelf business software, and a vital component technology of the Internet.
Unix的用途范围之广，令人难以置信。Unix可以用作研究工具、技术应用软件的友好主机系统、市场上销售的成品商用软件的平台，同时还是Internet不可或缺的组成部分；除Unix之外，没有哪个操作系统能够在这些应用领域里都能表现得同样杰出。
Confident predictions that Unix would wither away, or be crowded out by other operating systems, have been made yearly since its infancy. And yet Unix, in its present-day avatars as Linux and BSD and Solaris and MacOS X and half a dozen other variants, seems stronger than ever today.
从Unix的初生时期开始，就有人大胆寓言：Unix将衰亡，或者被其他操作系统赶出舞台。然而，化身为Linux、BSD、Solaris、MacOS X以及诸多其他变体，今天的Unix似乎更加强大。
Robert Metcalf [the inventor of Ethernet] says that if something comes along to replace Ethernet, it will be called “Ethernet”, so therefore Ethernet will never die.[4] Unix has already undergone several such transformations.
--
<author>KenThompson</author>
Robert Metcalf（以太网发明人）说过，如果出现了能够替代以太网的东西，它就将叫做“以太网”，从而以太网永远不会消亡[4]。Unix也经历了若干类似的改变。
--
<author>KenThompson</author>
At least one of Unix’s central technologies — the C language — has been widely naturalized elsewhere. Indeed it is now hard to imagine doing software engineering without C as a ubiquitous common language of systems programming. Unix also introduced both the now-ubiquitous tree-shaped file namespace with directory nodes and the pipeline for connecting programs.
至少，Unix的核心技术之一——C语言——已经被广为移植。实际上，很难想象这样的软件工程，它不把C用做系统程序设计的普遍、共同的语言。Unix还引入了现在无处不在的带有目录节点的树状文件，引入了连接程序的管道技术。
Unix’s durability and adaptability have been nothing short of astonishing. Other technologies have come and gone like mayflies. Machines have increased a thousandfold in power, languages have mutated, industry practice has gone through multiple revolutions — and Unix hangs in there, still producing, still paying the bills, and still commanding loyalty from many of the best and brightest software technologists on the planet.
Unix的持久性和适应性，总是让我们惊讶不已。其它技术象蜉蝣一样来了又去了。机器性能已提升了上千倍、语言发生了变异、工业实践也经历了数次革命——Unix依然矗立在那里，还在进行生产性的运转，还在处理帐单，依然得到了许多这个星球上最优秀最聪明的软件技术专家的忠实拥戴。
One of the many consequences of the exponential power-versus-time curve in computing, and the corresponding pace of software development, is that 50% of what one knows becomes obsolete over every 18 months. Unix does not abolish this phenomenon, but does do a good job of containing it. There’s a bedrock of unchanging basics —languages, system calls, and tool invocations —that one can actually keep using for years, even decades. Elsewhere it is impossible to predict what will be stable; even entire operating systems cycle out of use. Under Unix, there is a fairly sharp distinction between transient knowledge and lasting knowledge, and one can know ahead of time (with about 90% certainty) which category something is likely to fall in when one learns it. Thus the loyalty Unix commands.
考虑计算能力－时间的指数曲线、考虑软件发展的相应步伐，推断的结果之一是：你所知道的东西，每18个月就有50％会过时。Unix不是这个观察现象的例外，反而吻合得很好。没有改变的是根基——语言、系统调用和工具的用法——它们还能使用数年，甚至数十年。其他地方，就不可能预测哪些将是稳定；甚至，整个操作系统都可能不再被使用。在Unix下，短暂知识和持久知识之间的区分相当明显，在你学习某种东西时，基本能事先推断（大概有90％的确定性）你所学的属于短暂知识还是持久知识。这就是Unix得到拥戴的原因。
Much of Unix’s stability and success has to be attributed to its inherent strengths, to design decisions Ken Thompson, Dennis Ritchie, Brian Kernighan, Doug McIlroy, Rob Pike and other early Unix developers made back at the beginning; decisions that have been proven sound over and over. But just as much is due to the design philosophy, art of programming, and technical culture that grew up around Unix in the early days. This tradition has continuously and successfully propagated itself in symbiosis with Unix ever since.
Unix的稳定和成功，大部分要归因于其固有的强壮、归因于 Ken Thompson、Dennis Ritchie、Brian Kernighan、Doug McIlroy、Rob Pike 以及其他早期 Unix 开发者从最开始就做出的设计决策；决策的正确性已经得到反复证明。但是，早期围绕着Unix成长起来的设计思想、程序设计艺术、技术文化同样贡献巨大。这个传统，还将继续地成功地传承下去，始终与Unix息息相依。
[1] The three and a half decades between 1969 and 2003 is a long time. Going by the historical trend curve in number of Unix sites during that period, probably somewhere upwards of fifty million man-years have been plowed into Unix development worldwide.
1969到2003的35个年头是段漫长的时间。这个时期，伴随着Unix站点数量的历史增长趋势线，大概有超过五千万人年，干劲十足地投入了到全球Unix开发中。
[2] This particular footnote is dedicated to Terry Pratchett, whose use of footnotes is quite...inspiring.
本条特别脚注献给Terry Pratchett，他对脚注的使用是相当……启发性的。
[3] An appreciation of Alexander’s work, with links to on-line versions of significant portions, may be found at Some Notes on Christopher Alexander [http://www.math.utsa.edu/sphere/salingar/Chris.text.html].
对Alexander工作的赏析，以及指向其书中重要部分在线版本的链接，可以在Some Notes on Christopher Alexander网站找到 [http://www.math.utsa.edu/sphere/salingar/Chris.text.html]。
[4] In fact, Ethernet has already been replaced by a different technology with the same name — twice. Once when coax was replaced with twisted pair, and a second time when gigabit Ethernet came in.
事实上，以太网已经为有着相同名字的不同技术所替代——而且替代了两次。一次是双绞线替代了同轴电缆，第二次是千兆以太网的出现。
2199
到【灌水乐园】发言
评论
http://blog.csdn.net/vennlx/archive/2004/07/16/43229.aspx
前几天有人公开自己的译稿，大家七嘴八舌的，这样子搞很难判断大家的真实水平了。出版社可能没有料到这一点，呵呵。
另外，拜托抄的时候小心些，是“见性成佛”。
2、如果你能对出版社施展影响，那么你是谁？什么动机？
3、如果你不能对出版社施加影响，那么你又是谁？什么动机？
dd上面的话，超级暧昧，很容易引起误会。——比如，我们可否怀疑，dd就是博文视点的人或者是内部人士？
呵呵。
哪些地方是参考了别人？请指出来。——我知道哪些地方参考了，呵呵，不会超过3处，还都是很细小的地方——而且并不可耻。海纳百川，有容奶大。
＝＝＝＝＝
你这个算是集众家之长了。要你自己搞估计更不行。
前几天有人公开自己的译稿，大家七嘴八舌的，这样子搞很难判断大家的真实水平了。出版社可能没有料到这一点，呵呵。
另外，拜托抄的时候小心些，是“见性成佛”。
＝＝＝＝＝＝
很不上路。你这个人心理比较阴暗啊，哈哈。
讨论里面，主要是我在发言。有人在tmd与人打嘴仗——以一种很奇怪的方式在论战。
你有两点结论比较突兀：一是什么“更不行”，二是“抄袭”。下结论的时候千万要当心，不要胡乱推测。
其实dd啊，你完全可以参考我的翻译，拿出自己的翻译样稿来——我的结论是：你肯定不会超过我——你肯定不会同意对不对？OK，just do it.
不要介意，谈点个人感觉，不一定对。
比如第一句，别人是这么译的，“Unix，与其说是操作系统，不如说是口述历史。”，你也跟着走，其中，“口述历史”让人有动词 + 名词的感觉，觉得是一个动作，你觉得译为“一部口述史”是否更好呢？
>2、如果你能对出版社施展影响，那么你是谁？什么动机？
没有啊，个人感觉。在 blog 随意发表评论，有什么动机？
>3、如果你不能对出版社施加影响，那么你又是谁？什么动机？
不认识任何一个任何出版社的人 :(
>译者注：对菩提达摩开创的禅宗，基本要点归结为四句：
另外，你不懂禅宗，佛经都没有读过几卷，最好不要乱注释，误导读者。禅宗不是你说的那样。
一个概念问题：The Open Group可不是什么“开源组织”。别一见open就以为是开源。呵呵。The Open Group就像Sun, Microsoft一样，是法人，可以不译，只呼其名就行了。
原来是你老哥。同意啊，怎么不同意。最后我不是说“你对“了吗。
“Unix，与其说是操作系统，不如说是口述历史。”——这个逗号别人可没有加啊。关于oral history怎么翻译，在老袁的帖子后面我有谈到选择这个词的过程。——“一部”要不要加，就是个人口味问题了，很难判断好坏——语言是活的东西，没有那么对规则来限制的。
禅宗以前看过，忘记了，现在也不打算再看。但是。在翻译的时候，起码要知道这是比较关键的地方，要去查资料的，搞明白。至于对达摩的四句总结，肯定不是我的意思，是很多专门研究禅宗的专家的意见——他们说的禅宗也与你理解的不一样，我们听谁的啊？
比如Plan 9，看见这个东西，就不能简单地翻译“计划9”，必然是有所指，就要去搞清楚。比如old school, new school，也得去查阅资料，了解了解rap的历史。
承认无知并不可怕，关键是在翻译的时候不能想当然，需要小心处理，不能犯错误。多请教专家，多看相关资料。
出版社我也不认识人，呵呵。最近正在试图与出版社联系，看看能不能够靠科技翻译吃饭呢。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
d兄的comments是启发性的，呵呵。谢谢。
Open Group不用翻译，留在那里是最好的选择。
这句话也不是针对你的。因为出版社现在肯定分不清每件译稿中有多少是提交者自己的，又有多少是来自别人的了。这是和出版社挑选译者的目的相悖的。当然，出版社至少炒作了一把，公开征求译者也是个不错的想法。
这四句只是禅宗的传授特点，说成禅宗的基本要点就偏了。
最后，声明一下: dd != d; 倒弟兄 != d. 呵呵。
臆测一下：
dd == aa？
如果是的话，摆脱你还是不要dd吧，confusing的说（当然，除非这就是你的主意，我总不能强制你不用dd）。如果不是，那抱歉，请当我没说。呵呵。
OK，说点建设性的 :)
>xmlto命令，把DocBook和其他XML文档转换为各种输出格式，输出格式包括HTML、纯文本和PostScript。源码和文档，见xmlto工程网站 [ http://cyberelk.net/tim/xmlto/]。
"输出格式包括" 能不能简化为 "包括"，因为前面已经提到是"输出格式"了。
这个应该没人会搞混淆吧?
不好意思，我 dd 、aa 随便来的，图方便。估计你也是。下面改为 aa。
于是在internet上一阵狂搜，终于搞定。
禅宗的基本要点，咳呀，我还真不清楚。当年看了一些粗浅的读物，以为他们鼓吹的就是一种积极的入世修炼。什么得道、成佛，都比较虚幻。——这是当年的理解，估计很不正确，哈。
话题谈开来。有个念研究生时的兄弟，皈依我佛了，很虔诚。好的一面是，他看上去精神非常好，身体也很更健康了，绝对给人一种阳光活力的感觉。坏的一面是，他的看问题、思考的方式，有点偏离了理性的批判轨道。喜欢预设前提，喜欢大胆结论，还开始向何新那一流派的“极端民族主义”靠拢。
呜呼，不提也罢。
或许，人到了一定的年龄段，都要在精神上务虚？
”源码和文档，见xmlto工程网站“前面加上一个”其“字，文气是否更顺畅一些？
佛和极端民族主义能够在同一个人身上统一，有意思。
>或许，人到了一定的年龄段，都要在精神上务虚？
看清楚了，就失望了；务虚就是失望的一种后果，当然还有其它的可以选择，比如和我一样，相信世界末日什么的 :)
尽量选择，尽量、尽力，褒义。试图好象中性甚至偏贬义一点？
>出于这个目的，
把 same 省掉了。为何不译成“出于同样的目的”呢？存疑。
＝＝＝＝＝＝＝＝＝＝＝
xmlto命令，把DocBook和其他XML文档转换为各种输出格式，输出格式包括HTML、纯文本和PostScript。源码和文档，见……
"输出格式包括" 能不能简化为 "包括"，因为前面已经提到是"输出格式"了。
＝＝＝＝＝＝＝＝＝＝＝
感谢建设性的comments。
这里的处理，是经过斟酌的，绝对不是没动大脑小脑就这么简单翻译了再说。:)。这个地方，恐怕也没有什么最好的处理方式吧？完全是口味问题——考虑之后我选择了“输出格式包括……”。这并不意味着我的选则就是对的。这里看样子还要再斟酌斟酌。
话题一转：科技翻译，其实还是很个性化的东西，在一些复杂的地方、一些灵活的地方，都体现了翻译者的个性。因此，简单的抄袭，基本上一看便知。
比如，我现在就喜欢把长句拆短，经常大声念出来，看是否憋气，也经常让我那些非技术的朋友难过难过——叫他们看看我翻译的天书，呵呵。
我觉得 The guest contributors 大概就是我这样挑挑刺、提点意见什么的多一点，但是还没有亲自上阵“撰稿”的地步。
不是很清楚出版社的事物，参考吧。
aa兄信基督还是真主？佛也有地狱说。
宗教这个东西，不好说。
虔诚的兄弟对我说：首先，你面对的宗教问题就是“接受或不接受”。我说，感情信仰都那么霸道？没有商量余地么？
如果我不接受基本教义，神就不管我的堕落了。我想：当我傻啊？不打个商量，那不行。我还是不要接受了吧，继续堕落。
这里的 care 似乎不是“关爱”的意思，是对 excellence 很关心、很在乎的意思。
>比如，我现在就喜欢把长句拆短，经常大声念出来，看是否憋气，也经常让我那些非技术的朋友难过难过——叫他们看看我翻译的天书，呵呵。
绚烂归于平淡，难。
>aa兄信基督还是真主？佛也有地狱说。
信基督、真主或者佛就不会有世界末日问题了。我相信科学 :)))
我喜欢内人(你又要 BS 我了:)。
觉得逐字逐句更合乎中国人的习惯，表达的也是同样的意思。
激发了内容，嗯，感觉有点那个。要不，引出了？
最终稿，似乎叫定稿、定案的比较多。
在写作本书的五年多时间里，哪个更好？
“部分观点”更合乎我的审美标准，你估计不会同意。
"核心教条",教条，贬义。“核心理念”
我考虑过把本书命名为《Unix设计模式》的想法
>技术性不那么强的读者
具有较少技术背景的读者
>很多好书
我喜欢“佳作”
>indeed for all programmers in any language
这里 language 指的是 C/Perl 这样的计算机编程语言呢，还是汉语、日语这样自然语言？多办是前者，可是后者也是一说。
>你应该阅读本书，如果你是应用架构师，对于主要通用市场或特定领域的纵向应用软件，你在考虑软件的平台或实施策略。本书将有助于你理解Unix作为开发平台的力量、理解开源作为开发方式的Unix传统的力量。
主要通用市场，有点别扭 -> 主流通用市场
考虑软件的平台或实施策略 -> 考虑不排除细节，考量似乎更强调总体性，从大的方面考察，更切合本书主题。
特定领域的纵向应用软件？这个不好译啊 :(
理解开源作为开发方式的Unix传统的力量 -> 加个以，理解以开源作为开发方式的Unix传统的力量？
总的说来，我喜欢这样：
你应该阅读本书，如果你作为应用架构师，正在考量对于主要通用市场或特定领域的纵向应用软件的平台或实施策略。
从 xmlto 开始让我感觉不好的地方就这些了。前面估计少一些，因为讨论的人只看前面的多，后面的大家懒得看 :)
其实我心目中理想的译者是一个有 5 年左右(10 年更好，但是难找) Unix 经验的人，比较支持开源运动(同声相应，这样才能更深入理解作者的思想)。对书中提到的软件都有了解，比如用过 fetchmail 收 email、用过 DocBook 写文档、用过 GIMP 处理图片。
PS: 找到一个，息息相依，我出的主意 ;)
科技翻译小有心得的，这不是好人家的孩子干的活。
报酬低、太累，牛人是不屑做的——最多玩票似地干一把，博点名声。
首先，这个英语你要过关。CET6根本连门都没有入——不要用砖头砸我，我大二就过了cet6，知道其水平。
然后，你得有一定的科技翻译经验，不亲自下水翻译数十万字，都不敢说有经验。
第三，你得技术敏感。不一定是技术专家，但要技术敏感，否则要成厦门大学的老邱。
这个第四么，中文还得要过关，知识面最好广泛一点，连《九阳真经》都要看！
满足以上条件的人真的不多。
如果是牛人，牛气起来，或者就自己写上一本了，哈。
什么事情要做精深，都要有爱好撑着；当然，天赋也重要。你过 CET-6 玩似的，可是 CET-4 却难倒我，活活气死的是我才对。其实美国鬼子平常写的英文随心所欲，哪有什么狗屁语法了，CET-4 肯定过不了。
希望你将来成名成家以后，还能够矢志不移。贫，气不改！ 达，志不改!
比如佛经上说，佛教本身要修禅定、断烦恼、显常住真心性净明体、破种种妄惑颠倒、终达无上涅槃妙境。不论是禅宗还是什么宗，大乘还是小乘，苦修还是顿悟，区别只是修行的方法。但是佛祖也说，法性常真，各随根性，门门方便，皆可证入圆通。
几百年前从天竺文翻译来的，也不知道准不准。不过我更相信这些佛塔里的译者，至少他们都有一颗虔诚的心。
如果我不接受基本教义，神就不管我的堕落了。我想：当我傻啊？不打个商量，那不行。我还是不要接受了吧，继续堕落。
信仰必须信的是永恒不变的终极真理。既然是终极真理，那就应该超乎人自己。信仰个什么人的理论，那就完了，因为人的理论终归都是错的。因此，科学是不能成为信仰的，因为科学是人的思想，在人之下。信仰科学云云者，多半还没有清楚什么是信仰。
所以，有信仰的人都认为她所信的是真理，这是一个逻辑大前提。而真理是没得商量的，你要不接受，逻辑上只有一个后果：玩完；就象一个人愣不接受地球引力，非要跳楼试试一样。所以，“信仰都那么霸道，没有商量余地么”是必然的。觉得奇怪是因为信仰在我们的经验之外。
首先澄清一下，说相信世界末日云云当然是开玩笑的。话说回来，如果世界末日真的来了，那么肯定是科学的暴力美学杰作无疑。
一个对科学有基本概念的人一般不会认为某一理论是万古不易的终极真理。如果有，那也是信仰这套理论，不是信仰科学。这种信仰太容易被打破，一个实验而已，所以早就不流行了。
大致上，说“相信科学”或者“信仰科学”的人，主要指的是“相信科学的那一套方法可以解决我们的一切问题，可以解释一切客观现象，可以让我们知道过去未来”。这个就是比较好的信仰题材，因为今天解决不了，可以推到明天，没有被当场推翻危险 :)
所以“信仰科学”其实是“信仰科学的那套方法论”的简单说法，至少对我而言是这样。当然，你可能不会这样想。不同的人对同样的字眼有完全不同的理解，也属正常。
然而，作为人类，我们大概在科学上面临各种理论的和实际的极限。思考科学会不会在未来的某一天和石油一样被采干，实在是打发时间的有效方法。
虽然和话题无关，还是想说，有意思的是，拿出歌德尔不完备性定理来证明机器不如人的家伙，大多数并不理解歌德尔定理。
其实我们早就糊里糊涂、不加思索地接受、相信了一大堆自相矛盾的东西。比如翻开历史书，前一页说“中国人民是爱好和平的，永远不称霸”，后一页就是“坑杀赵卒 40 万”“黄巢把人磨碎了做粮食”。中国那么大地盘，不是杀出来的，难道还是别人送的？
这算不算信仰呢？也许是傻吧？