|
LimeWire 1.9c beta LimeWire has released the beta version of LimeWire 1.9c, available at: http://www.limewire.com/index.jsp/download_beta This beta is almost identical to the 1.9b beta (probably the most short-lived beta in LimeWire history!) with several important fixes for non-Windows systems. As with 1.9b beta, this is primarily a maintenance release, although the improvements over the LimeWire 1.9 beta are crucial, particularly in terms of performance. The changes include: <ul> <li>Significant performance improvements, both in terms of CPU and memory. <li>Prevents spurious disconnects from UltraPeers after conducting searches that return a lot of results. <li>Ads in non-Windows versions! Seriously, they are there. Don't worry too much, though -- we did the ads ourselves, so they're a bit less annoying than the Windows ones. If you click on the Amazon link to do late Christmas shopping, a portion of the proceeds goes to support LimeWire and the open source project. <li>Minor bug fixes with swarm downloading. <li>Improved logic for grouping similar results for swarm downloading and smart downloading. <li>Improved UltraPeer election process, so you will not get elected as an UltraPeer if you are a modem user. </ul> As many of you have noticed, we are having problems with the Linux installers. We are still unable to identify the precise system configurations that will cause the error, but if the beta installer gives you problems, try just using the tgz file available at: http://www9.limewire.com/beta/1.9c/l...eWireLinux.tgz. This file will also work on most other Unix and Unix-like OSes. The most important change for the beta is really in performance. You should see significant performance improvements, especially as an UltraPeer, over the previous version. As with the short-lived 1.9b beta, thanks very much for everyone's feedback on 1.9. Your assistance has been invaluable, and we have fixed many bugs in this version that we likely would not have found without the help of all you forum readers out there! |
LimeWire 1.9c is working on FreeBSD. I just had to comment out J2SE_PREEMPTCLOSE=1; export J2SE_PREEMPTCLOSE so it would work. If not it gave me this error /usr/local/linux-jdk1.3.1/bin/i386/green_threads/java: error in loading shared libraries: /usr/local/linux-jdk1.3.1/jre/lib/i386/libpreemptive_close.so: undefined symbol: pthread_kill But anyways, I have it working...I like the little neat features and options it has. Keep up the good work! |
Works Under Linux Installer works for me! Good Work! P.S. Linux installer hasn't ever worked for me til now! (all betas) |
Ads I tried clicking on the ads and nothing happens. Should my browser or something open? I'm using linux. I know Limewire can load a browser because Help-Forums works! thank you. |
Glad it seems to be working for everyone so far. Good point on the browser launching with the ads -- browser and file launching on Linux in general is quite tricky, and is an area that we hope to improve. It should work, however, whenever any of the help menu items work. Anti-Bearshare -- thanks for the tip on the PREEMPTCLOSE variable -- I believe that we put that in there for the Linux JVM (if I remember correctly), so this makes some sense that it would cause problems on FreeBSD. That's great you're running FreeBSD over there -- I was woefully ignorant of its significance to computing in general until reading up on my computing history over the last year. Glad LimeWire's working on it. |
I like the LimeWire ads, they look nice. I would like to see more Open Source ads or geek ads (ThinkGeek). Ads along that nature. Even though I cant click on the ad to let it pop up a web page what is the LimeWire Pro all about. Whats the url? |
uhmm ok..... I've been running LimeWire 1.9c since the first time I posted which was not so ever long ago (I would do the math but the board is set on a different time zone or something). This is a fresh install of LimeWire on this system so of course it shouldnt have any values set for my stats (uptime, downloads, etc). But I noticed I'm already an Ultrapeer. This is the first time I have became an Ultrapeer. Before I was running Windows (I wont go into that :x). Anyways I can see that some of my connections are 0.4 and some say leaf. So I'm guessing only 1.8 and up only support the Ultrapeer function? For some reason I was thinking the older clients could take advantage of becoming a leaf. I guess I was having a brain fart (this past week I took all my finals for this semester :P). |
Glad you think the ads look alright. If you click on the Amazon ones to do late Christmas shopping, we get some of the profit =). As far as the connections issue, older 1.8 clients did not have any logic in them to take advantage of new UltraPeers, although this would have been very nice. We really merged in three major projects into 1.9 that had previously developed relatively independently (the swarmed downloading, the UltraPeers, and the query routing, which had undergone an earlier sort of merge with UltraPeers), and none of these had previously been in the code. Moving forward, we should see some really nice improvements as more nodes become UltraPeers. |
afisk, you didn't answer my objections concerning the modem-exclusion for swarming. i ask you again to remove it. one highspeed connection downloading five files could easily consume 30 swarm sources. a modem user would hardly ever use more than 3 until his speed is maxed out. therefore, it is not them who are responsible for having less upload slots. the highspeed users are. furthermore, the current swarming feature allows highspeed users to swarm from up to six modem users and decrease the little bit of bandwidth that they have, while a modem user can only download from one other modem user. sure, modem users don't profit as much as highspeed users. but that also means that they can't harm the network as much. this doesn't make any sense at all. how do you think i feel when i know that: - highspeed users may swarm - this decreases the number of upload slots - therefore modem users (who hardly consume any slots compared to highspeed ones) are excluded from swarming - but the highspeed ones are still eating up my bandwith in order to max out theirs? if you want to ensure the number of available upload slots find better ways . for example, link the numer of allowed download connections to the number of upload slots. so a user who has allowed no more than 5 simultaneous uploads should not have more than 5 connections to simultaneously download from. the way it is is not peer to peer at all. it is next to exploiting modem users. on a p2p network, either everyone should be allowed to benefit from swarming, or noone should. -- awaiting comments |
Abaris- I did not neglect your questions intentionally -- it is just a bit difficult to keep up with all of the threads and release new clients at the same time. We do dynamically allocate upload slots in 1.9 and above versions of LimeWire based on your measured bandwidth. The quick solution to this problem is to switch your connection speed to cable in the options window. If you do uploads and downloads, we will still be able to measure your speed, and you will still be reported as a modem in outgoing search results. We may change this behavior at some point, but this is the way it is for now. It's too sensitive a change to make this close to final release. Thanks for bringing this up -- you raise valid concerns that we will consider in the future. |
Quote:
You have file X which is ~5MB (5120 bytes) and so do 5 other hosts (all modem users). Well if host HS (highspeed) tries downloading file X from you he is more in likely to consume all your bandwidth. Saying ~5KB/s is your max total (exclude Gnutella and other network traffic at the moment). Ok 5120 / 5 = 1024 (seconds) 1024 / 60 (secs; also 1 min) = ~17 (mins) That means that Host HS would be consuming all your bandwidth for a total of 17 mins. That really sucks. Now lets see how many mins it would take if Host HS was swarming you and the 5 other hosts for file X. ~17 (mins) / 6 (hosts) = ~3 mins (2.83) Thats a lot faster! Which means if Host AHS (another highspeed) down the road also wants file X. QoS (Quality of Service) results will likely show Host HS as the best source to download from. Or if Host AHS swarmed he would be leaving one or two modem users out by connecting to Host HS and also finishing at a faster rate b/c of Host AHS's connection. Quote:
Quote:
Quote:
Quote:
|
afisk: i didn't say you were. i just meant to remind you. i am pretty sure that you have much to do and i understand that there may be difficulties in changing the measurement code and that you can't do it for the next release. nevertheless, i ask for the modem exclusion to being no more than temporarily. anti-bearshare: > The whole point is for a host to get the file as fast as it can so > another host can download from them instead of lower speed > connections. For example... thank you, teacher. i know what it is about. > There is nothing you can do about your bandwidth!? Thats like > complaining who won an election when you're old enough to > vote. Its just something you have to live with or get a faster > connection. it is not like that at all. actually there are locations where cable or dsl connections are not available. i live in one. shall i move to another town ? i don't even want to have more bandwidth. i want to use that what i have more efficiently. what's bad with that ? > There should be no restriction from who you can download really ? why should you use more download connections than you are giving upload connections ? why should you use more bandwidth for downloading than you offer for uploading ? what you say is a mandate for freeloading. > Why dont we just get the RIAA and MPAA to regulate the > Gnutella network. [...] This isnt Commie P2P either. now do you take me for a communist or for an RIAA lobbyist? it seems that i am both to you...interesting really > you dont try to have 5 downloads simultaneously and expect to > be able to load a webpage within 30-60 seconds Just listen: when i download a file, i get a transfer rate of 1-2 kbps most of the time. this is not due to network traffic - when i download two different files simultaneously, i get much more. but i don't want to download two different files in order to use my bandwidth effectively. i want to download one file from two sources simultaneously. when i download a 100mb file (what i don't do frequently), shall i download another 100mb of mp3s (that i don't even want at that time) in order to not waste my bandwidth? don't write nonsense about Commies and the RIAA, but answer me one simple question: if i am allowed to download two or three different files simultaneously, why should i not be allowed to downlad one file from two or three different sources simultaneously ? why is the latter one hurting the network ? maybe a 2-3 kbps gain is not much to you. it is the world to me. it more than doubles my transfer speed. you benefit of swarming, why shouldn't i? i don't hurt the network more than you do. a swarm download of n sources uses these sources for 1/n of the time than a standard download, being a modem user or t3 user does not matter a heck. when developers are troubled about decreasing the number of available upload slots when everyone uses swarming, they should bind download connections to possible upload connections. they should not select one group of users and disable swarming for them. this is not about communism, it is about fairness. |
| All times are GMT -7. The time now is 07:49 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.
Copyright © 2020 Gnutella Forums.
All Rights Reserved.