Hitler created a new police/military wing to deal with the "dangers" posed by the people involved with the Reichstag fires and other "internal threats" -- the SS (Bush's equivalent is the Department of Homeland Security).
The SS existed before the Reichstag was set on fire and it wasn't the German secret police (that would have been the GeStaPo). The SS was a para-militaric organization within the NSDAP (the ruling party at that time) which had organized the genocide and owned the concentration and extermination camps.
wind converters can produce about 20 to 100 times the energy needed to build and support them.
Taking the energy out of the wind is pretty much impossible with wind converters, - just consider the area covered by the turbine (maybe 200m).
Commonly when speaking about power plants, you specify the power produced under ideal conditions, not the average power produced by the plant. So a 1,000 MW coal plant will usually produce only 800-900 MWa of energy per year.
If you say '5MW plant' you never mean the average power production of that plant.
There is no way you can detect some of those hostilities except by the increased overall query traffic. A node can not keep track of the number of connetion to the network another node keeps.
That's simply impossible. You can say you won't allow more than X queries in N minuetes but a hostile client would simply disconnect after sending those X queries and you wouldn't know if it is really a hostile client or if the connection just failed...
No. The papers were a complicated mix of old documents and new additions (most not documented nor indexed).
You are an idiot. And I'm not even going to bother explaining to you in detail why those papers are not complex at all for the experienced developer.
Even worse, you had to search a path through old v0.4 specs, old GDF postings and finally reading open source code (to reverse engineer what the core communication does). Then you had to test your own Gnutella code against other clienst and ask on the GDF why it doesn't work with client x or client y.
Most of those questions came from dim-witted school boys who thought they could be the next Shawn Fanning because they had read "A Beginner's Guide To Visual Basic". Most of them didn't even bother to read the specs carefully.
AFAIK G2 was never planed nor designed nor announced as a proprietary network, so your false rumours are wrong.
Look up the meaning of the word 'proprietary', please.
Vinnie (who owns gnutella3.com) has said that Bearshare will be "moving forward with our own proprietary Gnutella 3 technology".
That was more or less an empty threat, as Vinnie admitted later on BearShare. There are no concrete plans from BearShare's side to create a proprietary new protocol.
Even well integrated features like 'swarmed downloading' were once rated "bad" from those developers who didn't have it in their own clients - now it's standard in every client.
It was rated "bad" that Xolox had implemented a proprietary sub-protocol for its swarming without discussing it with the other developers.
Limewire decided to call it's superpeer concept "Ultrapeer" to make it look better than other P2P systems
Not true. Ultrapeers were initially called supernodes. The name was changed because they are working slightly different. Supernodes are indexing the files of the leafs, Ultrapeers aren't.
Of course there are exception! I'd like to name two: For exmaple one open source developer, John from Gnucleus, has written lines and lines of free code.
And so do LimeWire, gtk-gnutella, mutella or Phex. Shareaza however is completely proprietary.
For example, the Gnutella protocol documentation at http://rfc-gnutella.sourceforge.net/ [sourceforge.net] mainly from Tor Klingberg & Raphael Manfredi - which was started long after the big ones had there userbase already (no papers prolly to keep new developers away and to increase greedy spyware businees plans? *asking*).
Crap. The papers have always been available at the GDF yahoogroup and at LimeWire.com. You didn't even have to join the group to download them so it did not take a Raphael Manfredi or a Tor Klingberg to document the gnutella protocol.
hope those guys and also Shareaza keep their motivation to innovate and help the Gnutella community
Shareaza chose to create its own proprietary protocol instead.
That's because the kind of improvements Mike wanted to make couldn't be done with that kind of model.
That's simply not true. Mike claimed that on the gnutella developer forum as well but he could not come up with a single feature that could not be implemented as well using the old protocol OR requiring only slight alterations to the existing model.
Others would say users are more important than the other developers.
If Mike were interested in the experience of his users he would go open source and collaborate with other developers to improve his software.
There is NO possibility of reliably blocking hostile clients. You look out for a pattern in their user-agent, messages, anything - they can change it easily.
You try to count the queries they are sending, - they simply drop connections often or even claim that some else originated a query and they are merely passing it on.
This has been discussed often and lengthy but you simply cannot protect an open network against malicious clients.
As everyone here knows, the biggest problem with Gnutella is the sheer amount of bandwidth that each servent uses by just trying to "actively" discover hosts by using pings and pongs--but is this method really necessary?
Gnutella has stopped using Pings/Pongs that excessively almost two years ago. Today most of the bandwidth is used for routing queries and queryhits.
Gnutella is currently scaling infinitely. But it does and will never be able to let one user search the entire network. On Fasttrack or any other decentralized p2p network not a single search will ever reach more than a certain network horizon. The challenge is to increase this searchable horizon as much as possible. Clients sending many, many queries reduce this horizon because the more queries are sent, the sooner they will be flow-controlled. The only solution to this problem is, that every client says: "I'm just going send so many queries that are just as long-lived to find one or two hundred results and then I'm going to stop to free resources for others."
If there are many selfish users/clients searching for as many results as possible you can as well forget the whole open network thing. The most exciting idea behind Gnutella is that everybody can connect to it. This is its greatest strength and its greatest weekness at the same time. We will see if the world is ready for such a network or if it will go down the same road as Socialism;-)
1. Compression of gnutella peer/ultrapeer/leaf traffic a la zlib. (my little cablemodem that used to be able to support up to 110 connections now supports up to 290 connections as ultrapeer with compressed streams.)
Proposed and implemented first by gtk-gnutella. However LimeWire is also using some form of compression.
2. Tigertree hashing - tigertree, as well as e-donkey2k, sha1 and md5 hashes (i believe) are all supported. Not sure if shazaa actually verifies each chunk against the tigertree, but it _should_.
md4/md5 hashes won't be used by others because it creates a huge redundancy. If you have two files, one with a md4 has the other one with a sha-1 hash you can't make sure if they have the same content or not. As far as tigertree hashing is concerned, nobody ever said it wouldn't be implemented after it was proposed by Gordon Mohr. LimeWire has it on their to-do list for example.
3. Ultrapeer "crawling" via udp queries.
Even that was decided to be used before Gnutella2 was released.
My problem is, that Mike Stokes knew those features would be implemented but he didn't take part in the discussion, he kept his ideas for himself to be the first one implementing them.
The GDF was productive (it produces the proposals more quickly then the GDF members are implementing them).
Shareaza hasn't (yet) broken the existing gnetwork.
The way you say it, it sounds like that is just a matter of time. - By the way, Shareaza is sending corrupt alternate locations, so it is breaking the network.
1. Compression of gnutella peer/ultrapeer/leaf traffic a la zlib. (my little cablemodem that used to be able to support up to 110 connections now supports up to 290 connections as ultrapeer with compressed streams.)
Proposed and implemented first by gtk-gnutella. However LimeWire is also using some form of compression.
2. Tigertree hashing - tigertree, as well as e-donkey2k, sha1 and md5 hashes (i believe) are all supported. Not sure if shazaa actually verifies each chunk against the tigertree, but it _should_.
md4/md5 hashes won't be used by others because it creates a huge redundancy. If you have two files, one with a md4 has the other one with a sha-1 hash you can't make sure if they have the same content or not. As far as tigertree hashing is concerned, nobody ever said it wouldn't be implemented after it was proposed by Gordon Mohr. LimeWire has it on their to-do list for example.
3. Ultrapeer "crawling" via udp queries.
Even that was decided to be used before Gnutella2 was released.
My problem is, that Mike Stokes knew those features would be implemented but he didn't take part in the discussion, he kept his ideas for himself to be the first one implementing them.
The GDF was productive (it produces the proposals more quickly then the GDF members are implementing them).
Shareaza hasn't (yet) broken the existing gnetwork.
The way you say it, it sounds like that is just a matter of time. - By the way, Shareaza is sending corrupt alternate locations, so it is breaking the network.
Last statement I read was an estimation of 20,000 users but that was some two or three weeks ago. But maybe he changed is mind.
I don't know what he means by "node capacity"
LimeWire/BearShare said they would implement the parts of the protocol that they like but not the whole thing. E.g. Shareaza's idea to prevent DDOS attacks using resources of the gnutella network will probably be used in some way.
1) The developers opposing Gnutella2 seem to be the LimeWire developers (their client is open-source under the GPL see www.limewire.org), gtk-gnutella (GPL as well, see gtk-gnutella.sf.net) and BearShare (not open-source). So calling this a war between free and commercial is stupid, especially since Shareaza IS NOT open-source.
2) LimeWire and the other opposed Gnutella2 for a variety of reasons. They didn't want a new message format where the old would still work, they preferred the GUESS search algorithm over the Gnutella2 search and they said they would not accept the name because if there ever was a Gnutella2 it should be announced by the whole GDF (Gnutella Developer Forum) and not by a single developer.
3) After Shareaza developer Mike Stokes has shown an attitude towards the GDF that could very well be called hostile, things got a little out of hand. The GDF now demands that Mike hands the Gnutella2.com domain to the people running Gnutella.com. Mike won't do so and Raphael Manfraedi (gtk-gnutella) has even proposed to start blocking gnutella2 enabled clients.
4) Shareaza fan's like the one who posted this news story helped a great deal to create the current situation by flaming on the GDF, posting rumors and lies (like Shareaza had 80k-100k users - even Mike Stokes denied that) on various news sites and in gnutella-centric forums.
5) The Gnutella2 protocol is still an undocumented proprietary extension.
It was called PARQ and it was not used because it was more complicated to implement. And PARQ was proposed weeks after the first ideas about remote queueing - which came from LimeWire actually.
Oh, and what about your Remote Queueing feature? Shareaza founded that, and it's included in Limewire. Mike wants to cooperate, but your not giving him a chance.
A similar remote queueing was (if I'm not completely mistaken) discussed on the GDF before Shareaza published the proposal and I think LimeWire had already started implementing something very much alike (I found that when browsing through their cvs branches a while back). So claiming Shareaza is the sole inventor of gnutella's remote queueing is simply not true. It was publicly discussed, many developers expressed their ideas and sometime later Shareaza wrote a proposal...
Slashdot Mirror
The SS existed before the Reichstag was set on fire and it wasn't the German secret police (that would have been the GeStaPo). The SS was a para-militaric organization within the NSDAP (the ruling party at that time) which had organized the genocide and owned the concentration and extermination camps.
wind converters can produce about 20 to 100 times the energy needed to build and support them. Taking the energy out of the wind is pretty much impossible with wind converters, - just consider the area covered by the turbine (maybe 200m).
Commonly when speaking about power plants, you specify the power produced under ideal conditions, not the average power produced by the plant. So a 1,000 MW coal plant will usually produce only 800-900 MWa of energy per year. If you say '5MW plant' you never mean the average power production of that plant.
5MW is just the amount of power this turbine would produce if wind blew 24/7. Effectively you will get an average of maybe 20%-35% of that power.
There is no way you can detect some of those hostilities except by the increased overall query traffic. A node can not keep track of the number of connetion to the network another node keeps. That's simply impossible. You can say you won't allow more than X queries in N minuetes but a hostile client would simply disconnect after sending those X queries and you wouldn't know if it is really a hostile client or if the connection just failed...
No. The papers were a complicated mix of old documents and new additions (most not documented nor indexed).
You are an idiot. And I'm not even going to bother explaining to you in detail why those papers are not complex at all for the experienced developer.
Even worse, you had to search a path through old v0.4 specs, old GDF postings and finally reading open source code (to reverse engineer what the core communication does). Then you had to test your own Gnutella code against other clienst and ask on the GDF why it doesn't work with client x or client y.
Most of those questions came from dim-witted school boys who thought they could be the next Shawn Fanning because they had read "A Beginner's Guide To Visual Basic". Most of them didn't even bother to read the specs carefully.
AFAIK G2 was never planed nor designed nor announced as a proprietary network, so your false rumours are wrong.
Look up the meaning of the word 'proprietary', please.
Vinnie (who owns gnutella3.com) has said that Bearshare will be "moving forward with our own proprietary Gnutella 3 technology".
That was more or less an empty threat, as Vinnie admitted later on BearShare. There are no concrete plans from BearShare's side to create a proprietary new protocol.
Even well integrated features like 'swarmed downloading' were once rated "bad" from those developers who didn't have it in their own clients - now it's standard in every client.
It was rated "bad" that Xolox had implemented a proprietary sub-protocol for its swarming without discussing it with the other developers.
Limewire decided to call it's superpeer concept "Ultrapeer" to make it look better than other P2P systems
Not true. Ultrapeers were initially called supernodes. The name was changed because they are working slightly different. Supernodes are indexing the files of the leafs, Ultrapeers aren't.
Of course there are exception! I'd like to name two: For exmaple one open source developer, John from Gnucleus, has written lines and lines of free code.
And so do LimeWire, gtk-gnutella, mutella or Phex. Shareaza however is completely proprietary.
For example, the Gnutella protocol documentation at http://rfc-gnutella.sourceforge.net/ [sourceforge.net] mainly from Tor Klingberg & Raphael Manfredi - which was started long after the big ones had there userbase already (no papers prolly to keep new developers away and to increase greedy spyware businees plans? *asking*).
Crap. The papers have always been available at the GDF yahoogroup and at LimeWire.com. You didn't even have to join the group to download them so it did not take a Raphael Manfredi or a Tor Klingberg to document the gnutella protocol.
hope those guys and also Shareaza keep their motivation to innovate and help the Gnutella community
Shareaza chose to create its own proprietary protocol instead.
That's because the kind of improvements Mike wanted to make couldn't be done with that kind of model.
That's simply not true. Mike claimed that on the gnutella developer forum as well but he could not come up with a single feature that could not be implemented as well using the old protocol OR requiring only slight alterations to the existing model.Others would say users are more important than the other developers.
If Mike were interested in the experience of his users he would go open source and collaborate with other developers to improve his software.Just a few comments on your comment. KaZaA (Lite) works in Linux under Wine.
People who seriously claim that have never used Kazaa under WINE. Gnutella may have its problems but Kazaa on WINE is just ugly.There is NO possibility of reliably blocking hostile clients. You look out for a pattern in their user-agent, messages, anything - they can change it easily. You try to count the queries they are sending, - they simply drop connections often or even claim that some else originated a query and they are merely passing it on. This has been discussed often and lengthy but you simply cannot protect an open network against malicious clients.
It's nothing I haven't already seen among developers. It seems to be quite common on certain - ahem - open source devel mailing lists.
As everyone here knows, the biggest problem with Gnutella is the sheer amount of bandwidth that each servent uses by just trying to "actively" discover hosts by using pings and pongs--but is this method really necessary?
Gnutella has stopped using Pings/Pongs that excessively almost two years ago. Today most of the bandwidth is used for routing queries and queryhits.
Gnutella is currently scaling infinitely. But it does and will never be able to let one user search the entire network. On Fasttrack or any other decentralized p2p network not a single search will ever reach more than a certain network horizon. The challenge is to increase this searchable horizon as much as possible. Clients sending many, many queries reduce this horizon because the more queries are sent, the sooner they will be flow-controlled. The only solution to this problem is, that every client says: "I'm just going send so many queries that are just as long-lived to find one or two hundred results and then I'm going to stop to free resources for others."
If there are many selfish users/clients searching for as many results as possible you can as well forget the whole open network thing. The most exciting idea behind Gnutella is that everybody can connect to it. This is its greatest strength and its greatest weekness at the same time. We will see if the world is ready for such a network or if it will go down the same road as Socialism ;-)
1. Compression of gnutella peer/ultrapeer/leaf traffic a la zlib. (my little cablemodem that used to be able to support up to 110 connections now supports up to 290 connections as ultrapeer with compressed streams.)
Proposed and implemented first by gtk-gnutella. However LimeWire is also using some form of compression.
2. Tigertree hashing - tigertree, as well as e-donkey2k, sha1 and md5 hashes (i believe) are all supported. Not sure if shazaa actually verifies each chunk against the tigertree, but it _should_.
md4/md5 hashes won't be used by others because it creates a huge redundancy. If you have two files, one with a md4 has the other one with a sha-1 hash you can't make sure if they have the same content or not. As far as tigertree hashing is concerned, nobody ever said it wouldn't be implemented after it was proposed by Gordon Mohr. LimeWire has it on their to-do list for example.
3. Ultrapeer "crawling" via udp queries. Even that was decided to be used before Gnutella2 was released.
My problem is, that Mike Stokes knew those features would be implemented but he didn't take part in the discussion, he kept his ideas for himself to be the first one implementing them. The GDF was productive (it produces the proposals more quickly then the GDF members are implementing them).
Shareaza hasn't (yet) broken the existing gnetwork.
The way you say it, it sounds like that is just a matter of time. - By the way, Shareaza is sending corrupt alternate locations, so it is breaking the network.
1. Compression of gnutella peer/ultrapeer/leaf traffic a la zlib. (my little cablemodem that used to be able to support up to 110 connections now supports up to 290 connections as ultrapeer with compressed streams.) Proposed and implemented first by gtk-gnutella. However LimeWire is also using some form of compression. 2. Tigertree hashing - tigertree, as well as e-donkey2k, sha1 and md5 hashes (i believe) are all supported. Not sure if shazaa actually verifies each chunk against the tigertree, but it _should_. md4/md5 hashes won't be used by others because it creates a huge redundancy. If you have two files, one with a md4 has the other one with a sha-1 hash you can't make sure if they have the same content or not. As far as tigertree hashing is concerned, nobody ever said it wouldn't be implemented after it was proposed by Gordon Mohr. LimeWire has it on their to-do list for example. 3. Ultrapeer "crawling" via udp queries. Even that was decided to be used before Gnutella2 was released. My problem is, that Mike Stokes knew those features would be implemented but he didn't take part in the discussion, he kept his ideas for himself to be the first one implementing them. The GDF was productive (it produces the proposals more quickly then the GDF members are implementing them). Shareaza hasn't (yet) broken the existing gnetwork. The way you say it, it sounds like that is just a matter of time. - By the way, Shareaza is sending corrupt alternate locations, so it is breaking the network.
Last statement I read was an estimation of 20,000 users but that was some two or three weeks ago. But maybe he changed is mind. I don't know what he means by "node capacity"
LimeWire/BearShare said they would implement the parts of the protocol that they like but not the whole thing. E.g. Shareaza's idea to prevent DDOS attacks using resources of the gnutella network will probably be used in some way.
1) The developers opposing Gnutella2 seem to be the LimeWire developers (their client is open-source under the GPL see www.limewire.org), gtk-gnutella (GPL as well, see gtk-gnutella.sf.net) and BearShare (not open-source). So calling this a war between free and commercial is stupid, especially since Shareaza IS NOT open-source.
2) LimeWire and the other opposed Gnutella2 for a variety of reasons. They didn't want a new message format where the old would still work, they preferred the GUESS search algorithm over the Gnutella2 search and they said they would not accept the name because if there ever was a Gnutella2 it should be announced by the whole GDF (Gnutella Developer Forum) and not by a single developer.
3) After Shareaza developer Mike Stokes has shown an attitude towards the GDF that could very well be called hostile, things got a little out of hand. The GDF now demands that Mike hands the Gnutella2.com domain to the people running Gnutella.com. Mike won't do so and Raphael Manfraedi (gtk-gnutella) has even proposed to start blocking gnutella2 enabled clients.
4) Shareaza fan's like the one who posted this news story helped a great deal to create the current situation by flaming on the GDF, posting rumors and lies (like Shareaza had 80k-100k users - even Mike Stokes denied that) on various news sites and in gnutella-centric forums.
5) The Gnutella2 protocol is still an undocumented proprietary extension.
It was called PARQ and it was not used because it was more complicated to implement. And PARQ was proposed weeks after the first ideas about remote queueing - which came from LimeWire actually.
Looks like that Shareaza guy will have a hard time finding support for his new protocol by other developers...
We all remember how OS/2 pushed Windows 3.11 from the market because of its superior interface and memory management.