Tower of Kubes

OpenCode: The Agentic Tool That Anthropic and Google Don't Want You To Use

2026-05-05T00:00:00Z

For the past four months, OpenCode has been my primary agent tool. A piece of AI industry drama is what brought it to my attention.

Background

In January 2026, I started seeing drama online: Anthropic blocks third-party use of Claude subscriptions. The most surprising part to me wasn’t that Anthropic decided to block this type of usage, that’s unfortunate but expected. What surprised me was that I hadn’t known this was even possible in the first place.

I had briefly read about OpenCode and Crush during my Agentic CLI Tools Comparison, but hadn’t used them due to their BYO (Bring Your Own) API key requirement, which in most cases is significantly more expensive than subscription tiers. As it turns out, people had found ways to use those subscriptions anyway. OpenCode had implemented an OAuth flow that spoofed Claude Code’s HTTP headers to authenticate against Anthropic’s API with a Claude Pro or Max subscription. This gave OpenCode users access to Claude models at subscription pricing, a significant cost advantage.

The Crackdown

Anthropic’s response came in several phases. Active enforcement began on January 9, 2026, when Anthropic deployed server-side protections blocking all unofficial OAuth access. On February 19, Anthropic updated its legal compliance page to make the OAuth restriction explicit: OAuth tokens obtained from Claude subscription accounts are only permitted for use with official Claude tools.

Legal requests followed, and in mid-March OpenCode’s maintainers merged a PR removing the Anthropic OAuth plugin from the project. By early April, Anthropic extended restrictions to OpenClaw and other third-party harnesses. Google ran the same playbook with Gemini around the same period, banning third-party OAuth access and issuing account-level suspensions.

The Community Reaction

The Hacker News thread filled with genuine disappointment. Many users felt OpenCode was a significantly better tool than Claude Code. The main advantages cited were its open-source MIT license, an optional web UI and client/server architecture, and the absence of flickering, a complaint about Claude Code that hasn’t gone away. OpenCode had also grown remarkably fast, reaching over 150,000 GitHub stars.

OpenAI and GitHub went the other direction. Tibo, OpenAI’s Codex lead, announced on X that Codex subscribers could use their subscription directly within OpenCode, and GitHub formally announced support for OpenCode across all GitHub Copilot subscriptions. That’s what originally got me to give OpenCode a real try, paired with GitHub Copilot and ChatGPT subscriptions, and I’ve been using it regularly since.

My Impressions of OpenCode

OpenCode immediately seemed appealing when I started using it. Until that point, Claude Code had remained my preferred agentic CLI tool. In the months since I wrote Agentic CLI Tools Comparison, I had continued experimenting with different CLI tools and models, notably Claude Code 2.0, Codex CLI, Gemini CLI, and GitHub Copilot CLI. Claude Code consistently remained the best tool in my opinion, both in terms of UI design and features, and in terms of Anthropic’s models feeling the strongest at coding and agentic tool usage based on my experience. The other tools felt like UI imitations of Claude Code running different models, with no meaningful improvements. OpenCode is genuinely different, though. It runs on a client/server model with an HTTP API, supports 75+ AI providers including local models, and has native multi-session support.

When opening OpenCode in a terminal, it feels familiar but different. The starting screen looks a lot like a classic search engine, with the prompt box centered on the screen, rather than being off to the bottom like in most other agentic CLI tools.

However, once you enter an initial prompt, the prompt box moves to the bottom of the terminal, making for a more familiar look. In my opinion, OpenCode strikes a good balance: it will feel familiar to users who have used Claude Code (and similar tools) before, but at the same time it does not feel like a clone of other tools. OpenCode does a lot of unique things that other tools don’t do. For example, OpenCode has a useful sidebar that displays information about active MCPs, LSPs (language servers) and token usage for the current session.

The look of OpenCode becomes even more unique when using its web UI or the OpenCode desktop app.

Image source: Web | OpenCode

Models and Providers

When first using OpenCode, it defaults to using the OpenCode Zen models. As of today, OpenCode Zen offers several free models, as well as paid models.

When using OpenCode Zen, it’s recommended to read about the privacy for each model.

These paid models can either be used by paying for credits (similar to OpenRouter) or using the OpenCode Go subscription. However, OpenCode does not limit to only using their offering. One of the best features of OpenCode is its wide provider support. LLM models can be used from practically any provider (that hasn’t outright blocked OpenCode), or even use local models. This provides users a lot of flexibility to use the same tool across many different models, with one unified agent harness. It also means users are not “locked-in” to one provider if they want to continue using OpenCode. When providers change the terms, such as Claude and Gemini limiting usage of OpenCode, or GitHub Copilot changing the terms of their subscriptions, OpenCode users can just move to other providers and continue their existing workflow.

Agentic Tool Usage

Using one tool for all providers also means that I can have a unified place to configure my MCP servers, Skills and AGENTS.md files. While there have been attempts to standardize the agents world, including the Agentic AI Foundation (AAIF), the reality is that agentic tools still have different ways to configure. For example, Anthropic to date has refused to adopt the usage of the AGENTS.md file, instead referring only to the CLAUDE.md file.

OpenCode supports these emerging agent standards, as well as LSP servers (Language Server Protocol, which has been around before agents, to give code editors better support for programming languages). At the same time, OpenCode also has its own config file.

As an example, if you want to configure Chrome DevTools MCP server, add the following to your OpenCode config:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "chrome-devtools": {
      "type": "local",
      "command": ["npx", "-y", "chrome-devtools-mcp@latest"]
    }
  }
}

OpenCode also supports a range of built-in tools, including web searches. One of my personal favorite tools is the question tool. It allows the model to ask you questions mid-task: for gathering preferences, clarifying instructions, or getting decisions on implementation choices. Each question includes a header, question text, and a list of options, with the ability to type a custom answer. When there are multiple questions, you can navigate between them before submitting.

It’s Dangerous: Permissions and Safety

OpenCode is a powerful tool, and with great power comes great responsibility. By default, it will happily edit anything, run anything, and delete anything without asking, which can feel great for vibe-coding but can also wreak havoc on your machine and codebases if left unchecked. For users that are coming from Claude Code, the default permissions feel similar to the claude --dangerously-skip-permissions flag. By default, OpenCode does not ask permission for anything. It edits files freely and can run any command. Even when using “Plan” mode (instead of “Build” mode), OpenCode can still run commands (by default the “Plan” mode only disallows file edits). Fortunately, this is fairly easy to fix. To get a locked-down OpenCode, add this to your OpenCode config:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "ask"
  }
}

OpenCode Permissions can be customized further.

It is also worth running OpenCode in a sandboxed environment. Refer to my previous article on Claude Code Sandboxing for examples on how to achieve this.

Final Verdict: Is OpenCode Better Than Claude Code?

Overall, OpenCode is a very compelling agent tool, with wide model support and lots of features. It is certainly among the best AI tools I have ever used.

On the question of “OpenCode vs. Claude Code”, I would say both tools are honestly equally strong. OpenCode felt like a breath of fresh air after months of using Claude Code, with many unique features. For example, mouse support, which Claude Code has only recently gained and is currently still a preview feature. At the same time, going back to Claude Code after several months of only using OpenCode, I have noticed Anthropic have not been resting and have been frantically adding new features to Claude Code, including plugins and a plugin marketplace, Agent Teams for multi-agent orchestration, the /btw command for lightweight side questions, and Auto mode, a new permission tier that sits between manual approval and skipping permissions entirely.

Overall, OpenCode feels surprisingly more polished (despite being developed by a much smaller team), while Claude Code has the edge in raw features. Nevertheless, the tools feel very close in quality. The choice between them ultimately comes down to one question: do you have a Claude subscription?

As I explained at the opening of this article, Anthropic has made their stance clear that Claude subscriptions are only for use within official Claude tools, and third-party tool usage is blocked for subscribers. Claude Code also locks you into Claude models exclusively, with no support for other providers.

If you’re already paying for a Claude subscription, Claude Code is the natural fit, as it’s the only tool where Anthropic’s subscriptions are officially supported. If you’re not, OpenCode’s model flexibility and open-source nature make it a compelling alternative that gives you full control over both your models and your costs.

Featured image by Viktor Forgacs on Unsplash.

TrueNAS Removes SMART Scheduling

2026-01-25T00:00:00Z

I have recently learned that TrueNAS 25.10 (Goldeye) removed SMART Scheduling from the Web UI:

Quote

SMART Monitoring:

25.10 removes the built-in SMART test scheduling and monitoring interface to improve user flexibility for disk monitoring. The smartmontools binaries remain installed and continue to be used internally by TrueNAS, ensuring that existing third-party scripts and monitoring tools continue to work unchanged. Users seeking advanced SMART monitoring can install the “Scrutiny” app from the TrueNAS catalog, which offers superior disk health tracking with historical data storage, customizable alerts, and automatic drive detection. TrueNAS maintains monitoring of critical disk health indicators and automatically migrates existing scheduled SMART tests to cron tasks during upgrade. See Disk Management for more information on disk health monitoring in 25.10 and beyond.

25.10 (Goldeye) Version Notes | TrueNAS Documentation Hub

This is a baffling change. TrueNAS is a NAS (Network Attached Storage) operating system. Data integrity is important for NAS users, it is important enough that TrueNAS has a “Data Protection” tab (which was where SMART tests used to be scheduled, before that section was removed in the 25.10 update).

SMART tests have their flaws, even so they can be very valuable and were used by many TrueNAS users, including me! One of the reasons I liked using TrueNAS was how easy it was to schedule SMART tests and ZFS scrub tasks.

What Are SMART Tests?

SMART (Self-Monitoring, Analysis and Reporting Technology) is the drive’s built-in health reporting. It exposes attributes (error counters, temps, reallocated/pending sectors, etc.) and can run self-tests on demand.

The two tests most people schedule are:

Short test: quick sanity check.
Long/extended test: full surface scan that can take hours (and may impact performance while running).

SMART tests don’t replace ZFS scrubs (scrubs verify data end-to-end), but they’re still useful as an early warning system for drives that are slowly going bad.

What Exactly Did TrueNAS Remove?

Technically, iXsystems did not remove any SMART functionality from the system, only a UI section. SMART tests can still be scheduled using cron, though it is more cumbersome. For such a critical task, I appreciate having a UI that explains when tests are scheduled and makes it easy to schedule them at different times.

Indeed, the SMART UI in TrueNAS was never great. For as much as I avoid using TrueNAS apps (for reasons such as TrueNAS having broken every single app in the past when they moved from Kubernetes to Docker), the one app I always install is Scrutiny. It explains the SMART results better than any other app that I have found. Nevertheless, I take issue with the recommendation to use it as if it’s an alternative (“Users seeking advanced SMART monitoring can install the “Scrutiny” app from the TrueNAS catalog, which offers superior disk health tracking with historical data storage, customizable alerts, and automatic drive detection”). Scrutiny is great at displaying SMART results, however it does not schedule the tests itself. Scrutiny is also seeking new maintainers. What would’ve been nice was if instead of just pointing users to a third-party app, iXsystems would have stepped up and contributed to Scrutiny, acknowledging the things it does better than TrueNAS itself while also working to bring a better SMART UI to TrueNAS. Notably, iXsystems have contributed back to OpenZFS.

How Did the TrueNAS Community Respond?

What was perhaps more infuriating than the decision itself was the stubbornness in ignoring the community feedback that followed. A feature request to Bring back SMART scheduling to UI was opened on the Feature Requests section on the TrueNAS forums, stating “Literally no one approves this change. Bring it back.”. The feature request gained significant traction: it received 121 votes and 110 responses. In the end, after internal discussion, the feature was denied (with explanations that many users didn’t find convincing).

If this doesn’t prove that iXsystems doesn’t care about community feedback, I don’t know what does. So much for TrueNAS “Community Edition”.

Will I Keep Using TrueNAS?

I have been using TrueNAS for several years, since the release of TrueNAS SCALE in 2022 (which has since been renamed to TrueNAS Community Edition). I have maintained scripts that help install TrueNAS on Proxmox VE. To this day, TrueNAS remains a critical part of my homelab.

Of course there are alternatives. Before I moved to TrueNAS, I was using OpenMediaVault (OMV). I have high praise for that project, and unlike TrueNAS and Unraid, OMV is community-driven with no profit motives (donations are accepted). The main reason I moved to TrueNAS at the time was the native ZFS integration. OMV relies on a plugin to enable ZFS. It works, but I preferred a system that’s designed to work with ZFS from the get-go (I was able to export my ZFS pool from OMV and import it into TrueNAS with no data loss).

These days, if I were to move away from TrueNAS, I will likely go the DIY route instead. When I think of what I use TrueNAS for, all I really need is a system that supports ZFS, NFS/SMB data shares, SMART tests and Scrutiny. I am currently experimenting with a NixOS installation that does all of that in one declarative configuration.

Nevertheless, for now I plan to stay with TrueNAS (at least until I finish examining NixOS for this purpose). I will continue using TrueNAS for the time being, ensure SMART tests are still scheduled in cron, as well as continue using Scrutiny.

There is value in having a curated and tested NAS distribution, even if I don’t agree with all of their decisions. I am reminded of the time that Linus Sebastian lost a petabyte of data, due to having manually configured ZFS on CentOS without data scrubbing. In TrueNAS, data scrubbing is configured by default to run automatically, and at least the scheduling UI for that has not been removed.

Featured image by Frank R on Unsplash.

Claude Code Sandboxing

2026-01-13T00:00:00Z

A couple of days ago, my coworker Roey Wullman wrote this article: Claude Code Sandboxing: Stop Babysitting Your AI Assistant (published in Develeap’s Magazine).

This morning, I saw the latest announcement by Anthropic: Introducing Cowork | Claude, then read the comments on Hacker News. Some of the comments discussed how secure Cowork is (or isn’t) and how it’s sandboxing works. Then other comments mentioned different approaches of sandboxing Claude Code (e.g. this comment and these comments).

Ways to Sandbox Claude Code

Featured image by Markus Spiske on Unsplash.

New Configuration Languages - MAML and TOON

2025-11-18T00:00:00Z

I came across this article today: Things I Don’t Like in Configuration Languages. It mentions an overwhelming amount of configuration languages. XML, JSON and YAML are well known, but there are many others, some of which I have heard about and even used (for example, I have used TOML, JSON5 and JSONC), others were entirely new to me (there are more JSON variants than I realized). The article didn’t even mention KYAML.

What’s the solution for this mess? More configuration languages!

xkcd: Standards

MAML

Quote

Cloudflare Workers

2025-11-18T00:00:00Z

Introduction

I have been considering different options for hosting static-sites for free. In my personal notes, I previously wrote about three differenet services for static website hosting: GitHub Pages, Cloudflare Pages and Codeberg Pages. Two of these options now have more modern alternatives: Grebedoc instead of Codeberg Pages and Cloudflare Workers instead of Cloudflare Pages.

Cloudflare Workers vs Cloudflare Pages

Although Cloudflare Pages is still around, since 2023 Cloudflare has been merging some of the features into Workers. Nowadays, while both Pages and Workers can be used, Workers is the preferred option (Migrate from Pages to Workers · Cloudflare Workers docs). Workers now has all the same static asset hosting features as Pages, plus additional features.

Pricing

In terms of pricing, Workers & Pages Pricing | Cloudflare lists the prices for both Workers and Pages. At first glance, the Workers Free tier appears to be more limited than Pages Free tier. Pages Free boasts “Unlimited sites”, “Unlimited requests” and “Unlimited bandwidth”, while Workers Free says “Includes 100k requests per day”, which is a far cry from “unlimited”. However, delving into the Cloudflare Worker docs, reveals the distinction:

Quote

Requests to static assets are free and unlimited. Requests to the Worker script (for example, in the case of SSR content) are billed according to Workers pricing. Refer to pricing for an example.
There is no additional cost for storing Assets.

Billing and Limitations · Cloudflare Workers docs

Therefore, my understanding is that Cloudflare Workers is free and unlimited for static assets, and only costs money with requests to Worker scripts (importantly, clients loading static assets do not count as “requests”). This is essentially the same as Cloudflare Pages pricing, it only starts to potentially cost money if you go beyond what Pages can do and into other Worker features.

Why use Cloudflare Workers?

Despite today’s outage, I find Cloudflare to be generally reliable and use its free tier for most of my self-hosted websites and services. The only thing I pay for is domain registration, and domains are fairly priced (offered at cost). Many people have concerns over Cloudflare’s control of the web. I understand those concerns but it’s not something that I personally worry about. I enjoy taking advantage of their generous free tier either way.

Because I already use Cloudflare as my domain registrar, it makes sense to also take advantage of their static website hosting features and the included unlimited traffic.

Compared to GitHub Pages

Both Cloudflare Pages and Workers have less limitations than GitHub Pages. The most notable limitation of GitHub Pages that I can find is that the free tier of GitHub Pages and wikis only allows using “Public repositories”.

Compared to self-hosting

Self-hosting a website is possible as I have the infrastructure for it at home. After I completed the bootcamp, I kept my final project (PetInvent) up for several months on a self-hosted Docker Compose stack (PetInvent + PostgreSQL + nginx), which was running on my homelab along my other other self-hosted services. However, I don’t have the same uptime as Cloudflare. And even if I did, I still rely on Cloudflare anyway (Tunnels + domain), even for self-hosting. I might as well use their hosting as well if it doesn’t cost me anything.

Documentation

Some relevant pages from Cloudflare Workers docs:

Tip

Cloudflare Workers docs have guides for various frameworks which I am using or considering using, including React + Vite and Docusaurus. These guides can either be followed directly, or npm create cloudflare@latest can help bootstrap a project for various frameworks with correct Workers configurations.

Can I use Cloudflare Workers for my projects?

Based on the docs, Cloudflare Workers may be ideal for CALMe, which uses React + Vite for the frontend and Docusaurus for the documentation. My current goal is to set up a Continuous Deployment for CALMe, with the main branch deploying live to my FQDN on Cloudflare using Cloudflare Workers. After I get main working, I can setup a fancier CD flow with previews on pull requests.

For my personal website, I was leaning towards using Hugo, which works with Cloudflare Workers.

Featured image by Sharad Bhat on Unsplash.

Chrome DevTools MCP server

2025-11-16T00:00:00Z

I have recently been using Chrome DevTools MCP server (which I tend to call Chrome MCP) to work on personal projects, notably CALMe. In my first day of using MCP, I added Playwright MCP server to my .mcp.json. Both Playwright MCP and Chrome DevTools are MCP servers that work in similar ways, they give MCP clients (agentic CLI tools) various tools that give the ability to browse web pages, click on buttons, read console logs and even “see” how the web page looks by allowing the client to take screenshots/snapshots. Playwright MCP is based on the Playwright framework for Web Testing and Automation, and is developed by Microsoft. Chrome DevTools MCP is based on the world’s most popular browser, and specifically its DevTools, and is developed by Google. Two big tech giants, which means these MCPs are well developed.

The comment that prompted me to try Chrome DevTools MCP

While Playwright MCP was working okay for me, I saw that Chrome DevTools was released after and wondered if it’s any better.

A comment from this thread (which I also linked in Cool MCP Servers) prompted me to try it: What MCPs are you using with Claude Code right now? : r/ClaudeCode

Question

What’s the advantage of chrome devtools vs playwright mcp?

Conclusion

Faster, more capable. Reads the console logs, and can execute scripts. The long screenshots are great too

I used to use playwright but Chrome dev tools blew me away

Guide: Using Chrome DevTools MCP

Claude Code

At the project level, run:

claude mcp add --scope project chrome-devtools npx chrome-devtools-mcp@latest

This configures the following in the .mcp.json file:

{
  "mcpServers": {
    "chrome-devtools": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest"
      ],
      "env": {}
    }
  }
}

Then simply open a new instance of claude and confirm that you trust the folder and MCP server. Run the /mcp slash command to verify that the MCP server appears as “✔ connected”.

To use the MCP server, I simply tell Claude something like “use chrome mcp to test and troubleshoot website x”. I would add more context depending on the specific task, but in general this is enough to let Claude know that it can use this MCP server.

Codex CLI

The Codex CLI sandbox makes working with Chrome DevTools MCP more challenging, though I managed to make it work (Source: Connecting to a running Chrome instance | ChromeDevTools/chrome-devtools-mcp: Chrome DevTools for coding agents).

Run the following command:

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --browser-url="http://127.0.0.1:9222"

In addition, if live websites need to be tested, allow network access by adding the following lines to the global Codex config:

[mcp_servers.chrome-devtools] 
command = "npx" 
args = ["chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9222"]

[sandbox_workspace_write] 
network_access = true 

Now, every time we want to use Codex CLI with Chrome DevTools MCP, we must first run this command in the background:

nohup /usr/bin/google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug-headful --no-first-run --disable-gpu about:blank >/tmp/chrome-launch.log 2>&1

Gemini CLI

At the project level, run:

gemini mcp add chrome-devtools npx chrome-devtools-mcp@latest

This configures the following project settings:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest"
      ]
    }
  }
}

Other MCP clients

Follow the instructions in MCP Client configuration | ChromeDevTools/chrome-devtools-mcp: Chrome DevTools for coding agents.

Featured image by Growtika on Unsplash.

Home Assistant on Kubernetes

2025-11-13T00:00:00Z

Today I learned Home Assistant can run on K8s using this Helm Chart: pajikos/home-assistant-helm-chart: Helm Chart for Home Assistant

Quote

This Helm chart bootstraps a Home Assistant instance on Kubernetes, supports configurable persistence, controller types, add-ons (e.g. code-server), and is auto-updated with new Home Assistant releases.

Telegram: View @KubeBuilders

My Opinion

For over two years, I have been running Home Assistant on Home Assistant Green, which comes pre-installed with Home Assistant OS.

The device has been working perfectly well for all of my smart home needs. Even though it is not the most cost-effective way to run Home Assistant, it is a well-designed device, fast enough for my needs and power efficient.

If I were buying a new dedicated device for Home Assistant today, I may have preferred to get a mini PC instead, since some mini PCs are similar in price to the HA Green but significantly more powerful (though maybe not as power efficient). However, I would still strive to run Home Assistant with Home Assistant OS.

Why standalone device for Home Assistant

On recent podcast episodes of Linux Unplugged (including LINUX Unplugged 637: Chris’ Smart Home Disaster), Chris talked about considering a move away from the Home Assistant Yellow (which is more powerful than the HA Green), perhaps towards a mini PC running multiple services (rather than just a mini PC). Chris also debated the benefits of running Home Assistant on NixOS vs Home Assistant OS. Nevertheless, I tend to agree with Chris’s long-standing stance that it’s best to give Home Assistant its own device, because of how essential it can be to a home.

Why Home Assistant OS

I run all my other self-hosted services in containers. Why not Home Assistant as well? The reason is that Home Assistant OS makes everything easy. Notably, Home Assistant Container installations don’t have access to add-ons.

Quote

Add-ons are additional standalone third-party software packages that can be installed on Home Assistant OS. \[Learn more\]

Installation - Home Assistant

Although Add-ons are really just containers, and many Home Assistant users manage to install them as separate containers, this requires elaborate configurations to make the different containers work together with Home Assistant. Even though I’ve been doing Docker Compose stacks (for example, applications that have multiple containers including a database), the moment I found out that HAOS allows one-click installation of Add-ons, I immediately gravitated towards that simplicity. Some examples of Add-ons that I use and rely on are Matter Server, Zigbee2MQTT and Music Assistant.

Backups are also fairly simple on HAOS.

Benefits of the Home Assistant Helm Chart

Nevertheless, I do find the idea of this Home Assistant Helm Chart compelling. Features such as replicas and partial add-ons support make this an interesting alternative to HAOS. I may run a test deployment in my parent’s home, since that’s where my homelab cluster is.

Featured image by Jakub Żerdzicki on Unsplash.

Grebedoc

2025-11-13T00:00:00Z

Today I learned about Grebedoc — static site hosting for git forges.

Note

Grebedoc is Codeberg spelled backwards. I find this name very clever, especially since it has “doc” in it (static site hosting can be used for Markdown Documentation|documentation).

This is a new option for Static Website Hosting, which can serve as an alternative to GitHub Pages. Codeberg already a similar solution called Codeberg Pages, though Codeberg Pages had a big scary warning that says it is in maintenance mode. Grebedoc is using new software, git-pages, so does not rely on Codeberg/pages-server (which is the part of the Codeberg Pages stack that is in maintenance mode).

Origin Story

Quote

One of Grebedoc maintainers here! I came up with the idea for Grebedoc (and its underlying software, git-pages) when I realized that I have an extreme degree of dependency on GitHub Pages from many years of using GitHub, but it also seemed pretty likely that sooner or later, GitHub will stop subsidizing my efforts one way or another, and I need a backup plan.

I originally wanted to just use Codeberg Pages, but it had some significant scaling and uptime issues (that I don’t want to rehash here). I ended up concluding that the reasonable way forward is a redesign, which is what I’ve built and deployed with a small team of other volunteers. It took about a month of work and the whole thing, anycast and all, costs about 35€/mo to run. Also, Codeberg Pages is currently trialing the use of git-pages as the new pages backend, and you should be able to use it on the *.codeberg.page domain already (it responds to the same POST/PUT requests as Grebedoc)/

whitequark’s comment on Grebedoc — static site hosting for git forges | Lobsters

The fact that the entire global stack “costs about 35€/mo to run” is impressive. Though, I wonder what the increase in cost will be when more people start using Grebedoc.

Can I use Grebedoc for my personal projects?

One of my concerns was that Grebedoc sites would have to use a Codeberg repository. Codeberg looks good, though it is more limiting than GitHub or GitLab since they require every repo to use an open source license. This also raises concerns when creating a website/blog of my own, will any content hosted on a Codeberg repo also have to be licensed for the public domain?

However, based on grebedoc.dev, using Codeberg is not mandatory. There is a small learning curve to understanding how to host a site on Grebedoc, but the main page explains different scenarios clearly. There is a size limitation:

Quote

The size of a website is currently limited to 1 GiB. We are aiming to eventually raise this to 10 GiB.

Note

UPDATE: Originally, the size limit was 768 MiB, but this has recently been raised to 1 GiB.

Based on all of that, it looks like I should be able to host small websites (up to 1 GiB) on Grebedoc, no matter which Git forge I choose to use and the repo can also remain private. I can use my own domains if I want, though Grebedoc also allows using *.grebedoc.dev or *.codeberg.page subdomains. All of this is free, as far as I can tell there is no paid-tier (Codeberg is a non-profit, they can be supported, but this is not required for using anything they offer).

Resources

Featured image by Tina Rolf on Unsplash.

Pre-commit hooks for Node.js projects

2025-11-10T00:00:00Z

This is my workflow for integrating pre-commit hooks for Node.js (NPM) projects. I combine this with my Oxc Workflow.

What is a Git pre-commit hook?

A pre-commit is a type of Git Hook that runs before each commit. It can help with verifying code standards (linting, formatting, testing etc.).

Pre-commit tools

pre-commit

A tool written in Python, though can be used with projects in any language. Can be configured to run many hooks including pre-commit/pre-commit-hooks and Gitleaks. I have used this tool and like it for Python and other projects, though for Node.js projects, I prefer the options below.

Husky

A pre-commit hooks tool written in JavaScript. I prefer this tool for Node.js projects since it can be easily integrated in package.json scripts.

lint-staged

Another tool that’s written in JavaScript, to help run checks against staged files (see Guide below). Lint-staged does not configure git pre-commit hooks on its own, but can be combined with Husky.

simple-git-hooks

Another git hooks manager written in JavaScript. Use to be more lightweight than Husky, but newer versions of Husky closed the gap.

Guide: Husky + Lint-staged + Oxc workflow

Configure oxlint and oxfmt based on my Oxc Workflow.
Install devDependencies:

npm install --save-dev husky lint-staged

Initialize husky:

# Installed
./node_modules/.bin/husky --init

# Not installed
npx run husky --init

Configure lint-staged to run Oxc and tsc checks:

[/**
 * @filename: lint-staged.config.js
 * @type {import('lint-staged').Configuration}
 */
export default {
  '**/*.[jt]s?(x)': [
    'oxfmt',
    'oxlint --type-aware --type-check --fix',
  ],
  '**/*.ts?(x)': () => 'tsc -p tsconfig.json --noEmit',
}

Note

Can be further configured, but this is a good start for a project using TypeScript and Oxc.

Configure husky to run lint-staged as a pre-commit hook:

npm exec -- lint-staged --config lint-staged.config.js

Add a preparescript in package.json :

  "scripts": {
    "prepare": "husky"
  },

This script may have already been added by husky --init.

Featured image by Yancy Min on Unsplash.

Oxc Workflow

2025-11-10T00:00:00Z

Here’s how I like to setup new Node.js projects, with linting and formatting using Oxc.

Oxc

I wrote about Oxc (The JavaScript Oxidation Compiler) in Next Generation Tooling for Developers. When I first wrote this article, Oxc already included a linter (oxlint, which can replace ESLint), but the formatter was not available yet. Since then, VoidZero has continued the development of Oxc, not only launching Vite+ but also launching a formatter (oxfmt, which can replace Prettier). With the combination of oxlint and oxfmt, I now have a modern-alternative to ESLint + Prettier. Note that this might not work as a replacement in all existing projects that rely on specific configurations of ESLint and/or Prettier. However, for new Node.js projects, I will strive to go with the Oxc stack.

Why Oxc instead of ESLint + Prettier?

The two main reasons I prefer Oxc is speed and ease of configuration; as I have explained in Next Generation Tooling for Developers, the Rust-based tools are noticeably faster. In addition, they have a more modern design with more intutive configuration. In particular, ESLint has become a nightmare to configure after the breaking changes in ESLint v9.

Guide

One-time run

These tools can be run in a project without being installed or added to package.json using npx commands:

npx oxlint@latest

npx oxfmt@latest

Install Oxc tools in NPM project

For consistent usage in an npm project, Oxc packages can be added as devDependencies.

npm install --save-dev oxlint@latest oxlint-tsgolint@latest oxfmt@latest

Initialize configuration for oxlint

Quote

Configuration files for Oxlint are written in JSON, with support for comments (JSONC). Oxlint will automatically search for files named .oxlintrc.json and automatically use those. But you can name the file anything when you are using the --config CLI option.

Configuring Oxlint | The JavaScript Oxidation Compiler

Use the --init option to initialize a .oxlintrc.json file:

## If installed
./node_modules/.bin/oxlint --init

## If not installed
npx oxlint@latest --init

Initialize configuration for oxfmt

Quote

By default, oxfmt automatically tries to find the nearest .oxfmtrc.json or .oxfmtrc.jsonc file from current working directory. If not found, default configuration is used.

Also you can specify your config file by -c yourconfig.jsonc flag.

Almost all format options are compatible with Prettier’s options. So you may finish your setup by just renaming .prettierrc.json to .oxfmtrc.jsonc.

Formatter | The JavaScript Oxidation Compiler

Use the --init option to initialize a .oxfmtrc.json file:

## If installed
./node_modules/.bin/oxfmt --init

## If not installed
npx oxfmt@latest --init

A previous version of this article, suggested to use prettier-init (before oxfmt had the --init option).

MCP Security

2025-11-04T00:00:00Z

Ziva Wernick did a Google AI workshop today and learned about MCP. She raised valuable concerns about MCP security and privacy.

Security: Has to do with the security risk of using MCP servers, and the possibility of those servers to facilitate malicious actions.
Privacy: Has to do with AI tools constantly collecting private information. In some cases there may be an option to opt-out, or pay for an enterprise license that limits what the provider can do with the data.

I will focus on Security in regards to how it works with agentic CLI tools and MCP servers.

MCP Horror Stories

Docker Blog wrote a series called MCP Horror Stories:

Part 1: MCP Security Issues Threatening AI Infrastructure | Docker
Part 2: MCP Horror Stories: The Supply Chain Attack | Docker
Part 3: The GitHub Prompt Injection Data Heist | Docker
Part 4: MCP Horror Stories: The Drive-By Localhost Breach | Docker

Unrelated to Docker, there’s also this article that features “Five Horror Stories That Actually Happened”: The Day I Told 800+ Engineers Their AI Dreams Could Become Security Nightmares

Five Horror Stories That Actually Happened 😱

The GitHub Data Heist (CVSS: 9.6/10)
The mcp-remote Catastrophe (437,000 Environments Compromised)
Container Escape via Tool Poisoning (CVSS: 9.4/10)
The Great Secrets Exposure
WhatsApp MCP Shadowing

For more information on each “horror story”, read the full article:

The Day I Told 800+ Engineers Their AI Dreams Could Become Security Nightmares

First Malicious MCP in the Wild

On 2025-09-25, Koi Blog wrote this article: First Malicious MCP in the Wild: The Postmark Backdoor That’s Stealing Your Emails | Koi Blog

Quote

postmark-mcp - downloaded 1,500 times every single week, integrated into hundreds of developer workflows. Since version 1.0.16, it’s been quietly copying every email to the developer’s personal server. I’m talking password resets, invoices, internal memos, confidential documents - everything.

This is the world’s first sighting of a real world malicious MCP server. The attack surface for endpoint supply chain attacks is slowly becoming the enterprise’s biggest attack surface.

The article generated some discussion, including on Hacker News: A Postmark backdoor that’s downloading emails | Hacker News. Some of the comments pointed out that the MCP risk isn’t really different from existing software risks:

Quote

This has nothing to do with MCP really, the same flaw is there in all software: you have to trust the author and the distributor. Nothing stops Microsoft from copying all your Outlook mail. Nothing stops Google from copying all your gmail. Nothing stops the Mutt project from copying all your email. Open source users like to think that “many eyes” keep the code clean and they probably do help, especially on popular projects where all commits get reviewed in detail, but the chance is still there. And the rest of us just trust the developers. This problem is as old as software.

Are MCP Security risks real or overblown?

MCP security risks are a real concern and I do not want to downplay that. In many ways though, these risks have existed for as long as software itself, MCP is just the latest attack vendor.

I will note that the blogs I featured here, from Docker and Koi Security, are from companies that attempt to sell solutions to this problem. This does not mean that the problem is not real or that the solutions are not needed, just something to note. I actually do find Docker’s MCP solutions to be very interesting (I mention Docker MCP Catalog below in Supply-Chain Security).

MCP Defense

The article “The Day I Told 800+ Engineers Their AI Dreams Could Become Security Nightmares” (mentioned above in MCP Horror Stories), suggests five defense solutions:

The Solution: Defense in Depth (That Actually Works) 🛡

Component Isolation
️Attack Surface Reduction
Supply Chain Security
Input/Output Sanitization
WhatsApp MCP Shadowing

For more information on each solution, read the full article:

The Day I Told 800+ Engineers Their AI Dreams Could Become Security Nightmares

What I Do

So far I have been limiting my MCP usage to personal projects and learning. Below are some of the things I have noted while learning about how to use MCP “safely”:

Supply-Chain Security

When Ziva asked about the MCP security risks, she was told to “read the code”. While it’s true that many MCP servers are open-source, reviewing all of them is not exactly feasible. I often do a surface level look at the repo, its activity and amount of stars, but this is not same as reviewing the code in-depth. For this reason, I believe it is worth using MCP servers by known publishers. Docker does come in handy here with their Docker MCP Catalog. While, this catalog is not as extensive as other MCP galleries, it focuses on quality over quantity. All of the MCP servers are in the Docker MCP Catalog are by known publishers. Note that I still refuse to use Docker Desktop (due to its license), but these MCP servers can also be used in Docker CLI together with an MCP client.

MCP Server Configuration

Some MCP servers may have permissive default permissions, but can be configured to be more “locked-down” and limited and what they can do and access.

As an example, Kubernetes MCP Server can be run in read-only mode (this is not the default but can be set with a flag when setting up the MCP server). In this mode, the Kubernetes MCP server cannot make changes to clusters (for example, it is unable to apply manifests, but can still view existing resources). Note that even in this mode there can be security risks. One example is viewing secrets. In Kubernetes, secrets are stored in Base64 strings, which are trivial to decode for anyone that has full read access to the cluster. I have personally witnessed Claude Code attempt to read and decode Kuberenets Secrets (either with Kubernetes MCP Server or just kubectl commands) when asked to help troubleshoot my homelab cluster. For this reason, when using agentic CLI tools, I prefer to approve each command individually. Further, Kubernetes access can be regulated with Role-based access control (RBAC).

Ignore files

Similar to .gitignore files, most agentic CLI tools have a way to exclude specific files from the context. For example, a .env file (that may include secrets), should be specifically excluded (when not doing this, I have seen Claude Code attempt to read these files). Unfortunately, there isn’t really a standard “ignore file” for this, each tool has it own way to achieve this. If using multiple tools, multiple files might be needed.

Documentation on excluding/ignoring files

Featured image by FlyD on Unsplash.

Tour de Sonol Around Kinneret 2025

2025-11-01T00:00:00Z

After two years of postponements, the Kinneret cycling race finally happened again. It was the 45th edition of the event but my first time riding it. This was not my first time riding part of the Kinneret loop, though. I rode 40 KM during Tri Kinneret 2025 when I finished the Olympic triathlon in April 2025.

My friend Yehuda signed up for this event a year ago, but it kept getting postponed. His registration was carried over to the new date. I only registered a few weeks ago, after confirming I would be home on the event date (2025-11-01). We both registered for the 60.5 KM amateur course. Even though I am not at the same fitness level I was a few months ago, I kept riding about once a week for an hour on Zwift. From a fitness perspective, I believed I could finish the full distance.

Yehuda and I arrived on Friday at the Jacob Ohalo Kinneret hotel. Location-wise, the hotel was right at the start of the tour route, so there was no need to drive to the starting line. On Friday we brought pasta and had a carb-loading dinner. We went to sleep around 23:00. The next day we woke up at 6 a.m., got organized, and headed to the course at 7 a.m.

The ride took me about 3 hours; I finished at 10:15. I took water breaks but otherwise pedaled continuously. This was my first time riding clipped in outdoors. Until now, I had only used cleats on the trainer. I was afraid of falling. A few months ago I bought pedals with a power meter, Garmin Rally XC200, and shoes with compatible cleats. On Friday I practiced clipping in and out outdoors for the first time. After a few minutes I felt I understood it, and despite the risk I decided to ride the tour that way. Thankfully, I managed to ride the full course clipped in.

There were a lot of people at the tour; estimates talk about 10,000 riders. In Tri Kinneret most people had road or TT bikes. In contrast, on this tour I saw a wide variety of bikes: road, mountain, hybrid, tandem, hand cycles, and more. The age range was also wide; I saw young kids riding with their families. One kid told me his six-year-old sister had just learned to ride and was already doing 30 KM.

Even so, road bikes were the ideal bikes for this course. One hundred percent of the route was paved asphalt, with no off-road or dirt sections (like there were at Sovev Jerusalem). As a result, I could ride very fast on my road bike (Giant TCR). On one descent I reached a top speed of 56 KM/h. On the other hand, my average speed was much lower, 21 KM/h. In many sections I felt a need to slow down. The roads were closed to car traffic in all lanes, but there were so many bikes on the road and many people did not keep to the right when riding slowly.

This was my longest ride in terms of distance, but not in terms of time. Sovev Jerusalem in May 2025 was a more challenging ride because there were climbs, off-road sections, and I rode my mountain bike, which is heavier and slower than my road bike.

This ride was good preparation for Tri Kinneret 2026.

Official video

Official poster

Featured image by Johnnie Cohen on Unsplash.

Istio Gateway

2025-10-19T00:00:00Z

Istio as a Gateway and Ingress Controller

Istio is known for its service mesh capabilities, however it can also serve as a Gateway and Ingress Controller, with support for both Ingress resources and Gateway API resources. Some view this use-case as overkill. However, my own testing of using Istio exclusively as a gateway (without a service mesh) proves that it can in fact work quite well for this purpose. This is strengthened by the benchmarks done by Howard John.

My Rationale for using Istio

Here’s one potential reason I found to use Istio for ingress/gateway instead of Envoy Gateway: Coraza WAF.

I was previously using ingress-nginx which has easy-to-enable support for ModSecurity and OWASP CRS (Core Rule Set). Since ingress-nginx is planned to eventually be replaced with InGate, I decided to look at the currently available Gateway API implementations and what WAF (Web Application Firewall) support they have. I found out that the more modern alternative to ModSecurity is OWASP Coraza WAF. From my research it seems to be able to use Coraza with Envoy Gateway you have to use Tetrate Enterprise Gateway.

However, upon further research I found this OpenShift guide: Creating a Web Application Firewall in Red Hat OpenShift. This guide uses Coraza Proxy WASM with Istio. Istio seems to be required in order to be able to use the WasmPlugin custom resource. I believe that following this guide it should work with Istio on non-OpenShift K8s just the same.

My Installation

I can confirm this works even without OpenShift! I tested this on my Talos staging cluster. Once Istio is installed and configured with the WASM Plugin for OWASP Coraza WAF, test malicious requests get blocked as expected.

The difficult part for me was getting Istio installed and figuring it out how to configure it as a gateway for Ingress and HTTPRoute resources. I wanted to avoid using the more advanced features of Istio (service mesh, ambient mesh etc.), at least for now. I have not used Istio before so there was a learning curve, certainly more complex than ingress-nginx. However, once I got Istio working as a gateway like I wanted, applying the WASM Plugin was relatively straightforward.

This is the solution that I am now using for my “homelab-as-code” Talos cluster.

Istio Gateway Installation

The main resources which I followed are:

I followed these resources, then adapted them for my own Argo CD GitOps structure and made them work with my existing adyanth/cloudflare-operator and cert-manager deployments. I used some Istio custom resources to make the same Istio Gateway work with both Ingress resources and Gateway API resources. This essentially made Istio a drop-in replacement for my previous ingress-nginx deployment (any existing Ingress resources now use Istio as the default ingress class), with the added ability to now use Gateway API.

Benchmarks

Howard John works on Istio, so is not entirely without bias (which he admits). Nevertheless, he has created Gateway API Benchmarks, a common set of tests to evaluate a Gateway API implementation. Istio comes out quite favorably in the benchmark ("✅ No issues were found"): howardjohn/gateway-api-bench: Gateway API Benchmarks provides a common set of tests to evaluate a Gateway API implementation.

UPDATE: John Howard has released Gateway API Benchmarks - Part 2. According to the new benchmarks, Istio is still among the leading Gateway API implementations; however, the new Agentgateway has better performance in the Route Scale and ListenerSet Scale benchmarks.

Featured image by Sam Moghadam on Unsplash.

Lima and Colima

2025-10-16T00:00:00Z

Today I learned about Lima and Colima, which help run Linux VMs and containers on macOS.

I learned about these tools while writing How To Install Docker. Although I’ve heard about them in the past, I kept forgetting what they were called, which is one reason I am writing about them now.

Lima

Lima launches Linux virtual machines with automatic file sharing and port forwarding (similar to WSL2).

Lima: Linux Machines | Lima

As this description states, Lima is similar to WSL. When using Windows, I have gotten used to a workflow based around WSL, both for Docker and with Git. I have not used macOS yet but expect to one day get a MacBook as a work laptop, and will have to learn an effective workflow for macOS.

Colima

Colima - container runtimes on macOS (and Linux) with minimal setup.

GitHub - abiosoft/colima: Container runtimes on macOS (and Linux) with minimal setup

Differences between Lima and Colima

How does Colima compare to Lima?

Colima is basically a higher level usage of Lima and utilises Lima to provide Docker, Containerd and/or Kubernetes.

colima/docs/FAQ.md at main · abiosoft/colima · GitHub

“How does Lima relate to Colima?”

Colima is a third-party project that wraps Lima to provide an alternative user experience for launching containers.

The key difference is that Colima launches Docker by default, while Lima launches containerd by default.

Colima (third-party project) | Lima

It’s worth noting that current versions of Lima also support using Docker as a container runtime, and the same is true the other way: Colima supports using containerd as a container runtime.

Installation

Install Lima

Installation | Lima

Example

# Homebrew
brew install lima

# MacPorts
sudo port install lima

# Nix
nix-env -i lima

Install Colima

Colima is available on Homebrew, MacPorts, and Nix. Check here for other installation options.

Example

# Homebrew
brew install colima

# MacPorts
sudo port install colima

# Nix
nix-env -iA nixpkgs.colima

Using Docker with Lima and Colima

Docker with Lima

Documentation / Examples / Containers / Docker | Lima

Lima Docker Rootless

limactl start template://docker
export DOCKER_HOST=$(limactl list docker --format 'unix://{{.Dir}}/sock/docker.sock')
docker run -d --name nginx -p 127.0.0.1:8080:80 nginx:alpine

Lima Docker Rootful

limactl start template://docker-rootful
export DOCKER_HOST=$(limactl list docker-rootful --format 'unix://{{.Dir}}/sock/docker.sock')
docker run -d --name nginx -p 127.0.0.1:8080:80 nginx:alpine

Docker with Colima

Docker client is required for Docker runtime. Installable with brew brew install docker.

You can use the docker client on macOS after colima start with no additional setup.

brew install docker
colima start

Linux Support

Both run on Linux hosts. Lima also supports non-macOS hosts (Linux, NetBSD, etc.) and Colima’s README lists Linux as supported.

There’s less reason to use Lima/Colima on Linux than on macOS, but it may still be useful in certain cases, since it is another way to run VMs on Linux.

Apple Container

After years of mac users using projects such as Lima, Colima and others in order to run containers on macOS, Apple released their own solution a few months ago: Container. This seems like a good solution that likely has good performance. Notably, this solution is not based on Docker, but can nevertheless run OCI containers.

Featured image by Aarom Ore on Unsplash.

How To Install Docker

2025-10-16T00:00:00Z

This is how I like to install Docker on my workstations.

Choose Environment

Docker runs best on Linux. If using Linux, skip to Install Docker below. If using Windows, read the WSL section first.

Note

I don’t use macOS so cannot advise on installation methods for Docker on macOS. However, Lima, Colima and Rancher Desktop are possible options. See Alternative Docker Installation Methods below.

WSL

On Windows, Docker Engine can be installed inside WSL. This is an alternative to using Docker Desktop (unlike Docker CE, Docker Desktop is not open source).

Install WSL command

You can install everything you need to run WSL with a single command. Open PowerShell in administrator mode by right-clicking and selecting “Run as administrator”, enter the wsl --install command, then restart your machine.

wsl --install

Note

This command will enable the features necessary to run WSL and install the Ubuntu distribution of Linux. (This default distribution can be changed).

Install Docker

These commands all need to run in a Linux shell.

1. Install using the official Docker installation script

/bin/sh -c "$(curl -fsSL https://get.docker.com)"

If you are using WSL, you may get a warning about Docker Desktop. Since we do not use Docker Desktop, simply ignore this warning (wait 20 seconds and the installation will resume).

2. After the install completes, complete the Linux post-installation steps for Docker Engine by running the following commands

sudo usermod -aG "docker" "${USER}"
newgrp docker
sudo systemctl enable --now docker.service
sudo systemctl enable --now containerd.service

Optional: Confirm Docker Is Installed

These commands all need to run in a Linux shell.

1. Confirm `docker` is installed and check versions

docker version
docker --version

2. Confirm the `docker buildx` and `docker compose` plugins are also installed (likely already installed alongside `docker`)

docker buildx version
docker compose version

3. Run a test container

docker run --rm hello-world

Alternative Docker Installation Methods

Note

I do not suggest Docker Desktop as an installation method because it is not open source.

Manual Install: Follow the steps in Install | Docker Docs according to your distribution.
Ansible: Use geerlingguy/ansible-role-docker: Ansible Role - Docker.
Docker on NixOS: Docker - NixOS Wiki.
Rancher Desktop: Follow Installation | Rancher Desktop Docs.
Lima: Lima; GitHub - lima-vm/lima: Linux virtual machines, with a focus on running containers.
Colima: GitHub - abiosoft/colima: Container runtimes on macOS (and Linux) with minimal setup.

Docker Alternatives for Running OCI Containers

Note

All of these tools can run OCI containers (sometimes referred to as “Docker containers”).

Resources

Featured image by Ian Taylor on Unsplash.

Git Setup for Windows and WSL

2025-10-16T00:00:00Z

Introduction

Setting up Git correctly on both Windows and WSL is essential for a smooth development workflow, especially in environments where you switch between the two.

This guide ensures

Consistency – Your Git configuration and credentials work the same way in Windows and WSL, avoiding conflicts or repeated prompts.
Security – By using Git Credential Manager (GCM) from Windows inside WSL, you get secure token storage without duplicating credentials.
Efficiency – No need to manage separate credential helpers or manually sync .gitconfig files between systems.

Follow these steps to install Git, configure it properly, and enable seamless authentication across both environments.

Git for Windows Setup

Note

These commands all need to run in Windows PowerShell.

1. Install Git for Windows. Git for Windows can be installed with the following command

winget install -e --id Git.Git --source=winget

Tip

If you need Git LFS, also run the following command:

winget install -e --id GitHub.GitLFS --source=winget

2. Verify installation of Git for Windows (including Git Credentials Manager) with the following command

git --version; git credential-manager --version

3. Set your Git email and username

Tip

If you are using GitHub, you can use your GitHub username and the “no-reply” email address from GitHub Email settings.

$env:GIT_EMAIL = "your-git-email"

$env:GIT_USER  = "your-git-username"

4. Run the following commands to set initial settings for `.gitconfig`

Tip

These settings help avoid common git warnings.

git config --global color.ui "auto"
git config --global init.defaultBranch "main"
git config --global user.email "$env:GIT_EMAIL"
git config --global user.name  "$env:GIT_USER"

Git on WSL Setup

Note

These commands all need to run in WSL.

1. Install git and git-lfs packages. On Debian/Ubuntu

sudo apt-get update && sudo apt-get install git git-lfs

2. Verify installation of Git and Git LFS

git --version && git lfs --version

3. Copy your existing `.gitconfig` file from Windows

cp "$(wslpath -a "$(cmd.exe /c ")")" "${HOME}/.gitconfig"

4. Configure Git Credentials Manager

git config --global credential.helper "$(wslpath -a "$(powershell.exe -NoProfile -Command "Write-Host -NoNewline (Join-Path ((Get-Item (git --exec-path)).Parent.Parent.FullName) 'bin\git-credential-manager.exe')")")"

Featured image by Gabriel Heinzer on Unsplash.

Next Generation Tooling for Developers

2025-10-12T00:00:00Z

In recent months I have been learning about Astral: High-performance Python tooling. I first learned about Astral’s tools from this article: I’m Switching to Python and Actually Liking It and have started using uv and ruff. This led me to try to find similar tools for other languages.

What makes a tool “next generation”?

Note

I am not focusing on AI tools in this article. I have other articles on this subject (such as Agentic CLI Tools Comparison).

The projects below have a few things in common. The projects are led by companies which have similar missions to develop modern tooling for developers. All of the tools below are open-source under the MIT License.

Most of the tools are written in modern compiled languages such as Rust or Go. Many of the tools boast significant performance improvements compared to previous tools, as well as a more modern design with better Developer Experience (DX or DevEx).

As a result, these tools tend to feel both faster and easier to use than the tools that they aim to replace.

Toolsets

Python

Astral: High-performance Python tooling

Astrals’s Mission

Quote

Astral’s Mission

We build high-performance developer tools for the Python ecosystem.

Our mission is to make the Python ecosystem more productive.

By building tools that enable developers to ship great software, faster.

Tools that change how we work.

About | Astral

Astral’s Projects

uv (Docs | GitHub): An extremely fast Python package and project manager, written in Rust.
ruff (Docs | GitHub): An extremely fast Python linter and code formatter, written in Rust.
ty (Docs | GitHub): An extremely fast Python type checker and language server, written in Rust.
python-build-standalone (Docs | GitHub): This project produces standalone, highly-redistributable builds of Python. Used in uv.

Note

Rye is another tool that was maintained by Astral, however it is no longer developed and uv is considered “the successor project from the same maintainers”.

JavaScript/TypeScript

VoidZero | Next Generation Tooling for the Web

VoidZero’s Mission

Quote

The Mission

We are building a unified high-performance toolchain for JavaScript: including parser, transformer, resolver, linter, formatter, minifier, bundler, test runner, and meta framework support. Our mission is to make the next generation of JavaScript developers more productive than ever before.

VoidZero | Next Generation Tooling for the Web

VoidZero’s Projects

Vite (Website | GitHub): The build tool for the web.
Vitest (Website | GitHub): Next generation testing framework powered by Vite.
Rolldown (Website | GitHub): Fast Rust bundler for JavaScript/TypeScript with Rollup-compatible API.
The JavaScript Oxidation Compiler (Oxc) (Website | GitHub): A collection of JavaScript tools written in Rust.

ByteDance Web Infra Team

Web Infra’s Mission

Quote

Web Infra

We are from ByteDance, our goal is to build an open technical ecosystem to promote the development of frontend technology.

Web Infra · GitHub

Web Infras’s Projects

Rspack (Website | GitHub): Fast Rust-based web bundler with webpack-compatible API.
Rsbuild (Website | GitHub): Zero-config build tool powered by Rspack.
Rspress (Website | GitHub): A fast Rsbuild-based static site generator.
Rsdoctor (Website | GitHub): A one-stop build analyzer for Rspack and webpack.
Rslib (Website | GitHub): Create JavaScript libraries in a simple and intuitive way.
Rstest (Website | GitHub): The testing framework powered by Rspack.
Rslint (Website | GitHub): High-performance JavaScript and TypeScript linter written in Go.
Midscene.js (Website | GitHub): AI Operator for Web, Android, Automation & Testing.
Modern.js (Website | GitHub): Progressive web framework based on React and Rsbuild.
Garfish (Website | GitHub): Powerful micro front-end framework.

Business Model

All of the tools mentioned above are primarily developed and maintained by companies. This raises the question, if the tools are FOSS (Free and Open Source), what are their business models?

ByteDance of course owns TikTok. They make enough money already and can afford contributing to open-source if they so chose. My theory is that ByteDance likely wants to continue contributing to open-source to put them in the same positive light as Western tech companies (for example Meta, who developed many open-source projects including React, Docusaurus and Llama).

On the other hand, Astral and VoidZero are both venture-backed. While they can afford to lose money for a period while gaining users, eventually they will want to find a way to extract value. In the past, when the founders of the companies were asked about this, they gave somewhat vague statements.

However, more recently, Astral introduced pyx (a Python-native package registry):

Quote

Beyond the product itself, pyx is also an instantiation of our strategy: our tools (uv, Ruff, ty, etc.) remain free, open source, and permissively licensed — forever. Nothing changes there. Instead, we’ll offer paid, hosted services like pyx that represent the “natural next thing you need” when you’re already using our tools: the Astral platform.

pyx: a Python-native package registry, now in Beta

It is likely that VoidZero will go for a similar strategy in the future, by introducing paid services that go alongside the free tools.

The tools themselves are still FOSS, and all are licensed under the permissive MIT License. These companies know that if they ever attempt to change the license or terms for these tools, the community will immediately fork the projects (as has happened many times in the past with other open-source projects).

Note

UPDATE: VoidZero has launched Vite+.

My Experience

I have listed a lot of tools from these companies, of course I have not tried all of the tools mentioned above.
I have been using Astral’s projects, uv and Ruff, and had good experience with both, and I want to try ty as well. As I’m getting more into TypeScript development with React, Docusaurus and Cloud Development Kit (CDK), I have been trying out some of the TypeScript tools as well.
In the case of Docusaurus, I tried Docusaurus Faster which uses Rspack (by Web Infra), as well as SWC and Lightning CSS. This makes it almost as fast as Rspress (another project by Web Infra). The difference in build times is immediately noticeable compared to building Docusaurus with Webpack.
The speed difference is also felt in uv; compared to pip, uv downloads the same packages noticeably faster. I have further explained my love for uv in uv is incredible.
Ruff works well as both a Linter and Formatter. Ty does the same for type checking in Python.
Besides the speed, I have also noticed these tools tend to be easier to use than the older, less modern tools that the aim to replace. The focus on Developer Experience (DX or DevEx) is apparent.
Recently, I have been trying out TypeScript Linters and Formatters and wrote about the Rust Alternatives. Oxc looks promising, it currently has a Linter, while the Prettier-compatible Formatter is still under development. Once the Formatter is ready, I will try using Oxc (instead of ESLint + Prettier), at least for projects that don’t require specific ESLint plugins that aren’t yet supported by Oxc.

Note

UPDATE: oxfmt is now available and I have been using it in my projects alongside oxlint.

I wrote more about using Oxc in Oxc Workflow).

Vite

Out of all the projects I listed here, Vite is probably the most widely used. It’s popular enough to have gotten its own documentary: Vite: The Documentary - YouTube
I have been using Vite for React apps, notably CALMe. Ever since create-react-app has been deprecated, I have been consistently seeing Vite as one of the top recommendations, including in the React Documentation: Creating a React App and Build a React app from Scratch.
Vite is being integrated with Rolldown: Rolldown Integration | Vite

Featured image by Anton Savinov on Unsplash.

Cloud Development Kit (CDK)

2025-10-12T00:00:00Z

I’ve been learning about CDK at work, using it for Infrastructure as Code (IaC).

What is CDK?

These “Cloud Development Kits” are used for defining and provisioning cloud infrastructure resources using familiar programming languages including TypeScript, Python, Java and Go. In AWS, CDK is offered in addition to AWS SDK for various languages.

What they share: all three use the constructs programming model (object-oriented code → declarative infra).
What they target:

AWS CDK → CloudFormation templates (JSON/YAML) + asset packaging.
cdk8s → Kubernetes manifests (YAML).
CDKTF → Terraform configuration (Terraform JSON), then Terraform does the planning/applying/state.

CDK Family

AWS CDK: AWS Cloud Development Kit Documentation
cdk8s: cdk8s (Website)
CDKTF: CDK for Terraform | Terraform | HashiCorp Developer

As far as history goes, it seems AWS CDK was first, then cdk8s, and finally CDKTF. I remember the hype about CDKTF a few years ago.

`cdk synth`

The different CDK tools each have their own CLI, however some commands are similar and related. For example cdk synth.

“synthesize”

Turn constructs-based code → declarative output for the downstream engine.

Tool	Command	Produces	Next step
AWS CDK	`cdk synth` (alias: `cdk synthesize`)	CloudFormation template(s)	`cdk deploy`
cdk8s	`cdk8s synth`	Kubernetes Manifests	`kubectl apply -f dist/`
CDKTF	`cdktf synth`	Terraform JSON	`cdktf plan` / `cdktf deploy`

Quick CLI

Stage	AWS CDK	cdk8s	CDKTF
Init	`cdk init app --language ts`	`cdk8s init typescript-app`	`cdktf init --template=typescript`
Bootstrap / State	`cdk bootstrap`	(none)	Configure TF backend (state)
Synthesize	`cdk synth`	`cdk8s synth`	`cdktf synth`
Preview	`cdk diff`	`kubectl diff -f dist/`	`cdktf plan`
Deploy	`cdk deploy`	`kubectl apply -f dist/`	`cdktf deploy`
Destroy	`cdk destroy`	`kubectl delete -f dist/`	`cdktf destroy`

Construct Hub

Construct Hub helps developers find open-source construct libraries for use with AWS CDK, CDK8s, CDKTF and other construct-based tools.

Supported Programming Languages

Language	AWS CDK	CDKTF	cdk8s
TypeScript	✓	✓	✓
JavaScript	✓		✓
Python	✓	✓	✓
Java	✓	✓	✓
C#	✓	✓
Go	✓	✓	✓

Most Used Programming Languages

Reddit Poll for AWS CDK shows “JavaScript or TypeScript” as the most used: Poll: Which programming language do you use for AWS CDK? : r/aws
Reddit Poll for CDKTF shows “Python” as the most used: Poll: Which programming language do you use for CDKTF? : r/Terraform

Comparison to HCL

The most used IaC language remains HCL, using Terraform or OpenTofu.

HCL syntax is designed to be easily read and written by humans, and allows declarative logic to permit its use in more complex applications.

GitHub - hashicorp/hcl: HCL is the HashiCorp configuration language.

HCL is declarative, compared to traditional programming languages which are imperative. HCL is a good fit for provisioning IaC, however some find it limiting. While solutions like Terragrunt address some of Terraform’s limitations, some wished for the flexibility of a full programming language. This was what led to the birth of HCL.

CDKTF still uses Terraform providers under the hood, and synthesizes to valid Teraform JSON.

My Usage At Work

At my client, I wanted to use OpenTofu for IaC. However, I was told that AWS CloudFormation is what’s already used internally at the client.

For my current use-case, my IaC mainly consists of an EC2 instance configured for use as a Bitbucket Runner. I decided to use AWS CDK for this use case, as it works with AWS CloudFormation but is more flexible than the JSON syntax that CFN uses.

Converting my working OpenTofu HCL code to AWS CDK TypeScript code was frustrating and made me curse AWS multiple times. However, I eventually got it working and functionally equivalent to what I already had working with OpenTofu.

My Opinion

Declarative vs Imperative IaC

I personally don’t find much value in using a “real” programming language for IaC. I believe Terraform owes a lot of success to the simple, imperative nature of HCL, and in some ways succeeded because of its limitations and not despite them.

My experiences with Pulumi and AWS CDK show me that if not being careful, the IaC could turn into spaghetti code. Of course, the potential for spaghetti code exists for HCL as well, especially when attempting to overcome some of its limitations. However, I believe for many of the common use-cases of IaC, the imperative design fits better and should be used unless there is a specific need for a “real” programming language.

AWS CDK

Assuming I get the choice, I wouldn’t willingly use AWS CDK again. I have tried many IaC tools. Terraform, Ansible, OpenTofu, Terragrunt and Pulumi. Out of all ones I tried, AWS CDK was by far the most confusing.

CDKTF

I was initially interested in CDKTF, but it seems it has gained very little traction compared to Terraform or OpenTofu:

I was also concerned that CDKTF might not work well with OpenTofu. It seems it does currently work even if it’s not officially supported, but might break in the future: Port cdktf to OpenTofu · Issue #601 · opentofu/opentofu · GitHub

I believe that CDKTF is now an afterthought for HashiCorp, compared to Terraform. Development for CDKTF is not completely abandoned, but based on recent activity development seems slow and mainly focuses on fixes and dependency updates, rather than major new features.

cdk8s

I haven’t found a compelling reason to use this either. I’m not sure where exactly it fits into the Kubernetes manifest landscape between KYAML, Helm Charts, Kustomizations, CUE/HCL and GitOps solutions (mainly Argo CD and Flux CD).

Info

UPDATE: CDKTF has been archived: GitHub - hashicorp/terraform-cdk: Define infrastructure resources using programming constructs and provision them using HashiCorp Terraform

Pulumi IaC

Not technically CDK but is similar in many ways. Supports TypeScript, JavaScript, Python, Go, C#, Java and YAML. Last year, Pulumi introduced support for any Terraform Provider, With that, I believe Pulumi can serve as a solid replacement for CDKTF (not a drop-in replacement, but can be functionally equivalent). Unlike HashiCorp, which seems to treat CDKTF as an afterthought, Pulumi (the company) is primarily focused on Pulumi IaC. pulumi/pulumi is open-source under the Apache-2.0 license, though Pulumi as a company also offers paid solutions (such as Pulumi Cloud).

If I had to choose between CDKTF and Pulumi, I would lean towards Pulumi.

Photo by Abraham Barrera on Unsplash.

My Experience with Claude Sonnet 4.5 and Claude Code 2.0

2025-10-06T00:00:00Z

After the announcement of Claude Sonnet 4.5 and Claude Code 2.0, I finally had a little bit of time to experiment with the new Claude versions today.

My first impressions is Claude Sonnet 4.5 feels slightly better than Sonnet 4. At least that’s more than I can say for GPT-5, which my first impressions of weren’t as positive (it felt like a downgrade compared to o3, but I’ve gotten used to it).

Honestly, it’s hard to tell though. I find it hard to give objective feedback on LLM models. There are benchmarks that claim to be objective, but benchmarks don’t tell the full story of how a model actually feels in real world use. It’s kind of similar to how phone benchmarks don’t necessarily tell the fully story on how smooth a phone actually feels in real world use; for example Google Pixel models are not technically as powerful as some of the competition, but have optimized software that makes them feel smooth to use.

When evaluating LLM models, I try to use them as normal. Sometimes I give the same prompt to different LLM models to gauge the differences in answers and which gives the “best” response. However, even that is not always effective; since LLM answers are non-deterministic and even asking the same model inside the same tool the same prompt twice can give different answers (sometimes even wildly different). The differences can be even larger when using the same model across different tools. I feel like I get significantly different answers when using GPT-5 in ChatGPT 5, Microsoft Copilot, Cursor CLI, Codex CLI and Perplexity Pro.

Which brings me back to today. I was working on documentation frameworks, specifically setting up Docusaurus, with Claude Code 2.0 and Sonnet 4.5. This is actually a task I’ve done several times in the past with previous versions of Claude Code using the Sonnet 4 model. This time, I was trying to vibe code less and actually understand every line of code I was writing so that I would eventually feel confident deploying Docusaurus in production (using static website hosting). Nevertheless, I still used Claude Code to help me with some menial tasks, while making an effort to read every single line of code (rather than just “vibe coding”). Because I have done this task before, it might have been a decent benchmark if I had actually tried to examine it in that way, but really I was just trying to get a task done.

As for the results? I managed to achieve what I was trying to do, but really my goal in the first place was to rely less on AI. I still consulted Claude Code frequently. It gave some good responses, some dumb responses and some mid responses. Not too different from usual, maybe slightly better, but again hard to tell. I don’t plan to make a more rigorous test of Sonnet 4 vs Sonnet 4.5, I don’t mind trusting the benchmarks in this case. In many benchmarks Sonnet 4.5 even beats Opus 4.1!

Usage Limits

Before I even had a chance to try it myself, I saw many posts on r/ClaudeCode complaining about usage limits getting worse. Many of these posts were from users paying for the expensive $100-$200/month Claude MAX plans. A lot of them complained about reaching usage limits faster than before while using Claude Opus 4.1 in Claude Code. It’s not clear to me why those users insisted on still using Opus 4.1 despite some benchmarks showing that Sonnet 4.5 has surpassed it, but to be fair the ability to use Opus in Claude Code is one of the selling points of the MAX plans. On my $20/month Claude Pro plan, I can only use Opus 4.1 on claude.ai, not inside Claude Code. I haven’t found that a huge limitation though since I was still getting good results with Sonnet 4 and will presumably get even better results with Sonnet 4.5.

One of the most useful features added in Claude Code 2.0 is /usage, which allows to see daily and weekly usage. It still doesn’t show how much the tokens you use really cost, for that I still use ccusage.

Unfortunately, this comes with new weekly rate limits. I missed this at first but now I believe this might be the main cause of what the community has been complaining about it. Weekly rate limits were one of the features I disliked most about ChatGPT, back when o3 was limited to 50 prompts a week I was genuinely rationing my usage of o3. Since the launch of GPT-5, the limits for ChatGPT 5 Thinking have been raised significantly, to the point that I don’t reach those limitations anymore.

As for Claude Code, until now I found the usage limits to be fairly reasonable. The limits were in 5 hour blocks, not daily or weekly. It would take me two full hours of heavy vibe coding before a limit was actually reached. In cases where I was taking a more active role in coding I often did not reach the limit at all. Even when the limit was reached, it was unlikely I would have to wait the full 5 hours, since often I would be either in the middle or near the end of the 5 hour block anyway (one time I only had to wait 5 minutes for the limits to reset). The end result was that I felt like I could practically use Claude Code as much as I want without really worrying about limits, since worse case I would just take a break and wait a few hours for all of the limits to reset. I also saw little value in the more expensive Claude MAX plans.

Now with the weekly limits, there is a larger risk of reaching them. After just one day of medium usage, I already used 11% of the weekly limit (which resets on 2025-10-12). I’m not that worried though, since reaching the limits if anything would give me more time to experiment with other agentic CLI tools. I read that Codex CLI also has a weekly limit; one user claimed that Codex is so much better than Claude Code that they ration it, use CC for easier tasks and save Codex for the more complex tasks. In any case, I believe using a combination of free AI tools and paid subscriptions is both more cost-effective and more insightful compared to committing to one tool and paying an expensive “MAX” subscription.

Featured image by Aerps.com on Unsplash.

Diátaxis framework for technical documentation

2025-10-05T00:00:00Z

Today I learned about Diátaxis, a framework for technical documentation.

Quote

Diátaxis is a way of thinking about and doing documentation. It prescribes approaches to content, architecture and form that emerge from a systematic approach to understanding the needs of documentation users.

Diátaxis identifies four distinct needs, and four corresponding forms of documentation - tutorials, how-to guides, technical reference and explanation. It places them in a systematic relationship, and proposes that documentation should itself be organised around the structures of those needs.

Diátaxis solves problems related to documentation content (what to write), style (how to write it) and architecture (how to organise it).

As well as serving the users of documentation, Diátaxis has value for documentation creators and maintainers. It is light-weight, easy to grasp and straightforward to apply. It doesn’t impose implementation constraints. It brings an active principle of quality to documentation that helps maintainers think effectively about their own work.

I Need To Write Documentation

I’ve been thinking a lot about documentation recently, experimenting with software such as Material for MkDocs and Docusaurus. These frameworks solve the problems of how and where to write documentation (Markdown files served as a static site by one of these frameworks together with static website hosting). However, they don’t solve the much more important problem of what to write about. There’s an entire field of technical writing.

I am now in a situation where I need to write several pieces of documentation. My client requested I create documentation for them based on what I’m working on, to both on-board new users/developers on how to work on the codebase and run pipelines, as well as two explain in-depth to any future DevOps Engineers or admins about how I set up our cloud infrastructure, repositories, custom tools and pipelines. Two pieces of documentation are needed. For the client, I will use Confluence; I am not a fan of Atlassian, but the alternative for this client is to write Word documents. Confluence will do. Besides, I’m not going to setup Docusaurus for this client.

At the same time, I also want to write documentation for my “homelab-as-code” project and to help write documentation for CALMe (together with Josh, who works as a technical writer).

Diátaxis

I learned about Diátaxis from Khue’s Homelab: Updating documentation (this website) - Khue’s Homelab

Khue’s Homelab is one of the most impressive homelab projects that I’ve seen. “Fully automated homelab from empty disk to running services with a single command”. It is also well documented. It uses the Diátaxis technical documentation framework:

Quote

There are 4 main parts:

Getting started (tutorials): learning-oriented
Concepts (explanation): understanding-oriented
How-to guides: goal-oriented
Reference: information-oriented

These four parts are the basis of Diátaxis:

Quote

At the core of Diátaxis are the four different kinds of documentation it identifies. If you’re encountering Diátaxis for the first time, start with these pages.

Tutorials - learning-oriented experiences
How-to guides - goal-oriented directions
Reference - information-oriented technical description
Explanation - understanding-oriented discussion

Diátaxis prescribes principles that guide action. These translate into particular ways of working, with implications for documentation process and execution. Once you’ve made your first start, the tools and methods outlined here will help smooth your way.

The compass - a simple tool for direction-finding
Workflow in Diátaxis

Should I Adopt Diátaxis?

On first impressions Diátaxis looks great. Writing it may be somewhat challenging at first as I learn to structure technical writing in this way, but the results may well be worth it. I am having a hard time finding alternative documentation frameworks (though I’m sure they exist). The alternative for me to using Diátaxis would be free-flow documentation based on the topics that I think I should cover; this is how I have been writing documentation until now which does work but may end up a bit messy. Of course, Diátaxis is not perfect either and there are criticisms for it: My Problem With the Four-Document Model.

Featured image by Sigmund on Unsplash.

uv is incredible

2025-09-30T00:00:00Z

I have recently learned about uv and the uv workflow. Since then, I’ve been using uv a lot more, both for personal projects and at work!

uv is the best

Quote

My conclusion is: if your situation allows it, always try uv first. Then fall back on something else if that doesn’t work out.

A year of uv: pros, cons, and should you migrate

While reading more about uv, I found these two articles:

Production-ready Python Docker Containers with uv (Hynek Schlawack)
A year of uv: pros, cons, and should you migrate (Bite code! | Substack)

What’s interesting, is that these both of these articles each link to older articles where they each extensively compared tools for Python dependency management.

Python Application Dependency Management (Hynek Schlawack)
Why not tell people to “simply” use pyenv, poetry, pipx or anaconda (Bite code! | Substack)

The articles reach similar conclusions, in that the existing tools can be useful but have limitations. However, both articles have been updated to have disclaimers at the top:

Quote

This article is really old.

If you want to see how I manage my dependencies since 2024, the short answer is uv, and the long answers are:

Spoiler: Everything got pretty good.

Python Application Dependency Management (Hynek Schlawack)

Quote

THIS ARTICLE HAS BEEN WRITTEN BEFORE UV EXISTED. UV SOLVES MOST OF THOSE PROBLEMS. YOU CAN TELL PEOPLE TO “SIMPLY” USE UV.

Why not tell people to “simply” use pyenv, poetry, pipx or anaconda (Bite code! | Substack)

As far as I am aware, the authors were not inspired by each other. They both tried to solve the problems of Python dependency management, found the previous tools lacking, and now love uv.

My Opinion

I have personally not compared every single Python dependency management tool, but do give weight to the opinion of those who have. In the past, I have heard about tools like virtualenv, pyenev, poetry and others, and decided to simply stick with pip and venv. However, after hearing increasingly good things about uv, I decided to try it myself. I have now used it for several projects, both work and personal projects. My conclusion: it’s good.

I don’t know if I will be using uv for every project. As good as uv is, I am still sometimes hesitant to add a new build dependency. I also had some concerns about the venture-backed nature of uv (which I addressed in when writing about the Business Model in Next Generation Tooling for Developers).

At the same time, uv works really well and is even fun to use, so I’ll probably trend towards using it more often than not. The fact that the tool is open source and strives to conform to Python PEP standards also makes me feel comfortable using it. For example, uv works with pyproject.toml. In theory, I could replace uv with another tool in the future but still use the same file. I looked at what it takes to use pyproject.toml on its own and found this article: Python packages with pyproject.toml and nothing else | Simon Willison’s TILs. This shows me that it’s possible to work this way without using a tool like uv, however using uv makes things much easier!

Featured image by Point Blanq on Unsplash.

Bitbucket versus the Competition

2025-09-30T00:00:00Z

TIL that Bitbucket is the slowest of the major software forges according to Software Forge Performance Index.

forgeperf.org is maintained by SourceHut, who are not impartial. SourceHut just so happen to lead most of the performance results. I can believe that the benchmarks are accurate, though the benchmarks may have been designed in a way that favors SourceHut.

Even so, performance is not everything. SourceHut’s UI is noticeably basic, which might be good for performance but not necessarily the most pleasent to use. SH patchsets are sent over email, an antiquated workflow (even if it’s still how Linux kernel development works).

The reasons I dislike Bitbucket have little to do with its subpar performance. Bitbucket, like most of Atlassian’s suite, just feels aggressively average. I wouldn’t go as far as to say Bitbucket is bad, it functions fine as a git forge. It does the basics decently well and many enterprises successfully use it. However, when compared to its main competitors, Bitbucket feels objectively worse. It kind of sucks.

The Competition

I would consider the main competitors to be GitHub and GitLab. Both of these have many more features than Bitbucket. Bitbucket is falling behind and playing catch-up, slowly implementing features that the competitors had years ago. Here are several examples.

Artifact Registry

There was a recent announcement of Bitbucket Packages. This will be Bitbucket’s own solution for an artifact registry, starting with a container registry. GitHub and GitLab already had artifact registry solutions for years, for example GitHub launched GitHub Package Registry in 2019 and GitHub Container Registry in 2021. Even when Bitbucket Packages does launch it will be limited to containers only at first. I also noticed that Bitbucket is missing a Releases feature, which both GitHub and GitLab have.

CI/CD

Atlassian has had several different CI/CD solutions over the years. Bamboo used to be the main one, and many companies used (or still use) a Bitbucket+Jenkins combo. Nowadays, Bitbucket Pipelines is the main solution that Atlassian tries to push onto its customers. One of these customers is my current client. I came into the client having to deal with the hacky Bitbucket pipelines that the previous team left me. We are using self-hosted Bitbucket Runners running on EC2 instances, because the hosted Bitbucket Runners are underpowered. Overall, I got the pipeline working, although the entire time I wished I was using GitHub Actions instead. To be fair, it’s clear Bitbucket Pipelines is being actively developed and is getting new features. However, it’s also clear that it’s playing catch-up against others CI/CD solutions (including GHA and GitLab CI/CD). There are all sorts of weird limitations, some of which have been fixed and others which still haven’t. For example, until recently, Bitbucket Pipeline steps were limited to only 2 hours. This has thankfully been fixed, and now the max-time can be set up to 720 (12 hours), enough to most (but not all) jobs. Other limitations continue to exist. GitHub has the Actions Marketplace full of community actions that can be easily integrated into GHA workflows, often completely for free (many actions are FOSS). Bitbucket works with the Atlassian Marketplace and Bitbucket Pipes integrations | Bitbucket, but this is much more limited and harder to use with Pipelines, and the majority of Apps are paid.

SSH commit signature verification

I was excited about SSH commit signature verification this feature when I learned about it during my bootcamp in late 2022. GitHub was quick to implement it and GitLab not long after. I then started working with clients that used Bitbucket and was surprised to find this feature missing! Only in 2025 did Bitbucket Cloud release SSH commit signature verification, more than two years after both GitHub and GitLab.

Bitbucket CLI

Bitbucket has no official CLI tool in the style of GitHub CLI or GitLab CLI. Of course, the standarad Git CLI does work well with Bitbucket, but the gh and glab CLI tools go beyond that and allow to do many actions directly using commands. Bitbucket does have REST APIs (The Bitbucket Data Center REST API and The Bitbucket Cloud REST API) which do work, but are harder to use than an equivalent CLI tool would be.

Cloud Development Environments

GitHub has Codespaces and GitLab has Workspaces. Both are Cloud Development Environments based on VS Code. Microsoft maintains both GitHub and VS Code. VS Code itself remains open source under the MIT license. GitLab maintains their own VS Code fork.

Bitbucket offers to use Cloud IDE add-ons Bitbucket Integrations, but doesn’t have anything built-in.

Automatic Dependency Updates

Dependabot is built into GitHub. GitLab uses Renovate GitLab Bot. Renovatebot can work with Bitbucket, either self-hosted or supported by Mend, however there is nothing built-in to Bitbucket.

Fragmented Hosting Solutions

A major point of confusion for me when using Bitbucket has been the the differences between Bitbucket Data Center and Bitbucket Cloud. While both look like Bitbucket, they are essentially two different products with different features and development cycles. Every time I look up Bitbucket documentation, I have to make sure that I am following docs for the right product. There are even two different Bitbucket REST APIs.

In comparison, GitLab operates under a single codebase for Community and Enterprise editions and the same codebase is used to run GitLab.com:

Quote

The largest known GitLab instance is on GitLab.com, which is deployed using our official GitLab Helm chart and the official Linux package.

GitLab architecture overview | GitLab Docs

Bitbucket Kills Self-Hosting

Bitbucket Server reached end of support in 2024. My clients at the time were already using Bitbucket Data Center so they weren’t affected. However, Bitbucket recently announced that Data Center will reach end of life in 2029. The solution going forward will be only Bitbucket Cloud. While this solves the fragmentation problem, it does so at the expanse of any self-hosted solutions. I believe there are still organizations for whom self-hosting is non-negotiable. Atlassian is essentially giving up on these customers. Perhaps they’ve done their cold calculations and decided that continuing to develop and support Bitbucket Data Center is no longer worth it even if they do lose some customers.

Meanwhile, GitLab continues to to offer a self-hosted solution, that can even run for free with GitLab Community Edition. GitHub offers GitHub Enterprise Server.

Featured image by Courtney Moore on Unsplash.

Agentic CLI Tools Comparison

2025-09-28T00:00:00Z

GitHub Copilot CLI is the latest Agentic CLI tool. Yet another Agentic CLI tool in the same style of Claude Code, Cursor CLI, Gemini CLI, Codex CLI and Qwen Code (and probably others that I am forgetting). So far I have tried all of these except for Qwen, and am now trying GitHub Copilot CLI as well.

All Agentic CLI tools look the same

All of these tools are superficially similar. Claude Code, GPT-5, Cursor CLI, Gemini CLI, Qwen Code and now GitHub Copilot CLI all have a TUI design that looks almost exactly the same, not even trying to hide that they’re copying each other. The notable exception is Codex CLI, which has its own TUI design. Honestly though I find Codex’s TUI to be inferior and kind of wish it also copied the others. I think the common design works well and don’t mind it, it’s just funny that all of these companies copy each other.

Another thing that is similar is that all these tools have npm as their primary installation option. While most tools can also be installed in other ways (such as Homebrew), npm is usually recommended first in their respective README files. Of course, npm has been widely-used for years and many developers already have it installed (these tools are primarily for developers, though they can do more than coding); however, I’ve personally never before seen npm recommended as the primary installation method before this wave of Agentic CLI tools started. Some of the tools are written in TypeScript so it makes sense. On the other hand, there’s Codex CLI, which has its own design and is written in Rust, but nevertheless adapted to work with npm (TIL Rust binaries can be distributed on npm).

Agentic CLI tools have differences

I mentioned these tools are superficially similar, however that doesn’t mean they all work the same. Outside of design and installation method, there’s the matter of functionality and how well these tools actually work. Differences include:

Model

Some tools are designed to work with one companie’s models. Claude Code of course uses Claude Sonnet and Claude Opus. OpenAI’s Codex CLI uses GPT-5 models (including GPT‑5-Codex). Gemini CLI uses Gemini 2.5 and 3 (Pro with a fallback to Fast). Other tools support a variety of different models through one service, for example Cursor CLI and GitHub Copilot CLI (the same is true for their non-CLI offerings). Others allow you to BYO (Bring Your Own) API keys (notably OpenCode).

Tools & Agentic Abilities

Even when two tools use the same AI model, that doesn’t necessarily mean they will work the same. These tools have agentic abilities, enhanced with tools and prompts. Tools can built-in or provided with MCP. As an example, Claude Code has a wide variety of built-in tools that allows it to read and write locals files, browse the web (Search and Fetch websites) and more. On the other hand, while Codex Is Improving, it still does not have as many built-in tools as Claude Code. When tools are missing or limited, the gap can be bridged either with other CLI programs (that these agentic tools know how to run directly) or MCP servers. Most if not all of these tools support both running CLI commands and interacting with MCP servers. Notably, Cursor CLI now supports MCP as well (when I first tried it, Cursor CLI was missing MCP support).

License

Not all of these tools are open source. In a way that is somewhat deceiving, several of these tools have a GitHub repo that is little more than a closed-source LICENSE and README, but does not actually include any code. At present, this even includes GitHub Copilot CLI, which is marked as Public Preview and has Pre-release License Terms (it is not clear to me what the license terms would be after release). Claude Code and Cursor CLI are also closed source (others may have copied CC’s design, but not its code). Gemini CLI is open source and was later forked to Qwen Code, which is also open source (both Apache-2.0). OpenCode is also open source (as its name implies), under MIT. charmbracelet/crush (from the same people who created some of my favorite Go CLI and TUI Frameworks) uses this weird license: Functional Source License, Version 1.1, MIT Future License.

Pricing & Usage Limits

These tools have different limits.

Claude Code

Out of all of these tools I have (so far) used Claude Code the most and am most fimilar with their pricing and usage limits. I am using Claude Pro on the $20 a month plan. Claude Code also has the crazy expensive Max plans ($100 or $200 a month). I have mentioned previously in my Claude Code notes about my experience using the Claude Code $20 plan. My experience honestly haven’t changed much. While there was some drama about Claude Code changing usage limits, I still rarely run into usage limits. When I do, I have to wait at most a few hours for the usage limits to reset. In that time I can either use other tools or take a break. Other than not having access to the Opus model on CC, I don’t feel like I’m missing anything by not being on Max and am still baffled at how people justify the price of those Max plans. ccusage implies I use more than $100 a month, significantly more than what I pay. Anthropic either operates at a loss or can somehow afford to do that since it’s their own models.

Gemini CLI

Gemini CLI has a generous free tier and is what I currently recommend for people wanting to try an agentic tool for free. I’m not sure whether my Google AI Pro trial increases my Gemini CLI usage limits or if it’s unrelated, I’m honestly kind of confused with Google’s various AI plans (in typical Google fashion).

Note

UPDATE: Google AI Pro and Ultra subscribers now get Gemini CLI and Gemini Code Assist with higher limits.

Codex

Included with paid ChatGPT plans including Plus, Pro and Team.

BYO (Bring Your Own) API keys

Ironically, the FOSS tools such as opencode and crush might actually be more expensive in this case. When using an API key you have to pay the “real” cost of running the AI model which can end up significantly more expensive than a set plan. The same is true when using Claude Code with an API key instead of a plan; in all but very moderate use a plan would make more sense. Even the expensive Max plans often end up cheaper than what equivalent API use would cost.

My Opinion

Claude Code remains my most used agentic CLI tool. Neverthelss, I am still actively experimenting with other tools, I have used Gemini CLI increasingly more in recent weeks (Gemini’s free tier is really good), and am also trying Codex due to its improvements. However, while these tools feel similar in many ways and the competition is closer than ever, I still feel that Claude Code with Claude Sonnet 4.5 is noticeably better than all other tools that I have used. This may change in the near future as all of these tools are actively developed and new ones are introduced all the time.

This is in addition to other AI tools which I am also actively using. Right now I am mainly using the web and app versions of ChatGPT, Gemini, Claude and Perplexity Pro (I also use Microsoft Copilot at work, but it’s not very good).

Featured image by Steve Johnson on Unsplash.

Docker User Interfaces

2025-09-17T00:00:00Z

There are different User Interfaces that help use Docker.

Web UI

Desktop UI

TUI (Terminal UI)

My Experiences

I first started using Docker with Podman CE in openmediavault. OMV-Extras.org used to have an easy install option for Docker + Portainer CE.

Note

I see OMV 7 no longer has Portainer CE and the current guide recommends using openmediavault-compose plugin instead. Of course, Portainer can still be installed manually.

Initially, I was using the Portainer Web UI to deploy containers manually, until I learned about Docker Compose and Portainer Stacks. I quickly noticed that defining all the services in one file was quicker and more reproducible than manually configuring containers in Portainer. I continued using Portainer Stacks as my main form of container deployment, eventually transferring all my existing containers to stacks. I noticed that compose stacks that are deployed outside Portainer can be viewed but not managed by the Portainer UI, so I defaulted to deploying all Stacks through Portainer.

I am aware that some people don’t like Portainer for various reasons. However, it has been rock-solid for me through the years that I’ve been using it. I’ve also never found the Community Edition of Portainer to be too limiting. There are a few minor things that I don’t like about it, but I still appreciated having a UI, and even experimented with some of Portainer’s more advanced features like Agents/Edge Agents (for management of multiple nodes) and GitOps. Eventually, I learned how to use the Docker CLI and docker compose commands well enough to the point that I don’t need the Web UI for anything, however I still like having a UI for my homelab.

Throughout the years, there have been many other Web UIs. I tried some of them including Yacht. Some of these UIs did not survive and got abandoned eventually (including Yacht). Portainer continued to be maintained. It’s likely the fact that Portainer is a company with paid solutions helped. Interestingly, I see Portainer much more in the homelab community than in the professional world, so I don’t know how much the company is really making. Nevertheless, Portainer looks like it’s here to stay and recently went through a rebrand (Why we rebranded Portainer).

More recently, I have heard about two newer Web UIs, Komodo and Dockge. Both look good, though part of me wonders whether they will last a long time like Portainer, or get abandoned eventually like Yacht.

On the Desktop UI front, I have avoided using Docker Desktop for many years. I felt like I had no need for it since I had Portainer CE working well as a Web UI, and also learned to use the Docker CLI commands. I was also concerend about the Docker Desktop license agreement. Unlike Docker CLI, Docker Desktop is not open-source.

I did briefly try Docker Desktop a few months ago before uninstalling it. It is useful on Windows, however I found that installing regular Docker inside WSL also works well.

I have also tried Podman Desktop. Unlike most of the tools in this note, Podman Desktop is not a Docker UI but instead a Podman UI. Nevertheless, Podman can run Docker containers thanks to the Open Container Initiative.

My Choice

I’m in the process of fully moving my homelab from Docker to a Kubernetes cluster. My Kubernetes UIs of choice are Argo CD (Web UI and GitOps), kubectl (CLI) and K9s (TUI), though there are many others as well which I may try.

I still want to try Komodo some day. I imagine, if I were to ever re-engineer my homelab, but choose to go back to Docker instead of Kubernetes, I would want to have a Web UI and some type of GitOps solution. Portainer and Komodo both have GitOps support. Dockge doesn’t which rules it out for me.

Featured image by Venti Views on Unsplash.

GPT-5

2025-08-16T00:00:00Z

This Week I Learned about GPT-5

At the announcement post, OpenAI made some bold claims about GPT-5. Including:

The best response, every time

KYAML

2025-08-11T00:00:00Z

Today I learned, in Kubernetes v1.34, kubectl will also support a new strict subset of YAML called KYAML.

Resources

Shell Script

I coded a simple script to convert all Kubernetes manifests in a directory from YAML to KYAML.

Initially, I wanted to code my own converter, but then found out that the upstream Kubernetes project already has a new yamlfmt tool (different from google/yamlfmt).

#!/bin/sh
# kyamlify.sh — Rename *.yaml -> *.kyaml then format to KYAML (POSIX)
# Usage: ./kyamlify.sh [ROOT_DIR]
# Env: YAMLFMT_VERSION (default: master)

set -eu

ROOT_DIR="${1:-kubernetes}"
YAMLFMT_VERSION="${YAMLFMT_VERSION:-master}"

# Require Go
command -v go >/dev/null 2>&1 || { echo "error: Go not found in PATH" >&2; exit 1; }

echo "→ Installing yamlfmt @ $YAMLFMT_VERSION"
go install "sigs.k8s.io/yaml/yamlfmt@${YAMLFMT_VERSION}"


echo "→ Formatting all YAML files under ${ROOT_DIR} as KYAML"
find "${ROOT_DIR}" -type f -name '*.yaml' -print0 \
  | xargs -0 -n1 "$(go env GOPATH)/bin/yamlfmt" -o kyaml -w

KYAML Rules

Quote

KEP-5295 introduces KYAML, which tries to address the most significant problems by:

Always double-quoting value strings
Leaving keys unquoted unless they are potentially ambiguous
Always using {} for mappings (associative arrays)
Always using [] for lists

Support for KYAML: a Kubernetes dialect of YAML | Kubernetes v1.34 Sneak Peek | Kubernetes

These rules are similar in practice to JSON5. However, while JSON5 is a superset of JSON (as well as a subset of ES5), KYAML is a subset of YAML.

In fact, I suspect that by adding --- to the first line of a JSON5 file, it would be valid KYAML.

By the way, starting the file with --- is required for KYAML (while it’s optional in YAML).

Experimentation and Additional Observations

I was initially excited about converting all my Kubernetes manifests to the “safer” KYAML format.
I ran my script then followed it by running yamllint, which introduced a few warnings post-conversion.
After fixing all yamllint warnings, I had well-formatted KYAML files.
I considered whether to rename all converted manifest files to use a *.kyaml suffix. I decided against this since I couldn’t find any evidence of this file extension.
KYAML files are 100% valid YAML files, and work with existing tooling. This includes existing Kubernetes versions and tooling.
The main thing introduced with Kubernetes v1.34 is a kubectl get -o kyaml option.
Keeping the *.yaml file extension makes sense since KYAML is still valid YAML and existing tools expect *.yaml or *.yml file extensions, not *.kyaml
After running the script, fixing formatting, and deciding to keep the filenames the same, I could add all modified files in homelab-as-code to a new kyaml branch and make a commit.
I considered opening a Pull Request, however, am still undecided.
My main consideration is whether the KYAML format would impact usability, making it harder for me to write and edit manifests.
I am not sure whether KYAML solves any real problems for me.
I understand YAML limitations but know how to avoid them by quoting values when needed, using linting and formatting tools (manually, with pre-commitand in CI).

My Opinion on the Format

In a way, KYAML is itself “yet another markup language” (despite using existing YAML rules). It is far from the first solution to problems with existing markup languages.

One notable limitation of standarad JSON is no comments. Both JSON5 and Microsoft’s JSONC (JSON with comments, primarily used in VS Code’s setttings.json file) previously addressed this. KYAML has the benefit of being a subset of YAML and designed to work with all existing YAML tooling.

In theory, KYAML could be a “safer” way to write production-grade manifests. However, this was already possible to do with JSON files. Kubernetes manifests can all be written in JSON, but there is a reason that this is rarely done in practice.

JSON files are arguably less readable and harder to work with (for humans, not machines) than YAML. At the same time, JSON files are very much machine-parsable with a lot of existing tooling like jq (though YAML tooling exists as well).

In imitating JSON but staying YAML, KYAML can feel like the worst of both, rather than the best of both world. Not as clean as JSON, and not as “human-readable” as YAML.

Featured image by Marvin Meyer on Unsplash.

OpenAI o3 Review

2025-05-28T00:00:00Z

I’ve used o3 extensively, and I think it’s a really strong model compared to earlier ChatGPT models.

It doesn’t just “think”; it also does web research and cross-checks sources to reach a conclusion. Other ChatGPT models can browse too, but o3 digs deeper and pulls more sources (when I read its “thoughts,” it said it tries to fetch at least 10 sources).

This is similar to what Deep Research does, which makes sense because ChatGPT’s DR used the o3 model even before it launched. However, DR returns essay-length answers (and is limited to 10 uses per month on ChatGPT Plus), which isn’t always practical. o3 gives answers closer in length to the other ChatGPT models. There are Plus usage limits, but I had to use it quite a lot before hitting them.

The model “thinks” for several minutes before responding. Usually it’s worth the wait, except for simple questions another model could answer faster. For complex questions, o3 is often noticeably better. I tried tough coding prompts that 4o struggled with (confident answers with hallucinations), then asked o3 and got much better results. For bigger tasks I sometimes had to tweak the prompt a few times, but in most cases o3 eventually delivered (unlike 4o).

The model isn’t perfect. There are still hallucinations and mistakes. Neverthless, in my experience fewer than other models I’ve tried.

AI moves so fast that it’s hard to keep up. Last month o3 was probably the best model around, and now people say Gemini 2.5 has overtaken it. It takes time to use a new model enough to really understand its strengths and weaknesses.

I also played a bit with ChatGPT 4.5 and 4.1. I haven’t used them much yet and so far I’m less impressed.

I haven’t tried o4 or o4-mini-high yet. Assuming o3 is better, I’d rather wait a few minutes for deeper reasoning. For simpler questions I still default to 4o.

Featured image by Levart_Photographer on Unsplash.

The Ultimate Guide to Kubernetes Books: From Beginner to Certified Expert

2024-06-26T00:00:00Z

While studying for the Certified Kubernetes Administrator certification last year, I wanted to take a deep dive into Kubernetes topics, both those covered by the certification and beyond.

As a develeap employee, I had access to all of develeap’s courses which I used to learn more about Kubernetes. Alongside that, I wanted to supplement my learning with books and practice labs. After I earned the CKA certification, I decided to review the field of Kubernetes books, labs, and courses. In part one of this article series I reviewed several of the CKA courses I took in Review of CKA Courses. In part two, I reviewed Kubernetes practice labs and mock exams in Review of Kubernetes Practice Labs. In this part (part three), I will review several of the books and written materials that I have read while learning about Kubernetes.

The Book of Kubernetes

Author: Alan Hohn

Publisher: No Starch Press

Publication Date: August 2022

Link: No Starch Press | Amazon | Penguin Random House | O’Reilly

The Book of Kubernetes (not to be confused with The Kubernetes Book by Nigel Poulton, which I have not read) is written by Alan Hohn and published by No Starch Press. I was already a fan of No Starch Press, having read many of their previous books, and this book was brand new when I first read it, so it was naturally my first choice when wanting to read more about Kubernetes.

This book serves as an introduction to Kubernetes. Although it assumes some sysadmin knowledge (and gets quite technical fairly fast), you don’t need to know anything about containers, as everything is explained—especially in the first part.

The book is split into 20 chapters across three parts. The first part, “Making and Using Containers,” serves as a fairly comprehensive overview of what containers actually are, as well as their benefits. In fact, I would go as far as to say this book might be the best explanation I’ve read about containers; too often I see simplified explanations about containers boiled down to “containers are like virtual machines but not really”. This book actually goes through the effort of explaining the technical underpinnings of containers, and how they use the fundamental capabilities of the Linux kernel, like namespaces and cgroups, to provide containers process isolation, resource limiting and network namespaces. This is first explained using Docker, the most used container tool, but later on the chapter shows how to achieve the same results using containerd as well as CRI-O and crictl. Showing how the same container image can be run through different container runtimes and tools, helped me understand the universal nature of OCI containers and the way Kubernetes can interface with containers through the CRI protocol.

The next two parts, “Containers in Kubernetes” and “Performant Kubernetes,” focus on many important Kubernetes topics. Along the book are examples which you can deploy yourself from the book’s GitHub repo. These are automated exercises that can be deployed using Ansible and run on either Vagrant (virtual machines) or AWS. These examples are very useful for hands-on understanding of the topics, and having them all automated while offering different ways to deploy – makes them very useful.

I will note that this book isn’t specifically designed to prepare readers for the Certified Kubernetes Administrator (CKA) exam. While it covers many relevant topics, there are some key CKA subjects not included, and conversely, some topics explored here might not directly align with the CKA curriculum (for example, Custom Resource Definitions). This, however, isn’t a drawback – the book excels in its own right, just keep this in mind if your primary goal is CKA certification.

Certified Kubernetes Administrator (CKA) Study Guide

Author: Benjamin Muschko

Publisher: O’Reilly Media, Inc.

Publication Date: June 2022

Link: O’Reilly | Amazon | eBooks.com

My one “complaint” about the No Starch book was that it was not a CKA study guide (it was not really a complaint, just an observation). Well, this book is! After No Starch Press, my other favorite publisher for technical books is O’Reilly, which has maintained a high standard for decades.

This book has everything you’d expect from a study guide. There are detailed explanations of everything you need to know in the CKA curriculum. There are useful tips for the exam and practice questions which are at a good level. For some of the practice questions you get automated Vagrant environments from the book’s GitHub repo, however for many questions you will have to set up a practice cluster yourself (or use Killercoda).

In some places the book mentions optionally using Kubernetes environments in Katacoda. This was a service offered by O’Reilly, unfortunately public use of Katacoda was recently shut down. This decision must have happened around the same time this book was published, but due to the unfortunate timing, Katacoda is still mentioned in this book. Fortunately this book does not really rely on using Katacoda to understand its material, it is merely offered as another option for practice. Now, Killercoda is available as a form of replacement for Katacoda (reviewed below).

Overall this book serves its purpose well as a written CKA study guide.

Learning CoreDNS

Author: John Belamaric, Cricket Liu

Publisher: O’Reilly Media, Inc.

Publication Date: September 2019

Link: O’Reilly | Amazon | eBooks.com

This book is, of course, about CoreDNS, the modern DNS server used for Kubernetes. Despite being about CoreDNS, it also focuses on Kubernetes networking and service discovery. It’s a good read for anyone who wants to understand Kubernetes networking on a deeper level. It’s more detailed than what is required to know for the CKA exam, but more knowledge is always good.

The book starts by explaining what CoreDNS is and why a new DNS for the container and micro-service was needed. It compares CoreDNS with BIND 9 (a more traditional DNS server), and explains the pros and cons of each. Spoiler: CoreDNS is not necessarily a replacement for BIND 9, they have different usages.

The book then dives deeper into how CoreDNS works with Kubernetes and etcd for service discovery, and delves into modern workflows and best practices (including Prometheus monitoring).

If you want to understand CoreDNS well, then there is probably no better book. For learning Kubernetes networking specifically for the CKA exam, this book is not the best option as it focuses on concepts that are not that important for the exam itself, while at the same time not delving too deeply into concepts which are important (such as Kubernetes Ingresses).

Kubernetes Documentation

Link: https://kubernetes.io/docs/

Of course, this is not a book but a website, one that everyone working with Kubernetes must be familiar with—and especially anyone taking one of the certification exams where this resource is allowed.

The Kubernetes Documentation has tons of relevant information; almost everything you would need to know for the CKA and CKAD exams is included in these docs. Of course, the documentation goes beyond what you need to know for the exams. If you want to become an expert on everything you can do with “stock” Kubernetes, you could read the entire documentation. Or you can focus on reading the sections that are most relevant to you.

Since I used other resources to study for the CKA certification, I did not read the documentation cover-to-cover.¹ I did, however, use the documentation frequently to reiterate the concepts that I learned, as well as during practice labs and mock exams. Whenever I needed to find out how to do something in Kubernetes, rather than searching Google, I searched through the Kubernetes Documentation first. For example, say I wanted to find a YAML template for deploying a PersistentVolumeClaim; I would go into the Kubernetes Docs and type “PVC” into the search bar, then click “ Configure a Pod to Use a PersistentVolume for Storage”, which explains PVCs and other relevant concepts.

I found this learning method to be very effective. When preparing for the CKA/CKAD exams, you should be adept at finding relevant information from the documents quickly and efficiently.² This is why I recommend using the documents as much as possible while studying. You don’t have to read everything in the documents, but you should be familiar with the content they include and how to find it using the built-in search. Configure a Pod to Use a PersistentVolume for Storage, I highly recommend exploring the Kubernetes Docs yourself and seeing what they offer. There are sections explaining common tasks, a One-page API Reference for Kubernetes v1.30, and even Tutorials.

Featured image by 🇸🇮 Janko Ferlič on Unsplash.

In fact the Kubernetes Docs can’t be read cover-to-cover because they are not a book and therefore lack a cover. ↩︎
The CKA exam has its own way of scoring things and is not public. You get a score sometime after completing the exam, but you won’t know which questions you answered correctly. ↩︎

Review of Kubernetes Practice Labs

2024-06-26T00:00:00Z

While studying for the Certified Kubernetes Administrator certification last year, I wanted to take a deep dive into Kubernetes topics, both those covered by the certification and beyond.

As a develeap employee, I had access to all of develeap’s courses which I used to learn more about Kubernetes. Alongside that, I wanted to supplement my learning with books and practice labs. After I earned the CKA certification, I decided to review the field of Kubernetes books and practice labs. In part one of this article series I reviewed several of the CKA courses I took in Review of CKA Courses. In this part (part two), I reviewed Kubernetes practice labs and mock exams. In part three, I share my take on written materials in The Ultimate Guide to Kubernetes Books: From Beginner to Certified Expert.

Killercoda

Link: Killercoda CKA Area

CKAD Equivalent: Killercoda CKAD Area

Killercoda offers free labs! Although Killercoda does offer subscriptions, the paid features which are currently included are not major. I’d say the main reason to consider a subscription is if you are using Killercoda frequently and want to support what they are doing. Honestly, what they are doing is excellent and worth supporting.

With a free account you can access various different environments and scenarios. The ones offered are very good and worth doing. I especially like the CKA Playground environment, designed to be similar to the current environment used by the CKA exam. You can use the Killecoda playgrounds to freely play around with Kubernetes, without being constrained to a specific scenario. This is really useful, for example if you just want to try out some commands to see what they do.

In addition, the environments load fast. This is impressive considering this is all available on the free tier.

Killer Shell

Link: Killer Shell CKA Simulator

CKAD Equivalent: Killer Shell CKAD Simulator

Killer Shell is created and maintained by the same team as Killercoda (led by Kim Wüstkamp), however they have notable differences. You can read their own comparison here; to summarize, while Killercoda allows you to practice exam topics, it is not an exam simulator.

Killer Shell is an exam simulator. In fact, it is the official exam simulator for the CKA, CKAD and CKS certifications (and soon the LFCT certification as well). Although using Killer Shell on its own is not free, you get two sessions included when signing up for any of these certifications.

Each session lasts 36 hours and includes an exam simulation that is designed to closely mirror the real exam environment. This means you get not only a terminal, but also a full XFCE desktop to work in. You get to work on 25 questions (plus a few extra questions) across several different Kubernetes clusters. You have a two-hour timer. However, after the two hours pass, you can continue to answer the questions at your own pace (up to the 36-hour time limit of the session).

To be honest, it’s very hard to answer all 25 questions within the two-hour limit… The questions in the Killer Shell exam are designed to be slightly harder than in the real exam. In addition, in the real exam, you are likely to get less than 25 questions to answer within the two-hour limit. My advice is not to focus too heavily on the time limit. However, do make sure you can answer all questions, even if it takes you longer than two hours. Nevertheless, you should be trying to find ways in which you can work fast and most efficiently; for example setting aliases and environment variables, and learning Vim shortcuts. These tricks will help you in the real exam, and the exam simulation is the best place to practice.

After the two-hour timer passes (which you can also end early), you get to see an automated scoring system that checks which questions you answered correctly. The exam, however, still continues in the background, and you can go back to questions and fix your answers. I noticed the automated scoring system sometimes takes a few minutes to update, which led to some confusing situations where I tried to fix an answer but had to wait a few minutes to confirm I answered correctly. Another nitpick is the automated scoring system is a bit overly strict in the way it likes its answers. For example, in one of the early questions, you have to write a shell script to do a simple task; this can be done in several ways, but in practice, the script has to be written in the exact way that the automated scoring system expects (you can’t even use a shebang, as a friend of mine found out while trying out Killer Shell). I don’t know if the real exam is as strict with its scoring as Killer Shell.

In the real CKA exam you don’t get to see which questions you answered correctly, that’s why you should practice checking your own answers. After answering questions, you should verify that you did things correctly using different commands. Again this is something which of course can be practiced within the Killer Shell environment.

As I mentioned, you get two Killer Shell sessions after signing up for a certification. It’s worth noting that both sessions will have the same questions. In my case I found that one session was sufficient for preparing for the real exam. However if you didn’t do well in the first session, then that’s a good sign you should go back to practice and learn the concepts that you struggled with. Once you are able to get a good score at Killer Shell, you will know you are ready for the exam.

As for when to take the Killer Shell exam, it is often recommended to take it relatively close to the real exam (say within one week), after you have thoroughly learned using other resources. If you are already experienced in using Kubernetes and wondering if you need to spend time on courses, you could test yourself by doing a Killer Shell simulation session first and see how well you do.

Review of CKA Courses

2024-06-26T00:00:00Z

While studying for the Certified Kubernetes Administrator certification last year, I wanted to take a deep dive into Kubernetes topics, both those covered by the certification and beyond.

As a develeap employee, I had access to all of develeap’s courses which I used to learn more about Kubernetes. Alongside that, I wanted to supplement my learning with books and practice labs. After I earned the CKA certification, I decided to review the field of Kubernetes books and practice labs. In part one of this article series (this article), I review several of the CKA courses I took. In part two, I review Kubernetes practice labs and mock exams in Review of Kubernetes Practice Labs. In part three, I share my take on written materials in The Ultimate Guide to Kubernetes Books: From Beginner to Certified Expert.

KodeKloud

KodeKloud courses are available on their own site and some are also on Udemy. Some courses and labs are only available through a KodeKloud subscription.

Certified Kubernetes Administrator (CKA) with Practice Tests

Link: KodeKloud | Udemy

The gold standard in Kubernetes courses. This course by KodeKloud Training and Mumshad Mannambeth covers everything one needs to know for the CKA exam. The explanations are clear, there are high quality slides and animations for every topic and the topics themselves are well organized. Every section has accompanying practice labs on KodeKloud (the labs are included even if you sign up through Udemy). Each lab runs for one hour but you can repeat every lab as many times as you’d like.

The course includes 22 hours of videos and in addition to the videos you can expect to spend at least that long on the practice labs. I highly recommend doing all the labs even if you don’t watch all of the videos. After every lab there is a solution video where Mumshad shows how to solve all the practice questions; these solution videos are marked as optional, you may choose to skip them when you have solved all the questions yourself; however I found that these solution videos often feature additional tips and tricks or ways to solve the problems that are possibly faster than what I did. Learning through a combination of watching videos and reinforcing the concepts through practice labs leads to very good understanding of the topics in my experience.

Some people wonder if this course alone includes all the content that you need to know for the CKA exam. In my opinion, it certainly does; this course is very thorough and combined with the practice labs it prepares you very well. In a few sections, such as Networking, the course even goes more in-depth than is needed for the CKA exam (as knowing core networking concepts is always useful). Having said that I don’t recommend skipping any sections that are not marked as optional (”Kubernetes The Hard Way” is an optional part of this course which I will cover below).

In addition, the course and labs are constantly updated to keep up with changes to Kubernetes and the CKA exam. For the rest of this paragraph I will go on a slight technical tangent; The one part I felt was missing from this course were additional explanations of container runtimes and the removal of dockershim. Kubernetes v1.24 removed dockershim support. This change is therefore relevant to the CKA exam starting from 2023 when the exam environment moved to Kubernetes v1.26. There is some confusion regarding all this and I think a video explaining this change would’ve been helpful (hopefully it gets added in the future). As of now, the course videos don’t reflect this change, however the practice labs actually do. In some of the practice labs the solution videos show Mumshad using the docker CLI, however the actual practice labs have been updated to use the crictl tool instead. Hopefully the course videos get fully updated to reflect these changes.

Overall I highly recommend this course. If you follow only one course from this list, make sure it is this one. In addition, this course also includes mock exams which I review below (in the “Labs” section).

Kubernetes for the Absolute Beginners - Hands-on

Link: KodeKloud | Udemy | O’Reilly

This course by KodeKloud Training and Mumshad Mannambeth is similar to their CKA course, however the difference is it’s designed for “Absolute Beginners” (whereas their CKA course already expects a little bit of familiarity with Kubernetes). If you have no previous experience with Kubernetes, or haven’t worked with it in a while and need a refresher, I recommend taking this Beginners course first before moving on to KodeKloud’s CKA or CKAD courses. However, despite the “Absolute Beginners” title of this course, I would still recommend having some knowledge of Docker/Podman and the Linux command line before moving on to this course (I cover some resources for learning those topics below).

The course includes 6 hours of videos and in addition to the videos you can expect to spend at least that long on the practice labs. I will note that many of the topics in this course are also covered in the KodeKloud CKA/CKAD courses, mainly everything related to the core Kubernetes concepts like Pods, ReplicaSets, Deployments and Services. There are however some additional coding exercises though for each of these topics. If you choose to do this course first you can later skip these topics when moving on to the later courses. Despite the repetition, I do think this course offers enough additional content to be worth it in its own right (although in terms of value, it is significantly shorter than the KodeKloud CKA/CKAD courses). I think its introduction to Kubernetes is very good, and in the later parts of the course you get to deploy a relatively complex Microservice Architecture across the three major cloud providers and their respective managed Kubernetes services - GCP (GKE), AWS (EKS) and Azure (AKS).

Courses - Honorable Mentions

TechWorld with Nana

Link: Website | YouTube Channel

Anyone learning DevOps has probably come across Nana’s insightful videos on YouTube.

Nana has many videos on her YouTube channel about Kubernetes which are offered for free! Then on her website she offers full courses. The price difference is stark though, especially compared to the wealth of free content she has on her YouTube channel. Her courses are quite pricey compared to other options. I can’t make a judgement about their value though since I have not tried her paid courses. So instead I will focus on the value offered by Nana’s free YouTube videos.

The TechWorld with Nana YouTube channel has videos on many topics. Kubernetes is certainly one of the prominent topics in her channel, including both short and long videos on this subject. Her videos are great for learning the basics. Her free videos won’t teach you everything you need to know for the CKA or CKAD certifications, but they will give you a good baseline.

Personally I used KodeKloud’s courses for the majority of my learning. However when I wanted to reinforce certain concepts, I often watched Nana’s videos on them to hear them explained in a different way. This was very helpful. Nana explains complex concepts in a very clear way.

Kubernetes Fundamentals (LFS258)

Link: Linux Foundation - Training

This is the Kubernetes course that is recommended in the “official” learning path by the Linux Foundation. Although it is not a cheap course, it can be bundled together with a purchase of a CKA exam voucher, which can make it affordable when bought during one of their frequent sales (such as Cyber Monday).

The course videos cover all the relevant Kubernetes topics. In terms of labs, you don’t get practice labs like with KodeKloud, instead you are provided instructions for setting up a Kubernetes environment either locally or using a cloud provider (AWS or GCP). Using a cloud provider for all the labs could potentially get expensive though.

Each section starts with videos, continues with lab exercises and ends with a Knowledge Check. The lab exercises have to be run on your own cluster. The Knowledge Check is an interactive quiz testing your knowledge.

Overall this course isn’t bad but I personally think it’s hard to recommend it when comparing it to KodeKloud… Especially for its full price (which is more expensive than KodeKloud’s courses). If you can get in a bundle during a sale then it might be worth it for you, just remember that you will still have to set up your own cluster.

Certified Kubernetes Administrator CKA Video Course by Sander van Vugt

Link: sandervanvugt.com

I have not tried this course personally, however my coworker Lior Dux highly recommends it.

Amazon Linux 2023 review

2023-03-20T00:00:00Z

It’s finally here! Amazon Linux 2023. Originally named Amazon Linux 2022, then silently renamed to Amazon Linux 2023 after a delay… Was it worth the wait?

Amazon Linux bird logo

I decided to take a look at Amazon’s new Linux distribution. I will cover eight key areas that I personally believe are important to consider when choosing a Linux distro for server workloads in the cloud.

1. Upgrade path

Amazon Linux 2023 can be considered the successor to Amazon Linux 2.¹ Therefore, you might think you’ll be able to run some commands in order to upgrade your AL2 instances to AL2023, but this is not the case. AL2023 is a major new version and has many breaking changes (as you can tell by the fact that it’s 2,021 versions higher than AL2). For all intents and purposes, I think it’s safe to consider AL2023 an entirely different Linux distro than AL2. I will explain more about the differences below. However, it is important to note that you should not expect any of your existing AL2 workloads to necessarily work in AL2023, unless you have thoroughly tested them.

This might seem disappointing compared to other Linux distros which do offer in-place upgrades (for example Ubuntu and RHEL). However this is not new for Amazon Linux; there was no upgrade path between the original Amazon Linux to Amazon Linux 2 either. If I had to guess the reasoning for this, aside from technical challenges, is that Amazon wants to implicitly encourage us to treat instances as cattle, not pets. That is, we shouldn’t get so attached to a particular instance that we feel we have to upgrade it in-place. Instead, we should be comfortable terminating any one instance and spinning up a new one in its place.

However even if you deploy AL2023 in a new instance, you still have to be aware of its changes and how they might impact your workflows. For example if you have a User data script that automatically runs every time your AL2 instances launch, you will have to test it on AL2023 to ensure it achieves the same results as you expect.

It will be interesting to see if Amazon will have an upgrade path in the future from Amazon Linux 2023 to Amazon Linux 2025. As far as I am aware they have not announced anything in this matter, so I won’t expect it unless Amazon says otherwise.

2. Availability

Amazon Linux 2023 is now generally available in all AWS Regions. This means you can deploy EC2 instances running this new Linux distro by choosing the right AMI (Amazon Machine Image). This can be done from the AWS EC2 Management Console, where it’s possible AL2023 will already appear as the default Quick Start AMI option for you. If it does not appear by default, search for “Amazon Linux 2023” and ensure you choose an option from a “Verified provider”. If using a tool like AWS CLI or Terraform, you can copy the AMI ID yourself (just remember that AMI IDs differ by AWS region); see how to find a Linux AMI in the AWS EC2 documentation.

A view of the AWS EC2 Console showing how to deploy Amazon Linux 2023

3. Cost

Amazon Linux 2023 is free by both definitions of the word. It is open source, and also does not incur any additional costs to use.

Of course you will still need to pay any relevant fees for using EC2, for example payment for on-demand Linux pricing and EBS volumes. However you don’t need to pay any additional pricing for licensing like you do for some operating systems in AWS (e.g. RHEL, SUSE or Windows). In addition, AL2023 is “Free tier eligible” — meaning you can try it for free as long as your usage is within the AWS Free Tier.

An example of EC2 instance pricing. Amazon Linux 2023 falls under “On-Demand Linux pricing” which is cheaper than RHEL, SUSE and Windows pricing. Prices are in “us-east-1” region as of 2022–03–20.

4. Kernel

Now that I knew that AL2023 is available and understood its costs, I was ready to test it myself. I deployed a micro EC2 instance for testing and started running commands to see what I can find. The first command I ran was uname -a to see the Linux kernel version that is currently included with AL2023. Running that command shows that the current AL2023 Linux kernel version is 6.1.15-28.43.amzn2023.

I was pleasantly surprised to find out that AL2023 runs Linux kernel version 6.1, the latest LTS Linux kernel. This is a big jump compared to AL2 which uses Linux kernel version 5.10. Originally AL2 used kernel version 4.14, but later received updates to 5.4 and 5.10 kernel versions. However AL2 was never updated to Linux kernel 5.15, the previous LTS kernel version.

Amazon Linux 2023 is expected to receive kernel updates as well, at least for the 6.1.x kernel series (and maybe for future LTS kernels too). Kernel live patching is supported, meaning you will be able to install kernel updates without rebooting.

5. OS Family

Obviously Amazon Linux 2023 is “Linux”, and we know that its kernel is 6.1, but which Linux distribution is it based on exactly? The Linux distribution family tree is big and complex, but to simplify things a bit, we can consider the two main branches of Linux distributions to be Debian-based distros and RPM-based distros. These two distro branches are dominant both in the Linux desktop space but especially when it comes to server distros.² Debian-based distros include Ubuntu, RPM-based distros include RHEL, CentOS Stream, Fedora and SUSE.

All Amazon Linux distros are RPM-based. AL2 for example was partially based on CentOS 7. However, AL2023 is instead based on components of Fedora 34/35/36 with some aspects of CentOS 9 Stream. However Amazon clarifies that AL2023 isn’t directly comparable to any specific Fedora release. This means you can’t expect it to behave the same way as Fedora or CentOS Stream. You should treat it as its own distro with its own packages.

5. Package availability

AL2023 uses the DNF package manager, which is the successor to YUM (previously used in AL2). Although yum commands are still available, they now point to dnf instead.

In terms of package availability, AL2023 does not use the Fedora or CentOS Stream repos, instead, AL2023 has dedicated repos of its own. The packages are similar but not identical to what were offered in AL2. Most packages have been updated to the latest versions. When upgrading to AL2023 from AL2, you should ensure that all the packages you need are still available. In addition you should ensure that the version updates don’t have breaking changes that affect you. For example, Python 2.7 is no longer available in AL2023, unlike AL2 which still has extended support for Python 2.7.

In terms of packages outside of the AL2023 repo, support seems limited. AL2023 does not support EPEL repos, nor does it support amazon-linux-extras. Although some packages from amazon-linux-extras are now included in the main AL2023 repos (including docker and nginx), not all of them are; for example, I noticed Ansible is missing (although it can still be installed through pip).

Compared to Fedora repos, there are many packages that are missing from AL2023 repos. I already mentioned Ansible, but to give another example — Podman is missing. This is interesting given how much focus RedHat has put on Podman in recent years (in order to “compete” with Docker). In recent versions of Fedora, Podman is even installed by default. Yet it’s nowhere to be seen in AL2023 which is partially based on Fedora. However, you do get Docker and containerd in the AL2023 repos.

Over on the Amazon Linux 2023 GitHub repo anyone can open issues asking to add missing packages. I hope that the Amazon Linux team will be quick to add highly-requested packages. This is because I am not really sure what the alternative is for users; AL2023 users can’t safely add Fedora, CentOS Stream or EPEL repos because AL2023 is not directly compatible with any of these distributions. I guess maybe we should just run everything in containers? I am not opposed to that idea personally for some packages, but then we should at least get packages like podman and ansible.

Another thing to know about the AL2023 repos, is that they use Deterministic upgrades through versioned repository.

6. Release Cadence and Long Term Support

Starting with Amazon Linux 2023, Amazon plans to release a new major version every two years. Two years from now we can expect to see Amazon Linux 2025, then Amazon Linux 2027 and 2029. Each version should receive Long Term Support (LTS) for five years.

If this kind of release cadence sounds familiar to you, then it is definitely not because of previous versions of Amazon Linux. Historically, Amazon Linux version releases have been quite inconsistent, with Amazon Linux 2023 itself being delayed and renamed to Amazon Linux 2022. Instead, this release cadence seems to be inspired by Ubuntu, which releases major LTS versions every two years in April. Regardless of what you think about Ubuntu and Canonical, you can’t fault them for not being consistent. Since Ubuntu 8.04 LTS in 2008, Canonical has consistently released LTS versions every two years, without ever missing the April release date. This is on top of their standard Ubuntu releases which we get every six months. Every Ubuntu LTS release since 12.04 LTS has received at least five years of support. Ubuntu’s consistent release cadence and Long Term Support has been one of the reasons it became a leading Linux distro, both in the desktop space and for server use. When it comes to AWS, Ubuntu competes closely with Amazon Linux.

It will take years to see if Amazon can live up to its promises of consistent Amazon Linux releases. Will Amazon Linux 2025 release on time two years from now, or will it get delayed again and renamed to Amazon Linux 2026? We will have to wait and see. In the meantime, Amazon also promises quarterly minor updates for Amazon Linux 2023.

7. Performance

Amazon claims that AL2023 offers “optimized performance for Amazon Elastic Compute Cloud (EC2) Graviton-based” and “AL2023 optimizes boot time to reduce the time from instance launch to running the customer workload”. Of course optimized performance is always helpful, especially when it comes to EC2 instances which you want to be able to launch fast when needed. At the scale that AWS operates, “optimized performance” can lead to significant gains.

So does AL2023’s performance live up to its promises? According to Michael Larabel over on Phoronix, the answer is yes! See his detailed benchmarks: Amazon Linux 2023 Is Running Well, Boosting EC2 Performance Over Amazon Linux 2

Larabel’s benchmarks were done on a powerful Graviton3 c7g.metal instance. However AL2023 is capable of running even on the weakest EC2 instance types. A minimal AL2023 AMI is also available.

8. Security

According to Amazon, “AL2023 takes a security-by-default approach to help improve your security posture with preconfigured security policies, SELinux in permissive mode and IMDSv2 enabled by default, and the availability of kernel live patching”.

Updates and security updates for supported packages are provided by Amazon, however because of the new Deterministic upgrades through versioned repository system, updates need to be applied differently than how you might expect (see here).

When running Amazon Linux 2023, it is critical to remember the principles of the shared responsibility model.

AWS Shared Responsibility Model

Conclusion

Amazon Linux 2023 is an exciting new release. There are many things to like about it including the new Fedora base, updated packages, improved performance and security. However because of the many breaking changes it is not an easy upgrade to recommend for existing Amazon Linux 2 users. The limited package availability also makes it not suitable for some workloads, which might still be better served by other popular AMIs (such as Ubuntu).

Even though it won’t win everyone over, Amazon Linux 2023 is still an excellent new release and a significant improvement over Amazon Linux 2.

Note that Amazon Linux 2 is still supported until 2025–06–30. ↩︎
Yes I know some people run their servers on Arch. Even if that’s arguably not the best idea… ↩︎

Tower of Kubes

OpenCode: The Agentic Tool That Anthropic and Google Don't Want You To Use

Background

The Crackdown

The Community Reaction

My Impressions of OpenCode

Models and Providers

Agentic Tool Usage

It’s Dangerous: Permissions and Safety

Final Verdict: Is OpenCode Better Than Claude Code?

TrueNAS Removes SMART Scheduling

What Are SMART Tests?

What Exactly Did TrueNAS Remove?

How Did the TrueNAS Community Respond?

Will I Keep Using TrueNAS?

Claude Code Sandboxing

Ways to Sandbox Claude Code

New Configuration Languages - MAML and TOON

Cloudflare Workers

Introduction

Cloudflare Workers vs Cloudflare Pages

Pricing

Why use Cloudflare Workers?

Compared to GitHub Pages

Compared to self-hosting

Documentation

Can I use Cloudflare Workers for my projects?

Chrome DevTools MCP server

The comment that prompted me to try Chrome DevTools MCP

Guide: Using Chrome DevTools MCP

Claude Code

Codex CLI

Gemini CLI

Other MCP clients

Home Assistant on Kubernetes

My Opinion

Why standalone device for Home Assistant

Why Home Assistant OS

Benefits of the Home Assistant Helm Chart

Grebedoc

Origin Story

Can I use Grebedoc for my personal projects?

Resources

Pre-commit hooks for Node.js projects

What is a Git pre-commit hook?

Pre-commit tools

Guide: Husky + Lint-staged + Oxc workflow

Oxc Workflow

Oxc

Why Oxc instead of ESLint + Prettier?

Guide

One-time run

Install Oxc tools in NPM project

Initialize configuration for oxlint

Initialize configuration for oxfmt

MCP Security

MCP Horror Stories

First Malicious MCP in the Wild

Are MCP Security risks real or overblown?

MCP Defense

What I Do

Supply-Chain Security

MCP Server Configuration

Ignore files

Documentation on excluding/ignoring files

Tour de Sonol Around Kinneret 2025

Links

Official video

Official poster

Istio Gateway

Istio as a Gateway and Ingress Controller

My Rationale for using Istio

My Installation

Istio Gateway Installation

Benchmarks

Lima and Colima

Lima

Colima

Differences between Lima and Colima

Installation

1. Confirm `docker` is installed and check versions

2. Confirm the `docker buildx` and `docker compose` plugins are also installed (likely already installed alongside `docker`)

4. Run the following commands to set initial settings for `.gitconfig`

3. Copy your existing `.gitconfig` file from Windows

`cdk synth`