diff options
| -rw-r--r-- | gemfeed/2025-12-24-x-rag-observability-hackathon.md | 2 | ||||
| -rw-r--r-- | gemfeed/DRAFT-distributed-systems-simulator.md | 8 | ||||
| -rw-r--r-- | gemfeed/DRAFT-f3s-kubernetes-with-freebsd-part-X.md | 8 | ||||
| -rw-r--r-- | gemfeed/DRAFT-ipv6test-deployment.md | 4 |
4 files changed, 11 insertions, 11 deletions
diff --git a/gemfeed/2025-12-24-x-rag-observability-hackathon.md b/gemfeed/2025-12-24-x-rag-observability-hackathon.md index 76d1eede..b47ea553 100644 --- a/gemfeed/2025-12-24-x-rag-observability-hackathon.md +++ b/gemfeed/2025-12-24-x-rag-observability-hackathon.md @@ -2,7 +2,7 @@ > Published at 2025-12-24T09:45:29+02:00 -This blog post describes my hackathon efforts adding observability to X-RAG, the extensible Retrieval-Augmented Generation (RAG) platform built by my brother Florian. I especially made time available over the weekend to join his 3-day hackathon (attending 2 days) with the goal of instrumenting his existing distributed system with observability. What started as "let's add some metrics" turned into a comprehensive implementation of the three pillars of observability: tracing, metrics, and logs. +This post describes my hackathon efforts adding observability to X-RAG, the extensible Retrieval-Augmented Generation (RAG) platform built by my brother Florian. I made time over the weekend to join his 3-day hackathon (attending 2 days) with the goal of instrumenting his existing distributed system with observability. What started as "let's add some metrics" turned into a comprehensive implementation of the three pillars of observability: tracing, metrics, and logs. [X-RAG source code on GitHub](https://github.com/florianbuetow/x-rag) diff --git a/gemfeed/DRAFT-distributed-systems-simulator.md b/gemfeed/DRAFT-distributed-systems-simulator.md index 45e75a0d..1c2f668b 100644 --- a/gemfeed/DRAFT-distributed-systems-simulator.md +++ b/gemfeed/DRAFT-distributed-systems-simulator.md @@ -54,7 +54,7 @@ This blog explores the Java-based Distributed Systems Simulator program I create ## Motivation -Distributed systems are notoriously complex, with intricate interactions between multiple nodes, network partitions, and failure scenarios that can be difficult to understand and debug in production environments. A distributed systems simulator provides an invaluable learning tool that allows developers and students to experiment with different architectures, observe how systems behave under various failure conditions, and gain hands-on experience with concepts like consensus algorithms, replication strategies, and fault tolerance -- all within a controlled, repeatable environment. By abstracting away the operational overhead of managing real distributed infrastructure, simulators enable focused exploration of system design principles and help bridge the gap between theoretical knowledge and practical understanding of how distributed systems actually work in the real world. +Distributed systems are complex—interactions between nodes, network partitions, failure scenarios are hard to debug in production. A simulator lets you experiment with architectures, observe how systems behave under failure, and learn consensus algorithms, replication strategies, and fault tolerance in a controlled, repeatable environment. No operational overhead, no real infrastructure—just focused exploration of system design. In the literature, one can find many different definitions of a distributed system. Many of these definitions differ from each other, making it difficult to find a single definition that stands alone as the correct one. Andrew Tanenbaum and Maarten van Steen chose the following loose characterization for describing a distributed system: @@ -62,11 +62,11 @@ In the literature, one can find many different definitions of a distributed syst The user only needs to interact with the local computer in front of them, while the software of the local computer ensures smooth communication with the other participating computers in the distributed system. -This thesis aims to make it easier for users to view distributed systems from a different perspective. Here, the viewpoint of an end user is not adopted; instead, the functional methods of protocols and their processes in distributed systems should be made comprehensible, while simultaneously making all relevant events of a distributed system transparent. +This thesis aims to make distributed systems easier to understand from a different angle. Instead of the end-user perspective, it focuses on the functional methods of protocols and their processes, making all relevant events of a distributed system transparent. -To achieve this goal, a simulator was developed, particularly for teaching and learning purposes at the University of Applied Sciences Aachen. With the simulator, protocols from distributed systems with their most important influencing factors can be replicated through simulations. At the same time, there is ample room for personal experiments, with no restriction to a fixed number of protocols. It is therefore important that users are enabled to design their own protocols. +To achieve this, I developed a simulator, particularly for teaching and learning at the University of Applied Sciences Aachen. Protocols from distributed systems with their most important influencing factors can be replicated through simulations. At the same time, there's room for personal experiments—no restriction to a fixed number of protocols. Users can design their own. -The original simulator (VS-Sim) was written in Java 6 in 2008 with a German-language UI. In 2025, I revamped and modernized it as ds-sim: The entire codebase and UI were translated from German to English. The build system was migrated from hand-rolled Ant scripts to Maven. The Java baseline was upgraded from Java 6 to Java 21, adopting modern language features such as sealed class hierarchies, record types, formatted strings, and pattern matching. A proper exception hierarchy and consistent error handling were introduced. Comprehensive Javadoc documentation was added to all public APIs. A headless testing framework was implemented, bringing the project to 208 unit tests covering core components, the event system, and all protocol implementations. The project structure was reorganized to follow standard Maven conventions, and architecture documentation was added. In total, the modernization touched 199 files with over 15,000 lines of new code. Back in 2008, I wrote every single line by hand using the Vim editor. For the 2025 modernization, I could rely on Claude Code for most of the heavy lifting -- the translation, the refactoring, the test generation, the documentation. It is insane how times have changed. +The original simulator (VS-Sim) was written in Java 6 in 2008 with a German-language UI. In 2025, I revamped and modernized it as ds-sim: translated the entire codebase and UI from German to English, migrated the build system from hand-rolled Ant scripts to Maven, upgraded from Java 6 to Java 21 (adopting sealed class hierarchies, record types, formatted strings, pattern matching), introduced a proper exception hierarchy and consistent error handling, added comprehensive Javadoc documentation, implemented a headless testing framework (208 unit tests covering core components, the event system, and all protocol implementations), reorganized the project structure to follow standard Maven conventions, and added architecture documentation. Total: 199 files, over 15,000 lines of new code. Back in 2008, I wrote every line by hand in Vim. For the 2025 modernization, Claude Code did most of the heavy lifting—translation, refactoring, test generation, documentation. Times have changed. ## Installation diff --git a/gemfeed/DRAFT-f3s-kubernetes-with-freebsd-part-X.md b/gemfeed/DRAFT-f3s-kubernetes-with-freebsd-part-X.md index a0d22d4b..ca133c4a 100644 --- a/gemfeed/DRAFT-f3s-kubernetes-with-freebsd-part-X.md +++ b/gemfeed/DRAFT-f3s-kubernetes-with-freebsd-part-X.md @@ -46,19 +46,19 @@ This is part X of the f3s series for my self-hosting demands in a home lab. f3s? ## Introduction -In the previous posts, I deployed applications to the k3s cluster using Helm charts and Justfiles—running `just install` or `just upgrade` to imperatively push changes to the cluster. While this approach works, it has several drawbacks: +In previous posts, I deployed applications to the k3s cluster using Helm charts and Justfiles—running `just install` or `just upgrade` to imperatively push changes to the cluster. Works fine, but has some drawbacks: * No single source of truth: The cluster state depends on which commands were run and when * Manual synchronization: Every change requires manually running commands * Drift detection is hard: No easy way to know if cluster state matches the desired configuration -* Rollback complexity: Rolling back changes means re-running old Helm commands +* Rollback complexity: Rolling back means re-running old Helm commands * No audit trail: Hard to track who changed what and when -This blog post covers the migration from imperative Helm deployments to declarative GitOps using ArgoCD. After this migration, the Git repository becomes the single source of truth, and ArgoCD automatically ensures the cluster matches what's defined in Git. +This post covers migrating from imperative Helm deployments to declarative GitOps using ArgoCD. After this, the Git repository becomes the single source of truth, and ArgoCD automatically ensures the cluster matches what's defined in Git. ## What is GitOps? -GitOps is an operational framework that applies DevOps best practices—like version control, collaboration, and CI/CD—to infrastructure automation. The core idea is simple: the entire desired state of your infrastructure is stored in Git, and automated processes ensure the actual state matches the desired state. +GitOps is an operational framework that applies DevOps best practices—version control, collaboration, CI/CD—to infrastructure automation. The core idea: the entire desired state lives in Git, and automated processes ensure the actual state matches it. Key principles: diff --git a/gemfeed/DRAFT-ipv6test-deployment.md b/gemfeed/DRAFT-ipv6test-deployment.md index 290b0f07..dd266c5c 100644 --- a/gemfeed/DRAFT-ipv6test-deployment.md +++ b/gemfeed/DRAFT-ipv6test-deployment.md @@ -2,9 +2,9 @@ ## Introduction -This post covers deploying a simple IPv6/IPv4 connectivity test application to the f3s Kubernetes cluster. The application displays visitors' IP addresses and determines whether they're connecting via IPv6 or IPv4—useful for testing dual-stack connectivity. +Deploying a simple IPv6/IPv4 connectivity test application to the f3s Kubernetes cluster. It displays visitors' IP addresses and tells them whether they're connecting via IPv6 or IPv4—useful for testing dual-stack connectivity. -The interesting technical challenge was preserving the original client IP address through multiple reverse proxies: from the OpenBSD relayd frontends, through Traefik ingress, to the Apache CGI backend. +The interesting bit was preserving the original client IP address through multiple reverse proxies: from the OpenBSD relayd frontends, through Traefik ingress, to the Apache CGI backend. [f3s series](./2024-11-17-f3s-kubernetes-with-freebsd-part-1.md) |