A Question and Something to Say

[DeadSkullzJr]

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.

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

The particular line in question is the following:

• 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

"...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.

 

[impeeza]

man you really got that out of your chest took me a while to read all, but I am on the same thinking of you for some points.

But think on the scene as something live, some things are valid and then changes are made to the general picture and then render no valid anymore.

By example, on Wii you can't use EmuNAND at first but some years later was essential. Initially on Switch a file EmuNAND was bad Idea, today make no difference between file or partition EmuNAND. On the 3DS, A9LH and B9B differences and needs to migrate, etc.

The guides need to be updated to that changes, and sometimes egos get involved but all changes. remember the recent beef between tinfoil and hekate.

 

[Kwyjor]

A Question and Something to Say

Holy cow, dude. If you wanted to complain about the Luma 10.3 changelog, don't you think you could have come up with a better subject line!?

If you want professional, unified documentation and development, then you should probably steer clear of homebrew, period. I daresay this is nothing compared to what has turned up in Linux development over the years.

I have some vague understanding that the reason the blank-screen bug persisted for so long is that the devs wanted to encourage people to use fastboot instead of b9s, but that never caught on.

(I agree that I have no idea why the essentials backup should be written to the NAND. It obviously has a place in a NAND backup, but it could just as easily be included in the backup itself when the backup is created, instead of writing it to the NAND directly.)

 

[DeadSkullzJr]

Holy cow, dude. If you wanted to complain about the Luma 10.3 changelog, don't you think you could have come up with a better subject line!?

If you want professional, unified documentation and development, then you should probably steer clear of homebrew, period. I daresay this is nothing compared to what has turned up in Linux development over the years.

I have some vague understanding that the reason the blank-screen bug persisted for so long is that the devs wanted to encourage people to use fastboot instead of b9s, but that never caught on.

(I agree that I have no idea why the essentials backup should be written to the NAND. It obviously has a place in a NAND backup, but it could just as easily be included in the backup itself when the backup is created, instead of writing it to the NAND directly.)

Holy cow, dude. If you wanted to complain about the Luma 10.3 changelog, don't you think you could have come up with a better subject line!?

This wasn't even about Luma3DS at all aside from what the latest changelog stated, this has everything to do with people using stuff like ctr-no-timeoffset for sometime, because the universally standard practiced 3DS guide said so, however the Luma3DS changelog for v10.3 essentially states it's incorrect, the fact of the matter is we've been gambling our data, even if it is small amounts of data, it's important data no less. You missed the entirety of my point. I asked my question and I did have something to say, nowhere does it say either was going to be a certain length. I would appreciate if you read the whole thing before jumping to wild conclusions of what I am trying to say. I have no beef with Luma and I have no beef with the developer behind ctr-no-timeoffset, the idea here is to establish a better sense of communication with users regarding WHAT they are doing to their systems, and how homebrew should be handled better in the future, maybe better management and checks on whether or not something like ctr-no-timeoffset is actually good to use on the system or not.

If you want professional, unified documentation and development, then you should probably steer clear of homebrew, period. I daresay this is nothing compared to what has turned up in Linux development over the years.

This is a pointless point to make, it shouldn't matter what type of software it is. You use the systems you use, which means you SHOULD care about what goes on it, what it does, and how well the software being put on it is handled. If you like running stuff that does things it shouldn't or that you may not want it to do, then great, but that shouldn't be a universal standard in a world where stability, professionalism, and serious attention is actually necessary here (no I am not talking about Linux specifically, this is in general). While a lot of what we use on a day to day basis may not be well handled (Windows for example), that doesn't mean we should be silent about it and just deal with it. We either do something about it or continue to let it pile up to be an unstable mess.


Maybe my interpretation of what the changelog stated about this is different than what it was intended to actually portray. All I can say is from what I gathered from that blurb, based on how the wording is, the developers said that we SHOULDN'T nullify the offset, the very thing ctr-no-timeoffset does, the software that people were instructed to use on their systems based on a standard practice guide. It makes it seem like the scene is just winging the process of getting stuff like this working on these systems, which "winging" to me correlates to unprofessional actions.

Again a huge misunderstanding from my part, keep going.

 

[KleinesSinchen]

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.

Not likely to be a thing on NAND. Remove the battery for some seconds, reinsert, set date/time in System Settings and you will have a great difference between the shown clock and the internal, real clock. Setting the date in settings only sets the offset.
You are a developer: Just look through the source code of ctr-no-timeoffset. That should contain the answer.

Again: No idea where this comes from. A recommendation without reason isn't very convincing. Maybe there has been some discussion in a closed platform?


About the writing to NAND:
That is a thing that I do not understand at all. Especially on the DSi it is repeated like a mantra that a few write cycles will kill the chip. That doesn't make sense for me. Even a simple NAND chip has some wear levelling and writing a bit every now and then is not gonna come anywhere near 1000 cycles for each cell in a decade. Furthermore NAND needs to be refreshed. It has a limited data retention time.

EmuNAND:
I know of one case of partially failed 3DS NAND (don't find it at the moment) where the solution was creating an EmuNAND to revive the console. Other than such cases EmuNAND just adds complexity and SDs fail far more often than the internal chip. That would mean a lot of unneeded troubleshooting for end users. We have a really great number of modded 2|3DS systems and… doesn't seem like they all go bad because of writing a bit to NAND (which the system does in normal operation).
===========

 

[Halvorsen]

There's nothing unprofessional about stating a fact. And personally not knowing the reason behind the message doesn't discredit the original message in any capacity. Expecting that the homebrew scene collectively knows everything about the system, and collectively knows why certain glitches occurs, is a very unrealistic and naive perspective. Ensuring the offset remains untouched in order to prevent occurrences of a bug that has been plaguing hacked 3DSes for nearly half a decade when the cause is fully reasonable (black screens on boot with otherwise fully intact system software, or lumabug, can be attributed with a PTM issue caused by this offset change).

I get told often that the NAND shouldn't be written to, or that it's dangerous to write to it

This is either a user spewing nonsense or parroting outdated info. For example, sysNAND, back in the 9.2 days and prior, was dangerous to use as a primary NAND given that any bricks weren't recoverable (at the time) and updating would ensure that entrypoints are blocked. On the DSi, there have been reports of bricks after restoring NAND backups, but this is a completely separate system.

This is a pointless point to make, it shouldn't matter what type of software it is. You use the systems you use, which means you SHOULD care about what goes on it, what it does, and how well the software being put on it is handled.

Yikes. There is no "professionalism" owed in the first place. You are reminded every step of the way, by the homebrew community, by every guide, and by Nintendo themselves, that you accept any risk endured by your console by making the conscious choice to run unauthorised software. People learn new things about the console to this day. The party who controls the guide and the party who writes the 3DS software are not the same and there should be no expectation that everyone is on the same page about the best practices for a device that they never created in the first place.

TuxSH learned about the cause of lumabug today. The practices recommended by the changelog helps prevent it, but the original release notes only actually disclaimed messing with the RTC due to being a bad practice in general. Despite disclaiming that there are no fingers pointed to any individuals, it genuinely makes no sense to post this. This is a homebrew community, not a paid organisation. Not a single person is responsible for the safety of the data on any device other than yourself, by choosing to run community software.

This should be common sense going into a homebrew community, of all places.

 

[lasagnaloverleo]

Does anyone know what I would have to do if I were trying to install cfw onto a 3ds right now, do I follow Luma and ignore ctr-no-timeoffset and DSP1 or do I install them anyway if I want godmode9??

I'm not really familiar with these things and this Luma update is so new that I can't find any answers on this

 

[Halvorsen]

Does anyone know what I would have to do if I were trying to install cfw onto a 3ds right now, do I follow Luma and ignore ctr-no-timeoffset and DSP1 or do I install them anyway if I want godmode9??

I'm not really familiar with these things and this Luma update is so new that I can't find any answers on this

Ignoring the ctr-no-timeoffset and DSP1 sections of the guide would be a good practice, as they will be removed soon from the guide.

 

[lasagnaloverleo]

Ignoring the ctr-no-timeoffset and DSP1 sections of the guide would be a good practice, as they will be removed soon from the guide.

and just to be 100% sure, this won't affect Godmode9 due to the new Luma update?

 

[Halvorsen]

and just to be 100% sure, this won't affect Godmode9 due to the new Luma update?

As a person new to the 3DS, it would be best to wait until the guide updates are published. Skipping steps in a guide also isn't a general good practice unless you know exactly what you're doing. To answer the question, GodMode9 is separate software and will still currently nag you to adjust the RTC. Generally speaking, you can/should ignore GM9's message at this time.

 

[lasagnaloverleo]

As a person new to the 3DS, it would be best to wait until the guide updates are published. Skipping steps in a guide also isn't a general good practice unless you know exactly what you're doing. To answer the question, GodMode9 is separate software and will still currently nag you to adjust the RTC. Generally speaking, you can/should ignore GM9's message at this time.

Ok, thanks for the help, really appreciate it!

 

[lone_wolf323]

Ignoring the ctr-no-timeoffset and DSP1 sections of the guide would be a good practice, as they will be removed soon from the guide.

why would DSP1 be good to ignore? Im sure thats what gives all homebrew sound. Is there something thats auto built this in?

 

[Halvorsen]

why would DSP1 be good to ignore? Im sure thats what gives all homebrew sound. Is there something thats auto built this in?

https://github.com/LumaTeam/Luma3DS/releases/tag/v10.3

• Add an option to dump the DSP firmware from Home Menu, effectively making programs like DSP1 obsolete

 

[lone_wolf323]

https://github.com/LumaTeam/Luma3DS/releases/tag/v10.3

• Add an option to dump the DSP firmware from Home Menu, effectively making programs like DSP1 obsolete

Awesome. Thank you.

 

[asiekierka]

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.

Where did anyone imply there's integrity?

The "standard practice guide" is not liked by a significant portion of the homebrew scene's developers, as it documents installation of tools used for activities other than user-mode homebrew execution. It's that simple. At the same time, the "standard practice guide" is popular because (a) the vast majority of people modifying their consoles do so for "activities other than user-mode homebrew execution", particularly piracy; (b) there are no alternative guides with anywhere near as much polish, at least not ones I'm aware of.

Beyond the veil, there's a lot of schisms and frustration. Ever since the mid-00s, you can observe a divide between "people who want to run their own code" and "people who want to faciliate piracy", with a lot of groups (ROM hackers, game modders, fan translators) kind of being stuck in the middle. It's just that a lot of this discourse happens in more private communities, and what the community sees is the tools with little of the context.

 

[ihaveahax]

TuxSH is right that time offset nullification is a bad idea. In case anyone doesn't know, the offset is a 64-bit number is stored in config save. All ctr-no-timeoffset did was set it to 0, so the time matched the raw rtc. The idea behind it was so that the time could be altered without games detecting it (e.g. Pokémon will delay berry growth for 24 hours if it detects the time has changed).

The reason GodMode9 tells you to change the raw rtc is because it did not have the ability to read from config save for a long time. The necessary parts to do that weren't available (specifically, reading DISA/DIFF containers and the filesystem within). But they are now and so it should be changed to read from the offset.

The problem is that some other parts of the console like ptm didn't react well to that. And as a result some people got issues like a black screen at boot that lasted 10 minutes while ptm caught up with the new raw rtc.

It was a neat little thing I figured out and published that happened to become the likely source of many headaches since 2017. I'm sorry for screwing something up that sticked around for years again.

(If anyone is going to ask, there is no need to change the offset away from 0 if it's already like that. It's likely not going to break anything further if it stays.)

 

[DeadSkullzJr]

There's nothing unprofessional about stating a fact. And personally not knowing the reason behind the message doesn't discredit the original message in any capacity. Expecting that the homebrew scene collectively knows everything about the system, and collectively knows why certain glitches occurs, is a very unrealistic and naive perspective. Ensuring the offset remains untouched in order to prevent occurrences of a bug that has been plaguing hacked 3DSes for nearly half a decade when the cause is fully reasonable (black screens on boot with otherwise fully intact system software, or lumabug, can be attributed with a PTM issue caused by this offset change).


This is either a user spewing nonsense or parroting outdated info. For example, sysNAND, back in the 9.2 day and prior, was dangerous to use a primary NAND given that any bricks weren't recoverable (at the time) and updating would ensure that entrypoints are blocked. On the DSi, there have been reports of bricks after restoring NAND backups, but this is a completely separate system.

There is no "professionalism" owed in the first place. These people are having fun creating unofficial software for a community in their free time. People learn new things about the console to this day. TuxSH learned about the cause of lumabug today. This bug fix helps prevent it, but the original release notes only disclaimed messing with the RTC due to being a bad practice in general. Despite disclaiming that there are no fingers pointed to any individuals, it genuinely makes no sense to post this. This is a homebrew community, not a paid organisation. The party who controls the guide and the party who writes the 3DS software are not the same and there is no expectation that everyone is on the same page about the best practices for a device that they never created in the first place.

Let me stress some points to make this clear.

There's nothing unprofessional about stating a fact. And personally not knowing the reason behind the message doesn't discredit the original message in any capacity.

No way was I claiming anything was wrong about the fact, I was talking about the fact of using software, ctr-no-timeoffset, knowing (from the standpoint of developers who knew about this) that it's bad practice in general to mess with RTC stuff with solutions like these, yet we got these solutions anyways and no warnings given of what it could break, if there was one then it's missing or I overlooked it. The primary point is if you willingly know something isn't going to work correctly, why push it out to the public anyways?

Expecting that the homebrew scene collectively knows everything about the system, and collectively knows why certain glitches occurs, is a very unrealistic and naive perspective.

I never said I expected the scene to know everything, to make everything bug free, and have already mentioned don't expect anything to be perfect. What I expect is maybe more testing on the potential at hand before a solution gets pumped out, because based on my readings, this issue has been known about, but a real fix never came. The fact a solution was invented knowing the issue existed, that doesn't seem optimal.

This is either a user spewing nonsense or parroting outdated info. For example, sysNAND, back in the 9.2 day and prior, was dangerous to use a primary NAND given that any bricks weren't recoverable (at the time) and updating would ensure that entrypoints are blocked. On the DSi, there have been reports of bricks after restoring NAND backups, but this is a completely separate system.

If you gathered the amount of people that have told me that over time, you would probably have a small community to work with lol. I honestly have no idea what to believe, but one thing I do know is EmuNAND is actually a more appropriate environment for cases like bricks and what not from homebrew applications, plugins, etc. (I can name a recent situation that happened last year, of course others have before that too). Personally I just sit with the mindset that if you take care of your stuff, it will last you a long time, anything can happen to it honestly so there is no definitive death date unless it's proven to die within a set timeframe or from a certain condition of sorts.

There is no "professionalism" owed in the first place. These people are having fun creating unofficial software for a community in their free time. People learn new things about the console to this day. TuxSH learned about the cause of lumabug today. This bug fix helps prevent it, but the original release notes only disclaimed messing with the RTC due to being a bad practice in general.

I don't expect it "owed", the main reason I mention professionalism, serious attention, and stability the way I do is because look at what we are working with here? Expensive devices that aren't easy to replace, especially thanks to greedy scalpers bumping the prices, it's not like most people have a pile of these systems sitting around waiting to be modified in some way. When I do my work, I always strive to make sure what I give is the best and most optimal it can be (I am not saying other developers do not, I know majority of them do in the scene), usually whenever it comes to solutions that may bug out an aspect of the system in some way, I never give it out until it's fixed properly, I always thought that was the same practice other developers were to live by with their work when dealing with public related usage of said works. I definitely get your case entirely with the concept of learning, we all learn, that never ends, it's just within the time the issue was known, nobody pushed an issue out in the respective repositories about it, or gave any word on the matter. Maybe the situation isn't a huge deal, but I've always held keeping the systems running properly a major priority, if it's not, then I generally deem that an issue.

TuxSH learned about the cause of lumabug today. This bug fix helps prevent it, but the original release notes only disclaimed messing with the RTC due to being a bad practice in general.

This is why I said maybe my interpretation of what it meant was potentially different from its original intentions in my second post here in the thread:

Maybe my interpretation of what the changelog stated about this is different than what it was intended to actually portray. All I can say is from what I gathered from that blurb, based on how the wording is, the developers said that we SHOULDN'T nullify the offset, the very thing ctr-no-timeoffset does, the software that people were instructed to use on their systems based on a standard practice guide. It makes it seem like the scene is just winging the process of getting stuff like this working on these systems, which "winging" to me correlates to unprofessional actions.

From the changelog itself:
"...Also, even if 3ds.hacks.guide recommends it and GodMode9 mandates it, time offset nullification should not be done"

Let me restate this, I took this as we should never nullify the offset using solutions like ctr-no-timeoffset, it made me think the issue was known already, which it kind of was known, I mean from the Luma3DS GitHub commits section I can at least account for last year, but there could be other sources of it from before then. It's just the fact that a solution was made potentially knowing the side effects it may cause seems unprofessional to me, mismanaged a bit too. However when you stated the changelog entry this way it makes much more sense now.


It's pretty clear I may have jumped the gun through my own misunderstanding, I just hold the concept of a developer high in the sense that they were passionate, but professional with their work as well. With no excuses of course, I am sorry for the way I reacted.

 

[DeadSkullzJr]

TuxSH is right that time offset nullification is a bad idea. In case anyone doesn't know, the offset is a 64-bit number is stored in config save. All ctr-no-timeoffset did was set it to 0, so the time matched the raw rtc. The idea behind it was so that the time could be altered without games detecting it (e.g. Pokémon will delay berry growth for 24 hours if it detects the time has changed).

The reason GodMode9 tells you to change the raw rtc is because it did not have the ability to read from config save for a long time. The necessary parts to do that weren't available (specifically, reading DISA/DIFF containers and the filesystem within). But they are now and so it should be changed to read from the offset.

The problem is that some other parts of the console like ptm didn't react well to that. And as a result some people got issues like a black screen at boot that lasted 10 minutes while ptm caught up with the new raw rtc.

It was a neat little thing I figured out and published that happened to become the likely source of many headaches since 2017. I'm sorry for screwing something up that sticked around for years again.

(If anyone is going to ask, there is no need to change the offset away from 0 if it's already like that. It's likely not going to break anything further if it stays.)

I have no ill feelings with you and I know you meant well, I misunderstood what the changelog entry meant, it took @Halvorsen restating it differently to make me understand (thank you by the way). Seems like the idea was kind of clever that you had going on. I do have to ask though, where is this offset located on the system (assuming BIOS but I don't think GodMode9 can access that stuff)? I never could figure out where GodMode9 was pulling the data and what not from.

 

[ihaveahax]

I do have to ask though, where is this offset located on the system (assuming BIOS but I don't think GodMode9 can access that stuff)? I never could figure out where GodMode9 was pulling the data and what not from.

Config block 0x00030001 in the config savegame (/data/id0/sysdata/00010017)
I think the raw rtc is in the i2c registers.

 

[Halvorsen]

I definitely get your case entirely with the concept of learning, we all learn, that never ends, it's just within the time the issue was known, nobody pushed an issue out in the respective repositories about it, or gave any word on the matter.

With all due respect, there were certainly long-standing issues created across community GitHub repositories which ended up either closed or otherwise unresolved from not being able to pinpoint a cause, or being seemingly unrelated to Luma itself (which ended up being the case on Luma3DS's issue tracker).

I was talking about the fact of using software, ctr-no-timeoffset, knowing (from the standpoint of developers who knew about this) that it's bad practice in general to mess with RTC stuff with solutions like these, yet we got these solutions anyways and no warnings given of what it could break, if there was one then it's missing or I overlooked it.

At the time, it wasn't consensually concluded that there would be any direct ill-effect of adjusting the RTC manually, as you can see from ihaveahax's post. In this case, it was found to be a bad practice as more information about the 3DS was discovered. You're correct that TuxSH could have raised an issue with guide developers during some point in the past, but the timeline of these events makes this point somewhat dubious, as public knowledge was still in the process of being gathered and implemented. The cause of the bug was only recently discovered to be RTC manipulation, and TuxSH independently recommended against RTC manipulation based on his knowledge while not being aware that it was the catalyst of lumabug at the time of 10.3's release.

Let me restate this, I took this as we should never nullify the offset using solutions like ctr-no-timeoffset, it made me think the issue was known already, which it kind of was known, I mean from the Luma3DS GitHub commits section I can at least account for last year

The cause of the issue was discovered within the last six months. I admit that I am not sure what issues from the Luma3DS repo you are referring to, since I do not track it; I am mildly interested.

It's just the fact that a solution was made potentially knowing the side effects it may cause seems unprofessional to me, mismanaged a bit too.

There's nothing wrong with wanting the best out of a community. The main takeaway is that an instance of an error that flew under the radar isn't necessarily indicative of a longstanding community management error, especially given that it's often a small group of individuals with wildly varying degrees of knowledge. The community created spaces like 3dbrew to help close this gap.

I never give it out until it's fixed properly

To my knowledge, most users and developers had no reason to consider their action of resetting RTC "generally improper" usage. Of course, if TuxSH did explicitly recommend against it before 10.3's release, it would partially nullify that point.

It makes it seem like the scene is just winging the process of getting stuff like this working on these systems, which "winging" to me correlates to unprofessional actions.

Unfortunately, this is, and will almost always be, the case for reverse engineering a device that doesn't have manufacturer documentation or decades of history. It isn't necessarily a lack of passion, or else none of this would continue to exist in 2022. What happened here can be reasonably shown to be an instance of a spoken caution that wasn't necessarily caught by everyone until issues arose.

No harm done, so no need to apologise.