Slashdot Mirror

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.

I'd highly reccomend, if you are in the Boston area, and you like Furbies, to check out the Furby Wall at the DeCordova Museum in Lincoln, MA. Furby Wall

Ok, now wake up.... ;-)

No really, as long as people want to communicate with each other they will have nearly unlimited business.

Also, as long as they have right of way, there can be no REAL competition.

I have a feeling that another monopoly breakup is the only thing that could help at this point....
As for now, I'll just sit back, keeping paying my $170+ monthly qwest bill, and wait for dog to eat dog...then maybe Master (DOJ) will punish....it's inevitable. (sorry, link is PPT)

The vibe here seems to be along the lines of "Red Hat needs to do this to defend themselves from other patent holders." But RH is going beyond that, with it's offering of free use only to certain types of software. If self-defense was the only reason for this, RH could easily grant free use to "anybody that agrees not to ever sue us for patent violation." They have not done this.

Software patents are wrong for many reasons. The work that Red Hat have put into what they've patented does not warrant granting them a monopoly on the technique for over a decade. Exploiting a misguided, fascist system to quash potential competitors is wrong.

It was wrong when Amazon did it, and it's wrong now. The fact that Redhat does free software (which 'we' like) and Amazon doesn't (which 'we' don't) doesn't make this right.

This work doesn't solve any new problems and is essentially the same as Chord , a project at MIT, which has the same basic layout but in a more structured fashion (as far as I can tell from his slides). Chord came out over a year ago (they submitted to last year's SIGCOMM which would have been due in early 2001). He mentions that they're very similar, but as far as I can tell, there is nothing new in his implementation and it isn't necessarily as good. The Chord guys actually prove how fast their system works while he just waves his hands. They also have a paper about how to actually implement a p2p file system over it (I think they give a reference to someone who actually did it too).

There's no good reason this work should have been accepted. Whoever reviewed for this linux.conf.au dropped the ball in a big way. A real academic reviewer would have eaten him alive it.

At the same time, we are forced to live in the world as it is, and that world currently permits software patents. A relatively small number of very large companies have amassed large numbers of software patents. ...

One defense against such misuse is to develop a corresponding portfolio of software patents for defensive purposes. .... In the interests of our company and in an attempt to protect and promote the open source community, Red Hat has elected to adopt this same stance. We do so reluctantly because of the perceived inconsistency with our stance against software patents; however, prudence dictates this position.

The idea is very similar to the GPL. Maybe we need a general "patent GPL" - one which is not a "policy", which can be changed later, but a stronger assignment of patent rights to a GPL'ish foundation in defense.

Maybe it's time to revive the League for Programming Freedom, but along these lines.

Sig: What Happened To The Censorware Project (censorware.org)

At the same time, we are forced to live in the world as it is, and that world currently permits software patents. A relatively small number of very large companies have amassed large numbers of software patents. ...

One defense against such misuse is to develop a corresponding portfolio of software patents for defensive purposes. .... In the interests of our company and in an attempt to protect and promote the open source community, Red Hat has elected to adopt this same stance. We do so reluctantly because of the perceived inconsistency with our stance against software patents; however, prudence dictates this position.

The idea is very similar to the GPL. Maybe we need a general "patent GPL" - one which is not a "policy", which can be changed later, but a stronger assignment of patent rights to a GPL'ish foundation in defense.

Maybe it's time to revive the League for Programming Freedom, but along these lines.

Sig: What Happened To The Censorware Project (censorware.org)

Everyone knows aboutBSD'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 void 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.

You might check out iRobot. I work at the MIT AI Lab and we use the B21r for my project, which has similar goals. This robot was originally designed by a company called Real World Interface (RWI) that was ultimately purchased by iRobot. In any case, the robot runs Linux and uses V4L as far as I can tell, with what appears to be an off-the-shelf Hauppage WinTV card or equivalent. I don't know much about the camera, but conceptually, you should be able to set something up very similarly.

Now, as far as actually writing the code for real-time vision... that's up to you - good luck - it is a difficult problem.

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

If you notice the pads on the back of the enigmah board (6 on the top right) -- these are to program the part (probably an FPGA or an PLD). These wires don't go anywhere else, so I doubt the part would be able to be programed from software loaded onto the xbox... so the enigmah is also upgradable, but it would require extra cabling/equipment (maybe as simple as a parallel port cable)

I wonder if the Enigmah makes use of the extra images of firmware that bunnie found in the xbox's on-board flash?

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

The original spacewar game is available here as a java applet.

It actually runs the original PDP-1 assembler code in an emulator.

That depends on how you're interpreting "everyone's free use." It is definitely possible to license a patent for use only in GPLed software. See, for example, the RTLinux open patent license.

If I had a patent, I'd license it defensively: to people who have no patents and to people who only use patents defensively. In terms of mutual defense, I wouldn't grant a license to patent aggressors. This is similar to the Gilmore patent license someone mentioned in another post.

If you're opposed to (software) patents, I hope you won't limit free licensing to GPLed software. While it may be difficult to implement, mutual defense is the appropriate patent analog to the GNU GPL.

The intersection of copyright and patent opponents is smaller than either on its own. If you are in both camps, support them separately with copyleft and mutual defense. The enemy of my enemy is my friend, or something like that.

No. Trademarks can be abandoned (i.e., revert to the public domain) if they are not defended against dilution. Patents don't work that way. They can lie in wait for the technology to be more widely used, even if by independent invention. The most public instance of such a "submarine patent" is the GIF patent. Slashdot has also reported on BT's hyperlink patent. Ditto Rambus's SDRAM patents.

The only obstacles to late enforcement of a patent are public opinion and laws against unfair business practices. The latter is mentioned in the Rambus link above.

Interesting enough if anyone cares, iridium the element was discovered when dissolving platnum using aqua regia (acid).

Interesting enough if anyone cares, iridium the element was discovered when dissolving platnum using aqua regia (acid).

There are several interesting alternatives to the radio model we have today. The first is micropowered broadcasting. Micropower broadcasting is all about creating very cheap, low-powered transmitters in the 1 to 100 watt range. At these power levels the equipment is cheap, simple to use, can reach across most cities and rural areas, and allows a larger concentration of micropower broadcasting. Micropower allows communities, neighborhoods, and special interest groups to have their own radio stations and communicate with their local communities. I find it to be an attractive, democratic vision. Also check out Free Radio Berkeley for information on low-cost transmitters that are available, as well as educational information.

Another model that is still developing, and which is beautifully decentralized, is the OpenSpectrum idea. This model is based on several ideas. One part that is core is that the spectrum is not prematurely allocated to particular uses and users; instead, people have transceivers that can both broadcast and receive at a range of powers and at a range of frequencies. These transceivers constantly look at the spectrum, jumping around and broadcasting at various frequencies depending on the density of other transceivers. One important aspect is that transceivers can also act as repeaters for other transceivers. A few years ago it was theoretically shown that if this is done that "one can build a practical network whose capacity increases the more stations you add". This is powerful stuff, and the ideas should slowly percolate into society over the next few decades as the technology continues to improve (things like Ultra Wide Band, software defined radio, decentralized wireless meshes, etc.)

Make media! Make Trouble!
Brad GNUberg

I just don't understand how they're going to pull this off. If you've ever taken any kind of digital design class, you understand how ubiquitous and relatively inexpensive A/D converters are. I've had a whole lot of fun with the AD670
from Analog Devices and if you look at the pricing, I just don't know where they're going to fit a "cop chip" into this thing. At $10 a chip or thereabout, putting a big chunk of digital logic into it seems unmanageable.

Also, maybe I'm wrong about this, but for the "cop chip" to tell the ADC whether or not everything is good, won't it just have to make a pin high or low to signal it to shut down? I mean, there is a limited number of ways that one chip can efficiently signal another chip. How hard would it be to just tie the "cop chip" lead on an ADC to Vcc and not worry about it again?

This doesn't even get into the fact that there is no WAY, I mean NO WAY for any over-the-counter ADC to pick up a watermark. I mean, its not like in the Flintstones where there is a little bird pecking shit out on a stone tablet and the bird says "Hey, that's copyrighted... SQUAWK!" The ADC doesn't know how its being used. I could be throwing anything at it in any format. Hell, I could have run all sorts of analog signal processing on it beforehand...

Here's a good example: I was building a TTL-based robot for a class that needed to see using an NTSC camera. In the class, we weren't allowed to use any pre-fab processors - we were required to build our own from scratch. So I built a little special-purpose 16-bit RISC processor. So memory wasn't exactly in abundance, due to prototyping limitations, and clock speed wasn't exactly stellar, so the two big video-processing options were out: not fast enough to process NTSC in real-time and not enough memory to store the whole image and then process it. The way I got around this was by using the camera as a sort of memory device and detecting each horizontal sync off of the ADC, then just storing the individual line and processing that. It was an extremely good compromise. My point is this: how would the MPAA or whoever have any idea whether or not there was a watermark on the thing I was pointing the camera at? Particularly since I ran the whole thing through some signal processing before the ADC in order to widen the band of the most relevant image data.

At the end of the day, this is simply impossible. Maybe companies that have a vested interest in this, such as Sony, can integrate it into their higher-level hardware, but I can't imagine that the Analog Devices of the world are ever going to pull this off sanely.

Just my thoughts.

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

Not really that much of a spread of technologies, mostly just small-scale molecular/DNA computing and quantum computing. If you ask me the real front runners for next gen computing are RSFQ, spintronics, and massively parallel "quasi-processors" / reconfigurable computers (such as RAW and "smart memory"). More the kind of thing you'll see on your desktop 5-10 years from now rather than in the lab and still needing another decade to fully develop.

at http://web.mit.edu/network/pgp.html, but you can bet that i'm gonna download it again right now and burn the installer onto a CD.

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

The language is called Logo, and the triangle is commonly called a "turtle." Some Logo implementations included a software driver that would let you control a real robot containing a real pen via a hardware (usually serial) interface.

Logo is a more intereresting language than most people think...

I remeber using the language... uhm.. was it called Basic? No... Logix? No....damn.

You're thinking of Logo. I had a lot of fun with Logo back in the early 80s. Those were the days.

The starting point for this has to be the classic Boehringer Mannheim "Biochemical Pathways" charts which you can access on the Web here and here. Just click on one of the squares and it will present you with a blow-up of that section of the chart. These are also available as HUGE wallcharts on paper you can order from here. Amazing, ain't it? How the proteins produced by DNA manage to work together as catalysts to create the chemicals needed to form an organism is almost totally unknown, yet by definition it is a cellular automaton problem! To read up on all of this stuff, start with this, then for more details go here and here. After you've skimmed all of the above, pick a site from here or here or here and keep going. It never stops.

The starting point for this has to be the classic Boehringer Mannheim "Biochemical Pathways" charts which you can access on the Web here and here. Just click on one of the squares and it will present you with a blow-up of that section of the chart. These are also available as HUGE wallcharts on paper you can order from here. Amazing, ain't it? How the proteins produced by DNA manage to work together as catalysts to create the chemicals needed to form an organism is almost totally unknown, yet by definition it is a cellular automaton problem! To read up on all of this stuff, start with this, then for more details go here and here. After you've skimmed all of the above, pick a site from here or here or here and keep going. It never stops.

The critics of great ideas, like those of Erich von Daniken , Noam Chomsky and Emmanuel Goldstein all say the same things about them that you say about Stephen Wolfram and this new breakthrough.

So now who's the crank?

Ooops! wrong article sorry!

This means he's almost certainly a crank.

The critics of great minds, like Erich von Daniken, Noam Chomsky and Emmanuel Goldstein all say the same things about them that you say about Stephen Wolfram.

So now who's the crank?

Thank you

There are pleny of other open p2p products.

Freenet scaleable, not vaporware, very much beta.

Alpine.
based on trust
Gnunet. Sounds very open. based on electonic money. also seach for gnet.

chord Very efficient to find files.

distrinet At this stage: vaporware.(there is code....) But if you look at the description it beats any p2p software!

But in the end the network with the most data (gnutella/kazaa) will be used. Note that users will switch networks very quickly. Look what happened to napster.

Or you can use one that already exists. The intro computation structures class at MIT uses JSim, which I believe is based on Spice libraries and will let you simulate circuits from the MOSFET or the gate level. The final project is to design a 32-bit microprocessor, the Beta, if memory serves me correctly.

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.

BSD's 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 bureacratic 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. He who ignores history is doomed to repeat it; 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.

BSD's early triumphs would soon be forgotten in a series of

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

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 too bureacratic 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.

Other posters who suggest that you do some studying are not unwise. Digital logic is straightforward when you have a background in combinatorial logic and a few other concepts up to about 25MHz. Designs with that level of clock speed can easily be wire-wrapped. Beyond that, you are going to have to start considering high-speed design issues when you route your boards.

One of the most rewarding things that I did as an undergrad was design my own SBC around a Motorola 68HC11 to run the mechanics for a 3-D scanning system that interfaced to an SGI workstation.

I really think that if this interests you, you should pursue it . The current 'state of the hobby' is now so advanced that it is somewhat mind numbing what can be done with some FPGAs and some software to layout a PCB.

The Motorola Dragonball family (or it's decendants) are an excellent 68000 core family of chips that are easy to use and you can design a modestly useful machine around them with a classic buss / memory mapped IO architecture without working up too much of a sweat.

S.L. "So do you believe we'll find this code in your lifetime?"

S.W. "I hope so. Yeah."

:) Meaning if you are looking for the code, it ain't there.

Aparently Steven Wolfram is no Neo.

S. W.s error?:

So put on your Neo Glasses and know:

S.L./W. - Not only does a single measly rule account for everything, but if one day we actually see the rule, he predicts, we'll probably find it unimpressive. "One might expect," he writes, "that in the end there would be nothing special about the rule for our universe - just as there has turned out to be nothing special about our position in the solar system or the galaxy."

Hmmm, a recent slashdot linked to article on the possible changing nature of the laws of physics? seems to suggest that what exist in existance is changeable.

Ok existance exist, but what's in it can change, just like consciousness either exist or not but what exist in consciousness is changeable.

Are consciousness and existance related?

EQUATIONS:
Conversion / Translation

E = MC - EINSTEIN
E = Energy, M = Matter, C = Speed of Light Squared.

T1 = T2 k - SPINOZA
T1 = non-mystical thought, T2 = things in physical reality, k = the active constant.

T1 ( I + E ) = v T2 (k) - Di SILVESTRO
I = degree of Intent, E = degree of Effort, v = velocity of conversion.

Einstein searched until the moment he died for the equation of the "Unified Field Theory". He never realized the missing element was the same element that caused so much of his life to be what it was. From the cheers and recognition from supporters of his work to the threats on his life, exile out of his country and destruction of publications on his work. All this caused from the element Einstein was exercising, but not realizing, the element of consciousness. It was Einsteins' conscious efforts that lead him to produced his work. The consciousness of those who recognized his work and put forth the effort to honor him for it. The conscious efforts of some to create an illusion, leading many into action of threat, destruction and force to have a physical impact on Einstein and many others. And it was the conscious efforts to apply Einsteins' work that contributed to creating the physical power that removed the force which cause Einstein to leave his country. Perhaps Einstein did come to intimately know what the missing element was, in those last few moments of his life.

The Spinoza equation "T1 = T2 k" expresses two perspectives: All things in physical reality can be comprehended/translated into conscious thought and conscious thought can be converted/translated into physical reality. For those who have doubt about the validity of this equation: Look around and note all the physical things you perceive. Then determine, to the best of your ability, what exist as a result of conscious comprehension of physical reality and conscious directed action, effort and intent to apply physical movement to create? In other words: What do you see that originated in conscious imagination?

For those still in doubt: What don't you perceive, but know by what you do perceive, that there must exist both the conscious ability to comprehend physical reality and conscious imagination to cause intentional control of physical reality? (i.e. Computer usage and its internal operations. Software and it's existence on magnetic media. Disease identification and treatment or cure. Radio wave creation used in sending and receiving data, and its' translation to and from what we can perceive - music, pictures of stars we cannot see from earth but now know they exist. The life we create via genetic control and duplication, etc..)

This article mentions the "great AT&T problem" of 1989. But it doesn't mention the corporate witch-hunt for "hackers" which was known as Operation Sundevil. Everyone at AT&T was so hopped up on their own hubris, they assumed that the telecom problem that shut down exchanges in NYC and elsewhere had to be cause be (malicious) human hands.

The complete details are set out in Bruce Sterling's book "The Hacker Crackdown." Operation Sundevil also lead to the creation of the Electronic Frontier Foundation.

A turbine does not a generator make. Show me the electricity! Silicon ain't magnetic people. OK, magnetless generators exist, how about "coils" then? Show me the coils! Until I see a working, efficient, microsized generator, I don't see any of this happening.

Funny you should mention that; a graduate student at MIT working on that very topic defended his thesis earlier this week. An old progress report describes the basic idea. It's more difficult, but not impossible.

As things get smaller and smaller, your perceived viscosity goes up and up.

Although viscous drag is a problem with MEMS (another MIT student defended his thesis this week on efficient algorithms for calculating fluid drag on MEMS), the beauty of microfabrication is that as the characteristic length gets smaller, the Reynolds number drops, so the flow stays laminar. At 1 MHz, the boundary layer thickness is pretty small, so in fact you can model the fluid (air) as nearly inviscid. It's not uncommon for resonant MEMS devices to have a Q of 50 or more in air.

The majority of damping in MEMS comes from squeeze-film damping, which occurs when you have a moving object suspended a small distance above the substrate. Motions of the object towards or away from the substrate cause fluid flow that generates a lot of damping; motions of the object parallel to the substrate cause a lot less damping. The micro-turbine is made out of 6 (!) wafers of silicon (which creates one hell of an alignment problem, by the way), so the turbine can be suspended well above the substrate. It also moves parallel to the substrate, rather than perpendicular to it. Of course, viscosity is still the ultimate limiting factor, but it's not as bad as you make it sound.

Back when the company was in Glendale (before it became the big ISP we all know and hate) it was staffed with like 90% Scientologists. The CTO was Brian Wenger, who used to edit the "Pro-Scientology" FAQ

Another of their employees was Philip Gale. He worked there when he was 16, before going to MIT and killing himself.

Stay far away from Earthlink...Not only are they a shitty business, but any money you send there way helps Scientology.

Read these links regarding Autocoding and the problem with private efforts

I probably won't respond to anything else you say on the politial part of this subthread since what I'm really interested in debating is the global warming part.

Agreed. Anyway, as much as I enjoy this challenging exchange (I do, really), it's probably time to move on. I would just like to say one last thing about the whole Chavez affair. While I agree with you that Latin America government are corrupt in general, that paints only half of the picture, i.e. that businesses in those area also tend to be corrupt. After all, to use an appropriate analogy, it takes two to tango. This is why sticking to due process (and in the case of Venezuela, the constitutional process) is essential, and should be encouraged. In my view Bush failed to encourage the constitutional process because his administration clearly dislikes Chavez. That was a blatant faux-pas on the government's part.

In other words, "Global warming is probably real. But if it isn't, we should act like it is since all it means is that it isn't happening now but will probably happen someday." I can't argue with that logic. If that's the way you see it then we might as well abandon all research--if our actions with or without global warming are the same, there's no reason to research it.

Well, that's not exactly what I meant. What I believe would go more along these lines: "Global warming is probably real. Until we know for sure that it isn't, we should act as if it was in order not to make the situation worse. It just so happens that in changing our habits in order to avert this probable catastrophe, we also solve another problem: our dependence on fossil fuels, which has dire economic and geopolitical consequences. So we kill two birds - or at least one and possible other one - with one stone (to use a non-politically correct saying... :-)

If the satellites and radiosondes for the last 23 (satellites) to 50 (radiosondes) years are showing a slight cooling and the surface record shows heating, the surface measurements are not reliable.

Read the stories again: radiosondes measure atmospheric, not surface, temperatures. In the NASA papers, they clearly show that the difference is not between recorded surface temperatures, but between recorded surface and atmospheric temperatures. The surface indeed is warming up, but the atmosphere is not warming up at the same rate, and parts of it are cooling instead. As I said, this shows that the computer models used to predict atmospheric changes are incorrect, which may mean that global warming is slower than expected (let's hope that's what it means). However, the radiosonde data does not invalidate surface temperature records, because it doesn't measure surface temperatures. The discrepancy is with the expected atmospheric warming and the actual recorded one, which is lower than expected. Thus the question of reliability does not apply to surface temperature measurements (save for the so-called "asphalt effect"), but rather to the computer models used to predict atmospheric changes.

In one section it talks about reducing emissions by 17% while in another part it says that it's emissions have increased by half the rate of growth of the economy.

Actually, the arctile says the country's energy consumption has increased by half the rate of growth of the economy, not its emissions. Those are two different things. Emissions did increase in the first part of the 90s, mind you, but they have been decreasing in the second half. A few more links about a piece of news that was quite underreported in the U.S.:

World Carbon Emissions Fall

Carbon Emissions Data | China

China and Climate Change

And here is an analysis by the US NGO that published the original report. In this analysis the researchers said they cross-examined their data a second time after the Washington Post claimed that China had underreported its actual emission figures while inflating its actual economic growth. The NRDC still found that China had in fact decreased its carbon emissions while enjoying a healthy economic growth. So the two are not irreconcilable, and the "China excuse" is not a valid reason for the U.S. to drop out of Kyoto...unless you are suggesting that americans are somehow less capable at taking on the environmental challenge than the chinese are...

Sure, there will be short-term costs, but these will be quickly recouped, and the goal is quite worthy of those small sacrifices (energetic independence and reducing the likelihood of a probable global warming).

Anyway, that's my opinion. We probably won't be able to see eye to eye on this, but still I respect your position.

Google cache

Also, a news article

In preparation for being slashdotted, they have already posted a mirror site link.

I was much more annoyed when Yahoo removed pop3 access. Now how am I supposed to archive old email?

First, computer-generated singing from MIDI files can be done better. Listen to Festival Singer, from the Oregon Graduate University of Science and Technology, which is in turn based on a speech system from the University of Edinburgh. It's still not that great, but progress is being made. They're approaching the garage-band level.

More components are needed to make computer-generated music more human-like. Some of that work has been done. The Media Lab system for Expressive Performance Extraction takes in a MIDI file and an audio recording of piano music, and builds a model of the performer's expression. This model can then be used with other MIDI files to mimic the specific pianist.

The next big step is to do that for singers.

The goal is to have a system where you put in a MIDI file, lyrics, performer and singer models, and push start. Out comes a performance that sounds like a good backup band.

Because the music industry likes to have the option to replace performers, copyright law doesn't prevent doing this on popular music. You only have to pay a modest statutory royalty to the original songwriter.

Once this works, it could make a real dent in the music industry. Performers could go the way of orators. People would still go to live performances, but we could dispense with much of the recorded music industry.

Yes, BNETD is completely dead. The DMCA has prevailed.

- A.P.

The Xbox has a PIC 16LC63A microcontroller... people are still figuring out what it does.

AFAIK, the satellite boxen don't necessarily use a PIC for authentication -- they would probably use a more cryprographically secure/hacker-proof device. It's been the cloners that use PIC chips because they are versatile and cheap enough to get the job done.

I was happy to solve 1840, even though I immediately recognized the language, because it is poorly specified and there is no interpreter. But that was nothing compared with my teammates, who solved 1183 with nothing but the problem and pure reason.

I was happy to solve 1840, even though I immediately recognized the language, because it is poorly specified and there is no interpreter. But that was nothing compared with my teammates, who solved 1183 with nothing but the problem and pure reason.

Reminds me of the distance hack in the Infinite Corridor. From hacks.mit.edu:
http://hacks.mit.edu/Hacks/by_year/1997/infinity_r ods/
http://hacks.mit.edu/Hacks/by_year/1997/infinity_r ods/poster_text.html