From 5c52f44108dfe6b175417a49fade3ece93762043 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sat, 6 Jun 2026 08:54:53 +0300 Subject: Update content for html --- gemfeed/atom.xml | 409 +++++++++++++++++++++++++++---------------------------- 1 file changed, 203 insertions(+), 206 deletions(-) (limited to 'gemfeed/atom.xml') diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index e6ae257e..b168f2b4 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,11 +1,211 @@ - 2026-05-31T22:32:28+03:00 + 2026-06-06T08:54:01+03:00 foo.zone feed To be in the .zone! https://foo.zone/ + + Random Weird Things - Part Ⅳ + + https://foo.zone/gemfeed/2026-06-06-random-weird-things-iv.html + 2026-06-06T08:54:00+03:00 + + Paul Buetow aka snonux + paul@dev.buetow.org + + Every so often I stumble upon random, weird, and completely unexpected things on the internet. I thought it would be neat to share them here from time to time. This is the fourth run. + +
+

Random Weird Things - Part Ⅳ


+
+Every so often I stumble upon random, weird, and completely unexpected things on the internet. I thought it would be neat to share them here from time to time. This is the fourth run.
+
+
+   /\_/\      /\_/\      /\_/\  
+  ( o.o )    ( o.o )    ( o.o ) 
+   > ^ <      > ^ <      > ^ <
+   
+   /\_/\    Miaaauuuu....
+  ( o.o )
+   > ^ < 
+
+
+2024-07-05 Random Weird Things - Part Ⅰ
+2025-02-08 Random Weird Things - Part Ⅱ
+2025-08-15 Random Weird Things - Part Ⅲ
+2026-06-06 Random Weird Things - Part Ⅳ (You are currently reading this)
+
+

Table of Contents


+
+
+

31. GUI Apps in Your Terminal


+
+term.everything is a from-scratch Wayland compositor that renders GUI apps inside your terminal. GTK, Qt, whatever — it just grabs it and draws it right there. You can run Firefox or GIMP over SSH and interact with it using your mouse. No X forwarding, no latency nonsense. It actually works.
+
+term.everything demo
+term.everything
+
+

32. TempleOS


+
+Terry A. Davis spent years single-handedly building a complete 64-bit operating system from scratch because God told him to. It runs at 640×480, uses a custom language called HolyC, has its own compiler, and is designed as a temple. Boot it up and you get scripture, a talking parrot, and probably the weirdest OS you'll ever see. One of the most fascinating stories in computing.
+
+TempleOS screenshot
+TempleOS
+
+

33. LLM via DNS


+
+You can query an LLM using nothing but DNS. Just run dig @ch.at "what is golang" TXT +short and you get back an answer in the TXT records. No browser, no API key. It even works over SSH tunnels.
+
+ +
$ dig @ch.at "what is golang" TXT +short
+"Golang, or Go, is an open-source programming language developed by Google.
+It was created to simplify the development of reliable and efficient software.
+Go is known for its simplicity, strong concurrency support, and performance
+comparable to C or C++. I" "t features garbage collection, type safety, and
+built-in support for concurrent programming through goroutines and channels.
+Go is widely used for web servers, cloud services, and distributed systems due
+to its efficiency and ease of deployme..."
+
+
+

34. Black Hole in ~125 Bytes


+
+Thi le in your browser tab. No frameworks, no libraries, just code-golf magic. I stared at it way longer than I care to admit.
+
+Black Hole
+
+

35. loss32: Win32 on Linux


+
+loss32 is a Linux distro where the entire desktop is classic Win32 apps running natively. ReactOS + WINE on steroids. You get the Windows 98/2000 vibe on a modern Linux kernel. It's not trying to be practical — it's pure nostalgia for people who miss the old Windows desktop but don't want the actual Windows.
+
+loss32 desktop screenshot
+loss32
+
+

36. LLM Rescuer 🤖💰


+
+LLM Rescuer is a tiny Ruby gem that hooks into Ruby's method dispatch so that calling a method on nil doesn't crash — it asks an LLM what the return value should be instead. When a NoMethodError would normally explode, the gem catches it, packages up the context (what method was called, what the variable name suggests, maybe the surrounding code), fires that off to an actual LLM API, and returns whatever the model hallucinates as sensible.
+
+So user.email on a nil user doesn't die. It asks the LLM "someone called .email on a user that turned out to be nil, what should I return?" and the model says "probably 'no-reply@example.com'". The gem swallows the error and hands you that string.
+
+It tries to keep API costs down by sending only minimal context — just the method name and variable name rather than your whole codebase — but every nil-hit still costs tokens and adds latency.
+
+This is runtime monkey-patching powered by a remote AI. Your nil bugs don't crash, they silently return AI-guessed values. In production this would be a debugging nightmare.
+
+Examples:
+
+ +
# Classic nil safety
+user = find_user(id: "nonexistent") # returns nil
+puts user.email
+# AI: "Analyzing context... user seems to need an email...
+#      returning 'no-reply@example.com'"
+
+# Shopping cart magic
+cart = session[:cart] # nil because session expired
+total = cart.total_price
+# AI: "This looks like e-commerce. Based on similar patterns,
+#      I'll return 0.0 to avoid charging $nil"
+
+# The existential crisis
+meaning_of_life = nil
+answer = meaning_of_life.to_i
+# AI: "Clearly this should be 42. I've read Douglas Adams."
+
+
+LLM Rescuer
+
+

37. Filesystem Backed by an LLM


+
+Mount a folder via FUSE, and every time you read or write a file, an LLM decides what the contents should be. There's a real working implementation. You literally cat a file and the LLM generates the output on the fly.
+
+Example usage:
+
+ +
$ echo "a nginx config for a reverse proxy to localhost:8080" > /mnt/llmfs/nginx.conf
+$ cat /mnt/llmfs/nginx.conf
+server {
+    listen 80;
+    location / {
+        proxy_pass http://localhost:8080;
+    }
+}
+
+$ echo "my todo list for today" > /mnt/llmfs/todo.txt
+$ cat /mnt/llmfs/todo.txt
+- Write blog post
+- Fix that bug in prod
+- Drink coffee
+
+$ cat /mnt/llmfs/todo.txt
+- Write blog post (done?)
+- Fix that bug in prod
+- Drink more coffee
+
+
+The LLM hallucinates the file contents every single read. Your todo list literally mutates when you look at it. Want a config file? Just describe it in the filename or write a prompt into it. Equal parts brilliant and terrifying.
+
+Filesystem Backed by an LLM
+
+

38. QR Code with Pure SQL in Postgres


+
+Someone generated a full QR code using nothing but SQL queries inside PostgreSQL. No extensions, no external tools — just raw Postgres doing things it was never meant to do. I ran the example and watched a QR code materialize in the query result. Mad stuff.
+
+QR code generated with pure SQL
+Pure SQL QR Code
+
+

39. The SL Train in Your Terminal


+
+You mistype ls as sl and a steam locomotive comes chugging across your terminal. The SL program has been around for decades and it still cracks me up. There's even a flying train variant.
+
+SL train in action
+sl
+
+

40. URL in C Code Puzzle


+
+The following C program compiles and runs perfectly:
+
+
+#include <stdio.h>
+
+int main(void) {
+    https://foo.zone
+    printf("hello, world\n");
+    return 0;
+}
+
+
+The https: becomes a label, the //foo.zone is just a comment. C parser shenanigans.
+
+Found something weird lately? Send me a link!
+
+E-Mail your comments to paul@nospam.buetow.org :-)
+
+Back to the main site
+
+
+
`gt` calculator - a calculator built with local LLMs @@ -11362,6 +11562,7 @@ ls -d -- !(.git|node_modules) 2>/dev/null 2024-07-05 Random Weird Things - Part Ⅰ
2025-02-08 Random Weird Things - Part Ⅱ
2025-08-15 Random Weird Things - Part Ⅲ (You are currently reading this)
+2026-06-06 Random Weird Things - Part Ⅳ

  /\_/\        /\_/\        /\_/\
@@ -18490,6 +18691,7 @@ http://www.gnu.org/software/src-highlite -->
 2024-07-05 Random Weird Things - Part Ⅰ
2025-02-08 Random Weird Things - Part Ⅱ (You are currently reading this)
2025-08-15 Random Weird Things - Part Ⅲ
+2026-06-06 Random Weird Things - Part Ⅳ

 /\_/\           /\_/\
@@ -20319,211 +20521,6 @@ Waking up e8:ff:1e:d7:1c:a0...
 
E-Mail your comments to paul@nospam.buetow.org :-)

-Back to the main site
- - - - - f3s: Kubernetes with FreeBSD - Part 1: Setting the stage - - https://foo.zone/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.html - 2024-11-16T23:20:14+02:00 - - Paul Buetow aka snonux - paul@dev.buetow.org - - This is the first blog post about my f3s series for my self-hosting demands in my home lab. f3s? The 'f' stands for FreeBSD, and the '3s' stands for k3s, the Kubernetes distribution I will use on FreeBSD-based physical machines. - -
-

f3s: Kubernetes with FreeBSD - Part 1: Setting the stage


-
-Published at 2024-11-16T23:20:14+02:00
-
-This is the first blog post about my f3s series for my self-hosting demands in my home lab. f3s? The "f" stands for FreeBSD, and the "3s" stands for k3s, the Kubernetes distribution I will use on FreeBSD-based physical machines.
-
-I will post a new entry every month or so (there are too many other side projects for more frequent updates—I bet you can understand).
-
-These are all the posts so far:
-
-2024-11-17 f3s: Kubernetes with FreeBSD - Part 1: Setting the stage (You are currently reading this)
-2024-12-03 f3s: Kubernetes with FreeBSD - Part 2: Hardware and base installation
-2025-02-01 f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts
-2025-04-05 f3s: Kubernetes with FreeBSD - Part 4: Rocky Linux Bhyve VMs
-2025-05-11 f3s: Kubernetes with FreeBSD - Part 5: WireGuard mesh network
-2025-07-14 f3s: Kubernetes with FreeBSD - Part 6: Storage
-2025-10-02 f3s: Kubernetes with FreeBSD - Part 7: k3s and first pod deployments
-2025-12-07 f3s: Kubernetes with FreeBSD - Part 8: Observability
-2025-12-14 f3s: Kubernetes with FreeBSD - Part 8b: Distributed Tracing with Tempo
-2026-04-02 f3s: Kubernetes with FreeBSD - Part 9: GitOps with ArgoCD
-
-f3s logo
-
-ChatGPT generated logo..
-
-Let's begin...
-
-

Table of Contents


-
-
-

Why this setup?


-
-My previous setup was great for learning Terraform and AWS, but it is too expensive. Costs are under control there, but only because I am shutting down all containers after use (so they are offline ninety percent of the time and still cost around $20 monthly). With the new setup, I could run all containers 24/7 at home, which would still be cheaper in terms of electricity consumption. I have a 400 MBit/s uplink (I could have more if I wanted, but it is more than plenty for my use case already).
-
-From babylon5.buetow.org to .cloud
-
-Migrating off all my containers from AWS ECS means I need a reliable and scalable environment to host my workloads. I wanted something:
-
-
    -
  • To self-host all my open-source apps (Docker containers).
  • -
  • Fully under my control (goodbye cloud vendor lock-in).
  • -
  • Secure and redundant.
  • -
  • Cost-efficient (after the initial hardware investment).
  • -
  • Something I can poke around with and also pick up new skills.
  • -

-

The infrastructure


-
-This is still in progress, and I need to own the hardware. But in this first part of the blog series, I will outline what I intend to do.
-
-Diagram
-
-

Physical FreeBSD nodes and Linux VMs


-
-The setup starts with three physical FreeBSD nodes deployed into my home LAN. On these, I'm going to run Rocky Linux virtual machines with bhyve. Why Linux VMs in FreeBSD and not Linux directly? I want to leverage the great ZFS integration in FreeBSD (among other features), and I have been using FreeBSD for a while in my home lab. And with bhyve, there is a very performant hypervisor available which makes the Linux VMs de-facto run at native speed (another use case of mine would be maybe running a Windows bhyve VM on one of the nodes - but out of scope for this blog series).
-
-https://www.freebsd.org/
-https://wiki.freebsd.org/bhyve
-
-I selected Rocky Linux because it comes with long-term support (I don't want to upgrade the VMs every 6 months). Rocky Linux 9 will reach its end of life in 2032, which is plenty of time! Of course, there will be minor upgrades, but nothing will significantly break my setup.
-
-https://rockylinux.org/
-https://wiki.rockylinux.org/rocky/version/
-
-Furthermore, I am already using "RHEL-family" related distros at work and Fedora on my main personal laptop. Rocky Linux belongs to the same type of Linux distribution family, so I already feel at home here. I also used Rocky 9 before I switched to AWS ECS. Now, I am switching back in one sense or another ;-)
-
-

Kubernetes with k3s


-
-These Linux VMs form a three-node k3s Kubernetes cluster, where my containers will reside moving forward. The 3-node k3s cluster will be highly available (in etcd mode), and all apps will probably be deployed with Helm. Prometheus will also be running in k3s, collecting time-series metrics and handling monitoring. Additionally, a private Docker registry will be deployed into the k3s cluster, where I will store some of my self-created Docker images. k3s is the perfect distribution of Kubernetes for homelabbers due to its simplicity and the inclusion of the most useful features out of the box!
-
-https://k3s.io/
-
-

HA volumes for k3s with HAST/ZFS and NFS


-
-Persistent storage for the k3s cluster will be handled by highly available (HA) NFS shares backed by ZFS on the FreeBSD hosts.
-
-On two of the three physical FreeBSD nodes, I will add a second SSD drive to each and dedicate it to a zhast ZFS pool. With HAST (FreeBSD's solution for highly available storage), this pool will be replicated at the byte level to a standby node.
-
-A virtual IP (VIP) will point to the master node. When the master node goes down, the VIP will failover to the standby node, where the ZFS pool will be mounted. An NFS server will listen to both nodes. k3s will use the VIP to access the NFS shares.
-
-FreeBSD Wiki: Highly Available Storage
-
-You can think of DRBD being the Linux equivalent to FreeBSD's HAST.
-
-

OpenBSD/relayd to the rescue for external connectivity


-
-All apps should be reachable through the internet (e.g., from my phone or computer when travelling). For external connectivity and TLS management, I've got two OpenBSD VMs (one hosted by OpenBSD Amsterdam and another hosted by Hetzner) handling public-facing services like DNS, relaying traffic, and automating Let's Encrypt certificates.
-
-All of this (every Linux VM to every OpenBSD box) will be connected via WireGuard tunnels, keeping everything private and secure. There will be 6 WireGuard tunnels (3 k3s nodes times two OpenBSD VMs).
-
-https://en.wikipedia.org/wiki/WireGuard
-
-So, when I want to access a service running in k3s, I will hit an external DNS endpoint (with the authoritative DNS servers being the OpenBSD boxes). The DNS will resolve to the master OpenBSD VM (see my KISS highly-available with OpenBSD blog post), and from there, the relayd process (with a Let's Encrypt certificate—see my Let's Encrypt with OpenBSD and Rex blog post) will accept the TCP connection and forward it through the WireGuard tunnel to a reachable node port of one of the k3s nodes, thus serving the traffic.
-
-KISS high-availability with OpenBSD
-Let's Encrypt with OpenBSD and Rex
-
-The OpenBSD setup described here already exists and is ready to use. The only thing that does not yet exist is the configuration of relayd to forward requests to k3s through the WireGuard tunnel(s).
-
-

Data integrity


-
-

Periodic backups


-
-Let's face it, backups are non-negotiable.
-
-On the HAST master node, incremental and encrypted ZFS snapshots are created daily and automatically backed up to AWS S3 Glacier Deep Archive via CRON. I have a bunch of scripts already available, which I currently use for a similar purpose on my FreeBSD Home NAS server (an old ThinkPad T440 with an external USB drive enclosure, which I will eventually retire when the HAST setup is ready). I will copy them and slightly modify them to fit the purpose.
-
-There's also zfstools in the ports, which helps set up an automatic snapshot regime:
-
-https://www.freshports.org/sysutils/zfstools
-
-The backup scripts also perform some zpool scrubbing now and then. A scrub once in a while keeps the trouble away.
-
-

Power protection


-
-Power outages are regularly in my area, so a UPS keeps the infrastructure running during short outages and protects the hardware. I'm still trying to decide which hardware to get, and I still need one, as my previous NAS is simply an older laptop that already has a battery for power outages. However, there are plenty of options to choose from. My main criterion is that the UPS should be silent, as the whole setup will be installed in an upper shelf unit in my daughter's room. ;-)
-
-

Monitoring: Keeping an eye on everything


-
-I want to know when stuff breaks (ideally before it breaks), so monitoring is a big part of the plan.
-
-

Prometheus and Grafana


-
-Inside the k3s cluster, Prometheus will be deployed to handle metrics collection. It will be configured to scrape data from my Kubernetes workloads, nodes, and any services I monitor. Prometheus also integrates with Alertmanager to generate alerts based on predefined thresholds or conditions.
-
-https://prometheus.io
-
-For visualization, Grafana will be deployed alongside Prometheus. I mostly just want dashboards for CPU, memory, and pod health — the usual stuff. Makes it way easier to figure out what's going wrong when something inevitably does.
-
-https://grafana.com
-
-

Gogios: My custom alerting system


-
-Alerts generated by Prometheus are forwarded to Alertmanager, which I will configure to work with Gogios, a lightweight monitoring and alerting system I wrote myself. Gogios runs on one of my OpenBSD VMs. At regular intervals, Gogios scrapes the alerts generated in the k3s cluster and notifies me via Email.
-
-KISS server monitoring with Gogios
-
-Ironically, I implemented Gogios to avoid using more complex alerting systems like Prometheus, but here we go—it integrates well now.
-
-

Conclusion


-
-This setup may be just the beginning. Some ideas I'm thinking about for the future:
-
-
    -
  • Adding more FreeBSD nodes (in different physical locations, maybe at my wider family's places? WireGuard would make it possible!) for better redundancy. (HA storage then might be trickier)
  • -
  • Deploying more Docker apps (data-intensive ones, like a picture gallery, my entire audiobook catalogue, or even a music server) to k3s.
  • -

-For now, though, I'm focused on completing the migration from AWS ECS and getting all my Docker containers running smoothly in k3s.
-
-Anyway, stay tuned — in part 2 I'll probably get into the hardware and OS setup.
-
-Read the next post of this series:
-
-f3s: Kubernetes with FreeBSD - Part 2: Hardware and base installation
-
-Other *BSD-related posts:
-
-2026-04-02 f3s: Kubernetes with FreeBSD - Part 9: GitOps with ArgoCD
-2025-12-14 f3s: Kubernetes with FreeBSD - Part 8b: Distributed Tracing with Tempo
-2025-12-07 f3s: Kubernetes with FreeBSD - Part 8: Observability
-2025-10-02 f3s: Kubernetes with FreeBSD - Part 7: k3s and first pod deployments
-2025-07-14 f3s: Kubernetes with FreeBSD - Part 6: Storage
-2025-05-11 f3s: Kubernetes with FreeBSD - Part 5: WireGuard mesh network
-2025-04-05 f3s: Kubernetes with FreeBSD - Part 4: Rocky Linux Bhyve VMs
-2025-02-01 f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts
-2024-12-03 f3s: Kubernetes with FreeBSD - Part 2: Hardware and base installation
-2024-11-17 f3s: Kubernetes with FreeBSD - Part 1: Setting the stage (You are currently reading this)
-2024-04-01 KISS high-availability with OpenBSD
-2024-01-13 One reason why I love OpenBSD
-2022-10-30 Installing DTail on OpenBSD
-2022-07-30 Let's Encrypt with OpenBSD and Rex
-2016-04-09 Jails and ZFS with Puppet on FreeBSD
-
-E-Mail your comments to paul@nospam.buetow.org :-)
-
Back to the main site
-- cgit v1.2.3