I understand now why I haven't seen newer acqx nodes. Dave IS AN ***. I told him 50% of acqx users were leechers and few of them were running UPs (things verified by me and Stief) and now we can't even verify the behaviour of acqx (because Dave changes settings in the LW core). Now Dave merits to be slammed, what an idiot!!!

Acqx su*cks!

I already asked him, if it was a bug. The answer was, that it is intentional. He didn't react to further questions about this.

But You'll have to excuse me for quite liking Acquisition, as it still quite beats LimeWires usability. A LimeWire lite with only the most necessary features (or a Konfabulator-widget for which I posted the request in the LW-OSX-Board: http://www.gnutellaforums.com/showth...threadid=25614 ) would be likely to make me switch back. Problem is: I want a good working, sleek app, and Acq is that. I can for example "stream" mp3s over Gnutella with it via the preview-function (using iTunes) (as long as I get enough speed) with a single click.
At the moment I mostly use LimeWire to create magnet-links.

PS: I only found it out by chance as I tested, if Phex is able to connect to Acquisition through my dyndns-account (works) and just saw the LimeWire vendor-message, but at my dyndns-account and with my custom Acquisition port.

You shouldn't bother with ACQX and Dave's interpretation of the GPL. It makes you only feel anger and you risk to die of heart attack. It's only a matter of time until LimeWire's UI will catch up and will hopefully outrun ACQX in some way. Just lay back and enjoy the upcoming novelties and possibilities. An important decision was made last week but I cannot tell you more yet, sorry. :cool:

BTW. Arne, Dave contacted me last week and he said he'll include the missing classes in the next release of the "Acquisition-Core"

Now you got me excited :)

Even the small changes I saw in the UI (new splash-screen for example) showed my, that I can expect LimeWire to get far more usable.

Good to see, that you are now far enough with the network-code, that you can actually work on the interface again. 3kB/s network overhead for an ultrapeer sure is great!

Rodger: I do not care a lot about Dave, it is just that some support him blindingly and spread some propaganda. He is like a few other dozen P2P "devs" that abuse gnutella and LW. I'm so happy LW clusters themselves and limit the dommage by not allowing many foreign vendors slots!

There is a lot of knowledge to spread around to kill misinformation, and still many myths to kill ;)

C'est vrai--Let's keep the knowledge flowing . . . and keep crediting those who contribute real benefits to gnutella users.

Dave: You harm yourself and your users by taking more than your share of the credit. Roger, Sam, Gregorio, Phillipe, Jens-Uwe and many others I am only dimly aware of deserve credit. You know best who to credit, so let your users know too. You corrected those who bashed gnutella, so do the same for those who bash LW.

(Arne, I know you try: do you get much credit for your contributions?)

If ACQX is really using the 4.0.2 core, we'll see how many people complain about too many connections as an UP.

Politics--bleagh! (RAZA is taking another hit in the GDF this morning--hope Phiippe's java optimization gets more attention).

Back to the topic: so--multinetworks (bad), which leads to clustering/ "Good Leaf" definition.

Should we ask for "Block Vendor" with the ability to identify false Vendor messages?

Currently LW clusters naturally, but bans itself from taking all the slots, right? LW will not allow *itself* to use all leaf slots--two will be reserved for non-LW leafs, but as many as 15 *could* be connected if I understood Sam correctly here http://groups.yahoo.com/group/the_gdf/message/19704
I agree--this is a very generous policy.

The definition of a *good* leaf is less clear to me;)
trap_jaw wrote a "greedy client" patch, which I gather has been adapted and works quite well. Is this enough?

I'm inclined to think the slow process of the GDF and the proven cooperation of LW to encourage other developers is sufficient.

Ask for "Block Vendor", or just let it be?

(@stief: I got some, and for GnuFU I got quite many positive reactions (and when I don't get them, I can at least look at the visitor count, which just topped 3000).

The translation of Acquisition was rather hard work, which was hard to do when we first had to convince Dave to make if fraggin possible.)

I think it would be better to do the blocking dynamically than just specific vendors, but it would be nice, if specific version-numbers could be blocked, so that especially greedy or buggy versions could be taken out of the net, while the client can still get back to adopting good practice.

Among these, only Sam is working for Limewire. All others are generous contributors. Sam was a contributor too last year before he joined the Limewire crew working in New York.

Our common policy however is to keep being generous with other servents, under some limitations to protect LimeWire users from excessive abuses, in the hope that LimeWire users will still benefit of a good interconnection with other servents that also have interesting contents (BearShare notably and GTKG, Swapper.Net or MLDonkey or MyNapster, but also GnucDNA-based servents and even Shareaza for which we still offer a mutual access even if we control their greedy behavior and limit the access due to lack of support).

Extreme measures are taken on really malicious and leaching servents (Xolox for example) that abuse all other good or average servents without offering any assistance to maintain the network or to discuss the interoperability issues within the GDF. Some other servents are also abusing the GPL, such as Poco in China (abusing the gIFT's GPL; well gIFT is not even a good implementation of Gnutella and its poorly coded and we need to maintain it under control, without rejecting it completely).

For LimeWire open-source abusers, there was the case of FreeWire and AtomWire. But they are nearly extinct due to their bad stability and absence of maintenance or support, unlike AcqLite and Acquisition which are very active.

I still don't know what is "Kiwi" which has started since a few weeks to come regularly. I have no opinion on its quality.

I would like to have opinions of LimeWire users about what they get from remote TrustyFiles servents, which are now very active. I hope this newer servent is correctly maintained. The next months will learn that to us, or simply LimeWire 4 will beat it...

Philippe, Trustyfiles (also abusing the GPL of giFT for fasttrack support) and Kiwi alpha are GnucDNA clients meaning they harm Gnutella as well.

Désolé :(

TrustyFiles legal status
 

Please note that much of the network code in TrustyFiles 2.2 was rewritten for better performance and stability. The code is now 100% internally developed and does not use giFT or gnucDNA.

Marc Freedman
RazorPop, developer of TrustyFiles