Crucially, the story in 2025 isn’t just about games: everyday desktop life on Linux (web browsing, office work, chat apps, media, and coding) is now straightforward, with good hardware support, polished desktops like GNOME and KDE, and easy software installation via app stores and flatpaks. Many users report that once they set up their favorite browser, office suite, and a couple of communication tools, Linux feels like a calm, predictable environment compared with the constant churn of Windows 11, making it attractive both as a gaming platform and as a daily driver.

Putting it all together, 2025 feels less like “the year of Linux on the desktop” as a meme and more like a real inflection point. Steam’s own stats support that and show Linux hitting record share on the platform and growing faster than before, even if the overall percentage is still modest. Community reports and long‑term tests from Linux gamers with large libraries confirm that thousands of titles now “just work”, often with performance equal or better than Windows.

The Turnaround

This marks a turnaround in the long lasting dominion of Windows and how it’s perceived by broader, even non-tech audience. Microsoft really did everything they can to push people away from their well-established eco-system, people looking for alternatives, and finding that within the Linux community. Valve’s strategy empowering gaming on Linux is paying off (they seem to be the good guys here). Imagine a world, where the computer you’ve bought is actually yours. It does not spy on you. It does not force certain actions on you. Instead, it works for you. You can be an avid gamer or a desktop user. It doesn’t matter. I think we don’t need to imagine it anymore. It’s here, or at least it’s more close than ever before.

As you know, Linux has been my daily driver for years and I kept an eye on how things evolved. I am super happy to see that development, also in previous years, but personally I always had a dual boot setup with Windows (10). Despite not playing frequently, I still kept that, to not close any doors when I really wanted to play something which doesn’t work on Linux. It has always bothered me to indirectly support Microsoft. That there was no real alternative. I knew for quite some time that the moment I have the chance to ditch Windows, I will, but Linux was just not there yet. Until 2025!

Over the past two years I’ve though noticed that I’ve only been in my Windows when I thought it was “time to update”, not for gaming. Ultimately, Windows 10 being end-of-life gave the final argument for me to do it despite not playing on my Windows for over 1.5 years.

At least for me, 2025 is the year where I finally ditched Windows altogether! Quick partition deletion, resizing, and that space is now available for my Linux setup. Nice!

Recommendations and caveats

A lot of blog posts focus on the heavy nerdy topics, like #nix, though I think Linux is moving into the right direction. People who never considered it, are picking it up, or at least questioning the current situation. Adoption and usage is significantly increasing. If people start to question their existing behavior and come back with positive feedback on how they felt “they got control over their systems back”, it’s the perfect time for you to at least start thinking as well!

You don’t need to be a developer. You don’t need to be that tech guy. You can make the switch, especially if you just do some browsing, checking mails, and some writing. No need to ditch old hardware, they usually still work. Even if you’re a gamer, you can do the switch. Gaming support has never been better.

Keep in mind, leaving your comfort zone is usually perceived as discomfort. Maintain an open mindset while trying it out. Nobody forces you to do the switch. It’s all about giving it a try!

As closing words, let me give you my two cents what you should be looking at and what you should avoid. Those points are heavily opinionated, keep that in mind!

• Don’t use Ubuntu. You might read that it’s beginner friendly, it might be, but the company behind it usually does “their own stuff”. I’d recommend going with something more standard and broadly used. You’ll have a better experience with other distributions.
• Fedora is a valid choice.
• KDE Desktop might look more familiar to your previous Windows setup.
• GNOME Desktop looks really fancy in my opinion, requires you more to change what you’re used to from Windows. I still think you should try, it’s good and feels super polished.
• Bazzite (based on Fedora) seems to be a very good choice for gaming-focused workloads.
• For games, research how they work on protondb.com, that’s a really good source, especially if you’re into Steam anyways!
• In case you’re about to buy new hardware, research on compatibility. Most stuff just works, but cross-checking for Linux compatibility doesn’t hurt. I can also recommend going with AMD altogether, especially for graphics. AMD support on Linux is amazing.

This post is part of #nixjourney series.

Recently, I came across a blog post stating someone’s reasons to move away from nix on his Mac where he maintains dotfiles using Home Manager. This made me think. Some points are valid: /nix/store is large (my desktop has ~267G right now as I keep building for all hosts on my machine and have the tendency to never clean it up), quickly “changing” a hot key takes more time than editing the configuration file directly. Though, that cannot come as surprise, right? It’s the trade off you make for being the new cool kid on the block (or reproducibility, easy rollback) and central management. It plays nicely together if you manage more than your dotfiles with nix, like a lot more. That’s where nix shines. It’s not supposed to work for everyone. If it doesn’t work for you, that’s totally fine. It does for me though. As you might now, I am Cosplaying as a Sysadmin for quite some time which made me finally move to NixOS from Arch (btw) over two years ago.

That post was the perfect motivation for me to continue the #nixjourney series.

When I started looking around into NixOS documentation, some guides, starters, I really had no clue what was going on and how nice the final result would be. I’ve learned a lot on the way. It took several months to migrate all hosts during my spare time. In the beginning, I was confused about all the terms. I knew my goal and hoped that nix can deliver that, but why would there be different solutions? Nix, NixOS, Nix Flakes, Nix channels, home manager, and sops for secrets?! Took some reading to get this sorted out, but when it was, I noticed flakes are actually what I want. To be honest, without flakes, I would have probably never fully switched to “nixify” my setup. Flakes give you a .lock file, similar to package-lock.json in node applications or alike. They exactly determine which versions and dependencies you’ll get, but on an operating system level whereas Nix channels are more “volatile”, not providing the same guarantees. You definitely have more control with flakes and I would recommend everyone to go with flakes.

While researching to get a jump start, I thought it would be nice to learn by doing and having a solid base line I can extend, thus I started my journey by picking up nix-starter-configs [1]. Nix as language felt alien. Despite the fact that I know some functional programming, it was harder to get started and to write each line of code than I thought. In the beginning, I spent more on researching, reading, and asking than actually getting my setup done. In retrospective, the relatively complex starter didn’t help either. It might have even confused me more. In all honesty, it was a brutal and steep learning curve to get basic things done. After a while though, results were reasonable. I started to enjoy how simple it was getting applications ready and fully configured through nix code/modules, no manual config tuning on any server afterward, that was huge! I also loved the implicit documentation it forces you to do. You’re documenting your steps with git commits (or at least I did that). Your nix setup is a git repository, the same as with any other code. With this, you have all the benefits of versioning, but on an operating system level. Derivations force you to even add proper dependencies to any of your bash scripts which you’ve likely put together late the other day and never touched them again. Furthermore, nix modules force you to structure your setup, add custom options, and enable dependencies to other modules properly by for example leveraging lib.mkDefault.

Instead of starting with my desktop machines to NixOS, I decided to move some of my VPS first. I kept the old ones still alive… in case I decide otherwise half way. Another reason behind this was that I didn’t want to disrupt my daily routine yet. In the end of the day, it was experimenting and seeing how it goes, taking the safe route. I also knew that fully migrating all of my dotfiles and in addition my tiling window manager setup to nix would take more time than going with basic servers. The plan was simple. Iterate, move quickly, do mistakes, recover, and have No-Go’s show up as early in the process as possible to evaluate if this is more than a prototype, something I want to keep. Turns out: Yes, I really want this to stay and never move back (hopefully or until something better comes up).

Even if something breaks (which actually never happened to me since I’ve started using NixOS), having the ability to easily rollback by booting into the previous version feels like a huge step forward (each build/deploy creates a new, bootable generation which you can boot into when your machine comes up through normal means of your bootloader). Back then, I did encounter issues sometimes on my Arch machines with dependencies, or manual interventions were required which I then needed to repeat for all of my hosts which was annoying. I haven’t seen this (until now) with my current NixOS setup.

My setup

Let’s directly jump into it. I currently manage eight hosts using NixOS. The entire setup is “nixified”, meaning that I don’t add plain config files to a specific location, but instead use the provided modules or write them, though some scheme files are imported from plain text files.

The structure is something which evolved the more I added to my setup, still based on the initial base line I touched above.

 1├── commons
 2│   ├── modules     # Opinionated modules (with my configuration)
 3│   ├── presets     # Opinionated presets for desktop, server etc., importing modules/ or snippets/
 4│   └── snippets    # Opinionated snippet options to directly use in imports (with my configuration)
 5├── hosts           # Host configuration, importing presets and specific host configuration
 6│   ├── ando (vps)
 7│   ├── hoth (vps)
 8│   ├── ilum (laptop)
 9│   ├── kuat (vps)
10│   ├── mantell (home server)
11│   ├── rion (Raspberry Pi 3)
12│   ├── ukio (Raspberry Pi 4)
13│   └── ziost (desktop)
14├── modules         # Independent modules not provided by upstream
15├── overlays        # Overlays
16└── pkgs            # Derivations for custom packages

The commons/ folder contains opinionated nix files. This means that those represent my configuration or setup, like theming, keyboard shortcuts, or other settings usually wrapped into a custom module under commons/modules/. They typically use the mkIf guard pattern, meaning that I’ve wrapped those opinionated settings by either leveraging the .enable upstream module option or one of my custom written modules (not present in upstream at all and located under modules/).

Here’s an example for btop to apply my settings like the dracula theme.

 1{ config, lib, ... }:
 2{
 3  config = lib.mkIf config.programs.btop.enable {
 4    programs.btop = {
 5      settings = {
 6        color_theme = "dracula";
 7        theme_background = false;
 8      };
 9      themes = {
10        # ....
11      };
12    };
13  };
14}

As you can see, if I now enable the programs.btop.enable anywhere in my config, I’ll automatically get my settings.

Files inside the presets/ folder import modules and set the enable option for them depending on a use case. I have a desktop.nix and a server.nix. This allows me to import a simple preset in my actual hosts file and then all my defaults are applied. If I need to overwrite any defaults for a host (when I don’t need a specific module), I can simple set their module option to be disabled (or not import the preset at all).

The snippets/ folder contains nix snippets which I tend to re-use often, but have no intention of modularizing them as they’re so simple that I think they’re not worth wrapping in an additional module and use the import directive instead. Here’s an example of such a snippet.

1# locale.nix
2{ ... }:
3{
4    console.font = "Lat2-Terminus16";
5    console.keyMap = "de-latin1-nodeadkeys";
6}

The hosts/ folder contains files for my all my hosts. When adding a new host, I add a new folder, adapt my flake.nix to import it under a hostname and that’s about it. This means I import a preset and a specific hardware-configuration.nix which is generated during install and some boilerplate code around users, Home Manager, and deployment (see below).

Secret management

When you move to a nixified setup, you don’t want any secret hard-coded in your nix files. Those would be tracked in your git or put into the nix store when you build. Instead, what you really want is proper secret management. There are some alternatives out there, but what has worked best for me is sops-nix. It’s pretty flexible and supports secrets per host. You configure yaml file(s) for a host, edit them with the sops command, e.g., sops ./hosts/mantell/secrets.yaml. The result is asymmetrically encrypted against a sops key of your machine (or multiple ones) and the hosts machine (automatically derived from SSH setup for example, can also be done manually). It also works per user on a certain host. Pretty convenient. With this setup, you can reference any of your secret keys in your nix files.

Here’s an example to secure a reverse proxy with basic auth.

 1{ ... }:
 2let
 3    fqdn = "mydomain.tld";
 4in
 5{
 6    sops.secrets.nginx-basicauth-fqdn.owner = "nginx";
 7
 8    services.nginx.virtualHosts."${fqdn}" = {
 9        forceSSL = true;
10        enableACME = true;
11        locations."/" = {
12            proxyPass = "http://127.0.0.1:${toString port}";
13            extraConfig = ''
14            auth_basic "Protected";
15            auth_basic_user_file ${config.sops.secrets.nginx-basicauth-fqdn.path};
16            '';
17        };
18    };
19}

Notice that I’ve leveraged the directive auth_basic_user_file from nginx directly. Most Nix options actually have a dedicated option to support files as secret inputs. If they only support an environment file, the sops YAML file can host the entire environment file as well. The only catch is that the underlying application needs to have a configuration option to get the necessary application secrets in. Most modern applications do or can be worked around with environment files. If they absolutely don’t support that, I personally think it’s worth requesting it from upstream. So, if you’re an application developer, please consider directly supporting file secrets.

When you change receivers/keys for a secret file, make sure to update the keys with sops updatekeys ./hosts/<name>/secrets.yaml. Otherwise sops cannot decrypt that properly!

Building and deployment

To get the state of your nix files onto a machine, you need to build the nix generation, either on the host itself or “deploy” it from your local machine. For my desktop hosts, I directly build it locally with sudo nixos-rebuild switch --flake .\#ziost or instead of the switch the boot option to have it live on next reboot. This means that you need to have your Nix git repository on the machine, checkout the state you like to build, and execute the command above where ziost is one of my flake’s configuration (desktop machine).

This works fine, but you might not want to go the same route with your servers. What I use instead is build the nix generation on my machine and then deploy it over SSH. For this, I set up deploy-rs in my flake.nix file for each host to define how I want to deploy, e.g., over SSH with a specific user on the remote machine and alike. Let’s imagine I like to deploy the latest state for my server ando, then I’d simply invoke deploy .\#ando on my machine in the git repository. deploy-rs sends over all necessary data and the server’s updated with my desired state. This means that I build the nix generation on my machine first and send it over afterwards. It also gives you a lot of options how you want the deploy process to happen. You can also decide to build remotely instead.

Upgrading

When I upgrade, I invoke nix flake update to update all defined inputs. This also updates the aforementioned flake.lock file. Afterward, I build the toplevel target for all my hosts separately to see if it builds successfully before I move on into deploying that state. No worries though, deploy-rs would obviously not deploy something which does not build!

1# build a single target, replace <host> with the proper nix configuration (visible through nix flake show)
2nix build .\#nixosConfigurations.<host>.config.system.build.toplevel

For a lot of hosts, this can get quite tedious to do. I use a one-liner to do it for all my defined hosts:

1nix eval .\#nixosConfigurations --raw --apply 'c: builtins.concatStringsSep "\n" (builtins.attrNames c)'| xargs -I'{}' nix build .\#nixosConfigurations.'{}'.config.system.build.toplevel --out-link result-'{}'

Looks scary, but you can put it into a shell alias or into a nix development shell for your nixos-config git repository. It iterates over all defined nix configurations, builds them and stores it as result-<name>.

If that is successful, I deploy one by one as it really depends on the host when I want to do it.

There’s also a way to visualize changes of nix generations, e.g., which packages have updates, with nvd. What I do there is a) build the current generation, b) update nix flake, and lastly c) build the “next” generation, then compare with nvd diff <current> <next>.

I wrapped this into a little convenient script called nvd-diff-prev-next. Here’s an example output when I call that for my VPS ando:

1nix-shell-env ❯ nvd-diff-prev-next ando
2⚠️ Resetting lock file...
3<<< result-ando-prev
4>>> result-ando-next
5Version changes:
6[U.]  #01  linux              6.12.61, 6.12.61-modules x2, 6.12.61-modules-shrunk -> 6.12.63, 6.12.63-modules x2, 6.12.63-modules-shrunk

OS releases

NixOS releases come out every six months, following a year and month versioning scheme (25.05 and 25.11). When this happens, some options you use might be deprecated or got replaced. I typically upgrade the flake input references, then invoke builds and see what breaks (if at all). For strict validation I tend to use --abort-on-warn for building the toplevel target such that even warnings or future deprecations are captured.

This release cycle sounds exhaustive, like you would need to change a lot every half year. In reality though, options are pretty stable, they have automatic migrations, and are usually backwards compatible, even introducing a deprecation / warning. For the past OS releases, my changes are on average 10-20 lines of code changed where most of them target deprecations which would still work fine.

Wrap up

Now with my setup explained, what made me ultimately move and commit to it? Reproducibility, easy fallback to boot into a (previously working) generation. Versioning all my setups with git, sharing (configuration) code in one central place. And, lastly, declaring what I want instead of changing what is provided to me as base made me do the final switch. Without any exaggeration, it feels revolutionary when you’ve fully moved to it. It also costs less time to maintain which was ultimately the goal of why I looked into alternatives in the first place. There are multiple tools out to have a similar feeling for non-declarative distributions (ansible, Puppet). None of them felt right to me though, more like a workaround. Nix is different in every aspect. It feels way more natural compared to the tools you plug in on top where this can be solved directly, not generating that “alien feeling” that it “doesn’t belong there”.

Obviously, there are caveats. It’s a trade off nevertheless. Despite giving you all the benefits and actually saving you time after the migration, the nix eco system can be a rabbit hole. It’s code, your imagination is the limit on how you optimize your setup, where to improve, what to fine-tune, and how much time you spend with this. If you go too deep, then it might not be the time saver anymore, though it will stay fun nevertheless. It’s really up to you to hold you back from over-optimizing and iterating too much over it than needed. 😅

For me personally, it worked out quite well, but it would be an unfair statement that I can recommend it to everyone. I think there’s a clear audience for this: people willing to take the steep learning curve and people who value reproducibility, stability, and versioning for host setup. For a casual user, I think a standard GNU/Linux distribution will do way better. I think it would even scare people off showing them “what is possible”. Though, the moment you face maintaining a lot of hosts, it might be a fit for you. Remember, you decide what exactly you “nixify”. You don’t need to “nixify” your entire setup including user configuration. You can also only have the base system “nixified”.

The next aspect I’d like to personally dive deeper into is some automation around CI/CD and a (local network) cache for Nix. I can imagine that my homesever (mantell) regularly does some build tests, creates merge requests in my git repository and does automatically deploy the main branch to all of my hosts (at least servers). It can also leverage nvd to provide information what has been updated, on which host which version/generation is deployed and alike.

That’s quite advanced, though it would even reduce the maintenance efforts further where I need to take action only if something breaks, I want to explicitly change something, or there’s a new NixOS release. To be honest, I am not sure that I’ll ever dive into that as I am quite happy about my current state.

What nix gave me is that it makes maintaining the hosts enjoyable again. It’s not a burden, really. It’s actually fun! Something I haven’t felt for quite some time with the previous setups using other distributions (before you ask: reducing the number of hosts is not viable for me, I do I need them).

1: FYI, I still use a modified version of it as my daily driver, but it might not be elegant or the most up-to-date starter you should use. It does work fine for me over nearly 2.5 years and I have no intention on changing it as of now.

Frankly, I’m not writing this to promote a desktop application or MPD itself, I am quite happy with it. Desktop usage is fine, but when it comes to mobile, things are different. Using Android/GrapheneOS as my daily driver (together with an old Raspberry Pi 3 serving as MPD proxy for playback through my AV receiver), I need a decent mobile client to control it. And there’s really a lack of those. Back then, MAFA was a massive improvement compared to the outdated M.A.L.P. despite being closed-source. I still decided to use MAFA as my daily driver. Using closed-source applications does make me feel uncomfortable, but sometimes it’s the price you need to pay. Unfortunate, but that’s life.

Recently, the MAFA authors (Indi Software) removed their app from the official Play Store due to questionable (or insufficient) reasoning. Don’t get me wrong, the new policies Google has put in place are not nice, but for such an app, there’s not much to pay attention to except for developer verification which in my opinion was the whole point of Google introducing it so you can be called out if you smuggle unwanted behavior/malware. But people don’t like change, so they take irrational decisions. The same happened with MAFA. It’s now only available as direct .apk download 😱. Being closed-source, this is an absolute no-go for me. All applications on Android have network permission (what would you do with your phone otherwise?). They could do anything, execute whatever they want in the background without you noticing. That’s an issue with closed-source apps in general, not specifically tied to how they’re distributed, but the official distribution through stores (including open stores like Izzy or FDroid) gives some trust, applications are cross-checked (at least by Google for Play Store), but not with your side-loaded apk. When such things happen, you’re exposed to the authors, trusting them way more than a closed-source application which is distributed through official channels.

Back to MAFA. A friend posted basically the explanation below on the announcement forum of the MAFA authors, asking and also explaining that no store as distribution is probably a bad idea, leading to distrust. Guess what happened. The MAFA authors (Indi Software) deleted that post within 15 minutes.

To be clear, releasing a mobile app outside of trusted app stores is highly risky and should be avoided at all costs. Both users and developers face significant security, trust, and usability problems when bypassing established distribution channels.

• Users downloading apps from unknown websites risk installing malware, spyware, or trojans disguised as legitimate apps.
• Without Google Play, IzzyOnDroid, or F-Droid, there are no independent review processes or automated checks to catch malicious code.
• Lack of regular updates through verified channels exposes users to unpatched vulnerabilities (or they can secretly point to another domain using their in-application updater).
• If an app is only available via direct download (APK sideloading), many users immediately see it as suspicious.
• Sideloading requires lowering a phone’s security settings, which most users associate with scams or hacked software.
• Developers releasing apps this way damage credibility, as users expect apps to be available through legitimate, recognized stores - Play Store is not the only one.
• Installing apps outside of app stores is confusing for non-technical users and creates unnecessary friction.

Bypassing recognized stores undermines the app’s security, harms user confidence, and reduces usability. Developers who care about adoption, trust, and long-term sustainability should always release their apps through safe and transparent stores, whether proprietary (Google Play) or free/open (F-Droid, IzzyOnDroid).

MAFA is still by far the best Android MPD client, feel free to continue using it, but I cannot. I cannot trust closed-source applications where authors delete posts on their official forums and in addition don’t give good reasoning why they went the route in the first place. It just creates a bad feeling for me, so I need to say goodbye MAFA, goodbye Indi Software, hello M.A.L.P. (again)!

A side note: I personally maintain fbmobile which I distribute through Play Store and IzzyOnDroid. When Google started changing their policy, I had similar thoughts as the MAFA authors. Just removing it is the easy way and seems legit, given that Google is that evil big tech giant, enforcing their new policy for everyone. To be honest, that wouldn’t be too bad for my application. It was just removing one of my distribution channels and not forcing people to install plain apk files. They could still decide to install via IzzyOnDroid. When thinking about the “why” Google probably introduced it, I suddenly reverted my initial plan. That developers are forced to be authentic and that they can be held liable to a certain degree is actually quite beneficial from my perspective. Don’t get me wrong. I don’t like this as a developer. It creates additional work, but as user I prefer that developers need to go through this verification process.

Google’s move also seems to pay off. Since the new policies have been introduced, I am regularly (like at least weekly) receiving mails from folks that they want to buy my legitimate Google developer account. I guess they need to find new ways to distribute their shady software.

This post is part of #nixjourney series.

For over two decades, I’ve been an avid GNU/Linux user (“Yes, I’m that old” 🦕).

My first encounter with Linux happened in my teens. Fueled by curiosity about alternative tech, I sought options beyond Windows, the only OS I knew back then. This was the era of screeching modems and dial-up internet connections.

It started with Ubuntu 04.10 (“Warty Warthog”). The experience was… rough. Hardware support was spotty, key features didn’t work, and I quickly abandoned it. Yet something stuck: the terminal’s raw power and Linux’s different aesthetic intrigued me, even as basic functionality failed.

Two years later, I tried again. What a difference! Out-of-the-box hardware support, GNOME2’s polished interface, and stability made it a viable Windows replacement for my aging machine, except for gaming. Linux gaming then was a nightmare, so I kept a dual-boot setup.

Ubuntu became my daily driver for years, though I remained a surface-level user. When everything worked, I was content. When it broke, often due to my reckless config file experiments, I struggled to fix it. My limited understanding of Linux fundamentals turned minor issues into multi-day research projects. I was totally fine being an average user, but tinkering with it was fun, just my lack of knowledge was not. Quickly, those early struggles became lessons: understanding fundamentals and its architecture. When time went by, I became more experienced and I noticed that I needed more. I needed a more bare bones experience where I am forced to learn and deal with everything on my own, a system from scratch.

I did a little bit of distro hopping, but ultimately ended up with Arch Linux. The learning curve was very steep coming from the clicky Ubuntu experience. I spent days, weeks, and months reading its (fantastic!) wiki. It felt like a huge achievement when I got my first installation working (and many more would follow). I also noticed that my knowledge got a huge bump. Everything felt familiar, I was getting way better at how internals work, why I initially was right that apt with its PPAs is super inconvenient compared to pacman. I enjoyed every little bit of my new knowledge and the experience I had. Among these, the beauty of AUR, the freedom to have an unbloated system nobody pre-installs software I don’t want. That’s how digital freedom feels. I was finally there where I wanted to be. Very quickly I became a super user. Tiling window manager, command-line first. It was also super convenient to code (what I already did for a couple of years). I enjoyed it so much that Arch Linux has been my main driver for over 15 years, even maintaining some AUR packages myself.

Over the last three years of my Arch experience, a strange feeling haunted me though. Confident, that I knew already a lot, as I’ve also managed some servers and more than just one personal device running Arch, I still had that feeling: This cannot be the end of my GNU/Linux journey. I always enjoyed new tech. I was curious about alternatives and out of sheer curiosity and by pure accident for further acceleration and evolvement, I stumbled upon something called NixOS as it tackled one of my main pain points when I was managing multiple devices.

Arch is great for bleeding-edge software, but keeping configurations consistent across my growing amount of devices like laptops, servers, and arm-powered computers quickly became a headache and time consuming. I needed a tool or OS which actually requires less time. More automation, more configuration sharing, and a convenient way to bootstrap a fresh machine in a matter of minutes (reproducible). With my personal discovery of NixOS through IRC (“yep, still old” 🦖), it seemed like a perfect match as other config management tools didn’t align well with me personally. I had an “alien” feeling when looking at puppet, ansible, or alike. I was seeking a piece of software which feels “native”, embedded into the concepts of an OS and not an addition which works around some quirks.

Moving from Arch Linux to NixOS: Simplifying Multi-Device Maintenance

After years of managing multiple devices with Arch Linux, I switched to NixOS and it has been a game changer. NixOS uses declarative configuration, meaning you define your entire system setup in configuration files (configuration.nix). This lets you:

• Reproduce identical setups across devices
• Roll back updates atomically if something breaks
• Avoid dependency conflicts with isolated package environments

With NixOS, provisioning a new machine is as simple as cloning your config repo and running nixos-rebuild switch --flake .\#target. You can maintain:

• Host-specific hardware configs
• Shared services like SSH and monitoring
• User environments with tools like Home Manager

This approach eliminates configuration drift and turns system maintenance into a version-controlled, repeatable process.

Nix’s functional language took some getting used to, but the benefits, safe testing, managing multiple software versions, and automating updates-are worth it. If you manage more than a couple of Linux devices, NixOS’s declarative model saves time and headaches. It’s not just a distro, it’s a new way to manage systems reliably and at scale.

Next up in the #nixjourney series: exploring my setup where I manage around 9 devices leveraging Nix flakes.

“What the hell did I write there?”

Or worse: the code was written by someone else. You’re not alone. This frustration stems from how codebases evolve. Features get added quickly, hotfixes are rushed to production, and contributions accumulate. Gradually, your once-readable code becomes a tangled mess.

You might think: “just add comments”. Don’t. Heavy reliance on inline comments to explain logic often signals code that needs refactoring. Exceptions exist - method documentation and complex algorithm explanations are valid, but verbose step-by-step comments usually mask unclear code.

Programming languages and frameworks are precise by design. There’s no room for interpretation. We’re engineers, we’ll understand it. While documentation, onboarding, and experience help us understand code, complexity remains the ultimate barrier though. Simple code is inherently easier to understand, extend, and maintain. The less complex your code is, the better you and others will understand (and extend and maintain) it.

I’ll try to share my thoughts on complexity:

Rather prioritize clarity over cleverness, and you’ll build systems that stand the test of time.

Abstraction layers

Does your code need to be that complex?

I’ve seen this pattern repeatedly and still fall into the trap myself. We over-engineer solutions because they’re “clever” or “future-proof,” adding layers like “X might need this later.” But ask yourself:

• Will X ever actually happen?
• What’s the real cost of maintaining these abstractions today?
• Couldn’t you add them when they’re needed?

If your answer is “Yes, I can live without it now,” delete that complexity immediately. Future-proofing often becomes future-burdening.

Example?

1public interface MyEndpoint {
2    PostResponse createPost(CreatePostRequest post);
3}
4
5public class MyRestEndpoint implements MyEndpoint {
6    public PostResponse createPost(@Valid @RequestBody CreatePostRequest post) {
7        // some logic to create the post in a service
8    }
9}

This Java example looks pretty straight forward, right? Well, it’s clean, no doubt. But why do we need an interface here? Do you really anticipate to add more implementations to create a post in your small back-end in addition to the RESTful way? No? Kill it.

Don’t over-do interfaces or abstractions. Introduce them when necessary.

That was quite an easy example. It gets worse when you see entire applications being introduced just for the sake of abstraction. Step back, think about it twice if it’s really serving any benefit despite fulfilling your engineer’s dream.

Dependencies

We all love and hate them. We love them because they eliminate the need to write code yourself. Just plug in that tool, and it handles everything without requiring a single line of custom code. We hate them when they break or demand maintenance.

Don’t reinvent the wheel, but for every dependency you add, ask:

• Is this worth the long-term maintenance cost for the 50 lines of code it saves?
• Does its quality and complexity justify the added hassle for your team?
• Is it rigorously tested and aligned with your coding standards?
• Does it introduce necessary complexity, or just bloat?

If the answer is no to any of these: Kill it.

Derived from this, it should be common sense, but here’s why you should never add unused dependencies. Adding unused dependencies to your project is a major no-go. They introduce unnecessary security risks, increase code bloat, slow down builds, and create extra maintenance overhead. Even if you’re “preparing for something”, unused dependencies expand your attack surface and complicate your codebase without delivering any real benefit.

To keep your software lean, secure, and efficient, always remove dependencies you don’t actively use. Regular cleanup helps prevent vulnerabilities, reduces build times, and makes your project easier to maintain. Remember: less is more when it comes to dependencies! It’s about reducing, not adding complexity.

Shared code

Code duplication remains a hotly debated topic in software development, balancing the need for flexibility against long-term maintainability.

While the “Don’t Repeat Yourself” (DRY) rule is foundational, blind adherence can lead to over-engineering. Short, stable code snippets or temporary prototypes might justify duplication, but uncontrolled copying creates technical debt through inconsistent logic and hidden bugs.

Adhering to the following might help balance it for you:

1. Libraries:
   • Best for: Stable, widely-used utilities.
   • Pros: Single source of truth for shared code.
   • Cons: High maintenance overhead, poor fit for volatile code.
2. Git submodules:
   • Best for: Large, semi-stable dependencies (e.g., shared API clients).
   • Pros: Atomic updates, separation of concerns.
   • Cons: IDE tooling challenges, might feel “alien” compared to a library.
3. Plain copy:
   • Best for: Experimental features or highly contextual logic.
   • Pros: Zero abstraction cost, isolated changes.
   • Cons: Manual synchronization, version drift risks, actual duplication.

When choosing an approach, inspect expected change frequency (libraries for low-churn code, copies for high-churn), cross-project use (libraries/submodules for shared code, copies for project-specific needs), and team expertise (submodules require more Git mastery while libraries demand more packaging skills).

If you find yourself duplicating code, ensure to track origins with comments, as description of a git message or document it externally with proper reasoning. As a rule of thumb, abstracting at the third duplication might serve useful to avoid complexity. In my opinion, the real danger lies not in duplication itself, but in unmanaged duplication. If you (and everyone who needs to) know where code requires synchronization, is it an issue by itself?

Tooling

Modern development offers endless tools to “simplify” configuration management, deployments, and workflows, but each new addition introduces complexity. Are you using tools to solve problems, or just creating new ones?

Ask yourself:

• Do these tools overlap? If three utilities handle similar tasks (e.g., YAML templating), you’re likely maintaining redundant abstractions.
• Are they worth the learning curve? A “magic” deployment CLI might save time initially, but obscure errors and tribal knowledge will haunt your team later. Rather solve it with KISS being very explicit about each tool used and its purpose.
• Can you debug without them? If a tool obscures the underlying process (e.g., abstracting Docker into a proprietary layer), you lose visibility when things break.

Audit your toolchain. Remove underused tools, consolidate overlapping ones, and favor transparency over “black-box” solutions. Hot take, but sometimes, a well-documented shell script beats a bloated framework.

CI/CD complexity

When building modern applications, you’ll typically rely on a pipeline to handle building, testing, and shipping your code. Whether you use GitHub Actions, Jenkins, or other tools, be mindful of the complexity your pipeline introduces. If maintaining it becomes a burden, it’s likely too complex!

Avoid letting your DevOps team dictate which tools you must use. Don’t work around artificial limitations - implement CI/CD in a way that aligns with the application’s requirements and expected environment. As the domain expert, you possess the deepest understanding of your application’s requirements and operational needs - knowledge your DevOps team might lack. Collaborate rather than circumvent. You and your DevOps colleagues share the same objectives: rapid, reliable, and automated delivery. Try to keep it simple. If there’s (nearly) zero difference between developing, building locally, and shipping a production artifact, then you’re spot on!

Simplify releases

Releases shouldn’t require code changes! Automate version bumps and changelogs instead. Use conventional commits (feat:, fix:, chore:) to auto-generate release notes directly from your commit messages. Tools like git-cliff do the rest. This means cleaner, faster releases, fewer mistakes, and everything’s auditable. Stop manually updating versions and doing all the merge backs – automate it!

Writing less complex applications or why 12 Factor Apps matter

If you’re like me and have wrestled with messy deployments or “works on my machine” bugs, the 12 Factor App methodology is a game changer. It lays out simple, practical best practices for building cloud-native apps that are scalable, maintainable, and resilient.

By standardizing how you handle code, dependencies, configs, and processes, it cuts down on complexity and those frustrating environment-specific issues. Plus, it encourages building stateless, easily deployable services that scale smoothly and bounce back quickly from failures.

In my experience, embracing these principles not only makes your life easier but also helps your team deliver reliable software faster. It’s all about working smarter, not harder, and keeping things simple where it counts.

Conclusion: Coding with clarity

This article emphasizes applying practical judgment to reduce unnecessary complexity in your codebase. Being practical and having a feeling for it often comes with experience.

• Resist over-engineering: Don’t let abstract ideals dictate your design – solve the core problem first.
• Iterate strategically: Add complexity only when requirements demand it, not as a preemptive measure.
• Legacy code can be changed: While greenfield projects benefit most upfront, apply these principles incrementally to existing systems for most value to historically grown code base.

By prioritizing simplicity, you’ll ship faster, improve maintainability, and create code that’s easier to onboard others to. Over time, refactoring replaces accidental complexity with robust, resilient systems.

The best code solves problems, not just theoretical puzzles.

Still with me? Perfect. During my research, I was particular interested how to leverage them as build tool, if they can have an impact on development workflows, and reproducibility during the usual engineering cycle. I’d like to share my experience during my experiments.

Kinda in reverse order, starting with the conclusion: This is fantastic, why did I miss that before?! They have a huge potential to accelerate development workflows, boost reproducibility and make our engineering lives easier. Wherever possible, I am going to push for it, at least for my small private projects. Though, I am unsure if they should be a first-class citizen for everything. Gradually changing existing build processes and development flows can be quite time consuming. For new projects it might be worth a try though. Also, I have no experience how this works out in distributed teams with members using that Micro*** OS (which should work just fine).

Development workflow

Collaborating with peers or on your personal projects can be cumbersome when these projects require a lot of different tooling. Maybe you’re a front-end developer, some projects use yarn, some pnpm, some are still on Node 20, and some are on recent Node LTS already. When frequently switching between (very different) projects, you’ll likely end up with a lot of tools on your PATH or some kind of tool to manage those tools. Just to cover every project. Version conflicts might pop up, specific combinations don’t work, or worse, you need to manually dive into bootstrapping tools just for specific projects, adjusting what’s on your PATH or in your environment and change every time.

I learned that there’s really no need to. When I came across direnv (and it’s actually quite popular for some time), I noticed for myself: You did it wrong all the time. Instead of preparing my operating system for the projects I work on, the projects should prepare my OS/configuration for me to work on them.

The combination of direnv with flakes is convenient. Probably no other stack can provide similar guarantees to have identical and reproducible development and production (more on that later) setups.

How does it work? How can we get the same experience on any machine with nix installed without messing up our PATH or installing tools to manage tools?

We’ll use flakes in conjunction with a tool called direnv (or better the improved nix variant nix-direnv which can handle the use flake directive). We’ll not go into details how you can set them up properly, but home manager makes it easy to get started on your machine.

Once required tools are ready (nix and nix-direnv/direnv), let’s dive deeper into our new project which we call myapp which resides on our disk at ~/Workspaces/myapp/. We plan to have bootstrap a static site generator project with gohugo.

Bootstrap your project using nix flakes

Everything (good) begins with a flake.nix file in the root project folder. It defines the environment we like to set up once we change directory into the project folder with the so called devShells (development shells).

 1# flake.nix
 2{
 3  description = "A basic flake with a dev shell";
 4  inputs.nixpkgs.url = "github:nixos/nixpkgs/nixos-24.11";
 5  inputs.systems.url = "github:nix-systems/default";
 6  inputs.flake-utils = {
 7    url = "github:numtide/flake-utils";
 8    inputs.systems.follows = "systems";
 9  };
10
11  outputs = { nixpkgs, flake-utils, ... }:
12    flake-utils.lib.eachDefaultSystem (system:
13      let pkgs = nixpkgs.legacyPackages.${system};
14      in {
15        devShells.default =
16          pkgs.mkShell { packages = [ pkgs.hugo ]; };
17      });
18}

We also need a .envrc file with use flake as content.

1# .envrc
2use flake

Let’s create a lock file. It controls the flake versions we get for any dependency. Invoke nix flake lock which creates a flake.lock file. Make sure to version control it. I also recommend adding .direnv to your .gitignore.

Let’s go back to our application. We want to create a web site which uses the static site generator gohugo. Obviously, we need the hugo binary. Usually, you would download it or install it into your PATH. You also need to think about updating it periodically. Not anymore! Everything’s ready to use with our flake definition packages = [ pkgs.hugo ]. Change directory into ~/Workspaces/myapp. If you allow direnv to be invoked (it will ask for it), then you should see an indicator in your shell. hugo is available. You can start using it as it would be globally on your PATH.

This is how it could look like:

1direnv: loading ~/Workspaces/myapp/.envrc
2direnv: using flake
3direnv: nix-direnv: Using cached dev shell
4direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +HOST_PATH +IN_NIX_SHELL +LD +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_BUILD_CORES +NIX_CC +NIX_CC_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_CFLAGS_COMPILE +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_LDFLAGS +NIX_STORE +NM +OBJCOPY +OBJDUMP +RANLIB +READELF +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +__structuredAttrs +buildInputs +buildPhase +builder +cmakeFlags +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +dontAddDisableDepTrack +mesonFlags +name +nativeBuildInputs +out +outputs +patches +phases +preferLocalBuild +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~PATH ~XDG_DATA_DIRS
5
6~/Workspaces/myapp master*
7nix-shell-env ❯ which hugo
8/nix/store/5h5q5jjr64chslxp4qwjqn86vzc1ybj5-hugo-0.136.5/bin/hugo

What we’ve achieved: an environment based on the directory you’re in. If you have a lot of projects, switching environments has never been easier. No mess on your PATH anymore. The project decides what you need and what everyone gets.

Even if you only have few projects to work on, using this method (maybe we call it git native flakes repository?) makes it easy for anyone to get started. Your environment is “inside your directory” and automatically started. You can add any nix package to it, even specific Python dependencies, Ruby, or specific versions of NodeJS and npm, e.g., with packages = [ pkgs.nodejs_20 pkgs.pnpm_9 ];.

Key takeaways from this section:

• Use flakes to manage your required environments and easily switch between them through convenience feature of direnv (nix-direnv)
• Identical development setup for everyone
• Easy to get started, just needs nix and nix-direnv/direnv on the system
• Easy to maintain and upgrade with nix flake update (and look into nix’ inputs to follow nix releases) and everyone gets the new required environment once they change into a project’s directory
• Huge time saver: you don’t need to update your dependencies on your system for all the different tools you need. The flake is doing it for you and for everyone else involved in your project as well

The static web site example is kinda simple and might not capture what you’re looking for. It also doesn’t cover the power of flakes, though it clearly shows that you can easily set up required environment/packages through flakes which are then used as development shells using direnv. Any developer in your team only needs to properly set up nix as package manager and have direnv installed. “It works on my machine” is no excuse anymore. If it works on your machine, it will work on production (and vice versa), because we’ll make production artifacts leverage our flakes as well.

Packaging and shipping

Packaging and shipping your application to production is mostly done as container image or natively. Let’s touch on the container approach first.

You might be familiar that Dockerfile container images can be quite tedious to create in the first place (... AS builder) to avoid unnecessary layers. It gets worse when we think about long-term maintenance and horrible when we talk about security. You often end up with stuff in your image you actually don’t need. Also, your development setup is likely different, right? Some packages from a repository of your operating system or maybe you’ve just downloaded that binary and put it into your PATH and now it simply “works”? And a peer wrote this pipeline with some other versions. Still works? But, should it “work” like that? The answer to that question is probably no, it should not, we should do better.

If you think about container images, you most likely want to use FROM scratch to reduce unnecessary bloat and attack surface. The issue with only adding your stuff to the image (even with builder) falls short the moment you require different types of linking and libraries. It becomes a mess to manage. Then, your next choice might be FROM alpine.

Compared to scratch images, we can achieve similar results with flakes. We already have our flake.nix file in the project’s root directory and use it for our local development setup. Let’s enhance that to build an example Go application a container image from that binary.

Here’s the full flake.nix:

 1{
 2  description = "A basic flake with a dev shell";
 3  inputs = {
 4    nixpkgs.url = "github:nixos/nixpkgs/nixos-24.11";
 5    systems.url = "github:nix-systems/default";
 6    flake-utils = {
 7      url = "github:numtide/flake-utils";
 8      inputs.systems.follows = "systems";
 9    };
10  };
11
12  outputs = { nixpkgs, flake-utils, ... }:
13    flake-utils.lib.eachDefaultSystem (system:
14      let pkgs = nixpkgs.legacyPackages.${system};
15      in {
16        packages = rec {
17          default = pkgs.buildGoModule {
18            pname = "myapp";
19            version = "latest";
20            pwd = ./.;
21            src = ./.;
22            CGO_ENABLED = 0;
23            # input actual hash by building once locally
24            vendorHash = "sha256-AAAA";
25          };
26          container = pkgs.dockerTools.buildImage {
27            name = "myapp";
28            tag = "latest";
29            created = "now";
30            copyToRoot = pkgs.buildEnv {
31              name = "image-root";
32              paths = [ default ];
33              pathsToLink = [ "/bin" ];
34            };
35            config.Cmd = [ "${default}/bin/myapp" ];
36          };
37        };
38        devShells.default =
39          pkgs.mkShell { packages = with pkgs; [ go ]; };
40      });
41}

Run nix build to build the native application (it defaults to target default). It will be placed into a result/ folder. Make sure you also add this directory/file to your .gitignore.

To build your container image, invoke nix build .#container. It will automatically build the defined default package and use it. Then, import it into your image registry with docker load < result (or podman) to make it available for further usage.

For one of my projects, I gave it a shot. It currently uses the AS builder approach and the main container image is derived with FROM alpine. Compared to the traditional way, the produced image by nix flakes is only ~71% in size.

1❯ podman image ls
2REPOSITORY                           IMAGE ID      SIZE
3git.myservermanager.com/varakh/upda  0925c69fcf0f  48.8 MB
4withnixflakes/varakh/upda            e574f8840f1d  34.9 MB

Reproducibility

When you first invoke nix build, you’ll see that it complains about a mismatched vendorHash. You can paste the proposed hash of the output into the flake.nix file. Subsequent invocations then succeed. If you don’t change your application afterward, outputs stay the same, thus the hash stays the same. Locally and on any build pipeline. If you’ve missed updating the hash, then your build fails. Transposing such a produced artifact through your different development, staging and production environments is pretty straight forward (just remember to use the load command above). Certainly, there are some benefits we’ve gained with this:

• The artifact is 100% identical when you build it, independent of your environment (due to the hash).
• The flake’s lock file ensures development and production gets the same tooling.
• direnv/nix-direnv provides a convenient way to develop your application on any machine.
• Produced (container image) artifacts are smaller in size compared to the traditional way with your Dockerfile, thus they implicitly reduce attack surface. There’s no 3rd party dependency in your image. No alpine, no ubuntu. You’re not bound to upstream changes. It’s like the FROM scratch approach, but way easier to get started and to maintain.

Build pipeline

When switching to nix (flakes) as primary build and development tool, your pipeline needs to change. Good news is, that you only need nix and enable flake usage with NIX_CONFIG=experimental-features = nix-command flakes there. Not more. Pretty straight forward and the same as locally.

Bad news is, that you might encounter increased disk space usage due to the nix building steps. Make sure that pipeline executors are deleted or at least clean up their nix store periodically. Furthermore, to do this at large scale (and I don’t have any experience with that), you probably want add your own nix cache to avoid downloading everything all over again.

Trying this out in my ecosystem

For all my private project, I use Forgejo and their runner concept. Depending on a label you select, a runner picks up a job and executes it after you’ve registered it to your instance. These labels are prefixed with docker, host, or alike. From these labels, they derive the environment they execute the pipeline in.

What we need is a “nix” runner then. As all of my machines are on NixOS, that’s pretty straight forward. I set up a new Forgejo Runner on NixOS with NixOS Containers to ensure they’re isolated.

 1{ ... }: {
 2  containers.gitea-runner = {
 3    autoStart = true;
 4    privateNetwork = false;
 5    config = { config, pkgs, ... }: {
 6      networking.hostName = "my-native-runners";
 7      networking.firewall.enable = true;
 8      environment.systemPackages = with pkgs; [ ];
 9      services.gitea-actions-runner = {
10        package = pkgs.forgejo-actions-runner;
11        instances.native-runner = {
12          enable = true;
13          name = "runner-container";
14          url = "https://forgejo.domain.tld";
15          labels = [ "native-container:host" ];
16          hostPackages = with pkgs; [
17            bash
18            coreutils-full
19            curl
20            gawk
21            gcc
22            gitMinimal
23            gnumake
24            gnused
25            gnutar
26            gzip
27            nix
28            nix-direnv
29            podman
30            wget
31          ];
32          settings = {
33            log = { level = "info"; };
34            runner = {
35              capacity = 1;
36              timeout = "1h";
37              insecure = false;
38              fetch_timeout = "10s";
39              fetch_interval = "10s";
40            };
41            cache = { enabled = false; };
42          };
43        };
44      };
45      system.stateVersion = "24.11";
46    };
47  };
48}

Then, with the applications git repository already having the flake.nix, we need to change the step definition the runner executes in the build.yaml workflow file:

 1on:
 2  push:
 3    branches:
 4      - master
 5  pull_request:
 6    types: [ opened, synchronize, reopened ]
 7jobs:
 8  build:
 9    runs-on: native-container
10    steps:
11      - uses: actions/checkout@v3
12        name: Checkout
13      - name: Build and test
14        shell: bash
15        run: |
16          nix build
17          nix build .#container

Let me know what you think. The aspects of reproducibility, developer convenience, reducing attack surface, and the simplicity in pipelines are really convincing to me. As I don’t have the setup running for a long time, I cannot derive any conclusion on maintenance costs yet, but at least from a complexity perspective it seems to just “bump the flake” with nix flake update and adapt it if changed. But you only need to do that once, not distributed in all your build tools and (local) environments.

Side note: If you don’t want to dive into nix flakes and its ecosystem entirely, you’re probably missing out on something very cool, but nevertheless, direnv plays nicely for other directives like dotenv in your .envrc which ensures that environment variables from a project’s .env file are available once you enter the project’s directory. This could already provide value to automate and start your projects in seconds. No more tinkering with your environment.

Years ago, this blog was a digital journal - raw, personal, and unpolished. But during my 2019 revival, I tried to change: English-language mostly politics in bite-sized posts. Short. Frankly, too much ranting, useless, and very opinionated. 😀

The initial shift came from discomfort. Sharing intimate life details online started feeling invasive. Privacy concerns drove that initial topic switch, but the bigger question lingered: Why keep blogging at all?

For those who want some nostalgic feelings when they see that my blog is live again, I’m afraid I need to let you down. I won’t be picking up any posts from my very old blog, which was in German, though I still have a database dump named slimblog_db_all_plus_new_from_jekyll.sql flying around here. Scrolling through them was fun! 😊

When looking at my last blog post, it seems I wasn’t that happy about the vote on net neutrality. Maybe that’s the reason I stopped - or at least I didn’t want to report anything.

The Unshakable Urge

The answer lies in an itch I can’t stop scratching - the need to share (tech) ideas and thoughts that matter. Looking back at my 2019 posts with brutal honesty? I missed the mark entirely. This time, I’m chasing more substance. Less “another dude’s hot take,” more posts worth your time.

This space needs to serve two masters now. It should be a reflection tool for my own growth, yet useful enough to justify your attention. The industry is fast, I’m constantly bombarded with tech ideas or discoveries in daily life I want to try out - things I can’t simply let go and I feel the urge to share as they’re pretty cool. Writing helps me sharpen these thoughts while (hopefully) helping others. Every post forces me to organize. But balance remains elusive. Past attempts prove this: My switch to English political posts in 2019 became less analysis, more ranting. Opinions evolve, lives change, and what felt urgent then, now reads like digital graffiti.

Here’s to new beginnings (again and with hugo instead of jekyll). Let’s see how long this one lasts. My goal is to create engaging and more insightful content that could help you. Stay tuned for contents focusing on software, development, engineering, coding, and computer science topics. Feel free to let me know if you want me to tailor this for a specific topic.

The portal boerse.* is now being blocked by German internet providers Vodafone and 1&1, because the German GEMA, an institute which “represents” artists, forced them to. Besides the “zero traffic” mobile streaming offered by the Telekom and by Vodafone, this the first time providers really don’t care too much.

Which site’s next? I’d vote for cdu.de for all users of the Telekom. We need to stop this. Now! 😀

PS: Fortunately, every German institute is very unskilled when it comes down to digital strategies and their implementation. Just change your DNS which is responsible for assigning web pages to IP address so your browser can connect. I encourage you to use the DNS servers of Digitalcourage e.V. anyway.

She also advised to not vote for “Piratenpartei” on the 25th of May. For whom shall we vote then?

So, either way: cable, unstable with “high speed” or slow robust DSL. What a choice.

The good thing is: the sheer amount of participants who protested … astonishing.

The content of our website has been compiled with meticulous care and to the best of our knowledge. However, we cannot assume any liability for the up-to-dateness, completeness or accuracy of any of the pages.

Pursuant to section 7, para. 1 of the TMG, we as service providers are liable for our own content on these pages in accordance with general laws. However, pursuant to sections 8 to 10 of the TMG, we as service providers are not under obligation to monitor external information provided or stored on our website. Once we have become aware of a specific infringement of the law, we will immediately remove the content in question. Any liability concerning this matter can only be assumed from the point in time at which the infringement becomes known to us.

Limitation of liability for external links

Our website contains links to the websites of third parties (“external links”). As the content of these websites is not under our control, we cannot assume any liability for such external content. In all cases, the provider of information of the linked websites is liable for the content and accuracy of the information provided. At the point in time when the links were placed, no infringements of the law were recognisable to us. As soon as an infringement of the law becomes known to us, we will immediately remove the link in question.

Copyright

The content and works published on this website are governed by the copyright laws of Germany. Any duplication, processing, distribution or any form of utilisation beyond the scope of copyright law shall require the prior written consent of the author or authors in question.

Data protection

A visit to our website can result in the storage on our server of information about the access (date, time, page accessed). This does not represent any analysis of personal data (e.g., name, address or e-mail address). If personal data are collected, this only occurs - to the extent possible - with the prior consent of the user of the website. Any forwarding of the data to third parties without the express consent of the user shall not take place.

We would like to expressly point out that the transmission of data via the Internet (e.g., by e-mail) can offer security vulnerabilities. It is therefore impossible to safeguard the data completely against access by third parties. We cannot assume any liability for damages arising as a result of such security vulnerabilities.

The use by third parties of all published contact details for the purpose of advertising is expressly excluded. We reserve the right to take legal steps in the case of the unsolicited sending of advertising information; e.g., by means of spam mail.