Slashdot Mirror

the really huge multi-panel display outside of toys 'r us in times square.

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.

Well... there was the naming computers after fruits phase that made me question Mac users sexuality

Okay, now I think I may have a clearer idea of why you may think of mac users as 'teh ghey', but I stand by my claim that there is NO commonality (sexual, political or otherwise) amongst mac users... except for a ruthless efficiency and fanatical devotion to the pope... But as to the naming of a computer comany after a fruit...has to do mostly with the bizarre dietary habits of Steve Jobs. Now he is the strictest of vegetarians...a VEGAN! The most dreaded strain of vegetarian at all. BUT before Steve-O was a vegetarian of any stripe he was a fruitarian. As far as I understand (I am an Atkins practicioning carnivour, and not a vegetarian or especially a "fruitarian") fruitairians not only eat only fruit...it is prohibited by some sects to eat any fruit that has not dropped naturally to the ground from the vine. NO HAND PICKING or OFF THE DAMN DIRTY HIPPY COMMUNE YOU GO!!! :) Before Jobs started Apple, he lived for a while on a Fruitarian commune in Oregon. Many suppose that it was this experience that lead to the naming of the now famous computer company.

Actually, as I google around, I find this supposedly direct quote:

I was actually a fruitarian at that point in time. I ate only fruit. Now I'm a garbage can like everyone else. And we were about three months late in filing a fictitious business name so I threatened to call the company Apple Computer unless someone suggested a more interesting name by five o'clock that day. Hoping to stimulate creativity. And it stuck. And that's why we're called Apple.

Well... there was the naming computers after fruits phase that made me question Mac users sexuality

Okay, now I think I may have a clearer idea of why you may think of mac users as 'teh ghey', but I stand by my claim that there is NO commonality (sexual, political or otherwise) amongst mac users... except for a ruthless efficiency and fanatical devotion to the pope... But as to the naming of a computer comany after a fruit...has to do mostly with the bizarre dietary habits of Steve Jobs. Now he is the strictest of vegetarians...a VEGAN! The most dreaded strain of vegetarian at all. BUT before Steve-O was a vegetarian of any stripe he was a fruitarian. As far as I understand (I am an Atkins practicioning carnivour, and not a vegetarian or especially a "fruitarian") fruitairians not only eat only fruit...it is prohibited by some sects to eat any fruit that has not dropped naturally to the ground from the vine. NO HAND PICKING or OFF THE DAMN DIRTY HIPPY COMMUNE YOU GO!!! :) Before Jobs started Apple, he lived for a while on a Fruitarian commune in Oregon. Many suppose that it was this experience that lead to the naming of the now famous computer company.

Actually, as I google around, I find this supposedly direct quote:

I was actually a fruitarian at that point in time. I ate only fruit. Now I'm a garbage can like everyone else. And we were about three months late in filing a fictitious business name so I threatened to call the company Apple Computer unless someone suggested a more interesting name by five o'clock that day. Hoping to stimulate creativity. And it stuck. And that's why we're called Apple.

Unless you believe there is something inherently "magical" about human beings (i.e., we have a soul) then we are simply following the laws of physics which determine how the matter and energy in our bodies will behave.

To say that we "follow" the laws of physics gives a misleding connotation. Physical "law" decribes how things act, it doesn't determine how things act.

If there were something about human beings such that the matter that makes up our bodies behaved differently than matter ourside of bodies (which I'm not asserting, BTW), it wouldn't be a violation of physical law, but an indication that our physical laws are an inaccurate description of the Universe. The Universe knows not of Maxwell's equations (or even of particles, energy, mass, and other human ideas); it just does its thing. Which happens to include bits of it forming into patterns (us) that make other patterns (words), some of which encode information about patterns in the thing (ideas like Maxwell's equations)...

For futher clarification, I recommend Raymond Smullyan's Is God A Taoist? (Stumbling upon this essay in Hofstadter and Dennett's The Mind's I changed my life.)

Actually X provides a mechanism for supporting every conceivable datatype; anyone can define a property using XInternAtom() and XChangeProperty() on an X-Window in your X application or on the root window, encoding an arbitrary datatype into the bits of the property. This is all fully described in the X design documentation. especially in Xlib C Programming X Interface, Chapter 4, Section 4.3 . See also the source code for xprop.c for a detailed example of how to use X properties.

Conclusion: You don't have to change the API of X. X is already very extendable.

Actually X provides a mechanism for supporting every conceivable datatype; anyone can define a property using XInternAtom() and XChangeProperty() on an X-Window in your X application or on the root window, encoding an arbitrary datatype into the bits of the property. This is all fully described in the X design documentation. especially in Xlib C Programming X Interface, Chapter 4, Section 4.3 . See also the source code for xprop.c for a detailed example of how to use X properties.

Conclusion: You don't have to change the API of X. X is already very extendable.

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.

Link. Not all the courses have lecture notes or othe useful stuff in them yet. When dig deeper into each course's links you may notice a nav bar on the left of the screen. Many of the courses have the "Lecture Notes" section there.

If you cross a chameleon with a cow, do you get cow that changes it spots when it senses danger?

They will change from a holstein to a jersey. If the chameleon blood is particularly powerful, it may morph into an angus.

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.

Thanks to the excellent voodo1man! Some citations:

• Lambda: the Ultimate Imperative
• LAMBDA: The Ultimate Declarative
• Lambda: The Ultimate GOTO

Thanks to the excellent voodo1man! Some citations:

• Lambda: the Ultimate Imperative
• LAMBDA: The Ultimate Declarative
• Lambda: The Ultimate GOTO

Thanks to the excellent voodo1man! Some citations:

• Lambda: the Ultimate Imperative
• LAMBDA: The Ultimate Declarative
• Lambda: The Ultimate GOTO

In terms of pure science and academa, a few have been reasonably covered here already. A few from my personal library:

Anything from Donald Knuth

Andrew Tannenbaum and most of his publications

The greatest fundamental contributor to all great science, however, is inspiration. WRT/scientific inspiration, a few loom large in my mind...

Most things from:Marvin Minsky (Negative Expertise was at one point groundbreaking for me)

Richard Feynman holds a place in my personal history

Douglas R. Hofstadter and his writting, Godel, Escher, Bach

Roger Penrose and his writting, The Emperors New Mind

Carl Sagan, especially his work in The Demon-Haunted World. I read this in more recent years, and found myself launched into a new understanding and exploration of the nature of science and humanity.

...and pick any of the large number of scifi authors, of course.

UA

In terms of pure science and academa, a few have been reasonably covered here already. A few from my personal library:

Anything from Donald Knuth

Andrew Tannenbaum and most of his publications

The greatest fundamental contributor to all great science, however, is inspiration. WRT/scientific inspiration, a few loom large in my mind...

Most things from:Marvin Minsky (Negative Expertise was at one point groundbreaking for me)

Richard Feynman holds a place in my personal history

Douglas R. Hofstadter and his writting, Godel, Escher, Bach

Roger Penrose and his writting, The Emperors New Mind

Carl Sagan, especially his work in The Demon-Haunted World. I read this in more recent years, and found myself launched into a new understanding and exploration of the nature of science and humanity.

...and pick any of the large number of scifi authors, of course.

UA

All the AI Lab tech reports going back to #9 (I'm not sure where 1-8 went).

This issue is not giving away `details' -- you can get all those free online, from the library, from a bookstore, wherever. What's hard to give away (or even if you want to give it away, hard to find the time for) is the work involved in organizing a curriculum/outline/lecture series and writing it all down.

For those interested, there is already MIT courseware; the whole textbook to`Structure in and Interpretation of Computer Programs' is available.... that's a good start.

Please don't misunderstand me -- I'm all in favor of free information. It's just that this particular suggestion is actually soliciting a lot of work on the part of the parent of the parent (somewhere up the thread, there).... But hey, if he's interested, I'm presuming he can let everyone know, and I will, of course, gladly shut up. :-)

• The Wikipedia project has spun off the Wikibooks, the free textbook project.
• MIT offers the OpenCourseWare initiative
• the venerable Project Gutenberg offers e-texts of public domain books
• The University of Pennsylvania complements Gutenberg with the Online Books Page
• and numerous other authors, universities, and organizations are jumping on the bandwagon

MIT Open Courseware These are not whitepapers and the like. Rather, they are mostly lecture notes from the professors who teach the classes there - Enjoy!

p.s. - Check out the link in my earlier post

Reference: Jerome H. Saltzer, and Michael D. Schroeder. The Protection of Information in Computer Systems. (invited tutorial paper) Proceedings of the IEEE 63, 9 (September 1975) pages 1278-1308. Reprinted in David D. Clark and David D. Redell, editors. Protection of Information in Computer Systems. IEEE 1975 CompCon tutorial. IEEE # 75CH1050-4. Also reprinted in Rein Turn, editor. Advances in Computer System Security. ArTech House, Dedham, MA, 1981, pages 105-135. ISBN 0-89006-096-7 Also reprinted in Marvin S. Levin, Steven B. Lipner, and Paul A. Karger. Protecting Data & Information: A Workshop in Computer & Data Security. Digital Equipment Corporation, 1982. This paper was originally prepared off-line. In 1997, Norman Hardy kindly rendered it into World-Wide Web form. here

So you're saying that someone who engages is mass murder, mass torture, the use of weapons of mass destruction against his own people, and so on is not evil, just misunderstood?

There's darker moments in Anglo-Saxon history. I wouldn't say Hussein is misunderstood, but that he justifies his own actions. We, at this point of our civilization find his actions to be unjustifiable. But, take a look in our history of civilization and you'll see large moments in time that Hussein would fit right in. Iraq is simply in a different time civilization wise (don't let the modern trappings of materialism distract you), and eventually they will advance to the next stage. Now that we're the catalyst for their advancement, I sincerely hope they're able to move on to the next stage, but I fear they won't be and they'll actually go backwards, but I've been wrong before.

As for using weapons of mass destruction on his own people, the people were rebels attempting a coup. The US and other governments have done similar (see Waco, TX and the Civil War), and the US is confirmed to have used military and civilian personnel for testing of chemical and radioactive substances.

Oh, and for your information, Bin Laden is evil too. As is anyone who purposely targets civilians. Yes, that makes the IRA evil, too.

In a democratic government (of which both the US and Britain are), there are no civilians. Though you may choose to not carry a gun, the bottom line is that we elected our leaders. Therefore, we are responsible for their actions. Since bin Laden (or the IRA) has no hope of defeating a conventional military, their only way of fighting is to convince the people ultimately in charge of that military that it's not worth it. Electing a leader and designating the most well equipped, trained and funded among us to be our soldiers neither absolves us of their actions nor protects us from retribution.

Ultimately, it is we the people that dictate policy and our government - and that the enemy has a conflict with...why shouldn't they attack us? Because we have a mighty miltary force who we'd rather them attack?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In LISP, macros became so bloated that Scheme had to be invented to strip the language down. But it was too late.

Sussman and Steele's compiler was first of all an implementation of Hewitt's ACTORS, and second of all an interpreter that re-wrote Scheme in CPS style (along the way inventing general tail-recursion) targeted at Maclisp. The only "bloat" that Scheme fixed was the "funarg problem" of early lisps by introducing full lexical scoping (along the way inventing the closure) and applicative order reduction/evaluation for function arguments, a convention that most later Lisps adopted (those that did not reportedly disappeared without a trace in the 1980s). The original Scheme did not include macros, and didn't have FEXPRS (ie - all functions evaluated their arguments, as mentioned above), but it did have quote, which is enough to build macros. I'm pretty sure they used some form of macros for transforming special forms to lambdas (off the top of my head, I think Steele mentions dirty macros in Compiler Optimization based on viewing LAMBDA as rename plus GOTO in Winston, ed, Artificial Intelligence - An MIT Perspective, Vol. 2). I know AI Memo 349 (Sussman, Steele, SCHEME an interpteter for extended lambda calculus) mentions something about AMACROs in the implementation.

But certainly neither of them disparaged macros (as a matter of fact, I do recall a not too old discussion on the Lighweight Languages mailing list where Steele defends macros against an attack using the same (lack of) arguments as yours).

PS - yes, it certainly was too late for Scheme, but luckily they added syntax-case back in somewhere around R4RS. Better late than never.

In LISP, macros became so bloated that Scheme had to be invented to strip the language down. But it was too late.

Sussman and Steele's compiler was first of all an implementation of Hewitt's ACTORS, and second of all an interpreter that re-wrote Scheme in CPS style (along the way inventing general tail-recursion) targeted at Maclisp. The only "bloat" that Scheme fixed was the "funarg problem" of early lisps by introducing full lexical scoping (along the way inventing the closure) and applicative order reduction/evaluation for function arguments, a convention that most later Lisps adopted (those that did not reportedly disappeared without a trace in the 1980s). The original Scheme did not include macros, and didn't have FEXPRS (ie - all functions evaluated their arguments, as mentioned above), but it did have quote, which is enough to build macros. I'm pretty sure they used some form of macros for transforming special forms to lambdas (off the top of my head, I think Steele mentions dirty macros in Compiler Optimization based on viewing LAMBDA as rename plus GOTO in Winston, ed, Artificial Intelligence - An MIT Perspective, Vol. 2). I know AI Memo 349 (Sussman, Steele, SCHEME an interpteter for extended lambda calculus) mentions something about AMACROs in the implementation.

But certainly neither of them disparaged macros (as a matter of fact, I do recall a not too old discussion on the Lighweight Languages mailing list where Steele defends macros against an attack using the same (lack of) arguments as yours).

PS - yes, it certainly was too late for Scheme, but luckily they added syntax-case back in somewhere around R4RS. Better late than never.

Aaahhh it uses a kickstand if it fails. That'll teach me to RTFLWWWP!

This robot's design is actually pretty cool. If you go to this site you will see a bunch of really cool pictures, and even a video about the Cardea. It has three arms, which may seem awkward at first, but actually it is a pretty ingenius design. The "extra" arm isn't really its own arm, it is more of an extension of the left arm that allows the Cardea to open doors and hold objects better.

Carlin Vieri at MIT designed and fabricated a reversible processor, described in his PhD thesis defense. It was really a fascinating gadget. It was very interesting how far-reaching the implications of reversibility were -- he needed to be able to reverse all the conditional jumps in the code, so it influenced compiler design as well as hardware design.

If by "vaporware" you mean "I can't buy one today at CompUSA", then you're correct. If you mean "it has never been built and it never will be built" then you are misinformed.

Mit's reversible computing page and pendulam project

Another site with Reverse logic gate pictures

Real: just about anything from the MIT Leg Lab.

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.

Indeed at least two sites document the Apple viruses in 1981. In addition, they were discussed in theory as early as 1949, and appeared in science fiction as least by 1975 in John Brunner's great Shockwave Rider, which was the inspiration for Robert Morris' famous Internet worm.

Except if you look at recent history, the large corporations are not the ones abusing the patent system [...]

Please read this webpage on how valuable IBM considers its patents to be and why. IBM holds more patents than anyone else. When they say cross-licensing is an order of magnitude more valuable than infringement lawsuits, everyone had better listen. Cross-licensing takes away all of the exclusive power patents were invented to bestow upon the patent holder. Cross-licensing is only for the biggest patent holders, so it by definition does not serve the majority of patent holders well. The public is also not served well by it either. Your view of the matter is incorrect and your post is horribly overrated.

You could have IBM apply for this patent, or you could have some less scrupulous company.

Or you could work to inform people about people about the problem with so-called software patents thus helping them understand why nobody should have them.

IBM is more likely to allow others to use this technology without filing patent infringement suits than some other company like amazon.com with its one-click shopping.

Just because you may avoid an infringement lawsuit doesn't mean you are being helped. Cross-licensing with IBM (or some other big patent holder) means you lose the exclusivity the patent system was built to create. If your product was built on these patents, you now have a potential competitor. This informative summary of a point raised in an old "Think" magazine article is telling:

The value IBM gets from cross-licensing measures the trouble that the patent system would cause IBM if IBM could not avoid it. IBM's estimate is that the trouble could easily be ten times the good one can expect from one's own patents--even for a company with 9,000 of them.

Any big patent holder likes cross-licensing more than litigation because litigation is more risky than getting the competitive patent holder's permission in a contract. But this strategy can only work for large patent holders--any smaller patent holder cannot cross-license to avoid patent infringement lawsuits because they don't have the war chest of patents to work with.

Software patents are bad for anyone that isn't IBM. It would be reasonable to estimate the threat and harm they pose is inversely proportional to the number of patent one holds. This is not a reasonable way to do business in the field of computer software development. We all should work for bringing an end to this collective threat, not take solace in that we're likely to avoid a trip to court.

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 ever more market share and as BSD sinks yet deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

John Underkoffler is a former member of the Tangible Media Group, and was the science advisor on the film.

This is actually the same thing developed by the James Pattern and Ben Recht. I was just on the site a couple of days ago looking at it for an MIS class. This page however is the first time that I have seen some of the other unique applications such as the sandscape.

Now earlier in the comments fireboy1919 that it wouldn't work because people are unwilling to learn a new interface in addition to the ones they are already good at. I think for it to be successful it depends on the application of they system and playing off of its core competencies which are the ability to track more than one object on the surface at a time and the ability to take on any shape and size by adding more units to the interface. So where it becomes useful is in a group situation where many people can interact with the objects at the same time and they are not limited to the size of a monitor. In the audio example it is like a mixing board but what makes it special is that every object has a contextual menu and can change to the users needs.

A concept like this one has already been explored at MIT with the Audiopad (Google Cache), used to make music but really could be used as a new, innovative kind of interface.

What I'm waiting for is for someone to combine that Linux HD of the PS2 and the EyeToy into a Minority Report type interface.

A concept like this one has already been explored at MIT with the Audiopad (Google Cache), used to make music but really could be used as a new, innovative kind of interface.

What I'm waiting for is for someone to combine that Linux HD of the PS2 and the EyeToy into a Minority Report type interface.

This would be an appropriate place to mention Sparkle (the first MPEG player I ever used) for the Mac. It doesn't appear to be listed on the InfoMac HyperArchive anymore.

It is a little bit different if you live with the Abstract notion of someone dropping "The Bomb(TM)" on you

There is nothing abstract about seeing B-52s flying overhead after taking off from the SAC base 2 miles away. Can you say "ground zero"?

Can we take the Airbag and Seatbelt back as well? Both were developed by Mercedes-Benz

Maybe M-B invented the airbag, maybe not. But it took an American to make it better.

I am at work right now

Aha! And you said europeans are more productive because they don't hang about the water cooler. When in Rome? :)

Cheers!

Right. But well, some people have attempted to develop quantum authentication protocols like this one, this one, and this one. Dunno if the device in question does any of them, or even if any of them are actually practical to use with today's technology. If the device in question doesn't use quantum authentication of some kind, well, they're selling snake oil, but I wouldn't dismiss the whole concept of quantum cryptography out of hand totally the way you seem so ready to.

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.

[A]ll the software we're using today will have been replaced by 9999.

Back in '99 there was a story about this.

The AVENUE Project at Columbia University had an earlier implementation for modeling urban sites.

Also check out The MIT City Scanning Project.

* NetBSD (of course!)
* Darwin (Mac OS X)
* FreeBSD
* IRIX
* Linux
* OpenBSD
* Solaris

or doesn't MIT usually let these kinds of things go. I mean come on they're the College who have a subdomain called fuck-the-skull-of-jesus.mit.edu. I really hope the RIAA hasn't managed to actually influence them in any way.