Slashdot Mirror
Domain: rice.edu
Stories and comments across the archive that link to rice.edu.
Comments · 754
-
Not quite right
That's not quite true. The signatory nations of the Antarctic Treaty have agreed that noonee owns the continent or portions of it. A few of the countries actually do have staked claims, but they don't actually defend them or reasonably expect anyone else to. See http://tea.rice.edu/deaton/12.2.2004.html for more info.
-
in the old days, great programmers used to say...
"We should forget about small efficiencies, say about 97% of the time:
I loved and still get a kick out of squeezing a function into the fewest bytes or cpu cycles possible...I also like math puzzles. But it would be a mistake to romanticize the "good old days" when memory was expensive and cpu's were both slow and costly. Tweaking and whittling code at the instruction level would take you forever to write systems as complex as sit on the average user's desk these days.
premature optimization is the root of all evil." - Donald Knuth
"Programming can be fun, so can cryptography; however
they should not be combined." - Kreitzberg and Shneiderman
"More computing sins are committed in the name
of efficiency (without necessarily achieving it)
than for any other single reason - including
blind stupidity." - W.A. Wulf
The real lessons of computer era are not Moores' law of transistor density but Gate's law of cyber-guzzling by dense users which I now coin:"processors are never so fast or memory so big that the next generation of customers can't be convinced to buy software that strains the system"
In the long run, marketing pull always gets ahead of engineering push...just look at DEC. When I joined DEC in 77, those old programming proverbs were taped like gospel to the cubicles where the compiler writers worked. They seem forgotten but I found them here and here. In that year, nearly any system or periperal DEC dreamed up found willing scientific and engineering customers in labs. By '84, the earliest PC's were all the buzz but DEC's offerings in that area were ignored by the market. The imagination and genius of engineers and scientists is generally sufficient to awe the public initially. But if the technology has gratifying uses and economic benefits, markets absorb magic and make it an ordinary commodity and finally a staple for which improvement is always wanted.
And by the way, since when is this topic news? I hope it isn't just because DDJ mentioned it. I don't feel like dredging up pointers to the bezillion pages on the matter but there has been academic and industry handwringing about the inevitable limitations of transistor size and speed for a decade. OK, one URL, thats all you get! read pg 62 for consice four year old description of the issue [and how carbon nanotubes are going to save us]. The predictions of the exact day when progress stops were always a bit vague and hedged with hopeful notes about gallinium and going to 3-d circuits...all that is really happening is that, having seen the wall a long ways off, chip makers aren't going to smack into it head on with an abrupt cesation of speed increases but veer off in new directions and so only slow down the increases. -
Adieu BSD
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. -
Re:Bram is coolInteresting idea, but it's essentially a reputation system, which opens you up to a Sybil attack. For example, a leech could run two clients, one of which provides fake upload reports for the other, increasing the second client's priority. Even if the tracker checks that the reporter and the reportee have different IP addresses, two leeches can provide fake reports for one another.
BitTorrent currently avoids this kind of attack because it has no system-wide notion of identity - each peer measures the actual performance of its neighbours, instead of trying to predict performance based on out-of-date, possibly falsified, second-hand reports.
-
Lessons from the Ashes
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. -
Ha! Eat THAT one, Time Magazine!
An article on blogging, as contained in the Dec. 27th issue of 'Time' magazine, made a reference to ham radio as a "faintly embarassing" hobby.
I wonder if the operators of that station find it so? Especially since they're providing a most valuable service that the (supposedly) much tougher public infrastructure failed to?
The same thing happened with the Nisqually Quake in 2001. Within minutes after the shocks subsided, landline phones and cellphone networks alike were overwhelmed into non-functionality.
Guess what stayed up and working through the whole affair? Yep. Ham radio VHF and UHF repeaters, and HF nets.
-
Hindenburg?
I imagine that such an aluminum-based paint would, shall we say, violate building fire codes.
-
A glacier is much more likelyhttp://www.glacier.rice.edu/land/5_antarcticicesh
e etlast.htmlDuring the period from about 120,000 years ago to 20,000 years ago, the Antarctic Ice Sheet grew much larger than it is today. This was the last glacial phase. Since about 20,000 years ago, the ice sheet has been retreating to its present size. This marks the present interglacial phase of the cycle. A similar change occurred in the Northern Hemisphere, with ice sheets expanding across large areas of North America, Asia, and Europe. Shifts in climatic conditions occur across the globe accompany these cycles. This cycle of advance and retreat of the ice sheets in the Northern and Southern hemispheres has occurred many times in the past and will occur again in the future.
All but small remnants of the continental ice sheets retreated from North America thousands of years ago. Although it may appear that the Ice Age has ended, many scientists argue that our present relatively warm period represents but a brief interlude and that the glaciers may again advance in the future.
A glacier covering much North America, Europe, and Asia seems like a more serious (and more likely) problem than a mega tsunami. -
Lessons from the Ashes
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. -
How did parent get modded "Insightful"?
This is a troll if I ever saw one. I usually don't respond to trolls, but when they get modded "+4 Insightful", I have to.
Zope is a nice application server, but not exactly fast. It has nice abstractions like acquisition to do very complex web applications with only a few lines of code.
Zope is among the fastest application servers out there, and certainly scales better than any Java-based app server I've seen due to its native support for ZEO (server clustering). Boston.com runs a huge Zope cluster on the back-end, and CBS New York does the same. This is pure FUD.
Plone adds more layers of abstraction and makes the whole even slower. It is almost as if the plone designers read a book about advanced OO concepts and wanted to implement every single concept they just learned about in a single application.
Oh, come on. We haven't added any unnecessary abstractions - we have mostly added glue code to tie together other pieces of Zope and CMF code in a better way, and put a standards-compliant, user-friendly UI on it.
Abstractions are your friend. If you want to know everything about how things work, the Python code is available for you to read. Trust me, you don't want to have to think about every single detail about what's going on underneath the hood at all times.
The goal of Plone is to make things Just Work, and from the feedback we get from our users, we have succeeded in this.
The only way to get decent performance out of a plone/zope setup is to put a squid proxy in front of it, but that causes a lot of problems with dynamic content.
The only way to get decent performance on *any* web-based application server system is to put a cache in front. Apache and Squid work well, and we have giant Plone sites out there with Squid in front and dynamic cache invalidation. And what are the "problems with dynamic content" you are referring to? Both Apache and Squid handle expiry dates for web pages and cache invalidation just fine.
Plone is distributed for development, not deployment. It's common knowledge among all developers that you have to spend some time doing proper caching setups for bigger and more complex sites - but that's the case for every system out there.
The documentation is also horrible. If you are lucky it is just incomplete and out of date, but in most cases there is none at all.
There are three books on it out now, and the best one so far wasn't reviewed here. Andy McKay's book shows you most of what you want to know, is available for free (under a Creative Commons license) online. How is that "horrible"?
If you want to do a small application with less than one hit per second, go ahead. But for a big site: forget it.
It's actually the other way around. If you want to do a small site, Plone's workflow support, schema-based content type definitions, metadata engine, reference support, superior multilingual support and server scalability makes it a tad too complex for small projects, and we usually recommend other systems for people who just want a blog or a forum system.
For bigger organizations like Oxfam America, Credit Muncipal de Paris, Rice University's Connextion project, Clear Channel's racing sites and the USDA Forest Service - you *need* a proper tool to keep the content up-to-date.
Plone is that tool. Take your trolling elsewhere.
Disclaimer: I'm one of Plone's founders, so I'm biased. The claims put forth by the parent poster have nothing to do with reality, though.
-
A Hard Lesson
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. 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. -
Straight from the horse's mouth
Here's Rice's security lab post about the flaw: clicky
-
Re:Professor Wallach taking all the credit?
Check out our webpage . The tone of the article is not Dan's doing. He has been more than generous with the credit, and was involved with our project and of invaluable assistance the entire time.
-
Re:No update here!?
This is unnecessary. You can disable the integration option, which is a minor feature anyway. Check our webpage
-
Re:How it's probably done
Not quite. Again, I recomend checking the webpage , but since I know most of you won't (I wouldn't)... Go install google desktop. Go to google.com. Do a search. Notice it says 'local results found:' and includes small snippets of the local results. We can get those snippets for arbitrary searches by making our own requests to Google. The local data is integrated after the reponse comes back from Google, but before we get it. The only tricky bit is making the requests to google.com through an applet, since the applet is not allowed to connect to google.com, only the originating host. Luckily we can run a web proxy on our originating host and still get the integration results. We don't even have to return the right google.com search result... we can just replay an old page.
-
How it works
A web page on the attack is http://seclab.cs.rice.edu/ which also links to a technical report.
The way it works is actually pretty simple. What happens normally is that the toolbar watches your outgoing and incoming web connections. When you make a Google query, it detects that and does a local search of its index of your disk. When the results come back from Google, it mixes in the results from the web with the results from your disk. This design is to protect your privacy.
The attack is for a malicious site to download a Java applet to your system. This applet does a Google query (via the malicious site as a proxy, to defeat applet sandboxing), and then reads the results which come back. When the results get back to the applet they have gone through the Google toolbar and gotten the local disk results integrated. The applet then sends the data to the malicious site, and presto, it knows a lot about the contents of your disk. -
How it works
A web page on the attack is http://seclab.cs.rice.edu/ which also links to a technical report.
The way it works is actually pretty simple. What happens normally is that the toolbar watches your outgoing and incoming web connections. When you make a Google query, it detects that and does a local search of its index of your disk. When the results come back from Google, it mixes in the results from the web with the results from your disk. This design is to protect your privacy.
The attack is for a malicious site to download a Java applet to your system. This applet does a Google query (via the malicious site as a proxy, to defeat applet sandboxing), and then reads the results which come back. When the results get back to the applet they have gone through the Google toolbar and gotten the local disk results integrated. The applet then sends the data to the malicious site, and presto, it knows a lot about the contents of your disk. -
Re:No, it is a dumb explaination...
Google never sends the data to an external host. check the report and explanation The composition flaw is in the integration of external, possibly active, web page with local data intended to be integrated only into static pages. The security policies for active web pages don't take in account the possiblity of data intended only for the local computer.
-
Re:From the article (I actually read it this time)
Wow, I'm famous enought that people are getting karma for knowing me.
As a note, you can find a tech report on our webpage at http://seclab.cs.rice.edu -
Better link
From the researchers themselves, rather than the NYT's garbled take on it.
-
Lamentations of the Dead
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. -
A Lesson From The Ashes
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. -
Lessons from the Ashes
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. -
Re:Student Life Website
I'm a bit curious about how this is completely in-house code... see, my college's website at Rice university has the exact same looking portal system: http://www.brown.rice.edu
How is it that both sites are nearly identical in design, yet one of them is completely "in-house"? -
Re:#101: See the shock wave on an airplane wing
One of the coolist things I ever saw with my own eyes was an F-18 at an airshow with the conical vapor/shockwave going off the back. here is a picture.
My wife was not nearly as impressad as I was -
Object Lesson
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. -
Re:Thats great
I want my Internet sense.
All I need is input (RTFA) and output.... oh, and, maybe Gaim and Mozilla plugins, and BitchX scripts.
Now, if I could throw a laptop with 802.11 and packet radio on my back, I'd be good from anywhere, until the battery died.
A laptop with two battery compartments that lets you hot-swap batteries without losing power could solve that, if I had an infinite supply of batteries.
Infinite supplies aren't too hard to come by. The backpack could charge itself from the sun and, with a crystal-radio-like method, from nearby radio sources (including power lines). And for those cold, gray days, use a many-stage thermocouple between the cold air and your warm body.
That's probably not enough power, though, if you're indoors. So, you build a little robot (Roomba-style?) to dispatch with empty batteries to charge them and come back full. The only problem is that people might notice your robot, and, err, complain about stealing power, but, that can be fixed, especially if the robot lays low, doesn't move when there's a lot of people around, sticks to dark rooms and hallways when possible, hugs walls, and moves quietly (noise cancellation helps, too). It just needs to come back when called (map memory, path-finding algorithms, homing mechanism).
Who has lots of money and free time, and feels like building something fun for me to wear?
It doesn't even need to be a backpack. -
Rice did it first!
The folks at Rice University did this first. (2-Sep-2004)
-
The article
The link is kind of crappy. It's sort of hype-ish without real science, which coincidentally is the name of the journal whose latest issue is mentioned in the link as containing the paper describing the breakthrough. What a sentence that was...anyways, here you go. You should be able to read it even if you aren't at a subscribing institution since it's the latest issue.
It's worth noting that UTD has only been hard at work in CNT research for a few years. I was there in 2002 when the NanoTech institute was still being built. They had a bunch of Dells sitting outside the building with no one watching...but I guess they didn't worry. I mean, who steals a Dell?
Other good links, mostly culled from the above Science article:
Baughman's summary of nanotube work
Smalley (the Nobel prize winner) and his CNT work:: He invented the HiPCO process for large-scale development of CNT's...from what I gather, fiber-spinning like the UTD method is a direct competitor.
A really good (and 46 page!) discussion of nanotube work
Strong Bad, in case you get tired of science. -
The article
The link is kind of crappy. It's sort of hype-ish without real science, which coincidentally is the name of the journal whose latest issue is mentioned in the link as containing the paper describing the breakthrough. What a sentence that was...anyways, here you go. You should be able to read it even if you aren't at a subscribing institution since it's the latest issue.
It's worth noting that UTD has only been hard at work in CNT research for a few years. I was there in 2002 when the NanoTech institute was still being built. They had a bunch of Dells sitting outside the building with no one watching...but I guess they didn't worry. I mean, who steals a Dell?
Other good links, mostly culled from the above Science article:
Baughman's summary of nanotube work
Smalley (the Nobel prize winner) and his CNT work:: He invented the HiPCO process for large-scale development of CNT's...from what I gather, fiber-spinning like the UTD method is a direct competitor.
A really good (and 46 page!) discussion of nanotube work
Strong Bad, in case you get tired of science. -
Re:SED - the new 'killer app' in TV and monitors?
-
Get rich selling arms to both sides!Time to buy stock in Garvey Unlimited!
Stupid gimpy fish! Oh yeah?!! Whatta ya goin' ta do aboot it?!!! -
HCL Principles
More about HCL Principles can be found here
-
Re:Quite the opposite
Yes, but summer in Antarctica is still freaking cold. Winter in Chicago is warmer than summer in Antarctica. An average summer temp of 0C at the coast and around -30 on the plateau. Where is Dome C? On the plateau.
-
Re:Course at Rice
Okay. I know that was an off-hand comment, so I'll forgive you. But next, time perhaps you should check the syllabus before you go about criticizing what was truly an excellent course. One of the best CS class I took at Rice, actually (just behind Keith Cooper's compiler construction class.)
You'll note that the very first substantial lecture is on ethics. -
Re:Course at Rice
Okay. I know that was an off-hand comment, so I'll forgive you. But next, time perhaps you should check the syllabus before you go about criticizing what was truly an excellent course. One of the best CS class I took at Rice, actually (just behind Keith Cooper's compiler construction class.)
You'll note that the very first substantial lecture is on ethics. -
Hack-a-vote!
Yep. I was in the course, actually.
For those of you too lazy to ready the webpage: the assignment was in three parts. First, given a simple Java-based voting terminal (HackAVote), hack it (inconspicuously) to bias an election to serve your own nefarious purposes. Second, given another group's hacked terminal, how many of their hacks could you find without the source code? With the source code? Finally, design a provably secure algorithm (using cryptyc) for communication between the smart card and voting terminal, and an appropriate smart-card distribution scheme.
My experiences: hiding bugs is easy (duh). Finding bugs in black-box testing is hard (duh). Finding them with source code is substantially easier, but still non-trivial. Finally, getting it right, while not impossible, is non-trivial! There are a *lot* of cases to consider (nefarious poll workers, smart-card hackers, people with access to a machine that "fell off the back of a truck", etc.)
Dan wrote a paper about the experience. It's worth a quick read. Finally, his homepage is rather amusing, beyond the typical nerdly computer-science professor stuff. -
Hack-a-vote!
Yep. I was in the course, actually.
For those of you too lazy to ready the webpage: the assignment was in three parts. First, given a simple Java-based voting terminal (HackAVote), hack it (inconspicuously) to bias an election to serve your own nefarious purposes. Second, given another group's hacked terminal, how many of their hacks could you find without the source code? With the source code? Finally, design a provably secure algorithm (using cryptyc) for communication between the smart card and voting terminal, and an appropriate smart-card distribution scheme.
My experiences: hiding bugs is easy (duh). Finding bugs in black-box testing is hard (duh). Finding them with source code is substantially easier, but still non-trivial. Finally, getting it right, while not impossible, is non-trivial! There are a *lot* of cases to consider (nefarious poll workers, smart-card hackers, people with access to a machine that "fell off the back of a truck", etc.)
Dan wrote a paper about the experience. It's worth a quick read. Finally, his homepage is rather amusing, beyond the typical nerdly computer-science professor stuff. -
Course at Rice
Dan Wallach is teaching a course at Rice that, I think, includes this sort of challenge.
-
library pictures?
Hey, but the cops do stop you from taking pictures of the library...
(Rice, USCD... close enough) Rice University. -
a little more info...
since the link seems to be broken I quickly googled the topic...
apparently OMGN has a small blurb on the topic and it says to email Dr. Dholakia if you are interested.
-
Electronic Voting at Baker Instititute in Houston
An upcoming event will discuss this issue in depth.
Technology, Society, and Public Policy Lecture Series:
Electronic Voting and Accountable Voting Systems
Panel Discusion
Sept. 16, 2004 at 6:00 PM
http://bakerinstitute.org/Resource/UpEvents.htm
cosponsored by the Computer and Information Technology Institute at Rice University.
http://dacnet.rice.edu/depts/citi/calendar/index.c fm?EventRecord=4566
The event will be webcast by the University at
http://www.rice.edu/webcast -
Electronic Voting at Baker Instititute in Houston
An upcoming event will discuss this issue in depth.
Technology, Society, and Public Policy Lecture Series:
Electronic Voting and Accountable Voting Systems
Panel Discusion
Sept. 16, 2004 at 6:00 PM
http://bakerinstitute.org/Resource/UpEvents.htm
cosponsored by the Computer and Information Technology Institute at Rice University.
http://dacnet.rice.edu/depts/citi/calendar/index.c fm?EventRecord=4566
The event will be webcast by the University at
http://www.rice.edu/webcast -
Lessons learned too lateWhat We Can Learn From BSD
By Chinese Karma Whore, Version 1.0Everyone 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. -
Lessons from the Ashes
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. -
Reading the ashes
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. -
Info on these drivers for FreeBSD
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. -
Gender breakdown studies?So where are the gender breakdown studies?
- UNESCO/GAB Toolkit on Gender Indicators in Engineering, Science and Technology
- Comp Sci and Women (Yale)
- Gender and the Workplace
- Gender and Innovation Stats - DTI
It would also be really interesting to see what can be found in the Engineering Trends databases -
Re:Worthless info.
Yes, but I was thinking of a visual diagram, like this one
-
Secrets of the Dead
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.
