Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

The Art of Unix Programming 358

Posted by timothy from the at-long-last-and-for-heather dept.
rjnagle writes "Eric S. Raymond (or ESR) is widely known for the groundbreaking series of essays in his book, The Cathedral and the Bazaar. In TCatB, he makes a credible case for why open source sofware works so well, and why community-supported software won't put developers out of a job. (I once attended a delightful talk he gave where, among other things, he gave sartorial advice to open source developers, urging them to avoid formal suits at presentations to CEO's as a way to give off the auras of foreign dignitaries unused to local customs). The arguments presented in Cathedral and the Bazaar were persuasive and original and now regarded as obvious. In his new book, Art of Unix Programming (available for free on the web), ESR stakes an even bolder claim: that initial design decisions make Unix uniquely well-suited to take advantage of open source's power. This book is an attempt to explain why Unix is so...well, Unixy." Read on for the rest of Nagle's review of The Art of Unix Programming.
The Art of Unix Programming
author Eric S. Raymond
pages 560
publisher Addison Wesley
rating great and free on the web!
reviewer Robert Nagle
ISBN 0131429019
summary Instructive for the Student; Profound for the Professional

On the surface, this book is a gentle introduction to programming; but in reality it is an attempt to explain the Unix aesthetic; at times I felt as if I were reading less a technical guide than an art history book, a chatty account of Gothic Architecture as told by someone who helped build a few churches himself. ESR articulates a set of design principles for Unix, which because of succintness deserve reprinting here.

  1. Rule of Modularity: Write Simple Parts connected by clean interfaces.
  2. Rule of Clarity: Clarity is better than cleverness.
  3. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
  4. Rule of Simplicity: Design for simplicity; add complexity only where you must
  5. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
  6. Rule of Transparency: Design for visibility to make inspection and debugging easier.
  7. Rule Of Robustness: Robustness is the child of transparency and simplicity.
  8. Rule of Representation: Fold Knowledge into data, so program logic can be stupid and robust.
  9. Rule of Least Surprise: In interface design, always do the least surprising thing.
  10. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
  11. Rule of Repair: Repair what you can--but when you must fail, fail noisily and as soon as possible.
  12. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
  13. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
  14. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
  15. Rule of Diversity: Distrust all claims for one true way.
  16. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

ESR shows how to follow these general principles while writing Unix programs. The central metaphors of Unix (that everything is a file, and data-streams that can be piped and redirected) are intuitive, and maximize transparency and separation. About pipes, he writes:

A subtle but important property of pipes and the other classic Unix IPC (Interprocess Communication) is that they require communication between programs to be held down to a level of simplicity that encourages separation of function. Conversely, the result of having no equivalent of the pipe is that programs can only be designed to cooperate by building in full knowledge of each others' internals (p 81, Chapter 3)

Interestingly, the real opposing aesthetic to the Unix aesthetic is not Microsoft (which really is a hybrid), but Macintosh:

The Macintosh's unifying idea is so strong that most of the other design choices we discussed above are either forced by it or invisible. All programs have GUIs. There is no CLI at all. Scripting facilities are present but much less commonly used than under Unix; many Mac programmers never learn them. Mac OS's captive-interface GUI metaphor (organized around a single main event loop) leads to a weak scheduler without presumption... Mac OS applications are not, however, invariably monster monoliths. The system's GUI support code, which is partly implemented in a ROM shipped with the hardware, and partly implemented in shared libraries, communicates with Mac OS programs through an event interface that has been quite stable since its beginnings. Thus, the design of the operating system encourages a relatively clean separation between application engine and GUI interfaces.

ESR's criticism right here (and throughout the book) is not necessarily condemnation. In fact, ESR recognizes that Macintosh as a competing aesthetic has a lot to offer that Unix does not. For example, Mac file attributes (in which a file has both data and resource "forks") provide mechanism for richer GUI support. Thus, we have (ESR says) developers "who work from the interface inward, rather than the engineer outward." In contrast, the Unix byte-stream metaphor may make it hard to conceptualize the meaning of operations such as Create, Open, Read, Write and Delete.

With Unix, the Rule of Least Surprise suggests that the developer delegate interface functions to a GUI or to another program. Instead of creating a built-in editor inside an application, the developer should allow the user to choose which editor to use. Instead of making a robust and easy-to-use interface, the Unix developer should produce a command line utility first, and then let someone else create a separate and independent GUI layer. (Rule of Separation). Xcdroast is a perfect example of a GUI layer for the command line program, cdrecord.

The Command Line Interface (CLI) may scare off new users, but it offers endless scripting and batching capabilities for programs (and smooth IPC). Also, it offers expressiveness to developers. "The Unix programmer," ESR writes, "is likely to see defaulting away from expressiveness as a sort of cop-out or even betrayal of future users, who will know their own requirements better than the present implementer. Ironically, though the Unix attitude is often construed as a sort of programmer arrogance, it is actually a form of humility -- one often acquired along with years of battle scars" (p.304, "Interfaces,")

ESR distinguishes between interface complexity and implementation complexity. Unix projects often involve tradeoffs on these two. The Unix developer prefers a lean and simple implementation at the expense of a usable interface; ESR writes:

Programs that mediate between the user and the rest of the universe notoriously attract features. This includes not just editors but Web browsers, mail and newsgroup readers, and other communication programs. All tend to evolve in accordance with the Law of Software Envelopment, aka Zawinski's Law. 'Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones that can'".

The book devotes considerable space to showcasing Unix best practices (which in most cases, means readable config files, limiting the program's scope, providing access to sufficient debug information and making it easy to hack). He offers sensible advice about when to use minilanguages ("don't extend your way to it, one patch and crufty feature at a time"), why to limit the number of available command-line switches (each one increases debug time), why optimization has few payoffs ("Moore's law implies a 26% performance gain just by buying new hardware every six months") and why bottoms-up programming can work better than top down design(because "it gives you time and room to refine a vague specification" when "...you are programming in an exploratory way, trying to get a grasp on hardware or software or real-world phenomena you don't completely understand.").

One of the most instructive chapters was about J. Random Newbie, a fictional programmer fresh out of college who understands basic programming concepts and the value of reuse. ESR presents a scenario of how Newbie nonetheless ends up rewriting rather than reusing, relying more on his own code than that of others. When he changes jobs, "he is likely to discover that he can't take his toolkit with him" and may even find it to be useless at a new job with different proprietary tools, languages and libraries. Thus, ESR writes:

Programmers have reuse (and other good practices that go with it, like modularity and transparency) systematically conditioned out of them by a combination of technical problems, intellectual-property barriers, politics and personal ego needs. Multiply J. Random Newbie by a hundred thousand, age him by decades, and have him grow more cynical and more used to the system year by year. There you have the state of much of the software industry, a recipe for enormous waste of time and capital and human skill -- even
before you factor in vendors' market-control tactics, incompetent management, impossible deadlines, and all the other pressures that make doing good work difficult. (p.420, "Reuse")

This book is a good introduction for this newbie programmer (as well as a warning about what to expect). It offers practical advice about which license and language to use, how to set up documentation, how to decipher the standards process, how to check things into CVS and how to submit a patch to an open source project.

The chapter on Unix's history puts the current SCO/IBM controversy into perspective. Unix has always been dogged by exertions of commercial control, and ESR accurately conveys how the software world is constantly swinging back and forth from periods of intensely-creative free-spirited openness to periods of commercial control.

I was struck by several of ESR's observations: that Linus Torvald's "refusal to be a zealot" was a contributing reason why Linux was able to succeed; that both the patch utility and email probably did more to advance the Open Source movement than mere "consciousness raising."

In summary, this book is a great help for the student programmer. It synthesizes a lot of ideas and insights from other programming gurus, and is full of insights, aphorisms and fun digressions (no surprise to readers of ESR's other works). The experienced programmer, on the other hand, might find the book more profound than practical. Invoking the Zen metaphor (and even including Unix koans at the book's end), ESR shows us how the abstract nature of programming provides insight into problem-solving, design and yes, even a kind of enlightenment. The book, available for free on the Net, is probably better to read on vacation or an airplane or as a welcome break when stumped by a programming problem. More practical books on Unix programming exist (I happen to recommend Mark Sobell's), but ESR's book will stay with you long after you have finished reading, providing countless hours for reflection and appreciation of Unix's Unix-nature.

Robert Nagle (aka Idiotprogrammer), believes that plone is the best thing since garage door openers, and is a strong supporter of music sharing. You can purchase The Art of Unix Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

The Art of Unix Programming More

The Art of Unix Programming

Comments Filter:
  • reading it will get you billed by SCO for $699.
  • The ultimate skill is to take up a position where you are formless. ?

    If you are formless, the most penetrating spies will not be able to discern you, or the wisest counsels will not be able to do calculations against you. ?

    With formation, the army achieves victories yet they do not understand how.

    No wait, that's the Art of War, not the Art of Unix. Nevermind.

  • The Command Line Interface (CLI) may scare off new users, but it offers endless scripting and batching capabilities for programs (and smooth IPC).

    I think in some ways, Windows manages to out-Unix Unix. For example, I find Windows programs to be much more scriptable than their Unix counterparts.
    I'm talking mostly about OLE automation. For example, it's pretty easy to write a batch file drives any of the Office suite. Can you drive OpenOffice in a similar fashion?
    -ec

    • Yup, you can script Open Office using Python. [openoffice.org]

    • I understand that OpenOffice has its own object / component model, with bindings to various langauges, including Java and Python.
      See OpenOffice.org [openoffice.org]

      Of course, the Windows OS provides COM as a standard for applications to use, and on Unix, each application provides its own incompatible object model. KDE has KParts, GNOME has Bonobo, Open Office has UNO and maybe Mozilla has its own too.

    • You're clearly confused. MS Office and OpenOffice are applications, not operating systems.

      Can you, for example, write a Windows script (ie, DOS .bat program) to say, take a directory full of text files, make some simple text edits on all the files, write those to a new folder, and then create a CD-ROM with an ISO image of that folder? It's just a few lines of shell script on Unix/Linux. (Most distros include mkisofs and cdrecord as standard utilities.)

    • Re:batch files in Windows vs Unix (Score:5, Informative)

      by kfg ( 145172 ) on Monday October 20, 2003 @01:07PM (#7261921)
      You have to bear in mind that OpenOffice, KDE, and like programs aren't very Unixy in the first place. They are essentially crossover tools for Windows and Mac Users who wish a familiar enviroment in an alternative OS.

      The problem is that Unix is not merely an alternative to Windows, it is fundamentally different.

      The optimum solution for the same problem is thus going to be different in both systems. As such, crossover apps aren't representative of how to do things in Unix. They offer the functionality for those that require them. That's a legitimate role and I use such apps where appropriate, but they aren't "Unix."

      ESR's book isn't about apps. It's about Unix and how to do things in Unix. Not about how to do things in a Microsofty way in Unix.

      OpenOffice is perfectly scriptable, although in a somewhat Unixy way, but that isn't really the point. OpenOffice is a particular app, not Unix. Below the level of the app Unix is designed to be run by scripting. Windows is designed to be run from a GUI with added scripting features.

      In many ways the enviroments are inverses of each other, much as the East-West cultural issues.

      In the "old days" Unix gurus learned Unix much as they learned their own cultures language and way of doing things. By osmosis. They knew Unix. To them it was simply natural.

      Now we have more and more people crossing cultural lines and moving to Unix enviroments from a Windows enviroment. They get lost. They don't know the language. They don't know how to use the toilets. They can't order food in a restaurant, and tend to conclude that the language is inherently chaotic and unlearnable, the toilets are "stupid" and the restaurants unusable.

      The people to whom ESR's book is likely to be most useful to aren't actually the Unix people (althoug h they should read it too. They might learn something), it is these people who are crossing over ( or just wondering what the hell it's all about anyway, much as people will read books on Japan even if they don't intend to visit there).

      It explains UNIX.

      Read it with an open mind.

      KFG
      • One of the reasons I like KDE is that, under the hood, it *does* have the feel of Unix. The code itself is very Unixy, and the way signals/slots works feels like pipes. In addition, DCOP exposes all those points to everything from shell scripts to manual poking to Perl to C. It's protected by the same uid/gid process permissions that everything else on the system is.

        Run KDE and use the command line 'dcop' program. If you're a GUI kinda user, use kdcop (hit alt-F2 and type kdcop). Take a look at how fu

    • BATCH is dead! Enough already... (Score:4, Informative)

      by rmdyer ( 267137 ) on Monday October 20, 2003 @05:57PM (#7264868)
      Long live the Windows Command Shell Processor CMD.EXE...

      1. CMD.EXE replaced COMMAND.COM as the scripting shell to use under NT as early as v3.51.

      2. If you are still using the .BAT extension under NT/Win2k/XP then you are not following the correct use. The "*.bat" is for COMMAND.COM scripts. The ".cmd" is for CMD.EXE scripts.

      3. If you are running COMMAND.COM under NT/2K/XP then DON'T. When you run COMMAND.COM, the kernel automatically fires up the vdm (virtual DOS machine). This is a 16 bit emulator.

      4. The advantages to CMD.EXE scripts are numerous...

      a. The engine is 32 bit and small. It typically occupies 1 Meg or less of memory.
      b. It has backward compatibility for .BAT scripts.
      c. The functionality of most of the internal command set has been greatly expanded.
      d. It uses standard Borne shell syntax with pipes and redirection.
      e. Has string functions.
      f. Has numeric functions.
      g. Has buit-in token-izing, no need for AWK/SED type scripts.
      h. Has extensive compatibility with the Windows paradigm of Drives/UNC paths. This is why using Cygwin with UNIX type shells is a worse idea as they don't know anything about Windows. (much like using a screwdrive for a hammer).
      i. Allows subroutines and functions.
      j. Operates directly on environment variable table without the need for variable shuffling.
      k. Process execution with little need for escaped arguments.
      l. Directory/Tree recursion-enumeration built-in.
      m. The 'FOR' capabilities have been greatly expanded, as well as 'SET', 'CALL'. Look into them.

      5. Process management without the overhead of exiting the shell for externals like "find", and "ls".

      6. When externals are needed, there is an extensive command set provided for just about anything from regular expressions to process control.

      In short, the flexability of the Command Processor under 2K/XP is drastically increased to match just about anything you would use sh,csh,tcsh for. If you are a network administrator I would look into using the command shell. It is included standard. There's nothing to add. You can use it for everything from cron scripts to logon script, and even logon authentication. It is so much simpler than using VB scripting, without the overhead of a huge runtime engine. The scripts run, then end very quickly. I use it for just about everything. Our entire network infrastructure is based on this "glue" scripting that sits at the highest level of proecess management. In many ways using command shell scripting is the "right way" to do things because it frees you from sticky vendor lock-in technologies like systems management server, or Zenworks. You are in control.

      See...

      http://www.microsoft.com/technet/prodtechnol/win do wsserver2003/proddocs/server/ntcmds_o.asp

      I could provide so many more compelling reasons to use the command shell that echo Raymonds sentiments, but I'll just stop here.

      +5

  • ESR's a nut (Score:2, Funny)

    by MrFreak ( 204353 )
    I also had the fortune to see ESR [sloppydisk.com] give the Keynote at the MacHack 2000 [machack.com] conference. He spent 6 hours espousing the virtue of Open source programming, comparing open source developers to dogs who know their territory, among other things.

    Its funny because in 2000, he was still worth several million still from I believe the VA Linux IPO, so he was telling all these propreitary guys how stupid they were for not jumping on the sunny open source revolution. Of course we all know how that turned out....

    Anyw

    • > comparing open source developers to dogs who know their territory, among other things.

      They sniff themselves and pee to warn off others?
    • He spent 6 hours espousing the virtue of Open source programming, comparing open source developers to dogs who know their territory, among other things.

      To be fair, at least 2 hours of that was the audience arguing with him. I was there too.

  • First Linuxy and now Unixy?

    What is going on? Is there a rule somewhere that says all Operating System nouns must have the -y suffix?

    MacOSXy, WinXPy, Solarisy? This does not compute.

    -Cyc

  • The Art of Inflating Your Ego (Score:3, Insightful)

    by duffbeer703 ( 177751 ) on Monday October 20, 2003 @12:39PM (#7261722)
    What exactly has Eric Raymond done besides write that Cathederal book or attempt to invent his own "jargon"?

    A book as high and mighty sounding as "The Art of XXX" should be written by an acknowledged luminary in the art...

  • Rewriting networking history (Score:5, Informative)

    by Animats ( 122034 ) on Monday October 20, 2003 @12:40PM (#7261737) Homepage
    • Until the TCP/IP implementation was released with Berkeley 4.2 in 1983, Unix had had only the weakest networking support. Early experiments with Ethernet were unsatisfactory. An ugly but serviceable facility called UUCP (Unix to Unix Copy Program) had been developed at Bell Labs for distributing software over conventional telephone lines via modem.[16] UUCP could forward Unix mail between widely separated machines, and (after Usenet was invented in 1981) supported Usenet, a distributed bulletin-board facility that allowed users to broadcast text messages to anywhere that had phone lines and Unix systems.

    Wrong.

    The Berkeley TCP/IP implementation wasn't the first for UNIX. Not even close. It was the third. There was TCP/IP for UNIX years before Berkeley. 3COM had their UNET product, and there was a BBN implementation. UNET needed considerable rewriting, (much of which I did) but it ran quite well.

    But the Berkeley implementation was free, and the 3COM implementation cost about $2000 per CPU. Because BSD was Government-subsidized, it won out.

    • The Berkeley TCP/IP implementation wasn't the first for UNIX.

      And nowhere in the paragraph you quoted does it say that it was. Nice strawman you set up there, but you could have bragged on your rewrite of UNET without it.

      • Well, it does say "Until the TCP/IP implementation was released with Berkeley 4.2 in 1983, Unix had had only the weakest networking support." That's not true.

        Berkeley was Government-funded to develope it and give it away. That doesn't happen any more. Under the Bayh-Dole Act, universities can now own intellectual property rights in works developed with Government funding. The head of "intellectual property" at UC Berkeley said last year that if they'd had those rights back then, "they would have owned TC

    • Re:Rewriting networking history (Score:4, Interesting)

      by Bruce Perens ( 3872 ) <bruce@perens.com> on Monday October 20, 2003 @03:12PM (#7263045) Homepage Journal
      I think the Berkeley version was a derived work of the BBN one. It's been a long time. Berkeley's main feat was adding VM to Unix.

      Gee, remember when fsck came along? It was a lot easier than icheck, dcheck, ncheck, and your last resort: adb. Sysadmins really had to know their stuff before fsck.

      Bruce

  • Whatever (Score:3, Insightful)

    by Golias ( 176380 ) on Monday October 20, 2003 @12:42PM (#7261746)
    From the text of the intro: 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.

    Look, I've already read "Zen and the Art of Motorcylce Maintenance" and "The Inner Game of Tennis." Do I really need another watered down screed on half-understood principals of Eastern philosophy crammed down my throat to become a better UNIX programmer? Most of the concepts that books like this borrow from Zen are so painfully obvious that it really serves as little more than padding for a poorly thought-out thesis which would only populate about 50 pages (at best) if not for the endless ramblings about holistic thinking.

    Okay, UNIX, like everything else, is all part of the Buddha. Very profound. We all marvel at your wisdom. Now stop wasting our time.

    • Re:Whatever (Score:2, Informative)

      by gowen ( 141411 )

      Look, I've already read "Zen and the Art of Motorcylce Maintenance... Do I really need another watered down screed on half-understood principals of Eastern philosophy

      Zen and the Art Of Motorcycle Maintenance isn't about Eastern philosophy (nearly all of it is based in Western Classicism) and doesn't pretend to be either. The frontpiece of the book even includes a disclaimer to that effect.

      Other than that, I agree with you. ESR is a shameless pseud whose knowledge of real Zen buddhism would fit on the ba

    • In case you missed the musings of the "Zen master" regarding the SCO suit:

      from http://catb.org/~esr/writings/taoup/html/unix-nat u re.html

      Master Foo Discourses on the Unix-Nature

      A student said to Master Foo: "We are told that the firm called SCO holds true dominion over Unix".

      Master Foo nodded.

      The student continued, "Yet we are also told that the firm called OpenGroup also holds true dominion over Unix".

      Master Foo nodded.

      "How can this be?" asked the student.

      Master Foo replied:

      "SCO indeed has domin

    • Dude, it's called skipping pages! If you don't want to read it, then don't! By posting this useless Slashdot rant that nobody else seems to cares about, you are _allowing_ your time to be wasted.
  • Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.

    .begin FLAMEWAR

    ahem, cough cough emacs cough cough

    .end

  • from the reviewer: a short correction (Score:3, Informative)

    by rjnagle ( 122374 ) on Monday October 20, 2003 @12:56PM (#7261837) Homepage
    Sorry, a sentence was incomplete and left out the URL. More practical books on Unix programming exist (I happen to recommend Mark Sobell's Practical Guide to Red Hat Linux [barnesandnoble.com]) , but ESR's book will stay with you long after you have finished reading, providing countless hours for reflection and appreciation of Unix's Unix-nature.

  • Fetchmail, Fetchmail (Score:4, Interesting)

    by An Anonymous Hero ( 443895 ) on Monday October 20, 2003 @12:58PM (#7261851)
    I think Raymond would be a lot more credible if he didn't keep using Fetchmail as an example for everything (with rather heavy insistence on how incredibly smart its conception is).

    OK, he's familiar with the program, but the effect is, at times it really looks like it's all he's familiar with. I mean, if the design principles it illustrates are so prevalent, it shouldn't be hard to find other examples that avoid this obvious slant, no?

    • he's familiar with the program,

      He wrote the damn thing, he should be familiar with it.

      It's not that he's just blowing his own horn either (although that may be part of his motivation), but that it's a good program that exemplifies a programming style, is relatively complete, is readable enough for students, and is widely used.

      It's also convenient enough for (possibly unfair, but humorous) criticism whenever ESR is within earshot.

    • Pity it sucks so bad (Score:3, Interesting)

      by devphil ( 51341 )

      I got sick of patching fetchmail for one buffer overrun after another. Unfortunately, there's nothing else out there that will do what it does, so until someone gets fed up with and rewrites it, we're stuck with it.

      I especially like how the passwords are stored in cleartext in the various rc files, if you want fetchmail to run as a daemon. Yeah, real secure design there.

      Fetchmail is a great victory for how open source can successfully work to rescue old code and turn it into something new and viable.

  • Eric S. Raymond's credibility (Score:3, Interesting)

    by Branka96 ( 628759 ) on Monday October 20, 2003 @01:01PM (#7261875)
    Here are some quotes from TCatB (October '99).
    "Microsoft will not have an enterprise ready operating system, because Windows 2000 will not ship in a useable form. (At 60 million lines of code and still bloating, its development is out of control.)"
    "Windows 2000 will be either canceled or dead on arrival. Either way it will turn into a horrendous train wreck, the worst strategic disaster in Microsoft's history."
    "the most likely scenario for late 2000/early 2001 has Linux in effective control of servers, data centers, ISPs, and the Internet, ..."
    Raymond is a true visionary. He can almost see beyond his own nose. Why anyone takes him seriously is beyond me.

  • Pipes (Score:3, Interesting)

    by bloo9298 ( 258454 ) on Monday October 20, 2003 @01:02PM (#7261883)

    This is bogus:

    A subtle but important property of pipes and the other classic Unix IPC (Interprocess Communication) is that they require communication between programs to be held down to a level of simplicity that encourages separation of function. Conversely, the result of having no equivalent of the pipe is that programs can only be designed to cooperate by building in full knowledge of each others' internals (p 81, Chapter 3)

    It's just as easy to define and use a serialization format for IPC via shared memory as it is do so for IPC via pipes. Sure, if you just copy objects from the stack or heap to shared memory without any abstraction (such as a vtable), then all programs will have to know about the common representation, but that applies equally to stream-based IPC mechanisms such as pipes or sockets.

    Honestly, kids, don't bother with this book. Read K &R, Steele, Stevens, Richter, and Stroustrup instead.

  • "Argument list too long" is kind of like the buffer overflow of the scripting world. It is one of the worst Unix violators of "16. Rule of Extensibility: Design for the future, because it will be here sooner than you think."

    I have been bitten by this several times over the years on various Unices, where a script that has been running fine will one day break when another file is added to a directory. Of course it can be fixed with xargs etc. but if it is a complex, otherwise stable script written by so

  • another review (Score:4, Insightful)

    by bcrowell ( 177657 ) on Monday October 20, 2003 @01:28PM (#7262091) Homepage
    Here [theassayer.org] is my own review of (an earlier version of) the book.

    In general, I have a problem with Raymond's pose as an anthropologist or sociologist of the open-source movement. Sociology and anthropology are supposed to be sciences, and scientists are supposed to try to be impartial and base things on empirical evidence, not preconceived beliefs. To me, Raymond's descriptions of the open-source culture read too much like a utopian fairy tale. The truth is that sometimes open source succeeds and sometimes it fails.

  • Has anyone found an available .pdf of this book? The new laser printer with duplex unit made me ask.
    • I'd be utterly stupefied if you actually got the duplexer to work. I've never seen one, on any brand of printer whatsoever, that actually worked properly...
      • My duplexer on my LaserJet IIID worked fine until the fuser exploded.

        Maybe you have to have a low slashdot UID for it to work..... ;)

  • Uhhh (Score:2)

    by 4of12 ( 97621 )

    I admire ESR's ability to write these rules that are concise and profound.

    In my real life UNIX world, despite my heavy use of the command line, there's a lot of GUI stuff managed by systems with less philosphical purity.

    Put X, KDE and Gnome up agains the list of Rules and it's hard to say they their successes originate in their observance of the rules. Perhaps their failings may be correlated to their deviance from the rules.

  • What Unix Gets Wrong (Score:2, Insightful)

    by schwaang ( 667808 )
    In the section on What Unix Gets Wrong the author's prime example is how X, by striving to provide "mechanism, not policy", leaves users overwhelmed with options.

    But the cost of the mechanism-not-policy approach is that when the user can set policy, the user must set policy. Nontechnical end-users frequently find Unix's profusion of options and interface styles overwhelming and retreat to systems that at least pretend to offer them simplicity.

    I agree with this. Linux distros that hope for mass adoption a

  • Anyone who's ever worked with any of Eric's code (and there's a lot less of it than he usually lets on) knows that ESR is the world's LEAST qualified person to write a book about programming as an art. A nice example of ESR's code is fetchmail, one of the most security-hole ridden POP clients ever produced; so poorly coded that it should likely be thrown out since it can't be fixed. Well, it can be fixed about once or twice a month I guess, if history serves.

    Mod me down if you wish, but ESR is a blunderi
  • ESR is well known for his Open Source advocacy, but this does not make him authority on software developement. What is the biggest piece of software he developed? fetchmail?!

  • Avoid wearing a suit? (Score:5, Insightful)

    by PCM2 ( 4486 ) on Monday October 20, 2003 @02:36PM (#7262728) Homepage
    (I once attended a delightful talk he gave where, among other things, he gave sartorial advice to open source developers, urging them to avoid formal suits at presentations to CEO's as a way to give off the auras of foreign dignitaries unused to local customs).

    Buh? How is sending the message to CEOs that you don't share their values/priorities (not to mention that you have no experience in making line-item purchasing decisions, even to the extent of getting yourself a decent suit) supposed to convince them that you're worth listening to? Seems to me that they've taken the time to develop the business plans ... it's up to you to convince them how your product will fit into those plans, not that it hovers around in some everything-is-dandy fantasy land, ignorant of how 90 percent of the world does business.

    Seriously, can somebody explain his rationale on this one?

    • well, i guess you had to be there to enjoy this advice. He was saying that merely playing by the rules of management meant turning yourself into just another pointy haired boss. By stressing your different status in the company, you might have more chance in persuading a CEO.

      It was a little tongue in cheek, but not ridiculous advice. There was a slashdot story a year or two ago about whether wearing a three piece suit for an interview indicated that you were professional or utterly clueless about the geek
    • If that talk was anything like his "Meme Hacking For Fun and Profit" talk on technetcast, the rational for not wearing a suit is that geeks tend to not look good in a suit because they are not used to wearing them.(this is a gross generality, but its true in my case). They are used to more comfortable clothing such as jeans and t-shirts. He does advocate dressing neatly (such as a sports shirt and pants). The idea being that you want to give the impression that "I can play the 'dress for success' game, I

      • If you look good in a suit, and are comfortable wearing them, then by all means wear one to the meeting with the CEO, but if your not, don't

        I agree to an extent. Somebody else brought up the argument about whether one should wear a suit to a job interview, and I indeed would not. If nothing else, I can't afford to buy a new wardrobe just to fit in at the workplace. My habit for interviews is to dress nicely, but not to dress "up" from how I'd dress on a normal workday.

        But this seems to be an entirely

  • It might have been interesting for ESR to have mentioned Plumbing [bell-labs.com] as seem in Plan 9. Arguably (as with much in Plan 9), the idea is a natural evolution of the UNIX model (in this case pipes):

    Plumbing is a new mechanism for inter-process communication in Plan 9, specifically the passing of messages between interactive programs as part of the user interface. Although plumbing shares some properties with familiar notions such as cut and paste, it offers a more general data exchange mechanism without imposing

  • Worse is Better (Score:3, Interesting)

    by 11223 ( 201561 ) on Monday October 20, 2003 @03:22PM (#7263112)
    I think that this famous article [dreamsongs.com] from 1991 explains quite well why Open Source and UNIX have been so successful over the past twenty years. It's not about technical superiority at all - it's rather about an approach called "worse is better", which Richard Gabriel contrasts against the Lisp approach. Favoring small, fast, and fragile systems lead C and UNIX to their success, and Lisp seems to attract only a fraction of the attention.


    Well worth the read, even if you aren't familiar with / think you don't like Lisp. There's another page [dreamsongs.com] with links to followups too.

    • You forgot the other possibility, know Lisp and don't like it...

      • ... know Lisp and don't like it...

        We have considered this possibility and found that the members of this community can be put into one-to-one equivalence with the empty set. Or in other words, if you really know lisp, you like it and, if you don't like lisp, you don't really know it.

  • Here's the entire online version of the book. [catb.org]
  • The web site for TAOUP is actually banned by the web-censor software SurfControl! We have had this inflicted on us at work. I wonder if ESR would like to have words with them about libel ...

  • Without presumption?!? (Score:3, Insightful)

    by El ( 94934 ) on Monday October 20, 2003 @05:42PM (#7264736)
    Mac OS's captive-interface GUI metaphor (organized around a single main event loop) leads to a weak scheduler without presumption...
    Uh, I think the phrase you're looking for is "without premption". I'll assume this was the reviewer's typo, and not ESR's original text...

  • Take it with a lump of salt (Score:3, Interesting)

    by cookd ( 72933 ) <douglascookNO@SPAMjuno.com> on Monday October 20, 2003 @06:18PM (#7265084) Journal
    I haven't read the whole thing, but I've read parts of it. Some of it is quite good, but other parts... Well, I'll just say that he doesn't let the facts stand in the way of the point he's trying to make.

    Really, it just blew me away how biased he was in some areas. For example, about two years ago, I was reading the draft edition. In his section where he was discussing various operating systems, he compared Windows to UNIX. He made some very broad, very negative statements about Windows that simply weren't/aren't true. The link at the bottom of the page asked for corrections and suggestions, so I sent him a short email with some additional information. He replied, and admitted that he didn't really know much about Windows since he didn't use it very much, and that the information was all second hand. I pointed out some factual errors, along with references to back up the corrections. The discussion seemed very positive at the time. However, now that the book has gone to print, I have looked over that section to see how it turned out. Not much has really changed -- some of the most blatant mistakes have been corrected, but many factual errors of which he was fully aware remain in the printing edition. Most importantly, the tone of the section is very authoritative and negative towards the technical aspects of Windows, when ESR admits that he really doesn't know much about it.

    I guess that tells me what I wanted to know about the book. It may have some wonderful insights about the "UNIX way" (which is actually pretty cool), but the author isn't interested in making me wiser and better informed -- he's pushing an agenda. His statements are heavily slanted towards what he wants people to believe, and he is willing to bend the facts to strengthen his case.

    Personally, I think he would have no trouble defending his position with solid facts. There is a lot of good in the "UNIX Way" of doing things. He shouldn't need to twist things to get his point across. This simply discredits him, and by association, discredits the Open Source movement in general.

    There are plenty of books out there about UNIX, more than I'll ever be able to read in the limited amount of time I have for bedtime reading. I'm not going to spend my time on one that I can't trust to give me the straight facts.

Slashdot Top Deals

Swap read error. You lose your mind.

Close