Slashdot Mirror

If you're at say Princeton, Stanford or MIT I daresay the lectures (e.g. 18.01 18.014 18.01a ) are plenty fast enough thanks.

If you're at say Princeton, Stanford or MIT I daresay the lectures (e.g. 18.01 18.014 18.01a ) are plenty fast enough thanks.

If you're at say Princeton, Stanford or MIT I daresay the lectures (e.g. 18.01 18.014 18.01a ) are plenty fast enough thanks.

No Shit!

On a related note, does this remind anyone else of those old "luggable" proto-laptops of the late 80s? I remember all those ads in Byte pronouncing the joys of "35 easy-to-lug pounds of blazing 80286 action, at a whopping 4Mhz! All for $7999!" I mean, come back when you have something that doesn't look like a bunch of parts thrown together on a vest.

Hi Carolyn. How are things? :-)

There is real content on the web, especially if you're willing to pay. Encyclpedia Britannica, for instance. I also ran across a URL the other day that was free, but seemed to have a lot of interesting information (if perhaps sometimes of dubious origin. This is the first article I read, regarding aerospike engines..

There is plenty of good scientific content (I think it's a bit much to lump it in as geekery related to computers;) on the web at sites like fas.org, newscientist.com and many more technical examples (spie.org for instance).

There is a ton of sports, travel and hobby related info on the web. It pays to do a little research before believing any given opinion, but you can usually shortly arrive at a pretty good understanding of a given topic.

I was also pleased to see the recent release of a bunch of MIT courseware to the web. More colleges and universities should follow that lead!

One of MIT's main goals with OCW is to provide course materials for other universities. OCW's primary mission is not to provide a free education to individuals with internet access, though there is nothing in their policy that prevents it. The real winners from OCW will be institutes of higher learning that can now use the OCW material as a basis for creating their own university courses. Obviously universities in poorer countries can benefit greatly from OCW.

About a year ago, when OCW was first being accounced, I attended a presentation by a MIT official who explained OCW and some of the issues behind it. He also explained that there was some resistance by professors, which mainly fell into the following areas:

1. Concern over intellectual property and copyright issues.

2. Concern that the professors would not have enough time, to prepare OCW versions of their courses, given their present research and teaching responsibilities.

3. Concern that the material presented via OCW would be of high quality and worthy of MIT.

You will note that OCW, in its early stages, will probably consist of a wide variety of items in strange and incompatible formats, hopefully coalescing over time into a more unified body of information. This is deliberate. MIT has a policy of never specifying too many details. In OCW's case, this means that MIT is not specifying how the material must be technically presented or formatted, knowing that the best ideas will bubble up as MIT's creative minds ship away at the problem. Indeed another goal of OCW is to find better ways to use the internet to enhance the learning experience. In some ways, OCW's journey is also it's destination, with the hope of finding something interesting along the way.

This approach, is what lead to the creation of X (and a ton of other cool stuff) as a spinoff of the Athena project. There the stated goal was (somewhat simplified):

• We have a bunch of different computers, let's connect them all together in a network, in spite of the different hardware and operating systems.

Not a bad idea for those with an abundance of time (I have a 2.5-year-old to take care of and entertain, so I wouldn't be able to take advantage of this).

The death of Captain James Cook at Kealakekua Bay, Hawaii. (Archival photograph by Sean Linehan, courtesy of the National Oceanic and Atmospheric Administration.)

Documentary photographers on 18th century exploring ships?

On the other hand, circuits and electronics also has exams, labs, and lecture notes.

What I want to know is though - where are the answers? ;-)

On the other hand, circuits and electronics also has exams, labs, and lecture notes.

What I want to know is though - where are the answers? ;-)

Quantitative Physiology is taught by Denny Freeman who took over the course from his advisor Tom Weiss who wrote an excellent two volume textbook on 'Cellular Biophysics'. The first volume is on 'Transport' and the second is on 'Electrical' properties. The text takes an approach which is based on the physical interpretation of the time evolution of the solutions to the governing differential equations (good stuff for EECS types who are interested in Signals & Systems).

The course stems from a nearly 50 year research program in 'Auditory Physiology' at the Research Laboratory of Electronics. The 'engineers' who were trained at RLE learned to apply the quanitative methods of engineering and the physical sciences to biological problems. Inside of RLE, both Tom and Denny where trained in the inter-institutional Eaton-Peabody Laboratory, which served as the training ground of for dozens of well known researchers (including the founder of the Biomedical Engineering Department at Johns Hopkins). The modern version of this training philosophy is characterized by the HST Speech and Hearing Bioscience and Technology Program.

Quantitative Physiology is taught by Denny Freeman who took over the course from his advisor Tom Weiss who wrote an excellent two volume textbook on 'Cellular Biophysics'. The first volume is on 'Transport' and the second is on 'Electrical' properties. The text takes an approach which is based on the physical interpretation of the time evolution of the solutions to the governing differential equations (good stuff for EECS types who are interested in Signals & Systems).

The course stems from a nearly 50 year research program in 'Auditory Physiology' at the Research Laboratory of Electronics. The 'engineers' who were trained at RLE learned to apply the quanitative methods of engineering and the physical sciences to biological problems. Inside of RLE, both Tom and Denny where trained in the inter-institutional Eaton-Peabody Laboratory, which served as the training ground of for dozens of well known researchers (including the founder of the Biomedical Engineering Department at Johns Hopkins). The modern version of this training philosophy is characterized by the HST Speech and Hearing Bioscience and Technology Program.

Quantitative Physiology is taught by Denny Freeman who took over the course from his advisor Tom Weiss who wrote an excellent two volume textbook on 'Cellular Biophysics'. The first volume is on 'Transport' and the second is on 'Electrical' properties. The text takes an approach which is based on the physical interpretation of the time evolution of the solutions to the governing differential equations (good stuff for EECS types who are interested in Signals & Systems).

The course stems from a nearly 50 year research program in 'Auditory Physiology' at the Research Laboratory of Electronics. The 'engineers' who were trained at RLE learned to apply the quanitative methods of engineering and the physical sciences to biological problems. Inside of RLE, both Tom and Denny where trained in the inter-institutional Eaton-Peabody Laboratory, which served as the training ground of for dozens of well known researchers (including the founder of the Biomedical Engineering Department at Johns Hopkins). The modern version of this training philosophy is characterized by the HST Speech and Hearing Bioscience and Technology Program.

Quantitative Physiology is taught by Denny Freeman who took over the course from his advisor Tom Weiss who wrote an excellent two volume textbook on 'Cellular Biophysics'. The first volume is on 'Transport' and the second is on 'Electrical' properties. The text takes an approach which is based on the physical interpretation of the time evolution of the solutions to the governing differential equations (good stuff for EECS types who are interested in Signals & Systems).

The course stems from a nearly 50 year research program in 'Auditory Physiology' at the Research Laboratory of Electronics. The 'engineers' who were trained at RLE learned to apply the quanitative methods of engineering and the physical sciences to biological problems. Inside of RLE, both Tom and Denny where trained in the inter-institutional Eaton-Peabody Laboratory, which served as the training ground of for dozens of well known researchers (including the founder of the Biomedical Engineering Department at Johns Hopkins). The modern version of this training philosophy is characterized by the HST Speech and Hearing Bioscience and Technology Program.

Quantitative Physiology is taught by Denny Freeman who took over the course from his advisor Tom Weiss who wrote an excellent two volume textbook on 'Cellular Biophysics'. The first volume is on 'Transport' and the second is on 'Electrical' properties. The text takes an approach which is based on the physical interpretation of the time evolution of the solutions to the governing differential equations (good stuff for EECS types who are interested in Signals & Systems).

The course stems from a nearly 50 year research program in 'Auditory Physiology' at the Research Laboratory of Electronics. The 'engineers' who were trained at RLE learned to apply the quanitative methods of engineering and the physical sciences to biological problems. Inside of RLE, both Tom and Denny where trained in the inter-institutional Eaton-Peabody Laboratory, which served as the training ground of for dozens of well known researchers (including the founder of the Biomedical Engineering Department at Johns Hopkins). The modern version of this training philosophy is characterized by the HST Speech and Hearing Bioscience and Technology Program.

Quantitative Physiology is taught by Denny Freeman who took over the course from his advisor Tom Weiss who wrote an excellent two volume textbook on 'Cellular Biophysics'. The first volume is on 'Transport' and the second is on 'Electrical' properties. The text takes an approach which is based on the physical interpretation of the time evolution of the solutions to the governing differential equations (good stuff for EECS types who are interested in Signals & Systems).

The course stems from a nearly 50 year research program in 'Auditory Physiology' at the Research Laboratory of Electronics. The 'engineers' who were trained at RLE learned to apply the quanitative methods of engineering and the physical sciences to biological problems. Inside of RLE, both Tom and Denny where trained in the inter-institutional Eaton-Peabody Laboratory, which served as the training ground of for dozens of well known researchers (including the founder of the Biomedical Engineering Department at Johns Hopkins). The modern version of this training philosophy is characterized by the HST Speech and Hearing Bioscience and Technology Program.

Quantitative Physiology is taught by Denny Freeman who took over the course from his advisor Tom Weiss who wrote an excellent two volume textbook on 'Cellular Biophysics'. The first volume is on 'Transport' and the second is on 'Electrical' properties. The text takes an approach which is based on the physical interpretation of the time evolution of the solutions to the governing differential equations (good stuff for EECS types who are interested in Signals & Systems).

The course stems from a nearly 50 year research program in 'Auditory Physiology' at the Research Laboratory of Electronics. The 'engineers' who were trained at RLE learned to apply the quanitative methods of engineering and the physical sciences to biological problems. Inside of RLE, both Tom and Denny where trained in the inter-institutional Eaton-Peabody Laboratory, which served as the training ground of for dozens of well known researchers (including the founder of the Biomedical Engineering Department at Johns Hopkins). The modern version of this training philosophy is characterized by the HST Speech and Hearing Bioscience and Technology Program.

A lot of the course notes aren't particularly useful without a teacher actually explaining things to you. [...] While some of the notes may be useful and educational, I don't think it replaces a real, live professor explaning things and available to answer questions.

Well, no, but then replacing real, live professors is not the point. I consider it, in part, an FM to R before hastling a person with ignorant questions.

Case in point: I discovered that a topic I'm interested is considered an obscure sub-branch of the field of anthropology. I have friends who are anthropologists, and they're happy to answer my questions until the cows come home (and talk about their research until long after that), but the one question they don't have a handy answer to and never have time to work up is this:

What are the foundational texts of this field, which I have to read to get just enough broad overview (to then be able to follow the specialty discussions I'm interested in), and to provide me with a "score-card" of "schools of thought" so I can keep track to the sides in various academic debates?

In short, I needed the syllabus and bibliography of a "Anthropology 101" undergrad course, which focused on theory and not practice. Lo! I have all I requested.

However, programming is distinctly different from computer science. In programming, you want to know exactly how to code--how to create classes, what pointers go where, etc. In computer science, you are trying to understand the way the computer operates and manipulates data ("thinks", as it were), so that you know how to code effectively. Scheme is frequently used as a language in introductory computer science classes because it is a very good language for teaching these concepts. That's why it's used in 6.001.

Also, Scheme is a LISP variant, and the mechanics of LISP and its close cousins make them the languages of choice in the field of artificial intelligence. You probably wouldn't want to, say, write a webserver in Scheme (although a friend of mine once did...), but it is, in fact, a good choice for 6.034 or actual work in the AI field. (A different friend of mine, a CS graduate student working on an AI project, absolutely swears by CommonLISP as the best computer language known to man.)

However, programming is distinctly different from computer science. In programming, you want to know exactly how to code--how to create classes, what pointers go where, etc. In computer science, you are trying to understand the way the computer operates and manipulates data ("thinks", as it were), so that you know how to code effectively. Scheme is frequently used as a language in introductory computer science classes because it is a very good language for teaching these concepts. That's why it's used in 6.001.

Also, Scheme is a LISP variant, and the mechanics of LISP and its close cousins make them the languages of choice in the field of artificial intelligence. You probably wouldn't want to, say, write a webserver in Scheme (although a friend of mine once did...), but it is, in fact, a good choice for 6.034 or actual work in the AI field. (A different friend of mine, a CS graduate student working on an AI project, absolutely swears by CommonLISP as the best computer language known to man.)

However, programming is distinctly different from computer science. In programming, you want to know exactly how to code--how to create classes, what pointers go where, etc. In computer science, you are trying to understand the way the computer operates and manipulates data ("thinks", as it were), so that you know how to code effectively. Scheme is frequently used as a language in introductory computer science classes because it is a very good language for teaching these concepts. That's why it's used in 6.001.

Also, Scheme is a LISP variant, and the mechanics of LISP and its close cousins make them the languages of choice in the field of artificial intelligence. You probably wouldn't want to, say, write a webserver in Scheme (although a friend of mine once did...), but it is, in fact, a good choice for 6.034 or actual work in the AI field. (A different friend of mine, a CS graduate student working on an AI project, absolutely swears by CommonLISP as the best computer language known to man.)

Many of them use texts which are listed and anyone is perfectly capable of buying from Amazon...

eg. 6.170 Software Engineering

Rob :)

To clarify, Biomedical Engineering is only a possible undergraduate minor, although there are musings that it may be expanded as a new major. BME could indeed fit in many categories--it was developed by faculty from Aero-astro, Biology, Chem. E, Mech. E., Nuclear E., EECS, and Health Science & Technology departments.

Hilarious!

Seriously, this MIT project is a great resource.

Some of them have audio as well. Besides, any amount of free education is good, as far as I'm concerned.

...and it's great! I'm stuck in a shitty little comm. coll. here where everything is "learn how to use vendor x's program y" and it stinks. I told several profs to their faces now that I'm not coming to any classes when we're not taking a test because there's nothing that I can learn there that I care about or that matters.

With the Open CourseWare site though, I've started plugging my way through an almost complete cirriculum! I finally got the motivation to learn Java so I could use it in the 6-170 course. The content, organization, and overall structure of the course is incredible (6-170 is by far one of the best classes I've ever had in any subject at any school with any professor ever)! I'm looking forward to following it into the next class I work through on OCW.

There's no way I can afford to go to MIT - as much as I would love to - but with OCW, at least I can benefit from a great deal of their wisdom with some elbow grease, even without the cash.

Course Description

This course explores the properties of non-sequential, multi-linear, and interactive forms of narratives as they have evolved from print to digital media. Works covered in this course range from the Talmud, classics of non-linear novels, experimental literature, early sound and film experiments to recent multi-linear and interactive films and games. The study of the structural properties of narratives that experiment with digression, multiple points of view, disruptions of time, space, and of storyline is complemented by theoretical texts about authorship/readership, plot/story, properties of digital media and hypertext. Questions that will be addressed in this course include: How can we define 'non-sequentiality/multi-linearity', 'interactivity', 'narrative'. To what extend are these aspects determined by the text, the reader, the digital format? What are the roles of the reader and the author? What kinds of narratives are especially suited for a non-linear/interactive format? Are there stories that can only be told in a digital format? What can we learn from early non-digital examples of non-linear and interactive story telling?

Overall, though, I have to say that the information available on the classes is a bit thin --- didn't they get a multi-million dollar grant to put this together?

The news is that they reached the 500-course mark, not that they opened up the library. That news was released yesterday.

In case you're wondering, the Wired article (printed in the Semptember issue) is here, and the September OpenCourseWare newsletter is here. At the time that it was published, OCW only offered 262 courses. I agree that MIT adding more courses to OCW isn't exactly earthshattering news, but it is a recent thing.

For anyone interested in the MIT course 6.004 Computation Structures: the lectures are very similar to ArsDigita University's "How Computers Work".

ArsDigita University put all its lectures online in realvideo format. Here's mirror of the "How Computers Work" course.

A better way to put it would be that the marginal cost of making information available once it's produced is free, and that the best we can hope for is that schools will make pre-existing information available for free. Whether this works as a business model will depend on whether the "value added" by the educational environment of actually attending an institution makes up for the cost of tuition.

The optimist in me says 'I always wanted to know more about the adiabatic approximation and Berry's phase.' The pessimist says 'methinks this will only lead to an increase in the number of people who think they know what they are talking about.'

You left out the part where you used an open proxy and spoofed an @mit.edu email account.
Do not even think about emailing me again you bastard.

- Noam Chomsky

Just what the world needed! Free Nuclear Engineering classes! From the comfort of your own 3rd world country!

A lot of the course notes aren't particularly useful without a teacher actually explaining things to you. For example, look at the following link .
While some of the notes may be useful and educational, I don't think it replaces a real, live professor explaning things and available to answer questions.

Do they have courses on shutting up Chomsky?

Would your grenade fit the payload requirements for something like this?

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.

As the classroom becomes more digital, I predict we'll see a strong move to "courseware" as opposed to simple digital versions of textbooks. One reason (among many) is that courseware is easy to do in the form of "software as service" and thus has little worry about unauthorized copying. But some people are doing courseware that may be freely copied and reused. Check out MIT OpenCourseWare and the Rice Connexions Repository.

Also, why not collaborative creation of textbooks using a Wikipedia model?

Unfortunately the article is premised on a classic economic fallacy: that advances in technology and efficiency result in net job loss. For a good debunking, see Paul Krugman's review of William Greider's "One World, Ready or Not: The Manic Logic of Global Capitalism".

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.

Walking robots have been around for over 20 years. I worked on a running biped at the MIT Leg Lab in 1990. According to the timeline Miura and Shimoyama had the first actively balancing biped in 1981. The cutting edge of research would be to walk more efficiently (i.e. low energy per foot walked), to walk on rough terrain, to navigate stairs, to couple with sonar or vision sensors... In other words, basic walking is solved, but doing anything useful with it is still a tough problem.

Walking robots have been around for over 20 years. I worked on a running biped at the MIT Leg Lab in 1990. According to the timeline Miura and Shimoyama had the first actively balancing biped in 1981. The cutting edge of research would be to walk more efficiently (i.e. low energy per foot walked), to walk on rough terrain, to navigate stairs, to couple with sonar or vision sensors... In other words, basic walking is solved, but doing anything useful with it is still a tough problem.

Walking robots have been around for over 20 years. I worked on a running biped at the MIT Leg Lab in 1990. According to the timeline Miura and Shimoyama had the first actively balancing biped in 1981. The cutting edge of research would be to walk more efficiently (i.e. low energy per foot walked), to walk on rough terrain, to navigate stairs, to couple with sonar or vision sensors... In other words, basic walking is solved, but doing anything useful with it is still a tough problem.

What We Can Learn From BSD

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

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

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

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

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

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

What We Can Learn From BSD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the 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.

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.

Why couldn't we put this lab in orbit?

The main reason is that the effect is so weak. A mission concept called LISA is being studied by ESA and NASA. The idea is to have 6 spacecraft orbiting the Sun, which together form a interferometer several million kilometers in size. The catch: Because the waves are so weak, the distances between these spacecraft would need to be controlled to within about a nanometer (!) to have any hope of detecting a signal. Needless to say a VERY challenging mission.

A lot of other interesting missions would be enabled by good formation flight technology. Look at NASA's Terrestrial Planet Finder mission, or the ESA's similar Darwin mission.

Try MIT world they video lectures and presentations by current and former MIT professors.