From 1bdbc9b2d5237f705ec0bee48d848834a6e3722e Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sun, 31 Aug 2025 15:58:18 +0300 Subject: Update content for md --- about/showcase.md | 514 +++++++++++++++++-------------------- about/showcase/debroid/image-1.png | 38 +-- 2 files changed, 254 insertions(+), 298 deletions(-) diff --git a/about/showcase.md b/about/showcase.md index 3ea6ca12..a71d4922 100644 --- a/about/showcase.md +++ b/about/showcase.md @@ -10,68 +10,37 @@ This page showcases my side projects, providing an overview of what each project * [⇢ ⇢ Overall Statistics](#overall-statistics) * [⇢ ⇢ Projects](#projects) * [⇢ ⇢ ⇢ hexai](#hexai) -* [⇢ Hexai](#hexai) * [⇢ ⇢ ⇢ conf](#conf) * [⇢ ⇢ ⇢ rexfiles](#rexfiles) * [⇢ ⇢ ⇢ hxcode](#hxcode) -* [⇢ HxCode](#hxcode) * [⇢ ⇢ ⇢ totalrecall](#totalrecall) -* [⇢ totalrecall - Bulgarian Anki Flashcard Generator](#totalrecall---bulgarian-anki-flashcard-generator) * [⇢ ⇢ ⇢ gitsyncer](#gitsyncer) -* [⇢ GitSyncer](#gitsyncer) * [⇢ ⇢ ⇢ timr](#timr) -* [⇢ timr](#timr) * [⇢ ⇢ ⇢ tasksamurai](#tasksamurai) -* [⇢ Task Samurai](#task-samurai) * [⇢ ⇢ ⇢ ior](#ior) -* [⇢ I/O Riot NG (aka ior)](#io-riot-ng-aka-ior) * [⇢ ⇢ ⇢ dtail](#dtail) * [⇢ ⇢ ⇢ wireguardmeshgenerator](#wireguardmeshgenerator) -* [⇢ WireGuard Mesh Generator](#wireguard-mesh-generator) * [⇢ ⇢ ⇢ foostats](#foostats) -* [⇢ foostats](#foostats) * [⇢ ⇢ ⇢ ds-sim](#ds-sim) -* [⇢ DS-Sim](#ds-sim) * [⇢ ⇢ ⇢ sillybench](#sillybench) -* [⇢ Silly Benchmark](#silly-benchmark) * [⇢ ⇢ ⇢ gos](#gos) -* [⇢ Gos (Go Social Media)](#gos-go-social-media) * [⇢ ⇢ ⇢ rcm](#rcm) -* [⇢ rcm](#rcm) * [⇢ ⇢ ⇢ gemtexter](#gemtexter) * [⇢ ⇢ ⇢ docker-gpodder-sync-server](#docker-gpodder-sync-server) * [⇢ ⇢ ⇢ docker-radicale-server](#docker-radicale-server) * [⇢ ⇢ ⇢ quicklogger](#quicklogger) -* [⇢ Quick logger](#quick-logger) * [⇢ ⇢ ⇢ terraform](#terraform) -* [⇢ Terraform](#terraform) * [⇢ ⇢ ⇢ docker-anki-sync-server](#docker-anki-sync-server) * [⇢ ⇢ ⇢ gogios](#gogios) -* [⇢ Gogios](#gogios) * [⇢ ⇢ ⇢ gorum](#gorum) -* [⇢ Gorum](#gorum) * [⇢ ⇢ ⇢ guprecords](#guprecords) -* [⇢ guprecords - Global uptime records](#guprecords---global-uptime-records) * [⇢ ⇢ ⇢ randomjournalpage](#randomjournalpage) -* [⇢ Read a random journal](#read-a-random-journal) * [⇢ ⇢ ⇢ sway-autorotate](#sway-autorotate) -* [⇢ sway-autorotate](#sway-autorotate) * [⇢ ⇢ ⇢ algorithms](#algorithms) * [⇢ ⇢ ⇢ geheim](#geheim) -* [⇢ geheim.rb](#geheimrb) * [⇢ ⇢ ⇢ foo.zone](#foozone) * [⇢ ⇢ ⇢ perl-c-fibonacci](#perl-c-fibonacci) * [⇢ ⇢ ⇢ ioriot](#ioriot) -* [⇢ I/O Riot ](#io-riot) -* [⇢ ⇢ Overview ](#overview) -* [⇢ ⇢ Benefits ](#benefits) -* [⇢ Send in patches ](#send-in-patches) -* [⇢ How to install I/O Riot ](#how-to-install-io-riot) -* [⇢ How to use I/O Riot ](#how-to-use-io-riot) -* [⇢ Appendix ](#appendix) -* [⇢ ⇢ Supported file systems ](#supported-file-systems) -* [⇢ ⇢ Supported syscalls ](#supported-syscalls) -* [⇢ ⇢ Source code documentation ](#source-code-documentation) * [⇢ ⇢ ⇢ photoalbum](#photoalbum) * [⇢ ⇢ ⇢ staticfarm-apache-handlers](#staticfarm-apache-handlers) * [⇢ ⇢ ⇢ dyndns](#dyndns) @@ -104,9 +73,9 @@ This page showcases my side projects, providing an overview of what each project * 📦 Total Projects: 59 * 📊 Total Commits: 11,848 -* 📈 Total Lines of Code: 206,416 +* 📈 Total Lines of Code: 205,836 * 📄 Total Lines of Documentation: 23,246 -* 💻 Languages: Go (32.9%), Java (19.6%), Perl (8.5%), C++ (8.3%), C (8.2%), C/C++ (5.9%), Shell (3.5%), Config (1.9%), HTML (1.8%), Ruby (1.7%), YAML (1.6%), HCL (1.3%), JSON (0.9%), Python (0.8%), CSS (0.8%), Make (0.7%), Raku (0.4%), TOML (0.4%), XML (0.3%), Haskell (0.3%), TypeScript (0.2%) +* 💻 Languages: Go (32.9%), Java (19.7%), C++ (8.3%), Perl (8.3%), C (8.2%), C/C++ (5.9%), Shell (3.5%), Config (1.9%), HTML (1.8%), Ruby (1.7%), YAML (1.6%), HCL (1.3%), JSON (0.9%), Python (0.8%), CSS (0.8%), Make (0.7%), Raku (0.4%), TOML (0.4%), XML (0.3%), Haskell (0.3%), TypeScript (0.2%) * 📚 Documentation: Text (50.6%), Markdown (49.4%) * 🎵 Vibe-Coded Projects: 4 out of 59 (6.8%) * 🤖 AI-Assisted Projects (including vibe-coded): 9 out of 59 (15.3% AI-assisted, 84.7% human-only) @@ -119,7 +88,7 @@ This page showcases my side projects, providing an overview of what each project * 💻 Languages: Go (100.0%) * 📚 Documentation: Markdown (100.0%) * 📊 Commits: 103 -* 📈 Lines of Code: 5521 +* 📈 Lines of Code: 5479 * 📄 Lines of Documentation: 399 * 📅 Development Period: 2025-08-01 to 2025-08-29 * 🔥 Recent Activity: 8.1 days (avg. age of last 42 commits) @@ -130,7 +99,9 @@ This page showcases my side projects, providing an overview of what each project [![hexai screenshot](showcase/hexai/image-1.png "hexai screenshot")](showcase/hexai/image-1.png) -# Hexai +Hexai is an AI-powered extension designed to enhance the Helix Editor by integrating advanced code assistance features through Language Server Protocol (LSP) and large language models (LLMs). Its core capabilities include LSP-based code auto-completion, code actions, and an in-editor chat interface that allows users to interact directly with AI models for coding help and suggestions. Additionally, Hexai provides a standalone command-line tool for interacting with LLMs outside the editor. It supports multiple AI backends, including OpenAI, GitHub Copilot, and Ollama, making it flexible for various user preferences and workflows. + +The project is implemented primarily in Go and uses Mage as its build and task automation tool. The architecture consists of two main binaries: one for general LLM interaction and another for LSP integration with the editor. Hexai communicates with LLM providers via their APIs, relaying code context and user queries to generate intelligent responses or code completions. The modular design allows for easy configuration and extension, and while it is tailored for Helix, it may work with other editors that support LSP. This makes Hexai a valuable tool for developers seeking AI-assisted productivity directly within their coding environment. [View on Codeberg](https://codeberg.org/snonux/hexai) [View on GitHub](https://github.com/snonux/hexai) @@ -150,9 +121,9 @@ This page showcases my side projects, providing an overview of what each project * 🧪 Status: Experimental (no releases yet) -Certainly! However, the provided description ("Bapdidu di du di du dap dap dap!") does not contain any technical or contextual information about the "Jupdidu" project. To give a meaningful summary, I would need details such as the project's purpose, its main features, how it is implemented, and its architecture. +Certainly! However, the project description you provided for "Jupdidu" only contains a playful phrase ("Bapdidu di du di du dap dap dap!") and does not include any technical or functional details about the project itself. Without additional information—such as its purpose, features, or implementation details—it's not possible to summarize what the project does, why it's useful, or how it's architected. -If you can provide a README, project documentation, or a brief description of what Jupdidu does, I can summarize it clearly and concisely, focusing on its functionality, usefulness, and technical implementation. Please share more information or context about the project! +If you can provide a README, code snippet, or a more detailed description of "Jupdidu," I'd be happy to analyze it and provide a concise, informative summary focusing on its key features and architecture. Please share more context or documentation for a meaningful explanation. [View on Codeberg](https://codeberg.org/snonux/conf) [View on GitHub](https://github.com/snonux/conf) @@ -167,13 +138,14 @@ If you can provide a README, project documentation, or a brief description of wh * 📈 Lines of Code: 5715 * 📄 Lines of Documentation: 1183 * 📅 Development Period: 2021-12-28 to 2025-08-13 -* 🔥 Recent Activity: 22.6 days (avg. age of last 42 commits) +* 🔥 Recent Activity: 22.7 days (avg. age of last 42 commits) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) -Jupdidu -======= +Certainly! However, the provided project description ("Bapdidu di du di du dap dap dap!") does not contain any technical or descriptive information about the project "Jupdidu." To provide a meaningful summary, I would need details such as the project's purpose, main features, target users, and implementation approach. + +If you can share a README file, code snippets, or a more detailed description, I can analyze that information and deliver a concise, informative summary focusing on what the project does, its usefulness, and its key architectural features. Please provide more context or documentation for "Jupdidu," and I'll be happy to help! [View on Codeberg](https://codeberg.org/snonux/rexfiles) [View on GitHub](https://github.com/snonux/rexfiles) @@ -193,7 +165,9 @@ Jupdidu * 🧪 Status: Experimental (no releases yet) -# HxCode +The HxCode project provides seamless integration between the Helix text editor and Visual Studio Code (VSCode) through a set of extensions and plugins. Its primary goal is to enable users to leverage the advanced features and ecosystem of VSCode—such as language servers, debugging, and extensions—directly within the Helix editor, which is known for its modal editing and performance. This interoperability is particularly useful for developers who prefer Helix's editing model but require the rich tooling and language support available in VSCode. + +The project is organized into two main components: the ./hxcode directory contains the VSCode extension, which acts as a bridge to expose Helix's capabilities within the VSCode environment, while the ./helix directory provides the necessary integration hooks and configuration for Helix to communicate with VSCode services. The architecture relies on standardized protocols (such as the Language Server Protocol) and inter-process communication to synchronize features like code completion, diagnostics, and navigation between the two editors. This modular design makes it easy to maintain and extend, allowing users to benefit from the strengths of both platforms without sacrificing workflow efficiency. [View on Codeberg](https://codeberg.org/snonux/hxcode) [View on GitHub](https://github.com/snonux/hxcode) @@ -216,7 +190,13 @@ Jupdidu [![totalrecall screenshot](showcase/totalrecall/image-1.png "totalrecall screenshot")](showcase/totalrecall/image-1.png) -# totalrecall - Bulgarian Anki Flashcard Generator +**Summary of totalrecall - Bulgarian Anki Flashcard Generator** + +[![totalrecall screenshot](showcase/totalrecall/image-2.png "totalrecall screenshot")](showcase/totalrecall/image-2.png) + +`totalrecall` is a specialized tool designed to streamline the creation of Anki flashcards for Bulgarian vocabulary learners. It automates the generation of high-quality study materials—including audio pronunciations, AI-generated contextual images, phonetic transcriptions (IPA), and translations—by leveraging OpenAI’s TTS and DALL-E APIs. The tool supports both a fast, keyboard-driven graphical user interface (GUI) and a flexible command-line interface (CLI), making it accessible for users with different preferences. Key features include batch processing of word lists, randomization of voices and art styles for variety, and seamless export to Anki-compatible formats (APKG and CSV), ensuring that learners can quickly build rich, multimedia flashcard decks. + +Architecturally, totalrecall is implemented in Go and integrates with OpenAI services via API keys for audio and image generation. It processes input in various formats, automatically handling translation and media generation as needed. Output files—including MP3s, images, and Anki packages—are organized in a user’s local state directory, with configuration options for customization. The project’s modular design allows for easy installation, desktop integration (especially on GNOME/Fedora), and extensibility. By automating the most time-consuming aspects of flashcard creation and enhancing cards with multimedia and phonetic data, totalrecall significantly improves the efficiency and quality of language learning for Bulgarian. [View on Codeberg](https://codeberg.org/snonux/totalrecall) [View on GitHub](https://github.com/snonux/totalrecall) @@ -228,7 +208,7 @@ Jupdidu * 💻 Languages: Go (90.6%), Shell (7.8%), YAML (1.0%), JSON (0.7%) * 📚 Documentation: Markdown (100.0%) * 📊 Commits: 104 -* 📈 Lines of Code: 9605 +* 📈 Lines of Code: 9567 * 📄 Lines of Documentation: 2433 * 📅 Development Period: 2025-06-23 to 2025-08-19 * 🔥 Recent Activity: 44.9 days (avg. age of last 42 commits) @@ -237,7 +217,9 @@ Jupdidu * 🎵 Vibe-Coded: This project has been vibe coded -# GitSyncer +**GitSyncer** is an automation tool designed to synchronize git repositories across multiple organizations and hosting platforms, such as GitHub, Codeberg, and private SSH servers. Its primary purpose is to keep all branches and tags in sync between these platforms, ensuring that codebases remain consistent and up-to-date everywhere. GitSyncer is especially useful for developers and teams managing projects across different git hosts, providing features like automatic branch and repository creation, one-way backups to offline or private servers, and robust error handling for merge conflicts and missing resources. It also includes advanced capabilities like AI-powered project showcase generation, batch synchronization for automation, and flexible configuration for branch exclusions and backup strategies. + +The tool is implemented as a modern CLI application in Go, with a modular, command-based architecture. Users configure organizations, repositories, and backup locations via a JSON file, and interact with GitSyncer through intuitive commands (e.g., `gitsyncer sync`, `gitsyncer release create`). Under the hood, GitSyncer clones repositories, adds all remotes, fetches and merges branches, and pushes updates to all destinations, handling repository and branch creation as needed. SSH backup locations are supported for one-way, opt-in backups, with automatic bare repo initialization. The AI-powered showcase feature analyzes repositories and uses Claude or other AI tools to generate comprehensive project summaries and statistics. The architecture emphasizes automation, safety (never deleting branches), and extensibility, making GitSyncer a powerful solution for multi-platform git management and backup. [View on Codeberg](https://codeberg.org/snonux/gitsyncer) [View on GitHub](https://github.com/snonux/gitsyncer) @@ -258,7 +240,11 @@ Jupdidu * 🎵 Vibe-Coded: This project has been vibe coded -# timr +**Summary of the `timr` Project** + +`timr` is a lightweight, command-line time tracking tool designed to help users monitor the time they spend on tasks directly from their terminal. Its core functionality revolves around simple commands to start, stop, pause, reset, and check the status of a stopwatch-style timer, making it ideal for developers, freelancers, or anyone who prefers a minimalist workflow without the overhead of complex time-tracking applications. The tool also offers a live, full-screen timer mode with keyboard controls and can display the timer status in real-time within the fish shell prompt, enhancing productivity by keeping time tracking seamlessly integrated into the user's environment. + +From an architectural standpoint, `timr` is implemented in Go, ensuring cross-platform compatibility and efficient performance. The timer's state is persistently stored on the user's system, allowing for accurate tracking even across sessions. The command structure is straightforward, with subcommands for each primary action (`start`, `stop`, `status`, etc.), and the project includes shell integration scripts for fish to display timer status in the prompt. This combination of simplicity, persistence, and shell integration makes `timr` a practical and unobtrusive solution for time management at the command line. [View on Codeberg](https://codeberg.org/snonux/timr) [View on GitHub](https://github.com/snonux/timr) @@ -281,7 +267,11 @@ Jupdidu [![tasksamurai screenshot](showcase/tasksamurai/image-1.png "tasksamurai screenshot")](showcase/tasksamurai/image-1.png) -# Task Samurai +**Task Samurai** is a fast, keyboard-driven terminal interface for [Taskwarrior](https://taskwarrior.org/), designed to streamline task management directly from the command line. Built in Go using the [Bubble Tea](https://github.com/charmbracelet/bubbletea) TUI framework, it displays tasks in an interactive table and allows users to add, modify, and complete tasks efficiently using intuitive hotkeys. The interface is optimized for speed and responsiveness, offering a modern alternative to other Taskwarrior UIs like `vit`. + +[![tasksamurai screenshot](showcase/tasksamurai/image-2.png "tasksamurai screenshot")](showcase/tasksamurai/image-2.png) + +The core architecture leverages the Bubble Tea framework for rendering the terminal UI, while all task operations are performed by invoking the native `task` command-line tool. Each user action—such as adding or completing a task—triggers the corresponding Taskwarrior command, and the UI refreshes automatically to reflect changes. Key features include hotkey-driven task management, real-time updates, and support for all Taskwarrior filters and queries. Optional features like "disco mode" add visual flair by changing the theme after each task modification. Installation is straightforward via Go tooling, and the project is particularly useful for users who want a fast, fully keyboard-controlled Taskwarrior experience in the terminal. [View on Codeberg](https://codeberg.org/snonux/tasksamurai) [View on GitHub](https://github.com/snonux/tasksamurai) @@ -304,7 +294,11 @@ Jupdidu [![ior screenshot](showcase/ior/image-1.png "ior screenshot")](showcase/ior/image-1.png) -# I/O Riot NG (aka ior) +**I/O Riot NG (ior)** is a Linux-based tool designed to trace and analyze synchronous I/O system calls using BPF (Berkeley Packet Filter) technology. Its primary function is to monitor how long each synchronous I/O syscall takes, providing detailed timing information that can be visualized as flamegraphs. These flamegraphs help developers and system administrators identify performance bottlenecks in I/O operations, making it easier to optimize applications and systems. + +[![ior screenshot](showcase/ior/image-2.svg "ior screenshot")](showcase/ior/image-2.svg) + +The project is implemented using a combination of Go, C, and BPF, leveraging the `libbpfgo` library to interface with BPF from Go. Unlike its predecessor (which used SystemTap and C), I/O Riot NG offers a more modern and flexible architecture. The tool captures syscall events at the kernel level, processes the timing data in user space, and outputs results suitable for visualization with tools like Inferno Flamegraphs. Its architecture consists of BPF programs for efficient kernel tracing, a Go-based user-space component for data aggregation, and integration with third-party visualization tools. This makes I/O Riot NG a powerful and extensible solution for low-overhead, high-resolution I/O performance analysis on Linux systems. [View on Codeberg](https://codeberg.org/snonux/ior) [View on GitHub](https://github.com/snonux/ior) @@ -327,8 +321,11 @@ Jupdidu [![dtail screenshot](showcase/dtail/image-1.png "dtail screenshot")](showcase/dtail/image-1.png) -DTail -===== +DTail is an open-source distributed log management tool designed for DevOps engineers to efficiently tail, cat, and grep log files across thousands of servers simultaneously. Written in Go, it supports advanced features such as on-the-fly decompression (gzip, zstd) and distributed MapReduce-style aggregations, making it highly useful for large-scale log analysis and troubleshooting in complex environments. By leveraging SSH for secure communication and adhering to UNIX file permission models, DTail ensures both security and compatibility with existing infrastructure. + +[![dtail screenshot](showcase/dtail/image-2.gif "dtail screenshot")](showcase/dtail/image-2.gif) + +The architecture consists of a client-server model: DTail servers run on each target machine, while a DTail client—typically on an engineer’s workstation—connects to all servers concurrently to aggregate and process logs in real time. This design enables scalable, parallel log operations and can be extended to a serverless mode for added flexibility. DTail’s implementation emphasizes performance, security, and ease of use, making it a valuable tool for organizations needing to monitor and analyze distributed logs efficiently. [View on Codeberg](https://codeberg.org/snonux/dtail) [View on GitHub](https://github.com/snonux/dtail) @@ -348,7 +345,9 @@ DTail * 🏷️ Latest Release: v1.0.0 (2025-05-11) -# WireGuard Mesh Generator +The **WireGuard Mesh Generator** is a tool designed to automate the creation and deployment of WireGuard VPN configurations for a network of machines, forming a secure mesh network. This is particularly useful for system administrators or DevOps engineers who need to connect multiple servers or nodes (for example, in a Kubernetes cluster) with encrypted, peer-to-peer tunnels, ensuring secure and private communication across potentially untrusted networks. + +The project is implemented using Ruby, with tasks managed via Rake, and configuration defined in a YAML file (`wireguardmeshgenerator.yaml`). Key features include automated generation of WireGuard configuration files (`rake generate`), streamlined installation of these files to remote machines (`rake install`), and easy cleanup of generated artifacts (`rake clean`). The architecture leverages WireGuard’s lightweight VPN capabilities and Ruby’s scripting power to simplify and standardize the setup of complex mesh VPN topologies, reducing manual errors and saving time in multi-node deployments. [View on Codeberg](https://codeberg.org/snonux/wireguardmeshgenerator) [View on GitHub](https://github.com/snonux/wireguardmeshgenerator) @@ -368,7 +367,9 @@ DTail * 🏷️ Latest Release: v0.1.0 (2025-07-12) -# foostats +**foostats** is a privacy-focused web analytics tool designed specifically for OpenBSD environments, with support for both traditional web (HTTP/HTTPS) and Gemini protocol logs. Its primary function is to generate anonymous, comprehensive site statistics for the foo.zone ecosystem and similar sites, while strictly preserving visitor privacy. This is achieved by hashing all IP addresses with SHA3-512 before storage, ensuring no personally identifiable information is retained. The tool provides detailed daily, monthly, and summary reports in Gemtext format, tracks feed subscribers, and includes robust filtering to block and log suspicious requests based on configurable patterns. + +Architecturally, foostats is modular, with components for log parsing, filtering, aggregation, replication, and reporting. It processes logs from OpenBSD httpd and Gemini servers (vger/relayd), aggregates statistics, and outputs compressed JSON files and human-readable reports. Its distributed design allows replication and merging of stats across multiple nodes, supporting comprehensive analytics for federated sites. Key features include multi-protocol and IPv4/IPv6 support, privacy-first data handling, and flexible configuration for filtering and reporting, making it a secure and privacy-respecting alternative to conventional analytics platforms. [View on Codeberg](https://codeberg.org/snonux/foostats) [View on GitHub](https://github.com/snonux/foostats) @@ -391,7 +392,9 @@ DTail [![ds-sim screenshot](showcase/ds-sim/image-1.png "ds-sim screenshot")](showcase/ds-sim/image-1.png) -# DS-Sim +DS-Sim is an open-source Java-based simulator designed for modeling and experimenting with distributed systems. It provides a robust environment for simulating distributed protocols, handling events, and visualizing system behavior through an interactive Swing GUI. Key features include support for simulating core distributed algorithms (such as Lamport clocks, vector clocks, PingPong, Two-Phase Commit, and Berkeley Time), comprehensive event handling, and detailed logging. DS-Sim is particularly useful for students, educators, and developers who want to learn about or prototype distributed systems concepts in a controlled, observable setting. + +Architecturally, DS-Sim is organized into modular components: core process and message handling, an extensible event system, protocol implementations, and a main simulation engine. The project uses Maven for build automation and dependency management, and includes a thorough suite of unit tests and a dedicated protocol simulation testing framework. Users can quickly build and run the simulator via Maven commands, and the project structure is well-documented to support both usage and extension. This modular, test-driven approach makes DS-Sim both a practical teaching tool and a flexible platform for distributed systems research and development. [View on Codeberg](https://codeberg.org/snonux/ds-sim) [View on GitHub](https://github.com/snonux/ds-sim) @@ -411,7 +414,9 @@ DTail * 🧪 Status: Experimental (no releases yet) -# Silly Benchmark +The **Silly Benchmark** project is a simple benchmarking tool designed to compare the performance of code execution between a native FreeBSD system and a Linux virtual machine running under Bhyve (the FreeBSD hypervisor). Its primary purpose is to provide a straightforward, reproducible way to measure and contrast the computational speed or efficiency of these two environments. This can help users or system administrators understand the performance impact of virtualization and the differences between operating systems when running the same workload. + +Implementation-wise, the project likely consists of a small, easily portable program—often written in C or a scripting language—that performs a set of computational tasks or loops, measuring the time taken to complete them. The key features include its simplicity, ease of use, and focus on raw execution speed rather than complex benchmarking scenarios. The architecture is minimal: the benchmark is run natively on FreeBSD and then inside a Linux VM managed by Bhyve, with results compared to highlight any performance discrepancies attributable to the OS or virtualization overhead. This approach is useful for system tuning, hardware evaluation, or making informed decisions about deployment environments. [View on Codeberg](https://codeberg.org/snonux/sillybench) [View on GitHub](https://github.com/snonux/sillybench) @@ -433,7 +438,11 @@ DTail [![gos screenshot](showcase/gos/image-1.png "gos screenshot")](showcase/gos/image-1.png) -# Gos (Go Social Media) +**Gos (Go Social Media)** is a command-line tool written in Go that serves as a self-hosted, scriptable alternative to Buffer.com for scheduling and managing social media posts. Designed for users who prefer automation, privacy, and control, Gos enables posting to Mastodon and LinkedIn (with OAuth2 authentication for LinkedIn) directly from the terminal. It supports features like dry-run mode for safe testing, flexible configuration via flags and environment variables, image previews for LinkedIn, and a pseudo-platform ("Noop") for tracking posts without publishing. Gos is particularly useful for developers, power users, or anyone who wants to automate their social media workflow, avoid third-party service limitations, and integrate posting into their own scripts or shell startup routines. + +[![gos screenshot](showcase/gos/image-2.png "gos screenshot")](showcase/gos/image-2.png) + +**Architecturally**, Gos operates on a file-based queueing system: users compose posts as text files (optionally using the companion `gosc` composer tool) in a designated directory. Posts are tagged via filenames or inline tags to control target platforms, priorities, and behaviors (e.g., immediate posting, pausing, or requiring confirmation). When Gos runs, it processes these files, moves them through platform-specific queues, and posts them according to user-defined cadence, priorities, and pause intervals. The configuration is managed via a JSON file storing API credentials and scheduling preferences. Gos also supports generating Gemini Gemtext summaries of posted content for blogging or archival purposes. The system is highly scriptable, easy to integrate into automated workflows, and can be synced or backed up using tools like Syncthing, making it a robust, extensible solution for personal or small-team social media management. [View on Codeberg](https://codeberg.org/snonux/gos) [View on GitHub](https://github.com/snonux/gos) @@ -448,12 +457,14 @@ DTail * 📈 Lines of Code: 1373 * 📄 Lines of Documentation: 48 * 📅 Development Period: 2024-12-05 to 2025-02-28 -* 🔥 Recent Activity: 191.3 days (avg. age of last 42 commits) +* 🔥 Recent Activity: 191.4 days (avg. age of last 42 commits) * ⚖️ License: Custom License * 🧪 Status: Experimental (no releases yet) -# rcm +The **rcm** project is a lightweight, personal Ruby-based configuration management system designed with the KISS (Keep It Simple, Stupid) principle in mind. Its primary purpose is to automate and manage configuration tasks, such as setting up services or environments, in a straightforward and minimalistic way. This makes it especially useful for users who want a simple, customizable tool for managing their own system configurations without the overhead and complexity of larger solutions like Ansible or Chef. + +Key features include a test suite (run via `rake test`) to ensure reliability, and a task-based invocation system using Rake, Ruby's build automation tool. Users can execute specific configuration tasks (e.g., `rake wireguard -- --debug`) from within a project directory, allowing for modular and scriptable management of services. The architecture leverages Ruby and Rake for task definition and execution, keeping dependencies minimal and the codebase easy to understand and extend for personal workflows. [View on Codeberg](https://codeberg.org/snonux/rcm) [View on GitHub](https://github.com/snonux/rcm) @@ -473,8 +484,11 @@ DTail * 🏷️ Latest Release: 3.0.0 (2024-10-01) -The Gemtexter blog engine and static site generator -=================================================== +**Summary of the Gemtexter Project** + +Gemtexter is a static site generator and blog engine designed to manage and publish content written in the Gemini Gemtext format, a lightweight markup language used in the Gemini protocol. Its key feature is the ability to convert Gemtext source files into multiple static output formats—specifically Gemini Gemtext, XHTML (HTML), and Markdown—without relying on JavaScript. This enables the same content to be served across different platforms, including Gemini capsules, traditional web pages, and code hosting services like Codeberg and GitHub Pages. Gemtexter also supports Atom feed generation, source code syntax highlighting, theming, and advanced templating, making it a versatile tool for technical bloggers and those interested in multi-platform publishing. + +The project is implemented as a large Bash script, leveraging standard GNU utilities (sed, grep, date, etc.) for text processing and file management. Content is organized in a configurable directory structure, with separate folders for each output format. The script automates tasks such as content conversion, Atom feed updates, and Git integration for version control and deployment. Advanced features include content filtering for selective regeneration, customizable themes, Bash-based templating for dynamic content generation, and support for source code highlighting via GNU Source Highlight. Configuration is flexible, supporting both local and user-specific config files, and the system is designed to be extensible and maintainable despite being written in Bash. This architecture makes Gemtexter particularly useful for users who value simplicity, transparency, and control over their publishing workflow, especially in environments where minimalism and static content are preferred. [View on Codeberg](https://codeberg.org/snonux/gemtexter) [View on GitHub](https://github.com/snonux/gemtexter) @@ -494,9 +508,9 @@ The Gemtexter blog engine and static site generator * 🧪 Status: Experimental (no releases yet) -This project provides a Dockerized build environment for the GPodder sync server, specifically targeting the [mygpo](https://github.com/gpodder/mygpo) backend. The GPodder sync server enables users to synchronize podcast subscriptions and playback progress across multiple devices and clients, making it easier to keep listening experiences consistent. By containerizing the server with Docker, the project simplifies deployment and management, ensuring that all dependencies and configurations are encapsulated and reproducible. +This project provides a Docker-based deployment solution for the GPodder sync server, specifically targeting the open-source [mygpo](https://github.com/gpodder/mygpo) backend. GPodder is a popular podcast manager, and the sync server enables users to synchronize their podcast subscriptions, episode progress, and device data across multiple clients and devices. By containerizing the sync server with Docker, this project simplifies installation, configuration, and maintenance, making it easy to run the service in a consistent and isolated environment regardless of the host system. -The implementation centers around a Dockerfile and related configuration files that automate the setup of the mygpo server, including its Python dependencies and any required services (such as a database). Key features include ease of deployment (just a few Docker commands to get started), isolation from the host system, and portability across different environments. The architecture leverages Docker’s layered image system to build, run, and update the GPodder sync server efficiently, making it accessible for both development and production use. +The implementation leverages Docker to encapsulate all dependencies and runtime requirements of the mygpo server. The provided Dockerfile and configuration scripts automate the setup process, including installing necessary Python packages, configuring the database, and exposing the appropriate network ports. This architecture enables rapid deployment, scalability, and straightforward updates, while also supporting best practices for security and resource management. Key features include reproducible builds, environment variable configuration, and compatibility with orchestration tools like Docker Compose, making it a practical solution for both personal and small-scale public GPodder sync services. [View on Codeberg](https://codeberg.org/snonux/docker-gpodder-sync-server) [View on GitHub](https://github.com/snonux/docker-gpodder-sync-server) @@ -511,14 +525,14 @@ The implementation centers around a Dockerfile and related configuration files t * 📈 Lines of Code: 40 * 📄 Lines of Documentation: 3 * 📅 Development Period: 2023-12-31 to 2025-08-11 -* 🔥 Recent Activity: 490.9 days (avg. age of last 42 commits) +* 🔥 Recent Activity: 491.0 days (avg. age of last 42 commits) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) -This project provides a Docker image for the [Radicale server](https://radicale.org), an open-source CalDAV and CardDAV server for managing calendars and contacts. By containerizing Radicale, the project makes it easy to deploy and run the server in isolated, reproducible environments, simplifying installation and upgrades. Users can quickly set up a personal or small-team calendar/contact server without worrying about system dependencies or manual configuration. +This project provides a Docker image for the [Radicale server](https://radicale.org), an open-source CalDAV and CardDAV server for managing calendars and contacts. By containerizing Radicale, the project makes it easy to deploy and run the server in isolated, reproducible environments, ensuring consistent behavior across different systems. This is particularly useful for users who want to quickly set up personal or small-team calendar/contact synchronization without complex installation steps or dependency management. -The Docker image is built to be lightweight and configurable, exposing necessary ports and allowing persistent storage of data via Docker volumes. The architecture typically involves a Dockerfile that installs Radicale and its dependencies, sets up configuration files, and defines entrypoints for running the server. This approach ensures portability, consistency across environments, and ease of integration with orchestration tools like Docker Compose or Kubernetes. Key features include simplified deployment, secure isolation, and support for custom configuration through environment variables or mounted files. +The Docker image is typically implemented using a `Dockerfile` that installs Radicale and its dependencies into a minimal base image, exposes the necessary ports, and defines configuration options via environment variables or mounted volumes. Key features include ease of deployment, portability, and simplified updates—users can start a Radicale server with a single `docker run` command, mount their data/configuration for persistence, and benefit from Docker’s security and resource isolation. The architecture leverages Docker’s containerization to encapsulate Radicale, making it suitable for both development and production use. [View on Codeberg](https://codeberg.org/snonux/docker-radicale-server) [View on GitHub](https://github.com/snonux/docker-radicale-server) @@ -540,7 +554,11 @@ The Docker image is built to be lightweight and configurable, exposing necessary [![quicklogger screenshot](showcase/quicklogger/image-1.png "quicklogger screenshot")](showcase/quicklogger/image-1.png) -# Quick logger +Quick Logger is a lightweight graphical application designed for quickly capturing and saving ideas or notes as plain text files, primarily targeting Android devices but also runnable on Linux desktops. Built with the Go programming language and the Fyne GUI framework, the app provides a simple interface where users can enter a message, which is then saved to a designated folder. This folder can be synchronized across devices using tools like Syncthing, ensuring that notes taken on a mobile device are automatically available on a home computer. + +[![quicklogger screenshot](showcase/quicklogger/image-2.png "quicklogger screenshot")](showcase/quicklogger/image-2.png) + +The project’s key features include its minimalistic design, cross-platform compatibility (Android and Linux), and seamless integration with file synchronization workflows. Architecturally, Quick Logger leverages Fyne for its user interface, enabling a consistent look and feel across platforms, and uses Go’s standard library for file operations. The build process supports both direct compilation and containerized cross-compilation (using fyne-cross and Podman/Docker), making it accessible to developers on different systems. This combination of simplicity, portability, and easy synchronization makes Quick Logger a practical tool for quickly jotting down ideas on the go. [View on Codeberg](https://codeberg.org/snonux/quicklogger) [View on GitHub](https://github.com/snonux/quicklogger) @@ -560,7 +578,9 @@ The Docker image is built to be lightweight and configurable, exposing necessary * 🧪 Status: Experimental (no releases yet) -# Terraform +This project is a Terraform-based infrastructure-as-code setup designed to automate the deployment and management of a cloud environment on AWS. Its primary goal is to provision and configure core AWS resources—such as VPCs, subnets, EFS (Elastic File System), ECS (Elastic Container Service) with Fargate, and Application Load Balancers—while also integrating essential operational features like CloudWatch monitoring and EFS backups. The project is modular, with separate Terraform modules or directories (e.g., `org-buetow-base`, `org-buetow-bastion`, `org-buetow-elb`, `org-buetow-ecs`) handling different aspects of the infrastructure, promoting reusability and maintainability. + +Key features include the ability to specify which ECS services to deploy, automated creation of networking and storage resources, and integration with AWS Secrets Manager for secure credential handling. Some steps, such as creating DNS zones, TLS certificates, and certain EFS subdirectories, are performed manually to ensure security and compliance with organizational policies. The architecture leverages a bastion host for secure EFS management, and uses AWS-native services for high availability and scalability. CloudWatch monitoring with email alerts (planned) will enhance operational visibility. Overall, this project streamlines the deployment of containerized applications on AWS, making it easier to manage complex environments with infrastructure as code. [View on Codeberg](https://codeberg.org/snonux/terraform) [View on GitHub](https://github.com/snonux/terraform) @@ -580,9 +600,9 @@ The Docker image is built to be lightweight and configurable, exposing necessary * 🧪 Status: Experimental (no releases yet) -The **docker-anki-sync-server** project provides a Docker image for running an Anki sync server, which enables users to synchronize their Anki flashcard collections across multiple devices without relying on AnkiWeb. This is particularly useful for individuals or organizations who want to maintain control over their data, improve privacy, or operate in environments with restricted internet access. By containerizing the sync server, the project simplifies deployment, making it easy to set up a consistent and isolated environment on any system that supports Docker. +The **docker-anki-sync-server** project provides a Dockerized solution for running an Anki sync server, which enables users to synchronize their Anki flashcard collections across multiple devices. This is particularly useful for individuals or organizations who want to host their own private Anki synchronization service instead of relying on AnkiWeb, offering greater control over data privacy and server customization. By packaging the sync server within a Docker image, the project simplifies deployment, making it easy to set up and run the server on any system that supports Docker, regardless of the underlying operating system. -The implementation centers around creating a Docker image that packages the official Anki sync server along with its dependencies. The Dockerfile automates the installation and configuration process, exposing necessary ports and allowing for environment variable customization. Users can launch the server with a single command, and it integrates seamlessly with Anki clients by specifying the custom sync server URL. The architecture leverages Docker’s portability and isolation, ensuring that updates, scaling, and maintenance are straightforward and reproducible. +The implementation centers around a Dockerfile that builds an image containing all necessary dependencies and the Anki sync server software. Key features include portability, reproducibility, and ease of maintenance—users can deploy updates or migrate the server with minimal effort. The architecture typically involves exposing the sync server on a configurable network port, allowing Anki clients to connect and synchronize their data. This approach abstracts away complex environment setup, letting users focus on managing their Anki data rather than server configuration. [View on Codeberg](https://codeberg.org/snonux/docker-anki-sync-server) [View on GitHub](https://github.com/snonux/docker-anki-sync-server) @@ -605,7 +625,9 @@ The implementation centers around creating a Docker image that packages the offi [![gogios screenshot](showcase/gogios/image-1.png "gogios screenshot")](showcase/gogios/image-1.png) -# Gogios +Gogios is a lightweight, minimalistic server monitoring tool designed for small-scale, self-hosted environments—such as personal servers or a handful of virtual machines—where simplicity and low resource usage are priorities. Unlike more complex solutions like Nagios or Prometheus, Gogios focuses on essential monitoring: it periodically runs standard Nagios/Icinga-compatible plugins to check system health and sends concise email notifications when the status of any monitored service changes. This makes it ideal for users who want straightforward, email-based alerts without the overhead of web interfaces, databases, or advanced clustering features. + +Architecturally, Gogios is implemented in Go for efficiency and ease of deployment. It uses a JSON configuration file to define which checks to run, their dependencies, retry logic, and notification settings. Checks are executed as external scripts (Nagios plugins), and results are tracked in a persistent state file to ensure notifications are only sent on status changes. Email notifications are handled via a local Mail Transfer Agent (MTA), and the tool is typically run as a scheduled CRON job under a dedicated system user for security. High-availability can be achieved by deploying Gogios on multiple servers with staggered schedules, though this results in duplicate notifications by design. Overall, Gogios is useful for users seeking a no-frills, reliable monitoring solution that is easy to install, configure, and maintain for small infrastructures. [View on Codeberg](https://codeberg.org/snonux/gogios) [View on GitHub](https://github.com/snonux/gogios) @@ -626,7 +648,9 @@ The implementation centers around creating a Docker image that packages the offi ⚠️ **Notice**: This project appears to be finished, obsolete, or no longer maintained. Last meaningful activity was over 2 years ago. Use at your own risk. -# Gorum +Gorum is a minimalistic quorum manager designed to coordinate and manage quorum-based operations, typically used in distributed systems to ensure consensus and reliability. Its primary function is to oversee the execution of checks or tasks across multiple nodes, ensuring that a specified minimum number (a quorum) agree or complete the task before proceeding. This is particularly useful in scenarios where fault tolerance and consistency are critical, such as distributed databases or clustered services. + +The project is still under development, but its planned features include remote execution control—allowing users to trigger and monitor quorum checks on remote systems. The architecture is likely lightweight, focusing on simplicity and ease of integration rather than complex orchestration. Key features will revolve around managing quorum thresholds, tracking node responses, and providing a minimal interface for triggering and observing quorum checks. This approach makes Gorum useful for developers and operators who need a straightforward tool to add quorum-based decision-making to their distributed applications or infrastructure. [View on Codeberg](https://codeberg.org/snonux/gorum) [View on GitHub](https://github.com/snonux/gorum) @@ -646,7 +670,9 @@ The implementation centers around creating a Docker image that packages the offi * 🏷️ Latest Release: v1.0.0 (2023-04-29) -# guprecords - Global uptime records +`guprecords` is a command-line tool written in Raku that generates comprehensive uptime reports for multiple hosts by aggregating and analyzing raw record files produced by the `uptimed` daemon. Its primary purpose is to provide system administrators and enthusiasts with detailed, customizable statistics on system reliability and availability across a fleet of machines. By supporting various categories (such as Host, Kernel, KernelMajor, and KernelName) and metrics (including Boots, Uptime, Score, Downtime, and Lifespan), `guprecords` enables users to identify trends, compare system stability, and track performance over time. Reports can be output in plaintext, Markdown, or Gemtext formats, making them suitable for different documentation or publishing needs. + +The architecture of `guprecords` is modular, with classes dedicated to parsing epoch data, aggregating statistics, and formatting output. The tool reads uptime record files collected from multiple hosts (typically centralized via a git repository), processes them to compute the desired metrics, and generates ranked tables highlighting top performers or outliers. Users can tailor reports using command-line options to select categories, metrics, output formats, and entry limits. The design emphasizes flexibility and extensibility, allowing for easy integration into existing monitoring workflows. While `guprecords` does not handle the collection of raw data itself, it complements existing `uptimed` deployments by transforming raw uptime logs into actionable insights and historical records. [View on Codeberg](https://codeberg.org/snonux/guprecords) [View on GitHub](https://github.com/snonux/guprecords) @@ -667,7 +693,9 @@ The implementation centers around creating a Docker image that packages the offi ⚠️ **Notice**: This project appears to be finished, obsolete, or no longer maintained. Last meaningful activity was over 2 years ago. Use at your own risk. -# Read a random journal +This project is a personal script designed to help the user revisit past thoughts and ideas by randomly selecting and displaying pages from their collection of scanned bullet journal PDFs. By running the script, the user can reflect on previous journal entries, book notes, and spontaneous ideas, fostering self-reflection and inspiration. The script automates the process of choosing a random journal file and a random set of pages within it, making the experience effortless and serendipitous. + +The implementation relies on standard Linux utilities: `qpdf` for manipulating PDF files and `pdfinfo` (from `poppler-utils`) for extracting metadata such as page counts. The user configures the script with the path to their journal PDFs and their preferred PDF viewer. When executed, the script randomly selects a PDF and extracts a random range of pages, which are then opened for viewing. The architecture is intentionally simple, leveraging shell scripting for automation and requiring minimal setup, making it a lightweight and practical tool for personal knowledge management. [View on Codeberg](https://codeberg.org/snonux/randomjournalpage) [View on GitHub](https://github.com/snonux/randomjournalpage) @@ -682,12 +710,14 @@ The implementation centers around creating a Docker image that packages the offi * 📈 Lines of Code: 41 * 📄 Lines of Documentation: 17 * 📅 Development Period: 2020-01-30 to 2025-04-30 -* 🔥 Recent Activity: 1112.3 days (avg. age of last 42 commits) +* 🔥 Recent Activity: 1112.4 days (avg. age of last 42 commits) * ⚖️ License: GPL-3.0 * 🧪 Status: Experimental (no releases yet) -# sway-autorotate +**sway-autorotate** is a Bash script designed to automatically rotate the display orientation in the Sway window manager, particularly useful for convertible laptops and tablets like the Microsoft Surface Go 2 running Fedora Linux. The script listens for orientation changes from the device's built-in sensors (using the `monitor-sensor` command from the `iio-sensor-proxy` package) and then issues commands to Sway to rotate both the screen and relevant input devices accordingly. This ensures that the display and touch input remain aligned with the physical orientation of the device, providing a seamless experience when switching between portrait and landscape modes. + +The script is implemented by piping the output of `monitor-sensor` into `autorotate.sh`, which parses sensor events and uses `swaymsg` to adjust the display and input device orientations. The devices to be rotated are specified in the `WAYLANDINPUT` array, which can be populated by querying available input devices with `swaymsg -t get_inputs`. This approach leverages existing Linux utilities and Sway's IPC interface, making it lightweight and easily adaptable to different hardware setups. The project is particularly useful for users who need automatic screen rotation on devices running Sway, where such functionality is not provided out-of-the-box. [View on Codeberg](https://codeberg.org/snonux/sway-autorotate) [View on GitHub](https://github.com/snonux/sway-autorotate) @@ -708,9 +738,9 @@ The implementation centers around creating a Docker image that packages the offi ⚠️ **Notice**: This project appears to be finished, obsolete, or no longer maintained. Last meaningful activity was over 2 years ago. Use at your own risk. -This project is a collection of exercises and implementations based on an Algorithms lecture, designed primarily as a refresher for fundamental algorithmic concepts. It provides a structured environment for practicing and testing various algorithms, making it useful for students or professionals looking to reinforce their understanding of algorithm design and analysis. The project includes both unit tests and benchmarking capabilities, allowing users to verify correctness and measure the performance of their solutions. +This project is a collection of exercises and implementations based on an Algorithms lecture, designed primarily as a refresher for key algorithmic concepts. It provides a hands-on environment for practicing and reinforcing understanding of fundamental algorithms, such as sorting, searching, and possibly data structures, through practical coding exercises. The project is structured to facilitate both learning and assessment, featuring built-in unit tests to verify correctness and benchmarking tools to evaluate performance. -The architecture is straightforward: algorithm implementations are organized in source files, with accompanying test suites to ensure reliability. The use of Makefile commands (e.g., make test and make bench) streamlines the process of running tests and benchmarks, promoting good development practices. This setup encourages iterative development and performance tuning, making the project both educational and practical for algorithm study and review. +Key features include a modular codebase where each algorithm or exercise is likely implemented in its own file or module, making it easy to navigate and extend. The use of Makefile commands (make test and make bench) streamlines the workflow: make test runs automated unit tests to ensure the algorithms work as expected, while make bench executes performance benchmarks to compare efficiency. This architecture supports iterative development and experimentation, making the project useful for students, educators, or anyone looking to refresh their algorithm skills in a practical, test-driven manner. [View on Codeberg](https://codeberg.org/snonux/algorithms) [View on GitHub](https://github.com/snonux/algorithms) @@ -730,7 +760,13 @@ The architecture is straightforward: algorithm implementations are organized in * 🧪 Status: Experimental (no releases yet) -# geheim.rb +**Summary of the Project:** + +The `geheim.rb` project is a Ruby-based tool designed for secure encryption and management of text and binary documents. It leverages the AES-256-CBC encryption algorithm, with initialization vectors derived from a user-supplied PIN, ensuring strong cryptographic protection. The tool is cross-platform, running on macOS, Linux, and Android (via Termux), and is particularly suited for handling smaller files such as text documents and PDFs. A key feature is its integration with Git: all encrypted files and their (also encrypted) filenames are stored in a Git repository, allowing users to version, backup, and synchronize their secure data across multiple remote locations for redundancy. + +**Key Features and Architecture:** + +The architecture centers around a local Git repository that acts as the secure storage backend. File encryption and decryption are handled by the Ruby script, which also manages encrypted indices for filenames, making it possible to search for documents using `fzf`, a fuzzy finder tool. Editing is streamlined through NeoVim, with safety measures like disabled caching and swapping to prevent data leaks. The script supports clipboard operations on macOS and GNOME, provides an interactive shell for user commands, and includes batch import/export as well as secure shredding of exported data. This combination of strong encryption, Git-based storage, and user-friendly search and editing makes `geheim.rb` a practical solution for individuals seeking portable, encrypted document management with robust redundancy and usability features. [View on Codeberg](https://codeberg.org/snonux/geheim) [View on GitHub](https://github.com/snonux/geheim) @@ -750,8 +786,9 @@ The architecture is straightforward: algorithm implementations are organized in ⚠️ **Notice**: This project appears to be finished, obsolete, or no longer maintained. Last meaningful activity was over 2 years ago. Use at your own risk. -The foo.zone internet site -=========================== +This project hosts the static files for the foo.zone website, which is accessible via both the Gemini protocol (gemini://foo.zone) and the web (https://foo.zone). The repository is organized with separate branches for each content format—such as Gemtext, HTML, and Markdown—allowing the site to be served in multiple formats tailored to different protocols and user preferences. This structure makes it easy to maintain and update content across platforms, ensuring consistency and flexibility. + +The site is maintained using a suite of open-source tools, including Neovim for editing, GNU Bash for scripting, and ShellCheck for shell script linting. It is deployed on OpenBSD, utilizing the vger Gemini server (managed via relayd and inetd) for Gemini content and the native httpd server for the HTML site. Source code and hosting are managed through Codeberg. The static content is generated with the help of the gemtexter tool, which streamlines the process of converting and managing content in various formats. This architecture emphasizes simplicity, security, and portability, making it a robust solution for multi-protocol static site hosting. [View on Codeberg](https://codeberg.org/snonux/foo.zone) [View on GitHub](https://github.com/snonux/foo.zone) @@ -787,7 +824,7 @@ perl-c-fibonacci: source code repository. * 📈 Lines of Code: 12420 * 📄 Lines of Documentation: 610 * 📅 Development Period: 2018-03-01 to 2020-01-22 -* 🔥 Recent Activity: 2505.5 days (avg. age of last 42 commits) +* 🔥 Recent Activity: 2505.6 days (avg. age of last 42 commits) * ⚖️ License: Apache-2.0 * 🏷️ Latest Release: 0.5.1 (2019-01-04) @@ -795,147 +832,9 @@ perl-c-fibonacci: source code repository. [![ioriot screenshot](showcase/ioriot/image-1.png "ioriot screenshot")](showcase/ioriot/image-1.png) -# I/O Riot - -## Overview - - - -...is an I/O benchmarking tool for Linux based operating systems which captures I/O operations on a (possibly production) server in order to replay the exact same I/O operations on a load test machine. - -I/O Riot is operated in 5 steps: - -1. Capture: Record all I/O operations over a given period of time to a capture log. -2. Initialize: Copy the log to a load test machine and initialize the load test environment. -3. Replay: Drop all OS caches and replay all I/O operations. -4. Analyze: Look at the OS and hardware stats (throughput, I/O ops, load average) from the run phase and draw conclusions. The aim is to identify possible I/O bottlenecks. -5. Repeat: Repeat steps 2-4 multiple times but adjust OS and hardware settings in order to improve I/O performance. - -Examples of OS and hardware settings and adjustments: - -* Change of system parameters (file system mount options, file system caching, file system type, file system creation flags). -* Replay the I/O at different speed(s). -* Replay the I/O with modified pattern(s) (e.g. remove reads from the replay journal). -* Replay the I/O on different types of hardware. - -The file system fragmentation (depending on the file system type and utilisation) might affect I/O performance as well. Therefore, replaying the I/O will not give the exact same result as on a production system. But it provides a pretty good way to determine I/O bottlenecks. As a rule of thumb file system fragmentation will not be an issue, unless the file system begins to fill up. Modern file systems (such as Ext4) will slowly start to suffer from fragmentation and slow down then. - -## Benefits - -In contrast to traditional I/O benchmarking tools, I/O Riot reproduces real production I/O, and does not rely on a pre-defined set of I/O operations. - -Also, I/O Riot only requires a server machine for capturing and another server machine for replaying. A traditional load test environment would usually be a distributed system which can consist of many components and machines. Such a distributed system can become quite complex which makes it difficult to isolate possible I/O bottlenecks. For example in order to trigger I/O events a client application would usually have to call a remote server application. The remote server application itself would query a database and the database would trigger the actual I/O operations in Linux. Furthermore, it is not easy to switch forth and back between hardware and OS settings. For example without a backup and restore procedure a database would most likely be corrupt after reformatting the data partitions with a different file system type. - -The benefits of I/O Riot are: - -* It is easy to determine whether a new hardware type is suitable for an already existing application. -* It is easy to change OS and hardware for performance tests and optimizations. -* Findings can be applied to production machines in order to optimize OS configuration and to save hardware costs. -* Benchmarks are based on production I/O patterns and not on artificial I/O patterns. -* Log files can be modified to see whether a change in the application behavior would improve I/O performance (without actually touching the application code) -* Log files could be generated synthetically in order to find out how a new application would perform (even if there isn't any code for the new application yet) -* It identifies possible flaws in the applications (e.g. Java programs which produce I/O operations on the server machines). Findings can be reported to the corresponding developers so that changes can be introduced to improve the applications I/O performance. -* It captures I/O in Linux Kernel space (very efficient, no system slowdowns even under heavy I/O load) -* It replays I/O via a tool developed in C with as little overhead as possible. - -# Send in patches - -Patches of any kind (bug fixes, new features...) are welcome! I/O Riot is new software and not everything might be perfect yet. Also, I/O Riot is used for a very specific use case at Mimecast. It may need tuning or extension for your use case. It will grow and mature over time. - -This is also potentially a great tool just for analysing (not replaying) the I/O, therefore it would be a great opportunity to add more features related to that (e.g. more stats, filters, etc.). - -Future work will also include file hole support and I/O support for memory mapped files. - -# How to install I/O Riot - -I/O Riot depends on SystemTap and a compatible version of the Linux Kernel. To get started have a read through the [installation guide](doc/markdown/installation.md). - -# How to use I/O Riot - -Check out the [I/O Riot usage guide](doc/markdown/usage.md) for a full usage workflow demonstration. - -# Appendix - -## Supported file systems - -Currently I/O Riot supports replaying I/O on ``ext2``, ``ext3``, ``ext4`` and ``xfs``. However, it should be straightforward add additional file systems. - -## Supported syscalls - -Currently, these file I/O related syscalls are supported (as of CentOS 7): - -``` -open -openat -lseek -llseek -fcntl