http://www.ktemkin.com/faq-fusee-gelee/

Kate has collected and answered the most common questions she's gotten regarding Fusée Gelée. Most notably she explains the three "types" of FG hacks, software, hardware (temporary) and hardware (permanent).

Enjoy!

Kate herself responded to this thread on page 26, thanks Kate!

There's a lot more here than I can easily respond to, so apologies if I miss posts or gloss over points.



This is correct-- while there likely will be software chains around for these things in the future, I don't see them as coming along as quickly as f-g. We don't have a non-coldboot exploit chain at all for 5.0.0-- and we haven't looked yet, as we've had other things to focus on and coldboot works. We do have one for 4.1.0, but it's centered around a couple of exploits that we don't want to burn-- we're hoping to use them to get an opportunity to poke around inside T214/Mariko.



I don't view you as particularly hostile, no. I don't know if challenge is generally a good thing-- sometimes you do have to accept that other people have different ethics or viewpoints from yourself and let that pass, especially if they're just doing stuff for fun-- but I don't view your post as hostile.



Jamais Vu (1.0.0 TrustZone hack) isn't my bug, but has been written up, and is just awaiting someone with the skills to have time to do a public interpretation. Déjà Vu is currently centered around the exploit I mentioned above, and we definitely want to hold onto that for as long as it's applicable. It's entirely a Switch bug, too, so I don't see it as being something that needs responsible disclosure.



For Déjà Vu, absolutely. (explained in last quote)



I don't agree that things like tweeting are ego. This is something I work on because I find it a lot of fun to hack on things, and there's definitely an aspect in which it makes me happy when seeing the results of things makes other people happy. There's also an aspect in which I hope that showing these things are possible inspires people to want to learn e.g. reverse engineering. This stuff is cool; and I want to share the excitement with others and lift them up as much as I can.

You don't have to believe me on that or like that that's my goal. I won't hold it against you if you don't.



I honestly support people updating when it makes sense; and I recognize that there's a conflict between holding back information and enabling others to make reasonable decisions about that. I don't like or feel good about secrecy, and I know it has implications. I've tried to be as clear as I can about the costs regarding updating without crossing the line into giving things away.



I think we've been pretty clear that 4.1.0 will eventually see a non-coldboot, software-only exploit with the same level of power. That's actually been posted on the ReSwitched Discord's FAQ for months, but I know the message gets skewed as its gets communicated over to other places. That's part of why I'm here, now-- I want to help clear things up.

The interactions between the operating system and the bootloader-- say on reboot-- are actually fairly limited; and knowing what any of them are is enough to point people at the particular section of bootrom that's vulnerable. That's why I'm not commenting on Fusée Gelée and how it relates to software-only solutions right now. I have said e.g. above that since there's no public way of getting the privileges necessary to run things, 4.1.0 isn't going to see a pure software solution that the public can use at the time that f-g is released. Software exploits will likely come in time; and it's possible we'll come up with things that are even easier than f-g.



I'm not sure if they'll take it seriously enough. I don't know how they are internally-- but I can't just assume they'll fail to do anything and skip disclosure. Honestly, I don't think a "security advisory" is really a bad thing, either-- there are definitely applications of Tegra chips that I and/or the public don't know about. If giving NVIDIA notice gives them time to explain exactly what's dangerous and allow their customers to remove and replace units from places where the vulnerability can cause harm, I consider that a win, and well worth delaying some public switch hacks by a few months.

I'll also say that my fear that vendors won't take the vulnerability seriously is a huge reason I'm so keen to get things out there-- and why I provided a date after which I'll tell the public what's going on that I've said was non-negotiable. I want to make sure this doesn't get hidden, and that people understand exactly what f-g can and can't accomplish, to minimize FUD while also letting people understand the actual risks are associated with using a vulnerable device.



It changes this from an exploit that's going to be usable before the affected people know it's a thing to something that people may have a chance to react to. Making the vulnerability public without disclosure really increases the odds someone is capable of using it to do bad.

I didn't really give NVIDIA a chance to sell-off stock; though. I've said publicly multiple times that there are bugs in Tegra processors well before NVIDIA reached out to me seeking disclosure. If anything, I think telling the public that these vulnerabilities exist while pursuing disclosure helps developers interested in using Tegra chips in the future ask the right question.



I've already said that while pure-software stuff is doable on 4.1.0; it'll be a wait. As far as I'm remembering, the only part of the chain that could require multiple tries to work is PegaSwitch, which is our browser-based entry point, and I haven't even tried the browser entry point that'll eventually be public to see how reliable it is. SciresM did the work to get our non-coldboot exploit working on 4.1.0; not me.



Yeah, that's hard-- especially as everyone has a different view as to how inconvenient things are. I don't know of a way to communicate this better without more details.

Incidentally, the 'inconvenience' verbiage came from SciresM and I discussing our respective views on updating. I think SciresM is more towards the opinion that people should hold back more often, where I'm more of the opinion that updating can be a good and reasonable option sometimes. The way we wound up phrasing things is a compromise between views.



(I'm going to assume this meant "on the hacking side". If not I'm not sure what hacking site you're referring to.)

Updating to latest just closes the possibility of using software exploits launched from Horizon, which can make setup more difficult. I know you'd like to know how much, but I unfortunately don't have a good way of qualifying that. As I've mentioned, if you're suffering from not being able to use your 3.0.1+ Switch, you probably do want to upgrade and just risk things being more inconvenient in the future. Worst comes to worst, if you decide you can't tolerate the inconvenience, you upgrade and then wind up having to figure out a modchip.

The downgrade protection fuses literally mean nothing to a system with f-g, which can entirely skip the downgrade check. Incidentally, SciresM actually accidentally bricked one of his systems in a way such that it was always failing the downgrade checks, and he's been able to use f-g to get that system up and running again.



I don't think that's clear at all, nor do I want to confirm or deny this. Sorry.



I think you're making a bunch of assumptions here, and that's maybe not a great idea. I'm not saying you're necessarily right or wrong; just that I don't think your assumptions are founded.



I don't think this contradicts. This is talking about vulnerabilities that aren't f-g; not because f-g doesn't work on 4.1.0, but because it's possible we may come up with vulnerabilities that are even nicer on 4.1.0 in the future.



I'm being as clear as I feel I can, and adding clarifications e.g. here where I think it helps. There will be different names for the the ways you can use f-g eventually; and I'll be fully open about everything once the summer rolls around and I'm not putting the disclosure timeline in jeopardy.



I know and have said about that this "bring your own exploit" business makes development exclusive, and that's exclusionary and I really don't like it-- I just don't see a way around it. I would love to get more developers and more perspective, and that's why my release date for f-g is tied to my disclosure timeline and not in particular to Atmosphère's release.




I've tried to point out approximately what the difficulty would be for some of the options to kind of provide this, but this is a hard thing to accomplish. In this case, providing details that are more specific really points a finger at vulnerability details, so there's not much I'm comfortable sharing. I've shared what I could-- as a data point, some of the other teams have outright stated that they think I've shared too much already and made things obvious. I don't agree or necessarily care about their opinons, but c'est la vie.



Well, this isn't the case. This has been disclosed to Nintendo, too-- as NVIDIA shares their vulnerability findings with downstream customers. It's more general malicious actors that I'd be worried about.



See above-- but I don't think I'd advise specifically updating to 4.1.0 unless that gives you enough access to the games you want.



I'm also super glad that we can do a lot of our work in the open. I hope there's a lot more of it in the future-- and I'd love to stream some of it.



I find the requirement disheartening as well, but I think this is the right way to do things, for now. I've explained my rationale above; feel free to ask questions.



I'm not sure why people are against communication, here. There were definite benefits to talking about f-g in the first place; including that it demonstrates that Tegra chips are vulnerable-- which hopefully influences buying decisions in the future and puts pressure on NVIDIA to seek as much of a fix as they can. After that there seemed to be definitely benefits to talking about more details, even in the limited sense that I'm able to. I've tried to give people more information than the nothing they would have had so they could have more of an idea whether it's be a good idea to e.g. pre-order a modchip or update their system. I know it can be frustrating to not get full disclosure, and that more information would help people to make a better or more conclusive decision, but full disclosure isn't an option until this summer. I don't think that's a reason to hold back information.



I don't have specific answers to your questions, unfortunately-- but I think it sounds like the main purpose of this Switch is as a gaming device and maybe you should upgrade and enjoy playing games with your son.



I don't think that asking for clarification is criticism. It might be rude to push me to answer something I said I wouldn't, but I don't think there's harm in answer.



I don't think I've said anything about opening the console or not. See above for my views on updating?



I'm not sure where you got this impression, or why you're confident about things enough to claim you know about the internal values or working of ReSwitched. This is also easily disprovable just from public information--Hedgeberg has tested out f-g on stream. I don't see it as great opsec to enumerate how many people have access to the vulnerability, but we've long had a policy of only giving exploit details to those who actually want to know them and are in a position where they can use them to help. This is a basic security precaution and not about trust.

I'm actually not sure how this is relevant to the broader discussion. Based on your post history, I can tell that you strongly support TX and the option they're providing, and you're welcome to that, but I think throwing around generic unfounded criticism of RS doesn't do much good and distracts from me answering community questions.



I don't think they're obviously more convenient, as they exist right now. They're both inherently however-tethered-you-consider-PegaSwitch, take a bunch of time to run, and rely on a pegaswitch entry point.



That's not correct-- everyone on a current hardware revision will be able to install and use CFW the day it's released, if they're willing to put in the effort and potentially take on some minor risk.



I'm actually not sure what you mean by this entire post? Sorry about that-- I'd love to address your ideas, but unfortunately I can't figure out your meaning.



That was about me having fun by trying to see if a DIY, cheap modchip option is reasonable. It turns out it is. As you've noted, it's not necessary on any firmware. I just really like the idea that the open exchange of knowledge -- especially when profit's not a motive -- can result in creation of neat options for the community. ^-^



Yep; that's exactly what it means.



I don't think this has been at all implied-- and you'd be hard pressed to find a way to make a solder-less Arduino option that even remotely fits in the Switch case.

I should also clarify that the DIY option isn't solderless.

If you have or are going to get the game anyway, you can. Those versions are pretty much interchangeable in the long-term.



Yep-- and it's possible at some point that we'll allow you to install Fake News without Puyo using f-g/Atmosphère. The original plan was to release Atmosphère for 1.0.0 first while we tried to figure out how to deal with Fusée Gelée, but we actually wound up with a disclosure schedule that was faster than we'd thought.

 

[linuxares]

No tiny soldering required.

*My sides*

 

[hippy dave]

So, there are going to be different versions depending on FW or ease of use?

The CFW you will end up running is the same, but the stuff you will have to do to run it will be different for different firmware versions, and simpler on earlier ones.

I meant to say, thanks OP for sharing. Good info, clarified and confirmed what I gathered from twatter conversations, and reassured me about my decision.

 

[notimp]

Its still too meandering to be of any "short phrase usability".

The essence of it seems to be "most people" (as in probably e/o after 1.0.0) will want to look into a "hardware assisted" method of /snip-shortened-logic/ booting the cfw, although the hardware assist can be very simple (bridging a few pins), or a bit more elaborate (not disclosed in detail), but will not require the TX solution - as all information on it will be openly disclosed, and should lead to ubiquitous, very inexpensive, easy to apply - even solderless "hardmod solutions".

In specific. The softmod only implementation of Fusée Gelée is the one to be least excited about.

Differences are mostly to be conceptualized in "time and effort to boot to cfw".


Attempt to simplify - taking no prisoners:

Everything is far from "convenient", "untethered", "fast" - unless you use "some form of hardmod" (or maybe are on 1.0.0). Hackers be scrambling to release an open source hardmod that does it all - so TX doesnt get a marketable advantage.

Also - this (what fallows) is very odd.

While it's cool that they want to build technical solutions to Switch-hacking problems, I completely detest what I've seen of their practices and methods. Not just do they publicly endorse piracy, and seek to profit from keeping information to a few people, but they're also willing to drop a 0-day that affects a broad swathe of devices on the public without any responsible disclosure.

All in all, I think that Team Xecuter seems to be without morals or scruples, and I am happy to do as much as I can to reduce their profitability and thus disincentivize these kinds of awful behaviors.

Here is where I am logic wise. Lets say this allows for remote takeover of devices containing those type of NVIDIA socs. Worst that could happen is the botnetability of a few hundred thousands NVIDIA shields (not many other vendors use NViDIA silicon, because its expensive). Which are IOT devices to begin with. If this does indeed effect SOCs that are used in the automotive sector - whats the suggested path of action there?

The "bootrom bug" can not be fixed by a software update. NVIDIA will do NOTHING to protect the affected devices out there in that regard. All you are giving them by insisting on responsible disclosure (which I am a fan of, btw - just playing this out logic wise), is a leg up on the production of new silicon, that doesn't suffer from the main issue.

So you are making them money, with no publicly discernable benefit at all.

Disclose all aspects of the exploit chain, where software fixes can be rolled out - but insisting on a "non patchable" vuln to be disclosed as early as possible, doesnt necessarily benefit the common user. Because - economics dictate, that there will not be a replacement program, by anyone. End of use will not be significantly earlier. The world goes on, and nVidia gets a financial leg up because of your research.

Bravo? Moral superiority claimed?

Nintendo will not replace 20mio switches. Nor will the car manufacturer, that used NVIDIA silicon.

Looking at TX's behavior - its perfectly rational from a for profit POV. Promote piracy, because it will make you the most sales. Dont disclose vuln, because it will ensure prolonged use. Don't disclose method, because it gives you marketable advantage over your competition.

Where the "no morals and scrupels" part comes in, I'm not so sure...

I couldnt care less about the prosperity of whoever sits behind the TX label these days, but to me this still sounds like a very strange, hard sell.

I don't suspect Kate Tempkin to suffer from social justice warrior syndrom (her humor is too elaborate.. ), but still - I claim "pretty odd logic" being at work here..

 

[brickmii82]

Its still too meandering to be of any "short phrase usability".

The essence of it seems to be "most people" (as in probably e/o after 1.0.0) will want to look into a "hardware assisted" method of /snip-shortened-logic/ booting the cfw, although the hardware assist can be very simple (bridging a few pins), or a bit more elaborate (not disclosed in detail), but will not require the TX solution - as all information on it will be openly disclosed, and should lead to ubiquitous, very inexpensive, easy to apply - even solderless "hardmod solutions".

In specific. The softmod only implementation of Fusée Gelée is the one to be least excited about.

Differences are mostly to be conceptualized in "time and effort to boot to cfw".


Attempt do simplify - taking no prisoners:

Everything is far from "convenient", "untethered", "fast" - unless you so "some form of hardmod" (or maybe are on 1.0.0). Hackers be scrambling to release an open source hardmod that does it all - so TX doesnt get a marketable advantage.

Also - this (what fallows) is very odd.



Here is where I am logic wise. Lets say this allows for remote takeover of devices containing those type of NVIDIA socs. Worst that could happen is the botnetability of a few hundred thousands NVIDIA shields (not many other vendors use NViDIA silicon, because its expensive). Which are IOT devices to begin with. If this does indeed effect SOCs that are used in the automotive sector - whats the suggested path of action there?

The "bootrom bug" can not be fixed by a software update. NVIDIA will do NOTHING to protect the affected devices out there in that regard. All you are giving them by insisting on responsible disclosure (which I am a fan of, btw - just playing this out logic wise), is a leg up on the production of new silicon, that doesn't suffer from the main issue.

So you are making them money, with no publicly discernable benefit at all.

Disclose all aspects of the exploit chain, where software fixes can be rolled out - but insisting on a "non patchable" vuln to be disclosed as early as possible, doesnt necessarily benefit the common user. Because - economics dictate, that there will not be a replacement program, by anyone. End of use will not be significantly earlier. The world goes on, and nVidia gets a financial leg up because of your research.

Bravo? Moral superiority claimed?

Nintendo will not replace 20mio switches. Nor will the car manufacturer, that used NVIDIA silicon.

Looking at TX's behavior - its perfectly rational from a for profit POV. Promote piracy, because it will make you the most sales. Dont disclose vuln, because it will ensure prolonged use. Don't disclose method, because it gives you marketable advantage over your competition.

Where the "no morals and scrupels" part comes in, I'm not so sure...

I couldnt care less about the prosperity of whoever sits behind the TX label these days, but to me this still sounds like a very strange hard sell.

Admittedly, I haven’t read this whole post yet but you have a habit of making a wall of text so cut me some slack.

Yes, any auto mftr will immediately recall any potential safety issues. From leaky Schrader valves in tire stems, to seat belts that don’t fasten right, to gas pedals that get stuck, to yes, also computer issues.


Ok yeah I agree with most of it(I think) lol

 

[notimp]

Yes, any auto mftr will immediately recall any potential safety issues. From leaky Schrader valves in tire stems, to seat belts that don’t fasten right, to gas pedals that get stuck, to yes, also computer issues.

If thats the case, the logic is sound - and me trying to marter my brain would come to an end. I just don't see this happening, for a hardware vuln. At all.

To me its almost like saying that Intel would exchange all products produced in the last four years. (Because companies cant think back for more than that timespan, when it comes to responsibility.. ) - it just doesnt happen.

"But give them a chance.." Yes, I guess...

 

[brickmii82]

If thats the case, the logic is sound - and me trying to marter my brain would come to an end. I just don't see this happening, for a hardware vuln. At all.

To me its almost like saying that Intel would exchange all products produced in the last four years. (Because companies cant think back for more than that timespan, when it comes to responsibility.. ) - it just doesnt happen.

"But give them a chance.." Yes, I guess...

Typically that’s the case, but the Department of Transportation will have this issue in front of Congress if it’s a broad safety issue. Idk how far reaching this vulnerability goes, and it seems you’d need physical access to the computer to actually execute something malicious. But if it was an exploit that could be done remotely... yeah they’d be on top of that shit quickly.

I think we’re on the same page here lol. It’s not something that is an outright hazard, just something that someone might use to steal a Ferrari in some Gone in 60 Seconds shit.

 

[notimp]

Thats basically it, if this is such a "high impact issue" (as in governments will make them do it), the actions are rectified.

But this is how this plays out in my head.

If issue is a faulty steering column, every mechanic in washington will talk about it and joke about how easily it could have been prevented. Thats something you can explain to your average politician or judge on a "even he snickers about it, and it can cost lives" basis. If there is a not software fixable vuln in a piece of silicon, mechanics and the general public goes *huh*? Manufacturer goes "will fix it with software update!" (which of course isn't true) and thats the end of it.

I know that the logic for self driving vehicles is a little different, because the manufacturers are trying to design "trust networks" as a future business model - but anything where you bank on an engineer convincing management to loose money on with not even necessarily a public trust benefit ("eh, who does understand those things, am I right?" excuse still flies), usually doesnt work.

 

[subcon959]

something that someone might use to steal a Ferrari in some Gone in 60 Seconds shit.

But is it even that? Or just a part of the media/entertainment system that isn't connected to anything else?

 

[brickmii82]

Thats basically it, if this is such a "high impact issue" (as in governments will make them do it), the actions are rectified.

But this is how this plays out in my head.

If issue is a faulty steering column, every mechanic in washington will talk about it and joke about how easily it could have been prevented. Thats something you can explain to your average politician or judge on a "even he snickers about it, and it can cost lives" basis. If there is a not software fixable vuln in a piece of silicon, mechanics and the general public goes *huh*? Manufacturer goes "will fix it with software update!" (which of course isn't true) and thats the end of it.

I know that the logic for self driving vehicles is a little different, because the manufacturers are trying to design "trust networks" as a future business model - but anything where you bank on an engineer convincing management to loose money on with not even necessarily a public trust benefit ("eh, who does understand those things, am I right?" excuse still flies), usually doesnt work.

Firestone took all of the blame for Fords SUV flipping issue some while back even though the engineering physics of said SUV’s was also to blame. Why? Exactly what you said. It was cheaper to payout than lose Fords business for OE tires.

--------------------- MERGED ---------------------------

But is it even that? Or just a part of the media/entertainment system that isn't connected to anything else?

I honestly have no idea. I’m just throwing out scenarios. All in all, it really looks like you’d need physical access to the comp utilizing the X1 if I understand this exploit correctly. Which means you’d have to hack the damn thing under the hood. There’s no remote vulnerability. That was where I was going.

 

[subcon959]

I honestly have no idea. I’m just throwing out scenarios. All in all, it really looks like you’d need physical access to the comp utilizing the X1 if I understand this exploit correctly. Which means you’d have to hack the damn thing under the hood. There’s no remote vulnerability. That was where I was going.

I agree, it almost sounds like there's some (unconscious?) self-aggrandising going on about the scope of the discovery.

 

[leon315]

I've got a Million dollars question: How do you pronounce Fusée Gelée??

 

[subcon959]

I've got a Million dollars question: How do you pronounce Fusée Gelée??

Use the speaker icon:
https://www.collinsdictionary.com/dictionary/french-english/fusée
https://www.collinsdictionary.com/dictionary/french-english/gelée

 

[brickmii82]

I've got a Million dollars question: How do you pronounce Fusée Gelée??

I’m imagining it in French, said by Sophie Marceau in her mid 20’s....

 

[Nincompoopdo]

For people who don't understand:

Different firmwares (1.0, 3.0, 4.01, etc) are like different houses, you can get in through the door, but some are locked so you try the windows. If they are locked then get in through the chimney. If you still can't get in, then dig a tunnel under the house. Some houses are easier to break in (1.0/3.0) others (>3.1) required more work. Eventually, if you do break in... you do the same thing: remove all the locks (installing CFW). Now your house is free as a bird.

 

[leon315]

Use the speaker icon:
https://www.collinsdictionary.com/dictionary/french-english/fusée
https://www.collinsdictionary.com/dictionary/french-english/gelée

wow, that's very fascinating, i was totally wrong about the pronounce, until now, devs should really put it in Q&A how to pronounce Fusée Gelée

 

[sarkwalvein]

wow, that's very fascinating, i was totally wrong about the pronounce, until now, devs should really put it in Q&A how to pronounce Fusée Gelée

True, they should specially put some emphasis on how to pronounce those vowels correctly.

In my mother tongue Spanish way of thinking, I read it as "fusé yelé", or perhaps "fusé yolé"... sure that "e" vowel in "Gelée" sounds something between e and o, weird... also, a very relevant topic.

 

[brickmii82]

For people who don't understand:

Different firmwares (1.0, 3.0, 4.01, etc) are like different houses, you can get in through the door, but some are locked so you try the windows. If they are locked then get in through the chimney. If you still can't get in, then dig a tunnel under the house. Some houses are easier to break in (1.0/3.0) others (>3.1) required more work. Eventually, if you do break in... you do the same thing: remove all the locks (installing CFW). Now your house is free as a bird.

You sound like you have experience..... hooligan

 

[leon315]

True, they should specially put some emphasis on how to pronounce those vowels correctly.

In my mother tongue Spanish way of thinking, I read it as "fusé yelé", or perhaps "fusé yolé"... sure that "e" vowel in "Gelée" sounds something between e and o, weird... also, a very relevant topic.

i think almost all people don't care about it, the only purpose about this hack considered ''relevant'' is how to allow those stingy pirates to pirate all the shii out without tiny soldering.

 

[Onibi]

Literally contains almost no information, beides:
- the bootrom has multiple bugs
- is simple to pull off in HW (meaning you don't really have to care about the FW if you are willing to mod)
- shorting / glitching seems to be almost sufficient to trigger the initial issue (likely to gain recovery)

I think this confirms what we have been expecting. That if the eMMC is somehow not detected right, the recovery is triggered and has a security hole.

Literally, instead of this text the same length text could detail the exploit.

The whole responsible disclosure delay is still an absolutely crap argument. The whole release is simply delayed until they want to release a CFW. Nothing else. IMO an intentional slowdown and ploy to stay in control and to gain maximum attention for everybody involved and get some personal hype going ... Pretty meh.

 

[sarkwalvein]

Literally contains almost no information, beides:
- the bootrom has multiple bugs
- is simple to pull off
- shorting / glitching seems to be almost sufficient to trigger the initial issue (likely to gain recovery)

I think this confirms what we have been expecting. That if the eMMC is somehow not detected right, the recovery is triggered and has a security hole.

Literally, instead of this text the same length text could detail the exploit.

The whole responsible disclosure delay is still an absolutely crap argument. The whole release is simply delayed until they want to release a CFW. Nothing else. IMO an intentional slowdown and ploy to stay in control and to gain maximum attention for everybody involved and get some personal hype going ... Pretty meh.

I disagree, it turned out to be a pretty interesting read.

Regarding the "responsible disclosure", it was also good to know, made me think probably of the self-driving Tesla computers, but sure there are a lot of Tegra devices out there, perhaps those also suffer from the bug.

And specially about the hack, it is now quite clear that no matter what version of firmware you have, you can still pull it off without even soldering anything, that is to said, quite easily.

I think you probably just can't enjoy reading. Or perhaps you are an unhappy person... I mean, for the unnecessary complaining about the length of a good structured text that actually is not that long.