Forem: Ari Abramowitz

The Tale of the Flickering Monitors, part 2: You're (not) Grounded!

Ari Abramowitz — Tue, 26 Aug 2025 16:37:08 +0000

This is a followup to my previous post: The Tale of the Flickering Monitors. To recap, my monitors were blinking in strange and disruptive ways. The culprit turned out to be my treadmill, and spraying some water on it made the flickering stop. If that sounds like a head scratcher, welcome to my world.

After last weeks wild and crazy monitor adventures, I thought I would be done writing about computer screens and instead focus on what I generally try to use those screens for: work. But there were still some loose ends to tie up. Spraying the treadmill cut down the flickering, but it was only a temporary fix. Once the water dried, the flicker returned and I had to spray again. Not terrible, but not ideal.

Also, I wasnt wearing shoes and all of this spraying was making my socks wet, which is never a good thing.

At this point I knew the problem had to do with static electricity buildup. I figured the socks werent helping with that, so I tried putting my sneakers on. The flickering seemed to stop. That was good, but could I do better?

I searched around a bit more and discovered a whole community of people with similar treadmill-caused monitor flickering issues. Among them, this guy (flickering at 5:30):

https://youtu.be/-lTdZFEQPn8?t=223

I wasnt going to start playing around with wires the way he did (again, Im a software guy). And the static discharge bands didnt look like they would be any better than my current sneaker solution. But Mr. ElectroBOOMs talk about electrical grounding basically, giving stray electricity a safe place to go got me thinking.

There was something about my treadmills power cord that I had noticed a long time ago and then promptly ignored: the plug was not a standard Israeli plug (I live in Israel). To compare, below is a picture of standard 2- and 3- pronged Israeli plugs, next to the thing I found attached to my treadmill:

It was unusual, but I plugged it in and, hey, it worked. I hardly gave it a second thought. Until now.

I knew that the third prong on a 3-prong plug is usually meant for grounding, but this plug didnt have a third prong. It just had a metal strip going down the middle. Maybe that was the problem. I fed a picture of it to chatgpt. This time, it gave me some darned good information:

Ah this is actually a Schuko plug (Type F, common in Europe).

Its not just a 2-prong plug. The two round pins are live and neutral, and the metal strips on the top and bottom edges (you can see them on your photo) are the ground contacts. When you plug it into a proper Schuko socket, those strips touch the grounded clips in the socket and provide a full earth ground.

So your treadmill does support grounding its just that the ground is on the side rails , not a third pin sticking out.

Again, for comparison, below is a standard Israeli outlet (left) and a Shuko outlet (right):

The Shuko plug fit in the Israeli outlet. It was able to power the treadmill, just the grounding mechanism didn't have anything to attach to. I thought I might be on to something. I went back to Google and discovered the nifty product pictured below: a Shuko to Israeli plug adapter. I ordered one.

Shuko to Israeli plug adapters (https://shop.super-pharm.co.il/electricity-and-electronics/cables-and-adapters/electric-cables/----(Schuko)-----3---16A-/p/mp-00106831)

The adapter arrived a few days later. As a test, I turned on the treadmill one more time without the adapter. It was still flickering. So I attached the adapter, held my breath, and it kept flickering. Oh well. At least I had the sneaker solution. It beat the spray bottle, and I got to learn a bit more about plugs and outlets along the way.

P.S. While doing all of this, I decided to give my homemade docking station stand (mentioned in my last post) a slight upgrade so it looks a bit less like what it is: a piece of garbage. Well call this version 2.1:

]]>

The Tale of the Flickering Monitors

Ari Abramowitz — Wed, 20 Aug 2025 21:18:35 +0000

Like many software engineers and other professionals, I prefer having extra screen space when I'm working. At my desk in my home office, I have two external monitors that I use in addition to my laptops built-in screen. For the past few weeks, Ive noticed that one or both would occasionally flicker. The offending screen would turn off for a second or two, then turn back on, with everything still on the screen where I had left it. An annoyance I could work around, but when I touched the docking station that my monitors were connected to, I noticed it was very hot.

Thinking the docking station might be overheating, I built a cardboard stand for ventilation. My mother-in-law happened to be around and suggested upgrading to a piece of plastic food packaging. That became version 2.0 and it worked, at least for a few days. The docking station got a bit cooler and the flickering seemed to taper off.

Versions 1.0 and 2.0 of my homemade docking station stand

Yesterday, however, the flicker frequency suddenly picked up dramatically. The screens would blink multiple times per minute, interrupting my work and making them essentially unusable. The problem had to be re-addressed.

I had run into a similar issue about a year or two earlier. Somehow the mysterious flickering had been resolved, but I did not remember how - if it disappeared on its own, or if I found a fix, or what that fix might have been. Unfortunately, two weeks prior to the more recent incident, my group lost a large portion of our Teams chat history due to unrelated and unforeseen circumstances. I was on my own.

My first thought was to make sure this didnt happen again next time. I started a new page in Notion so I could jot down whatever I was about to find out.

I thought this still might be an overheating problem, so I found a small fan and pointed it at the docking station. It made no difference. The flickering continued apace.

Then I got to work trying to isolate where the problem was really coming from. I swapped out my work laptop (system76, popos) for my personal one (lenovo, kubuntu), and the flicker continued. Whatever was happening probably did not have to do with the laptops hardware, since it persisted on two different machines. And if it was a software problem, it had to be something affecting both laptops.

I posted about the problem on my groups Teams channel. Someone asked if I had done any system updates recently that might have unintentionally caused the problem. I hadnt certainly not anything that would have affected both computers. Still, I thought Id try switching Linux kernels. (For context: in Linux, the kernel is the core of the operating system. Hardware-related bugs sometimes appear or disappear between versions, so trying a different kernel is a common troubleshooting step.) However, I knew that finding the right kernel might turn into a wild goose chase, assuming that was the problem at all. So before going down that path, I searched around and found a suggestion to tweak some Intel driver frame delivery settings (https://www.reddit.com/r/Ubuntu/comments/1cfzjpj/comment/lpc77o7/). Unfortunately, that didnt help.

So I moved on to kernel hoping. I tried 5 different versions (6.0.19, 6.5.6, 6.8.12, 6.12.42, and 6.16.1), but the flickering persisted across all of them.

From there, I launched into a long back and forth with chatgpt. It suggested checking logs from various sources on my machine, using journalctl and dmesg. Nothing particularly insightful came from that. It then suggested updating the linux-firmware on my machine. I dutifully obliged. The flickering dutifully continued.

I then tried to clarify that chatgpt understood what I meant by flickering, realizing that the term could refer to different screen-related issues which might stem from different causes. It did understand. It just couldnt figure out what to do about it.

At some point in all of these attempts, I noticed that the flickering followed an odd pattern. I normally stand when I work, and I have a desk treadmill that I use so I can walk at the same time. The flickering only happened when the treadmill was turned on. Strange, but consistent. The easy solution, without understanding what was happening, would be to stop using the treadmill. Of course, I didnt want to do that, and I had been using the same treadmill and monitors for nearly four years with (almost) no issues. Why had the flickering suddenly jumped today?

I told chatgpt about the treadmill epiphany and it started talking about electromagnetic noise and voltage dips. This was not my area of expertise, but I stuck around for the ride. It suggested rearranging the cables or moving the treadmill to another room (which would obviously defeat the purpose of a desk treadmill, but what can you expect from an LLM that doesnt have to worry staying active during the workday?). I moved a bookcase to gain access to a separate outlet that I could plug the treadmill into. I threw in an extension cord and attached it to an outlet in the bathroom across the hall. Still no difference. The flickering continued.

Chatgpt recommended several other pieces of hardware I could buy that might (might) solve the problem a more well shielded HDMI cable, an Uninterruptible Power Supply (or UPS), or a line conditioner but I was hesitant to do any of these things not really knowing that they would solve the problem. It suggested twist[ing] the cable on itself. Easy enough, but also ineffective.

Finally, I went back to Google and updated my search: monitor flickering when treadmill on. The first result led me to a reddit user with the same brand of treadmill, complaining that their screen flickers when the treadmill turns on:

I just bought a walking pad so that I can work while getting my steps in. I was super excited to get started, only to realize shortly after that walking on the treadmill while using the computer causes my monitors to flicker

Update: I have found a silly, but useful solution to this problem. I figured that the issue was caused by static electricity. I googled how to get rid of static electricity, and it said to create more humidity in the room. I have a spray bottle of water, and I just spray it on the track of the treadmill. Dont spray too much so that youre slipping and sliding, but just enough that it is a tiny little bit wet. This is seem to solve the problem for me. Ill probably get a humidifier.

https://www.reddit.com/r/Monitors/comments/10jfbfh/monitors_flicker_while_using_walking_pad/

And then it hit me.

A few days earlier, I had discovered some mold growing in my office. Among the measures that I took to address that, I put a *de*humidifier in the office. By now, the dehumidifier had been sitting there for just about 24 hours and, together with the treadmill, created the perfect atmosphere for screen flickering. I had found the answer.

I found a spray bottle, and sprayed a bit of water on the treadmill. The flickering stopped.

And with that, I was back to my regularly scheduled programming (pun very much intended).

Part 2 (theres more!?) here: https://ariabramowitz.me/the-tale-of-the-flickering-monitors-part-2-youre-not-grounded

]]>

Linux Boot Trouble: "Gave up waiting for root file system"

Ari Abramowitz — Sun, 04 May 2025 19:39:50 +0000

I recently ran into the error above while trying to start up my dual-boot Lenovo laptop (Kubuntu + Windows 11). These are the steps I took to fix it.

Starting with this SO post, I did the following:
Ran sudo file -s /dev/sda3 to check the filesystem type. Output was data, suggesting this was likely not the right partition. No other partition seemed to be the one I was looking for.
Went to BIOS to check various settings
Went to Lenovo boot menu and selected Ubuntu was able to start up (?!)
Ran the following to reinstall GRUB Bootloader:
Ran cat /etc/fstab to make sure things looked right:
Saved a backup of my fstab in case this happens again:
Rebooted the laptop to see if the fix held:
Removed several old popos entries in the laptops boot order. Not clear if those had anything to do with this, but cant hurt to remove

]]>

Python Operator Chaining… and why you still can’t trust ChatGPT

Ari Abramowitz — Sat, 08 Mar 2025 19:04:10 +0000

A colleague of mine recently posted the following on a Teams channel which we’ve appropriately named “Something cool I learned today!”:

"a" in "abc" is True will evaluate to False (!)

This is because the [Python] interpreter reads this as "a" in ("abc" is True), which is the same as "a" in False.

The first problem with this, which I did not catch until later, is that "a" in False does not in fact evaluate to False. It raises an exception because False is not iterable so the in operator does not work:

"a" in False

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument of type 'bool' is not iterable

Having overlooked that issue, I was about to respond with this link giving more details about operator precedence in Python. However, after looking more closely at the explanation there, I noticed something else: in and is have the same precedence and have left-to-right associativity (they get processed left-to-right). Following that, I would have expected the example to evaluate to True:

"a" in "abc" is True # -> ("a" in "abc") is True
"a" in "abc" # -> True
True is True # -> True

But when I actually ran the code, it returned False.

Something wasn't lining up, so I decided to do some more digging. I started with a conversation with ChatGPT that went something like this (full thread here - https://chatgpt.com/share/67c629cb-38e8-8013-8daf-290abec2600a):

Me: Hey, ChatGPT, what's going on here?
ChatGPT: Simple. It’s operator precedence.
Me: But don’t is and in have the same precedence?
ChatGPT: Good point. This should evaluate to True.
Me: But it doesn’t.
ChatGPT: Oooohhh. Riiiighht. It’s operator chaining.

This was a good reminder that ChatGPT is still not a Python expert. I would have expected it to catch both of the points I mentioned above, unravel the incorrect assumptions, and then give the correct explanation. Instead, it gave a misleading answer and only corrected itself after two rounds of prodding. Oh well.

Needless to say, my conversation with ChatGPT was not the most confidence-inspiring one I’ve had in my life, so I went to Google next. I found a Stack Overflow post with a similar question and the same explanation that ChatGPT eventually gave: https://stackoverflow.com/questions/31487806/a-in-abc-true-evaluates-to-false

Essentially, because of "operator chaining" the example above, "a" in "abc" is True, translates to the following:

'a' in 'abc' and 'abc' is True

Since "abc" is not True, the right half of the expression, and thereby all of it, evaluates to False.

This is similar to how Python evaluates 1 < 2 < 3 as (1 < 2) and (2 < 3). Alternatively, using the example from the Python docs:

x < y <= z is equivalent to x < y and y <= z

I had known about this rule generally, but did not realize it applied in a case like this.

Lessons learned:

If two or more comparison operators are "chained" together, Python inserts ands between them to interpret what's going on.
- "Comparison operators" include: <, <=, >, >=, ==, !=, is, is not, in, and not in
ChatGPT is not a Python expert... yet.

For more on this, check out these links:

GeeksForGeeks on operator precedence: https://www.geeksforgeeks.org/precedence-and-associativity-of-operators-in-python/
Stack Overflow on the example covered here: https://stackoverflow.com/questions/31487806/a-in-abc-true-evaluates-to-false
Python docs on operators: https://docs.python.org/3/reference/expressions.html#comparisons
PEP 535 – Rich comparison chaining: https://peps.python.org/pep-0535/

Python Imports and Module Caching: Behind the Scenes

Ari Abramowitz — Sat, 08 Mar 2025 18:59:21 +0000

This is another post based on Dr. Fred Baptiste' Python 3: Deep Dive series. For more, head over to Udemy.

What happens behind the scenes in a python import statement? Glad I asked. Here's how it works:

Check sys.modules: Python first checks sys.modules to see if your module has already been loaded.
- sys.modules is a regular python dict that is used to cache modules. The keys are strings of the modules' names and the values are module objects (i.e. objects of type ModuleType)
- If your module is already in sys.modules, python adds the cached version to globals() and skips the steps below.
Create a module object: If python does not find the module in sys.modules, it creates a new ModuleType object and loads the module's source code into it
Cache the module: The new module objects is added to the sys.modules cache
Compile and execute: Python compiles and executes the source code from your module
Add to globals(): Python and adds your module to globals(), making it available for use going forward.

Key Point: It is often said that importing a python module will execute all of the code in the module. That is only partly true. Python only executes a module the first time it is imported, then caches it in sys.modules. Subsequent import statements throughout your code, even in different files, will refer back to the cached version and will not execute the module again.

Below is a bit of code to bring all of this home. We will:

Create a simple module (module1) with a print statement so we can see when the module gets executed.
Import module1 into main.py, which will execute module1.
Delete module1 from globals(), then try accessing it to demonstrate that it is no longer available.
Re-import module1. This will add module1 back to globals(), but will use the cached version from sys.modules and will not re-execute module1.
Access module1 again to demonstrate that is has in fact been added back to globals()

# module1.py
print("Running module1")

# main.py
print("======== Running main.py ======== ")
print("Importing module1")
import module1
print("Deleting module1")
del globals()["module1"] # Deletes from globals(), but not from sys.modules
try:
    print("Accessing module 1 after deleting from globals()")
    # This will cause an exception. module1 is still cached in `sys.modules`,
    # but the reference to the cache has been removed from globals()
    module1
except NameError as e:
    print("NameError", e)
print("Re-importing module1")
# Adds the cached version of module1 back to globals(), without
# re-executing the module
import module1
print("Accessing module 1 after re-importing from globals()")
module1
print("Done!")
print("=================================")

Output from main.py:

======== Running main.py ========
Importing module1
Running module1
Deleting module1
Accessing module 1 after deleting from globals()
NameError name 'module1' is not defined
Re-importing module1
Accessing module 1 after re-importing from globals()
Done!
=================================

Namedtuple Default Values

Ari Abramowitz — Sat, 08 Mar 2025 18:53:47 +0000

I've been making my way through a deep-dive python series on Udemy (I highly recommend it - Python 3: Deep Dive by Dr. Fred Baptiste). The course recently touched on the question of how to set default arguments on a namedtuple. I found out afterwards that as of python 3.7 namedtuple has a defaults argument (see the docs), making the following neat little trick largely irrelevant. We'll pretend that doesn't exist for the moment.

Dr. Baptiste's way around the problem relies on the __new__ method and the __defaults__ property, neither of which typically get much air time:

__new__ is a built in method on all classes. It creates an instance of the class (before __init__ gets called)
__defaults__ is a property on all functions that stores the default values, and it's writable
- if there are fewer defaults than function arguments, the values get "right aligned". See the screenshot:

If you're on python 3.7+, stick with the built-in option. If not though, good to know you can do this:

from collections import namedtuple

Point = namedtuple("Point", ["x", "y", "z"])
# Defaults `y` to 2, and `z` to 3. `x` has no default
Point.__new__.__defaults__ = (2, 3)

print(Point(1))
# Point(x=1, y=2, z=3)

Python Decorators: How They Work and How to Write One

Ari Abramowitz — Sat, 08 Mar 2025 18:42:03 +0000

This is a dev talk I gave back in February 2023 at Centers Healthcare explaining how python decorators work and how to write one. Enjoy!

Python Imports and Module Caching

Ari Abramowitz — Tue, 14 Jan 2025 22:00:00 +0000

This is another post based on Dr. Fred Baptiste Python 3: Deep Dive series. For more, head over to Udemy.

What happens behind the scenes in a python import statement? Glad I asked. Heres how it works:

Check sys.modules : Python first checks sys.modules to see if your module has already been loaded.
Create a module object: If python does not find the module in sys.modules, it creates a new ModuleType object and loads the modules source code into it
Cache the module: The new module objects is added to the sys.modules cache
Compile and execute: Python compiles and executes the source code from your module
Add to globals() : Python and adds your module to globals(), making it available for use going forward.

Key Point : It is often said that importing a python module will execute all of the code in the module. That is only partly true. Python only executes a module the first time it is imported, then caches it in sys.modules. Subsequent import statements throughout your code, even in different files, will refer back to the cached version and will not execute the module again.

Below is a bit of code to bring all of this home. We will:

Create a simple module (module1) with a print statement so we can see when the module gets executed.
Import module1 into main.py, which will execute module1.
Delete module1 from globals(), then try accessing it to demonstrate that it is no longer available.
Re-import module1. This will add module1 back to globals(), but will use the cached version from sys.modules and will not re-execute module1.
Access module1 again to demonstrate that is has in fact been added back to globals()

# module1.pyprint("Running module1")# main.pyprint("======== Running main.py ======== ")print("Importing module1")import module1print("Deleting module1")del globals()["module1"] # Deletes from globals(), but not from sys.modulestry: print("Accessing module 1 after deleting from globals()") # This will cause an exception. module1 is still cached in `sys.modules`, # but the reference to the cache has been removed from globals() module1except NameError as e: print("NameError", e)print("Re-importing module1")# Adds the cached version of module1 back to globals(), without# re-executing the moduleimport module1print("Accessing module 1 after re-importing from globals()")module1print("Done!")print("=================================")

Output from main.py:

======== Running main.py ========Importing module1Running module1Deleting module1Accessing module 1 after deleting from globals()NameError name 'module1' is not definedRe-importing module1Accessing module 1 after re-importing from globals()Done!=================================

]]>