...now we have to figure out how to fix it. None of the OEMs like MS's restrictive licensing, but they know that even if they all got together and refused to accept the new terms Microsoft would just stop giving them all OEM discounts. Like one of the posters above said: Microsoft will suffer minutely decreased sales from the increased price, but the OEMs' margins will go from razor thin to nearly invisible. None of them want to risk it because they don't have another OS to fall back on if Microsoft doesn't accept their terms.
What we need to do is make sure there is another OS that's as good on the desktop as Windows. That way OEMs have choice and Microsoft has competition.
On the internet, it's fairly easy to generate a new identity. Just redail your isp on a modem, release and renew your IP on cable, or re-authenticate with PPPoE on DSL and you've got a new IP. If you're using a system that incorporates public key cryptography, just generate a new key pair and you're indistinguishable from a fresh node on the network. When people can "reset" like that and the system only allows for the accumulation of bad karma, there's no incentive to keep the same identity for long.
Good karma, combined with a starting "entry" karma that's not good enough to get a node serviced by others, encourages people to keep the same identity for a longer period of time. If a user has to contribute a little before they can search and download, the user is incapable of connecting and spamming the network right away. Once the user has gained karma to the point where they can search and download, the user is more likely to continue that good behavior. Why? Because behaving badly (spamming, clogging the network, etc...) would take away that hard-won good karma and make it necessary to start all over again.
What we need is a system that has both bad karma and good karma, but that doesn't associate them. Neither can cancel the other one out, and only hosts with sufficient good karma and sufficiently low bad karma would be serviced. Both should be initialized to 0 upon connecting. This is the simplest solution that I can think of off the top of my head. However, I remember reading a really well-written article involving an intricate trust system that sounded like it would be even more effective. Too bad I don't have it bookmarked....
Ok. So you're talking about ignoring servers that respond to queries that do not have to do with your specific interests. As I see it, there are a couple problems with that:
1. If you only use your client to search for anime, what happens when your client sees lots of queries for "mp3" or "porn" and includes those terms in a validation search? Lots of hosts will respond to those queries, bloating your "ignored hosts" table and hammering your internet connection with query hits. 2. What about people that share your interests but also have others of their own? A validation search with the terms "metallica" and "mp3" will provoke a query hit from a host that has a file named "metallica-song.mp3" as well as "anime-episode.mpg". Since that host responds to your validation search, it will be ignored.
Somebody wrote comments in reply to this article, pleading for more testers of GNUnet and giFT, neither of which is "ready" enough to release Windows binaries, or even a source tarball that will compile properly under MinGW. I'm not saying nobody should test out those systems. In this case, only users who are willing to download the sources, do a little hacking/run linux, and compile should (and could) test them out. My original post wasn't suggesting that people need to go out of their way to learn new skills or spend lots of time getting frustrated with their compiler - only that users should test out all that they are able to and evaluate the merits of new systems.
I was specifically referring to the policies of many Direct Connect hubs. Ok.
I already [download one at a time], using software such as WinMX that supports a local queue. Good for you! A lot of people don't have the courtesy to do that, and it really helps out the network. I can't offer you much help about getting kicked there. In my experience winmx users tend to micromanage - it's not as bad elsewhere.
And if I'm not available often (I only get 150 hours per month on my dial-up plan), then I feel like I'm cheating people who try to download rare stuff from me when I cut them off. Two things: 1. Investigate other dial-up ISPs (if there are any in your area). Many are offering unlimited hours per month. 2. Even if you drop someone who's trying to download a rare file, you provided that person with an opportunity they otherwise wouldn't have had to get a few more bytes. In addition, if you served the initial bytes in the file to that person, you gave that person a valid hash to search for later thereby vastly improving their chances of finding other sources for the same data.
And what about recordings of my own performance? I'm a musician, but I suck at vocals so I just record instrumental music. How do I make those available on a P2P network?
Just drop them in your shared folder. If you're using a p2p system that supports metadata, make sure to fully describe you music (i.e. set the genre, release date, author, title, etc...). You may not be able to put as much bandwidth toward "getting them out there" as you would want, but that's the plight of anyone who has data and wants it hosted. Not being a musician, I couldn't point you toward any known good and reliable web-based mp3.com style "exposure" sites. Maybe someone else on slashdot will have a suggestion?
Is using gnucleus and WinMX on the same modem a problem? In general, running more than one p2p client on a single connection is not a good idea. Inside a p2p client's program logic, essential, high-priority, latency-sensitive data (searches and routing updates) can be differentiated from (and prioritized over) less critical or latency insensitive data (file transfers). With intelligent bandwidth throttling code this works out pretty well. However, when more than one p2p client is running at the same time and both are set to use a max of 70% of your bandwidth, contention arises and the operating system is called in to arbitrate. The problem is that packets are packets to the OS so high priority packets from one program may be lost in favor of low priority packets from the other program. You could solve this by setting each p2p client to use a max of 50% of your bandwidth, but then you wouldn't get optimal usage of your connection. In short, your apps would be competing with eachother.
However, there is a way you can run both at the same time while avoiding any serious adverse effects. In gnucleus, go into properties and uncheck "can become a supernode/ultrapeer". In winmx, select the radio button for "make a secondary connection to the network". This will guarantee that the only high priority traffic your nodes have to deal with will be the data generated by you. Your file transfers will compete for bandwidth, but the networks won't be adversely affected. Even if you choose to continue running winmx alone, you should create a secondary connection to the network. Primary connections speed up searches a bit, but usually use bandwidth in quantities only available to broadband users.
The easy answer is that the newer clients have an option to send out queries for random data every so often -- anything that answers affirmative to those queries gets ignored. Simple and effective.
That might cut down on the advertising spam that's commonly seen on gnutella. However, the counter attack to this, when karma-whoring to offset high volumes of repeat search traffic, lies is the solution to the advertising problem. Namely, you can safely ignore any host that responds to a randomly generated query as a direct result of the fact that legitimate queries (and file names) are not random. A malicious host could sit quietly on the network for a little while after connecting and parse incoming search queries to create a dictionary of valid search terms. This dictionary would then be used to validate incoming queries before responding to them by generating a "validity index" based on their similarity. Sure, some legitimate queries would be ignored, but enough would come through with a payload to the effect of "metallica mp3" or "britney spears porn" to make it worth the node's while.
Of course, this "solution" is only necessary when the network is not versatile enough to allow query hits to travel along a different host path than the original query. If the network does allow this, then it's a simple matter of generating query hits that nobody asked for and that will eventually be dropped.
I don't like blue screens I don't know what to say about this one. I use win2k and I hardly ever get a blue screen. The philosophy for all NT kernel based OSs is: if a program can crash the OS, it's a bug. I'm not saying all NT kernel based OSs are stable, just that they're less unstable than (for example) WinME.
I don't like spyware Do research beforehand so you don't download spyware or adware-infested clients. For every corporate sponsored client that I know of (KaZaa, Morpheus, etc...) there exists a spyware-free version (KaZaa Lite, Gnucleus, etc...) that is available for free.
I don't know how to use CVS You don't need to know how to use CVS. If the author isn't providing binaries, the program is either too early in the development cycle to use or the author (and it pains me to say this) doesn't care enough about the project to make it a success. The fact is, "most people" don't know how to use CVS/compile non-autoconf software under windows OR linux. One of the keys to success for a p2p file transfer program is that "most people" are able to use it.
I don't have the second hard disk to hold a Linux installation. Two things: 1. You don't need a second hard disk to install linux. Some distros even let you install by borrowing space on your main fat32 windows drive. If you're using WinME, you can do it. 2. You don't, by any means, have to use linux. I don't know of a p2p network that doesn't have a win32 client of some kind.
Besides, some of the apps let a server administrator kick off any user who connects to the Internet at ISDN data rate or slower. In a true p2p system, and user can kick any other user from their own server. However, one of the ways you can avoid being booted (not that it's all that common anyway) is by not tying up a whole bunch of download slots with one 56k connection. In other words, if someone has a bunch of files you want, download them one at a time.
I share as much as I am able, but if I share files, I will cut off the person downloading from me when I go offline. All major p2p networks in existance provide for resuming downloads. You can pop on and offline as much as you want, and those people downloading from you will simply download when you're available. When you're offline, those same people will resume the file from other hosts. Unreliable net connections are not a problem.
Is it true that Gnucleus will not work well over dial-up? This used to be a BIG issue. What happened was, all nodes in a gnutella network performed two functions: searching and file transfer. The file transfer part meant nodes directly connected to one-another to transfer files at the request of a user. The searching part meant nodes also maintained (an average of) 4-7 connections at all times to other nodes through which search requests were broadcast and query hits were routed. As the size of the gnutella network grew, the volume of searches grew beyond what a 56k connection could handle. All bandwidth was being consumed by searches leaving nothing for file transfers, or anything else. Even worse, slow connections caused searches to be dropped. Clients started implementing xolox-esqe methods to "improve" searching and it all went down hill from there. The solution? Supernodes (aka ultrapeers). Now, in the post-supernode network, nodes still transfer files in the usual way (direct connect). However, only a small portion of the nodes, the ones with the most bandwidth, form a sort of "search network" in which each node maintains the ususal 4-7 connections and forwards searches. Nodes with less bandwidth (modem users, 64k and BRI ISDN users, etc...) operate in "leaf mode" or "child node mode" (depending on whether you speak fastrackese or gnutellian). They make a single connection to a supernode through which they send queries and receive query hits. Upon connecting, the leaf node tells its supernode what files it has, and the supernode responds to queries on behalf of the leaf node.
It's actually a bit more complicated than that, but that explains the basic idea. The answer to your question is: "No. Using gnucleus on a modem is not a problem." Other clients shouldn't cause problems as long as they properly support either "supernodes" or "ultrapeers". Most do.
Here's what you can do to work towards a better p2p future for everyone:
See a new client? Check it out. Improved networks can't take off without a user base. If it sucks, uninstall it - but send a bug report/feature request. C'mon. If you can spend 2 minutes writing a slashdot post you can fire off a quick email.
Share files. People think that if they share files it will unavoidably clog their upstream link and slow their downloads (and web browsing) to a crawl. Not true! Simply limit how much upstream bandwidth the client will use to (just a rough estimate) 60-70% of your upstream bandwidth. You'll be amazed at the difference. If the client lacks a bandwidth throttle, a serious problem for tcp-based networks, send a bug report.
Get involved politically. Write your congresscritters and tell them you don't want to see competition in the home broadband arena killed by deregulation. Write your cable/phone company and tell them you oppose monthly transfer caps. Call your friends and make sure they're aware of the issues. Vote.
This is the bare minimum you should be doing if you care about/use p2p networks. If you're not willing to do this, stop downloading. Seriously. If you want to do more, there's a lot to be done.
If you're a programmer, join an open source project and develop. Your time and skills are needed.
If you're a logical thinker and like analyzing networks and complex node relationships, join a p2p protocol discussion forum. I suggest lurking for a while, though - there's a lot to learn if you're new to p2p protocol design.
Whether you develop, research, or both, recognise that other people are going to have ideas that seem stupid to you and your ideas may seem stupid to other people. Don't waste time arguing. Think before you open your mouth (or put your hands on the keyboard) and recognise that the people making the actual coding decisions have an in-depth understanding of what's going on. Really bad ideas are shot down before they make it into the code -- flame wars are never necessary.
Need a link? Check here. It's a great client if you're windows-bound, it's open source, and it has a lively discussion forum.
I've done everything short of examining the code for GNUNet and a possible flaw occurs to me. From your post:
Bad or expensive behavior like out-of-spec activity or excessive querying lowers the 'credit' of the node. Good behavior like answering queries increases a node's credit.
How to write an "abusive" client that is still serviced by the rest of the network:
1. Create queries at the request of the user and send them. Re-query frequently to increase search results (a la Xolox) ["karma" decrease] 2. Respond to all queries with an affirmative "I have that file!" message ["karma" increase].
Abusively written clients will not eventually be ignored out of the network. Users of abusive clients will get better search results and clog other clients will false query hits in the process. In the long term, users will have to migrate to abusive clients to be able to get search results thus crushing the network.
I may be wrong - I only have coding and protocol development experience with gnutella servents. Hopefully the good GNUNet developers have come up with an elegant solution to this problem, but it doesn't seem like it on the surface.
What probably happened is that you snagged an IP previously used by a gnutella user when you dailed in. You're getting 6346 connection requests because the IP you're currently using is in the host cache of one or more gnutella nodes out there that are trying to connect. If it really bothers you, reconnect and get a different IP. Otherwise, wait for a bit and they'll realize you're not running a servent and stop trying to connect.
You're right, though. Most gnutella servent software out there doesn't behave very well.
Microsoft definitely doesn't want a "chip-in-all-hardware-to-prevent-copying" scheme. They want a "microsoft-chip-in-the-hardware-to-prevent-copying " scheme (see: palladium). Yes, I'm aware that the TCPA and Palladium are two different things, but they have nearly identical goals and the technology goes hand in hard.
So what is the significance of this latest decision? Well, a couple of things. First, as far as I know, every major company to use the DMCA to stifle research has had to backpeddle fairly quickly. The public may not know what "DRM" or "CBTDDTTDBDBTCDBTCDDPTCBPA" mean but a significant portion of the tech community understands "stifling research," which is why we'll end up with Palladium but we'll probably only have to put up a modest fight every so often to be able to freely publish research. We could have a world free of both if slashdotters weren't so utterly pathetic politically, but I seriously doubt there'll be any change before it's too late. Second, the more "unjust" a company's actions seem, the more publicity they get in the geek community. Since Microsoft was "nice" this time, comparatively few people will hear about it and as a consequence comparatively few people will understand the critical flaw in the X-Box, CSS, etc...
From MS's point of view, the fewer people that hear about it, the better. This is how they deal with things that are Really Evil (TM). Anyone remember Windows Whistler, recently known as Windows XP, now known as Windows DRM (a la forced updates to the OS and media player)? How about HailStorm? You didn't see a lot of publicity on that until it was being launched. Sure, there was.Net this and.Net that, but, for a very long time, people had a lot of different and mixed up ideas about what.Net was. Some people still don't understand what it is. What about Palladium? I remember reading an article linked to from a slashdot story a while back that was a reporter's view of Palladium. The article, written after a viewing a Microsoft confidential presentation on palladium, said something to the effect of,"I can't reveal to you very much about the details about Palladium - Microsoft has been very strict about this. However, I can tell you that I was shocked." It then went on to give a rough outline of DRM-related possible hardware and software components. See what I mean? It's their M.O.
I totally agree with you. Now we know a little more about primes - that's all. My post was in reply to all of the previous posts saying something to the effect of "Doesn't this have a huge impact on modern cryptography?" and "Well, looks like RSA is broken..."
They've figured out how to determine if a given number is prime in P time. That, by itself, doesn't break modern public key cryptographic systems. In order to do that, you would need to be able to factor a given number into its two prime factors in P time (a different problem).
d be able to see the entire scene in the movie from all angles at the same time. Not really of course, since you can't see in 3d, only two 2d images, but you get the idea.
Sorry about the split post - I guess I'm not very coordinated at 4am:P.
It's talking about a shape in 4 spatial dimesions, not 3 spacial dimensions and one time dimension. Also, movies aren't 3d - not even those red-cyan ones. If movies were truly 3d, you'
From the article: "HP hereby requests that you cooperate with us to remove the buffer overflow exploit from Securityfocus.com and to take all steps necessary to prevent the further dissemination by SnoSoft and its agents of this and similar exploits of Tru64 Unix," Ferson wrote, according to a copy of the letter seen by CNET News.com. "If SnoSoft and its members fail to cooperate with HP, then this will be considered further evidence of SnoSoft's bad faith."
How about this: "SnoSoft hereby requests that you cooperate with us to remove the buffer overflow exploit from Tru64 Unix and to take all steps necessary to prevent the further dissemination by HP and its agents of this and similar exploits of free speech,"
"If HP and its members fail to cooperate with SnoSoft, then this will be considered further evidence of HP's bad faith."
Depends. If a library is _incredibly crucial_ (not to mention huge) like glibc, then it would be included in the base task. When an updated version of glibc comes out, the old package would be migrated to the "legacy support" task and the new one would become a member of base. Authors of applications wouldn't include package X if it's a part of base. Glibc is a good example.
libopenssl is a different matter. Although it's becoming less and less common, there are still lots of machines that are not connected to a network, and thus don't neet secure sockets layer support for their applications. Because of this, libopenssl would not be included in the "bare bones" task. Task authors would have a choice here. For maximum compatibility, they would include libssl in their task as an "If you don't know what to download, download this." complete package. If the application needs a fairly common lib like libopenssl and the task author can safely assume that it will be on the system ("The user is downloading the task over and https connection or is already using software which already provides libopenssl") or is willing to take the risk, the author can choose not to include that package within his or her task. If a user downloads an application task that assumes the presence of a library that in fact is not present in the system, the system would pop up an error message to the effect of "This task does not contain all of the files necessary to install itself. Please obtain and install the complete version of the task." The wording of that message is very important. It says "please obtain and install the complete version of the task," not "please obtain and install a complete version of the task if one is provided, otherwise, resolve the dependency issue," - it takes for granted the existance of the complete task in a declaratory statement. It needs to be clear that if an author chooses to package his or her application, it is that author's responsibility to provide a complete task. Not all users can be expected to go out and resolve dependency issues by themselves and offering a complete task is the easiest way to deal with this situation from the point of view of the task author as well as the user. This is especially true if this model were widely adopted (a necessary precursor to success anyway) and producers of libraries (or other things commonly depended upon) started offering "task components." This way, the author would simply bind their application task componenet with the proper task components that it depended upon with a single command line (or click) and providing complete tasks would be virtually zero extra effort.
Yes, I'm aware that debian will automagically solve dependency issues, but only if the needed dependency is listed in sources.list. This may not be the case with an independently produced (or uncommon) dependency. This, it fosters dependence on the (excelently maintained but not under the user's control) debian package servers on the internet which does not offer the same level of mental security to the user as having everything on a cd and the application's web site. The situation is analagous to not being able to install many apps unless the windows update servers are up and running. This comparison doesn't perfectly reflect the situation, as windows update is offline a _whole lot more often_ than all the debian servers in the world are offline at the same time, but you get the idea.
Anyway, that's how apps would make sure they get the right libraries. The system would also be able to handle uninstallation while keeping dependencies in mind and making sure no extra bloat gets left behind on the system.
Example:
You don't have libA on your system, but you download taskB which, like any other properly produced "complete" task, contains the non-base libraries upon which it depends which in this case is libA. Everything is installed, and libA is now present on your system as a part of taskB. Then, you decide to download taskC which also depends on libA. Being the intelligent user that you are, you decide to download the "slim version" of the task that does not include libA. You tell the system to install taskC, the package management system detects that the required libA is already installed, a part of another task, and lets you install taskC. Now, let's say that you get bored with taskB and uninstall it. While processing your uninstall command, the PMS detects that a part of taskB, libA, is required by taskC. In order to process your command and follow the "no orphan packages" rule, libA is migrated from taskB into taskC, bringing the contents of taskC closer to the "complete version" of taskC (remember you downloaded the "slim version"). In this way, all applications continue to work properly and there are no conflicts. In the case that you had taskD, E and F installed that all used libA, ownership of libA would simply be moved into any single one of those tasks. In the case that "Joe Idunno Anythingaboutcomputers" was going through the same scenario and had downloaded the complete version of taskC (the smartest choice for him), the libA package from taskC simply would not be installed, and it would be noted in the DB that taskC does not have ownership over libA. Joe could then dump the taskC installer safe with (or in Joe's case, probably without) the knowledge that in the case he uninstalled taskB, libA from taskB would be moved to taskC, keeping taskC happy.
I think I understand what you're saying now. As I see it, my model is different from pseudo-packages in two different ways:
1. Pseudo packages _are_ regular packages - that is they are not marked differently. They are simply regular packages that depend on other packages but contain no files.
2. Packages can exist without belonging to pseudo-packages (or tasks).
I would alter these conditions.
Metapackages or tasks or whatever would be explicitly marked as being what they are and having greater significance than regular packages (options).
Packages would have to belong to a task - they could not be installed by themselves. This does not limit an author's ability to write new independent libraries - it enforces clear organization for clean integration. At first, when there are no applications that depend on it, it would be a part of the "test" task. If the library author wants to write an application that uses that library (or someone else wants to do the same), then that library would be included inside that application's task.
In addition to the ability for a user to view their entire system as a collection of several (not hundreds) of tasks that have clear definitions and purposes and manage them in a way that they can understand, it eliminates the existance of "ghost" packages left over from software that's been previously uninstalled but has not perfectly removed all of its guaranteed unique dependencies. Sure, you can do this with the system now by checking for packages that aren't depended on by anything and sorting through the list to see which ones you use to do something and which ones are merely unnecessary support libraries, but within this hypothetical system, the system will not allow this problem to occur in the first place.
It also makes possible distributing applications as complete tasks that contain all the packages necessary to use that application in one file. Download, install, it works. No more downloading a.rpm, finding out it requires the support libraries b.rpm, and c.rpm, downloading them and finding out c.rpm requires d.rpm and e.rpm, and then finding out that your system has a conflict between d.rpm and a currently installed packages. Yes, I know that debian already has support for automatic dependency checking and problem resolution, but only if the package management system can get a good look at all the dependencies and conflicts at once which means having all the packages somewhere in sources.list at the same time.
I'm not sure I understand what you're saying...
on
RPM Dependency Graph
·
· Score: 1
[pseudo-packages] accomplish EXACTLY what you want.
As I understand it, pseudo-packages tell the package management system that something is installed without actually installing anything. This allows you to install whatever you want to handle that function without causing the package management system to freak out. I don't see how this, which seems to me like circumventing the package management system in order to install unpackaged software, accomplishes the unification of groups of packages into functional units that do things users can understand while eliminating giant webs of dependencies by discouraging single-library/executable packages.
Slashdot Mirror
If he goes back in time and patents it then you won't reveal it when he was around so he won't have been able to go back and patent it.
...now we have to figure out how to fix it. None of the OEMs like MS's restrictive licensing, but they know that even if they all got together and refused to accept the new terms Microsoft would just stop giving them all OEM discounts. Like one of the posters above said: Microsoft will suffer minutely decreased sales from the increased price, but the OEMs' margins will go from razor thin to nearly invisible. None of them want to risk it because they don't have another OS to fall back on if Microsoft doesn't accept their terms.
What we need to do is make sure there is another OS that's as good on the desktop as Windows. That way OEMs have choice and Microsoft has competition.
Because good karma makes the system work.
On the internet, it's fairly easy to generate a new identity. Just redail your isp on a modem, release and renew your IP on cable, or re-authenticate with PPPoE on DSL and you've got a new IP. If you're using a system that incorporates public key cryptography, just generate a new key pair and you're indistinguishable from a fresh node on the network. When people can "reset" like that and the system only allows for the accumulation of bad karma, there's no incentive to keep the same identity for long.
Good karma, combined with a starting "entry" karma that's not good enough to get a node serviced by others, encourages people to keep the same identity for a longer period of time. If a user has to contribute a little before they can search and download, the user is incapable of connecting and spamming the network right away. Once the user has gained karma to the point where they can search and download, the user is more likely to continue that good behavior. Why? Because behaving badly (spamming, clogging the network, etc...) would take away that hard-won good karma and make it necessary to start all over again.
What we need is a system that has both bad karma and good karma, but that doesn't associate them. Neither can cancel the other one out, and only hosts with sufficient good karma and sufficiently low bad karma would be serviced. Both should be initialized to 0 upon connecting. This is the simplest solution that I can think of off the top of my head. However, I remember reading a really well-written article involving an intricate trust system that sounded like it would be even more effective. Too bad I don't have it bookmarked....
Ok. So you're talking about ignoring servers that respond to queries that do not have to do with your specific interests. As I see it, there are a couple problems with that:
1. If you only use your client to search for anime, what happens when your client sees lots of queries for "mp3" or "porn" and includes those terms in a validation search? Lots of hosts will respond to those queries, bloating your "ignored hosts" table and hammering your internet connection with query hits.
2. What about people that share your interests but also have others of their own? A validation search with the terms "metallica" and "mp3" will provoke a query hit from a host that has a file named "metallica-song.mp3" as well as "anime-episode.mpg". Since that host responds to your validation search, it will be ignored.
Somebody wrote comments in reply to this article, pleading for more testers of GNUnet and giFT, neither of which is "ready" enough to release Windows binaries, or even a source tarball that will compile properly under MinGW.
I'm not saying nobody should test out those systems. In this case, only users who are willing to download the sources, do a little hacking/run linux, and compile should (and could) test them out. My original post wasn't suggesting that people need to go out of their way to learn new skills or spend lots of time getting frustrated with their compiler - only that users should test out all that they are able to and evaluate the merits of new systems.
I was specifically referring to the policies of many Direct Connect hubs.
Ok.
I already [download one at a time], using software such as WinMX that supports a local queue.
Good for you! A lot of people don't have the courtesy to do that, and it really helps out the network. I can't offer you much help about getting kicked there. In my experience winmx users tend to micromanage - it's not as bad elsewhere.
And if I'm not available often (I only get 150 hours per month on my dial-up plan), then I feel like I'm cheating people who try to download rare stuff from me when I cut them off.
Two things:
1. Investigate other dial-up ISPs (if there are any in your area). Many are offering unlimited hours per month.
2. Even if you drop someone who's trying to download a rare file, you provided that person with an opportunity they otherwise wouldn't have had to get a few more bytes. In addition, if you served the initial bytes in the file to that person, you gave that person a valid hash to search for later thereby vastly improving their chances of finding other sources for the same data.
And what about recordings of my own performance? I'm a musician, but I suck at vocals so I just record instrumental music. How do I make those available on a P2P network?
Just drop them in your shared folder. If you're using a p2p system that supports metadata, make sure to fully describe you music (i.e. set the genre, release date, author, title, etc...). You may not be able to put as much bandwidth toward "getting them out there" as you would want, but that's the plight of anyone who has data and wants it hosted. Not being a musician, I couldn't point you toward any known good and reliable web-based mp3.com style "exposure" sites. Maybe someone else on slashdot will have a suggestion?
Is using gnucleus and WinMX on the same modem a problem?
In general, running more than one p2p client on a single connection is not a good idea. Inside a p2p client's program logic, essential, high-priority, latency-sensitive data (searches and routing updates) can be differentiated from (and prioritized over) less critical or latency insensitive data (file transfers). With intelligent bandwidth throttling code this works out pretty well. However, when more than one p2p client is running at the same time and both are set to use a max of 70% of your bandwidth, contention arises and the operating system is called in to arbitrate. The problem is that packets are packets to the OS so high priority packets from one program may be lost in favor of low priority packets from the other program. You could solve this by setting each p2p client to use a max of 50% of your bandwidth, but then you wouldn't get optimal usage of your connection. In short, your apps would be competing with eachother.
However, there is a way you can run both at the same time while avoiding any serious adverse effects. In gnucleus, go into properties and uncheck "can become a supernode/ultrapeer". In winmx, select the radio button for "make a secondary connection to the network". This will guarantee that the only high priority traffic your nodes have to deal with will be the data generated by you. Your file transfers will compete for bandwidth, but the networks won't be adversely affected. Even if you choose to continue running winmx alone, you should create a secondary connection to the network. Primary connections speed up searches a bit, but usually use bandwidth in quantities only available to broadband users.
The easy answer is that the newer clients have an option to send out queries for random data every so often -- anything that answers affirmative to those queries gets ignored. Simple and effective.
That might cut down on the advertising spam that's commonly seen on gnutella. However, the counter attack to this, when karma-whoring to offset high volumes of repeat search traffic, lies is the solution to the advertising problem. Namely, you can safely ignore any host that responds to a randomly generated query as a direct result of the fact that legitimate queries (and file names) are not random. A malicious host could sit quietly on the network for a little while after connecting and parse incoming search queries to create a dictionary of valid search terms. This dictionary would then be used to validate incoming queries before responding to them by generating a "validity index" based on their similarity. Sure, some legitimate queries would be ignored, but enough would come through with a payload to the effect of "metallica mp3" or "britney spears porn" to make it worth the node's while.
Of course, this "solution" is only necessary when the network is not versatile enough to allow query hits to travel along a different host path than the original query. If the network does allow this, then it's a simple matter of generating query hits that nobody asked for and that will eventually be dropped.
I don't like blue screens
I don't know what to say about this one. I use win2k and I hardly ever get a blue screen. The philosophy for all NT kernel based OSs is: if a program can crash the OS, it's a bug. I'm not saying all NT kernel based OSs are stable, just that they're less unstable than (for example) WinME.
I don't like spyware
Do research beforehand so you don't download spyware or adware-infested clients. For every corporate sponsored client that I know of (KaZaa, Morpheus, etc...) there exists a spyware-free version (KaZaa Lite, Gnucleus, etc...)
that is available for free.
I don't know how to use CVS
You don't need to know how to use CVS. If the author isn't providing binaries, the program is either too early in the development cycle to use or the author (and it pains me to say this) doesn't care enough about the project to make it a success. The fact is, "most people" don't know how to use CVS/compile non-autoconf software under windows OR linux. One of the keys to success for a p2p file transfer program is that "most people" are able to use it.
I don't have the second hard disk to hold a Linux installation.
Two things:
1. You don't need a second hard disk to install linux. Some distros even let you install by borrowing space on your main fat32 windows drive. If you're using WinME, you can do it.
2. You don't, by any means, have to use linux. I don't know of a p2p network that doesn't have a win32 client of some kind.
Besides, some of the apps let a server administrator kick off any user who connects to the Internet at ISDN data rate or slower.
In a true p2p system, and user can kick any other user from their own server. However, one of the ways you can avoid being booted (not that it's all that common anyway) is by not tying up a whole bunch of download slots with one 56k connection. In other words, if someone has a bunch of files you want, download them one at a time.
I share as much as I am able, but if I share files, I will cut off the person downloading from me when I go offline.
All major p2p networks in existance provide for resuming downloads. You can pop on and offline as much as you want, and those people downloading from you will simply download when you're available. When you're offline, those same people will resume the file from other hosts. Unreliable net connections are not a problem.
Is it true that Gnucleus will not work well over dial-up?
This used to be a BIG issue. What happened was, all nodes in a gnutella network performed two functions: searching and file transfer. The file transfer part meant nodes directly connected to one-another to transfer files at the request of a user. The searching part meant nodes also maintained (an average of) 4-7 connections at all times to other nodes through which search requests were broadcast and query hits were routed. As the size of the gnutella network grew, the volume of searches grew beyond what a 56k connection could handle. All bandwidth was being consumed by searches leaving nothing for file transfers, or anything else. Even worse, slow connections caused searches to be dropped. Clients started implementing xolox-esqe methods to "improve" searching and it all went down hill from there. The solution? Supernodes (aka ultrapeers). Now, in the post-supernode network, nodes still transfer files in the usual way (direct connect). However, only a small portion of the nodes, the ones with the most bandwidth, form a sort of "search network" in which each node maintains the ususal 4-7 connections and forwards searches. Nodes with less bandwidth (modem users, 64k and BRI ISDN users, etc...) operate in "leaf mode" or "child node mode" (depending on whether you speak fastrackese or gnutellian). They make a single connection to a supernode through which they send queries and receive query hits. Upon connecting, the leaf node tells its supernode what files it has, and the supernode responds to queries on behalf of the leaf node.
It's actually a bit more complicated than that, but that explains the basic idea. The answer to your question is: "No. Using gnucleus on a modem is not a problem." Other clients shouldn't cause problems as long as they properly support either "supernodes" or "ultrapeers". Most do.
Ah. Most likely it is a badly behaved servent then. :)
This is the bare minimum you should be doing if you care about/use p2p networks. If you're not willing to do this, stop downloading. Seriously. If you want to do more, there's a lot to be done.
Need a link? Check here. It's a great client if you're windows-bound, it's open source, and it has a lively discussion forum.
I've done everything short of examining the code for GNUNet and a possible flaw occurs to me. From your post:
Bad or expensive behavior like out-of-spec activity or excessive querying lowers the 'credit' of the node. Good behavior like answering queries increases a node's credit.
How to write an "abusive" client that is still serviced by the rest of the network:
1. Create queries at the request of the user and send them. Re-query frequently to increase search results (a la Xolox) ["karma" decrease]
2. Respond to all queries with an affirmative "I have that file!" message ["karma" increase].
Abusively written clients will not eventually be ignored out of the network. Users of abusive clients will get better search results and clog other clients will false query hits in the process. In the long term, users will have to migrate to abusive clients to be able to get search results thus crushing the network.
I may be wrong - I only have coding and protocol development experience with gnutella servents. Hopefully the good GNUNet developers have come up with an elegant solution to this problem, but it doesn't seem like it on the surface.
What probably happened is that you snagged an IP previously used by a gnutella user when you dailed in. You're getting 6346 connection requests because the IP you're currently using is in the host cache of one or more gnutella nodes out there that are trying to connect. If it really bothers you, reconnect and get a different IP. Otherwise, wait for a bit and they'll realize you're not running a servent and stop trying to connect.
You're right, though. Most gnutella servent software out there doesn't behave very well.
Microsoft definitely doesn't want a "chip-in-all-hardware-to-prevent-copying" scheme. They want a "microsoft-chip-in-the-hardware-to-prevent-copying " scheme (see: palladium). Yes, I'm aware that the TCPA and Palladium are two different things, but they have nearly identical goals and the technology goes hand in hard.
.Net this and .Net that, but, for a very long time, people had a lot of different and mixed up ideas about what .Net was. Some people still don't understand what it is. What about Palladium? I remember reading an article linked to from a slashdot story a while back that was a reporter's view of Palladium. The article, written after a viewing a Microsoft confidential presentation on palladium, said something to the effect of,"I can't reveal to you very much about the details about Palladium - Microsoft has been very strict about this. However, I can tell you that I was shocked." It then went on to give a rough outline of DRM-related possible hardware and software components. See what I mean? It's their M.O.
So what is the significance of this latest decision? Well, a couple of things. First, as far as I know, every major company to use the DMCA to stifle research has had to backpeddle fairly quickly. The public may not know what "DRM" or "CBTDDTTDBDBTCDBTCDDPTCBPA" mean but a significant portion of the tech community understands "stifling research," which is why we'll end up with Palladium but we'll probably only have to put up a modest fight every so often to be able to freely publish research. We could have a world free of both if slashdotters weren't so utterly pathetic politically, but I seriously doubt there'll be any change before it's too late. Second, the more "unjust" a company's actions seem, the more publicity they get in the geek community. Since Microsoft was "nice" this time, comparatively few people will hear about it and as a consequence comparatively few people will understand the critical flaw in the X-Box, CSS, etc...
From MS's point of view, the fewer people that hear about it, the better. This is how they deal with things that are Really Evil (TM). Anyone remember Windows Whistler, recently known as Windows XP, now known as Windows DRM (a la forced updates to the OS and media player)? How about HailStorm? You didn't see a lot of publicity on that until it was being launched. Sure, there was
...by that time, we'll finally be able to run 99% of all 32-bit windows apps in wine!
I wonder how long it'll be before the *AA asks for a tax on atoms "to offset the costs of piracy".
I totally agree with you. Now we know a little more about primes - that's all. My post was in reply to all of the previous posts saying something to the effect of "Doesn't this have a huge impact on modern cryptography?" and "Well, looks like RSA is broken..."
look here.
They've figured out how to determine if a given number is prime in P time. That, by itself, doesn't break modern public key cryptographic systems. In order to do that, you would need to be able to factor a given number into its two prime factors in P time (a different problem).
d be able to see the entire scene in the movie from all angles at the same time. Not really of course, since you can't see in 3d, only two 2d images, but you get the idea.
:P.
Sorry about the split post - I guess I'm not very coordinated at 4am
It's talking about a shape in 4 spatial dimesions, not 3 spacial dimensions and one time dimension. Also, movies aren't 3d - not even those red-cyan ones. If movies were truly 3d, you'
I hope you're using the spyware-free KaZaa Lite rather than the infested KaZaa.
From the article:
"HP hereby requests that you cooperate with us to remove the buffer overflow exploit from Securityfocus.com and to take all steps necessary to prevent the further dissemination by SnoSoft and its agents of this and similar exploits of Tru64 Unix," Ferson wrote, according to a copy of the letter seen by CNET News.com. "If SnoSoft and its members fail to cooperate with HP, then this will be considered further evidence of SnoSoft's bad faith."
How about this:
"SnoSoft hereby requests that you cooperate with us to remove the buffer overflow exploit from Tru64 Unix and to take all steps necessary to prevent the further dissemination by HP and its agents of this and similar exploits of free speech,"
"If HP and its members fail to cooperate with SnoSoft, then this will be considered further evidence of HP's bad faith."
This is an interesting discussing, but slashdot web posting has pretty high latency. Do you use MSN or ICQ chat services?
Depends. If a library is _incredibly crucial_ (not to mention huge) like glibc, then it would be included in the base task. When an updated version of glibc comes out, the old package would be migrated to the "legacy support" task and the new one would become a member of base. Authors of applications wouldn't include package X if it's a part of base. Glibc is a good example.
libopenssl is a different matter. Although it's becoming less and less common, there are still lots of machines that are not connected to a network, and thus don't neet secure sockets layer support for their applications. Because of this, libopenssl would not be included in the "bare bones" task. Task authors would have a choice here. For maximum compatibility, they would include libssl in their task as an "If you don't know what to download, download this." complete package. If the application needs a fairly common lib like libopenssl and the task author can safely assume that it will be on the system ("The user is downloading the task over and https connection or is already using software which already provides libopenssl") or is willing to take the risk, the author can choose not to include that package within his or her task. If a user downloads an application task that assumes the presence of a library that in fact is not present in the system, the system would pop up an error message to the effect of "This task does not contain all of the files necessary to install itself. Please obtain and install the complete version of the task." The wording of that message is very important. It says "please obtain and install the complete version of the task," not "please obtain and install a complete version of the task if one is provided, otherwise, resolve the dependency issue," - it takes for granted the existance of the complete task in a declaratory statement. It needs to be clear that if an author chooses to package his or her application, it is that author's responsibility to provide a complete task. Not all users can be expected to go out and resolve dependency issues by themselves and offering a complete task is the easiest way to deal with this situation from the point of view of the task author as well as the user. This is especially true if this model were widely adopted (a necessary precursor to success anyway) and producers of libraries (or other things commonly depended upon) started offering "task components." This way, the author would simply bind their application task componenet with the proper task components that it depended upon with a single command line (or click) and providing complete tasks would be virtually zero extra effort.
Yes, I'm aware that debian will automagically solve dependency issues, but only if the needed dependency is listed in sources.list. This may not be the case with an independently produced (or uncommon) dependency. This, it fosters dependence on the (excelently maintained but not under the user's control) debian package servers on the internet which does not offer the same level of mental security to the user as having everything on a cd and the application's web site. The situation is analagous to not being able to install many apps unless the windows update servers are up and running. This comparison doesn't perfectly reflect the situation, as windows update is offline a _whole lot more often_ than all the debian servers in the world are offline at the same time, but you get the idea.
Anyway, that's how apps would make sure they get the right libraries. The system would also be able to handle uninstallation while keeping dependencies in mind and making sure no extra bloat gets left behind on the system.
Example:
You don't have libA on your system, but you download taskB which, like any other properly produced "complete" task, contains the non-base libraries upon which it depends which in this case is libA. Everything is installed, and libA is now present on your system as a part of taskB. Then, you decide to download taskC which also depends on libA. Being the intelligent user that you are, you decide to download the "slim version" of the task that does not include libA. You tell the system to install taskC, the package management system detects that the required libA is already installed, a part of another task, and lets you install taskC. Now, let's say that you get bored with taskB and uninstall it. While processing your uninstall command, the PMS detects that a part of taskB, libA, is required by taskC. In order to process your command and follow the "no orphan packages" rule, libA is migrated from taskB into taskC, bringing the contents of taskC closer to the "complete version" of taskC (remember you downloaded the "slim version"). In this way, all applications continue to work properly and there are no conflicts. In the case that you had taskD, E and F installed that all used libA, ownership of libA would simply be moved into any single one of those tasks. In the case that "Joe Idunno Anythingaboutcomputers" was going through the same scenario and had downloaded the complete version of taskC (the smartest choice for him), the libA package from taskC simply would not be installed, and it would be noted in the DB that taskC does not have ownership over libA. Joe could then dump the taskC installer safe with (or in Joe's case, probably without) the knowledge that in the case he uninstalled taskB, libA from taskB would be moved to taskC, keeping taskC happy.
How's that sound?
I think I understand what you're saying now. As I see it, my model is different from pseudo-packages in two different ways:
1. Pseudo packages _are_ regular packages - that is they are not marked differently. They are simply regular packages that depend on other packages but contain no files.
2. Packages can exist without belonging to pseudo-packages (or tasks).
I would alter these conditions.
Metapackages or tasks or whatever would be explicitly marked as being what they are and having greater significance than regular packages (options).
Packages would have to belong to a task - they could not be installed by themselves. This does not limit an author's ability to write new independent libraries - it enforces clear organization for clean integration. At first, when there are no applications that depend on it, it would be a part of the "test" task. If the library author wants to write an application that uses that library (or someone else wants to do the same), then that library would be included inside that application's task.
In addition to the ability for a user to view their entire system as a collection of several (not hundreds) of tasks that have clear definitions and purposes and manage them in a way that they can understand, it eliminates the existance of "ghost" packages left over from software that's been previously uninstalled but has not perfectly removed all of its guaranteed unique dependencies. Sure, you can do this with the system now by checking for packages that aren't depended on by anything and sorting through the list to see which ones you use to do something and which ones are merely unnecessary support libraries, but within this hypothetical system, the system will not allow this problem to occur in the first place.
It also makes possible distributing applications as complete tasks that contain all the packages necessary to use that application in one file. Download, install, it works. No more downloading a.rpm, finding out it requires the support libraries b.rpm, and c.rpm, downloading them and finding out c.rpm requires d.rpm and e.rpm, and then finding out that your system has a conflict between d.rpm and a currently installed packages. Yes, I know that debian already has support for automatic dependency checking and problem resolution, but only if the package management system can get a good look at all the dependencies and conflicts at once which means having all the packages somewhere in sources.list at the same time.
[pseudo-packages] accomplish EXACTLY what you want.
As I understand it, pseudo-packages tell the package management system that something is installed without actually installing anything. This allows you to install whatever you want to handle that function without causing the package management system to freak out. I don't see how this, which seems to me like circumventing the package management system in order to install unpackaged software, accomplishes the unification of groups of packages into functional units that do things users can understand while eliminating giant webs of dependencies by discouraging single-library/executable packages.