翻译 2004年07月18日 18:20:00






Unix is not so much an operating system as an oral history.




―― 作者:NealStephenson



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.





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.





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.





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.





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 ,YaccPerlPython的参考,它不是网络初级编程,也不是一本神秘的X指南,它也不是一本对Unix体系结构入门的书。其他的书在这些细节上写得更好,这本书仅点到为止。



Beyond all these technical specifics, the Unix culture has an unwritten engineering tradition that has developed over literally millions of man-years 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文化有个不成文的工程惯例,在这个惯例的基础上已经发展了几百万人年的成就。这本书正式秉着这个惯例的理念写的。 并且把它的设计模式加进了你的工具包,这将帮助你成为更好的程序员和设计师。



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.





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.





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.






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.





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.





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.





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环境高级编程》[Stevens92]Unix API 书籍中的杰作,《编程实践》[Kernighan-Pike99]是所有C程序员的推荐读物(实际上是使用任何一种语言的程序员)。



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.





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.





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.





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





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






Related References



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、万维网或解释语言的浪潮,例如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的书《Unix思想》[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 Practice of Programming [Kernighan-Pike99] covers some of the same ground as The Pragmatic

Programmer from a position deep within the Unix tradition.




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.


最后(带有一定目的),我们推荐《禅、肉体和尸体》 [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.





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手册的第一部分说明,如果Unix手册在你的系统上存在的话。第二部分是C系统调用,第三部分是C库调用,第五部分是文件格式和协议,第八部分是系统管理工具。其他的部分在Unixes之间变化,但是在本书中并没有引用。更多,在你的Unix系统下输入man 1 man shell命令(在更老的系统V Unixes上可能是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.


本书中,在各种不同的点后我们涉及“老学校”和“新学校”方法。像快板歌一样,“新学校”开始于大约1990年。在这个过程中,随着脚本语言、GUIs、开源Unixes和Web的壮大,与他们相关联。“老学校”涉及到1990年之前(尤其是1985年之前)昂贵的电脑、所有的Unixes、shell中的脚本 和 无处不在的C。值得指出的不同点是便宜和更小的内存促进了Unix程序风格的一些重要的改变。



Our Case Studies



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 2个相关的项目通常一起使用。cdrtools工具包是一系列CLI关于写CD-ROM的CLI工具集;通过网络搜索“cdrtools”。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程序利用POP3IMAP邮局协议从远端邮件服务器收回mail.请查看Fetchmail的主页。[http://www.catb.org/~esr/fetchmail](或在网上查找“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 available from the GIMP home page [http://www.gimp.org/] (or search for "GIMP" on the Web).


GIMP                GIMPGNU图形操作程序)是一个全功能的绘画、图形处理程序,它可以神秘的处理各种各样的图形格式。可以从GIMP主页上得到源代码。[http://www.gimp.org/](或者在网上查找“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(多用途网络邮件扩展)有相当好的支持,并且带有隐私帮助,例如PGPPretty Good Privacy)和GPGGNU 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 其他的文档 呈现出各种输出格式,包括 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.





Author’s Acknowledgements



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, and 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是作为非技术读者,是我的测试观众。这本书在内容上对非程序员的可读性,很大程度上源于她的努力。



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系统构架组对早期的章节提供了有用的反馈。(What Unix Gets Wrong and Flexibility in Depth)部分直接来源于他们评审的灵感。Russell J. Nelson对第七章的Bernstein chaining提供了很多材料。Jay Maynard提供了第三章MVS个里研究的绝大部分材料。Les Hatton给Languages章节提供了学多有用的评论,激发了第四章Optimal Module Size的一部分。David A. Wheeler提供了许多有意义的批评和一些个例研究材料,尤其是在设计(Design)部分。Russ Cox发展了survey of Plan 9。Dennis Ritchie纠正了我的一些C的历史的错误。



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. 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 (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程序员,由于太多这儿无法罗列。在2003年1月到6月的公共评审阶段它们贡献了很多有用的建议和评论。所以,我发现放在web上进行公共评审是既有挑战也有丰厚的回报的。而且,对结果工作中遗留的任何错误的责任。这本书的说明风格和本书一些涉及项已经被涉及模式运动所影响。确实,我犹豫着是否这本书的名字应该是《Unix设计模式》。我并没有那么做,我并不盲从这场运动的教条,并且我认为确实没必要接受他的正式的设备和他的文化包袱。然而,我的接近当然被Christopher Alexander的工作所影响。(尤其是《建筑的永恒方法》和《一种模式语言》,我归功于“四人帮”和其他的大量指引我可能利用Alexander的洞察力在几乎没有含糊的高水平的软件设计。有兴趣的读者可以看看《设计模式》和《可重用面向对象软件原理》[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. 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.



这本书的标题当然是参考了Donald Knuth的《计算机编程艺术》。然而于Unix传统关联不是很大,Knuth已经对我们有很大的影响。编辑的想象并不是他们应该的那么普通。Mark Taub是其中的一个,她看到一个中断的工程的价值并且说服我去完成它。有散文风格和足够能力提高写作的拷贝编辑们不是像他们那样less common,但是Mary Lou Nohr做出了成绩。Jerry Votta抓住了我的封面的核心,并且它比我想象的要好。Prentice-Hall的全体人员在编辑和出版过程得到了很高的评价,在我的文本而不是书的可视化设计、艺术和市场的详细内容的也有很高的评价。






Chapter 1. Philosophy

第一章 思想

Philosophy Matters


Those who do not understand Unix are condemned to reinvent it, poorly.


Usenet signature, November 1987



-- HenrySpencer 1987.11



Culture? What Culture?



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. 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”.


这是一本Unix编程的书,但是在本书中我们并不打算围绕“文化”、“艺术”和“思想”等讨论很多。如果你还不是一个程序员,或者你是一个很少接触Unix世界的程序员,可能会感到有些奇怪。但是Unix有一种文化,它有与众不同的编程艺术,并且它承载了一种强大的设计思想。懂得这些传统将帮助你构件更好的软件,甚至你正在一个非Unix平台下开发软件。每一个工程设计的分支都有技术文化。在很多种类的工程中,该领域不成文的规定是从业者的学习范畴,这个同正式的手册和课本同样重要(并且随着经验的增长,越来越重要)。高级工程师发展了大量被证实为正确的知识,这些知识靠(正如Zen Buddhists说的)“特殊的方式,在文档之外的”这种方式传给后来的人。




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.






The Durability of 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 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 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已经提供了一个mind-bogglingly 范围的使用。没有哪个其他的操作系统有这样的研究手段,为技术定制应用程序的主机,商业软件平台,和 Internet技术的重要组件。



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. 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.


自信的语言,自从Unix产生的幼年开始,Unix终究会枯萎,或者被其他的操作系统所排挤。但是,Unix,和他的具体存在形式,如LinuxBSDSolarisMacOS X 和其他半打其他的操作系统,看起来比曾经的任何时候都要健壮,Robert Metcalf(以太网的发明者)说如果某个东西出来了并代替了以太网,它将叫做“以太网”,所以说以太网将不会灭亡。



4 Unix has already undergone several such transformations.




---- KenThompson


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 treeshaped file namespace with directory nodes and the pipeline for connecting programs.





Unix’s durability and adaptability have been nothing short of astonishing. Other technologies have come and gone like mayflies. Machines have increased a thousand fold 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.








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.





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传统在与Unix合作中已经不断的,成功的宣传它自己。




1The 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.





2This particular footnote is dedicated to Terry Pratchett, whose use of footnotes is quite...inspiring.


为这个特别的脚注做出贡献的Terry Pratchett,他对脚注的利用是非常受人鼓舞的。



3An 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].


3.非常感谢Alexander对在线连接翻译的部分重要工作,你可以在这个网站Christopher Alexander [http://www.math.utsa.edu/sphere/salingar/Chris.text.html] 找到一些笔记.



4In 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.





  • llwszjj
  • llwszjj
  • 2013年11月24日 15:11
  • 2423


公司入职前安排了读书环节,后台开发类推荐了一下书籍: C++ Primer Unix 环境高级编程(APUE) Unix网络编程 1/2卷(UNP) TCP/IP协议详解 深入理解计算机系统 Effe...
  • zy416548283
  • zy416548283
  • 2015年12月30日 20:30
  • 2282


unix哲学 让每个程序就做好一件事。如果有新任务,就重新开始,不要往原程序中加入新功能而搞得复杂。假定每个程序的输出都会成为另一个程序的输入,哪怕那个程序还是未知的。输出中不要有无关的信息干扰...
  • fishmai
  • fishmai
  • 2017年03月01日 08:33
  • 231


最近在学习《unix编程艺术》。第一章非常不错,讲了很多Unix的历史,哲学基础,其中最重要的是提到的十七条设计原则。很多原则自己也知道,但是从来没有总结的如此详细深刻。 下面的内容大部分来自《un...
  • chgaowei
  • chgaowei
  • 2011年07月29日 22:04
  • 2844


Unix 设计的统一思想:一切皆文件。 Linux是一个采取了Unix的设计思想,初始行为表现与Unix相同的操作系统,但Linux中的源码并未有任何出自Unix。Linux符合一切皆文件的思想,其...
  • Virtual_Func
  • Virtual_Func
  • 2017年04月07日 12:08
  • 396


  • gujinjin2008
  • gujinjin2008
  • 2014年08月17日 21:45
  • 1822


前三章:主要讲解了,unix的历史,以及与其他操作系统的不同之处 第四章:模块性-->保持清晰,保持简洁。 1:模块化的首要特质就是封装,不要过多的披露自身的细节,不胡乱共享全局数据,不直接调用其...
  • helloarm123456
  • helloarm123456
  • 2014年07月01日 11:00
  • 389

[总结]Unix设计哲学 <<Unix编程艺术>>

学习了第一章关于哲学的部分, 做个汇总. 现在已经对精简设计, 舍弃华而不实是被普遍认可的.但早在Unix发展的时期, 这一条原则却是在实践中不断提炼出来的. 这就是最为根本的一条:   KISS -...
  • HorkyChen
  • HorkyChen
  • 2012年05月29日 08:32
  • 3066


  • chgaowei
  • chgaowei
  • 2011年09月06日 20:11
  • 1893

【Unix编程艺术】第6章 透明性

第6章 透明性 如果实际上能预测到程序行为的全部或大部分情况,并能建立简单的心理模型,这个程序就是透明的。 如果软件系统所包含的功能是为了帮助人们对软件建立正确的“做什么、怎样做”的心理模型而设计...
  • hellokangning
  • hellokangning
  • 2014年03月06日 11:06
  • 567