Slashdot Mirror

You shave at least 4 km/sec off of your required delta-v if you can use ion drives and have a longer trip.

Do you think you could build a mechanical ethernet interface?

It might need to use some paper tape to buffer the incoming packets before routing them. But there is hardware that does that:
Reperferator transmitter

The weather info comes from MIT's weather server which still formats the weather service info as teletype output.

Of couse it's all the administrations fault for not finding a big alumni donor to put their name on it.

European? No. Ignorant? Yes. CPUs, no matter the heat limitations, require a certain wattage to operate properly.

To see why this is so, consider a modern semiconductor circuit. Information is stored as 1's and 0's, with the 1's meaning a capacitor is storing a charge at some voltage. A 0 means the capacitor stores no electrons and sits at ground potential. To switch a bit from off to on today involves stuffing electrons into a capacitor until it is charged. To go the other way, from 1 to 0, requires grounding the capacitor. "The real dissipation comes from the fact that when you switch you normally throw away the energy that's sitting in the device capacitances. The charge is sitting there, and the energy is stored in there, and you normally throw that away. That's the easiest thing to do with it" ... The amount of energy wasted per capacitor is minuscule, but discharges take place millions of times or more a second all over a chip. What's more, standard programming practice is to clear all registers and set them to a known state before beginning an algorithm. That, too, throws away information.

The standard sysadmin reward-food is "anything flat". For programmers you can also add (for those from MIT) Suan La Chow Show. If you don't know what the Suan is, you have not yet lived. Go directly to Mary's, do not type go, do not clock 200MhZ.

I'm up for offering you a free Mary's run. Just drop me some mail.

Government Information Awareness

Mission

To empower citizens by providing a single, comprehensive, easy-to-use repository of information on individuals, organizations, and corporations related to the government of the United States of America.

To allow citizens to submit intelligence about government-related issues, while maintaining their anonymity. To allow members of the government a chance to participate in the process.

I doubt he has more then ten grand in the bank for god's sake.

A year or so ago, on another occasion when we discussed his finances, I spent a couple of hours googling him.

Stallman has been the receipient of a MacArthur "genius" grant -- and a couple of other similar ones.

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.

And then the moved to an infix syntax and pissed all of them off.

van Rossum :

I guess one difference is that it has a long history, since it was first distributed in 1991. In those days nobody talked about "open source", and Richard Stallman [founder of the Free Software Foundation] wasn't very well known and the GNU General Public License didn't exist.

parent poster (Slothrup) :

WTF? The GPL didn't exist in 1991? I guess I was hallucinating when I was using GNU Emacs and GCC in the 80s.

Yes, I was also surprised at this large factual error.

GPL Version 2 : June 1991

GPL Version 1 : February 1989

Earlier forms of Copyleft licenses also existed from before 1989. The Free Software Foundation was founded in 1985 and has of course always released its work as 'Free Software'.

p.s. Slothrup, I suggest evening tea at Miss Quoad's would be a suitable punishment for van Rossum's inaccuracy. As a man who named his language after an English comedy group, I'm sure he has the required sensibility to appreciate the full horror of this particular engagement.

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

Engineering!=CAD

I am an engineer. I've worked on many engineering studies over the past few years. I run a engineering company now. The number of times I've had to use a propriety CAD package I can count on my right hand.

Thanks to all of the open source packages out there, there are plenty of engineerng apps available for Mac OS X.

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.

Initial results were quite positive. We found statistically significant differences between groups learning through games and those doing inquiry-based units. We found that most importantly, kids could tell you things like what field lines are and what they're used for in the experimental group -- whereas the controls could tell you the right answer but not really know why.

Still, the teacher played a really critical role in the environment, doing a lot of coaching and helping kids connect what they're seeing in the game back to the academic content. Interpreting game play is a tricky process, I'm finding.

I'd also admit though that Supercharged is a pretty mediocre game. It was our first shot at this -- and it came out ok but has a lot of issues. I'm excited about some of our other designs -- particularly revolution, which is designed to use the neverwinter nights modding tools. here's the initial design concept for revolution.

Our current plans are to begin working with a larger network of commercial game developers to really do this kind of thing right, now that we have some preliminary data to show that it's at least worth trying.

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 I feel is the most important concept for people designing edutainment games is the hierarchy fo learning. This hierarchy is also called "Bloom's Cognative Taxonomy." Rote memorization and drilling are good for immediate responses, but of very little value in the real world. If I remember correctly, its been theorized that knowledge is held longer as it is used in higher and higher level learning.

In the current edutainment area, there are two fields of game design. The first is a quiz and reward system. The student is presented with a quizing system and the actual game. The learning is supposed to come from the quiz. Depending on how well the student does, permission is given to play the game part for a little while, rewarding the player for doing well. It's a basic operant conditioning design. Learning here is very basic rote; trial and error learning.

The second common design is basic skills drilling. Number munchers, math blaster and that little spelling game where words marched down the castle wall and you had to type them before they got to you are all included in this area. Basically the game is timed drilling. The computer is used to encourage and engage the student, as well as to time them. Again the learning here is by trial and error. These sorts of games serve best as a reinforcement/recollection activity. If you know how to multiply numbers then they can help you instantly recall facts.

What I'd like to see more of these days is problem solving game design. This type merges the learning with the gameplay. It encourages experimentation, and extrapolation. Most REAL games operate in this manner these days; edutainment games should focus on making sure the lessons learned reflect reality accurately (or at least as best we know ;)). MIT's games-to-teach project is such a group of people working on edutainment games. If my friend Kurt is reading this, I'm sure he'll post more about their success stories. I'd just like to mention Hephaestus, a game based on engineering robots (I'm guessing remote controlled rather than AI)from lego like parts, although it looks like they've jumped on the current trends marketing bandwagon and its now an MMORPG of some sort, with energy as currency.

What I feel is the most important concept for people designing edutainment games is the hierarchy fo learning. This hierarchy is also called "Bloom's Cognative Taxonomy." Rote memorization and drilling are good for immediate responses, but of very little value in the real world. If I remember correctly, its been theorized that knowledge is held longer as it is used in higher and higher level learning.

In the current edutainment area, there are two fields of game design. The first is a quiz and reward system. The student is presented with a quizing system and the actual game. The learning is supposed to come from the quiz. Depending on how well the student does, permission is given to play the game part for a little while, rewarding the player for doing well. It's a basic operant conditioning design. Learning here is very basic rote; trial and error learning.

The second common design is basic skills drilling. Number munchers, math blaster and that little spelling game where words marched down the castle wall and you had to type them before they got to you are all included in this area. Basically the game is timed drilling. The computer is used to encourage and engage the student, as well as to time them. Again the learning here is by trial and error. These sorts of games serve best as a reinforcement/recollection activity. If you know how to multiply numbers then they can help you instantly recall facts.

What I'd like to see more of these days is problem solving game design. This type merges the learning with the gameplay. It encourages experimentation, and extrapolation. Most REAL games operate in this manner these days; edutainment games should focus on making sure the lessons learned reflect reality accurately (or at least as best we know ;)). MIT's games-to-teach project is such a group of people working on edutainment games. If my friend Kurt is reading this, I'm sure he'll post more about their success stories. I'd just like to mention Hephaestus, a game based on engineering robots (I'm guessing remote controlled rather than AI)from lego like parts, although it looks like they've jumped on the current trends marketing bandwagon and its now an MMORPG of some sort, with energy as currency.

Didn't these people ever play Oregon Trail or the Carmen Sandiego games? I mean, come on! I'm 26 years old and I rememember playing these games in elementary school. And (I know, it's not a game--but it did have a cute turtle) who can forget LOGO programming? Tons of fun for everyone.

However the business logic and reporting is written in Guile. This in turn is based directly on Scheme, to quote the home page:

a statically scoped and properly tail-recursive dialect of the Lisp programming language

The thing is that when you work with this kind of program, you need to implement the objects in something that is fast, however the upper layers need to be at a higher level so this approach works well.

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

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.

Having said all this, I don't think it's necessarly a bad thing that sending qualified email take a bit more thought.

I have to correct myself a bit here. The Ogg Vorbis toolkit was originally licensed under the GPL, from what I remember, and they later shifted to a BSD-style license, which move was not begrudgingly accepted by RMS and the rest of the Free Software Foundation. They actively encouraged the move, IIRC, as Ogg Vorbis is a technologically superior format unencumbered by patents, unlike the dominant MP3 format, for which a legal codec would be impossible for Free Software (LAME and Bladeenc are legally a gray area, and that isn't a good thing). Think GIF vs. PNG. RMS and the FSF have always understood that software patents pose an even greater threat to the cause of Free Software than proprietary software does. The GPL is designed to protect against software from going proprietary, but is of no help at all when dealing with patents (for which there can be no effective legal defense, short of having your own cross-licensable patent pool or having software patents abolished totally, which the FSF and the LPF are actively working to do).

Care to give a link that shows that RMS and the Free Software Foundation did not fully endorse Xiph's decision to move the licensing from GPL to BSD-style? Another link I've found, again RMS's own words, shows more pragmatism than anything. For reference, here's the original link from which i got the first RMS quote.

You are right of course that yes, rare are the cases where another license would serve the cause of Free Software better than the GPL would, but these cases are not unknown. For another example, someone else points out that the FSF actually discourages people from GPLing components at the core of the X Window System. The FSF as a whole and even Stallman in particular are not as inflexible and unpragmatic as many here seem to think.

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.

Got to remember these old jokes:

Longer list here...

Q. What's the difference between a violin and a viola?
A. A viola burns longer.

One day, in the middle of a rehearsal, the conductor sees the second chair viola in tears. He stops the orchestra, and asks, "What's wrong?" The violist replied "The oboist turned one of my tuning pegs!" The conductor asked "Don't you think you're overreacting?" "NO! He won't tell me which one!"

Actually if you look at the guy's home page at MIT you'll see that he isn't spenging his life studying just this but fluid dynamics generally. He seems to have a particular interest in the fine points of stuff you see everyday like the fluid dynamics of wine in a glass and soap film

I suppose you might still consider this boring but I sort of like the idea of the brainy mathematician walking around looking at everyday things nobody (not even other scientists) really notices and saying "I wonder why it does that?"

Actually if you look at the guy's home page at MIT you'll see that he isn't spenging his life studying just this but fluid dynamics generally. He seems to have a particular interest in the fine points of stuff you see everyday like the fluid dynamics of wine in a glass and soap film

I suppose you might still consider this boring but I sort of like the idea of the brainy mathematician walking around looking at everyday things nobody (not even other scientists) really notices and saying "I wonder why it does that?"

Actually if you look at the guy's home page at MIT you'll see that he isn't spenging his life studying just this but fluid dynamics generally. He seems to have a particular interest in the fine points of stuff you see everyday like the fluid dynamics of wine in a glass and soap film

I suppose you might still consider this boring but I sort of like the idea of the brainy mathematician walking around looking at everyday things nobody (not even other scientists) really notices and saying "I wonder why it does that?"

Don't!
Don't -- don't!
Don't -- don't!
Don't, don't believe the hype!

Flava Flav was right: the hype for anything is almost always wrong, and the bigger it is, the bigger the letdown.

That doesn't mean that the Segway itself isn't a great idea, or that the idle predictions that the widespread adoption of such a machine could reshape the way cities are built.

Look at what another commenter noted about the bike city in Holland, for example. I've been to Amsterdam, and even there the city has evolved into a place where multiple forms of transportation co-exist. Many of the major streets are 100 feet across, with multiple channels for different modes of transportation. The widest streets were laid out something like this (arrows indicate direction that traffic is permitted to flow, which may or may not be bidirectional):

<--- wide brick sidewalk (perhaps 15 feet or 5 meters wide) --->
<--- tarmac bike lane (2m) --->
<--- narrower sidewalk for pedestrians (2 or 3m) --->
X--- barricades to protect slower moving traffic (1m) ---X
<--- space for parallel parked cars (3m) <---

<--- a lane or two for cars & trucks to travel (3-6m) <---
<--- a set of rails for streetcars / trolleys (3m) <---

<--- narrow sidewalk for crossing, train platforms etc (2m) --->

---> another set of train tracks (3m) --->
---> another lane or two for cars going the other direction (3-6m) --->
---> more space for parallel parking (3m) --->

X--- barricades (1m) ---X;
<--- narrow pedestrian sidewalk (2 or 3m) --->
<--- another bike lane (2m) --->
<--- another wide brick sidewalk (5m) --->

if you add it up, the whole thing ends up taking something like 40 meters, or ~120 feet. (It's been a couple of years since my visit, so the widths are rough estimates, but they seem roughly correct to me -- corrections welcome :-).

Additionally, some streets had wide canals for boats to go back & forth, but most of these streets dropped the rail & bike lanes, and the overall width was generally similar to the non-canal streets. For streets not wide enough for all the lanes above, different lanes would be dropped at random: there's always be sidwwalks, but there might or might not be car lanes, rail tracks, bike lanes, canals, etc.

Also, as an aside, everyone with a bike seemed to be a Pee-Wee Herman fan, which is just fantastic :-)

Anyway, just imagine how much American streets would have to be re-engineered to support such a rich breadth of traffic. If Segways were to catch on in Amsterdam, maybe they could share that bike lane on either side of the street, or that mini sidewalk next to the parked cars could be converted for Segway-only traffic. Either way though, they have the basic framework such that a vehicle like this could find a niche somewhere. That isn't the case in any American city I've been to. If we ever bother to build streets as wide as the ones I saw in Amsterdam, they almost always end up being used for three or four lanes of cars

What's that line about predicting the futur

Don't!
Don't -- don't!
Don't -- don't!
Don't, don't believe the hype!

Flava Flav was right: the hype for anything is almost always wrong, and the bigger it is, the bigger the letdown.

That doesn't mean that the Segway itself isn't a great idea, or that the idle predictions that the widespread adoption of such a machine could reshape the way cities are built.

Look at what another commenter noted about the bike city in Holland, for example. I've been to Amsterdam, and even there the city has evolved into a place where multiple forms of transportation co-exist. Many of the major streets are 100 feet across, with multiple channels for different modes of transportation. The widest streets were laid out something like this (arrows indicate direction that traffic is permitted to flow, which may or may not be bidirectional):

<--- wide brick sidewalk (perhaps 15 feet or 5 meters wide) --->
<--- tarmac bike lane (2m) --->
<--- narrower sidewalk for pedestrians (2 or 3m) --->
X--- barricades to protect slower moving traffic (1m) ---X
<--- space for parallel parked cars (3m) <---

<--- a lane or two for cars & trucks to travel (3-6m) <---
<--- a set of rails for streetcars / trolleys (3m) <---

<--- narrow sidewalk for crossing, train platforms etc (2m) --->

---> another set of train tracks (3m) --->
---> another lane or two for cars going the other direction (3-6m) --->
---> more space for parallel parking (3m) --->

X--- barricades (1m) ---X;
<--- narrow pedestrian sidewalk (2 or 3m) --->
<--- another bike lane (2m) --->
<--- another wide brick sidewalk (5m) --->

if you add it up, the whole thing ends up taking something like 40 meters, or ~120 feet. (It's been a couple of years since my visit, so the widths are rough estimates, but they seem roughly correct to me -- corrections welcome :-).

Additionally, some streets had wide canals for boats to go back & forth, but most of these streets dropped the rail & bike lanes, and the overall width was generally similar to the non-canal streets. For streets not wide enough for all the lanes above, different lanes would be dropped at random: there's always be sidwwalks, but there might or might not be car lanes, rail tracks, bike lanes, canals, etc.

Also, as an aside, everyone with a bike seemed to be a Pee-Wee Herman fan, which is just fantastic :-)

Anyway, just imagine how much American streets would have to be re-engineered to support such a rich breadth of traffic. If Segways were to catch on in Amsterdam, maybe they could share that bike lane on either side of the street, or that mini sidewalk next to the parked cars could be converted for Segway-only traffic. Either way though, they have the basic framework such that a vehicle like this could find a niche somewhere. That isn't the case in any American city I've been to. If we ever bother to build streets as wide as the ones I saw in Amsterdam, they almost always end up being used for three or four lanes of cars

What's that line about predicting the futur

Don't!
Don't -- don't!
Don't -- don't!
Don't, don't believe the hype!

Flava Flav was right: the hype for anything is almost always wrong, and the bigger it is, the bigger the letdown.

That doesn't mean that the Segway itself isn't a great idea, or that the idle predictions that the widespread adoption of such a machine could reshape the way cities are built.

Look at what another commenter noted about the bike city in Holland, for example. I've been to Amsterdam, and even there the city has evolved into a place where multiple forms of transportation co-exist. Many of the major streets are 100 feet across, with multiple channels for different modes of transportation. The widest streets were laid out something like this (arrows indicate direction that traffic is permitted to flow, which may or may not be bidirectional):

<--- wide brick sidewalk (perhaps 15 feet or 5 meters wide) --->
<--- tarmac bike lane (2m) --->
<--- narrower sidewalk for pedestrians (2 or 3m) --->
X--- barricades to protect slower moving traffic (1m) ---X
<--- space for parallel parked cars (3m) <---

<--- a lane or two for cars & trucks to travel (3-6m) <---
<--- a set of rails for streetcars / trolleys (3m) <---

<--- narrow sidewalk for crossing, train platforms etc (2m) --->

---> another set of train tracks (3m) --->
---> another lane or two for cars going the other direction (3-6m) --->
---> more space for parallel parking (3m) --->

X--- barricades (1m) ---X;
<--- narrow pedestrian sidewalk (2 or 3m) --->
<--- another bike lane (2m) --->
<--- another wide brick sidewalk (5m) --->

if you add it up, the whole thing ends up taking something like 40 meters, or ~120 feet. (It's been a couple of years since my visit, so the widths are rough estimates, but they seem roughly correct to me -- corrections welcome :-).

Additionally, some streets had wide canals for boats to go back & forth, but most of these streets dropped the rail & bike lanes, and the overall width was generally similar to the non-canal streets. For streets not wide enough for all the lanes above, different lanes would be dropped at random: there's always be sidwwalks, but there might or might not be car lanes, rail tracks, bike lanes, canals, etc.

Also, as an aside, everyone with a bike seemed to be a Pee-Wee Herman fan, which is just fantastic :-)

Anyway, just imagine how much American streets would have to be re-engineered to support such a rich breadth of traffic. If Segways were to catch on in Amsterdam, maybe they could share that bike lane on either side of the street, or that mini sidewalk next to the parked cars could be converted for Segway-only traffic. Either way though, they have the basic framework such that a vehicle like this could find a niche somewhere. That isn't the case in any American city I've been to. If we ever bother to build streets as wide as the ones I saw in Amsterdam, they almost always end up being used for three or four lanes of cars

What's that line about predicting the futur

Don't!
Don't -- don't!
Don't -- don't!
Don't, don't believe the hype!

Flava Flav was right: the hype for anything is almost always wrong, and the bigger it is, the bigger the letdown.

That doesn't mean that the Segway itself isn't a great idea, or that the idle predictions that the widespread adoption of such a machine could reshape the way cities are built.

Look at what another commenter noted about the bike city in Holland, for example. I've been to Amsterdam, and even there the city has evolved into a place where multiple forms of transportation co-exist. Many of the major streets are 100 feet across, with multiple channels for different modes of transportation. The widest streets were laid out something like this (arrows indicate direction that traffic is permitted to flow, which may or may not be bidirectional):

<--- wide brick sidewalk (perhaps 15 feet or 5 meters wide) --->
<--- tarmac bike lane (2m) --->
<--- narrower sidewalk for pedestrians (2 or 3m) --->
X--- barricades to protect slower moving traffic (1m) ---X
<--- space for parallel parked cars (3m) <---

<--- a lane or two for cars & trucks to travel (3-6m) <---
<--- a set of rails for streetcars / trolleys (3m) <---

<--- narrow sidewalk for crossing, train platforms etc (2m) --->

---> another set of train tracks (3m) --->
---> another lane or two for cars going the other direction (3-6m) --->
---> more space for parallel parking (3m) --->

X--- barricades (1m) ---X;
<--- narrow pedestrian sidewalk (2 or 3m) --->
<--- another bike lane (2m) --->
<--- another wide brick sidewalk (5m) --->

if you add it up, the whole thing ends up taking something like 40 meters, or ~120 feet. (It's been a couple of years since my visit, so the widths are rough estimates, but they seem roughly correct to me -- corrections welcome :-).

Additionally, some streets had wide canals for boats to go back & forth, but most of these streets dropped the rail & bike lanes, and the overall width was generally similar to the non-canal streets. For streets not wide enough for all the lanes above, different lanes would be dropped at random: there's always be sidwwalks, but there might or might not be car lanes, rail tracks, bike lanes, canals, etc.

Also, as an aside, everyone with a bike seemed to be a Pee-Wee Herman fan, which is just fantastic :-)

Anyway, just imagine how much American streets would have to be re-engineered to support such a rich breadth of traffic. If Segways were to catch on in Amsterdam, maybe they could share that bike lane on either side of the street, or that mini sidewalk next to the parked cars could be converted for Segway-only traffic. Either way though, they have the basic framework such that a vehicle like this could find a niche somewhere. That isn't the case in any American city I've been to. If we ever bother to build streets as wide as the ones I saw in Amsterdam, they almost always end up being used for three or four lanes of cars

What's that line about predicting the futur

Light still can't travel around corners.

hunt, not wump.

hunt, not wump.

I'd rather have an OSI Red Team that was more like Delta Force.

They could wear MIT wearables, have an internet uplink, and code-fu your ass into submission.

Video-conferencing for education, which is what's really mentioned in the article, has taken off in a big way in this part of the world. MIT offers webcast lectures to graduate students in Singapore, just as Eidenhoven, Georgia Tech and others do. Carnegie Mellon also has a similar programme in India.

The Indian President, Dr APJ Abdul Kalam, was a tenured lecturer at the Anna University before getting elected as a President; I remember reading somewhere that he still gives lectures to students in Madras through video-conferencing.

There was an earlier case where, again, Dr Kalam apparently got doctors in Hyderabad to consult, check and finally operate on an eight-year-old kid in Agartala with a heart problem. (They, of course, flew the doctors in for the operation).

That said, I know many doctors back in India, many of them in the hospital that did the actual surgery, and most of them don't quite believe that video-conferencing will revolutionise their work. Just doesn't happen; the doctors I met love the technology, but they really would like to meet their patients f2f.

A better question, then, would be "How effective is video-conferencing for medical consultations and education?". Your poser will, rightly I might add, draw emotional responses on nations ("Hey, India has the world's biggest graduate population!", or something like that), rather than sane responses effective use of technology, which, IMHO, is the real question here.

ok, i confess i didn't read the article, but a recent mit project seems related: LAMP FAQ (scroll down a bit). offering cds over cable with an internet based request system. still in beta right now.

The War on Terror is a PR exercise to justify a 'forward-leaning' expansionist foreign policy.

We are very, very lucky in that the terrorists are a magnitude level higher in stupidity than the government and apparently much more incompetent. Consider that with CAPPS II, it is actually quite easy to circumvent the system and get on the plane. The fact that the terrorists haven't exploited our monumental security holes leads me to believe

1. They are incredibly stupid, or
2. There is something else occupying their time or they are laying low for now

The government cannot protect you from terrorists.

Ah, right. Let me guess... You're a MIT student, and you need to justify your hording of an entire class A block.

That clearly shows that CNN got it wrong. How can you extepct them to calculate from Miles to Kilometers, if they do not even know where Switzerland is.

You could use LOGO to program the directions...