Slashdot Mirror

I don't accept any patches that I don't understand, or that I think will make the project harder to direct, maintain, or to make additions. If somebody wants to fork it is almost never a problem. If you think their patches will have problems, so will their version. If they want to do something different with it, then it really isn't competition. Why is competition bad anyway? Its not like you expect to make more money the more customers you get.

Read the cathedral and the bazaar if you have not already done so. You think like a cathedral programmer: your program should be directed from on high. A bazaar programmer will coerce others into feeling good about making contributions and release early and often.

Furthermore, you need to look at your motivations for producing open source software. You sound like you want the user base and the name recognition. It doesn't happen to all of us. I code open source because I want to make cool things happen and I want to force other people to let me experience the cool things that they make happen (for free!) So one of my favorites is why not lgpl?

If you want a successful (popular) open source project, the ones that make it big fall into two categories as I see it:
1) The ones that are big: mozilla, the gimp, they take a lot of open source programmers working together to produce something that paid developers would have a hard time doing.
2) Projects that let other developers build from them: linux, libraries, that fuel innovation in other open source developers.

If you work on something that falls in both those categories (like linux and mozilla) you are all set. But you can't do it alone. And unless you release early, and often, you can't get help.

Until a recent /. thread, I didn't realize there was such a tool as Fetchmail. This makes it exceedingly easy to use SpamAssassin.

I thought that since I didn't own/administer the mail server for my address that I couldn't get spamassassin installed or even use it in any way. But if you use Fetchmail on your OWN box, it pops/sends from your pop account on the remote machine to your address on the local machine, where you can use all the spamassassin & procmail stuff you want.

I didn't think that I could ever get SpamAssassin working for me, but after getting fetchmail working and a few Perl module installs later, SpamAssassin is tagging those nasty spams for easy filtering. It's great

• The characters are distinct and have real personalities. Each one has a sad past that you gradually learn about through the series. By the end, I actually felt bad for Faye.
• The premise is a little different as the series isn't about 1) mecha, 2) big-eyed teenage girls or 3) tentacle pr0n.
• There are only 26 episodes, so it doesn't go on forever like some series I could mention *cough*DBZ*cough*.
• While there is an underlying plot to the series, each episode is more-or-less self-contained; so if you miss an episode, you're not completely lost.
• I don't speak Japanese and I don't really want to watch subtitles, so it's fortunate that the English dubbing really is quite good.
• The music is very good. 'Waltz for Zizi', for example, is a very pretty song.
• It is very artistic. The very first scene in the first episode and the very last scene of the last episode (to take two at random :)) are well done. There are some episodes as a whole that were very well done. 'Pierrot Le Fou' comes to mind. And finally...
• It had Ein. :)

ObJargonFileRef: ISO pizza? How about an ANSI Standard Pizza?

Team software development generates lots of sincronization points between team members. A large team loses more time communicating than developing. Thus, project development speed doesn't grow linearly with added manpower. This is one of the causes for Brooks's Law (the other being team setup-time).

So, how far from reality you are depends on how big a distributed software development team can get, before "thrashing". I'd say the dynamic nature of open-source projects already generates ideally sized teams for popular projects. There would be no advantage in making them bigger.

People

Richard Stallman -
Eric S. Raymond -
Larry Wall

Linux Programming

Unix

Programming Methodologies

C Programming

C++ Programming

Perl Programming

Network Programming

Open Source

People

Richard Stallman -
Eric S. Raymond -
Larry Wall

Linux Programming

Unix

Programming Methodologies

C Programming

C++ Programming

Perl Programming

Network Programming

Open Source

People

Richard Stallman -
Eric S. Raymond -
Larry Wall

Linux Programming

Unix

Programming Methodologies

C Programming

C++ Programming

Perl Programming

Network Programming

Open Source

to describe "bad coders," i think the phrase you're looking for is "Code Monkey," sense #1 from the Jargon file: A person only capable of grinding out code, but unable to perform the higher-primate tasks of software architecture, analysis, and design. Mildly insulting. Often applied to the most junior people on a programming team.

1.5 millibit/sec - I wonder how many Libraries of Congress per microfortnight that'd be? hmmm... Assuming the most often figure that 1LOC = 10TB, that's

806.4 microfortnights/bit
= 8,866,461,766,385,664 microfortnights/LOC
= 1.127845612317619342652578202505e-16 LOCs/microfortnight

BTW, I prefer LOC/attoparsec over the more frequently used LOC/hectare for storage density measurements.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

look it up.

somewhere else...

You may also want to take a look at the letter Richard Stallman (the hacker who created GNU, wrote GNU Emacs, the GNU Compiler Collection, and the GNU Debugger, among other things), wrote to the New York Times protesting their misuse of the term "hacker".

You can find his letter at the bottom of this page in The Jargon File.

--Phillip

You may also want to take a look at the letter Richard Stallman (the hacker who created GNU, wrote GNU Emacs, the GNU Compiler Collection, and the GNU Debugger, among other things), wrote to the New York Times protesting their misuse of the term "hacker".

You can find his letter at the bottom of this page in The Jargon File.

--Phillip

For those too lazy to follow the link, here is the definition (minus all the crossreferences):

hacker n.

[originally, someone who makes furniture with an axe] 1. A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. 2. One who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorizing about programming. 3. A person capable of appreciating hack value. 4. A person who is good at programming quickly. 5. An expert at a particular program, or one who frequently does work using it or on it; as in `a Unix hacker'. (Definitions 1 through 5 are correlated, and people who fit them congregate.) 6. An expert or enthusiast of any kind. One might be an astronomy hacker, for example. 7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations. 8. [deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence `password hacker', `network hacker'. The correct term for this sense is cracker.

The term `hacker' also tends to connote membership in the global community defined by the net (see the network and Internet address). For discussion of some of the basics of this culture, see the How To Become A Hacker FAQ. It also implies that the person described is seen to subscribe to some version of the hacker ethic (see hacker ethic).

It is better to be described as a hacker by others than to describe oneself that way. Hackers consider themselves something of an elite (a meritocracy based on ability), though one to which new members are gladly welcome. There is thus a certain ego satisfaction to be had in identifying yourself as a hacker (but if you claim to be one and are not, you'll quickly be labeled bogus). See also geek, wannabee.

This term seems to have been first adopted as a badge in the 1960s by the hacker culture surrounding TMRC and the MIT AI Lab. We have a report that it was used in a sense close to this entry's by teenage radio hams and electronics tinkerers in the mid-1950s.

For those too lazy to follow the link, here is the definition (minus all the crossreferences):

hacker n.

[originally, someone who makes furniture with an axe] 1. A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. 2. One who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorizing about programming. 3. A person capable of appreciating hack value. 4. A person who is good at programming quickly. 5. An expert at a particular program, or one who frequently does work using it or on it; as in `a Unix hacker'. (Definitions 1 through 5 are correlated, and people who fit them congregate.) 6. An expert or enthusiast of any kind. One might be an astronomy hacker, for example. 7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations. 8. [deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence `password hacker', `network hacker'. The correct term for this sense is cracker.

The term `hacker' also tends to connote membership in the global community defined by the net (see the network and Internet address). For discussion of some of the basics of this culture, see the How To Become A Hacker FAQ. It also implies that the person described is seen to subscribe to some version of the hacker ethic (see hacker ethic).

It is better to be described as a hacker by others than to describe oneself that way. Hackers consider themselves something of an elite (a meritocracy based on ability), though one to which new members are gladly welcome. There is thus a certain ego satisfaction to be had in identifying yourself as a hacker (but if you claim to be one and are not, you'll quickly be labeled bogus). See also geek, wannabee.

This term seems to have been first adopted as a badge in the 1960s by the hacker culture surrounding TMRC and the MIT AI Lab. We have a report that it was used in a sense close to this entry's by teenage radio hams and electronics tinkerers in the mid-1950s.

Woohoo, now I get to be modded down!

You, sir, are an ass. A well-intentioned ass, to be sure, but an ass nonetheless.

First, you mention specific political situations in the 1930's. You are dangerously close to forfeiting via Godwin's Law. But enough about that, I'll merely point out that straw men do not an argument make.

Now then, you claim that Yahoo should pull out of China rather than bend to the will of the Chinese government. I wonder what you hope to gain by this? Do you hope to make the lot of the Chinese people better by denying them even a censored Yahoo? To you expect the Chinese government to cave in and embrace the unfiltered net? No. Dictators love embargoes. Compare China, North Korea, and Cuba. Which is the most free? What have our policies of isolation done to promote freedom? Nothing. They have buttressed up Castro and Kim, allowing them a death-grip on their people. Supposedly most North Koreans don't even realize that starving to death is unusual in the wider world.

So, yes. Appeasement. It is a wonderful strategy for fighting totalitarianism. Beats invasion, beats embargoes. Why? The center cannot hold. People do not want to be repressed. If you isolate them, they cannot even get an inkling of freedom. If you let them peek out through the thick curtains of censorship, they can see that there's a different world outside. You make the choice - the windowless room of isolation or the thin slit of censorship. Which would you offer the Chinese people?

I'm still curious about your previous soundbite. ("Yahoo! Where your civil liberties are what your government tells us they are.") What other kinds of civil liberties are there?

HHOS? YMMV? What the fuck do all those acronyms mean?

HHOS

YMMV

HHOS? YMMV? What the fuck do all those acronyms mean?

HHOS

YMMV

YHBT. YHL. HAND.

AT&T is being smart here. Socially engineer me once, shame on you. Socially engineer me twice, shame on me. Granted, what with all the shenanigans that have happened in the past with AT&T and hackers (they dont seem to get along so well) it has been a great deal more than "Socially engineer me twice" for the folks at AT&T.

Read the jargon file !

On the recently developed UCSC Student Portal, I added an easter egg into the site search that automatically changed the search context to the "Jargon File" if someone typed "Jargon: " before thier search string. Pretty hard to find, but I mostly wanted there as a way for me (and other C.S. majors) to search the Jargon File without having to add it as an option in the drop down list and have the heads breathing down my neck for it.

Yes, this is a possible. Just because you can doesn't mean you will. Anyone that attempts this "hack" will be busted ASAFP. This would require prior control over either the target computer (internal DNS cache or DNS setting) or the control over its DNS server. Either attack would be extremely difficult.

The first would require a previous hack into the Mac OS X machine. If you can do that, why go to the trouble of altering the DNS cache or DNS setting? With Mac OS X's BSD roots, its not too tuff to modify the system with root access. Pointless.

The second attack option would require you to break into a public DNS server, modify the tables, slip out and hope that your non-targets (huge numbers of Windows users) don't start complaining to the DNS admin about problems. This attack is a possibility but most likely will be noticed quickly.

This is not to excuse Apple but I think its nice that I can read in clear text with ettercap what is going on with my Mac OS X system when it contacts the "Reality Distortion Field" of the Internet. If I want to wear a tinfoil hat and put Tapioca pudding in a locked jar, I can always turn automatic Software Updates off and download the updates straight from the Apple web site.

However, it would be nice if Apple used some sort of the handshake to ensure the safety of the update. There is a myriad of options to choose from...all with benefits and deficits.

The OSI logo contest information might clear this up. It was conceived by ESR with some pretty specific rules. There were a wide variety of submissions. There was a diverse interpretation of what OS was to represent. The selected image was provided by "Hilmar". Additionally, here is the index of all the submissions.here

Hardware wears out. Software doesn't.

I've also often seen people try to take flash pictures of things through glass, while taking the picture perpendicular to the plane of the glass.

Somebody in this thread estimated 70%, but I think that person forgot about Sturgeon's Law.

Well the problem is that general purpose parsing in itself is a difficult task (check all the grammar/compiler tools). This sounds like a second-system effect: Perl6 is giving up the simple frequent parsing syntax it has, in order to allow people to make more generic complex parsing. The problem is that most people won't have the time to properly code the complex parsing, so those "new" features will be mostly unused. What usually happens in complex parsing, is that people code mostly whatever is enough to parse the few data files they have, but don't test all cases... and then when in production, misparsing occurs often.

Just because it's sounds like a popular good idea doesn't mean it is in the end. Complexity kills the cat in computing.

One of the reasons that lawmakers often "don't speak geek" is that they "speak law" instead. Many of us in the computer world do not realize the inordinate amount of work that these people must go through to get a law degree. One might even say that the profession of law is even more bloated with jargon than our own profession is - a quick look at the infamous Jargon File [warning, 2.2MB link] will prove that. (incidentally, if printed, it's about 785 pages of stuff!)

While I may give the legislators this chip to bargain with, it is taken away just as quickly by telling them that if they are to make laws that govern the fruits of our profession, (by "our profession" I mean programmers, primarily) they must understand it. It is this core point that legislators fail to accept. It is also this core point that lawyers often refuse to accept.

The only solution in this matter is to educate - and for that to happen, those of us who are so quick to judge people who do not intrinsically understand the ways computers work (and lawmakers often understand less about computers than the average bear) must put aside some of that cynicism and try to teach these people enough so that their laws not only are effective, but enforceable.

Note the difference - these people are not your 90 year old grandmas who only use their computers as a glorified typewriter!! Especially in reading some posts here, we are quick to rail away against our legislators because they do not seem to understand the ramifications of their actions. I am not discounting that the mafia-boss style tactics of the MPAA and RIAA, for example, have an effect on our legislators' votes, because they do, but maybe by giving our legislators enough good information about how computers work and how these things can actually be managed, the legislators might actually be able to out-think idiots like Hilary Rosen and Jack Valenti.

Or am I being too optimistic?
--

I'm a big fan of cats, myself. The only problem is when they want to be the center of attention and jump up on they keyboard (or book or whatever else I happen to be holding between me and the rest of the world).

"It is widely grokked that cats have the hacker nature" - The Jargon Files

Call me cynical, but anybody who says "80s music rox" probably isn't old enough to remember "back then." With the obvious exception of the 10% not covered by Sturgeon's Law.

See this link. Or are you the grammar Nazi?

Excellent troll btw. People flock by the half-dozen (so far) and counting !

I thought UNIX's mascot was the cute, cuddly Death Star. Either that, or Dennis Ritchie.

my fisrt kid will be call erik or erika, this way he/she can join the conspiracy

The same goes for people who forward their spam to services like SpamCop--you are only clogging the network even more, please stop.

I think you're just trolling, but in case you aren't, here's the difference:

I go to a fair bit of trouble and expense to maintain my networks. I get to decide what happens with it. Spam is a parasitical use of that network, something I don't want. The reporting of spam is one of the things I do want. If I feel that it's clogging my network, I can stop anytime; I can't do that with spam.

Spam is noise on a data channel.

Uh, no. It's not like spam is some weird radio interference problem or some quantum effect. Real humans write and send every spam. They do it because they think they can make money at it.

This is not an inevitable consequence of the existence of a communication channel. Spam was negligible for many years; it wasn't until around the time of September That Never Ended or maybe the green card spam that I recall getting any. Since then it has grown explosively, so that for many people it outweighs regular mail. Ignoring it in hopes that it will go away or level out is about as smart as ignoring a suppurating wound.

I almost spewed up my iced mocha latté when I read the opening paragraph of the article:

In ancient Troy stood the Palladium, a statue of the goddess Athena. Legend has it that the safety of the city depended on that icon's preservation.

Even someone with the most rudimentary liberal arts education knows what happened to Troy and the Trojans, right? No? Well, here are the relevant parts of Homer's Iliad and Vergil's Aeneid boiled down into one paragraph:

The Greeks went to war against the Trojans because one of their kings' wife, Helen, skipped town to hop in the sack with a Trojan prince. The war went on for about ten years or so with no clear victory in sight for either side. Finally, however, the Greek soldier Odysseus (a.k.a. Ulysses) hatched a clever plan--the Greeks would build a huge, wheeled wooden horse and offer it to the Trojans as a sign of surrender. Unbeknownst to the Trojans, however, Odysseus and a crack team of Greek soldiers would be holed up in the horse's body. Lo and behold, the Trojans accepted the horse and opened the gates to let it in. That night, Odysseus and his posse got down and started kicking some serious Trojan ass from inside the city. In fact, the shrine of Pallas Athena (the Palladium in question) was where the Trojan king Priam and his remaining family members took refuge. But it didn't matter; the Greeks came in and slaughtered them.

Three thousand-odd years later, the term "Trojan horse" has taken on a special meaning in tech jargon. Perhaps whichever marketing dweeb at Microsoft came up with the name "Palladium" for a security product should have paid more attention in that world literature class.

(As a side note, with this story in mind, using the brand name "Trojan" for security tool of a different sort is also ironic.)

I'd wager that the majority of those who follow the herd and say, "VB is an idiot's language," have never even tried VB.

I've tried VB; I used it by client mandate on a 4-month project. I started with only a slight bias, and ended up hating it with a burning passion. I wouldn't say it's an idiot's language, but I would agree that it makes weaker programmers.

Why? Let's ignore VB for a bit and compare Pascal, Perl, and BASIC.

Pascal is a language made for instruction. It's uptight, a bondage and discipline language, forcing you to program in a way that's pretty orderly. Developers who start with it tend to follow those habits later. Perl is neutral; it will allow you to program in a way that's as fussy as Pascal, but it will also let you write utterly perverse code. BASIC, has a weird set of limitations and freedoms that actively train people in bad habits that they will have to unlearn later.

In my experience, VB isn't as bad as BASIC, but it was pretty close. My major complaint is the complaint I have about a lot of Microsoft stuff: on top of a skeleton of early, rushed design (kept for the sake of backwards compatibility) somebody glued multiple layers of marketing's features d'jour, doing so without any particular appreciation for elegance.

A good programmer could spend some time working in VB and live; if they've had some broad exposure, then then won't learn the bad habits that VB allows and the tolerance for ugliness that VB requires. But somebody whose main experience is VB is another story entirely.

I know of one group of former VB developers who are now Java developers. The whole way through they've worked on a large dynamic website for a major financial institution, which they redid in Java a while back. For the most part the site works, but the code brought me to tears.

In trying to help these people (who were all smart, committed, and nice) the main problem was that 90% of them couldn't tell good design from bad, elegant architecture from tangled, or clear code from obtuse. I blame this directly on their years of working with a language whose designers didn't know the difference either.

YHBT. YHL. HAND.

All of which is very cool of them. But not sueing people for writing virtual machines isn't coolness, it's just basic law. Infocom never claimed the exclusive right to implement the Z-machine specification, and probably couldn't have made that claim even if they tried.

Now, what I'd really like is to play is the original Zork. The one that the founders wrote for ITS while students at MIT. No, not "Dungeon," that's an unauthorized port, with an incomplete game and flawed parser.

Once a to-be previous employer was concerned that I might go write an even better application for a competitor (I was lead developer on a project that blew the competition of some 10 other products out of the water -- maybe thanks to that we got a number of military and navy contracts for it as well :-).

There wasn't a problem, as I became a software egnineering consultant and stayed away from that very specialized market segment we were in. I learned the lesson, however. Ever since, I have a clause such as this entered into any new contracts (of course, IANAL):

The non-disclosure agreement remains in effect after the termination of this contract, but does not apply to knowledge, skills, methods and choices of technology that were acquired under this contract.

It's usually not difficult to get in. You can motivate it by simply pointing out that the reason they want to hire you is exactly because of this: you can apply your full register of skills and experience in your new position. The following employer would expect no less.

Killer app

Your wish is my command Anonymous Coward one. See here. For the goatse.cx averse, cut-and-paste: www.tuxedo.org/~esr/writings/sextips/

I mean, renaming a file to a new directory by pointing your finger is fine if you just want to rename one file. But to suggest that this is an improvement over the command line if you've got thousands of files to shuffle around is completely ignoring the computer's ability to do mind-numbing repetitive jobs quickly and accurately. Instead it's insisting that a human interact at every mind-numbing repetitive step. This is not progress, people!

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

This is indeed an excellent read and well worth the time - if you want some other online books which discuss the earlier days of computing and hacker culture try these

Free As In Freedom - Sam Williams - A biography of Richard Stallman and an excellent read for those who would like to understand the man a bit more or even understand how GNU and Open Source actually happen. I reccomend this to even people who dislike RMS (as i did) as you will understand the man from a new perspective

The Cathedral and the Bazzar- Eric Raymond - This book has been condemmed and praised by many and provides an intersting look at open source and the different models of software - worth a read

Underground : Hacking, madness and obsession on the electronic frontier - Sulette Dreyfuss - A great look inside the world of the cracker and very intersting and compelling to read

There are heaps more out there - post them as you find them - BTW if you have a bit of cash to spend i reccomend Hackers by Steven Levy and Fire in the Valley by freiburger and swain for 2 more great books on computer and PC history

Everyone knows bout BSD's failure and imminent demise. As we pore over the history of BS, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Aha! A DNA bogo-sort!

• develop some sexy expressive skill like music or poetry
• Make eye contact.
• Finding common interests is a good thing.
• 
  
  and my personal favorite:
  
  
• It's very easy to touch a woman intimately