Looking Back at 2025
Merry Christmas and Happy New Year!
It’s almost the end of the year and it means it’s time for a retrospective.
Disto Hopping vs. Backups
As you may notice I failed my challenge to hop from distro to distro every two months. What did go wrong? Well, backups. Most of my life I didn’t bother about automatic backups, but when I started to face the reality of wiping my system every two months, automatic backups became too important to ignore.
As a tool for making backups I decided to use BorgBackup because it’s well-known and trustworthy.
In it’s core BB is a “deduplicating archiver” which means that in the “repo” (“archive of archives”) all archives share a common table of chunks that helps to save a lot of space compared to simple backup-1.tar.gz , backup-2.tar.gz … What I didn’t expect was that Borg Backup is a low-level tool, not a “battery included” solution for backing up your system. Of course BB is aware that it’s used for backups and has some relevant features (working in a client-server mode, checking archives for corruption, pruning based on different criteria, etc.), but it completely lacks an “automation” layer.
I said to myself: “Okay, not a problem. I just need to write a couple of Bash scripts and set up a systemd timer”.
Say-do. The first version of the script was implemented in a couple of hours and was really simple. Almost immediately, I realized that I needed more features before calling it done and moving forward. To my frustration, I also realized that I can’t simply walk to Mordor implement what I need, because I have to test the code, but testing it on my precious data is not an option.
Hence, I started to work on the test environment for developing my backup system. It turned to be a nice side project, although it took more time than I expected.
In my test environment, I have everything defined as code. The build script for the test environment uses Ubuntu as a base OS. It injects autoinstall plus cloud-init config to the installation ISO, then it creates VM(s) and installs OS from that custom ISO. When the system reboots, the build script runs the Ansible playbook to make the final provisioning, e.g. making structures of directories and putting there test files. Starting from scratch, I can in one command create a disposable virtual environment that mirrors my “production”, then attach there with VSCode Remote SSH and develop my backup automation without the fear of damaging the real data.
This task was not difficult, but it took me some time to code. I finished it by the end of summer, I think. Then I could finally implement missing features of my backup system (including migration from systemd timers to anacron, because the next distro I want to use will be not a systemd-based one).
There are still a couple of TODOs, though, that I plan to cover before moving forward 😂
OTS Static Site Generators Considered Harmful
There are bad things that have to happen one day, but you still expect them to never happen and it’s always a surprise when they finally do.
One shiny morning after zypper dup I wanted to write something to my blog, when I discovered that the local build gives me:
ERROR deprecated: resources.ToCSS was deprecated in Hugo v0.128.0 and subsequently removed. Use css.Sass instead.
Easy to fix, just do what error message says. But then suddenly on the server side:
ERROR render of "page" failed: "/opt/buildhome/repo/themes/scratch/layouts/_default/baseof.html:21:29": execute of template failed: template: _default/single.html:21:29: executing "style" at <css>: can't evaluate field Sass in type interface {}|
The reason is that Cloudflare Pages uses older version of Hugo (v0.118.2) and my local version of Hugo went to v0.148.1.
Fixing this situation was simple, I just removed zypper-installed Hugo and installed through go install the exact version used by Cloudflare Pages:
CGO_ENABLED=1 go install -tags extended github.com/gohugoio/hugo@v0.118.2
But the problem made me think.
First, why do I have two versions of Hugo? The benefit of a static site generator is that you don’t have to run the code on the server side. All you need from the server is serving static HTML! Why on Earth do I need to run a build pipeline on the server risking generating not what I see locally or failing generation at all?
Of course, it’s easy to switch from CI/CD Hugo pipeline in Cloudflare Pages to serving the pre-generated public directory. But then even nastier questions pop up: “Why do I even need Hugo?”
When I started this blog, I decided that I wanted to have a super-minimalistic theme. Not a plain HTML without styles (although some venerable programmers do that), but something extremely simple.
My first look was at the theme called “No Theme Please”, but then I found that it’s too clogged, and I need something even simpler. As a result I implemented my own theme from scratch.
I wrote an article about it, and the point was that Hugo is rather a framework than a ready application. But in my use case, I don’t need 99.9% of this framework, while at the same time I’m paying the price of complexity (I need to follow Hugo conventions) and fragility (my code can break on any Hugo update).
If the first problem I can live with, the second is more annoying. If you browse the catalog of community-made themes for Hugo you can discover that roughly 30% are broken because they were made for the earlier versions that are not supported anymore. This problem is not limited to Hugo (or even static site generators), it’s the price you pay for using 3rd party framework. But I don’t like to continuously fix my code while the framework goes forward, I want to write blog posts and do other stuff that I’m interested in!
The idea that comes naturally is that my theme is so simple that I could implement the whole static site generator myself by putting together the same components as Hugo (Go templates and Goldmark). Honestly, I don’t even need SCSS. And if I do all myself, I could implement new features more easily than using Hugo!
I haven’t done this migration yet, but it’s on my “TODO” list for the new year.
Btw, this way of thought is not unique, and I see more and more people switching from ready-made 3rd party bloated software to DIY software tailored just for their use case. This approach has its own limitations, but in the future I believe we’ll see more and more of it.
Work
Last year (2024) I found a new job in a health tech company. The job is super interesting, and so far I consider it to be amongst the best places I’ve ever worked in.
This is also my first time in the health tech industry. For the last year I’ve been planning to write an article “One Year in Health Tech” about cultural shocks, myths and reality, and just to tell a little bit about the company’s product and mind-blowing things that are possible with modern technology. But that was the year 2025, in the next year it’s gotta be already (if it ever happens) “Two Years in Health Tech” ha-ha!
Tech-wise most of the year I spent learning about making my own Linux distributions and customizing existing ones, and everything around this topic. I spent some time playing with Kairos, then got my hands dirty with industrial Ethernet (Profinet and Modbus) and Simatic industrial automation modules.
Language-wise it was mostly Bash, C++ and C. I want to say that I started to like shell programming more and more. I think it’s overlooked by many of my colleagues. Amongst all programming languages it has the highest “useful load” / “boilerplate” ratio. If you know how and have some discipline, you can write surprisingly complex programs with surprisingly low effort. Unfortunately, it doesn’t scale beyond some limits, but the feeling of this power made me think that maybe it’s worth studying exotic shells (Elvish? Nushell?). Who knows, maybe there is a 100x programming language hidden somewhere out there.
Btw, one candidate that caught my attention recently is … Tcl. The language is surprisingly nice and powerful: it feels like if Lisp and Bash had a child. But I haven’t tried to program anything complex with it, so it’s just a first impression. Maybe I will rewrite my home backup system that to Tcl at some point.
Plans for 2026
- Continue to do what I’ve been doing at 2025
- A lot more
- May be some articles for this blog 😅