Slashdot Mirror

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

Have you used an Alpha workstation? Do you even know anyone who has? You'd think they would have learned something from the failure of Symbolics, and ported to commodity (IA32) hardware. In computing, economies of scale will win every time.

Lisp didn't win because Worse is Better. Lisp has incredible advantages that few people are capable enough to exploit. Everyone else whined and went back to BASIC with curly braces.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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

I would have guessed that if hackerdom had a logo it would be some derivative of this.

The self-certifying filesystem or the cooperative filesystem might do what you want, though I believe they only run on unix platforms. The code is considered to be in the alpha stage, but apparently the maintainers have been using it for a while without losing files. On some platforms SFS (on which CFS is based) has the nasty habit of deadlocking the kernel from time to time. You might want to read their documentation, since this might not be a problem for what you're running on.

SFS

CFS

Intermezzo and Coda both do this, but I don't think there's any windows versions available. There are some Microsoft things available too, but obviously those aren't for linux. NBD (which everyone else has mentioned) isn't distributed, so that's not really what you're looking for.

What you might be able to do is put together a microcosm of Freenet or something like it, running on just your home computers. There may be other Peer-to-Peer solutions available that are faster/more stable. Do some searching on peer-to-peer distributed storage networks. I know of two researchy ones: OceanStore and Chord. Good luck!

It seems as if this oak tool was written by Kretchmar himself: check it out at his page http://web.mit.edu/ktools/www/oak.html

Not really that I've seen. Honestly since coming here (I'm a junior, undergrad, comp sci dept.) I've been kind of disappointed -- there are plenty of intelligent (book smart) people, but there aren't really that many truly talented and passionate hacker types (well, at least not that I've met in like the software engineering class [6.170] or other course 6 [comp sci] classes.) Well, there are a couple, but they are REALLY, uh, eccentric or arrogant. The most "innovative" hacks I've seen are like the freaking bathroom/laundry monitors, and those aren't really that impressive (who gives a shit anyway.)

It's too bad. Mostly everyone is so damn busy with the workload that they rarely have time to pursue cool independent projects in their spare time. Which sucks because one would expect that revolutionary new sociological/technological inventions like Napster (northeastern) or Friendster or even cool hacks like BuddyZoo (caltech) etc would be coming out of MIT but from what I've seen that's sadly not the case because everyone is so stressed and maxed out with work.

-fren

Not really that I've seen. Honestly since coming here (I'm a junior, undergrad, comp sci dept.) I've been kind of disappointed -- there are plenty of intelligent (book smart) people, but there aren't really that many truly talented and passionate hacker types (well, at least not that I've met in like the software engineering class [6.170] or other course 6 [comp sci] classes.) Well, there are a couple, but they are REALLY, uh, eccentric or arrogant. The most "innovative" hacks I've seen are like the freaking bathroom/laundry monitors, and those aren't really that impressive (who gives a shit anyway.)

It's too bad. Mostly everyone is so damn busy with the workload that they rarely have time to pursue cool independent projects in their spare time. Which sucks because one would expect that revolutionary new sociological/technological inventions like Napster (northeastern) or Friendster or even cool hacks like BuddyZoo (caltech) etc would be coming out of MIT but from what I've seen that's sadly not the case because everyone is so stressed and maxed out with work.

-fren

Here is a link to the files referenced in the book: http://web.mit.edu/ktools/

Regards,
Timothy Boyden
Systems Administrator
MIT Department of Facilities

http://hacks.mit.edu/

...can be found here.

Fair warning - the linked-to page contains an applet, so be prepared for the usual "computer freezes for 10 seconds" effect if you're running Windows.

i suspect this violates iswc's reprint policy, but anyway, the paper should be here. this paper doesn't answer your question directly. but current research does, and the answer is simple: the cost of misinformation. if the cue is correct, then leaving it up improves performance more than a subliminal cue can. but computers are imperfect (news flash!). so the memory glasses are also imperfect; sometimes they will get it wrong. (you should already know this about face-recognition technology, which is our primary current working domain.) anyway: if you give somebody an incorrect cue in a readable way, they tend to then give the wrong answer. however, if you give an incorrect cue subliminally, you can at least in some cases still improve their chances of getting the *correct* answer anyway. and subliminal misinformation doesn't interfere with processing the way overt misinformation does. for gorier details, i refer you to the paper.

No, that's not true. X has excellent color management support. It's one of the best things about the design of X. You seem like so many other X critics highly confused about the design of X including the key concepts of an X server and an X application because you continue in your comment by criticising an application better known as xterm, which has absolutely nothing to do with the design of an X server. You are comparing apples and oranges. It is meaningless to compare X applications with X servers. Please read the design documentation for X. People who have not read the design documentation for X, wrongly believe they understand the design just by reading the man pages for X and then wrongly think they can produce valid criticisms of X.

Both the design of X and the implementation in XFree86 provide a very flexible and powerful color model based on color science. Here is not the right place for a tutorial on color science. Please read the excellent book by G.Wyszecki and W.S.Stiles, "Color Science: Concepts and Methods, Quantitative Data and Formulas", 2nd edition, 1982, published by Wiley, New York. Only after you are confident you have understood the theory of color science, please then read the X design document from "Chapter 6: Color Management Functions [in X]"

You are again wrong and confused in your criticism of xterm's color management. xterm like any X application built on Xlib/Xaw/Xt has the usual excellent color management support. You just don't understand how to use it. Read the X documentation for how to specify colors in a color space and how to specify a calibration for a color device. Also, you appear to be hopelessly confused about the differences between "visuals" and "colormaps" in X. Read the X design documents.

• "X *does* have a higher latency than Windows (partly due to serialization of commands and partly due to the context-switch requirement)".

This is untrue. Serialisation and context-switching have insignificant effects on the speed of a locally displayed application. Did you really read my post? How do you know serialisation and context-switching are to blame for alleged high latency? Did you measure anything? Did you recompile X with profiling enabled and do a breakdown of the profiling results component by component? Properly written X applications running on a local X display can usually run as fast as MS-Windows applications. Amazingly some 2d graphics operations are faster in X than in some versions of MS-Windows. Some X applications would benefit from optimised graphics drivers which are only available for MS-Windows. XFree86 does not have optimised graphics drivers because the graphics card manufacturers have not provided programming information for their products. However, properly written X applications running on a local X display can usually run as fast as MS-Windows applications. Unfortunately, many toolkit libraries are not written to use X very well.

No, that's not true. X has excellent color management support. It's one of the best things about the design of X. You seem like so many other X critics highly confused about the design of X including the key concepts of an X server and an X application because you continue in your comment by criticising an application better known as xterm, which has absolutely nothing to do with the design of an X server. You are comparing apples and oranges. It is meaningless to compare X applications with X servers. Please read the design documentation for X. People who have not read the design documentation for X, wrongly believe they understand the design just by reading the man pages for X and then wrongly think they can produce valid criticisms of X.

Both the design of X and the implementation in XFree86 provide a very flexible and powerful color model based on color science. Here is not the right place for a tutorial on color science. Please read the excellent book by G.Wyszecki and W.S.Stiles, "Color Science: Concepts and Methods, Quantitative Data and Formulas", 2nd edition, 1982, published by Wiley, New York. Only after you are confident you have understood the theory of color science, please then read the X design document from "Chapter 6: Color Management Functions [in X]"

You are again wrong and confused in your criticism of xterm's color management. xterm like any X application built on Xlib/Xaw/Xt has the usual excellent color management support. You just don't understand how to use it. Read the X documentation for how to specify colors in a color space and how to specify a calibration for a color device. Also, you appear to be hopelessly confused about the differences between "visuals" and "colormaps" in X. Read the X design documents.

• "X *does* have a higher latency than Windows (partly due to serialization of commands and partly due to the context-switch requirement)".

This is untrue. Serialisation and context-switching have insignificant effects on the speed of a locally displayed application. Did you really read my post? How do you know serialisation and context-switching are to blame for alleged high latency? Did you measure anything? Did you recompile X with profiling enabled and do a breakdown of the profiling results component by component? Properly written X applications running on a local X display can usually run as fast as MS-Windows applications. Amazingly some 2d graphics operations are faster in X than in some versions of MS-Windows. Some X applications would benefit from optimised graphics drivers which are only available for MS-Windows. XFree86 does not have optimised graphics drivers because the graphics card manufacturers have not provided programming information for their products. However, properly written X applications running on a local X display can usually run as fast as MS-Windows applications. Unfortunately, many toolkit libraries are not written to use X very well.

In case anyone else wants to read some of the other coverage....

MIT Develops Legal Music-Sharing Via Cable TV

MIT students have developed a music on demand file-sharing system that uses the analog campus cable TV system to bypass the Internet and digital distribution (Google link). This takes advantage of the relatively less-restrictive licensing that the recording industry makes available to radio stations and others for analog transmission. The system, called the Libraries Access to Music Project and dubbed miTunes, is backed by MIT, funded by Microsoft iCampus and will give campus access to 3,500 CDs. More at USA Today, Boston.com and AP / Detroit News.

In case anyone else wants to read some of the other coverage....

MIT Develops Legal Music-Sharing Via Cable TV

MIT students have developed a music on demand file-sharing system that uses the analog campus cable TV system to bypass the Internet and digital distribution (Google link). This takes advantage of the relatively less-restrictive licensing that the recording industry makes available to radio stations and others for analog transmission. The system, called the Libraries Access to Music Project and dubbed miTunes, is backed by MIT, funded by Microsoft iCampus and will give campus access to 3,500 CDs. More at USA Today, Boston.com and AP / Detroit News.

In case anyone else wants to read some of the other coverage....

MIT Develops Legal Music-Sharing Via Cable TV

MIT students have developed a music on demand file-sharing system that uses the analog campus cable TV system to bypass the Internet and digital distribution (Google link). This takes advantage of the relatively less-restrictive licensing that the recording industry makes available to radio stations and others for analog transmission. The system, called the Libraries Access to Music Project and dubbed miTunes, is backed by MIT, funded by Microsoft iCampus and will give campus access to 3,500 CDs. More at USA Today, Boston.com and AP / Detroit News.

In case anyone else wants to read some of the other coverage....

MIT Develops Legal Music-Sharing Via Cable TV

MIT students have developed a music on demand file-sharing system that uses the analog campus cable TV system to bypass the Internet and digital distribution (Google link). This takes advantage of the relatively less-restrictive licensing that the recording industry makes available to radio stations and others for analog transmission. The system, called the Libraries Access to Music Project and dubbed miTunes, is backed by MIT, funded by Microsoft iCampus and will give campus access to 3,500 CDs. More at USA Today, Boston.com and AP / Detroit News.

No, But, never fear, someone else at MIT built this robotic DJ that can: DJ I Robot

DJ I ROBOT uses a PC, several micro-controllers, and an advanced "motion control" system to automatically mix, scratch, and search a pair of custom vinyl records on the robotic phonographs.

And, er, to annoyingly reply to myself, this is why 'edutainment' is a good sign of active Microsoft involvement. Randy Hinrichs, Microsoft Research's Group Research Manager for Learning Science and Technology, is a major believer in the use of 'learning through play'. The LAMP project, on the other hand, is just a student project, and therefore supported to the tune of $30,000. I suspect Microsoft had veto power on it, though. Um.

Off now.

And, er, to annoyingly reply to myself, this is why 'edutainment' is a good sign of active Microsoft involvement. Randy Hinrichs, Microsoft Research's Group Research Manager for Learning Science and Technology, is a major believer in the use of 'learning through play'. The LAMP project, on the other hand, is just a student project, and therefore supported to the tune of $30,000. I suspect Microsoft had veto power on it, though. Um.

Off now.

Microsoft are funding a bunch of campus style software and such. iCampus is one example of this, a large MIT research thingy, which covers funding for all sorts of projects (I seem to recall there being, for example, a student shuttle-bus which reports its location via gps to the web...). It's actually fairly fragmented; like most large lumps of university money it has been taken up by people as and when rather than as part of a Grand Plan.

Well, no matter how it appears, certainly if you ask MS or MIT they will tell you there is a grand plan - for sure. But relax, Microsoft have been throwing funding at universities for 'wired campus' style projects on a regular basis as far as I know, and as yet it has met with limited success from their perspective. They would love to own the education market, of course. They just haven't got a decent grip on it yet, and not for lack of trying.

You have to realise that research and industrial funding is an uneasy alliance at best. Good researchers attract funding whilst controlling the conditions under which it is given; bad researchers accept funding that comes with strings. In this case, MIT are, I suspect, in the driver's seat. This makes them relatively unusual; many researchers are rather naive and, on receipt of a few flattering comments and hints of 'long term collaborations', 'special relationships' or similar, will immediately go for it no matter what the conditions. Some even believe that they are the ones doing the 'using'. Having worked for one of these types, I can assure you that these researchers are wrong (do I sound disillusioned? Oh well).

It's worth keeping your eyes open, anyway; if you see anything using tablet PCs, MS DRM, heavy use of .NET, and 'Learning through [demonstration/play]' with [insert microsoft technologies], then you can more or less assume that the researcher is a Microsoft prostitute of some kind. But this particular project seems too 'free' to be particularly blessed by MS.

Don't know if that helps.

Am I the only one who thinks that, at this very moment, a RIAA lawyer will be drafting notes that use your comment as the centrepiece for a legal motion to get this MIT project shut down?

This is not some random student project. MIT has intellectual property lawyers.

innovative legitimate music-buying options

Music need not be purchased to be heard. MIT has paid ASCAP et al for blanket transmission licenses, like radio stations use. (BTW, the campus radio station, WMBR, used to be called the "Tech Broadcasting System" or WTBS, until some guy in Atlanta bought the call letters from them...now it stands for Walker Memorial Basement Radio, for its location.)

See their FAQ, particularly the questions "Is this really legal? How?" and "Did you have lawyers look at this?"

Quote at the bottom of the page:
LAMP is funded by the iCampus Alliance (MIT/Microsoft Research)

http://lamp.mit.edu

Okay, slashdot... does Microsoft get any props here?

(oh, sh!t, there goes my Karma.)

Davak

Quoth the author:

These "memory glasses" were also discussed at the recent International Symposium on Wearable Computers.

Lessee here . . . Symposium, literally translated from Greek, means drinking party. The Platonic dialogue of the same name was, in fact, a drinking party.

Glasses that flash messages in someone's eyes immediately following a drinking party . . . sounds like the makings of a barf-o-rama to me.

Personally I'd find it great if they could add voice recognition to it. One of my biggest weaknesses is remembering new names, especially when I'm introduced to a whole bunch of people one after the other. (I remember a job interview where I was taken on a tour of the building, and met around 10 people in 15 minutes. Then near the end of the tour, one of those people joined us for the rest of the interview, and I was trying desperately to remember which one he was :) ). Being able to have it dynamically associate people's faces with names and display a prompt would be a huge assist.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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

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 just an example of the "Carnival Booth" algorithm for identifying which of your terrorist buddies are on the watch list.. and which are NOT. Then the guy not on the watch list can safely board a blame, knowing he will probably not be searched.

"Carnival Booth: An Algorithm for Defeating the Computer-Assisted Passenger Screening System"

Uh... laser cutters have been around for years (more like decades) and are limited in what they can cut. Waterjet cutters on the other hand can cut metal (titanium even!).

Check here (MIT) for a few resources on laser cutting and the feasibility of producing laser cutters at a cost comparable to injet printers.

Not a big deal... just know that it's not the first laser cutter.

Hey, now there's an idea. Oil-eating bacteria already exist, so why don't we pump some of those little fuckers down the oil wells to speed things along? Exponential growth and an abundant food supply ought to take care of the rest.

Anyone have an idea how to get rid of the coal?

GATOR IS SPYWARE!

I don't think you quite understand the scale of what we're dealing with here. IIRC, IPv6 has a large enough address space to give every atom in the known universe its own IP address, and then some.

...they paid about $30 per copy.

Or, following the link directly on the page, then could essentially have the book for free.

I refer my students to addall.com. Instead of paying nearly $100 for one of the best CS books ever, they paid about $30 per copy. I hope the authors still get their share.

MIT has been working on an even safer method for years: Pebble Bed reactors. The idea is: seal the uranium in bocci-ball sized graphite balls (uranium reaction won't get hot enough to melt the graphite balls). to stop the reaction roll the balls away from each other. when the fuel is spent, the U is sealed in graphite.

http://web.mit.edu/pebble-bed/

Also, whenever people invoke Three MIle Island, I'm always obliged to point out that ZERO nuclear waste was released during the accident. It was all completely contained. Most people think it was like Chernobyl, but the fact is: the safety standards worked for 3-mile.

We've been running a contest that uses similar hardware. Take a look at http://maslab.lcs.mit.edu. Our platform uses a slow (but more power-efficient than the epia) Natsemi GX-1 (300MHz x86). We've built a custom robot controller board (4 motor drivers, support for quad-phase optical encoders, analog and digital i/o, etc). We're not mass-producing them, but should have a few extras at the end of January. Should be much cheaper than the $500 those folks talk about.

We use the CPU power to do vision processing and allow autonomous operation. The versatility of the ORC board allows teams to build really cool robots.

We used Linux last year and this year we're trying Windows XP Embedded with C#.

If you're in the Boston area, come check us out at the end of January!

We've been running a contest that uses similar hardware. Take a look at http://maslab.lcs.mit.edu. Our platform uses a slow (but more power-efficient than the epia) Natsemi GX-1 (300MHz x86). We've built a custom robot controller board (4 motor drivers, support for quad-phase optical encoders, analog and digital i/o, etc). We're not mass-producing them, but should have a few extras at the end of January. Should be much cheaper than the $500 those folks talk about.

We use the CPU power to do vision processing and allow autonomous operation. The versatility of the ORC board allows teams to build really cool robots.

We used Linux last year and this year we're trying Windows XP Embedded with C#.

If you're in the Boston area, come check us out at the end of January!

In those days, many people used Unix and VMS or other big systems and had a good idea of the merits of both and the book The Unix Haters Handbook. It is humorous but it makes some valid points. Perhaps it wasn't up to date with all Unix versions at the time, and in the same way can we expect Mr Raymond to be aware of all the goodness lurking somewhere within the Windows code base (there must be some!).

Perhaps Raymond should have reused but praphrased that quote from the forward of The Unix Haters Handbook:

It might be that once in a while Microsoft allows a programmer to fix a bug rather than apply for a patent so some of the superficial problems might not appear in a particular version of Windows.

In the end Raymond is kind of right. Microsoft themselves are having problems getting everyone to upgrade. How many copies of 95 and 98 are out there still? The NT kernel is kind of cool but not everyone has that kind of horsepower.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

What We Can Learn from BSD
By Chinese Karma Whore, Version 1.0

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.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

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