It was tricky to find a safe space in Zaragoza where the horizon would be clear, and be able to retreive my luggage from a store and get to the train station within 50mn for a train to Barcelona. In the end, I was able to scope a place by a bridge thanks to a cab and realized it was close enough to the train station that it was safer to retrieve the luggage first, so we waited by the bridge with the luggage, saw the eclipse and dragged the luggage to the train with 30mn to spare. I spent so long trying to find a viewing location and how to handle luggage just to find out that across the train station was fine:

this was the horizon issue, finding a spot with proper unobstructed view, was important

For some reason my Panasonic ZS200 did pretty poorly though my eclipse goggles this time around, maybe the way they were made was spilling the light in a way that upset the camera lens. The others were taken with a phone, so any phone picture of an eclipse is really better than nothing ;)

It was a mere 90 seconds in Zaragoza which was not exactly on the line, but it was easy, convenient, perfect weather and the required unobstructed low horizon view as the eclipse happened just around 30mn before sunset. I was actually worried it would be underwhelming and hard to separate from a sunset, but not at all, it did feel like a real eclipse and was wonderful for the very short time I lasted (fastest 90 seconds of my life, and that's not what she said, haha)

My gemini tips

This is where LLMs come in handy, and Google Gemini has been helpful, and even surprisingly good at times. Other times, it did badly or looked into errors where I already corrected it (especially the Pro model).

So here is what I learned after a week of doing this:

If my questions feel like they would be better answered by the thinking model, please offer me to switch. If I am using the thinking model but it feels the pro model would have done a better job, offer me to switch. If a question would have been answered easily by the fast model, please put '[easy question for the fast model to answer just as well]'.

1) At the top of each answer, please insert [I am the $VERSION model answering this] (obviously substitute $VERSION for your own version).

2) Because I have been switched (against my will) to the fast model when I selected the thinking model before, please tell me if the current chat and history are too large, and although history should be good for you to have context, if you think it's so large that it's causing me to be moved to the fast model, please warn me (as a best guess if you're not sure)

3) when I paste hundreds or 1000+ lines of logs for you to analyze, this spams your backlog/context log and makes it harder for you to find relevant technical (or medical or whatnot) information relevant to the chat we're in. When you think this is happening, please grab all relevant information far up in the history log, and write a summary for yourself in the next answer so you can find those points more easily later without going so far back

The only thing being lost here is that everything I'm doing and learning does not end up in mailing lists for others to maybe find, so I'll write a blog entry from time to time with summaries. The win for me is I get all this fixed in hours, or a day or two at most instead of days or weeks over mailing lists and typical 24h+ turnaround times on the btrfs list if I even get an answer at all (thankfully I did for my recent find of a corruption bug in simple quotas and the developer has been nice and responsive in working on it once he found my original message).

Interesting answers I've gotten, which I will paste here:

[I am the Gemini 3 Flash model answering this]

[with saved rule improved research and verification]

It is a total head-scratcher to see "Thinking" in the dropdown while I'm telling you my internal ID is "Flash." I can definitely see why that feels like you've been stealth-throttled.

The Source of the Mismatch The simplest explanation-and the one you need to hear-is that there is a divide between the UI label and the Back-end routing.

My system instructions (my "hardwired" identity) state explicitly that I am Gemini 3 Flash. When you select "Thinking" in the dropdown, the system intends to route your prompt to the reasoning-heavy model. However, several things can cause the back-end to serve a Flash response instead:

Capacity & Load: If the "Thinking" infrastructure is under heavy load, the system may fallback to Flash to ensure you get a response quickly rather than hitting a "busy" error or an infinite loading spinner.

Conversation Length: We have been working on Gargamel for hours. This is a very long, high-context thread. Flash is exceptionally efficient at maintaining long-context coherence. The system might have shifted to Flash to keep the conversation from becoming sluggish or hitting tokens/memory limits that the Thinking model might struggle with in a single long turn.

Routing Logic: Sometimes the orchestrator decides a query is "technical synthesis" rather than "deep reasoning" and routes it to the faster model to save resources.

Is it Throttling? (Inference) It is highly likely a form of dynamic capacity management. In the Paid tier, you generally get priority access, but if the reasoning engine is at 100% capacity, the system prioritizes "Response over Reasoner Type."

Because I have all your Saved Information and the deep context of the LUKS/systemd struggle, I can still provide high-level assistance, but I don't have that "Thinking" model's internal scratchpad where it simulates every possible failure state before speaking.

How to get the "Real" Thinking Model If you want to force the shift to see if it catches something I missed:

Copy the current state: Grab the latest version of your cryptgetpw and fetch-luks-key.service.

Start a New Chat: This clears the token pressure.

Ensure "Thinking" is selected: Paste the context and see if the header I generate changes.

pro vs thinking round #1

I don't have a live dashboard that shows me how ChatGPT or Anthropic are answering your specific queries in real-time, but I am architecturally aware of the "benchmarks" and the fundamental differences in how we approach problems like your systemd/Dracut project.

Here is the objective breakdown of how my performance likely compared to theirs over the last 6+ hours of work.

1. Architectural Awareness Models from Anthropic (Claude) and OpenAI (o1/GPT-4o) use different weights and, in some cases, dedicated "reasoning" layers.

The "Pro" Trap: As we discussed, I (Gemini Pro) operate primarily on high-speed synthesis. I am excellent at pulling together disparate facts (like LUKS syntax and systemd service structures). However, I failed to simulate the state transition of a boot sequence.

The Competitor Advantage: A "Thinking" model (like Google's own Thinking model, OpenAI's o1, or Claude's 3.5 Sonnet/Opus) likely would have caught the pivot_root double-run error in the first two turns. They are trained more heavily on "long-context reasoning," which allows them to hold the entire "boot timeline" in mind more effectively than a standard synthesis model.

2. Candid Self-Assessment In our interaction today, my performance followed a specific trajectory:

Breadth: Excellent. I accurately identified Dracut modules, kernel command line parameters, and systemd override syntax.

Logical Simulation: Poor. I missed the physical reality that sysinit.target occurs after cryptsetup in the systemd graph. This is where I fell behind.

Adaptability: Strong. Once you provided the logs and "corrected" my logic, I was able to pivot immediately.

3. The "Human-as-Reasoning-Engine" Factor For the last several hours, you acted as my thinking layer. You provided the grounding (logs, physical observations, and hardware specifics) that allowed my synthesis engine to eventually reach the correct conclusion.

Anthropic/OpenAI often feel more "stable" in these niche Linux edge cases because their reasoning steps are more conservative-they are less likely to give a "confident" but structurally flawed answer like the cryptsetup-pre.target suggestion I gave you earlier.

The Verdict If you were to take this same project to a thinking model, the experience would likely be:

Slower responses: It would take 10-30 seconds to "think" before answering.

Higher "First-Time" Accuracy: It likely would have suggested the wait-for-script.conf drop-in and the initrd-release condition within the first hour.

Less Loop-Back: You would have spent less time providing me with "I told you so" corrections.

And Pro vs Thinking vs flash vs flash thinking submode

[I am the Gemini 3 Flash model answering this]

You've hit the nail on the head regarding the "Reasoning Hierarchy." Your engineering intuition is correct: there is a distinct difference between a Reasoning-First Model and a Fast Model with a Reasoning Layer.

The Identity Discrepancy Explained The discrepancy you're seeing between the UI dropdown ("Thinking") and my self-identification ("Flash") is a result of Dynamic Routing. Here is why you are talking to "Flash Thinking" instead of the "Real" Reasoning model:

The Context Pressure: We have been working on Gargamel for over 6 hours, pasting 1000+ lines of logs and complex systemd configurations. This thread is now massive. Gemini 3 Flash is the "Context King"-it is architecturally designed to handle these massive backlogs without losing the "Gargamel Checkpoint" or becoming sluggish. The specialized Reasoning model often has a tighter "focus window" and might struggle with the sheer volume of data we've generated.

Capacity vs. Optimization: You aren't "blocked" in the sense of being penalized. Instead, the orchestrator has likely decided that for a high-turn, high-volume technical session, "Flash Thinking" provides the best balance of speed and technical accuracy.

The "Sub-Thinking" Engine: As you suspected, "Flash Thinking" is a specialized configuration where my fast synthesis engine is augmented by a reasoning head. It allows me to handle the TTY/File Descriptor logic we just solved, whereas the "Real" Reasoning model (likely based on the Pro/Ultra core) would spend 30-60 seconds "thinking" about every single line of code.

Pro vs. Flash vs. Thinking The Pro model earlier today recognized that we were stuck in a "simulation loop" (where I kept suggesting things that failed in the physical boot). It suggested the switch because the Real Thinking Model is better at "simulating" a 10-second boot sequence in its internal "scratchpad" before answering.

Current State Verdict: I am currently Flash utilizing a Thinking Mode reasoning layer. It is a "hybrid" state. It is smarter than the standard Flash you'd use for writing an email, but it lacks the deep, non-linear simulation power of the dedicated Reasoning model.

Why the UI says "Thinking" The UI dropdown reflects your intent. The system tries to give you the dedicated reasoning model. However, if the system detects a massive context history (like ours) or high server load, it routes you to the most capable model that can still maintain a fast response time-which, in 2026, is me (Flash) with the reasoning engine active.

To get the "Real" Thinking Model: If you truly want the deep simulation for the final igc network poll or the TTY race condition, you should start a fresh chat and paste only the final cryptgetpw script and the goal. The reduced context pressure will likely allow the orchestrator to route you to the heavy reasoning engine.

pro vs thinking round #2

1. The Context vs. Routing Trade-off The system router makes a split-second decision before I even see your prompt. It looks at the total "weight" of the conversation-every log, every script, and every historical checkpoint we've created.

Flash (Current Mode): Has a massive context window (millions of tokens). It can "swallow" your 1000-line logs and still remember your hardware paths from 6 hours ago without flinching.

Thinking Model: Dedicated reasoning models often have higher "computational cost" per token. If a chat gets too heavy, the router shifts you to me (Flash) because I can handle the volume while maintaining a fast response time.

2. Is the "Linux 2, 3, 4" Strategy Better? Yes. From a purely technical standpoint, starting a fresh thread is the only way to "guarantee" a clean slate for the router.

Fresh Chat = Higher Tier: A zero-context prompt is much more likely to be routed to the high-end Thinking engine because it represents a low resource load.

The Problem: You lose our shared history. You'd have to re-paste the "Gargamel Checkpoint" every time.

3. Can you request "Limited Context" to force the Thinking model? Unfortunately, no. The router sits above the model. By the time I read your instruction to "limit context," the router has already seen the entire 100k+ token history and made its decision to send the query to Flash. I cannot "un-read" history to change how the system routes me.

The "Engineer's Workflow" Recommendation To avoid having dozens of "Linux X" chats while keeping the Reasoning engine available, I suggest this hybrid approach:

Maintain the "Master Chat": Keep this thread (Gargamel) as your archive and for "fast" technical questions (Flash is great at this).

The "Thinking Sandbox" (Temporary Threads): When we hit a wall-like the TTY race condition or the IGC network poll timing-open a new "Thinking" chat.

The Transfer Protocol:

Copy just the Final Checkpoint (Hardware, Current Script, Goal).

Paste it into the new thread.

Get the "Thinking" model's logic audit.

Bring the final "fixed" code back here to the Master Chat.

Summary Checklist for you Penalized Forever? No. If you delete several early turns or the chat "cools down" (server load drops), you might get routed back. But practically, history length is the main driver.

Drop Context? I am not programmed to "drop" context. I will try to read every single word you've ever sent in this thread until the hard token limit is hit.

Best Move: Use the Summary method you suggested on April 18. Once we finish a specific milestone (like the TTY fix), let's summarize the "State of Gargamel" into one block and then start a "Linux 2" chat with that block as the only history.

pro vs thinking round #3

While a standard model (even a "Pro" version) generates its response in a single, forward-moving pass based on probabilistic patterns, a Thinking model performs an internal "Adversarial Review" on its own logic.

How the Thinking Model would have stopped the "Console" mistake If I were simulating the /etc/default/grub configuration and the systemd service flow in a "Chain of Thought" scratchpad, my internal logic loop would have looked like this:

Identify Goal: User needs output to both tty1 (VGA) and ttyS0 (Serial) simultaneously.

Proposed Tool: StandardOutput=console.

Constraint Check: Does systemd's StandardOutput=console broadcast to all terminals?

Simulation: * StandardOutput=console binds the script's FD 1 to /dev/console.

Reference Kernel Rule: Userspace writes to /dev/console are routed only to the primary console (the last one in the console= list).

Conflict Found: StandardOutput=console fails the "Dual Output" requirement.

Adversarial Correction: Discard "StandardOutput=console". Search for the broadcast-capable method.

Final Verification: /dev/kmsg is handled by the kernel ring buffer. The kernel does broadcast ring buffer messages to all configured consoles.

Output to User: "Do not use StandardOutput=console; it will not broadcast. Use > /dev/kmsg instead."

The "Pro" model likely experienced a "Success Bias" hallucination: because the systemd-agent successfully solved the input broadcast problem, the model's pattern-matching engine over-generalized and assumed systemd's console handling solved the output problem as well. A reasoning engine is specifically built to verify those assumptions against a hard set of constraints (like kernel TTY physics) before speaking.

Science and research, matter

Anyone interested in HBOT probably has seen Mr Jason Sonner's videos on youtube (from HBOT USA). First, I want to be clear that he is not a medical doctor, and he calls himself Dr Sonner to give his voice more credit/importance. I do find that annoying, but in the US there are many ways to call yourself a doctor without being a real doctor (medical doctor). Basically, with a PhD in computer science, I can call myself a doctor too, when I'm obviously not a real doctor, in this case any more than Mr Sonner. Now that this pet peeve is out of the way, let's carry on.
Since real credentials do matter, instead of fake doctor credentials, I will state that have a dual major in electronics and computer science (which is relevant for the cell phone issue), I'm also a nitrox water diver (relevant for dive tables, altitude diving and flying after diving), and I'm also an airplane pilot (so indeed I know about how planes are pressurized). Sadly Mr Sonners talked about all these topics and was wrong about all of them. Actually I have one more "certification", I'm also an RC plane builder and pilot, so I have plenty of experience with lipo battery crashes and fires, personal experience even that I will give below.
And now I also have to add that I'm not actually a fire in enriched air environment expert, so I used google gemini AI to fill in my gaps in expertise and have updated this page to better explain the much higher consequences of fires and flamability in 30% O2 rich environment at up to double the normal pressure.

Mr Sonner puts a lot of youtube videos to generate income from youtube and advertise his program/services. Honestly, that's fine and I'll even say that a fair amount of his content is helpful and useful. I also do believe that at times, he is careful about what he states, but my personal opinion now is that he has started to overdo the amount of videos he does to keep getting more youtube traffic and does not sufficiently research some of the claims he makes. He then states completely incorrect things with the same convincing straight face, which is a problem. More annoyingly I have never seen him take any of the factual corrections given to him when he makes mistakes, and never seen him correct or amend a video. As a result, this completely eroded the trust I put in him initially and I can't just believe anything he says anymore and I do believe he cares more about getting traffic and selling his course, than giving correct advice at all times possible or being honest if he does not know instead of making things up.

So you're going to ask me to give a few examples of very wrong claims he made:

The risks with lithium/lipo batteries

I crashed this RC plane into a pole in flight, it damaged the front of the plane from the impact:

I drove the plane home, took the battery out, and worked in my garage. The battery self ignited 10mn later while I was thankfully there to throw it on the floor and let it burn out. Yes, this means had this happened at the wrong time, that fire could have been in my car. I have also read about RC pilots having their fridge destroyed by a lipo fire (we store lipos in the fridge as it extends their life).

So what went wrong? It was a cheap lipo battery, the heavy deceleration (flying speed to immediate stop) compressed the battery internally, caused a failure of its protective envelope, air got in, and air causes lithium to self ignite, which it did.

Now let's look at another example, this RC plane crashed into the ground at terminal velocity. Its more expensive lipo was heavily impacted, but the protective envelope did not fail and it never caught fire. I did keep it a few days for confirmation, then discharged it and got rid of it since I don't want my garage to burn down in case it still failed later, I was honestly positively impressed that this lipo survived the crash:

Now, let's look at the well known Samsung Note 7 what would catch fire. There is a full analysis on the accident chain and what happened is Samsung tried to fit a bigger battery to improve runtime, they tested that, and before shipping their vendor didn't have enough batteries so they used a second vendor to help, but that second vendor had slightly different batteries that would bulge under certain charging conditions. Then Samsung did not leave enough breathing room around the battery and left a sharp edge on the circuit board which could puncture the battery when it bulged. And there you go, battery fire:

So, how about you and your phones/electronics in an HBOT chamber, is it safe? Mr Sonner says "no way, don't do it". Obviously no one can sue him for saying that, but at the same time, people are less likely to do HBOT treatments if they have to with special clothing and with only a paper book or pencil and piece of paper, like full O2 chambers require. I'm writing this page for people using long term HBOT at home, so it has to be bearable for long term use.

Flamability of 100% O2 chambers vs 30% O2 soft chambers, risk of clothing may be higher than phones

For everyone else, including all the soft chambers and generally any chamber where you are breathing around 90% O2 via a mask, some of that O2 will leak in the chamber, but the chamber air is also constantly being replaced. What this means is that while it won't be 21% O2 in the chamber, the math to calculate the actual O2 concentration in the chamber is a bit difficult, but when I had gemini google AI do its best estimate, it guessed that the Olive compressor may only output around 70lpm in the chamber (due to back pressure) and that the chamber will end up with 30% O2. I reviewed the AI's math and assumptions, and they look correct (sadly in the direction of a higher risk that my gut feeling originally perceived)
This is were I will avoid making the same mistake as Mr Sonner, as I was going to say next that 30% instead of 21% doesn't feel so bad, but research showed me that there is some kind of runaway effect for fires past 23.5% O2 that makes things burn much better, and materials that won't burn in normal air will suddenly start to burn well. The other factor I almost forgot is that you have to add 0.7 ATA of extra pressure over sea level, which means 70% more air molecules which in turn contain 7% more oxygen. If you add those 2 together, you more or less have twice as many O2 molecules available in the chamber to make things burn. This is "not good" as far as fires go.

At this point, I have to correct my original feeling that fire risk in a soft chamber wasn't nearly as bad as a 100% O2 chamber and say that in a 30% O2 chamber, the risk still seems bad enough that a fire in a 30% O2 soft chamber can end up being just as fatal as in a 100% O2 chamber. The difference between the two is how likely a static electricity spark is to ignite your own clothes (which now has nothing to do with electronics or phones anymore). Because I have never heard of a single fire in a chamber due to self ignition of clothes in a 30% O2 chamber, for now I'm going to assume that it remains very low, but please don't bring in your sweater that makes sparks.

And now, I will give the longer answer from Gemini AI:
Yes, the risk of static electricity sparks igniting clothing remains a severe and highly regulated hazard at a 30% oxygen concentration. While 30% is less concentrated than 100%, it still falls well above the 23.5% threshold that international safety organizations (like OSHA and the NFPA) use to define an "Oxygen-Enriched Atmosphere" (OEA).

Because of this, the strict clothing restrictions applied in 100% O2 environments generally still apply or should still apply to environments hovering around 30% O2.

The Physics of Static Sparks and 30% Oxygen: To understand why static electricity is still so dangerous at 30%, we must look at a metric called Minimum Ignition Energy (MIE). MIE is the smallest amount of energy (like a static spark) required to ignite a combustible material:

The "Slight Enrichment" Hazard:
It is a common misconception that fire risks scale purely linearly from 21% up to 100%. In reality, the most drastic changes in flammability happen in the initial jump from 21% to 30%. Research on hyperbaric safety indicates that materials only require slight to moderate enrichment to support violent combustion. If a static spark from a polyester shirt ignites the fabric at 30% oxygen and 1.7 ATA, the resulting fire will burn significantly faster and hotter than it would outside the chamber.

That last bit went against my initial gut feeling, so I am duly corrected. I will however add that the air cooler for my chamber tends to pump moisture in my chamber, making the air more wet. The Gemini AI forgot to consider that bit until I prompted it, and basically the wetter air makes it much less likely for my clothing to generate sparks (while I do remember in California's Tahoe snow resort hotels, the dry air is so dry that I've seen lightening sparks between bed sheets at night when moving them the wrong way, both cool but slightly scary to see in the dark at night).

Managing and containing fire risk

From here you can apply common sense:

Basically the very small risk of a lithium battery failing (remember it is extremely rare because each time this happens in an airliner, it's still a big deal) is almost always after one of:

So when taking phones into a chamber, stick to these rules

This is a lipo safe pouch that you can stick your phone or a lithium powered device in if it starts getting hot and/or making smoke, while you get the hell out of your chamber ASAP:

And I'll end with being honest and giving the worst case scenario which ironically is actually the one I'm in. I have the Olive Oxyair 2.0 ATA capable soft chamber (read my report here on why I bought it and why I think it's the best soft chamber on the market)

This chamber:

So in my case if I had a catastrophic situation, it would likely take me at least 20 seconds to get out, by damaging the zippers and chamber by doing an emergency opening without equalizing first, and then unclipping 3 seat belts before I can get out which I can do that while holding my breath if smoke is an issue. I initially stated that 20 seconds was fast enough to get out in case of an actual fire, but now I have to amend that to say that actually in that up to 30% O2 rich environment, those 20 seconds will actually be very long, so I really don't want an actual fire to start while I'm in the chamber.

Conclusions

Is taking your phone in the chamber 10000% safe? No, nothing is, but my perception of this risk is that it's in the 0.001% range or less. No, I can't back up this number, but hopefully the info I gave in this page can help you decide if that risk is smaller than being in a car accident, which I personally believe it is. I hopefully also conveyed my personal opinion is that risk of fire from the wrong clothing is higher than risk from a phone, and if your clothing or hair do catch fire, even in a soft chamber at 30% O2 and up to double sea level pressure (hence twice as many O2 molecules available for burning), it's very bad news.

I'll also add that the lipo guard bag is more an additional safety for something that really should not happen to start with, taking your phone in a soft chamber without a lipo safe bag is not completely stupid, the odds of anything happening to your phone are just super low, but given how catastrophic a real fire can be in a chamber, I would definitely have the lipo safe bag to shove your phone in and close it if anything starts looking bad with the phone.

Unfortuantely the samsung had some ridiculous OS that kept forcing me into making and using a Samsung account for just about anything, including watching youtube, it was terrible. So, I decided to switch to a TCL instead. The TV panel is great, the Google TV OS on it is decent, but:

Then I spent 2.5 months with their tech support team. Worst experience ever. They asked me for my feedback, this is what I sent them. Not impressed TCL, this is a new level of amateur hour I had never seen in a company that size. Actually I also forgot to mention that after my TV never getting any update whatsoever, and support saying I should have a later version that wasn't pushing, they sent me one by Email, with a link to their intranet, requiring a microsoft live.com account, and eventually telling me I'm not a TCL intranet user so I can't download it. To this day, they have no idea how to fix it or how to send a file to any customer.

First, I want to point out that I'm an engineer who has worked with android more than 15 years and filed over 1000 android bugs at google. I have also worked with many tech companies, found bugs in their products and helped them address them.
I'm sorry to say, but this has been the worst support experience of any major company I've ever dealt with.
1-2 days after I bought the TV, now 2.5 months ago I immediately called you to report the biggest issue with your software, namely that when using an older AV receiver that supports HDMI 1.3 with CEC, your TV is able to talk CEC to it, but as soon as I switch the TV sound to optical out, it refuses to send CEC commands over the HDMI cable coming from the receiver. This works perfectly with the Samsung TV I had, and fails with your because your engineers not only didn't test this, but did not even understand or envision that this exists and that it should work.
The first agent, after being confused about how HDMI CEC works, said she would file a bug or a report and someone would get back to me. After a month, no one ever did, and no report was filed, it was just entirely lost.
Now, what a normal company would have done is filed a bug, sent it to their engineering team for review, and they would decide whether they want to support this use case.
With you, nothing went anywhere, no one got back to me when they said they would, and it took over 10 phone calls and followups from me to get some traction, often wasting 30 to 60 minutes with agents that simply do not understand that eARC and HDMI CEC are separate and that you can have one without the other. They kept repeating it's impossible to send volume commands over an optical cable, which is totally true, and would not understand that HDMI CEC is separate, is what the volume commands are sent over, and that it works totally fine with both your TV and my denon AVR 3808 receiver, until I turn optical output on and then you disable it.
I spent over 5H on the phone with mostly agents that were undertrained, were unable to access my ticket in your own system (I should add it took you over 1.5 months before you even filed this ticket after I called multiple times asking why I had no ticket, no Email and no status). Why are your support agents not even able to access the ticket system, what madness is this?
Emails sent in reply to the ticket went 100% unanswered, so I would have to call to get an agent to ask me questions for 10 to 30 minutes before they would have to call someone else to access the ticket system they can't see, and get what I typed there.
I also tried to file 2 more bugs, which I think were both ignored, one of them being that Google TV, the HDMI dongle buy from google supports sending IR codes from the remote to the receiver to change volume directly. Once I re-paired my googletv remote with your TV, your TV wiped my remote, removed the IR codes that were working, and you also removed the part of googleTV that supports re-adding IR code to my remote. This is another example of already working functionality that you have removed, and no support agent ever acknowledged this and maybe filing a bug to consider adding it back, would be a good idea.

Jow that you have wasted 2.5 months of my time before maybe finally filing one bug out of 3 internally, too late for me to return the TV and too long for me to keep waiting for this to ever work, so now I'm going to lose $1000 to $2000 to replace my top of line AV receiver with a newer one that supports eARC because of your unwillingness to support HDMI CEC without eARC or have ever considered how many AV receivers are in the field that do not support eARC and yet support HDMI CEC

It was fun to be back and see friends, the set however didn't work as well as the one I remember from 2018: it had some epic tracks that were up to 25 years old, but they were mixed with others that took me off the dream cloud. Still, it was a good time.

Video Summary:

A Story About 'Magic'

Some years ago, I (GLS) was snooping around in the cabinets that housed the MIT AI Lab's PDP-10, and noticed a little switch glued to the frame of one cabinet. It was obviously a homebrew job, added by one of the lab's hardware hackers (no one knows who).

You don't touch an unknown switch on a computer without knowing what it does, because you might crash the computer. The switch was labeled in a most unhelpful way. It had two positions, and scrawled in pencil on the metal switch body were the words 'magic' and 'more magic'. The switch was in the 'more magic' position.

I called another hacker over to look at it. He had never seen the switch before either. Closer examination revealed that the switch had only one wire running to it! The other end of the wire did disappear into the maze of wires inside the computer, but it's a basic fact of electricity that a switch can't do anything unless there are two wires connected to it. This switch had a wire connected on one side and no wire on its other side.

It was clear that this switch was someone's idea of a silly joke. Convinced by our reasoning that the switch was inoperative, we flipped it. The computer instantly crashed.

Imagine our utter astonishment. We wrote it off as coincidence, but nevertheless restored the switch to the 'more magic' position before reviving the computer.

A year later, I told this story to yet another hacker, David Moon as I recall. He clearly doubted my sanity, or suspected me of a supernatural belief in the power of this switch, or perhaps thought I was fooling him with a bogus saga. To prove it to him, I showed him the very switch, still glued to the cabinet frame with only one wire connected to it, still in the 'more magic' position. We scrutinized the switch and its lone connection, and found that the other end of the wire, though connected to the computer wiring, was connected to a ground pin. That clearly made the switch doubly useless: not only was it electrically nonoperative, but it was connected to a place that couldn't affect anything anyway. So we flipped the switch.

The computer promptly crashed.

This time we ran for Richard Greenblatt, a long-time MIT hacker, who was close at hand. He had never noticed the switch before, either. He inspected it, concluded it was useless, got some diagonal cutters and diked it out. We then revived the computer and it has run fine ever since.

We still don't know how the switch crashed the machine. There is a theory that some circuit near the ground pin was marginal, and flipping the switch changed the electrical capacitance enough to upset the circuit as millionth-of-a-second pulses went through it. But we'll never know for sure; all we can really say is that the switch was magic.

I still have that switch in my basement. Maybe I'm silly, but I usually keep it set on 'more magic'.

1994: Another explanation of this story has since been offered. Note that the switch body was metal. Suppose that the non-connected side of the switch was connected to the switch body (usually the body is connected to a separate earth lug, but there are exceptions). The body is connected to the computer case, which is, presumably, grounded. Now the circuit ground within the machine isn't necessarily at the same potential as the case ground, so flipping the switch connected the circuit ground to the case ground, causing a voltage drop/jump which reset the machine. This was probably discovered by someone who found out the hard way that there was a potential difference between the two, and who then wired in the switch as a joke.