Slashdot Mirror

A lot of people have a /8 network. From what I remember from my networking class, there was a scheme for how the ips should be divided.

If the first digit is less than 128 (ok, in reality, it is 127), they get a /8. If it is less than 192 (I think this is about where it is) they buy in a /16. If it is over 192, they get a /24.

Of course these can be subdivided.

Other examples of people who have /8 networks

MIT 18.0.0.0/8
Merck & Co., Inc 54.0.0.0/8
General Electric 3.0.0.0/8
US Department of Defence 6.0.0.0/8, 7.0.0.0/8, and 11.0.0.0/8
Genuity 4.0.0.0/8 and 8.0.0.0/8
American Telephone and Telegraph (AT&T) 12.0.0.0/8.

And that is just barely touching the surface.

--CPM

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.

Heheh... Got a bigger one for you. Hit Kazaa, and you should catch it from time to time.

To really fit in with your fellow Engineering students (and I mean the right ones, the ones who are there because they built stuff as kids, not the ones who are there because some dumbass guidance counsellor said, "Hey, you're good at math and physics, you should take engineering!"), you need to be able to sing a couple of verses of The Engineer's Drinking Song between drinking games.

We are, we are, we are, we are, we are the Engineers
We can, we can, we can, we can, demolish forty beers
Drink rum, drink rum, drink rum all day, and come along with us
'Cause we don't give a damn for any old man who don't give a damn for us!

Godiva was a lady well-endowed there is no doubt
She never wore a stitch of clothes, just wound her hair about
The first man who did make her was a Engineer, of course,
But on just one beer an artsie queer had made Godiva's horse

An MIT surveyor once found the gates of Hell
He looked the devil in the eye, and said "You're looking well"
The devil looked right back at him, and said "Why visit me -
You've been through Hell already; you went to MIT!"

An artsman and an Engineer once found a gallon can
Said the artsman, "Match me drink for drink, let's see if you're a man."
They drank three drinks, the artsman fell, his face was turning green
But the Engineer drank on and said, "It's only gasoline!"

An Engineer once stumbled through the halls of Building 10
That night he'd drunken rum enough to drown a dozen men
In fact, the only things there were that kept him on his course
Were the boundary conditions and the Coriolis force

An MIT computer man got drunk one fateful night
He opened up the console and smashed everything in sight
When they finally subdued him, the judge he stood before,
Said, "Lock him up for twenty years, he's rotten to the core!"

Here are a few links about it->
1
2
3

I certainly find audiopad much more interesting than these three. Be sure to watch the audiopad video, which illustrates its impressive projector_integrated interface. Definately the coolest electronic performance tool I've seen.

what about audiopad??

that is the sickest thing i've ever seen.

Isn't the Doc supposed to be in the next Spiderman movie?

Has anyone seen OpenGov MIT Project ? What is it with all this uncovering business, can't the creatures at MIT leave our act of a society alone?

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

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

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

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

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

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

The Remembrance Agent is an Emacs add-in that does mostly what Nat's tools seems to be supposed to do : "The Remembrance Agent (RA) is a program which augments human memory by displaying a list of documents which might be relevant to the user's current context. Unlike most information retrieval systems, the RA runs continuously without user intervention. Its unobtrusive interface allows a user to pursue or ignore the RA's suggestions as desired". Nice concept, but since the original is mostly tied to Emacs, a modern implementation would sure be quite welcome.

Reminds me of haystack which was dismissed as been-there-seen-that when it was discussed here. I think there might be a place for these things -- but where?

once again, lame technologies seek to imitate what the One True Editor has been able to do for years.

next!

In March 1995, the 1st US Circuit Court of Appeals overturned the 1993 decision of Judge Keeton of Boston in Lotus' lawsuit against Borland. Lotus sued Borland for copyright infringement on Lotus 1-2-3. In its decision the appeals court determined that Lotus' menu structures, incorporated into Borland's Quatro Pro spreadsheet, are "an uncopyrightable method of operation".

In March 1995, the 1st US Circuit Court of Appeals overturned the 1993 decision of Judge Keeton of Boston in Lotus' lawsuit against Borland. Lotus sued Borland for copyright infringement on Lotus 1-2-3. In its decision the appeals court determined that Lotus' menu structures, incorporated into Borland's Quatro Pro spreadsheet, are "an uncopyrightable method of operation".

William Freeman has a good page on his MIT AI lab homepage about doing the same thing except using kites to take pictures. (Btw, check out William T Freemans MIT e-mail address...)
http://www.ai.mit.edu/people/wtf/kite.html

And another link to a good site is Charles Benton's site.
http://www.arch.ced.berkeley.edu/kap/

Its interesting to note that there are lots of methos for creating unstructured panoramas. Where you have a set of images and the algorithm does its best to determine how to stick the images together to form a panorama. You could imagine a similar algorithm using these images to auotmatically create aerial maps... might make a good paper.

Kite Aerial Photography
Mosaics of kite aerial photographs
Aerial photography using a balloon at Burning Man
Other types of aerial photography (balloon, helicopter, kite, even periscope!)

Actually, I think a check-in/check-out system for having members listen to music would work. MIT already has a beta version of this called LAMP (Library Access to Music Project) that's been pretty good. If only they'd get more CDs.

I think the thing that would make something like this less legally sketchy is if the number of people playing a particulary song/album is equal to the number of copies owned by the organization. I.e. the "company" would have to buy more copies of the popular stuff, but only 1-2 of the obscure stuff. If they only have 10 copies of your favorie album and 10 people are currently listening to it, you're out of luck.

I see little difference between a piece of land and a piece of music.

Ha. Ha ha ha. Ha, ha ha ha, ha ha ha ha ha ha ha.

You apparently suffer the mental aberration called synesthesia.

Me, I can't see a piece of music at all. Or touch it, feel it, or especially hold it.

Property, by definition, can only be used by a limited number of people at once. Once written, music is not like that.

I'm not a capitalist but doesn't capitalism and free markets call for strong property rights?

There are two conflicting definitions of capitalism. Both are valid, but one (the more "Liberal" interpretation) calls for external intervention to enable competition, even overriding property rights. (This is the justification for anti-monopoly laws, which violate the sancity of property)

You just can't quickly record mathematical symbols or graphical diagrams with a computer. Classroom use may become more justified when handwriting recognition software matures, but currently there is no good reason to bring a laptop to class.

This isn't necessarily true anymore with the introduction of Tablet PCs. One of MIT's Brain and Cognitive Sciences classes, 9.01, is issuing "e-tablets" to its students for the purposes of notetaking. From what I've seen of tablet PCs (played with a few in stores), they seem pretty effective for taking notes.

For one thing, it's nice to have an assortment of colors all in one normal sized pen. In one engineering class I took sophomore year (Unified, for those at MIT who'd understand), I carried around a set of 6 color pencils without which it would've been impossible to copy the complex diagrams presented in lecture in a way I could be able to decipher later. (The profs tended to draw these on the spot using a set of color chalk.) I'm certain a tablet PC would've made that process worlds easier.

The way that AI is headed, I think that there may be robots that will be able to to menial work, e.g. cook, clean, build, etc. I don't think that AI will become an actual intelligence for some time.

An artifical intelligence is able to invent new things is something that may take much longer.

Although, I think that some researchers have realize what it is that made humans want to leard; Physical and Emotional needs. For all we know one of these needs driven robots could develop a more advanced intelligence than humans.

• Kismet
• Meet Kismet...
• Robot Learning Driven by Emotions
• AGI Project Phase-Overview
• Emotional and Intelligent: The Tangled Knot of Cognition

Whish I had seen this thread earlier. Oh well if you make it to Boston be sure to check out the following:

MIT Computer Flea Market while you are there you will surely meet somone who will be willing you to help you explore the MIT Steam tunnels but before you go be sure to walk down the street to were Alexandar Graham Bell invented the telephone.

Then of course is the Boston Museum of Science.

- SR

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

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

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

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

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

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

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

MIT also has the Media Lab, and that monstrosity that is their new ugly as sin CS complex. And If you're at Harvard, you should stop by and see the piece of the the Mark I computer that's sitting in the Science Center.

BTW, it seems every college is getting those shirts. I have one of the "because not everybody can get into MIT" shirts, but my friend has a "Harvard... because not everybody can get into Brown" and I have another friend with a the same thing for Dartmouth. Any others out there?

Don't forget the W3C, which has its main office at MIT's Laboratory for Computer Science!

Memphis is a good place to go to get away from too much tech. But that doesn't mean that it can't be fun, quirky, or even geeky.

For instance, A. Schwab's on Beale street has been home to millions of items of questionable utility since 1876. Get your "voodoo powders, handcuffs, clerical collars, saucepans and the largest collection of hats in town" from one of the "cousins" who run the store now.

If you do decide to go to Graceland, consider going for Elvis Week, lovingly called "Death Week" by the locals. It's August 9 - 17, peaking during the candle light vigil on the 15th. It's much more lively during this week than others. You can go to things like the (unofficial) Elvis Impersonator's Contest or the mostly locals only Dead Elvis Ball at the P&H Cafe.

Of course for a real "experience" you need to visit Graceland Too in Holly Springs, Mississippi. This place is everything that Graceland isn't and somehow more. You can come 24 hours a day, 7 days a week, so there's no excuse. You'll go, right? Paul McLeod, who lives in Graceland Too and gives the tours, is a character who's collected more junk, err, memorabilia, about Elvis than he knows what to do with. He kept saying that people showed up at 3 am in a limo with girls in bikinis and a man dressed up in a banana suit every 5 minutes during the first half of the tour. Then he pull out a picture of a limo in front of Graceland Too with a guy in a banana suit...so maybe we should believe him when he says he records every channel of television and makes note of every Elvis reference. Or maybe not.

Oh, and one last thing, if you can't get enough of this kind of thing, you should really hop on over to Joni Mabe, the Elvis Babe's Museum which includes a wart of Elvis' as well as pieces that might be his toe nail. It's in Athens, Georgia.

There is geeky history , other geeks,fun tours, funner tours and of course 100k college students 7/13ths of whom are female.

And if you want to stay, make sure to stop buy one of the millions of awesome high tech firms in the area.

I don't - it's right outside my window :-)

265 Massachusetts Ave Cambridge, MA

http://web.mit.edu/museum/

And while you're at it, come walk around the MIT campus. I hear tell there's also some kind of finishing school farther up Massachusetts Ave, but it's not really worth visiting.

Boston, Massachusetts and its environs are filled with incredibly geeky things. Boston is the home of the Free Software Foundation, Ximian, and OSDN. Just across the river, Cambridge is the home of the Massachusetts Institute of Technology, undeniably a geek Mecca. Next door to MIT is Harvard University (as the MIT t-shirts say, "Harvard: Because not everybody can get in to MIT"). Plus we've got the Big Dig, which despite its infamy for budget overruns, corruption, and defacement of the city landscape, is also home to some incredibly geeky marvels of engineering! And of course, many other geeks of note live and work in and around Boston.

> (and really, of Boston schools, BU has the share of weapon related defense grants)

Wrong.

See MIT Lincoln Laboratory - it's awwwllll government and weapons stuff...

How about the official mit news release here.
It better explains what they are really doing.

MIT is less than anxious to turn over the name and address of the user robotrodney@KaZaA.

I could even call the toilet to see if anyone is using it.

MIT got there first: http, finger.

I could even call the toilet to see if anyone is using it.

MIT got there first: http, finger.

It's the mob mentality: democracy at its very worst.

Actually non-violent civil disobedience as a riot or mob has a long history in promoting social change in democracies (and non-democracies).

Here's some info on it.

There's a lot more out there on the subject as well.

It's interesting because this could be viewed as an internet riot of sorts (although relatively low intensity and chronic) as the people involved are breaking the law.

The question is are most people doing this fully informed and opposing the issues involved or is it just an issueless excuse to 'loot', or are they not even aware that they're 'rioting' or are just going along with the crowd.

I would put forth that there are all of those different groups involved, and possibly there are in any crowd or mob action.

As far as confronting this concentration of power, something inspiring to watch is how a powerful music industry can be held accountable by the power of just regular folks and their computers. Similarly, the Government Information Awareness program was very inspiring.

my friend brian built the thing. he's reading this over my shoulder, so here's what he says:

"to be honest, they kinda blew it out of proportion. it doesn't have much to do with microfluidics. after building a water strider, i wanted to make a snail =b"

here's a link to a couple of his other projects

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

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

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

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents [theos.com] 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.

Government Information Awareness
here

John Conyers fact sheet:

here

Howard Berman fact sheet:

here

Government Information Awareness
here

John Conyers fact sheet:

here

Howard Berman fact sheet:

here

Government Information Awareness
here

John Conyers fact sheet:

here

Howard Berman fact sheet:

here

• http://open-gov.media.mit.edu/DBD/CACHE/0000/000/4 00/025/

• http://open-gov.media.mit.edu/DBD/CACHE/0000/000/4 00/080/

• http://open-gov.media.mit.edu/DBD/CACHE/0000/000/4 00/025/

• http://open-gov.media.mit.edu/DBD/CACHE/0000/000/4 00/080/

Kindly see who supports (with $$$) Mr. Berman.

Entertainment Industry: $204,291.00
Legal Firms: $109,600.00

surprise, surprise. opengov coming in handy, once again

Byzantine fault tolerance (BFT) is a "traditional" distributed systems technique that enables intrusion resilience. BFT replicates a service such that the service continues to work correctly as long as less than one third of the replicas are comprimised. Combined with proactive recovery (periodically shutting down replicas and restarting them from a read-only disk), this can enable the system to survive an arbitrary number of compromises over its lifetime.

This is similar to research being done at MIT in the Computer Architecture Group by Martin Rinard and his graduate student Brian Demsky. They are building and researching ways to automatically detect and repair data structure errors so that if a programs data structures get corrupted their tool will repair the heap so the program can keep running.

There was related work done like this back in the day at AT&T but Rinard and Demsky have introduced automatic repair which, as you might imagine like this security idea, is scary to some people. Imagine a program that would have crashed due to some bug or malicious data mangling, now kept running by a tool... But the tool chooses the repair actions based on heuristics and specifications by the developer... takes some getting used to!

All of this stuff falls under fault tolerance... its pretty crazy to look at what the AT&T/Lucent Phone Switches do when they fail... they try a million different things to keep operating no matter what happens...

This is similar to research being done at MIT in the Computer Architecture Group by Martin Rinard and his graduate student Brian Demsky. They are building and researching ways to automatically detect and repair data structure errors so that if a programs data structures get corrupted their tool will repair the heap so the program can keep running.

There was related work done like this back in the day at AT&T but Rinard and Demsky have introduced automatic repair which, as you might imagine like this security idea, is scary to some people. Imagine a program that would have crashed due to some bug or malicious data mangling, now kept running by a tool... But the tool chooses the repair actions based on heuristics and specifications by the developer... takes some getting used to!

All of this stuff falls under fault tolerance... its pretty crazy to look at what the AT&T/Lucent Phone Switches do when they fail... they try a million different things to keep operating no matter what happens...

This is similar to research being done at MIT in the Computer Architecture Group by Martin Rinard and his graduate student Brian Demsky. They are building and researching ways to automatically detect and repair data structure errors so that if a programs data structures get corrupted their tool will repair the heap so the program can keep running.

There was related work done like this back in the day at AT&T but Rinard and Demsky have introduced automatic repair which, as you might imagine like this security idea, is scary to some people. Imagine a program that would have crashed due to some bug or malicious data mangling, now kept running by a tool... But the tool chooses the repair actions based on heuristics and specifications by the developer... takes some getting used to!

All of this stuff falls under fault tolerance... its pretty crazy to look at what the AT&T/Lucent Phone Switches do when they fail... they try a million different things to keep operating no matter what happens...

I use Netscape as my default browser because Netscape 7.02 is the MIT recommend web browser! Until recently MIT employees couldn't get and use a personal certificate with Internet Explorer, meaning you had to use Netscape to access web applications here. Now using Netscape is just a habit.

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

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

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

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

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

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

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

The Robosnail page suggests they will next be looking at undulating movements. But galloping on one foot would be more interesting - it's how snails leave footprints.