Only at a college where the women are outnumbered by the men about ten-to-one would something like this even be conceived.
This is a tired myth. In fact 41% of all undergraduates and 29% of all graduate students at MIT are female. The situation is admittedly less equitable in the faculty ranks, where only 16% are female.
There is no silver bullet, but having a good programming language sure helps. Of all programming language features, garbage collection probably improves programmer productivity the most. Anyone who has ever tracked down a stubborn memory leak or dangling pointer knows what I mean. Most newer languages (e.g. Java, C#, Python) have some sort of automatic storage reclamation, and it can be used with non-cooperative languages like C/C++.
Re:The problems with Gnutella 1
on
Gnutella2?
·
· Score: 4, Insightful
What may not be clear to many Slashdot readers is that the Gnutella protocol has been steadily improving over the last few months. Let me correct the previous poster on a few points:
Search results. You only get about 4-7 hops. Assuming 4 hops & 4 non-redundant connections per node, that means you are only searching about 256 nodes.
Your math is way off here. Try 7 hops with 6 connections, plus an extra factor of 100 or so from ultrapeers. That said, we are always looking for ways to improve searching. Ultrapeers were one step along that path.
Fifo queuing. You may have been requesting a file for the past 24 hours, but someone that just requested a file may get lucky, and take what should have been your spot.
Many clients (e.g., LimeWire, BearShare, Shareaza, Gtk-Gnutella) have supported this for some time now. They all interoperate too.
Bandwith Min/Max for Uploads/Downloads. A limit on the min/max speed for each file download/uploaded, and a min/max for the TOTAL of all downloads/uploads.
All decent client have features like this. But note that this is an implementation issue, not a protocol issue.
Search by hash
This has been supported for many months, thanks to Gordon Mohr's HUGE proposal.
Metadata
LimeWire has had XML-based metadata for over a year. I believe Shareaza uses the same scheme.
As these examples show, the GDF has been quite successful at driving innovation on the Gnutella network. But caution is sometimes in order; it can be hard to predict the result of thousands of clients running a new protocol. It would be good for Shareaza to submit its new extensions for peer review before rolling out thousands of clients. It is easy to build a client that gets more search results; it is harder to do that without hurting the entire network.
One problem I see with this study is it doesn't account for ultrapeers, technology that was released by LimeWire in early January. Ultrapeers increase scalability by offloading most of the bandwidth burden to dynamically-elected high-speed hosts. Unlike Fasttrack, ultrapeers use an open protocol with open-source implementations. I believe BearShare is also adding ultrapeer support.
One problem with LimeWire's initial implementation is that ultrapeers didn't respond to "crawler pings" with "leaf pongs". (We've since changed that.) So as pretty as these pictures are, they're probably not accurate. I would love to see updated results that accounted for ultrapeers.
The Gnutella network is evolving rapidly, and it would be great if academic papers considered these changes. The Gnutella Developer Forum (GDF) is the primary location for protocol development.
It would also be fantasy to ignore the knowledge and experience of your team, present and future. One does not become fluent in a programming language overnight. There's more than just learning its control structures, scoping rules, etc. So it may be advisable to use a standard language even if it isn't the perfect tool for the job.
LimeWire has attacked this problem by introducing "ultrapeers", which offload most of the bandwidth to a small subset of hosts. It works really well. Unlike FastTrack, this is an open-protocol with an open-source implementation available.
The next step is to add more sophisticated routing protocols between ultrapeers. Many of the algorithms mentioned elsewhere in this post (Chord, CAN, etc.) are contenders for that, as is LimeWire's home-grown query-routing proposal.
This is not a new idea, nor is it exclusively the domain of economics. In The Selfish Gene, for example, the biologist Richard Dawkins discusses the evolution of cooperation. He gives the example of chimps removing insects from others' backs. This benefits everyone, since a chimp cannot easily remove insects from his own back. Unfortunately a freeloader who takes without giving benefits even more--unless the others have a way of recognizing and shunning him. Perhaps this is why many animals have such good face recognition.
I have used Limewire in the past and I like it a lot, but the CPU load makes me cry
LimeWire uses a negligible amount of CPU on my machine. Sharing a lot of files should not make a lot of difference, since LimeWire uses a rather sophisticated indexing mechanism. Perhaps you're using an outdated JVM? Or you've set the JVM max heap size (-mx) too small?
Finally one thin I would like to see: A pure and true gnutella server daemon.
Check out the core package of the LimeWire project. There's a minimal command-line interface version buried in there. Probably not hard to get it to do what you want.
It's also worth pointing out that you CAN have a native look and feel if you want. It's a one line code change. We could easily make it an option in the LimeWire GUI, but we like our cross-platform L&F much better.
Native integration is not that difficult. We've added some native code for Windows (system tray, file launching, etc.) since that's the vast majority of users. We'd welcome any volunteers to add native support (like file launching) to other platforms. Hey, I run LimeWire on Linux myself.
No client-side Java on Windows you say? What about the 3+ million people who have downloaded LimeWire, a Java-based Gnutella client? Every Windows installer contains a full copy of the JRE.
Slashdot Mirror
This is a tired myth. In fact 41% of all undergraduates and 29% of all graduate students at MIT are female. The situation is admittedly less equitable in the faculty ranks, where only 16% are female.
There is no silver bullet, but having a good programming language sure helps. Of all programming language features, garbage collection probably improves programmer productivity the most. Anyone who has ever tracked down a stubborn memory leak or dangling pointer knows what I mean. Most newer languages (e.g. Java, C#, Python) have some sort of automatic storage reclamation, and it can be used with non-cooperative languages like C/C++.
What may not be clear to many Slashdot readers is that the Gnutella protocol has been steadily improving over the last few months. Let me correct the previous poster on a few points:
Search results. You only get about 4-7 hops. Assuming 4 hops & 4 non-redundant connections per node, that means you are only searching about 256 nodes.
Your math is way off here. Try 7 hops with 6 connections, plus an extra factor of 100 or so from ultrapeers. That said, we are always looking for ways to improve searching. Ultrapeers were one step along that path.
Fifo queuing. You may have been requesting a file for the past 24 hours, but someone that just requested a file may get lucky, and take what should have been your spot.
Many clients (e.g., LimeWire, BearShare, Shareaza, Gtk-Gnutella) have supported this for some time now. They all interoperate too.
Bandwith Min/Max for Uploads/Downloads. A limit on the min/max speed for each file download/uploaded, and a min/max for the TOTAL of all downloads/uploads.
All decent client have features like this. But note that this is an implementation issue, not a protocol issue.
Search by hash
This has been supported for many months, thanks to Gordon Mohr's HUGE proposal.
Metadata
LimeWire has had XML-based metadata for over a year. I believe Shareaza uses the same scheme.
As these examples show, the GDF has been quite successful at driving innovation on the Gnutella network. But caution is sometimes in order; it can be hard to predict the result of thousands of clients running a new protocol. It would be good for Shareaza to submit its new extensions for peer review before rolling out thousands of clients. It is easy to build a client that gets more search results; it is harder to do that without hurting the entire network.
Christopher Rohrs
LimeWire
One problem with LimeWire's initial implementation is that ultrapeers didn't respond to "crawler pings" with "leaf pongs". (We've since changed that.) So as pretty as these pictures are, they're probably not accurate. I would love to see updated results that accounted for ultrapeers.
The Gnutella network is evolving rapidly, and it would be great if academic papers considered these changes. The Gnutella Developer Forum (GDF) is the primary location for protocol development.
Christopher Rohrs
Sr. Software Engineer
LimeWire
It would also be fantasy to ignore the knowledge and experience of your team, present and future. One does not become fluent in a programming language overnight. There's more than just learning its control structures, scoping rules, etc. So it may be advisable to use a standard language even if it isn't the perfect tool for the job.
The next step is to add more sophisticated routing protocols between ultrapeers. Many of the algorithms mentioned elsewhere in this post (Chord, CAN, etc.) are contenders for that, as is LimeWire's home-grown query-routing proposal.
Christopher Rohrs
LimeWire
Ever listened to Paul Harvey? Same thing--seemless blending of news and advertising!
This is not a new idea, nor is it exclusively the domain of economics. In The Selfish Gene, for example, the biologist Richard Dawkins discusses the evolution of cooperation. He gives the example of chimps removing insects from others' backs. This benefits everyone, since a chimp cannot easily remove insects from his own back. Unfortunately a freeloader who takes without giving benefits even more--unless the others have a way of recognizing and shunning him. Perhaps this is why many animals have such good face recognition.
I have used Limewire in the past and I like it a lot, but the CPU load makes me cry
LimeWire uses a negligible amount of CPU on my machine. Sharing a lot of files should not make a lot of difference, since LimeWire uses a rather sophisticated indexing mechanism. Perhaps you're using an outdated JVM? Or you've set the JVM max heap size (-mx) too small?
Finally one thin I would like to see: A pure and true gnutella server daemon.
Check out the core package of the LimeWire project. There's a minimal command-line interface version buried in there. Probably not hard to get it to do what you want.
-Christopher Rohrs
Senior Software Engineer
LimeWire
It's also worth pointing out that you CAN have a native look and feel if you want. It's a one line code change. We could easily make it an option in the LimeWire GUI, but we like our cross-platform L&F much better.
Native integration is not that difficult. We've added some native code for Windows (system tray, file launching, etc.) since that's the vast majority of users. We'd welcome any volunteers to add native support (like file launching) to other platforms. Hey, I run LimeWire on Linux myself.
-Christopher Rohrs
Senior Software Engineer
LimeWire
No client-side Java on Windows you say? What about the 3+ million people who have downloaded LimeWire, a Java-based Gnutella client? Every Windows installer contains a full copy of the JRE.