Slashdot Mirror

So that's what it is! I give job interviews, and ask "What is the largest or most impressive computer program you've ever written?"

Frequently if the applicant is an MIT student, they respond with "a pinball game". Now I can see what assignment those kids were fulfilling with that game.

Note that I don't consider it very impressive if a student has never made any program larger than a single semester's final project. A good programmer should have some love of the art, and will have 1-2 good hobbyist projects under his belt. In the case of Gizmoball, it's even less of an achievement, since the students get a good quantity of example code provided. Isn't it reasonable to expect that MIT students can roll their own elastic-collision physics?

So that's what it is! I give job interviews, and ask "What is the largest or most impressive computer program you've ever written?"

Frequently if the applicant is an MIT student, they respond with "a pinball game". Now I can see what assignment those kids were fulfilling with that game.

Note that I don't consider it very impressive if a student has never made any program larger than a single semester's final project. A good programmer should have some love of the art, and will have 1-2 good hobbyist projects under his belt. In the case of Gizmoball, it's even less of an achievement, since the students get a good quantity of example code provided. Isn't it reasonable to expect that MIT students can roll their own elastic-collision physics?

Don't be silly. People don't go to MIT to get an education. They go to drink beer and get laid...no, wait. That must have been some other college I was thinking of.

Oh yes, I remember now. They go to MIT in order to assemble police cars on the roof. Seriously, if you think college is all about classes, you missed out on your education.

From the MIT mission statement:

The Institute is committed to generating, disseminating, and preserving knowledge, and to working with others to bring this knowledge to bear on the world's great challenges.

It's one thing for a university to say something like that, but what I as a student can contribute to this discussion is the assurance that they're for real. TDespite huge military and government funding there are no secret projects on campus; every research lab is open to every student. Most parts of campus (including the extensive libraries) are even open to the public. Data is posted on the internet as soon as it can be verified... I feel silly listing these individual things MIT does to share information. That's probably because OCW is the single greatest step in that process.

I'm not worried that my degree will be obsolete in 20 years. Other people may have learned the same material organized by the same professors, but the real value of MIT is the interaction with the teachers and the students. It comes with a hefty price tag, of course. Disclaimer: MIT isn't perfect. Every time I've mentioned the school before I've gotten flamed. Flame away. The school isn't perfect, but it does have a particular nobility of purpose.

"Of course, there will probably be debates to see if these courses will be admissible for diploma..."

Probably only between people such as yourself that have not read any of the FAQs:

"MIT OCW is not meant to replace degree-granting higher education or for-credit courses. Rather, the goal is to provide the content that supports an education."

About 1/3 of the FAQs there plainly state that this is just the publishable material of the course; not at all a replacement for taking the course, and in no way is admissible for a diploma.

If you've ever attended college and skipped a class, you should know there is absolutely no comparison between being in class and reading the notes on the web later. That being said, I think this is a great idea, and hopefully people will use it for its intended purpose.

Scott

Making MIT Affordable

Alas, I didn't graduate (ran out of money at the time) and don't see a way to get back into it. They don't seem to have any pages targeted at people who want to resume a long-interrupted stay.

Unfortunately that cannot work. People do not really want choice (except perhaps in California elections...?). Maybe they have 4 restaurants to choose from but in reality they will go to the same one over and over. The average person is a creature of habit, and once in that comfort zone, they will not leave.

This is particularly true in software. You and I are perfectly comfortable exploring new programs, UIs, operating systems, etc. We'll even intentionally do things that would be considered risky. It's a form of research for us, research into efficiency and enjoyment of our time. This is by far a minority behavior: most people can not or will not change for this. To them, the computer is a machine (interface and OS and all else be damned) and machines do not change.

While we're at it, let's complain about the keyboard layout that computers come with. There are other choices besides the standard QWERTY (some of which may be much more efficient), so how many of us use them? Oh wait, maybe it's too hard to change...

In case anyone wants to read the original paper on this it's at:

http://theory.lcs.mit.edu/~rivest/JuelsRivestSzydl o-TheBlockerTag.pdf

Like someone already pointed out, getting to space requires brute force. It seems that some people think who ever wins the X-Prize contest can practically begin sending people to LEO. Think again. Do some basic calculus (the potential energy needed to get something 100km up versus kinetic energy needed to put something into same altitude LEO) and realize that there's a HUGE difference. With a bit sophisticated garage technology and 137 s Isp you can jump at 100km but will not get anything orbiting Earth.

Big engine, hunking mechanical control systems with minimal intelligence.

In the 60s Saturn V had five F-1 engines pumping 1500000 pounds of thurst, each. Four of them were gimbaled, do you seriously think they were mechanically connected to some joystick in the command module?

Rocket science has not changed significantly since 1950, and needs a rethink. I believe this project is a solid approach that has good chances of succeeding, and if so, will redefine the way we conceive of this kind of engineering project in the future.

No amount of hype, CPU power or fancy 3D algorithms are going to overcome rocket equation. 'Real' space rockets sending something to orbit are going to stay as huge canisters of fuel with brute-force engines.

I do agree that space industry needs innovative thinking from people like J. Carmack but doubt that X-Prize contest itself will serve much of that, at least anything useful beyond creating these tourist 'trampolines' just to jump up there for a sec. A quick review of the teams puts them in three categories: vaporware (nice renderings though) for burning gullible vc (the most), crack pot science with desing (fins and more fins, big fins) straight from 50s SF strips, and a few with some real designs and even working hardware. Carmacks methodological approach ranks him to the last and best category but the ship design leans more to the 50s. Crushable nose cone?! Not very innovative, every new car has one but for the case of emergency!

MD5: Introduction
MD5 was developed by Professor Ronald L. Rivest of MIT. What it does, to quote the executive summary of rfc1321, is:

[The MD5 algorithm] takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA.

In essence, MD5 is a way to verify data integrity, and is much more reliable than checksum and many other commonly used methods.

...I can't help but start thinking about some of the Fun-But-Eevyl Things that one could do with this kind of hardware. The hack already done to the now-infamous 'Billy Bass' (or was it 'Boogie Bass?' I never was too clear on that) comes immediately to mind, as do the electronic surgical procedures performed on hapless furbys.

For example: I seem to recall that several of the parade floats have wireless receivers for the purpose of playing parade music through onboard speakers. I think it would be great fun to find what frequency they're on, use a transmitter powerful enough to override Disney's signal (FM does have that nice 'capture' effect), and broadcast a nice, juicy belch right in the middle of the event.

This idea took on new meaning with my recent (somewhat unwilling) exposure to the big parade at the Orlando park. Every time the stupid narration told the audience to yell "Pixie Dust," I found myself wondering how much effort it would take to substitute the words "Angel Dust!"

Same thing applies to Lucky. I'll bet that, with some creative tweaking, he could be made to do all kinds of things that would be, shall we say, less than politically correct?

All I can say is that I hope someone does it when the press is around to report it. ;-)

Looks like the puppetry is really good. Looks like there's a giant mass of batteries in the cart. Sounds like the motors are really noisy - atleast when the head turns.

For a real walking robot dinosaur take a look at Troody.

SCO didn't say before they were "associated with MIT". SCO actually said they were at the MIT math department.

Quoting from http://www.computerworld.com/governmenttopics/gove rnment/legalissues/story/0,10801,81973,00.html

SCO was able to uncover the alleged violations by hiring three teams of experts, including a group from the MIT math department, to analyze the Linux and Unix source code for similarities. "All three found several instances where our Unix source code had been found in Linux," said a SCO spokesman.

And this is what MIT said http://www-tech.mit.edu/V123/N33/33sco.33n.html

Hal Abelson, a computer science professor who co-directs the MIT-Microsoft partnership...

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.

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 quickly 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 heavily 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 heavily 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 M$NBC article claims, "Today, four years into the five-year partnership, the protests are over and Microsoft technology is firmly entrenched at MIT." Irony? Looks like an outright lie to me and an implicit endorsement I doubt any University, especially MIT, would make or will be happy about. It misrepresents the original 1999 initiative, the extent of penetration and M$ influence.

MIT has it's own private computer system, Athena What else would you expect from the people who developed X, kerbos and many other awesome packages while M$ was putzing around with Windoze 3.1? Athena finished in 1991, where did M$ want to go at that time? MIT is more likely to take credit for being an early haven for RMS.

Here is an informative PDF about Athena and kerbos usage at MIT With 96% of the students using Athena, I'd say that M$ hardly has a toe in the door. Indeed, it's hard to imagine serious scientific computing with Microsoft, though there are some interesting and expensive toys available on that platform, Athena seems to have them all and their betters. Here is an old list of software available to Athena users

"The university?s educational computer network is being overhauled to use Microsoft?s .Net architecture." Is a particularly rich lie considering the Company's ambition of 1999, expressed in this NYT article, to be set the tone for MIT and 36 other companies and thereby pervert everyone's standards and lock up all publishing in M$ DRM. The above article also claimed that M$ had become the "de facto standard" at Universities. It seems strange that M$ feels the need to restate the case four years later. Slashdot covered that move and the student comments are cutting.

Some things remain the same, however. The few M$ boxes seem to be the same headache at MIT as they are everywhere:

1. 750 boxes infected with sobig and blaster, presumably student owned, remedy is rebuild.
2. Problems with mail directories:
3. Problems with different versions of M$ office (another old page)

I can hardly believe that I read half of that nauseating piece of BS. Microsoft has tried to make policy at Universities and they have bought a few whores at some of them. This article is typical Microsoft, "we've already won" when the battle is far from over, "smart people use us" when the truth is far from it and "look how generous we are to be giving away Millions of dollars worth of binaries" as if an M$ CD was worth any more than an AOL CD. NBC should be ashamed to publish such rubbish, someone is asleep at the wheel.

Punching holes in this article for the last 30 minutes has been fun. Microsoft polute a LUG mailing list? No way. Come here, pig, I'm going to eat you alive. Bang, pow, bite, squeel, squeel, smash crash thud. /* - Big Grin full of exposed teeth - */ Only someone completely immersed in M$ BS and completely ignorant of scientific computing and campus life in general would think M$NBC was being critical of M$.

I now return you to news that matters and reality, which have nothing to do with M$ press releases.

The M$NBC article claims, "Today, four years into the five-year partnership, the protests are over and Microsoft technology is firmly entrenched at MIT." Irony? Looks like an outright lie to me and an implicit endorsement I doubt any University, especially MIT, would make or will be happy about. It misrepresents the original 1999 initiative, the extent of penetration and M$ influence.

MIT has it's own private computer system, Athena What else would you expect from the people who developed X, kerbos and many other awesome packages while M$ was putzing around with Windoze 3.1? Athena finished in 1991, where did M$ want to go at that time? MIT is more likely to take credit for being an early haven for RMS.

Here is an informative PDF about Athena and kerbos usage at MIT With 96% of the students using Athena, I'd say that M$ hardly has a toe in the door. Indeed, it's hard to imagine serious scientific computing with Microsoft, though there are some interesting and expensive toys available on that platform, Athena seems to have them all and their betters. Here is an old list of software available to Athena users

"The university?s educational computer network is being overhauled to use Microsoft?s .Net architecture." Is a particularly rich lie considering the Company's ambition of 1999, expressed in this NYT article, to be set the tone for MIT and 36 other companies and thereby pervert everyone's standards and lock up all publishing in M$ DRM. The above article also claimed that M$ had become the "de facto standard" at Universities. It seems strange that M$ feels the need to restate the case four years later. Slashdot covered that move and the student comments are cutting.

Some things remain the same, however. The few M$ boxes seem to be the same headache at MIT as they are everywhere:

1. 750 boxes infected with sobig and blaster, presumably student owned, remedy is rebuild.
2. Problems with mail directories:
3. Problems with different versions of M$ office (another old page)

I can hardly believe that I read half of that nauseating piece of BS. Microsoft has tried to make policy at Universities and they have bought a few whores at some of them. This article is typical Microsoft, "we've already won" when the battle is far from over, "smart people use us" when the truth is far from it and "look how generous we are to be giving away Millions of dollars worth of binaries" as if an M$ CD was worth any more than an AOL CD. NBC should be ashamed to publish such rubbish, someone is asleep at the wheel.

Punching holes in this article for the last 30 minutes has been fun. Microsoft polute a LUG mailing list? No way. Come here, pig, I'm going to eat you alive. Bang, pow, bite, squeel, squeel, smash crash thud. /* - Big Grin full of exposed teeth - */ Only someone completely immersed in M$ BS and completely ignorant of scientific computing and campus life in general would think M$NBC was being critical of M$.

I now return you to news that matters and reality, which have nothing to do with M$ press releases.

The M$NBC article claims, "Today, four years into the five-year partnership, the protests are over and Microsoft technology is firmly entrenched at MIT." Irony? Looks like an outright lie to me and an implicit endorsement I doubt any University, especially MIT, would make or will be happy about. It misrepresents the original 1999 initiative, the extent of penetration and M$ influence.

MIT has it's own private computer system, Athena What else would you expect from the people who developed X, kerbos and many other awesome packages while M$ was putzing around with Windoze 3.1? Athena finished in 1991, where did M$ want to go at that time? MIT is more likely to take credit for being an early haven for RMS.

Here is an informative PDF about Athena and kerbos usage at MIT With 96% of the students using Athena, I'd say that M$ hardly has a toe in the door. Indeed, it's hard to imagine serious scientific computing with Microsoft, though there are some interesting and expensive toys available on that platform, Athena seems to have them all and their betters. Here is an old list of software available to Athena users

"The university?s educational computer network is being overhauled to use Microsoft?s .Net architecture." Is a particularly rich lie considering the Company's ambition of 1999, expressed in this NYT article, to be set the tone for MIT and 36 other companies and thereby pervert everyone's standards and lock up all publishing in M$ DRM. The above article also claimed that M$ had become the "de facto standard" at Universities. It seems strange that M$ feels the need to restate the case four years later. Slashdot covered that move and the student comments are cutting.

Some things remain the same, however. The few M$ boxes seem to be the same headache at MIT as they are everywhere:

1. 750 boxes infected with sobig and blaster, presumably student owned, remedy is rebuild.
2. Problems with mail directories:
3. Problems with different versions of M$ office (another old page)

I can hardly believe that I read half of that nauseating piece of BS. Microsoft has tried to make policy at Universities and they have bought a few whores at some of them. This article is typical Microsoft, "we've already won" when the battle is far from over, "smart people use us" when the truth is far from it and "look how generous we are to be giving away Millions of dollars worth of binaries" as if an M$ CD was worth any more than an AOL CD. NBC should be ashamed to publish such rubbish, someone is asleep at the wheel.

Punching holes in this article for the last 30 minutes has been fun. Microsoft polute a LUG mailing list? No way. Come here, pig, I'm going to eat you alive. Bang, pow, bite, squeel, squeel, smash crash thud. /* - Big Grin full of exposed teeth - */ Only someone completely immersed in M$ BS and completely ignorant of scientific computing and campus life in general would think M$NBC was being critical of M$.

I now return you to news that matters and reality, which have nothing to do with M$ press releases.

don't know why this wasn't given in the writeup but here is the MIT SSL SPHERES site. And if you look at the pictures you will see that they are not spheres.

Nope. He paid for a part of the building. The building in question is the Stata Center, named for Ray and Maria Stata. Ray Stata is an MIT alum who founded Analog Devices, and he's the one shelling out much of the dough. Gates only paid for one tower of the building (cheapskate), so that's all he gets. No one calls it the Gates building - it's called the Stata Center. Or, alternatively "that pile of iron on Vassar street", since it's designed by "renowned" "architect" Fran Gehry, which means it looks like it was a very nice building that got hit by an earthquake...

You've obviously never heard of Steer Roast.

SCO's MIT mathematicians go AWOL

SCO said, they had three teams, including a team from MIT math department, examine their "proof" of UNIX code improperly in Linux

1. No such team could be found at MIT. And SCO are back tracking on this claim.

http://www-tech.mit.edu/V123/N33/33sco.33n.html

2. Here is an example quote that SCO made about MIT math involvement:

http://www.computerworld.com/governmenttopics/gove rnment/legalissues/story/0,10801,81973,00.html

SCO was able to uncover the alleged violations by hiring three teams of experts, including a group from the MIT math department, to analyze the Linux and Unix source code for similarities. "All three found several instances where our Unix source code had been found in Linux," said a SCO spokesman.

believe it or not, but robostrider was brian chan's undergrad thesis. he is now working on robosnail, and was recently featured on cnn. it now looks like they took the article down, but his personal website with all that stuff is here.his personal research info, not linked off his main page, is here.

oh yeah, he was my roommate when he was working on the robostrider. brian is fascinated by insects and such. we had a foot long 3/4" diameter millipede as a pet. one day it got loose.

he also forges traditional japanese swords. one day he came back from doing poorly on a test, and embedded it it 2 feet in the wall. luckily, no one was on the other side at the time.

believe it or not, but robostrider was brian chan's undergrad thesis. he is now working on robosnail, and was recently featured on cnn. it now looks like they took the article down, but his personal website with all that stuff is here.his personal research info, not linked off his main page, is here.

oh yeah, he was my roommate when he was working on the robostrider. brian is fascinated by insects and such. we had a foot long 3/4" diameter millipede as a pet. one day it got loose.

he also forges traditional japanese swords. one day he came back from doing poorly on a test, and embedded it it 2 feet in the wall. luckily, no one was on the other side at the time.

believe it or not, but robostrider was brian chan's undergrad thesis. he is now working on robosnail, and was recently featured on cnn. it now looks like they took the article down, but his personal website with all that stuff is here.his personal research info, not linked off his main page, is here.

oh yeah, he was my roommate when he was working on the robostrider. brian is fascinated by insects and such. we had a foot long 3/4" diameter millipede as a pet. one day it got loose.

he also forges traditional japanese swords. one day he came back from doing poorly on a test, and embedded it it 2 feet in the wall. luckily, no one was on the other side at the time.

Anti-establishment psychology also comes into play: for example, you don't see anti-business graffiti on your local coffee shop, you see it at Starbucks.

No, but you will see gang graffiti on the local coffee shop. Gangs are not part of the anti-big business movement; they have their own reasons for doing what they do. So it is, I think, with the virus writer.

Calling Linux secure because people love DDOS'ing Microsoft is faulty logic.

Absolutely right. Might be wise to remind ourselves of rtm's 1988 worm.

Apparently you don't recall this MIT hack.

Apparently you don't recall this MIT hack.

He's a cool guy- I took a fluids class he taught a few years back. He's one of those people who can use mathematical intuition to understand physical phenomena.

several people who thing that MIT's direction in AI has gone seriously awry

What does this have to do with AI?

The research reported on is primarily about fluid dynamics. Robostrider is a catchy thing they've created to bring attention to the important findings. In fact, seeing as the strider is powered by a rubber band, not only does it not have anything to do with AI, it has nothing to do with robotics either.

This doesn't mean it's not wicked cool.

For more cool (without downloading a video), check out david hu's beautiful strider pics.

several people who thing that MIT's direction in AI has gone seriously awry

What does this have to do with AI?

The research reported on is primarily about fluid dynamics. Robostrider is a catchy thing they've created to bring attention to the important findings. In fact, seeing as the strider is powered by a rubber band, not only does it not have anything to do with AI, it has nothing to do with robotics either.

This doesn't mean it's not wicked cool.

For more cool (without downloading a video), check out david hu's beautiful strider pics.

Just to save everyone the trouble, the third robot the fluids lab appears to be working on is a 3-segment swimmer.

Err, you might want to check you facts. I think MIT put out 31 astronauts, more than Purdue's 20?

Then again the article is from June 2001.

MIT Astronauts

but dead last in babe-filled orgies!

Can't upset the censors.

J

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.

"Irrational exuberance," anyone?
They should fix the problem with Yatta!

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 the open-source community. 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 the open-source community. 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.

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.

Of course MIT is the best engineering school - they have the best understanding of engineers!

MIT Traditonal, The Engineer's Drinking Song, as sung by engineers worldwide.

Search for it on Kazaa, you'll find the Chorallaries excellent version.

The Video Game Ombudsman does what this article did on a regular basis, with more structure, in the form of a (we)blog. Plus, Kyle has heard of the word "ombudsman" before, so that gives him a little more cred.

Websites like GameCritics, Joystick101, and GameGirlAdvance have gotten notable mentions from industry and academic heavyweights, such as the venerable Henry Jenkins.

I encourage smarter game/gamedev/gamebiz/gameculture/gameacademia journalism, but to say this is new and unique is an insult to those that have come before.

The Morris Internet Worm

Umm, you forgot 1988: Morris Worm spreads by using sendmail.

We weren't all laughing in 1994. Some of us were thinking Microsoft didn't learn from history.