Slashdot Mirror

In COMP 314 (Rice University's sophomore-level programming & algorithms class, taught this past spring by Prof. Dan Wallach) we TAs solved this problem with Subversion.

An important part of real-world programming is teamwork; in 314 we embrace this and randomly sort students into groups of two for pair programming. The groups change for each project, and each project group gets a spot in a svn repository set up for the course. ACLs keep groups from peeking at one another's changes (for example, see this team list, which is actually just a slice of our Subversion access control file). Students were required to tag their submissions for each of the project milestones: specification, prototype, final; this was how students submitted code for these deadlines. From timestamps we could easily see which groups incurred "slip hours" for late turnins.

There were a number of reported incidences of lost work or conflicting changes which would have been disasters if not for svn, which saved their bacon. Groups that learned to check in early and often knew that accidental deletions or disk failures posed no threat to a successful project submission. A few enterprising teams even used tags and branches to help organize complex development efforts. In all, it was quite a successful adventure and we'll probably do something similar in the future.

In COMP 314 (Rice University's sophomore-level programming & algorithms class, taught this past spring by Prof. Dan Wallach) we TAs solved this problem with Subversion.

An important part of real-world programming is teamwork; in 314 we embrace this and randomly sort students into groups of two for pair programming. The groups change for each project, and each project group gets a spot in a svn repository set up for the course. ACLs keep groups from peeking at one another's changes (for example, see this team list, which is actually just a slice of our Subversion access control file). Students were required to tag their submissions for each of the project milestones: specification, prototype, final; this was how students submitted code for these deadlines. From timestamps we could easily see which groups incurred "slip hours" for late turnins.

There were a number of reported incidences of lost work or conflicting changes which would have been disasters if not for svn, which saved their bacon. Groups that learned to check in early and often knew that accidental deletions or disk failures posed no threat to a successful project submission. A few enterprising teams even used tags and branches to help organize complex development efforts. In all, it was quite a successful adventure and we'll probably do something similar in the future.

In COMP 314 (Rice University's sophomore-level programming & algorithms class, taught this past spring by Prof. Dan Wallach) we TAs solved this problem with Subversion.

An important part of real-world programming is teamwork; in 314 we embrace this and randomly sort students into groups of two for pair programming. The groups change for each project, and each project group gets a spot in a svn repository set up for the course. ACLs keep groups from peeking at one another's changes (for example, see this team list, which is actually just a slice of our Subversion access control file). Students were required to tag their submissions for each of the project milestones: specification, prototype, final; this was how students submitted code for these deadlines. From timestamps we could easily see which groups incurred "slip hours" for late turnins.

There were a number of reported incidences of lost work or conflicting changes which would have been disasters if not for svn, which saved their bacon. Groups that learned to check in early and often knew that accidental deletions or disk failures posed no threat to a successful project submission. A few enterprising teams even used tags and branches to help organize complex development efforts. In all, it was quite a successful adventure and we'll probably do something similar in the future.

In COMP 314 (Rice University's sophomore-level programming & algorithms class, taught this past spring by Prof. Dan Wallach) we TAs solved this problem with Subversion.

An important part of real-world programming is teamwork; in 314 we embrace this and randomly sort students into groups of two for pair programming. The groups change for each project, and each project group gets a spot in a svn repository set up for the course. ACLs keep groups from peeking at one another's changes (for example, see this team list, which is actually just a slice of our Subversion access control file). Students were required to tag their submissions for each of the project milestones: specification, prototype, final; this was how students submitted code for these deadlines. From timestamps we could easily see which groups incurred "slip hours" for late turnins.

There were a number of reported incidences of lost work or conflicting changes which would have been disasters if not for svn, which saved their bacon. Groups that learned to check in early and often knew that accidental deletions or disk failures posed no threat to a successful project submission. A few enterprising teams even used tags and branches to help organize complex development efforts. In all, it was quite a successful adventure and we'll probably do something similar in the future.

In COMP 314 (Rice University's sophomore-level programming & algorithms class, taught this past spring by Prof. Dan Wallach) we TAs solved this problem with Subversion.

An important part of real-world programming is teamwork; in 314 we embrace this and randomly sort students into groups of two for pair programming. The groups change for each project, and each project group gets a spot in a svn repository set up for the course. ACLs keep groups from peeking at one another's changes (for example, see this team list, which is actually just a slice of our Subversion access control file). Students were required to tag their submissions for each of the project milestones: specification, prototype, final; this was how students submitted code for these deadlines. From timestamps we could easily see which groups incurred "slip hours" for late turnins.

There were a number of reported incidences of lost work or conflicting changes which would have been disasters if not for svn, which saved their bacon. Groups that learned to check in early and often knew that accidental deletions or disk failures posed no threat to a successful project submission. A few enterprising teams even used tags and branches to help organize complex development efforts. In all, it was quite a successful adventure and we'll probably do something similar in the future.

The spot exchange rate for exchanging dollars for rupees does not express the relative values of those currencies in their home countries. It costs nearly 46 rupees to buy 1 American dollar, but it does not cost 46 rupees in India to buy the equivalent of 1 dollar in the U.S. The value ratio, or purchasing power ratio, is really closer to 5 to 1, not 46 to 1.

An explanation from Yossi Yakhin of Rice University:
International Comparison: Adjusting to Purchasing Power Parity
One important role of real exchange rates is that they allow us to compare appropriately the standard of living between different countries. For example, consider the comparison between the GDP per capita in the US to that of India. In 2004 GDP per capita in the US was approximately $40,000 while in India it was $630 (see Table 1).

The figure for India was calculated by converting the rupee value into dollars using the average spot exchange rate. However, is that the right comparison? There is no doubt the US is richer then India, but are Americans really 63 (= 40,000/630) times richer than Indians?

The problem with the calculation we have just made is that it does not take into account differences in purchasing power in the two countries. It has long been recognized that poor countries have lower price levels; therefore, a dollar in India, for example, can go a longer way than in the US. Therefore, if the Indian dollar-income is 63 times lower than the American one, it does not mean that the standard of living in India is 63 times lower than in the US.

In order for the comparison to be meaningful we must adjust the GDP figures to the purchasing power of the dollar in the two countries. We do that by using the real exchange rate. For example, suppose that we find that prices in the US are twice as high as in India; then the Indian nominal GDP per capita figure should be doubled before we make any comparison to the US. In other words, we have to multiply the Indian figure by the (Indian) real exchange rate, which is exactly the price of American basket in terms of Indian basket.

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.

Here's a link showing salaries in Poland. It's four years old, but still somewhat relevant.

The research i've been doing in P2P networks (due to my involvement in the okopipi project) has shocked me. In file sharing, we're living in the STONE AGE. Yes, even with bittorrent (which depends on centralized servers, and there's practically no privacy. And anonymous bittorrent like mutorrent is closed source, who knows if they got a backdoor in there).

EDonkey uses MD4 for hashing, it depends on central servers, and has no anonymity at all. And without mentioning queue # 4892 for a popular file.

Unfortunately for filesharers, file sharing networks based on modern P2P architectures is very scarse. The supernodes / ultrapeers approach is obsolete, easy to disrupt both denial of service and eavesdropping attacks.

The future of P2P is Overlay Networks.

From an architectural point of view, I would recommend the KAD p2p network, which bases its architecture on the relatively-new kadelmia network (See Technical paper on Kadlemia, 2002).

Even then, Kadelmia could be improved because it's based on a Pastry network topology - compared to other topologies like De Bruijn Graphs, proposed by a recent paper in 2003.

And more research is being done dealing with load balancing, anonymity, trust, reputation, etc.

As I said, current peer to peer networks are in the stone age. Someone needs to design a file sharing network based on the latest research, and publish it.

Shouldve checked my preview better. Center for Biological and Environmental Technology

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

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

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

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

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

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

The Great Bubble of the late '90s shaped a generation of Internet entrepreneurs and investors much as the Great Depression shaped a generation of economizers in the mid-20th century.

Since my own existence only dates back some 40 years, I can't claim firsthand experience of the Great Depression, but comparisons between the Dot-Com Bust and the Great Depression are so overblown that it ain't even funny. From the usual suspects:

Almost all countries were affected; the worst hit were the most industrialized, including the United States, Germany, Britain, France, Canada, Australia, and Japan. Cities around the world were hit hard, especially those based on heavy industry. Construction virtually halted in many countries. Farmers and rural areas suffered as prices for crops fell by 40-60%. Mining and lumbering areas were perhaps the hardest hit because demand fell sharply and there was little alternative economic activity.

I guess it's to be expected, though. We're supposedly in this War on Terror, but so far, I haven't been asked to participate in a single Meatless Tuesday. Where do I go to get my ration cards, anyway?

"Main Entry: hopefully
Function: adverb
Date: circa 1639
1 : in a hopeful manner
2 : it is hoped : I hope : we hope
usage In the early 1960s the second sense of hopefully, which had been in sporadic use since around 1932, underwent a surge of popular use. A surge of popular criticism followed in reaction, but the criticism took no account of the grammar of adverbs. Hopefully in its second sense is a member of a class of adverbs known as disjuncts. Disjuncts serve as a means by which the author or speaker can comment directly to the reader or hearer usually on the content of the sentence to which they are attached. Many other adverbs (as interestingly, frankly, clearly, luckily, unfortunately) are similarly used; most are so ordinary as to excite no comment or interest whatsoever. The second sense of hopefully is entirely standard."

From Merriam-Webster, quoted at http://www.cs.rice.edu/~ian/Manifestoes/grammarNaz i.shtml

http://cohesion.rice.edu/naturalsciences/nanokids/ cast.cfm

Science: Big-O analysis, graph theory, computability evaluation
Not Science: Distributed systems design, system architecture

Tell that to this guy getting his PhD in it; his distributed project FeedTree has been previously featured on Slashdot.

Something doesn't stop being science just because you say so. Have you forgotten Google's roots?

Mozilla 1.3.1
DJBDNS 1.05
TCL 8.4.3
GLIB 2.2.1
Python 2.3b1
Perl 5.6.1
Perl 5.8.0
Linux 2.4.20 directory cache (dcache)
Squid 2.5STABLE1
Bro IDS 0.8a20

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

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.

You're right, I didn't really refute your point. However, I still disagree.

There have been some pretty elaborate attacks on software. For example, the vulnerability that some colleagues of mine at Rice University found in Google Desktop. They spent a good month analyzing the security of and trying different things on Google Desktop. In the process, they wrote plenty of their own software. Indeed, it would not have been possible to find this flaw had they not been clever engineers themselves.

There are plenty of other attacks out there, such as cache hit timing attacks, that are very, very complicated -- the idea itself behind that timing attack is insane to me, much less the implementation. (For those attacks, cache hit information was used to extract secret/private keys from inside other applications without having any special privileges!).

I don't think the situation is simple enough to say that breaking into things is always easier than making them in the first place, even as a generalization. Especially if you include the amount of time looking for vulnerabilities as part of the "circumvention" of one specific flaw, vulnerabilities are quite expensive to find.

I'm not entirely sure what happened at Rice w.r.t. Pastry. What I was told by Dr. Wong that Rice had a Pastry version, MS adopted it and converted it to C#, then allowed us to use it freely. All of this was part of an elective class called COMP 410 that students take. Basically, a team of 10-20 people act like a software company, self-organize, meet with a "client" (professor acting like one) and build a huge system.

And yes, we use entirely Microsoft software. But I think it's a good thing. When I took it, Microsoft gave us copies of Visual Studio 2003, SQL Server, and funding for some tablet PCs to use as part of the project. I thought it was a *superb* experience to work with so much real-world technology.

Yes, I suppose one could say that MS is stifling open-source competition... but seriously, we were building an application that used a distributed cluster of SQL Server databases, transactionally changed by Enterprise Services features with Event Queueing; all of this also used a distributed file and processing system based on Pastry (C#). Getting all that to work together with open-source in a single semester would be quite a challenge. What database would we even use? MySQL is definitely not capable of that. And Oracle isn't free.

So, in this case at least, I think Microsoft's support of us has been positive for students. We are not just a Microsoft shop -- there is even a research group at Rice called the Programming Languages Team, which focuses almost exclusively on Java for research projects. I'm currently involved in improving the open-source, student-oriented Java IDE called Dr Java, which is under the purview of PLT.

*Pant*

Well, I'm sorry this turned into a rant. I guess my point of this: Microsoft has not caused Rice to give up open-source software or anything like that. In reality, their funding has exposed us to more software and more systems than we would have otherwise. I think that is a Good Thing.

It is neither a good thing for students to be exposed solely to OSS, nor solely closed-source industry software. A university should educate well-rounded people, and much like liberal-arts universities require students to take many subjects, Rice exposes CS students to different technologies and environments in its computer science program. Otherwise, how can I ever decide which is best for a task?

[Note: I am heavily, personally in favor of Microsoft software and have accepted an internship with them in the C# Compiler group next summer. But this doesn't mean I dislike Java or OSS; I don't see why there has to be a conflict at all. Use whatever tool suits you best.

But that's just me. I'm going to do *my* best to make C#.NET the best language it can be. If you like Java, fine! We can learn from another :]

I'm not entirely sure what happened at Rice w.r.t. Pastry. What I was told by Dr. Wong that Rice had a Pastry version, MS adopted it and converted it to C#, then allowed us to use it freely. All of this was part of an elective class called COMP 410 that students take. Basically, a team of 10-20 people act like a software company, self-organize, meet with a "client" (professor acting like one) and build a huge system.

And yes, we use entirely Microsoft software. But I think it's a good thing. When I took it, Microsoft gave us copies of Visual Studio 2003, SQL Server, and funding for some tablet PCs to use as part of the project. I thought it was a *superb* experience to work with so much real-world technology.

Yes, I suppose one could say that MS is stifling open-source competition... but seriously, we were building an application that used a distributed cluster of SQL Server databases, transactionally changed by Enterprise Services features with Event Queueing; all of this also used a distributed file and processing system based on Pastry (C#). Getting all that to work together with open-source in a single semester would be quite a challenge. What database would we even use? MySQL is definitely not capable of that. And Oracle isn't free.

So, in this case at least, I think Microsoft's support of us has been positive for students. We are not just a Microsoft shop -- there is even a research group at Rice called the Programming Languages Team, which focuses almost exclusively on Java for research projects. I'm currently involved in improving the open-source, student-oriented Java IDE called Dr Java, which is under the purview of PLT.

*Pant*

Well, I'm sorry this turned into a rant. I guess my point of this: Microsoft has not caused Rice to give up open-source software or anything like that. In reality, their funding has exposed us to more software and more systems than we would have otherwise. I think that is a Good Thing.

It is neither a good thing for students to be exposed solely to OSS, nor solely closed-source industry software. A university should educate well-rounded people, and much like liberal-arts universities require students to take many subjects, Rice exposes CS students to different technologies and environments in its computer science program. Otherwise, how can I ever decide which is best for a task?

[Note: I am heavily, personally in favor of Microsoft software and have accepted an internship with them in the C# Compiler group next summer. But this doesn't mean I dislike Java or OSS; I don't see why there has to be a conflict at all. Use whatever tool suits you best.

But that's just me. I'm going to do *my* best to make C#.NET the best language it can be. If you like Java, fine! We can learn from another :]

All the detail are explained in the technical paper

In addition to the website, there is a technical paper that descirbes the whole architecture. How is it works on top of scribe, how it can work in different models of adoption. How security is handled and all the other technical details. If your interested in the gory details of how it all works you should go here pdf to see the paper.

As a Rice Computer Science student I would like to point out that Pastry actually originated at Rice, under Dan Sandler. The first framework was in Java. You can see from his web page that he's responsible for FeedTree, too.

Microsoft Research became interested in the product and ported it to C#, effectively turning it into the form it is now. Many classes at Rice have now "backported" it, I guess you could say, and it's used for many of our classes that involve distributed networks, such as the current COMP 410 class which has previously turned out distributed file and process system codename Voltron.

Here's a link to the paper co-authored by Sandler and others at Rice.

As a Rice Computer Science student I would like to point out that Pastry actually originated at Rice, under Dan Sandler. The first framework was in Java. You can see from his web page that he's responsible for FeedTree, too.

Microsoft Research became interested in the product and ported it to C#, effectively turning it into the form it is now. Many classes at Rice have now "backported" it, I guess you could say, and it's used for many of our classes that involve distributed networks, such as the current COMP 410 class which has previously turned out distributed file and process system codename Voltron.

Here's a link to the paper co-authored by Sandler and others at Rice.

As a Rice Computer Science student I would like to point out that Pastry actually originated at Rice, under Dan Sandler. The first framework was in Java. You can see from his web page that he's responsible for FeedTree, too.

Microsoft Research became interested in the product and ported it to C#, effectively turning it into the form it is now. Many classes at Rice have now "backported" it, I guess you could say, and it's used for many of our classes that involve distributed networks, such as the current COMP 410 class which has previously turned out distributed file and process system codename Voltron.

Here's a link to the paper co-authored by Sandler and others at Rice.

As a Rice Computer Science student I would like to point out that Pastry actually originated at Rice, under Dan Sandler. The first framework was in Java. You can see from his web page that he's responsible for FeedTree, too.

Microsoft Research became interested in the product and ported it to C#, effectively turning it into the form it is now. Many classes at Rice have now "backported" it, I guess you could say, and it's used for many of our classes that involve distributed networks, such as the current COMP 410 class which has previously turned out distributed file and process system codename Voltron.

Here's a link to the paper co-authored by Sandler and others at Rice.

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.

http://it.is.rice.edu/~rickr/goddard.editorial.htm l

You should check out Connexions. I don't know the framework behind it, but it is likely to be O/FSS. You take a look around http://cnx.rice.edu/

It is incidentally a very nice place to go for quick information on some college level material - statistics and signal analysis in particular is my experience. Good luck with your (very hard) problem.

entire poem located here...

The arching sky is calling
Spacemen back to their trade.
ALL HANDS! STAND BY! FREE FALLING!
And the lights below us fade.

Out ride the sons of Terra,
Far drives the thundering jet,
Up leaps a race of Earthmen,
Out, far, and onward yet --

We pray for one last landing
On the globe that gave us birth;
Let us rest our eyes on the friendly skies
And the cool, green hills of Earth.

-- Robert A. Heinlein

If you want to see a pretty cool website devoted to online courses with a lot of collaberation between different places, check out Connexions, hosted by Rice University.

Rice University has created a similar system at http://cnx.rice.edu/ which is meant to be universal. That is, other colleges or universities add content, too. Because it was created in the electrical engineering department it is still focused rather heavily on all things electrical engineering though other disciplines show up.

Disclaimer: I am a Rice University Electrical Engineering undergraduate.

It DOES?!? Maybe in the Jonestown sense...

Generally the friction caused by the subduction creates immense heat, melting the rock layer that is subducted. When the rock melts, superheated steam causes volcanoes to form above the subduction zone. For an example, see http://www.ruf.rice.edu/~leeman/Cascades.gif

So unless you want volcanoes of nuke waste (!) it might be better to bury it in a geologically stable area, such as the middle of a continent.

Logically, if they started reprocessing waste, it would be such a small amount you would only need a single salt mine or similar.

Can't even paste the surface integral symbol into /.'s HTML restrictor ... see http://cnx.rice.edu/content/m1005/latest/ for a decent formatting.

In words, Gauss's law states that "if you add up the surface integral of the displacement vector D over a closed surface S , what you get is the sum of the total charge enclosed by that surface."

I was taught this as a basic theorem in Physics, and thought it interesting as a tool. Then my girlfriend, who was far smarter than I, told me she was learning the same equation in Calc II, and that it could be proven using regular calculus (and had been proven, in fact, by Gauss, hence the name). I was stunned. Took me a week to come down off the glow.

Nah, mp3.com would query for several random bytes of the cd in question, so the person would pretty much have to have a copy of the cd. I remember the security was considered strong but they lost in court anyway because it was deemed to still be copyright infringement, see Umg vs. Mp3.com.

http://cnx.rice.edu/

There's already some open content there, and pretty decent tools for creating more. It's all creative commons.

But why, some say, the moon? Why choose this as our goal? And they may well ask why climb the highest mountain. Why, 35 years ago, fly the Atlantic? Why does Rice play Texas?

We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.

--John Kennedy at Rice University, 1962

http://www.rice.edu/fondren/woodson/speech.html

The ridge of mountains in Italy from north to south, including Sicily, are seismic active.
The southern part of Italy lies very close to the boundary of Eurasia
plate and the African plate (tectonic).

http://www.owlnet.rice.edu/~geol108/eq13/maps_of_t he_region_for_afr.htm

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

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

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

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

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

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

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

For example, how many companies fortunes have been made with digital computers?

We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.

The mission of KTRU as a student organization and a 50,000 watt radio station is to educate the station membership, the greater Houston community, and the students of Rice University through its progressive and eclectic programming in the spirit of the station's non-commercial, educational license. Musically, KTRU programming will endeavor to solely feature genres and/or artists who are unexposed, or unavailable on, the Houston commercial radio dial. Non-musical programming will focus on content with clear merit and of practical value to a significant segment of the communities served by KTRU.

In radio broadcasting operations to promote the full distribution of public information; to obtain access to sources of news not commonly brought together in the same medium; and to employ such varied sources in the public presentation of accurate, objective, comprehensive news on all matters vitally affecting the community.

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.

Existing transmission lines are a huge waste of energy. They hold back conversion from fossile fuels to solar and wind by limiting the distance electricity can be effectively sent. Copper is too soft and heavy so aluminum transmission lines are built but there is too much resistance so transmission distance is cut back.

With nanotubes, near-superconducting transmission lines could be built which would enable cloudly areas to reap the benefits of solar electric power from deserts and wind power from the plains.

References:
http://smalley.rice.edu/ (see associated video lecture.)

Upon what basis can you say that you do possess the ability to think rationally and logically? I do quite a bit of thinking, discussing, and writing that is rational and logical. I have several examples of my writing available on my personal website, if you care to take a look, and have been published by the Association for Computing Machinery's Ubiquity. You can see two articles I have published on Rice University's Connexions project here and here.

I would be interested in reading something that you've written and published, that can support an argument or point of view without resorting to name-calling.

Upon what basis can you say that you do possess the ability to think rationally and logically? I do quite a bit of thinking, discussing, and writing that is rational and logical. I have several examples of my writing available on my personal website, if you care to take a look, and have been published by the Association for Computing Machinery's Ubiquity. You can see two articles I have published on Rice University's Connexions project here and here.

I would be interested in reading something that you've written and published, that can support an argument or point of view without resorting to name-calling.

Upon what basis can you say that you do possess the ability to think rationally and logically? I do quite a bit of thinking, discussing, and writing that is rational and logical. I have several examples of my writing available on my personal website, if you care to take a look, and have been published by the Association for Computing Machinery's Ubiquity. You can see two articles I have published on Rice University's Connexions project here and here.

I would be interested in reading something that you've written and published, that can support an argument or point of view without resorting to name-calling.

regarding illitirate scribes, I don't know if that was true as a rule.

Certainly I know that manuscripts produced and used in celtic-monasteries have margin notes and other additions that are not the work of illiterates:
c.f. pangur bán: http://www.cs.rice.edu/~ssiyer/minstrels/poems/167 .html

There was also the preservation of written works for their own sake. Many non-religious classical texts were preserved and duplicated in monastic settings, and this went some way to preserving these works during the interregnum following the decline of the Roman empire.

Though surely coming from your personal experience, I think some of your other comments come across as a little prejudiced and over-general. I'd be interested to see the evidence for your origin of copyright laws thesis. And as another poster commented, there's no indication that Newton was by any means an atheist.

It's not the paper it used to be.

Used to be? You mean, when its editorial page mocked Goddard for his idea to send rockets outside the Earth's atmosphere?