Crise

Management
  • Content count

    3,004
  • Joined

  • Last visited

About Crise

  • Rank
    Developer

Contact Methods

  • Website URL
    http://www.apexdc.net
  • ICQ
    0

Profile Information

  • Gender
    Male

Previous Fields

  • Favourite DC++ client?
    ApexDC++

Recent Profile Visitors

53,724 profile views
  1. I am pretty sure there is no DC client out there (with a graphical user interface) that can handle high volume of hubs very well, of course it depends on hub activity and size as well as any ongoing transfers etc., but the UI's at the very least are not generally built to handle high loads. The only advice, short of looking at a command line client, I can give is make sure all logging is disabled, although this will only primarily reduce disk I/O.
  2. Built in Anti-SPAM

    Just as an general comment... running ApexDC, or any DC client, with 80 hubs open is not really a typical use case. Or rather it wasn't one when these applications where created. So they really can't deal with volume efficiently, regardless of whether PM's are spam or legitimate messages. The UI is (or rather was originally) designed in such a way that the user is expected to only open a number of hub connections they can manage manually, which is why there is no real degree of automation in many places when it comes to managing any aspect of the UI. To put it in another way, DC really is not a general purpose file sharing application, as it was never designed to reach a large volume of content at once. Rather it was designed to reach a type of content aggregated by getting like-minded users together, you could say quality over quantity I guess (hence why it has chat featured at least equally if not more prominently than file sharing capabilities). As a bit of a history lesson, the original incarnation of DC was intended as an IRC replacement with a more user friendly interface for sharing files, as using IRC for sending files or using file servers is a bit of a mystic art in itself (and certainly mostly a lost one at that these days). Apart from that the original DC client, out of which DC++ and its many variants were initially reverse engineered from, could only connect to one (1) hub at a time. For more on the history of this thing, look here. Not that it is really good for anything but an interesting retrospective in today's context as the DC of today is completely different from that, but some parts of it still show today, in particular in the way the applications remain structured to this day.
  3. Windows Defender found threat

    There is no difference, except that the slim package only contains the required binary (ie. the .exe file). Mainly I suggested it so that we can see if the issue is specific to the version bundled in the installer. Having said that the binaries in each case should be identical.
  4. i cant connect any hubs why

    Problems connecting to the update check should not be related to connecting to hubs at all, unless ApexDC is being blocked by either a router or a firewall, in which case it can not access the network at all. What is the connection error message you get in the hub windows (ie. after the line "*** Connecting <address>..."
  5. Built in Anti-SPAM

    I have actually recently though about this type of feature. However, pattern and IP matching will only result in a never ending game of cat and mouse. As such the only reasonable compromise I can think of (which can not be circumvented by script and bot authors) is to provide an option to ignore all PM's from particular type of hubs that are not from privileged users (ie. operators) or potentially users you have chosen to exclude by adding them as a favorite user. The problem with above though, is that it is quite a binary choice and can not be configured very well (at the same time, I am not interested in adding a feature that matches Nicks and IP's because of things already mentioned here). At the end of the day preventing bots from getting into a hub in the first place is obviously a hubs responsibility and whatever a client can do is only ever a band aid.
  6. Windows Defender found threat

    Where did you download the version of ApexDC in question, if you are using the installer make sure it is one from this web site. Also try with the binary only slim package instead.
  7. Did Team Elite win?

    I probably shouldn't say anything here to be honest, but I am going to anyways. Who won, is irrelevant... the whole concept of winning in this context is somewhat absurd it is not a war or a competition with a beginning and an end after all. I find it amusing that the word enemy even came up here at all. Whether I personally agree with or condone some actions of groups or individuals in the past, one way or another, is a different matter entirely, but also irrelevant. However, actions should have consequences and it should work both ways. I never was keyed into all of the drama, nor did I particularly want to be, however, I believe there is rarely if ever a good reason to hack (or whatever that word actually exactly means/meant here) something or someone. Unless, you have been explicitly asked or commissioned to do so to test for vulnerabilities for example. There is seldom a need to act on something, say a vulnerability, just to make it known. The situations where throwing your weight around is your only course of action should be few and far between (and if it is done, it should be with the knowledge that doing so will likely in turn invite some kind of response from others involved). This applies to all sides not just one or the other. When it comes to DC related projects, each project is free to manage themselves how they see fit, if that management causes ire with others then handling those situations is each projects individual responsibility as is handling any consequences of any decisions made. However, this also means that everyone involved should be able to respect these projects' right to make these decisions and at the very least agree to disagree on amicable terms. Just because you can do something doesn't mean you necessarily should, sometimes that means pushing aside your personal feelings so that you can look at a situation objectively and make the necessary decisions. Either way looking for trouble or making choices that you know are going to perpetuate a cycle can hardly be called productive use of time and resources. To address the matter of hublists, the whole concept while necessary at this time is, from infrastructure point of view, the weakest point in the DC network a linchpin if you will and obviously not in the positive sense. DC has a network structure that doesn't strictly require a centralized entity (above hubs) that has a lot of control in the first place so in the long run there should be an alternative for hublists that can ideally work autonomously. This is the direction that DC should have headed in the first place and it is purely based on the simple fact that a system that is self-managing is legally the most sound option (If you have little to no control over a system you can not be held responsible for exercising control, over said system, which you do not have).
  8. Don't stop downloading at missed file

    I don't speak german (I think that is german anyway), but those kind of errors are propagated from the file system... my guess is that says the syntax for the file name or path is incorrect or invalid. Which means it is not that the file can not be found but that ApexDC can not save the file on your system. There can be number of reasons for this, however, it should not stop other files from being downloaded. Unless, said errors are so common that they take up all the spaces for active downloads (see Settings > Downloads, under the limits section). If the errors are so common that it is making it difficult for you to use ApexDC, I would suggest looking at the files that this error keeps happening with and seeing what they have in common (such as if they are all from the same hub or same users, or if their names seem strange in some way). Off the top of my head I would also recommend checking that your incoming downloads directory is set in a location that is always reachable. With very long path names the archaic limitations on Windows file path length might also be what is causing this... if you need to have your files in such folders or if you routinely work with files that have long names I would recommend reading up on the matter because ApexDC will not be the only software with issues on those kind of paths (the linked StackOverflow question has some proposed solutions).
  9. Don't stop downloading at missed file

    Please clarify what you mean by file cannot be found? As far as I know, if the error encountered is "File not available" it will proceed to download files just fine (same should be the case if file has no sources). If there is an issue with these two transfer states it might be due to other features setting the priority of the file or preventig removal of invalid sources. However, initially I am thinking that what you mean with file not being found is not what I am talking about above but rather something else, because I don't ever recall hearing of this issue before (and as far as download queue management is concerned, that hasn't been touched in years).
  10. ApexDC++ 1.6.3 maintenance update available

    The upgrade notice says it fixes connectivity issues with older versions (of apexdc) ie. the problem with 1.6.3 discussed here. Hubs should discourage the use of 1.6.3. However, if they are doing the same for .4 then they are in the wrong in the sense that 1.6.4 exist to address the problem with 1.6.3. As far as we are aware, there is no connectivity issues with 1.6.4, with any version of ApexDC or any client that we are aware of. You should be able to use version 1.6.4 or 1.6.2 without problems. However, you should not use 1.6.3. That is exactly what it means, as it says in the 1.6.4 announcement.
  11. We are pleased to announce the immediate availability of another maintenance update 1.6.4. This version fixes connectivity issues with compressed transfers caused by recent updates to the zlib library that we use. These connectivity issues randomly affect both downloads and uploads with clients that are running an affected version of zlib without the appropriate fix included. Additionally OpenSSL and zlib dependencies have also been updated once again, in order to keep things current. For the people who still need the XP compatible binaries, we would like to take this chance to once more remind you about recent changes in release packaging for your operating system. A full list of changes are available on here. As usual we strongly recommend upgrading to 1.6.4 as soon as possible. Download: ApexDC++ 1.6.4
  12. ApexDC++ 1.6.3 maintenance update available

    Now, is that a nice way to ask someone to do something. As for people upgrading to this version, as far as I am concerned there is no reason not to, provided they know how to read [the release announcement]. The update check doesn't direct them directly to the download page and, even if it did, the release announcement is linked on both the page they land on as well as the download and the changelog pages. So they have ample oppertunity to read it. We did our due diligence on the issue after it became known and in the end provided a not one but two working alternative solutions. Whether people make use of those solutions is not something I can enforce in the slightest. Likewise taking 1.6.3 out of circulation, is effectively not possible. Even if I did remove it from the site, the binaries are still out there. Also, having said that there is currently no easy way to roll the website back and then redo the changes when the version with the fix is ready, which is why I will rely on users ability to read and be people who can think for themselves instead. Now, as far as hub admins go, they have two options, either instruct people not to upgrade to 1.6.3 or point them to the workaround provided. Alternatively they of course could enforce a bans on the use of the client, either version specific or for the client as a whole. However, this again is not something we can influence and as such how they deal with the issue is entirely up to them. As far as I am concerned, by providing a fixed version at our earliest convenience (which will likely be this weekend, because people have a lives), is all we have to do.
  13. ApexDC++ 1.6.3 maintenance update available

    I have updated the first post with instructions for a workaround for the time being. New version will be made available as soon as there is a verified fix for the problem. Relevant link: https://bugs.launchpad.net/dcplusplus/+bug/1656050
  14. ApexDC++ 1.6.3 maintenance update available

    1.6.2 is on sourceforge, the page is linked from the download page. This is an issue with zlib upgrade. It affects all dcpp based clients with the new zlib as far as I know.
  15. ApexDC++ 1.6.3 maintenance update available

    Not being affected by an exploit because a client is old isn't the same thing as not needing updates. It is just dumb luck most of the time. But you are right, that is off-topic.Also, being aware and doing something about an issue are two different things.. Why was it unclear... if another client can't decompress a filelist from the latest version of ApexDC yet that version can decompress its own filelists and another randomly picked client can decompress filelists from it then obviously I have to know which clients the issue manifests with. Also, there is always the possibility it is an issue specific to a single user, or multiple users with something in common when it comes to their shared files, (it could be as simple as the filelist that was generated being corrupted while being written to disk by chance), I am looking for information to reproduce the problem which your original post did not give me. Update: I just finished doing connectivity tests, and ApexDC 1.6.3 generated filelists download and open just fine using RSX++ and Zion++. So, it is definitely not a general issue with 1.6.3 (all involved clients in active mode using default settings).