Over the weekend, I decided to try running a Postgres database in my Homelab. In my current setup, the most convenient option for storage is NFS. However, NFS is especially tricky for databases. A misconfigured setup can lead to performance or data corruption issues.
After watching
Onyx tablets reportedly phone home and send "data" to some servers in China. The manufacturer apparently refuses to publish the source-code modifications to the OS and the open-source apps they are using and they even go as far as violating GPL.
Of course I learned all that after buying this tablet. To ease my mind, I spent some time debloating it and then blocked the outgoing traffic to
I was once working with a client, and our team was facing a mix of technical and non-technical challenges in shipping a relatively simple web application. During one of our meetings, I cracked a silly joke: "At this rate, we might as well zip up the source code and send it to anyone who wants to try it." (note for the reader: our users were non-developer colleagues from the same organization)
Of course we chuckled and we moved on. But later, I found myself aching to try that silly idea out. Or a refined version of it:
brew services start colima. You can skip the following work-around.
cat <<-EOF | sudo tee /usr/local/bin/colima-start-fg
#!/bin/bash
AMD’s Strix Halo APU is one of the most interesting consumer options right now for running local AI workloads. It is relatively power efficient, and its unified memory architecture lets the GPU access large amounts of system RAM. This makes it possible to run larger models locally without a discrete GPU.
As the software is still maturing, running models with GPU acceleration is not exactly straightforward yet. So I wrote this guide after getting a setup working
Tips for running a single-node Kubernetes cluster on WSL2 with Podman
Edit /etc/containers/containers.conf:
cgroup_manager to cgroupfsevents_logger to file
| [Palette] | |
| Name=Base16 Eighties | |
| Background=#2d2d2d | |
| Foreground=#d3d0c8 | |
| Cursor=#d3d0c8 | |
| Color0=#2d2d2d | |
| Color1=#f2777a | |
| Color2=#99cc99 | |
| Color3=#ffcc66 | |
| Color4=#6699cc |
When running containers with Docker Compose, I sometimes want to access an unpublished port from a dependency container. For example, I sometimes need to connect directly to a database running inside a compose stack.
The usual solution is to edit (docker-)compose.yml and recreate the container with a published port. This works, but it is disruptive when the service is already running.
After experimenting a bit, I discovered two ways to expose container ports without recreating the containers. I'll document those in this post.
[!NOTE]