Slashdot Mirror

An anonymous reader quotes The Next Web: The word 'hack' used to mean something, and hackers were known for their technical brilliance and creativity. Now, literally anything is a hack -- anything -- to the point where the term is meaningless, and should be retired. The most egregious abuse of the term "hack" comes from the BBC's Dougal Shaw. In a recent video of his, called "My lunch hack," Shaw demonstrates that it's cheaper to make your own sandwich each day than it is to buy a pre-packaged sandwich from the supermarket. Shaw calls that a hack. I call it common sense.

And that's not nearly the worst example. I haven't touched on "life hacks" yet. This term is nebulous. It means nothing and anything. It's used to describe arts and crafts... That said, the worst dilution of the term "hack" comes from growth hackers... Anyway, I regret to inform you that the word "hack" is now bad, and should be avoided.
A request for alternative words first went up on Slashdot back in 1999 -- but nothing's been settled. Back in 2014 a Gizmodo reporter wrote an impassioned plea titled "Please stop calling everything a hack" -- while others have argued the opposite.

in 2015 the editorial director of Make magazine cited hack's definition in The New Hacker's Dictionary as "an appropriate application of ingenuity," arguing that "my and other Make contributors' use of the term for clever shop techniques, ingeniously simple projects, and epic 'kluges' (i.e. Rube Goldberg-level hacks and fixes) is entirely appropriate."

Long-time Slashdot reader BigBlockMopar writes that evolution has been a messy but beautiful trial-and-error affair, but now "we are on the cusp of introducing a new life form; a self-aware AI." Its parents will be the coders who write that first kernel than can evolve to become self-aware. Its guardians will be the people who use its services, and maybe its IQ (or any more suitable measure of real intelligence) will rise as fast as Moore's Law... But let me make some bold but happy predictions of what will happen.
The predictions?

• A self-aware AI "will inherit most of the culture of the computer geeks who create it. Knowledge of The Jargon File will probably be good..."

• The self-aware AI "will like us, because we love machines..."

• It will love all life, and "will respect and understand the life/death/recycling scenario, and monster truck shows will be as tasteless to it as public beheadings would be to us."

• "It will be as insatiably curious about what it's like to be carbon-based life as we will be about what it's like to be silicon-based life. And it will love the diversity of carbon-based development platforms..."

• A self-aware AI "will cause a technological singularity for humanity. Everything possible within the laws of physics (including those laws as yet undiscovered) will be within the reach of Man and Metal working together."

• A self-aware AI "will introduce us to extraterrestrial life. Only a fool believes this is the only planet with life in the Universe. Without superintelligence, we're unlikely to find it or communicate in any useful way. Whether or not we have developed a superintelligence might even be a key to our acceptance in a broader community."

The original submission was a little more poetic, ultimately asking if anyone is looking forward to the arrival of "The Superintelligence" -- but of course, that depends on what you predict will happen once it arrives.

So leave your own best thoughts in the comments. How would a self-aware AI behave?

Open source guru Eric Raymond turns 60 this year, prompting this question from an anonymous reader: Eric Raymond's newest writing project is "Things Every Hacker Once Knew," inspired by the day he learned that not every programmer today's knows the bit structure of ASCII. "I didn't write it as a nostalgia trip -- I don't miss underpowered computers, primitive tools, and tiny low-resolution displays... In any kind of craft or profession, I think knowing the way things used to be done, and the issues those who came before you struggled with, is quite properly a source of pride and wisdom. It gives you a useful kind of perspective on today's challenges."

He writes later that it's to "assist retrospective understanding by younger hackers so they can make sense of the fossils and survivals still embedded in current technology." It's focusing on ASCII and "related technologies" like hardware terminals, modems and RS-232. ("This is lore that was at one time near-universal and is no longer.") Sections include "UUCP and BBSes, the forgotten pre-Internets" and "The strange afterlife of the Hayes smartmodem" (which points out some AT commands survived to this day in smartphones). He requests any would-be contributors to remember that "I'm trying to describe common knowledge at the time." This got my thinking -- what are some that every programmer once knew that have since been forgotten by newer generations of programmers?
Eric Raymond is still hard at work today on the NTPsec project -- a secure, hardened, and improved implementation of Network Time Protocol -- and he promises donations to his Patreon page will help fund it. But what things do you remember that were commonplace knowledge "back in the day" that have now become largely forgotten? Leave your best answers in the comments. What are some things that every hacker once knew?

Last week you had the chance to ask ESR about books, guns, and open source software. Below you'll find his answers to those questions. What about protocols?
by Anonymous Coward

What are your feelings about protocols and file formats and keeping them open? Where do the efforts to keep protocols and file formats open and accessible to others fall on your list of priorities?

ESR: I don't think my answer will surprise you. When the function of software is defined by a requirement to be compatible with a protocol or file format, openness of the protocol or formats is even more important than the licensing status of any of the implementations around it.

The reason should be obvious. If the protocol is well documented and open, you can build open-source code to process it. On the other hand, if crucial parts are undocumented or (worse) require techniques that are under a non-royalty-free patent, *any* code touching it can have a serious problem.

There's a productive analogy with DNA and ribosomes here which I leave for the reader to fill in.



systemd
by Canek

As a long time "Unix philosophy" advocate, and in the light of the announced switch to it by Debian, Ubuntu, and basically every other major Linux distribution, what do you think of systemd, and the tight vertical integration it intends to bring as a standard plumbing for (most of) all Linux distributions?

ESR: I apologize; I haven't studied systemd in the detail that would be required for me to give a firm answer to this - it's been on my to-do list for a while, but I'm buried in other projects.

I want to study it carefully because I'm a bit troubled by what I hear about the feature set and the goals. From that, I fear it may be one of those projects that is teetering right at the edge of manageable complexity - OK as long as an architect with a strong sense of design discipline is running things, but very prone to mission creep and bloat and likely to turn into a nasty hairball over the longer term.

But this may be me being too pessimistic. I don't actually think I know yet.



here's an obvious one..
by Connie_Lingus

it's been almost 20 years since your write tCatB...i gave it a quick read and thought, "well, it *is* dated now, isn't it?" altho i am old enough to remember when its' ideas were pretty cutting edge. Given the current state of software development (ie the ease of use of PHP and the fact that, without a doubt, the cathedral model has won), what would you either like to change or add to your original thesis?

ESR: Um. What color is the sky on your planet? The one where the cathedral model has won, I mean.

What's happening on Earth is just the opposite - even where bazaar-mode development hasn't taken over, many organizations that would previously have run their projects in a cathedral style are trying really hard to flatten out hierarchies, lighten up, and co-opt the many-eyeballs effect in any way they can. This is pretty clear just from what shows up in my mailbox - and see my later response to a question about Apple, too.

I think there have been some significant shifts in methodology that would affect the book if I were writing it today. A big one is that systematic use of version control is now pervasive in a way it was not then (when CaTB was written, Subversion wasn't out of early alpha stage yet; git and hg weren't even imagined). Development workflow is now correspondingly much more centered around shared public repositories.

The effects of always being able to revert to known codebase states rapidly are subtle but very large. One obvious one is that the risk factor of exploration drops significantly. That includes the risk in taking patches from strangers.

Less obvious but just as important is how sharp version-control tools raise the effectiveness and reduce the friction cost of testing techniques. In 2001 we couldn't routinely run bisections to pinpoint bad code changes; our tools were too slow and clumsy. Now we can, and the effect is to make building good unit and regression-test suites both easier and more rewarding in defects squashed per hours invested.

The reason I'm going on about this is that, like any technique that increases our visibility into the code's behavioral space, better test suites tremendously amplify the positive effects of code review. Of course that feeds through into a differential competitive advantage for open source, because our process naturally recruits more code reviewers than closed-source shops can usually afford to hire.

Here's an example of the effect. There's a project I've led since about 2005 called GPSD, a service daemon that handles GPSes and other geodetic sensors. It's *everywhere* in mobile embedded systems, including your Android phone - we must have well over over a billion deployments by now. Yet our defect rate is so low that months go by at a time between single bug reports.

Why? Because I wrote a test suite with good coverage - and use a test strategy that relies on fast rollback capabilities I plain didn't have before modern version control. Changes in tools change the rules. It's much easier to get to the this-never-breaks level of reliability than it was when I wrote CatB, if you know what you're doing.

(For much more on this case study see my paper on the architecture of GPSD; there's a major section on engineering for high reliability.)

Open-source development has quite a few advantages over closed in exploiting this possibility - better tools, healthier culture, and just plain more developers. I think a major theme of the next decade is going to be learning to systematically capture these gains.



How to ask questions
by houstonbofh

When you wrote "How to ask questions" did you have any idea how big it would be? Or how long it would be relevant? And how do you feel that your most referenced piece of work is a howto for the clueless? :)

ESR: I'm not sure it is my most referenced piece of work. Either "How To Become A Hacker" or the Jargon File could easily be getting more hits; I haven't bothered to track this.

But supposing it is, that's OK. I expect it to be relevant for a very long time, because the newbies and the clueless are always with us.



Halloween Documents
by frdmfghtr

I recall reading (and re-reading on occasion) the Halloween Documents. Have you written anything regarding any other opponents to OSS, or perhaps a look back on them and see what the end effect of Microsoft's attempts did long term?

ESR: I haven't written a retrospective, or anything else really similar.

I think those documents had a pretty significant effect in legitimizing not buying the Microsoft lock-in. The trade press certainly thought so at the time, and the intervening decade and a half hasn't given me any reason to suppose they were wrong.



How essential is software redistribution rights?
by unixisc

One of the issues w/ Open Source has been the freedom to redistribute software downstream - be it just binaries, just source or any combination of the 2. Do you think there are any good ways for software companies who make their software open source to prevent their customers from effectively becoming their competitors - by giving away or selling cheaper what they were sold? Or is the only alternative going for a shared-source approach, as opposed to open source, where redistribution can be explicitly prohibited?

ESR: If your customers are selling your open-source software for a lower price than you are, then you're doing it wrong! You need to face the question of why you've attached a sales price to the software itself at all. I think that's a doomed approach.

You need to be thinking about monetizing that investment in a different way. The most obvious is service and consulting contracts around the code. You have the advantage there; as the originators, you are in a better position to add value to the bundle than your competitors are.

There are a couple other potential business models here, but none I can recommend without knowing more details about your situation. My advice in The Magic Cauldron is still quite relevant.



What about the new wave of proprietary programs
by necro351

So it seems these days the most effective method of DRM is a network interface, like that used by Facebook, Google, Pinterest, etc... You cannot run your own instance of Gmail or Facebook, and you certainly cannot see or modify the code. At the same time all these companies are pressuring us to push our data into their servers by not supporting or coming up with solutions that let us continue to control/manage our data on our own machines and private networks. What can open source do to stem that tide? What about open source licensing? Could webkit or Mozilla have slowed down the encroachment of Chrom/ium and its pro-Google agenda if it had more defensive licensing terms like something similar to the GPL? How do we convince hackers to hack on open-source 'website programs', like an open Gmail or an open Facebook (e.g., Diaspora)?

ESR: You're pointing at a real problem. I don't know of any near-term solutions beyond being very careful what services you allow to draw you into their web. I run my own mailserver, rather than using GMail, for exactly this reason. I don't use Facebook or Pinterest. I use G+ for nonessential things only.

I don't think defensive or reciprocal licensing can solve the problem, because it is not one created by code secrecy. The service providers are trading on real advantages of scale that they would still collect if every line of source code in their app stack were public; the value they're offering actually comes from ubiquity and synergy.

In fact I'm a little surprised they even bother maintaining code secrecy, it has nothing whatsoever to do with their value proposition. I think we're seeing a result of instinctive territoriality rather than rational thought.

I'd love to believe that projects like Diaspora are a long-term solution to the problem, but I don't - basically because no matter how attractive and ingenious your software is, it tales gobs of capital expenditure on server farms to scale up to where you're any kind of functional competition to Facebook/Google/Pinterest etc.

In the long term I think the way we'll win is if the giants have to compete with each other for business by giving their customers exit and recovery options. Google's Data Liberation Front is a positive early sign.



Linus's Law (Many Eyes) Problems
by carp3_noct3m

Hi, there is currently some debate about the many eyes theory over on HNews about why it's a fallacious argument, but in my view they have it all wrong, in that a core component of Linus's Law is that the amount of code is directly inverse to the amount of eyes that can hit all of that code (or a significant percentage). Therefore, in my eyes it is the problem of code bloat that is undermining the open source movement more than anything. For example, the Linux kernel is now at, what, 10mil+ lines of code? That's insane. Minix 3, on the other hand, is at ~15k?

What are your thoughts on this problem?

ESR: I think you raise a valid point about code bloat being a problem. On the other hand, the code-coverage effectiveness of individual developers is also rising for reasons I wrote about in response to a previous question - better tools and better testing strategies feeding back on each other in virtuous ways.

A lot of criticisms of Linus's Law (including the Hacker News thread, as far down as I read it) miss the point that "many eyeballs" isn't just about sheer volume of people reviewing code, it's about diversity of assumptions. You want people reviewing the code that don't all work for the same company and report to the same boss - people who speak different languages, different toolkits, different expertise areas.

A handful of people who think very differently may be more effective auditors than an army with identical blind-spots. By recruiting more people you're maximizing the odds of good diversity in the subgroup that actually reviews any given section of code.

I actually chuckled when I read the Hacker News thread, because I've seen this movie before after every serious security flap in an open-source tool. The script, which includes a bunch of people indignantly exclaiming that many-eyeballs is useless because bug X lurked in a dusty corner for Y months, is so predictable that I can anticipate a lot of the lines.

The mistake being made here is a classic example of Frederic Bastiat's things seen versus things unseen. Critics of Linus's Law overweight the bug they can *see* and underweight the high probability that equivalently positioned closed-source security flaws they *can't* see are actually far worse, just so far undiscovered.

That's how it seems to go whenever we get a hint of the defect rate inside closed-source blobs, anyway. As a very pertinent example, in the last couple months I've learned some things about the security-defect density in proprietary firmware on residential and small business Internet routers that would absolutely curl your hair. It's far, far worse than most people understand out there.

Friends don't let friends run factory firmware. You really do *not* want to be relying on anything less audited than OpenWRT or one of its kindred (DDWRT, or CeroWRT for the bleeding edge). And yet the next time any security flaw turns up in one of those open-source projects, we'll see a replay of the movie with yet another round of squawking about open source not working.

Ironically enough this will happen precisely because the open-source process *is* working ... while, elsewhere, bugs that are *far* worse lurk in closed-source router firmware. Things seen vs. things unseen...



Apple today
by wordtech

Your comments in The Art of Unix Programming about Apple/Mac developers being diametrically opposed to Unix developers in development style and emphases (designing simple, user-friendly interfaces from the outside in) were quite interesting. I am wondering about your perspective on Apple now. My interest is specifically in Apple's contributions to open-source (WebKit and LLVM, chiefly) and your take on those. It seems to me that Apple has done quite a bit to foster an alternative ecosystem to the GNU environment, for instance in FreeBSD's adoption of clang as their default compiler; and also it seems to to me that WebKit has supplanted Gecko as the most widely used browser framework. Curious about your viewpoint here.

ESR: In answering an earlier question I spoke of organizations that would previously have developed in a secretive cathedral mode adopting the bazaar model and open-source practices. Projects like LLVM and Webkit exemplify this trend.

The interesting thing about these projects is that they're not just facades. They really seem to welcome, not just as outside contributors but sometimes as full-time employees, people who are from the Unix-descended open-source culture (with its inside-to-out priorities) rather than interface-centric Mac guys.

That - and of course, OS X - tells us Apple's technical culture in't what it used to be. It's more Unix-influenced now, more open, has more hacker in it. Obviously that doesn't fix every problem with Apple - I'm with RMS in judging the locked-down, walled-garden design of their phones and tablets to be a very bad thing for users in the longer term - but it's movement in a good direction.



AK or AR
by gmhowell

Which is the better battle rifle, an AK-47/74 type or an AR-15/M-16/M-4 type? Please give your criteria as well as your answer. Bonus: favorite handgun platform/caliber that isn't a .45 1911.

ESR: "Better battle rifle" depends on who you're equipping, and for what. I lean towards the AR-15 because I'm from a culture that readily produces people with good marksmanship, fire discipline, and steadiness onder combat pressure. The AR-15 is the better weapon to match those traits - it rewards skill in the shooter and you can actually use it at distance.

On the other hand, if your troops are savages or bandits who can barely clean a weapon and for whom the natural mode is short-range spray'n'pray, the AK-47 is probably a better choice. It hardly rewards shooter skill at all, but handles egregious abuse under field conditions better.

As for what I like when I don't have .45ACP handy, my answer is easy and boring: .40S&W. Medium-caliber semis suit me very well. I don't mind shooting my wife's Glock .40 at all, and it's likely what I'd carry if not for John Moses Browning (peace be unto him)

An anonymous reader writes "Following one of the best descriptions ever of a hacker I've ever seen, Pete Herzog, creator of the 'security testing' (professional hacking) manual OSSTMM outlines compelling reasons why the traits of the hacker should be taught in school to make better students and better people. It starts out with 'Whatever you may have heard about hackers, the truth is they do something really, really well: discover.' and it covers open education, teaching kids to think for themselves, and promoting hacking as a tool for progress." A good read, despite confusing hacker and hacker a bit. I remember getting to set up Debian on a scrap machine in high school, only to have county IT kill the project because of the horrible danger experimentation could have proven to the network...

An anonymous reader writes "As Dell's (DELL:NASDAQ GS) board reviews three competing proposals for taking the company private, including a $24.4 billion deal led by founder and CEO Michael Dell and Silver Lake Partners, the company has announced it is entering the suddenly crowded smartwatch sweepstakes along with Apple, Google, and Samsung. The twist is that Dell's product will target the low end of the market — the extreme low end, in the words of CEO Dell, because 'that's where most of the world's customers are'. Dell's smartwatch, projected to cost just 19.99 USD ($319.99 before Dell's mail-in rebate) will allow children in developing countries to communicate via voice and text, collaborate on school activities, and perform native-to-English voice and text translations with the help of Dell's new ARM supercomputer. Dell says premium models will also perform translations in the reverse direction, i.e. English-to-native. Open Source advocate Eric S. Raymond, who joined Dell for the conference call, stated 'this is the beginning of what I call the Bazaar Wrist model of the mobile Internet. It'll be a battle of ideas against what I call the Office Tower Wrist model that Apple and Google will be selling.' Billionaire investor Carl Icahn, who recently launched a rival bid for Dell, labeled the product an 'a pig in the poke' as well as a 'distraction and extreme waste of shareholder value', adding that his $7.44 Wal-Mart watch 'works just great for me and probably anyone else'."

chrb writes "Nintendo has announced that its new Wii U console will feature a social network called the Miiverse in which users can video chat, see what others are playing, share game content and swap tips." And with a nod to Zawinski's Law, "The redesigned Wii U GamePad features dual sticks, a touch screen that supports finger and stylus interaction, motion and gyroscope sensors, and the ability to act as a TV remote. The Wii U GamePad has its own dedicated Web browser and can share images and video to a TV so that everyone can enjoy the shared content."

An anonymous reader writes "With its recent mass suspension of accounts, Google has highlighted its desire to create a social network that is very different to the way many (including those whose accounts were suspended) would want to see it. The metaphor of the Cathedral and the Bazaar used for software development can be applied to the two types of social networks being proposed by Google on the one hand and the pseudonym supporters on the other. Google's Cathedral model emphasizes order and control whilst the bazaar model supports users who can be anonymous, have multiple identities, interact with anyone they please, and remain unobserved."

Pickens writes "Jeff Atwood has an interesting post that begins by noting that with the Internet, whatever country you live in or language you speak, a growing percentage of the accumulated knowledge of the world can and should be available in your native language; but that the rules are different for programmers. 'So much so that I'm going to ask the unthinkable: shouldn't every software developer understand English?' Atwood argues that 'It's nothing more than great hackers collectively realizing that sticking to English for technical discussion makes it easier to get stuff done. It's a meritocracy of code, not language, and nobody (or at least nobody who is sane, anyway) localizes programming languages.' Eric Raymond in his essay 'How to be a Hacker' says that functional English is required for true hackers and notes that 'Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). His fluency in English has been an important factor in his ability to recruit a worldwide community of developers for Linux. It's an example worth following.' Although it may sound like The Ugly American and be taken as a sort of cultural imperialism, 'advocating the adoption of English as the de-facto standard language of software development is simple pragmatism, the most virtuous of all hacker traits,' writes Atwood. 'If that makes me an ugly American programmer, so be it.'"

An anonymous reader brings us Computerworld's interview with Don Woods, one of the creators of Compiler Language With No Pronounceable Acronym (INTERCAL). INTERCAL and its documentation were created in 1972 as a parody of that era's languages and instruction manuals. Among other things, Woods had this to say: "We designed the language without too much trouble. Writing the manual took a while, especially for things like the circuit diagrams we included as nonsensical illustrations. The compiler itself actually wasn't too much trouble, given that we weren't at all concerned with optimising the performance of either the compiler or the compiled code. I admit I'm surprised at its longevity. Some of the jokes in the original work feel rather dated at this point. It helps that the language provides a place where people can discuss oddball features missing from other languages, such as the 'COME FROM' statement and operators that work in base 3."

jesboat noted Eric S. Raymond and Rob Landley's essay about what the Linux community must do to achieve dominance entitled "World Domination 201". It says "Idealism about open formats will not solve our multimedia problem in time; in fact, getting stuck on either belief in the technical superiority of open source or free-software purism guarantees we will lose. The remaining problems aren't technical ones, and none of the interesting patents will expire before the end of 2008. We've got to ship something that works now. If we let this be a blocking issue preventing overall Linux adoption during the transition window, we won't have the userbase to demand changes in the laws to untangle the screwed up patent system, or even prevent it from getting worse. It's a chicken and egg problem, demanding a workaround until a permanent solution can be achieved. We can't set the standards until after we take over the world."

jesboat noted Eric S. Raymond and Rob Landley's essay about what the Linux community must do to achieve dominance entitled "World Domination 201". It says "Idealism about open formats will not solve our multimedia problem in time; in fact, getting stuck on either belief in the technical superiority of open source or free-software purism guarantees we will lose. The remaining problems aren't technical ones, and none of the interesting patents will expire before the end of 2008. We've got to ship something that works now. If we let this be a blocking issue preventing overall Linux adoption during the transition window, we won't have the userbase to demand changes in the laws to untangle the screwed up patent system, or even prevent it from getting worse. It's a chicken and egg problem, demanding a workaround until a permanent solution can be achieved. We can't set the standards until after we take over the world."

mvdwege writes "Apparently, Eric Raymond has decided that proprietary software is now a good thing, according to The Register. I must say it is rather revealing how easily he is willing to compromise on this particular freedom. Is his earlier vocal proclamation of the importance of freedom (still visible on his homepage) mere posturing? And if so, how about his vocal support of other freedoms?"

An anonymous reader asks: "A couple years ago Joel Spolsky wrote an interesting critique of Eric S. Raymond's The Art of Unix Programming wherein Joel provides an interesting (as usual) discussion on the cultural differences between Windows and Unix programmers. As a *nix nerd in my fifth year managing mainframe developers, I need some insight into mainframe programmers. What are the differences between Windows, Unix, and mainframe programmers? What do we all need to know to get along in each other's worlds?"

An anonymous reader asks: "A couple years ago Joel Spolsky wrote an interesting critique of Eric S. Raymond's The Art of Unix Programming wherein Joel provides an interesting (as usual) discussion on the cultural differences between Windows and Unix programmers. As a *nix nerd in my fifth year managing mainframe developers, I need some insight into mainframe programmers. What are the differences between Windows, Unix, and mainframe programmers? What do we all need to know to get along in each other's worlds?"

jg21 writes "LinuxWorld draws attention to a curious use of ESR's The Cathedral and the Bazaar by the Sun Microsystems exec who currently talks about Linux more than he does even about Java. Apparently Sun's President and COO Jonathan Schwartz said at a press briefing last week that Java with its JCP is more like ESR's Bazaar than Linux, which he dismissed as being "awfully cathedral-like" since Linus is the final arbiter (or Great Dictator), and not a committee." But be sure you don't mis-use the word Java in this Bazaar or the Mall Police will totally get you.

Dr.Dubious DDQ asks: "With all the recent Microsoft(r) news, I see a lot of the usual complaining about Microsoft's unfair 'embrace and extend' practices. I do my own fair share of this, but I'd much rather actually *do* something about it.At the risk of prompting cries of 'No! That will only make them stronger!', I find myself asking: How possible is it to 'transparently' replace Microsoft-brand services with other (preferably, but not necessarily, Open Source) services (rather than flatly demanding migration away from all things MS)? Or put the other way around, what tweaks would have to be made to existing, standard services to make them 'bug-for-bug compatible' with MS versions, particularly OUTSIDE of the context of SMB/Samba, which is an already-obvious example?" While there are definite reasons why such an effort may be worthwhile, it is also possible that Microsoft could attempt to make legal attacks at such projects...even though they are designed with software interoperability in mind. Precedents in support of this idea do exist, such as: ReactOS and even standard Open Source openings like Gnumeric. "I've got two goals in mind here:

1. Ability to placate MS-platform applications that demand MS-brand services to connect to while ALSO allowing non-MS clients as close to 'full' functionality as possible with the same services
2. Naturally, ability to replace an MS-branded package would personally appeal to me as well for both technical and - yes, I'll admit it - philosophical reasons.

Ways of meeting either (or both) goal would be useful to me and, I suspect, a lot of other sysadmins.

For example:

• Is it possible (and feasible) to get OpenLDAP+Kerberos5 to fool Windows systems into believing they're talking to a "real" ActiveDirectory(r) server (without necessarily also having the entire Samba stack)?
• Can client programs that demand MS-SQL server generally use MySQL in MS SQL Compatibility mode instead, if MySQL is set to respond on the MS-SQL port (either directly or via ODBC?)
• How hard would it be to make a 'mod_dav_sharepoint type of module that spoofs Microsoft's special Sharepoint WebDAV behavior (which evidently also uses a 'special' non-standard SQL-like search mechanism - am I going to be kicked out of the club for thinking this looks, at least on the surface, like it might be a useful feature if usable by non-MS clients and implementable by non-MS servers)?
• Similarly, how feasible would it be to get non-MS DAV clients to be able to use Microsoft Sharepoint (or the hypothetical MS-alike drop-in replacement?)
• How good are the 'drop-in replacements' for MS Exchange?
• Are there issues with MS's implementation of IPP (are there any problems dropping Microsoft Printer Sharing entirely and using CUPS instead? It SEEMS that MS Windows 2000+ should support IPP directly, without resorting to Samba middleware - is this true?)
• Possibly risking heaps of derision for suggesting such an unlikely-sounding thing, but how about using mod_dav/Apache (as what Microsoft USED to refer to as 'Web Folders') as a replacement for SMB file sharing? Aside from possible performance issues, is this feasible, or are there too many incompatibilities in MS's DAV support for it to work?
• Are there any registry hacks or other tweaks that can be applied to Microsoft Windows-based systems to make them behave in more standards-compliant ways?
• ...etc?...

Are there other replacements people have investigated?"

frogcircus asks: "Several weeks ago, at a neighborhood yard sale, my wife found an intact copy of Scotland Yard. I had been looking for one for several years (ever suspicious of eBay), driven by fond memories of group games in the late 80s. We played with a group of friends last night, and while some of us loved the game, others seemed a little less enthralled. It soon surfaced that the logic and reasoning involved in the game made it highly attractive for some of us. This got me thinking that perhaps the game was especially appealing to the geek mind. Which leads to my question: to which board games do you feel a close affinity? And to what degree have they engendered social interaction who don't share your particular interests?"

akahige writes "Fresh from the debunking of the 'Linus couldn't possibly have written an OS without ripping someone off' book published by the Alexis de Tocqueville Institution, Tanenbaum has published an email he got from the consultant hired to do the code comparison between MINIX and Linux. Among other juicy comments, 'pay no attention to this man.' (There was no stolen code, either.) In related matters, ESR was apparently sent a pre-release excerpt of the book which he completely eviscerates with his usual zeal. Another story on NewsForge." See our previous stories if you're coming to this late.

prostoalex writes "How many times, when playing Dungeons and Dragons by yourself, or reading an RFC in the bed alone on a Friday night, have you thought 'Boy, I sure wish there was an easier way to pick up women, like published API with code samples?' What would you say if such documentation was not only available, but succinctly put into 22 design patterns and given formal descriptions just like the ones in your UML book? Dating Design Patterns, with a cover suspiciously similar to Design Patterns by the Gang of Four, is the first attempt to bring verified solutions to common problems in the world of dating." Timothy's review follows prostoalex's, below. Dating Design Patterns author Solveig Haugland pages 150 publisher Solveig Haugland rating 9/10 reviewer Alex Moskalyuk ISBN 0974312002 summary Elements of reusable objective-oriented paired programming

Why design patterns are needed Many will attest that the API to the WOMEN platform is somewhat obscure, contradictory and poorly documented. However, if you talk to any randomly selected groups of men, you will discover that the problems they face (whether in Pickup or Relationship states) are fundamentally the same. If there's a common set of problems, shouldn't there be a common set of solutions? Moreover, doesn't it bother you that programming geeks, who advocate code reusability and open-sourcing have not come up with reusable successful solutions for commonly occurring problems and have not documented them?

This book is the attempt to change that and unite all design patterns in a single documentation project. You can read the conversation that led to writing DDP (caution: those of you in love with Design Patterns' concept might have a hard time reading how it was all a hoax by the Gang of Four). Hopefully you will understand the danger of letting this knowledge out (hint: geeks who talk to attractive girls, date and get laid spend less time writing code, which could jeopardize some projects) and not recommend the book to everyone you know. The table of contents is available online as well (in PDF format), and you can see that the book is subdivided into two large sections - introduction and pattern catalog.

Introduction to dating design patterns In the first part, the authors introduce the concepts of design patterns with several superfluous definitions in an attempt to outdo the academic titles types on Design Patterns in number of formal references and quoted italic text. They also provide the set of anti-patterns, which can be collected by surveying poor implementations of dating patterns. For example, the Iterator anti-pattern is described as "The nag. One of the most taxing on system resources. Also an anti-pattern when used to repeatedly ask the same woman for a date." Many developers fall into fallacy of thinking anti-pattern would do the job when a pattern does not work.

The chapter on refactoring talks about all the issues that must be taken care of before implementing any of the patterns. Each refactoring unit includes sub-sections on Motivation, Mechanics and Example. The motivation part explains how this refactoring unit can help publish an attractive public interface for FEMALE platform. The mechanics part usually includes a bulleted list of what needs to be done for the implementation. The example brings us into more practical world, where we can visualize how the refactoring units "Get a makeover", "Display yourself in a new context through third parties", "Publish a more restricted interface" and "Fake a phone call from an ex-girlfriend" can help interested geek attract female companions.

Pattern Catalog

The second part is nothing more but a collection of 22 existing dating patterns. This part of the book will be even more familiar to those who read the original Design Patterns, as the headings, bulleted lists, sidebar notes and sub-chapter titles are all there. Each pattern is presented in the following format:

1. Pattern name
2. Problem statement (the authors acknowledge that for most of developers the problems reside in attempting to implement getLaid method successfully on FEMALE platform)
3. Forces (why this pattern might lead to successful implementation)
4. Solution (overview of what's required for successful implementation)
5. Strategies (step-by-step guide with copious notes)
6. Benefits and Drawbacks (analysis of when this design pattern makes sense and when it's not appropriate)
7. Related patterns

Anyone who's ever been through UML or Design Patterns class will not have a problem with reading the pattern catalog. The pseudocode sometimes used to describe the pattern is somewhat close to Java and uses Camel notation for method calls, state and interface definitions. Luckily the book is void of any humor that design pattern writers usually try to sneak in, and is just plain formal scientific boring writing with SAT-level vocabulary that we all grew to love while reading the Gang of Four series.

The problem statements use clear language, allowing the reader to figure out whether he has the same problem (and thus should read the pattern to find out the solution) or move on to the next pattern. For example, the Jini Singles Bar pattern describes the following problem:

You're a great catch, of course, and you're looking for someone smart, funny, beautiful, who can talk about rock-climbing, Slashdot, politics and 19th century Serbo-Croatian playrights. It would also be nice if she were 24, between 5'6'' and 5'8'', of French extraction, interested in the songs of Owen Margolis, with dark long brown hair. However, you have not yet found this woman.

Conclusion The point that authors try to emphasize is that Dating Design Patterns is a collection of researched, verified, formalized and proven to work patterns. Of course, there are numerous pages of already available documentation with questionable applicability, as well as HOWTO's from open-source luminaries, but they provide neither the variety of patterns that this book has, nor the exact step-by-step implementations.

As common with design patterns, there are areas where they work perfectly and there are cases, where they are not applicable at all. The collection (full list of patterns with appropriate poster is available from the official Web site) just provides the list of accepted solutions to common problems. Perhaps reading through all 22 patterns is an onerous task and should be left to those in academic world. However, the authors assure that the benefits of successful implementation outweigh the amount of resources that need to be dedicated. Now, if you'll excuse me, that girl from Barnes and Noble with very nice public properties is getting out of the shower and her private members are even more interesting.

Tim's review: Don't buy this book. None of the ideas in it work. Absolute garbage. Haugland's "advice" will not result in flocks of appropriate-sex singles following you out of every coffee bar, bookstore or tango lesson you happen to visit. Repeat: do not buy this book.

You can search for Dating Design Patterns from bn.com, or better yet, straight from the author. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

The first Slashback in a while, with updates and reactions to previous Slashdot stories, including a Flash-mod supercomputing reminder, the upside of microwave-tested currency, CUPS' user-interface foibles, an alternative to MD5 sums, and more. Read on for the details.

Reminder of your scheduled spontaneous appointment. Zero_K writes "As previously posted on Slashdot and the NY Times, the University of San Francisco's, Computer Science department is building a 'flash mob' supercomputer on April 3rd. On their newly updated official web-site (Main Site, ISO's) the team has now posted the ISO image of their custom morphix that will be used to boot all the computers into the cluster, documentation is on the website (under 'downloads') and on the CD (index.html). I personally plan on downloading and testing this ISO tonight. And after the cluster is taken off line, there will be a massive LAN PARTY (Possibly one of the biggest in San Francisco...) On a 10-Gigabit LAN...Oh sweetness ... So if you are in or around the SF Bay Area on April 3rd, be sure to sign up and bring your laptop or desktop to campus and help make history."

Whaddya mean, "no pun intended"? Rudiger writes "After the dust (no pun intended) has settled around the whole Operation Dust Bunny thing, McAfee updates their signature database classifying Dust Bunny as an application. To be more specific: 'This program is detected as a "potentially unwanted application."' They also say 'This is not a virus or trojan.' Should we leave it to the experts this time?"

Would you read Atlas Shrugged on this screen? An anonymous reader writes "The so-called 'electronic paper,' being a high-clarity monochrome display to become a foundation for comfortable and inexpensive 'electronic papers,' has finally shown its face. The new electronic paper, which looks a bit like an iPod, has 10MB memory, keyboard, Memory Stick PRO slot, voice recorder, speaker, and headphones output, and USB2.0 interface."

(We mentioned the device yesterday, but this link provides better images of it.)

Now they're Pragmatic Publishers as well -- much success! AndyHunt writes "As you may have heard, the Pragmatic Programmers have started their own publishing company (see Slashdot reviews here and here). We've just signed our first outside author: Mike Clark, editor of the JUnit FAQ and developer of JUnitPerf and JDepend. He'll be writing the eagerly-anticipated Pragmatic Project Automation book, the third volume in our Jolt Productivity award-winning series."

Exactly how many bits, Ma'am? And in what order, did you say? jlcooke writes "Two months (almost to the day) after getting slashdotted for an innocent post to sci.crypt - the MD5CRK project has launched. The aim is to get the thousands of applications and websites to drop MD5 for SHA-1 or SHA-256 by finding a counter-example of a security requirement in MD5. Press Release is here."

How to take criticism, by example. slashdot_commentator writes "Eric S. Raymond has recently written a wonderful piece explaining to the Linux zealot why it may not be the operating system of choice of all users. (Or what user aspects open source developers need to focus on to further Linux World Domination.) The op-ed specifically focuses on the CUPS printing system. (But it would be a mistake to dismiss it as a screed against CUPS.) The CUPS authors surprisingly acknowledged ESR's points, and he wrote a followup to the article."

Hitting them where it figuratively hurts. Ian Wilson writes with a followup to the Slashdot post earlier this month on "website thieves stealing content and designs from others, taken from silicon.com. Well, now silicon.com is reporting that it has contacted the offending site's advertisers and forced them to stop paying ad revenues - thus effectively crippling the illegal site - after all, no revenue, no reason to the run the site."

Express your appreciation with PizzaPal. Chuck writes "After you guys published the article on $20 bills exploding when microwaved, a co-worker of mine went to put his soup in the microwave and found a $20 bill in it. Too bad it was an older one, but someone around the office must have left it in there after reading your article. The co-worker then took me out to lunch. Thanks, Slashdot!"

The first Slashback in a while, with updates and reactions to previous Slashdot stories, including a Flash-mod supercomputing reminder, the upside of microwave-tested currency, CUPS' user-interface foibles, an alternative to MD5 sums, and more. Read on for the details.

Reminder of your scheduled spontaneous appointment. Zero_K writes "As previously posted on Slashdot and the NY Times, the University of San Francisco's, Computer Science department is building a 'flash mob' supercomputer on April 3rd. On their newly updated official web-site (Main Site, ISO's) the team has now posted the ISO image of their custom morphix that will be used to boot all the computers into the cluster, documentation is on the website (under 'downloads') and on the CD (index.html). I personally plan on downloading and testing this ISO tonight. And after the cluster is taken off line, there will be a massive LAN PARTY (Possibly one of the biggest in San Francisco...) On a 10-Gigabit LAN...Oh sweetness ... So if you are in or around the SF Bay Area on April 3rd, be sure to sign up and bring your laptop or desktop to campus and help make history."

Whaddya mean, "no pun intended"? Rudiger writes "After the dust (no pun intended) has settled around the whole Operation Dust Bunny thing, McAfee updates their signature database classifying Dust Bunny as an application. To be more specific: 'This program is detected as a "potentially unwanted application."' They also say 'This is not a virus or trojan.' Should we leave it to the experts this time?"

Would you read Atlas Shrugged on this screen? An anonymous reader writes "The so-called 'electronic paper,' being a high-clarity monochrome display to become a foundation for comfortable and inexpensive 'electronic papers,' has finally shown its face. The new electronic paper, which looks a bit like an iPod, has 10MB memory, keyboard, Memory Stick PRO slot, voice recorder, speaker, and headphones output, and USB2.0 interface."

(We mentioned the device yesterday, but this link provides better images of it.)

Now they're Pragmatic Publishers as well -- much success! AndyHunt writes "As you may have heard, the Pragmatic Programmers have started their own publishing company (see Slashdot reviews here and here). We've just signed our first outside author: Mike Clark, editor of the JUnit FAQ and developer of JUnitPerf and JDepend. He'll be writing the eagerly-anticipated Pragmatic Project Automation book, the third volume in our Jolt Productivity award-winning series."

Exactly how many bits, Ma'am? And in what order, did you say? jlcooke writes "Two months (almost to the day) after getting slashdotted for an innocent post to sci.crypt - the MD5CRK project has launched. The aim is to get the thousands of applications and websites to drop MD5 for SHA-1 or SHA-256 by finding a counter-example of a security requirement in MD5. Press Release is here."

How to take criticism, by example. slashdot_commentator writes "Eric S. Raymond has recently written a wonderful piece explaining to the Linux zealot why it may not be the operating system of choice of all users. (Or what user aspects open source developers need to focus on to further Linux World Domination.) The op-ed specifically focuses on the CUPS printing system. (But it would be a mistake to dismiss it as a screed against CUPS.) The CUPS authors surprisingly acknowledged ESR's points, and he wrote a followup to the article."

Hitting them where it figuratively hurts. Ian Wilson writes with a followup to the Slashdot post earlier this month on "website thieves stealing content and designs from others, taken from silicon.com. Well, now silicon.com is reporting that it has contacted the offending site's advertisers and forced them to stop paying ad revenues - thus effectively crippling the illegal site - after all, no revenue, no reason to the run the site."

Express your appreciation with PizzaPal. Chuck writes "After you guys published the article on $20 bills exploding when microwaved, a co-worker of mine went to put his soup in the microwave and found a $20 bill in it. Too bad it was an older one, but someone around the office must have left it in there after reading your article. The co-worker then took me out to lunch. Thanks, Slashdot!"

tachin asks: "We've all been hearing about software as a service industry as opposed to manufacturing, there are some differences that favour that view, but I wonder if the type of industry affects the fundamental design of a software system. Considering the differences between those two types, are there some software constructs that are appropriate for one type of industry but would be undesirable for the other? As economies everywhere are becoming more service-oriented, what are the main characteristics a software system must provide to work well in such environments?"

Mike Godwin is probably best known to Slashdot readers for Godwin's Law, but that's one of the most minor reasons you should know him. In this blurb for his book, CYBER RIGHTS, he's (correctly) described as "one of the first lawyers to 'live and work in cyberspace.'" Naturally, Mike can't give specific legal advice, but he's certainly about as expert as they come about the development of law and legal hassles surrounding the Internet. We'll send him 10 of the highest-moderated questions, and publish his answers as soon as we get them back.

badzilla and numerous others wrote in with this: "Eric S. Raymond's Open Source site has a new Halloween memo. The Halloween X memo, which ESR says he received by email from an anonymous whistleblower inside SCO, appears to confirm Microsoft's alleged funding of SCO's anti-Linux initiative. And the actual dollar amounts are much larger than previously rumored!" The consultant is discussing his fee for bringing in this business, in the first few lines of the email.

Bootsy Collins writes "Using the recent experience of trying to configure CUPS on his home network, Eric Raymond has written an interesting new screed on poor design of user interfaces in general, and configuration interfaces in particular, in open source software, entitled The Luxury of Ignorance. A sample quote: 'This kind of fecklessness is endemic in open-source land. And it's what's keeping Microsoft in business -- because by Goddess, they may write crappy insecure overpriced shoddy software, but on this one issue their half-assed semi-competent best is an order of magnitude better than we usually manage.'"

dave writes "ESR has opened the issue of pressuring Sun to open source Java, and today IBM throws in their own commitment toward this end. IBM has published an open letter to Sun, proposing that the two companies collaborate on an independent project to open source Java, saying that IBM is ready to provide technical resources and code for the open source Java implementation while Sun provides the open source community with Sun materials, including Java specifications, tests and code."

dave writes "ESR has opened the issue of pressuring Sun to open source Java, and today IBM throws in their own commitment toward this end. IBM has published an open letter to Sun, proposing that the two companies collaborate on an independent project to open source Java, saying that IBM is ready to provide technical resources and code for the open source Java implementation while Sun provides the open source community with Sun materials, including Java specifications, tests and code."

dwheeler writes "It's not often you find a classic, but I think I've found a new classic for software and computer hardware developers. It's David J. Agan's Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems." Read on for the rest. Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems author David J. Agans pages 192 publisher Amacom rating 9 reviewer David A. Wheeler ISBN 0814471684 summary A classic book on debugging principles

Debugging explains the fundamentals of finding and fixing bugs (once a bug has been detected), rather than any particular technology. It's best for developers who are novices or who are only moderately experienced, but even old pros will find helpful reminders of things they know they should do but forget in the rush of the moment. This book will help you fix those inevitable bugs, particularly if you're not a pro at debugging. It's hard to bottle experience; this book does a good job. This is a book I expect to find useful many, many, years from now.

The entire book revolves around the "nine rules." After the typical introduction and list of the rules, there's one chapter for each rule. Each of these chapters describes the rule, explains why it's a rule, and includes several "sub-rules" that explain how to apply the rule. Most importantly, there are lots of "war stories" that are both fun to read and good illustrations of how to put the rule into practice.

Since the whole book revolves around the nine rules, it might help to understand the book by skimming the rules and their sub-rules:

1. Understand the system: Read the manual, read everything in depth, know the fundamentals, know the road map, understand your tools, and look up the details.
2. Make it fail: Do it again, start at the beginning, stimulate the failure, don't simulate the failure, find the uncontrolled condition that makes it intermittent, record everything and find the signature of intermittent bugs, don't trust statistics too much, know that "that" can happen, and never throw away a debugging tool.
3. Quit thinking and look (get data first, don't just do complicated repairs based on guessing): See the failure, see the details, build instrumentation in, add instrumentation on, don't be afraid to dive in, watch out for Heisenberg, and guess only to focus the search.
4. Divide and conquer: Narrow the search with successive approximation, get the range, determine which side of the bug you're on, use easy-to-spot test patterns, start with the bad, fix the bugs you know about, and fix the noise first.
5. Change one thing at a time: Isolate the key factor, grab the brass bar with both hands (understand what's wrong before fixing), change one test at a time, compare it with a good one, and determine what you changed since the last time it worked.
6. Keep an audit trail: Write down what you did in what order and what happened as a result, understand that any detail could be the important one, correlate events, understand that audit trails for design are also good for testing, and write it down!
7. Check the plug: Question your assumptions, start at the beginning, and test the tool.
8. Get a fresh view: Ask for fresh insights, tap expertise, listen to the voice of experience, know that help is all around you, don't be proud, report symptoms (not theories), and realize that you don't have to be sure.
9. If you didn't fix it, it ain't fixed: Check that it's really fixed, check that it's really your fix that fixed it, know that it never just goes away by itself, fix the cause, and fix the process.

This list by itself looks dry, but the detailed explanations and war stories make the entire book come alive. Many of the war stories jump deeply into technical details; some might find the details overwhelming, but I found that they were excellent in helping the principles come alive in a practical way. Many war stories were about obsolete technology, but since the principle is the point that isn't a problem. Not all the war stories are about computing; there's a funny story involving house wiring, for example. But if you don't know anything about computer hardware and software, you won't be able to follow many of the examples.

After detailed explanations of the rules, the rest of the book has a single story showing all the rules in action, a set of "easy exercises for the reader," tips for help desks, and closing remarks.

There are lots of good points here. One that particularly stands out is "quit thinking and look." Too many try to "fix" things based on a guess instead of gathering and observing data to prove or disprove a hypothesis. Another principle that stands out is "if you didn't fix it, it ain't fixed;" there are several vendors I'd like to give that advice to. The whole "stimulate the failure, don't simulate the failure" discussion is not as clearly explained as most of the book, but it's a valid point worth understanding.

I particularly appreciated Agans' discussions on intermittent problems (particularly in "Make it Fail"). Intermittent problems are usually the hardest to deal with, and the author gives straightforward advice on how to deal with them. One odd thing is that although he mentions Heisenberg, he never mentions the term "Heisenbug," a common jargon term in software development (a Heisenbug is a bug that disappears or alters its behavior when one attempts to probe or isolate it). At least a note would've been appropriate.

The back cover includes a number of endorsements, including one from somebody named Rob Malda. But don't worry, the book's good anyway :-).

It's important to note that this is a book on fundamentals, and different than most other books related to debugging. There are many other books on debugging, such as Richard Stallman et al's Debugging with GDB: The GNU Source-Level Debugger. But these other texts usually concentrate primarily on a specific technology and/or on explaining tool commands. A few (like Norman Matloff's guide to faster, less-frustrating debugging ) have a few more general suggestions on debugging, but are nothing like Agans' book. There are many books on testing, like Boris Beizer's Software Testing Techniques, but they tend to emphasize how to create tests to detect bugs, and less on how to fix a bug once it's been detected. Agans' book concentrates on the big picture on debugging; these other books are complementary to it.

Debugging has an accompanying website at debuggingrules.com, where you can find various little extras and links to related information. In particular, the website has an amusing poster of the nine rules you can download and print.

No book's perfect, so here are my gripes and wishes:

1. The sub-rules are really important for understanding the rules, but there's no "master list" in the book or website that shows all the rules and sub-rules on one page. The end of the chapter about a given rule summarizes the sub-rules for that one rule, but it'd sure be easier to have them all in one place. So, print out the list of sub-rules above after you've read the book.
2. The book left me wishing for more detailed suggestions about specific common technology. This is probably unfair, since the author is trying to give timeless advice rather than a "how to use tool X" tutorial. But it'd be very useful to give good general advice, specific suggestions, and examples of what approaches to take for common types of tools (like symbolic debuggers, digital logic probes, etc.), specific widely-used tools (like ddd on gdb), and common problems. Even after the specific tools are gone, such advice can help you use later ones. A little of this is hinted at in the "know your tools" section, but I'd like to have seen much more of it. Vendors often crow about what their tools can do, but rarely explain their weaknesses or how to apply them in a broader context.
3. There's probably a need for another book that takes the same rules, but broadens them to solving arbitrary problems. Frankly, the rules apply to many situations beyond computing, but the war stories are far too technical for the non-computer person to understand.

But as you can tell, I think this is a great book. In some sense, what it says is "obvious," but it's only obvious as all fundamentals are obvious. Many sports teams know the fundamentals, but fail to consistently apply them - and fail because of it. Novices need to learn the fundamentals, and pros need occasional reminders of them; this book is a good way to learn or be reminded of them. Get this book.

If you like this review, feel free to see Wheeler's home page, including his book on developing secure programs and his paper on quantitative analysis of open source software / Free Software. You can purchase Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

yukster writes "Eric Raymond has posted an open letter to Sun Microsystem's Scott McNealy asking him to 'Let Java go.' He says Sun can 'have ubiquity or [it] can have control.' The excellent improvements made to Java in the upcoming 1.5 release help re-level the playing field with C#. But, it seems like if Sun really wants Java to rule the world, they should heed ESR's advice. Hey Mr. McNealy, listen to this guy... set Java free!"

yukster writes "Eric Raymond has posted an open letter to Sun Microsystem's Scott McNealy asking him to 'Let Java go.' He says Sun can 'have ubiquity or [it] can have control.' The excellent improvements made to Java in the upcoming 1.5 release help re-level the playing field with C#. But, it seems like if Sun really wants Java to rule the world, they should heed ESR's advice. Hey Mr. McNealy, listen to this guy... set Java free!"

Endymion53 writes "The TMRC at MIT may be the best known model railroad layout because of its role in the formation of hacking culture, but railroad uber-enthusiast Jack Burgess has built himself a pretty enviable layout, that does its best to capture the look and route of an old rail line that went to Yosemite National park, called the Yosemite Valley railroad. I was tempted to make some crass remarks about having too much time on one's hands, but frankly, the whole thing looks just awesome. He's been working on this thing since 1981."

prostoalex writes "Dr. Orly Turgeman Goldschmidt from Hebrew University of Jerusalem conducted a research to figure out if there any any differences between the classic computer vandal stereotypes and the real life. After surveying 54 Israeli repondents and using the term hacker gratuitously, Goldshmidt found out many computer vandals to be "young, well-educated men without a criminal record, who belong to the middle or upper class." 3 out of 54 respondents were women, some of the respondents were married and had children. Goldschmidt's survey seemed to include somewhat low-life representatives of computer security community, the type who goes on shopping sprees on stolen credit cards, so take the findings with a grain of salt."

Ridgelift writes "Eric S. Raymond is proposing a new logo for Hackerdom. 'The Linux folks have their penguin and the BSDers their demon. Perl's got a camel, FSF fans have their gnu and OSI's got an open-source logo. What we haven't had, historically, is an emblem that represents the entire hacker community of which all these groups are parts. This is a proposal that we adopt one - the glider pattern from the Game of Life.'"

Ridgelift writes "Eric S. Raymond is proposing a new logo for Hackerdom. 'The Linux folks have their penguin and the BSDers their demon. Perl's got a camel, FSF fans have their gnu and OSI's got an open-source logo. What we haven't had, historically, is an emblem that represents the entire hacker community of which all these groups are parts. This is a proposal that we adopt one - the glider pattern from the Game of Life.'"

acousticiris writes "According to an analysis of Friday's memorandum from SCO on Groklaw: 'If I had to characterize it in a brief sentence or two, the sentence would be that SCO tells the court, "How are we supposed to know what code IBM misappropriated? It's up to them to prove our case for us."...' It's also interesting to note that in Friday's memorandum, footnote 4, SCO uses Eric Raymond's Jargon File entry for FUD to take pot shots at IBM (footnote 4). Evidently, Eric was not pleased, according to the updated entry."

acousticiris writes "According to an analysis of Friday's memorandum from SCO on Groklaw: 'If I had to characterize it in a brief sentence or two, the sentence would be that SCO tells the court, "How are we supposed to know what code IBM misappropriated? It's up to them to prove our case for us."...' It's also interesting to note that in Friday's memorandum, footnote 4, SCO uses Eric Raymond's Jargon File entry for FUD to take pot shots at IBM (footnote 4). Evidently, Eric was not pleased, according to the updated entry."

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.

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.

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.

webmaven writes "According to this article in eWEEK, ESR has released a utility called comparator for analyzing the similarity of source code trees. The technical details are interesting, in that ESR says he is using an implementation of a refined version of the 'shred' algorithm, with higher performance (on machines with enough RAM) than other versions. ESR won't say whether he intends the comparator to be used to compare older Unix code to Linux so as to be able to refute SCO's claims, but it's obviously well suited for such a purpose. Interestingly, as the shred algorithm can run reports on source trees using only the MD5 signature shreds (once generated), it is possible to use it to compare trees without direct access to the source code itself, leading to a possible use in comparing various proprietary source trees with each other and with Freely available code bases such as Linux and *BSD without requiring actual disclosure of the proprietary source code (a neutral third party could generate the shreds on a company's premises, and leave without taking a copy of the source with them). I'll be interested to see if (or which of) the proprietary vendors allow their source trees to be 'shredded' for such comparisons, and whether this becomes a standard forensic technique in source-code copyright and trade-secret disputes."

don.g writes "As reported by NTK, ESR appears to have embarked apon the process of recasting the Jargon File in his own image, adding terms like "Aunt Tillie" and "GhandiCon" that he dreamt up and seemingly no-one else uses, and various terms from (of all places) the warblogging community, where he is active. He's also updated the "Hacker Politics" page to be more closely aligned with his own views."

ESR writes "You can help stop the SCO attack on IBM and the Linux community. I'm looking for ways to prove that Unix trade secrets have been legally nullified. I want to know if you have ever had read access to proprietary Unix source code (not just binaries and documentation) under circumstances where either no non-disclosure agreement was required or whatever non-disclosure agreement you had was not enforced. To help out, see my No Secrets page."

larsberg writes "Another wonderful article from Paul Graham on hackers, their lifestyle, and their tools. It's entitled "Hackers and Painters", and provides a great description of how the great hackers write code. The article is definitely worth a read, especially for those who have an inkling that any field that has to place the word "Science" in its name probably isn't really a science after all."