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

It reminds me of FTL or teleportation; with every little "advance" physics fanboys crow about how much "closer" we are, whereas I see an ever-refined understanding of why the thing we are looking for is still impossible and the potential loopholes slamming shut.

You should try learning more because you have no idea what you're talking about.

Small-scale quantum computing has been happening for a while now. The only problem now is overcoming physical challenges to scale them up for solving larger-scale problems. And more strides are being made to overcome them all of the time.

FTL is crap because the "things" that are cited as travelling faster than light cannot be used to send information faster than light. How QC reminds you of FTL is beyond me since the situations are completely different.

It wouldn't take a "physics fanboy" (whatever that is) to mod you down. Just someone fond of facts and reason would suffice.

Try "How to Manage Projects" by Hooman Katirai from MIT I've seen this methodology repeatedly outperform the one you find in textbooks. What I like about it is that it is light, and it was born out of hi-tech, but has been applied in a lot of other contexts.

Try "How to Manage Projects" by Hooman Katirai from MIT I've seen this methodology repeatedly outperform the one you find in textbooks. What I like about it is that it is light, and it was born out of hi-tech, but has been applied in a lot of other contexts.

For less than $50 in parts (most of them can sampled for free from friendly parts manufacturers, you can easily hack an iPod shuffle... can it run Linux? Yes. A shot of the reassembly.

and here is the FREE online version:
http://mitpress.mit.edu/sicp/full-text/book/book.h tml

Aww, come on, at that point you might as well mention Al Gore...

There were browsers before Mosaic; only they were text-only. The transition between text-based applications and GUI-based ones is trivial and well-documented; it happened at NCSA, but it might as well have happened in New Zealand, or Germany. At the point Mosaic was created, there were already quite a few sites on the Web, or it would have been useless for Kunz et alii to build a graphical client for it -- there was a rival protocol, Gopher, developed in the US, but it was more complex and seems to have all but died out.

Finally, know that the W3C, which regulates the Web, has its copyright held jointly by three bodies: One is MIT in the US, another is the European ERCIM, and the other is Keio U in Japan. Pretty international, if you ask me.

Upon further reading, I see that it was inspired by the MIT hack. Also, I nominate this story for the "most error-filled /. post" award:

"A group of anonymous cowards (eningeers) has apparently constructed a four story mural of scenes from the SNES Super Mario games. The best part is, they did the whole thing out of Post-It Notes, recreating the wondeful pixellated goodness we expect from Super Mario. The idea for this mural seems to have originated in the Strong Bad email of the same name."

How about this instead:

"A group of anonymous cowards (engineers) has apparently constructed a four story mural of scenes from the NES Super Mario games. The best part is, they did the whole thing out of Post-It Notes, recreating the wonderful pixellated goodness we expect from Super Mario. The idea for this mural seems to have originated from the Strong Bad email-based MIT hack ."

What do the Slashdot "editors" do, again?

Actually, according to the actual page, the inspiration came from these guys. The link is down at the bottom of the page.

The idea for this mural seems to have originated in the Strong Bad email of the same name.

Um, I've seen all the SBemails, and I don't get this reference. There is no SBemail called "mural" or "Post-it". Post-its are used occasionally , and a mural was mentioned once though. There also was a "hack" at MIT involving a SBemail.

Anyone care to explain that reference?

Although the article says it was inspired by a StrongBad email, it was actually inspired by another post-it note creation, that of Trogdor from StrongBad.

It wasn't directly inspired by the Strong Bad Email, but rather inspired by a post-it mural in turn inspired by SB. Here's the Post-it Trogdor!

Well, theres Apple, of course. And Pixar. And the Virginia Tech supercluster, and the majority of genetic research/biotech labs, like the Whitehead Institute, BioGen and Genentech. Then there's Staples corporate headquarters. Those are the ones I know of off the top of my head.

According to this and this
it seems that non-commerical, private copying is non-actionable, irrespective of 106 and 107. IE - downloading, ripping, time/format-shifting, mixing, etc are free and clear, provided I don't step over the "private" and "non-commercial" boundaries.

What say you to that?

(not (eq? a b))

The earliest version of Emacs I can lay my hands on dates from 1992. Searching it for occurrences of "(not (eq" reveals lots of hits. One of them (hanoi.el) is from a file last modified in 1987.

So clause 1 of the patent is not novel, and the idea existed widely in the literature and publicly available information at least 18 years before the patent was filed, and quite possibly as much as 42 years.

Some references found through a quick citesser search:

C. Krick, F. Meyer auf der Heide, H. Räcke, B. Vöcking, M. Westermann: Data Management in Networks: Experimental Evaluation of a Provably Good Strategy. Theory Comput. Syst. 35(2): 217-245 (2002)

http://citeseer.ist.psu.edu/meyeraufderheide99prov ably.html

http://citeseer.csail.mit.edu/krick99data.html

See Intrabody Signalling from the MIT media lab.

So don't pick a language like Java that's changing so fast. Then you don't need a new book every semester. I know it's hard to believe, but Java and C# are not the only programming languages.

I know people who got started programming in college with Pascal, C, C++, Matlab, and Scheme -- the latter being especially good because SICP (an outstanding book) teaches concepts first, then coding.

Java is a bad language for entry courses, anyway. I bet you especially love teaching students "public static void main(String args[])". Do you simply wave your hands and say "Don't try to understand, the computer needs this cryptic incantation to work right", or do you explain visibility, class/instance methods, return values, void, objects, method arguments, and arrays on the first day of class? ...

I do agree that lecture notes are not a textbook. I even had one prof who had his lecture notes cleaned up and typeset (by some grad students), got it published by Springer, and used that as the textbook. Of course, it was the worst CS textbook I'd ever seen -- and that's quite an accomplishment. The "chapters" are all 2 pages long, and there's no depth or overviews or summaries or even interesting writing. (He wasn't a good teacher to begin with, though he seems to be highly regarded in his field, for whatever reason.)

The Maslab Robotics Contest evaluated both Linux and Windows for our robots, and working with Windows was a real pain. Windows Embedded lacked the configurability and features we wanted, and full-blown XP was way too bloated and GUI-dependent.

We stuck with Linux even though it meant passing up potentially lucrative sponsorship.

Here in Boston we have a Nuclear Reactor that is almost in downtown Boston:MIT Reactor
Technically, it's in Cambridge where MIT's campus is, but it is in Greater Boston. Also, seems like some residents in Cambridge ate a little annoyed about it. I can't wait for the big MIT student's prank (or hack) where they fake a meltdown ...

Speaking of hacks my favourite is the police car on top of the dome at MIT, and the Harvard -Yale Game banner prank ...

Here in Boston we have a Nuclear Reactor that is almost in downtown Boston:MIT Reactor
Technically, it's in Cambridge where MIT's campus is, but it is in Greater Boston. Also, seems like some residents in Cambridge ate a little annoyed about it. I can't wait for the big MIT student's prank (or hack) where they fake a meltdown ...

Speaking of hacks my favourite is the police car on top of the dome at MIT, and the Harvard -Yale Game banner prank ...

Here in Boston we have a Nuclear Reactor that is almost in downtown Boston:MIT Reactor
Technically, it's in Cambridge where MIT's campus is, but it is in Greater Boston. Also, seems like some residents in Cambridge ate a little annoyed about it. I can't wait for the big MIT student's prank (or hack) where they fake a meltdown ...

Speaking of hacks my favourite is the police car on top of the dome at MIT, and the Harvard -Yale Game banner prank ...

Here in Boston we have a Nuclear Reactor that is almost in downtown Boston:MIT Reactor
Technically, it's in Cambridge where MIT's campus is, but it is in Greater Boston. Also, seems like some residents in Cambridge ate a little annoyed about it. I can't wait for the big MIT student's prank (or hack) where they fake a meltdown ...

Speaking of hacks my favourite is the police car on top of the dome at MIT, and the Harvard -Yale Game banner prank ...

Hydrogen has no future. You need more energy to create it than you get out of it. Its "energy return on investment" (EROI) is negative. Biodiesel has a positive EROI.

Moreover, as a carrier, hydrogen has all kinds of problems (safety, you need a major overhaul of the entire infrastructure, entirely new cars, etc...).

Hybrid diesel and hybrid biodiesel cars are the only real alternative.

In 2003, MIT's Lab for Energy and the Environment made a study comparing the entire lifecycle for idealized automotive drive systems (internal combustion, hybrids, fuel cells). The results were very clear:
-straight gasoline scores worst of all
-gasoline hybrids score far worse than diesel hybrids
-diesel hybrids are nearly just as good as the best fuel cell systems.

The study didn't include biodiesel in hybrid diesel cars, but any laymen can dedude that it is the technology of the future.

You have to look at the entire lifecycle, when comparing technologies. And hydrogen/fuel cells are not efficient.
MIT's study can be found here (pdf): http://lfee.mit.edu/publications/PDF/LFEE_2003-001 _RP.pdf

No. It means that it took 2^80 "computations" and it now takes 2^69 "computations".
O(2^80) = O(2^69) = O(1). See for example http://mitpress.mit.edu/sicp/full-text/sicp/book/n ode17.html.

little known, but the Secret Service have jurisdiction over counterfeiting crimes

It's not a little known fact amongst people who follow the hacking/cracking/phreaking/carding scene, even loosely. Read the excellent book the hacker crackdown by Bruce Sterling for an informative account of what the SS does (and also does spectacularly wrong).

Chandler:
http://www.osafoundation.org/Chandler_Compelling_V ision.htm

Haystack:
http://haystack.lcs.mit.edu/

Tim Berners-Lee is all about making the web smarter and this mspace and other projects like SIMILE are changing the way we leverage data in smarter ways keep up the good work.

SIMILE is a joint project conducted by the W3C, HP, MIT Libraries, and MIT CSAIL. SIMILE seeks to enhance inter-operability among digital assets, schemata/vocabularies/ontologies, metadata, and services. A key challenge is that the collections which must inter-operate are often distributed across individual, community, and institutional stores. We seek to be able to provide end-user services by drawing upon the assets, schemata/vocabularies/ontologies, and metadata held in such stores.

SIMILE will leverage and extend DSpace, enhancing its support for arbitrary schemata and metadata, primarily though the application of RDF and semantic web techniques. The project also aims to implement a digital asset dissemination architecture based upon web standards. The dissemination architecture will provide a mechanism to add useful "views" to a particular digital artifact (i.e. asset, schema, or metadata instance), and bind those views to consuming services.

Delft

Cornell

MIT

Why call a beamer 'holographic television'?

The significance of this news is hardly that MIT is setting any standard and only those with MIT-envy would be prone to such a mis-reading. What I see this as signaling is a furtherance of the trend which brought Susan Hockfield, a distinguished neuroscientist, to the helm of the institution, not a physicist, EE or mathematician and only coincidentally, not a man. The trend away from being a hardware hackers haven has long been afoot. If you hit their home page today, you will probably see a headline about cancer research...that did not happen overnight.

Actually, that web page was up to date... I skipped right over it.

It is "Course BE."

How could they depart from hallowed tradition? O tempora. O mores. O mens. O manes.

Of course, question that all of want to know is, what Roman numeral did they give to the new course?

I think the highest existing number is Course XXIV, Linguistics and Philosophy, so presumably Biological Engineering is Course XXV... or is it?

This web page,alas, is not up-to-date.

The fact that MIT has not opened a BE major until now does not imply that it is not a world leader on this area. Consider for example , Robert Langer , one of the fathers of Tissue Engineering and the only person alive to be member of the three major american academies (science, engineering, medicine), he has been leading this field for years..only that he has been associated with the chemical engineering department.In MIT are also Linda Griffith , an outstanding female bioengineer.. and Douglas Lauffenburger an authority in this area. Heck!, even the students are creating ways to effectively fight cancer.

The fact that MIT has not opened a BE major until now does not imply that it is not a world leader on this area. Consider for example , Robert Langer , one of the fathers of Tissue Engineering and the only person alive to be member of the three major american academies (science, engineering, medicine), he has been leading this field for years..only that he has been associated with the chemical engineering department.In MIT are also Linda Griffith , an outstanding female bioengineer.. and Douglas Lauffenburger an authority in this area. Heck!, even the students are creating ways to effectively fight cancer.

The fact that MIT has not opened a BE major until now does not imply that it is not a world leader on this area. Consider for example , Robert Langer , one of the fathers of Tissue Engineering and the only person alive to be member of the three major american academies (science, engineering, medicine), he has been leading this field for years..only that he has been associated with the chemical engineering department.In MIT are also Linda Griffith , an outstanding female bioengineer.. and Douglas Lauffenburger an authority in this area. Heck!, even the students are creating ways to effectively fight cancer.

The fact that MIT has not opened a BE major until now does not imply that it is not a world leader on this area. Consider for example , Robert Langer , one of the fathers of Tissue Engineering and the only person alive to be member of the three major american academies (science, engineering, medicine), he has been leading this field for years..only that he has been associated with the chemical engineering department.In MIT are also Linda Griffith , an outstanding female bioengineer.. and Douglas Lauffenburger an authority in this area. Heck!, even the students are creating ways to effectively fight cancer.

RTFA, please. MIT is already a leader in what you call "bioengineering," particularly in interdisciplinary fields integrating biology and engineering. In addition, MIT already has a joint program with Harvard medical school (the Health Sciences and Technology program). The new "biological engineering" field is different in that the tradition view of BE/BME is "engineering applications of biology." MIT wants to rethink this view. From TFA:
However, each established engineering discipline is naturally limited to addressing a certain range of problems within biology that fall within the scope of tools and approaches of that discipline. The fusion of engineering with modern biology, then, requires development of a new discipline of engineering, "Biological Engineering," which brings to bear on biology the appropriate tools and perspectives from chemical, civil, computer, electrical, materials, mechanical, and nuclear engineering in an integrated way. Biological Engineering is not envisioned as replacing the individual efforts, but rather enhancing them by pushing new frontiers.

This quote is the one that made me laugh out loud, and shows that we (meaning the Linux/Slashdot/techie crowd) just aren't getting through to the proper people so that changes can be made. [Note: TT is "The Tech" and JV is "Jack Valenti"]

TT: No, you said four years ago that people under Linux should use one of these licensed players that would be available soon. They're still not available -- it's been four years.
JV: Well why aren't they available? I don't know, because I don't make Linux machines.
Let me put it in my simple terms. If you take something that doesn't belong to you, that's wrong. Number two, if you design your own machine, you can't fuss at people, because you're one of just a few. How many Linux users are there?
TT: About two million.
JV: Well, I can't believe there's not any -- there must be a reason for... Let me find out about that. You bring up an interesting question -- I don't know the answer to that... Well, you're telling me a lot of things I don't know.
TT: Okay. Well, how can we have this dialogue?
JV: Well, we're having it right now. I want to try to find out the point you make on why are there no Linux licensed players. There must be a reason -- there has to be a reason. I don't know.

During all his time presiding over the MPAA, he didn't even realize the enormity of the problem. That sends the message that word justisn't getting out. This case, should Michael Malcolm be successful and gain some ground, may finally allow Linux users to legally play DVD's they bought with their own money.

No article about Kerberos would be complete without a link to one of the more interesting introductions out there:
Designing an Authentication System: a Dialogue in Four Scenes

Furthermore, if I wanted to help my programming career, then I'd learn C++. Why would you reccommend LISP over C++ if your goal is to help me in my programming career?

For the same kinds of reasons that they teach languages like Scheme in universities. What I personally recommend is learning more about the basic principles of programming, which is why I mentioned SICP.

But if you learn a language like Lisp or Scheme properly, you'll be exposed to many of the ideas covered in books like SICP, so learning the language isn't a bad substitute for studying the underlying concepts.

The reason I would recommend doing that over learning C++ is that it provides a foundation for understanding any programming language - it'll be easier to learn and understand C++ afterwards. This has been studied in universities - students who go through the more theoretical introduction to CS concepts using Scheme do better on subsequent courses in Java and C++ than students who start out learning the latter languages (I can dig up references if you care).

The foundational ideas I'm talking about help you to design better programs, even when you're using mainstream languages. To give you some idea of what I'm referring to, I recommend reading The Role of the Study of Programming Languages in the Education of a Programmer (PDF).

One problem Lisp advocates face is, how do you explain to someone that learning Lisp will teach them important things about programming that they don't yet understand? People don't want to believe that, so they respond negatively, and things devolve from there because both sides are human.

My personal experience is that I spent almost 20 years programming in languages like C, C++, Java, and various scripting languages. I developed some successful commercial products in C and C++. But when I read SICP a few years ago, I was intrigued enough to learn more about Scheme, and later some of the more functional languages like ML and OCaml. I only wish I had known about these languages, and the ideas behind them, a long time ago.

• The Complexity of Sliding Block Puzzles and Plank Puzzles
• The Nondeterministic Constraint Logic Model of Computation
• Generalized Rush Hour is PSPACE-complete
• Computational Complexity of Games and Puzzles

There is a sign at the site saying "No Photography Permitted", which as far as I know is legitimate, as any reasonably close site from which a picture could be taken is on private property.

There's nothing they can do to prevent you taking a picture of it from a helicopter, assuming you stay clear of FAA flight regulations. But the developers who own 17-Mile Drive, Pebble Beach, etc., also say that the image is part of their trademark, so any commercial use of the image requires paying a fee.

Of course, there are similar or worse restrictions on photography in other countries.

-ccm

OK. For those of you who are not familiar with Jon "Hannibal" Stokes, he Knows his stuff about CPU architecture and provides a great service to hobbyists and programmers (such as myself, as I do scientific computing).

OK so if you want to understand pipelines and why longer ones are not always better?
http://arstechnica.com/articles/paedia/cpu/pipelin ing-1.ars

No? Well how about caching?
http://arstechnica.com/articles/paedia/cpu/caching .ars

And then there is the Opteron/Athlon64 goodness
http://arstechnica.com/articles/paedia/cpu/amd-ham mer-1.ars

Historical view of the Pentium Architecture?
http://arstechnica.com/articles/paedia/cpu/pentium -1.ars

For more great articles from him (and others)
http://arstechnica.com/paedia/

Also dont forget about MIT open courseware to fill in the gaps...
http://ocw.mit.edu/OcwWeb/Electrical-Engineering-a nd-Computer-Science/6-823Computer-System-Architect ureSpring2002/CourseHome/index.htm

And how can you not have love for
http://slashdot.org/comments.pl?sid=138810&cid=116 17250

Keep up the good work!

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.

http://web.media.mit.edu/~stefanm/TinyProjector/Ti nyProjector.html

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.

MIT's president Susan Hockfield.