This series is written by a representative of the latter group, which is comprised mostly of what might be called "productivity users" (perhaps "tinkerly productivity users?"). Though my lack of training precludes me from writing code or improving anyone else's, I can, nonetheless, try and figure out creative ways of utilizing open source programs. And again, because of my lack of expertise, though I may be capable of deploying open source programs in creative ways, my modest technical acumen hinders me from utilizing those programs in what may be the most optimal ways. The open-source character, then, of this series, consists in my presentation to the community of open source users and programmers of my own crude and halting attempts at accomplishing computing tasks, in the hope that those who are more knowledgeable than me can offer advice, alternatives, and corrections. The desired end result is the discovery, through a communal process, of optimal and/or alternate ways of accomplishing the sorts of tasks that I and other open source productivity users need to perform.

Thursday, August 7, 2025

The AI revolution?

That's kind of a dramatic title, but an appropriate one for this blog and this post. I've recently discovered (yes, I've been living under a bit of a rock) AI and its possibilities for the kinds of tech projects I undertake. It turns out that, by using AI, my laborious process of trawling the internet for snippets of information related to the kinds of things I try to do with my computer may have come to an end. Yes, having AI at my disposal, I can have an always-available interlocutor to consult with on these topics, and one who is far more knowledgeable than me about computer coding.

The impact of this on this blog is that I will likely now be, instead of documenting my halting attempts and offering links to articles I've found, the posting of a lot of articles henceforth about scripts AI has helped me to create and related knowledge it has conveyed. I've already developed several scripts over the last few weeks and I keep thinking up more. In fact this post is being published partly by a script AI helped me to develop. True, its initial attempts at using the blogger API turned out to be a huge and fruitless time sink. I finally told it I was calling it quits after many hours of meeting one frustration after another--not necessarily totally the fault of AI, but due in large part to google's inhumanly complex way of expecting users to interface which seem calculated to deviously thwart the standard end user at every turn.

But I managed to get AI to help me develop a semi-automated way of posting using the method discussed in the last post I made here that involves using the xclip utility. In other words, I need to sometimes come to AI's rescue, paltry as my abilities are in this realm. And I've had to several times make suggestions to AI about how to do something or about some utility to use. In fact, I just had a frustrating session with AI trying to develop a working .asoundrc (yes, no pulse or pipewire here, just good old-fashioned alsa) that would allow me to send sound through my laptop's HDMI port. To offer a bit of gory detail, AI couldn't figure out (nor could I) why aplay could send sound via plughw while trying to configure .asoundrc with plughw devices would report that the relevant library couldn't be found.

But AI did provide me with a nice workaround for sending my laptop display out the HDMI port using xrandr, that solution leaving it to the video player (mpv in this case) to select the proper audio device for the sound. In fact, here's a nice bash script I asked it to develop for when I want to send the display through the HDMI port:


#!/bin/bash

# Find the names of your displays with 'xrandr'
# For a typical laptop, this is a good guess:
LAPTOP_DISPLAY="LVDS1"
EXTERNAL_DISPLAY="HDMI1"

# Present the menu
echo "Choose a display configuration (for mpv audio hit g-d keys & select alsa/hdmi once mpv has been started):"
echo "1) Extend desktop (external right of laptop)"
echo "2) Mirror displays"
echo "3) External display only"
echo "4) Revert to laptop display only"
echo -n "Enter your choice (1-4): "
read choice

# Execute the command based on user choice
case $choice in
    1)
        echo "Extending desktop..."
        xrandr --output "$EXTERNAL_DISPLAY" --auto --right-of "$LAPTOP_DISPLAY"
        ;;
    2)
        echo "Mirroring displays..."
        xrandr --output "$EXTERNAL_DISPLAY" --auto --same-as "$LAPTOP_DISPLAY"
        ;;
    3)
        echo "Using external display only..."
        xrandr --output "$EXTERNAL_DISPLAY" --auto --output "$LAPTOP_DISPLAY" --off
        ;;
    4)
        echo "Reverting to laptop display only..."
        xrandr --output "$EXTERNAL_DISPLAY" --off --output "$LAPTOP_DISPLAY" --auto
        ;;
    *)
        echo "Invalid choice. Please enter a number between 1 and 4."
        ;;
esac

By the way, I'm using mostly Google's Gemini so far. I've tried duck.ai as well, which I found to be a bit deficient although, on the positive side they don't seem to do geo-blocking like other services do. I also decided to try a paid service, github's co-pilot. Honestly, I've so far not seen its advantages as compared to Gemini. But I'm still quite new at this, so I may decide in the future to use some better alternative. Time will tell.

I've learned a bit about strategizing to get help from AI as well. I've discovered that I need to develop projects gradually, first coming up with a sort of simplified mock-up of a key part of what I'm aiming to accomplish, then asking it to build gradually on that. Describing to AI a complex project and its aims at the outset is likely to result in AI proposing a complex script, but experience has thus far shown that it will be so unwieldy and with parts so error-prone that it will turn out to be a nightmare to troubleshoot. Better to start off simplistically and build on working parts that can later be tied together.

I would say I stand to learn a lot about coding from AI. It's light years ahead of me when it comes to error-checking routines. I'm usually so focused on getting my tasks accomplished that I don't even think about those sorts of things. But I also suspect that AI doesn't implement sound code practices very well. Some of the scripts it has put together for me, so far as I can tell, have turned out to be horrendously complex monstrosities which, as I think of what they do and how they're designed, seem to me to string together too many routines and files into one. If I understand coding protocols at all correctly, I think these scripts should be divided up in a couple of smaller scripts and the data they produce should be turned into separate files. This is all pretty abstract without giving some concrete examples. But in future posts I should be posting here some of that code, which may give a clearer indication of what I think I'm getting at.

So stay tuned for those posts.

No comments:

Post a Comment