I agree for the most part, but also think that you can be glad Atlas is dead without wishing ill on anyone. as in being glad that the devs are sticking with the choices that they want to make.
1. Kosmos had something to do with fss0= style booting it BECAUSE they had that as the default configuration when there was no need to have it set up that way. They could have used the payload= syntax some of the time.Fss0 is still a part of hekate and atmosphere, kosmos had nothing to do with that besides having that as the default configuration. Which is absolutely fine btw, why would it be better off unused? It's perfect for using the featureset that hekate actually has together with Atmosphere, both benefit greatly from that. It is not a hack whatsoever.
1. Well it has to be set up that way if you want sysnand and emunand boot as seperate entities (which is very handy btw)1. Kosmos had something to do with fss0= style booting it BECAUSE they had that as the default configuration when there was no need to have it set up that way. They could have used the payload= syntax some of the time.
2. It is better off unused with newer versions of Atmosphere because it complicates the loading of patches. With payload= syntax, all the patches and kips load automatically.
3. fss0= style admosphere loading is not perfect for people who wanted to load patches without ideological BS for why they don't need this or that patch. Kosmos stopped bundling any patches with their configs, they never included acid, which makes Kosmos style booting "broken out-of-the box" for many users. The reasons they didn't include patches and the counter arguments are ideological BS which 99% people do not give a damn about.
4. You KNOW it is a hack because fss0= style loading works by manually extracting modules from fusee-secondary.bin and then loading them. This meant that hekate had to be updated every time atmosphere changed stuff. There was no need for this if they were fully independent (as they are with payload= style booting) because hekate was basically hacking fusee-secondary.bin to load atmosphere in an unsupported way. Go ask ReSwitched if they support fss0= style booting if you have any doubts. This is also why the patch/kip patches loading was not automatic, because they were not applied when hekate extracts out the modules to process and then boot.
You said yourself that kosmos could've had used payload= only some of the time, so there is no doubt that fss0 booting is more versitile and allows for much finer control and configuration of Atmosphere, all bundled within multiple configuration options a tap away. Why anyone would consider this a con is beyond me.
but it was a convenient zip folderto the average user who just wants to play video games and doesn't give a shit about """"configurations"""" or """"features"""" its a mess that just serves to confuse the enduser for no reason
kosmos is, and always has been, a glorified zip file used to dumb down the general userbase and im all for it dying, regardless of my 'allegiances'.
donate to my patreon and we'll talkbut it was a convenient zip folder
now who will zip all my files for me? I'm taking applications
now who will zip all my files for me? I'm taking applications
See #1.ss0 booting is more versitile and allows for much finer control and configuration of Atmosphere, all bundled within multiple configuration options a tap away. Why anyone would consider this a con is beyond me.
Well, I disagree. It's not the fault of hekate/CTCaer that blawar decided to block certain patches. If anything, it is his fault, and his fault alone. Would it be better if hekate used the same patching system Atmos does? Arguably yes, but nonetheless it's working exactly as intended just as well as the atmos system.1. Incorrect. For the emuMCC entry, it could be set up as payload= and have the same functionality. Only the sysnand CFW entry needed the fss0= syntax. The emuMMC CFW entry never did.
2. Except that there is no reason to disable them, especially with emuMMC CFW, and most people just wanted them to always load and everything to just work "out of the box". Thus fss0= style booting is best off unused most of the time, and absolutely should not be the default setting.
3. True, except when it is false, which it is for a certain piece of very important software that implements CSE when it detects Haruko's patches.ini. Again, people do not care about ideological about why this or that doesn't work or why they shouldn't be using that piece of software. With "payload=" syntax everything works, which (unfairly) but nonetheless does mean that "fss0=" style booting is needlessly complicated for people.
4. Atmosphere doesn't support fss0= style booting, only Hekate does which is why it is a hack, because Atmosphere does not natively support it. The part where hekate needs to get updated to use that "fss0=" syntax (but not for payload= syntax) is a litmus test for why "fss0=" style booting a hack. There is nothing wrong with it being a hack in and of itself, but it is a hack: an way of obtaining functionality that the software program was never intended to have.
See #1.
It is a con because it does not need to be used for that boot entry. payload= syntax would not change the behavior of that boot entry and using fss0= for the "CFW EMUMMC" boot entry needlessly complicates loading of patches for that boot entry.
That boot entry is also the one that everyone was basically always trying to use so it was the de-facto "default" boot entry. Team Atlas had no technical need to break things by including fss0= style booting in that boot entry and yet they did so anyway.
I do agree with you that Team Atlas did a lot of positive things for the scene, especially for new users, but using that "fss0=" style booting instead of "payload=" for that boot entry did a lot of harm. In terms of how the technology works, the scene will benefit from being united now compared to before because the principle entity that supported that technologically inferior way to boot atmosphere in an emuMMC CFW configuration (primary one for many people) will be dropping its support for it.
Hopefully that will lesson the need for 2 different sets of patches needing to be maintained going forward.
Does that mean someone is devoloping a hekate fork with Atmos patching system?View attachment 208826
@tom2199
--------------------- MERGED ---------------------------
since you seem so concerned about hekate patches blocking
1. Well it has to be set up that way if you want sysnand and emunand boot as seperate entities (which is very handy btw)
Oh thats nice. Props @blawar@tom2199 no,it means blawar WILL be removing thoses blocks for hekate
View attachment 208826
@tom2199
--------------------- MERGED ---------------------------
since you seem so concerned about hekate patches blocking