The Custom Script

It has been two months since I moved to Central Europe and there are some improvements I need to make to my work station.

My current status as a remote worker allows me to work from anywhere and after my last move I have decided I have to keep under control the amount of stuff I own.

Although so far I am not being very successful at it, my work station responds to this necessity.

I began only having laptops which can be moved around in a backpack.

To this I added a portable screen to increase my much needed monitor space, a keyboard, a ball mouse and a laptop stand I am using to bring the main display to the level of my eyes.

(I have added Amazon affiliate links in case you want to support this blog and are interested in a similar setup, so far I am happy with these products and can recommend them).

This is more of need than preference, recently my ergonomics have been sub-optimal and I have developed some neck pain problems which I expect to solve with this new setup.

This new keyboard has the US key layout while my personal laptop uses ES.

In the spirit of what we discussed in Points Of Presence, I decided to add a customization to my environment to automatically change from one layout to the other.

I used AI to do it of course, via a CLI tool called OpenCode with Big Pickle to be exact.

The first attempt was going to be a Plug-And-Play docking solution.

The initial requirements stated that when the new keyboard was plugged in, the system was going to detect the udev ID of the keyboard, and execute a script that would disable the laptop keyboard and change the key layout from ES to US. It required some dependencies to be installed using root privileges.

Big Pickle implemented a udev rule and a couple of scripts to do this, it also identified the location in my system in which to install it and created a Makefile with the right instructions to use it and deploy it.

These are the capabilities of a free model in 2026. I paid nothing for any of this with anything other than my data, my feedback and my time. I spent more time trying to understand what it was doing and writing this article than generating these artifacts.

I didn’t get to run any of this, instead a silent voice inside my head whispering to me to make it simpler.

This is probably that thing which some people call intuition, seniority, experience or taste.

Maybe the pain and fear of past trauma of facing mastodons of prideful monolithic complexity overengineering their way into what the internet has come to call slop or slopware, ignorant of the trade offs that complexity brings.

Whatever it was, that is what I told the AI. I reviewed my requirements. I did not need nor really wanted a plug and play solution with automatic detection and hardware deactivation, I just wanted a command to change between key layouts so that I didn’t have to click my way into changing that option.

This returned a correct bash script that did exactly what I wanted, but I was not satisfied, I knew we could still make it simpler.

What I really wanted was a state machine that reads the value of the current key layout of the system, if ES it would go to US, if US it would go to ES. And for the escape condition it would just do nothing. This is basically an ES/US switch.

Then I asked to make it simpler. I did not want to manage script files, I wanted an alias for the terminal.

The end solution was this one-liner.

alias kbd-toggle='C=$(gsettings get org.gnome.desktop.input-sources sources); case "$C" in *"'\''us'\''"*) T=es;; *) T=us;; esac; gsettings set org.gnome.desktop.input-sources sources "[('\''xkb'\'','\''$T'\'')]"; echo "$C -> [('\''xkb'\'','\''$T'\'')]"'

Free Desktop

This is possible because we find ourselves sitting on the shoulders of giants.

First we leverage gsettings to obtain the current key layout from org.gnome.desktop.input-sources, which looks like [('xkb', 'us')].

This is then stored in a variable C that is then evaluated by a bash case statement to set the new layout on variable T, which is then used to set the new value for the key layout, which is finally printed on the terminal.

gsettings follows the freedesktop.org specification, which is an open standard to improve the interoperability between desktop applications, frameworks and environments governed by consensus.

It provides a common way of doing things like automatic startup for applications, base directories for files, icons, D-Bus for message passing between applications, and in the case of Gnome, default settings.

The org.gnome.desktop.input-sources is what is called a schema convention, and is used as the address in a key-value database for the configuration of a Linux Desktop, which in this case is Gnome.

No additional dependencies needed. No scripts that need root access. No installation required.

All this should be shipped with any Linux distribution using a desktop environment that follows this convention such as Gnome. This makes it ideal for customizations and automations that can be portable to other systems that speak the same language.

The Price Of An App

In another somewhat related episode of this week, I had the chance to attend a business networking event.

At some point one of the friends I made that day asked me how would I price an app he had an idea about.

Every single developer and software engineer gets to receive this question at some point of its career. The usual joke I give about it is that it might cost between $100 and $100 billion.

The long answer is that, if the app is yours you will get paid for it as much as the market values the services it provides according to a free market or the strategic value of a possible acquisition by some agent that buys it from you.

None of this is obvious to quantify and can strongly depend on intangible assets like the brand, the traction it gets or some bubble inflated bets for the future.

The next best thing is to measure the price by number of development hours needed to implement whatever features you want it to have. Usually this depends on the team of developers, their seniority, experience as well as how many LLM tokens they are willing to spend in this venture.

This is without including the work needed in the backend to actually scale it with your users if it gets successful.

However, after patiently listening to his app idea I came to the conclusion that what he wanted to do could be achieved via a community in some app like Facebook, Telegram, Discord or WhatsApp for exactly $0.

This is just another instance of the idea of make it simpler. Having a community is an excellent way to validate an idea that involves multiple agents such as clients, sellers and moderators.

This is not to denigrate the worth of a technical solution of an app, but to point out that design must always follow function, this is true both in business and engineering.

The KISS principle

Since the 1970s, the guiding principle behind UNIX utilities is to do one thing and do it well, specially regarding the CLI.

A technical example I love is the design of the Bash shell and its set of utilities.

This means having small utilities such as cat, grep or awk that can be connected using the pipe symbol | to execute more complex and specific tasks that are beyond the imagination of their designers.

For example the following command obtains the process ID of the chrome instances of my machine, then I can aggregate them into a list to send all of them a signal, which in this case is to kill them.

kill -9 $(ps -aux | grep chrome | awk '{print $2}' | xargs)  

This keeps default system complexity under control, while allowing customization for very complex workflows and utilities.

There is still a specific utility for this in modern systems that achieve the same thing, but the point remains.

pkill -9 chrome

This principle has been broken countless times before and after UNIX.

One example are applications with graphical user interfaces that aggregate very complex functionalities within a single large program that encapsulates all of them.

Sometimes this is perfectly justified in utilities that have a very highly coupled set of very specific operations or that require the complete immersion of the attention of their users. Think design programs, CAD engineering, web browsers, video games and movie players.

However, with the widespread access of LLM systems that are able to generate working code at scale we can only expect the situation to worsen.

We need to catch ourselves when we are reinventing the wheel and strive for some form of digital minimalism.

Takeaways

The funnier part of the key layout story is that I found a configuration for my setup that doesn’t even require the keyboard, which reminded me of the 0 code solution episode.

One skill in the agentic era is to be able to model problems in the simplest way possible with the maximum leverage, which might not mean 100% automation or any code written.

For this a good foundation might be knowledge of automata theory, math and logic as well as a personal philosophy of radical simplification and the humility to understand when a solution we have invested time has gotten out of hand or has lost its purpose.

In the technical arena, we need an awareness of open standards, protocols, default tools and standard libraries for the programming languages we use to build our customization in order to avoid reinventing the wheel.

And in business, we should always remember that the mother of creativity is to have the right restrictions to the solutions we are willing to deploy.