16 September 2026

Macbook Woes - Mutliple Monitor Problems

I started my day wasting yet another 30 minutes on getting my MacBook to recognize dual monitors again after being unplugged and used remotely at my dad's house yesterday. This has come to be expected behavior for Apple devices. It's a real shame these guys haven't figured out how to do this successfully yet. Perhaps they can contact the Linux community and ask them for help since my Linux laptops have this perfected. Who knew that the Just Works™ motto would be more applied to the open source community rather than to accompany the who had once inspired technology but has become stagnant and design and innovation since the loss of its founder 15 years ago?

When I got my first Mac, there were so many expectations of grand experiences which quickly fell short when I tried to use their GUI which oddly had inspired the Gnome desktop environment for Linux. I discovered quickly that I still needed to keep one hand on the mouse to accomplish most tasks, something that Gnome had made unnecessary to humans who knew how to do everything from just the keyboard. The first markings of inefficiency in the ample design were revealed. I have found it takes so much extra work to do simple things which the Linux community can do fluidly and seamlessly. 

I have to say that the Apple sheep fan base remains loyal to the company despite the creative drought. Their virtue is coupled with ignorant bliss since they don't really know what they are missing having never worked with Linux enough to see the nuances which make it better. Sadly, that blind perspective will keep them coupled with a company slowly cooking them in the frying pan. Perhaps one day they will burn out which might be the catalyst for them to break free of the rut of default acceptance to try something better. 

For me, I can take heart at the end of the day that I can close up my MacBook and go back to Linux and be most productive.

17 August 2024

Google TV Purchased Content Removed (Updated}

I decided today that I was going to go pick a movie from my library that I have purchased through Google TV. I have amassed quite a bit of content, and these movies are favorites. I actually have been going back through my library to watch some selections.

However, I was met with an empty library this afternoon when I pulled up the Google TV on my living room TV. It was empty. It still is empty. I did a complete factory reset of the device because all other partial attempts at removing cache and data didn't seem to make it difference. And the factory reset did nothing to help the situation. 

I don't know what Google is doing. I don't know what message they're trying to send. But this is the message that I've received: Don't buy digital media through them. I think the time has come for me to buy physical media for the things that I want to keep and the things that I think are my favorites.

Google TV providing movies and shows was a convenience, and I think that I knew it was never a permanence. Today, I have realized that very practical sense. Maybe it's the wake up call that I've needed. Maybe I need to thank Google for stopping me from wasting money with them. 

I have submitted feedback through the app about this particular situation. I'm sure it will fly under their radar, and any resolution will probably take several weeks or several months, if at all. But the precedence has been set.

----

Well, the library was restored as of Sunday. I'm guessing they had some issues over the weekend. My niece had also seen her pictures disappear from her Gmail account yet found them today (Monday). My perspective still stands as a valid reminder that what we purchase through streaming services is not always guaranteed to persist. There are plenty of other stories/articles about purchased rights for content changing requiring services like this to pull content.

12 July 2023

Revenge of the Nano

It's funny. I thought I had removed nano on my main system. Yet today, I typed sudo visudo to check the syntax of the file, and the file opened in nano. I was both confused and annoyed. I had removed nano from my system with extreme prejudice. (Ref: https://blog.mock.tech/2021/10/fedora-updates-remove-vim-default.html)

Indeed /usr/bin/nano persisted. Someone in the #fedora-social suggested rpm -qf `which nano`. It was from Fedora 34. Somehow, the package was still installed and left the cruft of nano behind.

So, with a swift rpm -e $(rpm -e `which nano`), I finally swept away the last remnants of that horrid editor.

Long live vim!

22 May 2023

Chat Etiquette

At work last week on our intercompany daily update, a post was made discussing chat courtesy. The original message was to convey that instead of sending a greeting and waiting for a response, send with the greeting a question. So, instead of this:

Joe: Hello.
Frank: ...?
Joe: How do I do this?
Frank: This is is how....

This is preferred:

Joe: Good morning, Frank. How do I do this?
Frank: This is how....

The post received a load of responses. Many initially applauded the idea calling the first behavior a pet peeve. Many others countered with the opposite approach of perhaps a greeting and then asking if now is a good time for a question.

I happen to agree solely with the author's approach of asking the question along with the greeting. But I noticed that the answers did not take other factors into consideration. I believe these other factors are these:

  • Assumed/understood behaviors
  • Audience
  • Efficiency

There are assumed behaviors of how the technology works. Chat or messaging is not equivalent to a phone call. Phone calls take more or complete attention to engage. Messaging was not designed to do that but to fill the gap of not interrupting someone's flow of work to get a response.

Messaging is not email, which has come to represent a document to be read and answered with a bit more time and attention put into it at a more convenient time. There is an implied delay with email in this culture almost to the point of considering it the same as snail mail.

Chat is a hybrid of these two: A more direct interaction than email without the complete interruption of a phone call (or video call). It's designed to be an efficient means of communicating.

The approach of the latter group in the above response pool, this is how they would prefer the messaging engagement to go:

Joe: Good morning, Frank. Do you have a moment for a question?
Frank: Sure.
Joe: How do I do this?

In this case, the question to ask a question is not only inefficient but also introduces the phone-call style interruption. Frank now has to take extra moments just to respond to the question to ask a question. But even when a question is posted in chat, there is assumed sometimes that there can be a delay.

Some of the responses included "ideas" of having a status of "unavailable," something which our messaging tool clearly has as a status indicator including a do not disturb option with even a place for text, e.g. "Busy until noon." Adding more to it would be redundant. I can also see when people are in meetings and not only that but when they are also presenting. The technology helps when the uncertainty of understanding of immediacy isn't obvious.

I think the audience also factors into this. With my team and more frequent conversation colleagues, I have no problem asking them messages even without a greeting. I would take a different approach with people I have never met or only have engaged a few times. Maybe a long time since the last interaction requires a greeting to renew the connection. There are different approaches to different people. I think the less familiar you are with the colleague, the more pleasantries.

Efficiency is the biggest factor as I see chat. If I can know what you want as soon as I see your message, the quicker I can respond. More than that, I'm less interrupted and definitely less derailed. There are some who just ping me with a greeting:

Joe: Hello.

I'm in the zone. My brain is deep into some logic and needs to stay on track. Waiting for a response from me now requires my full attention. (Phone call style interrupting in effect.)

Me: Yes?

I switch back to my train of thought to not lose it. Anywhere from a few second to a few minutes later comes the actual question. Now comes my second derailment...and aggravation mainly because it could have happened like this:

Joe: Hey, what's the name of the Python library we decided to use for the project?
Me: pandas

That entire engagement took at most 10 seconds to process and answer. Maximum efficiency achieved! I'm still in the zone. And if I choose to engage more on the subject, I can.

The first approach might seem kind, but here is what you are really communicating to me:

Joe: Hello. [I am more important than what you are doing so I need your full attention to me so I can ask even the simplest of questions.]
Me: Yes? [If you had asked the question, we'd already be done with this. You are now being selfish.]

I get that different people need more interaction and this one-line exchange seem rude. So, I think the best way to approach this is this way: When you engage me in messaging, be efficient. Ask the question without having me respond or pull it out of you. It might feel rude, but it won't be. It will be efficient!


15 March 2023

Fedora and Radeon HDMI Sound Issues

I have recently moved my desktop system into a rack mount case and rearranged my office. There were a few changes I ended up making because the rack case I ordered is a little short on depth. I ended up replacing the Gigabyte ATX motherboard with Intel CPU to a mini-ITX board with an AMD CPU which fits better. I transferred the hard drives and everything was working just fine...except for sound.

I spent a good bit of time tracking this down. The audio devices were recognized, the sinks were all operational (I could see activity on the meter in the sound settings), but there was no actual audio through the TV which was my monitory. All this had worked with the same equipment under the Intel resgeme.

My searching online provided no real help. I had a friend from the Fedora IRC support channel check things for comparison. But we couldn't find any real differences after two days. Being still frustrated had me checking Google results again.

I had found this page and started to look it over this morning: https://bbs.archlinux.org/viewtopic.php?id=256989. It got me thinking about Alsa configurations which are part of an older configuration possibly left over from upgrades. I had my friend check his /etc/modprobe.d/alsa-base.conf for what he had. He didn't. Mine had some options.

options snd-hda-intel model=generic

I commented that line out and rebooted. And that was the fix! Sound check was working again. Comment the options or remove the file for great justice!

28 February 2023

Better Logging for the Best Sleep

I enjoy my sleep. An uninterrupted night after completing a coding project and having it deployed into a production environment is some of the best sleep I can have.

Being woken in the middle of the night because my code is failing in production and the support team not knowing the cause is something I have learned over the year to try to address long before my head hits the pillow. My logging should help them understand if the problem is really bad code or really something else such as a network problem or bad data. Well constructed logging can point the spotlight on the right place to look.

I was going through logs of some automation software at work trying to find a flow to the process. I will admit I did not know the package that well, so I was trying to gain an understanding reading through the logs. I've found using an application's logs to be helpful to understanding how it works without taking a class on the software. This got me thinking about how I log my own code. I've been writing log statements for years, but I know I could always improve my own logging skills. The following aspects are a few things I've learned over the years.

Logging is communication

Relationships are always better with good communication. The clearer the communication, the better the relationship. Assumptions can be made when it comes to believing what the code is doing, and we all know what is said about assumptions. In fact, the logical flow one expects might actually be part of the problem which logging could reveal. Being explicit when logging to remove any guesswork will save so much time when troubleshooting. Log clearly and concisely. Get to the point.


Understand the levels

Logging generally has about five levels: Debug, Info, Warning, Error, and Critical. And most loggers allow for customizing these levels or even adding levels among these defaults. Knowing what goes into a general flow of knowledge when reading logs and what belongs at the debug level should be obvious, but it might take a little time to make those judgment calls. At the Info level, I normally want to give more of an overall stepping through the code at points which mark functionality so that a first pass of the logs can help me at least see where in the code it is failing. I will throw in more variables and values into my Debug level statements when I need to see beyond the obvious logic. Warnings are for giving notice of things to not do or things which could be done better. Errors should be obvious as are Critical responses.

Logging is documentation

To be clear, logging does not replace documentation. It is a form of documentation. It goes hand-in-hand with documentation. Instead of explaining how the code functions, it shows how the process flows. It's a real-time walkthrough of the logical execution of the code. It can tell the story of what the program is doing while you watch it play out before you. If you consider it a part of the of the documentation, how you construct the statements might vary a little from what might seem obvious when in the middle of coding.

Another idea is to combine the documentation with the logging. Sometimes it is better to put longer explanations and suggestions for solving in the actual documentation and use custom codes in the logging to direct the support team to text that will give them a better understanding of the causes and outline the solutions to take.

Write for a larger audience

Sawing logs is an expression defining heavy sleeping. But when someone in a support capacity who does not have an intimate knowledge of the code, what they have in the logs can be enough for them to know what is wrong or leave them confused even a little bit which will prompt a next level call to the development team and possibly the developer.

My approach to logging has always been to write it so that no one needs to call me in the middle of the night because they have reached a point where it cannot be solved by them. In most cases, other pieces in the system could be the cause and easily determined with clear logging. When certain common problems have been experiences, adjusting the logs to better pinpoint the place to check and even suggest a course of action can help keep notifications at bay.

Keep it safe

Logging is generally put on a protected file system (or it should be) and/or ingested by a secure logging service, but logging credentials is generally unnecessary. Login ids should be enough to know which credentials are being used. Sometimes connection strings logged as a lump of information. Measures should be taken to mask passwords in those blocks of strings. I've seen functions built to parse that output before it's put out to mask the sensitive information. Knowing again the audience who will view the logs should also be considered for this.


I'm sure more could be said about logging. Clear and thorough logging can keep you sleeping when your code is being reviewed by a support team. Support teams can do their jobs more efficiently and effectively with skilled logging. Developers who will manage projects you leave behind will herald you wise. It should be every developer's goal to become a master at logging.

18 February 2023

More Thought on Dell's Recent Battery Policy

After mulling over the situation for the past couple of days, I have considered another course of action if I want to keep purchasing Dell laptops: When I buy a new laptop, just add two replacement batteries to the cart to keep the life of the laptop going well past the five years they will support them.

This does not mean I am remaining exclusively with Dell has been my practice. Extra batteries from Dell are three times the perfectly good third-party replacements found on Amazon. I will be doing a little more investigation into other companies like Lenovo and HP. If they allow for generic replacement batteries to be used without a BIOS block, then they are definitely a better investment.

I did spend some time yesterday evening disassembling an official Dell battery (which was dead). I thought maybe I could either swap out the actual lithium-ion packs or extract whatever circuitry which identified the units as officially Dell. The batteries are not a something that can be simply disassembled. Neither of those theories were feasible.