First of all, the purpose of this blog post is not to bash something, but rather to enable you, the users to make an informed choice. In return, I only ask of you to keep the discussion below this blog post civil, as in the past similar discussions got emotional rather fast. Always keep in mind, it is your hardware, you paid for it, you can do with it what you want.
I am the current main dev behind Decryt9WIP and the dev of EmuNAND9, OTPHelper, HourGlass9, GodMode9 and CTRXplorer (among others). Chances are you used one of my tools at one point or another, even if you are not a a9lh user. I have followed the progress of the arm9loaderhax installation setup over time. I know that there is a shitton of stuff that can go wrong in the process. After all you are overriding Nintendo's own safety mechanisms with a bunch of unstable exploits (failed boots anyone?), and doing stuff your console was never intended for. The arm9loaderhax process, as detailed by @Plailect's guide has gotten pretty safe. There are only very few bricks by now, most (all?) of which can be explained by user errors, which we are trying actively to prevent. There were more bricks in the past (just look at polls of the past), but that was research in progress. To get to the level of safety that we have now, a lot of work, from a lot of devs and hardmod testers was involved.
Now, a new player enters the field and claims stuff such as: "We are the only ones to present you the best, safest and user-friendliest way out there to install the GATEWAY FAST BOOT method also known as A9LH." Let's look a bit closer at this claim, shall we?
(best, user-friendliest)
What you get with GW A9LH if everything goes right (= not a brick), using their tools to install:
In contrast, what you get with the standard, open source A9LH installation:
(best, safest)
As I wrote above, there is a shitton of stuff that can go wrong on a A9LH installation. GW's A9LH installation process seems simple when compared to @Plailect's guide, but that is mainly due to (1) less detailed instructions and (2) the removal of crucial safety steps, stuff that could save your 3DS' ass in case something goes wrong.
I followed the testing process closely, noticing several errors they made. The worst of it was the failure to actually unbrick N3DS 2.1 NANDs, resulting in a guaranteed brick for N3DS users (only solvable by hardmod). This would have been very easy to catch, even before any testing phase, but it still slipped through. Team GW is not even really at fault for these errors - the process is complicated, and it took open source devs and testers a long time and a lot of dedication to get it as safe as it is now. They, on the other hand, consist only of a small team, and are also pressed to do sales (as shown by their marketing claims). That task is too big for them, and it is very doubtful that even on a later release version this will be sufficiently safe. It is on the other hand very likely that there will always be a significant bricking risk with this.
Users should also take note that GW software contains code that bricks your console on purpose, which is a known fact. In theory, that code should only spring into action when a fake GW card was detected, but there was at least one case during the last testing phase where a genuine GW user was bricked, most likely by exactly those deliberate bricking routines.
TL;DR
It is your hardware, do with it as you want, but get informed about the risks. My - and basically everyone elses - recommendation for everyone who wants A9LH is not to use GW's time machine and A9LH installer, but use the open source guide and tools for the installation instead. For GW features, use the arm9loaderhax.bin they provide instead of the full installer.
I am the current main dev behind Decryt9WIP and the dev of EmuNAND9, OTPHelper, HourGlass9, GodMode9 and CTRXplorer (among others). Chances are you used one of my tools at one point or another, even if you are not a a9lh user. I have followed the progress of the arm9loaderhax installation setup over time. I know that there is a shitton of stuff that can go wrong in the process. After all you are overriding Nintendo's own safety mechanisms with a bunch of unstable exploits (failed boots anyone?), and doing stuff your console was never intended for. The arm9loaderhax process, as detailed by @Plailect's guide has gotten pretty safe. There are only very few bricks by now, most (all?) of which can be explained by user errors, which we are trying actively to prevent. There were more bricks in the past (just look at polls of the past), but that was research in progress. To get to the level of safety that we have now, a lot of work, from a lot of devs and hardmod testers was involved.
Now, a new player enters the field and claims stuff such as: "We are the only ones to present you the best, safest and user-friendliest way out there to install the GATEWAY FAST BOOT method also known as A9LH." Let's look a bit closer at this claim, shall we?
(best, user-friendliest)
What you get with GW A9LH if everything goes right (= not a brick), using their tools to install:
- Fast and stable boot to the Gateway CFW on EmuNAND
- System updates are blocked and would otherwise brick the system
- No ability to run ARM9 homebrew such as Decrypt9 or EmuNAND9
- No ability to restore to an earlier state (might be wrong, see below)
In contrast, what you get with the standard, open source A9LH installation:
- Fast and stable boot with a free choice of CFW
- The A9LH installation is protected on most CFWs, thus you can do system updates without trouble
- A plethora of ARM9 homebrews, which make the whole thing safer, give you more options or are just fun
- You can always go back to an earlier state thanks to actively developed homebrews
(best, safest)
As I wrote above, there is a shitton of stuff that can go wrong on a A9LH installation. GW's A9LH installation process seems simple when compared to @Plailect's guide, but that is mainly due to (1) less detailed instructions and (2) the removal of crucial safety steps, stuff that could save your 3DS' ass in case something goes wrong.
I followed the testing process closely, noticing several errors they made. The worst of it was the failure to actually unbrick N3DS 2.1 NANDs, resulting in a guaranteed brick for N3DS users (only solvable by hardmod). This would have been very easy to catch, even before any testing phase, but it still slipped through. Team GW is not even really at fault for these errors - the process is complicated, and it took open source devs and testers a long time and a lot of dedication to get it as safe as it is now. They, on the other hand, consist only of a small team, and are also pressed to do sales (as shown by their marketing claims). That task is too big for them, and it is very doubtful that even on a later release version this will be sufficiently safe. It is on the other hand very likely that there will always be a significant bricking risk with this.
Users should also take note that GW software contains code that bricks your console on purpose, which is a known fact. In theory, that code should only spring into action when a fake GW card was detected, but there was at least one case during the last testing phase where a genuine GW user was bricked, most likely by exactly those deliberate bricking routines.
TL;DR
It is your hardware, do with it as you want, but get informed about the risks. My - and basically everyone elses - recommendation for everyone who wants A9LH is not to use GW's time machine and A9LH installer, but use the open source guide and tools for the installation instead. For GW features, use the arm9loaderhax.bin they provide instead of the full installer.
