• Content count

  • Joined

  • Last visited

About Crise

  • Rank

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender

Previous Fields

  • Favourite DC++ client?

Recent Profile Visitors

53,035 profile views
  1. 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).
  2. 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).
  3. 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).
  4. 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.
  5. 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
  6. 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.
  7. 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:
  8. 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.
  9. 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).
  10. ApexDC++ 1.6.3 maintenance update available

    I am not yelling at all. Zion, last updated in 2007, and RSX++, last updated in 2011, to be frank I am surprised this is the first issue you have encountered with newer clients. I will do what I can, however, if I can reproduce this issue with the latest version of DC++ then as far as I am concerned it is something that has to be taken care of upstream. No need to be so hostile all I did was as a simple diagnostic question, because for one your post was unclear on which clients were encountering an issue.
  11. ApexDC++ 1.6.3 maintenance update available

    Can you tell me which clients the users people are seeing this from are uaing? (exact versions). Seems to be a backwards compatibility issue with zlib most likely.
  12. ApexDC++ 1.6.3 maintenance update available

    I do use it, although only for chatting, and that is enough for me. If I am going to patch in security updates for my personal use I might as well put the builds out there available for everyone. I don't exactly disagree with you entirely on the state of DC, however, there are still plenty of people who do use it. Like I said in an earlier post, it can not compete as a p2p application, but it does offer something that most other p2p applications do not (and it does so, in my opinion, better than f.ex. IRC, personal servers are easier to set up and if you do need to send files it is way more user friendly). Mainstream p2p, if there is or ever was such a thing, I definitely concur with you DC is far past its time in the spotlight. But at the end of the day, that is understandable, the software was developed when terabyte was a large amount of data and most normal people didn't even know what a petabyte was. DC is not dead though, it just so happens it no longer has large scale public appeal (at least in most of Europe and USA, not sure what the situation is out there in Asia etc.). PS: DC++ is a piece of software, DC is the network (technically even that isn't correct DC being originally a shorthand for NMDC, but it now also covers ADC).
  13. ApexDC++ 1.6.3 maintenance update available

    The code is technically open source even now, as any DC++ derivative should be, just that it is not being actively distributed just as the builds aren't (anyone who has had access to the builds in the past has been, and still is, able to request the source code for any build they have access to, as per GPL's requirement of equivalent access). It will probably eventually end up out there in the open, however, it is literally years behind at this point. Not that it means all that much, considering the cadence of updates on the windows side has also dropped. I know that opening it up might have some benefits at the same time I'd rather not put something out there, generally available, that is in a state not representative of what ApexDC is on windows (generally when it comes to wxWidgets version of ApexDC, it is like taking one step forward on other platforms but taking two steps back when your point of comparison is the windows version). It was never in a state where I could take it up as my daily driver on windows, which is probably one big contributor as to why I wasn't very motivated to work on its problems. I am not sure if I have previously said this here, but in retrospect if I had to make a cross-platform DC client I would probably take the ApexDC core gut the UI out of it and expand the current very barebones web server that it has to actually be modern and fully usable set of API's to which I could then build web based UI for in relatively short time. I believe at least one other client has done this (AirDC) and, even though hindsight is 20/20, it is really the way we should have approached this aspect as well. If only because building web based user interfaces has come a long way in the past few years and it is comparatively extremely fast to building something more native (and the technologies involved are generally very well supported). To give the above a bit of context, my use of DC today is entirely for discussion, it has basically taken the same role as IRC would for most people, the P2P aspect of it is honestly completely secondary to me at this point (also, the performance the protocols can support just can't compete with other ways of distributing files these days).
  14. Thumbnail view

    Depends, such a feature is in theory possible... having said that it would most likely require either creative use of the protocols as they exist right now or extending the network protocols to add this behavior . So, in short. Even if it was done it would only at best work between two other clients that implement this same feature in the exact same way.
  15. ApexDC++ 1.6.3 maintenance update available

    As much as I would wish to say otherwise, that project has been stalled for quite some time now, and minor releases like this one are basically everything I have time for at the moment. On windows, I can put out a small release efficiently, whereas for other platforms my ability to even test changes and make builds available is limited. This works, however, the way people should actually address this issue is by changing the "Balloon Popups" options in ApexDC settings to their preferences instead. Yes, the title of the page is technically not correct anymore but once up on a time it was.