You're providing devkitPro branded products and copyrighted code which isn't released under a permissive license.
I am providing devkitPro branded products which are exact copies of the original devkitPro binaries. According to the "Trademark" page in your Wiki, verbatim copies may be made by anyone, so how is this a trademark violation? Trademark violations are if someone makes a different product and tries to publish / release it as "devkitPro".
That's not how it works, no. You're obliged to provide sources for 3 years from the last availability of the binary. If you provide a binary then you have to also provide corresponding sources, you're also not allowed to just link to someone else's sources to fulfill that obligation.
I am obliged to provide sources for 3 years? Then how come you / the devkitPro team are not providing sources for old versions either? For example devkitPPC r28 is from November 2016, and was removed some time in 2017. Where can one get the source code for that? Or, for libogc 1.8.14 which has been released two years ago and has been available for download at least until 2017 as well?
If I looked correctly, you are not providing that either (all the links from github have been removed) so why should I need to?
However providing old binaries mean that people don't even try. There have been several projects over the years on various platforms that built with newer tools just fine with relatively minimal changes to use newer functions and/or defines. Case in point, there were a huge number of DS projects that used the dual cpu templates for no reason & the arm7 side had bitrotted & no longer compiled. Converting those projects to a simple arm9 project using the default arm7 binary was the only change required.
In other cases projects have become unmaintainable due to people ignoring the compiler warnings which newer compilers have occasionally turned into fatal bugs because function signatures were wrong. In these cases just fixing the warnings has been enough.
"Providing old binaries means people don't try" - that depends on the context. If you have a homebrew developer actively developing a homebrew app, I am sure he will try to keep it updated. And even if he doesn't, he will continue using his old local copy of devkitPPC and doesn't need a mirror. Who this mirror is intended for, is for people, possibly even unexperienced people, who just want to build an old app.
Wii IOS development, for example, still requires a fairly old devkitARM version from 2011 (as I've been told, I'm not sure if this is accurate). Updating all these to the newest version (which would be a skip of at least 15 releases) would be a huge amount of work, (even if every update on its own would only be a little work), while most of the original developers of the old cIOS aren't even in the Wii scene any more. So anyone trying to update cIOS code is basically screwed unless they get the old devkitARM from some other source.
I agree that there are various projects that build on newer versions just fine - and I bet that if someone downloads homebrew sourcecode and wants to compile it and it works with very minor easy-to-do changes, they are going to perform those instead of figuring out the needed old version and downloading that. It is only if rewriting becomes difficult that people would even start searching for the old versions and giving up on porting to a new environment.
And in that case, I've experienced it myself, it is most of the time done by contacting the dev (or, if needed, some other people in the homebrew scene) and get the proper old version from them to compile. If people want to get an old version, they are going to get it with the help of people who still have it. Such an archive just makes it easier.
This, more than anything, illustrates why providing these archives is short sighted and unhelpful. The tools and libraries have moved far beyond the early days of just being able
The tools and libraries work together as a whole. Some versions of libfat work with some versions of libnds but not others. Both libnds and libfat work with some versions of devkitARM and not others. In some cases code built using unmatched versions of devkitARM/libnds/libfat will fail to build or fail to link. In other cases code will appear to build fine but have fatal bugs due to some change in the underlying ABI. Using the wrong default arm7 binary for the libnds version you're compiling with will also result in code just failing to boot.
The same thing applies to devkitPPC/libogc/libfat.
In some cases code built with unmatched versions of the tools & libraries will corrupt SD cards quite badly.
I don't get how this is supposed to be a problem of a mirror / of old versions in particular? Can't that happen with official binaries as well if people compile a tool and have an old version of libfat they didn't update, and a new version of libogc or other mixed versions? Of course it would be the responsibility of the user to download matching versions. But then, in most cases, you can google for which devkitPPC, libogc or other libraries versions you'd need for a given app.
The thing is, we'd much rather improve the experience.
I get that, and I think that this is the goal of all software developers, improving the experience the user has with their software. However, that experience isn't going to be improved if the user is unable to use the software in its given environment. If there'd be any substancial bugs / errors causing FAT corruption or something with the most recent *working* versions of devkitPPC, don't you think the homebrew would already have been updated to work with a newer version?
I get that using pacman and automated updates and such help getting new, improved versions out to people, and that is a good thing. But when that breaks old homebrew applications, the user experience is even better if they have an easy way to compile those anyways, with all the known bugs of the old version (which, in this case, have been present in the homebrew app all the time anyways).
You don't understand the post.
Providing archives of old releases with no understanding of how they fit together purely to avoid having to update code for newer tools is one of the things hinted at under the metaphor of "cleaning windows with a cat".
Updating old projects for newer tools will teach you more about programming than simply recompiling a binary using the tool & library combinations that were originally used. Asking us for help with that process will help us to help you - we don't intend to break old code or prevent people from compiling old projects. If we don't know things are broken then we can't fix them.
Teaching people to hunt for old tools and libraries instead of teaching them how to fix common warnings and update to newer APIs is teaching them to clean windows with cats. It's painful, inappropriate and rather cruel.
I think I did indeed understand the post.
And I agree that *using* (not necessarily providing) old releases with no understanding is "cleaning windows with a cat".
I also agree that asking you for help in order to fix old code is "getting a squeegee and water to clean the windows instead"
But "grabbing old working outdated versions of devkitPPC" sometimes is the "enjoy[ing] cleaning [my] windows with a cat so much", because it is what has been done in the past and has been working in the past. And if there are users who absolutely want to do that, they should be able to do so; in my opinion.
Before devkitPro became a thing it was fairly common for people working on GBA homebrew to be completely incapable of collaborating on anything because there were several different tutorials of varying degrees of wrongness explaining how to build a toolchain and providing a bunch of magic numbers for hardware registers. Some of those toolchain instructions were turned into pre-built binaries with varying degrees of success. Windows centric instructions used bat files, linux often used shell scripts or makefiles. Some toolchains supported C++, some didn't. OSX users were generally left in the cold.
The major thing we did was standardise the toolchain and the environment so that someone using our templates could take a project and compile it on linux, windows or OSX with no changes, everything was provided. This helped a lot with the emerging DS homebrew scene and allowed many more people to just get on with making homebrew instead of attempting to make sense of dozens of contradictory tutorials.
I agree that standardizing the toolchain and environment to compile on all systems and to allow collaborating is a great thing. But, in the case of old unmaintained homebrew, can't that be accomplished with old versions of said toolchain as well?
It wasn't perfect but it was way better than it was before.
We're continually updating and tweaking things too. Pacman is the best thing I've ever done and provides the means to obtain a standardised environment across the 3 main desktop OSes. We intend to improve things further but having to deal with users attempting to build example code and failing because they've followed some random tutorial instructing them to overwrite their initial toolchain install with old versions in order to compile some project that hasn't been updated in years takes a load of time away from improvements we want to make.
Sure, we could just say we can't help them but the truth is if they remove the broken toolchain installation & redo it using pacman then all the example code works and they can get back to learning something instead.
I agree that it is better than before (even though I wasn't active in the GBA homebrew scene so I don't know how it was before, but from your description it definitely sounds like it was hell), and I do indeed agree that pacman is a good idea for new users to download a toolchain. I also get the idea that you got many support requests because people used broken toolchains, and redo-ing them with pacman helped. Yes, the example code will work when compiled with the pacman-version. But the old code the user cares about might not.
Pacman is a great thing for new developers and/or newly-started projects. But, in my opinion, for old, unmaintained projects, it sometimes isn't, because even if the old toolchains might have issues and might be partially broken, they are still easier to use for said old homebrew than rewriting those for the newest toolchains.
-------
I hope that this helped you understand my position and why I wanted to provide said mirror. I am not trying to cause you any additional work, and I'm also not advocating the use of old toolchains for new or maintained products. But there are just edge-cases, where, in my opinion, using an old toolchain is a better solution than spending a lot of time adapting an app for the new one, even if you and the rest of the devkitPro team is willing to help with that.
