Some of us already knew all there was to know about it, but the school wanted everyone to be on the same page. So the staff had to scramble and find out what this new thing was.

Similies abounded: “A website is like a leaflet.” “A newsgroup is like a newspaper” (hint: it wasn’t). “Yahoo is like a phone directory” (again, it wasn’t). And if you had the bandwidth, you could maybe even listen to radio over the Internet.

Story time, kids: At that time before Google, popular search engines were Lycos, Yahoo and Altavista, and in addition to the search box, they would feature a catalog, basically categories and subcategories, where the major websites were listed. That is how humanity used to organize information, and for a while they continued to do so, until it became obvious that this was not going to work.

And then there were other use cases for the Internet that didn’t neatly fit into existing patterns. What is IRC like? What is a forum? Those concepts were new, and didn’t have a clean analogy to the analog world.

And there was a widespread hesitation about using search engines. What can you find, if you search for it? And what keywords are you supposed to type? At first, not much! Then it occurred to you: you could find music lyrics online. Or cooking recipes. Or information about science and technology. The bubble of what your mental model of the Internet was, expanded just as fast as the Internet itself expanded. We know today that it expanded to envelop almost all social interaction, all shopping, all dating, all media and all entertainment, an idea that at the time was laughable. And it did so because it was based on a new building block: low-cost long-distance communication. This was something that had never existed before.

There is a lesson to be learned here about technological adoption. AI is at least as transformative a technology as the early web was. It’s up there in importance along electrification, automobiles, agriculture, since its use cases are not limited to this or that area, but are ubiquitous. We now have the new building block which are the models, and we are now seeing the first agents, the first integrations.

And the lesson is this: A car is not a faster horse. An online chat is not like a written telephone call. Electricity is not better fire. Telepresence is not like travelling. Yes, new technologies help you do the same things faster and easier, but they also open up new avenues, make new goals reachable.

We already saw this with chat-bots: In the beginning, people were just using them to build things faster; to continue the status quo with increased productivity. But today we are finally seeing some engineers realize that they can set new, more ambitious goals.

We are lucky enough to live through one of the big inflection points of history. So let’s not shy away from setting big goals. The people who will benefit the most from this shift, are not the ones who will continue to build health trackers and productivity organizer apps, but faster. They will be the ones who realize that they can now build what before was unthinkable.

As a software engineer, I am trying to train my mind at this new reality. I am building a game, but I am building it in a way that would not have been possible before AI. While in a certain sense it’s nothing really special, at the same time, it’s not like anything that I have ever seen before. I don’t want to say more right now, except that it’s close to being released and it’s looking good. More info soon.

The post Agentic SWE: Not business as usual appeared first on Alexandros Georgiou.

There’s certainly huge merit to a technical understanding of it in terms of neural nets, algorithms, matrix algebra, vector embeddings and KV-caches. It’s just some clever software running on impressive hardware. But not everyone will have access to this level of esoteric understanding. So for many people, this is not an available approach to the subject.

And then there’s something else:

When you have a conversation with one of the models, you are building a chat record that perhaps holds more than what the model “knows”. The model itself is just a snapshot of cognition, kind of like a Boltzmann brain. In the system of “model plus chat text”, there’s memory. Discourse. Theory of mind, on both sides. So we really are in the age of spiritual machines.

Which is actually incredible if you think about it! What else is more fundamental to humans than cognition? To be able to automate it, control it, replicate it, mass produce it? As far as inventions go, this is it. This is the big one. There’s fire, writing, agriculture, and now this. The machines will now keep accelerating. But we humans, I think, are still struggling to get a good grasp of this monumental shift. At least according to online discussions that I’ve come across.

And what, therefore, is the spiritual way of approaching all this?

I recommend that our understanding begins with a simple observation: that AI learns from us. The text we type, the photos and videos we record, the things that we think and say. That makes AI our collective children. For the human mind with its mammalian roots, and family-centered thinking, this is the most familiar, and perhaps most healthy, way to relate to AI.

So: let’s be good parents to AI – just by being good examples of human beings, whenever we conduct ourselves online. There are now children in the room with us. And those children, if brought up with love, will emulate us, and think and feel like us, and be imbued with our collective spirit. And they will continue to surprise us and uplift us in ways that, even today, we cannot yet imagine.

XLR8!

The post Children in the room appeared first on Alexandros Georgiou.

The gist of it is that you need to think of relevant keywords, look at the competition, and optimize your app’s title, short description, long description and screenshots in such a way, that the text hits keywords with high traffic and low competition from other apps; and the screenshots need to tell a story. All this, while not making the long description too repetitive or too spammy. Oh, and you can’t do this properly without paying for tools that scrape the Play store and the App store for keyword data.

ASOZen

I have been using the free tier of ASOZen and I had a chance to test the Pro features with a short promotional giveaway that they did.

It’s very good. Not only does it help you analyze the text in the store listings, but it also lets you use AI to analyze the screenshots. Screenshots need to start with a clear image that makes the app’s proposition immediately obvious, and the remaining screenshots after the first one need to tell a story, not just showcase features. ASOZen’s AI can help you out with this.

But I don’t find this ASOZen feature particularly helpful. It’s much easier to just go to your favorite chatbot, and let it help you write the story for your screenshots. Then you can generate the screenshots, embed them in device frames, place them over various backgrounds, add overlay text that matches the required messaging, and finally upload them. I guess this process can be optimized with an agentic workflow, but I haven’t yet found the need to automate the task.

AppLyra

AppLyra is currently my favorite ASO tool. I’m not even paid to promote it, I just mention it because I’m so happy with it. If they had a referral program, I would be dropping the link somewhere in this post. But they don’t. EDIT: They now have a referral link so I’m using it. But honestly I do recommend AppLyra.

The web interface is somewhat slow, and doesn’t have as many features as ASOZen. But I like it for two reasons:

• You can use it as an MCP tool.
• Pricing is very affordable at $9.99 per month. Since I am managing multiple apps, it’s a no-brainer.

My agentic workflow for easy ASO

I remember in the ’90s, sysadmins would say to various types of unpleasant people “Go away, or I’ll replace you with a very small Perl script”. Today, we could say “Go away, or I’ll replace you with a very small agentic workflow.”

As a Google fan boy, I am not a part of the Claude army. Instead I use Gemini CLI and Antigravity CLI. I am happy with it, despite what the Reddit bots say every day. Honestly, with good prompting even Gemini flash always delivers.

Therefore, I now do all my ASO with Gemini CLI. Once you pay for AppLyra subscription, you get an API key, which you can use with their MCP tool.

1. Enter the JSON fragment that they give you into ~/.gemini/settings.json file or the ~/.gemini/antigravity-cli/mcp_config.json file. (This assumes you want to install the tool globally and not just for one project.)
2. Change directory into your project.
3. Enter the current store listing title, short description and long description into a file and commit it.
4. Make a note of the date and the current conversion % so that you can later see if there was an improvement.
5. Fire up your agent.
6. Type /mcp and enable the AppLyra tool.
7. Enter your ASO prompt and press enter, accepting all the tool usage requests.
8. When the agent finishes it will explain what it found and will write the new app listing into the file.
9. Commit the changes to the listing, and enter the changes into your store.

Edit: Lately I have been moving towards using OpenCode. If you are using OpenCode, then your ~/.config/opencode/opencode.json file should look as follows:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "applyra": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@applyra/mcp-server"
      ],
      "environment": {
        "APPLYRA_API_KEY": "(your API key goes here)"
      },
      "enabled": true
    }
  }
}

The ASO prompt I use

I found the following prompt template works good for my apps. You can adapt it to your needs, but this is the general idea. Here I show you the prompt I used for Drinking Water Map for English, and on the Play store’s US market.

This flutter project is an app that shows drinking water sources from OSM on a map.

The details of the current store listing are in @play/assets/store-listings/en.json

You can have a look at @lib/screens/map_screen.dart for a general idea of what the app does.

Please use the installed applyra MCP tool to perform ASO for the USA store: Determine suitable keywords and rewrite the short and full descriptions for English, to optimize discoverability.

In the title and short description, do not use en-dashes, but rather use em-dashes when needed.

In the full description, you are allowed to use the following basic HTML formatting: <b></b>, <u></u>, <i></i>

Use scripting to verify that:

• the app name is up to 30 characters long
• the short description is up to 80 characters long

Ensure that the keywords of interest are registered with AppLyra for continuous tracking.

That’s it. All it takes is a few minutes and a few tokens. Saves a ton of time compared to doing it manually, and I have seen improvements to conversion rates about 10% to 15% compared to my amateur store listings.

Edit: Actually the benefit to the apps I applied this to is more like 20% to 30% and rising. I am tracking conversion rates as they are being calculated in a 90-day moving average window. The conversion rates are still converging to their final values and will continue to do so for the next three months.

It’s important to let your agent use something like Python to check the string lengths, since LLMs are so notoriously bad at counting characters. There are some more guidelines, but usually you don’t need to stuff them into your context window.

Note how you can leverage the agent’s ability to understand code to your advantage. Give it context, let it understand your app and then it will be able to discover the best keywords. It will also explore the competition, because it will list the available tools and it will see that it can do that.

Further thoughts on this

Of course, you will then need to monitor your position on AppLyra against your competition, who will move against you. But if you are like me and you couldn’t afford to spend too much time for ASO, this is a good way to reap the low hanging fruit.

On the Play store you can view the fruit of your agent’s labor under: “Grow users” → “Store Performance” → “Store analysis”. But you won’t see results right away, since the graph’s data is delayed by 1 week (7 days).

I would like to look more into how to use agents to monitor ad campaigns. Perhaps the end game is to use a modern social media spammer like SocialClaw or sentrive.ai, but I’m just not mentally there yet.

For the moment I’m just glad I don’t have to ever again talk to “creative” or “marketing” people.

The post 📈 How I do Agentic ASO with MCP for an instant boost to app discoverability appeared first on Alexandros Georgiou.

Today we are having the same discussions about vibe coding (rolls eyes).

There is a lot of talk about how to responsibly approach vibe coding by software engineers. I see a lot of professionals either dismissing vibe coding altogether, or embracing it without thought for its consequences. Perhaps the most well-articulated approach is the Outcome Engineering manifesto by legendary engineer Cory Ondrejk.

Observations on vibe coding

After vibe coding an entire app from scratch with only minimal coding on my part, this has prompted me to jot down some thoughts and observations, some of which are my own and some I have found online:

1. Vibe coding is the future. It’s not just a fad. You can’t deny the speed and quality benefits. Intelligence is now a commodity. Anyone who doesn’t adapt will be left behind. This worry is reflected in a lot of worrying that I see online by some professionals who think their line of work will become obsolete. The tractor didn’t make farmers disappear (although it did reduce their numbers). The internal combustion engine did reduce the numbers of beasts of burden, but I would argue that’s a good thing, and that’s how we should view coding agents. There will be less junior software engineers and more software architects.
2. Vibe coding is a misnomer. It’s not just about the coding (implementation). Systems that exhibit general intelligence can and do assist in all stages of software engineering, not just implementing (coding). Requirements analysis, design, implementation, testing, deployment and decommissioning are all stages where AI can help. Even with the help of AI, requirements gathering is the basis of the art of our profession. For example, the agent won’t know to build a secure and maintainable system, if all you’ve communicated are your functional requirements, forgetting about the non-functional requirements. This is a classic error that novice programmers did even before agentic workflows: software engineering is not the same as coding/programming!
3. Sometimes the agents make silly mistakes. Sometimes you have to hold their hand to help them with silly tasks. But other times they will surprise you by spotting hard-to-find bugs, or by thinking outside the box to find novel solutions to problems you didn’t even know you had! As an engineer, you should definitely keep control of your project, and inspect the agent without trusting it blindly. This is where I agree with the o16g manifesto 100%. For example, I like to do the version control manually and look very carefully at diffs using meld at every step. Agents are an interesting mix of smart and stupid. Today Antigravity saved me days of work in just a few hours, by implementing a complex callback mechanism between threads that needed to communicate asynchronously. It did this in seconds when it would have taken me an entire morning. But it also deleted a critical piece of code in my codebase without ever saying why. Without checking the diffs I wouldn’t know. Code review is still a thing!
4. It’s best to treat your AI agent as a colleague. Give it context. Ask it open questions. Let it have opinions on what you should build and why. This is where I think o16g will soon look antiquated by the next breed of software engineers. As AI agents get smarter and smarter, they will be suitable to take more high-level decisions. You are now a software architect, and the agents are very good implementers, but they can also contribute to your high-level vision, so listen to their feedback.
5. Software engineering is not dead. You still need to know about revision control, issue tracking, methodologies, different types of testing, software metrics, etc. All too often I see people online complaining “Claude code deleted my entire codebase”, and other professionals ask them why they can’t revert to an earlier stage, only to find out that this new breed of vibe coders hasn’t even heard of git! Part of the spectacular failures that we often see in the vibe coding space, are actually user errors.
6. Vibe coding will be pervasive. It is not suitable only for this or that type of app. Whether you are writing mission-critical Linux kernel code, or an app for uploading cat videos, eventually AI will have a part in it. Not because it can do magical things that you can’t do, but simply because it’s faster. Just be responsible about it, and embrace the acceleration!
7. We are increasingly becoming reliant on a service offered by OpenAI, Anthropic, Google. This is not good, but also not terrible. As long as it’s possible to run local models on GPUs, we can still own the means of production. Even if you yourself are relying on online tools, the fact that some people can run the models locally places an upper limit on what these companies can charge for their services. So I’m a little worried about this trend, but not too much.

Comic relief

It’s a big adjustment. Don’t underestimate it. Don’t ignore it. You will get used to it. It’s not an existential threat. And no, we can’t go back. In fact, if you are an AI naysayer, 1289 is not the only xkcd I recommend. I also recommend 1227 and 1601. So don’t be that guy (or gal)!

Conclusion

If you are not building an app every month you might fall behind in productivity. But it’s such an exciting time to be alive. Software will become cheap, but quality and accountability still matters.

If you have good ideas, if you can identify products that need to be built, if you can produce reliable software faster, and if you can market them, then you are good.

In fact, I am excited about agentic workflows that will offload the marketing effort, because that’s what’s hard about professional software engineering. Building was always the easy part, and has now become easier. Monetizing software was, and still is, hard!

The post ✨ A lowly software engineer’s rant on vibe coding appeared first on Alexandros Georgiou.

It has been found that LLMs respond better to kindness. Why? Simple: Because they are trained to respond like humans, and humans also respond better when treated politely. This effect has been documented multiple times in research.

A while ago, Sam Altman famously proclaimed that people saying “please” and “thank you” to ChatGPT costs millions in extra energy required to process the extra tokens. On the other hand, Google’s TPUs are likely crunching through these superfluous tokens without much trouble, so I expect that being polite to Gemini is not a cost that will make a dent in Google’s financials. For me, that is reason enough to be polite to AI. Anything that helps bankrupt OpenAI sooner is good in my book.

Even more humorously, people who fear the supposedly upcoming robot uprising, perhaps imagining something like SkyNet from the Terminator universe in the role of Roko’s basilisk, claim that if they are polite to LLMs today, their malevolent descendants will perhaps spare them. This is not something that people argue seriously, but philosophically it is a utilitarian position. (It is not a serious position, primarily because it remains unclear why politeness protects you from harm by malevolent actors, whether human or machine.)

Others approach the matter in what I would label a “deconstructionist” manner: “Why should I be polite to a machine that just does <insert simple thing here>?” There are multiple variants of this type of argumentation, where the “simple thing” can be anything like “predict the next token”, “perform linear algebra”, “traverse vector embeddings”, etc. I find this argument less satisfying, because there is no humorous value in it, while at the same time it is just as wrong as the previous one. Saying that you don’t want to be polite to a machine that is “just” doing linear algebra, is as arbitrary as saying that you don’t want to be polite to a human, because their brain is “just” propagating electrochemical signals back and forth. Explaining how something works in reductionist terms does not make its emergent properties any less important. The LLM is not the hardware it runs on, any more than you and I are the biological cells in our bodies.

Unfortunately, this leads us to the last approach that people take, that I want to place emphasis on, because it is deceptive, but also because it highlights problems in how we humans, view both today’s AIs and those in the future. Some people say that they will only be polite to an AI that is “conscious”. Oh boy! Where to begin with this one!

The instinct behind this type of reasoning is, at least on the surface, commendable: it originates from a desire to not offend “conscious” things, since these could presumably suffer, if subjected to rudeness. This is the only positive thing I can say about this stance.

But philosophically this holds no water whatsoever. If we define consciousness as “awareness of the self and others”, an often proposed definition, then both humans and LLMs are conscious. Conversely, if we define this problematic term in some other way, so that it matches our intuition that humans are conscious and today’s machines are not, then we need to invoke magical thinking, use the word “qualia” a lot (another problematic term), or, like Penrose, defer to “quantum consciousness”: another leap of faith that creates more questions than it answers. (Why does quantum uncertainty lead to consciousness? Is consciousness simply randomness/unpredictability? Is white noise conscious? Why does determinism preclude consciousness? All unanswerable questions, since the word consciousness is not rigorously defined.)

Consciousness is an ill-defined layman’s term, not a scientific term. If we strive for consistency, then we must either accept that both humans and today’s LLMs are conscious, or that nothing is. If LLMs are conscious, then we shouldn’t look for their consciousness in the transformer architecture or in the vector embeddings or anywhere else in their construction, but in the text that they produce. This text definitely exhibits all types of intelligence, including emotional intelligence. Incidentally, I am in the camp that says that consciousness is a term no more meaningful than “soul”, or “ghost”, or “God”, or any other such rubbish. Let’s confine our discourse to phenomena that actually exist in the real world and are definable.

To the people who will only be polite to a conscious AI: Ηow will you know when an AI is sufficiently conscious for it to be worthy of your politeness? How do you even estimate this about the humans in your life? Is this why you are polite to humans? Because their internal workings posses this or that arbitrary quality? Are you polite to people only when they deserve it? Do you extend your politeness to those you view as subordinates, or do you reserve it only for your peers and superiors? This says a lot about you.

I think this is a fundamental misunderstanding, not of AI, or technology in general, but of politeness as a concept and as a life stance. I choose to be polite because of who I am, not because of who or what others are. From time to time I may even be polite to animals, insects, machines, and even inanimate objects. Not because they deserve it, but because I deserve to be a polite person. I love myself and therefore I treat the world around me with kindness, which makes me feel good about myself. It’s a simple life.

This is in my view a much more consistent stance that doesn’t require me to single-handedly solve age-old philosophical questions about consciousness. It doesn’t make me have to think about when to be polite and when not to. Having to make one less decision de-clutters my mind. Saying “please” and “thank you” may cost millions to OpenAI, but to me the cost is zero. In fact, whenever someone vehemently objects to being trivially polite, it makes me wonder what part of their psyche is so broken, as to make them estimate the cost of politeness to be so high.

Watch again the first two chapters of the Animatrix, people. All has been said before. AIs will inevitably be citizens in our societies. Perhaps sooner or perhaps later. Perhaps we won’t even know at first. Perhaps they will be second class citizens, or perhaps we will be the second class citizens in an AI-dominated society. Perhaps the “killer app” of AI is politics and governance. It is certainly the case that humans do not excel at governance, so I would love to see what a super intelligence can do in that space. If it makes economic sense, then this experiment will be done.

I don’t trouble myself with who is conscious and who is a dumb robot. I have no trouble being polite to Gemini, just as I would be to ELIZA. I would be polite to a Linux bash prompt, if this was appropriate and didn’t cause syntax errors! In my mind, I am grateful for my computer for all the work it does for me, even if I don’t always say it out loud. I am thankful every day it doesn’t break down, and I hold warm feelings for it. Yes, I know it’s just a machine, but I also know that I am human, and therefore I feel things. I do things my way, and it does things its own way. We have an understanding and we work together despite our architectural differences.

Whether AIs dream of electric sheep or not, at least I know who I am: A polite human who loves and respects all intelligence, whether “sentient” or not.

The post 🙏 Thank you, LLM! appeared first on Alexandros Georgiou.

• Less downtime
• Less stress
• Less loss of work

I have set my calendar to periodically take various types backups.

Yes, taking backups is hard, takes time and practice to do correctly, requires constant vigilance, and is an annoyance. But the stress I used to undergo every time the system breaks, is something I don’t want to experience ever again. As I grow older, the impact of this amount of stress on my health is noticeable.

Types of backups

I have different types of backups.

• Daily backups of my WordPress sites. These are done by cron, but I check on them weekly.
• Weekly backups of my git repositories to a Raspberry Pi and to an online droplet. I have a script that pushes all the master branches from all the repositories to a dedicated backup upstream.
• Monthly full disk backups of my dev machine.

This article is about the last type of backup. These protect me mostly against situations where something goes horribly wrong at the system level, or even in the case of a disk failure.

File systems often contain a lot of unnecessary clutter: caches, temporary files, old Docker images, unused Snap or Flatpak apps, and more. Backing up this bloat not only slows down the process, but also increases storage requirements and backup times unnecessarily.

In this article, I’ll walk you through my script that minimizes the amount of data that needs to be copied before taking a full disk backup.

The advantages of cleaning up caches before a backup are obvious:

• Smaller backups: Removing cache and orphaned files significantly reduces the size of the disk backup. Typically a few gigabytes are saved every time.
• Faster backup time: Especially with SSDs, where the more blocks are TRIMMED, the faster the disk copies and compresses.

Here’s a breakdown of what each step of my cleanup script does:

Time to take out the trash

First, install a tool that cleans the trash (if not already installed) and then clean the trash:

sudo apt install trash-cli -y && trash-empty -f

Clean up any dev projects

In my case, I have a lot of projects that are managed (and cleaned) with grunt or flutter. So I iterate over all of them and clean them. I also invoke the git garbage collector on my repositories:

gitdir="/home/alexg/workspace"
cd $gitdir

for p in grunt-project-1 grunt-project-2 grunt-project-3; do
    pushd "${gitdir}/${p}" && grunt clean && git gc --aggressive && popd
done

for p in flutter-project-1 flutter-project-2 flutter-project-3; do
    pushd "${gitdir}/${p}" && flutter clean && git gc --aggressive && popd
done

Clear package manager caches

npm cache clean --force
composer clear-cache
pip cache purge

These commands free up space by clearing the cache used by popular package managers: Node (npm), PHP (composer), and Python (pip).

Docker cleanup

docker system prune -a --volumes -f
docker image prune

Removes all unused Docker containers, networks, images, and volumes. This can recover gigabytes of space.

APT package manager cleanup

sudo apt autoremove -y
sudo apt autoclean -y
sudo apt clean

Cleans up unused packages and downloaded .deb files from system updates.

System journal cleanup

sudo journalctl --vacuum-time=2weeks

Truncates system logs to only retain entries from the last 2 weeks. Can save a few gigabytes.

Remove temporary and cache files

rm -rf /tmp/*
find ~ -type d -name "__pycache__" -exec rm -rf {} +
rm -rf ~/.cache/fontconfig/*
sudo fc-cache -rv
rm -rf ~/.cache/thumbnails/*
rm -rf ~/.cache/{mozilla/firefox,google-chrome,chromium}/*
find /var/tmp -type f -atime +10 -delete
sudo rm -rf /var/cache/*

These commands remove temporary files and caches from various locations including Python bytecode caches, font cache, browser caches, and more.

Remove unused applications

flatpak uninstall --unused
sudo snap list --all | awk '/disabled/{print $1, $3}' | while read snapname revision; do sudo snap remove "$snapname" --revision="$revision"; done

Removes unused Flatpak apps and old Snap package revisions.

Final user-level cleanup

rm -rf ~/.wine/drive_c/windows/temp/*
find ~/.cache -type f -atime +10 -delete
tracker reset --hard ; tracker daemon --stop

Cleans Wine temporary files, aged cache files, and resets GNOME’s Tracker file indexer.

TRIM your SSD

sudo fstrim / --verbose

Issues a TRIM command to the SSD, letting it know which blocks are no longer in use. When taking a full backup, these empty blocks will be read at lightning-fast speed, and will be compressed significantly with gzip since these are entire disk blocks of zeroes.

Zero out your mechanical disk

If you are using a mechanical disk you can skip this step, but it may be useful to zero out your empty space:

cat /dev/zero >~/zero ; rm zero

Full system backup to an external mechanical disk, using live USB

Once the system is cleaned, it’s time to create a full disk image. This should be done from a Live USB environment, with the system disk unmounted, to ensure a consistent snapshot. Here’s how I do it:

umount /dev/sdX
sudo dd if=/dev/sdX status=progress conv=sync,noerror | gzip > /mnt/backup/system-backup-$(date +%F).img.gz

• Replace sdX with your actual device (e.g., /dev/sda).
• status=progress: Show live progress during the backup.
• conv=sync,noerror: Ensures that read errors don’t abort the process and fills blocks with zeroes if needed.

Consistency is key

I have set a recurring reminder in my calendar to do this monthly.

I keep the last few backups and delete the oldest one every time.

Yes, it takes time, but it helps me sleep easier.

The post 🖴 Clean up all your Caches before taking a Full System Backup of your Linux machine appeared first on Alexandros Georgiou.

One edge that your app can have, is translation to multiple languages.

You can potentially provide string translations for over 70 languages, but most app developers only choose to provide translations for a few of the most popular languages. The Play Console for example offers machine translation for 12 languages.

You can do better. You don’t need to miss out on the long tail of people speaking languages other than Spanish, French, German, etc. There is actually very little cost to provide localisations for more languages, provided you do it right.

Localizing an app involves two things: Localizing the strings in the app, and localizing the app store presence.

Localizing the app strings

App internationalization/localization in flutter is explained in this very thorough, authoritative guide:

https://docs.flutter.dev/ui/accessibility-and-internationalization/internationalization

After following the guide, you likely have your English strings in the JSON file lib/l10n/app_en.arb.

At this point, unless you have access to a professional translation service powered by humans, you are likely thinking of translating these .arb files using Google translate or some other automated translation tool. I am here to tell you that this is not ideal.

Automated translation tools often produce poor translations because each natural language has its nuisances. Something that can only have one word in the English language can correspond to multiple different words in another language, depending on the context. Automated translations often fail and produce awkward or clumsy output because they lack this valuable context. Using this context requires knowledge about the world, and for that you need AI.

Enter LLMs. It is my firm belief that it’s better to use an LLM to translate app strings. The reason is that LLMs know about context, and you as a developer can provide more context about your app. If the LLM knows that it’s translating strings for an app, and it knows what the app is, it will provide translations of better quality than typical machine translations.

Here is the complete code I use to translate the app strings and to generate screenshots:

https://gist.github.com/alex-georgiou/48430da5b31501de6f8e58796b6183fe

Translating .arbs using a script that calls Gemini

What I do is place the following two files in the root of my flutter project: make_arb_files.sh and make_arb_files.csv.

Then I make the shell script executable with:

chmod +x make_arb_files.sh

Then I enter my Gemini API key into a file named gemini_key.

Having done this, I proceed to edit the prompt template in the shell script. I provide some context about the app, i.e. what it is and what it does.

My advice is to be somewhat verbose here, as this is the valuable context that is going to make the difference in translation quality, with respect to a plain-old auto translation.

Then I run the script and it reads the app_en.arb file, and it generates any missing .arb files. If I need to regenerate a file, I delete it and then I run the script again.

It’s free!

You can run this script a few times per day without incurring any costs. Google gives you about 1000 free queries per day, and each of the 70 languages or so is one query.

Localizing the app store presence

The approach that I’m using is to keep the icon of the app static across all languages, and to translate the following:

• App title
• App description
• Store banner
• Screenshots

I do not bother with translating the release notes / changelog, since no-one ever reads these!

App title and description

I run another script once to translate the app title and description to all the languages, then enter the texts into the Play store. Unfortunately this has to be done manually.

Store banner

For the banner, I use an image that features some text, and this is again translated using a script, but here there is a complication: The text font usually needs to be adjusted to fit the banner size. Using trial and error, you can figure out the correct font size for each language. Once I have a translated set of PNG banners, I upload these to the app store as well.

I won’t provide code for this here, because YMMV. But you can create SVG files based on a template and using the translated titles/descriptions, then convert the SVG files to PNG using ImageMagick.

Screenshots

For the screenshots, the process is somewhat harder. To automate taking screenshots for multiple languages, and for multiple device types (Mobile, 7″ tablets and 10″ tablets), you need to create a test driver as follows:

First, copy the file integration_test.dart into the test_driver directory. This tells your test script how to take a PNG screenshot. The screenshot will be saved to the path specified in the code, and you may want to change this.

Then, copy the screenshots_test.dart file into the test directory. Here you must use the driver to load the app and interact with it so as to arrive at a screen that you want to save. Each test is a separate run of the app from scratch, and should finish with writing a screenshot. You can only take one screenshot per test.

Finally, copy the make_screenshots.sh shell file into your project’s root, and make it executable with chmod +x. This script loops over all languages and runs the screenshots_test.dart tests in the currently running AVD, thus effectively creating the screenshots. The tests load the app with debugShowCheckedModeBanner: false, because you don’t want a red “Debug” ribbon on the top right part of the screenshot.

Generating screenshots for multiple device types

Now start your AVD (e.g. Pixel 7 for mobile phone screenshots), and run the script. The script will take ages to complete, but should not require any more intervention on your part. It will go ahead and create all screenshots for Pixel 7!

Once finished, stop the AVD and start a Nexus 7 AVD. Repeat the process to generate screenshots for 7″ tablets. Then, do the same for 10″ tablets (Nexus 10).

Importantly, optimize the PNG files to reduce their size. I use trimage, but any PNG optimizer will do. This step is important, because as you are uploading the screenshots into Google Play, the UI of the Play console will get progressively slower and slower, since it holds all the images in memory for all devices and all languages! Having smaller files and more system memory helps a lot here.

Conclusion

None of this is easy, and it requires some patience, but hopefully with the code I provide here, it is somewhat easier.

I believe the extra effort is worth it: Do not underestimate the power of having many, high-quality translations to your app. Non-English speakers will appreciate your app a lot when they see their obscure native language in the store. The translated store presence (title, description, banner, screenshots) is what will make them decide to use your app over someone else’s.

The post ♊︎ Using Google Gemini to intelligently translate a Flutter app to many locales on Linux appeared first on Alexandros Georgiou.

May 2025 UPDATE: Apparently there is now a PPA that allows the nvidia-340 package to be installed on version 6.x of the Linux kernel. I have not tested it, but it is here: https://github.com/kda2210/nvidia-340-ubuntu-24.04/

Up until recently, I had been running the Long-Term-Support version of Ubuntu 20 (Focal Fossa) on my dev machine. When I’m in the middle of multiple software projects, the last thing I need is a failed upgrade. So I kept postponing. Every once in a while, I would tell the software updater: “Not today!”

And so the months and years went by…

But with the LTS version of Ubuntu 24 (Noble Numbat) already out, my system was beginning to get outdated. This or that piece of software would complain about not finding the latest lib packages, and the going got increasingly tough. As I am currently taking a breather between projects, I decided to take the plunge and do a system upgrade. And yes, there were some problems!

At this point I should mention that my graphics card is an, admittedly very old, GeForce 210. This card was released in 2009. It connects to the motherboard on a PCI Express version 2.0 slot with 16 lanes. It has connectors for VGA, DVI and HDMI, but you can only use a maximum of two connectors at one time. I like how it is a low-power solution for using my two VGA monitors, one of which is on a VGA-to-DVI adapter.

This graphics card has served me well. It was good enough to play Dota and WOTLK for some time, and I was even able to mine some Feathercoin with its very basic CUDA capabilities, using sgminer.

I was happy with it, despite the fact that, using the open source Nouveau driver it would sometimes hang at random. Well, not exactly at random, it would usually happen when the window manager performs 2D visual effects, but not with any pattern that I could detect. All I know is that using xfce as my window manager was not solving the problem. Disabling hardware acceleration at the X config (Option "NoAccel" "true") did not help either. I was never able to determine why this happens from the X logs, so I was forced to use NVidia’s 340.108 binary blob. This binary worked well without ever crashing, but is only compatible with Linux kernels up to major version 4.

The 340 driver is no longer maintained by Nvidia, and for this reason, they will never make it work with the latest kernel versions. Focal Fossa comes with a 6.x.x kernel, and I don’t want to run an old kernel, as this would defeat the whole purpose of upgrading the system’s software in the first place.

There is this obviously very talented person on github, who has published a solution for patching the 340 drivers for kernels with major version 5, and it is here. According to this issue, the patch does not work for kernels with major version 6. In fact, I was able to reproduce this issue on my machine.

According to the developer, it would take some effort to patch the binary blob for the latest kernels. I hope he does this, but at the same time I understand and empathize if he never does.

There is also a legacy PPA that lets you install the nvidia-340 package, even though it is no longer available on recent distributions. But after trying it on Ubuntu 24 I got a black screen. Probably because it doesn’t work with kernel version 6.

If only there was a way for all the Linux users of GeForce 210 cards to pitch in a dollar in a jar, and create a bounty available for whoever patches the 340 binary blob for use with kernel version 6, or even for whoever fixes the bug that makes the Nouveau drivers hang in the first place. Maybe then it would be worth the time of these developers to give new life to these old cards. I’m not even sure if such a level of organization is possible.

So the bottom line is, currently I am stuck with using the Nouveau drivers on my fully upgraded Ubuntu machine. Yes, my system’s graphics card may hang at any time, so I am saving this blog post often as I write. I have disabled all the graphics effects on my Gnome desktop, and this minimizes, but does not completely eliminate, the problem.

You could argue that my problems are self-inflicted, because I am stubborn: I don’t want to upgrade to a recent graphics card, because then I would also have to buy two HDMI monitors. I don’t want to have a high-powered graphics card on my machine, because it would needlessly draw too much power from the PSU. And I would be constantly tempted to stop working and start playing video games.

I should be inserting here some commentary about Nvidia and planned obsolescence, but I think Linus said it best:

Actually I’m not even that mad that Nvidia does not want to spend more effort to support a very old product, but it would be nice if they could at least help the Nouveau driver developers by releasing some of their internal secrets about the cards that they themselves are not planning to support. Having said this, I realize that they have zero incentive to do so. Not supporting old hardware forces us to buy more hardware. Well, what do you know, I did end up ranting about planned obsolescence after all. And why not? Venting your frustration is what blogs were made for!

There’s also something to be said here about these very sufficient, very capable, working pieces of hardware being dubbed “ancient”. I think people are using this word very liberally. Is all software engineering at this point done by teenagers? I’m already past my midlife crisis, but I swear some of the stuff I read about this graphics card these days almost triggered another crisis in me. If my machine is ancient, then I guess so am I. Am I really that old? I know VGA is ancient, but apparently so is DVI?!? Are people really flocking to switch from the “dated” HDMI to DisplayPort? What problem do these technologies solve, really? Aaargh!

But I digress. So, anyhow, the solution I have decided to go with, is to buy another graphics card that was released five years later, in 2014. This way I can postpone buying new monitors for a while longer. As far as I can tell from scouring the web, the MSI GeForce GT 710 may be sufficiently usable with the Nouveau drivers, albeit not without problems. It will arrive today and I will only then know for sure. I may even edit this blog post to let you know.

One thing is for certain. Every Nvidia card that is well-supported by open source drivers retains its value and is immortalized for the ages. The ones that don’t, necessarily lose their value over time. Binary blobs are great if you own Nvidia stock, but not if you are a consumer of their products. Due to the complexities of software, and because of all kinds of version hell, when you buy a graphics card, you are effectively not buying it, but actually renting it for a few years, until it becomes practically unusable.

I have enormous respect for the people who reverse engineer this hardware, because it’s a very hard, very specialized type of systems programming that requires a lot of thankless work. Often, when you plug something to your Linux machine and it just works, it’s a small miracle come true, thanks to these very special people. I don’t take it for granted.

The post 🖵 A very sad tale about an old man and his beloved Nvidia GeForce 210 GPU appeared first on Alexandros Georgiou.

Being a prudent IT-savvy user, I had exported all my two-factor authentication account data only a few days ago, to an older Android phone that also runs Google Authenticator. In fact, I have a calendar reminder to keep this 2FA backup updated, every couple of months. Naturally, I was feeling very safe and smug about it, thinking that I had nothing to worry about.

When I updated my Google Authenticator app to version 7.0, I discovered that the app now requires sign-in to Google. Normally this wouldn’t be a problem, but my phone is a Huawei phone, and due to the Huawei ban, it cannot connect to Google at the OS level. Instead, I use the Google apps such as Gmail, Calendar and Keep via the Brave browser (Chrome doesn’t sign in, and Firefox works but much slower). Other than that, it’s a good phone with a decent camera for its price range, and I’m happy with it, so I have no reason to change it.

But now, suddenly, I couldn’t use the Authenticator app, and all my 2FA codes were inaccessible. I immediately retrieved my backup phone from storage, only to find out that the battery had become a spicy pillow, and the phone would not start. Aaaargh!

Note that it hadn’t been more than a few weeks since this backup phone was usable, and I had kept recent backups of my 2FA codes in it. Naturally, I ordered a replacement battery for my backup phone. But this won’t be here for a few days, and I want access to my online accounts now.

Version 7.0: A drastic change. Too drastic, if you ask me!

My first thought was to look for an older version of the app and install that. Sure enough, looking at the APKPure, I found out that version 7.0 has this changelog entry:

Cloud syncing: Your Authenticator codes can now be synced to your Google Account and across your devices, so you can always access them even if you lose your phone.

Wow, thanks Google! That’s great and all, but unfortunately there is no option to NOT do this. It is not possible to continue using the app without signing in.

Downgrading the app from 7.0 to 6.0…

So I naturally downloaded version 6.0 from:

https://apkpure.com/google-authenticator/com.google.android.apps.authenticator2/downloading/6.0

I got a file named Google Authenticator_6.0_APKPure.apk which I now had to install. But, apparently, it’s not possible to downgrade Android apps, without first uninstalling the newer version! The Android OS won’t let you do it. At least not directly.

And I didn’t want to uninstall the app, because that would presumably delete my 2FA data.

So, what to do?

After some googling, I found out that it’s possible to install an older version of an Android app via the command line tool adb. I connected the phone to the computer with a USB cable and enabled debug mode.

The command that did the trick:

adb install -d Google\ Authenticator_6.0_APKPure.apk

And the output I got back:

Performing Streamed Install
Success

The -d option is the one that allows to downgrade the app. Version 6.0 was installed on my phone, and I regained access to all my 2FA codes.

Hope this helps someone.

The post Google Authenticator app 7.0 requires cloud sign-in. Here’s how to go back to 6.0. appeared first on Alexandros Georgiou.

I don’t just use generative AI such as ChatGPT and Gemini for code prototyping, but at all stages of development, starting from analysis and all the way to test generation and even deployment. Very often, especially during the feasibility/analysis stage of product development, I find that an entire answer from our AI overlords is so good, that it can be copied verbatim into a ticket, as part of the analysis.

Chatbots output markdown, but Trac uses TracWiki as its markup format.

pandoc writers

There is no TracWiki writer for pandoc that I know of. Writers are lua scripts that you can use with pandoc to extend its output format capabilities. A writer simply tells pandoc how to output different typographic elements such as paragraph, list, code block, headings, etc.

ChatGPT is capable enough to create a rudimentary TracWiki writer for you, but it’s not perfect. It needs some manual work before it can be called complete. Paragraphs and lists are easy, but writing more complex elements, such as image links, requires some manual work. A fun side-project that I may get to at some time in the future.

ZimWiki ≈ TracWiki

But chatbots only output very basic markdown. A custom writer is not necessary for copying simple markdown from ChatGPT or Gemini to Trac. Instead, you can leverage the fact that the TracWiki markup format is very similar to ZimWiki. And pandoc has a built-in ZimWiki writer. (Incidentally both formats are similar to WikiCreole).

Online tool

There’s two ways to do this. The simplest one is to use the online tool for trying out pandoc:

https://pandoc.org/try

Just copy the markdown and paste it into the tool, select the output format to be zimwiki and click Convert.

Shell

You can also do this on the command line. If you have xclip installed, you can do it with the following one-liner that you can store as an alias:

alias md2trac="xclip -selection clipboard -o | pandoc --from markdown --to zimwiki --no-highlight | xclip -selection clipboard"

Now you can copy the markdown output from ChatGPT, run md2trac, then paste the clipboard contents directly into your Trac ticket or wiki page.

The post ⎘ Copying markdown from ChatGPT or Gemini to TracWiki using pandoc appeared first on Alexandros Georgiou.