Hello everyone, Luma3DS (v10.3) came out today, as usual I examined the changelog as anyone should and noticed something concerning to me. If you read the third bulleted entry of changes, you'll see this.
"...Also, even if 3ds.hacks.guide recommends it and GodMode9 mandates it, time offset nullification should not be done"
While I do know some aspects of the 3DS and how it works, I will not claim to be an expert when it comes to the entire aspect of the NAND or its general data that sits within it. I have a question and I have a piece to say on the matter.
Question:
I actually have a couple systems I set up a few years ago, the guide at that time pointed to this software (ctr-no-timeoffset), obviously it was used, the question is can this be reversed or is this a permanent change to the NAND (assuming the offset is located in the NAND based on some small research)? I wasn't as intelligent as I am currently a few years ago, now that I have a better understanding of what is being messed with here, I don't exactly find this to be a very good result after having to use what the guide told me to do years ago.
My Piece:
While I am not pointing fingers or calling any sort of developer names over this, and while I don't really think this is a huge issue (could be wrong because again I am no expert about the entirety of NAND data), I do have to say I find this kind of unprofessional. The fact that everyone is told to follow a certain guide religiously, only to be told by another homebrew developer that there is a certain thing(s) you should NOT do when following the guide, or because certain homebrew applications want you to, seems to make me question the integrity of the homebrew scene as a whole just a bit. The idea that many users are expected to put trust in groups like these, told to do things a certain way, only to find out that an aspect of that should NOT be done is a major let down, because who's to say there isn't something else that shouldn't be done but we inadvertently do it anyways and more than likely not know about it, and what if some of these changes are permanent? GodMode9 for example writes directly into the NAND whenever you perform an essentials backup (though it is a one time thing), and the only way to remove that from the NAND is to directly write into the NAND to pad it out, or restore a NAND backup that has the data removed, what's worse about this though is you have to do a full SysNAND restore after manually padding the data out in the backup just so that removal actually gets applied, because a safe restore doesn't write the NAND backup to that area of the NAND, which means the essentials data will still persist. I get told often that the NAND shouldn't be written to, or that it's dangerous to write to it, or that the NAND will die the more you write to it, yet in the same breath we AVOID all of those things said and do it anyways, majority of cases it's to the point where even EmuNAND isn't encouraged, when that quite literally is one the best solutions for homebrew related reasons, to preserve your SysNAND. Most people aren't even aware of what they are sticking on their systems, and while true all the data is open source, that doesn't explain what's happening in a way that everyone understands. As a good developer, you should be responsible enough to know what should and shouldn't be done with the systems you are messing with, you should also consider the fact that YOUR solution is going out to the mass population of people of the world, which means you should be ensuring that your stuff works and isn't doing anything it probably shouldn't. NO nothing will ever be perfect, that's not expected, but what is expected is a sense of professional care and treatment with the work you do to ensure that people never have to wonder about situations like this, or question whether or not our data is completely screwed in some way, big or small, because someone wasn't thinking correctly. To be blunt, shit needs to be handled more appropriately, because we don't need a future where people are doing all sorts of wacky stuff to their systems, only for their system data to be gambled upon like this, because this could get worse if we don't play our cards correctly with future applications or tools. Again, I am not pointing fingers, calling anyone names, I feel like this is a situation that can be easily fixed (again I could be wrong, reason already stated earlier).
Homebrew can be very fascinating when handled correctly, if we want to keep our systems around for years to come, then we need to take the right measures to make sure that happens, no matter how big or small the matter is. This stuff doesn't last forever, so we need to make the best of it the right way.
I hope nobody takes what I am saying to heart, because that isn't my goal.
Huge misunderstanding on my part, move along.
The particular line in question is the following:Split NTP and user time offset nullification. This means two things:
- Time changes are immmediately visible and you do not need to reboot your console after using the feature anymore (although Home Menu might not always immmediately display the new time -- just open and close an application in that case)
- Programs like ctr-no-timeoffset should not be needed anymore. Also, even if 3ds.hacks.guide recommends it and GodMode9 mandates it, time offset nullification should not be done
- Programs like ctr-no-timeoffset should not be needed anymore. Also, even if 3ds.hacks.guide recommends it and GodMode9 mandates it, time offset nullification should not be done
While I do know some aspects of the 3DS and how it works, I will not claim to be an expert when it comes to the entire aspect of the NAND or its general data that sits within it. I have a question and I have a piece to say on the matter.
Question:
I actually have a couple systems I set up a few years ago, the guide at that time pointed to this software (ctr-no-timeoffset), obviously it was used, the question is can this be reversed or is this a permanent change to the NAND (assuming the offset is located in the NAND based on some small research)? I wasn't as intelligent as I am currently a few years ago, now that I have a better understanding of what is being messed with here, I don't exactly find this to be a very good result after having to use what the guide told me to do years ago.
My Piece:
While I am not pointing fingers or calling any sort of developer names over this, and while I don't really think this is a huge issue (could be wrong because again I am no expert about the entirety of NAND data), I do have to say I find this kind of unprofessional. The fact that everyone is told to follow a certain guide religiously, only to be told by another homebrew developer that there is a certain thing(s) you should NOT do when following the guide, or because certain homebrew applications want you to, seems to make me question the integrity of the homebrew scene as a whole just a bit. The idea that many users are expected to put trust in groups like these, told to do things a certain way, only to find out that an aspect of that should NOT be done is a major let down, because who's to say there isn't something else that shouldn't be done but we inadvertently do it anyways and more than likely not know about it, and what if some of these changes are permanent? GodMode9 for example writes directly into the NAND whenever you perform an essentials backup (though it is a one time thing), and the only way to remove that from the NAND is to directly write into the NAND to pad it out, or restore a NAND backup that has the data removed, what's worse about this though is you have to do a full SysNAND restore after manually padding the data out in the backup just so that removal actually gets applied, because a safe restore doesn't write the NAND backup to that area of the NAND, which means the essentials data will still persist. I get told often that the NAND shouldn't be written to, or that it's dangerous to write to it, or that the NAND will die the more you write to it, yet in the same breath we AVOID all of those things said and do it anyways, majority of cases it's to the point where even EmuNAND isn't encouraged, when that quite literally is one the best solutions for homebrew related reasons, to preserve your SysNAND. Most people aren't even aware of what they are sticking on their systems, and while true all the data is open source, that doesn't explain what's happening in a way that everyone understands. As a good developer, you should be responsible enough to know what should and shouldn't be done with the systems you are messing with, you should also consider the fact that YOUR solution is going out to the mass population of people of the world, which means you should be ensuring that your stuff works and isn't doing anything it probably shouldn't. NO nothing will ever be perfect, that's not expected, but what is expected is a sense of professional care and treatment with the work you do to ensure that people never have to wonder about situations like this, or question whether or not our data is completely screwed in some way, big or small, because someone wasn't thinking correctly. To be blunt, shit needs to be handled more appropriately, because we don't need a future where people are doing all sorts of wacky stuff to their systems, only for their system data to be gambled upon like this, because this could get worse if we don't play our cards correctly with future applications or tools. Again, I am not pointing fingers, calling anyone names, I feel like this is a situation that can be easily fixed (again I could be wrong, reason already stated earlier).
Homebrew can be very fascinating when handled correctly, if we want to keep our systems around for years to come, then we need to take the right measures to make sure that happens, no matter how big or small the matter is. This stuff doesn't last forever, so we need to make the best of it the right way.
I hope nobody takes what I am saying to heart, because that isn't my goal.
Huge misunderstanding on my part, move along.
Last edited by DeadSkullzJr,