What’s the down side? The down side can be that it’s not easy to operate Bazzite with out pulling down packages and making layers on top of your imutable OS, but it’s far from impossible.

Enter distrobox (pun intended). Why not toolbox ? toolboxhas become very complex, and it still lacks features that distrobox rocks. distrobox on the other hand is dirt simple (everything is relative) shell scripts that does it’s magic and never complains. No, really. distrobox is very clever and, although I, like some many else, has a devcrush on golang, the distrobox devs made the right choice.

A typical distrobox file might look something like this:

[fedora41] # also inline comments are supported
additional_packages="zsh fzf neovim golang cargo glib2-devel pango-devel cairo-gobject-devel
atk-devel javascriptcoregtk4.1-devel libsoup3-devel gtk3-devel webkit2gtk4.1-devel 
python3-pip pciutils tmux neomutt curl isync msmtp pass ca-certificates 
gettext lynx abook chronie qutebrowser"
image=registry.fedoraproject.org/fedora-toolbox:latest
home=/home/<user>/distroboxhome/
init=false
start_now=false
nvidia=true
pull=true
root=false
replace=false

The really big difference, for me, is the ease of which you can switch to a custom $HOME with distrobox.

$ distrobox assemble create --file distrobox.ini 
$ distrobox enter fedora41

That’s it. Now you have created and entered into a distrobox container (podman) in which you have installed all the additional_packages listed in the .ini file. Smooth AF.

So what’s the problem? The problem is that I have a mail client system consisting of neomutt configured with mutt-wizard relying on mbsync and notmuch. It’s a marginal problem, but for me it is a problem because I’ve decided that I will live my life inside a distrobox and never install anything that is not already present in Bazzite proper.

This in turn leads to https://github.com/roderik333/syncmail

..and I’ll try to explain why.

I can’t just install a initsystem in my distrobox

$ distrobox create --help
.
.
-- init/I       use init system (like systemd) inside the container.
                this will make hosts processes not visible from within the container.
.
.

And as explained in the README.md of syncmail running .timer on the systemd of Bazzite proper didn’t work very well.

HOWEVER! I still might do this if I manage to reform my workflow.. because I could run my mail in a separate distrobox that has a init system, and the rest of everything in a different distrobox.

I think I would then need a multiplexer in Bazzite terminal and a separate multiplexer for each distrobox which I fear might become a tad confusing.

Ghostty might also be an alternative. Haven’t tried it but it’s meant to send tmux and zellij in oblivion. But I can not use rpm-ostree to just install Ghosttty that would defat the whole purpose of this .. kinda moronic endeavour, anyways. Bazzite supports appimages out of the box. So there’s that.

‘till next time

Not too many mentions of podman, so here goes.

$ podman create -p 127.0.0.1:3000:8080 --network=pasta:-T,11434 \
--add-host=localhost:127.0.0.1 \
--env 'OLLAMA_BASE_URL=http://localhost:11434' \
--env 'ANONYMIZED_TELEMETRY=False' \
-v open-webui:/app/backend/data \
--label io.containers.autoupdate=registry \
--name open-webui ghcr.io/open-webui/open-webui:main

This will allow you to access Open WebUI on http://localhost:3000.

Remember to pull the image ghcr.io/open-webui/open-webui

‘till next time.

This was performed on a lenovo P14s 5Gen AMD 8840HS with 32GB memory running Fedora Workstation 41

Let’s start with the obvious stuff. The latest GPU firmware must be installed and the latest version of ollama must also be installed. As of this writing it is ollama 0.4.6

Then you may, or you may not, want to up the dedicated amount of “VRAM” your (A)GPU is allowed to use. My, albeit limited, experience is that leaving it at AUTOMATIC will send 50% of the processing to the CPU and 50% to the (A)GPU when working with models around ~4GB in size. Performance wise this isn’t too bad on my system, however setting BIOS to allocate 8GB will allow for ~8GB models to use the (A)GPU only..(and then also smaller models naturally).. which is faster, but wastes memory in most scenarios. I also noticed some instabilities with 8GB VRAM allocated, but I did not care to investigate it further.

I haven’t tried larger models with command line ollama.. i did try 14GB models using LM Studio. It worked, but it crashed my gnome session after a while and besides, I don’t think I like the LM Studios terms so I removed it from my system.

If you have followed along this far you’ve realized that “that guy is full of s**t.. this doesn’t work!” and you’d be right. I have not come to the most important part yet.

If you do -

$ journalctl -fu ollama --no-pager

you will see loglines indicating that ollama does not know about your (A)GPU.. even though ollama clearly stated that it was present when you installed ollama. So we need to remedy that.

I guess there are multiple ways to perform this next step, but I chose the path of least resistance.

$ sudo vim /etc/systemd/system/ollama.service
# insert the following in to the [Service] section. Yes, there is already
# a variable named Environment, we will add one more.
Environment="HSA_OVERRIDE_GFX_VERSION=11.0.2"

# save the file and exit
$ sudo systemctl daemon-reload
$ sudo systectl restart ollama.service

Finding the correct HSA_OVERRIDE_GFX_VERSION" was pain in the proverbial butt! The only place I’ve found it specified is here https://discuss.linuxcontainers.org/t/rocm-and-pytorch-on-amd-apu-or-gpu-ai/19743

I’ll admit that my google foo is not as strong as it once was, but I blame google and not my self (I had to give up on duckduck.. )

• for GCN 5th gen based GPUs and APUs HSA_OVERRIDE_GFX_VERSION=9.0.0

• for RDNA 1 based GPUs and APUs HSA_OVERRIDE_GFX_VERSION=10.1.0

• for RDNA 2 based GPUs and APUs HSA_OVERRIDE_GFX_VERSION=10.3.0

• for RDNA 3 based GPUs and APUs HSA_OVERRIDE_GFX_VERSION=11.0.0

I mucked about with 10.3.0, which was the only reference I found to GFX_VERSION, for several hours until I stumbled upon this guy: qkiel So, thank you qkiel, you saved my sanity.

So, there’s that.

I leave you with this

zsh> ollama run llama3.2
>>> Why should I blog about llama?
Blogging about llamas can be a unique and fascinating niche. Here are some reasons why you might consider starting a blog about llamas:

1. **Growing interest in alternative pets**: Llamas have become increasingly popular as exotic pets, and people are willing to learn more 
about their care, behavior, and needs.
2. **Unique perspective**: By focusing on llamas, you can offer a fresh and distinct voice in the world of pet blogging or wildlife writing.
3. **Educational value**: Llamas are intelligent, social animals that require specific care and attention. A blog about llamas can provide 
valuable information for potential owners, breeders, or anyone interested in these amazing creatures.
4. **Community building**: You can connect with a like-minded community of llama enthusiasts, share experiences, and build relationships 
with people who share your passion for these animals.
5. **Creative expression**: Writing about llamas can be a creative outlet, allowing you to express yourself through storytelling, poetry, or 
other forms of writing.
6. **Monetization opportunities**: If you have a large and engaged audience, you may be able to monetize your blog through advertising, 
affiliate marketing, or sponsored content related to llama-related products or services.
7. **Personal growth**: Learning about llamas can be a fun and rewarding experience that helps you develop new skills, such as animal care, 
research, or writing.

Some potential blog post ideas to get you started:

* "10 Fun Facts About Llamas You Never Knew"
* "A Beginner's Guide to Keeping Llamas as Pets"
* "The Benefits of Llama Therapy and How It Can Help People"
* "Llama Behavior: Understanding Their Body Language and Social Structure"
* "Llama Care and Nutrition: What You Need to Know"

Remember, starting a blog is just the first step. To make it successful, focus on creating high-quality content, engaging with your 
audience, and continuously learning about llamas to share your knowledge with others.

‘till next time.

At first I thought .. I don’t know what I thought really… anyways, the screen flickered at random intervals and rather infrequently too.

A quick search found a solution that works for me with my current configuration

$ uname -a 
Linux toblakai 6.11.8-300.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Nov 14 20:37:39 UTC 2024 x86_64 GNU/Linux

$ lspci -n -n -k | grep -A 2 -e VGA -e 3
.
.
c4:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix3 [1002:1900] (rev d2)                                    
        Subsystem: Lenovo Device [17aa:50ef]                                                                                                      
        Kernel driver in use: amdgpu

The flickering might or might not have started after I ran fwupdmgr update which updated the Phoenix firmware..

.. in either case, it seems to have been solved by editing /etc/default/grub adding amdgpu.dcdebugmask=0x10 to the end of the GRUB_CMDLINE_LINUX line and then

$ grub2-mkconfig -o /boot/grub2/grub.cfg
$ reboot

As mentioned, this works for me. Supposedly it will hurt the battery life of the machine, but not by much.. and there are several reports of people that wasn’t helped by this fix .. so your mileage may vary.

‘till next time.

Pandas function, .to_sql, which in combination with SQLAlchemy is really really cool. I had use for something that worked with django, so I whipped up this contraption. No, it’s no where near .to_sql, but it does the job. For me. In this instance.

import pandas as pd
import numpy as np
from django.db import models

def dataframe_to_django(
    df: Series | Any,
    model: type[models.Model],
    dbmapping: dict[str, str | None],
    convmapping: dict[str, Any],
    replace: bool = False,
) -> None:
    """Uses bulk_create to insert data in table.

    KeywordArguments:
      df           --  the dataframe.
      model        --  the django table in to which the dataframe should be inserted.
      dbmapping    --  mapping from dataframe name to db name. Typically {"ProductName": "product_name", "SkuDescription": None, ...}
      convmapping  --  converters for spesific fields. Typically, {"StartDate": pd.to_datetime, ...} .
      replace      --  bool False|True. If set to True it will wipe the table before import.
    """

    if replace:
        model.objects.all().delete()

    df.replace([np.nan], ["N/A"], inplace=True)
    for key in convmapping:
        df[key] = convmapping[key](df[key])

    model_list: list[models.Model] = [
        model(**{dbmapping[k]: v for k, v in x.items() if dbmapping[k] is not None}) for x in df.to_dict("records")
    ]
    model.objects.bulk_create(model_list)

The link to the gist is https://gist.github.com/roderik333/0343f54af1e27dcbd50affb19919ac11

until next time..

I needed to replace the sqlite3 database I was working with. sqlite3 is amazing, but has it's limits.

Naturally I turned to postgres:16

$ podman pod create --name postgre-sql -p 9876:80

This creates a pod with an opening for pgadmin on port 9876

$ podman run --pod postgre-sql -e 'PGADMIN_DEFAULT_EMAIL=syouradmin@yourdomain.com' -e 'PGADMIN_DEFAULT_PASSWORD=passWoRd' --name pgadmin -d docker.io/dpage/pgadmin4:latest

This creates a container with pgadmin running in the postgre-sql pod.

Now, create a volume

$ podman volume create postgres-volume

And use that volume when setting up the final container

$ podman run --name mypgdb --pod postgre-sql -d -e POSTGRES_USER=admin -e POSTGRES_PASSWORD=passWoRd -v postgres-volume:/var/lib/postgresql/data:rw,z docker.io/library/postgres:16

Done.

Now, connect to your pgadmin instance on http://localhost:9876

• Add new server

  • General

    • name == mypgdb (or what ever name you gave the database when created)

  • Connection

    • Hostname / address == 0.0.0.0

    • Username == <your user>

    • Password == <your password>

• Connect

You should now be connected to your postgres instance.

The Kube spec:

# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-5.1.1
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    app: postgre-sql
  name: postgre-sql
spec:
  containers:
  - env:
    - name: PGADMIN_DEFAULT_EMAIL
      value: <your.email>@<your.domain>
    - name: PGADMIN_DEFAULT_PASSWORD
      value: passWoRd
    image: docker.io/dpage/pgadmin4:latest
    name: pgadmin
    ports:
    - containerPort: 80
      hostPort: 9876
    securityContext: {}
    volumeMounts:
    - mountPath: /var/lib/pgadmin
      name: fe79dca434a958057fa493fb87879ccc2fdc3a73167a7940ff8a382f17ef548b-pvc
  - args:
    - postgres
    env:
    - name: POSTGRES_PASSWORD
      value: passWoRd
    - name: POSTGRES_USER
      value: admin
    image: docker.io/library/postgres:16
    name: mypgdb
    volumeMounts:
    - mountPath: /var/lib/postgresql/data
      name: postgre-sql-volume-pvc
  volumes:
  - name: fe79dca434a958057fa493fb87879ccc2fdc3a73167a7940ff8a382f17ef548b-pvc
    persistentVolumeClaim:
      claimName: fe79dca434a958057fa493fb87879ccc2fdc3a73167a7940ff8a382f17ef548b
  - name: postgre-sql-volume-pvc
    persistentVolumeClaim:
      claimName: postgre-sql-volume

What the keen eyed observer might have noticed is that you cant reach the postgres db from localhost... or any other host for that matter. This is by design of course. Add an application container to the pod and the application container has full access to the database. However, this is not what I want so we have to do a minor update to the kube.yaml file.

In the postgres section of the yaml file, under name: mypgdb add

name: mypgdb
ports:
- containerPort: 5432
  hostPort: 5432

Save and re run with

$ podman kube play --replace kube.yaml

this exposes the db to my ad-hoc scripts and applications on localhost. Convenient!

anyways.. 'till next time.

I outlined how you could use dotenv to load secrets into your environment and populate a settings object. This time I'm going to expand on the settings object, and I will show how to add the settings object to django.

Below is a non-typical django settings structure. Typically, when you start a project and add an application the application will contain a settings.py file. This is fine, for the most part. However - I tend to build monoliths, this after years and years of micro services. I've learned my lesson! Monoliths it is (I do of course also use micro services, only they are not so micro any more). Monoliths tend to acquire a lot of applications. Mine does anyway, and therefore I also tend to structure my settings in the way shown below.

<project>/<app>/settings
├── apps
│   ├── bcentral_settings.py
│   ├── some_settings.py
│   ├── __init__.py
│   ├── sso_settings.py
|   |── logging_settings.py
│   └── other_settings.py
├── base.py
└── __init__.py

base.py is more or less the just the settings.py file. The __init__.py file looks like this:

$ cat __init__.py
from .base import *
from bcentral_settings.py import *
from .apps.some_settings import *
from .apps.sso_settings import *
from .apps.logging_settings import *
from .apps.other_settings import *

This means that everything(yeah...) defined in these files will be read into the settings namespace. For example, logging_settings.py contains a dictionary

LOGGING = {
    "version": 1, 
    ....
}

I just prefer to have the logging in a separate configuration file. There's no magic here.. other than the magic that django introduces by automagically configuring the logger when it encounters LOGGING.. still. It's not like it's Galtworth or something.

We are just going to look at bcentral_settings.py

Let's start with some code.

"""A settings class."""
import os
from dataclasses import dataclass, field
from django.core.exceptions import ValidationError

__all__ = ["BCENTRAL"]

PREFIX = "BCENTRAL_"  # the environment variables are prefixed

@dataclass
class BCentralSettings:
    CLIENT_ID: str = field(default="")
    CLIENT_SECRET: str = field(default="")
    TENANT_ID: str = field(default="")
    API_URL: str = field(default="")
    AUTH_ENDPOINT: str = "https://login.microsoftonline.com//oauth2/v2.0/token"
    COMPANY_UUID: str = field(default="")
    SCOPE: list[str] = field(default_factory=lambda: [
        "https://api.businesscentral.dynamics.com/.default"
        ])

So far pretty normal. We are going to add a __post_init__ magic method to the class. In this __post_init__ we will build the mechanics for populating the class with environment variables, and we will add validation mechanics. The validation is no different from what you'd normally do in django (or any other framework / program). https://docs.djangoproject.com/en/5.0/ref/validators/

    def __post_init__(self):
        for name, _field in self.__dataclass_fields__.items():
            if match := os.getenv(f"{PREFIX}{name}"):
                setattr(self, name, match)
            if method := getattr(self, f"validate_{name}", None):
                setattr(self, name, method(getattr(self, name), field=_field))

This code might warrant some explanation. In this implementation of __post_init__ we are looping over all the fields in the dataclass and can do whatever we want with them. First, we try to match an environment variable to a name in the dataclass. I tend to keep one flat file of environment variables and distinguish between them I use a prefix that tie into the settings object. In this case PREFIX = "BCENTRAL_"

The second if statement looks for a metod named validate_NAME in the class.

    def validate_CLIENT_ID(self, value: str, field=field) -> str:
        if not value:
            raise ValidationError(f"{field.name} is required")
        return value

And so on and so forth. You could also make sure value is a valid UUID, has fins and lives in the Gobi desert.. if that's your thing.

After all this, make an instance of your object

BCENTRAL = BCentralSettings()

Do this at the end of bcentral_settings.py. As you might have noticed __all__ = ["BCENTRAL"] is used. This ensures that settings is not polluted with variables from our file.

Access your settings:

$ python <project>/manage.py shell
In [1]: from django.conf import settings
In [2]: settings.BCENTRAL.CLIENT_ID
'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
In [3]: settings.PREFIX
.
.
AttributeError: 'Settings' object has no attribute 'PREFIX'

That's about it. Easy configuration management for, in this instance, django.

Until next time..

This write up are instructions on how to successfully set up Nextcloud and cloudflare tunnels resulting, hopefully, in

• working Cockpit

• working NextCloud

• well behaved iOS and Android apps.

• persistent, authorized tunnels

• a pod that will start automagically after a reboot

First, lets start with Fedora server 39. yeah.. I've got the exact same setup on Fedora server 38 - with the exception that SELinux works perfectly on 38. Not so much on 39. Is it fixable? Yes, yes it is. It's just annoying.

Anyways. Why Fedora server? Because of Cockpit and podman. Not much to it. I happen to like fedora. Get acquainted with Cockpit. It will take some time and will be well worth it. And no matter what anyone may or may not tell you. Cockpit works, it works in production. It is not particularly fragile. It's a good piece of tech. Use it.

This installation guide requires you to get a free Cloudflare account and a domain. You might not need a domain, but this tutorial assumes that you've got one.

Prepare Cloudflare by adding your domain to the Cloudflare dashboard -> Websites. If you haven't got a domain I'm certain Cloudflare can provide you with one. The docs should be able to tell you how to do this.

Cloudflared

Download cloudflared from this page https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/downloads/

I'd recommend downloading the binary version and stuffing it in ~/.local/bin with a chmod +x to make cloudflared executable. No one but you should need to have access to it.

$ cloudflared login # follw the instructions.
# after successfull authentication you will get a certificate,
# and an ID. Take note of both
$ cloudflared tunnel create nextcloud # tunnel name can be anything
$ cloudflared tunnel route dns <your-tunnel-id> <subdomain>
# You did set up Cloudflare to host your domain.. right.
# chose a subdomain.. cloud, for example. That's imaginative.

Create a new file config.yml - this can be placed anywhere. Your home folder is a good choice (It will eventually get copied to /etc/cloudflared/config.yml)

# contents of config.yml
tunnel: <your-tunnel-id>
credentials-file: /home/<you>/.cloudflared/<your-tunnel-id>.json

Ingress:
    - hostname: subdomain.yourdomain.com
      service: http://localhost:8080
    - hostname: cockpit.yourdomain.com
      service: http://localhost:9090
      originRequest:
        noTLSVerify: true

Let's detour and fix Cockpit. As root, create the file /etc/cockpit/cockpit.conf

[WebService]
Origins = https://cockpit.yourdomain.com wss://cockpit.yourdomain.com
ProtocolHeader = X-Forwarded-Proto
AllowUnencrypted = true

This will let cockpit be proxied without error through the cloudflared tunnel. Remember to restart cockpit.

$ sudo systemctl restart cockpit.service

We're mostly done with the cloudflared stuff.. just one more thing.

$ sudo /home/<you>/.local/bin/cloudflared \
--config /path/to/config.yml service install # as mentioned, this will
# copy your config.yml to /etc/cloudflared/config.yml
$ sudo systemctl start cloudflared
$ sudo systemctl status cloudflared
$ sudo systemctl enable cloudflared

Now our cloudflared tunnel configuration is installed and enabled. It will survive a reboot. Excellent!

On to NextCloud.

This is the Kube file that will create the pod with all the containers.

Be sure to change out the various passwords and correct the paths, exchanging <you> with your actual account name (I'm trying to make this as beginner friendly as possible, seriously).

# nextcloud.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: nextcloud
  name: nextcloud
spec:
  containers:
    - name: db
      args:
        - --transaction-isolation=READ-COMMITTED
        - --binlog-format=ROW
      command:
        - docker-entrypoint.sh
      env:
        - name: MYSQL_ROOT_PASSWORD
          value: <secret password>
        - name: MYSQL_DATABASE
          value: nextcloud
        - name: MYSQL_USER
          value: nextcloud
        - name: MYSQL_PASSWORD
          value: <secret password>
      image: docker.io/library/mariadb:latest
      securityContext:
        allowPrivilegeEscalation: true
        capabilities:
          drop:
            - CAP_MKNOD
            - CAP_NET_RAW
            - CAP_AUDIT_WRITE
        privileged: false
        readOnlyRootFilesystem: false
        seLinuxOptions: {}
      volumeMounts:
        - mountPath: /var/lib/mysql:Z
          name: home-<you>-containers-nextcloud-data-db
      workingDir: /
    - name: app
      env:
        - name: REDIS_HOST_PASSWORD
          value: <secret password>
        - name: MYSQL_HOST
          value: 127.0.0.1
        - name: MYSQL_DATABASE
          value: nextcloud
        - name: REDIS_HOST
          value: 127.0.0.1
        - name: MYSQL_USER
          value: nextcloud
        - name: MYSQL_PASSWORD
          value: <the mysql password>
      image: docker.io/library/nextcloud:latest
      resources: {}
      ports:
        - containerPort: 80
          hostPort: 8080
          protocol: TCP
      securityContext:
        allowPrivilegeEscalation: true
        capabilities:
          drop:
            - CAP_MKNOD
            - CAP_NET_RAW
            - CAP_AUDIT_WRITE
        privileged: false
        readOnlyRootFilesystem: false
        seLinuxOptions: {}
      volumeMounts:
        - mountPath: /var/www/html:Z
          name: home-<you>-containers-nextcloud-data-html
      workingDir: /var/www/html
    - name: redis
      command:
        - redis-server
        - --requirepass
        - <secret password>
      image: docker.io/library/redis:alpine
      resources: {}
      securityContext:
        allowPrivilegeEscalation: true
        capabilities:
          drop:
            - CAP_MKNOD
            - CAP_NET_RAW
            - CAP_AUDIT_WRITE
        privileged: false
        readOnlyRootFilesystem: true
        seLinuxOptions: {}
      volumeMounts:
        - mountPath: /tmp:Z
          name: tmpfs
        - mountPath: /var/tmp:Z
          name: tmpfs
        - mountPath: /run:Z
          name: tmpfs
      workingDir: /data
    - name: cron
      image: docker.io/library/nextcloud:latest
      command: ["/cron.sh"]
      resources: {}
      securityContext:
        allowPrivilegeEscalation: true
        capabilities:
          drop:
            - CAP_MKNOD
            - CAP_NET_RAW
            - CAP_AUDIT_WRITE
        privileged: false
        readOnlyRootFilesystem: false
        seLinuxOptions: {}
      volumeMounts:
        - mountPath: /var/www/html:Z
          name: home-<you>-containers-nextcloud-data-html
      workingDir: /var/www/html
  restartPolicy: Always
  volumes:
    - hostPath:
        path: /home/<you>/containers/nextcloud/data/db
        type: Directory
      name: home-<you>-containers-nextcloud-data-db
    - hostPath:
        path: /home/<you>/containers/nextcloud/data/html
        type: Directory
      name: home-<you>-containers-nextcloud-data-html
    - hostPath:
        path: tmpfs
        type: DirectoryOrCreate
      name: tmpfs

Now, create the necessary directories.

$ cd $HOME; \
mkdir -p containers/nextcloud/data/html ;\
mkdir -p containers/nextcloud/data/db

Great, nearly there. We will be running this as rootless containers, ie. as an unprivileged user (you).. and we will run into trouble for not being allowed to create ports below 1024. So we need to fix that.

# edit /etc/sysctl.conf as root
# add this line at the end of the file.
net.ipv4.ip_unprivileged_port_start=80

You can now either chose to reboot or

$ sudo sysctl net.ipv4.ip_unprivileged_port_start=80

Which will temporarily let you use ports below 1024 without rebooting.

It's time to create the pod.

$ # remember, do this a you, the user. Not root!
$ podman kube play path/to/nexcloud.yaml

This will churn along for quite some time depending on your hardware and internet connection. With fair winds and Odins luck (which you really shouldn't put to much faith in) everything just works and

$ podman pod ps
POD ID        NAME        STATUS      CREATED            INFRA ID      # OF CONTAINERS
96exxxxxxxxx  nextcloud   Running     About an hour ago  6adxxxxxxxxx  5
$ podman ps
6ade3c848dc4  localhost/podman-pause:4.9.0-1706090847                        About an hour ago  Up About an hour  0.0.0.0:8080->80/tcp  96e88382ac54-infra
59865dbccd75  docker.io/library/mariadb:latest         --transaction-iso...  About an hour ago  Up About an hour  0.0.0.0:8080->80/tcp  nextcloud-db
f015ddcdb8db  docker.io/library/nextcloud:latest       apache2-foregroun...  About an hour ago  Up About an hour  0.0.0.0:8080->80/tcp  nextcloud-app
1a22384699bf  docker.io/library/redis:alpine                                 About an hour ago  Up About an hour  0.0.0.0:8080->80/tcp  nextcloud-redis
12b1bb3f2e0e  docker.io/library/nextcloud:latest                             About an hour ago  Up About an hour  0.0.0.0:8080->80/tcp  nextcloud-cron

Yeah.. Now, most stuff has configured it self. But there are .. rough edges.

You'll notice that the IOS and Android app won't be able to connect to your server, so lets fix that.

As root, edit this file /home/<you>/containers/nextcloud/data/html/config/config.php

/* Add the following structures to your file, 
*  update the scructures  if they allready exists
*/
  'trusted_proxies' => 
  array (
    0 => '<the ip address of your machine>',
  ),
  'overwriteprotocol' => 'https',
  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => '<the ip address of your machine>',
    2 => 'subdomain.yourdomain.com',
  ),

/* Also, find and update this variable */
'overwrite.cli.url' => 'http://subdomain.yourdomain.com'

Now, restart your pod.

Did you think we were done? We're not. We need to get the pod to start up again in case of catastrophic failure.. like a reboot or what ever. Podman switched to something called Quadlets .. not long ago. It's not difficult, but there's scarce information about how to use it with pods. Well.. not exactly - as long as you realize that pods are Kubes. In either case..

Create a directory

$ cd $HOME; mkdir -p .config/containers/systemd

In this directory you will create one file named nexcloud.kube

# $HOME/.config/containers/systemd/nextcloud.kube
[Unit]
Description=A kubernetes yaml based service
Before=local-fs.target
[Kube]
Yaml=/path/to/nextcloud.yaml
[Install]
WantedBy=multi-user.target default.target

Now run

$ loginctl enable-linger <you>  # for good measure
$ /usr/libexec/podman/quadlets -dryrun -user  # to test the .kube
$ systemctl --user daemon-reload  # this creates the nextcloud.service
$ systemctl --user start nextcloud.service

And, we're done.

Now you can enjoy the glory of Cockpit and NextCloud even after a reboot.

'till next time.

I'm going to post some code now.

from collections.abc import Generator
from contextlib import contextmanager, suppress
from dataclasses import dataclass

import click
import requests
from beartype.typing import Any, Sequence, TypedDict, Unpack

from src.auth import fetch_auth_token
from src.settings import SETTINGS


class CliOptions(TypedDict):
    auth_type: str
    chat_type: str
    topic: str | None
    participant: str | None


@dataclass(eq=False)
class Options:
    auth_type: str
    chat_type: str
    topic: str | None
    participant: str | None


@contextmanager
def find_in_instance(
    cli_options, data
) -> Generator[list[dict[str, None | str | dict[str, str]]], Any, None]:
    match cli_options:
        case Options(participant=None, topic=None, chat_type=("oneOnOne" | "group" | "meeting")):
            yield [item for item in data if cli_options.chat_type == item["chatType"]]
        case Options(participant=None, chat_type=("oneOnOne" | "group" | "meeting")):
            yield [
                item
                for item in data
                if cli_options.chat_type == item["chatType"] and cli_options.topic in item["topic".lower()]
            ]
        case Options(topic=None, chat_type=("oneOnOne" | "group" | "meeting")):
            yield [
                item
                for item in data
                if cli_options.chat_type == item["chatType"]
                for member in item["members"]
                if cli_options.participant in member["displayName"].lower()
            ]
        case Options(chat_type=("oneOnOne" | "group" | "meeting")):
            yield [
                item
                for item in data
                if cli_options.chat_type == item["chatType"] and cli_options.topic in item["topic"]
                for member in item["members"]
                if cli_options.participant in member["displayName"]
            ]
        case __:
            yield [{"default": None}]


def lowercase(ctx, param, value):
    if value is not None:
        return value.lower()


@click.command("cli")
@click.option(
    "--auth-type",
    type=click.Choice(
        ["interactive", "code"],
        case_sensitive=False,
    ),
    default="interactive",
    help="Default is 'interactive'. If running headless use 'code'",
)
@click.option(
    "--chat-type",
    type=click.Choice(["oneOnOne", "group", "meeting"], case_sensitive=False),
    default="oneOnOne",
    help="Chat is either oneOnOne [default],  group or meeting.",
)
@click.option(
    "--topic",
    callback=lowercase,
    help="Filter on chat name or topic when it contains the <string>",
)
@click.option(
    "--participant",
    callback=lowercase,
    help="Filter on chat participants name when it contains the <string>",
)
def cli(**kwargs: Unpack[CliOptions]):
    def recursive_fetch(
        url: str,
        headers: dict[str, str],
        cli_options: Options,
        index: int = 0,
    ) -> int:
        ...do some processing
    ..do auth and some pre prossesing
    cli_options = Options(**kwargs)
    recursive_fetch(url, headers, cli_options)

So, what are we looking at here? We are looking at a client that fetches chats from https://graph.microsoft.com/v1.0/me/chats?$top=50&$expand=members, recursively.

It started when ruff complained I had too many parameters in my method call. So, naturally, I turned to **kwargs I usually never turn to **kwargs but with TypedDict I feel I can have a clear and concise understanding of what hides inside the dict. So that's one thing. I haven't seen this particular pattern used with click in the wild yet. I might be the only one with this set of needs... or I'm just very poor at designing command-line applications. That might be it.

Anyways. One thing led to another. This is the first time I've used the match statement with any success. I've tried it before but never had a use case that actually resulted in fewer lines and clearer code. Now I think I have.

I will post the auth and the Settings too - when I get around to doing it. For the time being, this post is somewhat of a placeholder so that I don't forget..

Today I needed to retrieve a long-winded chat history from our corporate Teams .. thingie. Naturally, I fired up m365 and pulled a json from the server.

While parsing the json I got more than a couple of TypeError and KeyError...errors which I squashed with a try-except. All of a sudden I heard Raymond Hettinger whispering in my ear .. "there has to be a better way!" - and lo and behold. Raymond was right!!

from contextlib import suppress
import json

with open("exportedchat.json", "r") as innfile, suppress(TypeError), suppress(KeyError):
    doc = json.loads(fp)
    for chatline in doc:
        print(chatline["from"]["user"]["displayName"])

This is so much cleaner than try->except->pass

This example is a one-shot container. It's not a pod (that might be an upcoming post). I'm running one command in the container and then I remove it. The task is to do some async calls (usually less than 10,000) to Business Central and log the results. The log must be persistent.

On with the show.

# Dockerfile
FROM python:3.11-buster
WORKDIR /usr/src/myapp

ADD src ./src
COPY .env .
COPY poetry.lock .
COPY pyproject.toml .

RUN curl -sSL https://install.python-poetry.org | python3 -
ENV PATH="/root/.local/bin:$PATH"
RUN poetry config installer.max-workers 10
RUN poetry install --only main

One image, based on python3.11-buster and a src folder containing the application.

My application must have persistent logging. Coming from docker one would assume that a VOLUMES directive in the Dockerfile or, my preferred method:

# docker-compose.yaml
version: "3"
services:
  amazingapp:
    container_name: amazingapp
    env_file: .env
    build: .
    volumes:
      - ./logs:/usr/src/myapp/logs

docker-compose would do the trick. Well. I believe that I've read, somewhere, that docker-compose should just work with podman, but even this minuscule example fails. The VOLUME directive does nothing.

So, enter podman-compose.

Does it work? Yes, yes it does. Very well actually.

$ podman-compose -f docker-compose.yaml build
$ podman-compose -f docker-compose.yaml run --rm amazingapp \
  /path/to/my/script

To my surprise, this did not create persistent volumes visible for podman volume ls. But it works just as it should.

You might find it easier to run this just using plain podman. After all, it's one less dependency and is perhaps more future-proof.

$ podman build --tag amazingapp:latest .
$ podman run -it --name myhoovercraftisfulofeels \
  ./logs:/usr/src/myapp/logs:rw,z \
  localhost/amazingapp:latest \
  /path/to/my/script

Again, it works and no volumes are created.

If you instead execute /bin/bash (replacing /path/to/my/script) you can inspect your running container and find that - indeed the logs directory are being mounted inside the container at the WORKDIR path.

$ podman inspect -f '{{.Mounts}}' <containername>
[{bind  /home/USER/path/to/logs /usr/src/myapp/logs  \
  [rbind] true rprivate}

So what are then volumes?

In a pod where you typically would use a kubernetes compatible yaml description you would add a persistentVolumeClaim for each volume. This does basically the same as

$ podman volume create amazingapp-volume

Inspecting the volume

$ podman volume inspect amazingapp-volume
[
     {
          "Name": "amazingapp-volume",
          "Driver": "local",
          "Mountpoint": "/home/USER/.local/share/containers/storage/ \
           volumes/amazingapp-volume/_data",
          "CreatedAt": "2023-09-26T08:26:04.236862704+02:00",
          "Labels": {},
          "Scope": "local",
          "Options": {},
          "MountCount": 0,
          "NeedsCopyUp": true,
          "LockNumber": 3
     }
]

Using the volume instead of /home/USER/path/to/logs

$ podman run -it --name myhoovercraftisfulofeels \
  -v amazingapp-volume:/usr/src/myapp/logs:rw,z \
  localhost/amazingapp:latest \
  /path/to/my/script

Where's your log? It's at:
/home/USER/.local/share/containers/storage/volumes/amazingapp-volume/_data
not particularly convenient.

There are other mounting options as well:

$ podman run -it --name myhoovercraftisfulofeels \
--mount type=bind,source=/home/USER/path/to/logs,\ 
target=/usr/src/amazingapp localhost/amazingapp:latest \
/path/to/my/script

Using mount this way, you'll probably run into SELinux problems. Adding --privileged might help, but I'd just stick to the -v and rw,z option to avoid turning off SELinux for the entire container process.

So here we are. This has been a long arduous journey. podman and docker are just different enough to really really trip you up. The takeaways are:

• podman is better

• docker has got better documentation

• and a heck of a lot larger installed base

• but you'll find the answer to your podman question

• eventually

I recently got my hands on a Lenovo Thinkpad X1 carbon extreme gen4. A nice if somewhat noisy 16" laptop with abysmal battery life.

But, it's got a fingerprint reader.

$ sudo dnf install fprintd libfprint fprintd-pam
$ authselect enable-feature with-fingerprint
$ authselect apply-changes

That should do it.. if you've got a gen4.

Upon reboot the fingerprint option will appear in your gnome settings panel.

Not running gnome?

$ fprintd-enroll $USER

Anyways. The SUDO command also asks for a fingerprint, which may or may not be annoying. Since my machine is docked and attached to two screens while at work, having to use fingerprint for SUDO is a no-go.

(as root)
$ cp /etc/pam.d/system-auth /etc/pam.d/system-auth-no-fingerprint

Remove the line containing pam_fprintd.so from system-auth-no-fingerprint.

Make a backup of /etc/pam.d/sudo and edit the file so that it looks like this.

#%PAM-1.0
auth       include      system-auth-no-fingerprint
account    include      system-auth-no-fingerprint
password   include      system-auth-no-fingerprint
session    optional     pam_keyinit.so revoke
session    required     pam_limits.so
session    include      system-auth-no-fingerprint

That should do the trick.

Now, how the heck do I unlock my login chain with fingerprint..

Warning! This is a typical blog post of mine... "lest I forget, do these steps and you'll be fine!"

I did this on fedora37 in a toolbox. You don't have to.

The goal is to get pyright and ruff running for python in Helix.

Srsly!

Start by reading the Helix Editor install page. Seriously.

Move on to install things you might or might not be missing. Chances are if you start from a toolbox you'll be missing a lot.

# Install nvm, node, pyright, tree-sitter, rust, cargo, dev tools..
me@toolbox ~ dnf groupinstall "Development Tools"
me@toolbox ~ dnf install gcc-c++
me@toolbox ~ dnf install rust cargo
me@toolbox ~ curl https://raw.githubusercontent.com/creationix/nvm/master/install.sh | bash
me@toolbox ~ nvm install v16.19.1
me@toolbox ~ node install pyright tree-sitter tree-sitter-cli

All this happens in a toolbox. Read about it here.

There is one particular Helix branch that I'm interested in.

Hopefully, these instructions will be obsolete very, very soon.

Read all about it here

me@toolbox ~ git clone git@github.com:Philipp-M/helix.git
me@toolbox ~ cd helix
me@toolbox ~ git checkout remotes/origin/multiple-language-servers-with-options-manager
me@toolbox ~ cargo install --locked --path helix-term
me@toolbox ~ ln -s $PWD/runtime ~/.config/helix/runtime

The above is explained on the Helix Editor install page.

The final step is to create ~/.config/helix/config.toml and ~/.config/helix/languages.toml

# ~/.config/helix/config.toml
# This is an example which happens to be how I have helix right now
theme = "base16_transparent"

[editor]
line-number = "relative"
scroll-lines = 1
scrolloff = 8
true-color = true

[editor.cursor-shape]
insert = "bar"

[editor.lsp]
display-messages = true

[editor.statusline]
left = ["mode", "spinner", "file-name"]
center = []
mode.normal = "NORMAL"
mode.insert = "INSERT"
mode.select = "SELECT"
right = ["diagnostics", "selections", "position", "file-encoding", "file-line-ending", "file-type"]
separator = "│"

[editor.indent-guides]
render = true
character = "|"

And the language file.

[language-server.pyright]
command = "pyright-langserver"
args = ["--stdio"]

[language-server.pyright.config]
lint = true
inlayHint.enable = true

[language-server.ruff-lsp]
command = "ruff-lsp"
[[language]]
name = "python"
scope ="source.python"
auto-format = true
indent = { tab-width = 4, unit = " " }
formatter = { command = "black", args = ["-", "-q"] }
roots = ["pyproject.toml", "pyrightconfig.json", "Poetry.lock"]
language-servers = [
    { name = "pyright" },
    { name = "ruff-lsp" },
]

Is the language.toml config 100% correct? I don't think so. It works - so there's that, but this is hardly an authoritative source on how to configure pyright and ruff.

I've found it easiest to just add ruff-lsp to my pyproject.toml file and use Helix when in the virtual env.

To make the most of ruff, add this section in your pyproject.toml file

[tool.ruff]
extend-select = ["A", "B", "C4", "D", "I", "ERA", "PLR", "SIM", "TCH", "ANN"]
show-fixes = true
line-length=119

Learn about what it all means here

...at last

..we have arrived at the objective of this blog post. Running two lsp servers in helix. This feature is currently unavailable in release 22.12, hence the usage of the multiple-language-servers-with-options-manager branch.

There's one more thing I'd like to have as well, namely inlayHints https://github.com/helix-editor/helix/pull/5934

I have absolutely no idea how, or if it's even possible, to merge two repos..(turns out it is). I'm hoping for these patches to make it into the next helix release. Until then - I'm happy with having two lsp's.

I lied.

Anyways. I needed to deploy a script onto an older server where manually installing python > 3.11 just was too much hassle. I did have docker tho.

First, the Dockerfile

FROM python:3.11
RUN apt-get update && apt-get install -y \
curl

WORKDIR /usr/src/myapp
ADD src ./src
ADD logs ./logs

COPY .env .
COPY poetry.lock .
COPY pyproject.toml .

RUN curl -sSL https://install.python-poetry.org | python3
ENV PATH="/root/.local/bin:$PATH"
RUN poetry install --only main

Nothing much happening here. We install curl in the image just to be sure. It's probably there already and we do install poetry and add it to the PATH.

The docker-compose.yml

version: '3'
services:
    mymagnificentapp:
        container_name: myapp
        env_file: .env
        build: .
        volumes:
            - ./logs:/usr/src/myapp/logs
            - ./src:/usr/src/myapp/src
            - /etc/timezone:/etc/timezone:ro
            - /etc/localtime:/etc/localtime:ro

We mount both the logs and the src directory. This is afaik the only way to get persistent logs w/o using external logging facilities. We mount the src directory so we can make configuration changes between runs.

The Makefile

CMD := $1

build:
   docker-compose -f docker-compose.yml build $(c)

firstcmd:
   docker-compose -f docker-compose.yml run mymagnificentapp poetry run src/main1.py

secondcmd:
   docker-compose -f docker-compose.yml run mymagnificentapp poetry run src/main2.py

Executing make from the command line will build the app. Executing make firstcmd will run the defined command.

However, you might get a permission error if you, like me, have made a habit of forgetting to add the #SHEBANG to your main.py files.

#! /usr/bin/env python3
"""My magnificent main."""

def main():
    ...

if __name__ == "__main__":
    main()

That's it. You have a semi-isolated python 3.11 environment in which to run scripts.

Today, I needed typesubs for smbclient of package smbprotocol.

:CocCommand pyright.createstypestub smbclient

This creates the necessary typestubs.

In my case I use nvim with Conquer of Completion and pyright. Yes, I know nvim now has built-in lsp support, but CoC works better for me.

For the stubs to work with pyright you need a pyrightconfig.json file.

It might look something like this

    "include": [
      "src",
    ],

    "exclude": [
      "**/__pycache__"
    ],

    "ignore": [
    ],
    "typeshedPath": "/home/you/yoursource/typeshed",
    "stubPath": "/home/you/yoursource/stubs",
    "venvPath": ".",

    "reportMissingImports": true,
    "reportMissingTypeStubs": true,

    "pythonVersion": "3.11",
    "pythonPlatform": "Linux",

    "executionEnvironments": [
      {
        "root": "/",
        "venv": ".venv",
        "pythonVersion": "3.11",
        "pythonPlatform": "Linux",
        "extraPaths": [
          ""
        ]
      }
    ]
  }

and if /src are your sources it should be present alongside your /src directory.

This should solve missing type hints in smbclient. I did however encounter a different problem (this is not always the case).

To fix this, navigate to your stubs folder /smbclient and edit the __init__.py file in that directory.

In the __init__.py file add __all__

""" 
This type stub file was generated by pyright. 
""" 

import logging 
import smbclient.path
from smbclient._io import SEEK_CUR, SEEK_END, SEEK_SET
from smbclient._os import (
    SMBDirEntry,
    .
    open_file, 
    readlink,
    remove, 
    .
    .
)

# add this after all the imports
__all__ = ["open_file", "readlink", "remove", ....]

and pyright will stop complaining.

There might be a better way of doing this. Please comment if you know of a better way!

The main reason I'm late to the Poetry party is that I failed to read the docs. I prefer having a .venv in my local dir as opposed to a ~/.config/{virtualenv..cache..thingie} and somehow I had convinced myself that Poetry didn't support that.

$ poetry config virtualenvs.in-project true

So with that fixed, I promptly started complaining about Poetrys add <packagename> - time consuming and annoying!! .. but it takes a list of packages.. so if I take my requirements.in and dev-requirements.in files and ..

$ poetry add $(cat reqs/requirements.in)
$ poetry add $(cat reqs/dev-requirements.in) --group dev

Yeah, that worked. But hey(!), my deploy scripts expect a requirements.txt? file. I can't be bothered with fixing that!

$ poetry export --without-hashes --format=requirements.txt > requirements.txt

Damnation!

As you well understand, by now I've run out of excuses for not using Poetry.

One down, one more to go. Now, onwards towards integrating Poetry with my build setup.

I'm using the pyYaml library in this write-up.

# companies.yaml
- !Company
  company_name: PoundCompany
  active: True 
  has_dimensions: True
  dimensions:
    - sillyname1
    - sillyname2
  file_mapping:
    account_number_map: accounts.csv
    account_type_map: accounts.csv
    tax_code_map: taxcodes.csv
  bi_central_uuid: 00000000-0000-0000-0000-000000000001
- !Company
  company_name: EuroCompany
  active: True 
  has_dimensions: True
  dimensions:
    - sillyname1
    - sillyname2
  file_mapping:
    account_number_map: accounts.csv
    account_type_map: accounts.csv
    tax_code_map: taxcodes.csv
  bi_central_uuid: 00000000-0000-0000-0000-000000000002

This YAML describes two instances of the initialized class.

#company.py
from dataclasses import dataclass, field

@dataclass
class CompanyModel:
    company_name: str = field(default="")
    active: bool = False
    has_dimensions: bool = False
    dimensions: list = field(default_factory=list)
    file_mapping: dict = field(default_factory=dict)
    bi_central_uuid: str = field(default="")

And this is my class. It might surprise you that I've chosen to name it xxxModel. To me, this is a model. A collection of attributes that I, at some point, am going to serialize to JSON before posting it on the Business Central API. This class is basically data.

The task at hand is to go from YAML to (model)Class!

The pyYaml documentation has a few examples on how to do this, none of which I found particularly interesting.

Onwards! Let's start with reading the YAML

# company_loader.py
import yaml
from protocols import Settings, Company
from settings import SETTINGS
from company import CompanyModel
from beartype import beartype

@beartype
def get_companies(settings: Settings):
    with open(settings.base_dir / "companies.yaml", "rb") as fp:
        return yaml.load(fp, Loader=get_loader())

The interesting part here is get_loader(). Let's define it.

# company_loader.py
@beartype
def get_loader()->type[yaml.SafeLoader]:
    loader = yaml.SafeLoader
    loader.add_constructor("!Company", company_constructor)
    return loader

Now we have created the loader and we've added a constructor to it. The constructor does all the heavy lifting and will construct our class. There are a few constructors in pyYaml. To be honest, I gave yaml.SafeLoader.construct_mapping() a go and never figured out why it didn't produce lists and dicts. This is far from rocket science and creating a constructor is relatively easy

This might be a good time to explain why I created this contraption. I needed to move data (appearing in one and only one static format) to the BiCentral API. No room for interpretation.

Anyway. You'll find code in pyYaml that resembles the below function - the main difference being that I understand what my code does and it does exactly what I need.

# company_loader.py
@beartype
def company_constructor(
    loader: yaml.SafeLoader, 
    node: yaml.nodes.MappingNode,
    )-> Company:                                                                     
    """Construct an employee."""                                                                                                                                    
    _node = {}                                                                                                                         

    def process_node(node): -> None                                                                                                                                 
        for _n in node.value:                                                                                                                                       
            attr_name, attr_value = _n                                                                                                                   
            if isinstance(attr_name, yaml.MappingNode):                                                                                                             
                process_node(attr_name)                                                                                                                             
            _node[attr_name.value] = ""                                                                                                                             
            _cast: str = attr_value.tag.split(":")[-1]
            if _cast in ["bool", "int"]:                                                                                                                            
                _node[attr_name.value] = eval(attr_value.value)                                                                                                     
            elif _cast == "seq":                                                                                                                                    
                _node[attr_name.value] = [
                    item.value for item in
                    attr_value.value
                    ]                                                                                  
            elif _cast == "map":                                                                                                                                    
                _node[attr_name.value] = {}                                                                                                                         
                _node[attr_name.value].update(                                                                                                                      
                    {
                        (key.value, val.value) for (key, val)
                         in [
                                item for item in
                                attr_value.value
                             ]
                    },                                                                 
                )                                                                                                                                                   
            else:                                                                                                                                                   
                _node[attr_name.value] = attr_value.value
    process_node(node)                                                                                                                                              
    return CompanyModel(**_node)  # type: ignore

As you can see, the process_node() function is recursive and it is tailored to my needs. I don't need to call eval on items in my list or dict instances so naturally, I don't. When it's done I unpack the resulting dict and return an initialized CompanyModel object.

Before wrapping up I'd like to mention two minor details. I really like protocols (Thank you Arjan) and beartype - I also like beartype, a lot.

# protocols.py
from typing import Protocol
from pathlib import Path
from beartype import typing

@typing.runtime_checkable                                                                                                                                           
class Settings(Protocol):                                                                                                                                           
    base_dir: Path

@typing.runtime_checkable
class Company(Protocol):
    company_name: str
    active: bool
    has_dimensions: bool
    dimensions: list
    file_mapping: dict
    bi_central_uuid: str

You'll find the SETTINGS class somewhere else on this blog.

The main takeaways.

• YAML is still cool

• Things do not need to get too complicated if you scope it well

• Protocols are awesome

• Arjan is awesome

• Beartyping is next-level awesome