Slashdot Mirror

Good point. In a similar vein there is also MIT's Haystack (although the requirements are terrifying to behold).

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

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

The main problem in the USA isn't how we gather votes, although there are problems in some states (Florida). There is a more fundamental problem in that we aren't using the right voting mechanism. In the US, we use plurality voting -- a.k.a "first across the line" -- to determine who wins an election. This means that a candidate for whom only 30% of the people voted can win an election simply because there was no other single candidate with more votes.

This has a number of problems, but they can all be summed up by saying that plurality is one of the least fair, if not the least fair, way of determining the winner of a democratic election that you can get. Consider:

• Say 40% of the people vote for candidate A
• 35% of the people want candidate B
• 25% want candidate C

This situation encourages strategic voting; that is to say, voters for C have to decide whether they want to vote honestly, for C, or whether they should vote for B just to make that they don't get their least favorite candidate, A.

This is why we only have two parties in the US, and why -- despite the large number of Greens and Libertarians, neither party has a chance of winning. We don't even know what percentage of the US population is Green or Libertarian (or anything else, for that matter) because they aren't voting honestly. They're voting for the lesser of two evils. This system practically guarantees alienation of the largest number of people -- the majority ends up with a candidate they don't want, unless they lie when voting and vote for the candidate that they dislike the least who also has the best chance of winning.

There are voting mechanisms which allow people to vote their true opinion without being alienated. The most popular are Condorcet -- complex, but the most fair; Approval Voting -- not as fair as Condorcet, but much simpler, and can be implemented with existing voting technology; and Instant Runoff -- less fair than approval, no more simple -- but better than plurality.

Many democratic countries do not use plurality voting, although plurality is the most common. For example, Australia, Northern Ireland, and the Irish Republic (among others) use single transferable vote[1]. In fact, 68 countries (~2b ppl) use plurality, 31 countries (~400m ppl) use single transferable vote, and two countries (~18m ppl) use IRV (instant runoff) -- this is according to International IDEA Handbook.

There is a huge amount of information about Condorcet and Approval Voting available on the web. The Citizens for Approval Voting page is a good start, if you're at all interested in improving voting in the US. If you're interested in the mechanics and mathematics of the systems, start with Condorcet -- most sites that talk about Condorcet are less about how to get it implemented politically, and are more about how it works, fairness tests, and how it compares to other systems. The Wikipedia entry for "voting system" is particularly useful.

whatever you do, don't play Tetris on mushrooms.

'cause if you do, you'll start seeing tetris everywhere!

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.

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.

Reversible computing basically means doing calculations using operations that can be easily and exactly reversed, including at the lowest level, the level of transistors or other physical mechanisms. By using reversible operations we can avoid dissipating the energy associated with the bits and thus decrease the total disspation of energy in our computer. Since the only functions that cannot in principle be made reversible are input and output, and the bandwidth of these is rather small (compared with internal system bandwidth used in 2020 computers), most of the processing in the future could be done using energy efficient reversible computing. Ballistic computation is reversible computation with energy dissipation so low as to be zero for all practical purposes (i.e. something else is a bottleneck).

A nice reference page with a list of rather informative is maintained at the MIT AI Lab website:
http://www.ai.mit.edu/~cvieri/reversible.html

There's a great GPL'd program out there called XFoil that contains a large database of standard airfoils, including several "flat bottomed" foils, that are easy to construct from balsa.

I've used these before in some simple hobby projects (that never actually got finished)

For a good book check out The Computational Beauty of Nature). Some tasks can be broken down into very simple repeated actions which simple machines can perform. The beauty of these system is that they require little communication between agents. Merely an awareness of what is around you and a simple list of tasks can create some complecated forms.

For other institutions considering implementing their own "opencourseware" there are several open-source CMS options. At this point, MIT OCW is monitoring six: Zope, Red Hat, Midgard, OpenACS, OpenCMS, and Bricolage. By 2004, most experts agree that one CMS provider will become the clear, open-source leader in this industry sector. MIT OCW will track the progress of key open-source CMS providers during this accelerated maturation. This will contribute to MIT being able to share its experience and understanding of these CMS options with other institutions. The hope is that utilization of open-source model CMS products could lead to less expensive implementations of opencoursewares on other campuses.

This, my friend, is so completely untrue that it's mind boggling. Considering that Sloan has sponsored the .LRN project, the open source courseware system that rivals any proprietary system, you're head is deeply up your ass.

Alas. That's generally where MIT students spend their time.

In MIT's words: For the "proof of concept" pilot...the Web pages of the MIT OCW site were built by..."brute-force HTML." Utilizing Web content editors such as DreamWeaver, a team of programmers from MIT and Sapient...designed and built the first 32 subjects. However, that model was not scalable for 500 courses, so MIT OCW has implemented a Content Management System (CMS) in order to achieve MIT OCW's long-term publishing goals. The CMS we have been using since the beginning of 2003 is a customized implementation of Microsoft Content Management System 2002...there wasn't a viable open source solution...Microsoft made a serious commitment to the MIT OCW project...The hope is that utilization of open-source model CMS products could lead to less expensive implementations...

Nope, MIT tuition is about $30K, plus $10K living expenses, and so on... giving a grand total of about $41K to go to school there for *one* *year*, as of this school year (03-04). They may be increasing it in the future. It's a sizable chunk of change -- more than my family makes annually.

I know because I've been reading their financial aid brochures a *lot*. This is not a heartening development. More info here.

- sparrow_hawk, who is currently rethinking going to MIT...

Cost for one year of MIT undergraduate tuition in 2002-2003: $28,230.00
Cost for one year of MIT undergraduate tuition in 2003-2004: $29,400.00

School runs from Sept 3 to May 21, so estimate at 39 weeks. Next, assume the student is working for 1/2 tuition credit (which a lot of colleges like to do for part time work), at ~ $14,500. Since they're working part time and going to school, lets be generous and say they work three days a week: 24 hours. You've just forked out $15.50/hour for one "cheap labor" marginally-skilled student.

Now, compare that to what you can get for outsourcing it to anyone else... I'm not surprised they did; because of their rising tuition costs, they've priced out their own students.

Cost for one year of MIT undergraduate tuition in 2002-2003: $28,230.00
Cost for one year of MIT undergraduate tuition in 2003-2004: $29,400.00

School runs from Sept 3 to May 21, so estimate at 39 weeks. Next, assume the student is working for 1/2 tuition credit (which a lot of colleges like to do for part time work), at ~ $14,500. Since they're working part time and going to school, lets be generous and say they work three days a week: 24 hours. You've just forked out $15.50/hour for one "cheap labor" marginally-skilled student.

Now, compare that to what you can get for outsourcing it to anyone else... I'm not surprised they did; because of their rising tuition costs, they've priced out their own students.

He was talking about the cost of the degree, as in (queue MasterCard commercial):

OpenCourseware (partly outsourced): $11 million
MIT Staff support: $2 million (of the 11)
MIT Comp. Sci. degree: $160000 per student

Learning about the true economics of modern software development:
PRICELESS

It is a little strange to read, in the pitch for OpenCourseware that:

"It is true to MIT's values of excellence, innovation, and leadership."

In some ways (the intent of the project), yes, absolutely. In implementation, well, somehow it seems a bit unfulfilling. But it is up and running. A custom-coded solution might have taken longer.

Anyway, there is a bit more technical information in the FAQ at:

"What technology is used to publish the MIT OCW Web site?"

and

"Is MIT OCW an open-source project?"

The answer for the second one is fairly long, and could be succinctly summarized as "no", but there is a list of open-source content management systems they are monitoring for future potential use, and which is worth looking at if you are interested in this subject.

He was talking about the cost of the degree, as in (queue MasterCard commercial):

OpenCourseware (partly outsourced): $11 million
MIT Staff support: $2 million (of the 11)
MIT Comp. Sci. degree: $160000 per student

Learning about the true economics of modern software development:
PRICELESS

It is a little strange to read, in the pitch for OpenCourseware that:

"It is true to MIT's values of excellence, innovation, and leadership."

In some ways (the intent of the project), yes, absolutely. In implementation, well, somehow it seems a bit unfulfilling. But it is up and running. A custom-coded solution might have taken longer.

Anyway, there is a bit more technical information in the FAQ at:

"What technology is used to publish the MIT OCW Web site?"

and

"Is MIT OCW an open-source project?"

The answer for the second one is fairly long, and could be succinctly summarized as "no", but there is a list of open-source content management systems they are monitoring for future potential use, and which is worth looking at if you are interested in this subject.

He was talking about the cost of the degree, as in (queue MasterCard commercial):

OpenCourseware (partly outsourced): $11 million
MIT Staff support: $2 million (of the 11)
MIT Comp. Sci. degree: $160000 per student

Learning about the true economics of modern software development:
PRICELESS

It is a little strange to read, in the pitch for OpenCourseware that:

"It is true to MIT's values of excellence, innovation, and leadership."

In some ways (the intent of the project), yes, absolutely. In implementation, well, somehow it seems a bit unfulfilling. But it is up and running. A custom-coded solution might have taken longer.

Anyway, there is a bit more technical information in the FAQ at:

"What technology is used to publish the MIT OCW Web site?"

and

"Is MIT OCW an open-source project?"

The answer for the second one is fairly long, and could be succinctly summarized as "no", but there is a list of open-source content management systems they are monitoring for future potential use, and which is worth looking at if you are interested in this subject.

MIT OCW is a large-scale, Web-based electronic publishing initiative funded jointly by the William and Flora Hewlett Foundation, the Andrew W. Mellon Foundation, and MIT.

MIT OCW is a large-scale, Web-based electronic publishing initiative funded jointly by the William and Flora Hewlett Foundation, the Andrew W. Mellon Foundation, and MIT.

Not all of our students will see this cover story in Business Week on the migration of high-paying jobs to India. But most attended a lecture in 6.171 by the folks who run MIT's latest big IT effort: OpenCourseware ( http://ocw.mit.edu ), which distributes syllabi, problem sets, and other materials from MIT classes (at least one semester after the class is actually given). During the lecture the students learned that, although ocw.mit.edu is a purely static .html site, it is produced with a database-backed content management system. In fact, of the $11 million donated by foundations to support the service, about $2 million was spent on technology and the salaries of folks at MIT who oversee the technology.

The more sophisticated portion of ocw.mit.edu is a 100 percent Microsoft show. A student asks the speakers why they chose Microsoft Content Management Server, expecting to hear a story about careful in-house technical evaluation done by people sort of like them. The answer: "We read a Gartner Group report that said the Microsoft system was the simplest to use among the commercial vendors and that open-source toolkits weren't worth considering."

Students began to wake up.

A PowerPoint slide contained the magic word "Delhi". It turns out that most of the content editing and all of the programming work for OpenCourseware was done in India, either by Sapient, MIT's main contractor for the project, or by a handful of Microsoft India employees who helped set up the Content Management Server.

Thus did students who are within months of graduating with their $160,000 computer science degrees learn how modern information systems are actually built, even by institutions that earn much of their revenue from educating American software developers.

Not all of our students will see this cover story in Business Week on the migration of high-paying jobs to India. But most attended a lecture in 6.171 by the folks who run MIT's latest big IT effort: OpenCourseware ( http://ocw.mit.edu ), which distributes syllabi, problem sets, and other materials from MIT classes (at least one semester after the class is actually given). During the lecture the students learned that, although ocw.mit.edu is a purely static .html site, it is produced with a database-backed content management system. In fact, of the $11 million donated by foundations to support the service, about $2 million was spent on technology and the salaries of folks at MIT who oversee the technology.

The more sophisticated portion of ocw.mit.edu is a 100 percent Microsoft show. A student asks the speakers why they chose Microsoft Content Management Server, expecting to hear a story about careful in-house technical evaluation done by people sort of like them. The answer: "We read a Gartner Group report that said the Microsoft system was the simplest to use among the commercial vendors and that open-source toolkits weren't worth considering."

Students began to wake up.

A PowerPoint slide contained the magic word "Delhi". It turns out that most of the content editing and all of the programming work for OpenCourseware was done in India, either by Sapient, MIT's main contractor for the project, or by a handful of Microsoft India employees who helped set up the Content Management Server.

Thus did students who are within months of graduating with their $160,000 computer science degrees learn how modern information systems are actually built, even by institutions that earn much of their revenue from educating American software developers.

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.

If the Left is against this, and the Right is against this, who's pushing it? The Middle?

Wireless sensor networks are not new; there is even a textbook published recently on them (Wireless Sensor Networks: Architectures and Protocols). Many corporations have active WSN programs, including:

Motorola

Ember and

Figure 8 Wireless.

University research programs, in addition to Berkeley, include:

UCLA WINS

MIT uAMPS

plus those sposored by DARPA.

The IEEE 802.15.4 standard, available here, was designed to support such networks. The ZigBee Alliance, an industrial consortium of over 60 companies, is the marketing and compliance arm of the 802.15.4 standard, as the Wi-Fi Alliance is to 802.11. The vitality of the ZigBee Alliance, which had over 350 attendees at its recent open house in Silicon Valley, is an indication that this technology is moving from research into commercialization; the commercialization of wireless sensor networks is the real significance of the Wired article.

Being a graduate student at MIT working on sensor networks, I have to mention our project. : )

http://www-mtl.mit.edu/research/icsystems/uamps/uA MPShome.html

The uAMPS project will involve designing integrated circuits that realize wireless sensor networks. There are students researching low power integrated circuits - both analog and digital. I'm doing the wireless stuff.

You have to be careful to separate the hype from reality regarding sensor networks, but there are definitely some cool applications. One thing that I think will definitely help things progress is the new 802.15.4 standard (Zigbee).

doodles

I would say that RC cars are indeed a type of robot. In fact, MIT has a webpage on how to convert RC Cars to a robot. See:
http://web.mit.edu/tas/www/traxx/rt_main.htm

For those interested, here's Text mode Quake and AsciiMac, wich seem to predate the previous one, including the X11 ASCII art thing.

What is it with ASCII??

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

Similar to open source crypto code not being insecure, other processes can be open without being insecure. The first step in many cases is simply to incorporate randomness into the process early on. Randomness will handle points 1 and 3. Fraud detection can be open as well by incorporating fuzzy logic and genetic algorithms.

Really, isn't a functional language like LOGO
(hmmm, something strange about that turtle head there) better?

And what about LOGO's big brother, Common Lisp?

C'mon guys! The Turtle is calling for you. Will you answer?

We need projects like Roofnet to come to fruition too, so we can finally take the network itself out of organizations' hands. Having to pay a (lawsuit-susceptible and potentially evil) megacorp for Internet access isn't exactly conducive to freeing society FROM the megacorps...
Anyone considered starting a Great Sneakernet? Somehow it has to be detached from the Internet after it gets started, and it'll need to be self-perpetuating. Get everyone to cart their CD cases around whenever they go to their m8's house and copy...but I'm kinda at a loss as to how to make it take off. =\

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Um, not to be too much of a jerk, but that's Kerberos. I just felt a need to point that out in case anyone got confused. Your point remains valid, of course.

I recently heard Noam Chomsky respond to a comment like yours. He said that this woud be the same as saying to Alexander Solzhenitsyn that since he didn't like the regime in USSR he should just leave.

If he had maybe we would still be in the thralls of the Cold War.

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.

Very interesting. So Robert T. Morris has cleaned up his coding since the days of the Morris Worm

Read the above link and then read RTM's bio page. Same guy?

Look at DSpace, the mission of which is "To create and establish an electronic system that captures, preserves and communicates the intellectual output of MIT's faculty and researchers."

Each data set (collection) has a handle, suppoosedly longer lasting than URNs. We're talking about long term data storage here.

There's an implementation of it at Cambridge University, and my organisation will be evauluation it as soon as the SuSE Linux Enterprise Server software lands on my desk and I've installed my server.

Tom.

Each data set (collection) has a handle, suppoosedly longer lasting than URNs. We're talking about long term data storage here.

There's an implementation of it at Cambridge University, and my organisation will be evauluation it as soon as the SuSE Linux Enterprise Server software lands on my desk and I've installed my server.

Tom.

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.

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.

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.

"Pathetic" is a bit over the top. Each of those machines exerted some major influence and made a mark on the industry.

The TI 99/4 was definitely saddled with a weird "expansion box" which was essentially an empty PC case designed to hold expansion cards (memory, floppy drive, etc.). However, the 99/4 became the darling of early education since it ran LOGO, a programming language that was taught to kindergarten and elementary school children. There's a generation whose first classroom PC was a TI 99/4 running LOGO. TI also spent a lot of money advertising the 99/4 (Bill Cosby was the spokesman) which raised consumer awareness of the existence of PC's for the home.

The Timex/Sinclair was a novelty but also showed the possibilies for cheap and small PC's that could be used by hobbyists on a budget. There are a lot of programmers that cut their teeth on BASIC on the Sinclair

The Adam from Coleco was nearly "pathetic" as far as a PC, but it was a pretty cool gaming console and it had great packaging. It was compatable with nothing, but Coleco bundled it with a lot of stuff. However, if I recall correctly it was a major disaster in terms of sales and took Coleco down with it.

WTF is chaff?

Chaff:
1 : the seed coverings and other debris separated from the seed in threshing grain

Hence by association:

2 : something comparatively worthless

Also:

4 : material (as strips of foil or clusters of fine wires) ejected into the air for reflecting radar waves (as for confusing an enemy's radar detection)

That is, extra bogus data to hide the good stuff. See Rivest's paper on chaffing and winnowing

...by hammering another one that's only serving up a measly 13MB video of 1994 superballs :)