PSA: Do not try updating Atmosphere files from within HOS

[The Real Jdbye]

Removing the sd card honestly just shouldn't be recommended that much tbh. Hekate ums is the way to go.
Because of how the reader is made over time the connector will get damaged.

Yeah. Having looked at how the connector for that little SD reader board is designed, it's no wonder it breaks easily.
The board is screwed in, which is good, but they used a single screw, which won't prevent the board flexing from side to side and potentially damaging the connector over time. They should've used 2 screws.

But taking the SD card out every now and then (and not pushing on the SD card with more force than necessary to insert or eject it) probably won't cause any damage.

 

[vgmoose]

I largely agree with @CompSciOrBust , the Wii was explicitly made extremely simple, and Switch setup is comparatively harder. What are the official resources for installing or updating Atmosphere? Well there's the Github repo. Are there instructions in the readme or on the releases page? No.

The release zips do contain all the barebones resources that you do need to copy to SD root in one zip, and usually that can just be straight copied over (which already is no trivial feat, so it does show that intentional dev work has gone into making those files easy to copy, which is great!). However there isn't so much of a mention of any SD card root anywhere. That is left as an exercise to the reader. It's not trivial to explain that to someone who barely knows what a file explorer is!

And then there's even less of a mention of RCM, the ways to enter it, different exploits, how to update it in the future, how to use title override (hbmenu will helpfully display "- Applet Mode -" in big red letters, but with no explanation of what that means or what to do about it.)

Community guides, discords and this forum have become the lifeblood of helping users set that up. That's good on one hand, but if setting it up for the first time can become such an involved event, why would you ever want to force people to go through that every time for every update, compared to if you can manage your homebrew on console (AIO updater, hb-appstore (hi!)) or with a PC helper tool (HBUpdater).

But that isn’t a switch/homebrew scene problem. That’s someone going in with unrealistic expectations.

It's not unrealistic. Even if the Atmosphere/Switchbrew devs don't want to solve this problem or don't view it as important, they don't have to actively avoid the issue. Why not at least link to one of the guides on Github? Or have a blurb on the releases page, or a README.txt in the zip?

If we look at the Wii U, this isn't a controversial situation. There's an official top-level website: https://tiramisu.foryour.cafe/ that makes it very easy to set up your SD card. It also links right at the top to a community guide. There's also a blog post from the author explaining it in technical detail, as well as explicitly mentioning: "This also allows easy updating, because all you need to do, is replace a file on the sd card." and this is for a persistent, installed (modifies nand) exploit! Updating on console is a requested feature and is at least planned to be worked on.

Looking at the Wii, there's another similar top level page for LetterBomb: https://please.hackmii.com/ as well as an accompanying blog post that again calls attention to ease of use: "will then return a nicely packaged ZIP file that is ready for extraction to the root of your SD card. Simple eh?" Once installed (another nand modifier!) HBC also would check for updates on its own.

So just to reiterate one more time, this is a completely attainable goal, and others in the scene can 100% assist.

In the Switch scene (and possibly 3DS) however, it's much harder to get a foothold to "officially" contribute. There seems to have been a different philosophy from the start. Things are now primarily the user's fault.

There's a crash? You put the files in the wrong place, just put them in the right place. Do you know how to use a computer?

No SD card reader or usb-c cable on you? Get one. What are you doing without one?

Your mod didn't load? You didn't properly name it. You don't know what you're doing, do you?

There's this aftertone of judgement/hostility after some interactions, and I frequently see even big Switch-scene names throwing this stuff around as if it's fine and normal for developers to act like this too. It's not!

You can see what I'm talking about on the Atmosphere Issues page on Github. Good luck if you head in there creating an issue on a problem that turns out to be something that is on your end. Atmosphere's error screen is not that much more useful than Nintendo's to the uninitiated person in terms of debugging a crash.

The PSA in this thread's topic is helpful and useful in that it is based in the current truth that upgrading Atmosphere while it's running will result in unexpected results. That should not extend to defending the view that user-friendly on-console support resources are pointless because users are just gonna "be dumb" anyway.

Excuse the long response, but it's an issue that's close to home for me. I tried to do the best with hb-appstore on Switch/WiiU to make updating stuff on console easy and less frustrating to do. If that stops a few people from having to get up and search for an sd adapter, or save the pain of renaming a folder several times until it has the correct name, then that's great! Mission accomplished!

On WiiU, hb-appstore was endorsed directly by dimok who created the Wii U Homebrew Launcher:

The homebrew app store was really above all. This one looks great and reminds me of the homebrew browser app for the wii. Really nice job there.

But on Switch however, it has been repeatedly portrayed as bad and unnecessary by core AMS devs both publicly and privately, and my suggestions to core components have been either ignored or been deemed unwanted.

There are many other homebrew developers that definitely care about the end to end user experience like this, and I can't speak for them directly, but I have the impression they may be similarly ostracized from having tried to offer constructive criticism or support to Switchbrew/Atmosphere devs. And so the situation continues to be addressable, but those who want to assist are pushed away.

I'd be ecstatic to be wrong about this. Go ahead and feel free to try to make suggestions or PRs to improve the user experience for installing, updating, and using Atmosphere and hbmenu. It will not be as fun as it sounds. And if you do get through, and I'm wrong, then the user experience improves for everyone! But we need to completely refuse the notion that the current situation is as straightforward for the user as it gets.

 

[urherenow]

Atmosphere has a folder titled "Docs" at the top of the main repo page. It contains ALL information that you are complaining about not having/knowing about Atmosphere. Are you seriously complaining that scrolling down to the readme.md doesn't tell you to scroll back up to read the docs?

 

[l7777]

Atmosphere has a folder titled "Docs" at the top of the main repo page. It contains ALL information that you are complaining about not having/knowing about Atmosphere. Are you seriously complaining that scrolling down to the readme.md doesn't tell you to scroll back up to read the docs?

Maybe I'm missing it, but I read the Docs folder and did not see anything about installation or updating process. There is some great info on the inner working of Atmosphere. Once you've done an install or update it is trivial indeed but knowing what is needed to do isn't obvious from the repo.

 

[urherenow]

Maybe I'm missing it, but I read the Docs folder and did not see anything about installation or updating process. There is some great info on the inner working of Atmosphere. Once you've done an install or update it is trivial indeed but knowing what is needed to do isn't obvious from the repo.

It is assumed that anybody with enough brain cells to run CFW, knows how to extract a .zip file. All of those docs explain every option, in every possible .ini file, and where to put them. Whenever there is a change in required settings, it's noted crystal clear in the release notes.

Then again... I did have to create this thread, so... there maybe should be something that mentions that certain files are in use and can't be updated in a running system.

 

[l7777]

It is assumed that anybody with enough brain cells to run CFW, knows how to extract a .zip file. All of those docs explain every option, in every possible .ini file, and where to put them. Whenever there is a change in required settings, it's noted crystal clear in the release notes.

This thread isn't about knowing how to extract a zip or all the settings available. This thread was spawned because the steps needed to install/update Atmosphere are not documented anywhere in the repo. Nearly every piece of software has some kind of instructions on installation/updating even it they are as simple as "Double click setup.exe" or simply "Place the CD in the drive.". If this existed in the docs folder for Atmosphere I suspect this thread would likely not be needed as those of us who did go searching for the instructions would have found them. Those who rely on updaters and AIO packs would have likely still struggled but then you could simply point to the Atmosphere instructions and say "RTFM".

Secondarily, the assumption being operated on is false. There are plenty of people who heard "free games!", purchased an unpatched V1 or had a V2/OLED modded and then don't know what to do with it after. This is not limited to the Switch. Consoles, phones, tablets, etc... all have the same issue when it comes to modding/hacking. The hacks are worked out by some very knowledgeable individuals, publicized, and initially used by people who understand what they are doing. Then someone will try to be helpful and simplify the process for the masses with toolboxes and AIO packs. This leads to a lot of people asking questions because they don't really know what they are doing, they just know that they want the end result. When they can't get it working, they end up asking basic questions. These same people, and even past modders, also don't understand the potential legal trouble that has arisen around piracy and breaking DMCA rules. This necessitates the firm line that must be drawn between homebrew and piracy. For the most part they don't care either, they simply want their games.

 

[vgmoose]

Atmosphere has a folder titled "Docs" at the top of the main repo page. It contains ALL information that you are complaining about not having/knowing about Atmosphere. Are you seriously complaining that scrolling down to the readme.md doesn't tell you to scroll back up to read the docs?

This is technical documentation, not the kind of high level information that you see on the two user-friendly Wii U and Wii hacking setup sites (tiramisu.foryour.cafe, please.hackmii.com) I linked above (ignoring for a moment, that there is no top level atmosphere-specific site). Even the Tiramisu repo tells you the most basic information about where to put the files as an end user: https://github.com/wiiu-env/Tiramisu

And yes! Any docs should be linked in the readme, why is it absurd to suggest that? I took a good long look around the entire repo and release notes before making the claims I did. I've also been in the situation a lot where you end up having to Google and read conflicting forum posts before hopping on a discord to ask where things should go, because the readme basically has nothing useful in it.

Even look at the old wiiu homebrew_launcher repo, compare it to the Switch hbmenu one. Which one is more useful if you are sat staring at the page? The world where the code is the code and the devs are completely hands off is confusing. That creates not only the issue in this thread but others. If the hbmenu isn't going to tell you how to set it up, it could at least explain what's going on with its own Applet Mode messaging.

I just Googled "applet mode switch", which should, as a smart and motivated user, surely be my reaction to seeing "• Applet Mode •" in hbmenu in big red letters. The first result is a piracy subreddit, the second is a gbatemp that explains how to avoid it, but not really why, and then the third link is a piracy tool on github. The first result should be the hbmenu repo! There's a lot of SEO power the hbmenu github repo has, and it's all wasted. SEO optimization and user ease of use isn't as sexy of a problem to solve.

"how to install tiramisu" -> first hit is the official website, second is a gbatemp thread from the author, third is a community guide. Very normal search results for searching for how to install a technical tool.

"how to install atmosphere" -> first three results are ... well what I would consider to be incomplete guides or piracy adjacent guides. The fourth result is the well maintained community NH Switch Guide. Nothing at all from any official atmosphere/hbmenu resources.

I'll repeat this from my earlier post, since you just interpreted it as me complaining with no purpose: These are real, solvable user-accessibility issues that other technical projects and even homebrew ones do attempt to solve and make easier. The readme's can be changed, the docs updated, the top search results can change. The tone of making things easier can be considered a productive and useful things.

When I have personally tried to solve those problems and make things easier, both via my own tools or through conversations, I have been met with hostilities from the maintainers, bans from these repos, rejected ideas, and condescending comments. I've... been in these circles so long that yes, I have received enough flack that I would categorize personal hostilities and condescending remarks separately!

I am not saying that the maintainers are intentionally making it difficult to discover these things based off the repos. It looks like it's a genuine blind spot. User support is messy, and not as clean cut as just providing a technical tool, explaining a bit how it works, and carrying on. But the attitude is the problem that gets in the way of making productive changes. When someone makes an on-console updater, or even suggests a helpful change to the readme layout, the reaction in my experience has been consistently negative. If you think what I'm saying is easily addressable, then it should be easy to address it! In my experience, it's not easy to get a user-accessibility word in edgewise without being marked as an undesirable person. This is a much longer and more involved topic, but once others see that those who try to help / make things less frustrating start to get excluded, they are disincentivized to try to help too, lest they be aligned with those same people and ostracized themselves.

Guide writers, helpful tool makers, and those who do community support should be respected, working with, and talking directly to the main devs with feedback for a healthy ecosystem around an open source platform, not getting shunned, ignored, and/or insulted. If easy AMS updating (for instance, via AIO Updater) works, works well, and is desired by users... why not! What remains for the stance that it needs to be done via a PC? Because the maintainers of AMS already took a hard stance on saying to avoid it? (Also, even this type of statement (of what "not to do") needs to be pieced together via discord replies, github issues, or forum posts).

It is assumed that anybody with enough brain cells to run CFW, knows how to extract a .zip file. All of those docs explain every option, in every possible .ini file, and where to put them. Whenever there is a change in required settings, it's noted crystal clear in the release notes.

Then again... I did have to create this thread, so... there maybe should be something that mentions that certain files are in use and can't be updated in a running system.

I'd also challenge these specific comments. If you are able to arrive on the main docs page (which to be fair, is also accessible by the "Wiki" tab, if you know enough about Github to know to look for that), the "Configurations" link is buried towards the bottom, underneath some info about its AMS's implementation. After clicking that link, and only after that, do we even learn that there is a user-editable config! It hadn't yet been mentioned anywhere else. I don't see how this consists of "every option, in every possible .ini file" either. Comparing the info in these docs to the config templates leaves some keys that are unexplained. Please don't tell that's not a real issue for a technical repo with almost 10,000 stars on Github. There are many other homebrew projects, or even javascript frameworks that are 100x smaller that have more friendly and usable support info for editing config files and starting/updating the code. And they show up on Google!

And I also have to note that in this quote, you're suggesting those confused are stupid for not knowing what to do with an extracted zip file, but you're also conceding that a little helper text does go a long way, at least in the case of knowing not to use FTP or MTP to replace AMS while it is running. So the issue is identified, and now there's a useful gbatemp thread on the matter if a hopeless soul arrives here from Google after trying to debug why their update failed. Who wants to make a PR into the Atmosphere repo? Anybody brave enough? Maybe even just a small one to link the docs/wiki from the readme?

There's a reason that the readme/docs/sites/search results are all disorganized, and the reason is the user support and debugging experience is not a priority, and anyone who thinks it is a priority is shown the door. The number one issue on the AMS Github issue tracker has to do with crashing after updating. Maybe it's time to consider putting a common Q&A like that in the readme? Or on the crash screen itself? Or do anything besides closing the issue, telling the user it's their problem, and locking it. Yeah, from a core development perspective it's much easier just to ignore all that and keep focusing on the product, but if others are willing and can help with small stuff like this, it all adds up and can save users a lot of headaches.

 

[urherenow]

No... writing a 5 billion word rant is what gets you marked as an undesirable person. It takes no "brave enough" person to submit a pull request, and a lot less effort. Why didn't you just do that if you're so passionate about it?

I have no problems with people who write guides. I have problems when the guides include pre-packaged and configured files, leaving the users with no damn clue how to put the pieces together and configure them themselves. And do any of them warn not to update on a live system? No. They don't. They have steps like remove your sd card and copy files from your computer (most that I've seen, anyway). And I'm sure the authors expected those guides to be followed to the letter.

I'll say again: EVERY .ini option is in the Docs. Go ahead and prove me wrong. configurations.md tells you where the templates are and what to do with them. The templates themselves explain every line.

And you're seriously going to complain about which results Google turns up? As if anybody here controls Google or its algorithms?

Don't tell me what the thread is for, because I created the damn thing. You're welcome.

Create your own thread if you'd like to rant.

 

[The_Chaotician]

I really dont get why @Homlet s AIO Updater Homebrew gets bashed at every opportunity when a thread like this is made.

I've used it since it came out on my Erista switch with no problems whatsoever. If it only works for this model and not Mariko and Aula, then you'll need another option. You dont need a degree in rocket science.

 

[l7777]

I really dont get why @Homlet s AIO Updater Homebrew gets bashed at every opportunity when a thread like this is made.

This is a simple answer. They increase the number of people that ask for support from the team responsible for the actual software (in this case Atmosphere) rather than the creator/maintainer of the pack or updater.

Secondarily they make it more difficult for people to find out what actually needs to be done as the responses to technical questions are usually, "I use the XXXX pack." or "Just use the XXXX updater tool.".

Don't get me wrong, these packs and updaters are filling a knowledge gap, but when it doesn't work the support is then more difficult. There would be merit for the Atmosphere team to create a self update functionality as it would likely reduce their support requests when updates are released but that takes away dev time from working on actual functionality.

Personally as a more technical individual I prefer to know exactly what things are doing and where they go rather than relying on a third party to know this and do it for me. @urherenow make a good point noting that the updaters and packs usually wipe out any configuration changes that may have been made by the users as well.

I suppose the TLDR is this: Developers want people to educate themselves and know what they are doing each step of the way thus eliminating support requests, end users want an easy button.

 

[urherenow]

@urherenow make a good point noting that the updaters and packs usually wipe out any configuration changes that may have been made by the users as well.

To be fair, the AIO updater gives you the option to NOT touch .ini files. I really like the app, but does create issues when noobs don't learn the config and options themselves first. I would rather the inclusion of any .ini file at all would be left out as an option altogether. If not running into real issues, it leads to "bright ideas" that are already actually a thing... if the user knew about the options in the first place.

 

[The_Chaotician]

This is a simple answer. They increase the number of people that ask for support from the team responsible for the actual software (in this case Atmosphere) rather than the creator/maintainer of the pack or updater.

Secondarily they make it more difficult for people to find out what actually needs to be done as the responses to technical questions are usually, "I use the XXXX pack." or "Just use the XXXX updater tool.".

Don't get me wrong, these packs and updaters are filling a knowledge gap, but when it doesn't work the support is then more difficult. There would be merit for the Atmosphere team to create a self update functionality as it would likely reduce their support requests when updates are released but that takes away dev time from working on actual functionality.

Personally as a more technical individual I prefer to know exactly what things are doing and where they go rather than relying on a third party to know this and do it for me. @urherenow make a good point noting that the updaters and packs usually wipe out any configuration changes that may have been made by the users as well.

I suppose the TLDR is this: Developers want people to educate themselves and know what they are doing each step of the way thus eliminating support requests, end users want an easy button.

Thank you for the balanced response.

Similarly as a technically minded individual its easy to ignore the needs of less technically minded people I guess. I agree with the notion of Atmosphere having its own updater - it makes a lot of sense in this regard.

 

[vgmoose]

No... writing a 5 billion word rant is what gets you marked as an undesirable person. It takes no "brave enough" person to submit a pull request, and a lot less effort. Why didn't you just do that if you're so passionate about it?

I'm undesired by Switch CFW maintainers but well-respected by Wii U ones. I make my own tools and give feedback where I can, and from AMS/Switchbrew I've had my ideas and contributions rejected. If I could do anything more about it, besides speak on it from my perspective, I would.

hb-appstore has a huge user-base and a large number of daily downloads (~4TB/month of downloads), and I had repeatedly offered to Switchbrew devs that they could utilize these users if they need to streamline cfw updates or feedback systems (think, crash reports opt-in to be uploaded, like on PC). It's a suggestion met with hostility.

It's very impressive and respectable how AIO-Switch-Updater accomplishes what it does, given how the on-console use case is often treated. This project or components of it could become the base for an official on-console updating solution, distributed by AMS. Why not?

And you're seriously going to complain about which results Google turns up? As if anybody here controls Google or its algorithms?

Google is every user's literal first stop when they want to debug an issue. It is a good goal to improve that experience. We should agree on this. One way to help the Google algorithm identify which pages are useful for a "how to install atmosphere" query is by, say, being a 10k starred repo on Github named Atmosphere and putting in the readme: "# How to Install". I already mentioned, Wii and Wii U scenes don't have the same issue. It's doable.

Another easy way is to be a highly trafficked top-level domain, like please.hackmii.com or tiramisu.foryour.cafe. More examples are projects like yuzu-emu.org and ryujinx.org which have great SEO/docs as well.

I'll say again: EVERY .ini option is in the Docs. Go ahead and prove me wrong. configurations.md tells you where the templates are and what to do with them. The templates themselves explain every line.

That's not what you said the first time though, the first time you wrote: "It contains ALL information that you are complaining about not having/knowing about Atmosphere." It completely does not.

I'm the one that pointed out that the config_templates are really doing the heavy lifting of describing the parameters, not the docs. But this is a tangent from my main argument which is: 1. those docs are tucked away, and 2. are still only about the editable config, not the install/update of AMS itself. Ini templates aren't technically docs, but I agree that those templates are very usable, if you're familiar with editing files for configs.

Don't tell me what the thread is for, because I created the damn thing. You're welcome.

Create your own thread if you'd like to rant.

The entire point of my posts here is that it's not pointless to have higher installing/updating standards for users. This thread, whether intended by you or not, clears up some confusion about how to update atmosphere, which is not described anywhere by any atmosphere dev. That's bad. The fact remains that those kinds of enhancements are not reciprocated. Would love to be proven wrong.

 

[RednaxelaNnamtra]

I largely agree with @CompSciOrBust , the Wii was explicitly made extremely simple, and Switch setup is comparatively harder. What are the official resources for installing or updating Atmosphere? Well there's the Github repo. Are there instructions in the readme or on the releases page? No.

The release zips do contain all the barebones resources that you do need to copy to SD root in one zip, and usually that can just be straight copied over (which already is no trivial feat, so it does show that intentional dev work has gone into making those files easy to copy, which is great!). However there isn't so much of a mention of any SD card root anywhere. That is left as an exercise to the reader. It's not trivial to explain that to someone who barely knows what a file explorer is!

And then there's even less of a mention of RCM, the ways to enter it, different exploits, how to update it in the future, how to use title override (hbmenu will helpfully display "- Applet Mode -" in big red letters, but with no explanation of what that means or what to do about it.)

Community guides, discords and this forum have become the lifeblood of helping users set that up. That's good on one hand, but if setting it up for the first time can become such an involved event, why would you ever want to force people to go through that every time for every update, compared to if you can manage your homebrew on console (AIO updater, hb-appstore (hi!)) or with a PC helper tool (HBUpdater).



It's not unrealistic. Even if the Atmosphere/Switchbrew devs don't want to solve this problem or don't view it as important, they don't have to actively avoid the issue. Why not at least link to one of the guides on Github? Or have a blurb on the releases page, or a README.txt in the zip?

If we look at the Wii U, this isn't a controversial situation. There's an official top-level website: https://tiramisu.foryour.cafe/ that makes it very easy to set up your SD card. It also links right at the top to a community guide. There's also a blog post from the author explaining it in technical detail, as well as explicitly mentioning: "This also allows easy updating, because all you need to do, is replace a file on the sd card." and this is for a persistent, installed (modifies nand) exploit! Updating on console is a requested feature and is at least planned to be worked on.

Looking at the Wii, there's another similar top level page for LetterBomb: https://please.hackmii.com/ as well as an accompanying blog post that again calls attention to ease of use: "will then return a nicely packaged ZIP file that is ready for extraction to the root of your SD card. Simple eh?" Once installed (another nand modifier!) HBC also would check for updates on its own.

So just to reiterate one more time, this is a completely attainable goal, and others in the scene can 100% assist.

In the Switch scene (and possibly 3DS) however, it's much harder to get a foothold to "officially" contribute. There seems to have been a different philosophy from the start. Things are now primarily the user's fault.

There's a crash? You put the files in the wrong place, just put them in the right place. Do you know how to use a computer?

No SD card reader or usb-c cable on you? Get one. What are you doing without one?

Your mod didn't load? You didn't properly name it. You don't know what you're doing, do you?

There's this aftertone of judgement/hostility after some interactions, and I frequently see even big Switch-scene names throwing this stuff around as if it's fine and normal for developers to act like this too. It's not!

You can see what I'm talking about on the Atmosphere Issues page on Github. Good luck if you head in there creating an issue on a problem that turns out to be something that is on your end. Atmosphere's error screen is not that much more useful than Nintendo's to the uninitiated person in terms of debugging a crash.

The PSA in this thread's topic is helpful and useful in that it is based in the current truth that upgrading Atmosphere while it's running will result in unexpected results. That should not extend to defending the view that user-friendly on-console support resources are pointless because users are just gonna "be dumb" anyway.

Excuse the long response, but it's an issue that's close to home for me. I tried to do the best with hb-appstore on Switch/WiiU to make updating stuff on console easy and less frustrating to do. If that stops a few people from having to get up and search for an sd adapter, or save the pain of renaming a folder several times until it has the correct name, then that's great! Mission accomplished!

On WiiU, hb-appstore was endorsed directly by dimok who created the Wii U Homebrew Launcher:


But on Switch however, it has been repeatedly portrayed as bad and unnecessary by core AMS devs both publicly and privately, and my suggestions to core components have been either ignored or been deemed unwanted.

There are many other homebrew developers that definitely care about the end to end user experience like this, and I can't speak for them directly, but I have the impression they may be similarly ostracized from having tried to offer constructive criticism or support to Switchbrew/Atmosphere devs. And so the situation continues to be addressable, but those who want to assist are pushed away.

I'd be ecstatic to be wrong about this. Go ahead and feel free to try to make suggestions or PRs to improve the user experience for installing, updating, and using Atmosphere and hbmenu. It will not be as fun as it sounds. And if you do get through, and I'm wrong, then the user experience improves for everyone! But we need to completely refuse the notion that the current situation is as straightforward for the user as it gets.

I kinda don't like the comparrison against things like the letterbomb page, which is the exploit not the Homebrew launcher/CFW, and in itself is also not a full package for most people, most people probably also installed cios and more, and probably used another guide for that, or used a guide to even find the letterbomb page.
The 3DS also had a page like this for Ninjhax, which is even more helpfull then the letterbomb page, which also only explains the main part, and not everything most people will probably do.
These releases also have in common that they where long planned releases, while for the switch the RCM exploits release was kinda rushed after the leak, und the modchips where part of a CFW package, so it fully targeted that, while the other modchips don't seem to explain much either.

I also don't think the single parts of a modding setup all need to explain every funtion in a way everyone can understand it without at least some base knowledge on the topic. This is something the guides and packages should do, since they cater to the general audience and are done by people with much more interest in these kind of documentations, allowing them to do a much better job. Its also what I will direct people to when they tell me they want to mod something, and I'm not able to help them in them moment (otherwise I try to guide them through the steps myself).

Another thing I think is good advice, is to always have a fallback in case an update breaks somethign. So if you use an automatic tool to update your switch thats nice and compftable, but don't do it in a situation where you cant get to a pc or phone, unless you are ok to not be able to use the device in the worst case.
The homebrew appstore is also nice, and a standart part of most the cfw setups I help with, though not that much used most of the time, and it's important for people to also know how to manually get apps on the device or remove them from it.

 

[SciresM]

The release zips do contain all the barebones resources that you do need to copy to SD root in one zip, and usually that can just be straight copied over (which already is no trivial feat, so it does show that intentional dev work has gone into making those files easy to copy, which is great!). However there isn't so much of a mention of any SD card root anywhere. That is left as an exercise to the reader. It's not trivial to explain that to someone who barely knows what a file explorer is!

Atmosphere's installation is "extract a zip to the SD card". The update process is "extract the new zip to the sd card". All issues arise from people extending Atmosphere, and those extensions' updates not remaining synchronized with Atmosphere itself. It is my honest belief that this installation process cannot actually be made simpler, modulo the constraints that I operate under. More in the next response.

And then there's even less of a mention of RCM, the ways to enter it, different exploits, how to update it in the future, how to use title override (hbmenu will helpfully display "- Applet Mode -" in big red letters, but with no explanation of what that means or what to do about it.)

I cannot and do not provide RCM or exploit instructions. This is for legal reasons -- it is critically important for reasons of legal liability that Atmosphere does not provide exploits of any kind, including avoiding instructions on how to do so to the greatest extent reasonable.

This is particularly egregious on Mariko, which is supported "if you have some way of running fusee from bootloader context". But such a mechanism is not provided and I am legally not allowed to provide assistance.

Atmosphere is largely a reimplementation project; its nature as this means that I must be especially careful about what it does and doesn't provide.

It's not unrealistic. Even if the Atmosphere/Switchbrew devs don't want to solve this problem or don't view it as important, they don't have to actively avoid the issue. Why not at least link to one of the guides on Github? Or have a blurb on the releases page, or a README.txt in the zip?

Reasons relating to legal liability, as above.

So just to reiterate one more time, this is a completely attainable goal, and others in the scene can 100% assist.

I am pretty sure that people have made guides/sites to simplify the process already, have they not? There can never be an official one, but I am told they exist.

You can see what I'm talking about on the Atmosphere Issues page on Github. Good luck if you head in there creating an issue on a problem that turns out to be something that is on your end. Atmosphere's error screen is not that much more useful than Nintendo's to the uninitiated person in terms of debugging a crash.

The issue tracker is for bugs; it is not intended for support. When you go to make an issue, you are presented with a choice of "bug", "feature request", and "question/support". When you click on question/support, you get told to go on Discord. It is my expectation that technically oriented users will join ReSwitched, where I dutifully attempt to provide assistance to people. I expect non-technically oriented users will join Nintendo Homebrew, which I am not in but I know has several support channels.

Also, the error screen is not intended for the user. It is intended to provide maximum information to me -- with a screenshot of the atmosphere fatal screen or the report generated on a true-fatal error, I can diagnose and fix 95% of bugs without needing a reliable reproduction methodology.

This works as intended, in practice.

That should not extend to defending the view that user-friendly on-console support resources are pointless because users are just gonna "be dumb" anyway.

My issue with on-console updating is that it is the operation singularly most likely to lead to SD card corruption, given Nintendo's drivers.

The very worst case scenario to maximize the chance of corruption is to write to the SD card FAT and then reboot.

In addition, the file system in HOS provides no way to atomically perform an update operation. If something happens in the middle (including "the user has a custom theme so modifying the contents folder may return ResultTargetLocked at random").

Attempting to update from within HOS is for technical reasons a really bad idea. I restrict it to prevent avoidable SD card corruption (and ensuing reports).

When someone makes an on-console updater, or even suggests a helpful change to the readme layout, the reaction in my experience has been consistently negative.

Homlet reached out to me about how to do the on-device updating thing without doing so in HOS.

I suggested the reboot-to-RCM and do-it-via-payload approach, and provided technical advice to people asking about it on several occasions.

I don't use his thing, but I believe he did so and I have no true objection to this.

I don't think "provide a suggestion for a technical way to solve the problem and provide technical guidance when requested" is negative.

I do grant that my response to on-device updates from within HOS is negative, yes, because that's a terrible idea for the technical reasons above.

It's very impressive and respectable how AIO-Switch-Updater accomplishes what it does, given how the on-console use case is often treated. This project or components of it could become the base for an official on-console updating solution, distributed by AMS. Why not?

We're pretty much out of code space for fusee. It would have to be a separate program due to technical code size constraints on IRAM availability.

Given it *already has to be a separate program* and that I'm not especially interested in maintaining a codebase I haven't authored, official integration isn't exactly in the cards.

Another notable issue is that Atmosphere doesn't have userland networking support, and http is not a part of nnSdk I'm comfortable enough with to reimplement; this would be a fairly large reverse engineering + forward engineering task.

One way to help the Google algorithm identify which pages are useful for a "how to install atmosphere" query is by, say, being a 10k starred repo on Github named Atmosphere and putting in the readme: "# How to Install". I already mentioned, Wii and Wii U scenes don't have the same issue. It's doable.

I would observe once more that Atmosphere is a direct reimplementation project where those ecosystems were not, and further my personal tolerance for legal liability is likely much lower than the people who were making those decisions.

This really is a legal liability thing. Atmosphere does not/will never provide exploits/instructions on how to run Atmosphere on device. I make the assumption that the user has bypassed whatever TPMs necessary via means not related to Atmosphere, and Atmosphere works in the aftermath of that.

In the absence of instructions on how to run Atmosphere, I am not actually convinced adding the words "Atmosphere zips should be extracted to the root of the SD card; if you have previously customized your Atmosphere installation, you may need to first delete the "atmosphere" directory on the SD card before extracting and re-install the latest versions of your customizations after extracting" to the release notes is of benefit to any real person.

To wit, I would observe that since adding

Please be sure to update fusee when upgrading to 1.3.2. fusee-primary no longer exists, and will not work any more.

to Atmosphere's release notes, I still regularly receive reports from people who have not updated fusee and are continuing to use fusee-primary.

 

[The_Chaotician]

Atmosphere's installation is "extract a zip to the SD card". The update process is "extract the new zip to the sd card". All issues arise from people extending Atmosphere, and those extensions' updates not remaining synchronized with Atmosphere itself. It is my honest belief that this installation process cannot actually be made simpler, modulo the constraints that I operate under. More in the next response.



I cannot and do not provide RCM or exploit instructions. This is for legal reasons -- it is critically important for reasons of legal liability that Atmosphere does not provide exploits of any kind, including avoiding instructions on how to do so to the greatest extent reasonable.

This is particularly egregious on Mariko, which is supported "if you have some way of running fusee from bootloader context". But such a mechanism is not provided and I am legally not allowed to provide assistance.

Atmosphere is largely a reimplementation project; its nature as this means that I must be especially careful about what it does and doesn't provide.



Reasons relating to legal liability, as above.



I am pretty sure that people have made guides/sites to simplify the process already, have they not? There can never be an official one, but I am told they exist.



The issue tracker is for bugs; it is not intended for support. When you go to make an issue, you are presented with a choice of "bug", "feature request", and "question/support". When you click on question/support, you get told to go on Discord. It is my expectation that technically oriented users will join ReSwitched, where I dutifully attempt to provide assistance to people. I expect non-technically oriented users will join Nintendo Homebrew, which I am not in but I know has several support channels.

Also, the error screen is not intended for the user. It is intended to provide maximum information to me -- with a screenshot of the atmosphere fatal screen or the report generated on a true-fatal error, I can diagnose and fix 95% of bugs without needing a reliable reproduction methodology.

This works as intended, in practice.



My issue with on-console updating is that it is the operation singularly most likely to lead to SD card corruption, given Nintendo's drivers.

The very worst case scenario to maximize the chance of corruption is to write to the SD card FAT and then reboot.

In addition, the file system in HOS provides no way to atomically perform an update operation. If something happens in the middle (including "the user has a custom theme so modifying the contents folder may return ResultTargetLocked at random").

Attempting to update from within HOS is for technical reasons a really bad idea. I restrict it to prevent avoidable SD card corruption (and ensuing reports).




Homlet reached out to me about how to do the on-device updating thing without doing so in HOS.

I suggested the reboot-to-RCM and do-it-via-payload approach, and provided technical advice to people asking about it on several occasions.

I don't use his thing, but I believe he did so and I have no true objection to this.

I don't think "provide a suggestion for a technical way to solve the problem and provide technical guidance when requested" is negative.

I do grant that my response to on-device updates from within HOS is negative, yes, because that's a terrible idea for the technical reasons above.



We're pretty much out of code space for fusee. It would have to be a separate program due to technical code size constraints on IRAM availability.

Given it *already has to be a separate program* and that I'm not especially interested in maintaining a codebase I haven't authored, official integration isn't exactly in the cards.

Another notable issue is that Atmosphere doesn't have userland networking support, and http is not a part of nnSdk I'm comfortable enough with to reimplement; this would be a fairly large reverse engineering + forward engineering task.



I would observe once more that Atmosphere is a direct reimplementation project where those ecosystems were not, and further my personal tolerance for legal liability is likely much lower than the people who were making those decisions.

This really is a legal liability thing. Atmosphere does not/will never provide exploits/instructions on how to run Atmosphere on device. I make the assumption that the user has bypassed whatever TPMs necessary via means not related to Atmosphere, and Atmosphere works in the aftermath of that.

In the absence of instructions on how to run Atmosphere, I am not actually convinced adding the words "Atmosphere zips should be extracted to the root of the SD card; if you have previously customized your Atmosphere installation, you may need to first delete the "atmosphere" directory on the SD card before extracting and re-install the latest versions of your customizations after extracting" to the release notes is of benefit to any real person.

To wit, I would observe that since adding

Please be sure to update fusee when upgrading to 1.3.2. fusee-primary no longer exists, and will not work any more.

to Atmosphere's release notes, I still regularly receive reports from people who have not updated fusee and are continuing to use fusee-primary.

Quick question, and pardon my ignorance, but why does it appear that the same legality issues are not a problem for other systems (3DS, WiiU)? Admittedly I have no experience with WiiU exploits, hence my caution in asking.

Is it simply a choice you have made on the grounds of compliance with the law that other developers have chosen not to?

 

[SciresM]

Quick question, and pardon my ignorance, but why does it appear that the same legality issues are not a problem for other systems (3DS, WiiU)? Admittedly I have no experience with WiiU exploits, hence my caution in asking.

Is it simply a choice you have made on the grounds of compliance with the law that other developers have chosen not to?

Atmosphere is a reimplementation project -- unlike previous custom firmwares, it aims to as often as possible directly reimplement of Nintendo's code instead of patching it.

This means I stand on shakier ground and tread on thinner ice.

In addition, yes, I believe my personal tolerance for liability risk is lower than previous projects' developers, particularly in recent years.

 

[The_Chaotician]

Atmosphere is a reimplementation project -- unlike previous custom firmwares, it aims to as often as possible directly reimplement of Nintendo's code instead of patching it.

This means I stand on shakier ground and tread on thinner ice.

In addition, yes, I believe my personal tolerance for liability risk is lower than previous projects' developers, particularly in recent years.

Thanks. For the response and your effort.

You don’t get a fraction of the credit you deserve for the latter, in my opinion.

 

[vgmoose]

@SciresM Your response is overwhelmingly illuminating and fair. I don't have anything significant to add-on or follow-up with to it. The explanation makes perfect sense. Thank you for laying it out and taking the time to respond.

 

[l7777]

Atmosphere is a reimplementation project -- unlike previous custom firmwares, it aims to as often as possible directly reimplement of Nintendo's code instead of patching it.

This means I stand on shakier ground and tread on thinner ice.

In addition, yes, I believe my personal tolerance for liability risk is lower than previous projects' developers, particularly in recent years.

IANAL but IMO TX's attempt to profiteer from their CFW is what gained them the unwanted attention from Nintendo. That said, you are bearing the risk for all of us so I don't believe you're out of line taking the path you have chosen. Thank you for the hard work and tolerating the uninitiated.