Talk:EMule
From Wikipedia, the free encyclopedia
 |
This article is part of WikiProject Free Software, an effort to create, expand, organize, and improve free software-related articles. | |
| ??? | This article has not yet received a rating on the assessment scale. | |
| ??? | This article has not yet received an importance rating on the assessment scale. | |
- The correct title of this article is Talk:eMule. The initial letter is shown capitalized due to technical restrictions.
|
Contents |
[edit] REWRITE NEEDED
A large part of this article and hitory was removed because it was a copy of some pages on emule-project site. SOmeone needs to write something about the basic concepts how emule works. temp page here: (since temp page on emule seems to be not policy or something like that.) User:Leuk_he/eMule Juli 2006, still relevant!
- now included in article... please fee free to change lines since english is not my first language. :Leuk he 10:40, 16 January 2007 (UTC)
[edit] hotfix
The released a 0.47c hotfix for a KAD bug. [1] --165.21.155.12 04:19, 15 September 2006 (UTC)
[edit] Faults and Problems
I removed the following text:
- A problem is the size of unfinished files. The Help file incorporated into the program explains that it common to have a full-size temporary file, ie. before a single file has been downloaded, the harddrive may already be full; unlike the late edonkey, whose temp-files were only in about the size of the downloaded parts. As a result, few files (resulting in less traffic) can be downloaded when some files are as large as films. This problem has not yet been fixed.
It does not agree with the Extended Features documentation on the "Create new part files as sparse (NTFS only)" option. Frozen North 01:11, 20 September 2006 (UTC)
- As you say, thats for NTFS only (i just guess temps wouldnt like to be converted from fat to ntfs) FlammingoParliament 01:22, 21 September 2006 (UTC)
I fail to see the justification for "As a result, few files (resulting in less traffic) can be downloaded when some files are as large as films." Yes, if someone is downloading large files into a hard drive with a low amount of free space, they won't be able to download many of these large files at a time. However, I don't see how this is different for *any* program. If one doesn't have enough space, it doesn't matter how quickly they can download because they'll run out of space before some or any files complete. Frozen North 19:28, 20 September 2006 (UTC)
- This seems hard to describe, I 'll try to explain: My drive has, say, 1GB free space. Now I want to download freefilm_A.avi, size 700MB, and freefilm_B.avi, same size. eMule cannot do that, because on my FAT32 hard drive it will attempt to write two 700MB files at once BEFORE STARTING TO DOWNLOAD, stopping after 999MB saying "Insufficient Disk Space". Now, edonkey definitly did not do that. It created a temp folder each, 1.part(0kb), 2.part(0kb), etc, to 1.met. Unless one part was finished downloading, it contained 0kb, so I could start BOTH DOWNLOADS AT ONCE and burn and delete, say, freefilm_B.avi when it was finished to get the remaining bit of the other. eMule works best with many downloads at once, edonkey just needed less space. Is that not what the file (that you quoted, too) said? (I'd be happy to be wrong, it would help me a lot to know an alternative) FlammingoParliament 01:22, 21 September 2006 (UTC)
-
- My point is that if you began downloading freefilm_A.avi and freefilm_B.avi at the same time and they downloaded at the same speed, your hard drive would fill up when they both reached 500MB and you would have to delete something to complete them. In your example, you would have to either hope or micromanage so that one finished before the other reached 300MB. If you'll look in the extended settings, allocating the full file size is actually an option, not a problem. Frozen North 04:39, 21 September 2006 (UTC)
[edit] removed again.
A problem of insufficient disk space is the size of unfinished files when operating on a partition in FAT32 instead of NTFS. The Help file incorporated into the program explains that it is common to have a full-size temporary file, i.e. before a single file has been downloaded, the hard drive may already be full; it is different from the late eDonkey, whose temp-files were only in about the size of the downloaded parts. As a result, few files (resulting in less traffic) can be downloaded when some files are as large as films. This problem has not yet been fixed.
- If you want to reports bugs for emule use the http://forum.emule-project.net/index.php?showforum=5 bug report forum. I do not even want to start discussing this in this wiki. It is not a major bug. If you want to critisize eMule it should be the fact that it is too complex, not some feature that shows up if you use fat32 (btw, a far larger bug is that you cannot download files > 4 GB opn a fat32 file system.....) :Leuk he 08:58, 25 September 2006 (UTC)
[edit] eMule mod links
Since it seems that there exists a fair amount of confusion on what should and should not be linked on this article, I'd like to start a discussion on the topic. I'll begin by stating my opinion on this matter from my understanding of Wikipedia's guidelines. To quote WP:EL#Links_normally_to_be_avoided:
13: Sites that are only indirectly related to the article's subject: it should be a simple exercise to show how the link is directly and symmetrically related to the article's subject. This means that there is both a relation from the website to the subject of the article, and a relation from the subject of the article to the website. For example, the officially sanctioned online site of a rock band has a direct and symmetric relationship to that rock band, and thus should be linked from the rock band's Wikipedia article. An alternative site run by fans is not symmetrically related to the rock band, as the rock band has only indirect connections with that site.
From my interpretation of this analogy, I believe that linking to mod sites which have no direct relationship to the eMule project should not be allowed. The same way that the article on Linux does not act as a portal to its distributions, by only linking to their Wikipedia articles, eMule should not act as a portal to any of its modifiers' sites.Frozen North. 05:44, 17 February 2007 (UTC)
There are eMule Mods that are allowed by the eMule developers and some are not. a website that show all the allowed is symetric enough, i think. btw. emule-mods.de exist as long as emule and emule-project... Dresik 05:44, 17 February 2007 (UTC)
- My original reasoning was that this was a portal site but after looking at the site for 2 minutes I found an officially disallowed mod (TK4: added as a bad mod on January 15). There is now no question in my mind that this site should not be allowed as it promotes clients which harm the eMule network.Frozen North. 19:45, 17 February 2007 (UTC)
- check the thread http://forum.emule-project.net/index.php?showtopic=90032 if the mod is listed on the developer board, the mod is officially allowed.Dresik 23:29, 17 February 2007 (UTC)
- [tk4 is not a bad mod. But the site has an other problem i rather solve directly with the maintainers of the site than discussing it here. Instead of adding that link you would better add some description about the different kind of mods there are, why mods exist, Some talk about bad mods/ not recognised mods by e-p.net and after you have done that maybe add a short list of mods. remember also wp:el :Leuk he 09:29, 19 February 2007 (UTC) (PS, if you want to start a page abou tht emorph mod i will help to maintain it, but since i am co-dev of morph mod i am not supposed to start that page by wikipedia policy)
- My mistake, I misread a list of unsupported mods as bad mods. Frozen North. 02:05, 20 February 2007 (UTC)
[edit] Ideological developers/development
I think it would do some good to discuss emule's ideological develop(ers/ment). The official emule client imposes certain fixed behaviors that are meant to encourage the sharing of "rare" files. The problem is not in the philosophy, but the approach. For example you cannot control the speed or number of individual upload slots (the client fixes each slot at under 4kb/s, creating more slots to soak up the total upload allotment). You also cannot prioritize uploading chunks of files that are currently downloading, which is what most users understandably want. It's worth mentioning because it's one of the most commonly debated and dubious "features" of the software, and most of the popular mods are written precisely to change this behavior. For example, if there are only one or two sources for a file, having it transferred at 3.5kb/s, plus queue time multiplied by the number of chunks, is NOT conducive to sharing it. However, whenever this issue is brought up in the emule forum, the developers and forum regulars are quite adamant about never changing this functionality in emule, to the point that they are often derisive and smug towards anyone who brings it up. Personally I think it is an ideological, not a practical stance and one that will ultimately damage the long-term viability of the edonkey network. This is because of reality: users will find a way to get what they want. If emule does not allow prioritizing incomplete files, then users will remove completed files from their shared folder so that only current downloads are shared (thus earning credit faster). Or they simply stop using emule and move to BitTorrent or a faster network, taking their files and bandwidth with them. This ultimately damages file sharing through edonkey, because while prioritizing of incomplete files is temporary, the removal of completed files is permanent. In other words, the developers of emule base their design on an ideal model of usage that is not consistent with the real world. This leads to poor download performance for all files, whether popular or rare. (A file with 5 BT seeds/leechers is still going to download faster than the same file with 5 emule sources). The extended file diversity on the other hand, is limited only to small files (because if the file is large and truly rare, it is nigh impossible to complete), and strangely enough, pornographic films (because most torrent sites/trackers won't host porn). So basically, if you are looking for small files or porn, emule is the place to go. Everything else you are better off with BitTorrent. Cyaugin 05:50, 28 February 2007 (UTC)]]
- You really are confusing file shareing with file trading here.. emule is a filesharing application, bittorrent is a file trading applcation. If one starts prioritizong some files some other files will be slower, this will get you not much futher in the end. And emule protocol is better optimized for large files than small files. really. :Leuk he 21:22, 3 March 2007 (UTC) (yup, forum regular, so i am biased...)
