Ok, I should have been more verbose. Here is how it works with UDP through NAT.
1) Peer_A opens a UDP socket. Sends a packet to a well known server, or servers, that simply send a reply that contains the source IP and port of the packet.
2) Peer_A records this source IP and Port, as it is what the NAT gateway is masquerading its connection as.
3) Peer_B does the same. It know has its masqueraded IP and PORT from its NAT gateway.
4) Peer_A and Peer_B can now send packets to each other at their respective masqueraded IP and PORTs.
The ALPINE Network uses a flat direct connection network for searching/discovery operations.
There are a few tweaks which improve the efficiency of this type of network, such as a reputation/affinity value attached to peers to keep you connected to the best, while quickly filtering out the worst or dissimilar.
The communication is multiplexed over a single UDP port and can handle hundreds of thousands of concurrent connections at the lowest layer. (higher level ALPINE connections require more overhead, and are restricted to 10,000 to 100,000 depending on user preference)
At any rate, my point is that you can use a simple packet routing architecture like IP to accomplish a flat, large, directly connected network that is usable.
If you want higher performance, more efficiency, and greater throughput you would need to start experimenting with some of the advanced network architectures you mention. However, the chance of such a network reaching the masses any time soon is pretty slim.:/
There are two basic solutions for dual NAT commnication. Unfortunately neither solution is very usefull for a majority of P2P applications.
1) Use a proxy that is not behind a NAT firewal. This opens up problems all its own, which is fairly obvious.
2) Use UDP. For a number of reasons, a lot of people hate this idea as well.
The only hope (currently) is one of two things. First, that NAT firewall vendors will implement a suitable solution to bypass this problem (unlikely) and second, that we all get fixed IP addresses out the ass (about as unlikely).
So, in short, break out the wallet for those beefy relay servers!
OTOH, the bandwidth usage of gnutella searches vs. the total bandwidth available is a very small ratio.
This is probably true. Most gnutella clients would be on smaller DSL or modem links. These would have a hard time overwhelming bandwidth.
In most cases the problem occurs between different ISP level routers or at the client's link itself.
If the traffic on the multicast channel was greater than 56k consistently, the modem clients TCP connections would starve, which would not be good from an end user perspective.
If the traffic was such that a small ISP was using most of their bandwidth (probably outgoing for the multicast to destinations) then all clients of that ISP would be having problems as well.
It really does get pretty tricky quickly. however, there is good progress being made in this area, and perhaps with IPv6 we will begin to see multicast working on a larger scale (I hope so!)
The project I am working uses unicast to multiple destinations that acts very similiar to a multicast. However, I had to build some very elaborate mechanisms into the protocols to keep congestion and TCP starvation from occuring as well as allowing varied bandwidth links the ability to communicate without the fast ones overwhelming the slower ones.
Because dropping packets does not ease congestion. If you are sending a flood of packets that is continually overloading a given router, the TCP connections will starve, and the majority of the UDP multicast packets will be dropped.
This would be a horrible scenario!
There is some good information on TCP friendliness and congestion avoidance algorithms here: http://www.psc.edu/networking/tcp_friendly.html
This really is incredibly important. Anything that starves TCP and introduces congestion at a wide level in the internet is going to wreak havoc.
The biggest problem with multicast over the internet is that it is not supported.
If it was supported, then the biggest problem would be congestion avoidance.
The congestion avoidance algorithms built into TCP are the only saving grace for the internet backbone as it exists today. With any kind of widely deployed multicast, this becomes very critical to implement and work efficiently.
There has been some progress in this area, but it is a very difficult problem. The IETF has a working group on multicast congestion control. Its work is available here:
I am working on a project that may satisfy a number of the intended features you mention.
For exmaple...
As a straight-peer-to-peer network grows, it becomes saturated with traffic. Requests are sent, propagated, and choke the entire network of peer-to-peer clients, usually at the lowest bandwith level.
I saw this first hand when using a modified Gnutella client to monitor the types and number of queries occuring on the network. The vast majority was crap or outright maliscious, and it brought my 1.5Mbps downstream DSL line to a crawl.
But it is possible to have a fully decentralized network that is bandwidth friendly. I am working on it now.
If you try to run this through an established client server system, lawyers decend like flocks of carrion birds.
Another important asecpt of this network is that searching and actual transfer are decoupled. When you find some hits to your query, you are returned a list of locators for that resource. These may be simple HTTP style, or they may be Freenet SHA-1 hash keys. Which means that you can find the content you seek in an open, decentralized network. And the obtain it (if it is senstive data in your country, etc) via a secure, anonymous manner like Freenet.
And finally, the most important aspect of this network is that it is adaptive to your preferences. A very large problem with Gnutella and other peer based networks is spam and irrelevant results. With this network you continually add peers who respond with relevant, quality information, and drop other peers who provide no value.
There are a lot of posts here about how this is simply a rehash of Godel's theorem.
This is partly true, but not point. Godel showed that incompleteness exists in any type of formal system capable of self reference. Ala the infamous "This sentence is false" translated into an equivalent in a formal system. The original is rather obscure and reads:
On Formally Undeciable Propositions in Principa Mathematica and Related Systems
"To every w-consistent recursive class 'k' of formulae there correspond recursive class-signs 'r', such that neither v Gen r nor Neg (v Gen r) belongs to Flg(k) (where 'v' is the free variable of 'r')
This is all well understood and old news at this point. What the author has done is taken Godel's theorem, and the halting problem, and turned them around a different way.
The essence of what he is trying to say is summarized nicely in this paragraph of the conference log:
"So I had a crazy idea. I thought that maybe the problem is larger and Gödel and Turing were just the tip of the iceberg. Maybe things are much worse and what we really have here in pure mathematics is randomness. In other words, maybe sometimes the reason you can't prove something is not because you're stupid or you haven't worked on it long enough, the reason you can't prove something is because there's nothing there! Sometimes the reason you can't solve a mathematical problem isn't because you're not smart enough, or you're not determined enough, it's because there is no solution because maybe the mathematical question has no structure, maybe the answer has no pattern, maybe there is no order or structure that you can try to understand in the world of pure mathematics. Maybe sometimes the reason that you don't see a pattern or structure is because there is no pattern or structure!
He then describes how randomness would indicate an irreducible statement of truth that could not be compressed by finding a 'proof' that proves this truth. The idea being that a 'proof' is a program or function that generates truths, or verifies the truth of a statement.
Again, this is not groundbreaking, Godel proved essentialy the same thing with his proof. The turing halting problem is another variation, but this is where it gets interesting.
The author takes the halting problem and instead of determining whether the program halts or not, determines the probability of the program halting given a random program produced by flipping coins.
The equation to solve this is straightforward, the the 'proof' which is used to determine whether the program halts or not is the computer itself, and the statement is a program produced by random bits from a coin toss. Each bit determined by an individual coin toss.
What you then end up with is a statement that is well defined in number theory terms, but maximally unknowable. Every sample program produced from the random coin toss is a straight forward sequence of 1s or 0s, but the statement as a whole is irreducible.
Again, this seems rather unrelated, until you consider proofs as the computers which calculate the truth or non truth of a given statement.
It then becomes obvious that the truth or non truth of the statement requires a proof that can reduce the statements into a true or non true result. And there are a huge number of situations where such a proof can not exist.
So, godel's theorem deals with incompleteness in a formal system where a single proof cannot encompass the entire set of true and and un-true statements.
The authors work deals with the vast number of statements that are true or un-true, but for which no 'proof' can ever be discovered. They are simply true by random chance.
Which holds a lot of interest for physicists because they have been dealing with truths that are random and true for no provable reason for decades...
Trust - These certs are often a stamp of approval when conducting electronic commerece, etc, that the connection is secure, and that the party is who they say they are.
The first part is fairly straightforward. If you are using SSL then the connection is encrypted, and very likely secure.
It is the second part that makes certificates expensive. The Certificate Authorities (CA's) require a certain amount of information from you upfront before they issue a certificate. This is then used whenever you certificate is used to verify that you are indeed the person who originally received the certificate.
There are varying levels of assurance for this process. Most people opt for the basic level of assurance, which requires some paperwork and verifiable contact information.
There are additional levels which in some cases require your physical presence, a notary public, and some other contraints which I cannot recall, however, these are not used to my knowledge.
So, the root of the problem is that of trust. And trust is not cheap, when accounting for processing, maintenance, liability, etc. I beleive there is also a fair amount of cost to be considered a 'trustworthy' CA by the big browset CO's. Like Internet Exploder and Nutscrape.
eventually they will get tired of playing wack-a-mole
Yes, and that is the scary part. Notice that napster has to be especially wary of both contributory copyright infringement and vicarious copyright infringement.
The latter is the real stickler, because extra effort (aside from the current wack-a-mole strategy) must be expended to shield from this type of liability.
This means that napster would have to proactively monitor their network for infringing material.
The wack-a-mole system will end soon enough, but what replaces it will be much more constricting and may cause napster to abondon sharing and move entirely to their secure content system.
One of the weak points of the multi-tool strategy may be the search engine. The RIAA may be able to convince a judge that searches could be filtered based on songs.
Good point, and I have been working for months on a fully decentralized, open source searching network called the ALPINE Network which performs searching, and only searching.
The actual transfer of resources is done via other networks, like Freenet or Swarmcast, FTP, etc.
The previous poster had the same ideas in mind, namely, provide a decentralized, legally safe peer based searching network, and then use whatever you wish to actually get content/resources.
The searching is the most vulnerable part, and hence the reason I am pushing a fully decentralized network so hard.
This was an excellent article, and towards the end, which some of you may have missed, is a list of things you can do as a peer-to-peer developer or designer to prevent legal liability. These are very interesting suggestions...
1) Your two options: total control or total anarchy.
So, either a secure and monitored Napster or an efficient Gnutella are the two most resistant architectures. This has pretty broad implications.
2) Better to sell stand-alone software products than on-going services.
Assuming that you are using a decentralized model. A centralized service is by nature an ongoing service.
3) Can you plausibly deny knowing what your end-users are up to?
Only in a decntralized or mostly decentralized network. If you try to intentionally make it hard to know what your users are doing, you're again opening yourself up to liability.
4) What are your substantial noninfringing uses?
This applies mainly to a centralized service. And in fact, you really need to have ONLY noninfringing uses if you are turning a profit from the network. (vicarious liability)
5) Disaggregate functions.
For example, use one service to locate content. Use another service to transfer content, preferably in an anonymous, secure fashion. Etc. This is what the ALPINE Network is designed to accomplish.
6) Don't make your money from the infringing activities of your users.
The section on vicarious infringement which this relates to, is rather troubling. If you are a centralized service making money from its popularity (i.e. Napster) you need to have very stringent controls on what your users are doing. Filename filtering is only the very first step, and proactive monitoring is required.
7) Be open source.
Nuff said!
8) Do not be a direct infringer: make and store no copies.
This includes caching content! The DMCA safe harbor rules will not apply to you unless you have gone through a number of hoops to do so. (After reading through the requirements, only ISP's can do this. Anything riding on top of an ISP is pretty much screwed.)
9) Do not build any "circumvention devices" into your product.
Like including a DeCSS filter for downloaded movies.
So, in short, I think a lot of the peer based network that have sprung into recent existance need to chew on this for a while, as many of them do not comply with what is need to be truly safe from legal attack.
Also, this is assuming that current laws remain unchanged. There is a very real possiblity that parts of the DMCA or copyright law will be modified in a more linient manner. Don't hold your breath;)
I remember a quote that Neal Stephenson wrote about his geek tour of transoceanic network cabling. It said, in effect, that the concepts have not changed since the first copper wire was strung beneath the sea. Everything since has been a variation on this single theme. Sending blips of information in one end and receiving them out the other.
You have been very involved and observant of many of the changes occuring within the internet, from peer based networks to social interaction between its users.
Is there anything you have seen that indicates that the future of the net will contain many innovative, unique surprises for us?
Or will progress continue in a linear, continual refinement trajectory with the same things done today only faster/better?
And ideas on what the forthcoming surprises may be?
There are a number of reasons why you would pick any particular RDBMS, but I have seen three which come up most often and are of the most importance.
Support
This is a big one. And an enterprise scale RDBMS needs a lot of support. Ever wonder why some Oracle DBA's make more than skilled developers? Administration of a large database is not trivial, and these databases often run the core of a corporation. Mission critical to the extreme is common for these systems (Hence the reason Oracle can charge millions for a large Oracle Applications ERP installation)
Performace
These big databases are built to handle huge data sets. Oracle supports all kinds of direct interfaces to read/write directly from a SCSI/Fibre channel RAID setup. A number of the Oracle extensions, or custom application also have to be extremely fast given the amount of data they are working. PL/SQL and embeded SQL, OCI, etc, are all tools to allow maximum performace with large heaps of tables and rows.
Add-ons
And by this I mean extra pieces of functionality or applications that are only provided with a specific RDBMS. Oracle Applications, which is a popular ERP package, requires an Oracle database. Likewise, PL/SQL is very popular, but only available for Oracle. Add in all the other niceities that Oracle ships with 8i, and you can see why the entire package is pretty impressive.
So, in the majority of situation a smaller opensource RDBMS like postgreSQL or mSQL will probably work just fine.
If you are n enterprise customer which needs extreme scalability and performace, You would be hard pressed to go with anything other than Oracle or IBM.
There was no mention of how the filtering would work. Is this exact match? Key words?
I know napster would like to have the RIAA provide a long list of full seng titles in proper case. This would be great for avoiding the filtering mechanism by changing a letter, a case.
The RIAA would love to see keyword searching. That search for 'Metallica One' should be enough to filter replies (at least I am sure that is what they would assert).
The injuction may dictate which method Napster has to use to prevent its early demise. Maybe a happy medium between the two.
Programming is much more like artistic composition within contraints (which happen to be mathematically related).
Way back when IBM needed to find the first programmers to code for their new computer systems, they searched for a professional field that matched the requirements for writing software.
Do you know who they actively sought? It was not mathematicians, it was musicians.
Music has a very structured/math like feel to it at the lowest level, but the true expression of music is not number crunching, but artistic expression within contraints.
As for your assertion that math grads make the best programmers, I think you have a far to narrow and biased view of the skills and talents required to produce good software.
No, but the source of hawking radiation is the fact that matter and anti-matter spontaneously form for no reason, and at random all the time. Like magic.
Well, you know what? If no one posts links and provides the content then they have already won without a battle.
I may or may not suffer severe repercussions from my actions, but it will be worth providing the information, and perhaps showing my disdain for severely unconstitutional laws passed in congress.
You absolutely, possitively (in science) CANNOT get something from nothing.
Apparently you have not heard of quantum mechanics. We get a ton of matter created and destroyed at random for nothing. Go look up hawking radiation for starters...
This article is not the proof, it is about the proof, which is from a large volume of genetic information from the humand genome, and many many other species, including the lowly bacteria, which comprise a complete tapestry of evoltionary history among a large group of species.
Before dismissing things offhand because they challenge your faith, try reading the deatils, and actually checking out the research refered to in the article. There is a surprising amount of work that has been done which most people overlook.
Perhaps because it is far easier to pray and have faith in god, than it is to work and toil with intellectually chalenging conecepts to understand the mysteries of life.
Slashdot Mirror
Ok, I should have been more verbose. Here is how it works with UDP through NAT.
1) Peer_A opens a UDP socket. Sends a packet to a well known server, or servers, that simply send a reply that contains the source IP and port of the packet.
2) Peer_A records this source IP and Port, as it is what the NAT gateway is masquerading its connection as.
3) Peer_B does the same. It know has its masqueraded IP and PORT from its NAT gateway.
4) Peer_A and Peer_B can now send packets to each other at their respective masqueraded IP and PORTs.
The ALPINE Network uses a flat direct connection network for searching/discovery operations.
:/
There are a few tweaks which improve the efficiency of this type of network, such as a reputation/affinity value attached to peers to keep you connected to the best, while quickly filtering out the worst or dissimilar.
The communication is multiplexed over a single UDP port and can handle hundreds of thousands of concurrent connections at the lowest layer. (higher level ALPINE connections require more overhead, and are restricted to 10,000 to 100,000 depending on user preference)
At any rate, my point is that you can use a simple packet routing architecture like IP to accomplish a flat, large, directly connected network that is usable.
If you want higher performance, more efficiency, and greater throughput you would need to start experimenting with some of the advanced network architectures you mention. However, the chance of such a network reaching the masses any time soon is pretty slim.
There are two basic solutions for dual NAT commnication. Unfortunately neither solution is very usefull for a majority of P2P applications.
:)
1) Use a proxy that is not behind a NAT firewal. This opens up problems all its own, which is fairly obvious.
2) Use UDP. For a number of reasons, a lot of people hate this idea as well.
The only hope (currently) is one of two things. First, that NAT firewall vendors will implement a suitable solution to bypass this problem (unlikely) and second, that we all get fixed IP addresses out the ass (about as unlikely).
So, in short, break out the wallet for those beefy relay servers!
(or use UDP
OTOH, the bandwidth usage of gnutella searches vs. the total bandwidth available is a very small ratio.
This is probably true. Most gnutella clients would be on smaller DSL or modem links. These would have a hard time overwhelming bandwidth.
In most cases the problem occurs between different ISP level routers or at the client's link itself.
If the traffic on the multicast channel was greater than 56k consistently, the modem clients TCP connections would starve, which would not be good from an end user perspective.
If the traffic was such that a small ISP was using most of their bandwidth (probably outgoing for the multicast to destinations) then all clients of that ISP would be having problems as well.
It really does get pretty tricky quickly. however, there is good progress being made in this area, and perhaps with IPv6 we will begin to see multicast working on a larger scale (I hope so!)
The project I am working uses unicast to multiple destinations that acts very similiar to a multicast. However, I had to build some very elaborate mechanisms into the protocols to keep congestion and TCP starvation from occuring as well as allowing varied bandwidth links the ability to communicate without the fast ones overwhelming the slower ones.
This is the ALPINE Network and the more extensive information about congestion avoidance is here
Because dropping packets does not ease congestion. If you are sending a flood of packets that is continually overloading a given router, the TCP connections will starve, and the majority of the UDP multicast packets will be dropped.
This would be a horrible scenario!
There is some good information on TCP friendliness and congestion avoidance algorithms here: http://www.psc.edu/networking/tcp_friendly.html
This really is incredibly important. Anything that starves TCP and introduces congestion at a wide level in the internet is going to wreak havoc.
Another great site is Peertal at http://www.peertal.com/ for all sorts of news about peer to peer projects and news.
Ben Housten has a good page with ideas and links at http://www.exocortex.org/p2p/index.html
The Peer to peer working group has their site at http://www.peer-to-peerwg.org/
You may also want to check out the Orielly OpenP2P page at http://www.oreillynet.com/p2p/
And of course, I need to shamelessly plug my open source decentralized searching network, the ALPINE Network
The biggest problem with multicast over the internet is that it is not supported.
t -bb-lcc-00.txt
If it was supported, then the biggest problem would be congestion avoidance.
The congestion avoidance algorithms built into TCP are the only saving grace for the internet backbone as it exists today. With any kind of widely deployed multicast, this becomes very critical to implement and work efficiently.
There has been some progress in this area, but it is a very difficult problem. The IETF has a working group on multicast congestion control. Its work is available here:
http://www.ietf.org/internet-drafts/draft-ietf-rm
I am working on a project that may satisfy a number of the intended features you mention.
For exmaple...
As a straight-peer-to-peer network grows, it becomes saturated with traffic. Requests are sent, propagated, and choke the entire network of peer-to-peer clients, usually at the lowest bandwith level.
I saw this first hand when using a modified Gnutella client to monitor the types and number of queries occuring on the network. The vast majority was crap or outright maliscious, and it brought my 1.5Mbps downstream DSL line to a crawl.
But it is possible to have a fully decentralized network that is bandwidth friendly. I am working on it now.
If you try to run this through an established client server system, lawyers decend like flocks of carrion birds.
Another important asecpt of this network is that searching and actual transfer are decoupled. When you find some hits to your query, you are returned a list of locators for that resource. These may be simple HTTP style, or they may be Freenet SHA-1 hash keys. Which means that you can find the content you seek in an open, decentralized network. And the obtain it (if it is senstive data in your country, etc) via a secure, anonymous manner like Freenet.
And finally, the most important aspect of this network is that it is adaptive to your preferences. A very large problem with Gnutella and other peer based networks is spam and irrelevant results. With this network you continually add peers who respond with relevant, quality information, and drop other peers who provide no value.
At any rate, if you are interested, you can read more about this project. It is called the ALPINE Network and the main page is at http://cubicmetercrystal.com/alpine/
Yes, that is true. A better interpretation would be 'This statement has no proof in Principa Mathematica and related formal systems'
This is partly true, but not point. Godel showed that incompleteness exists in any type of formal system capable of self reference. Ala the infamous "This sentence is false" translated into an equivalent in a formal system. The original is rather obscure and reads:
On Formally Undeciable Propositions in Principa Mathematica and Related Systems
This is all well understood and old news at this point. What the author has done is taken Godel's theorem, and the halting problem, and turned them around a different way.
The essence of what he is trying to say is summarized nicely in this paragraph of the conference log:
He then describes how randomness would indicate an irreducible statement of truth that could not be compressed by finding a 'proof' that proves this truth. The idea being that a 'proof' is a program or function that generates truths, or verifies the truth of a statement.
Again, this is not groundbreaking, Godel proved essentialy the same thing with his proof. The turing halting problem is another variation, but this is where it gets interesting.
The author takes the halting problem and instead of determining whether the program halts or not, determines the probability of the program halting given a random program produced by flipping coins.
The equation to solve this is straightforward, the the 'proof' which is used to determine whether the program halts or not is the computer itself, and the statement is a program produced by random bits from a coin toss. Each bit determined by an individual coin toss.
What you then end up with is a statement that is well defined in number theory terms, but maximally unknowable. Every sample program produced from the random coin toss is a straight forward sequence of 1s or 0s, but the statement as a whole is irreducible.
Again, this seems rather unrelated, until you consider proofs as the computers which calculate the truth or non truth of a given statement.
It then becomes obvious that the truth or non truth of the statement requires a proof that can reduce the statements into a true or non true result. And there are a huge number of situations where such a proof can not exist.
So, godel's theorem deals with incompleteness in a formal system where a single proof cannot encompass the entire set of true and and un-true statements.
The authors work deals with the vast number of statements that are true or un-true, but for which no 'proof' can ever be discovered. They are simply true by random chance.
Which holds a lot of interest for physicists because they have been dealing with truths that are random and true for no provable reason for decades...
Two main reasons:
Trust - These certs are often a stamp of approval when conducting electronic commerece, etc, that the connection is secure, and that the party is who they say they are.
The first part is fairly straightforward. If you are using SSL then the connection is encrypted, and very likely secure.
It is the second part that makes certificates expensive. The Certificate Authorities (CA's) require a certain amount of information from you upfront before they issue a certificate. This is then used whenever you certificate is used to verify that you are indeed the person who originally received the certificate.
There are varying levels of assurance for this process. Most people opt for the basic level of assurance, which requires some paperwork and verifiable contact information.
There are additional levels which in some cases require your physical presence, a notary public, and some other contraints which I cannot recall, however, these are not used to my knowledge.
So, the root of the problem is that of trust. And trust is not cheap, when accounting for processing, maintenance, liability, etc. I beleive there is also a fair amount of cost to be considered a 'trustworthy' CA by the big browset CO's. Like Internet Exploder and Nutscrape.
eventually they will get tired of playing wack-a-mole
Yes, and that is the scary part. Notice that napster has to be especially wary of both contributory copyright infringement and vicarious copyright infringement.
The latter is the real stickler, because extra effort (aside from the current wack-a-mole strategy) must be expended to shield from this type of liability.
This means that napster would have to proactively monitor their network for infringing material.
The wack-a-mole system will end soon enough, but what replaces it will be much more constricting and may cause napster to abondon sharing and move entirely to their secure content system.
One of the weak points of the multi-tool strategy may be the search engine. The RIAA may be able to convince a judge that searches could be filtered based on songs.
Good point, and I have been working for months on a fully decentralized, open source searching network called the ALPINE Network which performs searching, and only searching.
The actual transfer of resources is done via other networks, like Freenet or Swarmcast, FTP, etc.
The previous poster had the same ideas in mind, namely, provide a decentralized, legally safe peer based searching network, and then use whatever you wish to actually get content/resources.
The searching is the most vulnerable part, and hence the reason I am pushing a fully decentralized network so hard.
This was an excellent article, and towards the end, which some of you may have missed, is a list of things you can do as a peer-to-peer developer or designer to prevent legal liability. These are very interesting suggestions...
;)
1) Your two options: total control or total anarchy.
So, either a secure and monitored Napster or an efficient Gnutella are the two most resistant architectures. This has pretty broad implications.
2) Better to sell stand-alone software products than on-going services.
Assuming that you are using a decentralized model. A centralized service is by nature an ongoing service.
3) Can you plausibly deny knowing what your end-users are up to?
Only in a decntralized or mostly decentralized network. If you try to intentionally make it hard to know what your users are doing, you're again opening yourself up to liability.
4) What are your substantial noninfringing uses?
This applies mainly to a centralized service. And in fact, you really need to have ONLY noninfringing uses if you are turning a profit from the network. (vicarious liability)
5) Disaggregate functions.
For example, use one service to locate content. Use another service to transfer content, preferably in an anonymous, secure fashion. Etc. This is what the ALPINE Network is designed to accomplish.
6) Don't make your money from the infringing activities of your users.
The section on vicarious infringement which this relates to, is rather troubling. If you are a centralized service making money from its popularity (i.e. Napster) you need to have very stringent controls on what your users are doing. Filename filtering is only the very first step, and proactive monitoring is required.
7) Be open source.
Nuff said!
8) Do not be a direct infringer: make and store no copies.
This includes caching content! The DMCA safe harbor rules will not apply to you unless you have gone through a number of hoops to do so. (After reading through the requirements, only ISP's can do this. Anything riding on top of an ISP is pretty much screwed.)
9) Do not build any "circumvention devices" into your product.
Like including a DeCSS filter for downloaded movies.
So, in short, I think a lot of the peer based network that have sprung into recent existance need to chew on this for a while, as many of them do not comply with what is need to be truly safe from legal attack.
Also, this is assuming that current laws remain unchanged. There is a very real possiblity that parts of the DMCA or copyright law will be modified in a more linient manner. Don't hold your breath
I remember a quote that Neal Stephenson wrote about his geek tour of transoceanic network cabling. It said, in effect, that the concepts have not changed since the first copper wire was strung beneath the sea. Everything since has been a variation on this single theme. Sending blips of information in one end and receiving them out the other.
You have been very involved and observant of many of the changes occuring within the internet, from peer based networks to social interaction between its users.
Is there anything you have seen that indicates that the future of the net will contain many innovative, unique surprises for us?
Or will progress continue in a linear, continual refinement trajectory with the same things done today only faster/better?
And ideas on what the forthcoming surprises may be?
There are a number of reasons why you would pick any particular RDBMS, but I have seen three which come up most often and are of the most importance.
Support
This is a big one. And an enterprise scale RDBMS needs a lot of support. Ever wonder why some Oracle DBA's make more than skilled developers? Administration of a large database is not trivial, and these databases often run the core of a corporation. Mission critical to the extreme is common for these systems (Hence the reason Oracle can charge millions for a large Oracle Applications ERP installation)
Performace
These big databases are built to handle huge data sets. Oracle supports all kinds of direct interfaces to read/write directly from a SCSI/Fibre channel RAID setup. A number of the Oracle extensions, or custom application also have to be extremely fast given the amount of data they are working. PL/SQL and embeded SQL, OCI, etc, are all tools to allow maximum performace with large heaps of tables and rows.
Add-ons
And by this I mean extra pieces of functionality or applications that are only provided with a specific RDBMS. Oracle Applications, which is a popular ERP package, requires an Oracle database. Likewise, PL/SQL is very popular, but only available for Oracle. Add in all the other niceities that Oracle ships with 8i, and you can see why the entire package is pretty impressive.
So, in the majority of situation a smaller opensource RDBMS like postgreSQL or mSQL will probably work just fine.
If you are n enterprise customer which needs extreme scalability and performace, You would be hard pressed to go with anything other than Oracle or IBM.
There was no mention of how the filtering would work. Is this exact match? Key words?
I know napster would like to have the RIAA provide a long list of full seng titles in proper case. This would be great for avoiding the filtering mechanism by changing a letter, a case.
The RIAA would love to see keyword searching. That search for 'Metallica One' should be enough to filter replies (at least I am sure that is what they would assert).
The injuction may dictate which method Napster has to use to prevent its early demise. Maybe a happy medium between the two.
Any thoughts?
This is a typical manager/employer viewpoint.
Programming is much more like artistic composition within contraints (which happen to be mathematically related).
Way back when IBM needed to find the first programmers to code for their new computer systems, they searched for a professional field that matched the requirements for writing software.
Do you know who they actively sought? It was not mathematicians, it was musicians.
Music has a very structured/math like feel to it at the lowest level, but the true expression of music is not number crunching, but artistic expression within contraints.
As for your assertion that math grads make the best programmers, I think you have a far to narrow and biased view of the skills and talents required to produce good software.
No, but the source of hawking radiation is the fact that matter and anti-matter spontaneously form for no reason, and at random all the time. Like magic.
You mean, if I were to Post a Link to the DeCSS Source Code online then I could be charged with distributing illegal content?
Well, you know what? If no one posts links and provides the content then they have already won without a battle.
I may or may not suffer severe repercussions from my actions, but it will be worth providing the information, and perhaps showing my disdain for severely unconstitutional laws passed in congress.
I got my takedown letter for This DeCSS Site via a word document attached to an email.
I guess they dont want to send certified snail mail to tens of thousands of people who post the information.
Nope. Still Here!
What happened to all those DeCSS links? Did they dissappear?
I would really like to see the DeCSS Source Code published by those who care about the chilling implications this has on your personal rights.
You absolutely, possitively (in science) CANNOT get something from nothing.
Apparently you have not heard of quantum mechanics. We get a ton of matter created and destroyed at random for nothing. Go look up hawking radiation for starters...
This article is not the proof, it is about the proof, which is from a large volume of genetic information from the humand genome, and many many other species, including the lowly bacteria, which comprise a complete tapestry of evoltionary history among a large group of species.
Before dismissing things offhand because they challenge your faith, try reading the deatils, and actually checking out the research refered to in the article. There is a surprising amount of work that has been done which most people overlook.
Perhaps because it is far easier to pray and have faith in god, than it is to work and toil with intellectually chalenging conecepts to understand the mysteries of life.