Slashdot Mirror
The Art of Unix Programming
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.
- Rule of Modularity: Write Simple Parts connected by clean interfaces.
- Rule of Clarity: Clarity is better than cleverness.
- Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
- Rule of Simplicity: Design for simplicity; add complexity only where you must
- Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
- Rule of Transparency: Design for visibility to make inspection and debugging easier.
- Rule Of Robustness: Robustness is the child of transparency and simplicity.
- Rule of Representation: Fold Knowledge into data, so program logic can be stupid and robust.
- Rule of Least Surprise: In interface design, always do the least surprising thing.
- Rule of Silence: When a program has nothing surprising to say, it should say nothing.
- Rule of Repair: Repair what you can--but when you must fail, fail noisily and as soon as possible.
- Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
- Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
- Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
- Rule of Diversity: Distrust all claims for one true way.
- 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.
reading it will get you billed by SCO for $699.
I would like to thank ESR for putting this book on the web, free of charge.
----
"Ours was a free culture. It is becoming much less so."-Lawrence Lessig
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.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
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
That's a good tip, not dressing up in a suit so that you impress and intimidate a CEO.
But, I am wondering if just not taking a bath will give me the aura of a foreign dignitary? I like wearing suits, and don't get to dress up that often.
If tits were wings it'd be flying around.
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....
Anyway, I decided to lampoon his dog comments for my hack that year, Doggie-Style Windows. By patching over some of OS 9's window calls, it would take all the windows behind the front window and make them run away into their own "territory""-- a feature now being introduced by Apple in OS X's Panther.
I released the source to Doggie-Style, but I'm still poor.
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
/.'s 10 Millionth
in many ways i agree with this statement (i'd know since i use a powerbook with programs like gvim frequently). however many mac native apps don't have a command line interface FIRST with a gui later. in fact, just about none do. os x has a few programs such as hdiutil, niutil, defaults, etc that are basically frontends to drive utility, net info, and property list but these seem to be the exception rather than the standard unfortunatly.
- tristan
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...
Conformity is the jailer of freedom and enemy of growth. -JFK
when someone simply says MacOS, they typically mean OS 9 or lesser. If someone wants to know they are talking about OS X, they say OS X. Of course since OS X is based on UNIX, it wouldn't give him a good counter point to his points about UNIX.
Of course since I know nothing about the internals of UNIX or MacOS I could be full of shit.
Note to self: No more arguing with the faithful.
83% of UNIX Programmers are Virgins
That's because they are smart enough to avoid getting women pregnant. You think because you're married and had 3 acciden^H^H^H^H^H^H^Hkids, you're somehow better than a virginal UNIX programmer?
I say, leave the promiscuous mode off. Celibacy all the way. Making babies just gets in the way of coding. Of course, this may lead to the extinction of the UNIX programmer, but fortunately there are a few that are foolish enough to leave their keyboards. And also I think it could easilly be argued that UNIX programming is a trait acquired from one's environment, and not necessarilly an inherited trait.
In any case, a little known fact is that some UNIX programmers like to receive blowjobs while coding. While, technically, they remain virgins, they still indulge in pleasures of the flesh, without the stress and responsibility involved in full intercourse. Now what percentage of these are receiving it from women, is a statistic I don't know if we want to address. Lets just say.. umm.. Do we consider Mac OS X programmers to be UNIX programmers?
#!/
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.
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.
Information wants to be anthropomorphized.
I heard him speak this weekend at a book signing, and his main objection to OS X was that applications developed for it were dependent on a proprietary library.
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
I mean, he's just puking up the usual 'rules' of software development...but tacked on 'Unix' so it would appear to the peoples.
Blar.
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.
Better than what?
Seriously, this is a good review so nitpicking is uncalled for.
The overall integration between the "Mac side" and the "Unix side" is pretty poor on OS X, in my book.
Either you have Mac Carbon/Cocoa programs that have virtually zero Unix integration, or you've got Unix programs that have the really rough, incomplete GUI front-ends typically found on a Unix system.
Just compare the functionality Windows "MMC" GUI for IIS versus the lame Start/Stop button for OS X's Apache server. A sysadmin might prefer the OS X/Unix config file approach, but regular users can't make head-nor-tail of getting Apache configured. It's kinda sad to see Microsoft out-Mac the Mac by providing a high-level of GUI integration, while Apple runs against 20 years of their advertising by telling people to go to the command line.
It's probably easier to think of MacOS X as a proprietary OS design that happens to have a Unix-compatibility module duct-taped on the side.
Business. Numbers. Money. People. Computer World.
You mean this Unix Hater's Handbook?
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 ) , 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, Idiotprogrammer, Houston
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?
What a delightful and clever retort. Bravo.
Robert Nagle, Idiotprogrammer, Houston
Oh, how very droll.
Your first paragraph invokes a book written in no small part by Microsoft apologists. Your second describes sins committed largely by... Microsoft.
We remain unimpressed.
Schwab
Editor, A1-AAA AmeriCaptions
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.
This is bogus:
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.
had nothing productive to say (much like some of you) but thought i'd point out that "software" is misspelled in the prompt.
Or perhaps because Yet Another Editor, or some other small app, is the next logical step after "hello, world" for somebody learning to be a programmer?
Everybody starts somewhere.
Information wants to be anthropomorphized.
This is a spammer. Check for the amazon link:
1 9/ ccats-2010-20
http://www.amazon.com/exec/obidos/ASIN/01314290
The referres is: ccats-2010-20
Wonder who thinks spam is Informative.
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
That has nothing to do with OSS versus propretary [sp?] models and everything to do with corporate profit and the achievement thereof at any cost.
When the US is another bananna republic in 10 years, it will be because of GWB, not RMS.
I never published my 'hello world' to sourceforge or expected it to get distributed with the major linux vendors. Yet how many frontends and crappy editors are available just with debian alone?
My point mainly being, because there is no ego gratification in re-using code written by someone else, most people tend to not re-use code. I backed this up by pointing to the overwhelming number of applications and os's written by people hoping to be the next RMS, when there is scads of code just laying around waiting to be reused by someone.
People are too busy reinventing the wheel, though, simply for the sake of putting their name on it. where are the oxcarts?
The book 'invoked' was written by people more highly accredited than you can ever hope to be. Had you have stated "lisp hackers" you might appear more clued, but instead it's pretty obvious you didn't look beyond the URL and made an accusation based on that alone.
Your assessment of my second paragraph is so wildly inaccurate, one can only conclude you are blinded by anti-M$ hatred to the point of having nothing intelligent to contribute to any conversation which remotely involves them.
In short, you are the typical no-nothing slashdotter. Me too, but at least I cop to it and try to keep a decently open mind and halfway informed opinion...you would do well to do the same.
Relax dude, you are correct. OS X is BSD (running on PPC) plus a GUI tightly integrated with hardware (and dependent on some ROM) and some specific libraries. On the other hand I really am full of shit ;-)
"This is crazy, you realise we could all go to jail for this?" - my manager, somewhere I used to work.
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 someone else, finding and fixing it can be time consuming and incurs the risk of introducing bugs.
For example, suppose you have an otherwise stable, reliable a script that processes say nightly invoices on a production machine, one file per invoice. But the script writer forgets to use xargs. It runs successfully for many years, then one day the company is "too" successful - oops.
You can argue that scripts should be written right in the first place to anticipate the problem, but the reality is that many aren't. And there's no easy way to test for it other than tediously analyzing the script line by line and making a judgment whether or not a particular wildcard expansion will ever be a problem in the future.
I simply don't understand why, when the wildcard expansion limit is reached, the underlying software can't just allocate more memory as needed. I don't even care how slow or inefficient it is, I just don't want it to blow up.
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.
Find free books.
You mean Microsoft apologists like Jamie Zawinksi? Or Simson Garfinkel? Oh wait -- you haven't read the book, so never mind.
Typical slashdot jackass.
'jfb
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Has anyone found an available .pdf of this book? The new laser printer with duplex unit made me ask.
OS X now ships with X Windows support built in, so I don't really see the big problem. Also, it's possible to use a cross-platform GUI library. For example, Audacity was written using the wxWindows toolkit, and runs natively on Linux, MacOS X (without X Windows), and Windows.
What I have against MacOS X is that it's new and relatively buggy, and they want you to pay $130 every few months for an upgrade that will fix a few more of the bugs.
Find free books.
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.
"Provided by the management for your protection."
Acquired traits can not be inherited. Otherwise, where do virgins come from?
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
The Unix haters handbook was written by:
:)
Who We Are
We are academics, hackers, and professionals. None of us were born in the computing analog of Ken Pier's East Africa. We have all experienced much more advanced, usable, and elegant systems than Unix ever was, or ever can be. Some of these systems have increasingly forgotten names, such as TOPS-20, ITS (the Incompatible Timesharing System), Multics, Apollo Domain, the Lisp Machine, Cedar/Mesa, and the Dorado. Some of us even use Macs and Windows boxes. Many of us are highly proficient programmers who have served our time trying to practice our craft upon Unix systems. It's tempting to write us off as envious malcontents, romantic keepers of memories of systems put to pasture by the commercial success of Unix, but it would be an error to do so: our judgments are keen, our sense of the possible pure, and our outrage authentic. We seek progress, not the reestablishment of ancient relics.
You can find that here:
Unix Haters Preface
I have seen some of the demos of ITS, TOPS 20 and Multics. These really were *incredible* systems. Because someone has seen systems better than Unix doesn't automatically imply they like Microsoft. Maybe one day we can get production of Lisp Machines back on track.
Doug Tolton
"The destruction of a value which is, will not bring value to that which isn't." -John Galt
There are a lot of things I could take issue with in your comment. But I'll just take on the easy one.
If you're holding up MMC as the paragon of GUI virtue, you are on serious crack, and I'm really pissed that you're not sharing.
I remember way back when SQL Server Enterprise Manager was a standalone piece of software. Then it became MMC-ified and became an even more bloated, unstable piece of poo.
I remember way back when User Manager for Domains was a standalone piece of software. Then it became MMC-ified and is no longer usable on dialup, and it's a more bloated, unstable piece of poo.
I remember way back when Disk Management was a standalone piece of software. Then it became MMC-ified and is a bloated, unstable piece of poo.
There is not ONE SINGLE administrative function that was put into MMC that works better now than it used to when it was standalone.
Perfmon used to be a standalone app, and it didn't take a minute and a half to load on my 1 Ghz PC.
MMC = Bloated, Unstable pile of Poo. Mac OS X may err on the other side of just having a start/stop button, but I'd prefer that to something like MMC that consumes 3 MB of RAM BEFORE you load any plugins.
I'm sorry to rant here, folks, but ESR, OSS, Unix, is so freaking dot-com era that I am baffled at how anyone could still be falling for that outmoded [??? profit!] model after the way it tanked our economy!
That's right, the whole damned economy rested on how well VA Linux's stock did. What a completely ignorant summation of our economy.
"Terminate?"
"Terminate... with extreme prejudice"
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 blundering fool, and his efforts to promote Linux only make the Linux community look like similar fools. After all, what kind of community would want THAT for its leader?
Customers who bought The Art of UNIX Programming also bought:
History of Classical Music by Britany Spears
Gov't By The People by George W. Bush
Improving Your Golf Swing by Stephen Hawking
Interpreting Modern Dance" by Stevie Wonder
But I was reffering to the mindset behind the whole dot-com era, which involved vague notions of advertising and half-cocked revenue 'concepts' such as basing businesses on giving away products and services for free [eg. gnu].
It was when the investors saw that they were being scammed by madmen and scammers and pulled out that the economy collapsed.
learn your history, it was only a couple years back, dumbass.
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?!
Yeah, I meant to note that MMC is a bloated piece of shit, and study of bad UI design with it's right-clicks and it's mega-tabbed dialogs.
However, I think the point stands that for casual Mac-type users, some GUI is better than no GUI.
Business. Numbers. Money. People. Computer World.
Nobody said UNIX couldn't be proprietary!
Actually, the entire UNIX market says it's not proprietary. (well, except for SCO)
Open Standards, independent certification, multiple vendors, etc.
Business. Numbers. Money. People. Computer World.
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?
Breakfast served all day!
# Rule of Clarity: Clarity is better than cleverness.
.o # don't try this at home (or work)
This is about Unix???? It'more like Smallness is better than Correctness.
# Rule of Least Surprise: In interface design, always do the least surprising thing.
rm -f *
"I think this line is mostly filler"
The comments on MacOS in chapter 3 are aimed specifically at pre-OS X versions.
Disinfect the GNU General Public Virus!
It might have been interesting for ESR to have mentioned Plumbing 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 a particular user interface.
The core of the plumbing system is a program called the plumber, which handles all messages and dispatches and reformats them according to configuration rules written in a special-purpose language. This approach allows the contents and context of a piece of data to define how it is handled. Unlike with drag and drop or cut and paste, the user doesn't need to deliver the data; the contents of a plumbing message, as interpreted by the plumbing rules, determine its destination.
The plumber has an unusual architecture: it is a language-driven file server. This design has distinct advantages. It makes plumbing easy to add to an existing, Unix-like command environment; it guarantees uniform handling of inter-application messages; it off-loads from those applications most of the work of extracting and dispatching messages; and it works transparently across a network.
I've tried to get him to give OS X a whirl more than once, and his objection is that he doesn't want to become dependent on non-open-source code. The proprrietary library he's referring to is the Cocoa UI layer.
Disinfect the GNU General Public Virus!
After further thought, it seems I need to repudiate my own post:
The fact that UNIX is still here doesn't necessarily prove anything about the technical merits (or not) of UNIX.
I've been a UNIX user for two decades, and I enjoy it. However, I, too, have used "better" systems. A quick Google for 'ewhac' will reveal many, many posts by a past version of me extolling the virtues of the Amiga with great fervor. Amiga's basically dead now, through no fault of its technology or the imagination of its developers.
Despite the fact that I'm constantly amazed at the new hoops UNIX jumps through (embedded on PDAs?!!?), I'm still of the opinion that UNIX is big, heavy, and slow. UNIX, IMHO, would be a laughable choice for a gaming console (but so also would Windows-NT, and it seems I'm wrong about that, too). However, for a stable development and general purpose computing environment, I find UNIX a comfortable environment.
The point I was trying to make, perhaps with more bombast than was strictly necessary, is that, while UNIX does have flaws, I don't regard The UNIX-Hater's Handbook as an authoratative reference on the subject. The work discredits itself in my eyes by reading too much like a USENET flame.
Schwab
Editor, A1-AAA AmeriCaptions
Speaking as a fledgling OS X programmer, I can say that I strongly support receiving blowjobs while writing code. Therefore, I would argue that OS X programmers are UNIX programmers.
Mike Gancarz covered some of this ground in his "The Unix Philosophy" http://www.amazon.com/exec/obidos/tg/detail/-/1555 581234/qid=1066681099/ It's a little dated now, since it was published in 1995, but still quite interesting.
-- Equity lord of the Trill Consortium
Well worth the read, even if you aren't familiar with / think you don't like Lisp. There's another page with links to followups too.
If ESR cared as much about linux and open source as he claims he does, he would stop talking about it in public.
Gee nothing like a timely criticism from him...3 years too late.
I forget...are we at war with Eurasia or East Asia?
I quote: "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. The only time this would apply: your theoretical "future user" is a system coder working on a system tool, or is someone who's willing to pay the money for a coder to come in and do extensive modifications to the app. The fact that he's missing, as do so many Unix (and especially Linux) zealots, is that people don't want to modify the source at a later date. The typical end user wants something that works for their needs now, and when it doesn't work anymore, they'll find another tool. The typical end user, yes even in the Unix world, is *not* a coder. Additionally, he's basically advocating code bloat, creeping featurism, rather than discrete tools for discrete functions, which he claims as a virtue. Inconsistency--it's an ESR hallmark. 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,") There's nothing to say to this but: Bullshit. The types he's trying to defend here are invariably the ones that are insufferable snots, and never comment their ugly, flea-ridden, hacked-together code. You can't make any case that their attitude is some sort of deference to the "future user". There's no humility to the behavior at all. Totally absurd.
I quote:
The only time this would apply: your theoretical "future user" is a system coder working on a system tool, or is someone who's willing to pay the money for a coder to come in and do extensive modifications to the app.
The fact that he's missing, as do so many Unix (and especially Linux) zealots, is that people don't want to modify the source at a later date. The typical end user wants something that works for their needs now, and when it doesn't work anymore, they'll find another tool. The typical end user, yes even in the Unix world, is *not* a coder.
Additionally, he's basically advocating code bloat, creeping featurism, rather than discrete tools for discrete functions, which he claims as a virtue. Inconsistency--it's an ESR hallmark.
There's nothing to say to this but: Bullshit. The types he's trying to defend here are invariably the ones that are insufferable snots, and never comment their ugly, flea-ridden, hacked-together code. You can't make any case that their attitude is some sort of deference to the "future user". There's no humility to the behavior at all.
Totally absurd.
discuss.
Here's the entire online version of the book.
peterrenshaw ~ Another Scrappy Startup
Naw, he's just a bitter Amiga zealot.
Says so downstream in the comments.
Amiga zealots are red-star members of the ABM (anything but Microsoft) brigade. Which is the vanguard of the Slashbots.
A Good Intro to NetBS
In the Operating Systems Comparison section, ESR fails to take note of the Lisp Machine. It's instructive to note that Lisp Machine hackers were the main contributors to the Unix-Haters Handbook and the Unix-Haters mailing list.
I am baffled at how anyone could still be falling for that outmoded [??? profit!] model after the way it tanked our economy!
There were two models that tanked the economy, neither one of which were UNIX or Open Source.
The first model was "money for nothing." If you had an idea for producing a product and making a profit, you got no funding. If you didn't have a product and didn't plan to make a profit, you got funded. Weird, but that's the way it was. At the company I worked, when we announced the highest profitably quarter in ten years, the stock tanked. When we announced the shipment of a new product line, the stock tanked. But when we announced we were working on an "eSolution", the stock went up three dollars.
The only reason UNIX got involved was because SUN and SGI tried to cash in on the style-over-substance craze. The only reason Open Source was connected was because it made an appearance during this period.
The second model is subtler, but more real. It's the fiat monetary policy of the US. It creates a cyclic business economy that booms and tanks on a irregular basis. It made the dot.boom worse because it pumped cheap money into hands of investors. And it's going to get worse, because we're monetizing the cost of the Iraqi war.
Don't blame me, I didn't vote for either of them!
The proprrietary library he's referring to is the Cocoa UI layer.
;-)
Two comments :
1) OpenStep (ie, cocoa) is one of the best programming framework available, and InterfaceBuilder is alone in its category. Thus, you could program GUI apps waaaaay faster. Depends of what you want, but just dismiss it without even dare to try it seems foolish. Moreover as all the development tools are free and downloadable on Apple developer's site.
2) Sure, Cocoa is proprietary. But if OSS programmers, instead of ranting about the great product offered by Apple (based on NeXT), had helped GNUstep (a free software implementation of OpenStep !!), well, we'll be in a better world
Last Note : GNUstep is, nonetheless, available, and there is an IB equivalent (Gorm). Sadly, GNUstep is yet another forgotten GNU project -- even if with the Buzz about Cocoa and Objective-C, many people seems to come now on GNUstep (plus one of the reason is that, obviously, GNUstep is quite usable, even if bugs remains).
I find it ironic that ESR became an overnight millionaire after selling his VA Linux stock as soon as he recieved it. But then he was curiously silent and low profile when the stock tanked as VA's business model slammed into a hard reality check.
Today, The Cathedral and the Bazaar should be categorized as a joke book. Personally, I think ESR should just take his money and STFU. The general malevolence in the posts on here towards this hypocrite is well deserved.
From the hour or two that I've spent reading the online version of this book, the overall conclusion that I've come to is that you can bust summarize it as follows: That's not a bug, that's a feature.
Essentially, ESR's view on most aspects of Unix are overflowingly positive, and that every mechanism exists today because it has been evolutionarily tested and has withstood the tests of time. A lot of unix critics will laugh at this explanation, because it's so simplistic that it cannot possibly fail. "Unix does it this way, and that's good. Why else would unix have survived for so long?"
And all of the common complaints are just completely ignored or turned around on their head, as in "that's not a bad thing, that's a good thing!" For example: the fact that some command line tools have an amazingly mind-boggling set of options is a GOOD thing, because it allows for ultimate flexibility. Well, that may be true if you're a long-bearded Unix wizard, but a lot of people AREN'T, nor do they wish to invest the time to become one. To them the fact that command line tools require careful study and consideration before attempting simple tasks is not a feature, it's a bug. It's almost as if he is taunting everyone that is not as able as him. For example, the fact that programs that produce little or no diagnostic/chatty output is to be commended, according to him. In other words, it comes off as "If you don't know how to use a program (because you haven't spent hours reviewing the handy texinfo <shudder> manual), then that's your problem not the program's. When you know what you're doing, anything and everything is possible, and screw you for wanting simplicity and ease of use. Don't clutter MY tools with your ease of use bullshit."
ANother aspect of this is the notion that all GUIs should be front-ends interfaces to some other independent back-end program, that you should build the command-line first and then build a GUI wrapper. Surely this makes sense for some things, but as a general principle? I just don't buy it. I guess I've used too many crappy front-ends that either omit functions (such that they're only available in the command line version) or don't implement functions correctly, such as failing to escape them for the command line... But the worst example of this type of case is where someone writes a wrapper that has almost zero actual usability -- it's essentially a form where you can fill in command line parameters. Sure, it's got a nice text-area for this and a radio button for that, instead of having to remember what "--foo" or "-i" means. But because it completely fails to go further than the "here are some inputs and option settings, now make an output" it is still not nearly as functional and intuitive as GUI applications that were designed from the ground up from some task rather than being simply a front-end to a bunch of command options. A very exaggerated example of what I'm talking about would be drawing a circle in a drawing program. In a native GUI app, you would select the "circle" tool, move over to the canvas, select a position, then drag to size while getting a preview of what it will look like. If this function had been implemented as a front-end to a command line program you would instead have a tick box next to "Draw circle" that you would select, and then you'd have two more little text boxes appear where you would then enter the coordinates for the center and the radius. To preview, you would run the command and then load the file into a viewer to see if it looks right, and repeat as necessary. (Obviously, this is an unrealistic exaggeration. But I wanted to illustrate my point of how not everything can be mapped to "a frontend to a completely seperate back-end using command lines and pipes" that is advocated.)
Another perfect example is the notion that because the X Window System supplies such a loose framework, that any UI widget toolkit can be used. "The user has ultimate control! ANything's possible! Total freedom a
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 ...
http://rocknerd.co.uk
Every 'true' Unix box that I own (Sun Sparcs, IBM RS/6000's, an SGI Indigo 2) has a proprietary X Server, that runs really well, and links into graphical resources that are hidden and closed source. NONE of the really good features of the framebuffers on those machines are taken advantage of with any of the freenixes. Because the Unix-based hardware vendors will not release the information needed to add to Xfree or any of the other Open Source X servers.
So, for instance, if I want to run dual headed 24 bit framebuffers on my SparcStation 10SX (which has really great dual 24 bit framebuffers built in) I have to use Solaris and reduce the machine to an X Terminal. Use NetBSD and I've got 8 bit color.
There's little at all 'open' about commercial UNIX except interconnectivity outside-the-box and the fact that they all run OSes that evolved from a common code base.
A Good Intro to NetBS
Gancarz has come out with an updated version of the book, now titled Linux and the Unix Philosophy. Here's a non-amazon link. If you have the original, there's not much new to recommend it, just updated (mostly Linux-based) examples; but if you're new to either OS, or want to give a book to a friend to explain why you love it/them, this is a good one.
"Hardly used" will not fetch you a better price for your brain.
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...
"Freedom means freedom for everybody" -- Dick Cheney
You're right. When ESR issued this statement his 150,000 shares in VA were worth around 36 million. Under SEC regulations he wasn't able to sell his stock until the following June, at which time VA Linux was worth considerably less. Still, I would wager that in the end he walked away from the crumbling wreckage of VA with at least a few million.
The prevalence of Make Money Fast IPO's during this time attracted a lot of people like ESR who were skilled at bending reality to make non-existant business cases look profitable. I find it amusing that in his statement it sounds like ESR actually thought he deserved the money he got from the VA IPO.
Long live the Windows Command Shell Processor CMD.EXE...
.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.
.BAT scripts.
n do wsserver2003/proddocs/server/ntcmds_o.asp
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
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
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/wi
I could provide so many more compelling reasons to use the command shell that echo Raymonds sentiments, but I'll just stop here.
+5
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.
Time flies like an arrow. Fruit flies like a banana.
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. It should not be used as an example of sound design.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
"That can't be right, my brother promised me Florida!"
Buy that book? To hell with that anyway. I've got higher priority book purchases than this thing. I got the O'Reilly 'Running Weblogs with Slash' book on Thursday at Half-Price books for $4.95. I just used wget to scarf down the HTML version off rayboy's website. The URL is here.
A Good Intro to NetBS
the topic is coding, however.
(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).
Main Entry: sartorial
Pronunciation: sar-'tOr-E-&l, s&(r)-, -'tor-
Function: adjective
Etymology: Medieval Latin sartor
Date: 1823
: of or relating to a tailor or tailored clothes; broadly : of or relating to clothes
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
The point of UNIX is that you could toss that SparcStation and go buy hardware from a vendor that documents their framebuffer (haha), with fairly low software migration costs.
At least that's how the UNIX vendors sold it.
Sun made lots of money selling "Open Systems" against DEC and IBM in their day, but now they are watching their customers switch seemlessly to Linux. So, they weren't entirely lying.
Business. Numbers. Money. People. Computer World.
Share and enjoy!
RinkRat
Windows 2000 hasn't arrived yet, what is being marketed as w2k and xp now is really just NT5 in in various tarted up configurations.
When ESR said that w2k was going to be what s now being called Longhorn (minus some things they didn't think of back then)
So I'd say that ESR was completely right on that one, except if you count the current w2k (nt5) as an enterprise os...
-- To dream a dream is grand, but to live it is divine. -- Leto ][
I get your point about A: and C: ; However, I am not sure your conclusion is correct.
:)
True, people like icons. I like icons. What if those icons were labeled as so?
System Disk
Option Disk
Floppy Disk
Removable Disk
CD-ROM
My Home Directory
My Pictures
My Settings
My Mail
The market identifies with A: and C: because one company in particular was successful in enough other things to make this acceptable. Users can easily remap these things, particularly when the names make sense and can be associated to common tasks or ideas.
As to having the power, I agree users need know nothing about it. A good OS will have reasonable defaults for the standalone machine, (Mandrake?) but will still have the power under the hood for those that know what they are doing.
Not having drive letters is a good thing --one that users can easily deal with. Having the ability to keep the logical state of things seperate from the physical state of things makes life easier for those doing the heavy lifting at very little cost to the user.
Personally, I have ran into a couple of these users. The names 'A drive' and 'C drive' worked quite nicely
Blogging because I can...
"Moore's law implies a 26% performance gain just by buying new hardware every six months" What about us poor peopke who live in Africa and can only afford to buy new haedware every 2-3 years?
On the other hand, the file system is completely mapped under /cygdrive, there is access to services and the registry. I don't exactly call that being ignorant of Windows.
Personally, I'm more inclined when doing system/network management thingies to go off in the direction of Perl/Win32 which gives me more than CMD and better implemented than WSH or VBS.
See my journal, I write things there
In those days, many people used Unix and VMS or other big systems and had a good idea of the merits of both and the book The Unix Haters Handbook. It is humorous but it makes some valid points. Perhaps it wasn't up to date with all Unix versions at the time, and in the same way can we expect Mr Raymond to be aware of all the goodness lurking somewhere within the Windows code base (there must be some!).
Perhaps Raymond should have reused but praphrased that quote from the forward of The Unix Haters Handbook:
This is a good disclaimer but this was originally written about Unix, meaning specifically closed source versions from vendors like SCO. What 'fixed' Unix, was freeing the programmer from the patents with open sorce versions like BSD and Linux.In the end Raymond is kind of right. Microsoft themselves are having problems getting everyone to upgrade. How many copies of 95 and 98 are out there still? The NT kernel is kind of cool but not everyone has that kind of horsepower.
See my journal, I write things there
Well, the start/stop Button you mentioned is only present in the consumer version of OS X. A newbie user doesn't WANT to configure anything, s/he wants to drop HTML files into the "Sites" folder and watch them with a web browser.
As soon as you want more from your web server, you know more than the newbie user and can either buy OS X Server which has a fine GUI for your configuration needs, install Webmin oder do the configuration by hand.
Do we consider Mac OS X programmers to be UNIX programmers?
as i type on this ibook some shells are open in other windows in Terminal.app. Yes, I consider myself a UNIX programmer and yes, I've written software for MacOS and Windows.
Lots of the gems in his book work. I like this one, it applies to life:
i started programming "UNIX" using QNX -- a "realtime" UNIX back in 1986. The cool tools in QNX were the C compiler (even though it was buggy at the time.) I've taken that UNIX experience, and knowledge (or lack thereof) and applied it later when writing software for DOS, MacOS, and Windows. There is something cool about writing a UNIXY "filter" in C that will run on Mac and Windows (oh and UNIX too.) And the rush of dragging a couple hundred very large files onto the application icon on MacOS to run the filter on all of them at once!
UNIX tools rant -- i still don't get the allure of grep, awk , sed and their likes. I often need to reread the rather long manual everytime I go to use grep. I just want to do a simple find and replace without all of the hiccups\"/.* of grep. ie. Don't use [a-z] use [[:alpha:]] instead blah blah blah. And these tools tend to work on lines of text when I want to do the "UNIXY" thing and work on the entire stream (blob, bag) of text. The other annoyance is that someone decided (that is a good idea) to truncate lines at 70-80 characters to fit their crappy shell/terminal program. Raymond makes mention of text editor "bobbles" I was fortunate enough to avoid the UNIX editors and use text editors on MacOS and Windows that didn't suffer from these problems. My current choice of text (and programming!) editor: TextEdit (MacOSX), WordPad (Windows) because like ed they are pretty much guaranteed to be installed already. I tried a few "bobbly" text editors on UNIX but they wouldn't be my preference. I once used VMS, briefly in college, and I would love to have that option of version control available in file systems that I use everyday. The most important thing to know about vi is how to quit: (open a shell, find vi's pid and kill it.) After reading all the praise of emacs, I went and fired it up, it seems to me that emacs could live on it's own, emacs is. emacs is the operating system that Stallman dreams of creating. because who needs an os anyways? i could limp along just fine with only a web browser -- but now i am sounding like those old-timers that could be just as happy using ed and nothing else.
\n rant and those pesky newlines: look for \n and accept all of these: